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