draft-ietf-tcpm-experimental-options-04.txt   draft-ietf-tcpm-experimental-options-05.txt 
TCPM Working Group J. Touch TCPM Working Group J. Touch
Internet Draft USC/ISI Internet Draft USC/ISI
Intended status: Proposed Standard February 25, 2013 Intended status: Proposed Standard March 13, 2013
Expires: August 2013 Expires: September 2013
Shared Use of Experimental TCP Options Shared Use of Experimental TCP Options
draft-ietf-tcpm-experimental-options-04.txt draft-ietf-tcpm-experimental-options-05.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 25, 2013. This Internet-Draft will expire on September 13, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
same connection. It uses a new IANA TCP experiment identifier, and same connection. It uses a new IANA TCP experiment identifier, and
is also robust to experiments that are not registered and those that is also robust to experiments that are not registered and those that
do not use this sharing mechanism. It is recommended for all new TCP do not use this sharing mechanism. It is recommended for all new TCP
options that use these codepoints. options that use these codepoints.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................2
2. Conventions used in this document..............................4 2. Conventions used in this document..............................4
3. TCP Experimental Option Structure..............................4 3. TCP Experimental Option Structure..............................4
3.1. Selecting an ExID.........................................5 3.1. Selecting an ExID.........................................6
3.2. Impact on TCP Option Processing...........................6 3.2. Impact on TCP Option Processing...........................7
4. Reducing the Impact of False Positives.........................6 4. Reducing the Impact of False Positives.........................7
5. Migration to Assigned Options..................................7 5. Migration to Assigned Options..................................8
6. Security Considerations........................................7 6. Rationale......................................................8
7. IANA Considerations............................................7 7. Security Considerations........................................9
8. References.....................................................8 8. IANA Considerations............................................9
8.1. Normative References......................................8 9. References....................................................10
8.2. Informative References....................................8 9.1. Normative References.....................................10
9. Acknowledgments................................................9 9.2. Informative References...................................10
10. Acknowledgments..............................................11
1. Introduction 1. Introduction
TCP includes options to enable new protocol capabilities that can be TCP includes options to enable new protocol capabilities that can be
activated only where needed and supported [RFC793]. The space for activated only where needed and supported [RFC793]. The space for
identifying such options is small - 256 values, of which 30 are identifying such options is small - 256 values, of which 30 are
assigned at the time this document was published [IANA]. Two of assigned at the time this document was published [IANA]. Two of
these codepoints are allocated to support experiments (253, 254) these codepoints are allocated to support experiments (253, 254)
[RFC4727]. These values are intended for testing purposes or anytime [RFC4727]. These values are intended for testing purposes or anytime
an assigned codepoint is either not warranted or available, e.g., an assigned codepoint is either not warranted or available, e.g.,
skipping to change at page 5, line 25 skipping to change at page 5, line 25
0 1 2 3 0 1 2 3
01234567 89012345 67890123 45678901 01234567 89012345 67890123 45678901
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Kind | Length | ExID | | Kind | Length | ExID |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| ExID (con't) | option contents... | ExID (con't) | option contents...
+--------+--------+--------+--- +--------+--------+--------+---
Figure 3 TCP Experimental Option with a 32-bit ExID Figure 3 TCP Experimental Option with a 32-bit ExID
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 >> Protocols requiring new TCP option codepoints that are not
eligible for assigned values SHOULD use the existing TCP eligible for assigned values SHOULD use the existing TCP
experimental option codepoints (253, 254) with ExIDs as described in experimental option codepoints (253, 254) with ExIDs as described in
this document. 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, >> All protocols using the TCP experimental option codepoints (253,
254) SHOULD use ExIDs as described in this document. 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 3.1. Selecting an ExID
ExIDs are selected at design time, when the protocol designer first ExIDs are selected at design time, when the protocol designer first
implements or specifies the experimental option. ExIDs can be either 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 16-bits or 32-bits. In both cases, the value is stored in the header
in network-standard (big-endian) byte order. ExIDs combine in network-standard (big-endian) byte order. ExIDs combine
properties of IANA registered codepoints with "magic numbers". 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.
ExIDs are registered with IANA using "first-come, first-served" ExIDs are registered with IANA using "first-come, first-served"
priority based on the first two bytes. Those two bytes are thus priority based on the first two bytes. Those two bytes are thus
sufficient to interpret which experimental option is contained in sufficient to interpret which experimental option is contained in
the option field. 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 The second two bytes serve as a "magic number". A magic number is a
self-selected codepoint whose primary value is its unlikely self-selected codepoint whose primary value is its unlikely
collision with values selected by others. Magic numbers are used in collision with values selected by others. Magic numbers are used in
other protocols, e.g., BOOTP [RFC951] and DHCP [RFC2131]. The magic other protocols, e.g., BOOTP [RFC951] and DHCP [RFC2131].
number helps reduce the probability of a false positive collision
with those who either do not register their experiment or who do not Using the additional magic number bytes helps the option contents
implement this mechanism. Using the additional magic number bytes have the same byte alignment in the TCP header as they would have if
also helps the option contents have the same byte alignment in the (or when) a conventional (non-experiment) TCP option codepoint is
TCP header as they would have if (or when) a conventional (non- assigned. Use of the same alignment reduces the potential for
experiment) TCP option codepoint is assigned. 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 3.2. Impact on TCP Option Processing
The ExID number is considered part of the TCP option, not the TCP The ExID number is considered part of the TCP option, not the TCP
option header. The presence of the ExID increases the effective option header. The presence of the ExID increases the effective
option Length field by the size of the ExID. The presence of this option Length field by the size of the ExID. The presence of this
ExID is thus transparent to implementations that do not support TCP ExID is thus transparent to implementations that do not support TCP
options where it is used. options where it is used.
During TCP processing, ExIDs in experimental options are matched During TCP processing, ExIDs in experimental options are matched
skipping to change at page 6, line 46 skipping to change at page 7, line 42
these are experiments, neither consideration is a substantial these are experiments, neither consideration is a substantial
impediment; a finalized protocol can avoid both issues with the impediment; a finalized protocol can avoid both issues with the
assignment of a dedicated option codepoint later. assignment of a dedicated option codepoint later.
4. Reducing the Impact of False Positives 4. Reducing the Impact of False Positives
False positives occur where the ExID of one experiment matches the False positives occur where the ExID of one experiment matches the
value of an option that does not use ExIDs or if two experiments value of an option that does not use ExIDs or if two experiments
select the same ExID. Such collisions can cause an option to be select the same ExID. Such collisions can cause an option to be
interpreted by the incorrect processing routine. Use of checksums or interpreted by the incorrect processing routine. Use of checksums or
signatures may help an experiment use a shorter ExID while reducing signatures may help an experiment use the shorter ExID while
the corresponding increased potential for false positives. reducing the corresponding increased potential for false positives.
>> Experiments that are not robust to ExID false positives SHOULD >> Experiments that are not robust to ExID false positives SHOULD
implement other detection measures, such as checksums or minimal implement other detection measures, such as checksums or minimal
digital signatures over the experimental options they support. digital signatures over the experimental options they support.
5. Migration to Assigned Options 5. Migration to Assigned Options
Some experiments may transition from experiment, and become eligible Some experiments may transition from experiment, and become eligible
for an assigned TCP option codepoint. This document does not for an assigned TCP option codepoint. This document does not
recommend a specific migration plan to transition from use of the recommend a specific migration plan to transition from use of the
skipping to change at page 7, line 25 skipping to change at page 8, line 21
However, once an assigned codepoint is allocated, use of an ExID However, once an assigned codepoint is allocated, use of an ExID
represents unnecessary overhead. As a result: represents unnecessary overhead. As a result:
>> Once a TCP option codepoint is assigned to a protocol, that >> Once a TCP option codepoint is assigned to a protocol, that
protocol SHOULD NOT continue to use an ExID as part of that assigned protocol SHOULD NOT continue to use an ExID as part of that assigned
codepoint. codepoint.
This document does not recommend whether or how an implementation of This document does not recommend whether or how an implementation of
an assigned codepoint can be backward-compatible with use of the an assigned codepoint can be backward-compatible with use of the
experimental codepoint/ ExID. experimental codepoint/ExID.
However, some implementers may be tempted to include both the However, some implementers may be tempted to include both the
experimental and assigned codepoint in the same segment, e.g., in a experimental and assigned codepoint in the same segment, e.g., in a
SYN to support backward-compatibility during connection SYN to support backward-compatibility during connection
establishment. This is a poor use limited resources and so to ensure establishment. This is a poor use limited resources and so to ensure
conservation of the TCP option space: conservation of the TCP option space:
>> A TCP segment MUST NOT contain both an assigned TCP option >> A TCP segment MUST NOT contain both an assigned TCP option
codepoint and a TCP experimental option codepoint for the same codepoint and a TCP experimental option codepoint for the same
protocol. protocol.
Instead, a TCP that intends backward compatibility might send Instead, a TCP that intends backward compatibility might send
multiple SYNs with alternates of the same option and discard all but multiple SYNs with alternates of the same option and discard all but
the most desired successful connection. Although this approach may the most desired successful connection. Although this approach may
resolve more slowly or require additional effort at the endpoints, resolve more slowly or require additional effort at the endpoints,
it is preferable to excessively consuming TCP option space. it is preferable to excessively consuming TCP option space.
6. Security Considerations 6. Rationale
The ExIDs described in this document combine properties of IANA
first-come/first-served (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) [802] [OUI]
[RFC1155].
OUIs are 24-bit identifiers that are combined with 24 to 40-bits of
privately-assigned space to create identifiers that 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 to have IANA
manage the entire space.
PENs were originally used in 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) [Li12].
PENs are currently assigned to organizations, and there is no
current process for assigning them to individuals. Finally, if 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 provide The mechanism described in this document is not intended to provide
(nor does it weaken existing) security for TCP option processing. (nor does it weaken existing) security for TCP option processing.
7. IANA Considerations 8. IANA Considerations
This document calls for IANA to create a new TCP experimental option This document calls for IANA to create a new TCP experimental option
Experiment Identifier (ExID) registry. Experiment Identifier (ExID) registry. The registry records both 16-
bit and 32-bit ExIDs, as well as a name and e-mail contact for each
entry.
That registry should allow 16-bit and 32-bit entries, where entries Entries are assigned on a First-Come, First-Served (FCFS) basis
are "first-come, first-served" on the first two bytes of the value [RFC5226]. The registry operates FCFS on the first two bytes of the
in network-standard byte order (big endian), in which the entry ExID (in network-standard order) but records the entire ExID (in
should indicate the entire ExID value. Known overlapping uses - network-standard order). Some examples are:
whether of the first-come portion or the entire value - should also
be listed and highlighted as collisions. o 0x12340000 collides with a previous registration of 0x1234abcd
o 0x5678 collides with a previous registration of 0x56780123
o 0xabcd1234 collides it 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 IANA should impose no requirements on making a registration other
than indicating the desired codepoint and providing a point of than indicating the desired codepoint and providing a point of
contact. A short description or acronym for the use is desired, but contact. A short description or acronym for the use is desired, but
should not be required. should not be required.
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, Sep. 1981. 793, Sep. 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4727] Fenner, B., "Experimental Values in IPv4, IPv6, ICMPv4, [RFC4727] Fenner, B., "Experimental Values in IPv4, IPv6, ICMPv4,
ICMPv6, UDP, and TCP Headers", RFC 4727, Nov. 2006. ICMPv6, UDP, and TCP Headers", RFC 4727, Nov. 2006.
8.2. Informative References [RFC5226] Narten, T., H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 5226, May
2008.
9.2. Informative References
[802] "IEEE Standard for Local and Metropolitan Area Networks:
Overview and Architecture", IEEE 802-2001, 8 March 2002.
[Bi11] Bittau, A., D. Boneh, M. Hamburg, M. Handley, D. Mazieres, [Bi11] Bittau, A., D. Boneh, M. Hamburg, M. Handley, D. Mazieres,
Q. Slack, "Cryptographic protection of TCP Streams Q. Slack, "Cryptographic protection of TCP Streams
(tcpcrypt)", work in progress, draft-bittau-tcp-crypt-03, (tcpcrypt)", work in progress, draft-bittau-tcp-crypt-03,
Sep. 3, 2012. Sep. 3, 2012.
[Ed11] Eddy, W., "Additional TCP Experimental-Use Options", work [Ed11] Eddy, W., "Additional TCP Experimental-Use Options", work
in progress, draft-eddy-tcpm-addl-exp-options-00, Aug. 16, in progress, draft-eddy-tcpm-addl-exp-options-00, Aug. 16,
2011. 2011.
[IANA] IANA web pages, http://www.iana.org/ [IANA] IANA web pages, http://www.iana.org/
[Li12] Liang, P., A. Melnikov, "Private Enterprise Number (PEN)
practices and Internet Assigned Numbers: Authority (IANA)
considerations for registration procedures", draft-liang-
iana-pen-01, (work in progress), June 2012.
[OUI] IEEE OUI registry,
http://standards.ieee.org/develop/regauth/oui/
[PEN] IANA Private Enterprise Numbers,
http://www.iana.org/assignments/enterprise-numbers
[RFC951] Croft, B., J. Gilmore, "BOOTSTRAP PROTOCOL (BOOTP)", RFC [RFC951] Croft, B., J. Gilmore, "BOOTSTRAP PROTOCOL (BOOTP)", RFC
951, Sept. 1985. 951, Sept. 1985.
[RFC1155] Rose, M., K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based internets", RFC
1155, May 1990.
[RFC1157] Case, J., M. Fedor, M. Schoffstall, J. Davin, "A Simple
Network Management Protocol (SNMP)", RFC 1157, May 1990.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, Oct. 1996. 3", BCP 9, RFC 2026, Oct. 1996.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, Mar. 1997. 2131, Mar. 1997.
[RFC2780] Bradner, S., V. Paxson, "IANA Allocation Guidelines For [RFC2780] Bradner, S., V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers", BCP Values In the Internet Protocol and Related Headers", BCP
37, RFC 2780, Mar. 2000. 37, RFC 2780, Mar. 2000.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, Jan. 2004. Considered Useful", BCP 82, RFC 3692, Jan. 2004.
[RFC5226] Narten, T., H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 5226, May
2008.
[RFC6013] Simpson, W., "TCP Cookie Transactions (TCPCT)", RFC 6013, [RFC6013] Simpson, W., "TCP Cookie Transactions (TCPCT)", RFC 6013,
Jan. 2011. Jan. 2011.
[Si11] Simpson, W., "TCP Cookie Transactions (TCPCT) Sockets [Si11] Simpson, W., "TCP Cookie Transactions (TCPCT) Sockets
Application Program Interface (API)", work in progress, Application Program Interface (API)", work in progress,
draft-simpson-tcpct-api-04, Apr. 7, 2011. draft-simpson-tcpct-api-04, Apr. 7, 2011.
9. Acknowledgments 10. Acknowledgments
This document was motivated by discussions on the IETF TCPM mailing This document was motivated by discussions on the IETF TCPM mailing
list and by Wes Eddy's proposal [Ed11]. Yoshifumi Nishida, Pasi list and by Wes Eddy's proposal [Ed11]. Yoshifumi Nishida, Pasi
Sarolathi, and Michael Scharf provided detailed feedback. Sarolathi, and Michael Scharf provided detailed feedback.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses Authors' Addresses
Joe Touch Joe Touch
 End of changes. 23 change blocks. 
42 lines changed or deleted 153 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/