draft-ietf-tsvwg-udp-options-02.txt   draft-ietf-tsvwg-udp-options-03.txt 
TSVWG J. Touch TSVWG J. Touch
Internet Draft Internet Draft
Intended status: Standards Track January 19, 2018 Intended status: Standards Track July 1, 2018
Intended updates: 768 Intended updates: 768
Expires: July 2018 Expires: January 2019
Transport Options for UDP Transport Options for UDP
draft-ietf-tsvwg-udp-options-02.txt draft-ietf-tsvwg-udp-options-03.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. This document may not be modified, provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to format it and derivative works of it may not be created, except to format it
for publication as an RFC or to translate it into languages other for publication as an RFC or to translate it into languages other
than English. than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 July 19, 2018. This Internet-Draft will expire on January 1, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 26 skipping to change at page 2, line 26
1. Introduction...................................................3 1. Introduction...................................................3
2. Conventions used in this document..............................3 2. Conventions used in this document..............................3
3. Background.....................................................3 3. Background.....................................................3
4. The UDP Option Area............................................4 4. The UDP Option Area............................................4
5. UDP Options....................................................7 5. UDP Options....................................................7
5.1. End of Options List (EOL).................................8 5.1. End of Options List (EOL).................................8
5.2. No Operation (NOP)........................................9 5.2. No Operation (NOP)........................................9
5.3. Option Checksum (OCS).....................................9 5.3. Option Checksum (OCS).....................................9
5.4. Alternate Checksum (ACS).................................10 5.4. Alternate Checksum (ACS).................................10
5.5. Lite (LITE)..............................................10 5.5. Lite (LITE)..............................................11
5.6. Maximum Segment Size (MSS)...............................12 5.6. Maximum Segment Size (MSS)...............................13
5.7. Timestamps (TIME)........................................13 5.7. Timestamps (TIME)........................................13
5.8. Fragmentation (FRAG).....................................13 5.8. Fragmentation (FRAG).....................................14
5.8.1. Coupling FRAG with LITE.............................16 5.8.1. Coupling FRAG with LITE.............................16
5.9. Authentication and Encryption (AE).......................16 5.9. Authentication and Encryption (AE).......................17
5.10. Experimental (EXP)......................................17 5.10. Experimental (EXP)......................................18
6. UDP API Extensions............................................17 6. UDP API Extensions............................................18
7. Whose options are these?......................................18 7. Whose options are these?......................................19
8. UDP options vs. UDP-Lite......................................19 8. UDP options vs. UDP-Lite......................................19
9. Interactions with Legacy Devices..............................19 9. Interactions with Legacy Devices..............................20
10. Options in a Stateless, Unreliable Transport Protocol........20 10. Options in a Stateless, Unreliable Transport Protocol........21
11. UDP Option State Caching.....................................21 11. UDP Option State Caching.....................................21
12. Multicast Considerations.....................................21 12. Multicast Considerations.....................................22
13. Security Considerations......................................21 13. Security Considerations......................................22
14. IANA Considerations..........................................22 14. IANA Considerations..........................................22
15. References...................................................22 15. References...................................................23
15.1. Normative References....................................22 15.1. Normative References....................................23
15.2. Informative References..................................23 15.2. Informative References..................................23
16. Acknowledgments..............................................24 16. Acknowledgments..............................................25
Appendix A. Implementation Information...........................26 Appendix A. Implementation Information...........................27
1. Introduction 1. Introduction
Transport protocols use options as a way to extend their Transport protocols use options as a way to extend their
capabilities. TCP [RFC793], SCTP [RFC4960], and DCCP [RFC4340] capabilities. TCP [RFC793], SCTP [RFC4960], and DCCP [RFC4340]
include space for these options but UDP [RFC768] currently does not. include space for these options but UDP [RFC768] currently does not.
This document defines an experimental extension to UDP that provides This document defines an experimental extension to UDP that provides
space for transport options including their generic syntax and space for transport options including their generic syntax and
semantics for their use in UDP's stateless, unreliable message semantics for their use in UDP's stateless, unreliable message
protocol. protocol.
skipping to change at page 7, line 25 skipping to change at page 7, line 25
5. UDP Options 5. UDP Options
The following UDP options are currently defined: The following UDP options are currently defined:
Kind Length Meaning Kind Length Meaning
---------------------------------------------- ----------------------------------------------
0* - End of Options List (EOL) 0* - End of Options List (EOL)
1* - No operation (NOP) 1* - No operation (NOP)
2* 2 Option checksum (OCS) 2* 2 Option checksum (OCS)
3 4 Alternate checksum (ACS) 3* 4 Alternate checksum (ACS)
4 4 Lite (LITE) 4* 4 Lite (LITE)
5 4 Maximum segment size (MSS) 5* 8/10 Fragmentation (FRAG)
6 10 Timestamps (TIME) 6* 4 Maximum segment size (MSS)
7 12 Fragmentation (FRAG) 7 10 Timestamps (TIME)
8 (varies) Authentication and Encryption (AE) 8 (varies) Authentication and Encryption (AE)
9-126 (varies) UNASSIGNED (assignable by IANA) 9-126 (varies) UNASSIGNED (assignable by IANA)
127-253 RESERVED 127-253 RESERVED
254 N(>=4) RFC 3692-style experiments (EXP) 254 N(>=4) RFC 3692-style experiments (EXP)
255 RESERVED 255 RESERVED
These options are defined in the following subsections. These options are defined in the following subsections.
>> An endpoint supporting UDP options MUST support those marked with >> An endpoint supporting UDP options MUST support those marked with
a "*" above: EOL, NOP, and OCS. a "*" above: EOL, NOP, OCS, ACS, LITE, FRAG, and MSS. This includes
both recognizing and being able to generate these options if
[QUESTION: Should we extend these, e.g., through #7?] configured to do so.
>> All other options (without a "*") MAY be implemented, and their >> All other options (without a "*") MAY be implemented, and their
use SHOULD be determined either out-of-band or negotiated. use SHOULD be determined either out-of-band or negotiated.
>> Receivers MUST silently ignore unknown options. That includes >> Receivers MUST silently ignore unknown options. That includes
options whose length does not indicate the specified value. options whose length does not indicate the specified value.
>> Only ACS and AE options depend on the contents of the option >> Except for NOP, each option SHOULD NOT occur more than once in a
area. AE is always computed as if both the AE hash and ACS checksum single UDP datagram. If a non-NOP option occurs more than once, a
are zero; ACS is computed as if the ACS checksum is zero. Future receiver MUST interpret only the first instance of that option and
options MUST NOT be defined as having a value independent of the MUST ignore all others.
contents of the option area. Otherwise, interactions between those
values, ACS, and UDP-AE could be unpredictable. >> Only the OCS and AE options depend on the contents of the option
area. AE is always computed as if the AE hash and OCS checksum are
zero; OCS is always computed as if the OCS checksum is zero and
after the AE hash has been computed. Future options MUST NOT be
defined as having a value dependent on the contents of the option
area. Otherwise, interactions between those values, OCS, and AE
could be unpredictable.
Receivers cannot treat unexpected option lengths as invalid, as this Receivers cannot treat unexpected option lengths as invalid, as this
would unnecessarily limit future revision of options (e.g., defining would unnecessarily limit future revision of options (e.g., defining
a new ACS that is defined by having a different length). a new ACS that is defined by having a different length).
>> Option lengths MUST NOT exceed the IP length of the packet. If >> Option lengths MUST NOT exceed the IP length of the packet. If
this occurs, the packet MUST be treated as malformed and dropped, this occurs, the packet MUST be treated as malformed and dropped,
and the event MAY be logged for diagnostics (logging SHOULD be rate and the event MAY be logged for diagnostics (logging SHOULD be rate
limited). limited).
>> Required options MUST come before other options. Each required >> Required options MUST come before other options. Each required
option MUST NOT occur more than once (if they are repeated in a option MUST NOT occur more than once (if they are repeated in a
received segment, all except the first MUST be silently ignored). received segment, all except the first MUST be silently ignored).
The requirement that required options come before others is intended The requirement that required options come before others is intended
to allow for endpoints to implement DOS protection, as discussed to allow for endpoints to implement DOS protection, as discussed
further in Section 13. further in Section 14.
5.1. End of Options List (EOL) 5.1. End of Options List (EOL)
The End of Options List (EOL) option indicates that there are no The End of Options List (EOL) option indicates that there are no
more options. It is used to indicate the end of the list of options more options. It is used to indicate the end of the list of options
without needing to pad the options to fill all available option without needing to pad the options to fill all available option
space. space.
+--------+ +--------+
| Kind=0 | | Kind=0 |
skipping to change at page 10, line 5 skipping to change at page 10, line 9
+--------+--------+ +--------+--------+
| Kind=2 | Ones8 | | Kind=2 | Ones8 |
+--------+--------+ +--------+--------+
Figure 7 UDP OCS option format Figure 7 UDP OCS option format
>> When present, the option checksum SHOULD occur as early as >> When present, the option checksum SHOULD occur as early as
possible, preferably preceded by only NOP options for alignment and possible, preferably preceded by only NOP options for alignment and
the LITE option if present. the LITE option if present.
OCS covers the entire UDP option, including the Lite option as OCS covers the entire UDP option area, including the Lite option as
formatted before swapping for transmission (or, equivalently, after formatted before swapping for transmission (or, equivalently, after
the swap after reception). the swap after reception).
>> If the option checksum fails, all options MUST be ignored and any >> If the option checksum fails, all options MUST be ignored and any
trailing surplus data (and Lite data, if used) silently discarded. trailing surplus data (and Lite data, if used) silently discarded.
>> UDP data that is validated by a correct UDP checksum MUST be >> UDP data that is validated by a correct UDP checksum MUST be
delivered to the application layer, even if the UDP option checksum delivered to the application layer, even if the UDP option checksum
fails, unless the endpoints have negotiated otherwise for this fails, unless the endpoints have negotiated otherwise for this
segment's socket pair. segment's socket pair.
5.4. Alternate Checksum (ACS) 5.4. Alternate Checksum (ACS)
The Alternate Checksum (ACS) is a 16-bit CRC of the UDP payload only The Alternate Checksum (ACS) provides a stronger alternative to the
(excluding the IP pseudoheader, UDP header, and UDP options). It UDP header checksum, using a 16-bit CRC of the conventional UDP
does not include the IP pseudoheader or UDP header, and so need not payload only (excluding the IP pseudoheader, UDP header, and UDP
be updated by NATs when IP addresses or UDP ports are rewritten. Its options, and not include the LITE area). It does not include the IP
purpose is to detect errors that the UDP checksum might not detect. pseudoheader or UDP header, and so need not be updated by NATs when
CRC-CCITT (polynomial x^16 + x^12 + x^5 + x or polynomial 0x1021) IP addresses or UDP ports are rewritten. Its purpose is to detect
has been chosen because of its ubiquity and use in other packet errors that the UDP checksum might not detect. CRC-CCITT (polynomial
protocols, such as X.25, HDLC, and Bluetooth. x^16 + x^12 + x^5 + x) has been chosen because of its ubiquity and
use in other packet protocols, such as X.25, HDLC, and Bluetooth.
The option contains the remainder of the calculation of the
polynomial over the UDP payload data (i.e., not inverted).
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Kind=3 | Len=4 | CRC16sum | | Kind=3 | Len=4 | CRC16sum |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 8 UDP ACS option format Figure 8 UDP ACS option format
When ACS is computed, its checksum (CRC) area is zeroed. No other When present, the ACS always contains a valid CRC checksum. There
options are zeroed before computing ACS. are no reserved values, including the value of zero. If the CRC is
zero, this must indicate a valid checksum (i.e., it does not
indicate that the ACS is not used; instead, the option would simply
not be included if that were the desired effect).
ACS does not protect the UDP pseudoheader; only the current UDP
checksum provides that protection. ACS cannot provide that
protection because it would need to be updated whenever the UDP
pseudoheader changed, e.g., during NAT address and port translation;
because this is not the case, ACS does not cover the pseudoheader.
5.5. Lite (LITE) 5.5. Lite (LITE)
The Lite option (LITE) is intended to provide equivalent capability The Lite option (LITE) is intended to provide equivalent capability
to the UDP Lite transport protocol [RFC3828]. UDP Lite allows the to the UDP Lite transport protocol [RFC3828]. UDP Lite allows the
UDP checksum to cover only a prefix of the UDP data payload, to UDP checksum to cover only a prefix of the UDP data payload, to
protect critical information (e.g., application headers) but allow protect critical information (e.g., application headers) but allow
potentially erroneous data to be passed to the user. This feature potentially erroneous data to be passed to the user. This feature
helps protect application headers but allows for application data helps protect application headers but allows for application data
errors. Some applications are impacted more by a lack of data than errors. Some applications are impacted more by a lack of data than
skipping to change at page 11, line 25 skipping to change at page 11, line 41
At the sender, the option is formed using the following steps: At the sender, the option is formed using the following steps:
1. Create a LITE option, ordered as the first UDP option (Figure 1. Create a LITE option, ordered as the first UDP option (Figure
10). 10).
2. Calculate the location of the start of the options as an absolute 2. Calculate the location of the start of the options as an absolute
offset from the start of the UDP header and place that length in offset from the start of the UDP header and place that length in
the last two bytes of the LITE option. the last two bytes of the LITE option.
3. Swap all four bytes of the LITE option with the first 4 bytes of 3. If the LITE data area is 4 bytes or longer, swap all four bytes
the LITE data area (Figure 11). of the LITE option with the first 4 bytes of the LITE data area
(Figure 11). If the LITE data area is 0-3 bytes long, slide the
LITE option to the front of the LITE data area (i.e., placing the
0-3 bytes of LITE data after the LITE option).
+---------+--------------+--------------+------------------+ +---------+--------------+--------------+------------------+
| UDP Hdr | user data | LITE data |LITE| other opts | | UDP Hdr | user data | LITE data |LITE| other opts |
+---------+--------------+--------------+------------------+ +---------+--------------+--------------+------------------+
<----------------------> <---------------------->
UDP Length UDP Length
Figure 10 LITE option formation - LITE goes first Figure 10 LITE option formation - LITE goes first
+---------+--------------+--------------+------------------+ +---------+--------------+--------------+------------------+
skipping to change at page 14, line 21 skipping to change at page 14, line 40
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Kind=8 | Len=8 | Frag. Offset | | Kind=8 | Len=8 | Frag. Offset |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Identification | | Identification |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 15 UDP non-terminal FRAG option format Figure 15 UDP non-terminal FRAG option format
The FRAG option also lacks a "more" bit, zeroed for the terminal The FRAG option also lacks a "more" bit, zeroed for the terminal
fragment of a set. This is possible because the terminal FRAG option fragment of a set. This is possible because the terminal FRAG option
is indicated as a longer, 12-byte variant, which includes an is indicated as a longer, 10-byte variant, which includes an
Internet checksum over the reassembled payload (omitting the IP Internet checksum over the entire reassembled UDP payload (omitting
pseudoheader and UDP header, as well as UDP options), as shown in the IP pseudoheader and UDP header, as well as UDP options), as
Figure 16. shown in Figure 16.
>> The reassembly checksum SHOULD be used, but MAY be unused in the >> The reassembly checksum SHOULD be used, but MAY be unused in the
same situations when the UDP checksum is unused (e.g., for transit same situations when the UDP checksum is unused (e.g., for transit
tunnels or applications that have their own integrity checks tunnels or applications that have their own integrity checks
[RFC8200]), and by the same mechanism (set the field to 0x0000). [RFC8200]), and by the same mechanism (set the field to 0x0000).
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Kind=8 | Len=12 | Frag. Offset | | Kind=8 | Len=12 | Frag. Offset |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Identification | | Identification |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Checksum | | Checksum |
+--------+--------+ +--------+--------+
Figure 16 UDP terminal FRAG option format Figure 16 UDP terminal FRAG option format
>> During fragmentation, the UDP header checksum of each fragment
needs to be recomputed based on each datagram's pseudoheader.
>> After reassembly is complete and validated using the checksum of
the terminal FRAG option, the UDP header checksum of the resulting
datagram needs to be recomputed based on the datagram's
pseudoheader.
The Fragment Offset is 16 bits and indicates the location of the UDP The Fragment Offset is 16 bits and indicates the location of the UDP
payload fragment in bytes from the beginning of the original payload fragment in bytes from the beginning of the original
unfragmented payload. The Len field indicates whether there are more unfragmented payload. The Len field indicates whether there are more
fragments (Len=8) or no more fragments (Len=12). fragments (Len=8) or no more fragments (Len=12).
>> The Identification field is a 32-bit value that MUST be unique >> The Identification field is a 32-bit value that MUST be unique
over the expected fragment reassembly timeout. over the expected fragment reassembly timeout.
>> The Identification field SHOULD be generated in a manner similar >> The Identification field SHOULD be generated in a manner similar
to that of the IPv6 Fragment ID [RFC8200]. to that of the IPv6 Fragment ID [RFC8200].
skipping to change at page 17, line 16 skipping to change at page 17, line 41
endpoints have populated Master Key Tuples (MKTs), used to exclude endpoints have populated Master Key Tuples (MKTs), used to exclude
non-protected traffic. non-protected traffic.
TCP-AO generates unique traffic keys from a hash of TCP connection TCP-AO generates unique traffic keys from a hash of TCP connection
parameters. UDP lacks a three-way handshake to coordinate parameters. UDP lacks a three-way handshake to coordinate
connection-specific values, such as TCP's Initial Sequence Numbers connection-specific values, such as TCP's Initial Sequence Numbers
(ISNs) [RFC793], thus UDP-AE's Key Derivation Function (KDF) uses (ISNs) [RFC793], thus UDP-AE's Key Derivation Function (KDF) uses
zeroes as the value for both ISNs. This means that the UDP-AE reuses zeroes as the value for both ISNs. This means that the UDP-AE reuses
keys when socket pairs are reused, unlike TCP-AO. keys when socket pairs are reused, unlike TCP-AO.
UDP-AE can be configured to either include or exclude TCP options, UDP-AE can be configured to either include or exclude UDP options,
the same way as can TCP-AO. When UDP options are covered, the ACS the same way as can TCP-AO. When UDP options are covered, the OCS
option area checksum and UDP-AE hash areas are zeroed before option area checksum and UDP-AE hash areas are zeroed before
computing the AE hash. It is important to consider that options not computing the UDP-AE hash. It is important to consider that options
yet defined might yield unpredictable results if not confirmed as not yet defined might yield unpredictable results if not confirmed
supported, e.g., if they contain other hashes or checksums that as supported, e.g., if they were to contain other hashes or
depend on the option area contents. checksums that depend on the option area contents. This is why such
dependencies are not permitted except as defined for OCS and UDP-AE.
Similar to TCP-AO-NAT, UDP-AE can be configured to support NAT Similar to TCP-AO-NAT, UDP-AE can be configured to support NAT
traversal, excluding one or both of the UDP ports [RFC6978]. traversal, excluding one or both of the UDP ports [RFC6978].
5.10. Experimental (EXP) 5.10. Experimental (EXP)
The Experimental option (EXP) is reserved for experiments [RFC3692]. The Experimental option (EXP) is reserved for experiments [RFC3692].
Only one such value is reserved because experiments are expected to Only one such value is reserved because experiments are expected to
use an Experimental ID (ExIDs) to differentiate concurrent use for use an Experimental ID (ExIDs) to differentiate concurrent use for
different purposes, using UDP ExIDs registered with IANA according different purposes, using UDP ExIDs registered with IANA according
skipping to change at page 19, line 7 skipping to change at page 19, line 36
UDP options are intended for use only by the transport endpoints. UDP options are intended for use only by the transport endpoints.
They are no more (or less) appropriate to be modified in-transit They are no more (or less) appropriate to be modified in-transit
than any other portion of the transport datagram. than any other portion of the transport datagram.
UDP options are transport options. Generally, transport datagrams UDP options are transport options. Generally, transport datagrams
are not intended to be modified in-transit. However, the UDP option are not intended to be modified in-transit. However, the UDP option
mechanism provides no specific protection against in-transit mechanism provides no specific protection against in-transit
modification of the UDP header, UDP payload, or UDP option area, modification of the UDP header, UDP payload, or UDP option area,
except as provided by the options selected (e.g., OCS, ACS, or AE). except as provided by the options selected (e.g., OCS, ACS, or AE).
8. UDP options vs. UDP-Lite 8. UDP options LITE option vs. UDP-Lite
UDP-Lite provides partial checksum coverage, so that packets with UDP-Lite provides partial checksum coverage, so that packets with
errors in some locations can be delivered to the user [RFC3828]. It errors in some locations can be delivered to the user [RFC3828]. It
uses a different transport protocol number (136) than UDP (17) to uses a different transport protocol number (136) than UDP (17) to
interpret the UDP Length field as the prefix covered by the UDP interpret the UDP Length field as the prefix covered by the UDP
checksum. checksum.
UDP (protocol 17) already defines the UDP Length field as the limit UDP (protocol 17) already defines the UDP Length field as the limit
of the UDP checksum, but by default also limits the data provided to of the UDP checksum, but by default also limits the data provided to
the application as that which precedes the UDP Length. A goal of the application as that which precedes the UDP Length. A goal of
UDP-Lite is to deliver data beyond UDP Length as a default, which is UDP-Lite is to deliver data beyond UDP Length as a default, which is
why a separate transport protocol number was required. why a separate transport protocol number was required.
UDP options do not need a separate transport protocol number because UDP options do not use or need a separate transport protocol number
the data beyond the UDP Length offset (surplus data) is not provided because the data beyond the UDP Length offset (surplus data) is not
to the application by default. That data is interpreted exclusively provided to the application by default. That data is interpreted
within the UDP transport layer. exclusively within the UDP transport layer.
UDP options support a similar service to UDP-Lite by terminating the The LITE UDP options option supports a similar service to UDP-Lite.
UDP options with an EOL option. The additional data not covered by The main difference is that UDP-Lite provides the un-checksummed
the UDP checksum follows that EOL option, and is passed to the user user data to the application by default, whereas the LITE UDP option
separately. The difference is that UDP-Lite provides the un- can safely provide that service only between endpoints that
checksummed user data to the application by default, whereas UDP negotiate that capability in advance. An endpoint that does not
options can provide the same capability only for endpoints that are implement UDP options would silently discard this non-checksummed
negotiated in advance (i.e., by default, UDP options would silently user data, along with the UDP options as well.
discard this non-checksummed data). Additionally, in UDP-Lite the
checksummed and non-checksummed payload components are adjacent,
whereas in UDP options they are separated by the option area -
which, minimally, must consist of at least one EOL option.
UDP-Lite cannot support UDP options, either as proposed here or in UDP-Lite cannot support UDP options, either as proposed here or in
any other form, because the entire payload of the UDP packet is any other form, because the entire payload of the UDP packet is
already defined as user data and there is no additional field in already defined as user data and there is no additional field in
which to indicate a separate area for options. The UDP Length field which to indicate a separate area for options. The UDP Length field
in UDP-Lite is already used to indicate the boundary between user in UDP-Lite is already used to indicate the boundary between user
data covered by the checksum and user data not covered. data covered by the checksum and user data not covered.
9. Interactions with Legacy Devices 9. Interactions with Legacy Devices
skipping to change at page 20, line 4 skipping to change at page 20, line 28
which to indicate a separate area for options. The UDP Length field which to indicate a separate area for options. The UDP Length field
in UDP-Lite is already used to indicate the boundary between user in UDP-Lite is already used to indicate the boundary between user
data covered by the checksum and user data not covered. data covered by the checksum and user data not covered.
9. Interactions with Legacy Devices 9. Interactions with Legacy Devices
It has always been permissible for the UDP Length to be inconsistent It has always been permissible for the UDP Length to be inconsistent
with the IP transport payload length [RFC768]. Such inconsistency with the IP transport payload length [RFC768]. Such inconsistency
has been utilized in UDP-Lite using a different transport number. has been utilized in UDP-Lite using a different transport number.
There are no known systems that use this inconsistency for UDP There are no known systems that use this inconsistency for UDP
[RFC3828]. It is possible that such use might interact with UDP [RFC3828]. It is possible that such use might interact with UDP
options, i.e., where legacy systems might generate UDP datagrams options, i.e., where legacy systems might generate UDP datagrams
that appear to have UDP options. The UDP OCS provides protection that appear to have UDP options. The UDP OCS provides protection
against such events and is stronger than a static "magic number". against such events and is stronger than a static "magic number".
UDP options have been tested as interoperable with Linux, Max OS-X, UDP options have been tested as interoperable with Linux, macOS, and
and Windows Cygwin, and worked through NAT devices. These systems Windows Cygwin, and worked through NAT devices. These systems
successfully delivered only the user data indicated by the UDP successfully delivered only the user data indicated by the UDP
Length field and silently discarded the surplus area. Length field and silently discarded the surplus area.
One reported embedded device passes the entire IP datagram to the One reported embedded device passes the entire IP datagram to the
UDP application layer. Although this feature could enable UDP application layer. Although this feature could enable
application-layer UDP option processing, it would require that application-layer UDP option processing, it would require that
conventional UDP user applications examine only the UDP payload. conventional UDP user applications examine only the UDP payload.
This feature is also inconsistent with the UDP application interface This feature is also inconsistent with the UDP application interface
[RFC768] [RFC1122]. [RFC768] [RFC1122].
skipping to change at page 21, line 19 skipping to change at page 21, line 43
Some TCP connection parameters, stored in the TCP Control Block, can Some TCP connection parameters, stored in the TCP Control Block, can
be usefully shared either among concurrent connections or between be usefully shared either among concurrent connections or between
connections in sequence, known as TCP Sharing [RFC2140][To18cb]. connections in sequence, known as TCP Sharing [RFC2140][To18cb].
Although UDP is stateless, some of the options proposed herein may Although UDP is stateless, some of the options proposed herein may
have similar benefit in being shared or cached. We call this UCB have similar benefit in being shared or cached. We call this UCB
Sharing, or UDP Control Block Sharing, by analogy. Sharing, or UDP Control Block Sharing, by analogy.
[TBD: extend this section to indicate which options MAY vs. MUST NOT [TBD: extend this section to indicate which options MAY vs. MUST NOT
be shared and how, e.g., along the lines of To18cb] be shared and how, e.g., along the lines of To18cb]
Updates to RFC 768 12. Updates to RFC 768
This document updates RFC 768 as follows: This document updates RFC 768 as follows:
o This document defines the meaning of the IP payload area beyond o This document defines the meaning of the IP payload area beyond
the UDP length but within the IP length. the UDP length but within the IP length.
o This document extends the UDP API to support the use of options. o This document extends the UDP API to support the use of options.
12. Multicast Considerations 13. Multicast Considerations
UDP options are primarily intended for unicast use. Using these UDP options are primarily intended for unicast use. Using these
options over multicast IP requires careful consideration, e.g., to options over multicast IP requires careful consideration, e.g., to
ensure that the options used are safe for different endpoints to ensure that the options used are safe for different endpoints to
interpret differently (e.g., either to support or silently ignore) interpret differently (e.g., either to support or silently ignore)
or to ensure that all receivers of a multicast group confirm support or to ensure that all receivers of a multicast group confirm support
for the options in use. for the options in use.
13. Security Considerations 14. Security Considerations
The use of UDP packets with inconsistent IP and UDP Length fields The use of UDP packets with inconsistent IP and UDP Length fields
has the potential to trigger a buffer overflow error if not properly has the potential to trigger a buffer overflow error if not properly
handled, e.g., if space is allocated based on the smaller field and handled, e.g., if space is allocated based on the smaller field and
copying is based on the larger. However, there have been no reports copying is based on the larger. However, there have been no reports
of such vulnerability and it would rely on inconsistent use of the of such vulnerability and it would rely on inconsistent use of the
two fields for memory allocation and copying. two fields for memory allocation and copying.
UDP options are not covered by DTLS (datagram transport-layer UDP options are not covered by DTLS (datagram transport-layer
security). Despite the name, neither TLS [RFC5246] (transport layer security). Despite the name, neither TLS [RFC5246] (transport layer
skipping to change at page 22, line 16 skipping to change at page 22, line 40
document. Transport security is provided in TCP by the TCP document. Transport security is provided in TCP by the TCP
Authentication Option (TCP-AO [RFC5925]) or in UDP by the Authentication Option (TCP-AO [RFC5925]) or in UDP by the
Authentication Extension option (Section 5.9). Transport headers are Authentication Extension option (Section 5.9). Transport headers are
also protected as payload when using IP security (IPsec) [RFC4301]. also protected as payload when using IP security (IPsec) [RFC4301].
UDP options use the TLV syntax similar to that of TCP. This syntax UDP options use the TLV syntax similar to that of TCP. This syntax
is known to require serial processing and may pose a DOS risk, e.g., is known to require serial processing and may pose a DOS risk, e.g.,
if an attacker adds large numbers of unknown options that must be if an attacker adds large numbers of unknown options that must be
parsed in their entirety. Implementations concerned with the parsed in their entirety. Implementations concerned with the
potential for this vulnerability MAY implement only the required potential for this vulnerability MAY implement only the required
options and MAY also limit NOPs (e.g., no more than three options and MAY also limit processing of TLVs. Because required
consecutive NOPs or some total number that might occur between the options come first and at most once each (with the exception of
required options, if all are present). Because the required options NOPs, which should never need to come in sequences of more than
come first and at most once each (and all later duplicates silently three in a row), this limits their DOS impact. Note that when a
ignored), this limits the DOS impact. packet's options cannot be processed, it MUST be discarded; the
packet and its options should always share the same fate.
14. IANA Considerations 15. IANA Considerations
Upon publication, IANA is hereby requested to create a new registry Upon publication, IANA is hereby requested to create a new registry
for UDP Option Kind numbers, similar to that for TCP Option Kinds. for UDP Option Kind numbers, similar to that for TCP Option Kinds.
Initial values of this registry are as listed in Section 5. Initial values of this registry are as listed in Section 5.
Additional values in this registry are to be assigned by IESG Additional values in this registry are to be assigned by IESG
Approval or Standards Action [RFC8126]. Approval or Standards Action [RFC8126].
Upon publication, IANA is hereby requested to create a new registry Upon publication, IANA is hereby requested to create a new registry
for UDP Experimental Option Experiment Identifiers (UDP ExIDs) for for UDP Experimental Option Experiment Identifiers (UDP ExIDs) for
use in a similar manner as TCP ExIDs [RFC6994]. This registry is use in a similar manner as TCP ExIDs [RFC6994]. This registry is
initially empty. Values in this registry are to be assigned by IANA initially empty. Values in this registry are to be assigned by IANA
using first-come, first-served (FCFS) rules [RFC8126]. using first-come, first-served (FCFS) rules [RFC8126].
15. References 16. References
15.1. Normative References 16.1. Normative References
[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.
[RFC768] Postel, J., "User Datagram Protocol", RFC 768, August [RFC768] Postel, J., "User Datagram Protocol", RFC 768, August
1980. 1980.
[RFC791] Postel, J., "Internet Protocol," RFC 791, Sept. 1981. [RFC791] Postel, J., "Internet Protocol," RFC 791, Sept. 1981.
15.2. Informative References [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts --
Communication Layers," RFC 1122, Oct. 1989.
16.2. Informative References
[Hi15] Hildebrand, J., B. Trammel, "Substrate Protocol for User [Hi15] Hildebrand, J., B. Trammel, "Substrate Protocol for User
Datagrams (SPUD) Prototype," draft-hildebrand-spud- Datagrams (SPUD) Prototype," draft-hildebrand-spud-
prototype-03, Mar. 2015. prototype-03, Mar. 2015.
[RFC793] Postel, J., "Transmission Control Protocol" RFC 793, [RFC793] Postel, J., "Transmission Control Protocol" RFC 793,
September 1981. September 1981.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts --
Communication Layers," RFC 1122, Oct. 1989.
[RFC1191] Mogul, J., S. Deering, "Path MTU discovery," RFC 1191, [RFC1191] Mogul, J., S. Deering, "Path MTU discovery," RFC 1191,
November 1990. November 1990.
[RFC2140] Touch, J., "TCP Control Block Interdependence," RFC 2140, [RFC2140] Touch, J., "TCP Control Block Interdependence," RFC 2140,
Apr. 1997. Apr. 1997.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery," RFC [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery," RFC
2923, September 2000. 2923, September 2000.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
skipping to change at page 24, line 42 skipping to change at page 25, line 16
Payload Encryption", draft-touch-tcp-ao-encrypt, Jan. Payload Encryption", draft-touch-tcp-ao-encrypt, Jan.
2018. 2018.
[To18cb] Touch, J., M. Welzl, S. Islam, J. You, "TCP Control Block [To18cb] Touch, J., M. Welzl, S. Islam, J. You, "TCP Control Block
Interdependence," draft-touch-tcpm-2140bis, Jan. 2018. Interdependence," draft-touch-tcpm-2140bis, Jan. 2018.
[Tr16] Trammel, B. (Ed.), M. Kuelewind (Ed.), "Requirements for [Tr16] Trammel, B. (Ed.), M. Kuelewind (Ed.), "Requirements for
the design of a Substrate Protocol for User Datagrams the design of a Substrate Protocol for User Datagrams
(SPUD)," draft-trammell-spud-req-04, May 2016. (SPUD)," draft-trammell-spud-req-04, May 2016.
16. Acknowledgments 17. Acknowledgments
This work benefitted from feedback from Bob Briscoe, Ken Calvert, This work benefitted from feedback from Bob Briscoe, Ken Calvert,
Ted Faber, Gorry Fairhurst, C. M. Heard (including the FRAG/LITE Ted Faber, Gorry Fairhurst, C. M. Heard (including the FRAG/LITE
combination), Tom Herbert, and Mark Smith, as well as discussions on combination), Tom Herbert, and Mark Smith, as well as discussions on
the IETF TSVWG and SPUD email lists. the IETF TSVWG and SPUD email lists.
This work is partly supported by USC/ISI's Postel Center. This work is partly supported by USC/ISI's Postel Center.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
 End of changes. 39 change blocks. 
92 lines changed or deleted 119 lines changed or added

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