Subject: [IPFIX] Fwd: New Version Notification for draft-trammell-ipfix-tcpcontrolbits-revision-00.txt

From: Brian Trammell <[email-masked]>
Date: Fri, 6 Sep 2013 12:36:04 +0200

Greetings, all,

I've submitted a new draft, essentially an Internet-Draft version of the revision of the tcpControlBits Information Element discussed on the IPFIX list and approved by the IE-DOCTORS. _Why_ this needs to be published as an RFC is explained in the Introduction section of the draft:

   The revised definition of the Information Element in Section 2 was
   developed and approved through the IE-DOCTORS process
   [I-D.ietf-ipfix-ie-doctors] in August 2013.  Section 5.1 of
   [I-D.ietf-ipfix-ie-doctors] states "This process should not in any
   way be construed as allowing the IE-DOCTORS to overrule IETF
   consensus.  Specifically, Information Elements in the IANA IE
   registry which were added with IETF consensus require IETF consensus
   for revision or deprecation".  Since the tcpControlBits Information
   Element was defined in [RFC5102], an IETF Proposed Standard, any
   revision of this Information Element definition requires IETF
   Consensus.  The publication of this document fulfills that
   requirement.

If you have any comments, please give them quickly; my intention is to seek publication as quickly as possible, as the document merely formalizes for process reasons a decision already made within the WG and approved by the IE-DOCTORS.

Many thanks, best regards,

Brian

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-trammell-ipfix-tcpcontrolbits-revision-00.txt
> Date: September 6, 2013 12:31:53 PM GMT+02:00
> To: Brian Trammell <[email-masked]>, Paul Aitken <[email-masked]>
> 
> 
> A new version of I-D, draft-trammell-ipfix-tcpcontrolbits-revision-00.txt
> has been successfully submitted by Brian Trammell and posted to the
> IETF repository.
> 
> Filename:	 draft-trammell-ipfix-tcpcontrolbits-revision
> Revision:	 00
> Title:		 Revision of the tcpControlBits IPFIX Information Element
> Creation date:	 2013-09-06
> Group:		 Individual Submission
> Number of pages: 5
> URL:             http://www.ietf.org/internet-drafts/draft-trammell-ipfix-tcpcontrolbits-revision-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-trammell-ipfix-tcpcontrolbits-revision
> Htmlized:        http://tools.ietf.org/html/draft-trammell-ipfix-tcpcontrolbits-revision-00
> 
> 
> Abstract:
>   This document revises the tcpControlBits IPFIX Information Element
>   defined in [RFC5102] to reflect changes to the TCP Flags header field
>   since [RFC0793].
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

---

From: Lothar Braun <[email-masked]>
Date: Tue, 10 Sep 2013 10:32:45 +0200

Hi,

