idnits 2.17.1 draft-touch-tsvwg-udp-options-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 1021 has weird spacing: '...default mean...' == Line 1053 has weird spacing: '...enabled net.i...' == Line 1054 has weird spacing: '...enabled net....' == Line 1064 has weird spacing: '...default mean...' == Line 1070 has weird spacing: '... params mean...' == (1 more instance...) -- The document date (April 17, 2017) is 2567 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 2140 (Obsoleted by RFC 9040) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- 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 (~~), 7 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TSGWG J. Touch 2 Internet Draft USC/ISI 3 Intended status: Experimental April 17, 2017 4 Expires: October 2017 6 Transport Options for UDP 7 draft-touch-tsvwg-udp-options-08.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. This document may not be modified, 13 and derivative works of it may not be created, and it may not be 14 published except as an Internet-Draft. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on October 17, 2017. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. 46 Abstract 48 Transport protocols are extended through the use of transport header 49 options. This document experimentally extends UDP by indicating the 50 location, syntax, and semantics for UDP transport layer options. 52 Table of Contents 54 1. Introduction...................................................2 55 2. Conventions used in this document..............................3 56 3. Background.....................................................3 57 4. The UDP Option Area............................................4 58 5. UDP Options....................................................7 59 5.1. End of Options List (EOL).................................7 60 5.2. No Operation (NOP)........................................8 61 5.3. Option Checksum (OCS).....................................8 62 5.4. Alternate Checksum (ACS)..................................9 63 5.5. Lite (LITE)...............................................9 64 5.6. Maximum Segment Size (MSS)...............................11 65 5.7. Timestamps (TIME)........................................12 66 5.8. Fragmentation (FRAG).....................................12 67 5.8.1. Coupling FRAG with LITE.............................14 68 5.9. Authentication and Encryption (AE).......................15 69 5.10. Experimental (EXP)......................................16 70 6. UDP API Extensions............................................16 71 7. Whose options are these?......................................17 72 8. UDP options vs. UDP-Lite......................................17 73 9. Interactions with Legacy Devices..............................18 74 10. Options in a Stateless, Unreliable Transport Protocol........19 75 11. UDP Option State Caching.....................................19 76 12. Security Considerations......................................20 77 13. IANA Considerations..........................................20 78 14. References...................................................20 79 14.1. Normative References....................................20 80 14.2. Informative References..................................20 81 15. Acknowledgments..............................................22 82 Appendix A. Implementation Information...........................24 84 1. Introduction 86 Transport protocols use options as a way to extend their 87 capabilities. TCP [RFC793], SCTP [RFC4960], and DCCP [RFC4340] 88 include space for these options but UDP [RFC768] currently does not. 89 This document defines an experimental extension to UDP that provides 90 space for transport options including their generic syntax and 91 semantics for their use in UDP's stateless, unreliable message 92 protocol. 94 2. Conventions used in this document 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [RFC2119]. 100 In this document, these words will appear with that interpretation 101 only when in ALL CAPS. Lowercase uses of these words are not to be 102 interpreted as carrying significance described in RFC 2119. 104 In this document, the characters ">>" preceding an indented line(s) 105 indicates a statement using the key words listed above. This 106 convention aids reviewers in quickly identifying or finding the 107 portions of this RFC covered by these key words. 109 3. Background 111 Many protocols include a default header and an area for header 112 options. These options enable the protocol to be extended for use in 113 particular environments or in ways unforeseen by the original 114 designers. Examples include TCP's Maximum Segment Size, Window 115 Scale, Timestamp, and Authentication Options 116 [RFC793][RFC5925][RFC7323]. 118 These options are used both in stateful (connection-oriented, e.g., 119 TCP [RFC793], SCTP [RFC4960], DCCP [RFC4340]) and stateless 120 (connectionless, e.g., IPv4 [RFC791], IPv6 [RFC2460] protocols. In 121 stateful protocols they can help extend the way in which state is 122 managed. In stateless protocols their effect is often limited to 123 individual packets, but they can have an aggregate effect on a 124 sequence as well. One example of such uses is Substrate Protocol for 125 User Datagrams (SPUD) [Tr15], and this document is intended to 126 provide an out-of-band option area as an alternative to the in-band 127 mechanism currently proposed [Hi15]. 129 UDP is one of the most popular protocols that lacks space for 130 options [RFC768]. The UDP header was intended to be a minimal 131 addition to IP, providing only ports and a data checksum for 132 protection. This document experimentally extends UDP to provide a 133 trailer area for options located after the UDP data payload. 135 4. The UDP Option Area 137 The UDP transport header includes demultiplexing and service 138 identification (port numbers), a checksum, and a field that 139 indicates the UDP datagram length (including UDP header). The UDP 140 Length length field is typically redundant with the size of the 141 maximum space available as a transport protocol payload (see also 142 discussion in Section 9). 144 For IPv4, IP Total Length field indicates the total IP datagram 145 length (including IP header), and the size of the IP options is 146 indicated in the IP header (in 4-byte words) as the "Internet Header 147 Length" (IHL), as shown in Figure 1 [RFC791]. As a result, the 148 typical (and largest valid) value for UDP Length is: 150 UDP_Length = IPv4_Total_Length - IPv4_IHL * 4 152 For IPv6, the IP Payload Length field indicates the datagram after 153 the base IPv6 header, which includes the IPv6 extension headers and 154 space available for the transport protocol, as shown in Figure 2 155 [RFC2460]. Note that the Next HDR field in IPv6 might not indicate 156 UDP (i.e., 17), e.g., when intervening IP extension headers are 157 present. For IPv6, the lengths of any additional IP extensions are 158 indicated within each extension [RFC2460], so the typical (and 159 largest valid) value for UDP Length is: 161 UDP_Length = IPv6_Payload_Length - sum(extension header lengths) 163 In both cases, the space available for the UDP transport protocol 164 data unit is indicated by IP, either completely in the base header 165 (for IPv4) or adding information in the extensions (for IPv6). In 166 either case, this document will refer to this available space as the 167 "IP transport payload". 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 |Version| IHL |Type of Service| Total Length | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Identification |Flags| Fragment Offset | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Time to Live | Proto=17 (UDP)| Header Checksum | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Source Address | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Destination Address | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 ... zero or more IP Options (using space as indicated by IHL) ... 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | UDP Source Port | UDP Destination Port | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | UDP Length | UDP Checksum | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 Figure 1 IPv4 datagram with UDP transport payload 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 |Version| Traffic Class | Flow Label | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Payload Length | Next Hdr | Hop Limit | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 ... 195 | Source Address (128 bits) | 196 ... 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 ... 199 | Destination Address (128 bits) | 200 ... 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 ... zero or more IP Extension headers (each indicating size) ... 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | UDP Source Port | UDP Destination Port | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | UDP Length | UDP Checksum | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Figure 2 IPv6 datagram with UDP transport payload 211 As a result of this redundancy, there is an opportunity to use the 212 UDP Length field as a way to break up the IP transport payload into 213 two areas - that intended as UDP user data and an additional 214 "surplus area" (as shown in Figure 3). 216 IP transport payload 217 <-------------------------------------------------> 218 +--------+---------+----------------------+------------------+ 219 | IP Hdr | UDP Hdr | UDP user data | surplus area | 220 +--------+---------+----------------------+------------------+ 221 <------------------------------> 222 UDP Length 224 Figure 3 IP transport payload vs. UDP Length 226 In most cases, the IP transport payload and UDP Length point to the 227 same location, indicating that there is no surplus area. It is 228 important to note that this is not a requirement of UDP [RFC768] 229 (discussed further in Section 9). UDP-Lite used the difference in 230 these pointers to indicate the partial coverage of the UDP Checksum, 231 such that the UDP user data, UDP header, and UDP pseudoheader (a 232 subset of the IP header) are covered by the UDP checksum but 233 additional user data in the surplus area is not covered [RFC3828]. 234 This document uses the surplus area for UDP transport options. 236 The UDP option area is thus defined as the location between the end 237 of the UDP payload and the end of the IP datagram as a trailing 238 options area. This area can occur at any valid byte offset, i.e., it 239 need not be 16-bit or 32-bit aligned. In effect, this document 240 redefines the UDP "Length" field as a "trailer offset". 242 UDP options are defined using a syntax similar to that of TCP 243 [RFC793]. They are typically a minimum of two bytes in length as 244 shown in Figure 4, excepting only the one byte options "No 245 Operation" (NOP) and "End of Options List" (EOL) described below. 247 +--------+--------+ 248 | Kind | Length | 249 +--------+--------+ 251 Figure 4 UDP option default format 253 >> UDP options MAY occur at any UDP length offset. 255 >> The UDP length MUST be at least as large as the UDP header (8) 256 and no larger than the IP transport payload. Values outside this 257 range MUST be silently discarded as invalid and logged where rate- 258 limiting permits. 260 Others have considered using values of the UDP Length that is larger 261 than the IP transport payload as an additional type of signal. Using 262 a value smaller than the IP transport payload is expected to be 263 backward compatible with existing UDP implementations, i.e., to 264 deliver the UDP Length of user data to the application and silently 265 ignore the additional surplus area data. Using a value larger than 266 the IP transport payload would either be considered malformed (and 267 be silently dropped) or could cause buffer overruns, and so is not 268 considered silently and safely backward compatible. Its use is thus 269 out of scope for the extension described in this document. 271 >> UDP options MUST be interpreted in the order in which they occur 272 in the UDP option area. 274 5. UDP Options 276 The following UDP options are currently defined: 278 Kind Length Meaning 279 ---------------------------------------------- 280 0* - End of Options List (EOL) 281 1* - No operation (NOP) 282 2* 2 Option checksum (OCS) 283 3 4 Alternate checksum (ACS) 284 4 4 Lite (LITE) 285 5 4 Maximum segment size (MSS) 286 6 10 Timestamps (TIME) 287 7 12 Fragmentation (FRAG) 288 8 (varies) Authentication and Encryption (AE) 289 128-253 RESERVED 290 254 N(>=4) RFC 3692-style experiments (EXP) 291 255 RESERVED 293 These options are defined in the following subsections. 295 >> An endpoint supporting UDP options MUST support those marked with 296 a "*" above: EOL, NOP, and OCS. 298 [QUESTION: Should we extend these through option #7?] 300 >> All other options (without a "*") MAY be implemented, and their 301 use SHOULD be determined either out-of-band or negotiated. 303 5.1. End of Options List (EOL) 305 The End of Options List (EOL) option indicates that there are no 306 more options. It is used to indicate the end of the list of options 307 without needing to pad the options to fill all available option 308 space. 310 +--------+ 311 | Kind=0 | 312 +--------+ 314 Figure 5 UDP EOL option format 316 >> When the UDP options do not consume the entire option area, the 317 last non-NOP option SHOULD be EOL (vs. filling the entire option 318 area with NOP values). 320 >> All bytes after EOL MUST be ignored by UDP option processing. 322 5.2. No Operation (NOP) 324 The No Operation (NOP) option is a one byte placeholder, intended to 325 be used as padding, e.g., to align multi-byte options along 16-bit 326 or 32-bit boundaries. 328 +--------+ 329 | Kind=1 | 330 +--------+ 332 Figure 6 UDP NOP option format 334 >> If options longer than one byte are used, NOP options SHOULD be 335 used at the beginning of the UDP options area to achieve alignment 336 as would be more efficient for active (i.e., non-NOP) options. 338 5.3. Option Checksum (OCS) 340 The Option Checksum (OCS) is an 8-bit ones-complement sum (Ones8) 341 that covers all of the UDP options. OCS can be calculated by 342 computing the 16-bit ones-complement sum and "folding over" the 343 result (using carry wraparound). Note that OCS is direct, i.e., it 344 is not negated or adjusted if zero (unlike the Internet checksum as 345 used in IPv4, TCP, and UDP headers). OCS protects the option area 346 from errors in a similar way that the UDP checksum protects the UDP 347 user data. 349 +--------+--------+ 350 | Kind=2 | Ones8 | 351 +--------+--------+ 353 Figure 7 UDP OCS option format 355 >> When present, the option checksum SHOULD occur as early as 356 possible, preferably preceded by only NOP options for alignment and 357 the LITE option if present. 359 >> OCS covers the entire UDP option, including the Lite option as 360 formatted before swapping for transmission (or, equivalently, after 361 the swap after reception). 363 >> If the option checksum fails, all options MUST be ignored and any 364 trailing surplus data (and Lite data, if used) silently discarded. 366 >> UDP data that is validated by a correct UDP checksum MUST be 367 delivered to the application layer, even if the UDP option checksum 368 fails, unless the endpoints have negotiated otherwise for this 369 segment's socket pair. 371 5.4. Alternate Checksum (ACS) 373 The Alternate Checksum (ACS) is a 16-bit CRC of the UDP payload only 374 (excluding the IP pseudoheader, UDP header, and UDP options). It 375 does not include the IP pseudoheader or UDP header, and so need not 376 be updated by NATs when IP addresses or UDP ports are rewritten. Its 377 purpose is to detect errors that the UDP checksum might not detect. 378 CRC-CCITT (polynomial x^16 + x^12 + x^5 + x or polynomial 0x1021) 379 has been chosen because of its ubiquity and use in other packet 380 protocols, such as X.25, HDLC, and Bluetooth. 382 +--------+--------+--------+--------+ 383 | Kind=3 | Len=4 | CRC16sum | 384 +--------+--------+--------+--------+ 386 Figure 8 UDP ACS option format 388 5.5. Lite (LITE) 390 The Lite option (LITE) is intended to provide equivalent capability 391 to the UDP Lite transport protocol [RFC3828]. UDP Lite allows the 392 UDP checksum to cover only a prefix of the UDP data payload, to 393 protect critical information (e.g., application headers) but allow 394 potentially erroneous data to be passed to the user. This feature 395 helps protect application headers but allows for application data 396 errors. Some applications are impacted more by a lack of data than 397 errors in data, e.g., voice and video. 399 >> When LITE is active, it MUST come first in the UDP options list. 401 LITE is intended to support the same API as for UDP Lite to allow 402 applications to send and receive data that has a marker indicating 403 the portion protected by the UDP checksum and the portion not 404 protected by the UDP checksum. 406 LITE includes a 2-byte offset that indicates the length of the 407 portion of the UDP data that is not covered by the UDP checksum. 409 +--------+--------+--------+--------+ 410 | Kind=5 | Len=4 | Offset | 411 +--------+--------+--------+--------+ 413 Figure 9 UDP LITE option format 415 At the sender, the option is formed using the following steps: 417 1. Create a LITE option, ordered as the first UDP option (Figure 418 10). 420 2. Calculate the location of the start of the options as an absolute 421 offset from the start of the UDP header and place that length in 422 the last two bytes of the LITE option. 424 3. Swap all four bytes of the LITE option with the first 4 bytes of 425 the LITE data area (Figure 11). 427 +---------+--------------+--------------+------------------+ 428 | UDP Hdr | user data | LITE data |LITE| other opts | 429 +---------+--------------+--------------+------------------+ 430 <----------------------> 431 UDP Length 433 Figure 10 LITE option formation - LITE goes first 435 +---------+--------------+--------------+------------------+ 436 | UDP Hdr | user data | LITE data |LITE| other opts | 437 +---------+--------------+--------------+------------------+ 438 ^^^^ ^^^^ 439 | | 440 +--------------+ 442 Figure 11 Before sending swap LITE option and front of LITE data 444 The resulting packet has the format shown in Figure 12. Note that 445 the UDP length now points to the LITE option, and the LITE option 446 points to the start of the option area. 448 +---------+--------------+----------------+------------------+ 449 | UDP Hdr | user data |LITE| LITE data |Ldat| other opts | 450 +---------+--------------+----------------+------------------+ 451 <----------------------> | ^ 452 UDP Length +-------------+ 454 Figure 12 Lite option as sent 456 A legacy endpoint receiving this packet will discard the LITE option 457 and everything that follows, including the lite data and remainder 458 of the UDP options. The UDP checksum will protect only the user 459 data, not the LITE option or lite data. 461 Receiving endpoints capable of processing UDP options will do the 462 following: 464 1. Process options as usual. This will start at the LITE option. 466 2. When the LITE option is encountered, record its location as the 467 start of the LITE data area and swap the four bytes there with 468 the four bytes at the location indicated inside the LITE option, 469 which indicates the start of all of the options, including the 470 LITE one (one past the end of the lite data area). This restores 471 the format of the option as per Figure 10. 473 3. Continue processing the remainder of the options, which are now 474 in the format shown in Figure 11. 476 The purpose of this swap is to support the equivalent of UDP Lite 477 operation together with other UDP options without requiring the 478 entire LITE data area to be moved after the UDP option area. 480 5.6. Maximum Segment Size (MSS) 482 The Maximum Segment Size (MSS, Kind = 3) is a 16-bit indicator of 483 the largest UDP segment that can be received. As with the TCP MSS 484 option [RFC793], the size indicated is the IP layer MTU decreased by 485 the fixed IP and UDP headers only [RFC6691]. The space needed for IP 486 and UDP options need to be adjusted by the sender when using the 487 value indicated. The value transmitted is based on EMTU_R, the 488 largest IP datagram that can be received (i.e., reassembled at the 489 receiver) [RFC1122]. 491 +--------+--------+--------+--------+ 492 | Kind=5 | Len=4 | MSS size | 493 +--------+--------+--------+--------+ 495 Figure 13 UDP MSS option format 497 The UDP MSS option MAY be used for path MTU discovery 498 [RFC1191][RFC1981], but this may be difficult because of known 499 issues with ICMP blocking [RFC2923] as well as UDP lacking automatic 500 retransmission. It is more likely to be useful when coupled with IP 501 source fragmentation to limit the largest reassembled UDP message, 502 e.g., when EMTU_R is larger than the required minimums (576 for IPv4 503 [RFC791] and 1500 for IPv6 [RFC2460]). 505 5.7. Timestamps (TIME) 507 The UDP Timestamp option (TIME) exchanges two four-byte timestamp 508 fields. It serves a similar purpose to TCP's TS option [RFC7323], 509 enabling UDP to estimate the round trip time (RTT) between hosts. 510 For UDP, this RTT can be useful for establishing UDP fragment 511 reassembly timeouts or transport-layer rate-limiting [RFC8085]. 513 +--------+--------+------------------+------------------+ 514 | Kind=6 | Len=10 | TS Value | TS Echo Reply | 515 +--------+--------+------------------+------------------+ 516 1 byte 1 byte 4 bytes 4 bytes 518 Figure 14 UDP TIME option format 520 TS Value (TSval) and TS Echo (TSecr) are used in a similar manner to 521 the TCP TS option [RFC7323]. A host using the Timestamp option sets 522 TS Value on all UDP segments issued. Received TSval values are 523 provided to the application, which passes this value as TSecr on UDP 524 messages sent in response to such a message. 526 >> UDP MAY use an RTT estimate based on nonzero Timestamp values as 527 a hint for fragmentation reassembly, rate limiting, or other 528 mechanisms that benefit from such an estimate. 530 >> UDP SHOULD make this RTT estimate available to the user 531 application. 533 5.8. Fragmentation (FRAG) 535 The Fragmentation option (FRAG) supports UDP fragmentation and 536 reassembly, which can be used to transfer UDP messages larger than 537 limited by the IP receive MTU (EMTU_R [RFC1122]). It is typically 538 used with the UDP MSS option to enable more efficient use of large 539 messages, both at the UDP and IP layers. FRAG is designed similar to 540 the IPv6 Fragmentation Header [RFC2460], except that the UDP variant 541 uses a 16-bit Offset measured in bytes, rather than IPv6's 13-bit 542 Fragment Offset measured in 8-byte units. This UDP variant avoids 543 creating reserved fields. 545 +--------+--------+--------+--------+ 546 | Kind=8 | Len=8 | Frag. Offset | 547 +--------+--------+--------+--------+ 548 | Identification | 549 +--------+--------+--------+--------+ 551 Figure 15 UDP non-terminal FRAG option format 553 The FRAG option also lacks a "more" bit, zeroed for the terminal 554 fragment of a set. This is possible because the terminal FRAG option 555 is indicated as a longer, 12-byte variant, which includes an 556 Internet checksum over the reassembled payload (omitting the IP 557 pseudoheader and UDP header, as well as UDP options), as shown in 558 Figure 16. The reassembly checksum SHOULD be used, but MAY be 559 ignored in the same situations when the UDP checksum is ignored 560 (e.g., for transit tunnels or applications that have their own 561 integrity checks [RFC2460]), and by the same mechanism (set the 562 field to 0x0000). 564 +--------+--------+--------+--------+ 565 | Kind=8 | Len=12 | Frag. Offset | 566 +--------+--------+--------+--------+ 567 | Identification | 568 +--------+--------+--------+--------+ 569 | Checksum | 570 +--------+--------+ 572 Figure 16 UDP terminal FRAG option format 574 The Fragment Offset is 16 bits and indicates the location of the UDP 575 payload fragment in bytes from the beginning of the original 576 unfragmented payload. The Len field indicates whether there are more 577 fragments (Len=8) or no more fragments (Len=12). 579 >> The Identification field is a 32-bit value that MUST be unique 580 over the expected fragment reassembly timeout. 582 >> The Identification field SHOULD be generated in a manner similar 583 to that of the IPv6 Fragment ID [RFC2460]. 585 >> UDP fragments MUST NOT overlap. 587 FRAG needs to be used with extreme care because it will present 588 incorrect datagram boundaries to a legacy receiver, unless encoded 589 as LITE data (see Section 5.8.1). 591 >> A host SHOULD indicate FRAG support by transmitting an 592 unfragmented datagram using the Fragmentation option (e.g., with 593 Offset zero and length 12, i.e., including the checksum area), 594 except when encoded as LITE. 596 >> A host MUST NOT transmit a UDP fragment before receiving recent 597 confirmation from the remote host, except when FRAG is encoded as 598 LITE. 600 UDP fragmentation relies on a fragment expiration timer, which can 601 be preset or could use a value computed using the UDP Timestamp 602 option. 604 >> The default UDP reassembly SHOULD be no more than 2 minutes. 606 Implementers are advised to limit the space available for UDP 607 reassembly. 609 >> UDP reassembly space SHOULD be limited to reduce the impact of 610 DOS attacks on resource use. 612 >> UDP reassembly space limits SHOULD NOT be implemented as an 613 aggregate, to avoid cross-socketpair DOS attacks. 615 >> Individual UDP fragments MUST NOT be forwarded to the user. The 616 reassembled datagram is received only after complete reassembly, 617 checksum validation, and continued processing of the remaining 618 options. 620 Any additional UDP options would follow the FRAG option in the final 621 fragment, and would be included in the reassembled packet. 622 Processing of those options would commence after reassembly. 624 >> UDP options MUST NOT follow the FRAG header in non-terminal 625 fragments. All other options that apply to a reassembled packet MUST 626 follow the FRAG header in the terminal fragment. 628 5.8.1. Coupling FRAG with LITE 630 FRAG can be coupled with LITE to avoid impacting legacy receivers. 631 Each fragment is sent as LITE un-checksummed data, where each UDP 632 packet contains no legacy-compatible data. Legacy receivers 633 interpret these as zero-payload packets, which would not affect the 634 receiver unless the presence of the packet itself were a signal. The 635 header of such a packet would appear as shown in Figure 17 and 636 Figure 18. 638 +---------+--------------+---------+ 639 | UDP Hdr | LiteFrag |LITE|FRAG| 640 +---------+--------------+----+----+ 641 <-------> ^^^^ ^^^^ 642 Zero UDP Length | | 643 +--------------+ 645 Figure 17 Preparing FRAG as Lite data 647 +---------+--------------+----+ 648 | UDP Hdr |LITE|LiteFrag |FRAG| 649 +---------+--------------+----+ 650 <-------> | ^ 651 Zero UDP Length | | 652 +-------------+ 654 Figure 18 Lite option before transmission 656 When a packet is reassembled, it appears as a complete LITE data 657 region. The UDP header of the reassembled packet is adjusted 658 accordingly, so that the reassembled region now appears as 659 conventional UDP user data, and processing of the UDP options 660 continues, as with the non-LITE FRAG variant. 662 5.9. Authentication and Encryption (AE) 664 The Authentication and Encryption option (AE) is intended to allow 665 UDP to provide a similar type of authentication as the TCP 666 Authentication Option (TCP-AO)_[RFC5925]. It uses the same format as 667 specified for TCP-AO, except that it uses a Kind of 8. UDP-AO 668 supports NAT traversal in a similar manner as TCP-AO [RFC6978]. UDP- 669 AO can also be extended to provide a similar encryption capability 670 as TCP-AO-ENC, in a similar manner [To16]. For these reasons, the 671 option is known as UDP-AE. 673 Like TCP-AO, UDP-AE is not negotiated in-band. Its use assumes both 674 endpoints have populated Master Key Tuples (MKTs), used to exclude 675 non-protected traffic. 677 TCP-AO generates unique traffic keys from a hash of TCP connection 678 parameters. UDP lacks a three-way handshake to coordinate 679 connection-specific values, such as TCP's Initial Sequence Numbers 680 (ISNs) [RFC793], thus UDP-AE's Key Derivation Function (KDF) uses 681 zeroes as the value for both ISNs. This means that the UDP-AE reuses 682 keys when socket pairs are reused, unlike TCP-AO. 684 5.10. Experimental (EXP) 686 The Experimental option (EXP) is reserved for experiments [RFC3692]. 687 Only one such value is reserved because experiments are expected to 688 use an Experimental ID (ExIDs) to differentiate concurrent use for 689 different purposes, using UDP ExIDs registered with IANA according 690 to the approach developed for TCP experimental options [RFC6994]. 692 >> The length of the experimental option MUST be at least 4 to 693 account for the Kind, Length, and the minimum 16-bit UDP ExID 694 identifier (similar to TCP ExIDs [RFC6994]). 696 6. UDP API Extensions 698 UDP currently specifies an application programmer interface (API), 699 summarized as follows (with Unix-style command as an example) 700 [RFC768]: 702 o Method to create new receive ports 704 o E.g., bind(handle, recvaddr(optional), recvport) 706 o Receive, which returns data octets, source port, and source 707 address 709 o E.g., recvfrom(handle, srcaddr, srcport, data) 711 o Send, which specifies data, source and destination addresses, and 712 source and destination ports 714 o E.g., sendto(handle, destaddr, destport, data) 716 This API is extended to support options as follows: 718 o Extend the method to create receive ports to include receive 719 options that are required. Datagrams not containing these 720 required options MUST be silently dropped and MAY be logged. 722 o Extend the receive function to indicate the options and their 723 parameters as received with the corresponding received datagram. 725 o Extend the send function to indicate the options to be added to 726 the corresponding sent datagram. 728 Examples of API instances for Linux and FreeBSD are provided in 729 Appendix A, to encourage uniform cross-platform implementations. 731 7. Whose options are these? 733 UDP options are indicated in an area of the IP payload that is not 734 used by UDP. That area is really part of the IP payload, not the UDP 735 payload, and as such, it might be tempting to consider whether this 736 is a generally useful approach to extending IP. 738 Unfortunately, the surplus area exists only for transports that 739 include their own transport layer payload length indicator. TCP and 740 SCTP include header length fields that already provide space for 741 transport options by indicating the total length of the header area, 742 such that the entire remaining area indicated in the network layer 743 (IP) is transport payload. UDP-Lite already uses the UDP Length 744 field to indicate the boundary between data covered by the transport 745 checksum and data not covered, and so there is no remaining area 746 where the length of the UDP-Lite payload as a whole can be indicated 747 [RFC3828]. 749 >> UDP options are intended for use only by the transport endpoints. 750 They are no more (or less) appropriate to be modified in-transit 751 than any other portion of the transport datagram. 753 UDP options are are transport options. Generally, transport 754 datagrams are not intended to be modified in-transit. However, the 755 UDP option mechanism provides no specific protection against in- 756 transit modification of the UDP header, UDP payload, or UDP option 757 area. 759 8. UDP options vs. UDP-Lite 761 UDP-Lite provides partial checksum coverage, so that packets with 762 errors in some locations can be delivered to the user [RFC3828]. It 763 uses a different transport protocol number (136) than UDP (17) to 764 interpret the UDP Length field as the prefix covered by the UDP 765 checksum. 767 UDP (protocol 17) already defines the UDP Length field as the limit 768 of the UDP checksum, but by default also limits the data provided to 769 the application as that which precedes the UDP Length. A goal of 770 UDP-Lite is to deliver data beyond UDP Length as a default, which is 771 why a separate transport protocol number was required. 773 UDP options do not need a separate transport protocol number because 774 the data beyond the UDP Length offset (surplus data) is not provided 775 to the application by default. That data is interpreted exclusively 776 within the UDP transport layer. 778 UDP options support a similar service to UDP-Lite by terminating the 779 UDP options with an EOL option. The additional data not covered by 780 the UDP checksum follows that EOL option, and is passed to the user 781 separately. The difference is that UDP-Lite provides the un- 782 checksummed user data to the application by default, whereas UDP 783 options can provide the same capability only for endpoints that are 784 negotiated in advance (i.e., by default, UDP options would silently 785 discard this non-checksummed data). Additionally, in UDP-Lite the 786 checksummed and non-checksummed payload components are adjacent, 787 whereas in UDP options they are separated by the option area - 788 which, minimally, must consist of at least one EOL option. 790 UDP-Lite cannot support UDP options, either as proposed here or in 791 any other form, because the entire payload of the UDP packet is 792 already defined as user data and there is no additional field in 793 which to indicate a separate area for options. The UDP Length field 794 in UDP-Lite is already used to indicate the boundary between user 795 data covered by the checksum and user data not covered. 797 9. Interactions with Legacy Devices 799 It has always been permissible for the UDP Length to be inconsistent 800 with the IP transport payload length [RFC768]. Such inconsistency 801 has been utilized in UDP-Lite using a different transport number. 802 There are no known systems that use this inconsistency for UDP 803 [RFC3828]. It is possible that such use might interact with UDP 804 options, i.e., where legacy systems might generate UDP datagrams 805 that appear to have UDP options. The UDP OCS provides protection 806 against such events and is stronger than a static "magic number". 808 UDP options have been tested as interoperable with Linux, Max OS-X, 809 and Windows Cygwin, and worked through NAT devices. These systems 810 successfully delivered only the user data indicated by the UDP 811 Length field and silently discarded the surplus area. 813 One reported embedded device passes the entire IP datagram to the 814 UDP application layer. Although this feature could enable 815 application-layer UDP option processing, it would require that 816 conventional UDP user applications examine only the UDP payload. 817 This feature is also inconsistent with the UDP application interface 818 [RFC768] [RFC1122]. 820 It has been reported that Alcatel-Lucent's "Brick" Intrusion 821 Detection System has a default configuration that interprets 822 inconsistencies between UDP Length and IP Length as an attack to be 823 reported. Note that other firewall systems, e.g., CheckPoint, use a 824 default "relaxed UDP length verification" to avoid falsely 825 interpreting this inconsistency as an attack. 827 (TBD: test with UDP checksum offload and UDP fragmentation offload) 829 10. Options in a Stateless, Unreliable Transport Protocol 831 There are two ways to interpret options for a stateless, unreliable 832 protocol -- an option is either local to the message or intended to 833 affect a stream of messages in a soft-state manner. Either 834 interpretation is valid for defined UDP options. 836 It is impossible to know in advance whether an endpoint supports a 837 UDP option. 839 >> UDP options MUST allow for silent failure on first receipt. 841 >> UDP options that rely on soft-state exchange MUST allow for 842 message reordering and loss. 844 >> A UDP option MUST be silently optional until confirmed by 845 exchange with an endpoint. 847 The above requirements prevent using any option that cannot be 848 safely ignored unless that capability has been negotiated with an 849 endpoint in advance for a socket pair. Legacy systems would need to 850 be able to interpret the transport payload fragments as individual 851 transport datagrams. 853 11. UDP Option State Caching 855 Some TCP connection parameters, stored in the TCP Control Block, can 856 be usefully shared either among concurrent connections or between 857 connections in sequence, known as TCP Sharing [RFC2140][To17]. 858 Although UDP is stateless, some of the options proposed herein may 859 have similar benefit in being shared or cached. We call this UCB 860 Sharing, or UDP Control Block Sharing, by analogy. 862 [TBD: extend this section to indicate which options MAY vs. MUST NOT 863 be shared and how, e.g., along the lines of To17] 865 12. Security Considerations 867 The use of UDP packets with inconsistent IP and UDP Length fields 868 has the potential to trigger a buffer overflow error if not properly 869 handled, e.g., if space is allocated based on the smaller field and 870 copying is based on the larger. However, there have been no reports 871 of such vulnerability and it would rely on inconsistent use of the 872 two fields for memory allocation and copying. 874 UDP options are not covered by DTLS (datagram transport-layer 875 security). Despite the name, neither TLS [RFC5246] (transport layer 876 security, for TCP) nor DTLS [RFC6347] (TLS for UDP) protect the 877 transport layer. Both operate as a shim layer solely on the payload 878 of transport packets, protecting only their contents. Just as TLS 879 does not protect the TCP header, DTLS does not protect the UDP 880 header or the new options introduced by this document. Transport 881 security is provided in TCP by the TCP Authentication Option (TCP-AO 882 [RFC5925]) or in UDP by the Authentication Extension option (Section 883 5.9). Transport headers are also protected as payload when using IP 884 security (IPsec) [RFC4301]. 886 13. IANA Considerations 888 Upon publication, IANA is hereby requested to create a new registry 889 for UDP Option Kind numbers, similar to that for TCP Option Kinds. 890 Initial values of this registry are as listed in Section 5. 891 Additional values in this registry are to be assigned by IESG 892 Approval or Standards Action [RFC5226]. 894 Upon publication, IANA is hereby requested to create a new registry 895 for UDP Experimental Option Experiment Identifiers (UDP ExIDs) for 896 use in a similar manner as TCP ExIDs [RFC6994]. This registry is 897 initially empty. Values in this registry are to be assigned by IANA 898 using first-come, first-served (FCFS) rules [RFC5226]. 900 14. References 902 14.1. Normative References 904 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 905 Requirement Levels", BCP 14, RFC 2119, March 1997. 907 14.2. Informative References 909 [Hi15] Hildebrand, J., B. Trammel, "Substrate Protocol for User 910 Datagrams (SPUD) Prototype," draft-hildebrand-spud- 911 prototype-03, Mar. 2015. 913 [RFC768] Postel, J., "User Datagram Protocol", RFC 768, August 914 1980. 916 [RFC791] Postel, J., "Internet Protocol," RFC 791, Sept. 1981. 918 [RFC793] Postel, J., "Transmission Control Protocol" RFC 793, 919 September 1981. 921 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -- 922 Communication Layers," RFC 1122, Oct. 1989. 924 [RFC1191] Mogul, J., S. Deering, "Path MTU discovery," RFC 1191, 925 November 1990. 927 [RFC1981] McCann, J., S. Deering, J. Mogul, "Path MTU Discovery for 928 IP version 6," RFC 1981, Aug. 1996. 930 [RFC2140] Touch, J., "TCP Control Block Interdependence," RFC 2140, 931 Apr. 1997. 933 [RFC2460] Deering, S., R. Hinden, "Internet Protocol Version 6 934 (IPv6) Specification," RFC 2460, Dec. 1998. 936 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery," RFC 937 2923, September 2000. 939 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 940 Internet Protocol", RFC 4301, Dec. 2005. 942 [RFC4340] Kohler, E., M. Handley, and S. Floyd, "Datagram Congestion 943 Control Protocol (DCCP)", RFC 4340, March 2006. 945 [RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol", 946 RFC 4960, September 2007. 948 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 949 Considered Useful," RFC 3692, Jan. 2004. 951 [RFC3828] Larzon, L-A., M. Degermark, S. Pink, L-E. Jonsson (Ed.), 952 G. Fairhurst (Ed.), "The Lightweight User Datagram 953 Protocol (UDP-Lite)," RFC 3828, July 2004. 955 [RFC5226] Narten, T., H. Alvestrand, "Guidelines for Writing an IANA 956 Considerations Section in RFCs," RFC 5226, May 2008. 958 [RFC5246] Dierks, T., E. Rescorla, "The Transport Layer Security 959 (TLS) Protocol Version 1.2," RFC 5246, Aug. 2008. 961 [RFC5925] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication 962 Option," RFC 5925, June 2010. 964 [RFC6347] Rescorla, E., N. Modadugu, "Datagram Transport Layer 965 Security Version 1.2," RFC 6347, Jan. 2012. 967 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)," 968 RFC 6691, July 2012. 970 [RFC6978] Touch, J., "A TCP Authentication Option Extension for NAT 971 Traversal", RFC 6978, July 2013. 973 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options," RFC 974 6994, Aug. 2013. 976 [RFC7323] Borman, D., R. Braden, V. Jacobson, R. Scheffenegger 977 (Ed.), "TCP Extensions for High Performance," RFC 7323, 978 Sep. 2014. 980 [RFC8085] Eggert, L., G. Fairhurst, G. Shepherd, "UDP Usage 981 Guidelines," RFC 8085, Feb. 2017. 983 [To16] Touch, J., "A TCP Authentication Option Extension for 984 Payload Encryption", Oct. 2016. 986 [To17] Touch, J., M. Welzl, S. Islam, J. You, "TCP Control Block 987 Interdependence," draft-touch-tcpm-2140bis, Jan. 2017. 989 [Tr15] Trammel, B. (Ed.), M. Kuelewind (Ed.), "Requirements for 990 the design of a Substrate Protocol for User Datagrams 991 (SPUD)," draft-trammell-spud-req-04, May 2016. 993 15. Acknowledgments 995 This work benefitted from feedback from Bob Briscoe, Ken Calvert, 996 Ted Faber, Gorry Fairhurst, C. M. Heard (including the FRAG/LITE 997 combination), Tom Herbert, and Mark Smith, as well as discussions on 998 the IETF SPUD email list. 1000 This work is partly supported by USC/ISI's Postel Center. 1002 This document was prepared using 2-Word-v2.0.template.dot. 1004 Authors' Addresses 1006 Joe Touch 1007 USC/ISI 1008 4676 Admiralty Way 1009 Marina del Rey, CA 90292 USA 1011 Phone: +1 (310) 448-9151 1012 Email: touch@isi.edu 1014 Appendix A. Implementation Information 1016 The following information is provided to encourage interoperable API 1017 implementations. 1019 System-level variables (sysctl): 1021 Name default meaning 1022 ---------------------------------------------------- 1023 net.ipv4.udp_opt 0 UDP options available 1024 net.ipv4.udp_opt_ocs 1 Default include OCS 1025 net.ipv4.udp_opt_acs 0 Default include ACS 1026 net.ipv4.udp_opt_lite 0 Default include LITE 1027 net.ipv4.udp_opt_mss 0 Default include MSS 1028 net.ipv4.udp_opt_time 0 Default include TIME 1029 net.ipv4.udp_opt_frag 0 Default include FRAG 1030 net.ipv4.udp_opt_ae 0 Default include AE 1032 Socket options (sockopt), cached for outgoing datagrams: 1034 Name meaning 1035 ---------------------------------------------------- 1036 UDP_OPT Enable UDP options (at all) 1037 UDP_OPT_OCS Enable UDP OCS option 1038 UDP_OPT_ACS Enable UDP ACS option 1039 UDP_OPT_LITE Enable UDP LITE option 1040 UDP_OPT_MSS Enable UDP MSS option 1041 UDP_OPT_TIME Enable UDP TIME option 1042 UDP_OPT_FRAG Enable UDP FRAG option 1043 UDP_OPT_AE Enable UDP AE option 1045 Send/sendto parameters: 1047 (TBD - currently using cached parameters) 1049 Connection parameters (per-socketpair cached state, part UCB): 1051 Name Initial value 1052 ---------------------------------------------------- 1053 opts_enabled net.ipv4.udp_opt 1054 ocs_enabled net.ipv4.udp_opt_ocs 1056 The following option is included for debugging purposes, and MUST 1057 NOT be enabled otherwise. 1059 System variables 1060 net.ipv4.udp_opt_junk 0 1062 System-level variables (sysctl): 1064 Name default meaning 1065 ---------------------------------------------------- 1066 net.ipv4.udp_opt_junk 0 Default use of junk 1068 Socket options (sockopt): 1070 Name params meaning 1071 ------------------------------------------------------ 1072 UDP_JUNK - Enable UDP junk option 1073 UDP_JUNK_VAL fillval Value to use as junk fill 1074 UDP_JUNK_LEN length Length of junk payload in bytes 1076 Connection parameters (per-socketpair cached state, part UCB): 1078 Name Initial value 1079 ---------------------------------------------------- 1080 junk_enabled net.ipv4.udp_opt_junk 1081 junk_value 0xABCD 1082 junk_len 4