idnits 2.17.1 draft-ietf-tcpm-experimental-options-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 5, 2012) is 4220 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-04) exists of draft-bittau-tcp-crypt-03 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 6013 (Obsoleted by RFC 7805) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TCPM Working Group J. Touch 2 Internet Draft USC/ISI 3 Intended status: Proposed Standard October 5, 2012 4 Expires: April 2013 6 Shared Use of Experimental TCP Options 7 draft-ietf-tcpm-experimental-options-02.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on April 5, 2013. 32 Copyright Notice 34 Copyright (c) 2012 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with 42 respect to this document. Code Components extracted from this 43 document must include Simplified BSD License text as described in 44 Section 4.e of the Trust Legal Provisions and are provided without 45 warranty as described in the Simplified BSD License. 47 Abstract 49 This document describes how TCP option codepoints can support 50 concurrent experiments using a magic number field. This mechanism 51 avoids the need for a coordinated registry, and is backward- 52 compatible with currently known uses. It is recommended for all new 53 experimental RFCs that require TCP option codepoints. 55 Table of Contents 57 1. Introduction...................................................2 58 2. Conventions used in this document..............................3 59 3. TCP Experimental Option Structure..............................4 60 3.1. Reducing the Impact of False Positives....................6 61 3.2. Migration to Assigned Options.............................6 62 4. Security Considerations........................................7 63 5. IANA Considerations............................................7 64 6. References.....................................................7 65 6.1. Normative References......................................7 66 6.2. Informative References....................................7 67 7. Acknowledgments................................................8 69 1. Introduction 71 TCP includes options to enable new protocol capabilities that can be 72 activated only where needed and supported [RFC793]. The space for 73 identifying such options is small - 256 values, of which 30 are 74 assigned at the time this document was published [IANA]. Two of 75 these codepoints are allocated to support experiments (253, 254) 76 [RFC4727]. These numbers are intended for testing purposes, and 77 implementations need to assume they can be used for other purposes, 78 but this is often not the case. 80 There is no mechanism to support shared use of the experimental 81 option codepoints. Experimental options 253 and 254 are deployed in 82 operational code to support an early version of TCP authentication. 83 Option 253 is also documented for the experimental TCP Cookie 84 Transaction option [RFC6013]. This shared use results in collisions 85 in which a single codepoint can appear multiple times in a single 86 TCP segment and each use is ambiguous. 88 Other codepoints have been used without assignment, notably 31-32 89 (TCP cookie transactions, as originally distributed and in its API 90 doc) and 76-78 (tcpcrypt) [Bi11][Si11]. Commercial products 91 reportedly also use unassigned options 33, 69-70, and 76-78 as well. 92 Even though these uses are unauthorized, they can impact legitimate 93 assignees. 95 There are a variety of proposed approaches to address this issue. 96 The first is to relax the requirements for assignment of TCP 97 options, allowing them to be assigned more readily for protocols 98 that have not been standardized through the IETF process [RFC5226]. 99 A second would be to assign a larger pool to options, and to manage 100 their sharing through IANA coordination [Ed11]. 102 This document proposes a solution that does not require additional 103 codepoints and also avoids IANA involvement. The solution involves 104 adding a field to the structure of the experimental TCP option. This 105 field is typically populated with a fixed "magic number" defined as 106 part of a specific option experiment. The magic number helps reduce 107 the probability of a collision of independent experimental uses of 108 the same option codepoint. This feature increases the number of 109 bytes used by experimental options, but the size can be reduced when 110 the experiment is converted to a standard protocol with a 111 conventional codepoint assignment. 113 The solution proposed in this document is recommended for all new 114 experimental protocols that require TCP option codpoints. This 115 document also contains suggestions for the transition from this 116 proposed mechanism to conventionally assigned codepoints, e.g., upon 117 transition of an experimental protocol to more standards-track use. 119 2. Conventions used in this document 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC-2119 [RFC2119]. 125 In this document, these words will appear with that interpretation 126 only when in ALL CAPS. Lower case uses of these words are not to be 127 interpreted as carrying RFC-2119 significance. 129 In this document, the characters ">>" preceding an indented line(s) 130 indicates a compliance requirement statement using the key words 131 listed above. This convention aids reviewers in quickly identifying 132 or finding the explicit compliance requirements of this RFC. 134 3. TCP Experimental Option Structure 136 TCP options have the current common structure, where the first byte 137 is the codepoint (Kind) and the second is the length of the option 138 in bytes (Length): 140 +--------+--------+--------+--------+ 141 | Kind | Length | ... | 142 +--------+--------+--------+--------+ 143 | ... 144 +-------- 146 Figure 1 TCP Option Structure [RFC793] 148 This document extends the option structure for experimental 149 codepoints (253, 254) with a magic number. The magic number is used 150 to differentiate different experiments, and is the first field after 151 the Kind and Length, as follows: 153 +--------+--------+--------+--------+ 154 | Kind | Length | Magic Number | 155 +--------+--------+--------+--------+ 156 | Magic Number | ... 157 +--------+--------+--------+--- 159 Figure 2 TCP Experimental Option with a Magic Number 161 >> Protocols defined in experimental RFCs or their precursor 162 Internet Drafts (expecting experimental RFC publication) requiring 163 new TCP option codepoints SHOULD use the existing TCP experimental 164 option codepoints (253, 254) with magic numbers as described in this 165 document. 167 >> All protocols using the TCP experimental option codepoints (253, 168 254) SHOULD use magic numbers as described in this document. 170 Magic numbers are used in other protocols, e.g., BOOTP [RFC951] and 171 DHCP [RFC2131]. Here they help ensure that concurrent experiments 172 that share the same TCP option codepoint do not interfere. 174 The magic number is selected by the protocol designer when an 175 experimental option is defined. The magic number is selected any of 176 a variety of ways, e.g., using the Unix time() command or bits 177 selected by an arbitrary function (such as a hash). 179 >> The magic number size and value SHOULD be selected to reduce the 180 probability of collision. 182 This document does not proscribe a minimum magic number size. 183 However, a reasonable suggested size is 32 bits, in network standard 184 byte order: 186 >> The magic number SHOULD be 32 bits, but MAY be either longer or 187 shorter. 189 The magic number is considered part of the TCP option, not the TCP 190 option header. The presence of the magic number increases the 191 effective option Length field by the size of the magic number. The 192 presence of this magic number is thus transparent to implementations 193 that do not support TCP options where it is used. 195 During TCP processing, experimental options are matched against both 196 the experimental codepoints and the magic number value for each 197 implemented protocol. 199 >> Experimental options that have magic numbers that do not match 200 implemented protocols MUST be ignored. 202 The remainder of the option is specified by the particular 203 experimental protocol. This includes the possibility that the magic 204 number could appear in only a subset of instances of the option. 205 Because TCP option capabilities are negotiated during connection 206 establishment, the magic number might be omitted afterwards (e.g., 207 in non-SYN segments). 209 >> TCP experimental option magic numbers, if used in any TCP segment 210 of a connection, MUST be present in TCP SYN segments of that 211 connection. 213 The specification of an experimental option needs to describe 214 whether the magic number appears in non-SYN segments. If the magic 215 number does not appear in all segments, the experimental option may 216 need to be rejected during connection negotiation because options 217 for different experiments in non-SYN segments may not be 218 distinguishable. As a result, this document recommends that: 220 >> TCP experimental option magic numbers, if used in any TCP segment 221 of a connection, SHOULD be used in all TCP segments of that 222 connection in which any experimental option is present. 224 Use of a magic number uses additional space in the TCP header and 225 requires additional protocol processing by experimental protocols. 226 Because these are experiments, neither consideration is a 227 substantial impediment; a finalized protocol can avoid both issues 228 with the assignment of a dedicated option codepoint later. 230 3.1. Reducing the Impact of False Positives 232 False positives are always possible, where a magic number matches 233 the value of a field in the legacy use of these options or a 234 protocol that does not implement the mechanism described in this 235 document. 237 >> Protocols that are not robust to magic number false positives 238 SHOULD implement other measures to ensure they process options for 239 their protocol only, such as checksums or digital signatures among 240 cooperating parties of their protocol. Such measures SHOULD 241 supplement, rather than substitute for, the use of magic numbers. 243 Use of checksums or signatures may help an experiment use a shorter 244 magic number while reducing the corresponding increased potential 245 for false positives. However this document recommends magic numbers 246 are used together with such checksums/signatures, not as a 247 substitute thereof. Magic numbers are static and thus more easily 248 identify the experiment using the experimental option; they can also 249 be more efficiently interpreted at the TCP receiver. 251 3.2. Migration to Assigned Options 253 This document does not require a specific migration plan to avoid 254 the use of magic numbers once a protocol using a experimental TCP 255 option codepoint is considered for operational deployment, e.g., if 256 it transitions to proposed standard. 258 The expectation is that such options would be assigned their own TCP 259 codepoints and their specifications updated to avoid the need to 260 support the experimental codepoint. Use of a magic number represents 261 unnecessary overhead in an assigned TCP codepoint. As a result: 263 >> Once a specific TCP option codepoint is assigned to a protocol, 264 that protocol SHOULD NOT continue to use a magic number as part of 265 that assigned codepoint. 267 >> The updated protocol specification SHOULD recommend that 268 implementations intended to be backward-compatible with experimental 269 deployments MUST support both the experimental codepoint/magic 270 number and assigned codepoint variants of the option. 272 Discontinuing support for the experimental codepoint/magic number 273 variant saves only a small amount of code. 275 >> Support for the experimental codepoint/magic number variant 276 SHOULD be discontinued for implementations where the protocol has 277 been revised in a non-backward-compatible way. 279 4. Security Considerations 281 The mechanism described in this document is not intended to provide 282 security for TCP option processing. 284 5. IANA Considerations 286 This document has no IANA considerations. This section should be 287 removed prior to publication. 289 6. References 291 6.1. Normative References 293 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 294 793, Sep. 1981. 296 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 297 Requirement Levels", BCP 14, RFC 2119, March 1997. 299 [RFC4727] Fenner, B., "Experimental Values in IPv4, IPv6, ICMPv4, 300 ICMPv6, UDP, and TCP Headers", RFC 4727, Nov. 2006. 302 6.2. Informative References 304 [Bi11] Bittau, A., D. Boneh, M. Hamburg, M. Handley, D. Mazieres, 305 Q. Slack, "Cryptographic protection of TCP Streams 306 (tcpcrypt)", work in progress, draft-bittau-tcp-crypt-03, 307 Sep. 3, 2012. 309 [Ed11] Eddy, W., "Additional TCP Experimental-Use Options", work 310 in progress, draft-eddy-tcpm-addl-exp-options-00, Aug. 16, 311 2011. 313 [IANA] IANA web pages, http://www.iana.org/ 315 [RFC951] Croft, B., J. Gilmore, "BOOTSTRAP PROTOCOL (BOOTP)", RFC 316 951, Sept. 1985. 318 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 319 2131, Mar. 1997. 321 [RFC5226] Narten, T., H. Alvestrand, "Guidelines for Writing an IANA 322 Considerations Section in RFCs", BCP 26, RFC 5226, May 323 2008. 325 [RFC6013] Simpson, W., "TCP Cookie Transactions (TCPCT)", RFC 6013, 326 Jan. 2011. 328 [Si11] Simpson, W., "TCP Cookie Transactions (TCPCT) Sockets 329 Application Program Interface (API)", work in progress, 330 draft-simpson-tcpct-api-04, Apr. 7, 2011. 332 7. Acknowledgments 334 This document was motivated by discussions on the IETF TCPM mailing 335 list and by Wes Eddy's proposal [Ed11]. Yoshifumi Nishida, Pasi 336 Sarolathi, and Michael Scharf provided detailed feedback. 338 This document was prepared using 2-Word-v2.0.template.dot. 340 Authors' Addresses 342 Joe Touch 343 USC/ISI 344 4676 Admiralty Way 345 Marina del Rey, CA 90292-6695 U.S.A. 347 Phone: +1 (310) 448-9151 348 Email: touch@isi.edu