Re: [IPFIX] TCP flags?

Brian,

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

Admittedly, FNF also does the same because we're simply reporting the 
raw bits from the packets as we see them.


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

I'm happy with that, except for enlarging the size from u8 to u16. Is 
that acceptable to collectors?

Otherwise, the changes do seem to be in line with ie-doctors.


> As a further note, the use of *bit* numbers has already bitten us in the past in this registry;

True. Note that I copied the RFC3540 bit ordering, and it corresponds to 
the RFC793 bit ordering too.

However, the disadvantage is that with the u8 form bit 7 is "FIN", 
whereas with the u16 form bit 7 is NS and FIN becomes bit 15... so 
that's confusing.

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

That works.

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