RFC 9565

An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element

📅 published March 2024, from ietf

Request for Comments: 9565 🎀

  • Author: M. Boucadair, Orange 💅
  • Category: Standards Track ✨
  • Date: March 2024 🌸
  • Obsoletes: RFC 7125 💀
  • ISSN: 2070-1721 🔥
  • Publisher: Internet Engineering Task Force (IETF) 🧚

An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element 🌈

Abstract ✨

Okay so, RFC 7125 updated the tcpControlBits IP Flow Information Export (IPFIX) Information Element, which was first defined in RFC 5102, so it would match the TCP header control bits changes since RFC 793. 💖 Lowkey though, that update still causes interop drama, because some flag values have since been deprecated. 😭

This document cleans up the stale stuff in the IANA "IPFIX Information Elements" registry and stops future clashes with the authoritative IANA "TCP Header Flags" registry. 🫶

This document obsoletes RFC 7125. 🥀

Status of This Memo 🌸

This is an Internet Standards Track document. ✨

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. 💅

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9565. 🔗

Copyright (c) 2024 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. 📜

Table of Contents 🦋

1.  Introduction
2.  Terminology
3.  Revised tcpControlBits Information Element
4.  An Example
5.  IANA Considerations
6.  Security Considerations
7.  References
  7.1.  Normative References
  7.2.  Informative References
Appendix A.  Changes from RFC 7125
Acknowledgments
  Acknowledgments from RFC 7125
Contributors
Author's Address

1. Introduction ✨

Okay so TCP has a set of control bits (also called "flags") for managing connections (Section 3.1 of [RFC9293]). 🧚 The "TCP Header Flags" registry was first set up by [RFC3168], but it only got filled with the TCP control bits that [RFC3168] defined. 🌸 Then [RFC9293] came in and fixed that by moving the registry so it's listed as a subregistry under the "Transmission Control Protocol (TCP) Parameters" registry [TCP-FLAGS]. It also added the bits that had been specified in [RFC0793] and removed the NS (Nonce Sum) bit per [RFC8311]. 💅 Section 6 of [RFC9293] also introduces "Bit Offset," which makes it way easier to point at each header flag's offset within the 16-bit aligned view of the TCP header (Figure 1 of [RFC9293]). So [TCP-FLAGS] is now the authoritative reference for the assigned TCP control bits. 👑

Note: The bits in offsets 0 through 3 are not header flags, but the TCP segment Data Offset field. 🙈

[RFC7125] revised the tcpControlBits IP Flow Information Export (IPFIX) Information Element that was originally defined in [RFC5102] so it reflects the TCP control bit changes since [RFC0793]. 💖 The problem is that this update is still kind of broken for interoperability, because a value was deprecated after that (Section 7 of [RFC8311]). That means [RFC7125] can drift away from the authoritative "TCP Header Flags" registry [TCP-FLAGS]. 😭

This document fixes that by cleaning up the stale info in the "IPFIX Information Elements" registry [IPFIX] and by avoiding future conflicts with the authoritative "TCP Header Flags" registry [TCP-FLAGS]. ✨ It also boosts observability. For example, network operators can spot packets that have unassigned TCP flags set, which helps them figure out which applications in the network should be upgraded to reflect the TCP flag changes that were introduced, e.g., in [RFC8311]. 🔥 Main vibe check: the main changes from [RFC7125] are listed in Appendix A. 🫶

2. Terminology 🎀

The key words "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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 💜

This document uses the terms defined in Section 2 of [RFC7011]. 🌸

3. Revised tcpControlBits Information Element 🦋

  • ElementID: 6 🌈
  • Name: tcpControlBits 💅
  • Abstract Data Type: unsigned16 ✨
  • Data Type Semantics: flags 🧚
  • Status: current 🌸
  • Description:

TCP control bits observed for the packets of this Flow. 💖 This information is encoded as a bit field, and each TCP control bit has a corresponding bit in that field. A bit is set to 1 if any observed packet of this Flow has the corresponding TCP control bit set to 1. Otherwise, the bit is cleared to 0. 🫶

