[pcap-ng-format] comments/edits on pcapng
Michael Richardson
mcr+ietf at sandelman.ca
Wed Nov 11 01:05:25 UTC 2015
11hr trips home are good for document review...
Is the XML around? Found it: https://github.com/pcapng/pcapng/pull/38
I reviewed draft-tuexen-opsawg-pcapng, while it hasn't had an -01, some work
has been occuring in the github copy, and so the effort isn't dead, just not
as visible.
For those that don't know, I'm been the packager/maintainer for tcpdump and
libpcap for about the last 15 years, and until 5-6 years ago, pretty much
anyone that used *pcap* format, used libpcap to read/write it.
That has changed (which is good!) since the advent of the pcapng format.
I personally didn't have a lot of time to review the ideas when they were in
their formative stage. Aside from my initial whine, I think the document is
quite mature, and I'd like to see it move forward, either within opsawg, or
as ISE.
Tcpdump has been able to read pcapng files for awhile now, but still writes
pcap format files.
This is definitely not my first read of the document, but the idea of going
via OPSAWG surfaced at IETF90 (Toronto), but seems to have gotten stuck?
In general, I had thought that pcapng was going to start with an identical
magic as pcap, but that the "version_major" would say, "2", i.e:
pcap1: bpf_u_int32 magic = 0xa1b2c3d4 (mutated for byte order)
u_short version_major;
u_short version_minor;
when in fact, pcapng files start with:
int32_t type = 0x0A0D0D0A
int32_t length;
int32_t byte_order_magic;
int16_t major; int16_t minor;
and the initial block isn't any different than any other blocks. I see the
logic for this, and I don't have a problem with this on account of working,
deployed code, I just wish they could all have been "pcap" files. So this is
more a whine than a comment.
I also find "pcapng" a poor long-term name, mostly it's the "ng" part that I
dislike. .pc2p or something might have been better.
section 4.1 says this about major/minor:
Major Version: number of the current mayor version of the
format. Current value is 1. This value should change if the format changes in
such a way that code that reads the new format could not read the old format
(i.e., code to read both formats would have to check the version number and
use different code paths for the two formats) and code that reads the old
format could not read the new format.
Minor Version: number of the current minor version of the
format. Current value is 0. This value should change if the format
changes in such a way that code that reads the new format could read
the old format without checking the version number but code that
reads the old format could not read all files in the new format.
and I think that I don't buy it.
[First, "major version" should have been started at "2" :-) ]
But, more importantly, we have an easily, and almost always incremenally
extendable file format. It's hard to imagine a change so drastic that it
would be worth incrementing the major version number that would still leave
enough of the file format intact that there would be any value left.
One would also wind up changing magic/header numbers.
With protocols that are online, it is different, as there can be a bit of
negotiation when major numbers don't match, but not really the case for files
resting on disk.
So I think that we should simply turn this into a 4-byte int32 field. Let's
just put the highest *RFC* number that must be understood in order to comprehend
all the blocks present. At approx. 3500 RFCs/10 years, 32-bits will last a
long long long time... We could even do this with just the Minor Version and
be good until rfc65535, which might be by oh year 2265 assuming the IETF
continues at it's present rate.
Maybe we could have a bit at the top which says, "There are experimental
blocks, and understanding them is critical to the semantic content of file"
On the Interface Description Block, (section: 4.2), the table shown should be
an IANA controlled registry. The reference to section 3.5 is initially
confusing when reading. I think that there should be a single table (in
section 3.5). I see that the Section Header Block also reuses codes used in
the IDB: I think that this is a mistake, the codes in a comment block should
not be context dependant. My pull request takes care of all of them, I
hope. I numbered them sequentially, but we could leave gaps.
We will need a registration formula for this registry, and I think that
First-Come / First Served (RFC5226/BCP26, section 4.1) will do fine for this one.
On the subject of the Encryption Block. In discussion on the list many asked
if we needed it. Let me suggest that we do, but that yes, we need more
information in it. First, we need to make it look more like ESP (RFC4303):
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| Security Parameters Index (SPI) | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data* (variable) | | ^
~ ~ | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |ered*
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
But, we don't need a SeqNumber, or a Next Header. We can probably assume
that the things inside are already padded to 32-bit boundary, but
self-describing padding is easy and simple. Yes, we should have an ICV.
I make the SPI 64-bits to give it more space. Who can decrypt and
even with what algorithm is actually unimportant/private. If you have
to ask, then it's not you! Further a comment in the SHR would permit
proper document management, if the file was part of an evidence locker.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI -- 64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data* (variable) |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 bytes) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+
| | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Now, about LinkType: I suggest that having libpcap/tcpdump continue to
maintain the table is not ideal. Instead, let's create an IANA registry for
it, populate it with existing values, and make the libpcap group the Expert
Review.
--
Michael Richardson <mcr+IETF at sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 481 bytes
Desc: not available
URL: <http://www.winpcap.org/pipermail/pcap-ng-format/attachments/20151110/fe1b4e62/attachment.pgp>
More information about the pcap-ng-format
mailing list