pcap.txt

libcap是常用的linux抓包程序,属于open source项目.

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