Re: MIME type for libpcap (tcpdump -w)

[Glen Turner <gdt () gdt id au>]

On Tue, 2010-11-09 at 17:46 -0800, Guy Harris wrote:

> 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"?

Yep, that's the issue. Programmers expect
  TYPE.VENDOR.FORMAT
and MIME types which don't fall into that are problematic even if that
MIME type is syntactically correct.

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

Noting that IANA would be good with any of those -- "tcpdump" is a
product name, "tcpdump-org" or "tcpdump-group" are vendor names. Both
vendor and product names are acceptable. They don't need to be formal
names (ie, trademarked or in a regulator's register of business names).

The advice I got was basically to be simple and direct whilst not
precluding future MIME types from that organisation/product (in our
case, a possible vnd.....pcap-ng).


> [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]

The RFC for MIME type applications requires issues for some data types
to be called out explicitly in the Security Considerations. So it's
wordy to meet that requirement :-(  I could bundle them altogether, but
that would make it less easy to show requirement asked--->satisfied
traceability (from which concern you can gather that I've done far too
much formal software testing, so feel free to tell me that documents are
for humans to read and to coalesce the paras).


> > 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…)?

That para is stolen pretty much word-for-word from the
application/postscript description, which is held up as a model. I
think we could express what it is saying better, but using the template
word-for-word is less likely to cause hassle (ie, IANA can't object to
the wording. Again, written by person with brain burnt by too much
formal software testing applies).


> 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.

Yep, will fix.


> Hopefully they won't get upset if, in a future release, the LINKTYPE_
> values move to a header file.

We should be fair to future readers of the document. So, will fix by
being less specific about where the definition of LINKTYPE_s are found:
something like "defined in the libpcap source code available from
www.tcpdump.org".

Cheers, Glen

-- 
 Glen Turner
 www.gdt.id.au/~gdt

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