draft-ietf-tcpm-experimental-options-05.txt | draft-ietf-tcpm-experimental-options-06.txt | |||
---|---|---|---|---|
TCPM Working Group J. Touch | TCPM Working Group J. Touch | |||
Internet Draft USC/ISI | Internet Draft USC/ISI | |||
Intended status: Proposed Standard March 13, 2013 | Intended status: Proposed Standard June 4, 2013 | |||
Expires: September 2013 | Expires: December 2013 | |||
Shared Use of Experimental TCP Options | Shared Use of Experimental TCP Options | |||
draft-ietf-tcpm-experimental-options-05.txt | draft-ietf-tcpm-experimental-options-06.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 September 13, 2013. | This Internet-Draft will expire on December 4, 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 31 | skipping to change at page 2, line 31 | |||
3.1. Selecting an ExID.........................................6 | 3.1. Selecting an ExID.........................................6 | |||
3.2. Impact on TCP Option Processing...........................7 | 3.2. Impact on TCP Option Processing...........................7 | |||
4. Reducing the Impact of False Positives.........................7 | 4. Reducing the Impact of False Positives.........................7 | |||
5. Migration to Assigned Options..................................8 | 5. Migration to Assigned Options..................................8 | |||
6. Rationale......................................................8 | 6. Rationale......................................................8 | |||
7. Security Considerations........................................9 | 7. Security Considerations........................................9 | |||
8. IANA Considerations............................................9 | 8. IANA Considerations............................................9 | |||
9. References....................................................10 | 9. References....................................................10 | |||
9.1. Normative References.....................................10 | 9.1. Normative References.....................................10 | |||
9.2. Informative References...................................10 | 9.2. Informative References...................................10 | |||
10. Acknowledgments..............................................11 | 10. Acknowledgments..............................................12 | |||
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 6, line 25 | skipping to change at page 6, line 25 | |||
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. | >> All ExIDs MUST be either 16-bits or 32-bits long. | |||
Use of the ExID, whether 16-bit or 32-bit, helps reduce the | Use of the ExID, whether 16-bit or 32-bit, helps reduce the | |||
probability of a false positive collision with those who either do | probability of a false positive collision with those who either do | |||
not register their experiment or who do not implement this | not register their experiment or who do not implement this | |||
mechanism. | mechanism. | |||
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" | 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. | >> 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 | |||
skipping to change at page 6, line 51 | skipping to change at page 7, line 11 | |||
implementation errors, especially in using the same word-alignment | implementation errors, especially in using the same word-alignment | |||
padding, if the same software is later modified to use a | padding, if the same software is later modified to use a | |||
conventional codepoint. Use of the longer, 32-bit ExID further | conventional codepoint. Use of the longer, 32-bit ExID further | |||
decreases the probability of such a false positive compared to those | decreases the probability of such a false positive compared to those | |||
using shorter, 16-bit ExIDs. | using shorter, 16-bit ExIDs. | |||
Use of the ExID does consume TCP option space but enables concurrent | Use of the ExID does consume TCP option space but enables concurrent | |||
use of the experimental codepoints and provides protection against | use of the experimental codepoints and provides protection against | |||
false positives, leaving less space for other options (including | false positives, leaving less space for other options (including | |||
other experiments). Use of the longer, 32-bit ExID consumes more | other experiments). Use of the longer, 32-bit ExID consumes more | |||
space, but provides more protection against false positives. | space, but provides more protection against false positives.S | |||
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 7, line 38 | skipping to change at page 7, line 46 | |||
which any experimental option is present. | which any experimental option is present. | |||
Use of an ExID uses additional space in the TCP header and requires | Use of an ExID uses additional space in the TCP header and requires | |||
additional protocol processing by experimental protocols. Because | additional protocol processing by experimental protocols. Because | |||
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 registered ExID of an experiment | |||
value of an option that does not use ExIDs or if two experiments | matches the value of an option that does not use ExIDs. Such | |||
select the same ExID. Such collisions can cause an option to be | collisions can cause an option to be interpreted by the incorrect | |||
interpreted by the incorrect processing routine. Use of checksums or | processing routine. Use of checksums or signatures may help an | |||
signatures may help an experiment use the shorter ExID while | experiment use the shorter ExID while reducing the corresponding | |||
reducing the corresponding increased potential for false positives. | 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 9, line 37 | skipping to change at page 9, line 43 | |||
7. Security Considerations | 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. | |||
8. 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. The registry records both 16- | 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 | bit and 32-bit ExIDs, as well as a name and e-mail contact for each | |||
entry. | entry. ExIDs are registered for use with both 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 | Entries are assigned on a First-Come, First-Served (FCFS) basis | |||
[RFC5226]. The registry operates FCFS on the first two bytes of the | [RFC5226]. The registry operates FCFS on the first two bytes of the | |||
ExID (in network-standard order) but records the entire ExID (in | ExID (in network-standard order) but records the entire ExID (in | |||
network-standard order). Some examples are: | network-standard order). Some examples are: | |||
o 0x12340000 collides with a previous registration of 0x1234abcd | o 0x12340000 collides with a previous registration of 0x1234abcd | |||
o 0x5678 collides with a previous registration of 0x56780123 | o 0x5678 collides with a previous registration of 0x56780123 | |||
End of changes. 8 change blocks. | ||||
13 lines changed or deleted | 23 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/ |