idnits 2.17.1 draft-ietf-tsvwg-udp-options-08.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 1400 has weird spacing: '...default mean...' == Line 1432 has weird spacing: '...enabled net.i...' == Line 1433 has weird spacing: '...enabled net....' == Line 1443 has weird spacing: '...default mean...' == Line 1449 has weird spacing: '... params mean...' == (1 more instance...) -- The document date (September 12, 2019) is 1680 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) -- 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) -- Duplicate reference: RFC2119, mentioned in 'RFC8174', was also mentioned in 'RFC2119'. Summary: 0 errors (**), 0 flaws (~~), 8 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 September 12, 2019 4 Intended updates: 768 5 Expires: March 2020 7 Transport Options for UDP 8 draft-ietf-tsvwg-udp-options-08.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 March 12, 2020. 36 Copyright Notice 38 Copyright (c) 2019 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....................................................7 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).................................11 68 5.5. Lite (LITE)..............................................12 69 5.6. Maximum Segment Size (MSS)...............................14 70 5.7. Fragmentation (FRAG).....................................15 71 5.8. Coupling FRAG with LITE..................................17 72 5.9. Timestamps (TIME)........................................18 73 5.10. Authentication and Encryption (AE)......................19 74 6. Echo request (REQ) and echo response (RES)....................20 75 6.1. Experimental (EXP).......................................20 76 7. Rules for designing new options...............................21 77 8. Option inclusion and processing...............................22 78 9. UDP API Extensions............................................24 79 10. Whose options are these?.....................................24 80 11. UDP options LITE option vs. UDP-Lite.........................25 81 12. Interactions with Legacy Devices.............................26 82 13. Options in a Stateless, Unreliable Transport Protocol........26 83 14. UDP Option State Caching.....................................27 84 15. Updates to RFC 768...........................................27 85 16. Multicast Considerations.....................................27 86 17. Security Considerations......................................28 87 18. IANA Considerations..........................................28 88 19. References...................................................29 89 19.1. Normative References....................................29 90 19.2. Informative References..................................29 91 20. Acknowledgments..............................................31 92 Appendix A. Implementation Information...........................32 94 1. Introduction 96 Transport protocols use options as a way to extend their 97 capabilities. TCP [RFC793], SCTP [RFC4960], and DCCP [RFC4340] 98 include space for these options but UDP [RFC768] currently does not. 99 This document defines an extension to UDP that provides space for 100 transport options including their generic syntax and semantics for 101 their use in UDP's stateless, unreliable message protocol. 103 2. Conventions used in this document 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in 108 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 109 capitals, as shown here. 111 In this document, the characters ">>" preceding an indented line(s) 112 indicates a statement using the key words listed above. This 113 convention aids reviewers in quickly identifying or finding the 114 portions of this RFC covered by these key words. 116 3. Background 118 Many protocols include a default header and an area for header 119 options. These options enable the protocol to be extended for use in 120 particular environments or in ways unforeseen by the original 121 designers. Examples include TCP's Maximum Segment Size, Window 122 Scale, Timestamp, and Authentication Options 123 [RFC793][RFC5925][RFC7323]. 125 These options are used both in stateful (connection-oriented, e.g., 126 TCP [RFC793], SCTP [RFC4960], DCCP [RFC4340]) and stateless 127 (connectionless, e.g., IPv4 [RFC791], IPv6 [RFC8200]) protocols. In 128 stateful protocols they can help extend the way in which state is 129 managed. In stateless protocols their effect is often limited to 130 individual packets, but they can have an aggregate effect on a 131 sequence as well. One example of such uses is Substrate Protocol for 132 User Datagrams (SPUD) [Tr16], and this document is intended to 133 provide an out-of-band option area as an alternative to the in-band 134 mechanism currently proposed [Hi15]. 136 UDP is one of the most popular protocols that lacks space for 137 options [RFC768]. The UDP header was intended to be a minimal 138 addition to IP, providing only ports and a data checksum for 139 protection. This document extends UDP to provide a trailer area for 140 options located after the UDP data payload. 142 4. The UDP Option Area 144 The UDP transport header includes demultiplexing and service 145 identification (port numbers), a checksum, and a field that 146 indicates the UDP datagram length (including UDP header). The UDP 147 Length field is typically redundant with the size of the maximum 148 space available as a transport protocol payload (see also discussion 149 in Section 12). 151 For IPv4, IP Total Length field indicates the total IP datagram 152 length (including IP header), and the size of the IP options is 153 indicated in the IP header (in 4-byte words) as the "Internet Header 154 Length" (IHL), as shown in Figure 1 [RFC791]. As a result, the 155 typical (and largest valid) value for UDP Length is: 157 UDP_Length = IPv4_Total_Length - IPv4_IHL * 4 159 For IPv6, the IP Payload Length field indicates the datagram after 160 the base IPv6 header, which includes the IPv6 extension headers and 161 space available for the transport protocol, as shown in Figure 2 162 [RFC8200]. Note that the Next HDR field in IPv6 might not indicate 163 UDP (i.e., 17), e.g., when intervening IP extension headers are 164 present. For IPv6, the lengths of any additional IP extensions are 165 indicated within each extension [RFC8200], so the typical (and 166 largest valid) value for UDP Length is: 168 UDP_Length = IPv6_Payload_Length - sum(extension header lengths) 170 In both cases, the space available for the UDP transport protocol 171 data unit is indicated by IP, either completely in the base header 172 (for IPv4) or adding information in the extensions (for IPv6). In 173 either case, this document will refer to this available space as the 174 "IP transport payload". 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 |Version| IHL |Type of Service| Total Length | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Identification |Flags| Fragment Offset | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Time to Live | Proto=17 (UDP)| Header Checksum | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Source Address | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Destination Address | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 ... zero or more IP Options (using space as indicated by IHL) ... 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | UDP Source Port | UDP Destination Port | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | UDP Length | UDP Checksum | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Figure 1 IPv4 datagram with UDP transport payload 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 |Version| Traffic Class | Flow Label | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Payload Length | Next Hdr | Hop Limit | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 ... 202 | Source Address (128 bits) | 203 ... 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 ... 206 | Destination Address (128 bits) | 207 ... 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 ... zero or more IP Extension headers (each indicating size) ... 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | UDP Source Port | UDP Destination Port | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | UDP Length | UDP Checksum | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 Figure 2 IPv6 datagram with UDP transport payload 218 As a result of this redundancy, there is an opportunity to use the 219 UDP Length field as a way to break up the IP transport payload into 220 two areas - that intended as UDP user data and an additional 221 "surplus area" (as shown in Figure 3). 223 IP transport payload 224 <-------------------------------------------------> 225 +--------+---------+----------------------+------------------+ 226 | IP Hdr | UDP Hdr | UDP user data | surplus area | 227 +--------+---------+----------------------+------------------+ 228 <------------------------------> 229 UDP Length 231 Figure 3 IP transport payload vs. UDP Length 233 In most cases, the IP transport payload and UDP Length point to the 234 same location, indicating that there is no surplus area. It is 235 important to note that this is not a requirement of UDP [RFC768] 236 (discussed further in Section 12). UDP-Lite used the difference in 237 these pointers to indicate the partial coverage of the UDP Checksum, 238 such that the UDP user data, UDP header, and UDP pseudoheader (a 239 subset of the IP header) are covered by the UDP checksum but 240 additional user data in the surplus area is not covered [RFC3828]. 241 This document uses the surplus area for UDP transport options. 243 The UDP option area is thus defined as the location between the end 244 of the UDP payload and the end of the IP datagram as a trailing 245 options area. This area can occur at any valid byte offset, i.e., it 246 need not be 16-bit or 32-bit aligned. In effect, this document 247 redefines the UDP "Length" field as a "trailer offset". 249 UDP options are defined using a TLV (type, length, and optional 250 value) syntax similar to that of TCP [RFC793]. They are typically a 251 minimum of two bytes in length as shown in Figure 4, excepting only 252 the one byte options "No Operation" (NOP) and "End of Options List" 253 (EOL) described below. 255 +--------+--------+ 256 | Kind | Length | 257 +--------+--------+ 259 Figure 4 UDP option default format 261 The Kind field is always one byte. The Length field is one byte for 262 all lengths below 255 (including the Kind and Length bytes). A 263 Length of 255 indicates use of the UDP option extended format shown 264 in Figure 5. The Extended Length field is a 16-bit field in network 265 standard byte order. 267 +--------+--------+--------+--------+ 268 | Kind | 255 | Extended Length | 269 +--------+--------+--------+--------+ 271 Figure 5 UDP option extended default format 273 >> UDP options MAY begin at any UDP length offset. 275 >> The UDP length MUST be at least as large as the UDP header (8) 276 and no larger than the IP transport payload. Values outside this 277 range MUST be silently discarded as invalid and logged where rate- 278 limiting permits. 280 >> Option Lengths (or Extended Lengths, where applicable) smaller 281 than the minimum for the corresponding Kind and default format MUST 282 be treated as an error. 284 Others have considered using values of the UDP Length that is larger 285 than the IP transport payload as an additional type of signal. Using 286 a value smaller than the IP transport payload is expected to be 287 backward compatible with existing UDP implementations, i.e., to 288 deliver the UDP Length of user data to the application and silently 289 ignore the additional surplus area data. Using a value larger than 290 the IP transport payload would either be considered malformed (and 291 be silently dropped) or could cause buffer overruns, and so is not 292 considered silently and safely backward compatible. Its use is thus 293 out of scope for the extension described in this document. 295 >> UDP options MUST be interpreted in the order in which they occur 296 in the UDP option area. 298 5. UDP Options 300 The following UDP options are currently defined: 302 Kind Length Meaning 303 ---------------------------------------------- 304 0* - End of Options List (EOL) 305 1* - No operation (NOP) 306 2* 3 Option checksum (OCS) 307 3* 6 Alternate checksum (ACS) 308 4* 4 Lite (LITE) 309 5* 4 Maximum segment size (MSS) 310 6* 8/10 Fragmentation (FRAG) 311 7 10 Timestamps (TIME) 312 8 (varies) Authentication and Encryption (AE) 313 9 6 Request (REQ) 314 10 6 Response (RES) 315 11-126 (varies) UNASSIGNED (assignable by IANA) 316 127-253 RESERVED 317 254 N(>=4) RFC 3692-style experiments (EXP) 318 255 Reserved 320 These options are defined in the following subsections. Options 0 321 and 1 use the same values as for TCP. 323 >> An endpoint supporting UDP options MUST support those marked with 324 a "*" above: EOL, NOP, OCS, ACS, LITE, FRAG, and MSS. This includes 325 both recognizing and being able to generate these options if 326 configured to do so. 328 >> All other options (without a "*") MAY be implemented, and their 329 use SHOULD be determined either out-of-band or negotiated. 331 >> Receivers MUST silently ignore unknown options. That includes 332 options whose length does not indicate the specified value. 334 >> Except for NOP, each option SHOULD NOT occur more than once in a 335 single UDP datagram. If a non-NOP option occurs more than once, a 336 receiver MUST interpret only the first instance of that option and 337 MUST ignore all others. 339 >> Only the OCS and AE options depend on the contents of the option 340 area. AE is always computed as if the AE hash and OCS checksum are 341 zero; OCS is always computed as if the OCS checksum is zero and 342 after the AE hash has been computed. Future options MUST NOT be 343 defined as having a value dependent on the contents of the option 344 area. Otherwise, interactions between those values, OCS, and AE 345 could be unpredictable. 347 Receivers cannot treat unexpected option lengths as invalid, as this 348 would unnecessarily limit future revision of options (e.g., defining 349 a new ACS that is defined by having a different length). 351 >> Option lengths MUST NOT exceed the IP length of the packet. If 352 this occurs, the packet MUST be treated as malformed and dropped, 353 and the event MAY be logged for diagnostics (logging SHOULD be rate 354 limited). 356 >> Options with fixed lengths MUST use the default option format. 358 >> Options with variable lengths MUST use the default option format 359 where their total length is 254 bytes or less. 361 >> Options using the extended option format MUST indicate extended 362 lengths of 255 or higher; smaller extended length values MUST be 363 treated as an error. 365 >> Required options MUST come before other options. Each required 366 option MUST NOT occur more than once (if they are repeated in a 367 received segment, all except the first MUST be silently ignored). 369 The requirement that required options come before others is intended 370 to allow for endpoints to implement DOS protection, as discussed 371 further in Section 17. 373 5.1. End of Options List (EOL) 375 The End of Options List (EOL) option indicates that there are no 376 more options. It is used to indicate the end of the list of options 377 without needing to pad the options to fill all available option 378 space. 380 +--------+ 381 | Kind=0 | 382 +--------+ 384 Figure 6 UDP EOL option format 386 >> When the UDP options do not consume the entire option area, the 387 last non-NOP option MUST be EOL. 389 >> All bytes in the surplus area after EOL MUST be zero. 391 Requiring the post-option surplus area to be zero prevents side- 392 channel uses of this area, requiring instead that all use of the 393 surplus area be UDP options supported by both endpoints. It is 394 useful to allow for such padding to increase the packet length 395 without affecting the payload length, e.g., for UDP PLPMTUD [Fa19]. 397 5.2. No Operation (NOP) 399 The No Operation (NOP) option is a one byte placeholder, intended to 400 be used as padding, e.g., to align multi-byte options along 16-bit 401 or 32-bit boundaries. 403 +--------+ 404 | Kind=1 | 405 +--------+ 407 Figure 7 UDP NOP option format 409 >> If options longer than one byte are used, NOP options SHOULD be 410 used at the beginning of the UDP options area to achieve alignment 411 as would be more efficient for active (i.e., non-NOP) options. 413 >> Segments SHOULD NOT use more than three consecutive NOPs. NOPs 414 are intended to assist with alignment, not other padding or fill. 416 [NOTE: Tom Herbert suggested we declare "more than 3 consecutive 417 NOPs" a fatal error to reduce the potential of using NOPs as a DOS 418 attack, but IMO there are other equivalent ways (e.g., using 419 RESERVED or other UNASSIGNED values) and the "no more than 3" 420 creates its own DOS vulnerability) 422 5.3. Option Checksum (OCS) 424 The Option Checksum (OCS) option is conventional Internet checksum 425 [RFC791] that covers all of the surplus area. The primary purpose of 426 OCS is to detect non-standard (i.e., non-option) uses of that area. 428 OCS is calculated by computing the Internet checksum over the 429 surplus area. OCS protects the option area from errors in a similar 430 way that the UDP checksum protects the UDP user data (when not 431 zero). 433 +--------+--------+--------+ 434 | Kind=2 | checksum | 435 +--------+--------+--------+ 437 Figure 8 UDP OCS option format 439 >> OCS is REQUIRED when the UDP checksum is nonzero and UDP options 440 are present. 442 >> When present, OCS SHOULD occur as early as possible, preceded by 443 only NOP options for alignment and the LITE option if present. 445 >> OCS MUST be half-word coordinated with the start of the UDP 446 options area. 448 This coordination is accomplished by computing the Internet checksum 449 over the surplus area (including EOL, if present) and then adjusting 450 the result before storing it into the OCS checksum field. If that 451 field is aligned to the start of the options area, then the checksum 452 is inserted as-is, otherwise the checksum bytes are swapped before 453 inserting them into the field. 455 The adjustment above helps enable that OCS, together with the other 456 options, result in an overall zero ones-complement sum. This feature 457 is intended to potentially help the UDP options traverse devices 458 that incorrectly attempt to checksum the surplus area (as originally 459 proposed as the Checksum Compensation Option, i.e., CCO [Fa18]). 460 Note that this incorrect checksum traversal feature is defeated by 461 the use of LITE, whether alone or with FRAG, because the LITE area 462 is deliberately not covered by OCS. It also is defeated by the use 463 of a zero UDP checksum (i.e., UDP checksum disabled). 465 OCS covers the UDP option area, including the Lite option (but not 466 LITE data area) as formatted before swapping (or relocation) for 467 transmission (or, equivalently, after the swap/relocation after 468 reception), as the LITE option would occur at the beginning of the 469 original (prior to rearrangement for transmission) or restored 470 (after rearrangement upon reception) UDP option area. 472 >> If OCS fails, all options MUST be ignored and any trailing 473 surplus data (and Lite data, if used) silently discarded. 475 >> UDP data that is validated by a correct UDP checksum MUST be 476 delivered to the application layer, even if OCS fails, unless the 477 endpoints have negotiated otherwise for this segment's socket pair. 479 As a reminder, use of the UDP checksum is optional when the UDP 480 checksum is zero. When not used, OCS is assumed to be "correct" for 481 the purpose of accepting UDP packets at a receiver (see Section 8). 483 OCS is intended to check for accidental errors, not for attacks. 485 5.4. Alternate Checksum (ACS) 487 The Alternate Checksum (ACS) option provides a stronger alternative 488 to the checksum in the UDP header, using a 32-bit CRC of the 489 conventional UDP payload only (excluding the IP pseudoheader, UDP 490 header, and UDP options, and not include the LITE area). Because it 491 does not include the IP pseudoheader or UDP header, it need not be 492 updated by NATs when IP addresses or UDP ports are rewritten. Its 493 purpose is to detect errors that the UDP checksum, when used, might 494 not detect. 496 CRC32c has been chosen because of its ubiquity and use in other 497 Internet protocols, including iSCSI and SCTP. The option contains 498 CRC32c in network standard byte order, as described in [RFC3385]. 500 +--------+--------+--------+--------+ 501 | Kind=3 | Len=6 | CRC32c... | 502 +--------+--------+--------+--------+ 503 | CRC32c (cont.) | 504 +--------+--------+ 506 Figure 9 UDP ACS option format 508 When present, the ACS always contains a valid CRC checksum. There 509 are no reserved values, including the value of zero. If the CRC is 510 zero, this must indicate a valid checksum (i.e., it does not 511 indicate that the ACS is not used; instead, the option would simply 512 not be included if that were the desired effect). 514 ACS does not protect the UDP pseudoheader; only the current UDP 515 checksum provides that protection (when used). ACS cannot provide 516 that protection because it would need to be updated whenever the UDP 517 pseudoheader changed, e.g., during NAT address and port translation; 518 because this is not the case, ACS does not cover the pseudoheader. 520 5.5. Lite (LITE) 522 The Lite option (LITE) is intended to provide equivalent capability 523 to the UDP Lite transport protocol [RFC3828]. UDP Lite allows the 524 UDP checksum to cover only a prefix of the UDP data payload, to 525 protect critical information (e.g., application headers) but allow 526 potentially erroneous data to be passed to the user. This feature 527 helps protect application headers but allows for application data 528 errors. Some applications are impacted more by a lack of data than 529 errors in data, e.g., voice and video. 531 >> When LITE is active, it MUST come first in the UDP options list. 533 LITE is intended to support the same API as for UDP Lite to allow 534 applications to send and receive data that has a marker indicating 535 the portion protected by the UDP checksum and the portion not 536 protected by the UDP checksum. 538 LITE includes a 2-byte offset that indicates the length of the 539 portion of the UDP data that is not covered by the UDP checksum. 541 +--------+--------+--------+--------+ 542 | Kind=4 | Len=4 | Offset | 543 +--------+--------+--------+--------+ 545 Figure 10 UDP LITE option format 547 At the sender, the option is formed using the following steps: 549 1. Create a LITE option, ordered as the first UDP option (Figure 550 11). 552 2. Calculate the location of the start of the options as an absolute 553 offset from the start of the UDP header and place that length in 554 the last two bytes of the LITE option. 556 3. If the LITE data area is 4 bytes or longer, swap all four bytes 557 of the LITE option with the first 4 bytes of the LITE data area 558 (Figure 12). If the LITE data area is 0-3 bytes long, slide the 559 LITE option to the front of the LITE data area (i.e., placing the 560 0-3 bytes of LITE data after the LITE option). 562 +---------+--------------+--------------+------------------+ 563 | UDP Hdr | user data | LITE data |LITE| other opts | 564 +---------+--------------+--------------+------------------+ 565 <----------------------> 566 UDP Length 568 Figure 11 LITE option formation - LITE goes first 570 +---------+--------------+--------------+------------------+ 571 | UDP Hdr | user data | LITE data |LITE| other opts | 572 +---------+--------------+--------------+------------------+ 573 ^^^^ ^^^^ 574 | | 575 +--------------+ 577 Figure 12 Before sending swap LITE option and front of LITE data 579 The resulting packet has the format shown in Figure 13. Note that 580 the UDP length now points to the LITE option, and the LITE option 581 points to the start of the option area. 583 +---------+--------------+----------------+------------------+ 584 | UDP Hdr | user data |LITE| LITE data |Ldat| other opts | 585 +---------+--------------+----------------+------------------+ 586 <----------------------> | ^ 587 UDP Length +-------------+ 589 Figure 13 Lite option as sent 591 A legacy endpoint receiving this packet will discard the LITE option 592 and everything that follows, including the lite data and remainder 593 of the UDP options. The UDP checksum will protect only the user 594 data, not the LITE option or lite data. 596 Receiving endpoints capable of processing UDP options will do the 597 following: 599 1. Process options as usual. This will start at the LITE option. 601 2. When the LITE option is encountered, record its location as the 602 start of the LITE data area and (if the LITE offset indicates a 603 LITE data length of at least 4 bytes) swap the four bytes there 604 with the four bytes at the location indicated inside the LITE 605 option, which indicates the start of all of the options, 606 including the LITE one (one past the end of the lite data area). 607 If the LITE offset indicates a LITE data area of 0-3 bytes, then 608 slide the LITE option forward that amount and slide the 609 corresponding bytes after the LITE option to where the LITE 610 option originally began. In either case, this restores the format 611 of the option as it was prior to being sent, as per Figure 11. 613 3. Continue processing the remainder of the options, which are now 614 in the format shown in Figure 12. 616 The purpose of this swap (or slide) is to support the equivalent of 617 UDP Lite operation together with other UDP options without requiring 618 the entire LITE data area to be moved after the UDP option area. 620 5.6. Maximum Segment Size (MSS) 622 The Maximum Segment Size (MSS, Kind = 3) option is a 16-bit 623 indicator of the largest UDP segment that can be received. As with 624 the TCP MSS option [RFC793], the size indicated is the IP layer MTU 625 decreased by the fixed IP and UDP headers only [RFC6691]. The space 626 needed for IP and UDP options need to be adjusted by the sender when 627 using the value indicated. The value transmitted is based on EMTU_R, 628 the largest IP datagram that can be received (i.e., reassembled at 629 the receiver) [RFC1122]. 631 +--------+--------+--------+--------+ 632 | Kind=5 | Len=4 | MSS size | 633 +--------+--------+--------+--------+ 635 Figure 14 UDP MSS option format 637 The UDP MSS option MAY be used for path MTU discovery 638 [RFC1191][RFC8201], but this may be difficult because of known 639 issues with ICMP blocking [RFC2923] as well as UDP lacking automatic 640 retransmission. It is more likely to be useful when coupled with IP 641 source fragmentation to limit the largest reassembled UDP message, 642 e.g., when EMTU_R is larger than the required minimums (576 for IPv4 643 [RFC791] and 1500 for IPv6 [RFC8200]). 645 5.7. Fragmentation (FRAG) 647 The Fragmentation (FRAG) option supports UDP fragmentation and 648 reassembly, which can be used to transfer UDP messages larger than 649 limited by the IP receive MTU (EMTU_R [RFC1122]). It is typically 650 used with the UDP MSS option to enable more efficient use of large 651 messages, both at the UDP and IP layers. FRAG is designed similar to 652 the IPv6 Fragmentation Header [RFC8200], except that the UDP variant 653 uses a 16-bit Offset measured in bytes, rather than IPv6's 13-bit 654 Fragment Offset measured in 8-byte units. This UDP variant avoids 655 creating reserved fields. 657 +--------+--------+--------+--------+ 658 | Kind=6 | Len=8 | Frag. Offset | 659 +--------+--------+--------+--------+ 660 | Identification | 661 +--------+--------+--------+--------+ 663 Figure 15 UDP non-terminal FRAG option format 665 The FRAG option also lacks a "more" bit, zeroed for the terminal 666 fragment of a set. This is possible because the terminal FRAG option 667 is indicated as a longer, 10-byte variant, which includes an 668 Internet checksum over the entire reassembled UDP payload (omitting 669 the IP pseudoheader and UDP header, as well as UDP options), as 670 shown in Figure 16. 672 >> The reassembly checksum SHOULD be used, but MAY be unused in the 673 same situations when the UDP checksum is unused (e.g., for transit 674 tunnels or applications that have their own integrity checks 675 [RFC8200]), and by the same mechanism (set the field to 0x0000). 677 +--------+--------+--------+--------+ 678 | Kind=6 | Len=10 | Frag. Offset | 679 +--------+--------+--------+--------+ 680 | Identification | 681 +--------+--------+--------+--------+ 682 | Checksum | 683 +--------+--------+ 685 Figure 16 UDP terminal FRAG option format 687 >> During fragmentation, the UDP header checksum of each fragment 688 needs to be recomputed based on each datagram's pseudoheader. 690 >> After reassembly is complete and validated using the checksum of 691 the terminal FRAG option, the UDP header checksum of the resulting 692 datagram needs to be recomputed based on the datagram's 693 pseudoheader. 695 The Fragment Offset is 16 bits and indicates the location of the UDP 696 payload fragment in bytes from the beginning of the original 697 unfragmented payload. The Len field indicates whether there are more 698 fragments (Len=8) or no more fragments (Len=12). 700 >> The Identification field is a 32-bit value that MUST be unique 701 over the expected fragment reassembly timeout. 703 >> The Identification field SHOULD be generated in a manner similar 704 to that of the IPv6 Fragment ID [RFC8200]. 706 >> UDP fragments MUST NOT overlap. 708 FRAG needs to be used with extreme care because it will present 709 incorrect datagram boundaries to a legacy receiver, unless encoded 710 as LITE data (see Section 5.8). 712 >> A host SHOULD indicate FRAG support by transmitting an 713 unfragmented datagram using the Fragmentation option (e.g., with 714 Offset zero and length 12, i.e., including the checksum area), 715 except when encoded as LITE. 717 >> A host MUST NOT transmit a UDP fragment before receiving recent 718 confirmation from the remote host, except when FRAG is encoded as 719 LITE. 721 UDP fragmentation relies on a fragment expiration timer, which can 722 be preset or could use a value computed using the UDP Timestamp 723 option. 725 >> The default UDP reassembly SHOULD be no more than 2 minutes. 727 Implementers are advised to limit the space available for UDP 728 reassembly. 730 >> UDP reassembly space SHOULD be limited to reduce the impact of 731 DOS attacks on resource use. 733 >> UDP reassembly space limits SHOULD NOT be implemented as an 734 aggregate, to avoid cross-socketpair DOS attacks. 736 >> Individual UDP fragments MUST NOT be forwarded to the user. The 737 reassembled datagram is received only after complete reassembly, 738 checksum validation, and continued processing of the remaining 739 options. 741 Any additional UDP options would follow the FRAG option in the final 742 fragment, and would be included in the reassembled packet. 743 Processing of those options would commence after reassembly. 745 >> UDP options MUST NOT follow the FRAG header in non-terminal 746 fragments. Any data following the FRAG header in non-terminal 747 fragments MUST be silently dropped. All other options that apply to 748 a reassembled packet MUST follow the FRAG header in the terminal 749 fragment. 751 5.8. Coupling FRAG with LITE 753 FRAG can be coupled with LITE to avoid impacting legacy receivers. 754 Each fragment is sent as LITE un-checksummed data, where each UDP 755 packet contains no legacy-compatible data. Legacy receivers 756 interpret these as zero-length payload packets (i.e., UDP Length 757 field is 8, the length of just the UDP header), which would not 758 affect the receiver unless the presence of the packet itself were a 759 signal. The header of such a packet would appear as shown in Figure 760 17 and Figure 18. 762 +---------+--------------+---------+ 763 | UDP Hdr | LiteFrag |LITE|FRAG| 764 +---------+--------------+----+----+ 765 <-------> ^^^^ ^^^^ 766 UDP Length=8 | | 767 +--------------+ 769 Figure 17 Preparing FRAG as Lite data 771 +---------+--------------+----+ 772 | UDP Hdr |LITE|LiteFrag |FRAG| 773 +---------+--------------+----+ 774 <-------> | ^ 775 UDP Length=8 | | 776 +-------------+ 778 Figure 18 Lite option before transmission 780 When a packet is reassembled, it appears as a complete LITE data 781 region. The UDP header of the reassembled packet is adjusted 782 accordingly, so that the reassembled region now appears as 783 conventional UDP user data, and processing of the UDP options 784 continues, as with the non-LITE FRAG variant. 786 5.9. Timestamps (TIME) 788 The Timestamp (TIME) option exchanges two four-byte timestamp 789 fields. It serves a similar purpose to TCP's TS option [RFC7323], 790 enabling UDP to estimate the round trip time (RTT) between hosts. 791 For UDP, this RTT can be useful for establishing UDP fragment 792 reassembly timeouts or transport-layer rate-limiting [RFC8085]. 794 +--------+--------+------------------+------------------+ 795 | Kind=7 | Len=10 | TSval | TSecr | 796 +--------+--------+------------------+------------------+ 797 1 byte 1 byte 4 bytes 4 bytes 799 Figure 19 UDP TIME option format 801 TS Value (TSval) and TS Echo Reply (TSecr) are used in a similar 802 manner to the TCP TS option [RFC7323]. On transmitted segments using 803 the option, TS Value is always set based on the local "time" value. 804 Received TSval and TSecr values are provided to the application, 805 which can pass the TSval value to be used as TSecr on UDP messages 806 sent in response (i.e., to echo the received TSval). A received 807 TSecr of zero indicates that the TSval was not echoed by the 808 transmitter, i.e., from a previously received UDP packet. 810 >> TIME MAY use an RTT estimate based on nonzero Timestamp values as 811 a hint for fragmentation reassembly, rate limiting, or other 812 mechanisms that benefit from such an estimate. 814 >> TIME SHOULD make this RTT estimate available to the user 815 application. 817 UDP timestamps are modeled after TCP timestamps and have similar 818 expectations. In particular, they are expected to be: 820 o Values are monotonic and non-decreasing 822 o Values should increase according to a typical 'tick' time 824 o A request is defined as "reply=0" and a reply is defined as both 825 fields being non-zero. 827 o A receiver should always respond to a request with the highest 828 TSval received, which is not necessarily the most recently 829 received. 831 5.10. Authentication and Encryption (AE) 833 The Authentication and Encryption (AE) option is intended to allow 834 UDP to provide a similar type of authentication as the TCP 835 Authentication Option (TCP-AO) [RFC5925]. It uses the same format as 836 specified for TCP-AO, except that it uses a Kind of 8. AE supports 837 NAT traversal in a similar manner as TCP-AO [RFC6978]. AE can also 838 be extended to provide a similar encryption capability as TCP-AO- 839 ENC, in a similar manner [To18ao]. 841 +--------+--------+--------+--------+ 842 | Kind=8 | Len | Digest... | 843 +--------+--------+--------+--------+ 844 | Digest (con't)... | 845 +--------+--------+--------+--------+ 847 Figure 20 UDP AE option format 849 Like TCP-AO, AE is not negotiated in-band. Its use assumes both 850 endpoints have populated Master Key Tuples (MKTs), used to exclude 851 non-protected traffic. 853 TCP-AO generates unique traffic keys from a hash of TCP connection 854 parameters. UDP lacks a three-way handshake to coordinate 855 connection-specific values, such as TCP's Initial Sequence Numbers 856 (ISNs) [RFC793], thus AE's Key Derivation Function (KDF) uses zeroes 857 as the value for both ISNs. This means that the AE reuses keys when 858 socket pairs are reused, unlike TCP-AO. 860 AE can be configured to either include or exclude UDP options, the 861 same way as can TCP-AO. When UDP options are covered, the OCS option 862 area checksum and AE hash areas are zeroed before computing the AE 863 hash. It is important to consider that options not yet defined might 864 yield unpredictable results if not confirmed as supported, e.g., if 865 they were to contain other hashes or checksums that depend on the 866 option area contents. This is why such dependencies are not 867 permitted except as defined for OCS and UDP-AE. 869 Similar to TCP-AO-NAT, AE can be configured to support NAT 870 traversal, excluding one or both of the UDP ports [RFC6978]. 872 6. Echo request (REQ) and echo response (RES) 874 The echo request (REQ, kind=9) and echo response (RES, kind=10) 875 options provide a means for UDP options to be used to provide 876 packet-level acknowledgements. Their use is described as part of the 877 UDP variant of packetization layer path MTU discovery (PLPMTUD) 878 [Fa19]. The options both have the format indicated in Figure 21. 880 +--------+--------+------------------+ 881 | Kind | Len=6 | nonce | 882 +--------+--------+------------------+ 883 1 byte 1 byte 4 bytes 885 Figure 21 UDP REQ and RES options format 887 6.1. Experimental (EXP) 889 The Experimental option (EXP) is reserved for experiments [RFC3692]. 890 It uses a Kind value of 254. Only one such value is reserved because 891 experiments are expected to use an Experimental ID (ExIDs) to 892 differentiate concurrent use for different purposes, using UDP ExIDs 893 registered with IANA according to the approach developed for TCP 894 experimental options [RFC6994]. 896 +----------+----------+----------+----------+ 897 | Kind=254 | Len | UDP ExID | 898 +----------+----------+----------+----------+ 899 | (option contents, as defined)... | 900 +----------+----------+----------+----------+ 902 Figure 22 UDP EXP option format 904 >> The length of the experimental option MUST be at least 4 to 905 account for the Kind, Length, and the minimum 16-bit UDP ExID 906 identifier (similar to TCP ExIDs [RFC6994]). 908 7. Rules for designing new options 910 The UDP option Kind space allows for the definition of new options, 911 however the currently defined options do not allow for arbitrary new 912 options. For example, LITE needs to come first if present; new 913 options cannot declare that they need to precede it. The following 914 is a summary of rules for new options and their rationales: 916 >> New options MUST NOT depend on option space content. Only OCS and 917 AE depend on the content of the options themselves and their order 918 is fixed (on transmission, AE is computed first using a zero- 919 checksum OCS if present, and OCS is computed last before 920 transmission, over the entire option area, including AE). 922 >> New options MUST NOT declare their order relative to other 923 options, whether new or old. 925 >> At the sender, new options MUST NOT modify UDP packet content 926 anywhere except within their option field; areas that need to remain 927 unmodified include the IP header, IP options, the UDP body, the UDP 928 option area (i.e., other options), and the post-option area. 930 >> Options MUST NOT be modified in transit. This includes those 931 already defined as well as new options. New options MUST NOT require 932 or intend optionally for modification of any UDP options, including 933 their new areas, in transit. 935 >> New options with fixed lengths smaller than 255 or variable 936 lengths that are always smaller than 255 MUST use only the default 937 option format. 939 Note that only certain of the initially defined options violate 940 these rules: 942 o >> LITE MUST be first, if present, and MUST be processed when 943 encountered (e.g., even before security options). 945 o >> LITE is the only option that modifies the UDP body or option 946 areas. 948 o >> OCS SHOULD be the first option, except in the presence of 949 LITE, in which case it SHOULD be the first option after LITE. 951 8. Option inclusion and processing 953 The following rules apply to option inclusion by senders and 954 processing by receivers. 956 >> Senders MAY add any option, as configured by the API. 958 >> All mandatory options MUST be processed by receivers, if present 959 (presuming UDP options are supported at that receiver). 961 >> Non-mandatory options MAY be ignored by receivers, if present, 962 based on API settings. 964 >> All options MUST be processed by receivers in the order 965 encountered in the options list. 967 The basic premise is that the sender decides what options to add and 968 the receiver decides what options to handle. Simply adding an option 969 does not force work upon a receiver, with the exception of the 970 mandatory options. 972 Upon receipt, the receiver checks various properties of the UDP 973 packet and its options to decide whether to accept or drop the 974 packet and whether to accept or ignore some its options as follows 975 (in order): 977 if the UDP checksum fails then 978 silently drop (per RFC1122) 979 if the UDP checksum passes then 980 if OCS is present and fails then 981 deliver the UDP payload but ignore all options 982 (this is required to emulate legacy behavior) 983 if OCS is present and passes then 984 deliver the UDP payload after parsing 985 and processing the rest of the options 987 (for other options 'OPT' when encountered in sequence): 988 if both sender and receiver choose to use OPT then 989 if OPT passes then 990 deliver the UDP payload after parsing 991 and processing the rest of the options 992 if OPT fails then 993 silently drop the packet 994 if OPT is not present when received then 995 silently drop the packet 996 if the sender includes OPT 997 and the receiver does not indicate OPT is required then 998 the receiver accepts all UDP payloads that pass 999 the UDP checksum and indicate for each packet 1000 whether OPT succeeded, but never drop when OPT fails 1002 I.e., all options other than OCS are treated the same, in that the 1003 transmitter can add it as desired and the receiver has the option to 1004 require it or not. Only if it is required (by API configuration) 1005 should the receiver require it being present and correct. 1007 I.e., for all options other than OCS: 1009 o if the option is not required by the receiver, then packets 1010 missing the option are accepted. 1012 o if the option is required and missing or incorrectly formed, 1013 silently drop the packet. 1015 o if the packet is accepted (either because the option is not 1016 required or because it was required and correct), then pass the 1017 option with the packet via the API. 1019 Any options whose length exceeds that of the UDP packet (i.e., 1020 intending to use data that would have been beyond the surplus area) 1021 should be silently ignored (again to model legacy behavior). 1023 9. UDP API Extensions 1025 UDP currently specifies an application programmer interface (API), 1026 summarized as follows (with Unix-style command as an example) 1027 [RFC768]: 1029 o Method to create new receive ports 1031 o E.g., bind(handle, recvaddr(optional), recvport) 1033 o Receive, which returns data octets, source port, and source 1034 address 1036 o E.g., recvfrom(handle, srcaddr, srcport, data) 1038 o Send, which specifies data, source and destination addresses, and 1039 source and destination ports 1041 o E.g., sendto(handle, destaddr, destport, data) 1043 This API is extended to support options as follows: 1045 o Extend the method to create receive ports to include receive 1046 options that are required. Datagrams not containing these 1047 required options MUST be silently dropped and MAY be logged. 1049 o Extend the receive function to indicate the options and their 1050 parameters as received with the corresponding received datagram. 1052 o Extend the send function to indicate the options to be added to 1053 the corresponding sent datagram. 1055 Examples of API instances for Linux and FreeBSD are provided in 1056 Appendix A, to encourage uniform cross-platform implementations. 1058 10. Whose options are these? 1060 UDP options are indicated in an area of the IP payload that is not 1061 used by UDP. That area is really part of the IP payload, not the UDP 1062 payload, and as such, it might be tempting to consider whether this 1063 is a generally useful approach to extending IP. 1065 Unfortunately, the surplus area exists only for transports that 1066 include their own transport layer payload length indicator. TCP and 1067 SCTP include header length fields that already provide space for 1068 transport options by indicating the total length of the header area, 1069 such that the entire remaining area indicated in the network layer 1070 (IP) is transport payload. UDP-Lite already uses the UDP Length 1071 field to indicate the boundary between data covered by the transport 1072 checksum and data not covered, and so there is no remaining area 1073 where the length of the UDP-Lite payload as a whole can be indicated 1074 [RFC3828]. 1076 UDP options are intended for use only by the transport endpoints. 1077 They are no more (or less) appropriate to be modified in-transit 1078 than any other portion of the transport datagram. 1080 UDP options are transport options. Generally, transport datagrams 1081 are not intended to be modified in-transit. UDP options are no 1082 exception and here are specified as "MUST NOT" be altered in 1083 transit. However, the UDP option mechanism provides no specific 1084 protection against in-transit modification of the UDP header, UDP 1085 payload, or UDP option area, except as provided by the options 1086 selected (e.g., OCS or AE). 1088 11. UDP options LITE option vs. UDP-Lite 1090 UDP-Lite provides partial checksum coverage, so that packets with 1091 errors in some locations can be delivered to the user [RFC3828]. It 1092 uses a different transport protocol number (136) than UDP (17) to 1093 interpret the UDP Length field as the prefix covered by the UDP 1094 checksum. 1096 UDP (protocol 17) already defines the UDP Length field as the limit 1097 of the UDP checksum, but by default also limits the data provided to 1098 the application as that which precedes the UDP Length. A goal of 1099 UDP-Lite is to deliver data beyond UDP Length as a default, which is 1100 why a separate transport protocol number was required. 1102 UDP options do not use or need a separate transport protocol number 1103 because the data beyond the UDP Length offset (surplus data) is not 1104 provided to the application by default. That data is interpreted 1105 exclusively within the UDP transport layer. 1107 The LITE UDP options option supports a similar service to UDP-Lite. 1108 The main difference is that UDP-Lite provides the un-checksummed 1109 user data to the application by default, whereas the LITE UDP option 1110 can safely provide that service only between endpoints that 1111 negotiate that capability in advance. An endpoint that does not 1112 implement UDP options would silently discard this non-checksummed 1113 user data, along with the UDP options as well. 1115 UDP-Lite cannot support UDP options, either as proposed here or in 1116 any other form, because the entire payload of the UDP packet is 1117 already defined as user data and there is no additional field in 1118 which to indicate a separate area for options. The UDP Length field 1119 in UDP-Lite is already used to indicate the boundary between user 1120 data covered by the checksum and user data not covered. 1122 12. Interactions with Legacy Devices 1124 It has always been permissible for the UDP Length to be inconsistent 1125 with the IP transport payload length [RFC768]. Such inconsistency 1126 has been utilized in UDP-Lite using a different transport number. 1127 There are no known systems that use this inconsistency for UDP 1128 [RFC3828]. It is possible that such use might interact with UDP 1129 options, i.e., where legacy systems might generate UDP datagrams 1130 that appear to have UDP options. The UDP OCS provides protection 1131 against such events and is stronger than a static "magic number". 1133 UDP options have been tested as interoperable with Linux, macOS, and 1134 Windows Cygwin, and worked through NAT devices. These systems 1135 successfully delivered only the user data indicated by the UDP 1136 Length field and silently discarded the surplus area. 1138 One reported embedded device passes the entire IP datagram to the 1139 UDP application layer. Although this feature could enable 1140 application-layer UDP option processing, it would require that 1141 conventional UDP user applications examine only the UDP payload. 1142 This feature is also inconsistent with the UDP application interface 1143 [RFC768] [RFC1122]. 1145 It has been reported that Alcatel-Lucent's "Brick" Intrusion 1146 Detection System has a default configuration that interprets 1147 inconsistencies between UDP Length and IP Length as an attack to be 1148 reported. Note that other firewall systems, e.g., CheckPoint, use a 1149 default "relaxed UDP length verification" to avoid falsely 1150 interpreting this inconsistency as an attack. 1152 (TBD: test with UDP checksum offload and UDP fragmentation offload) 1154 13. Options in a Stateless, Unreliable Transport Protocol 1156 There are two ways to interpret options for a stateless, unreliable 1157 protocol -- an option is either local to the message or intended to 1158 affect a stream of messages in a soft-state manner. Either 1159 interpretation is valid for defined UDP options. 1161 It is impossible to know in advance whether an endpoint supports a 1162 UDP option. 1164 >> UDP options MUST allow for silent failure on first receipt. 1166 >> UDP options that rely on soft-state exchange MUST allow for 1167 message reordering and loss. 1169 >> A UDP option MUST be silently optional until confirmed by 1170 exchange with an endpoint. 1172 The above requirements prevent using any option that cannot be 1173 safely ignored unless that capability has been negotiated with an 1174 endpoint in advance for a socket pair. Legacy systems would need to 1175 be able to interpret the transport payload fragments as individual 1176 transport datagrams. 1178 14. UDP Option State Caching 1180 Some TCP connection parameters, stored in the TCP Control Block, can 1181 be usefully shared either among concurrent connections or between 1182 connections in sequence, known as TCP Sharing [RFC2140][To19cb]. 1183 Although UDP is stateless, some of the options proposed herein may 1184 have similar benefit in being shared or cached. We call this UCB 1185 Sharing, or UDP Control Block Sharing, by analogy. 1187 [TBD: extend this section to indicate which options MAY vs. MUST NOT 1188 be shared and how, e.g., along the lines of To19cb] 1190 15. Updates to RFC 768 1192 This document updates RFC 768 as follows: 1194 o This document defines the meaning of the IP payload area beyond 1195 the UDP length but within the IP length. 1197 o This document extends the UDP API to support the use of options. 1199 16. Multicast Considerations 1201 UDP options are primarily intended for unicast use. Using these 1202 options over multicast IP requires careful consideration, e.g., to 1203 ensure that the options used are safe for different endpoints to 1204 interpret differently (e.g., either to support or silently ignore) 1205 or to ensure that all receivers of a multicast group confirm support 1206 for the options in use. 1208 17. Security Considerations 1210 The use of UDP packets with inconsistent IP and UDP Length fields 1211 has the potential to trigger a buffer overflow error if not properly 1212 handled, e.g., if space is allocated based on the smaller field and 1213 copying is based on the larger. However, there have been no reports 1214 of such vulnerability and it would rely on inconsistent use of the 1215 two fields for memory allocation and copying. 1217 UDP options are not covered by DTLS (datagram transport-layer 1218 security). Despite the name, neither TLS [RFC8446] (transport layer 1219 security, for TCP) nor DTLS [RFC6347] (TLS for UDP) protect the 1220 transport layer. Both operate as a shim layer solely on the payload 1221 of transport packets, protecting only their contents. Just as TLS 1222 does not protect the TCP header or its options, DTLS does not 1223 protect the UDP header or the new options introduced by this 1224 document. Transport security is provided in TCP by the TCP 1225 Authentication Option (TCP-AO [RFC5925]) or in UDP by the 1226 Authentication Extension option (Section 5.10). Transport headers 1227 are also protected as payload when using IP security (IPsec) 1228 [RFC4301]. 1230 UDP options use the TLV syntax similar to that of TCP. This syntax 1231 is known to require serial processing and may pose a DOS risk, e.g., 1232 if an attacker adds large numbers of unknown options that must be 1233 parsed in their entirety. Implementations concerned with the 1234 potential for this vulnerability MAY implement only the required 1235 options and MAY also limit processing of TLVs. Because required 1236 options come first and at most once each (with the exception of 1237 NOPs, which should never need to come in sequences of more than 1238 three in a row), this limits their DOS impact. Note that when a 1239 packet's options cannot be processed, it MUST be discarded; the 1240 packet and its options should always share the same fate. 1242 18. IANA Considerations 1244 Upon publication, IANA is hereby requested to create a new registry 1245 for UDP Option Kind numbers, similar to that for TCP Option Kinds. 1246 Initial values of this registry are as listed in Section 5. 1247 Additional values in this registry are to be assigned from the 1248 UNASSIGNED values Section 5 in by IESG Approval or Standards Action 1249 [RFC8126]. Those assignments are subject to the conditions set forth 1250 in this document, particularly (but not limited to) those in Section 1251 7. 1253 Upon publication, IANA is hereby requested to create a new registry 1254 for UDP Experimental Option Experiment Identifiers (UDP ExIDs) for 1255 use in a similar manner as TCP ExIDs [RFC6994]. This registry is 1256 initially empty. Values in this registry are to be assigned by IANA 1257 using first-come, first-served (FCFS) rules [RFC8126]. Options using 1258 these ExIDs are subject to the same conditions as new options, i.e., 1259 they too are subject to the conditions set forth in this document, 1260 particularly (but not limited to) those in Section 7. 1262 19. References 1264 19.1. Normative References 1266 [Fa19] Fairhurst, G., T. Jones, M. Tuexen, I. Ruengeler, T. 1267 Voelker, "Packetization Layer Path MTU Discovery for 1268 Datagram Transports," draft-ietf-tsvwg-datagram-plpmtud, 1269 Feb. 2019. 1271 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1272 Requirement Levels," BCP 14, RFC 2119, March 1997. 1274 [RFC768] Postel, J., "User Datagram Protocol," RFC 768, August 1275 1980. 1277 [RFC791] Postel, J., "Internet Protocol," RFC 791, Sept. 1981. 1279 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -- 1280 Communication Layers," RFC 1122, Oct. 1989. 1282 19.2. Informative References 1284 [Fa18] Fairhurst, G., T. Jones, R. Zullo, "Checksum Compensation 1285 Options for UDP Options", draft-fairhurst-udp-options-cco, 1286 Oct. 2018. 1288 [Hi15] Hildebrand, J., B. Trammel, "Substrate Protocol for User 1289 Datagrams (SPUD) Prototype," draft-hildebrand-spud- 1290 prototype-03, Mar. 2015. 1292 [RFC793] Postel, J., "Transmission Control Protocol" RFC 793, 1293 September 1981. 1295 [RFC1191] Mogul, J., S. Deering, "Path MTU discovery," RFC 1191, 1296 November 1990. 1298 [RFC2140] Touch, J., "TCP Control Block Interdependence," RFC 2140, 1299 Apr. 1997. 1301 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery," RFC 1302 2923, September 2000. 1304 [RFC3385] Sheinwald, D., J. Satran, P. Thaler, V. Cavanna, "Internet 1305 Protocol Small Computer System Interface (iSCSI) Cyclic 1306 Redundancy Check (CRC)/Checksum Considerations," RFC 3385, 1307 Sep. 2002. 1309 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1310 Considered Useful," RFC 3692, Jan. 2004. 1312 [RFC3828] Larzon, L-A., M. Degermark, S. Pink, L-E. Jonsson (Ed.), 1313 G. Fairhurst (Ed.), "The Lightweight User Datagram 1314 Protocol (UDP-Lite)," RFC 3828, July 2004. 1316 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1317 Internet Protocol", RFC 4301, Dec. 2005. 1319 [RFC4340] Kohler, E., M. Handley, and S. Floyd, "Datagram Congestion 1320 Control Protocol (DCCP)", RFC 4340, March 2006. 1322 [RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol", 1323 RFC 4960, September 2007. 1325 [RFC5925] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication 1326 Option," RFC 5925, June 2010. 1328 [RFC6347] Rescorla, E., N. Modadugu, "Datagram Transport Layer 1329 Security Version 1.2," RFC 6347, Jan. 2012. 1331 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)," 1332 RFC 6691, July 2012. 1334 [RFC6978] Touch, J., "A TCP Authentication Option Extension for NAT 1335 Traversal", RFC 6978, July 2013. 1337 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options," RFC 1338 6994, Aug. 2013. 1340 [RFC7323] Borman, D., R. Braden, V. Jacobson, R. Scheffenegger 1341 (Ed.), "TCP Extensions for High Performance," RFC 7323, 1342 Sep. 2014. 1344 [RFC8085] Eggert, L., G. Fairhurst, G. Shepherd, "UDP Usage 1345 Guidelines," RFC 8085, Feb. 2017. 1347 [RFC8126] Cotton, M., B. Leiba, T. Narten, "Guidelines for Writing 1348 an IANA Considerations Section in RFCs," RFC 8126, June 1349 2017. 1351 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1352 2119 Key Words," RFC 2119, May 2017. 1354 [RFC8200] Deering, S., R. Hinden, "Internet Protocol Version 6 1355 (IPv6) Specification," RFC 8200, Jul. 2017. 1357 [RFC8201] McCann, J., S. Deering, J. Mogul, R. Hinden (Ed.), "Path 1358 MTU Discovery for IP version 6," RFC 8201, Jul. 2017. 1360 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1361 Version 1.3," RFC 8446, Aug. 2018. 1363 [To18ao] Touch, J., "A TCP Authentication Option Extension for 1364 Payload Encryption," draft-touch-tcp-ao-encrypt, Jul. 1365 2018. 1367 [To19cb] Touch, J., M. Welzl, S. Islam, J. You, "TCP Control Block 1368 Interdependence," draft-touch-tcpm-2140bis, Jan. 2019. 1370 [Tr16] Trammel, B. (Ed.), M. Kuelewind (Ed.), "Requirements for 1371 the design of a Substrate Protocol for User Datagrams 1372 (SPUD)," draft-trammell-spud-req-04, May 2016. 1374 20. Acknowledgments 1376 This work benefitted from feedback from Bob Briscoe, Ken Calvert, 1377 Ted Faber, Gorry Fairhurst, C. M. Heard (including the FRAG/LITE 1378 combination), Tom Herbert, and Mark Smith, as well as discussions on 1379 the IETF TSVWG and SPUD email lists. 1381 This work was partly supported by USC/ISI's Postel Center. 1383 This document was prepared using 2-Word-v2.0.template.dot. 1385 Authors' Addresses 1387 Joe Touch 1388 Manhattan Beach, CA 90266 USA 1390 Phone: +1 (310) 560-0334 1391 Email: touch@strayalpha.com 1393 Appendix A. Implementation Information 1395 The following information is provided to encourage interoperable API 1396 implementations. 1398 System-level variables (sysctl): 1400 Name default meaning 1401 ---------------------------------------------------- 1402 net.ipv4.udp_opt 0 UDP options available 1403 net.ipv4.udp_opt_ocs 1 Default include OCS 1404 net.ipv4.udp_opt_acs 0 Default include ACS 1405 net.ipv4.udp_opt_lite 0 Default include LITE 1406 net.ipv4.udp_opt_mss 0 Default include MSS 1407 net.ipv4.udp_opt_time 0 Default include TIME 1408 net.ipv4.udp_opt_frag 0 Default include FRAG 1409 net.ipv4.udp_opt_ae 0 Default include AE 1411 Socket options (sockopt), cached for outgoing datagrams: 1413 Name meaning 1414 ---------------------------------------------------- 1415 UDP_OPT Enable UDP options (at all) 1416 UDP_OPT_OCS Enable UDP OCS option 1417 UDP_OPT_ACS Enable UDP ACS option 1418 UDP_OPT_LITE Enable UDP LITE option 1419 UDP_OPT_MSS Enable UDP MSS option 1420 UDP_OPT_TIME Enable UDP TIME option 1421 UDP_OPT_FRAG Enable UDP FRAG option 1422 UDP_OPT_AE Enable UDP AE option 1424 Send/sendto parameters: 1426 (TBD - currently using cached parameters) 1428 Connection parameters (per-socketpair cached state, part UCB): 1430 Name Initial value 1431 ---------------------------------------------------- 1432 opts_enabled net.ipv4.udp_opt 1433 ocs_enabled net.ipv4.udp_opt_ocs 1435 The following option is included for debugging purposes, and MUST 1436 NOT be enabled otherwise. 1438 System variables 1439 net.ipv4.udp_opt_junk 0 1441 System-level variables (sysctl): 1443 Name default meaning 1444 ---------------------------------------------------- 1445 net.ipv4.udp_opt_junk 0 Default use of junk 1447 Socket options (sockopt): 1449 Name params meaning 1450 ------------------------------------------------------ 1451 UDP_JUNK - Enable UDP junk option 1452 UDP_JUNK_VAL fillval Value to use as junk fill 1453 UDP_JUNK_LEN length Length of junk payload in bytes 1455 Connection parameters (per-socketpair cached state, part UCB): 1457 Name Initial value 1458 ---------------------------------------------------- 1459 junk_enabled net.ipv4.udp_opt_junk 1460 junk_value 0xABCD 1461 junk_len 4