draft-ietf-tsvwg-udp-options-31.txt | draft-ietf-tsvwg-udp-options-32.txt | |||
---|---|---|---|---|
TSVWG J. Touch | TSVWG J. Touch | |||
Internet Draft Independent Consultant | Internet Draft Independent Consultant | |||
Intended status: Standards Track March 4, 2024 | Intended status: Standards Track March 21, 2024 | |||
Intended updates: 768 | Intended updates: 768 | |||
Expires: September 2024 | Expires: September 2024 | |||
Transport Options for UDP | Transport Options for UDP | |||
draft-ietf-tsvwg-udp-options-31.txt | draft-ietf-tsvwg-udp-options-32.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 updates RFC 768 (UDP) by indicating the | |||
syntax, and semantics for UDP transport layer options. | location, syntax, and semantics for UDP transport layer options | |||
within the surplus area after the end of the UDP user data but | ||||
before the end of the IP length. | ||||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
skipping to change at page 1, line 38 ¶ | skipping to change at page 1, line 40 ¶ | |||
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 4, 2024. | This Internet-Draft will expire on September 21, 2024. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2024 IETF Trust and the persons identified as the | Copyright (c) 2024 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 27 ¶ | |||
4. Background ....................................................4 | 4. Background ....................................................4 | |||
5. UDP Option Intended Uses ......................................5 | 5. UDP Option Intended Uses ......................................5 | |||
6. UDP Option Design Principles ..................................6 | 6. UDP Option Design Principles ..................................6 | |||
7. The UDP Option Area ...........................................7 | 7. The UDP Option Area ...........................................7 | |||
8. The UDP Surplus Area Structure ...............................10 | 8. The UDP Surplus Area Structure ...............................10 | |||
9. The Option Checksum (OCS) ....................................10 | 9. The Option Checksum (OCS) ....................................10 | |||
10. UDP Options .................................................12 | 10. UDP Options .................................................12 | |||
11. SAFE UDP Options ............................................16 | 11. SAFE UDP Options ............................................16 | |||
11.1. End of Options List (EOL) ..............................17 | 11.1. End of Options List (EOL) ..............................17 | |||
11.2. No Operation (NOP) .....................................17 | 11.2. No Operation (NOP) .....................................17 | |||
11.3. Alternate Payload Checksum (APC) .......................18 | 11.3. Additional Payload Checksum (APC) ......................18 | |||
11.4. Fragmentation (FRAG) ...................................19 | 11.4. Fragmentation (FRAG) ...................................19 | |||
11.5. Maximum Datagram Size (MDS) ............................27 | 11.5. Maximum Datagram Size (MDS) ............................26 | |||
11.6. Maximum Reassembled Datagram Size (MRDS) ...............28 | 11.6. Maximum Reassembled Datagram Size (MRDS) ...............27 | |||
11.7. Echo request (REQ) and echo response (RES) .............28 | 11.7. Echo request (REQ) and echo response (RES) .............27 | |||
11.8. Timestamps (TIME) ......................................29 | 11.8. Timestamps (TIME) ......................................28 | |||
11.9. Authentication (AUTH), RESERVED Only ...................31 | 11.9. Authentication (AUTH), RESERVED Only ...................30 | |||
11.10. Experimental (EXP) ....................................31 | 11.10. Experimental (EXP) ....................................30 | |||
12. UNSAFE Options ..............................................32 | 12. UNSAFE Options ..............................................31 | |||
12.1. UNSAFE Compression (UCMP) ..............................33 | 12.1. UNSAFE Compression (UCMP) ..............................32 | |||
12.2. UNSAFE Encryption (UENC) ...............................33 | 12.2. UNSAFE Encryption (UENC) ...............................32 | |||
12.3. UNSAFE Experimental (UEXP) .............................33 | 12.3. UNSAFE Experimental (UEXP) .............................32 | |||
13. Rules for designing new options .............................33 | 13. Rules for designing new options .............................32 | |||
14. Option inclusion and processing .............................34 | 14. Option inclusion and processing .............................33 | |||
15. UDP API Extensions ..........................................36 | 15. UDP API Extensions ..........................................35 | |||
16. UDP Options are for Transport, Not Transit ..................38 | 16. UDP Options are for Transport, Not Transit ..................37 | |||
17. UDP options vs. UDP-Lite ....................................38 | 17. UDP options vs. UDP-Lite ....................................37 | |||
18. Interactions with Legacy Devices ............................39 | 18. Interactions with Legacy Devices ............................38 | |||
19. Options in a Stateless, Unreliable Transport Protocol .......40 | 19. Options in a Stateless, Unreliable Transport Protocol .......39 | |||
20. UDP Option State Caching ....................................40 | 20. UDP Option State Caching ....................................39 | |||
21. Updates to RFC 768 ..........................................41 | 21. Updates to RFC 768 ..........................................40 | |||
22. Interactions with other RFCs (and drafts) ...................41 | 22. Interactions with other RFCs (and drafts) ...................40 | |||
23. Multicast Considerations ....................................42 | 23. Multicast Considerations ....................................41 | |||
24. Security Considerations .....................................43 | 24. Security Considerations .....................................42 | |||
25. IANA Considerations .........................................45 | 25. IANA Considerations .........................................44 | |||
26. References ..................................................46 | 26. References ..................................................45 | |||
26.1. Normative References ...................................46 | 26.1. Normative References ...................................45 | |||
26.2. Informative References .................................46 | 26.2. Informative References .................................46 | |||
27. Acknowledgments .............................................49 | 27. Acknowledgments .............................................49 | |||
Appendix A. Implementation Information ..........................51 | Appendix A. Implementation Information ..........................50 | |||
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 [RFC9293], SCTP [RFC9260], and DCCP [RFC4340] | capabilities. TCP [RFC9293], SCTP [RFC9260], 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 updates RFC 768 with an extension to UDP that provides | |||
transport options including their generic syntax and semantics for | space for transport options including their generic syntax and | |||
their use in UDP's stateless, unreliable message protocol. | semantics for their use in UDP's stateless, unreliable message | |||
protocol. The details of the impact on RFC 768 are provided in | ||||
Section 21. This extension does not apply to UDP-Lite, as discussed | ||||
further in Section 17. | ||||
2. Conventions used in this document | 2. Conventions used in this document | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
In this document, the characters ">>" preceding an indented line(s) | In this document, the characters ">>" preceding an indented line(s) | |||
skipping to change at page 5, line 37 ¶ | skipping to change at page 5, line 45 ¶ | |||
5. UDP Option Intended Uses | 5. UDP Option Intended Uses | |||
UDP options provide a soft control plane to UDP. They enable | UDP options provide a soft control plane to UDP. They enable | |||
capabilities available in other transport protocols, such as | capabilities available in other transport protocols, such as | |||
fragmentation and reassembly, that enable UDP frames larger than the | fragmentation and reassembly, that enable UDP frames larger than the | |||
IP MTU to traverse devices that rely on transport ports, e.g., NATs. | IP MTU to traverse devices that rely on transport ports, e.g., NATs. | |||
It adds features that may, in the future, protect transport | It adds features that may, in the future, protect transport | |||
integrity and validate source identity (authentication), as well as | integrity and validate source identity (authentication), as well as | |||
those that may also encrypt the user payload, while still protecting | those that may also encrypt the user payload, while still protecting | |||
the UDP transport header - unlike DTLS. They also enable | the UDP transport header - unlike DTLS. They also enable | |||
packetization-layer path MTU discovery (PLPMTUD) over UDP, providing | packetization-layer path MTU discovery (PLPMTUD) over UDP, known as | |||
a means for probe packet validation without affecting the user data | Datagram Packetization Layer Path Maximum Transmission Unit | |||
plane, as well as providing explicit indication of the receiver | Discovery DPLPMTUD [Fa24], providing a means for probe packet | |||
transport reassembly size. | validation without affecting the user data plane, as well as | |||
providing explicit indication of the receiver transport reassembly | ||||
size. | ||||
UDP was originally intended to assume such capabilities could be | UDP was originally intended to assume such capabilities could be | |||
provided by the user or by a layer above UDP. However, enough | provided by the user or by a layer above UDP. However, enough | |||
protocols have evolved to use UDP directly, so such an intermediate | protocols have evolved to use UDP directly, so such an intermediate | |||
layer would be difficult to deploy for legacy applications. UDP | layer would be difficult to deploy for legacy applications. UDP | |||
options leverage the opportunity presented by the surplus area to | options leverage the opportunity presented by the surplus area to | |||
enable these extensions within the UDP transport layer itself. | enable these extensions within the UDP transport layer itself. | |||
6. UDP Option Design Principles | 6. UDP Option Design Principles | |||
skipping to change at page 6, line 50 ¶ | skipping to change at page 7, line 12 ¶ | |||
either replace these other protocols nor to instrument UDP to | either replace these other protocols nor to instrument UDP to | |||
replace the need for network testing devices. | replace the need for network testing devices. | |||
5. UDP options are a framework, not a protocol. | 5. UDP options are a framework, not a protocol. | |||
Options can be defined in this initial document even when the | Options can be defined in this initial document even when the | |||
details are not sufficient to specify a complete protocol. Uses | details are not sufficient to specify a complete protocol. Uses | |||
of such options may then be described or supplemented in other | of such options may then be described or supplemented in other | |||
documents. Examples herein include REQ/RES and TIME; in both | documents. Examples herein include REQ/RES and TIME; in both | |||
cases, the option format is defined, but the protocol that uses | cases, the option format is defined, but the protocol that uses | |||
these is specified elsewhere (REQ/RES for DPLPMTUD [Fa23])or left | these is specified elsewhere (REQ/RES for DPLPMTUD [Fa24]) or | |||
undefined (TIME). | left undefined (TIME). | |||
6. The UDP option mechanism and UDP options themselves should | 6. The UDP option mechanism and UDP options themselves should | |||
default to the same behavior experienced by a legacy receiver. | default to the same behavior experienced by a legacy receiver. | |||
By default, even when option checksums (OCS, APC), | By default, even when option checksums (OCS, APC), | |||
authentication, or encryption fail, every received packet is | authentication, or encryption fail, every received packet is | |||
passed (possibly with an empty data payload) to the user | passed (possibly with an empty data payload) to the user | |||
application. Options that do not modify user data should (by | application. Options that do not modify user data should (by | |||
default) result in the user data also being passed, even if, | default) result in the user data also being passed, even if, | |||
e.g., option checksums or authentication fails. It is always the | e.g., option checksums or authentication fails. It is always the | |||
user's obligation to override this default behavior explicitly. | user's obligation to override this default behavior explicitly. | |||
These principles are intended to enable the design and use of UDP | These principles are intended to enable the design and use of UDP | |||
options with minimal impact to legacy UDP endpoints, preferably | options with minimal impact to legacy UDP endpoints, preferably | |||
none. UDP is - and remains - a minimal transport protocol. | none. UDP is - and remains - a minimal transport protocol. | |||
Additional capability is explicitly activated by user applications | Additional capability is explicitly activated by user applications | |||
or libraries acting on their behalf. | or libraries acting on their behalf. | |||
Finally, although not a strict principle, UDP options do not attempt | Finally, UDP options do not attempt to match the number of zero- | |||
to match the number of zero-length UDP datagrams received by legacy | length UDP datagrams received by legacy and option-aware receivers | |||
and option-aware receivers from a source using UDP options. Zero- | from a source using UDP options. Legacy receivers interpret every | |||
length UDP packets have been used as "liveness" indicators see | UDP fragment as a zero-length packet (because they do not perform | |||
Section 5 of [RFC8085]), but such use is dangerous because they lack | reassembly), but option-aware receivers would reassemble the packet | |||
unique identifiers (IPv6 has none, the IPv4 ID field is deprecated | as a non-zero-length packet. Zero-length UDP packets have been used | |||
for such use [RFC6994]). | as "liveness" indicators see Section 5 of [RFC8085]), but such use | |||
is dangerous because they lack unique identifiers (the IPv6 base | ||||
header has none, the IPv4 ID field is deprecated for such use | ||||
[RFC6994]). | ||||
7. The UDP Option Area | 7. The UDP Option Area | |||
The UDP transport header includes demultiplexing and service | The UDP transport header includes demultiplexing and service | |||
identification (port numbers), an error detection checksum, and a | identification (port numbers), an error detection checksum, and a | |||
field that indicates the UDP datagram length (including UDP header). | field that indicates the UDP datagram length (including UDP header). | |||
The UDP Length field is typically redundant with the size of the | The UDP Length field is typically redundant with the size of the | |||
maximum space available as a transport protocol payload, as | maximum space available as a transport protocol payload, as | |||
determined by the IP header (see detail in Section 18). The UDP | determined by the IP header (see detail in Section 18). The UDP | |||
Option area is created when the UDP Length indicates a smaller | Option area is created when the UDP Length indicates a smaller | |||
skipping to change at page 10, line 32 ¶ | skipping to change at page 10, line 32 ¶ | |||
>> Option area bytes used for alignment before the OCS MUST be zero. | >> Option area bytes used for alignment before the OCS MUST be zero. | |||
The OCS contains an optional ones-complement sum that detects errors | The OCS contains an optional ones-complement sum that detects errors | |||
in the surplus area, which is not otherwise covered by the UDP | in the surplus area, which is not otherwise covered by the UDP | |||
checksum, as detailed in Section 9. | checksum, as detailed in Section 9. | |||
The remainder of the surplus area consists of options defined using | The remainder of the surplus area consists of options defined using | |||
a TLV (type, length, and optional value) syntax similar to that of | a TLV (type, length, and optional value) syntax similar to that of | |||
TCP [RFC9293], as detailed in Section 10. These options continue | TCP [RFC9293], as detailed in Section 10. These options continue | |||
until the end of the surplus area or can end earlier using the EOL | until the end of the surplus area or can end earlier using the EOL | |||
(end of list) option, followed by zeroes. | (end of list) option, followed by zeroes (discussed further in | |||
Section 10). | ||||
9. The Option Checksum (OCS) | 9. The Option Checksum (OCS) | |||
The Option Checksum (OCS) option is conventional Internet checksum | The Option Checksum (OCS) option is a conventional Internet checksum | |||
[RFC791] that detects errors in the surplus area. The OCS option | [RFC791] that detects errors in the surplus area. The OCS option | |||
contains a 16-bit checksum that is aligned to the first 2-byte | contains a 16-bit checksum that is aligned to the first 2-byte | |||
boundary, preceded by zeroes for padding (if needed), as shown in | boundary, preceded by zeroes for padding (if needed), as shown in | |||
Figure 4. | Figure 4. | |||
+--------+--------+--------+--------+ | +--------+--------+--------+--------+ | |||
| UDP data | 0 | | | UDP data | 0 | | |||
+--------+--------+--------+--------+ | +--------+--------+--------+--------+ | |||
| OCS | UDP options... | | | OCS | UDP options... | | |||
+--------+--------+--------+--------+ | +--------+--------+--------+--------+ | |||
skipping to change at page 11, line 24 ¶ | skipping to change at page 11, line 27 ¶ | |||
The design enables traversal of errant middleboxes that incorrectly | The design enables traversal of errant middleboxes that incorrectly | |||
compute the UDP checksum over the entire IP payload [Fa18][Zu20], | compute the UDP checksum over the entire IP payload [Fa18][Zu20], | |||
rather than only the UDP header and UDP payload (as indicated by the | rather than only the UDP header and UDP payload (as indicated by the | |||
UDP header length). Because the OCS is computed over the surplus | UDP header length). Because the OCS is computed over the surplus | |||
area and its length and then inverted, OCS effectively negates the | area and its length and then inverted, OCS effectively negates the | |||
effect that incorrectly including the surplus has on the UDP | effect that incorrectly including the surplus has on the UDP | |||
checksum. As a result, when OCS is non-zero, the UDP checksum is the | checksum. As a result, when OCS is non-zero, the UDP checksum is the | |||
same in either case. | same in either case. | |||
>> OCS MUST be non-zero when the UDP checksum is non-zero. | >> The OCS MUST be non-zero when the UDP checksum is non-zero. | |||
>> When the UDP checksum is zero, the OCS MAY be unused, and is then | >> When the UDP checksum is zero, the OCS MAY be unused, and is then | |||
indicated by a zero OCS value. | indicated by a zero OCS value. | |||
>> UDP option implementations MUST default to using OCS (i.e., as a | >> UDP option implementations MUST default to using OCS (i.e., as a | |||
non-zero value); users overriding that default take the risk of not | non-zero value); users overriding that default take the risk of not | |||
detecting nonstandard uses of the option area (of which there are | detecting nonstandard uses of the option area (of which there are | |||
none currently known). | none currently known). | |||
Like the UDP checksum, the OCS is optional under certain | Like the UDP checksum, the OCS is optional under certain | |||
skipping to change at page 11, line 46 ¶ | skipping to change at page 11, line 49 ¶ | |||
zero for IPv4 [RFC791] and for IPv6 [RFC8200] when UDP payload | zero for IPv4 [RFC791] and for IPv6 [RFC8200] when UDP payload | |||
already covered by another checksum, as might occur for tunnels | already covered by another checksum, as might occur for tunnels | |||
[RFC6935]. The same exceptions apply to the OCS when used to detect | [RFC6935]. The same exceptions apply to the OCS when used to detect | |||
bit errors; an additional exception occurs for its use in the UDP | bit errors; an additional exception occurs for its use in the UDP | |||
datagram prior to fragmentation or after reassembly (see Section | datagram prior to fragmentation or after reassembly (see Section | |||
11.4). | 11.4). | |||
The benefits are similar to allowing UDP checksums to be zero, but | The benefits are similar to allowing UDP checksums to be zero, but | |||
the risks differ. OCS is additionally important to ensure packets | the risks differ. OCS is additionally important to ensure packets | |||
with UDP options can traverse errant middleboxes [Zu20]. When the | with UDP options can traverse errant middleboxes [Zu20]. When the | |||
cost of computing OCS is negligible, it is better to use OCS to | cost of computing an OCS is negligible, it is better to use OCS to | |||
ensure such traversal. In cases where such traversal risks can | ensure such traversal. In cases where such traversal risks can | |||
safely be ignored, such as controlled environments, over paths where | safely be ignored, such as controlled environments, over paths where | |||
traversal is validated, or where upper layer protocols | traversal is validated, or where upper layer protocols | |||
(applications, libraries, etc.) can adapt (by enabling OCS when | (applications, libraries, etc.) can adapt (by enabling OCS when | |||
packet exchange fails), and when bit errors at the UDP layer would | packet exchange fails), and when bit errors at the UDP layer would | |||
be detected by other layers (as with the UDP checksum) OCS can be | be detected by other layers (as with the UDP checksum) OCS can be | |||
disabled, e.g., to conserve energy or processing resources or when | disabled, e.g., to conserve energy or processing resources or when | |||
it can improve performance. This is why zeroing OCS is only safe | it can improve performance. This is why zeroing OCS is only safe | |||
when UDP checksum is also zero, but why OCS might still be used in | when UDP checksum is also zero, but why OCS might still be used in | |||
that case. | that case. | |||
The OCS covers the surplus area as formatted for transmission and is | The OCS covers the surplus area as formatted for transmission and is | |||
processed immediately upon reception. | processed immediately upon reception. | |||
>> If the OCS fails, all options MUST be ignored and the surplus | >> If the receiver validation of the OCS fails, all options MUST be | |||
area silently discarded. | ignored and the surplus area silently discarded. | |||
>> UDP user data that is validated by a correct UDP checksum MUST be | >> UDP user data that is validated by a correct UDP checksum MUST be | |||
delivered to the application layer, even if the OCS fails, unless | delivered to the application layer, even if the OCS fails, unless | |||
the endpoints have negotiated otherwise for this UDP packet's socket | the endpoints have negotiated otherwise for this UDP packet's socket | |||
pair. | pair. | |||
When not used (i.e., containing zero), the OCS is assumed to be | When not used (i.e., containing zero), the OCS is assumed to be | |||
"correct" for the purpose of accepting UDP datagrams at a receiver | "correct" for the purpose of accepting UDP datagrams at a receiver | |||
(see Section 14). | (see Section 14). | |||
skipping to change at page 14, line 9 ¶ | skipping to change at page 14, line 9 ¶ | |||
>> UDP options MUST be interpreted in the order in which they occur | >> UDP options MUST be interpreted in the order in which they occur | |||
in the surplus area. | in the surplus area. | |||
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* 6 Alternate payload checksum (APC) | 2* 6 Additional payload checksum (APC) | |||
3* 10/12 Fragmentation (FRAG) | 3* 10/12 Fragmentation (FRAG) | |||
4* 4 Maximum datagram size (MDS) | 4* 4 Maximum datagram size (MDS) | |||
5* 4 Maximum reassembled datagram size (MRDS) | 5* 4 Maximum reassembled datagram size (MRDS) | |||
6* 6 Request (REQ) | 6* 6 Request (REQ) | |||
7* 6 Response (RES) | 7* 6 Response (RES) | |||
8 10 Timestamps (TIME) | 8 10 Timestamps (TIME) | |||
9 (varies) RESERVED for Authentication (AUTH) | 9 (varies) RESERVED for 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) RESERVED for Compression (UCMP) | 192 (varies) RESERVED for Compression (UCMP) | |||
193 (varies) RESERVED for Encryption (UENC) | 193 (varies) RESERVED for Encryption (UENC) | |||
194-253 UNASSIGNED-UNSAFE (assignable by IANA) | 194-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-UNSAFE | |||
Options indicated by Kind values in the range 0..191 are known as | Options indicated by Kind values in the range 0..191 are known as | |||
SAFE options because they do not alter the UDP data payload and thus | SAFE options because they do not interfere with use of that data by | |||
do not interfere with use of that data by legacy endpoints or when | legacy endpoints or when the option is unsupported. Options | |||
the option is unsupported. Options indicated by Kind values in the | indicated by Kind values in the range 192..255 are known as UNSAFE | |||
range 192..255 are known as UNSAFE options because they do alter the | options because might interfere with use by legacy receiving | |||
UDP data payload and thus would interfere with legacy endpoints. | endpoints (e.g., an option that alters the UDP data payload). | |||
UNSAFE option nicknames are expected to begin with capital "U", | UNSAFE option nicknames are expected to begin with capital "U", | |||
which should be avoided for SAFE option nicknames (see Section 25). | which should be avoided for SAFE option nicknames (see Section 25). | |||
RESERVED and RESERVED-UNSAFE are not assignable by IANA and not | RESERVED and RESERVED-UNSAFE are not assignable by IANA and not | |||
otherwise defined at this time. The AUTH, UCMP, and UENC | otherwise defined at this time. The AUTH, UCMP, and UENC | |||
reservations are intended for all future options supporting | reservations are intended for all future options supporting | |||
authentication, compression, and encryption, respectively, and | authentication, compression, and encryption, respectively, and | |||
remain reserved until assigned for those uses. | remain reserved until assigned for those uses. | |||
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 | |||
skipping to change at page 15, line 7 ¶ | skipping to change at page 15, line 10 ¶ | |||
Section 11.4. | Section 11.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 | |||
a "*" above: EOL, NOP, APC, FRAG, MDS, MRDS, REQ, and RES. This | a "*" above: EOL, NOP, APC, FRAG, MDS, MRDS, REQ, and RES. 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. | |||
>> An endpoint supporting UDP options MUST treat unsupported options | ||||
in the UNSAFE range as terminating all option processing. | ||||
>> All other SAFE options (without a "*") MAY be implemented, and | >> All other SAFE options (without a "*") MAY be implemented, and | |||
their use SHOULD be determined either out-of-band or negotiated, | their use SHOULD be determined either out-of-band or negotiated, | |||
notably if needed to detect when options are silently ignored by | notably if needed to detect when options are silently ignored by | |||
legacy receivers. | legacy receivers. | |||
>> Receivers supporting UDP options MUST silently ignore unknown | >> Receivers supporting UDP options MUST silently ignore unknown | |||
SAFE options (i.e., in the same way a legacy receiver would ignore | SAFE options (i.e., in the same way a legacy receiver would ignore | |||
all UDP options). That includes options whose length does not | all UDP options). That includes options whose length does not | |||
indicate the specified value(s), as long as the length is not | indicate the specified value(s), as long as the length is not | |||
inherently invalid (i.e., smaller than 2 for the default and 4 for | inherently invalid (i.e., smaller than 2 for the default and 4 for | |||
the extended formats). | the extended formats). | |||
>> UNSAFE options MUST be used only with the FRAG option, in a | >> UNSAFE options MUST be used only with the FRAG option, in a | |||
manner that prevents them from being silently ignored while still | manner that prevents them from being silently ignored while still | |||
passing up potentially modified UDP payload. This ensures their safe | passing up potentially modified UDP payload. This ensures their safe | |||
use in environments that might include legacy receivers (See Section | use in environments that might include legacy receivers (See Section | |||
12), because the UDP payload occurs inside the FRAG option area and | 12), because the UDP payload occurs inside the FRAG option area and | |||
is silently discarded by legacy receivers. | is silently discarded by legacy receivers. | |||
>> Receivers supporting UDP options MUST silently drop all UDP | >> Receivers supporting UDP options that receive unsupported options | |||
options in a datagram containing an UNSAFE option when any UNSAFE | in the UNSAFE range MUST terminate all option processing and MUST | |||
option it contains is unknown. See Section 12 for further discussion | silently drop all UDP options in that datagram. See Section 12 for | |||
of UNSAFE options. | further discussion of UNSAFE options. | |||
>> Each option SHOULD NOT occur more than once in a single UDP | >> Each option SHOULD NOT occur more than once in a single UDP | |||
datagram, the only exceptions being NOP, EXP, and UEXP. If an option | datagram, the only exceptions being NOP, EXP, and UEXP. If an option | |||
other than these occurs more than once, a receiver MUST interpret | other than these occurs more than once, a receiver MUST interpret | |||
only the first instance of that option and MUST ignore all others. | only the first instance of that option and MUST ignore all others. | |||
Section 24 provides additional advice for DOS issues that involve | Section 24 provides additional advice for DOS issues that involve | |||
large numbers of options, whether valid, unknown, or repeating. | large numbers of options, whether valid, unknown, or repeating. | |||
>> EXP and UEXP MAY occur more than once, but SHOULD NOT occur more | >> EXP and UEXP MAY occur more than once, but SHOULD NOT occur more | |||
than once using the same ExID (see Sections 11.10 and 12.3). | than once using the same ExID (see Sections 11.10 and 12.3). | |||
skipping to change at page 16, line 17 ¶ | skipping to change at page 16, line 16 ¶ | |||
unpredictable. This does not prohibit future uses of the entire | unpredictable. This does not prohibit future uses of the entire | |||
surplus area; space that would have occurred after the EOL can be | surplus area; space that would have occurred after the EOL can be | |||
used as a UDP option instead, i.e., rather than using the EOL option | used as a UDP option instead, i.e., rather than using the EOL option | |||
and trying to defining meaning beyond it, define a new option that | and trying to defining meaning beyond it, define a new option that | |||
uses the remaining surplus area as an option itself, in conjunction | uses the remaining surplus area as an option itself, in conjunction | |||
with an assigned UDP option codepoint and length to unambiguously | with an assigned UDP option codepoint and length to unambiguously | |||
indicate the meaning of that area. This also does not prohibit | indicate the meaning of that area. This also does not prohibit | |||
options that modify later options (in order of appearance within a | options that modify later options (in order of appearance within a | |||
packet), such as would typically be the case for compression (UCMP). | packet), such as would typically be the case for compression (UCMP). | |||
>> Impossible lengths SHOULD be treated as an indication of a | ||||
malformed surplus area and all options SHOULD silently be discarded. | ||||
This includes lengths that imply a physical impossibility, e.g., | ||||
smaller than two for conventional options and four for extended | ||||
length options. Lengths other than those expected result in safe | ||||
options being ignored and skipped over, as with any other unknown | ||||
safe option. | ||||
Receivers cannot generally treat unexpected option lengths as | Receivers cannot generally treat unexpected option lengths as | |||
invalid, as this would unnecessarily limit future revision of | invalid, as this would unnecessarily limit future revision of | |||
options (e.g., defining a new APC that is defined by having a | options (e.g., defining a new APC that is defined by having a | |||
different length). The exception is only for lengths that imply a | different length). | |||
physical impossibility, e.g., smaller than two for conventional | ||||
options and four for extended length options. | ||||
>> Impossible lengths SHOULD be treated as an indication of a | ||||
malformed surplus area and all options SHOULD silently be discarded. | ||||
Lengths other than those expected MUST result in safe options being | ||||
ignored and skipped over, as with any other unknown safe option. | ||||
>> Option lengths MUST NOT exceed the IP length of the overall IP | >> Option lengths MUST NOT exceed the IP length of the overall IP | |||
datagram. If this occurs, the options MUST be treated as malformed | datagram. A receiver MUST drop all options in such a malformed | |||
and all options dropped, and the event MAY be logged for diagnostics | packet and the event MAY be logged for diagnostics (logging SHOULD | |||
(logging SHOULD be rate limited). | be rate limited). | |||
>> "Must-support" options other than NOP and EOL MUST come before | >> "Must-support" options other than NOP and EOL MUST be placed by | |||
other options. | the transmitter before other UDP options and a receiver MUST drop | |||
all UDP options in such malformed packet (i.e., in which this | ||||
ordering is not honored) and that event MAY be logged for | ||||
diagnostics (logging SHOULD be rate limited). | ||||
The requirement that must-support options come before others is | The requirement that must-support options come before others is | |||
intended to allow for endpoints to implement DOS protection, as | intended to allow for endpoints to implement DOS protection, as | |||
discussed further in Section 24. | discussed further in Section 24. | |||
11. SAFE UDP Options | 11. 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 | |||
skipping to change at page 17, line 37 ¶ | skipping to change at page 17, line 37 ¶ | |||
>> Bytes after EOL in the surplus area MAY be checked as being zero | >> Bytes after EOL in the surplus area MAY be checked as being zero | |||
on receipt, but MUST NOT be otherwise processed (except for OCS | on receipt, but MUST NOT be otherwise processed (except for OCS | |||
calculation, which zeros would not affect) and MUST NOT be passed to | calculation, which zeros would not affect) and MUST NOT be passed to | |||
the user (e.g., as part of the surplus area). | the user (e.g., as part of the surplus area). | |||
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 [Fa23]). | e.g., for UDP DPLPMTUD (Section 4.1 of [Fa24]). | |||
11.2. No Operation (NOP) | 11.2. No Operation (NOP) | |||
The No Operation (NOP, Kind=1) option is a one-byte placeholder, | The No Operation (NOP, Kind=1) option is a one-byte placeholder, | |||
intended to be used as padding, e.g., to align multi-byte options | intended to be used as padding, e.g., to align multi-byte options | |||
along 16-bit, 32-bit, or 64-bit boundaries. | along 16-bit, 32-bit, or 64-bit boundaries. | |||
+--------+ | +--------+ | |||
| Kind=1 | | | Kind=1 | | |||
+--------+ | +--------+ | |||
skipping to change at page 18, line 20 ¶ | skipping to change at page 18, line 20 ¶ | |||
>> Receivers persistently experiencing packets with more than seven | >> Receivers persistently experiencing packets with more than seven | |||
consecutive NOPs SHOULD log such events, at least occasionally, as a | consecutive NOPs SHOULD log such events, at least occasionally, as a | |||
potential DOS indicator. | potential DOS indicator. | |||
NOPs are not reported to the user, whether used per-datagram or per- | NOPs are not reported to the user, whether used per-datagram or per- | |||
fragment (as defined in Section 11.4). | fragment (as defined in Section 11.4). | |||
This issue is discussed further in Section 24. | This issue is discussed further in Section 24. | |||
11.3. Alternate Payload Checksum (APC) | 11.3. Additional Payload Checksum (APC) | |||
The Alternate Payload Checksum (APC, Kind=2) option provides a | The Additional Payload Checksum (APC, Kind=2) option provides a | |||
stronger alternative to the checksum in the UDP header, using a 32- | stronger supplement to the checksum in the UDP header, using a 32- | |||
bit CRC of the conventional UDP user data payload only (excluding | bit CRC of the conventional UDP user data payload only (excluding | |||
the IP pseudoheader, UDP header, and surplus area). It is an | the IP pseudoheader, UDP header, and surplus area). It is not an | |||
"alternate" to the UDP checksum that covers the user data - not to | alternative to the UDP checksum because it does not cover the IP | |||
the OCS (the latter covers the surplus area only). Unlike the UDP | pseudoheader or UDP header, and it is not a supplement to the OCS | |||
checksum, APC does not include the IP pseudoheader or UDP header, | because the latter covers the surplus area only. Its purpose is to | |||
thus it does not need to be updated by NATs when IP addresses or UDP | detect user data errors that the UDP checksum might not detect. | |||
ports are rewritten. Its purpose is to detect user data errors that | ||||
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 19, line 8 ¶ | skipping to change at page 19, line 5 ¶ | |||
When present, the APC always contains a valid CRC checksum. There | When present, the APC always contains a valid CRC checksum. There | |||
are no reserved values, including the value of zero. If the CRC is | 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 | zero, this must indicate a valid checksum (i.e., it does not | |||
indicate that the APC is not used; instead, the option would simply | indicate that the APC is not used; instead, the option would simply | |||
not be included if that were the desired effect). | not be included if that were the desired effect). | |||
APC does not protect the UDP pseudoheader; only the current UDP | APC does not protect the UDP pseudoheader; only the current UDP | |||
checksum provides that protection (when used). APC cannot provide | checksum provides that protection (when used). APC cannot provide | |||
that protection because it would need to be updated whenever the UDP | that protection because it would need to be updated whenever the UDP | |||
pseudoheader changed, e.g., during NAT address and port translation; | pseudoheader changed, e.g., during NAT address and port translation. | |||
because this is not the case, APC does not cover the pseudoheader. | ||||
>> UDP packets with incorrect APC checksums MUST be passed to the | >> UDP packets with incorrect APC checksums SHOULD be passed to the | |||
application by default, e.g., with a flag indicating APC failure. | application, e.g., with a flag indicating APC failure. This is the | |||
default behavior for APC. | ||||
Like all SAFE UDP options, APC needs to be silently ignored when | Like all SAFE UDP options, APC needs to be silently ignored when | |||
failing by default, unless the receiver has been configured to do | failing by default, unless the receiver has been configured to do | |||
otherwise. Although all UDP option-aware endpoints support APC | otherwise. Although all UDP option-aware endpoints support APC | |||
(being in the required set), this silently-ignored behavior ensures | (being in the required set), this silently-ignored behavior ensures | |||
that option-aware receivers operate the same as legacy receivers | that option-aware receivers operate the same as legacy receivers | |||
unless overridden. Another reason is because APC may fail even where | unless overridden. Another reason is because APC may fail even where | |||
the user data has not been corrupted, such as when its contents have | the user data has not been corrupted, such as when its contents have | |||
been overwritten. Such overwrites could be intentional and not | been intentionally overwritten e.g. by a middlebox to update | |||
widely known; defaulting to silent ignore ensures that option-aware | embedded ports numbers or IP addresses. Such overwrites could be | |||
endpoints do not change how users or applications operate unless | intentional and not widely known; defaulting to silent ignore | |||
explicitly directed to do otherwise. | ensures that option-aware endpoints do not change how users or | |||
applications operate unless explicitly directed to do otherwise. | ||||
>> UDP packets with unrecognized APC lengths MUST receive the same | >> UDP packets with unrecognized APC lengths MUST receive the same | |||
treatment as UDP packets with incorrect APC checksums. | 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. | |||
APC is reported to the user, whether used per-datagram or per- | APC is reported to the user and useful only per-datagram, because | |||
fragment (as defined in Section 11.4). In the latter case, it is | fragments have no UDP user data. | |||
indicated as success only if reassembly is complete. | ||||
11.4. Fragmentation (FRAG) | 11.4. Fragmentation (FRAG) | |||
The Fragmentation (FRAG, Kind=3) option supports UDP fragmentation | The Fragmentation (FRAG, Kind=3) option supports UDP fragmentation | |||
and reassembly, which can be used to transfer UDP messages larger | and reassembly, which can be used to transfer UDP messages larger | |||
than allowed by the IP receive MTU (EMTU_R [RFC1122]). FRAG includes | than allowed by the IP receive MTU (EMTU_R [RFC1122]). FRAG includes | |||
a copy of the same UDP transport ports in each fragment, enabling | a copy of the same UDP transport ports in each fragment, enabling | |||
them to traverse Network Address (and port) Translation (NAT) | them to traverse Network Address (and port) Translation (NAT) | |||
devices, in contrast to the behavior of IP fragments. FRAG is | devices, in contrast to the behavior of IP fragments. FRAG is | |||
typically used with the UDP MDS and MRDS options to enable more | typically used with the UDP MDS and MRDS options to enable more | |||
skipping to change at page 25, line 26 ¶ | skipping to change at page 24, line 26 ¶ | |||
Per-fragment UDP options, if used in addition to FRAG, occur before | Per-fragment UDP options, if used in addition to FRAG, occur before | |||
the fragment data. They typically occur after the FRAG option, | the fragment data. They typically occur after the FRAG option, | |||
except where they modify the FRAG option itself (e.g., UENC or | except where they modify the FRAG option itself (e.g., UENC or | |||
UCMP). Per-fragment options are processed before the fragment is | UCMP). Per-fragment options are processed before the fragment is | |||
included in the reassembled datagram. Such options can be useful to | included in the reassembled datagram. Such options can be useful to | |||
protect the reassembly process itself, e.g., to prevent the | protect the reassembly process itself, e.g., to prevent the | |||
reassembly cache from being polluted (using AUTH or UENC). | reassembly cache from being polluted (using AUTH or UENC). | |||
>> Fragments of a single datagram MAY use different sets of options. | >> Fragments of a single datagram MAY use different sets of options. | |||
It is expected to be prohibitive to validate uniformity across all | It is expected to be computationally expensive to validate | |||
fragments and there may be legitimate reasons for including options | uniformity across all fragments and there may be legitimate reasons | |||
in a fragment but not all fragments (e.g., MDS, MRDS). | for including options in a fragment but not all fragments (e.g., | |||
MDS, MRDS). | ||||
If an option is used per-fragment but defined as not usable per- | If an option is used per-fragment but defined as not usable per- | |||
fragment, it is treated the same as any other unknown option. | fragment, it is treated the same as any other unknown option. | |||
Per-datagram UDP options, if used, reside in the surplus area of the | Per-datagram UDP options, if used, reside in the surplus area of the | |||
original UDP datagram. Processing of those options occurs after | original UDP datagram. Processing of those options occurs after | |||
reassembly is complete. This enables the safe use of UNSAFE options, | reassembly is complete. This enables the safe use of UNSAFE options, | |||
which are required to result in discarding the entire UDP datagram | which are required to result in discarding the entire UDP datagram | |||
if they are unknown to the receiver or otherwise fail (see Section | if they are unknown to the receiver or otherwise fail (see Section | |||
12). | 12). | |||
skipping to change at page 27, line 8 ¶ | skipping to change at page 26, line 8 ¶ | |||
5. Complete the processing associated with creating these additional | 5. Complete the processing associated with creating these additional | |||
per-fragment UDP options for each fragment. | per-fragment UDP options for 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. | |||
>> Reassembly failures at the receiver result in silent discard of | >> Reassembly failures at the receiver result in silent discard of | |||
any per-fragment options and fragment contents. Such failures SHOULD | any per-fragment options and fragment contents and such failures | |||
NOT generate zero-length frames to the user. | SHOULD NOT generate zero-length frames to the user. | |||
>> Finally, because fragmentation processing can be expensive, the | >> Finally, because fragmentation processing can be expensive, the | |||
FRAG option SHOULD be avoided unless the original datagram requires | FRAG option SHOULD be avoided unless the original datagram requires | |||
fragmentation or it is needed for "safe" use of UNSAFE options. | fragmentation or it is needed for "safe" use of UNSAFE options. | |||
>> Users MAY also select the FRAG option to provide limited support | >> Users MAY also select the FRAG option to provide limited support | |||
for UDP options in systems that have access to only the initial | for UDP options in systems that have access to only the initial | |||
portion of the data in incoming or outgoing packets, with the caveat | portion of the data in incoming or outgoing packets, with the caveat | |||
that such packets would be silently ignored by legacy receivers | that such packets would be silently ignored by legacy receivers | |||
(that do not support UDP options). | (that do not support UDP options). | |||
skipping to change at page 29, line 10 ¶ | skipping to change at page 28, line 10 ¶ | |||
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 provides UDP packet-level acknowledgements as a capability | options provides UDP packet-level acknowledgements as a capability | |||
for use by upper layer protocols, e.g., user applications, | for use by upper layer protocols, e.g., user applications, | |||
libraries, operating systems, etc. Both the REQ and RES are under | libraries, operating systems, etc. Both the REQ and RES are under | |||
the control of these upper layers, i.e., UDP itself never | the control of these upper layers, i.e., UDP itself never | |||
automatically responds to a REQ with a RES. Instead, the REQ is | automatically responds to a REQ with a RES. Instead, the REQ is | |||
delivered to the upper layer, which decides whether and when to | delivered to the upper layer, which decides whether and when to | |||
issue a RES. | issue a RES. | |||
One such use is described as part of the UDP options variant of | One such use is described as part of DPLPMTUD [Fa24]. The options | |||
packetization layer path MTU discovery (PLPMTUD) [Fa23]. The options | ||||
both have the format indicated in Figure 15, in which the token has | both have the format indicated in Figure 15, in which the token has | |||
no internal structure or meaning. | 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 15 UDP REQ and RES options format | Figure 15 UDP REQ and RES options format | |||
skipping to change at page 29, line 33 ¶ | skipping to change at page 28, line 32 ¶ | |||
supporting REQ/RES and responding with a RES, the upper layer SHOULD | supporting REQ/RES and responding with a RES, the upper layer SHOULD | |||
respond with the most recently received REQ token. | respond with the most recently received REQ token. | |||
>> REQ/RES MUST be disabled by default, i.e., arriving REQs are | >> REQ/RES MUST be disabled by default, i.e., arriving REQs are | |||
silently ignored and RES cannot be issued unless REQ/RES is actively | silently ignored and RES cannot be issued unless REQ/RES is actively | |||
enabled, e.g., for DPLPMTUD or other known use by an upper layer | enabled, e.g., for DPLPMTUD or other known use by an upper layer | |||
mechanism. | mechanism. | |||
For example, an application needs to explicitly enable the | For example, an application needs to explicitly enable the | |||
generation of a RES response by DPLPMTUD when using UDP Options | generation of a RES response by DPLPMTUD when using UDP Options | |||
[Fa23]. | [Fa24]. | |||
>> The token used in a RES option MUST be a token received in a REQ | >> The token transmitted in a RES option MUST be a token received in | |||
option. This ensures that the response is to a received request. | a REQ option by the transmitter. This ensures that the response is | |||
to a received request. | ||||
REQ and RES option kinds appear at most once each in each UDP | REQ and RES option kinds appear at most once each in each UDP | |||
packet, as with most other options. Note also that the FRAG option | packet, as with most other options. Note also that the FRAG option | |||
is not used when sending DPLPMTUD probes to determine a PLPMTU | is not used when sending DPLPMTUD probes to determine a PLPMTU | |||
[Fa23]. | [Fa24]. | |||
REQ and RES are reported to the user, whether used per-datagram or | REQ and RES are reported to the user, whether used per-datagram or | |||
per-fragment (as defined in Section 11.4). When used per-fragment, | per-fragment (as defined in Section 11.4). When used per-fragment, | |||
the report should indicate the most recently received token. | the report should indicate the most recently received token. | |||
11.8. Timestamps (TIME) | 11.8. Timestamps (TIME) | |||
The Timestamp (TIME, Kind=8) 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 | |||
skipping to change at page 31, line 36 ¶ | skipping to change at page 30, line 36 ¶ | |||
Like APC, AUTH is a SAFE option because it would not modify the UDP | Like APC, AUTH is a SAFE option because it would not modify the UDP | |||
user data. AUTH may fail even where the user data has not been | user data. AUTH may fail even where the user data has not been | |||
corrupted, such as when its contents have been overwritten. Such | corrupted, such as when its contents have been overwritten. Such | |||
overwrites could be intentional and not widely known; defaulting to | overwrites could be intentional and not widely known; defaulting to | |||
silent ignore ensures that option-aware endpoints do not change how | silent ignore ensures that option-aware endpoints do not change how | |||
users or applications operate unless explicitly directed to do | users or applications operate unless explicitly directed to do | |||
otherwise. | otherwise. | |||
11.10. Experimental (EXP) | 11.10. Experimental (EXP) | |||
The Experimental option (EXP, Kind=127) is reserved for experiments | The Experimental option (EXP, Kind=127) is allocated for experiments | |||
[RFC3692]. Only one such value is reserved because experiments are | [RFC3692]. Only one such value is allocated because experiments are | |||
expected to use an Experimental ID (ExIDs) to differentiate | expected to use an Experimental ID (ExIDs) to differentiate | |||
concurrent use for different purposes, using UDP ExIDs registered | concurrent use for different purposes, using UDP ExIDs registered | |||
with IANA according to the approach developed for TCP experimental | with IANA according to the approach developed for TCP 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 | |||
account for the Kind, Length, and the minimum 16-bit UDP ExID | account for the Kind, Length, and the 16-bit UDP ExID identifier | |||
identifier (similar to TCP ExIDs [RFC6994]). | (similar to TCP ExIDs [RFC6994]). | |||
The UDP EXP option uses only 16-bit ExIDs, unlike TCP ExiDs. In TCP, | ||||
the first 16 bits of the ExID is unique; the additional 16 bits, | ||||
where present, iss used to decrease the chance of the entire ExID | ||||
occurring in legacy use of the TCP EXP option. This extended variant | ||||
provides no similar use for UDP EXP because ExIDs are required. | ||||
The UDP EXP option also includes an extended length format, where | The UDP EXP option also includes an extended length format, where | |||
the option LEN is 255 followed by two bytes of extended length. | the option LEN is 255 followed by two bytes of extended length. | |||
+----------+----------+----------+----------+ | +----------+----------+----------+----------+ | |||
| Kind=127 | 255 | Extended Length | | | Kind=127 | 255 | Extended Length | | |||
+----------+----------+----------+----------+ | +----------+----------+----------+----------+ | |||
| UDP ExID. |(option contents...) | | | UDP ExID |(option contents...) | | |||
+----------+----------+----------+----------+ | +----------+----------+----------+----------+ | |||
Figure 18 UDP EXP extended option format | Figure 18 UDP EXP extended option format | |||
Assigned UDP experimental IDs (ExIDs) assigned from a single | Assigned UDP experimental IDs (ExIDs) assigned from a single | |||
registry managed by IANA (see Section 25). Assigned ExIDs can be | registry managed by IANA (see Section 25). Assigned ExIDs can be | |||
used in either the EXP or UEXP options (see Section 12.3 for the | used in either the EXP or UEXP options (see Section 12.3 for the | |||
latter). | latter). | |||
12. UNSAFE Options | 12. UNSAFE Options | |||
skipping to change at page 33, line 7 ¶ | skipping to change at page 32, line 9 ¶ | |||
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 or | datagram includes an UNSAFE option whose UKind is not supported or | |||
if an UNSAFE option appears outside the context of a fragment or | if an UNSAFE option appears outside the context of a fragment or | |||
reassembled fragments. | reassembled fragments. | |||
12.1. UNSAFE Compression (UCMP) | 12.1. UNSAFE Compression (UCMP) | |||
The UNSAFE Compression (UENC, Kind=192) option is reserved for all | The UNSAFE Compression (UCMP, Kind=192) option is reserved for all | |||
UDP compression mechanisms. UCMP is expected to cover the UDP user | UDP compression mechanisms. UCMP is expected to cover the UDP user | |||
data and some (e.g., later, in sequence) UDP options. | data and some (e.g., later, in sequence) UDP options. | |||
12.2. UNSAFE Encryption (UENC) | 12.2. UNSAFE Encryption (UENC) | |||
The UNSAFE Encryption (UENC, Kind=193) option is reserved for all | The UNSAFE Encryption (UENC, Kind=193) option is reserved for all | |||
UDP encryption mechanisms. UENC is expected to cover the UDP user | UDP encryption mechanisms. UENC is expected to cover the UDP user | |||
data and some (e.g., later, in sequence) UDP options, with possible | data and some (e.g., later, in sequence) UDP options, with possible | |||
additional protection of portions of the IP and UDP headers and | additional protection of portions of the IP and UDP headers and | |||
potentially also support for NAT traversal, in a similar manner as | potentially also support for NAT traversal, in a similar manner as | |||
skipping to change at page 37, line 14 ¶ | skipping to change at page 36, line 14 ¶ | |||
o Extend the receive function to indicate the per-packet options | o Extend the receive function to indicate the per-packet options | |||
and their parameters as received with the corresponding received | and their parameters as received with the corresponding received | |||
datagram. Note that per-fragment options are handled within the | datagram. Note that per-fragment options are handled within the | |||
processing of each fragment. | processing of each fragment. | |||
>> Options and their processing status (success/fail) MUST be | >> Options and their processing status (success/fail) MUST be | |||
available to the user (i.e., application layer or upper layer | available to the user (i.e., application layer or upper layer | |||
protocol/service), both for the packet and for the fragment set, | protocol/service), both for the packet and for the fragment set, | |||
except for FRAG, NOP, and EOL; those three options are handled | except for FRAG, NOP, and EOL; those three options are handled | |||
within UDP option processing only. | within UDP option processing only. As a reminder (from Section | |||
14), all options except UNSAFE options MUST result in the UDP | ||||
user data being passed to the application layer, regardless of | ||||
whether all options are processed, supported, or succeed. | ||||
o For fragments, success for an option is reported only when all | o For fragments, success for an option is reported only when all | |||
fragments succeed for that option. | fragments succeed for that option. | |||
>> Per-fragment option status reporting SHOULD default as needed | >> Per-fragment option status reporting SHOULD default as needed | |||
(e.g., not computed and/or not passed up to the upper layers) to | (e.g., not computed and/or not passed up to the upper layers) to | |||
minimize overhead unless actively requested (e.g., by the | minimize overhead unless actively requested (e.g., by the | |||
user/application layer). | user/application layer). | |||
o >> SAFE options associated with fragments are accumulated when | o >> SAFE options associated with fragments are accumulated when | |||
skipping to change at page 37, line 38 ¶ | skipping to change at page 36, line 41 ¶ | |||
fragment. | fragment. | |||
o Extend the send function to indicate the options to be added to | o Extend the send function to indicate the options to be added to | |||
the corresponding sent datagram. This includes indicating which | the corresponding sent datagram. This includes indicating which | |||
options apply to individual fragments vs. which apply to the UDP | options apply to individual fragments vs. which apply to the UDP | |||
packet prior to fragmentation, if fragmentation is enabled. This | packet prior to fragmentation, if fragmentation is enabled. This | |||
includes a minimum datagram length, such that the options list | includes a minimum datagram length, such that the options list | |||
ends in EOL and additional space is zero-filled as needed. It | ends in EOL and additional space is zero-filled as needed. It | |||
also includes a maximum fragment size, e.g., as discovered by | also includes a maximum fragment size, e.g., as discovered by | |||
DPLPMTUD, whether implemented at the application layer per | DPLPMTUD, whether implemented at the application layer per | |||
[RFC8899] or in conjunction with other UDP options [Fa23]. | [RFC8899] or in conjunction with other UDP options [Fa24]. | |||
Examples of API instances for Linux and FreeBSD are provided in | Examples of API instances for Linux and FreeBSD are provided in | |||
Appendix A, to encourage uniform cross-platform implementations. | Appendix A, to encourage uniform cross-platform implementations. | |||
APIs are not intended to provide user control over option order, | APIs are not intended to provide user control over option order, | |||
especially on a per-packet basis, as this could create a covert | especially on a per-packet basis, as this could create a covert | |||
channel (see Section 24). Similarly, APIs are not intended to | channel (see Section 24). Similarly, APIs are not intended to | |||
provide user/application control over UDP fragment boundaries on a | provide user/application control over UDP fragment boundaries on a | |||
per-packet basis, although they are expected to allow control over | per-packet basis, although they are expected to allow control over | |||
which options, including fragmentation, are enabled (or disabled) on | which options, including fragmentation, are enabled (or disabled) on | |||
a per-packet basis. Such control over when fragmentation is used is | a per-packet basis. Such control over fragmentation is critical to | |||
critical to DPLPMTUD. | DPLPMTUD. | |||
16. UDP Options are for Transport, Not Transit | 16. UDP Options are for Transport, Not Transit | |||
UDP options are indicated in the surplus area of the IP payload that | UDP options are indicated in the surplus area of the IP payload that | |||
is not used by UDP. That area is really part of the IP payload, not | is not used by UDP. That area is really part of the IP payload, not | |||
the UDP payload, and as such, it might be tempting to consider | the UDP payload, and as such, it might be tempting to consider | |||
whether this is a generally useful approach to extending IP. | whether this is a generally useful approach to extending IP. | |||
Unfortunately, the surplus area exists only for transports that | Unfortunately, the surplus area exists only for transports that | |||
include their own transport layer payload length indicator. TCP and | include their own transport layer payload length indicator. TCP and | |||
SCTP include header length fields that already provide space for | SCTP include header length fields that already provide space for | |||
transport options by indicating the total length of the header area, | transport options by indicating the total length of the header area, | |||
such that the entire remaining area indicated in the network layer | such that the entire remaining area indicated in the network layer | |||
(IP) is transport payload. UDP-Lite already uses the UDP Length | (IP) is transport payload. UDP-Lite already uses the UDP Length | |||
field to indicate the boundary between data covered by the transport | field to indicate the boundary between data covered by the transport | |||
checksum and data not covered, and so there is no remaining area | checksum and data not covered, and so there is no remaining area | |||
where the length of the UDP-Lite payload as a whole can be indicated | where the length of the UDP-Lite payload as a whole can be indicated | |||
[RFC3828]. | [RFC3828]. | |||
UDP options are intended for modification only by the transport | UDP options are transport options. They are no more (or less) | |||
endpoints. They are no more (or less) appropriate to be modified in- | appropriate to be modified in-transit than any other portion of the | |||
transit than any other portion of the transport datagram. | transport datagram. | |||
>> UDP options are transport options. Generally, transport headers, | >> Generally, transport headers, options, and data are not intended | |||
options, and data are not intended to be modified in-transit. UDP | to be modified in-transit. UDP options are no exception and here are | |||
options are no exception and here are specified as "MUST NOT" be | specified as "MUST NOT" be altered in transit." | |||
altered in transit. | ||||
However, note that the UDP option mechanism provides no specific | However, note that the UDP option mechanism provides no specific | |||
protection against in-transit modification of the UDP header, UDP | protection against in-transit modification of the UDP header, UDP | |||
payload, or surplus area, except as provided by the OCS or the | payload, or surplus area, except as provided by the OCS or the | |||
options selected (e.g., AUTH or UENC). | options selected (e.g., AUTH or UENC). | |||
Unless protected by encryption (e.g., UENC or via other layers, | Unless protected by encryption (e.g., UENC or via other layers, | |||
e.g., IPsec), UDP options remain visible to devices on the network | e.g., IPsec), UDP options remain visible to devices on the network | |||
path. | path. | |||
skipping to change at page 43, line 22 ¶ | skipping to change at page 42, line 22 ¶ | |||
Note that any user application that considers UDP options to affect | Note that any user application that considers UDP options to affect | |||
security need not enable them. However, their use does not impact | security need not enable them. However, their use does not impact | |||
security in a way substantially different than TCP options; both | security in a way substantially different than TCP options; both | |||
enable the use of a control channel that has the potential for | enable the use of a control channel that has the potential for | |||
abuse. Similar to TCP, there are many options that, if unprotected, | abuse. Similar to TCP, there are many options that, if unprotected, | |||
could be used by an attacker to interfere with communication. | could be used by an attacker to interfere with communication. | |||
UDP options create new potential opportunities for DDOS attacks, | UDP options create new potential opportunities for DDOS attacks, | |||
notably through the use of fragmentation. When enabled, UDP options | notably through the use of fragmentation. When enabled, UDP options | |||
cause additional work at the receiver, however, of the "must- | cause additional work at the receiver, however, of the "must- | |||
support" options, only REQ (e.g., when used with DPLPMTUD [Fa23]) | support" options, only REQ (e.g., when used with DPLPMTUD [Fa24]) | |||
will cause the upper layer to initiate a UDP response in the absence | will cause the upper layer to initiate a UDP response in the absence | |||
of user transmission. | of user transmission. | |||
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 [RFC8446] (transport layer | security). Neither TLS [RFC8446] (transport layer | |||
security, for TCP) nor DTLS [RFC9147] (TLS for UDP) protect the | security, for TCP) nor DTLS [RFC9147] (TLS for UDP) protect the | |||
transport layer. Both operate as a shim layer solely on the user | transport layer; both operate as a shim layer solely on the user | |||
data of transport packets, protecting only their contents. Just as | data of transport packets, protecting only their contents. | |||
TLS does not protect the TCP header or its options, DTLS does not | ||||
protect the UDP header or the new options introduced by this | Just as TLS does not protect the TCP header or its options, DTLS | |||
document. Transport security is provided in TCP by the TCP | does not protect the UDP header or the new options introduced by | |||
this document. Transport security is provided in TCP by the TCP | ||||
Authentication Option (TCP-AO [RFC5925]) and (when defined) in UDP | Authentication Option (TCP-AO [RFC5925]) and (when defined) in UDP | |||
by the Authentication (AUTH) option (Section 11.9) and (when | by the Authentication (AUTH) option (Section 11.9) and (when | |||
defined) the UNSAFE Encryption (UENC) option (Section 12). Transport | defined) the UNSAFE Encryption (UENC) option (Section 12). Transport | |||
headers are also protected as payload when using IP security (IPsec) | headers are also protected as payload when using IP security (IPsec) | |||
[RFC4301]. | [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, as is the case for IPv6 [RFC8504]. | parsed in their entirety, as is the case for IPv6 [RFC8504]. | |||
skipping to change at page 45, line 42 ¶ | skipping to change at page 44, line 42 ¶ | |||
>> Implementations concerned with the potential use of UDP options | >> Implementations concerned with the potential use of UDP options | |||
as a covert channel MAY consider limiting use of some or all | as a covert channel MAY consider limiting use of some or all | |||
options. Such implementations SHOULD ensure FRAG, NOP, and EOL are | options. Such implementations SHOULD ensure FRAG, NOP, and EOL are | |||
not passed to the receiving user and SHOULD return options in an | not passed to the receiving user and SHOULD return options in an | |||
order not related to their sequence in the received packet. | order not related to their sequence in the received packet. | |||
25. IANA Considerations | 25. 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; | group for UDP Options, consisting of UDP Option Kind numbers and UDP | |||
this assumes the creation of a new UDP registry group in which UDP | Option Experimental IDs (ExIDs). | |||
Option Kinds would be the only entry. | ||||
Initial values of the UDP Option Kind registry are as listed in | Initial values of the UDP Option Kind registry are as listed in | |||
Section 10, including those both assigned and reserved. Additional | Section 10, including those both assigned and reserved. Additional | |||
values in this registry are to be assigned from the UNASSIGNED | values in this registry are to be assigned from the UNASSIGNED | |||
values in Section 10 by IESG Approval or Standards Action [RFC8126]. | values in Section 10 by IESG Approval or Standards Action [RFC8126]. | |||
Those assignments are subject to the conditions set forth in this | Those assignments are subject to the conditions set forth in this | |||
document, particularly (but not limited to) those in Section 13. The | document, particularly (but not limited to) those in Section 13. | |||
r | ||||
>> Although option nicknames are not used in-band, new UNSAFE option | >> Although option nicknames are not used in-band, new UNSAFE option | |||
names SHOULD commence with the capital letter "U" and avoid either | names SHOULD commence with the capital letter "U" and avoid either | |||
uppercase or lowercase "U" as commencing safe options. | uppercase or lowercase "U" as commencing safe options. | |||
Upon publication, IANA is hereby requested to create a new registry | UDP Experimental Option Experiment Identifiers (UDP ExIDs) are | |||
for UDP Experimental Option Experiment Identifiers (UDP ExIDs) for | intended for use in a similar manner as TCP ExIDs [RFC6994]. UDP | |||
use in a similar manner as TCP ExIDs [RFC6994]. UDP ExIDs can be | ExIDs can be used in either (or both) the UDP EXP (Section 11.10) or | |||
used in either (or both) the EXP or UEXP options. This registry is | UEXP (Section 12.3) options. UDP ExID entries consist of a 16-bit | |||
initially empty. Values in this registry are to be assigned by IANA | ExID (in network-standard order), and (as with the TCP ExID) will | |||
using first-come, first-served (FCFS) rules [RFC8126]. Options using | preferentially also include a short description and acronym for use | |||
these ExIDs are subject to the same conditions as new options, i.e., | in documentation. UDP ExIDs are always 16 bits because their use in | |||
they too are subject to the conditions set forth in this document, | EXP and UEXP options is required and thus do not need a larger | |||
particularly (but not limited to) those in Section 13. | number space to decrease the probability of accidental occurrence | |||
with non-ExID uses of the experimental options, as is the case with | ||||
TCP ExIDs. | ||||
Values in this registry are to be assigned by IANA using first-come, | ||||
first-served (FCFS) rules applied to both the ExID value and the | ||||
acronym [RFC8126]. Options using these ExIDs 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 | ||||
to) those in Section 13. | ||||
The UDP ExID registry is intended to align with the TCP ExID | ||||
registry, where all UDP ExIDs are also TCP ExIDs, and the first 16 | ||||
bits of all TCP ExIDs are also UDP ExIDs. Whether these are | ||||
represented as separate registries or as a single registry is at the | ||||
discretion of IANA. If as separate registries, this document | ||||
requests that each ExID request in either registry generates a | ||||
corresponding entry in the other registry. If as a single registry, | ||||
please include the direction that "16-bit ExIDs can be used with | ||||
either TCP or UDP; 32-bit ExIDs can be used with TCP or their first | ||||
16 bits can be used with UDP". | ||||
26. References | 26. References | |||
26.1. Normative References | 26.1. Normative References | |||
[Fa23] Fairhurst, G., T. Jones, "Datagram PLPMTUD for UDP | [Fa24] Fairhurst, G., T. Jones, "Datagram PLPMTUD for UDP | |||
Options," draft-ietf-tsvwg-udp-options-dplpmtud, Jun. | Options," draft-ietf-tsvwg-udp-options-dplpmtud, Jan. | |||
2023. | 2024. | |||
[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 | |||
skipping to change at page 49, line 28 ¶ | skipping to change at page 48, line 45 ¶ | |||
[CERT18] CERT Coordination Center, "TCP implementations vulnerable | [CERT18] CERT Coordination Center, "TCP implementations vulnerable | |||
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. | |||
[To24] Touch, J., "The UDP Authentication Option," draft-touch- | [To24] Touch, J., "The UDP Authentication Option," draft-touch- | |||
udp-auth-option, Jul. 2018. | tsvwg-udp-auth-opt, Mar. 2024. | |||
[Zu20] Zullo, R., T. Jones, and G. Fairhurst, "Overcoming the | [Zu20] Zullo, R., T. Jones, and G. Fairhurst, "Overcoming the | |||
Sorrows of the Young UDP Options," 2020 Network Traffic | Sorrows of the Young UDP Options," 2020 Network Traffic | |||
Measurement and Analysis Conference (TMA), IEEE, 2020. | Measurement and Analysis Conference (TMA), IEEE, 2020. | |||
27. Acknowledgments | 27. Acknowledgments | |||
This work benefitted from feedback from Erik Auerswald, Bob Briscoe, | This work benefitted from feedback from Erik Auerswald, Bob Briscoe, | |||
Ken Calvert, Ted Faber, Gorry Fairhurst (including OCS for errant | Ken Calvert, Ted Faber, Gorry Fairhurst (including OCS for errant | |||
middlebox traversal), C. M. Heard (including combining previous FRAG | middlebox traversal), C. M. Heard (including combining previous FRAG | |||
End of changes. 55 change blocks. | ||||
155 lines changed or deleted | 194 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |