Re: MIME type for libpcap (tcpdump -w)

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

Thanks everyone for comments, including offlist from my coworkers at
AARNet and the media people at CSIRO.

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. Apparently I should not anticipate issues with "tcpdump" as
the vendor/product name.

Are there further comments on this Version 2 of this proposal?


Your Name:
[Glen Turner]

Your Email Address:
[gdt@___.__.__]


1. Media Type Name:
     See RFC 2046 section 3, and RFC 2077.
[application]


2. Subtype name (See Existing subtype names)
     See also RFC 2046, and RFC 4288, sections 3 and 4.2.
     Note: Registrations in the standards tree must be approved by the
     IESG and must correspond to a formal publication by a recognized
     standards body.
Vendor Tree - [vnd.tcpdump.pcap]


3. Required parameters
     See RFC 2046 section 1, and RFC 4288, section 4.3
[]


4. Optional parameters
     See RFC 2046 section 1, and RFC 4288, section 4.3
[]


5. Encoding considerations
     See RFC 2046 section 6, and RFC 4288 section 4.8.
[ ] 7 bit text
[ ] 8 bit text
     (this media type may require encoding on transports not capable of
      handling 8 bit text)
[X] binary
     (this media type may require encoding on transports not capable of
      handling binary)
[ ] framed
     (transport must provde framing information)


6. Security considerations
See RFC 4288, section 4.6
Note that discussion of security considerations is required.
[
The media does not contain "active content" (see RFC4288 section 4.6).
However a packet capture may contain traffic created by software which
uses "active content". Attempts to decode the contents of these captured
packets beyond a simple hex dump may require the interpretation of
"active content". Such interpretation should take care not to use files
and other resources on the machine inspecting the packet capture.

The media does not contain "compressed content" (see RFC4288 section
4.6). However a packet capture may contain traffic created by software
which uses compression. Attempts to decode the contents of these
captured packets beyond a simple hex dump may require decompression.
Such decompression should take care to ameliorate the risk of excessive
resource use on the machine inspecting the packet capture.

The media does not contain XML. However a packet capture may contain
traffic created by software which uses XML. Attempts to decode the
contents of these captured packets beyond a simple hex dump may require
the parsing of XML. Such parsing should take care to ameliorate the
risks noted in Section 10 "Security Considerations" of RFC3023 "XML
Media Types".

The media does not contain ASN.1. However a packet capture may contain
traffic created by software which uses ASN.1. Attempts to decode the
contents of these captured packets beyond a simple hex dump may require
the parsing of ASN.1. Such parsing has a history of implementation flaws
which can be exploited for denial of service or access. There were 39
distinct NIST CVE entries concerning the interpretation of ASN.1 between
2004 and 2010.

The general header and the packet headers may form a covert channel
which identifies the class of host which created the media.

The media contains captured network packets. These packets may reveal
the private matters of network users. Those network users may be unaware
that a packet capture has taken place. Even where software attempts to
preserve network user privacy by encrypting packet content (such as by
using Transport Layer Security or IPsec) the packets' headers and timing
are still subject to traffic analysis.

It is strongly recommended that packet captures be encrypted when
further transmitted (such as by e-mail or web) to preserve network
users' privacy from further interception.

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


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.

The accuracy and resolution of the time stamp on each packet and the
moment during packet processing when the timestamp is applied depends
upon the host's hardware and its operating system.

As a result of the two items above, differing hosts capturing the same
traffic at the same moment may not produce the same pcap media.

The header contains major and minor version numbers to allow a reading
program to determine if it is compatible with the media. A reading
program is not compatible if it encounters a major version number
greater than it expects.

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


8. Published specification
See RFC 4288, section 4.10
[
See the file pcap-savefile.manfile.in in the libpcap source code. Source
code for libpcap and tcpdump is available from
    <http://www.tcpdump.org/>.

See the web page "Libpcap File Format" at
    <http://wiki.wireshark.org/Development/LibpcapFileFormat>.

The pcap file format was invented for use by tcpdump. Tcpdump -- and its
pcap file format -- was created by V Jacobson, C Leres and S McCanne,
was included in Berkeley Software Distribution (BSD) UNIX, and is widely
available on many systems.
]


9. Applications which use this media type
See RFC 4288, section 4.5
[
Libpcap, a C library to capture network packets for POSIX-like systems.

Net::Pcap, Jpcap, python-libpcap, Ruby/Pcap are respectively Perl, Java,
Python and Ruby bindings for libpcap.

WinPcap, a port of libpcap for Microsoft Windows.

Libpcap and WinPcap are in turn used by:

Tcpdump, a command line tool to capture and display network packets.

WinDump, a port of tcpdump to Microsoft Windows.

Wireshark (formerly Ethereal), a graphical tool to capture, display and
analyse network packets.

Snort, a network intrusion detector.

Many other programs which capture, display, analyse, manipulate and
replay network traffic use this media format.
]


10. Additional information
See RFC 4288, section 4.11
  * Magic number(s)
    [0xa1b2c3d4, 0xd4c3b2a1]

  * File extension(s)
    [.pcap, .cap, .dmp]

  * Macintosh File Type Code(s)
    []

  * Object Identifier(s) or OID(s)
   (See RFC1494)
    []


11. Intended usage
[Common]
[
Network captures written in the pcap format are widely used in the data
networking community. They can be sent in email with a strong
expectation that the receiver's network capture software can read them.
]


12. Other Information/General Comment
[
For further information see <http://www.tcpdump.org/>.
]


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

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