< draft-ietf-tsvwg-udp-options-17.txt   draft-ietf-tsvwg-udp-options-18.txt >
TSVWG J. Touch TSVWG J. Touch
Internet Draft Independent Consultant Internet Draft Independent Consultant
Intended status: Standards Track March 24, 2022 Intended status: Standards Track March 26, 2022
Intended updates: 768 Intended updates: 768
Expires: September 2022 Expires: September 2022
Transport Options for UDP Transport Options for UDP
draft-ietf-tsvwg-udp-options-17.txt draft-ietf-tsvwg-udp-options-18.txt
Abstract Abstract
Transport protocols are extended through the use of transport header Transport protocols are extended through the use of transport header
options. This document extends UDP by indicating the location, options. This document extends UDP by indicating the location,
syntax, and semantics for UDP transport layer options. syntax, and semantics for UDP transport layer options.
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
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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
https://www.ietf.org/shadow.html https://www.ietf.org/shadow.html
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
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."
This Internet-Draft will expire on September 24, 2022. This Internet-Draft will expire on September 26, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 25 skipping to change at page 2, line 25
3. Terminology....................................................3 3. Terminology....................................................3
4. Background.....................................................4 4. Background.....................................................4
5. The UDP Option Area............................................5 5. The UDP Option Area............................................5
6. The UDP Surplus Area Structure.................................8 6. The UDP Surplus Area Structure.................................8
7. The Option Checksum (OCS)......................................8 7. The Option Checksum (OCS)......................................8
8. UDP Options...................................................10 8. UDP Options...................................................10
9. Safe UDP Options..............................................13 9. Safe UDP Options..............................................13
9.1. End of Options List (EOL)................................13 9.1. End of Options List (EOL)................................13
9.2. No Operation (NOP).......................................14 9.2. No Operation (NOP).......................................14
9.3. Alternate Payload Checksum (APC).........................14 9.3. Alternate Payload Checksum (APC).........................14
9.4. Fragmentation (FRAG).....................................15 9.4. Fragmentation (FRAG).....................................16
9.5. Maximum Datagram Size (MDS)..............................19 9.5. Maximum Datagram Size (MDS)..............................19
9.6. Maximum Reassembled Datagram Size (MRDS).................20 9.6. Maximum Reassembled Datagram Size (MRDS).................20
9.7. Echo request (REQ) and echo response (RES)...............21 9.7. Echo request (REQ) and echo response (RES)...............21
9.8. Timestamps (TIME)........................................21 9.8. Timestamps (TIME)........................................21
9.9. Authentication (AUTH)....................................22 9.9. Authentication (AUTH)....................................22
9.10. Experimental (EXP)......................................23 9.10. Experimental (EXP)......................................23
10. UNSAFE Options...............................................24 10. UNSAFE Options...............................................24
10.1. UNSAFE Encryption (UENC)................................25 10.1. UNSAFE Encryption (UENC)................................25
10.2. UNSAFE Experimental (UEXP)..............................25 10.2. UNSAFE Experimental (UEXP)..............................25
11. Rules for designing new options..............................25 11. Rules for designing new options..............................25
skipping to change at page 11, line 29 skipping to change at page 11, line 29
7* 6 Response (RES) 7* 6 Response (RES)
8 10 Timestamps (TIME) 8 10 Timestamps (TIME)
9 (varies) Authentication (AUTH) 9 (varies) Authentication (AUTH)
10-126 (varies) UNASSIGNED (assignable by IANA) 10-126 (varies) UNASSIGNED (assignable by IANA)
127 (varies) RFC 3692-style experiments (EXP) 127 (varies) RFC 3692-style experiments (EXP)
128-191 RESERVED 128-191 RESERVED
192 (varies) Encryption (UENC) 192 (varies) Encryption (UENC)
193-253 UNASSIGNED-UNSAFE (assignable by IANA) 193-253 UNASSIGNED-UNSAFE (assignable by IANA)
254 (varies) RFC 3692-style experiments (UEXP) 254 (varies) RFC 3692-style experiments (UEXP)
255 RESERVED-UNSAFE 255 RESERVED
Options indicated by Kind values in the range 0..191 are known as Options indicated by Kind values in the range 0..127 are known as
SAFE options because they do not alter the UDP data payload and thus SAFE options because they do not alter the UDP data payload and thus
do not interfere with use of that data by legacy endpoints. Options do not interfere with use of that data by legacy endpoints. Options
indicated by Kind values in the range 192..254 are known as UNSAFE indicated by Kind values in the range 192..254 are known as UNSAFE
options because they do alter the UDP data payload and thus would options because they do alter the UDP data payload and thus would
interfere with legacy endpoints. UNSAFE option nicknames are interfere with legacy endpoints. UNSAFE option nicknames are
expected to begin with "U", which should be avoided for safe option expected to begin with "U", which should be avoided for safe option
nicknames (see Section 23). nicknames (see Section 23). Kind values 128-191 and 255 are RESERVED
and not otherwise defined at this time.
>> RESERVED Kind values MUST NOT be assumed to be either SAFE nor
UNSAFE until defined.
Although the FRAG option modifies the original UDP payload contents Although the FRAG option modifies the original UDP payload contents
(i.e., is UNSAFE with respect to the original UDP payload), it is (i.e., is UNSAFE with respect to the original UDP payload), it is
used only in subsequent fragments with zero UDP payloads, thus is used only in subsequent fragments with zero UDP payloads, thus is
SAFE in actual use, as discussed further in Section 9.4. SAFE in actual use, as discussed further in Section 9.4.
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
skipping to change at page 13, line 33 skipping to change at page 13, line 38
9. Safe UDP Options 9. Safe UDP Options
Safe UDP options can be silently ignored by legacy receivers without Safe UDP options can be silently ignored by legacy receivers without
affecting the meaning of the UDP user data. They stand in contrast affecting the meaning of the UDP user data. They stand in contrast
to Unsafe options, which modify UDP user data in ways that render it to Unsafe options, which modify UDP user data in ways that render it
unusable by legacy receivers (Section 10). The following subsections unusable by legacy receivers (Section 10). The following subsections
describe safe options defined in this document. describe safe options defined in this document.
9.1. End of Options List (EOL) 9.1. End of Options List (EOL)
The End of Options List (EOL) option indicates that there are no The End of Options List (EOL, Kind=0) option indicates that there
more options. It is used to indicate the end of the list of options are no more options. It is used to indicate the end of the list of
without needing to use NOP options (see the following section) as options without needing to use NOP options (see the following
padding to fill all available option space. section) as padding to fill all available option space.
+--------+ +--------+
| Kind=0 | | Kind=0 |
+--------+ +--------+
Figure 7 UDP EOL option format Figure 7 UDP EOL option format
>> When the UDP options do not consume the entire surplus area, the >> When the UDP options do not consume the entire surplus area, the
last non-NOP option MUST be EOL. last non-NOP option MUST be EOL.
skipping to change at page 14, line 21 skipping to change at page 14, line 24
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 this area to be used for zero padding to increase useful to allow this area to be used for zero padding to increase
the UDP datagram length without affecting the UDP user data length, the UDP datagram length without affecting the UDP user data length,
e.g., for UDP DPLPMTUD (Section 4.1 of [Fa22]). e.g., for UDP DPLPMTUD (Section 4.1 of [Fa22]).
9.2. No Operation (NOP) 9.2. No Operation (NOP)
The No Operation (NOP) option is a one-byte placeholder, intended to The No Operation (NOP, Kind=1) option is a one-byte placeholder,
be used as padding, e.g., to align multi-byte options along 16-bit, intended to be used as padding, e.g., to align multi-byte options
32-bit, or 64-bit boundaries boundaries. along 16-bit, 32-bit, or 64-bit boundaries.
+--------+ +--------+
| Kind=1 | | Kind=1 |
+--------+ +--------+
Figure 8 UDP NOP option format Figure 8 UDP NOP option format
>> UDP packets SHOULD NOT use more than seven consecutive NOPs, >> UDP packets SHOULD NOT use more than seven consecutive NOPs,
i.e., to support alignment up to 8-byte boundaries. UDP packets i.e., to support alignment up to 8-byte boundaries. UDP packets
SHOULD NOT use NOPs at the end of the options area as a substitute SHOULD NOT use NOPs at the end of the options area as a substitute
for EOL followed by zero-fill. NOPs are intended to assist with for EOL followed by zero-fill. NOPs are intended to assist with
alignment, not as other padding or fill. alignment, not as other padding or fill.
This issue is discussed further in Section 22. This issue is discussed further in Section 22.
9.3. Alternate Payload Checksum (APC) 9.3. Alternate Payload Checksum (APC)
The Alternate Payload Checksum (APC) option provides a stronger The Alternate Payload Checksum (APC, Kind=2) option provides a
alternative to the checksum in the UDP header, using a 32-bit CRC of stronger alternative to the checksum in the UDP header, using a 32-
the conventional UDP user data payload only (excluding the IP bit CRC of the conventional UDP user data payload only (excluding
pseudoheader, UDP header, and surplus area). It is an "alternate" to the IP pseudoheader, UDP header, and surplus area). It is an
the UDP checksum that covers the user data - not to the OCS (the "alternate" to the UDP checksum that covers the user data - not to
latter covers the surplus area only). Unlike the UDP checksum, APC the OCS (the latter covers the surplus area only). Unlike the UDP
does not include the IP pseudoheader or UDP header, thus it does not checksum, APC does not include the IP pseudoheader or UDP header,
need to be updated by NATs when IP addresses or UDP ports are thus it does not need to be updated by NATs when IP addresses or UDP
rewritten. Its purpose is to detect user data errors that the UDP ports are rewritten. Its purpose is to detect user data errors that
checksum, when used, might not detect. the UDP checksum, when used, might not detect.
A CRC32c has been chosen because of its ubiquity and use in other A CRC32c has been chosen because of its ubiquity and use in other
Internet protocols, including iSCSI and SCTP. The option contains Internet protocols, including iSCSI and SCTP. The option contains
the CRC32c in network standard byte order, as described in the CRC32c in network standard byte order, as described in
[RFC3385]. [RFC3385].
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Kind=2 | Len=6 | CRC32c... | | Kind=2 | Len=6 | CRC32c... |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| CRC32c (cont.) | | CRC32c (cont.) |
skipping to change at page 15, line 48 skipping to change at page 16, line 7
unless overridden. unless overridden.
>> UDP packets with unrecognized APC lengths MUST be receive the >> UDP packets with unrecognized APC lengths MUST be receive the
same treatment as UDP packets with incorrect APC checksums. same treatment as UDP packets with incorrect APC checksums.
Ensuring that unrecognized APC lengths are treated as incorrect Ensuring that unrecognized APC lengths are treated as incorrect
checksums enables future variants of APC to be treated as APC-like. checksums enables future variants of APC to be treated as APC-like.
9.4. Fragmentation (FRAG) 9.4. Fragmentation (FRAG)
The Fragmentation (FRAG) option supports UDP fragmentation and The Fragmentation (FRAG, Kind=3) option supports UDP fragmentation
reassembly, which can be used to transfer UDP messages larger than and reassembly, which can be used to transfer UDP messages larger
limited by the IP receive MTU (EMTU_R [RFC1122]). FRAG includes a than limited by the IP receive MTU (EMTU_R [RFC1122]). FRAG includes
copy of the same UDP transport ports in each fragment, enabling them a copy of the same UDP transport ports in each fragment, enabling
to traverse Network Address (and port) Translation (NAT) devices, in them to traverse Network Address (and port) Translation (NAT)
contrast to the behavior of IP fragments. FRAG is typically used devices, in contrast to the behavior of IP fragments. FRAG is
with the UDP MDS and MRDS options to enable more efficient use of typically used with the UDP MDS and MRDS options to enable more
large messages, both at the UDP and IP layers. FRAG is designed efficient use of large messages, both at the UDP and IP layers. FRAG
similar to the IPv6 Fragmentation Header [RFC8200], except that the is designed similar to the IPv6 Fragmentation Header [RFC8200],
UDP variant uses a 16-bit Offset measured in bytes, rather than except that the UDP variant uses a 16-bit Offset measured in bytes,
IPv6's 13-bit Fragment Offset measured in 8-byte units. This UDP rather than IPv6's 13-bit Fragment Offset measured in 8-byte units.
variant avoids creating reserved fields. This UDP variant avoids creating reserved fields.
>> When FRAG is present, it SHOULD come as early as possible in the >> When FRAG is present, it SHOULD come as early as possible in the
UDP options list. UDP options list.
>> When FRAG is present, the UDP user data MUST be empty. If the >> When FRAG is present, the UDP user data MUST be empty. If the
user data is not empty, all UDP options MUST be silently ignored and user data is not empty, all UDP options MUST be silently ignored and
the user data received sent to the user. the user data received sent to the user.
Legacy receivers interpret FRAG messages as zero-length user data Legacy receivers interpret FRAG messages as zero-length user data
UDP packets (i.e., UDP Length field is 8, the length of just the UDP UDP packets (i.e., UDP Length field is 8, the length of just the UDP
skipping to change at page 17, line 26 skipping to change at page 17, line 30
>> Endpoints supporting UDP options MUST be capable of fragmenting >> Endpoints supporting UDP options MUST be capable of fragmenting
and reassembling at least 2 fragments, for a total of at least 3,000 and reassembling at least 2 fragments, for a total of at least 3,000
bytes (see MRDS in Section 9.6). bytes (see MRDS in Section 9.6).
Use of the single fragment variant can be helpful in supporting use Use of the single fragment variant can be helpful in supporting use
of UNSAFE options without undesirable impact to receivers that do of UNSAFE options without undesirable impact to receivers that do
not support either UDP options or the specific UNSAFE options. not support either UDP options or the specific UNSAFE options.
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Kind=4 | Len=12 | Frag. Start | | Kind=3 | Len=12 | Frag. Start |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Identification | | Identification |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Frag. Offset | Dgram Opt Start | | Frag. Offset | Dgram Opt Start |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 11 UDP terminal FRAG option format Figure 11 UDP terminal FRAG option format
The terminal FRAG option format adds a Datagram Option Start The terminal FRAG option format adds a Datagram Option Start
pointer, measured from the start of the original UDP datagram pointer, measured from the start of the original UDP datagram
skipping to change at page 19, line 46 skipping to change at page 19, line 50
5. Process the pre-reassembly UDP options of each fragment. 5. Process the pre-reassembly UDP options of each fragment.
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 UDP packet is processed with any trailing UDP options the entire UDP packet is processed with any trailing UDP options
applying to the reassembled user data. applying to the reassembled user data.
9.5. Maximum Datagram Size (MDS) 9.5. Maximum Datagram Size (MDS)
The Maximum Datagram Size (MDS, Kind = 5) option is a 16-bit hint of The Maximum Datagram Size (MDS, Kind=4) option is a 16-bit hint of
the largest unfragmented UDP packet that an endpoint believes can be the largest unfragmented UDP packet that an endpoint believes can be
received. As with the TCP Maximum Segment Size (MSS) option received. As with the TCP Maximum Segment Size (MSS) option
[RFC793], the size indicated is the IP layer MTU decreased by the [RFC793], the size indicated is the IP layer MTU decreased by the
fixed IP and UDP headers only [RFC6691]. The space needed for IP and fixed IP and UDP headers only [RFC6691]. The space needed for IP and
UDP options need to be adjusted by the sender when using the value UDP options need to be adjusted by the sender when using the value
indicated. The value transmitted is based on EMTU_R, the largest IP indicated. The value transmitted is based on EMTU_R, the largest IP
datagram that can be received (i.e., reassembled at the receiver) datagram that can be received (i.e., reassembled at the receiver)
[RFC1122]. However, as with TCP, this value is only a hint at what [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 the receiver believes; it does not indicate a known path MTU and
thus MUST NOT be used to limit transmissions. thus MUST NOT be used to limit transmissions.
skipping to change at page 20, line 31 skipping to change at page 20, line 34
source fragmentation or UDP fragmentation to limit the largest source fragmentation or UDP fragmentation to limit the largest
reassembled UDP message as indicated by MRDS (see Section 9.6), reassembled UDP message as indicated by MRDS (see Section 9.6),
e.g., when EMTU_R is larger than the required minimums (576 for IPv4 e.g., when EMTU_R is larger than the required minimums (576 for IPv4
[RFC791] and 1500 for IPv6 [RFC8200]). It can also be used with [RFC791] and 1500 for IPv6 [RFC8200]). It can also be used with
DPLPMTUD [RFC8899] to provide a hint to maximum DPLPMTU, though it DPLPMTUD [RFC8899] to provide a hint to maximum DPLPMTU, though it
MUST NOT prohibit transmission of larger UDP packets (or fragments) MUST NOT prohibit transmission of larger UDP packets (or fragments)
used as DPLPMTU probes. used as DPLPMTU probes.
9.6. Maximum Reassembled Datagram Size (MRDS) 9.6. Maximum Reassembled Datagram Size (MRDS)
The Maximum Reassembled Segment Size (MRDS, Kind=6) option is a 16- The Maximum Reassembled Segment Size (MRDS, Kind=5) option is a 16-
bit indicator of the largest reassembled UDP segment that can be bit indicator of the largest reassembled UDP segment that can be
received. MRDS is the UDP equivalent of IP's EMTU_R but the two are received. MRDS is the UDP equivalent of IP's EMTU_R but the two are
not related [RFC1122]. Using the FRAG option (Section 9.4), UDP not related [RFC1122]. Using the FRAG option (Section 9.4), UDP
packets can be transmitted as transport fragments, each in their own packets can be transmitted as transport fragments, each in their own
(presumably not fragmented) IP datagram and be reassembled at the (presumably not fragmented) IP datagram and be reassembled at the
UDP layer. UDP layer.
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Kind=5 | Len=4 | MRDS size | | Kind=5 | Len=4 | MRDS size |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 13 UDP MRDS option format Figure 13 UDP MRDS option format
>> Endpoints supporting UDP options MUST support a local MRDS of at >> Endpoints supporting UDP options MUST support a local MRDS of at
least 3,000 bytes. least 3,000 bytes.
9.7. Echo request (REQ) and echo response (RES) 9.7. Echo request (REQ) and echo response (RES)
The echo request (REQ, kind=6) and echo response (RES, kind=7) The echo request (REQ, Kind=6) and echo response (RES, Kind=7)
options provide a means for UDP options to be used to provide UDP options provide a means for UDP options to be used to provide UDP
packet-level acknowledgements. One such use is described as part of packet-level acknowledgements. One such use is described as part of
the UDP options variant of packetization layer path MTU discovery the UDP options variant of packetization layer path MTU discovery
(PLPMTUD) [Fa22]. The options both have the format indicated in (PLPMTUD) [Fa22]. The options both have the format indicated in
Figure 14, in which the token has no internal structure or meaning. Figure 14, in which the token has no internal structure or meaning.
+--------+--------+------------------+ +--------+--------+------------------+
| Kind | Len=6 | token | | Kind | Len=6 | token |
+--------+--------+------------------+ +--------+--------+------------------+
1 byte 1 byte 4 bytes 1 byte 1 byte 4 bytes
Figure 14 UDP REQ and RES options format Figure 14 UDP REQ and RES options format
Each of these option kinds appears at most once in each UDP packet, Each of these option kinds appears at most once in each UDP packet,
as with other options. Note also that the FRAG option is not used as with other options. Note also that the FRAG option is not used
when sending DPLPMTUD probes to determine a PLPMTU [Fa22]. when sending DPLPMTUD probes to determine a PLPMTU [Fa22].
9.8. Timestamps (TIME) 9.8. Timestamps (TIME)
The Timestamp (TIME) option exchanges two four-byte unsigned The Timestamp (TIME, Kind=8) option exchanges two four-byte unsigned
timestamp fields. It serves a similar purpose to TCP's TS option timestamp fields. It serves a similar purpose to TCP's TS option
[RFC7323], enabling UDP to estimate the round trip time (RTT) [RFC7323], enabling UDP to estimate the round trip time (RTT)
between hosts. For UDP, this RTT can be useful for establishing UDP between hosts. For UDP, this RTT can be useful for establishing UDP
fragment reassembly timeouts or transport-layer rate-limiting fragment reassembly timeouts or transport-layer rate-limiting
[RFC8085]. [RFC8085].
+--------+--------+------------------+------------------+ +--------+--------+------------------+------------------+
| Kind=8 | 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
skipping to change at page 22, line 37 skipping to change at page 22, line 37
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 [RFC9187], however zero values need to be sequence number extension [RFC9187], however zero values need to be
avoided explicitly. avoided explicitly.
>> TIME values MUST NOT use zeros as valid time values, because they >> TIME values MUST NOT use zeros as valid time values, because they
are used as indicators of requests and responses. are used as indicators of requests and responses.
9.9. Authentication (AUTH) 9.9. Authentication (AUTH)
The Authentication (AUTH) option is intended to allow UDP to provide The Authentication (AUTH, Kind=9) option is intended to allow UDP to
a similar type of authentication as the TCP Authentication Option provide a similar type of authentication as the TCP Authentication
(TCP-AO) [RFC5925]. AUTH covers the UDP user data. It uses the same Option (TCP-AO) [RFC5925]. AUTH covers the UDP user data. AUTH
format as specified for TCP-AO, except that it uses a Kind of 10. supports NAT traversal in a similar manner as TCP-AO [RFC6978].
AUTH supports NAT traversal in a similar manner as TCP-AO [RFC6978].
Figure 16 shows the UDP AUTH format, whose contents are identical to Figure 16 shows the UDP AUTH format, whose contents are identical to
that of the TCP-AO option. that of the TCP-AO option.
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Kind=9 | Len | TCP-AO fields...| | Kind=9 | Len | TCP-AO fields...|
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| TCP-AO fields (con't)... | | TCP-AO fields (con't)... |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 16 UDP AUTH option format Figure 16 UDP AUTH option format
skipping to change at page 23, line 41 skipping to change at page 23, line 41
were to contain other hashes or checksums that depend on the surplus were to contain other hashes or checksums that depend on the surplus
area contents. This is why such dependencies are not permitted area contents. This is why such dependencies are not permitted
except as defined for the OCS and the AUTH (and later, UENC) option. except as defined for the OCS and the AUTH (and later, UENC) option.
Similar to TCP-AO-NAT, AUTH (and later, UENC) can be configured to Similar to TCP-AO-NAT, AUTH (and later, UENC) can be configured to
support NAT traversal, excluding (by zeroing out) one or both of the support NAT traversal, excluding (by zeroing out) one or both of the
UDP ports and corresponding IP addresses [RFC6978]. UDP ports and corresponding IP addresses [RFC6978].
9.10. Experimental (EXP) 9.10. Experimental (EXP)
The Experimental option (EXP) is reserved for experiments [RFC3692]. The Experimental option (EXP, Kind=127) is reserved for experiments
It uses a Kind value of 127. Only one such value is reserved because [RFC3692]. Only one such value is reserved because experiments are
experiments are expected to use an Experimental ID (ExIDs) to expected to use an Experimental ID (ExIDs) to differentiate
differentiate concurrent use for different purposes, using UDP ExIDs concurrent use for different purposes, using UDP ExIDs registered
registered with IANA according to the approach developed for TCP with IANA according to the approach developed for TCP experimental
experimental options [RFC6994]. options [RFC6994].
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| Kind=127 | Len | UDP ExID | | Kind=127 | Len | UDP ExID |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| (option contents, as defined)... | | (option contents, as defined)... |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
Figure 17 UDP EXP option format Figure 17 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
skipping to change at page 25, line 10 skipping to change at page 25, line 10
either per-fragment or after reassembly. either per-fragment or after reassembly.
>> Receivers supporting UDP options MUST silently drop the UDP user >> Receivers supporting UDP options MUST silently drop the UDP user
data of the reassembled datagram if any fragment or the entire data of the reassembled datagram if any fragment or the entire
datagram includes an UNSAFE option whose UKind is not supported. datagram includes an UNSAFE option whose UKind is not supported.
Note that this still results in the receipt of a zero-length UDP Note that this still results in the receipt of a zero-length UDP
datagram. datagram.
10.1. UNSAFE Encryption (UENC) 10.1. UNSAFE Encryption (UENC)
UNSAFE encryption (UENC) has the same format as AUTH (Section 9.9), UNSAFE encryption (UENC, Kind=192) has the same format as AUTH
except that it encrypts (modifies) the user data. It provides a (Section 9.9), except that it encrypts (modifies) the user data. It
similar encryption capability as TCP-AO-ENC, in a similar manner provides a similar encryption capability as TCP-AO-ENC, in a similar
[To18]. Its fields, coverage, and processing are the same as for manner [To18]. Its fields, coverage, and processing are the same as
AUTH, except that UENC encrypts only the user data, although it can for AUTH, except that UENC encrypts only the user data, although it
(optionally) depend on the surplus area (with certain fields zeroed, can (optionally) depend on the surplus area (with certain fields
as per AUTH, e.g., providing authentication over the surplus area). zeroed, as per AUTH, e.g., providing authentication over the surplus
Like AUTH, UENC can be configured to be compatible with NAT area). Like AUTH, UENC can be configured to be compatible with NAT
traversal. traversal.
10.2. UNSAFE Experimental (UEXP) 10.2. UNSAFE Experimental (UEXP)
The UNSAFE Experimental option (EXP) is reserved for experiments The UNSAFE Experimental option (UEXP, Kind=254) is reserved for
[RFC3692]. It uses a Kind value of 254. Only one such value is experiments [RFC3692]. As with EXP, only one such UEXP value is
reserved because experiments are expected to use an Experimental ID reserved because experiments are expected to use an Experimental ID
(ExIDs) to differentiate concurrent use for different purposes, (ExIDs) to differentiate concurrent use for different purposes,
using UDP ExIDs registered with IANA according to the approach using UDP ExIDs registered with IANA according to the approach
developed for TCP experimental options [RFC6994]. developed for TCP experimental options [RFC6994].
Assigned ExIDs can be used with either the UEXP or EXP options. Assigned ExIDs can be used with either the UEXP or EXP options.
11. Rules for designing new options 11. 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,
skipping to change at page 38, line 22 skipping to change at page 38, line 22
to Denial of Service,", Vulnerability Note VU 962459, to Denial of Service,", Vulnerability Note VU 962459,
Software Engineering Institute, CMU, 2018, Software Engineering Institute, CMU, 2018,
https://www.kb.cert.org/vuls/id/962459. https://www.kb.cert.org/vuls/id/962459.
[To18] Touch, J., "A TCP Authentication Option Extension for [To18] 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.
25. Acknowledgments 25. Acknowledgments
This work benefitted from feedback from Bob Briscoe, Ken Calvert, This work benefitted from feedback from Erik Auerswald, Bob Briscoe,
Ted Faber, Gorry Fairhurst (including OCS for misbehaving middlebox Ken Calvert, Ted Faber, Gorry Fairhurst (including OCS for
traversal), C. M. Heard (including combining previous FRAG and LITE misbehaving middlebox traversal), C. M. Heard (including combining
options into the new FRAG), Tom Herbert, Mark Smith, and Raffaele previous FRAG and LITE options into the new FRAG), Tom Herbert, Mark
Zullo, as well as discussions on the IETF TSVWG and SPUD email Smith, and Raffaele Zullo, as well as discussions on the IETF TSVWG
lists. 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
 End of changes. 21 change blocks. 
68 lines changed or deleted 71 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/