Per [RFC9293], the assignment of TCP control bits is managed by IANA via the "TCP Header Flags" registry [TCP-FLAGS]. Implementers can retrieve the current TCP control bits from that registry, which is authoritative for them. 👑

As the most significant 4 bits of octets 12 and 13 (counting from zero) of the TCP header [RFC9293] are used to encode the TCP data offset (header length), the corresponding bits in this Information Element MUST be reported by the Exporter with a value of zero and MUST be ignored by the Collector. 😭 Use the tcpHeaderLength Information Element to encode this value. ✨

All TCP control bits (including those unassigned) MUST be exported as observed in the TCP headers of the packets of this Flow. 🔥

If exported as a single octet with reduced-size encoding (Section 6.2 of [RFC7011]), this Information Element covers the low-order octet of this field (i.e., bit offset positions 8 to 15) [TCP-FLAGS]. A Collector receiving this Information Element with reduced-size encoding must not assume anything about the content of the four bits with bit offset positions 4 to 7. 🙈

Exporting Processes exporting this Information Element on behalf of a Metering Process that is not capable of observing any of the flags with bit offset positions 4 to 7 SHOULD use reduced-size encoding, and only export the least significant 8 bits of this Information Element. 🎀

Note that previous revisions of this Information Element's definition specified that flags with bit offset positions 8 and 9 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. 🌈

Note also that the "TCP Header Flags" registry [TCP-FLAGS] indexes the bit offset from the most significant bit of octet 12 to the least significant bit of octet 13 in the TCP header, but the tcpControlBits is encoded as a regular unsigned 16-bit integer. 🧚

  • Units:
  • Range:
  • Additional Information: See the assigned TCP control bits in the "TCP Header Flags" registry [TCP-FLAGS]. 🌸
  • Reference: [RFC9293], RFC 9565 💖
  • Revision: 2 🦋

7.2. Informative References ✨

okay so these are the "extra reading" refs, the ones that aren't required to implement this but give you the backstory 📚💖

Appendix A. Changes from RFC 7125 🎀

okay so this is the glow-up log. Here's everything that changed from RFC 7125 bestie 💅

  • Cleaned up the description of the tcpControlBits Information Element 🧹 by removing mentions of stale flag bits, referring to the flag bits by their bit offset position, and relying upon the IANA "TCP Header Flags" registry. Less outdated gossip, more source of truth ✨
  • Removed the table of TCP flag bits from the description of the tcpControlBits Information Element. No more table, the registry does the talking 📋
  • Added the reference [TCP-FLAGS] to the Additional Information field of the tcpControlBits Information Element. 🔗
  • Used strong normative language for exporting observed flags. It's a whole mood now, no wiggle room 🔥
  • Updated the references of the tcpControlBits Information Element. 📚
  • Bumped the revision of the tcpControlBits Information Element. New version, new me 💖
  • Replaced obsolete RFCs (e.g., [RFC0793]). Out with the old citations, in with the new 🌈
  • Added an example section (Section 4). Showing, not just telling, which is so important 🙈

Acknowledgments 🫶

This document was triggered by a discussion in the opsawg working group between the author and the authors of [RFC9487]. The whole thing started from a chat, which is honestly iconic 💜

Thanks to Christian Jacquenet, Thomas Graf, and Benoît Claise for the review and comments. 🌸

Thanks to Michael Scharf for the tsvart review, Ketan Talaulikar for the rtgdir review, and Elwyn Davies for the genart review. 🙌

Thanks to Rob Wilton for the AD review. ✨

Thanks to Tim Bray for the artart review and Shawn Emery for the secdir review. 💅

Thanks to Éric Vyncke and Paul Wouters for the comments in the IESG review. 👑

Acknowledgments from RFC 7125 🌷

Thanks to Andrew Feren, Lothar Braun, Michael Scharf, and Simon Josefsson 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. 🇪🇺💖

Contributors 🧚

The authors of [RFC7125] are as follows:

  • Brian Trammell 🦋
  • Paul Aitken 🦋

Author's Address 💌

Mohamed Boucadair
Orange
35000 Rennes
France
Email: mohamed.boucadair@orange.com
📦 where this page comes from