idnits 2.17.1 draft-ietf-tcpm-experimental-options-03.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 (November 28, 2012) is 4168 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 November 28, 2012 4 Expires: May 2013 6 Shared Use of Experimental TCP Options 7 draft-ietf-tcpm-experimental-options-03.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 May 28, 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 the experimental TCP option codepoints 50 can support concurrent use through the use of a magic number. This 51 mechanism avoids the need for a coordinated registry and is 52 backward-compatible with currently known uses. It is recommended for 53 all new TCP options that use these codepoints. 55 Table of Contents 57 1. Introduction...................................................2 58 2. Conventions used in this document..............................4 59 3. TCP Experimental Option Structure..............................4 60 3.1. Selecting a Magic Number..................................5 61 3.2. Impact on TCP Option Processing...........................5 62 4. Reducing the Impact of False Positives.........................6 63 5. Migration to Assigned Options..................................7 64 6. Security Considerations........................................7 65 7. IANA Considerations............................................7 66 8. References.....................................................8 67 8.1. Normative References......................................8 68 8.2. Informative References....................................8 69 9. Acknowledgments................................................9 71 1. Introduction 73 TCP includes options to enable new protocol capabilities that can be 74 activated only where needed and supported [RFC793]. The space for 75 identifying such options is small - 256 values, of which 30 are 76 assigned at the time this document was published [IANA]. Two of 77 these codepoints are allocated to support experiments (253, 254) 78 [RFC4727]. These values are intended for testing purposes or anytime 79 an assigned codepoint is either not warranted or available, e.g., 80 based on the maturity status of the defined capability (i.e., 81 Experimental or Informational, rather than Standards Track). 83 The term "experimental TCP options" refers here to options that use 84 the experimental TCP option codepoints [RFC4727]. Such experiments 85 can be described in any type of RFC - Experimental, Informational, 86 etc., and are intended to be used both in controlled environments 87 and in are allowed in public deployments (when not enabled as 88 default) [RFC3962]. Nothing prohibits deploying multiple experiments 89 in the same environment - controlled or public. Further, some 90 protocols are specified in Experimental or Informational RFCs, which 91 either include parameters or design choices not yet understood or 92 which might not be widely deployed [RFC2026]. TCP options in such 93 RFCs are typically not eligible for assigned TCP option codepoints 94 [RFC2780], and so there is a need to share use of the experimental 95 option codepoints. 97 There is currently no mechanism to support shared use of the 98 experimental TCP option codepoints. Experimental options 253 and 254 99 are already deployed in operational code to support an early version 100 of TCP authentication. Option 253 is also documented for the 101 experimental TCP Cookie Transaction option [RFC6013]. This shared 102 use results in collisions in which a single codepoint can appear 103 multiple times in a single TCP segment and for which each use is 104 ambiguous. 106 Other codepoints have been used without assignment (known as 107 "squatting"), notably 31-32 (TCP cookie transactions, as originally 108 distributed and in its API doc) and 76-78 (tcpcrypt) [Bi11][Si11]. 109 Commercial products reportedly also use unassigned options 33, 69- 110 70, and 76-78 as well. Even though these uses are unauthorized, they 111 currently impact legitimate assignees. 113 Both such misuses (squatting on both experimental and assigned 114 codepoints) are expected to continue, but there are several 115 approaches which can alleviate the impact on cooperating protocol 116 designers. One proposal relaxes the requirements for assignment of 117 TCP options, allowing them to be assigned more readily for protocols 118 that have not been standardized through the IETF process [RFC5226]. 119 Another proposal assigns a larger pool to options and manages their 120 sharing through IANA coordination [Ed11]. 122 The approach proposed in this document does not require additional 123 codepoints and also avoids IANA involvement. The solution adds a 124 field to the structure of the experimental TCP option. This field is 125 populated with a fixed "magic number" defined as part of a specific 126 option experiment. The magic number helps reduce the probability of 127 a collision of independent experimental uses of the same option 128 codepoint, both for those who follow this document (using other 129 magic numbers) and those who do not (squatters). 131 The solution proposed in this document is recommended for all new 132 protocols that use experimental TCP option codepoints. The 133 techniques used here may also help share other experimental 134 codepoints, but that issue is out of scope for this document. 136 2. Conventions used in this document 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC-2119 [RFC2119]. 142 In this document, these words will appear with that interpretation 143 only when in ALL CAPS. Lower case uses of these words are not to be 144 interpreted as carrying RFC-2119 significance. 146 In this document, the characters ">>" preceding an indented line(s) 147 indicates a compliance requirement statement using the key words 148 listed above. This convention aids reviewers in quickly identifying 149 or finding the explicit compliance requirements of this RFC. 151 3. TCP Experimental Option Structure 153 TCP options have the current common structure [RFC793], in which the 154 first byte is the codepoint (Kind) and the second byte is the length 155 of the option in bytes (Length): 157 0 1 2 3 158 01234567 89012345 67890123 45678901 159 +--------+--------+--------+--------+ 160 | Kind | Length | ... | 161 +--------+--------+--------+--------+ 162 | ... 163 +-------- 165 Figure 1 TCP Option Structure [RFC793] 167 This document extends the option structure for experimental 168 codepoints (253, 254) with a magic number, which is typically 4 169 bytes in length. The magic number is used to differentiate different 170 experiments, and is the first field after the Kind and Length, as 171 follows: 173 0 1 2 3 174 01234567 89012345 67890123 45678901 175 +--------+--------+--------+--------+ 176 | Kind | Length | Magic Number | 177 +--------+--------+--------+--------+ 178 | Magic Number | ... 179 +--------+--------+--------+--- 181 Figure 2 TCP Experimental Option with a Magic Number 183 >> Protocols requiring new TCP option codepoints that are not 184 eligible for assigned values SHOULD use the existing TCP 185 experimental option codepoints (253, 254) with magic numbers as 186 described in this document. 188 >> All protocols using the TCP experimental option codepoints (253, 189 254) SHOULD use magic numbers as described in this document. 191 Magic numbers are used in other protocols, e.g., BOOTP [RFC951] and 192 DHCP [RFC2131]. In the use proposed in this document they help 193 ensure that concurrent experiments that share the same TCP option 194 codepoint do not interfere. 196 3.1. Selecting a Magic Number 198 The magic number is selected by the protocol designer when an 199 experimental option is defined, i.e., when the specification for 200 that option is authored. The magic number is selected any of a 201 variety of ways, e.g., using the Unix time() command or bits 202 selected by an arbitrary function (such as a hash) of an arbitrary 203 string (e.g., the document title). This operation occurs only when 204 the option is specified, and is not implemented as part of the 205 design of an option. 207 This document does not proscribe a minimum magic number size. Larger 208 magic numbers reduce the probability of a collision with other 209 options sharing the Kind codepoint, but also increase the option 210 size. A suggested size is 32 bits, in network standard byte order: 212 >> The magic number size and value SHOULD be selected to reduce the 213 probability of collision. 215 >> The magic number SHOULD be 32 bits, but MAY be either longer or 216 shorter. 218 3.2. Impact on TCP Option Processing 220 The magic number is considered part of the TCP option, not the TCP 221 option header. The presence of the magic number increases the 222 effective option Length field by the size of the magic number. The 223 presence of this magic number is thus transparent to implementations 224 that do not support TCP options where it is used. 226 During TCP processing, experimental options are matched against both 227 the experimental codepoints and the magic number value for each 228 implemented protocol. 230 >> Experimental options that have magic numbers that do not match 231 implemented protocols MUST be ignored. 233 The remainder of the option is specified by the particular 234 experimental protocol. This includes the possibility that the magic 235 number could appear in only a subset of instances of the option. 236 Because TCP option capabilities are negotiated during connection 237 establishment, the magic number might be omitted afterwards (e.g., 238 in non-SYN segments). 240 >> TCP experimental option magic numbers, if used in any TCP segment 241 of a connection, MUST be present in TCP SYN segments of that 242 connection. 244 The specification of an experimental option needs to describe 245 whether the magic number appears in non-SYN segments. If the magic 246 number does not appear in all segments, the experimental option may 247 need to be rejected during connection negotiation because options 248 for different experiments in non-SYN segments may not be 249 distinguishable. As a result, this document recommends that: 251 >> TCP experimental option magic numbers, if used in any TCP segment 252 of a connection, SHOULD be used in all TCP segments of that 253 connection in which any experimental option is present. 255 Use of a magic number uses additional space in the TCP header and 256 requires additional protocol processing by experimental protocols. 257 Because these are experiments, neither consideration is a 258 substantial impediment; a finalized protocol can avoid both issues 259 with the assignment of a dedicated option codepoint later. 261 4. Reducing the Impact of False Positives 263 False positives occur where the magic number of one experiment 264 matches the value of an option that does not use magic numbers or if 265 two experiments select the same magic number. Such collisions can 266 cause an option to be interpreted by the incorrect processing 267 routine. 269 >> Experiments that are not robust to magic number false positives 270 SHOULD implement other detection measures, such as checksums or 271 digital signatures. 273 Use of checksums or signatures may help an experiment use a shorter 274 magic number while reducing the corresponding increased potential 275 for false positives. However this document recommends magic numbers 276 are used together with such checksums/signatures, not as a 277 substitute thereof. Magic numbers are static and thus more easily 278 identify the experiment using the experimental option; they can also 279 be more efficiently interpreted at the TCP receiver. 281 5. Migration to Assigned Options 283 Some experiments may transition from experiment, and become eligible 284 for an assigned TCP option codepoint. This document does not 285 recommend a specific migration plan to transition from use of the 286 experimental TCP options/magic numbers to use of an assigned 287 codepoint. 289 However, once an assigned codepoint is allocated, use of a magic 290 number represents unnecessary overhead. As a result: 292 >> Once a TCP option codepoint is assigned to a protocol, that 293 protocol SHOULD NOT continue to use a magic number as part of that 294 assigned codepoint. 296 This document does not recommend whether or how an implementation of 297 an assigned codepoint should be backward-compatible with use of the 298 experimental codepoint/magic number. 300 However, some implementers may be tempted to include both the 301 experimental and assigned codepoint in the same segment, e.g., in a 302 SYN to support backward-compatibility during connection 303 establishment. This is a poor use limited resources and so to ensure 304 conservation of the TCP option space: 306 >> A TCP segment MUST NOT contain both an assigned TCP option 307 codepoint and an experimental TCP option codepoint/magic number for 308 the same protocol. 310 Instead, a TCP that intends backward compatibility might send 311 multiple SYNs with alternates of the same option and discard all but 312 the most desired successful connection. 314 6. Security Considerations 316 The mechanism described in this document is not intended to provide 317 (nor does it weaken existing) security for TCP option processing. 319 7. IANA Considerations 321 This document has no IANA considerations. This section should be 322 removed prior to publication. 324 8. References 326 8.1. Normative References 328 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 329 793, Sep. 1981. 331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 332 Requirement Levels", BCP 14, RFC 2119, March 1997. 334 [RFC4727] Fenner, B., "Experimental Values in IPv4, IPv6, ICMPv4, 335 ICMPv6, UDP, and TCP Headers", RFC 4727, Nov. 2006. 337 8.2. Informative References 339 [Bi11] Bittau, A., D. Boneh, M. Hamburg, M. Handley, D. Mazieres, 340 Q. Slack, "Cryptographic protection of TCP Streams 341 (tcpcrypt)", work in progress, draft-bittau-tcp-crypt-03, 342 Sep. 3, 2012. 344 [Ed11] Eddy, W., "Additional TCP Experimental-Use Options", work 345 in progress, draft-eddy-tcpm-addl-exp-options-00, Aug. 16, 346 2011. 348 [IANA] IANA web pages, http://www.iana.org/ 350 [RFC951] Croft, B., J. Gilmore, "BOOTSTRAP PROTOCOL (BOOTP)", RFC 351 951, Sept. 1985. 353 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 354 3", BCP 9, RFC 2026, Oct. 1996. 356 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 357 2131, Mar. 1997. 359 [RFC2780] Bradner, S., V. Paxson, "IANA Allocation Guidelines For 360 Values In the Internet Protocol and Related Headers", BCP 361 37, RFC 2780, Mar. 2000. 363 [RFC3962] Narten, T., "Assigning Experimental and Testing Numbers 364 Considered Useful", BCP 82, RFC 3962, Jan. 2004. 366 [RFC5226] Narten, T., H. Alvestrand, "Guidelines for Writing an IANA 367 Considerations Section in RFCs", BCP 26, RFC 5226, May 368 2008. 370 [RFC6013] Simpson, W., "TCP Cookie Transactions (TCPCT)", RFC 6013, 371 Jan. 2011. 373 [Si11] Simpson, W., "TCP Cookie Transactions (TCPCT) Sockets 374 Application Program Interface (API)", work in progress, 375 draft-simpson-tcpct-api-04, Apr. 7, 2011. 377 9. Acknowledgments 379 This document was motivated by discussions on the IETF TCPM mailing 380 list and by Wes Eddy's proposal [Ed11]. Yoshifumi Nishida, Pasi 381 Sarolathi, and Michael Scharf provided detailed feedback. 383 This document was prepared using 2-Word-v2.0.template.dot. 385 Authors' Addresses 387 Joe Touch 388 USC/ISI 389 4676 Admiralty Way 390 Marina del Rey, CA 90292-6695 U.S.A. 392 Phone: +1 (310) 448-9151 393 Email: touch@isi.edu