idnits 2.17.1 draft-ietf-tsvwg-udp-options-06.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 1341 has weird spacing: '...default mean...' == Line 1373 has weird spacing: '...enabled net.i...' == Line 1374 has weird spacing: '...enabled net....' == Line 1384 has weird spacing: '...default mean...' == Line 1390 has weird spacing: '... params mean...' == (1 more instance...) -- The document date (March 5, 2019) is 1872 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) Summary: 0 errors (**), 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 5, 2019 4 Intended updates: 768 5 Expires: September 2019 7 Transport Options for UDP 8 draft-ietf-tsvwg-udp-options-06.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 5, 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).................................10 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...............................19 77 8. Option inclusion and processing...............................20 78 9. UDP API Extensions............................................22 79 10. Whose options are these?.....................................22 80 11. UDP options LITE option vs. UDP-Lite.........................23 81 12. Interactions with Legacy Devices.............................24 82 13. Options in a Stateless, Unreliable Transport Protocol........24 83 14. UDP Option State Caching.....................................25 84 15. Updates to RFC 768...........................................25 85 16. Multicast Considerations.....................................25 86 17. Security Considerations......................................26 87 18. IANA Considerations..........................................26 88 19. References...................................................27 89 19.1. Normative References....................................27 90 19.2. Informative References..................................27 91 20. Acknowledgments..............................................29 92 Appendix A. Implementation Information...........................30 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 ones-complement of the 8-bit 404 ones-complement checksum (i.e., Internet checksum) sum of the 405 options area. OCS protects the option area from errors in a similar 406 way that the UDP checksum protects the UDP user data (when not 407 zero). 409 +--------+--------+ 410 | Kind=2 |checksum| 411 +--------+--------+ 413 Figure 7 UDP OCS option format 415 >> When present, the option checksum SHOULD occur as early as 416 possible, preferably preceded by only NOP options for alignment and 417 the LITE option if present. 419 >> OCS SHOULD be half-word aligned to the start of the UDP packet. 420 This is to help ensure that the option, together with the other 421 options, result in an overall zero ones-complement sum, which may 422 help the UDP options traverse devices that incorrectly attempt to 423 checksum the surplus area (as originally proposed as the Checksum 424 Compensation Option [Fa18]). 426 OCS covers the UDP option area, including the Lite option as 427 formatted before swapping (or relocation) for transmission (or, 428 equivalently, after the swap/relocation after reception). 430 >> If the option checksum fails, all options MUST be ignored and any 431 trailing surplus data (and Lite data, if used) silently discarded. 433 >> UDP data that is validated by a correct UDP checksum MUST be 434 delivered to the application layer, even if the UDP option checksum 435 fails, unless the endpoints have negotiated otherwise for this 436 segment's socket pair. 438 Note that use of the UDP checksum is optional. When not used, the 439 field is zero, where it is also assumed to be "correct" for these 440 purposes. 442 Note also that OCS is intended to check for accidental errors, not 443 for attacks. 445 5.4. Alternate Checksum (ACS) 447 The Alternate Checksum (ACS) provides a stronger alternative to the 448 checksum in the UDP header, using a 16-bit CRC of the conventional 449 UDP payload only (excluding the IP pseudoheader, UDP header, and UDP 450 options, and not include the LITE area). Because it does not include 451 the IP pseudoheader or UDP header, it need not be updated by NATs 452 when IP addresses or UDP ports are rewritten. Its purpose is to 453 detect errors that the UDP checksum, when used, might not detect. 455 CRC-CCITT (polynomial x^16 + x^12 + x^5 + 1) has been chosen because 456 of its ubiquity and use in other packet protocols, such as X.25, 457 HDLC, and Bluetooth. The option contains FCS-16 as defined in 458 Appendix C of [RFC1662], except that it is not inverted in the final 459 step and that it is stored in the ACS option in network byte order. 461 +--------+--------+--------+--------+ 462 | Kind=3 | Len=4 | CRC16sum | 463 +--------+--------+--------+--------+ 465 Figure 8 UDP ACS option format 467 When present, the ACS always contains a valid CRC checksum. There 468 are no reserved values, including the value of zero. If the CRC is 469 zero, this must indicate a valid checksum (i.e., it does not 470 indicate that the ACS is not used; instead, the option would simply 471 not be included if that were the desired effect). 473 ACS does not protect the UDP pseudoheader; only the current UDP 474 checksum provides that protection (when used). ACS cannot provide 475 that protection because it would need to be updated whenever the UDP 476 pseudoheader changed, e.g., during NAT address and port translation; 477 because this is not the case, ACS does not cover the pseudoheader. 479 5.5. Lite (LITE) 481 The Lite option (LITE) is intended to provide equivalent capability 482 to the UDP Lite transport protocol [RFC3828]. UDP Lite allows the 483 UDP checksum to cover only a prefix of the UDP data payload, to 484 protect critical information (e.g., application headers) but allow 485 potentially erroneous data to be passed to the user. This feature 486 helps protect application headers but allows for application data 487 errors. Some applications are impacted more by a lack of data than 488 errors in data, e.g., voice and video. 490 >> When LITE is active, it MUST come first in the UDP options list. 492 LITE is intended to support the same API as for UDP Lite to allow 493 applications to send and receive data that has a marker indicating 494 the portion protected by the UDP checksum and the portion not 495 protected by the UDP checksum. 497 LITE includes a 2-byte offset that indicates the length of the 498 portion of the UDP data that is not covered by the UDP checksum. 500 +--------+--------+--------+--------+ 501 | Kind=4 | Len=4 | Offset | 502 +--------+--------+--------+--------+ 504 Figure 9 UDP LITE option format 506 At the sender, the option is formed using the following steps: 508 1. Create a LITE option, ordered as the first UDP option (Figure 509 10). 511 2. Calculate the location of the start of the options as an absolute 512 offset from the start of the UDP header and place that length in 513 the last two bytes of the LITE option. 515 3. If the LITE data area is 4 bytes or longer, swap all four bytes 516 of the LITE option with the first 4 bytes of the LITE data area 517 (Figure 11). If the LITE data area is 0-3 bytes long, slide the 518 LITE option to the front of the LITE data area (i.e., placing the 519 0-3 bytes of LITE data after the LITE option). 521 +---------+--------------+--------------+------------------+ 522 | UDP Hdr | user data | LITE data |LITE| other opts | 523 +---------+--------------+--------------+------------------+ 524 <----------------------> 525 UDP Length 527 Figure 10 LITE option formation - LITE goes first 529 +---------+--------------+--------------+------------------+ 530 | UDP Hdr | user data | LITE data |LITE| other opts | 531 +---------+--------------+--------------+------------------+ 532 ^^^^ ^^^^ 533 | | 534 +--------------+ 536 Figure 11 Before sending swap LITE option and front of LITE data 538 The resulting packet has the format shown in Figure 12. Note that 539 the UDP length now points to the LITE option, and the LITE option 540 points to the start of the option area. 542 +---------+--------------+----------------+------------------+ 543 | UDP Hdr | user data |LITE| LITE data |Ldat| other opts | 544 +---------+--------------+----------------+------------------+ 545 <----------------------> | ^ 546 UDP Length +-------------+ 548 Figure 12 Lite option as sent 550 A legacy endpoint receiving this packet will discard the LITE option 551 and everything that follows, including the lite data and remainder 552 of the UDP options. The UDP checksum will protect only the user 553 data, not the LITE option or lite data. 555 Receiving endpoints capable of processing UDP options will do the 556 following: 558 1. Process options as usual. This will start at the LITE option. 560 2. When the LITE option is encountered, record its location as the 561 start of the LITE data area and (if the LITE offset indicates a 562 LITE data length of at least 4 bytes) swap the four bytes there 563 with the four bytes at the location indicated inside the LITE 564 option, which indicates the start of all of the options, 565 including the LITE one (one past the end of the lite data area). 566 If the LITE offset indicates a LITE data area of 0-3 bytes, then 567 slide the LITE option forward that amount and slide the 568 corresponding bytes after the LITE option to where the LITE 569 option originally began. In either case, this restores the format 570 of the option as it was prior to being sent, as per Figure 10. 572 3. Continue processing the remainder of the options, which are now 573 in the format shown in Figure 11. 575 The purpose of this swap (or slide) is to support the equivalent of 576 UDP Lite operation together with other UDP options without requiring 577 the entire LITE data area to be moved after the UDP option area. 579 5.6. Maximum Segment Size (MSS) 581 The Maximum Segment Size (MSS, Kind = 3) is a 16-bit indicator of 582 the largest UDP segment that can be received. As with the TCP MSS 583 option [RFC793], the size indicated is the IP layer MTU decreased by 584 the fixed IP and UDP headers only [RFC6691]. The space needed for IP 585 and UDP options need to be adjusted by the sender when using the 586 value indicated. The value transmitted is based on EMTU_R, the 587 largest IP datagram that can be received (i.e., reassembled at the 588 receiver) [RFC1122]. 590 +--------+--------+--------+--------+ 591 | Kind=5 | Len=4 | MSS size | 592 +--------+--------+--------+--------+ 594 Figure 13 UDP MSS option format 596 The UDP MSS option MAY be used for path MTU discovery 597 [RFC1191][RFC8201], but this may be difficult because of known 598 issues with ICMP blocking [RFC2923] as well as UDP lacking automatic 599 retransmission. It is more likely to be useful when coupled with IP 600 source fragmentation to limit the largest reassembled UDP message, 601 e.g., when EMTU_R is larger than the required minimums (576 for IPv4 602 [RFC791] and 1500 for IPv6 [RFC8200]). 604 5.7. Fragmentation (FRAG) 606 The Fragmentation option (FRAG) supports UDP fragmentation and 607 reassembly, which can be used to transfer UDP messages larger than 608 limited by the IP receive MTU (EMTU_R [RFC1122]). It is typically 609 used with the UDP MSS option to enable more efficient use of large 610 messages, both at the UDP and IP layers. FRAG is designed similar to 611 the IPv6 Fragmentation Header [RFC8200], except that the UDP variant 612 uses a 16-bit Offset measured in bytes, rather than IPv6's 13-bit 613 Fragment Offset measured in 8-byte units. This UDP variant avoids 614 creating reserved fields. 616 +--------+--------+--------+--------+ 617 | Kind=6 | Len=8 | Frag. Offset | 618 +--------+--------+--------+--------+ 619 | Identification | 620 +--------+--------+--------+--------+ 622 Figure 14 UDP non-terminal FRAG option format 624 The FRAG option also lacks a "more" bit, zeroed for the terminal 625 fragment of a set. This is possible because the terminal FRAG option 626 is indicated as a longer, 10-byte variant, which includes an 627 Internet checksum over the entire reassembled UDP payload (omitting 628 the IP pseudoheader and UDP header, as well as UDP options), as 629 shown in Figure 15. 631 >> The reassembly checksum SHOULD be used, but MAY be unused in the 632 same situations when the UDP checksum is unused (e.g., for transit 633 tunnels or applications that have their own integrity checks 634 [RFC8200]), and by the same mechanism (set the field to 0x0000). 636 +--------+--------+--------+--------+ 637 | Kind=6 | Len=10 | Frag. Offset | 638 +--------+--------+--------+--------+ 639 | Identification | 640 +--------+--------+--------+--------+ 641 | Checksum | 642 +--------+--------+ 644 Figure 15 UDP terminal FRAG option format 646 >> During fragmentation, the UDP header checksum of each fragment 647 needs to be recomputed based on each datagram's pseudoheader. 649 >> After reassembly is complete and validated using the checksum of 650 the terminal FRAG option, the UDP header checksum of the resulting 651 datagram needs to be recomputed based on the datagram's 652 pseudoheader. 654 The Fragment Offset is 16 bits and indicates the location of the UDP 655 payload fragment in bytes from the beginning of the original 656 unfragmented payload. The Len field indicates whether there are more 657 fragments (Len=8) or no more fragments (Len=12). 659 >> The Identification field is a 32-bit value that MUST be unique 660 over the expected fragment reassembly timeout. 662 >> The Identification field SHOULD be generated in a manner similar 663 to that of the IPv6 Fragment ID [RFC8200]. 665 >> UDP fragments MUST NOT overlap. 667 FRAG needs to be used with extreme care because it will present 668 incorrect datagram boundaries to a legacy receiver, unless encoded 669 as LITE data (see Section 5.8). 671 >> A host SHOULD indicate FRAG support by transmitting an 672 unfragmented datagram using the Fragmentation option (e.g., with 673 Offset zero and length 12, i.e., including the checksum area), 674 except when encoded as LITE. 676 >> A host MUST NOT transmit a UDP fragment before receiving recent 677 confirmation from the remote host, except when FRAG is encoded as 678 LITE. 680 UDP fragmentation relies on a fragment expiration timer, which can 681 be preset or could use a value computed using the UDP Timestamp 682 option. 684 >> The default UDP reassembly SHOULD be no more than 2 minutes. 686 Implementers are advised to limit the space available for UDP 687 reassembly. 689 >> UDP reassembly space SHOULD be limited to reduce the impact of 690 DOS attacks on resource use. 692 >> UDP reassembly space limits SHOULD NOT be implemented as an 693 aggregate, to avoid cross-socketpair DOS attacks. 695 >> Individual UDP fragments MUST NOT be forwarded to the user. The 696 reassembled datagram is received only after complete reassembly, 697 checksum validation, and continued processing of the remaining 698 options. 700 Any additional UDP options would follow the FRAG option in the final 701 fragment, and would be included in the reassembled packet. 702 Processing of those options would commence after reassembly. 704 >> UDP options MUST NOT follow the FRAG header in non-terminal 705 fragments. Any data following the FRAG header in non-terminal 706 fragments MUST be silently dropped. All other options that apply to 707 a reassembled packet MUST follow the FRAG header in the terminal 708 fragment. 710 5.8. Coupling FRAG with LITE 712 FRAG can be coupled with LITE to avoid impacting legacy receivers. 713 Each fragment is sent as LITE un-checksummed data, where each UDP 714 packet contains no legacy-compatible data. Legacy receivers 715 interpret these as zero-length payload packets (i.e., UDP Length 716 field is 8, the length of just the UDP header), which would not 717 affect the receiver unless the presence of the packet itself were a 718 signal. The header of such a packet would appear as shown in Figure 719 16 and Figure 17. 721 +---------+--------------+---------+ 722 | UDP Hdr | LiteFrag |LITE|FRAG| 723 +---------+--------------+----+----+ 724 <-------> ^^^^ ^^^^ 725 UDP Length=8 | | 726 +--------------+ 728 Figure 16 Preparing FRAG as Lite data 730 +---------+--------------+----+ 731 | UDP Hdr |LITE|LiteFrag |FRAG| 732 +---------+--------------+----+ 733 <-------> | ^ 734 UDP Length=8 | | 735 +-------------+ 737 Figure 17 Lite option before transmission 739 When a packet is reassembled, it appears as a complete LITE data 740 region. The UDP header of the reassembled packet is adjusted 741 accordingly, so that the reassembled region now appears as 742 conventional UDP user data, and processing of the UDP options 743 continues, as with the non-LITE FRAG variant. 745 5.9. Timestamps (TIME) 747 The UDP Timestamp option (TIME) exchanges two four-byte timestamp 748 fields. It serves a similar purpose to TCP's TS option [RFC7323], 749 enabling UDP to estimate the round trip time (RTT) between hosts. 750 For UDP, this RTT can be useful for establishing UDP fragment 751 reassembly timeouts or transport-layer rate-limiting [RFC8085]. 753 +--------+--------+------------------+------------------+ 754 | Kind=7 | Len=10 | TSval | TSecr | 755 +--------+--------+------------------+------------------+ 756 1 byte 1 byte 4 bytes 4 bytes 758 Figure 18 UDP TIME option format 760 TS Value (TSval) and TS Echo Reply (TSecr) are used in a similar 761 manner to the TCP TS option [RFC7323]. On transmitted segments using 762 the option, TS Value is always set based on the local "time" value. 763 Received TSval and TSecr values are provided to the application, 764 which can pass the TSval value to be used as TSecr on UDP messages 765 sent in response (i.e., to echo the received TSval). A received 766 TSecr of zero indicates that the TSval was not echoed by the 767 transmitter, i.e., from a previously received UDP packet. 769 >> UDP MAY use an RTT estimate based on nonzero Timestamp values as 770 a hint for fragmentation reassembly, rate limiting, or other 771 mechanisms that benefit from such an estimate. 773 >> UDP SHOULD make this RTT estimate available to the user 774 application. 776 These UDP timestamps are modeled after TCP timestamps and have 777 similar expectations. In particular, they are expected to be: 779 o Values are monotonic and non-decreasing 781 o Values should increase according to a typical 'tick' time 783 o A request is defined as "reply=0" and a reply is defined as both 784 fields being non-zero. 786 o A receiver should always respond to a request with the highest 787 TSval received, which is not necessarily the most recently 788 received. 790 5.10. Authentication and Encryption (AE) 792 The Authentication and Encryption option (AE) is intended to allow 793 UDP to provide a similar type of authentication as the TCP 794 Authentication Option (TCP-AO) [RFC5925]. It uses the same format as 795 specified for TCP-AO, except that it uses a Kind of 8. UDP-AO 796 supports NAT traversal in a similar manner as TCP-AO [RFC6978]. UDP- 797 AO can also be extended to provide a similar encryption capability 798 as TCP-AO-ENC, in a similar manner [To18ao]. For these reasons, the 799 option is known as UDP-AE. 801 +--------+--------+--------+--------+ 802 | Kind=8 | Len | Digest... | 803 +--------+--------+--------+--------+ 804 | Digest (con't)... | 805 +--------+--------+--------+--------+ 807 Figure 19 UDP non-terminal FRAG option format 809 Like TCP-AO, UDP-AE is not negotiated in-band. Its use assumes both 810 endpoints have populated Master Key Tuples (MKTs), used to exclude 811 non-protected traffic. 813 TCP-AO generates unique traffic keys from a hash of TCP connection 814 parameters. UDP lacks a three-way handshake to coordinate 815 connection-specific values, such as TCP's Initial Sequence Numbers 816 (ISNs) [RFC793], thus UDP-AE's Key Derivation Function (KDF) uses 817 zeroes as the value for both ISNs. This means that the UDP-AE reuses 818 keys when socket pairs are reused, unlike TCP-AO. 820 UDP-AE can be configured to either include or exclude UDP options, 821 the same way as can TCP-AO. When UDP options are covered, the OCS 822 option area checksum and UDP-AE hash areas are zeroed before 823 computing the UDP-AE hash. It is important to consider that options 824 not yet defined might yield unpredictable results if not confirmed 825 as supported, e.g., if they were to contain other hashes or 826 checksums that depend on the option area contents. This is why such 827 dependencies are not permitted except as defined for OCS and UDP-AE. 829 Similar to TCP-AO-NAT, UDP-AE can be configured to support NAT 830 traversal, excluding one or both of the UDP ports [RFC6978]. 832 6. Echo request (REQ) and echo response (RES) 834 The echo request (REQ, kind=9) and echo response (RES, kind=10) 835 options provide a means for UDP options to be used to provide 836 packet-level acknowledgements. Their use is described as part of the 837 UDP variant of packetization layer path MTU discovery (PLPMTUD) 838 [Fa19]. The options both have the format indicated in Figure 20. 840 +--------+--------+------------------+ 841 | Kind | Len=6 | nonce | 842 +--------+--------+------------------+ 843 1 byte 1 byte 4 bytes 845 Figure 20 Echo option format 847 6.1. Experimental (EXP) 849 The Experimental option (EXP) is reserved for experiments [RFC3692]. 850 It uses a Kind value of 254. Only one such value is reserved because 851 experiments are expected to use an Experimental ID (ExIDs) to 852 differentiate concurrent use for different purposes, using UDP ExIDs 853 registered with IANA according to the approach developed for TCP 854 experimental options [RFC6994]. 856 +----------+----------+----------+----------+ 857 | Kind=254 | Len | UDP ExID | 858 +----------+----------+----------+----------+ 859 | (option contents, as defined)... | 860 +----------+----------+----------+----------+ 862 Figure 21 UDP EXP option format 864 >> The length of the experimental option MUST be at least 4 to 865 account for the Kind, Length, and the minimum 16-bit UDP ExID 866 identifier (similar to TCP ExIDs [RFC6994]). 868 7. Rules for designing new options 870 The UDP option Kind space allows for the definition of new options, 871 however the currently defined options do not allow for arbitrary new 872 options. For example, LITE needs to come first if present; new 873 options cannot declare that they need to precede it. The following 874 is a summary of rules for new options and their rationales: 876 >> New options MUST NOT depend on option space content. Only OCS, 877 ACS, and AE depend on the content of the options themselves, and 878 their order is fixed (on transmission, AE is computed first using a 879 zero-checksum OCS or ACS if present, and OCS or ACS is computed 880 second over the entire option area, including AE). 882 >> New options MUST NOT declare their order relative to other 883 options, whether new or old. 885 >> New options MUST NOT modify content anywhere except within their 886 option field; areas that need to remain unmodified include the IP 887 header, IP options, the UDP body, the UDP option area (i.e., other 888 options), and the post-option area. 890 Note that only certain of the initially defined options violate 891 these rules: 893 o >> LITE MUST be first, if present, and MUST be processed when 894 encountered (e.g., even before security options). 896 o >> LITE is the only option that modifies the UDP body or option 897 areas. 899 o >> OCS or ACS MUST be the first option, except in the presence of 900 LITE, in which case they MUST be the first option after LITE. 902 o >> OCS and ACS MUST be processed by receivers when encountered in 903 the options list. 905 o >> AE MUST be processed by receivers when encountered in the 906 options list. 908 8. Option inclusion and processing 910 The following rules apply to option inclusion by senders and 911 processing by receivers. 913 >> Senders MAY add any option, as configured by the API. 915 >> All mandatory options MUST be processed by receivers, if present 916 (presuming UDP options are supported at that receiver). 918 >> Non-mandatory options MAY be ignored by receivers, if present, 919 based on API settings. 921 The basic premise is that the sender decides what options to add and 922 the receiver decides what options to handle. Simply adding an option 923 does not force work upon a receiver, with the exception of the 924 mandatory options. 926 Upon receipt, the receiver checks various properties of the UDP 927 packet and its options to decide whether to accept or drop the 928 packet and whether to accept or ignore some its options as follows 929 (in order): 931 if the UDP checksum fails then 932 silently drop (per RFC1122) 933 if the UDP checksum passes then 934 if OCS is present and fails then 935 deliver the UDP payload but ignore all options 936 (this is required to emulate legacy behavior) 937 if OCS is present and passes then 938 deliver the UDP payload after parsing 939 and processing the rest of the options 941 if both sender and receiver choose to use ACS then 942 if ACS passes then 943 deliver the UDP payload after parsing 944 and processing the rest of the options 945 if ACS fails then 946 silently drop the packet 947 if ACS is not present when received then 948 silently drop the packet 950 if the sender includes ACS 951 and the receiver does not indicate ACS is required then 952 the receiver accepts all UDP payloads that pass 953 the UDP checksum and indicate for each packet 954 whether ACS succeeded, but never drop when ACS fails 956 I.e., ACS should be treated like any other option, in that the 957 transmitter can add it as desired and the receiver has the option to 958 require it or not. Only if it is required (by API configuration) 959 should the receiver require it being present and correct. 961 I.e., for all options other than OCS: 963 o if the option is not required by the receiver, then packets 964 missing the option are accepted. 966 o if the option is required and missing or incorrectly formed, 967 silently drop the packet. 969 o if the packet is accepted (either because the option is not 970 required or because it was required and correct), then pass the 971 option with the packet via the API. 973 Any options whose length exceeds that of the UDP packet (i.e., 974 intending to use data that would have been beyond the surplus area) 975 should be silently ignored (again to model legacy behavior). 977 9. UDP API Extensions 979 UDP currently specifies an application programmer interface (API), 980 summarized as follows (with Unix-style command as an example) 981 [RFC768]: 983 o Method to create new receive ports 985 o E.g., bind(handle, recvaddr(optional), recvport) 987 o Receive, which returns data octets, source port, and source 988 address 990 o E.g., recvfrom(handle, srcaddr, srcport, data) 992 o Send, which specifies data, source and destination addresses, and 993 source and destination ports 995 o E.g., sendto(handle, destaddr, destport, data) 997 This API is extended to support options as follows: 999 o Extend the method to create receive ports to include receive 1000 options that are required. Datagrams not containing these 1001 required options MUST be silently dropped and MAY be logged. 1003 o Extend the receive function to indicate the options and their 1004 parameters as received with the corresponding received datagram. 1006 o Extend the send function to indicate the options to be added to 1007 the corresponding sent datagram. 1009 Examples of API instances for Linux and FreeBSD are provided in 1010 Appendix A, to encourage uniform cross-platform implementations. 1012 10. Whose options are these? 1014 UDP options are indicated in an area of the IP payload that is not 1015 used by UDP. That area is really part of the IP payload, not the UDP 1016 payload, and as such, it might be tempting to consider whether this 1017 is a generally useful approach to extending IP. 1019 Unfortunately, the surplus area exists only for transports that 1020 include their own transport layer payload length indicator. TCP and 1021 SCTP include header length fields that already provide space for 1022 transport options by indicating the total length of the header area, 1023 such that the entire remaining area indicated in the network layer 1024 (IP) is transport payload. UDP-Lite already uses the UDP Length 1025 field to indicate the boundary between data covered by the transport 1026 checksum and data not covered, and so there is no remaining area 1027 where the length of the UDP-Lite payload as a whole can be indicated 1028 [RFC3828]. 1030 UDP options are intended for use only by the transport endpoints. 1031 They are no more (or less) appropriate to be modified in-transit 1032 than any other portion of the transport datagram. 1034 UDP options are transport options. Generally, transport datagrams 1035 are not intended to be modified in-transit. However, the UDP option 1036 mechanism provides no specific protection against in-transit 1037 modification of the UDP header, UDP payload, or UDP option area, 1038 except as provided by the options selected (e.g., OCS, ACS, or AE). 1040 11. UDP options LITE option vs. UDP-Lite 1042 UDP-Lite provides partial checksum coverage, so that packets with 1043 errors in some locations can be delivered to the user [RFC3828]. It 1044 uses a different transport protocol number (136) than UDP (17) to 1045 interpret the UDP Length field as the prefix covered by the UDP 1046 checksum. 1048 UDP (protocol 17) already defines the UDP Length field as the limit 1049 of the UDP checksum, but by default also limits the data provided to 1050 the application as that which precedes the UDP Length. A goal of 1051 UDP-Lite is to deliver data beyond UDP Length as a default, which is 1052 why a separate transport protocol number was required. 1054 UDP options do not use or need a separate transport protocol number 1055 because the data beyond the UDP Length offset (surplus data) is not 1056 provided to the application by default. That data is interpreted 1057 exclusively within the UDP transport layer. 1059 The LITE UDP options option supports a similar service to UDP-Lite. 1060 The main difference is that UDP-Lite provides the un-checksummed 1061 user data to the application by default, whereas the LITE UDP option 1062 can safely provide that service only between endpoints that 1063 negotiate that capability in advance. An endpoint that does not 1064 implement UDP options would silently discard this non-checksummed 1065 user data, along with the UDP options as well. 1067 UDP-Lite cannot support UDP options, either as proposed here or in 1068 any other form, because the entire payload of the UDP packet is 1069 already defined as user data and there is no additional field in 1070 which to indicate a separate area for options. The UDP Length field 1071 in UDP-Lite is already used to indicate the boundary between user 1072 data covered by the checksum and user data not covered. 1074 12. Interactions with Legacy Devices 1076 It has always been permissible for the UDP Length to be inconsistent 1077 with the IP transport payload length [RFC768]. Such inconsistency 1078 has been utilized in UDP-Lite using a different transport number. 1079 There are no known systems that use this inconsistency for UDP 1080 [RFC3828]. It is possible that such use might interact with UDP 1081 options, i.e., where legacy systems might generate UDP datagrams 1082 that appear to have UDP options. The UDP OCS provides protection 1083 against such events and is stronger than a static "magic number". 1085 UDP options have been tested as interoperable with Linux, macOS, and 1086 Windows Cygwin, and worked through NAT devices. These systems 1087 successfully delivered only the user data indicated by the UDP 1088 Length field and silently discarded the surplus area. 1090 One reported embedded device passes the entire IP datagram to the 1091 UDP application layer. Although this feature could enable 1092 application-layer UDP option processing, it would require that 1093 conventional UDP user applications examine only the UDP payload. 1094 This feature is also inconsistent with the UDP application interface 1095 [RFC768] [RFC1122]. 1097 It has been reported that Alcatel-Lucent's "Brick" Intrusion 1098 Detection System has a default configuration that interprets 1099 inconsistencies between UDP Length and IP Length as an attack to be 1100 reported. Note that other firewall systems, e.g., CheckPoint, use a 1101 default "relaxed UDP length verification" to avoid falsely 1102 interpreting this inconsistency as an attack. 1104 (TBD: test with UDP checksum offload and UDP fragmentation offload) 1106 13. Options in a Stateless, Unreliable Transport Protocol 1108 There are two ways to interpret options for a stateless, unreliable 1109 protocol -- an option is either local to the message or intended to 1110 affect a stream of messages in a soft-state manner. Either 1111 interpretation is valid for defined UDP options. 1113 It is impossible to know in advance whether an endpoint supports a 1114 UDP option. 1116 >> UDP options MUST allow for silent failure on first receipt. 1118 >> UDP options that rely on soft-state exchange MUST allow for 1119 message reordering and loss. 1121 >> A UDP option MUST be silently optional until confirmed by 1122 exchange with an endpoint. 1124 The above requirements prevent using any option that cannot be 1125 safely ignored unless that capability has been negotiated with an 1126 endpoint in advance for a socket pair. Legacy systems would need to 1127 be able to interpret the transport payload fragments as individual 1128 transport datagrams. 1130 14. UDP Option State Caching 1132 Some TCP connection parameters, stored in the TCP Control Block, can 1133 be usefully shared either among concurrent connections or between 1134 connections in sequence, known as TCP Sharing [RFC2140][To19cb]. 1135 Although UDP is stateless, some of the options proposed herein may 1136 have similar benefit in being shared or cached. We call this UCB 1137 Sharing, or UDP Control Block Sharing, by analogy. 1139 [TBD: extend this section to indicate which options MAY vs. MUST NOT 1140 be shared and how, e.g., along the lines of To19cb] 1142 15. Updates to RFC 768 1144 This document updates RFC 768 as follows: 1146 o This document defines the meaning of the IP payload area beyond 1147 the UDP length but within the IP length. 1149 o This document extends the UDP API to support the use of options. 1151 16. Multicast Considerations 1153 UDP options are primarily intended for unicast use. Using these 1154 options over multicast IP requires careful consideration, e.g., to 1155 ensure that the options used are safe for different endpoints to 1156 interpret differently (e.g., either to support or silently ignore) 1157 or to ensure that all receivers of a multicast group confirm support 1158 for the options in use. 1160 17. Security Considerations 1162 The use of UDP packets with inconsistent IP and UDP Length fields 1163 has the potential to trigger a buffer overflow error if not properly 1164 handled, e.g., if space is allocated based on the smaller field and 1165 copying is based on the larger. However, there have been no reports 1166 of such vulnerability and it would rely on inconsistent use of the 1167 two fields for memory allocation and copying. 1169 UDP options are not covered by DTLS (datagram transport-layer 1170 security). Despite the name, neither TLS [RFC8446] (transport layer 1171 security, for TCP) nor DTLS [RFC6347] (TLS for UDP) protect the 1172 transport layer. Both operate as a shim layer solely on the payload 1173 of transport packets, protecting only their contents. Just as TLS 1174 does not protect the TCP header or its options, DTLS does not 1175 protect the UDP header or the new options introduced by this 1176 document. Transport security is provided in TCP by the TCP 1177 Authentication Option (TCP-AO [RFC5925]) or in UDP by the 1178 Authentication Extension option (Section 5.10). Transport headers 1179 are also protected as payload when using IP security (IPsec) 1180 [RFC4301]. 1182 UDP options use the TLV syntax similar to that of TCP. This syntax 1183 is known to require serial processing and may pose a DOS risk, e.g., 1184 if an attacker adds large numbers of unknown options that must be 1185 parsed in their entirety. Implementations concerned with the 1186 potential for this vulnerability MAY implement only the required 1187 options and MAY also limit processing of TLVs. Because required 1188 options come first and at most once each (with the exception of 1189 NOPs, which should never need to come in sequences of more than 1190 three in a row), this limits their DOS impact. Note that when a 1191 packet's options cannot be processed, it MUST be discarded; the 1192 packet and its options should always share the same fate. 1194 18. IANA Considerations 1196 Upon publication, IANA is hereby requested to create a new registry 1197 for UDP Option Kind numbers, similar to that for TCP Option Kinds. 1198 Initial values of this registry are as listed in Section 5. 1199 Additional values in this registry are to be assigned by IESG 1200 Approval or Standards Action [RFC8126]. 1202 Upon publication, IANA is hereby requested to create a new registry 1203 for UDP Experimental Option Experiment Identifiers (UDP ExIDs) for 1204 use in a similar manner as TCP ExIDs [RFC6994]. This registry is 1205 initially empty. Values in this registry are to be assigned by IANA 1206 using first-come, first-served (FCFS) rules [RFC8126]. 1208 19. References 1210 19.1. Normative References 1212 [Fa19] Fairhurst, G., T. Jones, M. Tuexen, I. Ruengeler, T. 1213 Voelker, "Packetization Layer Path MTU Discovery for 1214 Datagram Transports," draft-ietf-tsvwg-datagram-plpmtud, 1215 Feb. 2019. 1217 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1218 Requirement Levels," BCP 14, RFC 2119, March 1997. 1220 [RFC768] Postel, J., "User Datagram Protocol," RFC 768, August 1221 1980. 1223 [RFC791] Postel, J., "Internet Protocol," RFC 791, Sept. 1981. 1225 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -- 1226 Communication Layers," RFC 1122, Oct. 1989. 1228 [RFC1662] Simpson, W. Ed., "PPP in HDLC-like Framing," RFC 1662, 1229 Oct. 1994. 1231 19.2. Informative References 1233 [Fa18] Fairhurst, G., T. Jones, R. Zullo, "Checksum Compensation 1234 Options for UDP Options", draft-fairhurst-udp-options-cco, 1235 Oct. 2018. 1237 [Hi15] Hildebrand, J., B. Trammel, "Substrate Protocol for User 1238 Datagrams (SPUD) Prototype," draft-hildebrand-spud- 1239 prototype-03, Mar. 2015. 1241 [RFC793] Postel, J., "Transmission Control Protocol" RFC 793, 1242 September 1981. 1244 [RFC1191] Mogul, J., S. Deering, "Path MTU discovery," RFC 1191, 1245 November 1990. 1247 [RFC2140] Touch, J., "TCP Control Block Interdependence," RFC 2140, 1248 Apr. 1997. 1250 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery," RFC 1251 2923, September 2000. 1253 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1254 Internet Protocol", RFC 4301, Dec. 2005. 1256 [RFC4340] Kohler, E., M. Handley, and S. Floyd, "Datagram Congestion 1257 Control Protocol (DCCP)", RFC 4340, March 2006. 1259 [RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol", 1260 RFC 4960, September 2007. 1262 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1263 Considered Useful," RFC 3692, Jan. 2004. 1265 [RFC3828] Larzon, L-A., M. Degermark, S. Pink, L-E. Jonsson (Ed.), 1266 G. Fairhurst (Ed.), "The Lightweight User Datagram 1267 Protocol (UDP-Lite)," RFC 3828, July 2004. 1269 [RFC5925] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication 1270 Option," RFC 5925, June 2010. 1272 [RFC6347] Rescorla, E., N. Modadugu, "Datagram Transport Layer 1273 Security Version 1.2," RFC 6347, Jan. 2012. 1275 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)," 1276 RFC 6691, July 2012. 1278 [RFC6978] Touch, J., "A TCP Authentication Option Extension for NAT 1279 Traversal", RFC 6978, July 2013. 1281 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options," RFC 1282 6994, Aug. 2013. 1284 [RFC7323] Borman, D., R. Braden, V. Jacobson, R. Scheffenegger 1285 (Ed.), "TCP Extensions for High Performance," RFC 7323, 1286 Sep. 2014. 1288 [RFC8085] Eggert, L., G. Fairhurst, G. Shepherd, "UDP Usage 1289 Guidelines," RFC 8085, Feb. 2017. 1291 [RFC8126] Cotton, M., B. Leiba, T. Narten, "Guidelines for Writing 1292 an IANA Considerations Section in RFCs," RFC 8126, June 1293 2017. 1295 [RFC8200] Deering, S., R. Hinden, "Internet Protocol Version 6 1296 (IPv6) Specification," RFC 8200, Jul. 2017. 1298 [RFC8201] McCann, J., S. Deering, J. Mogul, R. Hinden (Ed.), "Path 1299 MTU Discovery for IP version 6," RFC 8201, Jul. 2017. 1301 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1302 Version 1.3," RFC 8446, Aug. 2018. 1304 [To18ao] Touch, J., "A TCP Authentication Option Extension for 1305 Payload Encryption," draft-touch-tcp-ao-encrypt, Jul. 1306 2018. 1308 [To19cb] Touch, J., M. Welzl, S. Islam, J. You, "TCP Control Block 1309 Interdependence," draft-touch-tcpm-2140bis, Jan. 2019. 1311 [Tr16] Trammel, B. (Ed.), M. Kuelewind (Ed.), "Requirements for 1312 the design of a Substrate Protocol for User Datagrams 1313 (SPUD)," draft-trammell-spud-req-04, May 2016. 1315 20. Acknowledgments 1317 This work benefitted from feedback from Bob Briscoe, Ken Calvert, 1318 Ted Faber, Gorry Fairhurst, C. M. Heard (including the FRAG/LITE 1319 combination), Tom Herbert, and Mark Smith, as well as discussions on 1320 the IETF TSVWG and SPUD email lists. 1322 This work was partly supported by USC/ISI's Postel Center. 1324 This document was prepared using 2-Word-v2.0.template.dot. 1326 Authors' Addresses 1328 Joe Touch 1329 Manhattan Beach, CA 90266 USA 1331 Phone: +1 (310) 560-0334 1332 Email: touch@strayalpha.com 1334 Appendix A. Implementation Information 1336 The following information is provided to encourage interoperable API 1337 implementations. 1339 System-level variables (sysctl): 1341 Name default meaning 1342 ---------------------------------------------------- 1343 net.ipv4.udp_opt 0 UDP options available 1344 net.ipv4.udp_opt_ocs 1 Default include OCS 1345 net.ipv4.udp_opt_acs 0 Default include ACS 1346 net.ipv4.udp_opt_lite 0 Default include LITE 1347 net.ipv4.udp_opt_mss 0 Default include MSS 1348 net.ipv4.udp_opt_time 0 Default include TIME 1349 net.ipv4.udp_opt_frag 0 Default include FRAG 1350 net.ipv4.udp_opt_ae 0 Default include AE 1352 Socket options (sockopt), cached for outgoing datagrams: 1354 Name meaning 1355 ---------------------------------------------------- 1356 UDP_OPT Enable UDP options (at all) 1357 UDP_OPT_OCS Enable UDP OCS option 1358 UDP_OPT_ACS Enable UDP ACS option 1359 UDP_OPT_LITE Enable UDP LITE option 1360 UDP_OPT_MSS Enable UDP MSS option 1361 UDP_OPT_TIME Enable UDP TIME option 1362 UDP_OPT_FRAG Enable UDP FRAG option 1363 UDP_OPT_AE Enable UDP AE option 1365 Send/sendto parameters: 1367 (TBD - currently using cached parameters) 1369 Connection parameters (per-socketpair cached state, part UCB): 1371 Name Initial value 1372 ---------------------------------------------------- 1373 opts_enabled net.ipv4.udp_opt 1374 ocs_enabled net.ipv4.udp_opt_ocs 1376 The following option is included for debugging purposes, and MUST 1377 NOT be enabled otherwise. 1379 System variables 1380 net.ipv4.udp_opt_junk 0 1382 System-level variables (sysctl): 1384 Name default meaning 1385 ---------------------------------------------------- 1386 net.ipv4.udp_opt_junk 0 Default use of junk 1388 Socket options (sockopt): 1390 Name params meaning 1391 ------------------------------------------------------ 1392 UDP_JUNK - Enable UDP junk option 1393 UDP_JUNK_VAL fillval Value to use as junk fill 1394 UDP_JUNK_LEN length Length of junk payload in bytes 1396 Connection parameters (per-socketpair cached state, part UCB): 1398 Name Initial value 1399 ---------------------------------------------------- 1400 junk_enabled net.ipv4.udp_opt_junk 1401 junk_value 0xABCD 1402 junk_len 4