Orange

Rennes 35000 France mohamed.boucadair@orange.com

Operations and Management OPSAWG IPFIX TCP Measurement Export Observability RFC 7125 revised the tcpControlBits IP Flow Information Export (IPFIX) Information Element that was originally defined in RFC 5102 to reflect changes to the TCP header control bits since RFC 793. However, that update is still problematic for interoperability because some flag values have subsequently been deprecated. This document removes stale information from the IANA "IPFIX Information Elements" registry and avoids future conflicts 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 .

Copyright Notice 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 () 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

• .  Introduction
• .  Terminology
• .  Revised tcpControlBits Information Element
• .  An Example
• .  IANA Considerations
• .  Security Considerations
• .  References
  • .  Normative References
  • .  Informative References
• .  Changes from RFC 7125
• Acknowledgments
  • Acknowledgments from RFC 7125
• Contributors
• Author's Address

Introduction TCP defines a set of control bits (also known as "flags") for managing connections (). The "TCP Header Flags" registry was initially set by , but it was populated with only TCP control bits that were defined in . fixed that by moving that registry to be listed as a subregistry under the "Transmission Control Protocol (TCP) Parameters" registry , adding bits that had previously been specified in , and removing the NS (Nonce Sum) bit per . Also, introduces "Bit Offset" to ease referencing each header flag's offset within the 16-bit aligned view of the TCP header (Figure 1 of ). is thus settled as 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. revised the tcpControlBits IP Flow Information Export (IPFIX) Information Element that was originally defined in to reflect changes to the TCP control bits since . However, that update is still problematic for interoperability because a value was deprecated since then (), and, therefore, risks deviating from the authoritative "TCP Header Flags" registry . This document fixes that problem by removing stale information from the "IPFIX Information Elements" registry and avoiding future conflicts with the authoritative "TCP Header Flags" registry . The update in this document also enhances observability. For example, network operators can identify packets that are observed with unassigned TCP flags set and, therefore, identify which applications in the network should be upgraded to reflect the changes to TCP flags that were introduced, e.g., in . The main changes from are listed in .

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 when, and only when, they appear in all capitals, as shown here. This document uses the terms defined in .

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; 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. The bit is cleared to 0 otherwise. Per , the assignment of TCP control bits is managed by IANA via the "TCP Header Flags" registry . 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 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 (), this Information Element covers the low-order octet of this field (i.e., bit offset positions 8 to 15) . 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 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 .

Reference:

, RFC 9565

Revision:

2

An Example shows an example of a tcpControlBits Information Element set to 0x92, where MSB indicates the most significant bit and LSB indicates the least significant bit. This Information Element is used to report TCP control bits for a Flow that has CWR (Congestion Window Reduced), ACK, and SYN flag bits set (that is, bit offset positions 8, 11, and 14).

An Example of the tcpControlBits Information Element MSB LSB 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|0|0|1|0|0|1|0|0|1|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IANA Considerations IANA has updated the "tcpControlBits" entry of the "IPFIX Information Elements" registry to echo the details provided in .

Security Considerations Because the setting of TCP control bits may be misused in some Flows (e.g., Distributed Denial-of-Service (DDoS) attacks), an Exporter has to report all observed control bits even if no meaning is associated with a given TCP flag. This document uses a stronger requirements language compared to . This document does not add new security considerations to those already discussed for IPFIX in .

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168. IANA Informative References IANA This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK] This memo defines an information model for the IP Flow Information eXport (IPFIX) protocol. It is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although developed for the IPFIX protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. [STANDARDS-TRACK] This document revises the tcpControlBits IP Flow Information Export (IPFIX) Information Element as originally defined in RFC 5102 to reflect changes to the TCP Flags header field since RFC 793. This memo updates RFC 3168, which specifies Explicit Congestion Notification (ECN) as an alternative to packet drops for indicating network congestion to endpoints. It relaxes restrictions in RFC 3168 that hinder experimentation towards benefits beyond just removal of loss. This memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation in these areas. An Experimental RFC in the IETF document stream is required to take advantage of any of these enabling updates. In addition, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and for the Datagram Congestion Control Protocol (DCCP) in RFCs 4341, 4342, and 5622. This memo also records the conclusion of the ECN nonce experiment in RFC 3540 and provides the rationale for reclassification of RFC 3540 from Experimental to Historic; this reclassification enables new experimental use of the ECT(1) codepoint. This document introduces new IP Flow Information Export (IPFIX) Information Elements (IEs) to identify a set of information related to Segment Routing over IPv6 (SRv6) such as data contained in a Segment Routing Header (SRH), the SRv6 control plane, and the SRv6 Endpoint behavior that traffic is being forwarded with.

Changes from RFC 7125

• 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.
• Removed the table of TCP flag bits from the description of the tcpControlBits Information Element.
• Added the reference to the Additional Information field of the tcpControlBits Information Element.
• Used strong normative language for exporting observed flags.
• Updated the references of the tcpControlBits Information Element.
• Bumped the revision of the tcpControlBits Information Element.
• Replaced obsolete RFCs (e.g., ).
• Added an example section ().

Acknowledgments This document was triggered by a discussion in the opsawg working group between the author and the authors of . Thanks to , , and for the review and comments. Thanks to for the tsvart review, for the rtgdir review, and for the genart review. Thanks to for the AD review. Thanks to for the artart review and for the secdir review. Thanks to and for the comments in the IESG review.

Acknowledgments from RFC 7125 Thanks to , , , and 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 are as follows:

Author's Address Orange

Rennes 35000 France mohamed.boucadair@orange.com