Internet-Draft tcpControlBits IPFIX February 2023
Boucadair Expires 28 August 2023 [Page]
Workgroup:
OPSAWG
Internet-Draft:
draft-ietf-opsawg-rfc7125-update-01
Updates:
7125 (if approved)
Published:
Intended Status:
Standards Track
Expires:
Author:
M. Boucadair
Orange

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

Abstract

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 Flags header field since RFC 793. However, that update is still problematic for interoperability because some flag values were deprecated since then.

This document updates RFC 7125 by removing stale information from the IPFIX registry and avoiding future conflicts with the authoritative TCP Header Flags registry.

Discussion Venues

This note is to be removed before publishing as an RFC.

Discussion of this document takes place on the Operations and Management Area Working Group Working Group mailing list (opsawg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/opsawg/.

Source for this draft and an issue tracker can be found at https://github.com/boucadair/-ipfix-rfc7125-update.

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 28 August 2023.

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

[RFC7125] revised the tcpControlBits IP Flow Information Export (IPFIX) Information Element (IE) that was originally defined in [RFC5102] to reflect changes to the TCP Flags header field 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 to deviate from the authoritative TCP registry [TCP-FLAGS]. This update 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].

This document fixes that problem by removing stale information from the IPFIX registry and avoiding future conflicts with the authoritative TCP registry [IPFIX].

Also, 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 requirement language compared to [RFC7125]. See Section 3 for more details.

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. An Update to tcpControlBits IP Flow Information Export (IPFIX) Information Element

This document updates Section 3 of [RFC7125] as follows:

OLD:
   The values of each bit are shown below, per the definition of the
   bits in the TCP header [RFC0793][RFC3168][RFC3540]:

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

   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

   As the most significant 4 bits of octets 12 and 13 (counting from
   zero) of the TCP header [RFC0793] are used to encode the TCP data
   offset (header length), the corresponding bits in this Information
   Element MUST be exported as zero and MUST be ignored by the
   collector.  Use the tcpHeaderLength Information Element to encode
   this value.

   Each of the 3 bits (0x800, 0x400, and 0x200), which are reserved
   for future use in [RFC0793], SHOULD be exported as observed in the
   TCP headers of the packets of this Flow.
NEW:
   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 exported 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.

4. IANA Considerations

IANA is requested to update the "tcpControlBits" entry of the [IPFIX] as follows:

5. Security Considerations

This document does not add any new security considerations to those already discussed in Section 5 of [RFC7125].

6. References

6.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC7011]
Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, , <https://www.rfc-editor.org/rfc/rfc7011>.
[RFC7125]
Trammell, B. and P. Aitken, "Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element", RFC 7125, DOI 10.17487/RFC7125, , <https://www.rfc-editor.org/rfc/rfc7125>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9293]
Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, , <https://www.rfc-editor.org/rfc/rfc9293>.
[TCP-FLAGS]
IANA, "TCP Header Flags", n.d., <https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-header-flags>.

6.2. Informative References

[I-D.ietf-opsawg-ipfix-srv6-srh]
Graf, T., Claise, B., and P. Francois, "Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX)", Work in Progress, Internet-Draft, draft-ietf-opsawg-ipfix-srv6-srh-06, , <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh-06>.
[IPFIX]
IANA, "IP Flow Information Export (IPFIX) Entities", n.d., <<https://www.iana.org/assignments/ipfix/ipfix.xhtml>.
[RFC0793]
Postel, J., "Transmission Control Protocol", RFC 793, DOI 10.17487/RFC0793, , <https://www.rfc-editor.org/rfc/rfc793>.
[RFC3168]
Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, , <https://www.rfc-editor.org/rfc/rfc3168>.
[RFC3540]
Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, DOI 10.17487/RFC3540, , <https://www.rfc-editor.org/rfc/rfc3540>.
[RFC5102]
Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, DOI 10.17487/RFC5102, , <https://www.rfc-editor.org/rfc/rfc5102>.
[RFC8311]
Black, D., "Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation", RFC 8311, DOI 10.17487/RFC8311, , <https://www.rfc-editor.org/rfc/rfc8311>.

Acknowledgments

This document was triggered by a discussion of the author in opsawg with the authors of [I-D.ietf-opsawg-ipfix-srv6-srh].

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

Author's Address

Mohamed Boucadair
Orange
35000 Rennes
France