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

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 https://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 1 June 2024.¶

Copyright Notice

Copyright (c) 2023 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 "Transmission Control Protocol (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 as 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 (IE) 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 registry [TCP-FLAGS].¶

This document fixes that problem by removing stale information from the IPFIX registry [IPFIX] and avoiding future conflicts with the authoritative TCP registry [TCP-FLAGS]. The update in this document is also useful to enhance observability. For example, network operators can identify when packets are being 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 to [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¶

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; 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.¶

As per [RFC9293], the assignment of the TCP control bits is managed by IANA from the "TCP Header Flags" registry [TCP-FLAGS]. That registry is authoritative to retrieve the most recent TCP control bits.¶

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 [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:¶

References:

[RFC9293][This-Document]¶

Additional Information:

See the assigned TCP control bits in [TCP-FLAGS].¶

Revision:

2¶

4. An Example

Figure 1 shows an example of a tcpControlBits Information Element set to 146. 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).¶

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 is requested to update the "tcpControlBits" entry of the [IPFIX] to echo the details provided in Section 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

• Clean-up the description by removing mentions of stale flag bits, referring to the flag bits by their bit offset position, and relying upon the IANA TCP registry.¶

• Remove the table of TCP flag bits from the description of the tcpControlBits Information Element.¶

• Add [TCP-FLAGS] to the Additional Information field of the tcpControlBits Information Element.¶

• Use strong normative language for exporting observed flags.¶

• Update the references of the tcpControlBits Information Element.¶

• Bump the revision of the tcpControlBits Information Element.¶

• Replace obsolete RFCs (e.g., [RFC0793]).¶

• Add an Example Section¶

Acknowledgments

This document was triggered by a discussion of the author in opsawg with the authors of [RFC9487].¶

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 for 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 [RFC7125]:

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