idnits 2.17.1 draft-ietf-tsvwg-udp-options-07.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 1365 has weird spacing: '...default mean...' == Line 1397 has weird spacing: '...enabled net.i...' == Line 1398 has weird spacing: '...enabled net....' == Line 1408 has weird spacing: '...default mean...' == Line 1414 has weird spacing: '... params mean...' == (1 more instance...) -- The document date (March 8, 2019) is 1875 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) ** Downref: Normative reference to an Informational RFC: RFC 1071 -- 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 (~~), 8 warnings (==), 6 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 March 8, 2019 4 Intended updates: 768 5 Expires: September 2019 7 Transport Options for UDP 8 draft-ietf-tsvwg-udp-options-07.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 September 8, 2019. 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 experimentally extends UDP by indicating the 55 location, 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).................................8 65 5.2. No Operation (NOP)........................................9 66 5.3. Option Checksum (OCS).....................................9 67 5.4. Alternate Checksum (ACS).................................11 68 5.5. Lite (LITE)..............................................11 69 5.6. Maximum Segment Size (MSS)...............................13 70 5.7. Fragmentation (FRAG).....................................14 71 5.8. Coupling FRAG with LITE..................................16 72 5.9. Timestamps (TIME)........................................17 73 5.10. Authentication and Encryption (AE)......................18 74 6. Echo request (REQ) and echo response (RES)....................19 75 6.1. Experimental (EXP).......................................19 76 7. Rules for designing new options...............................20 77 8. Option inclusion and processing...............................21 78 9. UDP API Extensions............................................23 79 10. Whose options are these?.....................................23 80 11. UDP options LITE option vs. UDP-Lite.........................24 81 12. Interactions with Legacy Devices.............................25 82 13. Options in a Stateless, Unreliable Transport Protocol........25 83 14. UDP Option State Caching.....................................26 84 15. Updates to RFC 768...........................................26 85 16. Multicast Considerations.....................................26 86 17. Security Considerations......................................27 87 18. IANA Considerations..........................................27 88 19. References...................................................28 89 19.1. Normative References....................................28 90 19.2. Informative References..................................28 91 20. Acknowledgments..............................................30 92 Appendix A. Implementation Information...........................31 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 experimental extension to UDP that provides 100 space for transport options including their generic syntax and 101 semantics for their use in UDP's stateless, unreliable message 102 protocol. 104 2. Conventions used in this document 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [RFC2119]. 110 In this document, these words will appear with that interpretation 111 only when in ALL CAPS. Lowercase uses of these words are not to be 112 interpreted as carrying significance described in RFC 2119. 114 In this document, the characters ">>" preceding an indented line(s) 115 indicates a statement using the key words listed above. This 116 convention aids reviewers in quickly identifying or finding the 117 portions of this RFC covered by these key words. 119 3. Background 121 Many protocols include a default header and an area for header 122 options. These options enable the protocol to be extended for use in 123 particular environments or in ways unforeseen by the original 124 designers. Examples include TCP's Maximum Segment Size, Window 125 Scale, Timestamp, and Authentication Options 126 [RFC793][RFC5925][RFC7323]. 128 These options are used both in stateful (connection-oriented, e.g., 129 TCP [RFC793], SCTP [RFC4960], DCCP [RFC4340]) and stateless 130 (connectionless, e.g., IPv4 [RFC791], IPv6 [RFC8200]) protocols. In 131 stateful protocols they can help extend the way in which state is 132 managed. In stateless protocols their effect is often limited to 133 individual packets, but they can have an aggregate effect on a 134 sequence as well. One example of such uses is Substrate Protocol for 135 User Datagrams (SPUD) [Tr16], and this document is intended to 136 provide an out-of-band option area as an alternative to the in-band 137 mechanism currently proposed [Hi15]. 139 UDP is one of the most popular protocols that lacks space for 140 options [RFC768]. The UDP header was intended to be a minimal 141 addition to IP, providing only ports and a data checksum for 142 protection. This document experimentally extends UDP to provide a 143 trailer area for options located after the UDP data payload. 145 4. The UDP Option Area 147 The UDP transport header includes demultiplexing and service 148 identification (port numbers), a checksum, and a field that 149 indicates the UDP datagram length (including UDP header). The UDP 150 Length field is typically redundant with the size of the maximum 151 space available as a transport protocol payload (see also discussion 152 in Section 12). 154 For IPv4, IP Total Length field indicates the total IP datagram 155 length (including IP header), and the size of the IP options is 156 indicated in the IP header (in 4-byte words) as the "Internet Header 157 Length" (IHL), as shown in Figure 1 [RFC791]. As a result, the 158 typical (and largest valid) value for UDP Length is: 160 UDP_Length = IPv4_Total_Length - IPv4_IHL * 4 162 For IPv6, the IP Payload Length field indicates the datagram after 163 the base IPv6 header, which includes the IPv6 extension headers and 164 space available for the transport protocol, as shown in Figure 2 165 [RFC8200]. Note that the Next HDR field in IPv6 might not indicate 166 UDP (i.e., 17), e.g., when intervening IP extension headers are 167 present. For IPv6, the lengths of any additional IP extensions are 168 indicated within each extension [RFC8200], so the typical (and 169 largest valid) value for UDP Length is: 171 UDP_Length = IPv6_Payload_Length - sum(extension header lengths) 173 In both cases, the space available for the UDP transport protocol 174 data unit is indicated by IP, either completely in the base header 175 (for IPv4) or adding information in the extensions (for IPv6). In 176 either case, this document will refer to this available space as the 177 "IP transport payload". 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 |Version| IHL |Type of Service| Total Length | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Identification |Flags| Fragment Offset | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Time to Live | Proto=17 (UDP)| Header Checksum | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Source Address | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Destination Address | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 ... zero or more IP Options (using space as indicated by IHL) ... 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | UDP Source Port | UDP Destination Port | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | UDP Length | UDP Checksum | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 Figure 1 IPv4 datagram with UDP transport payload 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 |Version| Traffic Class | Flow Label | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Payload Length | Next Hdr | Hop Limit | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 ... 205 | Source Address (128 bits) | 206 ... 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 ... 209 | Destination Address (128 bits) | 210 ... 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 ... zero or more IP Extension headers (each indicating size) ... 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | UDP Source Port | UDP Destination Port | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | UDP Length | UDP Checksum | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 Figure 2 IPv6 datagram with UDP transport payload 221 As a result of this redundancy, there is an opportunity to use the 222 UDP Length field as a way to break up the IP transport payload into 223 two areas - that intended as UDP user data and an additional 224 "surplus area" (as shown in Figure 3). 226 IP transport payload 227 <-------------------------------------------------> 228 +--------+---------+----------------------+------------------+ 229 | IP Hdr | UDP Hdr | UDP user data | surplus area | 230 +--------+---------+----------------------+------------------+ 231 <------------------------------> 232 UDP Length 234 Figure 3 IP transport payload vs. UDP Length 236 In most cases, the IP transport payload and UDP Length point to the 237 same location, indicating that there is no surplus area. It is 238 important to note that this is not a requirement of UDP [RFC768] 239 (discussed further in Section 12). UDP-Lite used the difference in 240 these pointers to indicate the partial coverage of the UDP Checksum, 241 such that the UDP user data, UDP header, and UDP pseudoheader (a 242 subset of the IP header) are covered by the UDP checksum but 243 additional user data in the surplus area is not covered [RFC3828]. 244 This document uses the surplus area for UDP transport options. 246 The UDP option area is thus defined as the location between the end 247 of the UDP payload and the end of the IP datagram as a trailing 248 options area. This area can occur at any valid byte offset, i.e., it 249 need not be 16-bit or 32-bit aligned. In effect, this document 250 redefines the UDP "Length" field as a "trailer offset". 252 UDP options are defined using a TLV (type, length, and optional 253 value) syntax similar to that of TCP [RFC793]. They are typically a 254 minimum of two bytes in length as shown in Figure 4, excepting only 255 the one byte options "No Operation" (NOP) and "End of Options List" 256 (EOL) described below. 258 +--------+--------+ 259 | Kind | Length | 260 +--------+--------+ 262 Figure 4 UDP option default format 264 >> UDP options MAY occur at any UDP length offset. 266 >> The UDP length MUST be at least as large as the UDP header (8) 267 and no larger than the IP transport payload. Values outside this 268 range MUST be silently discarded as invalid and logged where rate- 269 limiting permits. 271 Others have considered using values of the UDP Length that is larger 272 than the IP transport payload as an additional type of signal. Using 273 a value smaller than the IP transport payload is expected to be 274 backward compatible with existing UDP implementations, i.e., to 275 deliver the UDP Length of user data to the application and silently 276 ignore the additional surplus area data. Using a value larger than 277 the IP transport payload would either be considered malformed (and 278 be silently dropped) or could cause buffer overruns, and so is not 279 considered silently and safely backward compatible. Its use is thus 280 out of scope for the extension described in this document. 282 >> UDP options MUST be interpreted in the order in which they occur 283 in the UDP option area. 285 5. UDP Options 287 The following UDP options are currently defined: 289 Kind Length Meaning 290 ---------------------------------------------- 291 0* - End of Options List (EOL) 292 1* - No operation (NOP) 293 2* 2 Option checksum (OCS) 294 3* 4 Alternate checksum (ACS) 295 4* 4 Lite (LITE) 296 5* 4 Maximum segment size (MSS) 297 6* 8/10 Fragmentation (FRAG) 298 7 10 Timestamps (TIME) 299 8 (varies) Authentication and Encryption (AE) 300 9 6 Request (REQ) 301 10 6 Response (RES) 302 11-126 (varies) UNASSIGNED (assignable by IANA) 303 127-253 RESERVED 304 254 N(>=4) RFC 3692-style experiments (EXP) 305 255 RESERVED 307 These options are defined in the following subsections. Options 0 308 and 1 use the same values as for TCP. 310 >> An endpoint supporting UDP options MUST support those marked with 311 a "*" above: EOL, NOP, OCS, ACS, LITE, FRAG, and MSS. This includes 312 both recognizing and being able to generate these options if 313 configured to do so. 315 >> All other options (without a "*") MAY be implemented, and their 316 use SHOULD be determined either out-of-band or negotiated. 318 >> Receivers MUST silently ignore unknown options. That includes 319 options whose length does not indicate the specified value. 321 >> Except for NOP, each option SHOULD NOT occur more than once in a 322 single UDP datagram. If a non-NOP option occurs more than once, a 323 receiver MUST interpret only the first instance of that option and 324 MUST ignore all others. 326 >> Only the OCS and AE options depend on the contents of the option 327 area. AE is always computed as if the AE hash and OCS checksum are 328 zero; OCS is always computed as if the OCS checksum is zero and 329 after the AE hash has been computed. Future options MUST NOT be 330 defined as having a value dependent on the contents of the option 331 area. Otherwise, interactions between those values, OCS, and AE 332 could be unpredictable. 334 Receivers cannot treat unexpected option lengths as invalid, as this 335 would unnecessarily limit future revision of options (e.g., defining 336 a new ACS that is defined by having a different length). 338 >> Option lengths MUST NOT exceed the IP length of the packet. If 339 this occurs, the packet MUST be treated as malformed and dropped, 340 and the event MAY be logged for diagnostics (logging SHOULD be rate 341 limited). 343 >> Required options MUST come before other options. Each required 344 option MUST NOT occur more than once (if they are repeated in a 345 received segment, all except the first MUST be silently ignored). 347 The requirement that required options come before others is intended 348 to allow for endpoints to implement DOS protection, as discussed 349 further in Section 17. 351 5.1. End of Options List (EOL) 353 The End of Options List (EOL) option indicates that there are no 354 more options. It is used to indicate the end of the list of options 355 without needing to pad the options to fill all available option 356 space. 358 +--------+ 359 | Kind=0 | 360 +--------+ 362 Figure 5 UDP EOL option format 364 >> When the UDP options do not consume the entire option area, the 365 last non-NOP option SHOULD be EOL (vs. filling the entire option 366 area with NOP values). 368 >> All bytes after EOL MUST be ignored by UDP option processing. As 369 a result, there can only ever be one EOL option (even if other bytes 370 were zero, they are ignored). 372 5.2. No Operation (NOP) 374 The No Operation (NOP) option is a one byte placeholder, intended to 375 be used as padding, e.g., to align multi-byte options along 16-bit 376 or 32-bit boundaries. 378 +--------+ 379 | Kind=1 | 380 +--------+ 382 Figure 6 UDP NOP option format 384 >> If options longer than one byte are used, NOP options SHOULD be 385 used at the beginning of the UDP options area to achieve alignment 386 as would be more efficient for active (i.e., non-NOP) options. 388 >> Segments SHOULD NOT use more than three consecutive NOPs. NOPs 389 are intended to assist with alignment, not other padding or fill. 391 [NOTE: Tom Herbert suggested we declare "more than 3 consecutive 392 NOPs" a fatal error to reduce the potential of using NOPs as a DOS 393 attack, but IMO there are other equivalent ways (e.g., using 394 RESERVED or other UNASSIGNED values) and the "no more than 3" 395 creates its own DOS vulnerability) 397 5.3. Option Checksum (OCS) 399 The Option Checksum (OCS) is conventional Internet checksum that 400 covers all of the UDP options. The primary purpose of OCS is to 401 detect non-standard (i.e., non-option) uses of the options area. 403 OCS is calculated by computing the Internet checksum options area 404 [RFC1071]. OCS protects the option area from errors in a similar way 405 that the UDP checksum protects the UDP user data (when not zero). 407 +--------+--------+ 408 | Kind=2 |checksum| 409 +--------+--------+ 411 Figure 7 UDP OCS option format 413 >> When present, the option checksum SHOULD occur as early as 414 possible, preceded by only NOP options for alignment and the LITE 415 option if present. 417 >> The OCS checksum MUST be half-word coordinated with the start of 418 the UDP options area. 420 This coordination is accomplished by computing the Internet checksum 421 over the UDP options area (including EOL, if present) and then 422 adjusting the result before storing it into the OCS checksum field. 423 If that field is aligned to the start of the options area, then the 424 checksum is inserted as-is, otherwise the checksum bytes are swapped 425 before inserting them into the field. 427 The adjustment above helps enable that OCS, together with the other 428 options, result in an overall zero ones-complement sum. This feature 429 is intended to potentially help the UDP options traverse devices 430 that incorrectly attempt to checksum the surplus area (as originally 431 proposed as the Checksum Compensation Option, i.e., CCO [Fa18]). 432 Note that this incorrect checksum traversal feature is defeated by 433 the use of LITE, whether alone or with FRAG, because the LITE area 434 is deliberately not covered by OCS. It also is defeated by the use 435 of a zero UDP checksum (i.e., UDP checksum disabled). 437 OCS covers the UDP option area, including the Lite option (but not 438 LITE data area) as formatted before swapping (or relocation) for 439 transmission (or, equivalently, after the swap/relocation after 440 reception), as the LITE option would occur at the beginning of the 441 original (prior to rearrangement for transmission) or restored 442 (after rearrangement upon reception) UDP option area. 444 >> If OCS fails, all options MUST be ignored and any trailing 445 surplus data (and Lite data, if used) silently discarded. 447 >> UDP data that is validated by a correct UDP checksum MUST be 448 delivered to the application layer, even if OCS fails, unless the 449 endpoints have negotiated otherwise for this segment's socket pair. 451 As a reminder, use of the UDP checksum is optional. When not used, 452 i.e., when the field is zero, that checksum is assumed to be 453 "correct" for the purpose of accepting UDP packets at a receiver. 455 OCS is intended to check for accidental errors, not for attacks. 457 5.4. Alternate Checksum (ACS) 459 The Alternate Checksum (ACS) provides a stronger alternative to the 460 checksum in the UDP header, using a 16-bit CRC of the conventional 461 UDP payload only (excluding the IP pseudoheader, UDP header, and UDP 462 options, and not include the LITE area). Because it does not include 463 the IP pseudoheader or UDP header, it need not be updated by NATs 464 when IP addresses or UDP ports are rewritten. Its purpose is to 465 detect errors that the UDP checksum, when used, might not detect. 467 CRC-CCITT (polynomial x^16 + x^12 + x^5 + 1) has been chosen because 468 of its ubiquity and use in other packet protocols, such as X.25, 469 HDLC, and Bluetooth. The option contains FCS-16 as defined in 470 Appendix C of [RFC1662], except that it is not inverted in the final 471 step and that it is stored in the ACS option in network byte order. 473 +--------+--------+--------+--------+ 474 | Kind=3 | Len=4 | CRC16sum | 475 +--------+--------+--------+--------+ 477 Figure 8 UDP ACS option format 479 When present, the ACS always contains a valid CRC checksum. There 480 are no reserved values, including the value of zero. If the CRC is 481 zero, this must indicate a valid checksum (i.e., it does not 482 indicate that the ACS is not used; instead, the option would simply 483 not be included if that were the desired effect). 485 ACS does not protect the UDP pseudoheader; only the current UDP 486 checksum provides that protection (when used). ACS cannot provide 487 that protection because it would need to be updated whenever the UDP 488 pseudoheader changed, e.g., during NAT address and port translation; 489 because this is not the case, ACS does not cover the pseudoheader. 491 5.5. Lite (LITE) 493 The Lite option (LITE) is intended to provide equivalent capability 494 to the UDP Lite transport protocol [RFC3828]. UDP Lite allows the 495 UDP checksum to cover only a prefix of the UDP data payload, to 496 protect critical information (e.g., application headers) but allow 497 potentially erroneous data to be passed to the user. This feature 498 helps protect application headers but allows for application data 499 errors. Some applications are impacted more by a lack of data than 500 errors in data, e.g., voice and video. 502 >> When LITE is active, it MUST come first in the UDP options list. 504 LITE is intended to support the same API as for UDP Lite to allow 505 applications to send and receive data that has a marker indicating 506 the portion protected by the UDP checksum and the portion not 507 protected by the UDP checksum. 509 LITE includes a 2-byte offset that indicates the length of the 510 portion of the UDP data that is not covered by the UDP checksum. 512 +--------+--------+--------+--------+ 513 | Kind=4 | Len=4 | Offset | 514 +--------+--------+--------+--------+ 516 Figure 9 UDP LITE option format 518 At the sender, the option is formed using the following steps: 520 1. Create a LITE option, ordered as the first UDP option (Figure 521 10). 523 2. Calculate the location of the start of the options as an absolute 524 offset from the start of the UDP header and place that length in 525 the last two bytes of the LITE option. 527 3. If the LITE data area is 4 bytes or longer, swap all four bytes 528 of the LITE option with the first 4 bytes of the LITE data area 529 (Figure 11). If the LITE data area is 0-3 bytes long, slide the 530 LITE option to the front of the LITE data area (i.e., placing the 531 0-3 bytes of LITE data after the LITE option). 533 +---------+--------------+--------------+------------------+ 534 | UDP Hdr | user data | LITE data |LITE| other opts | 535 +---------+--------------+--------------+------------------+ 536 <----------------------> 537 UDP Length 539 Figure 10 LITE option formation - LITE goes first 541 +---------+--------------+--------------+------------------+ 542 | UDP Hdr | user data | LITE data |LITE| other opts | 543 +---------+--------------+--------------+------------------+ 544 ^^^^ ^^^^ 545 | | 546 +--------------+ 548 Figure 11 Before sending swap LITE option and front of LITE data 550 The resulting packet has the format shown in Figure 12. Note that 551 the UDP length now points to the LITE option, and the LITE option 552 points to the start of the option area. 554 +---------+--------------+----------------+------------------+ 555 | UDP Hdr | user data |LITE| LITE data |Ldat| other opts | 556 +---------+--------------+----------------+------------------+ 557 <----------------------> | ^ 558 UDP Length +-------------+ 560 Figure 12 Lite option as sent 562 A legacy endpoint receiving this packet will discard the LITE option 563 and everything that follows, including the lite data and remainder 564 of the UDP options. The UDP checksum will protect only the user 565 data, not the LITE option or lite data. 567 Receiving endpoints capable of processing UDP options will do the 568 following: 570 1. Process options as usual. This will start at the LITE option. 572 2. When the LITE option is encountered, record its location as the 573 start of the LITE data area and (if the LITE offset indicates a 574 LITE data length of at least 4 bytes) swap the four bytes there 575 with the four bytes at the location indicated inside the LITE 576 option, which indicates the start of all of the options, 577 including the LITE one (one past the end of the lite data area). 578 If the LITE offset indicates a LITE data area of 0-3 bytes, then 579 slide the LITE option forward that amount and slide the 580 corresponding bytes after the LITE option to where the LITE 581 option originally began. In either case, this restores the format 582 of the option as it was prior to being sent, as per Figure 10. 584 3. Continue processing the remainder of the options, which are now 585 in the format shown in Figure 11. 587 The purpose of this swap (or slide) is to support the equivalent of 588 UDP Lite operation together with other UDP options without requiring 589 the entire LITE data area to be moved after the UDP option area. 591 5.6. Maximum Segment Size (MSS) 593 The Maximum Segment Size (MSS, Kind = 3) is a 16-bit indicator of 594 the largest UDP segment that can be received. As with the TCP MSS 595 option [RFC793], the size indicated is the IP layer MTU decreased by 596 the fixed IP and UDP headers only [RFC6691]. The space needed for IP 597 and UDP options need to be adjusted by the sender when using the 598 value indicated. The value transmitted is based on EMTU_R, the 599 largest IP datagram that can be received (i.e., reassembled at the 600 receiver) [RFC1122]. 602 +--------+--------+--------+--------+ 603 | Kind=5 | Len=4 | MSS size | 604 +--------+--------+--------+--------+ 606 Figure 13 UDP MSS option format 608 The UDP MSS option MAY be used for path MTU discovery 609 [RFC1191][RFC8201], but this may be difficult because of known 610 issues with ICMP blocking [RFC2923] as well as UDP lacking automatic 611 retransmission. It is more likely to be useful when coupled with IP 612 source fragmentation to limit the largest reassembled UDP message, 613 e.g., when EMTU_R is larger than the required minimums (576 for IPv4 614 [RFC791] and 1500 for IPv6 [RFC8200]). 616 5.7. Fragmentation (FRAG) 618 The Fragmentation option (FRAG) supports UDP fragmentation and 619 reassembly, which can be used to transfer UDP messages larger than 620 limited by the IP receive MTU (EMTU_R [RFC1122]). It is typically 621 used with the UDP MSS option to enable more efficient use of large 622 messages, both at the UDP and IP layers. FRAG is designed similar to 623 the IPv6 Fragmentation Header [RFC8200], except that the UDP variant 624 uses a 16-bit Offset measured in bytes, rather than IPv6's 13-bit 625 Fragment Offset measured in 8-byte units. This UDP variant avoids 626 creating reserved fields. 628 +--------+--------+--------+--------+ 629 | Kind=6 | Len=8 | Frag. Offset | 630 +--------+--------+--------+--------+ 631 | Identification | 632 +--------+--------+--------+--------+ 634 Figure 14 UDP non-terminal FRAG option format 636 The FRAG option also lacks a "more" bit, zeroed for the terminal 637 fragment of a set. This is possible because the terminal FRAG option 638 is indicated as a longer, 10-byte variant, which includes an 639 Internet checksum over the entire reassembled UDP payload (omitting 640 the IP pseudoheader and UDP header, as well as UDP options), as 641 shown in Figure 15. 643 >> The reassembly checksum SHOULD be used, but MAY be unused in the 644 same situations when the UDP checksum is unused (e.g., for transit 645 tunnels or applications that have their own integrity checks 646 [RFC8200]), and by the same mechanism (set the field to 0x0000). 648 +--------+--------+--------+--------+ 649 | Kind=6 | Len=10 | Frag. Offset | 650 +--------+--------+--------+--------+ 651 | Identification | 652 +--------+--------+--------+--------+ 653 | Checksum | 654 +--------+--------+ 656 Figure 15 UDP terminal FRAG option format 658 >> During fragmentation, the UDP header checksum of each fragment 659 needs to be recomputed based on each datagram's pseudoheader. 661 >> After reassembly is complete and validated using the checksum of 662 the terminal FRAG option, the UDP header checksum of the resulting 663 datagram needs to be recomputed based on the datagram's 664 pseudoheader. 666 The Fragment Offset is 16 bits and indicates the location of the UDP 667 payload fragment in bytes from the beginning of the original 668 unfragmented payload. The Len field indicates whether there are more 669 fragments (Len=8) or no more fragments (Len=12). 671 >> The Identification field is a 32-bit value that MUST be unique 672 over the expected fragment reassembly timeout. 674 >> The Identification field SHOULD be generated in a manner similar 675 to that of the IPv6 Fragment ID [RFC8200]. 677 >> UDP fragments MUST NOT overlap. 679 FRAG needs to be used with extreme care because it will present 680 incorrect datagram boundaries to a legacy receiver, unless encoded 681 as LITE data (see Section 5.8). 683 >> A host SHOULD indicate FRAG support by transmitting an 684 unfragmented datagram using the Fragmentation option (e.g., with 685 Offset zero and length 12, i.e., including the checksum area), 686 except when encoded as LITE. 688 >> A host MUST NOT transmit a UDP fragment before receiving recent 689 confirmation from the remote host, except when FRAG is encoded as 690 LITE. 692 UDP fragmentation relies on a fragment expiration timer, which can 693 be preset or could use a value computed using the UDP Timestamp 694 option. 696 >> The default UDP reassembly SHOULD be no more than 2 minutes. 698 Implementers are advised to limit the space available for UDP 699 reassembly. 701 >> UDP reassembly space SHOULD be limited to reduce the impact of 702 DOS attacks on resource use. 704 >> UDP reassembly space limits SHOULD NOT be implemented as an 705 aggregate, to avoid cross-socketpair DOS attacks. 707 >> Individual UDP fragments MUST NOT be forwarded to the user. The 708 reassembled datagram is received only after complete reassembly, 709 checksum validation, and continued processing of the remaining 710 options. 712 Any additional UDP options would follow the FRAG option in the final 713 fragment, and would be included in the reassembled packet. 714 Processing of those options would commence after reassembly. 716 >> UDP options MUST NOT follow the FRAG header in non-terminal 717 fragments. Any data following the FRAG header in non-terminal 718 fragments MUST be silently dropped. All other options that apply to 719 a reassembled packet MUST follow the FRAG header in the terminal 720 fragment. 722 5.8. Coupling FRAG with LITE 724 FRAG can be coupled with LITE to avoid impacting legacy receivers. 725 Each fragment is sent as LITE un-checksummed data, where each UDP 726 packet contains no legacy-compatible data. Legacy receivers 727 interpret these as zero-length payload packets (i.e., UDP Length 728 field is 8, the length of just the UDP header), which would not 729 affect the receiver unless the presence of the packet itself were a 730 signal. The header of such a packet would appear as shown in Figure 731 16 and Figure 17. 733 +---------+--------------+---------+ 734 | UDP Hdr | LiteFrag |LITE|FRAG| 735 +---------+--------------+----+----+ 736 <-------> ^^^^ ^^^^ 737 UDP Length=8 | | 738 +--------------+ 740 Figure 16 Preparing FRAG as Lite data 742 +---------+--------------+----+ 743 | UDP Hdr |LITE|LiteFrag |FRAG| 744 +---------+--------------+----+ 745 <-------> | ^ 746 UDP Length=8 | | 747 +-------------+ 749 Figure 17 Lite option before transmission 751 When a packet is reassembled, it appears as a complete LITE data 752 region. The UDP header of the reassembled packet is adjusted 753 accordingly, so that the reassembled region now appears as 754 conventional UDP user data, and processing of the UDP options 755 continues, as with the non-LITE FRAG variant. 757 5.9. Timestamps (TIME) 759 The UDP Timestamp option (TIME) exchanges two four-byte timestamp 760 fields. It serves a similar purpose to TCP's TS option [RFC7323], 761 enabling UDP to estimate the round trip time (RTT) between hosts. 762 For UDP, this RTT can be useful for establishing UDP fragment 763 reassembly timeouts or transport-layer rate-limiting [RFC8085]. 765 +--------+--------+------------------+------------------+ 766 | Kind=7 | Len=10 | TSval | TSecr | 767 +--------+--------+------------------+------------------+ 768 1 byte 1 byte 4 bytes 4 bytes 770 Figure 18 UDP TIME option format 772 TS Value (TSval) and TS Echo Reply (TSecr) are used in a similar 773 manner to the TCP TS option [RFC7323]. On transmitted segments using 774 the option, TS Value is always set based on the local "time" value. 775 Received TSval and TSecr values are provided to the application, 776 which can pass the TSval value to be used as TSecr on UDP messages 777 sent in response (i.e., to echo the received TSval). A received 778 TSecr of zero indicates that the TSval was not echoed by the 779 transmitter, i.e., from a previously received UDP packet. 781 >> TIME MAY use an RTT estimate based on nonzero Timestamp values as 782 a hint for fragmentation reassembly, rate limiting, or other 783 mechanisms that benefit from such an estimate. 785 >> TIME SHOULD make this RTT estimate available to the user 786 application. 788 UDP timestamps are modeled after TCP timestamps and have similar 789 expectations. In particular, they are expected to be: 791 o Values are monotonic and non-decreasing 793 o Values should increase according to a typical 'tick' time 795 o A request is defined as "reply=0" and a reply is defined as both 796 fields being non-zero. 798 o A receiver should always respond to a request with the highest 799 TSval received, which is not necessarily the most recently 800 received. 802 5.10. Authentication and Encryption (AE) 804 The Authentication and Encryption option (AE) is intended to allow 805 UDP to provide a similar type of authentication as the TCP 806 Authentication Option (TCP-AO) [RFC5925]. It uses the same format as 807 specified for TCP-AO, except that it uses a Kind of 8. AE supports 808 NAT traversal in a similar manner as TCP-AO [RFC6978]. AE can also 809 be extended to provide a similar encryption capability as TCP-AO- 810 ENC, in a similar manner [To18ao]. 812 +--------+--------+--------+--------+ 813 | Kind=8 | Len | Digest... | 814 +--------+--------+--------+--------+ 815 | Digest (con't)... | 816 +--------+--------+--------+--------+ 818 Figure 19 UDP AE option format 820 Like TCP-AO, AE is not negotiated in-band. Its use assumes both 821 endpoints have populated Master Key Tuples (MKTs), used to exclude 822 non-protected traffic. 824 TCP-AO generates unique traffic keys from a hash of TCP connection 825 parameters. UDP lacks a three-way handshake to coordinate 826 connection-specific values, such as TCP's Initial Sequence Numbers 827 (ISNs) [RFC793], thus AE's Key Derivation Function (KDF) uses zeroes 828 as the value for both ISNs. This means that the AE reuses keys when 829 socket pairs are reused, unlike TCP-AO. 831 AE can be configured to either include or exclude UDP options, the 832 same way as can TCP-AO. When UDP options are covered, the OCS option 833 area checksum and AE hash areas are zeroed before computing the AE 834 hash. It is important to consider that options not yet defined might 835 yield unpredictable results if not confirmed as supported, e.g., if 836 they were to contain other hashes or checksums that depend on the 837 option area contents. This is why such dependencies are not 838 permitted except as defined for OCS and UDP-AE. 840 Similar to TCP-AO-NAT, AE can be configured to support NAT 841 traversal, excluding one or both of the UDP ports [RFC6978]. 843 6. Echo request (REQ) and echo response (RES) 845 The echo request (REQ, kind=9) and echo response (RES, kind=10) 846 options provide a means for UDP options to be used to provide 847 packet-level acknowledgements. Their use is described as part of the 848 UDP variant of packetization layer path MTU discovery (PLPMTUD) 849 [Fa19]. The options both have the format indicated in Figure 20. 851 +--------+--------+------------------+ 852 | Kind | Len=6 | nonce | 853 +--------+--------+------------------+ 854 1 byte 1 byte 4 bytes 856 Figure 20 UDP REQ and RES options format 858 6.1. Experimental (EXP) 860 The Experimental option (EXP) is reserved for experiments [RFC3692]. 861 It uses a Kind value of 254. Only one such value is reserved because 862 experiments are expected to use an Experimental ID (ExIDs) to 863 differentiate concurrent use for different purposes, using UDP ExIDs 864 registered with IANA according to the approach developed for TCP 865 experimental options [RFC6994]. 867 +----------+----------+----------+----------+ 868 | Kind=254 | Len | UDP ExID | 869 +----------+----------+----------+----------+ 870 | (option contents, as defined)... | 871 +----------+----------+----------+----------+ 873 Figure 21 UDP EXP option format 875 >> The length of the experimental option MUST be at least 4 to 876 account for the Kind, Length, and the minimum 16-bit UDP ExID 877 identifier (similar to TCP ExIDs [RFC6994]). 879 7. Rules for designing new options 881 The UDP option Kind space allows for the definition of new options, 882 however the currently defined options do not allow for arbitrary new 883 options. For example, LITE needs to come first if present; new 884 options cannot declare that they need to precede it. The following 885 is a summary of rules for new options and their rationales: 887 >> New options MUST NOT depend on option space content. Only OCS and 888 AE depend on the content of the options themselves and their order 889 is fixed (on transmission, AE is computed first using a zero- 890 checksum OCS if present, and OCS is computed last before 891 transmission, over the entire option area, including AE). 893 >> New options MUST NOT declare their order relative to other 894 options, whether new or old. 896 >> At the sender, new options MUST NOT modify UDP packet content 897 anywhere except within their option field; areas that need to remain 898 unmodified include the IP header, IP options, the UDP body, the UDP 899 option area (i.e., other options), and the post-option area. 901 >> Options MUST NOT be modified in transit. This includes those 902 already defined as well as new options. New options MUST NOT require 903 or intend optionally for modification of any UDP options, including 904 their new areas, in transit. 906 Note that only certain of the initially defined options violate 907 these rules: 909 o >> LITE MUST be first, if present, and MUST be processed when 910 encountered (e.g., even before security options). 912 o >> LITE is the only option that modifies the UDP body or option 913 areas. 915 o >> OCS SHOULD be the first option, except in the presence of 916 LITE, in which case it SHOULD be the first option after LITE. 918 8. Option inclusion and processing 920 The following rules apply to option inclusion by senders and 921 processing by receivers. 923 >> Senders MAY add any option, as configured by the API. 925 >> All mandatory options MUST be processed by receivers, if present 926 (presuming UDP options are supported at that receiver). 928 >> Non-mandatory options MAY be ignored by receivers, if present, 929 based on API settings. 931 >> All options MUST be processed by receivers in the order 932 encountered in the options list. 934 The basic premise is that the sender decides what options to add and 935 the receiver decides what options to handle. Simply adding an option 936 does not force work upon a receiver, with the exception of the 937 mandatory options. 939 Upon receipt, the receiver checks various properties of the UDP 940 packet and its options to decide whether to accept or drop the 941 packet and whether to accept or ignore some its options as follows 942 (in order): 944 if the UDP checksum fails then 945 silently drop (per RFC1122) 946 if the UDP checksum passes then 947 if OCS is present and fails then 948 deliver the UDP payload but ignore all options 949 (this is required to emulate legacy behavior) 950 if OCS is present and passes then 951 deliver the UDP payload after parsing 952 and processing the rest of the options 954 (for other options 'OPT' when encountered in sequence): 955 if both sender and receiver choose to use OPT then 956 if OPT passes then 957 deliver the UDP payload after parsing 958 and processing the rest of the options 959 if OPT fails then 960 silently drop the packet 961 if OPT is not present when received then 962 silently drop the packet 963 if the sender includes OPT 964 and the receiver does not indicate OPT is required then 965 the receiver accepts all UDP payloads that pass 966 the UDP checksum and indicate for each packet 967 whether OPT succeeded, but never drop when OPT fails 969 I.e., all options other than OCS are treated the same, in that the 970 transmitter can add it as desired and the receiver has the option to 971 require it or not. Only if it is required (by API configuration) 972 should the receiver require it being present and correct. 974 I.e., for all options other than OCS: 976 o if the option is not required by the receiver, then packets 977 missing the option are accepted. 979 o if the option is required and missing or incorrectly formed, 980 silently drop the packet. 982 o if the packet is accepted (either because the option is not 983 required or because it was required and correct), then pass the 984 option with the packet via the API. 986 Any options whose length exceeds that of the UDP packet (i.e., 987 intending to use data that would have been beyond the surplus area) 988 should be silently ignored (again to model legacy behavior). 990 9. UDP API Extensions 992 UDP currently specifies an application programmer interface (API), 993 summarized as follows (with Unix-style command as an example) 994 [RFC768]: 996 o Method to create new receive ports 998 o E.g., bind(handle, recvaddr(optional), recvport) 1000 o Receive, which returns data octets, source port, and source 1001 address 1003 o E.g., recvfrom(handle, srcaddr, srcport, data) 1005 o Send, which specifies data, source and destination addresses, and 1006 source and destination ports 1008 o E.g., sendto(handle, destaddr, destport, data) 1010 This API is extended to support options as follows: 1012 o Extend the method to create receive ports to include receive 1013 options that are required. Datagrams not containing these 1014 required options MUST be silently dropped and MAY be logged. 1016 o Extend the receive function to indicate the options and their 1017 parameters as received with the corresponding received datagram. 1019 o Extend the send function to indicate the options to be added to 1020 the corresponding sent datagram. 1022 Examples of API instances for Linux and FreeBSD are provided in 1023 Appendix A, to encourage uniform cross-platform implementations. 1025 10. Whose options are these? 1027 UDP options are indicated in an area of the IP payload that is not 1028 used by UDP. That area is really part of the IP payload, not the UDP 1029 payload, and as such, it might be tempting to consider whether this 1030 is a generally useful approach to extending IP. 1032 Unfortunately, the surplus area exists only for transports that 1033 include their own transport layer payload length indicator. TCP and 1034 SCTP include header length fields that already provide space for 1035 transport options by indicating the total length of the header area, 1036 such that the entire remaining area indicated in the network layer 1037 (IP) is transport payload. UDP-Lite already uses the UDP Length 1038 field to indicate the boundary between data covered by the transport 1039 checksum and data not covered, and so there is no remaining area 1040 where the length of the UDP-Lite payload as a whole can be indicated 1041 [RFC3828]. 1043 UDP options are intended for use only by the transport endpoints. 1044 They are no more (or less) appropriate to be modified in-transit 1045 than any other portion of the transport datagram. 1047 UDP options are transport options. Generally, transport datagrams 1048 are not intended to be modified in-transit. UDP options are no 1049 exception and here are specified as "MUST NOT" be altered in 1050 transit. However, the UDP option mechanism provides no specific 1051 protection against in-transit modification of the UDP header, UDP 1052 payload, or UDP option area, except as provided by the options 1053 selected (e.g., OCS or AE). 1055 11. UDP options LITE option vs. UDP-Lite 1057 UDP-Lite provides partial checksum coverage, so that packets with 1058 errors in some locations can be delivered to the user [RFC3828]. It 1059 uses a different transport protocol number (136) than UDP (17) to 1060 interpret the UDP Length field as the prefix covered by the UDP 1061 checksum. 1063 UDP (protocol 17) already defines the UDP Length field as the limit 1064 of the UDP checksum, but by default also limits the data provided to 1065 the application as that which precedes the UDP Length. A goal of 1066 UDP-Lite is to deliver data beyond UDP Length as a default, which is 1067 why a separate transport protocol number was required. 1069 UDP options do not use or need a separate transport protocol number 1070 because the data beyond the UDP Length offset (surplus data) is not 1071 provided to the application by default. That data is interpreted 1072 exclusively within the UDP transport layer. 1074 The LITE UDP options option supports a similar service to UDP-Lite. 1075 The main difference is that UDP-Lite provides the un-checksummed 1076 user data to the application by default, whereas the LITE UDP option 1077 can safely provide that service only between endpoints that 1078 negotiate that capability in advance. An endpoint that does not 1079 implement UDP options would silently discard this non-checksummed 1080 user data, along with the UDP options as well. 1082 UDP-Lite cannot support UDP options, either as proposed here or in 1083 any other form, because the entire payload of the UDP packet is 1084 already defined as user data and there is no additional field in 1085 which to indicate a separate area for options. The UDP Length field 1086 in UDP-Lite is already used to indicate the boundary between user 1087 data covered by the checksum and user data not covered. 1089 12. Interactions with Legacy Devices 1091 It has always been permissible for the UDP Length to be inconsistent 1092 with the IP transport payload length [RFC768]. Such inconsistency 1093 has been utilized in UDP-Lite using a different transport number. 1094 There are no known systems that use this inconsistency for UDP 1095 [RFC3828]. It is possible that such use might interact with UDP 1096 options, i.e., where legacy systems might generate UDP datagrams 1097 that appear to have UDP options. The UDP OCS provides protection 1098 against such events and is stronger than a static "magic number". 1100 UDP options have been tested as interoperable with Linux, macOS, and 1101 Windows Cygwin, and worked through NAT devices. These systems 1102 successfully delivered only the user data indicated by the UDP 1103 Length field and silently discarded the surplus area. 1105 One reported embedded device passes the entire IP datagram to the 1106 UDP application layer. Although this feature could enable 1107 application-layer UDP option processing, it would require that 1108 conventional UDP user applications examine only the UDP payload. 1109 This feature is also inconsistent with the UDP application interface 1110 [RFC768] [RFC1122]. 1112 It has been reported that Alcatel-Lucent's "Brick" Intrusion 1113 Detection System has a default configuration that interprets 1114 inconsistencies between UDP Length and IP Length as an attack to be 1115 reported. Note that other firewall systems, e.g., CheckPoint, use a 1116 default "relaxed UDP length verification" to avoid falsely 1117 interpreting this inconsistency as an attack. 1119 (TBD: test with UDP checksum offload and UDP fragmentation offload) 1121 13. Options in a Stateless, Unreliable Transport Protocol 1123 There are two ways to interpret options for a stateless, unreliable 1124 protocol -- an option is either local to the message or intended to 1125 affect a stream of messages in a soft-state manner. Either 1126 interpretation is valid for defined UDP options. 1128 It is impossible to know in advance whether an endpoint supports a 1129 UDP option. 1131 >> UDP options MUST allow for silent failure on first receipt. 1133 >> UDP options that rely on soft-state exchange MUST allow for 1134 message reordering and loss. 1136 >> A UDP option MUST be silently optional until confirmed by 1137 exchange with an endpoint. 1139 The above requirements prevent using any option that cannot be 1140 safely ignored unless that capability has been negotiated with an 1141 endpoint in advance for a socket pair. Legacy systems would need to 1142 be able to interpret the transport payload fragments as individual 1143 transport datagrams. 1145 14. UDP Option State Caching 1147 Some TCP connection parameters, stored in the TCP Control Block, can 1148 be usefully shared either among concurrent connections or between 1149 connections in sequence, known as TCP Sharing [RFC2140][To19cb]. 1150 Although UDP is stateless, some of the options proposed herein may 1151 have similar benefit in being shared or cached. We call this UCB 1152 Sharing, or UDP Control Block Sharing, by analogy. 1154 [TBD: extend this section to indicate which options MAY vs. MUST NOT 1155 be shared and how, e.g., along the lines of To19cb] 1157 15. Updates to RFC 768 1159 This document updates RFC 768 as follows: 1161 o This document defines the meaning of the IP payload area beyond 1162 the UDP length but within the IP length. 1164 o This document extends the UDP API to support the use of options. 1166 16. Multicast Considerations 1168 UDP options are primarily intended for unicast use. Using these 1169 options over multicast IP requires careful consideration, e.g., to 1170 ensure that the options used are safe for different endpoints to 1171 interpret differently (e.g., either to support or silently ignore) 1172 or to ensure that all receivers of a multicast group confirm support 1173 for the options in use. 1175 17. Security Considerations 1177 The use of UDP packets with inconsistent IP and UDP Length fields 1178 has the potential to trigger a buffer overflow error if not properly 1179 handled, e.g., if space is allocated based on the smaller field and 1180 copying is based on the larger. However, there have been no reports 1181 of such vulnerability and it would rely on inconsistent use of the 1182 two fields for memory allocation and copying. 1184 UDP options are not covered by DTLS (datagram transport-layer 1185 security). Despite the name, neither TLS [RFC8446] (transport layer 1186 security, for TCP) nor DTLS [RFC6347] (TLS for UDP) protect the 1187 transport layer. Both operate as a shim layer solely on the payload 1188 of transport packets, protecting only their contents. Just as TLS 1189 does not protect the TCP header or its options, DTLS does not 1190 protect the UDP header or the new options introduced by this 1191 document. Transport security is provided in TCP by the TCP 1192 Authentication Option (TCP-AO [RFC5925]) or in UDP by the 1193 Authentication Extension option (Section 5.10). Transport headers 1194 are also protected as payload when using IP security (IPsec) 1195 [RFC4301]. 1197 UDP options use the TLV syntax similar to that of TCP. This syntax 1198 is known to require serial processing and may pose a DOS risk, e.g., 1199 if an attacker adds large numbers of unknown options that must be 1200 parsed in their entirety. Implementations concerned with the 1201 potential for this vulnerability MAY implement only the required 1202 options and MAY also limit processing of TLVs. Because required 1203 options come first and at most once each (with the exception of 1204 NOPs, which should never need to come in sequences of more than 1205 three in a row), this limits their DOS impact. Note that when a 1206 packet's options cannot be processed, it MUST be discarded; the 1207 packet and its options should always share the same fate. 1209 18. IANA Considerations 1211 Upon publication, IANA is hereby requested to create a new registry 1212 for UDP Option Kind numbers, similar to that for TCP Option Kinds. 1213 Initial values of this registry are as listed in Section 5. 1214 Additional values in this registry are to be assigned from the 1215 UNASSIGNED values Section 5 in by IESG Approval or Standards Action 1216 [RFC8126]. Those assignments are subject to the conditions set forth 1217 in this document, particularly (but not limited to) those in Section 1218 7. 1220 Upon publication, IANA is hereby requested to create a new registry 1221 for UDP Experimental Option Experiment Identifiers (UDP ExIDs) for 1222 use in a similar manner as TCP ExIDs [RFC6994]. This registry is 1223 initially empty. Values in this registry are to be assigned by IANA 1224 using first-come, first-served (FCFS) rules [RFC8126]. Options using 1225 these ExIDs are subject to the same conditions as new options, i.e., 1226 they too are subject to the conditions set forth in this document, 1227 particularly (but not limited to) those in Section 7. 1229 19. References 1231 19.1. Normative References 1233 [Fa19] Fairhurst, G., T. Jones, M. Tuexen, I. Ruengeler, T. 1234 Voelker, "Packetization Layer Path MTU Discovery for 1235 Datagram Transports," draft-ietf-tsvwg-datagram-plpmtud, 1236 Feb. 2019. 1238 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1239 Requirement Levels," BCP 14, RFC 2119, March 1997. 1241 [RFC768] Postel, J., "User Datagram Protocol," RFC 768, August 1242 1980. 1244 [RFC791] Postel, J., "Internet Protocol," RFC 791, Sept. 1981. 1246 [RFC1071] Braden, R., D. Borman, C. Partridge, "Computing the 1247 Internet Checksum", RFC 1071, Sep. 1988. 1249 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -- 1250 Communication Layers," RFC 1122, Oct. 1989. 1252 [RFC1662] Simpson, W. Ed., "PPP in HDLC-like Framing," RFC 1662, 1253 Oct. 1994. 1255 19.2. Informative References 1257 [Fa18] Fairhurst, G., T. Jones, R. Zullo, "Checksum Compensation 1258 Options for UDP Options", draft-fairhurst-udp-options-cco, 1259 Oct. 2018. 1261 [Hi15] Hildebrand, J., B. Trammel, "Substrate Protocol for User 1262 Datagrams (SPUD) Prototype," draft-hildebrand-spud- 1263 prototype-03, Mar. 2015. 1265 [RFC793] Postel, J., "Transmission Control Protocol" RFC 793, 1266 September 1981. 1268 [RFC1191] Mogul, J., S. Deering, "Path MTU discovery," RFC 1191, 1269 November 1990. 1271 [RFC2140] Touch, J., "TCP Control Block Interdependence," RFC 2140, 1272 Apr. 1997. 1274 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery," RFC 1275 2923, September 2000. 1277 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1278 Internet Protocol", RFC 4301, Dec. 2005. 1280 [RFC4340] Kohler, E., M. Handley, and S. Floyd, "Datagram Congestion 1281 Control Protocol (DCCP)", RFC 4340, March 2006. 1283 [RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol", 1284 RFC 4960, September 2007. 1286 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1287 Considered Useful," RFC 3692, Jan. 2004. 1289 [RFC3828] Larzon, L-A., M. Degermark, S. Pink, L-E. Jonsson (Ed.), 1290 G. Fairhurst (Ed.), "The Lightweight User Datagram 1291 Protocol (UDP-Lite)," RFC 3828, July 2004. 1293 [RFC5925] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication 1294 Option," RFC 5925, June 2010. 1296 [RFC6347] Rescorla, E., N. Modadugu, "Datagram Transport Layer 1297 Security Version 1.2," RFC 6347, Jan. 2012. 1299 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)," 1300 RFC 6691, July 2012. 1302 [RFC6978] Touch, J., "A TCP Authentication Option Extension for NAT 1303 Traversal", RFC 6978, July 2013. 1305 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options," RFC 1306 6994, Aug. 2013. 1308 [RFC7323] Borman, D., R. Braden, V. Jacobson, R. Scheffenegger 1309 (Ed.), "TCP Extensions for High Performance," RFC 7323, 1310 Sep. 2014. 1312 [RFC8085] Eggert, L., G. Fairhurst, G. Shepherd, "UDP Usage 1313 Guidelines," RFC 8085, Feb. 2017. 1315 [RFC8126] Cotton, M., B. Leiba, T. Narten, "Guidelines for Writing 1316 an IANA Considerations Section in RFCs," RFC 8126, June 1317 2017. 1319 [RFC8200] Deering, S., R. Hinden, "Internet Protocol Version 6 1320 (IPv6) Specification," RFC 8200, Jul. 2017. 1322 [RFC8201] McCann, J., S. Deering, J. Mogul, R. Hinden (Ed.), "Path 1323 MTU Discovery for IP version 6," RFC 8201, Jul. 2017. 1325 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1326 Version 1.3," RFC 8446, Aug. 2018. 1328 [To18ao] Touch, J., "A TCP Authentication Option Extension for 1329 Payload Encryption," draft-touch-tcp-ao-encrypt, Jul. 1330 2018. 1332 [To19cb] Touch, J., M. Welzl, S. Islam, J. You, "TCP Control Block 1333 Interdependence," draft-touch-tcpm-2140bis, Jan. 2019. 1335 [Tr16] Trammel, B. (Ed.), M. Kuelewind (Ed.), "Requirements for 1336 the design of a Substrate Protocol for User Datagrams 1337 (SPUD)," draft-trammell-spud-req-04, May 2016. 1339 20. Acknowledgments 1341 This work benefitted from feedback from Bob Briscoe, Ken Calvert, 1342 Ted Faber, Gorry Fairhurst, C. M. Heard (including the FRAG/LITE 1343 combination), Tom Herbert, and Mark Smith, as well as discussions on 1344 the IETF TSVWG and SPUD email lists. 1346 This work was partly supported by USC/ISI's Postel Center. 1348 This document was prepared using 2-Word-v2.0.template.dot. 1350 Authors' Addresses 1352 Joe Touch 1353 Manhattan Beach, CA 90266 USA 1355 Phone: +1 (310) 560-0334 1356 Email: touch@strayalpha.com 1358 Appendix A. Implementation Information 1360 The following information is provided to encourage interoperable API 1361 implementations. 1363 System-level variables (sysctl): 1365 Name default meaning 1366 ---------------------------------------------------- 1367 net.ipv4.udp_opt 0 UDP options available 1368 net.ipv4.udp_opt_ocs 1 Default include OCS 1369 net.ipv4.udp_opt_acs 0 Default include ACS 1370 net.ipv4.udp_opt_lite 0 Default include LITE 1371 net.ipv4.udp_opt_mss 0 Default include MSS 1372 net.ipv4.udp_opt_time 0 Default include TIME 1373 net.ipv4.udp_opt_frag 0 Default include FRAG 1374 net.ipv4.udp_opt_ae 0 Default include AE 1376 Socket options (sockopt), cached for outgoing datagrams: 1378 Name meaning 1379 ---------------------------------------------------- 1380 UDP_OPT Enable UDP options (at all) 1381 UDP_OPT_OCS Enable UDP OCS option 1382 UDP_OPT_ACS Enable UDP ACS option 1383 UDP_OPT_LITE Enable UDP LITE option 1384 UDP_OPT_MSS Enable UDP MSS option 1385 UDP_OPT_TIME Enable UDP TIME option 1386 UDP_OPT_FRAG Enable UDP FRAG option 1387 UDP_OPT_AE Enable UDP AE option 1389 Send/sendto parameters: 1391 (TBD - currently using cached parameters) 1393 Connection parameters (per-socketpair cached state, part UCB): 1395 Name Initial value 1396 ---------------------------------------------------- 1397 opts_enabled net.ipv4.udp_opt 1398 ocs_enabled net.ipv4.udp_opt_ocs 1400 The following option is included for debugging purposes, and MUST 1401 NOT be enabled otherwise. 1403 System variables 1404 net.ipv4.udp_opt_junk 0 1406 System-level variables (sysctl): 1408 Name default meaning 1409 ---------------------------------------------------- 1410 net.ipv4.udp_opt_junk 0 Default use of junk 1412 Socket options (sockopt): 1414 Name params meaning 1415 ------------------------------------------------------ 1416 UDP_JUNK - Enable UDP junk option 1417 UDP_JUNK_VAL fillval Value to use as junk fill 1418 UDP_JUNK_LEN length Length of junk payload in bytes 1420 Connection parameters (per-socketpair cached state, part UCB): 1422 Name Initial value 1423 ---------------------------------------------------- 1424 junk_enabled net.ipv4.udp_opt_junk 1425 junk_value 0xABCD 1426 junk_len 4