Re: MIME type for libpcap (tcpdump -w)

[Guy Harris <guy () alum mit edu>]

On Nov 9, 2010, at 5:00 PM, Glen Turner wrote:

> The largest change is that I have altered the proposed MIME type based
> on the advice received.  The proposed type is now vnd.tcpdump.pcap. I am
> told the syntax of the previous "vnd.tcpdump.org-libpcap" was
> problematic, as some applications parse MIME types using the "." as a
> separator.

I.e., the problem isn't with the "-" prior to "libpcap", it's with the "." between "tcpdump" and "org", so that they 
think that the vendor is "tcpdump" and the final component of the type is "org-libpcap"?

> Apparently I should not anticipate issues with "tcpdump" as
> the vendor/product name.

Or perhaps

        vnd.tcpdump-org.pcap

I guess the group working on tcpdump and libpcap could be called "tcpdump.org" - or "the Tcpdump Group" - but, with no 
"."s allowed in the vendor name, we could use "-".

Michael, what do *you* prefer as the organization's name here - "tcpdump", "tcpdump-org", "tcpdump-group", or something 
else?

> 6. Security considerations
> See RFC 4288, section 4.6
> Note that discussion of security considerations is required.
> [

        [list of problems caused by the fact that network traffic can carry just about any sort of data, and a network 
traffic analyzer could analyze that data pretty much to any depth imaginable, elided]

        …

> Bugs may exist in some reading programs which could possibly be
> exploited to gain unauthorized access to a recipient's system.  Apart
> from noting this possibility, there is no specific action to take to
> prevent this, apart from the timely correction of such bugs if any are
> found.

That last item covers most of the "the media does not itself contain XXX, but the traffic in the capture could contain 
XXX, and if you don't parse XXX carefully, bad things could happen" items.  If we should mention specific examples of 
XXX known to be unsafely parsed by some code ("active content", XML, ASN.1), should we put the "Bugs may exist…" item 
before or after that list, e.g. "before" as in "here's a general problem, and here are some examples"?  Or is "Bugs may 
exist in some reading programs which could possibly be exploited to gain unauthorized access to a recipient's system" a 
statement that could be made about *anything* that has a MIME type (if you parse text/plain by, for example, reading 
each line by doing a gets() into a fixed-length buffer…)?

> 7. Interoperability considerations
> See RFC 4288, section 4.5
> [
> A network protocol capture is written in host byte order. The first four
> bytes form a magic number. 0xa1b2c3d4 indicates that the reader has the
> same byte order as the writer. 0xd4c3b2a1 indicates that the reader has
> a different byte order from the writer and so the reader should swap
> bytes in the general header, in the packet header and in some link layer
> headers. The bytes of the captured packet are always in the order they
> appeared on the wire.

I might say "the *other* bytes of the captured packet" - the link-layer headers in question are "bytes of the captured 
packet" in that they're in the blob of data libpcap hands you as the packet data, but do need to be byte-swapped.

> Data link types are assigned by tcpdump.org and can be viewed in the
> file pcap-common.c of the libpcap code. The data link types
> LINKTYPE_USER0 to LINKTYPE_USER15 are reserved for local use and thus
> captures containing those data link types are intentionally not
> interoperable.

Hopefully they won't get upset if, in a future release, the LINKTYPE_ values move to a header file.  (Any API that 
supports pcap-ng as well as pcap will probably supply LINKTYPE_ values rather than DLT_ values, and thus those values 
will have to appear in some header file.)

> Person to contact for further information
> See RFC 4288, section 4.9
>   * Name
>     [Guy Harris]
>   * E-mail
>     [guy@____.___.___]
>   * Author/Change controller
>     [Guy Harris <guy@____.___.___>]

Again - Michael, do you want to be the contact here, rather than me?  I'm willing to be the contact (in which case the 
underscores would presumably be replaced by the character they're masking out; I infer from the number of underscores 
that you intended to fill in the three blanks with "alum", "mit", and "edu" respectively :-)).

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.