1681 lines
63 KiB
Plaintext
1681 lines
63 KiB
Plaintext
|
|
|||
|
|
|||
|
Network Working Group L. Degioanni
|
|||
|
Internet-Draft F. Risso
|
|||
|
Expires: August 30, 2004 Politecnico di Torino
|
|||
|
March 2004
|
|||
|
|
|||
|
|
|||
|
PCAP New Generation Dump File Format
|
|||
|
pcap
|
|||
|
|
|||
|
Status of this Memo
|
|||
|
|
|||
|
This document is an Internet-Draft and is in full conformance with
|
|||
|
all provisions of Section 10 of RFC2026.
|
|||
|
|
|||
|
Internet-Drafts are working documents of the Internet Engineering
|
|||
|
Task Force (IETF), its areas, and its working groups. Note that other
|
|||
|
groups may also distribute working documents as Internet-Drafts.
|
|||
|
|
|||
|
Internet-Drafts are draft documents valid for a maximum of six months
|
|||
|
and may be updated, replaced, or obsoleted by other documents at any
|
|||
|
time. It is inappropriate to use Internet-Drafts as reference
|
|||
|
material or to cite them other than as "work in progress."
|
|||
|
|
|||
|
The list of current Internet-Drafts can be accessed at http://
|
|||
|
www.ietf.org/ietf/1id-abstracts.txt.
|
|||
|
|
|||
|
The list of Internet-Draft Shadow Directories can be accessed at
|
|||
|
http://www.ietf.org/shadow.html.
|
|||
|
|
|||
|
This Internet-Draft will expire on August 30, 2004.
|
|||
|
|
|||
|
Copyright Notice
|
|||
|
|
|||
|
Copyright (C) The Internet Society (2004). All Rights Reserved.
|
|||
|
|
|||
|
Abstract
|
|||
|
|
|||
|
This document describes a format to dump captured packets on a file.
|
|||
|
This format is extensible and it is currently proposed for
|
|||
|
implementation in the libpcap/WinPcap packet capture library.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 1]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
Table of Contents
|
|||
|
|
|||
|
1. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
|||
|
2. General File Structure . . . . . . . . . . . . . . . . . . . . 4
|
|||
|
2.1 General Block Structure . . . . . . . . . . . . . . . . . . . 4
|
|||
|
2.2 Block Types . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
|||
|
2.3 Block Hierarchy and Precedence . . . . . . . . . . . . . . . . 5
|
|||
|
2.4 Data format . . . . . . . . . . . . . . . . . . . . . . . . . 6
|
|||
|
3. Block Definition . . . . . . . . . . . . . . . . . . . . . . . 8
|
|||
|
3.1 Section Header Block (mandatory) . . . . . . . . . . . . . . . 8
|
|||
|
3.2 Interface Description Block (mandatory) . . . . . . . . . . . 9
|
|||
|
3.3 Packet Block (optional) . . . . . . . . . . . . . . . . . . . 13
|
|||
|
3.4 Simple Packet Block (optional) . . . . . . . . . . . . . . . . 15
|
|||
|
3.5 Name Resolution Block (optional) . . . . . . . . . . . . . . . 16
|
|||
|
3.6 Interface Statistics Block (optional) . . . . . . . . . . . . 18
|
|||
|
4. Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
|
|||
|
5. Experimental Blocks (deserved to a further investigation) . . 23
|
|||
|
5.1 Other Packet Blocks (experimental) . . . . . . . . . . . . . . 23
|
|||
|
5.2 Compression Block (experimental) . . . . . . . . . . . . . . . 23
|
|||
|
5.3 Encryption Block (experimental) . . . . . . . . . . . . . . . 23
|
|||
|
5.4 Fixed Length Block (experimental) . . . . . . . . . . . . . . 24
|
|||
|
5.5 Directory Block (experimental) . . . . . . . . . . . . . . . . 25
|
|||
|
5.6 Traffic Statistics and Monitoring Blocks (experimental) . . . 25
|
|||
|
5.7 Event/Security Block (experimental) . . . . . . . . . . . . . 25
|
|||
|
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27
|
|||
|
7. Most important open issues . . . . . . . . . . . . . . . . . . 28
|
|||
|
Intellectual Property and Copyright Statements . . . . . . . . 29
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 2]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
1. Objectives
|
|||
|
|
|||
|
The problem of exchanging packet traces becomes more and more
|
|||
|
critical every day; unfortunately, no standard solutions exist for
|
|||
|
this task right now. One of the most accepted packet interchange
|
|||
|
formats is the one defined by libpcap, which is rather old and does
|
|||
|
not fit for some of the nowadays applications especially in terms of
|
|||
|
extensibility.
|
|||
|
|
|||
|
This document proposes a new format for dumping packet traces. The
|
|||
|
following goals are being pursued:
|
|||
|
|
|||
|
o Extensibility: aside of some common functionalities, third parties
|
|||
|
should be able to enrich the information embedded in the file with
|
|||
|
proprietary extensions, which will be ignored by tools that are
|
|||
|
not able to understand them.
|
|||
|
|
|||
|
o Portability: a capture trace must contain all the information
|
|||
|
needed to read data independently from network, hardware and
|
|||
|
operating system of the machine that made the capture.
|
|||
|
|
|||
|
o Merge/Append data: it should be possible to add data at the end of
|
|||
|
a given file, and the resulting file must still be readable.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 3]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
2. General File Structure
|
|||
|
|
|||
|
2.1 General Block Structure
|
|||
|
|
|||
|
A capture file is organized in blocks, that are appended one to
|
|||
|
another to form the file. All the blocks share a common format, which
|
|||
|
is shown in Figure 1.
|
|||
|
|
|||
|
0 1 2 3
|
|||
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| Block Type |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| Block Total Length |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
/ Block Body /
|
|||
|
/ /* variable length, aligned to 32 bits */ /
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| Block Total Length |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
Figure 1: Basic block structure.
|
|||
|
|
|||
|
The fields have the following meaning:
|
|||
|
|
|||
|
o Block Type (32 bits): unique value that identifies the block.
|
|||
|
Values whose Most Significant Bit (MSB) is equal to 1 are reserved
|
|||
|
for local use. They allow to save private data to the file and to
|
|||
|
extend the file format.
|
|||
|
|
|||
|
o Block Total Length: total size of this block, in bytes. For
|
|||
|
instance, a block that does not have a body has a length of 12
|
|||
|
bytes.
|
|||
|
|
|||
|
o Block Body: content of the block.
|
|||
|
|
|||
|
o Block Total Length: total size of this block, in bytes. This field
|
|||
|
is duplicated for permitting backward file navigation.
|
|||
|
|
|||
|
This structure, shared among all blocks, makes easy to process a file
|
|||
|
and to skip unneeded or unknown blocks. Blocks can be nested one
|
|||
|
inside the others (NOTE: needed?). Some of the blocks are mandatory,
|
|||
|
i.e. a dump file is not valid if they are not present, other are
|
|||
|
optional.
|
|||
|
|
|||
|
The structure of the blocks allows to define other blocks if needed.
|
|||
|
A parser that does non understand them can simply ignore their
|
|||
|
content.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 4]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
2.2 Block Types
|
|||
|
|
|||
|
The currently defined blocks are the following:
|
|||
|
|
|||
|
1. Section Header Block: it defines the most important
|
|||
|
characteristics of the capture file.
|
|||
|
|
|||
|
2. Interface Description Block: it defines the most important
|
|||
|
characteristics of the interface(s) used for capturing traffic.
|
|||
|
|
|||
|
3. Packet Block: it contains a single captured packet, or a portion
|
|||
|
of it.
|
|||
|
|
|||
|
4. Simple Packet Block: it contains a single captured packet, or a
|
|||
|
portion of it, with only a minimal set of information about it.
|
|||
|
|
|||
|
5. Name Resolution Block: it defines the mapping from numeric
|
|||
|
addresses present in the packet dump and the canonical name
|
|||
|
counterpart.
|
|||
|
|
|||
|
6. Capture Statistics Block: it defines how to store some
|
|||
|
statistical data (e.g. packet dropped, etc) which can be useful
|
|||
|
to undestand the conditions in which the capture has been made.
|
|||
|
|
|||
|
7. Compression Marker Block: TODO
|
|||
|
|
|||
|
8. Encryption Marker Block: TODO
|
|||
|
|
|||
|
9. Fixed Length Marker Block: TODO
|
|||
|
|
|||
|
The following blocks instead are considered interesting but the
|
|||
|
authors believe that they deserve more in-depth discussion before
|
|||
|
being defined:
|
|||
|
|
|||
|
1. Further Packet Blocks
|
|||
|
|
|||
|
2. Directory Block
|
|||
|
|
|||
|
3. Traffic Statistics and Monitoring Blocks
|
|||
|
|
|||
|
4. Alert and Security Blocks
|
|||
|
|
|||
|
TODO Currently standardized Block Type codes are specified in
|
|||
|
Appendix 1.
|
|||
|
|
|||
|
2.3 Block Hierarchy and Precedence
|
|||
|
|
|||
|
The file must begin with a Section Header Block. However, more than
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 5]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
one Section Header Block can be present on the dump, each one
|
|||
|
covering the data following it till the next one (or the end of
|
|||
|
file). A Section includes the data delimited by two Section Header
|
|||
|
Blocks (or by a Section Header Block and the end of the file),
|
|||
|
including the first Section Header Block.
|
|||
|
|
|||
|
In case an application cannot read a Section because of different
|
|||
|
version number, it must skip everything until the next Section Header
|
|||
|
Block. Note that, in order to properly skip the blocks until the next
|
|||
|
section, all blocks must have the fields Type and Length at the
|
|||
|
beginning. This is a mandatory requirement that must be maintained in
|
|||
|
future versions of the block format.
|
|||
|
|
|||
|
Figure 2 shows two valid files: the first has a typical
|
|||
|
configuration, with a single Section Header that covers the whole
|
|||
|
file. The second one contains three headers, and is normally the
|
|||
|
result of file concatenation. An application that understands only
|
|||
|
version 1.0 of the file format skips the intermediate section and
|
|||
|
restart processing the packets after the third Section Header.
|
|||
|
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| SHB v1.0 | Data |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
Typical configuration with a single Section Header Block
|
|||
|
|
|||
|
|
|||
|
|-- 1st Section --|-- 2nd Section --|-- 3rd Section --|
|
|||
|
| |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| SHB v1.0 | Data | SHB V1.1 | Data | SHB V1.0 | Data |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
Configuration with three different Section Header Blocks
|
|||
|
|
|||
|
Figure 2: File structure example: the Section Header Block.
|
|||
|
|
|||
|
NOTE: TO BE COMPLETED with some examples of other blocks
|
|||
|
|
|||
|
2.4 Data format
|
|||
|
|
|||
|
Data contained in each section will always be saved according to the
|
|||
|
characteristics (little endian / big endian) of the dumping machine.
|
|||
|
This refers to all fields that are saved as numbers and that span
|
|||
|
over two or more bytes.
|
|||
|
|
|||
|
The approach of having each section saved in the native format of the
|
|||
|
generating host is more efficient because it avoids translation of
|
|||
|
data when reading / writing on the host itself, which is the most
|
|||
|
common case when generating/processing capture dumps.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 6]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
TODO Probably we have to specify something more here. Is what we're
|
|||
|
saying enough to avoid any kind of ambiguity?.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 7]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
3. Block Definition
|
|||
|
|
|||
|
This section details the format of the body of the blocks currently
|
|||
|
defined.
|
|||
|
|
|||
|
3.1 Section Header Block (mandatory)
|
|||
|
|
|||
|
The Section Header Block is mandatory. It identifies the beginning of
|
|||
|
a section of the capture dump file. Its format is shown in Figure 3.
|
|||
|
|
|||
|
0 1 2 3
|
|||
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| Magic |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| Major | Minor |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
/ /
|
|||
|
/ Options (variable) /
|
|||
|
/ /
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
Figure 3: Section Header Block format.
|
|||
|
|
|||
|
The meaning of the fields is:
|
|||
|
|
|||
|
o Magic: magic number, whose value is the hexadecimal number
|
|||
|
0x1A2B3C4D. This number can be used to distinguish section that
|
|||
|
have been saved on little-endian machines from the one saved on
|
|||
|
big-endian machines.
|
|||
|
|
|||
|
o Major: number of the current mayor version of the format. Current
|
|||
|
value is 1.
|
|||
|
|
|||
|
o Minor: number of the current minor version of the format. Current
|
|||
|
value is 0.
|
|||
|
|
|||
|
o Options: optionally, a list of options (formatted according to the
|
|||
|
rules defined in Section 4) can be present.
|
|||
|
|
|||
|
Aside form the options defined in Section 4, the following options
|
|||
|
are valid within this block:
|
|||
|
|
|||
|
+----------------+----------------+----------------+----------------+
|
|||
|
| Name | Code | Length | Description |
|
|||
|
+----------------+----------------+----------------+----------------+
|
|||
|
| Hardware | 2 | variable | An ascii |
|
|||
|
| | | | string |
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 8]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
| | | | containing the |
|
|||
|
| | | | description of |
|
|||
|
| | | | the hardware |
|
|||
|
| | | | used to create |
|
|||
|
| | | | this section. |
|
|||
|
| | | | |
|
|||
|
| Operating | 3 | variable | An ascii |
|
|||
|
| System | | | string |
|
|||
|
| | | | containing the |
|
|||
|
| | | | name of the |
|
|||
|
| | | | operating |
|
|||
|
| | | | system used to |
|
|||
|
| | | | create this |
|
|||
|
| | | | section. |
|
|||
|
| | | | |
|
|||
|
| User | 3 | variable | An ascii |
|
|||
|
| Application | | | string |
|
|||
|
| | | | containing the |
|
|||
|
| | | | name of the |
|
|||
|
| | | | application |
|
|||
|
| | | | used to create |
|
|||
|
| | | | this section. |
|
|||
|
+----------------+----------------+----------------+----------------+
|
|||
|
|
|||
|
Table 1
|
|||
|
|
|||
|
The Section Header Block does not contain data but it rather
|
|||
|
identifies a list of blocks (interfaces, packets) that are logically
|
|||
|
correlated. This block does not contain any reference to the size of
|
|||
|
the section it is currently delimiting, therefore the reader cannot
|
|||
|
skip a whole section at once. In case a section must be skipped, the
|
|||
|
user has to repeatedly skip all the blocks contained within it; this
|
|||
|
makes the parsing of the file slower but it permits to append several
|
|||
|
capture dumps at the same file.
|
|||
|
|
|||
|
3.2 Interface Description Block (mandatory)
|
|||
|
|
|||
|
The Interface Description Block is mandatory. This block is needed to
|
|||
|
specify the characteristics of the network interface on which the
|
|||
|
capture has been made. In order to properly associate the captured
|
|||
|
data to the corresponding interface, the Interface Description Block
|
|||
|
must be defined before any other block that uses it; therefore, this
|
|||
|
block is usually placed immediately after the Section Header Block.
|
|||
|
|
|||
|
An Interface Description Block is valid only inside the section which
|
|||
|
it belongs to. The structure of a Interface Description Block is
|
|||
|
shown in Figure 4.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 9]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
0 1 2 3
|
|||
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| Interface ID | LinkType |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| SnapLen |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
/ /
|
|||
|
/ Options (variable) /
|
|||
|
/ /
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
Figure 4: Interface Description Block format.
|
|||
|
|
|||
|
The meaning of the fields is:
|
|||
|
|
|||
|
o Interface ID: a progressive number that identifies uniquely any
|
|||
|
interface inside current section. Two Interface Description Blocks
|
|||
|
can have the same Interface ID only if they are in different
|
|||
|
sections of the file. The Interface ID is referenced by the packet
|
|||
|
blocks.
|
|||
|
|
|||
|
o LinkType: a value that defines the link layer type of this
|
|||
|
interface.
|
|||
|
|
|||
|
o SnapLen: maximum number of bytes dumped from each packet. The
|
|||
|
portion of each packet that exceeds this value will not be stored
|
|||
|
in the file.
|
|||
|
|
|||
|
o Options: optionally, a list of options (formatted according to the
|
|||
|
rules defined in Section 4) can be present.
|
|||
|
|
|||
|
In addition to the options defined in Section 4, the following
|
|||
|
options are valid within this block:
|
|||
|
|
|||
|
+----------------+----------------+----------------+----------------+
|
|||
|
| Name | Code | Length | Description |
|
|||
|
+----------------+----------------+----------------+----------------+
|
|||
|
| if_name | 2 | Variable | Name of the |
|
|||
|
| | | | device used to |
|
|||
|
| | | | capture data. |
|
|||
|
| | | | |
|
|||
|
| if_IPv4addr | 3 | 8 | Interface |
|
|||
|
| | | | network |
|
|||
|
| | | | address and |
|
|||
|
| | | | netmask. |
|
|||
|
| | | | |
|
|||
|
| if_IPv6addr | 4 | 17 | Interface |
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 10]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
| | | | network |
|
|||
|
| | | | address and |
|
|||
|
| | | | prefix length |
|
|||
|
| | | | (stored in the |
|
|||
|
| | | | last byte). |
|
|||
|
| | | | |
|
|||
|
| if_MACaddr | 5 | 6 | Interface |
|
|||
|
| | | | Hardware MAC |
|
|||
|
| | | | address (48 |
|
|||
|
| | | | bits). |
|
|||
|
| | | | |
|
|||
|
| if_EUIaddr | 6 | 8 | Interface |
|
|||
|
| | | | Hardware EUI |
|
|||
|
| | | | address (64 |
|
|||
|
| | | | bits), if |
|
|||
|
| | | | available. |
|
|||
|
| | | | |
|
|||
|
| if_speed | 7 | 8 | Interface |
|
|||
|
| | | | speed (in |
|
|||
|
| | | | bps). |
|
|||
|
| | | | |
|
|||
|
| if_tsaccur | 8 | 1 | Precision of |
|
|||
|
| | | | timestamps. If |
|
|||
|
| | | | the Most |
|
|||
|
| | | | Significant |
|
|||
|
| | | | Bit is equal |
|
|||
|
| | | | to zero, the |
|
|||
|
| | | | remaining bits |
|
|||
|
| | | | indicates the |
|
|||
|
| | | | accuracy as as |
|
|||
|
| | | | a negative |
|
|||
|
| | | | power of 10 |
|
|||
|
| | | | (e.g. 6 means |
|
|||
|
| | | | microsecond |
|
|||
|
| | | | accuracy). If |
|
|||
|
| | | | the Most |
|
|||
|
| | | | Significant |
|
|||
|
| | | | Bit is equal |
|
|||
|
| | | | to zero, the |
|
|||
|
| | | | remaining bits |
|
|||
|
| | | | indicates the |
|
|||
|
| | | | accuracy as as |
|
|||
|
| | | | negative power |
|
|||
|
| | | | of 2 (e.g. 10 |
|
|||
|
| | | | means 1/1024 |
|
|||
|
| | | | of second). If |
|
|||
|
| | | | this option is |
|
|||
|
| | | | not present, a |
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 11]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
| | | | precision of |
|
|||
|
| | | | 10^-6 is |
|
|||
|
| | | | assumed. |
|
|||
|
| | | | |
|
|||
|
| if_tzone | 9 | 4 | Time zone for |
|
|||
|
| | | | GMT support |
|
|||
|
| | | | (TODO: specify |
|
|||
|
| | | | better). |
|
|||
|
| | | | |
|
|||
|
| if_flags | 10 | 4 | Interface |
|
|||
|
| | | | flags. (TODO: |
|
|||
|
| | | | specify |
|
|||
|
| | | | better. |
|
|||
|
| | | | Possible |
|
|||
|
| | | | flags: |
|
|||
|
| | | | promiscuous, |
|
|||
|
| | | | inbound/outbou |
|
|||
|
| | | | nd, traffic |
|
|||
|
| | | | filtered |
|
|||
|
| | | | during |
|
|||
|
| | | | capture). |
|
|||
|
| | | | |
|
|||
|
| if_filter | 11 | variable | The filter |
|
|||
|
| | | | (e.g. "capture |
|
|||
|
| | | | only TCP |
|
|||
|
| | | | traffic") used |
|
|||
|
| | | | to capture |
|
|||
|
| | | | traffic. The |
|
|||
|
| | | | first byte of |
|
|||
|
| | | | the Option |
|
|||
|
| | | | Data keeps a |
|
|||
|
| | | | code of the |
|
|||
|
| | | | filter used |
|
|||
|
| | | | (e.g. if this |
|
|||
|
| | | | is a libpcap |
|
|||
|
| | | | string, or BPF |
|
|||
|
| | | | bytecode, and |
|
|||
|
| | | | more). More |
|
|||
|
| | | | details about |
|
|||
|
| | | | this format |
|
|||
|
| | | | will be |
|
|||
|
| | | | presented in |
|
|||
|
| | | | Appendix XXX |
|
|||
|
| | | | (TODO). |
|
|||
|
| | | | |
|
|||
|
| if_opersystem | 12 | variable | An ascii |
|
|||
|
| | | | string |
|
|||
|
| | | | containing the |
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 12]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
| | | | name of the |
|
|||
|
| | | | operating |
|
|||
|
| | | | system of the |
|
|||
|
| | | | machine that |
|
|||
|
| | | | hosts this |
|
|||
|
| | | | interface. |
|
|||
|
| | | | This can be |
|
|||
|
| | | | different from |
|
|||
|
| | | | the same |
|
|||
|
| | | | information |
|
|||
|
| | | | that can be |
|
|||
|
| | | | contained by |
|
|||
|
| | | | the Section |
|
|||
|
| | | | Header Block |
|
|||
|
| | | | (Section 3.1) |
|
|||
|
| | | | because the |
|
|||
|
| | | | capture can |
|
|||
|
| | | | have been done |
|
|||
|
| | | | on a remote |
|
|||
|
| | | | machine. |
|
|||
|
+----------------+----------------+----------------+----------------+
|
|||
|
|
|||
|
Table 2
|
|||
|
|
|||
|
|
|||
|
3.3 Packet Block (optional)
|
|||
|
|
|||
|
A Packet Block is the standard container for storing the packets
|
|||
|
coming from the network. The Packet Block is optional because packets
|
|||
|
can be stored either by means of this block or the Simple Packet
|
|||
|
Block, which can be used to speed up dump generation. The format of a
|
|||
|
packet block is shown in Figure 5.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 13]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
0 1 2 3
|
|||
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| Interface ID | Drops Count |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| Timestamp (High) |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| Timestamp (Low) |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| Captured Len |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| Packet Len |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| |
|
|||
|
| Packet Data |
|
|||
|
| |
|
|||
|
| /* variable length, byte-aligned */ |
|
|||
|
| |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
/ /
|
|||
|
/ Options (variable) /
|
|||
|
/ /
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
Figure 5: Packet Block format.
|
|||
|
|
|||
|
The Packet Block has the following fields:
|
|||
|
|
|||
|
o Interface ID: Specifies the interface this packet comes from, and
|
|||
|
corresponds to the ID of one of the Interface Description Blocks
|
|||
|
present in this section of the file (see Figure 4).
|
|||
|
|
|||
|
o Drops Count: a local drop counter. It specified the number of
|
|||
|
packets lost (by the interface and the operating system) between
|
|||
|
this packet and the preceding one. The value xFFFF (in
|
|||
|
hexadecimal) is reserved for those systems in which this
|
|||
|
information is not available.
|
|||
|
|
|||
|
o Timestamp (High): the most significative part of the timestamp. in
|
|||
|
standard Unix format, i.e. from 1/1/1970.
|
|||
|
|
|||
|
o Timestamp (Low): the less significative part of the timestamp. The
|
|||
|
way to interpret this field is specified by the 'ts_accur' option
|
|||
|
(see Figure 4) of the Interface Description block referenced by
|
|||
|
this packet. If the Interface Description block does not contain a
|
|||
|
'ts_accur' option, then this field is expressed in microseconds.
|
|||
|
|
|||
|
o Captured Len: number of bytes captured from the packet (i.e. the
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 14]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
length of the Packet Data field). It will be the minimum value
|
|||
|
among the actual Packet Length and the snapshot length (defined in
|
|||
|
Figure 4).
|
|||
|
|
|||
|
o Packet Len: actual length of the packet when it was transmitted on
|
|||
|
the network. Can be different from Captured Len if the user wants
|
|||
|
only a snapshot of the packet.
|
|||
|
|
|||
|
o Packet Data: the data coming from the network, including
|
|||
|
link-layer headers. The length of this field is Captured Len. The
|
|||
|
format of the link-layer headers depends on the LinkType field
|
|||
|
specified in the Interface Description Block (see Section 3.2) and
|
|||
|
it is specified in Appendix XXX (TODO).
|
|||
|
|
|||
|
o Options: optionally, a list of options (formatted according to the
|
|||
|
rules defined in Section 4) can be present.
|
|||
|
|
|||
|
|
|||
|
3.4 Simple Packet Block (optional)
|
|||
|
|
|||
|
The Simple Packet Block is a lightweight container for storing the
|
|||
|
packets coming from the network. Its presence is optional.
|
|||
|
|
|||
|
A Simple Packet Block is similar to a Packet Block (see Section 3.3),
|
|||
|
but it is smaller, simpler to process and contains only a minimal set
|
|||
|
of information. This block is preferred to the standard Packet Block
|
|||
|
when performance or space occupation are critical factors, such as in
|
|||
|
sustained traffic dump applications. A capture file can contain both
|
|||
|
Packet Blocks and Simple Packet Blocks: for example, a capture tool
|
|||
|
could switch from Packet Blocks to Simple Packet Blocks when the
|
|||
|
hardware resources become critical.
|
|||
|
|
|||
|
The Simple Packet Block does not contain the Interface ID field.
|
|||
|
Therefore, it must be assumed that all the Simple Packet Blocks have
|
|||
|
been captured on the interface previously specified in the Interface
|
|||
|
Description Block.
|
|||
|
|
|||
|
Figure 6 shows the format of the Simple Packet Block.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 15]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
0 1 2 3
|
|||
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| Packet Len |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| |
|
|||
|
| Packet Data |
|
|||
|
| |
|
|||
|
| /* variable length, byte-aligned */ |
|
|||
|
| |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
Figure 6: Simple Packet Block format.
|
|||
|
|
|||
|
The Packet Block has the following fields:
|
|||
|
|
|||
|
o Packet Len: actual length of the packet when it was transmitted on
|
|||
|
the network. Can be different from captured len if the packet has
|
|||
|
been truncated.
|
|||
|
|
|||
|
o Packet data: the data coming from the network, including
|
|||
|
link-layers headers. The length of this field can be derived from
|
|||
|
the field Block Total Length, present in the Block Header.
|
|||
|
|
|||
|
The Simple Packet Block does not contain the timestamp because this
|
|||
|
is one of the most costly operations on PCs. Additionally, there are
|
|||
|
applications that do not require it; e.g. an Intrusion Detection
|
|||
|
System is interested in packets, not in their timestamp.
|
|||
|
|
|||
|
The Simple Packet Block is very efficient in term of disk space: a
|
|||
|
snapshot of length 100 bytes requires only 16 bytes of overhead,
|
|||
|
which corresponds to an efficiency of more than 86%.
|
|||
|
|
|||
|
3.5 Name Resolution Block (optional)
|
|||
|
|
|||
|
The Name Resolution Block is used to support the correlation of
|
|||
|
numeric addresses (present in the captured packets) and their
|
|||
|
corresponding canonical names and it is optional. Having the literal
|
|||
|
names saved in the file, this prevents the need of a name resolution
|
|||
|
in a delayed time, when the association between names and addresses
|
|||
|
can be different from the one in use at capture time. Moreover, The
|
|||
|
Name Resolution Block avoids the need of issuing a lot of DNS
|
|||
|
requests every time the trace capture is opened, and allows to have
|
|||
|
name resolution also when reading the capture with a machine not
|
|||
|
connected to the network.
|
|||
|
|
|||
|
The format of the Name Resolution Block is shown in Figure 7.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 16]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
0 1 2 3
|
|||
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| Record Type | Record Length |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| Record Value |
|
|||
|
| /* variable length, byte-aligned */ |
|
|||
|
| + + + + + + + + + + + + + + + + + + + + + + + + +
|
|||
|
| | | | |
|
|||
|
+-+-+-+-+-+-+-+-+ + + + + + + + + + + + + + + + + + + + + + + + +
|
|||
|
. . . other records . . .
|
|||
|
| Record Type == end_of_recs | Record Length == 00 |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
/ /
|
|||
|
/ Options (variable) /
|
|||
|
/ /
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
Figure 7: Name Resolution Block format.
|
|||
|
|
|||
|
A Name Resolution Block is a zero-terminated list of records (in the
|
|||
|
TLV format), each of which contains an association between a network
|
|||
|
address and a name. There are three possible types of records:
|
|||
|
|
|||
|
+----------------+----------------+----------------+----------------+
|
|||
|
| Name | Code | Length | Description |
|
|||
|
+----------------+----------------+----------------+----------------+
|
|||
|
| end_of_recs | 0 | 0 | End of records |
|
|||
|
| | | | |
|
|||
|
| ip4_rec | 1 | Variable | Specifies an |
|
|||
|
| | | | IPv4 address |
|
|||
|
| | | | (contained in |
|
|||
|
| | | | the first 4 |
|
|||
|
| | | | bytes), |
|
|||
|
| | | | followed by |
|
|||
|
| | | | one or more |
|
|||
|
| | | | zero-terminate |
|
|||
|
| | | | d strings |
|
|||
|
| | | | containing the |
|
|||
|
| | | | DNS entries |
|
|||
|
| | | | for that |
|
|||
|
| | | | address. |
|
|||
|
| | | | |
|
|||
|
| ip6_rec | 1 | Variable | Specifies an |
|
|||
|
| | | | IPv6 address |
|
|||
|
| | | | (contained in |
|
|||
|
| | | | the first 16 |
|
|||
|
| | | | bytes), |
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 17]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
| | | | followed by |
|
|||
|
| | | | one or more |
|
|||
|
| | | | zero-terminate |
|
|||
|
| | | | d strings |
|
|||
|
| | | | containing the |
|
|||
|
| | | | DNS entries |
|
|||
|
| | | | for that |
|
|||
|
| | | | address. |
|
|||
|
+----------------+----------------+----------------+----------------+
|
|||
|
|
|||
|
Table 3
|
|||
|
|
|||
|
After the list or Name Resolution Records, optionally, a list of
|
|||
|
options (formatted according to the rules defined in Section 4) can
|
|||
|
be present.
|
|||
|
|
|||
|
A Name Resolution Block is normally placed at the beginning of the
|
|||
|
file, but no assumptions can be taken about its position. Name
|
|||
|
Resolution Blocks can be added in a second time by tools that process
|
|||
|
the file, like network analyzers.
|
|||
|
|
|||
|
In addiction to the options defined in Section 4, the following
|
|||
|
options are valid within this block:
|
|||
|
|
|||
|
+----------------+----------------+----------------+----------------+
|
|||
|
| Name | Code | Length | Description |
|
|||
|
+----------------+----------------+----------------+----------------+
|
|||
|
| ns_dnsname | 2 | Variable | An ascii |
|
|||
|
| | | | string |
|
|||
|
| | | | containing the |
|
|||
|
| | | | name of the |
|
|||
|
| | | | machine (DNS |
|
|||
|
| | | | server) used |
|
|||
|
| | | | to perform the |
|
|||
|
| | | | name |
|
|||
|
| | | | resolution. |
|
|||
|
+----------------+----------------+----------------+----------------+
|
|||
|
|
|||
|
|
|||
|
3.6 Interface Statistics Block (optional)
|
|||
|
|
|||
|
The Interface Statistics Block contains the capture statistics for a
|
|||
|
given interface and it is optional. The statistics are referred to
|
|||
|
the interface defined in the current Section identified by the
|
|||
|
Interface ID field.
|
|||
|
|
|||
|
The format of the Interface Statistics Block is shown in Figure 8.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 18]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
0 1 2 3
|
|||
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| IfRecv |
|
|||
|
| (high + low) |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| IfDrop |
|
|||
|
| (high + low) |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| FilterAccept |
|
|||
|
| (high + low) |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| OSDrop |
|
|||
|
| (high + low) |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| UsrDelivered |
|
|||
|
| (high + low) |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| Interface ID | Reserved |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
/ /
|
|||
|
/ Options (variable) /
|
|||
|
/ /
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
Figure 8: Interface Statistics Block format.
|
|||
|
|
|||
|
The fields have the following meaning:
|
|||
|
|
|||
|
o IfRecv: number of packets received from the interface during the
|
|||
|
capture. This number is reported as a 64 bits value, in which the
|
|||
|
most significat bits are located in the first four bytes of the
|
|||
|
field.
|
|||
|
|
|||
|
o IfDrop: number of packets dropped by the interface during the
|
|||
|
capture due to lack of resources.
|
|||
|
|
|||
|
o FilterAccept: number of packets accepeted by filter during current
|
|||
|
capture.
|
|||
|
|
|||
|
o OSDrop: number of packets dropped by the operating system during
|
|||
|
the capture.
|
|||
|
|
|||
|
o UsrDelivered: number of packets delivered to the user.
|
|||
|
UsrDelivered can be different from the value 'FilterAccept -
|
|||
|
OSDropped' because some packets could still lay in the OS buffers
|
|||
|
when the capture ended.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 19]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
o Interface ID: reference to an Interface Description Block.
|
|||
|
|
|||
|
o Reserved: Reserved to future use.
|
|||
|
|
|||
|
o Options: optionally, a list of options (formatted according to the
|
|||
|
rules defined in Section 4) can be present.
|
|||
|
|
|||
|
In addiction to the options defined in Section 4, the following
|
|||
|
options are valid within this block:
|
|||
|
|
|||
|
+----------------+----------------+----------------+----------------+
|
|||
|
| Name | Code | Length | Description |
|
|||
|
+----------------+----------------+----------------+----------------+
|
|||
|
| isb_starttime | 2 | 8 | Time in which |
|
|||
|
| | | | the capture |
|
|||
|
| | | | started; time |
|
|||
|
| | | | will be stored |
|
|||
|
| | | | in two blocks |
|
|||
|
| | | | of four bytes |
|
|||
|
| | | | each, |
|
|||
|
| | | | containing the |
|
|||
|
| | | | timestamp in |
|
|||
|
| | | | seconds and |
|
|||
|
| | | | nanoseconds. |
|
|||
|
| | | | |
|
|||
|
| isb_endtime | 3 | 8 | Time in which |
|
|||
|
| | | | the capture |
|
|||
|
| | | | started; time |
|
|||
|
| | | | will be stored |
|
|||
|
| | | | in two blocks |
|
|||
|
| | | | of four bytes |
|
|||
|
| | | | each, |
|
|||
|
| | | | containing the |
|
|||
|
| | | | timestamp in |
|
|||
|
| | | | seconds and |
|
|||
|
| | | | nanoseconds. |
|
|||
|
+----------------+----------------+----------------+----------------+
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 20]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
4. Options
|
|||
|
|
|||
|
Almost all blocks have the possibility to embed optional fields.
|
|||
|
Optional fields can be used to insert some information that may be
|
|||
|
useful when reading data, but that it is not really needed for packet
|
|||
|
processing. Therefore, each tool can be either read the content of
|
|||
|
the optional fields (if any), or skip them at once.
|
|||
|
|
|||
|
Skipping all the optional fields at once is straightforward because
|
|||
|
most of the blocks have a fixed length, therefore the field Block
|
|||
|
Length (present in the General Block Structure, see Section 2.1) can
|
|||
|
be used to skip everything till the next block.
|
|||
|
|
|||
|
Options are a list of Type - Length - Value fields, each one
|
|||
|
containing a single value:
|
|||
|
|
|||
|
o Option Type (2 bytes): it contains the code that specifies the
|
|||
|
type of the current TLV record. Option types whose Most
|
|||
|
Significant Bit is equal to one are reserved for local use;
|
|||
|
therefore, there is no guarantee that the code used is unique
|
|||
|
among all capture files (generated by other applications). In case
|
|||
|
of vendor-specific extensions that have to be identified uniquely,
|
|||
|
vendors must request an Option Code whose MSB is equal to zero.
|
|||
|
|
|||
|
o Option Length (2 bytes): it contains the length of the following
|
|||
|
'Option Value' field.
|
|||
|
|
|||
|
o Option Value (variable length): it contains the value of the given
|
|||
|
option. The length of this field as been specified by the Option
|
|||
|
Length field.
|
|||
|
|
|||
|
Options may be repeated several times (e.g. an interface that has
|
|||
|
several IP addresses associated to it). The option list is terminated
|
|||
|
by a special code which is the 'End of Option'.
|
|||
|
|
|||
|
The format of the optional fields is shown in Figure 9.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 21]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
0 1 2 3
|
|||
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| Option Code | Option Length |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| Option Value |
|
|||
|
| /* variable length, byte-aligned */ |
|
|||
|
| + + + + + + + + + + + + + + + + + + + + + + + + +
|
|||
|
| / / / |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
/ /
|
|||
|
/ . . . other options . . . /
|
|||
|
/ /
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| Option Code == opt_endofopt | Option Length == 0 |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
Figure 9: Options format.
|
|||
|
|
|||
|
The following codes can always be present in any optional field:
|
|||
|
|
|||
|
+----------------+----------------+----------------+----------------+
|
|||
|
| Name | Code | Length | Description |
|
|||
|
+----------------+----------------+----------------+----------------+
|
|||
|
| opt_endofopt | 0 | 0 | End of |
|
|||
|
| | | | options: it is |
|
|||
|
| | | | used to |
|
|||
|
| | | | delimit the |
|
|||
|
| | | | end of the |
|
|||
|
| | | | optional |
|
|||
|
| | | | fields. This |
|
|||
|
| | | | block cannot |
|
|||
|
| | | | be repeated |
|
|||
|
| | | | within a given |
|
|||
|
| | | | list of |
|
|||
|
| | | | options. |
|
|||
|
| | | | |
|
|||
|
| opt_comment | 1 | variable | Comment: it is |
|
|||
|
| | | | an ascii |
|
|||
|
| | | | string |
|
|||
|
| | | | containing a |
|
|||
|
| | | | comment that |
|
|||
|
| | | | is associated |
|
|||
|
| | | | to the current |
|
|||
|
| | | | block. |
|
|||
|
+----------------+----------------+----------------+----------------+
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 22]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
5. Experimental Blocks (deserved to a further investigation)
|
|||
|
|
|||
|
5.1 Other Packet Blocks (experimental)
|
|||
|
|
|||
|
Can some other packet blocks (besides the two described in the
|
|||
|
previous paragraphs) be useful?
|
|||
|
|
|||
|
5.2 Compression Block (experimental)
|
|||
|
|
|||
|
The Compression Block is optional. A file can contain an arbitrary
|
|||
|
number of these blocks. A Compression Block, as the name says, is
|
|||
|
used to store compressed data. Its format is shown in Figure 10.
|
|||
|
|
|||
|
0 1 2 3
|
|||
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| Compr. Type | |
|
|||
|
+-+-+-+-+-+-+-+-+ |
|
|||
|
| |
|
|||
|
| Compressed Data |
|
|||
|
| |
|
|||
|
| /* variable length, byte-aligned */ |
|
|||
|
| |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
Figure 10: Compression Block format.
|
|||
|
|
|||
|
The fields have the following meaning:
|
|||
|
|
|||
|
o Compression Type: specifies the compression algorithm. Possible
|
|||
|
values for this field are 0 (uncompressed), 1 (Lempel Ziv), 2
|
|||
|
(Gzip), other?? Probably some kind of dumb and fast compression
|
|||
|
algorithm could be effective with some types of traffic (for
|
|||
|
example web), but which?
|
|||
|
|
|||
|
o Compressed Data: data of this block. Once decompressed, it is made
|
|||
|
of other blocks.
|
|||
|
|
|||
|
|
|||
|
5.3 Encryption Block (experimental)
|
|||
|
|
|||
|
The Encryption Block is optional. A file can contain an arbitrary
|
|||
|
number of these blocks. An Encryption Block is used to sotre
|
|||
|
encrypted data. Its format is shown in Figure 11.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 23]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
0 1 2 3
|
|||
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| Encr. Type | |
|
|||
|
+-+-+-+-+-+-+-+-+ |
|
|||
|
| |
|
|||
|
| Compressed Data |
|
|||
|
| |
|
|||
|
| /* variable length, byte-aligned */ |
|
|||
|
| |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
Figure 11: Encryption Block format.
|
|||
|
|
|||
|
The fields have the following meaning:
|
|||
|
|
|||
|
o Compression Type: specifies the encryption algorithm. Possible
|
|||
|
values for this field are ??? NOTE: this block should probably
|
|||
|
contain other fields, depending on the encryption algorithm. To be
|
|||
|
define precisely.
|
|||
|
|
|||
|
o Encrypted Data: data of this block. Once decripted, it consists of
|
|||
|
other blocks.
|
|||
|
|
|||
|
|
|||
|
5.4 Fixed Length Block (experimental)
|
|||
|
|
|||
|
The Fixed Length Block is optional. A file can contain an arbitrary
|
|||
|
number of these blocks. A Fixed Length Block can be used to optimize
|
|||
|
the access to the file. Its format is shown in Figure 12. A Fixed
|
|||
|
Length Block stores records with constant size. It contains a set of
|
|||
|
Blocks (normally Packet Blocks or Simple Packet Blocks), of wihich it
|
|||
|
specifies the size. Knowing this size a priori helps to scan the file
|
|||
|
and to load some portions of it without truncating a block, and is
|
|||
|
particularly useful with cell-based networks like ATM.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 24]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
0 1 2 3
|
|||
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| Cell Size | |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|
|||
|
| |
|
|||
|
| Fixed Size Data |
|
|||
|
| |
|
|||
|
| /* variable length, byte-aligned */ |
|
|||
|
| |
|
|||
|
| |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
Figure 12: Fixed Length Block format.
|
|||
|
|
|||
|
The fields have the following meaning:
|
|||
|
|
|||
|
o Cell size: the size of the blocks contained in the data field.
|
|||
|
|
|||
|
o Fixed Size Data: data of this block.
|
|||
|
|
|||
|
|
|||
|
5.5 Directory Block (experimental)
|
|||
|
|
|||
|
If present, this block contains the following information:
|
|||
|
|
|||
|
o number of indexed packets (N)
|
|||
|
|
|||
|
o table with position and length of any indexed packet (N entries)
|
|||
|
|
|||
|
A directory block must be followed by at least N packets, otherwise
|
|||
|
it must be considered invalid. It can be used to efficiently load
|
|||
|
portions of the file to memory and to support operations on memory
|
|||
|
mapped files. This block can be added by tools like network analyzers
|
|||
|
as a consequence of file processing.
|
|||
|
|
|||
|
5.6 Traffic Statistics and Monitoring Blocks (experimental)
|
|||
|
|
|||
|
One or more blocks could be defined to contain network statistics or
|
|||
|
traffic monitoring information. They could be use to store data
|
|||
|
collected from RMON or Netflow probes, or from other network
|
|||
|
monitoring tools.
|
|||
|
|
|||
|
5.7 Event/Security Block (experimental)
|
|||
|
|
|||
|
This block could be used to store events. Events could contain
|
|||
|
generic information (for example network load over 50%, server
|
|||
|
down...) or security alerts. An event could be:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 25]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
o skipped, if the application doesn't know how to do with it
|
|||
|
|
|||
|
o processed independently by the packets. In other words, the
|
|||
|
applications skips the packets and processes only the alerts
|
|||
|
|
|||
|
o processed in relation to packets: for example, a security tool
|
|||
|
could load only the packets of the file that are near a security
|
|||
|
alert; a monitorg tool could skip the packets captured while the
|
|||
|
server was down.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 26]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
6. Conclusions
|
|||
|
|
|||
|
The file format proposed in this document should be very versatile
|
|||
|
and satisfy a wide range of applications. In the simplest case, it
|
|||
|
can contain a raw dump of the network data, made of a series of
|
|||
|
Simple Packet Blocks. In the most complex case, it can be used as a
|
|||
|
repository for heterogeneous information. In every case, the file
|
|||
|
remains easy to parse and an application can always skip the data it
|
|||
|
is not interested in; at the same time, different applications can
|
|||
|
share the file, and each of them can benfit of the information
|
|||
|
produced by the others. Two or more files can be concatenated
|
|||
|
obtaining another valid file.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 27]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
7. Most important open issues
|
|||
|
|
|||
|
o Data, in the file, must be byte or word aligned? Currently, the
|
|||
|
structure of this document is not consistent with respect to this
|
|||
|
point.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 28]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
Intellectual Property Statement
|
|||
|
|
|||
|
The IETF takes no position regarding the validity or scope of any
|
|||
|
intellectual property or other rights that might be claimed to
|
|||
|
pertain to the implementation or use of the technology described in
|
|||
|
this document or the extent to which any license under such rights
|
|||
|
might or might not be available; neither does it represent that it
|
|||
|
has made any effort to identify any such rights. Information on the
|
|||
|
IETF's procedures with respect to rights in standards-track and
|
|||
|
standards-related documentation can be found in BCP-11. Copies of
|
|||
|
claims of rights made available for publication and any assurances of
|
|||
|
licenses to be made available, or the result of an attempt made to
|
|||
|
obtain a general license or permission for the use of such
|
|||
|
proprietary rights by implementors or users of this specification can
|
|||
|
be obtained from the IETF Secretariat.
|
|||
|
|
|||
|
The IETF invites any interested party to bring to its attention any
|
|||
|
copyrights, patents or patent applications, or other proprietary
|
|||
|
rights which may cover technology that may be required to practice
|
|||
|
this standard. Please address the information to the IETF Executive
|
|||
|
Director.
|
|||
|
|
|||
|
|
|||
|
Full Copyright Statement
|
|||
|
|
|||
|
Copyright (C) The Internet Society (2004). All Rights Reserved.
|
|||
|
|
|||
|
This document and translations of it may be copied and furnished to
|
|||
|
others, and derivative works that comment on or otherwise explain it
|
|||
|
or assist in its implementation may be prepared, copied, published
|
|||
|
and distributed, in whole or in part, without restriction of any
|
|||
|
kind, provided that the above copyright notice and this paragraph are
|
|||
|
included on all such copies and derivative works. However, this
|
|||
|
document itself may not be modified in any way, such as by removing
|
|||
|
the copyright notice or references to the Internet Society or other
|
|||
|
Internet organizations, except as needed for the purpose of
|
|||
|
developing Internet standards in which case the procedures for
|
|||
|
copyrights defined in the Internet Standards process must be
|
|||
|
followed, or as required to translate it into languages other than
|
|||
|
English.
|
|||
|
|
|||
|
The limited permissions granted above are perpetual and will not be
|
|||
|
revoked by the Internet Society or its successors or assignees.
|
|||
|
|
|||
|
This document and the information contained herein is provided on an
|
|||
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|||
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|||
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 29]
|
|||
|
|
|||
|
Internet-Draft PCAP New Generation Dump File Format March 2004
|
|||
|
|
|||
|
|
|||
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|||
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|||
|
|
|||
|
Acknowledgment
|
|||
|
|
|||
|
Funding for the RFC Editor function is currently provided by the
|
|||
|
Internet Society.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Degioanni & Risso Expires August 30, 2004 [Page 30]
|
|||
|
|