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 athttps://www.rfc-editor.org/info/rfc9565.¶

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

TCP defines a set of control bits (also known as "flags") for managing connections (Section 3.1 of [RFC9293]). The "TCP Header Flags" registry was initially set by[RFC3168], but it was populated with only TCP control bits that were defined in[RFC3168].[RFC9293] fixed that by moving that registry to be listed as a subregistry under the "Transmission Control Protocol (TCP) Parameters" registry[TCP-FLAGS], adding bits that had previously been specified in[RFC0793], and removing the NS (Nonce Sum) bit per[RFC8311]. Also,Section 6 of [RFC9293] introduces "Bit Offset" to ease referencing each header flag's offset within the 16-bit aligned view of the TCP header (Figure 1 of[RFC9293]).[TCP-FLAGS] 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.¶

[RFC7125] revised the tcpControlBits IP Flow Information Export (IPFIX) Information Element that was originally defined in[RFC5102] to reflect changes to the TCP control bits since[RFC0793]. However, that update is still problematic for interoperability because a value was deprecated since then (Section 7 of [RFC8311]), and, therefore,[RFC7125] risks deviating from the authoritative "TCP Header Flags" registry[TCP-FLAGS].¶

This document fixes that problem by removing stale information from the "IPFIX Information Elements" registry[IPFIX] and avoiding future conflicts with the authoritative "TCP Header Flags" registry[TCP-FLAGS]. 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[RFC8311].¶

The main changes from[RFC7125] are listed inAppendix 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 inSection 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; each TCP controlbit has a corresponding bit in that field. A bit is set to 1 if anyobserved packet of this Flow has the corresponding TCP control bitset to 1. The bit is cleared to 0 otherwise.¶

Per[RFC9293], the assignment of TCP control bits ismanaged 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 fromzero) of the TCP header[RFC9293] are used to encode the TCP dataoffset (header length), the corresponding bits in this InformationElementMUST be reported by the Exporter with a value of zero andMUST be ignoredby the Collector. Use the tcpHeaderLength Information Element toencode this value.¶

All TCP control bits (including those unassigned)MUST be exportedas 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]), thisInformation Element covers the low-order octet of this field (i.e.,bit offset positions 8 to 15)[TCP-FLAGS]. A Collector receiving this Information Elementwith reduced-size encoding must not assume anything about thecontent of the four bits with bit offset positions 4 to 7.¶

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

Note that previous revisions of this Information Element'sdefinition specified that flags with bit offset positions 8 and 9 must be exported aszero, even if observed. Collectors should therefore not assumethat a value of zero for these bits in this Information Elementindicates the bits were never set in the observed traffic,especially if these bits are zero in every Flow Record sent by agiven Exporter.¶

Note also that the "TCP Header Flags" registry[TCP-FLAGS] indexes the bit offset from the most significantbit 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¶

4.An Example

Figure 1 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 Flowthat has CWR (Congestion Window Reduced), ACK, and SYN flag bits set (that is, bit offset positions 8, 11, and 14).¶

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

5.IANA Considerations

IANA has updated the "tcpControlBits" entry of the "IPFIX Information Elements" registry[IPFIX] to echo the details provided inSection 3.¶

6.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[RFC7125].¶

This document does not add new security considerations to those already discussed for IPFIX in[RFC7011].¶

Appendix A.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[TCP-FLAGS] 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.,[RFC0793]).¶

• Added an example section (Section 4).¶

Acknowledgments

This document was triggered by a discussion in the opsawg working group between the author and the authors of[RFC9487].¶

Thanks toChristian Jacquenet,Thomas Graf, andBenoît Claise for the review and comments.¶

Thanks toMichael Scharf for the tsvart review,Ketan Talaulikar for the rtgdir review, andElwyn Davies for the genart review.¶

Thanks toRob Wilton for the AD review.¶

Thanks toTim Bray for the artart review andShawn Emery for the secdir review.¶

Thanks toÉric Vyncke andPaul Wouters for the comments in the IESG review.¶

Contributors

The authors of[RFC7125] are as follows:¶

Author's Address