Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element
Updates the IPFIX tcpControlBits field so flow records can carry all the TCP flags in use, including ECN.
Trammell, B. and P. Aitken, "Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element", RFC 7125, DOI 10.17487/RFC7125, February 2014, <https://www.rfc-editor.org/info/rfc7125>.
@misc{rfc7125,
series = {Request for Comments},
number = 7125,
howpublished = {RFC 7125},
publisher = {RFC Editor},
doi = {10.17487/RFC7125},
url = {https://www.rfc-editor.org/info/rfc7125},
author = {B. Trammell and P. Aitken},
title = {{Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element}},
pagetotal = 6,
year = 2014,
month = feb,
} RFC text
Contents
Internet Engineering Task Force (IETF) B. Trammell
Request for Comments: 7125 ETH Zurich
Category: Informational P. Aitken
ISSN: 2070-1721 Cisco Systems, Inc
February 2014
Revision of the tcpControlBits
IP Flow Information Export (IPFIX) Information Element
Abstract
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.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
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). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7125.
Copyright Notice
Copyright (c) 2014 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
(http://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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
1. Introduction
Octets 12 and 13 (counting from zero) of the TCP header encode the
data offset (header length) in 4 bits, as well as 12 bits of flags.
The least significant 6 bits of these were defined in [RFC0793] as
URG, ACK, PSH, RST, SYN, and FIN for TCP control. Subsequently,
[RFC3168] defined the CWR and ECE flags for Explicit Congestion
Notification (ECN) negotiation and signaling; [RFC3540] additionally
defined the NS flag for the ECN Nonce Sum.
As defined in the IANA IPFIX Information Element Registry
[IANA-IPFIX], taken from [RFC5102], the tcpControlBits Information
Element for IPFIX [RFC7011] only covers the original 6 bits from
[RFC0793]. To allow IPFIX to be used to measure the use of ECN, and
to bring the IPFIX Information Element definition in line with the
current definition of the TCP Flags header field, it is necessary to
revise this definition.
The revised definition of the Information Element in Section 3 was
developed and approved through the IE-DOCTORS process [RFC7013] in
August 2013. Section 5.1 of [RFC7013] states "This process should
not in any way be construed as allowing the IE-DOCTORS to overrule
IETF consensus. Specifically, Information Elements in the IANA
Information Element registry that were added with IETF consensus
require IETF consensus for revision or deprecation". Since the
tcpControlBits Information Element was originally defined in
[RFC5102], an IETF Proposed Standard, any revision of this
Information Element definition requires IETF Consensus. The
publication of this document fulfills that requirement.
Section 3 defines the revised tcpControlBits Information Element as
in Section 9.1 of [RFC7013].
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
[RFC2119].
3. The 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; for each TCP control
bit, there is a bit in this set. The 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.
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.
If exported as a single octet with reduced-size encoding, this
Information Element covers the low-order octet of this field (i.e,
bits 0x80 to 0x01), omitting the ECN Nonce Sum and the three
Future Use bits. A collector receiving this Information Element
with reduced-size encoding must not assume anything about the
content of these four bits.
Exporting Processes exporting this Information Element on behalf
of a Metering Process that is not capable of observing any of the
ECN Nonce Sum or Future Use bits 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 the CWR and ECE bits 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.
Units:
Range:
References: [RFC0793] [RFC3168] [RFC3540]
Revision: 1
4. IANA Considerations
IANA has updated the definition of the tcpControlBits Information
Element in the IANA IPFIX Information Element Registry [IANA-IPFIX]
to reflect the changes in Section 3 above, setting the revision to 1
as noted, and the revision date to the date of publication of this
document.
5. Security and Privacy Considerations
This document changes the data type (and therefore the native size)
of the tcpControlBits Information Element, from unsigned8 (1 octet)
to unsigned16 (2 octets). As Exporting and Collecting Processes use
the Information Element Length field in Templates, Options Templates,
and specifications for reduced-size encoding where appropriate, as
opposed to abstract data type sizes, for encoding and decoding Data
Records, it is not expected that this will have any impact on buffer
sizing during encoding and decoding. Otherwise, note that the
security considerations for IPFIX [RFC7011] apply.
6. Acknowledgments
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.
7. References
7.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces", RFC
3540, June 2003.
[RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of
the IP Flow Information Export (IPFIX) Protocol for the
Exchange of Flow Information", STD 77, RFC 7011, September
2013.
[RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and
Reviewers of IP Flow Information Export (IPFIX)
Information Elements", BCP 184, RFC 7013, September 2013.
7.2. Informative References
[IANA-IPFIX]
IANA, "IP Flow Information Export (IPFIX) Entities",
<http://www.iana.org/assignments/ipfix>.
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
Meyer, "Information Model for IP Flow Information Export",
RFC 5102, January 2008.
Authors' Addresses
Brian Trammell
Swiss Federal Institute of Technology Zurich
Gloriastrasse 35
8092 Zurich
Switzerland
Phone: +41 44 632 70 13
EMail: trammell@tik.ee.ethz.ch
Paul Aitken
Cisco Systems, Inc.
96 Commercial Quay
Commercial Street, Edinburgh EH6 6LX
United Kingdom
Phone: +44 131 561 3616
EMail: paitken@cisco.com
AI ELI5
On this page
§1Why the Definition Needed Revising
Octets 12 and 13 of the TCP header hold the data offset (header length) in 4 bits and 12 bits of flags. RFC 793 defined the least significant 6 of these: URG, ACK, PSH, RST, SYN and FIN. RFC 3168 then added CWR and ECE for Explicit Congestion Notification (ECN), and RFC 3540 added NS for the ECN Nonce Sum.
The tcpControlBits Information Element came from RFC 5102 and only covered the original six bits. To let IPFIX measure ECN use and match the current TCP Flags field, it had to change.
Because RFC 5102 is a Proposed Standard, revising the element needs IETF consensus. The new definition was approved through the IE-DOCTORS process in August 2013, and publishing this RFC supplies the consensus.
TCP packets have little flags, like flags on a mailbox. The old form only had space for six of them, but there are more now, so the form needed more room.
§2The Revised Information Element
The element has ElementId 6, data type unsigned16 and data type semantics flags. It reports the TCP control bits seen across the packets of a Flow: a bit is set to 1 if any observed packet of the Flow had that TCP bit set to 1, and cleared to 0 otherwise.
The bit values run from 0x0100 for NS down to 0x0001 for FIN, covering CWR, ECE, URG, ACK, PSH, RST and SYN in between. The three bits 0x0800, 0x0400 and 0x0200 are Future Use, and the top four bits are zero.
The record keeps a row of switches. A switch is turned on if any packet in the conversation had it on.
- 0x8000-0x1000Zero — Overlaps the data offset; see tcpHeaderLength.
- 0x0800-0x0200Future Use — Three bits reserved in RFC 793.
- 0x0100NS — ECN Nonce Sum.
- 0x0080CWR — Congestion Window Reduced.
- 0x0040ECE — ECN Echo.
- 0x0020URG — Urgent Pointer field significant.
- 0x0010ACK — Acknowledgment field significant.
- 0x0008PSH — Push Function.
- 0x0004RST — Reset the connection.
- 0x0002SYN — Synchronize sequence numbers.
- 0x0001FIN — No more data from sender.
§3Zero, Future Use and Reduced-Size Encoding
The most significant 4 bits of the field overlap the TCP data offset. They MUST be exported as zero and MUST be ignored by the collector; the tcpHeaderLength element carries the header length instead. The 3 Future Use bits SHOULD be exported as observed in the TCP headers.
An Exporting Process may use reduced-size encoding, exporting a single octet that covers bits 0x80 to 0x01. That omits the NS bit and the three Future Use bits, and a collector must not assume anything about their content. If the Metering Process cannot observe those bits, the exporter SHOULD use reduced-size encoding.
Some boxes on the form are not used, so they must be left blank. If a counter cannot see some switches, it may send a shorter form with only the switches it can see.
§4Compatibility with Earlier Exports
Earlier revisions of the definition said that the CWR and ECE bits must be exported as zero, even if observed. So collectors should not assume that a zero for these bits means they were never set, especially if they are zero in every Flow Record from a given exporter.
IANA updated the registry entry, setting the revision to 1 and the revision date to the publication date.
Older forms always showed two of the switches as off, even when they were on. So if you see them off on an old form, you cannot be sure.
§5Size Change and Security
The change moves the element from unsigned8 (1 octet) to unsigned16 (2 octets). Because Exporting and Collecting Processes use the Information Element Length field in Templates, Options Templates and reduced-size encoding rather than abstract type sizes, no impact on buffer sizing is expected. Otherwise the security considerations of IPFIX (RFC 7011) apply.
The form got a bit wider, but the readers look at the size written on the form, so nothing breaks.