Re: [IPFIX] TCP flags?

hi, Paul, all,

Good questions all, attempt at answers inline:

On 19 Jul 2013, at 14:17 , Paul Aitken <[email protected]> wrote:

> Dear IPFIX experts,
> 
> IANA's IPFIX registry defines field #6, tcpControlBits, as an unsigned8 flags following RFC793:
> 0     1     2     3     4     5     6     7
> +-----+-----+-----+-----+-----+-----+-----+-----+
> |  Reserved | URG | ACK | PSH | RST | SYN | FIN |
> +-----+-----+-----+-----+-----+-----+-----+-----+
> 
> 
> This is missing the ECE and CWR bits from (Std) RFC 3168, and ECN Nonce Sum (NS) bit from (Exp) RFC 3540.
> 
> Per RFC3540, the TCP flags field is like so:
>      0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
>    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
>    |               |           | N | C | E | U | A | P | R | S | F |
>    | Header Length | Reserved  | S | W | C | R | C | S | S | Y | I |
>    |               |           |   | R | E | G | K | H | T | N | N |
>    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
> 
> 
> - where bits 7, 8, and 9 aren't defined in IPFIX.
> 
> 
> Q1: can we updated tcpControlBits to include the ECE and CWR bits from RFC 3168?

We certainly should. I was actually surprised on rereading the registry that ECE and CWR *weren't in the IE; QoF and YAF both export ECE and CWR in violation of the definition. 

> Q2: how should the ECN Nonce Sum be reported?

My suggestion would be to define this field as an unsigned16:

    MSb                                                         LSb
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |                           | N | C | E | U | A | P | R | S | F |
   |         Reserved          | S | W | C | R | C | S | S | Y | I |
   |                           |   | R | E | G | K | H | T | N | N |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

with a specific note that when the IE is encoded as an unsigned8 using reduced-length encoding, it has the following layout:

    MSb                         LSb
   +---+---+---+---+---+---+---+---+
   | C | E | U | A | P | R | S | F |
   | W | C | R | C | S | S | Y | I |
   | R | E | G | K | H | T | N | N |
   +---+---+---+---+---+---+---+---+

and a further specific note that Collecting Processes should not assume that CWR and ECE were not set simply because they're exported as 0, as previous revisions of the Information Element did not include them.

Yes, it's kludgy, but it has the advantage of describing the reality of the status quo.

As a further note, the use of *bit* numbers has already bitten us in the past in this registry; I'd strongly suggest we either use "most significant bit" and "least significant bit" as bit ordering terminology in these diagrams, or dispose with normative bitfield diagrams completely in favor of value tables, i.e.:

0x0100 = NS (ECN Nonce Sum, see RFC xxxx)
0x0080 = CWR (Congestion Window Reduced, see RFC 3168)
0x0040 = ECE (ECN Echo, see RFC 3168)
0x0020 = URG (Urgent pointer valid)
0x0010 = ACK (Acknowledgment number valid)
0x0008 = PSH (Push)
0x0004 = RST (Connection reset)
0x0002 = SYN (Connection synchronize)
0x0001 = FIN (Connection shutdown)

Cheers,

Brian
_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix