Subject: [IPFIX] tcpControlBits, ECN, and IE-DOCTORS

From: Brian Trammell <[email-masked]>
Date: Tue, 21 Aug 2012 18:49:58 +0200

Greetings, all,

I note that the definition of IE 6, tcpControlBits, uses the RFC793 definition of the TCP Flags byte, ignoring the changes to the definition of this field made by RFC3168 (ECN). The "must be zero" language here has two unfortunate consequences: (1) it obliges MP implementors to mask the field by 0x3F to zero out bytes that may be set in headers due to ECN negotiation and (2) it makes it impossible to use compliant implementations to measure ECN negotiation.

I have verified that the at least one shipping implementation of NetFlow V9 follows the IANA definition; it does indeed mask 0x3F, destroying ECN negotiation information. Yes, I know "nobody uses ECN" but recent active measurement efforts have shown increased default support for ECN negotiation; see e.g. Honda et al. in IMC 2011. 

I'd considered the right way to address this in view of the proposed IE-DOCTORS process; a change adding ECE and CWR to tcpControlBits would indeed appear to be eligible for an updated IE on first pass per section 5.2 (it harmonizes with an updated external reference (3168 updates 793, though the update happened before the definition of IPFIX); it also defines a previously reserved bit in an IE with flag semantics). However, tcpControlBits is in the magic lower 128 V9-compatible space; new IEs in this space require V9 expert approval, but changes (as yet) do not. Should this be corrected? 

Cheers,

Brian

---

From: Paul Aitken <[email-masked]>
Date: Wed, 22 Aug 2012 12:07:09 +0100

Brian,

Any IPFIX changes in the < 128 block should also be reflected in NFv9. 
If the change can't be in NFv9 for some reason, then a new IPFIX IE 
should be allocated.

If this isn't corrected then presumably IANA and the IPFIX expert 
reviewers would assume sole authority for changes in the < 128 block, 
which could have the undesirable effect of making IEs in this section 
incompatible with NFv9.

So short answer: yes, this should be corrected.

As a NFv9 expert, I'd be happy to see the ECE and CWR bits added to the 
existing IANA definition - although this means that CP can't know for 
sure what the 0-valued bits mean: they could be !ECE / !CWR, or they 
could be old implementations which mask out those bits. Hopefully the 
latter will disappear over time, so we can come to trust the bits.

P.

On 21/08/12 17:49, Brian Trammell wrote:
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Brian Trammell <[email-masked]>
Date: Wed, 22 Aug 2012 13:24:39 +0200

Hi, Paul,

On Aug 22, 2012, at 1:07 PM, Paul Aitken wrote:

> Brian,
> 
> Any IPFIX changes in the < 128 block should also be reflected in NFv9. If the change can't be in NFv9 for some reason, then a new IPFIX IE should be allocated.
> 
> If this isn't corrected then presumably IANA and the IPFIX expert reviewers would assume sole authority for changes in the < 128 block, which could have the undesirable effect of making IEs in this section incompatible with NFv9.
> 

Will do in IE-DOCTORS -03 working copy...

> As a NFv9 expert, I'd be happy to see the ECE and CWR bits added to the existing IANA definition - although this means that CP can't know for sure what the 0-valued bits mean: they could be !ECE / !CWR, or they could be old implementations which mask out those bits. Hopefully the latter will disappear over time, so we can come to trust the bits.

An update of the description of this IE would need to mention this ambiguity, of course.

It wouldn't be the only IE requiring some post-collection interpretation: ipClassOfService for instance also requires some knowledge of what's happening on the measured network, as it could really be (ipDiffServCodepoint << 2) | ecn (which would have unfortunate consequences on older ECN-naive MPs treating ipClassOfService as a key field).

Cheers,

Brian