idnits 2.17.1 draft-trammell-ipfix-tcpcontrolbits-revision-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The abstract seems to contain references ([RFC5102], [RFC0793]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 111 has weird spacing: '... bit flag...' == Line 112 has weird spacing: '... value name ...' -- The document date (December 4, 2013) is 3793 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 5102 (Obsoleted by RFC 7012) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPFIX Working Group B. Trammell 3 Internet-Draft ETH Zurich 4 Intended status: Informational P. Aitken 5 Expires: June 7, 2014 Cisco Systems, Inc 6 December 4, 2013 8 Revision of the tcpControlBits IPFIX Information Element 9 draft-trammell-ipfix-tcpcontrolbits-revision-05.txt 11 Abstract 13 This document revises the tcpControlBits IPFIX Information Element as 14 originally defined in [RFC5102] to reflect changes to the TCP Flags 15 header field since [RFC0793]. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 7, 2014. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 Octets 12 and 13 (counting from zero) of the TCP header encode the 52 data offset (header length) in four bits, as well as 12 bits of 53 flags. The least significant 6 bits of these were defined in 54 [RFC0793] as URG, ACK, PSH, RST, SYN, and FIN for TCP control. 55 Subsequently, [RFC3168] defined the CWR and ECE flags for Explicit 56 Congestion Notification (ECN) negotiation and signaling; [RFC3540] 57 additionally defined the NS flag for the ECN Nonce Sum. 59 As defined in the IANA IPFIX Information Element Registry 60 [IANA-IPFIX], taken from [RFC5102], the tcpControlBits Information 61 Element for IPFIX [RFC7011] only covers the original six bits from 62 [RFC0793]. To allow IPFIX to be used to measure the use of ECN, and 63 to bring the IPFIX Information Element definition in line with the 64 current definition of the TCP Flags header field, it is necessary to 65 revise this definition. 67 The revised definition of the Information Element in Section 3 was 68 developed and approved through the IE-DOCTORS process [RFC7013] in 69 August 2013. Section 5.1 of [RFC7013] states "This process should 70 not in any way be construed as allowing the IE-DOCTORS to overrule 71 IETF consensus. Specifically, Information Elements in the IANA 72 Information Element registry which were added with IETF consensus 73 require IETF consensus for revision or deprecation". Since the 74 tcpControlBits Information Element was orignally defined in 75 [RFC5102], an IETF Proposed Standard, any revision of this 76 Information Element definition requires IETF Consensus. The 77 publication of this document fulfills that requirement. 79 The following section defines the revised tcpControlBits Information 80 Element as in Section 9.1 of [RFC7013]. 82 2. Terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 86 "OPTIONAL" in this document are to be interpreted as described in 87 [RFC2119]. 89 3. The tcpControlBits Information Element 91 ElementId: 6 92 Data Type: unsigned16 93 Data Type Semantics: flags 94 Description: TCP control bits observed for the packets of this 95 Flow. This information is encoded as a bit field; for each TCP 96 control bit, there is a bit in this set. The bit is set to 1 if 97 any observed packet of this Flow has the corresponding TCP control 98 bit set to 1. The bit is cleared to 0 otherwise. 100 The values of each bit are shown below, per the definition of the 101 bits in the TCP header [RFC0793][RFC3168][RFC3540]: 103 MSb LSb 104 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 105 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 106 | | | N | C | E | U | A | P | R | S | F | 107 | Zero | Future | S | W | C | R | C | S | S | Y | I | 108 | (Data Offset) | Use | | R | E | G | K | H | T | N | N | 109 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 111 bit flag 112 value name description 113 ------+-----+------------------------------------- 114 0x8000 Zero (see tcpHeaderLength) 115 0x4000 Zero (see tcpHeaderLength) 116 0x2000 Zero (see tcpHeaderLength) 117 0x1000 Zero (see tcpHeaderLength) 118 0x0800 Future Use 119 0x0400 Future Use 120 0x0200 Future Use 121 0x0100 NS ECN Nonce Sum 122 0x0080 CWR Congestion Window Reduced 123 0x0040 ECE ECN Echo 124 0x0020 URG Urgent Pointer field significant 125 0x0010 ACK Acknowledgment field significant 126 0x0008 PSH Push Function 127 0x0004 RST Reset the connection 128 0x0002 SYN Synchronize sequence numbers 129 0x0001 FIN No more data from sender 131 As the most significant four bits of octets 12 and 13 (counting 132 from zero) of the TCP header [RFC0793] are used to encode the TCP 133 data offset (header length), the corresponding bits in this 134 Information Element MUST be exported as zero and MUST be ignored 135 by the collector; use the tcpHeaderLength Information Element to 136 encode this value. 138 Each of the three bits (0x800, 0x400, and 0x200) which are 139 reserved for future use in [RFC0793] SHOULD be exported as 140 observed in the TCP headers of the packets of this Flow. 142 If exported as a single octet with reduced size encoding, this 143 Information Element covers the low-order octet of this field (i.e, 144 bits 0x80 to 0x01), omitting the ECN Nonce Sum and the three 145 Future Use bits. A collector receiving this Information Element 146 with reduced size encoding must not assume anything about the 147 content of these four bits. 149 Exporting Processes exporting this Information Element on behalf 150 of a Metering Process that is not capable of observing any of the 151 ECN Nonce Sum or Future Use bits SHOULD use reduced size encoding, 152 and only export the least significant 8 bits of this Information 153 Element. 155 Note that previous revisions of this Information Element's 156 definition specified that the CWR and ECE bits must be exported as 157 zero, even if observed. Collectors should therefore not assume 158 that a value of zero for these bits in this Information Element 159 indicates the bits were never set in the observed traffic, 160 especially if these bits are zero in every Flow Record sent by a 161 given exporter. 162 References: [RFC0793][RFC3168][RFC3540] 163 Revision: 1 165 4. IANA Considerations 167 IANA has updated the definition of the tcpControlBits Information 168 Element in the the IANA IPFIX Information Element Registry 169 [IANA-IPFIX] to reflect the changes in Section 3 above, setting the 170 revision to 1 as noted, and the revision date to the date of 171 publication of this document. 173 5. Security and Privacy Considerations 175 This document changes the data type (and therefore the native size) 176 of the tcpControlBits Information Element, from unsigned8 (1 octet) 177 to unsigned16 (2 octets). As Exporting and Collecting Processes use 178 the Information Element Length field in Templates and Options 179 Templates and specifications for reduced size encoding where 180 appropriate, as opposed to abstract data type sizes, for encoding and 181 decoding Data Records, it is not expected that this will have any 182 impact on buffer sizing during encoding and decoding. Otherwise, 183 note that the security considerations for IPFIX [RFC7011] apply. 185 6. Acknowledgments 187 Thanks to Andrew Feren, Lothar Braun, Michael Scharf, and Simon 188 Josefsson for comments on the revised definition. This work is 189 partially supported by the European Commission under grant agreement 190 FP7-ICT-318627 mPlane; this does not imply endorsement by the 191 Commission. 193 7. References 195 7.1. Normative References 197 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 198 793, September 1981. 200 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 201 Requirement Levels", BCP 14, RFC 2119, March 1997. 203 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 204 of Explicit Congestion Notification (ECN) to IP", RFC 205 3168, September 2001. 207 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 208 Congestion Notification (ECN) Signaling with Nonces", RFC 209 3540, June 2003. 211 [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of 212 the IP Flow Information Export (IPFIX) Protocol for the 213 Exchange of Flow Information", STD 77, RFC 7011, September 214 2013. 216 [RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and 217 Reviewers of IP Flow Information Export (IPFIX) 218 Information Elements", BCP 184, RFC 7013, September 2013. 220 7.2. Informative References 222 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 223 Meyer, "Information Model for IP Flow Information Export", 224 RFC 5102, January 2008. 226 [IANA-IPFIX] 227 Internet Assigned Numbers Authority, , "IP Flow 228 Information Export Information Elements 229 (http://www.iana.org/assignments/ipfix)", . 231 Authors' Addresses 233 Brian Trammell 234 Swiss Federal Institute of Technology Zurich 235 Gloriastrasse 35 236 8092 Zurich 237 Switzerland 239 Phone: +41 44 632 70 13 240 Email: trammell@tik.ee.ethz.ch 241 Paul Aitken 242 Cisco Systems, Inc. 243 96 Commercial Quay 244 Commercial Street, Edinburgh EH6 6LX 245 United Kingdom 247 Phone: +44 131 561 3616 248 Email: paitken@cisco.com