<div dir="ltr"><div><div><span style="font-family:monospace,monospace">I'd like to propose the following new block structure for PcapNG:<br><br><artwork><br>    0                   1                   2                   3 <br>    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<br>   +---------------------------------------------------------------+<br>   |                 Block Type = 0xD5555555                       |<br>   +---------------------------------------------------------------+<br>   |                      Block Total Length                       |<br>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>   |   Flow Type   |               IPFIX options                   | <br>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| <br>   /                                                               /<br>   /     Src IP 4 bytes for IPv4; 16 bytes (4 words) for IPv6      /<br>   /                                                               /<br>   /                                                               /<br>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>   /                                                               /<br>   /     Dst IP 4 bytes for IPv4; 16 bytes (4 words) for IPv6      /<br>   /                                                               /<br>   /                                                               /<br>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>   |     Src Port or ICMP Type     |      Dst Port or ICMP Code    |<br>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>   |                   Flow Start Time (high order)                |<br>   +---------------------------------------------------------------+<br>   |                   Flow Start Time (low order)                 |<br>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>   |                    Flow Stop Time (high order)                |<br>   +---------------------------------------------------------------+<br>   |                    Flow Stop Time (low order)                 |<br>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>   |                                                               |<br>   |                                                               |<br>   |                     Flow ID = 20 bytes                        |<br>   |                                                               |<br>   |                                                               |<br>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>   /                                                               /<br>   /                   Other Options (variable)                    /<br>   /                                                               /<br>   +-------------------------------+-------------------------------+<br>   |  total_pkts_option = 0x0002   |   total_pkts_length = 0x0004  |<br>   +-------------------------------+-------------------------------+<br>   |                Number of Packets seen in this flow            |<br>   +-------------------------------+-------------------------------+<br>   |  total_bytes_option = 0x0003  |   total_bytes_length = 0x0004 |<br>   +-------------------------------+-------------------------------+<br>   |                Number of Bytes seen in this flow              |<br>   +-------------------------------+-------------------------------+<br>   |  end_of_options = 0x0000      |    options_length = 0x0000    |<br>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>   |                       Block Total Length                      |<br>   +---------------------------------------------------------------+<br>   <br></artwork><br><br>Ideally, libpcap can be built to support IPFIX flow information collection, and<br>the PcapNG file standard will be extended to fully support IPFIX-based blocks in<br>the file. IPFIX templates, along with Cisco NetFlow v9, are widely available <br>from a number of devices and there are tools designed specifically to consume <br>this data. The full IPFIX model includes sensors, collectors, and many <br>extensions and specifications. IPFIX data is intended to be passed as the <br>payload of a network packet from a sensor to a collector. However, it could also<br>easily be stored as block data in the binary PcapNG file format.<br><br>At this early stage, a rudimentary Flow Block structure is proposed, <br>specifically to support management of Encrypted Blocks. A Flow Block is designed<br>to provide a very simple means to track the initial characteristics of a network<br>flow and record these metadata and addressing elements along with a flow <br>identifier. At least ne of these blocks will be recorded for each newly <br>identified flow. This block type will contain the various elements of the packet<br>used to uniquely identify the flow (e.g. the source and destination IP <br>addresses) and will provide a searchable way to identify the associated <br>encrypted packets in the recording. The Flow Blocks will provide the appropriate<br>means of searching for network characteristics (e.g. by IP address) and will <br>provide the flow ID or Key Serial Number, which can then be searched from all <br>Encrypted Blocks or EPB FlowID Option in the file as an index.<br><br>Block Type: The block type proposed for the Flow Block is 0xD5555555 or as it <br>appears in binary: 0b11010101010101010101010101010101. This is a number chosen <br>that is above 0x80000000 indicating that it is for experimental use. This number<br>is distinctively non-random-looking when examining the binary file, but is an <br>otherwise arbitrary selection.<br><br>Flow Type and IPFIX Options: Flow type identifies what type of flow this block <br>contains. IPFIX Options is a reserved field for future development, intended to<br>allow the full support of IPFIX formatted blocks. This field could contain <br>IPFIX-compatible template options that determine what fields are available in <br>this block, or these fields may all be implemented as block options. The system <br>design presented here relies only on a simple method of determining flow type: <br>summing the protocol numbers (e.g IP version + embedded layer-4 protocol).<br><br>This is an over-simplified approach to determining a flow type. In particular,<br>there is a possibility of flow-type collisions. But it serves my current <br>purposes:<br><br>Flow Types (ip version + protocol):  <br>   ARP = 1<br>   IPv4 = 4<br>   IPv6 = 6<br>   IPv4 + ICMP = 5<br>   IPv6 + ICMPv6 = 7<br>   IPv4 + TCP = 4 + 6 = 10<br>   IPv6 + TCP = 6 + 6 = 12<br>   IPv4 + UDP = 4 + 17 = 21<br>   IPv6 + UDP = 6 + 17 = 23<br>   IPv4 + SCTP = 4 + 132 = 136<br>   IPv6 + SCTP = 6 + 132 = 138<br><br>Flow Options: <br>   code 2 = "Total Packets"<br>   code 3 = "Total Bytes"<br><br><br>Flow ID: The Flow Identifier is a unique number determined in the same way the <br>Key Serial Number is chosen in DUKPT. There is a portion of this identifier that<br>uniquely identifies the monitor station, the organization that is doing the <br>monitoring and the device being used. For example, this could include an <br>organizational identifier concatenated to the Ethernet MAC address of the <br>sniffing interface. The least-significant bits of the identifier should be a <br>unique counter that will be incremented each time a new flow is identified. As <br>mentioned, the DUKPT standard for credit card transaction hardware has a scheme <br>with the most significant 59 bits associated with the specific terminal, and the<br>least significant 21 bits associated with the transaction counter.<br><br>While the flow ID could be an arbitrary length, it is first helpful to define it<br>as a multiple of 32 bits. This allows it to be used in multiple ways within the <br>PcapNG file. In the method presented here, it appears as a field in the body of <br>two different block types and as an option in a third. Secondly, it may be a <br>requirement that the flow IDs are globally unique. There should be enough bits <br>to uniquely identify a recording session by device within a given organization <br>and perhaps across all organizations. There should likewise be enough bits to <br>uniquely count each flow that is observed during that recording session or by <br>that device. In the proposed method, the Flow ID is 20 bytes, and the first two<br>are always 0x01A6 or 0x01A7 to provide the appropriate options for this system. <br>The last 8 bytes are a unique counter, and the middle 10 bytes should contain <br>the 6-byte MAC address of the sniffer, and a 4-byte unique organizational <br>identifier. While 20 bytes may seem like significant additional overhead per <br>packet, this is still more efficient than keeping track of all the addressing <br>information used to uniquely identify a flow. The first 12 bytes will remain <br>static. A TCP flow over IPv6 would have 37 or more bytes to track it uniquely: <br>16 for each IP address and 2 for each port number, plus 1 byte to distinguish if<br>it is UDP, TCP, or SCTP ports or ICMP type and code that was tracked. 8 bytes <br>for a counter is the same space required to keep track of only 2 IPv4 addresses.<br>And as a counter, it is sufficiently large enough to account for the same number<br>of flows as if every unique possible IPv4 address had a conversation with every <br>other unique possible IPv4 address, including itself. This should therefore be<br>considered an appropriate length for a flow identifier.<br><br>Flow Start and End Times: One of the most important metadata fields to capture <br>when performing flow analysis is the time at which a flow occurred. The start <br>time can easily be captured. As a packet is identified as belonging to a unique <br>new flow, the time of its arrival marks the start of the flow. Start time is set<br>once when the flow is created. The end time is always updated with every packet <br>added to the flow tally, initially set the same time as the start time. This <br>serves as a “last seen” timestamp which will be accurate if a flow is stopped <br>for other reasons (e.g. timeout, memory release).<br><br>Flow Block Options: There are a number of different ways to track flows and to <br>help flows actively or passively time out to completion. When a flow is <br>initially identified, it should immediately be written to the PcapNG file. Any <br>block that follows it will be associated with the flow ID and should have the <br>proper ID stored in the file ahead of these packets. However, as the flow stats <br>are accumulating and these elements are being tracked in memory, either when the<br>flow ends, times out, or the recording session ends, this accumulated data <br>should also be written to the PcapNG file. In order to take advantage of the <br>extensible design of PcapNG, these statistics are implemented as options to the <br>block, so that both the initial and final flow blocks can be defined by the same <br>block type. Initial and final flow blocks are distinguished by the presence of <br>options for various flow statistics or IPFIX fields.<br><br>Two metadata elements that are relatively important and relatively easy to track<br>are packet count and byte count. The packet count can exist as a variable of the<br>flow state that is incremented for each new packet identified with that flow. <br>The byte count can be a variable increased by the size of each packet as it is <br>captured. Combined with time, an analyst can later calculate the rates of <br>packets per second, bytes per second, and average bytes per packet, each of <br>which portray important characteristics of that particular network flow.<br><br></span></div><span style="font-family:monospace,monospace">Regards,<br></span></div><span style="font-family:monospace,monospace">Michael<br><br></span></div>