I have some clarification questions/comments inline (I'm commenting on version 02)

> 
> 
> IPFIX Working Group                                          B. Trammell
> Internet-Draft                                                ETH Zurich
> Intended status: Informational                                 P. Aitken
> Expires: March 13, 2014                               Cisco Systems, Inc
>                                                       September 09, 2013
> 
> 
>         Revision of the tcpControlBits IPFIX Information Element
>           draft-trammell-ipfix-tcpcontrolbits-revision-02.txt
> 
> Abstract
> 
> Status of This Memo
>    This Internet-Draft is submitted in full conformance with the
>    provisions of BCP 78 and BCP 79.
> 
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF).  Note that other groups may also distribute
>    working documents as Internet-Drafts.  The list of current Internet-
>    Drafts is at http://datatracker.ietf.org/drafts/current/.
> 
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
> 
>    This Internet-Draft will expire on March 13, 2014.
> 
> Copyright Notice
> 
>    Copyright (c) 2013 IETF Trust and the persons identified as the
>    document authors.  All rights reserved.
> 
>    This document is subject to BCP 78 and the IETF Trust's Legal
>    Provisions Relating to IETF Documents
>    (http://trustee.ietf.org/license-info) in effect on the date of
>    publication of this document.  Please review these documents
>    carefully, as they describe your rights and restrictions with respect
>    to this document.  Code Components extracted from this document must
>    include Simplified BSD License text as described in Section 4.e of
>    the Trust Legal Provisions and are provided without warranty as
>    described in the Simplified BSD License.
> 
> 
> 
> 
> Trammell & Aitken        Expires March 13, 2014                 [Page 1]
> Internet-Draft            IPFIX tcpControlBits            September 2013
> 
> 
> 1.  Introduction
> 
>    Octets 12 and 13 of the TCP header encode the data offset (header
>    length) in four bits, as well as 12 bits of flags.  The least
>    significant 6 bits of these were defined in [RFC0793] as URG, ACK,
>    PSH, RST, SYN, and FIN for TCP control.  Subsequently, [RFC3168]
>    defined the CWR and ECE flags for Explicit Congestion Notification
>    (ECN) negotiation and signaling; [RFC3540] additionally defined the
>    NS flag for the ECN Nonce Sum.
> 
>    As defined in the IANA IPFIX Information Element Registry
>    [IANA-IPFIX], taken from [RFC5102], the tcpControlBits Information
>    Element for IPFIX [I-D.ietf-ipfix-protocol-rfc5101bis] only covers
>    the original six bits from [RFC0793].  To allow IPFIX to be used to
>    measure the use of ECN, and to bring the IPFIX Information Element
>    definition in line with the current definition of the TCP Flags
>    header field, it is necessary to revise this definition.
> 
>    The following section defines the revised tcpControlBits Information
>    Element as in Section 9.1 of [I-D.ietf-ipfix-ie-doctors].
> 
> 2.  The tcpControlBits Information Element
> 
>    ElementId:   6
>    Data Type:   unsigned16
>    Data Type Semantics:   flags
>    Description:   TCP control bits observed for the packets of this
>       Flow.  This information is encoded as a bit field; for each TCP
>       control bit, there is a bit in this set.  The bit is set to 1 if
>       any observed packet of this Flow has the corresponding TCP control
>       bit set to 1.  The bit is cleared to 0 otherwise.
> 
>       The values of each bit are shown below, per the definition of the
>       bits in the TCP header [RFC0793]:
> 
> 
> 
> 
> Trammell & Aitken        Expires March 13, 2014                 [Page 2]
> Internet-Draft            IPFIX tcpControlBits            September 2013
> 
> 
>     MSb                                                         LSb
>      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 |
>    |     Zero      |   Future  | S | W | C | R | C | S | S | Y | I |
>    | (Data Offset) |    Use    |   | R | E | G | K | H | T | N | N |
>    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
> 
>    bit    flag
>    value  name  description
>    ------+-----+-------------------------------------
>    0x8000       Zero (see tcpHeaderLength)
>    0x4000       Zero (see tcpHeaderLength)
>    0x2000       Zero (see tcpHeaderLength)
>    0x1000       Zero (see tcpHeaderLength)
>    0x0800       Future Use
>    0x0400       Future Use
>    0x0200       Future Use
>    0x0100   NS  ECN Nonce Sum
>    0x0080  CWR  Congestion Window Reduced
>    0x0040  ECE  ECN Echo
>    0x0020  URG  Urgent Pointer field significant
>    0x0010  ACK  Acknowledgment field significant
>    0x0008  PSH  Push Function
>    0x0004  RST  Reset the connection
>    0x0002  SYN  Synchronize sequence numbers
>    0x0001  FIN  No more data from sender
> 
> 
>       As the most significant four bits of octets 12 and 13 of the TCP
>       header [RFC0793] are used to encode the TCP data offset (header
>       length), the corresponding bits in this IE must be exported as
>       zero and must be ignored by the collector; use the tcpHeaderLength
>       Information Element to encode this value.

Are there good reasons for the two "must" in this sentence? (And shouldn't this be a MUST if this really should be zero?). 

We could, at some point in the future, decide to use those four bits for something else. This happened for example with the CWR and ECE bits of the previous definition that had a requirement to be zero. Later on, it turned out that those bits had to be used for encoding something that the original definition hadn't thought about. 

I understand that these four bits are not likely to be used in the TCP header length to encode any useful information for flow data, but we might decide to use those four bits for encoding other information, e.g. some more information about the TCP connection state (or whatever else we might think about). 

What I would like to have would be some text that sets the bits to reserved and says something like:

"Bits 0x1000 through 0x.8000 are reserved for future use. A collector must not assume to receive information about the TCP header length; the field tcpHeaderLength Information Element should be used to encode this value."

What do you think?

>       Each of the three future use bits (0x800, 0x400, and 0x200) should
>       be exported as one if the corresponding bit is observed in the TCP
>       headers of the packets of this Flow, as they may be subsequent to
>       a future update of [RFC0793].

What does "as one" in "exported AS ONE if" mean? Does this mean that these bits must be exported as seen in the packet headers?

>       If exported as a single octet with reduced length encoding,

Nit: RFC 5101 calls it reduced size encoding (at least most of the time ;))

> this
>       Information Element covers the low-order octet of this field (i.e,
>       bits 0x80 to 0x01), omitting the ECN Nonce Sum and the three
>       Future Use bits.  A collector receiving this Information Element
>       with reduced length encoding must not assume anything about the
>       content of these four bits.

I just wanted to raise this point (without objecting). This would clearly be an exception to what I would expect from reduced size encoding in RFC 5101bis:

   The reduction in size can be to any number of
   octets smaller than the original type if the data value still fits,
   i.e., so that only leading zeroes are dropped.

Whenever I see reduced size encoding, I assume that there is no further information in the field and that all leading bits are zero because of this text. But I would assume this is not a hard requirement from RFC 5101(bis), and it is probably ok if the data type has an explicit definition that states that the first bits are not zero.

> 
> 
> Trammell & Aitken        Expires March 13, 2014                 [Page 3]
> Internet-Draft            IPFIX tcpControlBits            September 2013
> 
> 
>       Note that previous revisions of this Information Element's
>       definition specified that the CWR and ECE bits must be exported as
>       zero, even if observed.  Collectors should therefore not assume
>       that a value of zero for these bits in this Information Element
>       indicates the bits were never set in the observed traffic,
>       especially if these bits are zero in every Flow Record sent by a
>       given exporter.
>    References:   [RFC0793][RFC3168][RFC3540]
>    Revision:  1
> 
> 3.  IANA Considerations
> 
>    IANA will update the definition of the tcpControlBits Information
>    Element in the the IANA IPFIX Information Element Registry
>    [IANA-IPFIX] to reflect the changes in Section 2 above.
> 
> 4.  Security and Privacy Considerations
> 
>    This document has no security or privacy considerations; the security
>    considerations for IPFIX [I-D.ietf-ipfix-protocol-rfc5101bis] apply.
> 
> 5.  Acknowledgments
> 
>    Thanks to Andrew Feren for comments on the revised definition.  This
>    work is partially supported by the European Commission under grant
>    agreement FP7-ICT-318627 mPlane; this does not imply endorsement by
>    the Commission.
> 
> 6.  References
> 
> 6.1.  Normative References
> 
>    [I-D.ietf-ipfix-protocol-rfc5101bis]
>               Claise, B. and B. Trammell, "Specification of the IP Flow
>               Information eXport (IPFIX) Protocol for the Exchange of
>               Flow Information", draft-ietf-ipfix-protocol-rfc5101bis-10
>               (work in progress), July 2013.
> 
>    [I-D.ietf-ipfix-ie-doctors]
>               Trammell, B. and B. Claise, "Guidelines for Authors and
>               Reviewers of IPFIX Information Elements", draft-ietf-
>               ipfix-ie-doctors-07 (work in progress), October 2012.
> 
>    [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
>               793, September 1981.
> 
> 
> 
> 
> 
> 
> Trammell & Aitken        Expires March 13, 2014                 [Page 4]
> Internet-Draft            IPFIX tcpControlBits            September 2013
> 
> 
>    [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
>               of Explicit Congestion Notification (ECN) to IP", RFC
>               3168, September 2001.
> 
>    [RFC3540]  Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
>               Congestion Notification (ECN) Signaling with Nonces", RFC
>               3540, June 2003.
> 
> 6.2.  Informative References
> 
>    [RFC5102]  Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
>               Meyer, "Information Model for IP Flow Information Export",
>               RFC 5102, January 2008.
> 
>    [IANA-IPFIX]
>               Internet Assigned Numbers Authority, ., "IP Flow
>               Information Export Information Elements
>               (http://www.iana.org/assignments/ipfix)", .
> 
> Authors' Addresses
> 
>    Brian Trammell
>    Swiss Federal Institute of Technology Zurich
>    Gloriastrasse 35
>    8092 Zurich
>    Switzerland
> 
>    Phone: +41 44 632 70 13
>    Email: [email-masked]
> 
> 
>    Paul Aitken
>    Cisco Systems, Inc.
>    96 Commercial Quay
>    Commercial Street, Edinburgh EH6 6LX
>    United Kingdom
> 
>    Phone: +44 131 561 3616
>    Email: [email-masked]

--
Lothar Braun
Chair for Network Architectures and Services (I8)
Department of Informatics
Technische Universität München
Boltzmannstr. 3, 85748 Garching bei München, Germany
Phone:  +49 89 289-18010       Fax: +49 89 289-18033
E-mail: [email-masked]

---

From: Brian Trammell <[email-masked]>
Date: Tue, 10 Sep 2013 13:11:46 +0200

On 10 Sep 2013, at 10:32 , Lothar Braun <[email-masked]> wrote:

> Are there good reasons for the two "must" in this sentence? 

Well, we'd really like to enable the following code on the first packet (assuming you have an alignment-friendly architecture):

tcp_control_bits = ntohl((uint16_t *)(tcp_hdr_base + 12)) & 0x0FFF;

and the following on subsequent packets:

tcp_control_bits |= ntohl((uint16_t *)(tcp_hdr_base + 12)) & 0x0FFF;

> (And shouldn't this be a MUST if this really should be zero?). 

This section doesn't use 2119 language because it's meant to be inserted into the registry, where, IIRC, 2119 isn't explicitly in effect.

> We could, at some point in the future, decide to use those four bits for something else.

I'm not sure how you'd get such a proposal past the IE doctors :). The other header-field-like IEs in the information model are clearly taken from a portion of the packet, so an IE that used the top four bits for something else would break that precedent.

> This happened for example with the CWR and ECE bits of the previous definition that had a requirement to be zero. Later on, it turned out that those bits had to be used for encoding something that the original definition hadn't thought about. 

Right, but in that case, the bits were reserved for future use in TCP, not in IPFIX. The mistake we made in the 5101 revision of this IE is referencing 793 only, and not the updates to it. (This is why there's a difference between Zero and Future Use in this IE definition).

> I understand that these four bits are not likely to be used in the TCP header length to encode any useful information for flow data, but we might decide to use those four bits for encoding other in…

I'm a big fan of "each IE means one thing", even at the expense of efficiency, especially as these IEs are beginning to see use outside IPFIX. But it's entirely possible if unlikely that at some point in the future we'll reuse these four bits for something else, at which point the solution is a matter for the people writing the redefinition, and will probably look a lot like what we did for the ECN flag bits.

> "Bits 0x1000 through 0x.8000 are reserved for future use. A collector must not assume to receive information about the TCP header length; the field tcpHeaderLength Information Element should be use…

Again, I'm not sure that I'd want to explicitly encourage such reuse.

> Nit: RFC 5101 calls it reduced size encoding (at least most of the time ;))

Yeah, it turns out I'm the only one who calls it reduced-length. Will fix, thanks.

> Whenever I see reduced size encoding, I assume that there is no further information in the field and that all leading bits are zero because of this text. But I would assume this is not a hard requi…

Well, it could mean two things: the top bits are zero because the Nonce Sum bit was never set on any packet in the flow (which, given studies on the usage of ECN, and anecdotes about ECN Nonce deployment, I would say is the case 99.99...% of the time), or because it was not observed (since nobody uses ECN nonce, nobody measures it, either).

Perhaps we should state that unsigned16 encoding should ONLY be used by EPs connected to MPs which actually know how to measure at least one of the bits, so that 0s here won't be interpreted as actual assertions of no flag present.

Cheers,

Brian

---

From: Andrew Feren <[email-masked]>
Date: Thu, 12 Sep 2013 08:27:48 -0400

> On 10 Sep 2013, at 10:32 , Lothar Braun <[email-masked]> wrote:
[ snip ]
> I'm a big fan of "each IE means one thing", even at the expense of
> efficiency, especially as these IEs are beginning to 

+1

> see use outside IPFIX. But it's entirely possible if unlikely that at
> some point in the future we'll reuse these four bits 

Where else?  Just curious.

> for something else, at which point the solution is a matter for the
> people writing the redefinition, and will probably look a lot like
> what we did for the ECN flag bits.

I'd go one step stronger and say such reuse should be actively discouraged.

[ snip ]

> Perhaps we should state that unsigned16 encoding should ONLY be used by EPs connected to MPs which actually know how to measure at least one of the bits, so that 0s here won't be interpreted as act…

I like this idea.  It provides an avenue to reduce/remove ambiguity.

-Andrew

---

From: Lothar Braun <[email-masked]>
Date: Thu, 19 Sep 2013 09:42:03 +0200

On Sep 10, 2013, at 1:11 PM, Brian Trammell <[email-masked]> wrote:

> tcp_control_bits |= ntohl((uint16_t *)(tcp_hdr_base + 12)) & 0x0FFF

I understand. But a more relaxed definition of the bit values, e.g. not defining them, would still give you the possibility to do this.

> This section doesn't use 2119 language because it's meant to be inserted into the registry, where, IIRC, 2119 isn't explicitly in effect.

Ok.

> Right, but in that case, the bits were reserved for future use in TCP, not in IPFIX. The mistake we made in the 5101 revision of this IE is referencing 793 only, and not the updates to it. (This is…

Point. 

> I'm a big fan of "each IE means one thing", even at the expense of efficiency, especially as these IEs are beginning to see use outside IPFIX. But it's entirely possible if unlikely that at some po…

I can absolutely understand your point. The only thing I'm saying is that there is no need to define the value of those four bits. I have no plans for using the four bits, but someday there might be someone with compelling reasons that convince IE doctors. 

And if the definition of the IE is then changed again, we need to think about whether the change would break existing collectors. An vendor could for example decide to implement sanity-checks on the flow records. And he could decide to throw away data that does not explicitly comply with the definition, e.g. does not set the four bits to zero.

It might be simpler to assign a new meaning to the four bits if there is good use for them if they are considered reserved. And there is still the IE doctors process to make sure that these bits are not abused without good reasons ;)

However, I do not have any plans to use the four bits and therefore no strong opinion on the topic. If there is a consensus that the definition should discourage the use of the four bits right away, then I'm not going to object.  

>> What does "as one" in "exported AS ONE if" mean? Does this mean that these bits must be exported as seen in the packet headers?

Can you give me a pointer on this question? (this was the initial reason for my previous mail :))

+1 

- Lothar