idnits 2.17.1 draft-ietf-tsvwg-udp-options-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- == The document has an IETF Trust Provisions of 28 Dec 2009, Section 6.c(i) Publication Limitation clause. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1584 has weird spacing: '...default mean...' == Line 1612 has weird spacing: '...enabled net.i...' == Line 1613 has weird spacing: '...enabled net....' == Line 1623 has weird spacing: '...default mean...' == Line 1629 has weird spacing: '... params mean...' == (1 more instance...) -- The document date (May 2, 2021) is 1061 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2460' is mentioned on line 1300, but not defined ** Obsolete undefined reference: RFC 2460 (Obsoleted by RFC 8200) -- Duplicate reference: RFC2119, mentioned in 'RFC8174', was also mentioned in 'RFC2119'. -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2140 (Obsoleted by RFC 9040) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 6691 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TSVWG J. Touch 2 Internet Draft Independent consultant 3 Intended status: Standards Track May 2, 2021 4 Intended updates: 768 5 Expires: November 2021 7 Transport Options for UDP 8 draft-ietf-tsvwg-udp-options-12.txt 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may not be modified, 14 and derivative works of it may not be created, except to format it 15 for publication as an RFC or to translate it into languages other 16 than English. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on November 2, 2021. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. Code Components extracted from this 47 document must include Simplified BSD License text as described in 48 Section 4.e of the Trust Legal Provisions and are provided without 49 warranty as described in the Simplified BSD License. 51 Abstract 53 Transport protocols are extended through the use of transport header 54 options. This document extends UDP by indicating the location, 55 syntax, and semantics for UDP transport layer options. 57 Table of Contents 59 1. Introduction...................................................3 60 2. Conventions used in this document..............................3 61 3. Background.....................................................3 62 4. The UDP Option Area............................................4 63 5. UDP Options....................................................8 64 5.1. End of Options List (EOL).................................9 65 5.2. No Operation (NOP).......................................10 66 5.3. Option Checksum (OCS)....................................10 67 5.4. Alternate Checksum (ACS).................................12 68 5.5. Fragmentation (FRAG).....................................13 69 5.6. Maximum Segment Size (MSS)...............................16 70 5.7. Maximum Reassembled Segment Size (MRSS)..................17 71 5.8. Unsafe (UNSAFE)..........................................17 72 5.9. Timestamps (TIME)........................................18 73 5.10. Authentication and Encryption (AE)......................19 74 5.11. Echo request (REQ) and echo response (RES)..............21 75 5.12. Experimental (EXP)......................................21 76 6. Rules for designing new options...............................22 77 7. Option inclusion and processing...............................23 78 8. UDP API Extensions............................................24 79 9. Whose options are these?......................................25 80 10. UDP options FRAG option vs. UDP-Lite.........................26 81 11. Interactions with Legacy Devices.............................26 82 12. Options in a Stateless, Unreliable Transport Protocol........27 83 13. UDP Option State Caching.....................................28 84 14. Updates to RFC 768...........................................28 85 15. Interactions with other RFCs (and drafts)....................28 86 16. Multicast Considerations.....................................29 87 17. Security Considerations......................................30 88 18. IANA Considerations..........................................31 89 19. References...................................................31 90 19.1. Normative References....................................31 91 19.2. Informative References..................................32 93 20. Acknowledgments..............................................34 94 Appendix A. Implementation Information...........................35 96 1. Introduction 98 Transport protocols use options as a way to extend their 99 capabilities. TCP [RFC793], SCTP [RFC4960], and DCCP [RFC4340] 100 include space for these options but UDP [RFC768] currently does not. 101 This document defines an extension to UDP that provides space for 102 transport options including their generic syntax and semantics for 103 their use in UDP's stateless, unreliable message protocol. 105 2. Conventions used in this document 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in 110 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 111 capitals, as shown here. 113 In this document, the characters ">>" preceding an indented line(s) 114 indicates a statement using the key words listed above. This 115 convention aids reviewers in quickly identifying or finding the 116 portions of this RFC covered by these key words. 118 3. Background 120 Many protocols include a default, invariant header and an area for 121 header options that varies from packet to packet. These options 122 enable the protocol to be extended for use in particular 123 environments or in ways unforeseen by the original designers. 124 Examples include TCP's Maximum Segment Size, Window Scale, 125 Timestamp, and Authentication Options [RFC793][RFC5925][RFC7323]. 127 These options are used both in stateful (connection-oriented, e.g., 128 TCP [RFC793], SCTP [RFC4960], DCCP [RFC4340]) and stateless 129 (connectionless, e.g., IPv4 [RFC791], IPv6 [RFC8200]) protocols. In 130 stateful protocols they can help extend the way in which state is 131 managed. In stateless protocols their effect is often limited to 132 individual packets, but they can have an aggregate effect on a 133 sequence of packets as well. This document is intended to provide an 134 out-of-band option area as an alternative to the in-band mechanism 135 currently proposed [Hi15]. 137 UDP is one of the most popular protocols that lacks space for 138 options [RFC768]. The UDP header was intended to be a minimal 139 addition to IP, providing only ports and a data checksum for 140 protection. This document extends UDP to provide a trailer area for 141 options located after the UDP data payload. 143 This extension is possible because UDP includes its own length 144 field, separate from that of the IP header. SCTP includes its own 145 length field, one for each chunk. TCP and DCCP lack this transport 146 length field, inferring it from the IP length. There are a number of 147 suggested reasons why UDP includes this field, notably to support 148 multiple UDP segments in the same IP packet or to indicate the 149 length of the UDP payload as distinct from zero padding required for 150 systems that require writes that are not byte-alighed. These 151 suggestions are not consistent with earlier versions of UDP or with 152 concurrent design of multi-segment multiplexing protocols, however. 154 4. The UDP Option Area 156 The UDP transport header includes demultiplexing and service 157 identification (port numbers), a checksum, and a field that 158 indicates the UDP datagram length (including UDP header). The UDP 159 Length field is typically redundant with the size of the maximum 160 space available as a transport protocol payload (see also discussion 161 in Section 11). 163 For IPv4, IP Total Length field indicates the total IP datagram 164 length (including IP header), and the size of the IP options is 165 indicated in the IP header (in 4-byte words) as the "Internet Header 166 Length" (IHL), as shown in Figure 1 [RFC791]. As a result, the 167 typical (and largest valid) value for UDP Length is: 169 UDP_Length = IPv4_Total_Length - IPv4_IHL * 4 171 For IPv6, the IP Payload Length field indicates the datagram after 172 the base IPv6 header, which includes the IPv6 extension headers and 173 space available for the transport protocol, as shown in Figure 2 174 [RFC8200]. Note that the Next HDR field in IPv6 might not indicate 175 UDP (i.e., 17), e.g., when intervening IP extension headers are 176 present. For IPv6, the lengths of any additional IP extensions are 177 indicated within each extension [RFC8200], so the typical (and 178 largest valid) value for UDP Length is: 180 UDP_Length = IPv6_Payload_Length - sum(extension header lengths) 182 In both cases, the space available for the UDP transport protocol 183 data unit is indicated by IP, either completely in the base header 184 (for IPv4) or adding information in the extensions (for IPv6). In 185 either case, this document will refer to this available space as the 186 "IP transport payload". 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 |Version| IHL |Type of Service| Total Length | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Identification |Flags| Fragment Offset | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Time to Live | Proto=17 (UDP)| Header Checksum | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Source Address | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Destination Address | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 ... zero or more IP Options (using space as indicated by IHL) ... 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | UDP Source Port | UDP Destination Port | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | UDP Length | UDP Checksum | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Figure 1 IPv4 datagram with UDP transport payload 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 |Version| Traffic Class | Flow Label | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Payload Length | Next Hdr | Hop Limit | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 ... 214 | Source Address (128 bits) | 215 ... 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 ... 218 | Destination Address (128 bits) | 219 ... 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 ... zero or more IP Extension headers (each indicating size) ... 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | UDP Source Port | UDP Destination Port | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | UDP Length | UDP Checksum | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 Figure 2 IPv6 datagram with UDP transport payload 230 As a result of this redundancy, there is an opportunity to use the 231 UDP Length field as a way to break up the IP transport payload into 232 two areas - that intended as UDP user data and an additional 233 "surplus area" (as shown in Figure 3). 235 IP transport payload 236 <-------------------------------------------------> 237 +--------+---------+----------------------+------------------+ 238 | IP Hdr | UDP Hdr | UDP user data | surplus area | 239 +--------+---------+----------------------+------------------+ 240 <------------------------------> 241 UDP Length 243 Figure 3 IP transport payload vs. UDP Length 245 In most cases, the IP transport payload and UDP Length point to the 246 same location, indicating that there is no surplus area. It is 247 important to note that this is not a requirement of UDP [RFC768] 248 (discussed further in Section 11). UDP-Lite used the difference in 249 these pointers to indicate the partial coverage of the UDP Checksum, 250 such that the UDP user data, UDP header, and UDP pseudoheader (a 251 subset of the IP header) are covered by the UDP checksum but 252 additional user data in the surplus area is not covered [RFC3828]. 253 This document uses the surplus area for UDP transport options. 255 The UDP option area is thus defined as the location between the end 256 of the UDP payload and the end of the IP datagram as a trailing 257 options area. This area can occur at any valid byte offset, i.e., it 258 need not be 16-bit or 32-bit aligned. In effect, this document 259 redefines the UDP "Length" field as a "trailer offset". 261 UDP options are defined using a TLV (type, length, and optional 262 value) syntax similar to that of TCP [RFC793]. They are typically a 263 minimum of two bytes in length as shown in Figure 4, excepting only 264 the one byte options "No Operation" (NOP) and "End of Options List" 265 (EOL) described below. 267 +--------+--------+------- 268 | Kind | Length | (remainder of option...) 269 +--------+--------+------- 271 Figure 4 UDP option default format 273 The Kind field is always one byte. The Length field is one byte for 274 all lengths below 255 (including the Kind and Length bytes). A 275 Length of 255 indicates use of the UDP option extended format shown 276 in Figure 5. The Extended Length field is a 16-bit field in network 277 standard byte order. 279 +--------+--------+--------+--------+ 280 | Kind | 255 | Extended Length | 281 +--------+--------+--------+--------+ 282 | (remainder of option...) 283 +--------+--------+--------+--------+ 285 Figure 5 UDP option extended default format 287 >> UDP options MAY begin at any UDP length offset. 289 >> The UDP length MUST be at least as large as the UDP header (8) 290 and no larger than the IP transport payload. Datagrams with length 291 values outside this range MUST be silently dropped as invalid and 292 logged where rate-limiting permits. 294 >> Option Lengths (or Extended Lengths, where applicable) smaller 295 than the minimum for the corresponding Kind and default format MUST 296 be treated as an error. Such errors call into question the remainder 297 of the option area and thus MUST result in all UDP options being 298 silently discarded. 300 >> Any UDP option whose length is only smaller than 255 MUST always 301 use the UDP option default format shown in Figure 4, excepting only 302 EOL and NOP. 304 >> Any UDP option whose length can be larger than 254 MUST always 305 use the UDP option extended default format shown in Figure 5, 306 including UNSAFE and EXP. 308 I.e., a UDP option always uses only the default format or the 309 extended default format, depending on whether its length is only 310 ever smaller than 255 or not. 312 Others have considered using values of the UDP Length that is larger 313 than the IP transport payload as an additional type of signal. Using 314 a value smaller than the IP transport payload is expected to be 315 backward compatible with existing UDP implementations, i.e., to 316 deliver the UDP Length of user data to the application and silently 317 ignore the additional surplus area data. Using a value larger than 318 the IP transport payload would either be considered malformed (and 319 be silently dropped) or could cause buffer overruns, and so is not 320 considered silently and safely backward compatible. Its use is thus 321 out of scope for the extension described in this document. 323 >> UDP options MUST be interpreted in the order in which they occur 324 in the UDP option area. 326 5. UDP Options 328 The following UDP options are currently defined: 330 Kind Length Meaning 331 ---------------------------------------------- 332 0* - End of Options List (EOL) 333 1* - No operation (NOP) 334 2* 3 Option checksum (OCS) 335 3* 6 Alternate checksum (ACS) 336 4* 10/12 Fragmentation (FRAG) 337 5* 4 Maximum segment size (MSS) 338 6* 4 Maximum reassembled segment size (MRSS) 339 7* (varies) Unsafe to ignore (UNSAFE) options 340 8 10 Timestamps (TIME) 341 9 (varies) Authentication and Encryption (AE) 342 10 6 Request (REQ) 343 11 6 Response (RES) 344 12-126 (varies) UNASSIGNED (assignable by IANA) 345 127-253 RESERVED 346 254 (varies) RFC 3692-style experiments (EXP) 347 255 RESERVED 349 These options are defined in the following subsections. Options 0 350 and 1 use the same values as for TCP. 352 >> An endpoint supporting UDP options MUST support those marked with 353 a "*" above: EOL, NOP, OCS, ACS, FRAG, MSS, MRSS, and UNSAFE. This 354 includes both recognizing and being able to generate these options 355 if configured to do so. These are called "must-support" options. 357 >> All other options (without a "*") MAY be implemented, and their 358 use SHOULD be determined either out-of-band or negotiated. 360 >> Receivers supporting UDP options MUST silently ignore unknown 361 options except UNSAFE. That includes options whose length does not 362 indicate the specified value(s). 364 >> Receivers supporting UDP options MUST silently drop the entire 365 datagram containing an UNSAFE option when any UNSAFE option it 366 contains is unknown. See Section 5.8 for further discussion of 367 UNSAFE options. 369 >> Except for NOP, each option SHOULD NOT occur more than once in a 370 single UDP datagram. If an option other than NOP occurs more than 371 once, a receiver MUST interpret only the first instance of that 372 option and MUST ignore all others. 374 >> Only the OCS and AE options depend on the contents of the option 375 area. AE is always computed as if the AE hash and OCS checksum are 376 zero; OCS is always computed as if the OCS checksum is zero and 377 after the AE hash has been computed. Future options MUST NOT be 378 defined as having a value dependent on the contents of the option 379 area. Otherwise, interactions between those values, OCS, and AE 380 could be unpredictable. 382 Receivers cannot treat unexpected option lengths as invalid, as this 383 would unnecessarily limit future revision of options (e.g., defining 384 a new ACS that is defined by having a different length). 386 >> Option lengths MUST NOT exceed the IP length of the packet. If 387 this occurs, the packet MUST be treated as malformed and dropped, 388 and the event MAY be logged for diagnostics (logging SHOULD be rate 389 limited). 391 >> Options with fixed lengths MUST use the default option format. 393 >> Options with variable lengths MUST use the default option format 394 where their total length is 254 bytes or less. 396 >> Options using the extended option format MUST indicate extended 397 lengths of 255 or higher; smaller extended length values MUST be 398 treated as an error. 400 >> "Must-support" options other than NOP and EOL MUST come before 401 other options. 403 The requirement that must-support options come before others is 404 intended to allow for endpoints to implement DOS protection, as 405 discussed further in Section 17. 407 5.1. End of Options List (EOL) 409 The End of Options List (EOL) option indicates that there are no 410 more options. It is used to indicate the end of the list of options 411 without needing to pad the options to fill all available option 412 space. 414 +--------+ 415 | Kind=0 | 416 +--------+ 418 Figure 6 UDP EOL option format 420 >> When the UDP options do not consume the entire option area, the 421 last non-NOP option MUST be EOL. 423 >> All bytes in the surplus area after EOL MUST be zero. If these 424 bytes are non-zero, the entire surplus area MUST be silently ignored 425 and only the UDP data passed to the user with an adjusted UDP length 426 to indicate that no options were present. 428 Requiring the post-option surplus area to be zero prevents side- 429 channel uses of this area, requiring instead that all use of the 430 surplus area be UDP options supported by both endpoints. It is 431 useful to allow for such padding to increase the packet length 432 without affecting the payload length, e.g., for UDP DPLPMTUD [Fa21]. 434 5.2. No Operation (NOP) 436 The No Operation (NOP) option is a one byte placeholder, intended to 437 be used as padding, e.g., to align multi-byte options along 16-bit 438 or 32-bit boundaries. 440 +--------+ 441 | Kind=1 | 442 +--------+ 444 Figure 7 UDP NOP option format 446 >> If options longer than one byte are used, NOP options SHOULD be 447 used at the beginning of the UDP options area to achieve alignment 448 as would be more efficient for active (i.e., non-NOP) options. 450 >> Segments SHOULD NOT use more than three consecutive NOPs. NOPs 451 are intended to assist with alignment, not other padding or fill. 453 This issue is discussed further in Section 17. 455 5.3. Option Checksum (OCS) 457 The Option Checksum (OCS) option is conventional Internet checksum 458 [RFC791] that covers all of the surplus area and a pseudoheader 459 composed of the 16-bit length of the surplus area (Figure 8). The 460 primary purpose of OCS is to detect non-standard (i.e., non-option) 461 uses of that area. The surplus area pseudoheader is included to 462 enable traversal of errant middleboxes that incorrectly compute the 463 UDP checksum over the entire IP payload rather than only the UDP 464 payload [Fa18]. 466 The OCS is calculated by computing the Internet checksum over the 467 surplus area and surplus length pseudoheader. The OCS protects the 468 option area from errors in a similar way that the UDP checksum 469 protects the UDP user data (when not zero). 471 +--------+--------+ 472 | surplus length | 473 +--------+--------+ 475 Figure 8 UDP surplus length pseudoheader 477 +--------+--------+--------+ 478 | Kind=2 | checksum | 479 +--------+--------+--------+ 481 Figure 9 UDP OCS option format 483 >> The OCS MUST be included when the UDP checksum is nonzero and UDP 484 options are present. 486 >> When present, the OCS SHOULD occur as early as possible, preceded 487 by only NOP options for alignment and the FRAG option if present. 489 >> OCS MUST be half-word coordinated with the start of the UDP 490 options area and include the surplus length pseudoheader similarly 491 coordinated with the start of UDP Header. 493 This Internet checksum is computed over the surplus area (including 494 EOL, if present) prefixed by the surplus length pseudoheader (Figure 495 8) and then adjusting the result before storing it into the OCS 496 checksum field. If the OCS checksum field is aligned to the start of 497 the options area, then the checksum is inserted as-is, otherwise the 498 checksum bytes are swapped before inserting them into the field. The 499 effect of this "coordination" is the same is if the checksum were 500 computed as if the surplus area and pseudoheader were aligned to the 501 UDP header. 503 This feature is intended to potentially help the UDP options 504 traverse devices that incorrectly attempt to checksum the surplus 505 area (as originally proposed as the Checksum Compensation Option, 506 i.e., CCO [Fa18]). 508 The OCS covers the UDP option area as formatted for transmission and 509 immediately upon reception. 511 >> If the OCS fails, all options MUST be ignored and the surplus 512 area silently discarded. 514 >> UDP data that is validated by a correct UDP checksum MUST be 515 delivered to the application layer, even if the OCS fails, unless 516 the endpoints have negotiated otherwise for this segment's socket 517 pair. 519 As a reminder, use of the UDP checksum is optional when the UDP 520 checksum is zero. When not used, the OCS is assumed to be "correct" 521 for the purpose of accepting UDP packets at a receiver (see Section 522 7). 524 The OCS is intended to check for accidental errors, not for attacks. 526 5.4. Alternate Checksum (ACS) 528 The Alternate Checksum (ACS) option provides a stronger alternative 529 to the checksum in the UDP header, using a 32-bit CRC of the 530 conventional UDP payload only (excluding the IP pseudoheader, UDP 531 header, and surplus area). It is an "alternate" to the UDP checksum 532 (covering the UDP payload) - not the OCS (the latter covers the 533 surplus area) Unlike the UDP checksum, ACS does not include the IP 534 pseudoheader or UDP header, thus it does not need to be updated by 535 NATs when IP addresses or UDP ports are rewritten. Its purpose is to 536 detect UDP payload errors that the UDP checksum, when used, might 537 not detect. 539 A CRC32c has been chosen because of its ubiquity and use in other 540 Internet protocols, including iSCSI and SCTP. The option contains 541 the CRC32c in network standard byte order, as described in 542 [RFC3385]. 544 +--------+--------+--------+--------+ 545 | Kind=3 | Len=6 | CRC32c... | 546 +--------+--------+--------+--------+ 547 | CRC32c (cont.) | 548 +--------+--------+ 550 Figure 10 UDP ACS option format 552 When present, the ACS always contains a valid CRC checksum. There 553 are no reserved values, including the value of zero. If the CRC is 554 zero, this must indicate a valid checksum (i.e., it does not 555 indicate that the ACS is not used; instead, the option would simply 556 not be included if that were the desired effect). 558 ACS does not protect the UDP pseudoheader; only the current UDP 559 checksum provides that protection (when used). ACS cannot provide 560 that protection because it would need to be updated whenever the UDP 561 pseudoheader changed, e.g., during NAT address and port translation; 562 because this is not the case, ACS does not cover the pseudoheader. 564 >> Packets with incorrect ACS checksums MUST be passed to the 565 application by default, e.g., with a flag indicating ACS failure. 567 Like all non-UNSAFE UDP options, ACS need to be silently ignored 568 when failing. Although all UDP option-aware endpoints support ACS 569 (being in the required set), this silently-ignored behavior ensures 570 that option-aware receivers operate the same as legacy receivers 571 unless overridden. 573 5.5. Fragmentation (FRAG) 575 The Fragmentation option (FRAG) combines properties of IP 576 fragmentation and the UDP Lite transport protocol [RFC3828]. FRAG 577 provides transport-layer fragmentation and reassembly in which each 578 fragment includes a copy of the same UDP transport ports, enabling 579 the fragments to traverse Network Address (and port) Translation 580 (NAT) devices, in contrast to the behavior of IP fragments. FRAG 581 also allows the UDP checksum to cover only a prefix of the UDP data 582 payload, to avoid repeated checksums of data prior to reassembly. 584 The Fragmentation (FRAG) option supports UDP fragmentation and 585 reassembly, which can be used to transfer UDP messages larger than 586 limited by the IP receive MTU (EMTU_R [RFC1122]). It is typically 587 used with the UDP MSS option to enable more efficient use of large 588 messages, both at the UDP and IP layers. FRAG is designed similar to 589 the IPv6 Fragmentation Header [RFC8200], except that the UDP variant 590 uses a 16-bit Offset measured in bytes, rather than IPv6's 13-bit 591 Fragment Offset measured in 8-byte units. This UDP variant avoids 592 creating reserved fields. 594 >> When FRAG is present, it MUST come first in the UDP options list. 596 >> When FRAG is present, the UDP payload MUST be empty. If the 597 payload is not empty, all UDP options MUST be silently ignored and 598 the payload received to the user. 600 Legacy receivers interpret FRAG messages as zero-length payload 601 packets (i.e., UDP Length field is 8, the length of just the UDP 602 header), which would not affect the receiver unless the presence of 603 the packet itself were a signal. 605 The FRAG option has two formats; non-terminal fragments use the 606 shorter variant (Figure 11) and terminal fragments use the longer 607 (Figure 12). The latter includes stand-alone fragments, i.e., when 608 data is contained in the FRAG option but reassembly is not required. 610 +--------+--------+--------+--------+ 611 | Kind=4 | Len=10 | Offset | 612 +--------+--------+--------+--------+ 613 | Identification | 614 +--------+--------+--------+--------+ 615 | Frag. Offset | 616 +--------+--------+ 618 Figure 11 UDP non-terminal FRAG option format 620 The FRAG option does not need a "more fragments" bit because it 621 provides the same indication by using the longer, 12-byte variant, 622 which also includes an Internet checksum over the entire reassembled 623 UDP payload (omitting the IP pseudoheader and UDP header, as well as 624 UDP options), as shown in Figure 12. 626 >> The FRAG option MAY be used on a single fragment, in which case 627 the Offset would be zero and the option would have the 12-byte 628 format, including the reassembly checksum. 630 Use of the single fragment variant can be helpful in supporting use 631 of UNSAFE options without undesirable impact to receivers that do 632 not support either UDP options or the specific UNSAFE options. 634 >> The reassembly checksum SHOULD be used, but MAY be unused in the 635 same situations when the UDP checksum is unused (e.g., for transit 636 tunnels or applications that have their own integrity checks 637 [RFC8200]), and by the same mechanism (set the field to 0x0000). 639 +--------+--------+--------+--------+ 640 | Kind=4 | Len=12 | Offset | 641 +--------+--------+--------+--------+ 642 | Identification | 643 +--------+--------+--------+--------+ 644 | Frag. Offset | Reassy. Checksum| 645 +--------+--------+--------+--------+ 647 Figure 12 UDP terminal FRAG option format 649 >> During fragmentation, the UDP header checksum of each fragment 650 needs to be recomputed based on each datagram's pseudoheader. 652 Unlike the UDP checksum, the reassembly checksum does not need to be 653 updated if the UDP header changes because it covers only the 654 reassembled data. FRAG uses a comparatively weak checksum upon 655 reassembly because the fragments are already checked individually. 657 >> After reassembly is complete and validated using the checksum of 658 the terminal FRAG option, the UDP header checksum of the resulting 659 datagram needs to be recomputed based on the datagram's 660 pseudoheader. 662 The Fragment Offset is 16 bits and indicates the location of the UDP 663 payload fragment in bytes from the beginning of the original 664 unfragmented payload. The Len field indicates whether there are more 665 fragments (Len=10) or no more fragments (Len=12). 667 >> The Identification field is a 32-bit value that MUST be unique 668 over the expected fragment reassembly timeout. 670 >> The Identification field SHOULD be generated in a manner similar 671 to that of the IPv6 Fragment ID [RFC8200]. 673 >> UDP fragments MUST NOT overlap. 675 UDP fragmentation relies on a fragment expiration timer, which can 676 be preset or could use a value computed using the UDP Timestamp 677 option. 679 >> The default UDP reassembly SHOULD be no more than 2 minutes. 681 Implementers are advised to limit the space available for UDP 682 reassembly. 684 >> UDP reassembly space SHOULD be limited to reduce the impact of 685 DOS attacks on resource use. 687 >> UDP reassembly space limits SHOULD NOT be implemented as an 688 aggregate, to avoid cross-socketpair DOS attacks. 690 >> Individual UDP fragments MUST NOT be forwarded to the user. The 691 reassembled datagram is received only after complete reassembly, 692 checksum validation, and continued processing of the remaining UDP 693 options. 695 Any additional UDP options, if used, follow the FRAG option in the 696 final fragment and would be included in the reassembled packet. 697 Processing of those options would commence after reassembly. This is 698 especially important for UNSAFE options, which are interpreted only 699 after FRAG. 701 >> UDP options MUST NOT follow the FRAG header in non-terminal 702 fragments. Any data following the FRAG header in non-terminal 703 fragments MUST be silently dropped. All other options that apply to 704 a reassembled packet MUST follow the FRAG header in the terminal 705 fragment. 707 In general, UDP packets are fragmented as follows: 709 1. Create a datagram with data and any non-FRAG UDP options, which 710 we will call "D". Note that the options apply to the entire data 711 area and must follow the data. These options are processed before 712 the rest of the fragmentation steps below. 714 2. Identify the desired fragment size, which we will call "S". This 715 value should take into account the path MTU (if known) and allow 716 space for per-fragment options (e.g., OCS). 718 3. Fragment "D" into chunks of size no larger than "S"-10 each, with 719 one final chunk no larger than "S"-12. Note that all the non-FRAG 720 options in step #1 MUST appear in the terminal fragment. 722 4. For each chunk of "D" in step #3, create a zero-data UDP packet 723 followed by the per-fragment options, with the final option being 724 the FRAG option followed by the FRAG data chunk. 726 The last chunk includes the non-FRAG options noted in step #1 727 after the end of the FRAG data. These UDP options apply to the 728 reassembled data as a whole when received. 730 5. Process the UDP options of each fragment, e.g., computing its 731 OCS. 733 Receivers reverse the above sequence. They process all received 734 options in each fragment. When the FRAG option is encountered, the 735 FRAG data is used in reassembly. After all fragments are received, 736 the entire packet is processed with any trailing UDP options 737 applying to the reassembled data. 739 5.6. Maximum Segment Size (MSS) 741 The Maximum Segment Size (MSS, Kind = 5) option is a 16-bit hint of 742 the largest unfragmented UDP segment that an endpoint believes can 743 be received. As with the TCP MSS option [RFC793], the size indicated 744 is the IP layer MTU decreased by the fixed IP and UDP headers only 746 [RFC6691]. The space needed for IP and UDP options need to be 747 adjusted by the sender when using the value indicated. The value 748 transmitted is based on EMTU_R, the largest IP datagram that can be 749 received (i.e., reassembled at the receiver) [RFC1122]. However, as 750 with TCP, this value is only a hint at what the receiver believes; 751 it does not indicate a known path MTU and thus MUST NOT be used to 752 limit transmissions, notably for DPLPMTU probes. 754 +--------+--------+--------+--------+ 755 | Kind=5 | Len=4 | MSS size | 756 +--------+--------+--------+--------+ 758 Figure 13 UDP MSS option format 760 The UDP MSS option MAY be used as a hint for path MTU discovery 761 [RFC1191][RFC8201], but this may be difficult because of known 762 issues with ICMP blocking [RFC2923] as well as UDP lacking automatic 763 retransmission. It is more likely to be useful when coupled with IP 764 source fragmentation to limit the largest reassembled UDP message as 765 indicated by MRSS (see Section 5.7), e.g., when EMTU_R is larger 766 than the required minimums (576 for IPv4 [RFC791] and 1500 for IPv6 767 [RFC8200]). It can also be used with DPLPMTUD [RFC8899] to provide a 768 hint to maximum DPLPMTU, though it MUST NOT prohibit transmission of 769 larger UDP packets (or fragments) used as DPLPMTU probes. 771 5.7. Maximum Reassembled Segment Size (MRSS) 773 The Maximum Reassembled Segment Size (MRSS, Kind=6) option is a 16- 774 bit indicator of the largest reassembled UDP segment that can be 775 received. MRSS is the UDP equivalent of IP's EMTU_R but the two are 776 not related [RFC1122]. Using the FRAG option (Section 5.5), UDP 777 segments can be transmitted as fragments in multiple IP datagrams 778 and be reassembled larger than the IP layer allows. 780 +--------+--------+--------+--------+ 781 | Kind=6 | Len=4 | MRSS size | 782 +--------+--------+--------+--------+ 784 Figure 14 UDP MRSS option format 786 5.8. Unsafe (UNSAFE) 788 The Unsafe option (UNSAFE) extends the UDP option space to allow for 789 options that are not safe to ignore and can be used unidirectionally 790 or without soft-state confirmation of UDP option capability. They 791 are always used only when the entire UDP payload occurs inside a 792 reassembled set of UDP fragments, such that if UDP fragmentation is 793 not supported, the entire fragment would be silently dropped anyway. 795 UNSAFE options are an extended option space, with its own additional 796 option types. These are indicated in the first byte after the option 797 Kind as shown in Figure 15, which is followed by the Length. Length 798 is 1 byte for UKinds whose total length (including Kind, UKind, and 799 Length fields) is less than 255 or 2 bytes for larger lengths (in 800 the similar style as the extended option format). 802 +--------+--------+--------+ 803 | Kind=7 | UKind | Length |... 804 +--------+--------+--------+ 805 1 byte 1 byte 1-2 bytes 807 Figure 15 UDP UNSAFE option format 809 >> UNSAFE options MUST be used only as part of UDP fragments, used 810 either per-fragment or after reassembly. 812 >> Receivers supporting UDP options MUST silently drop the entire 813 reassembled datagram if any fragment or the entire datagram includes 814 an UNSAFE option whose UKind is not supported. 816 The following UKind values are defined: 818 UKind Length Meaning 819 ---------------------------------------------- 820 0 RESERVED 821 1-253 (varies) UNASSIGNED (assignable by IANA) 822 254 (varies) RFC 3692-style experiments (UEXP) 823 255 RESERVED 825 Experimental UKind EXP ExID values indicate the ExID in the 826 following 2 (or 4) bytes, similar to the UDP EXP option as discussed 827 in Section 5.12. Assigned UDP EXP ExIDs and UDP UNSAFE UKind UEXP 828 ExIDs are assigned from the same registry and can be used either in 829 the EXP option (Section 5.12) or within the UKind UEXP. 831 5.9. Timestamps (TIME) 833 The Timestamp (TIME) option exchanges two four-byte timestamp 834 fields. It serves a similar purpose to TCP's TS option [RFC7323], 835 enabling UDP to estimate the round trip time (RTT) between hosts. 836 For UDP, this RTT can be useful for establishing UDP fragment 837 reassembly timeouts or transport-layer rate-limiting [RFC8085]. 839 +--------+--------+------------------+------------------+ 840 | Kind=8 | Len=10 | TSval | TSecr | 841 +--------+--------+------------------+------------------+ 842 1 byte 1 byte 4 bytes 4 bytes 844 Figure 16 UDP TIME option format 846 TS Value (TSval) and TS Echo Reply (TSecr) are used in a similar 847 manner to the TCP TS option [RFC7323]. On transmitted segments using 848 the option, TS Value is always set based on the local "time" value. 849 Received TSval and TSecr values are provided to the application, 850 which can pass the TSval value to be used as TSecr on UDP messages 851 sent in response (i.e., to echo the received TSval). A received 852 TSecr of zero indicates that the TSval was not echoed by the 853 transmitter, i.e., from a previously received UDP packet. 855 >> TIME MAY use an RTT estimate based on nonzero Timestamp values as 856 a hint for fragmentation reassembly, rate limiting, or other 857 mechanisms that benefit from such an estimate. 859 >> TIME SHOULD make this RTT estimate available to the user 860 application. 862 UDP timestamps are modeled after TCP timestamps and have similar 863 expectations. In particular, they are expected to be: 865 o Values are monotonic and non-decreasing except for anticipated 866 number-space rollover events 868 o Values should "increase" (allowing for rollover) according to a 869 typical 'tick' time 871 o A request is defined as "reply=0" and a reply is defined as both 872 fields being non-zero. 874 o A receiver should always respond to a request with the highest 875 TSval received (allowing for rollover), which is not necessarily 876 the most recently received. 878 Rollover can be handled as a special case or more completely using 879 sequence number extension [RFC5925]. 881 5.10. Authentication and Encryption (AE) 883 The Authentication and Encryption (AE) option is intended to allow 884 UDP to provide a similar type of authentication as the TCP 885 Authentication Option (TCP-AO) [RFC5925]. AE the conventional UDP 886 payload and may also cover the surplus area, depending on 887 configuration. It uses the same format as specified for TCP-AO, 888 except that it uses a Kind of 9. AE supports NAT traversal in a 889 similar manner as TCP-AO [RFC6978]. AE can also be extended to 890 provide a similar encryption capability as TCP-AO-ENC, in a similar 891 manner [To18ao]. 893 +--------+--------+--------+--------+ 894 | Kind=9 | Len | Digest... | 895 +--------+--------+--------+--------+ 896 | Digest (con't)... | 897 +--------+--------+--------+--------+ 899 Figure 17 UDP AE option format 901 Like TCP-AO, AE is not negotiated in-band. Its use assumes both 902 endpoints have populated Master Key Tuples (MKTs), used to exclude 903 non-protected traffic. 905 TCP-AO generates unique traffic keys from a hash of TCP connection 906 parameters. UDP lacks a three-way handshake to coordinate 907 connection-specific values, such as TCP's Initial Sequence Numbers 908 (ISNs) [RFC793], thus AE's Key Derivation Function (KDF) uses zeroes 909 as the value for both ISNs. This means that the AE reuses keys when 910 socket pairs are reused, unlike TCP-AO. 912 >> Packets with incorrect AE HMACs MUST be passed to the application 913 by default, e.g., with a flag indicating AE failure. 915 Like all non-UNSAFE UDP options, AE needs to be silently ignored 916 when failing. This silently-ignored behavior ensures that option- 917 aware receivers operate the same as legacy receivers unless 918 overridden. 920 In addition to the UDP payload (which is always included), AE can be 921 configured to either include or exclude the surplus area, in a 922 similar way as can TCP-AO can optionally exclude TCP options. When 923 UDP options are covered, the OCS option area checksum and AE hash 924 areas are zeroed before computing the AE hash. It is important to 925 consider that options not yet defined might yield unpredictable 926 results if not confirmed as supported, e.g., if they were to contain 927 other hashes or checksums that depend on the option area contents. 928 This is why such dependencies are not permitted except as defined 929 for OCS and UDP-AE. 931 Similar to TCP-AO-NAT, AE can be configured to support NAT 932 traversal, excluding (by zeroing out) one or both of the UDP ports 933 and corresponding IP addresses [RFC6978]. 935 5.11. Echo request (REQ) and echo response (RES) 937 The echo request (REQ, kind=10) and echo response (RES, kind=11) 938 options provide a means for UDP options to be used to provide 939 packet-level acknowledgements. One such use is described as part of 940 the UDP variant of packetization layer path MTU discovery (PLPMTUD) 941 [Fa21]. The options both have the format indicated in Figure 18. 943 +--------+--------+------------------+ 944 | Kind | Len=6 | nonce | 945 +--------+--------+------------------+ 946 1 byte 1 byte 4 bytes 948 Figure 18 UDP REQ and RES options format 950 5.12. Experimental (EXP) 952 The Experimental option (EXP) is reserved for experiments [RFC3692]. 953 It uses a Kind value of 254. Only one such value is reserved because 954 experiments are expected to use an Experimental ID (ExIDs) to 955 differentiate concurrent use for different purposes, using UDP ExIDs 956 registered with IANA according to the approach developed for TCP 957 experimental options [RFC6994]. 959 +----------+----------+----------+----------+ 960 | Kind=254 | Len | UDP ExID | 961 +----------+----------+----------+----------+ 962 | (option contents, as defined)... | 963 +----------+----------+----------+----------+ 965 Figure 19 UDP EXP option format 967 >> The length of the experimental option MUST be at least 4 to 968 account for the Kind, Length, and the minimum 16-bit UDP ExID 969 identifier (similar to TCP ExIDs [RFC6994]). 971 Assigned UDP EXP ExIDs and UDP UNSAFE UKind UEXP ExIDs are assigned 972 from the same registry and can be used either in the EXP option or 973 within the UKind UEXP (Section 5.8). 975 6. Rules for designing new options 977 The UDP option Kind space allows for the definition of new options, 978 however the currently defined options do not allow for arbitrary new 979 options. For example, FRAG needs to come first if present; new 980 options cannot declare that they need to precede it. The following 981 is a summary of rules for new options and their rationales: 983 >> New options MUST NOT depend on option space content, excepting 984 only those contained within the UNSAFE option. Only OCS and AE 985 depend on the content of the options themselves and their order is 986 fixed (on transmission, AE is computed first using a zero-checksum 987 OCS if present, and OCS is computed last before transmission, over 988 the entire option area, including AE). 990 >> UNSAFE options can both depend on and vary option space content 991 because they are contained only inside UDP fragments and thus are 992 processed only by UDP option capable receivers. 994 >> New options MUST NOT declare their order relative to other 995 options, whether new or old. 997 >> At the sender, new options MUST NOT modify UDP packet content 998 anywhere except within their option field, excepting only those 999 contained within the UNSAFE option; areas that need to remain 1000 unmodified include the IP header, IP options, the UDP body, the UDP 1001 option area (i.e., other options), and the post-option area. 1003 >> Options MUST NOT be modified in transit. This includes those 1004 already defined as well as new options. New options MUST NOT require 1005 or intend optionally for modification of any UDP options, including 1006 their new areas, in transit. 1008 >> New options with fixed lengths smaller than 255 or variable 1009 lengths that are always smaller than 255 MUST use only the default 1010 option format. 1012 Note that only certain of the initially defined options violate 1013 these rules: 1015 o >> FRAG MUST be first, if present, and MUST be processed when 1016 encountered (e.g., even before security options). 1018 o >> Only FRAG and UNSAFE options are permitted to modify the UDP 1019 body or option areas. 1021 o >> OCS SHOULD be the first option, except in the presence of 1022 FRAG, in which case it SHOULD be the first option after FRAG. 1024 7. Option inclusion and processing 1026 The following rules apply to option inclusion by senders and 1027 processing by receivers. 1029 >> Senders MAY add any option, as configured by the API. 1031 >> All mandatory options MUST be processed by receivers, if present 1032 (presuming UDP options are supported at that receiver). 1034 >> Non-mandatory options MAY be ignored by receivers, if present, 1035 e.g., based on API settings. 1037 >> All options MUST be processed by receivers in the order 1038 encountered in the options list. 1040 >> All options except UNSAFE options MUST result in the UDP payload 1041 being passed to the application layer, regardless of whether all 1042 options are processed, supported, or succeed. 1044 The basic premise is that, for options-aware endpoints, the sender 1045 decides what options to add and the receiver decides what options to 1046 handle. Simply adding an option does not force work upon a receiver, 1047 with the exception of the mandatory options. 1049 Upon receipt, the receiver checks various properties of the UDP 1050 packet and its options to decide whether to accept or drop the 1051 packet and whether to accept or ignore some its options as follows 1052 (in order): 1054 if the UDP checksum fails then 1055 silently drop (per RFC1122) 1056 if the UDP checksum passes then 1057 if OCS is present and fails then 1058 deliver the UDP payload but ignore all other options 1059 (this is required to emulate legacy behavior) 1060 if OCS is present and passes then 1061 deliver the UDP payload after parsing 1062 and processing the rest of the options, 1063 regardless of whether each is supported or succeeds 1064 (again, this is required to emulate legacy behavior) 1066 The design of the UNSAFE options as used only inside the FRAG area 1067 ensures that the resulting UDP data will be silently dropped in both 1068 legacy and options-aware receivers. 1070 Options-aware receivers can either drop packets with option 1071 processing errors via an override of the default or at the 1072 application layer. 1074 I.e., all options other than OCS are treated the same, in that the 1075 transmitter can add it as desired and the receiver has the option to 1076 require it or not. Only if it is required (e.g., by API 1077 configuration) should the receiver require it being present and 1078 correct. 1080 I.e., for all options other than OCS: 1082 o if the option is not required by the receiver, then packets 1083 missing the option are accepted. 1085 o if the option is required (e.g., by override of the default 1086 behavior at the receiver) and missing or incorrectly formed, 1087 silently drop the packet. 1089 o if the packet is accepted (either because the option is not 1090 required or because it was required and correct), then pass the 1091 option with the packet via the API. 1093 Any options whose length exceeds that of the UDP packet (i.e., 1094 intending to use data that would have been beyond the surplus area) 1095 should be silently ignored (again to model legacy behavior). 1097 8. UDP API Extensions 1099 UDP currently specifies an application programmer interface (API), 1100 summarized as follows (with Unix-style command as an example) 1101 [RFC768]: 1103 o Method to create new receive ports 1105 o E.g., bind(handle, recvaddr(optional), recvport) 1107 o Receive, which returns data octets, source port, and source 1108 address 1110 o E.g., recvfrom(handle, srcaddr, srcport, data) 1112 o Send, which specifies data, source and destination addresses, and 1113 source and destination ports 1115 o E.g., sendto(handle, destaddr, destport, data) 1117 This API is extended to support options as follows: 1119 o Extend the method to create receive ports to include receive 1120 options that are required. Datagrams not containing these 1121 required options MUST be silently dropped and MAY be logged. 1123 o Extend the receive function to indicate the options and their 1124 parameters as received with the corresponding received datagram. 1126 o Extend the send function to indicate the options to be added to 1127 the corresponding sent datagram. 1129 Examples of API instances for Linux and FreeBSD are provided in 1130 Appendix A, to encourage uniform cross-platform implementations. 1132 9. Whose options are these? 1134 UDP options are indicated in an area of the IP payload that is not 1135 used by UDP. That area is really part of the IP payload, not the UDP 1136 payload, and as such, it might be tempting to consider whether this 1137 is a generally useful approach to extending IP. 1139 Unfortunately, the surplus area exists only for transports that 1140 include their own transport layer payload length indicator. TCP and 1141 SCTP include header length fields that already provide space for 1142 transport options by indicating the total length of the header area, 1143 such that the entire remaining area indicated in the network layer 1144 (IP) is transport payload. UDP-Lite already uses the UDP Length 1145 field to indicate the boundary between data covered by the transport 1146 checksum and data not covered, and so there is no remaining area 1147 where the length of the UDP-Lite payload as a whole can be indicated 1148 [RFC3828]. 1150 UDP options are intended for use only by the transport endpoints. 1151 They are no more (or less) appropriate to be modified in-transit 1152 than any other portion of the transport datagram. 1154 UDP options are transport options. Generally, transport datagrams 1155 are not intended to be modified in-transit. UDP options are no 1156 exception and here are specified as "MUST NOT" be altered in 1157 transit. However, the UDP option mechanism provides no specific 1158 protection against in-transit modification of the UDP header, UDP 1159 payload, or UDP option area, except as provided by the options 1160 selected (e.g., OCS or AE). 1162 10. UDP options FRAG option vs. UDP-Lite 1164 UDP-Lite provides partial checksum coverage, so that packets with 1165 errors in some locations can be delivered to the user [RFC3828]. It 1166 uses a different transport protocol number (136) than UDP (17) to 1167 interpret the UDP Length field as the prefix covered by the UDP 1168 checksum. 1170 UDP (protocol 17) already defines the UDP Length field as the limit 1171 of the UDP checksum, but by default also limits the data provided to 1172 the application as that which precedes the UDP Length. A goal of 1173 UDP-Lite is to deliver data beyond UDP Length as a default, which is 1174 why a separate transport protocol number was required. 1176 UDP options do not use or need a separate transport protocol number 1177 because the data beyond the UDP Length offset (surplus data) is not 1178 provided to the application by default. That data is interpreted 1179 exclusively within the UDP transport layer. 1181 The UDP FRAG options option supports a similar service to UDP-Lite. 1182 The main difference is that UDP-Lite provides the un-checksummed 1183 user data to the application by default, whereas the UDP FRAG option 1184 can safely provide that service only between endpoints that 1185 negotiate that capability in advance. An endpoint that does not 1186 implement UDP options would silently discard this non-checksummed 1187 user data, along with the UDP options as well. 1189 UDP-Lite cannot support UDP options, either as proposed here or in 1190 any other form, because the entire payload of the UDP packet is 1191 already defined as user data and there is no additional field in 1192 which to indicate a separate area for options. The UDP Length field 1193 in UDP-Lite is already used to indicate the boundary between user 1194 data covered by the checksum and user data not covered. 1196 11. Interactions with Legacy Devices 1198 It has always been permissible for the UDP Length to be inconsistent 1199 with the IP transport payload length [RFC768]. Such inconsistency 1200 has been utilized in UDP-Lite using a different transport number. 1201 There are no known systems that use this inconsistency for UDP 1202 [RFC3828]. It is possible that such use might interact with UDP 1203 options, i.e., where legacy systems might generate UDP datagrams 1204 that appear to have UDP options. The UDP OCS provides protection 1205 against such events and is stronger than a static "magic number". 1207 UDP options have been tested as interoperable with Linux, macOS, and 1208 Windows Cygwin, and worked through NAT devices. These systems 1209 successfully delivered only the user data indicated by the UDP 1210 Length field and silently discarded the surplus area. 1212 One reported embedded device passes the entire IP datagram to the 1213 UDP application layer. Although this feature could enable 1214 application-layer UDP option processing, it would require that 1215 conventional UDP user applications examine only the UDP payload. 1216 This feature is also inconsistent with the UDP application interface 1217 [RFC768] [RFC1122]. 1219 It has been reported that Alcatel-Lucent's "Brick" Intrusion 1220 Detection System has a default configuration that interprets 1221 inconsistencies between UDP Length and IP Length as an attack to be 1222 reported. Note that other firewall systems, e.g., CheckPoint, use a 1223 default "relaxed UDP length verification" to avoid falsely 1224 interpreting this inconsistency as an attack. 1226 12. Options in a Stateless, Unreliable Transport Protocol 1228 There are two ways to interpret options for a stateless, unreliable 1229 protocol -- an option is either local to the message or intended to 1230 affect a stream of messages in a soft-state manner. Either 1231 interpretation is valid for defined UDP options. 1233 It is impossible to know in advance whether an endpoint supports a 1234 UDP option. 1236 >> All UDP options other than UNSAFE ones MUST be ignored if not 1237 supported or upon failure (e.g., ACS). 1239 >> All UDP options that fail MUST result in the UDP data still being 1240 sent to the application layer by default, to ensure equivalence with 1241 legacy devices. 1243 >> UDP options that rely on soft-state exchange MUST allow for 1244 message reordering and loss. 1246 The above requirements prevent using any option that cannot be 1247 safely ignored unless it is hidden inside the FRAG area (i.e., 1248 UNSAFE options). Legacy systems also always need to be able to 1249 interpret the transport payload fragments as individual transport 1250 datagrams. 1252 13. UDP Option State Caching 1254 Some TCP connection parameters, stored in the TCP Control Block, can 1255 be usefully shared either among concurrent connections or between 1256 connections in sequence, known as TCP Sharing [RFC2140][To21cb]. 1257 Although UDP is stateless, some of the options proposed herein may 1258 have similar benefit in being shared or cached. We call this UCB 1259 Sharing, or UDP Control Block Sharing, by analogy. Just as TCB 1260 sharing is not a standard because it is consistent with existing TCP 1261 specifications, UCB sharing would be consistent with existing UDP 1262 specifications, including this one. Both are implementation issues 1263 that are outside the scope of their respective specifications, and 1264 so UCB sharing is outside the scope of this document. 1266 14. Updates to RFC 768 1268 This document updates RFC 768 as follows: 1270 o This document defines the meaning of the IP payload area beyond 1271 the UDP length but within the IP length. 1273 o This document extends the UDP API to support the use of options. 1275 15. Interactions with other RFCs (and drafts) 1277 This document clarifies the interaction between UDP length and IP 1278 length that is not explicitly constrained in either UDP or the host 1279 requirements [RFC768] [RFC1122]. 1281 Teredo extensions (TE) define use of a similar surplus area for 1282 trailers [RFC6081]. TE defines the UDP length pointing beyond 1283 (larger) than the location indicated by the IP length rather than 1284 shorter (as used herein): 1286 "..the IPv6 packet length (i.e., the Payload Length value in 1287 the IPv6 header plus the IPv6 header size) is less than or 1288 equal to the UDP payload length (i.e., the Length value in 1289 the UDP header minus the UDP header size)" 1291 As a result, UDP options are not compatible with TE, but that is 1292 also why this document does not update TE. Additionally, it is not 1293 at all clear how TE operates, as it requires network processing of 1294 the UDP length field to understand the total message including TE 1295 trailers. 1297 TE updates Teredo NAT traversal [RFC4380]. The NAT traversal 1298 document defined "consistency" of UDP length and IP length as: 1300 "An IPv6 packet is deemed valid if it conforms to [RFC2460]: 1301 the protocol identifier should indicate an IPv6 packet and 1302 the payload length should be consistent with the length of 1303 the UDP datagram in which the packet is encapsulated." 1305 IPv6 is clear on the meaning of this consistency, in which the 1306 pseudoheader used for UDP checksums is based on the UDP length, not 1307 inferred from the IP length, using the same text in the current 1308 specification [RFC8200]: 1310 "The Upper-Layer Packet Length in the pseudo-header is the 1311 length of the upper-layer header and data (e.g., TCP header 1312 plus TCP data). Some upper-layer protocols carry their own 1313 length information (e.g., the Length field in the UDP header); 1314 for such protocols, that is the length used in the pseudo- 1315 header." 1317 This document is consistent the UDP profile for Robust Header 1318 Compression (ROHC)[RFC3095], noted here: 1320 "The Length field of the UDP header MUST match the Length 1321 field(s) of the preceding subheaders, i.e., there must not 1322 be any padding after the UDP payload that is covered by the 1323 IP Length." 1325 ROHC compresses UDP headers only when this match succeeds. It does 1326 not prohibit UDP headers where the match fails; in those cases, ROHC 1327 default rules (Section 5.10) would cause the UDP header to remain 1328 uncompressed. Upon receivep of a compressed UDP header, Section 1329 A.1.3 of that document indicates that the UDP length is "INFERRED"; 1330 in uncompressed packets, it would simply be explicitly provided. 1332 This issue of handling UDP header compression is more explicitly 1333 described in more recent specifications, e.g., Sec. 10.10 of Static 1334 Context Header Compression [RFC8724]. 1336 16. Multicast Considerations 1338 UDP options are primarily intended for unicast use. Using these 1339 options over multicast IP requires careful consideration, e.g., to 1340 ensure that the options used are safe for different endpoints to 1341 interpret differently (e.g., either to support or silently ignore) 1342 or to ensure that all receivers of a multicast group confirm support 1343 for the options in use. 1345 17. Security Considerations 1347 There are a number of security issues raised by the introduction of 1348 options to UDP. Some are specific to this variant, but others are 1349 associated with any packet processing mechanism; all are discussed 1350 in this section further. 1352 The use of UDP packets with inconsistent IP and UDP Length fields 1353 has the potential to trigger a buffer overflow error if not properly 1354 handled, e.g., if space is allocated based on the smaller field and 1355 copying is based on the larger. However, there have been no reports 1356 of such vulnerability and it would rely on inconsistent use of the 1357 two fields for memory allocation and copying. 1359 UDP options are not covered by DTLS (datagram transport-layer 1360 security). Despite the name, neither TLS [RFC8446] (transport layer 1361 security, for TCP) nor DTLS [RFC6347] (TLS for UDP) protect the 1362 transport layer. Both operate as a shim layer solely on the payload 1363 of transport packets, protecting only their contents. Just as TLS 1364 does not protect the TCP header or its options, DTLS does not 1365 protect the UDP header or the new options introduced by this 1366 document. Transport security is provided in TCP by the TCP 1367 Authentication Option (TCP-AO [RFC5925]) or in UDP by the 1368 Authentication Extension option (Section 5.10). Transport headers 1369 are also protected as payload when using IP security (IPsec) 1370 [RFC4301]. 1372 UDP options use the TLV syntax similar to that of TCP. This syntax 1373 is known to require serial processing and may pose a DOS risk, e.g., 1374 if an attacker adds large numbers of unknown options that must be 1375 parsed in their entirety. Implementations concerned with the 1376 potential for this vulnerability MAY implement only the required 1377 options and MAY also limit processing of TLVs. Because required 1378 options come first and at most once each (with the exception of 1379 NOPs, which should never need to come in sequences of more than 1380 three in a row), this limits their DOS impact. Note that TLV formats 1381 for options does require serial processing, but any format that 1382 allows future options, whether ignored or not, could introduce a 1383 similar DOS vulnerability. 1385 UDP security should never rely solely on transport layer processing 1386 of options. UNSAFE options are the only type that share fate with 1387 the UDP data, because of the way that data is hidden in the surplus 1388 area until after those options are processed. All other options 1389 default to being silently ignored at the transport layer but may be 1390 dropped either if that default is overridden (e.g., by 1391 configuration) or discarded at the application layer (e.g., using 1392 information about the options processed that are passed along with 1393 the packet). 1395 UDP fragmentation introduces its own set of security concerns, which 1396 can be handled in a manner similar to IP fragmentation. In 1397 particular, the number of packets pending reassembly and effort used 1398 for reassembly is typically limited. In addition, it may be useful 1399 to assume a reasonable minimum fragment size, e.g., that non- 1400 terminal fragments should never be smaller than 500 bytes. 1402 18. IANA Considerations 1404 Upon publication, IANA is hereby requested to create a new registry 1405 for UDP Option Kind numbers, similar to that for TCP Option Kinds. 1406 Initial values of this registry are as listed in Section 5. 1407 Additional values in this registry are to be assigned from the 1408 UNASSIGNED values in Section 5 by IESG Approval or Standards Action 1409 [RFC8126]. Those assignments are subject to the conditions set forth 1410 in this document, particularly (but not limited to) those in Section 1411 6. 1413 Upon publication, IANA is hereby requested to create a new registry 1414 for UDP Experimental Option Experiment Identifiers (UDP ExIDs) for 1415 use in a similar manner as TCP ExIDs [RFC6994]. UDP ExIDs can be 1416 used in either the UDP EXP option or the UDP UNSAFE option when 1417 using UKind=UEXP. This registry is initially empty. Values in this 1418 registry are to be assigned by IANA using first-come, first-served 1419 (FCFS) rules [RFC8126]. Options using these ExIDs are subject to the 1420 same conditions as new options, i.e., they too are subject to the 1421 conditions set forth in this document, particularly (but not limited 1422 to) those in Section 6. 1424 Upon publication, IANA is hereby requested to create a new registry 1425 for UDP UNSAFE UKind numbers. There are no initial assignments in 1426 this registry. Values in this registry are to be assigned from the 1427 UNASSIGNED values in Section 5.8 by IESG Approval or Standards 1428 Action [RFC8126]. Those assignments are subject to the conditions 1429 set forth in this document, particularly (but not limited to) those 1430 in Section 6. 1432 19. References 1434 19.1. Normative References 1436 [RFC768] Postel, J., "User Datagram Protocol," RFC 768, August 1437 1980. 1439 [RFC791] Postel, J., "Internet Protocol," RFC 791, Sept. 1981. 1441 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -- 1442 Communication Layers," RFC 1122, Oct. 1989. 1444 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1445 Requirement Levels," BCP 14, RFC 2119, March 1997. 1447 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1448 2119 Key Words," RFC 2119, May 2017. 1450 19.2. Informative References 1452 [Fa18] Fairhurst, G., T. Jones, R. Zullo, "Checksum Compensation 1453 Options for UDP Options", draft-fairhurst-udp-options-cco, 1454 Oct. 2018. 1456 [Fa21] Fairhurst, G., T. Jones, "Datagram PLPMTUD for UDP 1457 Options," draft-fairhurst-tsvwg-udp-options-dplpmtud, Apr. 1458 2021. 1460 [Hi15] Hildebrand, J., B. Trammel, "Substrate Protocol for User 1461 Datagrams (SPUD) Prototype," draft-hildebrand-spud- 1462 prototype-03, Mar. 2015. 1464 [RFC793] Postel, J., "Transmission Control Protocol" RFC 793, 1465 September 1981. 1467 [RFC1191] Mogul, J., S. Deering, "Path MTU discovery," RFC 1191, 1468 November 1990. 1470 [RFC2140] Touch, J., "TCP Control Block Interdependence," RFC 2140, 1471 Apr. 1997. 1473 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery," RFC 1474 2923, September 2000. 1476 [RFC3095] Bormann, C. (Ed), et al., "RObust Header Compression 1477 (ROHC): Framework and four profiles: RTP, UDP, ESP, and 1478 uncompressed," RFC 3095, July 2001. 1480 [RFC3385] Sheinwald, D., J. Satran, P. Thaler, V. Cavanna, "Internet 1481 Protocol Small Computer System Interface (iSCSI) Cyclic 1482 Redundancy Check (CRC)/Checksum Considerations," RFC 3385, 1483 Sep. 2002. 1485 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1486 Considered Useful," RFC 3692, Jan. 2004. 1488 [RFC3828] Larzon, L-A., M. Degermark, S. Pink, L-E. Jonsson (Ed.), 1489 G. Fairhurst (Ed.), "The Lightweight User Datagram 1490 Protocol (UDP-Lite)," RFC 3828, July 2004. 1492 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1493 Internet Protocol", RFC 4301, Dec. 2005. 1495 [RFC4340] Kohler, E., M. Handley, and S. Floyd, "Datagram Congestion 1496 Control Protocol (DCCP)", RFC 4340, March 2006. 1498 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1499 Network Address Translations (NATs)," RFC 4380, Feb. 2006. 1501 [RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol", 1502 RFC 4960, September 2007. 1504 [RFC5925] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication 1505 Option," RFC 5925, June 2010. 1507 [RFC6081] Thaler, D., "Teredo Extensions," RFC 6081, Jan 2011. 1509 [RFC6347] Rescorla, E., N. Modadugu, "Datagram Transport Layer 1510 Security Version 1.2," RFC 6347, Jan. 2012. 1512 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)," 1513 RFC 6691, July 2012. 1515 [RFC6978] Touch, J., "A TCP Authentication Option Extension for NAT 1516 Traversal", RFC 6978, July 2013. 1518 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options," RFC 1519 6994, Aug. 2013. 1521 [RFC7323] Borman, D., R. Braden, V. Jacobson, R. Scheffenegger 1522 (Ed.), "TCP Extensions for High Performance," RFC 7323, 1523 Sep. 2014. 1525 [RFC8085] Eggert, L., G. Fairhurst, G. Shepherd, "UDP Usage 1526 Guidelines," RFC 8085, Feb. 2017. 1528 [RFC8126] Cotton, M., B. Leiba, T. Narten, "Guidelines for Writing 1529 an IANA Considerations Section in RFCs," RFC 8126, June 1530 2017. 1532 [RFC8200] Deering, S., R. Hinden, "Internet Protocol Version 6 1533 (IPv6) Specification," RFC 8200, Jul. 2017. 1535 [RFC8201] McCann, J., S. Deering, J. Mogul, R. Hinden (Ed.), "Path 1536 MTU Discovery for IP version 6," RFC 8201, Jul. 2017. 1538 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1539 Version 1.3," RFC 8446, Aug. 2018. 1541 [RFC8724] Minaburo, A., L. Toutain, C. Gomez, D. Barthel, JC., 1542 "SCHC: Generic Framework for Static Context Header 1543 Compression and Fragmentation," RFC 8724, Apr. 2020. 1545 [RFC8899] Fairhurst, G., T. Jones, M. Tuxen, I. Rungeler, T. Volker, 1546 "Packetization Layer Path MTU Discovery for Datagram 1547 Transports," RFC 8899, Sep. 2020. 1549 [To18ao] Touch, J., "A TCP Authentication Option Extension for 1550 Payload Encryption," draft-touch-tcp-ao-encrypt, Jul. 1551 2018. 1553 [To21cb] Touch, J., M. Welzl, S. Islam, J. You, "TCP Control Block 1554 Interdependence," draft-touch-tcpm-2140bis, Apr. 2021. 1556 20. Acknowledgments 1558 This work benefitted from feedback from Bob Briscoe, Ken Calvert, 1559 Ted Faber, Gorry Fairhurst (including OCS for misbehaving middlebox 1560 traversal), C. M. Heard (including combining previous FRAG and LITE 1561 options into the new FRAG), Tom Herbert, Mark Smith, and Raffaele 1562 Zullo, as well as discussions on the IETF TSVWG and SPUD email 1563 lists. 1565 This work was partly supported by USC/ISI's Postel Center. 1567 This document was prepared using 2-Word-v2.0.template.dot. 1569 Authors' Addresses 1571 Joe Touch 1572 Manhattan Beach, CA 90266 USA 1574 Phone: +1 (310) 560-0334 1575 Email: touch@strayalpha.com 1577 Appendix A. Implementation Information 1579 The following information is provided to encourage interoperable API 1580 implementations. 1582 System-level variables (sysctl): 1584 Name default meaning 1585 ---------------------------------------------------- 1586 net.ipv4.udp_opt 0 UDP options available 1587 net.ipv4.udp_opt_ocs 1 Default include OCS 1588 net.ipv4.udp_opt_acs 0 Default include ACS 1589 net.ipv4.udp_opt_mss 0 Default include MSS 1590 net.ipv4.udp_opt_time 0 Default include TIME 1591 net.ipv4.udp_opt_frag 0 Default include FRAG 1592 net.ipv4.udp_opt_ae 0 Default include AE 1594 Socket options (sockopt), cached for outgoing datagrams: 1596 Name meaning 1597 ---------------------------------------------------- 1598 UDP_OPT Enable UDP options (at all) 1599 UDP_OPT_OCS Enable UDP OCS option 1600 UDP_OPT_ACS Enable UDP ACS option 1601 UDP_OPT_MSS Enable UDP MSS option 1602 UDP_OPT_TIME Enable UDP TIME option 1603 UDP_OPT_FRAG Enable UDP FRAG option 1604 UDP_OPT_AE Enable UDP AE option 1606 Send/sendto parameters: 1608 Connection parameters (per-socketpair cached state, part UCB): 1610 Name Initial value 1611 ---------------------------------------------------- 1612 opts_enabled net.ipv4.udp_opt 1613 ocs_enabled net.ipv4.udp_opt_ocs 1615 The following option is included for debugging purposes, and MUST 1616 NOT be enabled otherwise. 1618 System variables 1620 net.ipv4.udp_opt_junk 0 1621 System-level variables (sysctl): 1623 Name default meaning 1624 ---------------------------------------------------- 1625 net.ipv4.udp_opt_junk 0 Default use of junk 1627 Socket options (sockopt): 1629 Name params meaning 1630 ------------------------------------------------------ 1631 UDP_JUNK - Enable UDP junk option 1632 UDP_JUNK_VAL fillval Value to use as junk fill 1633 UDP_JUNK_LEN length Length of junk payload in bytes 1635 Connection parameters (per-socketpair cached state, part UCB): 1637 Name Initial value 1638 ---------------------------------------------------- 1639 junk_enabled net.ipv4.udp_opt_junk 1640 junk_value 0xABCD 1641 junk_len 4