On Wed, Nov 11, 2015 at 10:05 AM, Michael Richardson <[email protected]> wrote: > > 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.
I'm glad to hear this - it seemed like something worth pursuing - I had a todo that got buried under other things to followup with the authors to see whatever happened. > > 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. The IETF is traditionally not very good at formats and such, but I'm game to try progress it under OpsAWG. W > > 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 <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
