[pcap-ng-format] [tcpdump-workers] comments/edits on pcapng

[Guy Harris]

On Nov 12, 2015, at 8:26 AM, Michael Richardson <mcr+ietf at sandelman.ca> wrote:

> Guy Harris <guy at alum.mit.edu> wrote:
> 

>> I don't see what the problem is with different block types having
>> different option name spaces.  Common code to handle options in all
>> block types wouldn't be that useful - that code wouldn't, for example,
>> be able to do anything useful with the interface speed option in a Name
>> Resolution Block.  (And what do you mean by a "comment block"; we don't
>> have blocks whose sole purpose is to contain comments, we have a
>> comment option that can be used in any block, the content of which is
>> solely intended for display to humans.)
> 
> Perhaps I've mis-understood how these suboptions work.

The idea is that each block type has its own set of options, with every set being required to include an option numbered 0 for "end of options" and an option numbered 1 for "UTF-8 comment string".  Code to read a particular block type handles all the options for that block type, including options 0 and 1; the code to read option 1 is simple, it's the code to *display* it that does most of the work, and that'd probably be different for different block types anyway.

>>> 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.
> 
>> Well, the first question is what sort of information would be put in
>> it.  The current spec just says it "is used to store encrypted data"
>> and says of the data in it that "Once decrypted, it originates other
>> blocks.", but it doesn't say what sort of stuff is being encrypted!
>> Lists of credit card numbers? :-)
> 
> I think that essentially, it encrypts other blocks, such as captures, etc.

We should probably indicate that, then, rather than just vaguely stating "An Encryption Block is used to store encrypted data." and "Encrypted Data: data of this block. Once decrypted, it originates other blocks."

Or perhaps we should remove it from the spec, and put something back in once it's finalized to the point of having a block number assigned and having an indication of what it contains and how it should be handled by readers.

>>> 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.
> 
>> So where would the actual formats be made available?
> 
> We'd have to include a few key ones into this document, and the rest would
> continue to have the rather loose references that the web site has now.

The Web site also stores a few specs linked to from entries in the table at

	http://www.tcpdump.org/linktypes.html

for formats for which there's no spec to point to elsewhere on the Web; where should those specs be stored?

In addition, the description column in that table has some fairly long entries, which look longer than the sort of things that show up in IANA registries such as

	http://www.iana.org/assignments/snoop-datalink-types/snoop-datalink-types.xhtml#snoop-datalink-types-2

That table just points to RFCs, and the main RFC:

	http://tools.ietf.org/html/rfc1761

just has a rather terse table:

        Datalink Type:

                A 32-bit (4 octet) field identifying the type of
                datalink header used in the packet records that follow.
                The datalink type codes are listed in the table below:

                Datalink Type           Code
                -------------           ----
                IEEE 802.3              0
                IEEE 802.4 Token Bus    1
                IEEE 802.5 Token Ring   2
                IEEE 802.6 Metro Net    3
                Ethernet                4
                HDLC                    5
                Character Synchronous   6
                IBM Channel-to-Channel  7
                FDDI                    8
                Other                   9
                Unassigned              10 - 4294967295

most of the entries of which are probably sufficient (i.e., they just contain a frame for the particular LAN/MAN technology, with nothing added, subtracted, or rearranged), but "HDLC", "Character Synchronous", and "IBM Channel-to-Channel" are too vague to actually be useful.  That might be because those DLPI types were reserved for those purposes but never actually officially *used* for those purposes, and thus nobody had to figure out what the format of those packets were.

We could publish an RFC containing the current set of link-layer header types from the tcpdump.org site, perhaps including the text from the specs stored on tcpdump.org, and refer to that from the pcap-ng spec *and* from any pcap spec we publish as an I-D or RFC; I'd have it give the descriptions from the tcpdump.org site, to be a little more restrictive than the snoop spec - I'd rather not have to throw heuristics into tcpdump or Wireshark to distinguish between packets using one interpretation of the description of LINKTYPE_FOOBAR and packets using another interpretation.

>> I don't think an RFC is required as a reference, so we wouldn't have to
>> wait for an RFC to percolate through the process before making a new
>> link-layer header type available, but that would leave open the
>> question of what to use as a reference until the RFC comes out, and if
>> you don't want www.tcpdump.org to store the description until it shows
>> up in an RFC...
> 
> So, what happens right now is that we do Expert Review.  People ask us for a
> link type, and we beat on them a bit to give a slightly stable document to
> point at, or at least to argue why no existing type works for them.
> Then they get the number, and if we are lucky, we also have a stable link to
> their format.  With IANA Expert Review, we could essentially do exactly the
> same thing --- just that IANA would write down the result.
> 
> Numbers can be assigned by RFC as well, and can be assigned early, and IANA
> is happy to change the reference from draft-foo-bar to RFCxyaz as the
> document progresses.

So it sounds as if we can assign a number before the RFC is issued for a new block type/link type/option code/etc., and update the registry when an I-D is issued or updated or an RFC is issued.

> But, it can also just be a link to http://www.company.com/technote/foo.html,
> or it can, as it says now, say, "Used by Company XYZ for Proprietary FOO"

So presumably somebody who wants a link type would go to

	http://www.iana.org/form/protocol-assignment

and request one.

So does a Designated Expert for a registry get to edit whatever underlying file or database is used to generate pages for the registry in question?  I.e., what would the Designated Expert do when adding a new block type/link type/option/etc.?  Is there a repository to which they're granted access and to which they do a commit/push/whatever with the update?  Is it a database for which there's some Web interface to publish updates?

Or does the Designated Expert send a request to somebody at the IANA, who updates the file/database/whatever?

I assume the actual underlying mechanism that implements the Protocol Assignment registry pages is documented *somewhere*.