From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6994.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc6994.txt (limited to 'doc/rfc/rfc6994.txt') diff --git a/doc/rfc/rfc6994.txt b/doc/rfc/rfc6994.txt new file mode 100644 index 0000000..b145880 --- /dev/null +++ b/doc/rfc/rfc6994.txt @@ -0,0 +1,619 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Touch +Request for Comments: 6994 USC/ISI +Category: Standards Track August 2013 +ISSN: 2070-1721 + + + Shared Use of Experimental TCP Options + +Abstract + + This document describes how the experimental TCP option codepoints + can concurrently support multiple TCP extensions, even within the + same connection, using a new IANA TCP experiment identifier. This + approach is robust to experiments that are not registered and to + those that do not use this sharing mechanism. It is recommended for + all new TCP options that use these codepoints. + +Status of This Memo + + This is an Internet Standards Track document. + + 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). Further information on + Internet Standards is available in 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/rfc6994. + +Copyright Notice + + Copyright (c) 2013 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. + + + + + + +Touch Standards Track [Page 1] + +RFC 6994 Shared Use of Experimental TCP Options August 2013 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Conventions Used in This Document ...............................3 + 3. TCP Experimental Option Structure ...............................4 + 3.1. Selecting an ExID ..........................................5 + 3.2. Impact on TCP Option Processing ............................6 + 4. Reducing the Impact of False Positives ..........................7 + 5. Migration to Assigned Options ...................................7 + 6. Rationale .......................................................8 + 7. Security Considerations .........................................9 + 8. IANA Considerations .............................................9 + 9. References .....................................................10 + 9.1. Normative References ......................................10 + 9.2. Informative References ....................................10 + 10. Acknowledgments ...............................................11 + +1. Introduction + + TCP includes options to enable new protocol capabilities that can be + activated only where needed and supported [RFC793]. The space for + identifying such options is small -- 256 values, of which 30 are + assigned at the time of this document's publication [IANA]. Two of + these codepoints (253, 254) are allocated to support experiments + [RFC4727]. These values are intended for testing purposes or for use + when an assigned codepoint is either not warranted or available, + e.g., based on the maturity status of the defined capability (i.e., + Experimental or Informational, rather than Standards Track). + + Here, the term "experimental TCP options" refers to options that use + the TCP experimental option codepoints [RFC4727]. Such experiments + can be described in an RFC of any status (e.g., Experimental, + Informational, etc.) and are intended to be used in controlled + environments and are allowed in public deployments (when not enabled + as default [RFC3692]). Nothing prohibits the deployment of multiple + experiments in the same environment -- controlled or public. + Further, some protocols are specified in Experimental or + Informational RFCs, which either include parameters or design choices + not yet understood or which might not be widely deployed [RFC2026]. + Typically, these TCP options are not eligible to receive assigned + codepoints [RFC2780], so they need a way to share their use of the + experimental codepoints. + + There is currently no mechanism to support shared use of the TCP + experimental option codepoints, either by different experiments on + different connections or for more than two experimental options in + the same connection. Experimental options 253 and 254 are already + deployed in operational code to support an early version of TCP + + + +Touch Standards Track [Page 2] + +RFC 6994 Shared Use of Experimental TCP Options August 2013 + + + authentication. Option 253 is also documented for the experimental + TCP Cookie Transaction option [RFC6013]. This shared use results in + collisions in which a single codepoint can appear multiple times in a + single TCP segment and for which each use is ambiguous. + + Other codepoints have been used without assignment (known as + "squatting"), notably 31-32 (TCP cookie transactions, as originally + distributed and in its API doc) and 76-78 (tcpcrypt) [Bi11] [Si11]. + Commercial products reportedly also use unassigned options 33, 69-70, + and 76-78. Even though these uses are unauthorized, they currently + impact legitimate assignees. + + Both such misuses (squatting on both experimental and assigned + codepoints) are expected to continue, but there are several + approaches that can alleviate the impact on cooperating protocol + designers. One proposal relaxes the requirements for assignment of + TCP options, allowing them to be assigned more readily for protocols + that have not been standardized through the IETF process [RFC5226]. + Another proposal assigns a larger pool to the TCP experiment option + codepoints and manages their sharing through IANA coordination + [Ed11]. + + The approach proposed in this document does not require additional + TCP option codepoints and is robust to those who choose either not to + support it or not to register their experiments. The solution adds a + field to the structure of the experimental TCP option. This field is + populated with an "experiment identifier" (ExID) defined as part of a + specific option experiment. The ExID helps reduce the probability of + a collision of independent experimental uses of the same option + codepoint, both for those who follow this document (using registered + ExIDs) and those who do not (squatters who either ignore this + extension or do not register their ExIDs). + + The solution proposed in this document is recommended for all new + protocols that use TCP experimental option codepoints. The + techniques described here may also enable shared use of other + experimental codepoints, but that issue is out of scope for this + document. + +2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + + In this document, these words will appear with that interpretation + only when in ALL CAPS. Lowercase uses of these words are not to be + interpreted as carrying RFC 2119 significance. + + + +Touch Standards Track [Page 3] + +RFC 6994 Shared Use of Experimental TCP Options August 2013 + + + In this document, the characters ">>" preceding an indented line(s) + indicates a compliance requirement statement using the key words + listed above. This convention aids reviewers in quickly identifying + or finding the explicit compliance requirements of this RFC. + +3. TCP Experimental Option Structure + + TCP options have the current common structure [RFC793], in which the + first byte is the codepoint (Kind) and the second byte is the length + of the option in bytes (Length): + + 0 1 2 3 + 01234567 89012345 67890123 45678901 + +--------+--------+--------+--------+ + | Kind | Length | ... | + +--------+--------+--------+--------+ + | ... + +-------- + + Figure 1. TCP Option Structure [RFC793] + + This document extends the option structure for experimental + codepoints (253, 254) with an experiment identifier (ExID), which is + either 2 or 4 bytes in length. The ExID is used to differentiate + experiments and is the first field after Kind and Length, as follows: + + 0 1 2 3 + 01234567 89012345 67890123 45678901 + +--------+--------+--------+--------+ + | Kind | Length | ExID | + +--------+--------+--------+--------+ + | option contents... + +--------+--------+--------+--- + + Figure 2. TCP Experimental Option with a 16-bit ExID + + 0 1 2 3 + 01234567 89012345 67890123 45678901 + +--------+--------+--------+--------+ + | Kind | Length | ExID | + +--------+--------+--------+--------+ + | ExID (con't) | option contents... + +--------+--------+--------+--- + + Figure 3. TCP Experimental Option with a 32-bit ExID + + + + + + +Touch Standards Track [Page 4] + +RFC 6994 Shared Use of Experimental TCP Options August 2013 + + + This mechanism is encouraged for all TCP options that are not yet + eligible for assigned codepoints: + + >> Protocols requiring new TCP option codepoints that are not + eligible for assigned values SHOULD use the existing TCP + experimental option codepoints (253, 254) with ExIDs as described + in this document. + + This mechanism is encouraged for all TCP options using the current + experimental codepoints in controlled environments: + + >> All protocols using the TCP experimental option codepoints (253, + 254), even those deployed in controlled environments, SHOULD use + ExIDs as described in this document. + + This mechanism is required for all TCP options using the current + experimental codepoints that are publicly deployed, whether enabled + by default or not: + + >> All protocols using the TCP experimental option codepoints (253, + 254) that are deployed outside controlled environments, such as in + the public Internet, MUST use ExIDs as described in this document. + + Once a TCP option uses the mechanism in this document, registration + of the ExID with IANA is required: + + >> All protocols using ExIDs as described in this document MUST + register those ExIDs with IANA. + + Applicants register their desired ExID by contacting IANA [IANA]. + +3.1. Selecting an ExID + + ExIDs are selected at design time, when the protocol designer first + implements or specifies the experimental option. ExIDs can be either + 16 bits or 32 bits. In both cases, the value is stored in the header + in network-standard (big-endian) byte order. ExIDs combine + properties of IANA registered codepoints with "magic numbers". + + >> All ExIDs MUST be either 16 bits or 32 bits long. + + Use of the ExID, whether 16 bit or 32 bit, helps reduce the + probability of a false positive collision with those who either do + not register their experiment or who do not implement this mechanism. + + + + + + + +Touch Standards Track [Page 5] + +RFC 6994 Shared Use of Experimental TCP Options August 2013 + + + In order to conserve TCP option space, either for use within a + specific option or to be available for other options: + + >> Options implementing the mechanism of this document SHOULD use + 16-bit ExIDs, except where explicitly motivating the need for + 32-bit ExIDs, e.g., to avoid false positives or maintain alignment + with an expected future assigned codepoint. + + ExIDs are registered with IANA using "first come, first served" + (FCFS) priority based on the first two bytes. Those two bytes are + thus sufficient to interpret which experimental option is contained + in the option field. + + >> All ExIDs MUST be unique based on their first 16 bits. + + The second two bytes serve as a "magic number". A magic number is a + self-selected codepoint whose primary value is its unlikely collision + with values selected by others. Magic numbers are used in other + protocols, e.g., bootstrap protocol (BOOTP) [RFC951] and DHCP + [RFC2131]. + + Using the additional magic number bytes helps the option contents + have the same byte alignment in the TCP header as they would have if + (or when) a conventional (non-experiment) TCP option codepoint is + assigned. Use of the same alignment reduces the potential for + implementation errors, especially in using the same word-alignment + padding, if the same software is later modified to use a conventional + codepoint. Use of the longer, 32-bit ExID further decreases the + probability of such a false positive compared to those using shorter, + 16-bit ExIDs. + + Use of the ExID does consume TCP option space but enables concurrent + use of the experimental codepoints and provides protection against + false positives, leaving less space for other options (including + other experiments). Use of the longer, 32-bit ExID consumes more + space, but provides more protection against false positives. + +3.2. Impact on TCP Option Processing + + The ExID number is considered part of the TCP option, not the TCP + option header. The presence of the ExID increases the effective + option Length field by the size of the ExID. The presence of this + ExID is thus transparent to implementations that do not support TCP + options. + + During TCP processing, ExIDs in experimental options are matched + against the ExIDs for each implemented protocol. The remainder of + the option is specified by the particular experimental protocol. + + + +Touch Standards Track [Page 6] + +RFC 6994 Shared Use of Experimental TCP Options August 2013 + + + >> Experimental options with ExIDs that do not match implemented + protocols MUST be ignored. + + The ExID mechanism must be coordinated during connection + establishment, just as with any TCP option. + + >> TCP ExID, if used in any TCP segment of a connection, MUST be + present in TCP SYN segments of that connection. + + >> TCP experimental option ExIDs, if used in any TCP segment of a + connection, SHOULD be used in all TCP segments of that connection + in which any experimental option is present. + + Use of an ExID uses additional space in the TCP header and requires + additional protocol processing by experimental protocols. Because + these are experiments, neither consideration is a substantial + impediment; a finalized protocol can avoid both issues with the + assignment of a dedicated option codepoint later. + +4. Reducing the Impact of False Positives + + False positives occur where the registered ExID of an experiment + matches the value of an option that does not use ExIDs. Such + collisions can cause an option to be interpreted by the incorrect + processing routine. Use of checksums or signatures may help an + experiment use the shorter ExID while reducing the corresponding + increased potential for false positives. + + >> Experiments that are not robust to ExID false positives SHOULD + implement other detection measures, such as checksums or minimal + digital signatures over the experimental options they support. + +5. Migration to Assigned Options + + Some experiments may transition away from being experimental and + become eligible for an assigned TCP option codepoint. This document + does not recommend a specific migration plan to transition from use + of the experimental TCP options/ExIDs to use of an assigned + codepoint. + + However, once an assigned codepoint is allocated, use of an ExID + represents unnecessary overhead. As a result: + + >> Once a TCP option codepoint is assigned to a protocol, that + protocol SHOULD NOT continue to use an ExID as part of that + assigned codepoint. + + + + + +Touch Standards Track [Page 7] + +RFC 6994 Shared Use of Experimental TCP Options August 2013 + + + This document does not recommend whether or how an implementation of + an assigned codepoint can be backward compatible with use of the + experimental codepoint/ExID. + + However, some implementers may be tempted to include both the + experimental and assigned codepoint in the same segment, e.g., in a + SYN to support backward compatibility during connection + establishment. This is a poor use of limited resources; so, to + ensure conservation of the TCP option space: + + >> A TCP segment MUST NOT contain both an assigned TCP option + codepoint and a TCP experimental option codepoint for the same + protocol. + + Instead, a TCP that intends backward compatibility might send + multiple SYNs with alternates of the same option and discard all but + the most desired successful connection. Although this approach may + resolve more slowly or require additional effort at the endpoints, it + is preferable to excessively consuming TCP option space. + +6. Rationale + + The ExIDs described in this document combine properties of IANA + FCFS-registered values with magic numbers. Although IANA FCFS + registries are common, so too are those who either fail to register + or who 'squat' by deliberately using codepoints that are assigned to + others. The approach in this document is intended to recognize this + reality and be more robust to its consequences than would be a + conventional IANA FCFS registry. + + Existing ID spaces were considered as ExIDs in the development of + this mechanism, including IEEE Organizationally Unique Identifier + (OUI) and IANA Private Enterprise Numbers (PENs) [IEEE802] [OUI] + [RFC1155]. + + OUIs are 24-bit identifiers that are combined with 24 to 40 bits of + privately assigned space to create identifiers that are commonly + assigned to a unique piece of hardware. OUIs are already longer than + the smaller ExID value, and obtaining an OUI is costly (currently + $1,885.00 USD). An OUI could be obtained for each experiment, but + this could be considered expensive. An OUI already assigned to an + organization could be shared if extended (to support multiple + experiments within an organization), but this would either require + coordination within an organization or an IANA registry; the former + is prohibitive, and the latter is more complicated than having IANA + manage the entire space. + + + + + +Touch Standards Track [Page 8] + +RFC 6994 Shared Use of Experimental TCP Options August 2013 + + + PENs were originally used in the Simple Network Management Protocol + (SNMP) [RFC1157]. PENs are identifiers that can be obtained without + cost from IANA [PEN]. Despite the current registry, the size of the + PEN assignment space is currently undefined and has only recently + been proposed (as 32 bits) [IANA-PEN]. PENs are currently assigned + to organizations, and there is no current process for assigning them + to individuals. Finally, if the PENs are 32 bits as expected, they + would be larger than needed in many cases. + +7. Security Considerations + + The mechanism described in this document is not intended to enhance, + nor does it weaken the existing state of security for TCP option + processing. + +8. IANA Considerations + + IANA has created a "TCP Experimental Option Experiment Identifiers + (TCP ExIDs)" registry. The registry records both 16-bit and 32-bit + ExIDs, as well as a reference (description, document pointer, or + assignee name and e-mail contact) for each entry. ExIDs are + registered for use with both of the TCP experimental option + codepoints, i.e., with TCP options with values of 253 and 254. + + Entries are assigned on a First Come, First Served (FCFS) basis + [RFC5226]. The registry operates FCFS on the first two bytes of the + ExID (in network-standard order) but records the entire ExID (in + network-standard order). Some examples are: + + o 0x12340000 collides with a previous registration of 0x1234abcd + + o 0x5678 collides with a previous registration of 0x56780123 + + o 0xabcd1234 collides with a previous registration of 0xabcd + + IANA will advise applicants of duplicate entries to select an + alternate value, as per typical FCFS processing. + + IANA will record known duplicate uses to assist the community in both + debugging assigned uses as well as correcting unauthorized duplicate + uses. + + IANA should impose no requirements on making a registration other + than indicating the desired codepoint and providing a point of + contact. A short description or acronym for the use is desired but + should not be required. + + + + + +Touch Standards Track [Page 9] + +RFC 6994 Shared Use of Experimental TCP Options August 2013 + + +9. References + +9.1. Normative References + + [RFC793] 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. + + [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, + ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + +9.2. Informative References + + [Bi11] Bittau, A., Boneh, D., Hamburg, M., Handley, M., Mazieres, + D., and Q. Slack, "Cryptographic protection of TCP + Streams", Work in Progress, September 2012. + + [Ed11] + Eddy, W., "Additional TCP Experimental-Use Options", Work + in Progress, August 2011. + + [IANA] IANA, . + + [IANA-PEN] Liang, P. and A. Melnikov, "Private Enterprise Number + (PEN) Practices and Internet Assigned Numbers: Authority + (IANA) Considerations for Registration Procedures", Work + in Progress, June 2012. + + [IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area + Networks: Overview and Architecture", IEEE 802-2001, 8 + March 2002. + + [OUI] IEEE, "Organizationally Unique Identifier (OUI) or + 'Company_ID'", + . + + [PEN] IANA, "Private Enterprise Numbers", + . + + [RFC951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, + September 1985. + + + + +Touch Standards Track [Page 10] + +RFC 6994 Shared Use of Experimental TCP Options August 2013 + + + [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification + of Management Information for TCP/IP-Based Internets", STD + 16, RFC 1155, May 1990. + + [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, + "Simple Network Management Protocol (SNMP)", RFC 1157, May + 1990. + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, October 1996. + + [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC + 2131, March 1997. + + [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For + Values In the Internet Protocol and Related Headers", BCP + 37, RFC 2780, March 2000. + + [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers + Considered Useful", BCP 82, RFC 3692, January 2004. + + [RFC6013] Simpson, W., "TCP Cookie Transactions (TCPCT)", RFC 6013, + January 2011. + + [Si11] Simpson, W., "TCP Cookie Transactions (TCPCT) Sockets + Application Program Interface (API)", Work in Progress, + April 2011. + +10. Acknowledgments + + This document was motivated by discussions on the IETF TCPM mailing + list and by Wes Eddy's proposal [Ed11]. Yoshifumi Nishida, Pasi + Sarolathi, and Michael Scharf provided detailed feedback. + + This document was originally prepared using 2-Word-v2.0.template.dot. + +Author's Address + + Joe Touch + USC/ISI + 4676 Admiralty Way + Marina del Rey, CA 90292-6695 U.S.A. + + Phone: +1 (310) 448-9151 + EMail: touch@isi.edu + + + + + + +Touch Standards Track [Page 11] + -- cgit v1.2.3