Re: RFC: DLT for "application TCP stream capture"

["Paul \"LeoNerd\" Evans" <leonerd () leonerd org uk>]

On Wed, 14 Jan 2015 14:21:18 -0800
Guy Harris <guy () alum mit edu> wrote:

> OK, so the transport-layer metadata values we should include are:
>
>       UDP: source and destination port numbers
>
>       TCP: source and destination port numbers, EOF indication
> (think of it as FIN), urgent pointer?
>
>       SCTP: source and destination port numbers, stream ID, PPID,
> ordered/unordered flag, TSN/SSN
>
> Anything else?
>
> What about TCP - or IP - options?  Some of those may be exposed to
> the application.

I wonder if this suggests a sub-header approach?

Also, I seem to remember that the pcap format already gives every
frame a length, so we don't need to store the "payload length" in the
header here - it's implied from the end of the header until the end of
the frame.

So I wonder now, if we should have:

Main frame header:

  1 byte       | Flags and IP version:
     bit7 [ VVVV...W ] bit0
            VVVV     = IP version
                   W = write/!read

  1 byte       | IP protocol number (6=TCP, 17=UDP, etc...)
  {addr bytes} | Source address
  {addr bytes} | Destination address
    \-- length determined by protocol version; IPv4=4, IPv6=16

  1 byte       | Number of extra bytes of frame header
  1 byte       | Length of the per-protocol sub-header

The frame header extension length allows us to put more IP-specific
extensions in there at a later date. The protocol sub-header length
allows similar; that later versions of the sub-header can provide
extra fields we forgot about now.

Older consuming code that is unaware of those fields can still parse
files containing the information, they'll just ignore the fields. Older
generating code that is unaware of those fields will not omit them, and
new parsers will just have to accept that information is not available.

Protocol-specific sub-header:

 UDP:
  2 bytes      | Source port
  2 bytes      | Destination port

 TCP:
  2 bytes      | Source port
  2 bytes      | Destination port
  1 byte       | Flags
     bit7 [ .......E ] bit0
                   E = EOF

 SCTP:
  2 bytes      | Source port
  2 bytes      | Destination port
  ...          | Stream ID
               | PPID
               | Flags (ordered)
               | TSN
               | SSN
 ((someone who knows SCTP will have to define this one ;) ))

After the protocol-specific sub-header, all the remaining bytes of the
frame are the protocol data payload.

-- 
Paul "LeoNerd" Evans

leonerd () leonerd org uk
http://www.leonerd.org.uk/  |  https://metacpan.org/author/PEVANS
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers