idnits 2.17.1 draft-ietf-tcpm-experimental-options-00.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 (January 17, 2012) is 4483 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-01 -- 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 January 17, 2012 4 Expires: July 2012 6 Shared Use of Experimental TCP Options 7 draft-ietf-tcpm-experimental-options-00.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 July 17, 2012. 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. The suggested mechanism avoids the need for 51 a coordinated registry, and is backward-compatible with currently 52 known uses. 54 Table of Contents 56 1. Introduction...................................................2 57 2. Conventions used in this document..............................3 58 3. TCP Experimental Option Structure..............................3 59 4. Security Considerations........................................5 60 5. IANA Considerations............................................5 61 6. References.....................................................5 62 6.1. Normative References......................................5 63 6.2. Informative References....................................6 64 7. Acknowledgments................................................6 66 1. Introduction 68 TCP includes options to enable new protocol capabilities that can be 69 activated only where needed and supported [RFC793]. The space for 70 identifying such options is small - 256 values, of which 31 are 71 assigned at the time this document was published [IANA]. Two of 72 these codepoints are allocated to support experiments (253, 254) 73 [RFC4727]. These numbers are intended for testing purposes, and 74 implementations need to assume they can be used for other purposes, 75 but this is often not the case. 77 There is no mechanism to support shared use of the experimental 78 option codepoints. Experimental options 245 and 255 are deployed in 79 operational code to support an early version of TCP authentication. 80 Option 253 is also documented for the experimental TCP Cookie 81 Transaction option [RFC6013]. This shared use results in collisions 82 in which a single codepoint can appear multiple times in a single 83 TCP segment and each use is ambiguous. 85 Other options have been used without assignment, notably 31-32 (TCP 86 cookie transactions, as originally distributed and in its API doc) 87 and 76-78 (tcpcrypt) [Bi11][Si11]. Commercial products reportedly 88 also use unassigned options 33 and 76-78 as well. 90 There are a variety of proposed approaches to address this issue. 91 The first is to relax the requirements for assignment of TCP 92 options, allowing them to be assigned more readily for protocols 93 that have not been standardized through the IETF process [RFC5226]. 94 A second would be to assign a larger pool to options, and to manage 95 their sharing through IANA coordination [Ed11]. 97 This document proposes a solution that does not require additional 98 codepoints and also avoids IANA participation. A short magic number 99 is added to the structure of the experimental TCP option structure. 100 The magic number helps reduce the probability of collision of 101 independent experimental uses of the same option codepoint. This 102 feature increases the size of experimental options, but the size can 103 be reduced when the experiment is converted to a standard protocol 104 with a conventional codepoint assignment. 106 2. Conventions used in this document 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC-2119 [RFC2119]. 112 In this document, these words will appear with that interpretation 113 only when in ALL CAPS. Lower case uses of these words are not to be 114 interpreted as carrying RFC-2119 significance. 116 In this document, the characters ">>" preceding an indented line(s) 117 indicates a compliance requirement statement using the key words 118 listed above. This convention aids reviewers in quickly identifying 119 or finding the explicit compliance requirements of this RFC. 121 3. TCP Experimental Option Structure 123 TCP options have the current common structure, where the first byte 124 is the codepoint (Kind) and the second is the length of the option 125 in bytes (Length): 127 +--------+--------+--------+--------+ 128 | Kind | Length | ... | 129 +--------+--------+--------+--------+ 130 | ... 131 +-------- 133 Figure 1 TCP Option Structure [RFC793] 135 This document extends the option structure for experimental 136 codepoints (253, 254) with a magic number. The magic number is used 137 to differentiate different experiments, and is the first field after 138 the Kind and Length, as follows: 140 +--------+--------+--------+--------+ 141 | Kind | Length | Magic Number | 142 +--------+--------+--------+--------+ 143 | Magic Number | ... 144 +--------+--------+--------+--- 146 Figure 2 TCP Experimental Option with a Magic Number 148 >> Protocols using the TCP experimental option codepoints (253, 254) 149 SHOULD use magic numbers as described in this document. 151 Magic numbers are used in other protocols, e.g., BOOTP [RFC951] and 152 DHCP [RFC2131]. Here they help ensure that concurrent experiments 153 that share the same TCP option codepoint do not interfere. 155 The magic number is selected by the protocol designer when an 156 experimental option is defined. The magic number is selected any of 157 a variety of ways, e.g., using the Unix time() command or bits 158 selected by an arbitrary function (such as a hash). 160 >> The magic number value SHOULD be selected to reduce the 161 probability of collision. 163 The length of the magic number is a 32 bit value in network standard 164 byte order. It can be shorter if desired (e.g., 16 bits), with a 165 corresponding increased probability of collision and thus false 166 positives. 168 >> The magic number SHOULD be 32 bits long; it MAY be as few as 16 169 bits if desired. 171 The magic number is considered part of the TCP option, not the TCP 172 option header. The presence of the magic number increases the 173 effective option Length field by the size of the magic number. The 174 presence of this magic number is thus transparent to implementations 175 that do not support TCP options where it is used. 177 During TCP processing, experimental options are matched against both 178 the experimental codepoints and the magic number value for each 179 implemented protocol. 181 >> Experimental options that have magic numbers that do not match 182 implemented protocols MUST be ignored. 184 The remainder of the option is specified by the particular 185 experimental protocol. 187 Use of a magic number uses additional space in the TCP header and 188 requires additional protocol processing by experimental protocols. 189 Because these are experiments, neither consideration is a 190 substantial impediment; a finalized protocol can avoid both issues 191 with the assignment of a dedicated option codepoint later. 193 This document does not address a specific migration plan to avoid 194 the use of magic numbers once an experimental TCP option is 195 considered for operational deployment, e.g., if it transitions to 196 proposed standard. The expectation is that such options would be 197 assigned their own TCP codepoints and their specifications updated 198 to avoid the need to support the experimental codepoint 200 4. Security Considerations 202 The mechanism described in this document is not intended to provide 203 security for TCP option processing. False positives are always 204 possible, where a magic number matches the value of a field in the 205 legacy use of these options or a protocol that does not implement 206 the mechanism described in this document. 208 >> Protocols that are not robust to such false positives SHOULD 209 implement other measures to ensure they process options for their 210 protocol only, such as checksums or digital signatures among 211 cooperating parties of their protocol. 213 5. IANA Considerations 215 This document has no IANA considerations. This section should be 216 removed prior to publication. 218 6. References 220 6.1. Normative References 222 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 223 793, Sep. 1981. 225 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 226 Requirement Levels", BCP 14, RFC 2119, March 1997. 228 [RFC4727] Fenner, B., "Experimental Values in IPv4, IPv6, ICMPv4, 229 ICMPv6, UDP, and TCP Headers", RFC 4727, Nov. 2006. 231 6.2. Informative References 233 [Bi11] Bittau, A., D. Boneh, M. Hamburg, M. Handley, D. Mazieres, 234 Q. Slack, "Cryptographic protection of TCP Streams 235 (tcpcrypt)", work in progress, draft-bittau-tcp-crypt-01, 236 Aug. 29, 2011. 238 [Ed11] Eddy, W., "Additional TCP Experimental-Use Options", work 239 in progress, draft-eddy-tcpm-addl-exp-options-00, Aug. 16, 240 2011. 242 [IANA] IANA web pages, http://www.iana.org/ 244 [RFC951] Croft, B., J. Gilmore, "BOOTSTRAP PROTOCOL (BOOTP)", RFC 245 951, Sept. 1985. 247 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 248 2131, Mar. 1997. 250 [RFC5226] Narten, T., H. Alvestrand, "Guidelines for Writing an IANA 251 Considerations Section in RFCs", BCP 26, RFC 5226, May 252 2008. 254 [RFC6013] Simpson, W., "TCP Cookie Transactions (TCPCT)", RFC 6013, 255 Jan. 2011. 257 [Si11] Simpson, W., "TCP Cookie Transactions (TCPCT) Sockets 258 Application Program Interface (API)", work in progress, 259 draft-simpson-tcpct-api-04, Apr. 7, 2011. 261 7. Acknowledgments 263 This document was motivated by discussions on the IETF TCPM mailing 264 list and by Wes Eddy's proposal [Ed11]. 266 This document was prepared using 2-Word-v2.0.template.dot. 268 Authors' Addresses 270 Joe Touch 271 USC/ISI 272 4676 Admiralty Way 273 Marina del Rey, CA 90292-6695 U.S.A. 275 Phone: +1 (310) 448-9151 276 Email: touch@isi.edu