RFC 7125

Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element

📅 published February 2014, from ietf

RFC 7125 🎀 Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element

Bestie, this one is the glow-up for the tcpControlBits IPFIX Information Element 💅 Here's the title-block tea:

  • Authors: Brian Trammell (ETH Zurich) and Paul Aitken (Cisco Systems, Inc)
  • Category: Informational
  • ISSN: 2070-1721
  • Date: February 2014
  • What it does: revises the tcpControlBits Information Element as originally defined in RFC 5102
  • Obsoletes/updates: the title block doesn't list anything being obsoleted or updated, but the abstract says it's revising the RFC 5102 definition

Abstract ✨

Okay, so this doc gives the tcpControlBits IPFIX Information Element (originally from RFC 5102) a makeover 💖 It updates it so it matches how the TCP Flags header field has changed since RFC 793. Literally the whole point 🫶

Status of This Memo 📜

This document is not an Internet Standards Track specification. It's published for informational purposes 🌸

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🎀 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details 🧚

For the current status of this document, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7125 🦋

Copyright (c) 2014 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 read these carefully, because they spell out your rights and restrictions for 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 they're provided without warranty as described in the Simplified BSD License.

1. Introduction 🦋

So, the TCP header has this vibe: octets 12 and 13 (counting from zero) hold the data offset (header length) in 4 bits, plus 12 bits of flags. The least significant 6 bits were defined in [RFC0793] as URG, ACK, PSH, RST, SYN, and FIN for TCP control. Then [RFC3168] added the CWR and ECE flags for Explicit Congestion Notification (ECN) negotiation and signaling, and [RFC3540] added the NS flag for the ECN Nonce Sum 🔥

Here's the problem 😭 The IANA IPFIX Information Element Registry [IANA-IPFIX], which came from [RFC5102], says the tcpControlBits IE for IPFIX [RFC7011] only covers those original 6 bits from [RFC0793]. If you want IPFIX to measure ECN use, and you want the IE to match the current TCP Flags header field, the definition has to be revised. No way around it 💅

The revised definition in Section 3 went through the IE-DOCTORS process [RFC7013] and was approved in August 2013. Section 5.1 of [RFC7013] says: "This process should not in any way be construed as allowing the IE-DOCTORS to overrule IETF consensus. Specifically, Information Elements in the IANA Information Element registry that were added with IETF consensus require IETF consensus for revision or deprecation". Since tcpControlBits was originally defined in [RFC5102], which is an IETF Proposed Standard, any revision needs IETF Consensus. Publishing this document is what fulfills that requirement ✨

Section 3 defines the revised tcpControlBits IE, as in Section 9.1 of [RFC7013] 🎀

2. Terminology 💅

Here are the key words, and how to read them, per [RFC2119]: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🧚

3. The tcpControlBits Information Element 🎀

This is the main event, bestie 😭 Here's the field info:

ElementId:  6

Data Type:  unsigned16

Data Type Semantics:  flags

Description: the TCP control bits observed for the packets of this Flow 🌈 The info is a bit field. Each TCP control bit gets its own bit in the set. A bit is set to 1 if any observed packet of this Flow has that TCP control bit set to 1, and it's cleared to 0 otherwise.

The values for each bit come from the bit definitions in the TCP header, per [RFC0793] [RFC3168] [RFC3540]. Here's the layout 💖

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

And the bit-by-bit breakdown:

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

The top 4 bits of octets 12 and 13 (counting from zero) of the TCP header [RFC0793] are used for the TCP data offset (header length). So the matching bits in this Information Element MUST be exported as zero and MUST be ignored by the collector 🙈 For that value, use the tcpHeaderLength Information Element instead.

The three bits 0x800, 0x400, and 0x200 are reserved for future use in [RFC0793]. They SHOULD be exported as observed in the TCP headers of the packets of this Flow ✨

If it's exported as a single octet with reduced-size encoding, this IE only covers the low-order octet (bits 0x80 to 0x01). That means the ECN Nonce Sum and the three Future Use bits get left out 🫣 A collector that gets this IE with reduced-size encoding must not assume anything about the content of those four bits.

Exporting Processes that export this IE on behalf of a Metering Process that can't observe any of the ECN Nonce Sum or Future Use bits SHOULD use reduced-size encoding, and only export the least significant 8 bits of this Information Element 🍓

Okay, important tea ☕ Earlier revisions said the CWR and ECE bits had to be exported as zero, even if they were observed. So collectors should not assume that a zero for these bits in this IE means they were never set in the traffic, especially if those bits are zero in every Flow Record from a given exporter 👀

Units: (none)

Range: (none)

References: [RFC0793] [RFC3168] [RFC3540]

Revision: 1

4. IANA Considerations 🌸

IANA has updated the tcpControlBits definition in the IANA IPFIX Information Element Registry [IANA-IPFIX] to match the changes in Section 3 above. The revision is set to 1 as noted, and the revision date is the publication date of this document 🧚

5. Security and Privacy Considerations 🔥

This document changes the data type (and so the native size) of the tcpControlBits Information Element, going from unsigned8 (1 octet) to unsigned16 (2 octets). Exporting and Collecting Processes use the Information Element Length field in Templates, Options Templates, and reduced-size encoding specifications where appropriate. They don't rely on abstract data type sizes when encoding and decoding Data Records. So it's not expected to affect buffer sizing during encoding and decoding 💅 Otherwise, the security considerations for IPFIX [RFC7011] still apply, so go read those too 🔐

6. Acknowledgments 🫶

Thanks to Andrew Feren, Lothar Braun, Michael Scharf, and Simon Josefsson for their comments on the revised definition 💖 This work was partially supported by the European Commission under grant agreement FP7-ICT-318627 mPlane. That doesn't imply the Commission endorses it 🌈

7. References

7.1. Normative References

[RFC0793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
           793, September 1981.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

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

[RFC7011]  Claise, B., Trammell, B., and P. Aitken, "Specification of
           the IP Flow Information Export (IPFIX) Protocol for the
           Exchange of Flow Information", STD 77, RFC 7011, September
           2013.

[RFC7013]  Trammell, B. and B. Claise, "Guidelines for Authors and
           Reviewers of IP Flow Information Export (IPFIX)
           Information Elements", BCP 184, RFC 7013, September 2013.

7.2. Informative References

[IANA-IPFIX]
           IANA, "IP Flow Information Export (IPFIX) Entities",
           <http://www.iana.org/assignments/ipfix>.

[RFC5102]  Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
           Meyer, "Information Model for IP Flow Information Export",
           RFC 5102, January 2008.

Authors' Addresses 🧚

Brian Trammell
Swiss Federal Institute of Technology Zurich
Gloriastrasse 35
8092 Zurich
Switzerland

Phone: +41 44 632 70 13
EMail: trammell@tik.ee.ethz.ch


Paul Aitken
Cisco Systems, Inc.
96 Commercial Quay
Commercial Street, Edinburgh EH6 6LX
United Kingdom

Phone: +44 131 561 3616
EMail: paitken@cisco.com
📦 where this page comes from