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

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

On Tue, 13 Jan 2015 19:32:46 -0800
Guy Harris <guy () alum mit edu> wrote:

> LINKTYPE_IP_PAYLOAD, or something such as that, with a link-layer
> (pseudo-)header containing:

I'm happy with that as a name.

>       an indication of whether the network-layer addresses are IPv4
> or IPv6;
>
>       source address;
>
>       destination address;
>
>       IP protocol number (6 for TCP, 17 for UDP, etc.);
>
>       source port number;
>
>       destination port number.

I'd prefer to also have a flag to say if this segment was received or
transmitted - I've never liked inferring that information from the
identity of the source/dest. addresses. It then makes it impossible to
sensibly analyse the file if you don't know the underlying networking
configuration, as may well be the case for .pcap(ng) files copied from
one machine to another.

> The description would explicitly note that, at least for TCP, there
> is *NO* guarantee that packets correspond to actual TCP segments; for
> UDP, packet boundaries *are* exposed to the application, so maybe we
> make that TCP-only.

That seems reasonable; that's the only guarantee we can really give.
Also, for "transmitted" data, we don't even give the guarantee that
this data ever reached the network. All the userland knows is it told
that data to the kernel. It could still be sitting in a buffer.

Also, how to signify the eventual termination of a TCP stream? Does a
zero-byte segment seem sensible? Or should perhaps there be an explicit
"end" flag?

> Do you need to provide the timing information in a form other than
> the time stamp in a pcap record or a pcap-ng packet block?

I don't think any other timestamping is needed (or in fact accessible
to userland most of the time anyway). I'm sure the pcap(ng) timestamps
alone will be sufficient.

I think then, the header fields need to be:

  1 byte       | IP version: 4, 6

  1 byte       | IP protocol number: 6=TCP, 17=UDP

  1 byte       | Flags: 0x01 = write/!read

  2 bytes      | Source port

  2 bytes      | Destination port

  2 bytes      | Body length - 0=EOF, up to 65535 bytes

  {addr} bytes | Source address      \
                                      + IP version determines the length
  {addr} bytes | Destination address /

  {len} bytes  | Segment payload

I wonder though, whether the flags could be combined with the IP
version field, given as the version in the underlying (real) IP packet
anyway is only a 4-bit field.

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

Does it seem sensible to merge those to save a byte of output? (and
also ensure nice alignment of the header to 32bit boundaries).

It does momentarily seem wasteful to repeat the source/destination
information in every single packet (especially in the case of IPv6 with
its 256bits of addressing information). Though I don't know if that
outweighs the statefulness and added complexity of representing "flow
setup" operations and "more bytes of data sent/received on this flow"
as extra frame types.

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