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