draft-ietf-tsvwg-udp-options-09.txt   draft-ietf-tsvwg-udp-options-10.txt 
TSVWG J. Touch TSVWG J. Touch
Internet Draft Independent consultant Internet Draft Independent consultant
Intended status: Standards Track November 25, 2020 Intended status: Standards Track May 1, 2021
Intended updates: 768, 3095 Intended updates: 768
Expires: May 2021 Expires: November 2021
Transport Options for UDP Transport Options for UDP.txt
draft-ietf-tsvwg-udp-options-09.txt
Status of this Memo Status of this Memo draft-ietf-tsvwg-udp-options-10
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
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-
skipping to change at page 1, line 35 skipping to change at page 1, line 34
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 May 25, 2021. This Internet-Draft will expire on November 1, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
skipping to change at page 2, line 28 skipping to change at page 2, line 27
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....................................................8 5. UDP Options....................................................8
5.1. End of Options List (EOL).................................9 5.1. End of Options List (EOL).................................9
5.2. No Operation (NOP).......................................10 5.2. No Operation (NOP).......................................10
5.3. Option Checksum (OCS)....................................10 5.3. Option Checksum (OCS)....................................10
5.4. Alternate Checksum (ACS).................................12 5.4. Alternate Checksum (ACS).................................12
5.5. Fragmentation (FRAG).....................................13 5.5. Fragmentation (FRAG).....................................13
5.6. Maximum Segment Size (MSS)...............................17 5.6. Maximum Segment Size (MSS)...............................17
5.7. Unsafe (UNSAFE)..........................................17 5.7. Maximum Reassembled Segment Size (MRSS)..................17
5.8. Timestamps (TIME)........................................18 5.8. Unsafe (UNSAFE)..........................................18
5.9. Authentication and Encryption (AE).......................19 5.9. Timestamps (TIME)........................................19
5.10. Echo request (REQ) and echo response (RES)..............20 5.10. Authentication and Encryption (AE)......................20
5.11. Experimental (EXP)......................................21 5.11. Echo request (REQ) and echo response (RES)..............21
6. Rules for designing new options...............................21 5.12. Experimental (EXP)......................................21
7. Option inclusion and processing...............................22 6. Rules for designing new options...............................22
8. UDP API Extensions............................................24 7. Option inclusion and processing...............................23
8. UDP API Extensions............................................25
9. Whose options are these?......................................25 9. Whose options are these?......................................25
10. UDP options FRAG option vs. UDP-Lite.........................25 10. UDP options FRAG option vs. UDP-Lite.........................26
11. Interactions with Legacy Devices.............................26 11. Interactions with Legacy Devices.............................27
12. Options in a Stateless, Unreliable Transport Protocol........27 12. Options in a Stateless, Unreliable Transport Protocol........27
13. UDP Option State Caching.....................................27 13. UDP Option State Caching.....................................28
14. Updates to RFC 768...........................................28 14. Updates to RFC 768...........................................28
15. Interactions with other RFCs (and drafts)....................28 15. Interactions with other RFCs (and drafts)....................28
16. Multicast Considerations.....................................29 16. Multicast Considerations.....................................30
17. Security Considerations......................................30 17. Security Considerations......................................30
18. IANA Considerations..........................................31 18. IANA Considerations..........................................31
19. References...................................................31 19. References...................................................32
19.1. Normative References....................................31 19.1. Normative References....................................32
19.2. Informative References..................................32 19.2. Informative References..................................32
20. Acknowledgments..............................................34 20. Acknowledgments..............................................34
Appendix A. Implementation Information...........................35 Appendix A. Implementation Information...........................36
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 extension to UDP that provides space for This document defines an extension to UDP that provides space for
transport options including their generic syntax and semantics for transport options including their generic syntax and semantics for
their use in UDP's stateless, unreliable message protocol. their use in UDP's stateless, unreliable message protocol.
skipping to change at page 4, line 7 skipping to change at page 4, line 7
sequence of packets as well. This document is intended to provide an sequence of packets as well. This document is intended to provide an
out-of-band option area as an alternative to the in-band mechanism out-of-band option area as an alternative to the in-band mechanism
currently proposed [Hi15]. currently proposed [Hi15].
UDP is one of the most popular protocols that lacks space for UDP is one of the most popular protocols that lacks space for
options [RFC768]. The UDP header was intended to be a minimal options [RFC768]. The UDP header was intended to be a minimal
addition to IP, providing only ports and a data checksum for addition to IP, providing only ports and a data checksum for
protection. This document extends UDP to provide a trailer area for protection. This document extends UDP to provide a trailer area for
options located after the UDP data payload. options located after the UDP data payload.
This extension is possible because UDP includes its own length
field, separate from that of the IP header. SCTP includes its own
length field, one for each chunk. TCP and DCCP lack this transport
length field, inferring it from the IP length. There are a number of
suggested reasons why UDP includes this field, notably to support
multiple UDP segments in the same IP packet or to indicate the
length of the UDP payload as distinct from zero padding required for
systems that require writes that are not byte-alighed. These
suggestions are not consistent with earlier versions of UDP or with
concurrent design of multi-segment multiplexing protocols, however.
4. The UDP Option Area 4. The UDP Option Area
The UDP transport header includes demultiplexing and service The UDP transport header includes demultiplexing and service
identification (port numbers), a checksum, and a field that identification (port numbers), a checksum, and a field that
indicates the UDP datagram length (including UDP header). The UDP indicates the UDP datagram length (including UDP header). The UDP
Length field is typically redundant with the size of the maximum Length field is typically redundant with the size of the maximum
space available as a transport protocol payload (see also discussion space available as a transport protocol payload (see also discussion
in Section 11). in Section 11).
For IPv4, IP Total Length field indicates the total IP datagram For IPv4, IP Total Length field indicates the total IP datagram
skipping to change at page 8, line 17 skipping to change at page 8, line 17
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* 3 Option checksum (OCS) 2* 3 Option checksum (OCS)
3* 6 Alternate checksum (ACS) 3* 6 Alternate checksum (ACS)
4* 10/12 Fragmentation (FRAG) 4* 10/12 Fragmentation (FRAG)
5* 4 Maximum segment size (MSS) 5* 4 Maximum segment size (MSS)
6* (varies) Unsafe to ignore (UNSAFE) options 6* 4 Maximum reassembled segment size (MRSS)
7 10 Timestamps (TIME) 7* (varies) Unsafe to ignore (UNSAFE) options
8 (varies) Authentication and Encryption (AE) 8 10 Timestamps (TIME)
9 6 Request (REQ) 9 (varies) Authentication and Encryption (AE)
10 6 Response (RES) 10 6 Request (REQ)
11-126 (varies) UNASSIGNED (assignable by IANA) 11 6 Response (RES)
12-126 (varies) UNASSIGNED (assignable by IANA)
127-253 RESERVED 127-253 RESERVED
254 (varies) RFC 3692-style experiments (EXP) 254 (varies) RFC 3692-style experiments (EXP)
255 RESERVED 255 RESERVED
These options are defined in the following subsections. Options 0 These options are defined in the following subsections. Options 0
and 1 use the same values as for TCP. and 1 use the same values as for TCP.
>> An endpoint supporting UDP options MUST support those marked with >> An endpoint supporting UDP options MUST support those marked with
a "*" above: EOL, NOP, OCS, ACS, FRAG, MSS, and UNSAFE. This a "*" above: EOL, NOP, OCS, ACS, FRAG, MSS, MRSS, and UNSAFE. This
includes both recognizing and being able to generate these options includes both recognizing and being able to generate these options
if configured to do so. These are called "must-support" options. if configured to do so. These are called "must-support" options.
>> 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 supporting UDP options MUST silently ignore unknown >> Receivers supporting UDP options MUST silently ignore unknown
options except UNSAFE. That includes options whose length does not options except UNSAFE. That includes options whose length does not
indicate the specified value(s). indicate the specified value(s).
>> Receivers supporting UDP options MUST silently drop the entire >> Receivers supporting UDP options MUST silently drop the entire
datagram containing an UNSAFE option when any UNSAFE option it datagram containing an UNSAFE option when any UNSAFE option it
contains is unknown. See Section 5.7 for further discussion of contains is unknown. See Section 5.8 for further discussion of
UNSAFE options. UNSAFE options.
>> Except for NOP, each option SHOULD NOT occur more than once in a >> Except for NOP, each option SHOULD NOT occur more than once in a
single UDP datagram. If an option other than NOP occurs more than single UDP datagram. If an option other than NOP occurs more than
once, a receiver MUST interpret only the first instance of that once, a receiver MUST interpret only the first instance of that
option and MUST ignore all others. option and MUST ignore all others.
>> Only the OCS and AE options depend on the contents of the option >> 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 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 zero; OCS is always computed as if the OCS checksum is zero and
skipping to change at page 10, line 17 skipping to change at page 10, line 17
>> All bytes in the surplus area after EOL MUST be zero. If these >> All bytes in the surplus area after EOL MUST be zero. If these
bytes are non-zero, the entire surplus area MUST be silently ignored bytes are non-zero, the entire surplus area MUST be silently ignored
and only the UDP data passed to the user with an adjusted UDP length and only the UDP data passed to the user with an adjusted UDP length
to indicate that no options were present. to indicate that no options were present.
Requiring the post-option surplus area to be zero prevents side- Requiring the post-option surplus area to be zero prevents side-
channel uses of this area, requiring instead that all use of the channel uses of this area, requiring instead that all use of the
surplus area be UDP options supported by both endpoints. It is surplus area be UDP options supported by both endpoints. It is
useful to allow for such padding to increase the packet length useful to allow for such padding to increase the packet length
without affecting the payload length, e.g., for UDP DPLPMTUD [Fa20]. without affecting the payload length, e.g., for UDP DPLPMTUD [Fa21].
5.2. No Operation (NOP) 5.2. No Operation (NOP)
The No Operation (NOP) option is a one byte placeholder, intended to The No Operation (NOP) option is a one byte placeholder, intended to
be used as padding, e.g., to align multi-byte options along 16-bit be used as padding, e.g., to align multi-byte options along 16-bit
or 32-bit boundaries. or 32-bit boundaries.
+--------+ +--------+
| Kind=1 | | Kind=1 |
+--------+ +--------+
skipping to change at page 17, line 7 skipping to change at page 17, line 7
be zero-copied>> be zero-copied>>
Receivers reverse the above sequence. They process all received Receivers reverse the above sequence. They process all received
options in each fragment. When the FRAG option is encountered, the options in each fragment. When the FRAG option is encountered, the
FRAG data is used in reassembly. After all fragments are received, FRAG data is used in reassembly. After all fragments are received,
the entire packet is processed with any trailing UDP options the entire packet is processed with any trailing UDP options
applying to the reassembled data. applying to the reassembled data.
5.6. Maximum Segment Size (MSS) 5.6. Maximum Segment Size (MSS)
The Maximum Segment Size (MSS, Kind = 3) option is a 16-bit The Maximum Segment Size (MSS, Kind = 5) option is a 16-bit hint of
indicator of the largest UDP segment that can be received. As with the largest unfragmented UDP segment that an endpoint believes can
the TCP MSS option [RFC793], the size indicated is the IP layer MTU be received. As with the TCP MSS option [RFC793], the size indicated
decreased by the fixed IP and UDP headers only [RFC6691]. The space is the IP layer MTU decreased by the fixed IP and UDP headers only
needed for IP and UDP options need to be adjusted by the sender when [RFC6691]. The space needed for IP and UDP options need to be
using the value indicated. The value transmitted is based on EMTU_R, adjusted by the sender when using the value indicated. The value
the largest IP datagram that can be received (i.e., reassembled at transmitted is based on EMTU_R, the largest IP datagram that can be
the receiver) [RFC1122]. received (i.e., reassembled at the receiver) [RFC1122]. However, as
with TCP, this value is only a hint at what the receiver believes;
it does not indicate a known path MTU and thus MUST NOT be used to
limit transmissions, notably for DPLPMTU probes.
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Kind=5 | Len=4 | MSS size | | Kind=5 | Len=4 | MSS size |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 13 UDP MSS option format Figure 13 UDP MSS option format
The UDP MSS option MAY be used for path MTU discovery The UDP MSS option MAY be used as a hint for path MTU discovery
[RFC1191][RFC8201], but this may be difficult because of known [RFC1191][RFC8201], but this may be difficult because of known
issues with ICMP blocking [RFC2923] as well as UDP lacking automatic issues with ICMP blocking [RFC2923] as well as UDP lacking automatic
retransmission. It is more likely to be useful when coupled with IP retransmission. It is more likely to be useful when coupled with IP
source fragmentation to limit the largest reassembled UDP message, source fragmentation to limit the largest reassembled UDP message as
e.g., when EMTU_R is larger than the required minimums (576 for IPv4 indicated by MRSS (see Section 5.7), e.g., when EMTU_R is larger
[RFC791] and 1500 for IPv6 [RFC8200]). It can also be used with than the required minimums (576 for IPv4 [RFC791] and 1500 for IPv6
DPLPMTUD [RFC8899] to set a maximum DPLPMTU. [RFC8200]). It can also be used with DPLPMTUD [RFC8899] to provide a
hint to maximum DPLPMTU, though it MUST NOT prohibit transmission of
larger UDP packets (or fragments) used as DPLPMTU probes.
5.7. Unsafe (UNSAFE) 5.7. Maximum Reassembled Segment Size (MRSS)
The Maximum Reassembled Segment Size (MRSS, Kind=6) option is a 16-
bit indicator of the largest reassembled UDP segment that can be
received. MRSS is the UDP equivalent of IP's EMTU_R but the two are
not related [RFC1122]. Using the FRAG option (Section 5.5), UDP
segments can be transmitted as fragments in multiple IP datagrams
and be reassembled larger than the IP layer allows.
+--------+--------+--------+--------+
| Kind=6 | Len=4 | MRSS size |
+--------+--------+--------+--------+
Figure 14 UDP MRSS option format
5.8. Unsafe (UNSAFE)
The Unsafe option (UNSAFE) extends the UDP option space to allow for The Unsafe option (UNSAFE) extends the UDP option space to allow for
options that are not safe to ignore and can be used unidirectionally options that are not safe to ignore and can be used unidirectionally
or without soft-state confirmation of UDP option capability. They or without soft-state confirmation of UDP option capability. They
are always used only when the entire UDP payload occurs inside a are always used only when the entire UDP payload occurs inside a
reassembled set of UDP fragments, such that if UDP fragmentation is reassembled set of UDP fragments, such that if UDP fragmentation is
not supported, the entire fragment would be silently dropped anyway. not supported, the entire fragment would be silently dropped anyway.
UNSAFE options are an extended option space, with its own additional UNSAFE options are an extended option space, with its own additional
option types. These are indicated in the first byte after the option option types. These are indicated in the first byte after the option
Kind as shown in ?, which is followed by the Length. Length is 1 Kind as shown in Figure 15, which is followed by the Length. Length
byte for UKinds whose total length (including Kind, UKind, and is 1 byte for UKinds whose total length (including Kind, UKind, and
Length fields) is less than 255 or 2 bytes for larger lengths (in Length fields) is less than 255 or 2 bytes for larger lengths (in
the similar style as the extended option format). the similar style as the extended option format).
+--------+--------+--------+ +--------+--------+--------+
| Kind=6 | UKind | Length |... | Kind=7 | UKind | Length |...
+--------+--------+--------+ +--------+--------+--------+
1 byte 1 byte 1-2 bytes 1 byte 1 byte 1-2 bytes
Figure 14 UDP UNSAFE option format Figure 15 UDP UNSAFE option format
>> UNSAFE options MUST be used only as part of UDP fragments, used >> UNSAFE options MUST be used only as part of UDP fragments, used
either per-fragment or after reassembly. either per-fragment or after reassembly.
>> Receivers supporting UDP options MUST silently drop the entire >> Receivers supporting UDP options MUST silently drop the entire
reassembled datagram if any fragment or the entire datagram includes reassembled datagram if any fragment or the entire datagram includes
an UNSAFE option whose UKind is not supported. an UNSAFE option whose UKind is not supported.
The following UKind values are defined: The following UKind values are defined:
UKind Length Meaning UKind Length Meaning
---------------------------------------------- ----------------------------------------------
0 RESERVED 0 RESERVED
1-253 (varies) UNASSIGNED (assignable by IANA) 1-253 (varies) UNASSIGNED (assignable by IANA)
254 (varies) RFC 3692-style experiments (UEXP) 254 (varies) RFC 3692-style experiments (UEXP)
255 RESERVED 255 RESERVED
Experimental UKind EXP ExID values indicate the ExID in the Experimental UKind EXP ExID values indicate the ExID in the
following 2 (or 4) bytes, similar to the UDP EXP option as discussed following 2 (or 4) bytes, similar to the UDP EXP option as discussed
in Section 5.11. Assigned UDP EXP ExIDs and UDP UNSAFE UKind UEXP in Section 5.12. Assigned UDP EXP ExIDs and UDP UNSAFE UKind UEXP
ExIDs are assigned from the same registry and can be used either in ExIDs are assigned from the same registry and can be used either in
the EXP option (Section 5.11) or within the UKind UEXP. the EXP option (Section 5.12) or within the UKind UEXP.
5.8. Timestamps (TIME) 5.9. Timestamps (TIME)
The Timestamp (TIME) option exchanges two four-byte timestamp The Timestamp (TIME) option exchanges two four-byte timestamp
fields. It serves a similar purpose to TCP's TS option [RFC7323], fields. It serves a similar purpose to TCP's TS option [RFC7323],
enabling UDP to estimate the round trip time (RTT) between hosts. enabling UDP to estimate the round trip time (RTT) between hosts.
For UDP, this RTT can be useful for establishing UDP fragment For UDP, this RTT can be useful for establishing UDP fragment
reassembly timeouts or transport-layer rate-limiting [RFC8085]. reassembly timeouts or transport-layer rate-limiting [RFC8085].
+--------+--------+------------------+------------------+ +--------+--------+------------------+------------------+
| Kind=7 | Len=10 | TSval | TSecr | | Kind=8 | Len=10 | TSval | TSecr |
+--------+--------+------------------+------------------+ +--------+--------+------------------+------------------+
1 byte 1 byte 4 bytes 4 bytes 1 byte 1 byte 4 bytes 4 bytes
Figure 15 UDP TIME option format Figure 16 UDP TIME option format
TS Value (TSval) and TS Echo Reply (TSecr) are used in a similar TS Value (TSval) and TS Echo Reply (TSecr) are used in a similar
manner to the TCP TS option [RFC7323]. On transmitted segments using manner to the TCP TS option [RFC7323]. On transmitted segments using
the option, TS Value is always set based on the local "time" value. the option, TS Value is always set based on the local "time" value.
Received TSval and TSecr values are provided to the application, Received TSval and TSecr values are provided to the application,
which can pass the TSval value to be used as TSecr on UDP messages which can pass the TSval value to be used as TSecr on UDP messages
sent in response (i.e., to echo the received TSval). A received sent in response (i.e., to echo the received TSval). A received
TSecr of zero indicates that the TSval was not echoed by the TSecr of zero indicates that the TSval was not echoed by the
transmitter, i.e., from a previously received UDP packet. transmitter, i.e., from a previously received UDP packet.
>> TIME MAY use an RTT estimate based on nonzero Timestamp values as >> TIME MAY use an RTT estimate based on nonzero Timestamp values as
a hint for fragmentation reassembly, rate limiting, or other a hint for fragmentation reassembly, rate limiting, or other
mechanisms that benefit from such an estimate. mechanisms that benefit from such an estimate.
skipping to change at page 19, line 37 skipping to change at page 20, line 8
o A request is defined as "reply=0" and a reply is defined as both o A request is defined as "reply=0" and a reply is defined as both
fields being non-zero. fields being non-zero.
o A receiver should always respond to a request with the highest o A receiver should always respond to a request with the highest
TSval received (allowing for rollover), which is not necessarily TSval received (allowing for rollover), which is not necessarily
the most recently received. the most recently received.
Rollover can be handled as a special case or more completely using Rollover can be handled as a special case or more completely using
sequence number extension [RFC5925]. sequence number extension [RFC5925].
5.9. Authentication and Encryption (AE) 5.10. Authentication and Encryption (AE)
The Authentication and Encryption (AE) option is intended to allow The Authentication and Encryption (AE) option is intended to allow
UDP to provide a similar type of authentication as the TCP UDP to provide a similar type of authentication as the TCP
Authentication Option (TCP-AO) [RFC5925]. AE the conventional UDP Authentication Option (TCP-AO) [RFC5925]. AE the conventional UDP
payload and may also cover the surplus area, depending on payload and may also cover the surplus area, depending on
configuration. It uses the same format as specified for TCP-AO, configuration. It uses the same format as specified for TCP-AO,
except that it uses a Kind of 8. AE supports NAT traversal in a except that it uses a Kind of 9. AE supports NAT traversal in a
similar manner as TCP-AO [RFC6978]. AE can also be extended to similar manner as TCP-AO [RFC6978]. AE can also be extended to
provide a similar encryption capability as TCP-AO-ENC, in a similar provide a similar encryption capability as TCP-AO-ENC, in a similar
manner [To18ao]. manner [To18ao].
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Kind=8 | Len | Digest... | | Kind=9 | Len | Digest... |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Digest (con't)... | | Digest (con't)... |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 16 UDP AE option format Figure 17 UDP AE option format
Like TCP-AO, AE is not negotiated in-band. Its use assumes both Like TCP-AO, AE is not negotiated in-band. Its use assumes both
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 AE's Key Derivation Function (KDF) uses zeroes (ISNs) [RFC793], thus AE's Key Derivation Function (KDF) uses zeroes
as the value for both ISNs. This means that the AE reuses keys when as the value for both ISNs. This means that the AE reuses keys when
skipping to change at page 20, line 47 skipping to change at page 21, line 14
consider that options not yet defined might yield unpredictable consider that options not yet defined might yield unpredictable
results if not confirmed as supported, e.g., if they were to contain results if not confirmed as supported, e.g., if they were to contain
other hashes or checksums that depend on the option area contents. other hashes or checksums that depend on the option area contents.
This is why such dependencies are not permitted except as defined This is why such dependencies are not permitted except as defined
for OCS and UDP-AE. for OCS and UDP-AE.
Similar to TCP-AO-NAT, AE can be configured to support NAT Similar to TCP-AO-NAT, AE can be configured to support NAT
traversal, excluding (by zeroing out) one or both of the UDP ports traversal, excluding (by zeroing out) one or both of the UDP ports
and corresponding IP addresses [RFC6978]. and corresponding IP addresses [RFC6978].
5.10. Echo request (REQ) and echo response (RES) 5.11. Echo request (REQ) and echo response (RES)
The echo request (REQ, kind=9) and echo response (RES, kind=10) The echo request (REQ, kind=10) and echo response (RES, kind=11)
options provide a means for UDP options to be used to provide options provide a means for UDP options to be used to provide
packet-level acknowledgements. Their use is described as part of the packet-level acknowledgements. One such use is described as part of
UDP variant of packetization layer path MTU discovery (PLPMTUD) the UDP variant of packetization layer path MTU discovery (PLPMTUD)
[Fa20]. The options both have the format indicated in Figure 17. [Fa21]. The options both have the format indicated in Figure 18.
+--------+--------+------------------+ +--------+--------+------------------+
| Kind | Len=6 | nonce | | Kind | Len=6 | nonce |
+--------+--------+------------------+ +--------+--------+------------------+
1 byte 1 byte 4 bytes 1 byte 1 byte 4 bytes
Figure 17 UDP REQ and RES options format Figure 18 UDP REQ and RES options format
5.11. Experimental (EXP) 5.12. Experimental (EXP)
The Experimental option (EXP) is reserved for experiments [RFC3692]. The Experimental option (EXP) is reserved for experiments [RFC3692].
It uses a Kind value of 254. Only one such value is reserved because It uses a Kind value of 254. Only one such value is reserved because
experiments are expected to use an Experimental ID (ExIDs) to experiments are expected to use an Experimental ID (ExIDs) to
differentiate concurrent use for different purposes, using UDP ExIDs differentiate concurrent use for different purposes, using UDP ExIDs
registered with IANA according to the approach developed for TCP registered with IANA according to the approach developed for TCP
experimental options [RFC6994]. experimental options [RFC6994].
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| Kind=254 | Len | UDP ExID | | Kind=254 | Len | UDP ExID |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| (option contents, as defined)... | | (option contents, as defined)... |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
Figure 18 UDP EXP option format Figure 19 UDP EXP option format
>> The length of the experimental option MUST be at least 4 to >> The length of the experimental option MUST be at least 4 to
account for the Kind, Length, and the minimum 16-bit UDP ExID account for the Kind, Length, and the minimum 16-bit UDP ExID
identifier (similar to TCP ExIDs [RFC6994]). identifier (similar to TCP ExIDs [RFC6994]).
Assigned UDP EXP ExIDs and UDP UNSAFE UKind UEXP ExIDs are assigned Assigned UDP EXP ExIDs and UDP UNSAFE UKind UEXP ExIDs are assigned
from the same registry and can be used either in the EXP option or from the same registry and can be used either in the EXP option or
within the UKind UEXP (Section 5.7). within the UKind UEXP (Section 5.8).
6. Rules for designing new options 6. Rules for designing new options
The UDP option Kind space allows for the definition of new options, The UDP option Kind space allows for the definition of new options,
however the currently defined options do not allow for arbitrary new however the currently defined options do not allow for arbitrary new
options. For example, FRAG needs to come first if present; new options. For example, FRAG needs to come first if present; new
options cannot declare that they need to precede it. The following options cannot declare that they need to precede it. The following
is a summary of rules for new options and their rationales: is a summary of rules for new options and their rationales:
>> New options MUST NOT depend on option space content, excepting >> New options MUST NOT depend on option space content, excepting
skipping to change at page 29, line 8 skipping to change at page 29, line 36
inferred from the IP length, using the same text in the current inferred from the IP length, using the same text in the current
specification [RFC8200]: specification [RFC8200]:
"The Upper-Layer Packet Length in the pseudo-header is the "The Upper-Layer Packet Length in the pseudo-header is the
length of the upper-layer header and data (e.g., TCP header length of the upper-layer header and data (e.g., TCP header
plus TCP data). Some upper-layer protocols carry their own plus TCP data). Some upper-layer protocols carry their own
length information (e.g., the Length field in the UDP header); length information (e.g., the Length field in the UDP header);
for such protocols, that is the length used in the pseudo- for such protocols, that is the length used in the pseudo-
header." header."
This document hereby deprecates the requirement asserted in the UDP This document is consistent the UDP profile for Robust Header
profile for Robust Header Compression (ROHC)[RFC3095], noted here: Compression (ROHC)[RFC3095], noted here:
"The Length field of the UDP header MUST match the Length "The Length field of the UDP header MUST match the Length
field(s) of the preceding subheaders, i.e., there must not field(s) of the preceding subheaders, i.e., there must not
be any padding after the UDP payload that is covered by the be any padding after the UDP payload that is covered by the
IP Length." IP Length."
ROHC relies on this "matching" of values to avoid needing to ROHC compresses UDP headers only when this match succeeds. It does
transmit both the IP length and UDP length fields, even though this not prohibit UDP headers where the match fails; in those cases, ROHC
is not a strict requirement of UDP [RFC768] or host requirements default rules (Section 5.10) would cause the UDP header to remain
[RFC1122] and these preexisting standards were not updated by the uncompressed. Upon receivep of a compressed UDP header, Section
ROHC specification. Section A.1.3 of that document is hereby updated A.1.3 of that document indicates that the UDP length is "INFERRED";
to allow for UDP length to vary per packet, so that the UDP length in uncompressed packets, it would simply be explicitly provided.
in the table is "CHANGING" rather than "INFERRED". The text that
describes the UDP length field this is updated to:
This field is changing as allowed by UDP [RFC768] and used
by both UDP options [RFC-TBD] and Teredo extensions [RFC6081]
and is therefore classified as CHANGING.
The issue of handling UDP header compression has already been
correctly described in more recent specifications, e.g., Sec. 10.10
of Static Context Header Compression [RFC8724]. In that description,
the UDP length can be compressed out of a packet only when it can be
correctly inferred from the UDP length, i.e., when neither UDP
options nor Teredo extensions are present:
"The parser MUST NOT label this field unless the UDP Length value This issue of handling UDP header compression is more explicitly
matches the Payload Length value from the IPv6 header." described in more recent specifications, e.g., Sec. 10.10 of Static
Context Header Compression [RFC8724].
16. Multicast Considerations 16. 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.
skipping to change at page 30, line 23 skipping to change at page 30, line 36
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 [RFC8446] (transport layer security). Despite the name, neither TLS [RFC8446] (transport layer
security, for TCP) nor DTLS [RFC6347] (TLS for UDP) protect the security, for TCP) nor DTLS [RFC6347] (TLS for UDP) protect the
transport layer. Both operate as a shim layer solely on the payload transport layer. Both operate as a shim layer solely on the payload
of transport packets, protecting only their contents. Just as TLS of transport packets, protecting only their contents. Just as TLS
does not protect the TCP header or its options, DTLS does not does not protect the TCP header or its options, DTLS does not
protect the UDP header or the new options introduced by this protect the UDP header or the new options introduced by this
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.10). Transport headers
also protected as payload when using IP security (IPsec) [RFC4301]. are 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 processing of TLVs. Because required options and MAY also limit processing of TLVs. Because required
options come first and at most once each (with the exception of options come first and at most once each (with the exception of
NOPs, which should never need to come in sequences of more than NOPs, which should never need to come in sequences of more than
three in a row), this limits their DOS impact. three in a row), this limits their DOS impact.
skipping to change at page 31, line 30 skipping to change at page 31, line 44
using UKind=UEXP. This registry is initially empty. Values in this using UKind=UEXP. This registry is initially empty. Values in this
registry are to be assigned by IANA using first-come, first-served registry are to be assigned by IANA using first-come, first-served
(FCFS) rules [RFC8126]. Options using these ExIDs are subject to the (FCFS) rules [RFC8126]. Options using these ExIDs are subject to the
same conditions as new options, i.e., they too are subject to the same conditions as new options, i.e., they too are subject to the
conditions set forth in this document, particularly (but not limited conditions set forth in this document, particularly (but not limited
to) those in Section 6. to) those in Section 6.
Upon publication, IANA is hereby requested to create a new registry Upon publication, IANA is hereby requested to create a new registry
for UDP UNSAFE UKind numbers. There are no initial assignments in for UDP UNSAFE UKind numbers. There are no initial assignments in
this registry. Values in this registry are to be assigned from the this registry. Values in this registry are to be assigned from the
UNASSIGNED values in Section 5.7 by IESG Approval or Standards UNASSIGNED values in Section 5.8 by IESG Approval or Standards
Action [RFC8126]. Those assignments are subject to the conditions Action [RFC8126]. Those assignments are subject to the conditions
set forth in this document, particularly (but not limited to) those set forth in this document, particularly (but not limited to) those
in Section 6. in Section 6.
19. References 19. References
19.1. Normative References 19.1. Normative References
[Fa20] Fairhurst, G., T. Jones, "Datagram PLPMTUD for UDP
Options," draft-fairhurst-tsvwg-udp-options-dplpmtud, Mar.
2020.
[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.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -- [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts --
Communication Layers," RFC 1122, Oct. 1989. Communication Layers," RFC 1122, Oct. 1989.
[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.
[RFC3095] Bormann, C. (Ed), et al., "RObust Header Compression
(ROHC): Framework and four profiles: RTP, UDP, ESP, and
uncompressed," RFC 3095, July 2001.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words," RFC 2119, May 2017. 2119 Key Words," RFC 2119, May 2017.
19.2. Informative References 19.2. Informative References
[Fa18] Fairhurst, G., T. Jones, R. Zullo, "Checksum Compensation [Fa18] Fairhurst, G., T. Jones, R. Zullo, "Checksum Compensation
Options for UDP Options", draft-fairhurst-udp-options-cco, Options for UDP Options", draft-fairhurst-udp-options-cco,
Oct. 2018. Oct. 2018.
[Fa21] Fairhurst, G., T. Jones, "Datagram PLPMTUD for UDP
Options," draft-fairhurst-tsvwg-udp-options-dplpmtud, Apr.
2021.
[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.
[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.
[RFC3095] Bormann, C. (Ed), et al., "RObust Header Compression
(ROHC): Framework and four profiles: RTP, UDP, ESP, and
uncompressed," RFC 3095, July 2001.
[RFC3385] Sheinwald, D., J. Satran, P. Thaler, V. Cavanna, "Internet [RFC3385] Sheinwald, D., J. Satran, P. Thaler, V. Cavanna, "Internet
Protocol Small Computer System Interface (iSCSI) Cyclic Protocol Small Computer System Interface (iSCSI) Cyclic
Redundancy Check (CRC)/Checksum Considerations," RFC 3385, Redundancy Check (CRC)/Checksum Considerations," RFC 3385,
Sep. 2002. Sep. 2002.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful," RFC 3692, Jan. 2004. Considered Useful," RFC 3692, Jan. 2004.
[RFC3828] Larzon, L-A., M. Degermark, S. Pink, L-E. Jonsson (Ed.), [RFC3828] Larzon, L-A., M. Degermark, S. Pink, L-E. Jonsson (Ed.),
G. Fairhurst (Ed.), "The Lightweight User Datagram G. Fairhurst (Ed.), "The Lightweight User Datagram
skipping to change at page 34, line 5 skipping to change at page 34, line 25
[RFC8200] Deering, S., R. Hinden, "Internet Protocol Version 6 [RFC8200] Deering, S., R. Hinden, "Internet Protocol Version 6
(IPv6) Specification," RFC 8200, Jul. 2017. (IPv6) Specification," RFC 8200, Jul. 2017.
[RFC8201] McCann, J., S. Deering, J. Mogul, R. Hinden (Ed.), "Path [RFC8201] McCann, J., S. Deering, J. Mogul, R. Hinden (Ed.), "Path
MTU Discovery for IP version 6," RFC 8201, Jul. 2017. MTU Discovery for IP version 6," RFC 8201, Jul. 2017.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3," RFC 8446, Aug. 2018. Version 1.3," RFC 8446, Aug. 2018.
[RFC8724] Minaburo, A., L. Toutain, C. Gomez, D. Barthel, JC.,
"SCHC: Generic Framework for Static Context Header
Compression and Fragmentation," RFC 8724, Apr. 2020.
[RFC8899] Fairhurst, G., T. Jones, M. Tuxen, I. Rungeler, T. Volker,
"Packetization Layer Path MTU Discovery for Datagram
Transports," RFC 8899, Sep. 2020.
[To18ao] Touch, J., "A TCP Authentication Option Extension for [To18ao] Touch, J., "A TCP Authentication Option Extension for
Payload Encryption," draft-touch-tcp-ao-encrypt, Jul. Payload Encryption," draft-touch-tcp-ao-encrypt, Jul.
2018. 2018.
[To20cb] Touch, J., M. Welzl, S. Islam, J. You, "TCP Control Block [To20cb] Touch, J., M. Welzl, S. Islam, J. You, "TCP Control Block
Interdependence," draft-touch-tcpm-2140bis, Apr. 2020. Interdependence," draft-touch-tcpm-2140bis, Apr. 2020.
20. Acknowledgments 20. 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 (including OCS for misbehaving middlebox Ted Faber, Gorry Fairhurst (including OCS for misbehaving middlebox
traversal), C. M. Heard (including combining previous FRAG and LITE traversal), C. M. Heard (including combining previous FRAG and LITE
options into the new FRAG), Tom Herbert, and Mark Smith, as well as options into the new FRAG), Tom Herbert, Mark Smith, and Raffaele
discussions on the IETF TSVWG and SPUD email lists. Zullo, as well as discussions on the IETF TSVWG and SPUD email
lists.
This work was partly supported by USC/ISI's Postel Center. This work was 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.
Authors' Addresses Authors' Addresses
Joe Touch Joe Touch
Manhattan Beach, CA 90266 USA Manhattan Beach, CA 90266 USA
Phone: +1 (310) 560-0334 Phone: +1 (310) 560-0334
Email: touch@strayalpha.com Email: touch@strayalpha.com
Appendix A. Implementation Information Appendix A. Implementation Information
The following information is provided to encourage interoperable API The following information is provided to encourage interoperable API
implementations. implementations.
System-level variables (sysctl): System-level variables (sysctl):
Name default meaning Name default meaning
---------------------------------------------------- ----------------------------------------------------
net.ipv4.udp_opt 0 UDP options available net.ipv4.udp_opt 0 UDP options available
net.ipv4.udp_opt_ocs 1 Default include OCS net.ipv4.udp_opt_ocs 1 Default include OCS
skipping to change at page 35, line 36 skipping to change at page 36, line 36
UDP_OPT Enable UDP options (at all) UDP_OPT Enable UDP options (at all)
UDP_OPT_OCS Enable UDP OCS option UDP_OPT_OCS Enable UDP OCS option
UDP_OPT_ACS Enable UDP ACS option UDP_OPT_ACS Enable UDP ACS option
UDP_OPT_MSS Enable UDP MSS option UDP_OPT_MSS Enable UDP MSS option
UDP_OPT_TIME Enable UDP TIME option UDP_OPT_TIME Enable UDP TIME option
UDP_OPT_FRAG Enable UDP FRAG option UDP_OPT_FRAG Enable UDP FRAG option
UDP_OPT_AE Enable UDP AE option UDP_OPT_AE Enable UDP AE option
Send/sendto parameters: Send/sendto parameters:
(TBD - currently using cached parameters)
Connection parameters (per-socketpair cached state, part UCB): Connection parameters (per-socketpair cached state, part UCB):
Name Initial value Name Initial value
---------------------------------------------------- ----------------------------------------------------
opts_enabled net.ipv4.udp_opt opts_enabled net.ipv4.udp_opt
ocs_enabled net.ipv4.udp_opt_ocs ocs_enabled net.ipv4.udp_opt_ocs
The following option is included for debugging purposes, and MUST The following option is included for debugging purposes, and MUST
NOT be enabled otherwise. NOT be enabled otherwise.
 End of changes. 53 change blocks. 
108 lines changed or deleted 135 lines changed or added

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