idnits 2.17.1 draft-touch-tsvwg-udp-options-09.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 1081 has weird spacing: '...default mean...' == Line 1113 has weird spacing: '...enabled net.i...' == Line 1114 has weird spacing: '...enabled net....' == Line 1124 has weird spacing: '...default mean...' == Line 1130 has weird spacing: '... params mean...' == (1 more instance...) -- The document date (May 16, 2017) is 2530 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 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 TSVWG J. Touch 2 Internet Draft USC/ISI 3 Intended status: Standards Track May 16, 2017 4 Intended updates: 768 5 Expires: November 2017 7 Transport Options for UDP 8 draft-touch-tsvwg-udp-options-09.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, and it may not be 15 published except as an Internet-Draft. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on November 16, 2017. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. 47 Abstract 49 Transport protocols are extended through the use of transport header 50 options. This document experimentally extends UDP by indicating the 51 location, syntax, and semantics for UDP transport layer options. 53 Table of Contents 55 1. Introduction...................................................2 56 2. Conventions used in this document..............................3 57 3. Background.....................................................3 58 4. The UDP Option Area............................................4 59 5. UDP Options....................................................7 60 5.1. End of Options List (EOL).................................8 61 5.2. No Operation (NOP)........................................8 62 5.3. Option Checksum (OCS).....................................9 63 5.4. Alternate Checksum (ACS).................................10 64 5.5. Lite (LITE)..............................................10 65 5.6. Maximum Segment Size (MSS)...............................12 66 5.7. Timestamps (TIME)........................................13 67 5.8. Fragmentation (FRAG).....................................13 68 5.8.1. Coupling FRAG with LITE.............................16 69 5.9. Authentication and Encryption (AE).......................16 70 5.10. Experimental (EXP)......................................17 71 6. UDP API Extensions............................................17 72 7. Whose options are these?......................................18 73 8. UDP options vs. UDP-Lite......................................18 74 9. Interactions with Legacy Devices..............................19 75 10. Options in a Stateless, Unreliable Transport Protocol........20 76 11. UDP Option State Caching.....................................20 77 12. Security Considerations......................................21 78 13. IANA Considerations..........................................22 79 14. References...................................................22 80 14.1. Normative References....................................22 81 14.2. Informative References..................................22 82 15. Acknowledgments..............................................24 83 Appendix A. Implementation Information...........................26 85 1. Introduction 87 Transport protocols use options as a way to extend their 88 capabilities. TCP [RFC793], SCTP [RFC4960], and DCCP [RFC4340] 89 include space for these options but UDP [RFC768] currently does not. 90 This document defines an experimental extension to UDP that provides 91 space for transport options including their generic syntax and 92 semantics for their use in UDP's stateless, unreliable message 93 protocol. 95 2. Conventions used in this document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 In this document, these words will appear with that interpretation 102 only when in ALL CAPS. Lowercase uses of these words are not to be 103 interpreted as carrying significance described in RFC 2119. 105 In this document, the characters ">>" preceding an indented line(s) 106 indicates a statement using the key words listed above. This 107 convention aids reviewers in quickly identifying or finding the 108 portions of this RFC covered by these key words. 110 3. Background 112 Many protocols include a default header and an area for header 113 options. These options enable the protocol to be extended for use in 114 particular environments or in ways unforeseen by the original 115 designers. Examples include TCP's Maximum Segment Size, Window 116 Scale, Timestamp, and Authentication Options 117 [RFC793][RFC5925][RFC7323]. 119 These options are used both in stateful (connection-oriented, e.g., 120 TCP [RFC793], SCTP [RFC4960], DCCP [RFC4340]) and stateless 121 (connectionless, e.g., IPv4 [RFC791], IPv6 [RFC2460] protocols. In 122 stateful protocols they can help extend the way in which state is 123 managed. In stateless protocols their effect is often limited to 124 individual packets, but they can have an aggregate effect on a 125 sequence as well. One example of such uses is Substrate Protocol for 126 User Datagrams (SPUD) [Tr15], and this document is intended to 127 provide an out-of-band option area as an alternative to the in-band 128 mechanism currently proposed [Hi15]. 130 UDP is one of the most popular protocols that lacks space for 131 options [RFC768]. The UDP header was intended to be a minimal 132 addition to IP, providing only ports and a data checksum for 133 protection. This document experimentally extends UDP to provide a 134 trailer area for options located after the UDP data payload. 136 4. The UDP Option Area 138 The UDP transport header includes demultiplexing and service 139 identification (port numbers), a checksum, and a field that 140 indicates the UDP datagram length (including UDP header). The UDP 141 Length length field is typically redundant with the size of the 142 maximum space available as a transport protocol payload (see also 143 discussion in Section 9). 145 For IPv4, IP Total Length field indicates the total IP datagram 146 length (including IP header), and the size of the IP options is 147 indicated in the IP header (in 4-byte words) as the "Internet Header 148 Length" (IHL), as shown in Figure 1 [RFC791]. As a result, the 149 typical (and largest valid) value for UDP Length is: 151 UDP_Length = IPv4_Total_Length - IPv4_IHL * 4 153 For IPv6, the IP Payload Length field indicates the datagram after 154 the base IPv6 header, which includes the IPv6 extension headers and 155 space available for the transport protocol, as shown in Figure 2 156 [RFC2460]. Note that the Next HDR field in IPv6 might not indicate 157 UDP (i.e., 17), e.g., when intervening IP extension headers are 158 present. For IPv6, the lengths of any additional IP extensions are 159 indicated within each extension [RFC2460], so the typical (and 160 largest valid) value for UDP Length is: 162 UDP_Length = IPv6_Payload_Length - sum(extension header lengths) 164 In both cases, the space available for the UDP transport protocol 165 data unit is indicated by IP, either completely in the base header 166 (for IPv4) or adding information in the extensions (for IPv6). In 167 either case, this document will refer to this available space as the 168 "IP transport payload". 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 |Version| IHL |Type of Service| Total Length | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Identification |Flags| Fragment Offset | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Time to Live | Proto=17 (UDP)| Header Checksum | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Source Address | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Destination Address | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 ... zero or more IP Options (using space as indicated by IHL) ... 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | UDP Source Port | UDP Destination Port | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | UDP Length | UDP Checksum | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 Figure 1 IPv4 datagram with UDP transport payload 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 |Version| Traffic Class | Flow Label | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Payload Length | Next Hdr | Hop Limit | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 ... 196 | Source Address (128 bits) | 197 ... 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 ... 200 | Destination Address (128 bits) | 201 ... 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 ... zero or more IP Extension headers (each indicating size) ... 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | UDP Source Port | UDP Destination Port | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | UDP Length | UDP Checksum | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Figure 2 IPv6 datagram with UDP transport payload 212 As a result of this redundancy, there is an opportunity to use the 213 UDP Length field as a way to break up the IP transport payload into 214 two areas - that intended as UDP user data and an additional 215 "surplus area" (as shown in Figure 3). 217 IP transport payload 218 <-------------------------------------------------> 219 +--------+---------+----------------------+------------------+ 220 | IP Hdr | UDP Hdr | UDP user data | surplus area | 221 +--------+---------+----------------------+------------------+ 222 <------------------------------> 223 UDP Length 225 Figure 3 IP transport payload vs. UDP Length 227 In most cases, the IP transport payload and UDP Length point to the 228 same location, indicating that there is no surplus area. It is 229 important to note that this is not a requirement of UDP [RFC768] 230 (discussed further in Section 9). UDP-Lite used the difference in 231 these pointers to indicate the partial coverage of the UDP Checksum, 232 such that the UDP user data, UDP header, and UDP pseudoheader (a 233 subset of the IP header) are covered by the UDP checksum but 234 additional user data in the surplus area is not covered [RFC3828]. 235 This document uses the surplus area for UDP transport options. 237 The UDP option area is thus defined as the location between the end 238 of the UDP payload and the end of the IP datagram as a trailing 239 options area. This area can occur at any valid byte offset, i.e., it 240 need not be 16-bit or 32-bit aligned. In effect, this document 241 redefines the UDP "Length" field as a "trailer offset". 243 UDP options are defined using a TLV (type, length, and optional 244 value) syntax similar to that of TCP [RFC793]. They are typically a 245 minimum of two bytes in length as shown in Figure 4, excepting only 246 the one byte options "No Operation" (NOP) and "End of Options List" 247 (EOL) described below. 249 +--------+--------+ 250 | Kind | Length | 251 +--------+--------+ 253 Figure 4 UDP option default format 255 >> UDP options MAY occur at any UDP length offset. 257 >> The UDP length MUST be at least as large as the UDP header (8) 258 and no larger than the IP transport payload. Values outside this 259 range MUST be silently discarded as invalid and logged where rate- 260 limiting permits. 262 Others have considered using values of the UDP Length that is larger 263 than the IP transport payload as an additional type of signal. Using 264 a value smaller than the IP transport payload is expected to be 265 backward compatible with existing UDP implementations, i.e., to 266 deliver the UDP Length of user data to the application and silently 267 ignore the additional surplus area data. Using a value larger than 268 the IP transport payload would either be considered malformed (and 269 be silently dropped) or could cause buffer overruns, and so is not 270 considered silently and safely backward compatible. Its use is thus 271 out of scope for the extension described in this document. 273 >> UDP options MUST be interpreted in the order in which they occur 274 in the UDP option area. 276 5. UDP Options 278 The following UDP options are currently defined: 280 Kind Length Meaning 281 ---------------------------------------------- 282 0* - End of Options List (EOL) 283 1* - No operation (NOP) 284 2* 2 Option checksum (OCS) 285 3 4 Alternate checksum (ACS) 286 4 4 Lite (LITE) 287 5 4 Maximum segment size (MSS) 288 6 10 Timestamps (TIME) 289 7 12 Fragmentation (FRAG) 290 8 (varies) Authentication and Encryption (AE) 291 9-126 (varies) UNASSIGNED (assignable by IANA) 292 127-253 RESERVED 293 254 N(>=4) RFC 3692-style experiments (EXP) 294 255 RESERVED 296 These options are defined in the following subsections. 298 >> An endpoint supporting UDP options MUST support those marked with 299 a "*" above: EOL, NOP, and OCS. 301 [QUESTION: Should we extend these, e.g., through #7?] 303 >> All other options (without a "*") MAY be implemented, and their 304 use SHOULD be determined either out-of-band or negotiated. 306 >> Receivers MUST silently ignore unknown options. That includes 307 options whose length does not indicate the specified value. 309 Receivers cannot treat unexpected option lengths as invalid, as this 310 would unnecessarily limit future revision of options (e.g., defining 311 a new ACS that is defined by having a different length). 313 >> Option lengths MUST NOT exceed the IP length of the packet. If 314 this occurs, the packet MUST be treated as malformed and dropped, 315 and the event MAY be logged for diagnostics (logging SHOULD be rate 316 limited). 318 >> Required options MUST come before other options. Each required 319 option MUST NOT occur more than once (if they are repeated in a 320 received segment, all except the first MUST be silently ignored). 322 The requirement that required options come before others is intended 323 to allow for endpoints to implement DOS protection, as discussed 324 further in Section 12. 326 5.1. End of Options List (EOL) 328 The End of Options List (EOL) option indicates that there are no 329 more options. It is used to indicate the end of the list of options 330 without needing to pad the options to fill all available option 331 space. 333 +--------+ 334 | Kind=0 | 335 +--------+ 337 Figure 5 UDP EOL option format 339 >> When the UDP options do not consume the entire option area, the 340 last non-NOP option SHOULD be EOL (vs. filling the entire option 341 area with NOP values). 343 >> All bytes after EOL MUST be ignored by UDP option processing. As 344 a result, there can only ever be one EOL option (even if other bytes 345 were zero, they are ignored). 347 5.2. No Operation (NOP) 349 The No Operation (NOP) option is a one byte placeholder, intended to 350 be used as padding, e.g., to align multi-byte options along 16-bit 351 or 32-bit boundaries. 353 +--------+ 354 | Kind=1 | 355 +--------+ 357 Figure 6 UDP NOP option format 359 >> If options longer than one byte are used, NOP options SHOULD be 360 used at the beginning of the UDP options area to achieve alignment 361 as would be more efficient for active (i.e., non-NOP) options. 363 >> Segments SHOULD NOT use more than three consecutive NOPs. NOPs 364 are intended to assig with alignment, not other padding or fill. 366 [NOTE: Tom Herbert suggested we declare "more than 3 consecutive 367 NOPs" a fatal error to reduce the potential of using NOPs as a DOS 368 attack, but IMO there are other equivalent ways (e.g., using 369 RESERVED or other UNASSIGNED values) and the "no more than 3" 370 creates its own DOS vulnerability) 372 5.3. Option Checksum (OCS) 374 The Option Checksum (OCS) is an 8-bit ones-complement sum (Ones8) 375 that covers all of the UDP options. OCS is 8-bits to allow the 376 entire option to occupy a total of 16 bits. 378 OCS can be calculated by computing the 16-bit ones-complement sum 379 and "folding over" the result (using carry wraparound). Note that 380 OCS is direct, i.e., it is not negated or adjusted if zero (unlike 381 the Internet checksum as used in IPv4, TCP, and UDP headers). OCS 382 protects the option area from errors in a similar way that the UDP 383 checksum protects the UDP user data. 385 +--------+--------+ 386 | Kind=2 | Ones8 | 387 +--------+--------+ 389 Figure 7 UDP OCS option format 391 >> When present, the option checksum SHOULD occur as early as 392 possible, preferably preceded by only NOP options for alignment and 393 the LITE option if present. 395 OCS covers the entire UDP option, including the Lite option as 396 formatted before swapping for transmission (or, equivalently, after 397 the swap after reception). 399 >> If the option checksum fails, all options MUST be ignored and any 400 trailing surplus data (and Lite data, if used) silently discarded. 402 >> UDP data that is validated by a correct UDP checksum MUST be 403 delivered to the application layer, even if the UDP option checksum 404 fails, unless the endpoints have negotiated otherwise for this 405 segment's socket pair. 407 5.4. Alternate Checksum (ACS) 409 The Alternate Checksum (ACS) is a 16-bit CRC of the UDP payload only 410 (excluding the IP pseudoheader, UDP header, and UDP options). It 411 does not include the IP pseudoheader or UDP header, and so need not 412 be updated by NATs when IP addresses or UDP ports are rewritten. Its 413 purpose is to detect errors that the UDP checksum might not detect. 414 CRC-CCITT (polynomial x^16 + x^12 + x^5 + x or polynomial 0x1021) 415 has been chosen because of its ubiquity and use in other packet 416 protocols, such as X.25, HDLC, and Bluetooth. 418 +--------+--------+--------+--------+ 419 | Kind=3 | Len=4 | CRC16sum | 420 +--------+--------+--------+--------+ 422 Figure 8 UDP ACS option format 424 5.5. Lite (LITE) 426 The Lite option (LITE) is intended to provide equivalent capability 427 to the UDP Lite transport protocol [RFC3828]. UDP Lite allows the 428 UDP checksum to cover only a prefix of the UDP data payload, to 429 protect critical information (e.g., application headers) but allow 430 potentially erroneous data to be passed to the user. This feature 431 helps protect application headers but allows for application data 432 errors. Some applications are impacted more by a lack of data than 433 errors in data, e.g., voice and video. 435 >> When LITE is active, it MUST come first in the UDP options list. 437 LITE is intended to support the same API as for UDP Lite to allow 438 applications to send and receive data that has a marker indicating 439 the portion protected by the UDP checksum and the portion not 440 protected by the UDP checksum. 442 LITE includes a 2-byte offset that indicates the length of the 443 portion of the UDP data that is not covered by the UDP checksum. 445 +--------+--------+--------+--------+ 446 | Kind=5 | Len=4 | Offset | 447 +--------+--------+--------+--------+ 449 Figure 9 UDP LITE option format 451 At the sender, the option is formed using the following steps: 453 1. Create a LITE option, ordered as the first UDP option (Figure 454 10). 456 2. Calculate the location of the start of the options as an absolute 457 offset from the start of the UDP header and place that length in 458 the last two bytes of the LITE option. 460 3. Swap all four bytes of the LITE option with the first 4 bytes of 461 the LITE data area (Figure 11). 463 +---------+--------------+--------------+------------------+ 464 | UDP Hdr | user data | LITE data |LITE| other opts | 465 +---------+--------------+--------------+------------------+ 466 <----------------------> 467 UDP Length 469 Figure 10 LITE option formation - LITE goes first 471 +---------+--------------+--------------+------------------+ 472 | UDP Hdr | user data | LITE data |LITE| other opts | 473 +---------+--------------+--------------+------------------+ 474 ^^^^ ^^^^ 475 | | 476 +--------------+ 478 Figure 11 Before sending swap LITE option and front of LITE data 480 The resulting packet has the format shown in Figure 12. Note that 481 the UDP length now points to the LITE option, and the LITE option 482 points to the start of the option area. 484 +---------+--------------+----------------+------------------+ 485 | UDP Hdr | user data |LITE| LITE data |Ldat| other opts | 486 +---------+--------------+----------------+------------------+ 487 <----------------------> | ^ 488 UDP Length +-------------+ 490 Figure 12 Lite option as sent 492 A legacy endpoint receiving this packet will discard the LITE option 493 and everything that follows, including the lite data and remainder 494 of the UDP options. The UDP checksum will protect only the user 495 data, not the LITE option or lite data. 497 Receiving endpoints capable of processing UDP options will do the 498 following: 500 1. Process options as usual. This will start at the LITE option. 502 2. When the LITE option is encountered, record its location as the 503 start of the LITE data area and swap the four bytes there with 504 the four bytes at the location indicated inside the LITE option, 505 which indicates the start of all of the options, including the 506 LITE one (one past the end of the lite data area). This restores 507 the format of the option as per Figure 10. 509 3. Continue processing the remainder of the options, which are now 510 in the format shown in Figure 11. 512 The purpose of this swap is to support the equivalent of UDP Lite 513 operation together with other UDP options without requiring the 514 entire LITE data area to be moved after the UDP option area. 516 5.6. Maximum Segment Size (MSS) 518 The Maximum Segment Size (MSS, Kind = 3) is a 16-bit indicator of 519 the largest UDP segment that can be received. As with the TCP MSS 520 option [RFC793], the size indicated is the IP layer MTU decreased by 521 the fixed IP and UDP headers only [RFC6691]. The space needed for IP 522 and UDP options need to be adjusted by the sender when using the 523 value indicated. The value transmitted is based on EMTU_R, the 524 largest IP datagram that can be received (i.e., reassembled at the 525 receiver) [RFC1122]. 527 +--------+--------+--------+--------+ 528 | Kind=5 | Len=4 | MSS size | 529 +--------+--------+--------+--------+ 531 Figure 13 UDP MSS option format 533 The UDP MSS option MAY be used for path MTU discovery 534 [RFC1191][RFC1981], but this may be difficult because of known 535 issues with ICMP blocking [RFC2923] as well as UDP lacking automatic 536 retransmission. It is more likely to be useful when coupled with IP 537 source fragmentation to limit the largest reassembled UDP message, 538 e.g., when EMTU_R is larger than the required minimums (576 for IPv4 539 [RFC791] and 1500 for IPv6 [RFC2460]). 541 5.7. Timestamps (TIME) 543 The UDP Timestamp option (TIME) exchanges two four-byte timestamp 544 fields. It serves a similar purpose to TCP's TS option [RFC7323], 545 enabling UDP to estimate the round trip time (RTT) between hosts. 546 For UDP, this RTT can be useful for establishing UDP fragment 547 reassembly timeouts or transport-layer rate-limiting [RFC8085]. 549 +--------+--------+------------------+------------------+ 550 | Kind=6 | Len=10 | TS Value | TS Echo Reply | 551 +--------+--------+------------------+------------------+ 552 1 byte 1 byte 4 bytes 4 bytes 554 Figure 14 UDP TIME option format 556 TS Value (TSval) and TS Echo (TSecr) are used in a similar manner to 557 the TCP TS option [RFC7323]. A host using the Timestamp option sets 558 TS Value on all UDP segments issued. Received TSval values are 559 provided to the application, which passes this value as TSecr on UDP 560 messages sent in response to such a message. 562 >> UDP MAY use an RTT estimate based on nonzero Timestamp values as 563 a hint for fragmentation reassembly, rate limiting, or other 564 mechanisms that benefit from such an estimate. 566 >> UDP SHOULD make this RTT estimate available to the user 567 application. 569 5.8. Fragmentation (FRAG) 571 The Fragmentation option (FRAG) supports UDP fragmentation and 572 reassembly, which can be used to transfer UDP messages larger than 573 limited by the IP receive MTU (EMTU_R [RFC1122]). It is typically 574 used with the UDP MSS option to enable more efficient use of large 575 messages, both at the UDP and IP layers. FRAG is designed similar to 576 the IPv6 Fragmentation Header [RFC2460], except that the UDP variant 577 uses a 16-bit Offset measured in bytes, rather than IPv6's 13-bit 578 Fragment Offset measured in 8-byte units. This UDP variant avoids 579 creating reserved fields. 581 +--------+--------+--------+--------+ 582 | Kind=8 | Len=8 | Frag. Offset | 583 +--------+--------+--------+--------+ 584 | Identification | 585 +--------+--------+--------+--------+ 587 Figure 15 UDP non-terminal FRAG option format 589 The FRAG option also lacks a "more" bit, zeroed for the terminal 590 fragment of a set. This is possible because the terminal FRAG option 591 is indicated as a longer, 12-byte variant, which includes an 592 Internet checksum over the reassembled payload (omitting the IP 593 pseudoheader and UDP header, as well as UDP options), as shown in 594 Figure 16. 596 >> The reassembly checksum SHOULD be used, but MAY be unused in the 597 same situations when the UDP checksum is unused (e.g., for transit 598 tunnels or applications that have their own integrity checks 599 [RFC2460]), and by the same mechanism (set the field to 0x0000). 601 +--------+--------+--------+--------+ 602 | Kind=8 | Len=12 | Frag. Offset | 603 +--------+--------+--------+--------+ 604 | Identification | 605 +--------+--------+--------+--------+ 606 | Checksum | 607 +--------+--------+ 609 Figure 16 UDP terminal FRAG option format 611 The Fragment Offset is 16 bits and indicates the location of the UDP 612 payload fragment in bytes from the beginning of the original 613 unfragmented payload. The Len field indicates whether there are more 614 fragments (Len=8) or no more fragments (Len=12). 616 >> The Identification field is a 32-bit value that MUST be unique 617 over the expected fragment reassembly timeout. 619 >> The Identification field SHOULD be generated in a manner similar 620 to that of the IPv6 Fragment ID [RFC2460]. 622 >> UDP fragments MUST NOT overlap. 624 FRAG needs to be used with extreme care because it will present 625 incorrect datagram boundaries to a legacy receiver, unless encoded 626 as LITE data (see Section 5.8.1). 628 >> A host SHOULD indicate FRAG support by transmitting an 629 unfragmented datagram using the Fragmentation option (e.g., with 630 Offset zero and length 12, i.e., including the checksum area), 631 except when encoded as LITE. 633 >> A host MUST NOT transmit a UDP fragment before receiving recent 634 confirmation from the remote host, except when FRAG is encoded as 635 LITE. 637 UDP fragmentation relies on a fragment expiration timer, which can 638 be preset or could use a value computed using the UDP Timestamp 639 option. 641 >> The default UDP reassembly SHOULD be no more than 2 minutes. 643 Implementers are advised to limit the space available for UDP 644 reassembly. 646 >> UDP reassembly space SHOULD be limited to reduce the impact of 647 DOS attacks on resource use. 649 >> UDP reassembly space limits SHOULD NOT be implemented as an 650 aggregate, to avoid cross-socketpair DOS attacks. 652 >> Individual UDP fragments MUST NOT be forwarded to the user. The 653 reassembled datagram is received only after complete reassembly, 654 checksum validation, and continued processing of the remaining 655 options. 657 Any additional UDP options would follow the FRAG option in the final 658 fragment, and would be included in the reassembled packet. 659 Processing of those options would commence after reassembly. 661 >> UDP options MUST NOT follow the FRAG header in non-terminal 662 fragments. Any data following the FRAG header in non-terminal 663 fragments MUST be silently dropped. All other options that apply to 664 a reassembled packet MUST follow the FRAG header in the terminal 665 fragment. 667 5.8.1. Coupling FRAG with LITE 669 FRAG can be coupled with LITE to avoid impacting legacy receivers. 670 Each fragment is sent as LITE un-checksummed data, where each UDP 671 packet contains no legacy-compatible data. Legacy receivers 672 interpret these as zero-payload packets, which would not affect the 673 receiver unless the presence of the packet itself were a signal. The 674 header of such a packet would appear as shown in Figure 17 and 675 Figure 18. 677 +---------+--------------+---------+ 678 | UDP Hdr | LiteFrag |LITE|FRAG| 679 +---------+--------------+----+----+ 680 <-------> ^^^^ ^^^^ 681 Zero UDP Length | | 682 +--------------+ 684 Figure 17 Preparing FRAG as Lite data 686 +---------+--------------+----+ 687 | UDP Hdr |LITE|LiteFrag |FRAG| 688 +---------+--------------+----+ 689 <-------> | ^ 690 Zero UDP Length | | 691 +-------------+ 693 Figure 18 Lite option before transmission 695 When a packet is reassembled, it appears as a complete LITE data 696 region. The UDP header of the reassembled packet is adjusted 697 accordingly, so that the reassembled region now appears as 698 conventional UDP user data, and processing of the UDP options 699 continues, as with the non-LITE FRAG variant. 701 5.9. Authentication and Encryption (AE) 703 The Authentication and Encryption option (AE) is intended to allow 704 UDP to provide a similar type of authentication as the TCP 705 Authentication Option (TCP-AO) [RFC5925]. It uses the same format as 706 specified for TCP-AO, except that it uses a Kind of 8. UDP-AO 707 supports NAT traversal in a similar manner as TCP-AO [RFC6978]. UDP- 708 AO can also be extended to provide a similar encryption capability 709 as TCP-AO-ENC, in a similar manner [To17ao]. For these reasons, the 710 option is known as UDP-AE. 712 Like TCP-AO, UDP-AE is not negotiated in-band. Its use assumes both 713 endpoints have populated Master Key Tuples (MKTs), used to exclude 714 non-protected traffic. 716 TCP-AO generates unique traffic keys from a hash of TCP connection 717 parameters. UDP lacks a three-way handshake to coordinate 718 connection-specific values, such as TCP's Initial Sequence Numbers 719 (ISNs) [RFC793], thus UDP-AE's Key Derivation Function (KDF) uses 720 zeroes as the value for both ISNs. This means that the UDP-AE reuses 721 keys when socket pairs are reused, unlike TCP-AO. 723 5.10. Experimental (EXP) 725 The Experimental option (EXP) is reserved for experiments [RFC3692]. 726 Only one such value is reserved because experiments are expected to 727 use an Experimental ID (ExIDs) to differentiate concurrent use for 728 different purposes, using UDP ExIDs registered with IANA according 729 to the approach developed for TCP experimental options [RFC6994]. 731 >> The length of the experimental option MUST be at least 4 to 732 account for the Kind, Length, and the minimum 16-bit UDP ExID 733 identifier (similar to TCP ExIDs [RFC6994]). 735 6. UDP API Extensions 737 UDP currently specifies an application programmer interface (API), 738 summarized as follows (with Unix-style command as an example) 739 [RFC768]: 741 o Method to create new receive ports 743 o E.g., bind(handle, recvaddr(optional), recvport) 745 o Receive, which returns data octets, source port, and source 746 address 748 o E.g., recvfrom(handle, srcaddr, srcport, data) 750 o Send, which specifies data, source and destination addresses, and 751 source and destination ports 753 o E.g., sendto(handle, destaddr, destport, data) 755 This API is extended to support options as follows: 757 o Extend the method to create receive ports to include receive 758 options that are required. Datagrams not containing these 759 required options MUST be silently dropped and MAY be logged. 761 o Extend the receive function to indicate the options and their 762 parameters as received with the corresponding received datagram. 764 o Extend the send function to indicate the options to be added to 765 the corresponding sent datagram. 767 Examples of API instances for Linux and FreeBSD are provided in 768 Appendix A, to encourage uniform cross-platform implementations. 770 7. Whose options are these? 772 UDP options are indicated in an area of the IP payload that is not 773 used by UDP. That area is really part of the IP payload, not the UDP 774 payload, and as such, it might be tempting to consider whether this 775 is a generally useful approach to extending IP. 777 Unfortunately, the surplus area exists only for transports that 778 include their own transport layer payload length indicator. TCP and 779 SCTP include header length fields that already provide space for 780 transport options by indicating the total length of the header area, 781 such that the entire remaining area indicated in the network layer 782 (IP) is transport payload. UDP-Lite already uses the UDP Length 783 field to indicate the boundary between data covered by the transport 784 checksum and data not covered, and so there is no remaining area 785 where the length of the UDP-Lite payload as a whole can be indicated 786 [RFC3828]. 788 UDP options are intended for use only by the transport endpoints. 789 They are no more (or less) appropriate to be modified in-transit 790 than any other portion of the transport datagram. 792 UDP options are transport options. Generally, transport datagrams 793 are not intended to be modified in-transit. However, the UDP option 794 mechanism provides no specific protection against in-transit 795 modification of the UDP header, UDP payload, or UDP option area, 796 except as provided by the options selected (e.g., OCS, ACS, or AE). 798 8. UDP options vs. UDP-Lite 800 UDP-Lite provides partial checksum coverage, so that packets with 801 errors in some locations can be delivered to the user [RFC3828]. It 802 uses a different transport protocol number (136) than UDP (17) to 803 interpret the UDP Length field as the prefix covered by the UDP 804 checksum. 806 UDP (protocol 17) already defines the UDP Length field as the limit 807 of the UDP checksum, but by default also limits the data provided to 808 the application as that which precedes the UDP Length. A goal of 809 UDP-Lite is to deliver data beyond UDP Length as a default, which is 810 why a separate transport protocol number was required. 812 UDP options do not need a separate transport protocol number because 813 the data beyond the UDP Length offset (surplus data) is not provided 814 to the application by default. That data is interpreted exclusively 815 within the UDP transport layer. 817 UDP options support a similar service to UDP-Lite by terminating the 818 UDP options with an EOL option. The additional data not covered by 819 the UDP checksum follows that EOL option, and is passed to the user 820 separately. The difference is that UDP-Lite provides the un- 821 checksummed user data to the application by default, whereas UDP 822 options can provide the same capability only for endpoints that are 823 negotiated in advance (i.e., by default, UDP options would silently 824 discard this non-checksummed data). Additionally, in UDP-Lite the 825 checksummed and non-checksummed payload components are adjacent, 826 whereas in UDP options they are separated by the option area - 827 which, minimally, must consist of at least one EOL option. 829 UDP-Lite cannot support UDP options, either as proposed here or in 830 any other form, because the entire payload of the UDP packet is 831 already defined as user data and there is no additional field in 832 which to indicate a separate area for options. The UDP Length field 833 in UDP-Lite is already used to indicate the boundary between user 834 data covered by the checksum and user data not covered. 836 9. Interactions with Legacy Devices 838 It has always been permissible for the UDP Length to be inconsistent 839 with the IP transport payload length [RFC768]. Such inconsistency 840 has been utilized in UDP-Lite using a different transport number. 841 There are no known systems that use this inconsistency for UDP 842 [RFC3828]. It is possible that such use might interact with UDP 843 options, i.e., where legacy systems might generate UDP datagrams 844 that appear to have UDP options. The UDP OCS provides protection 845 against such events and is stronger than a static "magic number". 847 UDP options have been tested as interoperable with Linux, Max OS-X, 848 and Windows Cygwin, and worked through NAT devices. These systems 849 successfully delivered only the user data indicated by the UDP 850 Length field and silently discarded the surplus area. 852 One reported embedded device passes the entire IP datagram to the 853 UDP application layer. Although this feature could enable 854 application-layer UDP option processing, it would require that 855 conventional UDP user applications examine only the UDP payload. 856 This feature is also inconsistent with the UDP application interface 857 [RFC768] [RFC1122]. 859 It has been reported that Alcatel-Lucent's "Brick" Intrusion 860 Detection System has a default configuration that interprets 861 inconsistencies between UDP Length and IP Length as an attack to be 862 reported. Note that other firewall systems, e.g., CheckPoint, use a 863 default "relaxed UDP length verification" to avoid falsely 864 interpreting this inconsistency as an attack. 866 (TBD: test with UDP checksum offload and UDP fragmentation offload) 868 10. Options in a Stateless, Unreliable Transport Protocol 870 There are two ways to interpret options for a stateless, unreliable 871 protocol -- an option is either local to the message or intended to 872 affect a stream of messages in a soft-state manner. Either 873 interpretation is valid for defined UDP options. 875 It is impossible to know in advance whether an endpoint supports a 876 UDP option. 878 >> UDP options MUST allow for silent failure on first receipt. 880 >> UDP options that rely on soft-state exchange MUST allow for 881 message reordering and loss. 883 >> A UDP option MUST be silently optional until confirmed by 884 exchange with an endpoint. 886 The above requirements prevent using any option that cannot be 887 safely ignored unless that capability has been negotiated with an 888 endpoint in advance for a socket pair. Legacy systems would need to 889 be able to interpret the transport payload fragments as individual 890 transport datagrams. 892 11. UDP Option State Caching 894 Some TCP connection parameters, stored in the TCP Control Block, can 895 be usefully shared either among concurrent connections or between 896 connections in sequence, known as TCP Sharing [RFC2140][To17cb]. 897 Although UDP is stateless, some of the options proposed herein may 898 have similar benefit in being shared or cached. We call this UCB 899 Sharing, or UDP Control Block Sharing, by analogy. 901 [TBD: extend this section to indicate which options MAY vs. MUST NOT 902 be shared and how, e.g., along the lines of To17cb] 904 Updates to RFC 768 906 This document updates RFC 768 as follows: 908 o This document defines the meaning of the IP payload area beyond 909 the UDP length but within the IP length. 911 o This document extends the UDP API to support the use of options. 913 12. Security Considerations 915 The use of UDP packets with inconsistent IP and UDP Length fields 916 has the potential to trigger a buffer overflow error if not properly 917 handled, e.g., if space is allocated based on the smaller field and 918 copying is based on the larger. However, there have been no reports 919 of such vulnerability and it would rely on inconsistent use of the 920 two fields for memory allocation and copying. 922 UDP options are not covered by DTLS (datagram transport-layer 923 security). Despite the name, neither TLS [RFC5246] (transport layer 924 security, for TCP) nor DTLS [RFC6347] (TLS for UDP) protect the 925 transport layer. Both operate as a shim layer solely on the payload 926 of transport packets, protecting only their contents. Just as TLS 927 does not protect the TCP header or its options, DTLS does not 928 protect the UDP header or the new options introduced by this 929 document. Transport security is provided in TCP by the TCP 930 Authentication Option (TCP-AO [RFC5925]) or in UDP by the 931 Authentication Extension option (Section 5.9). Transport headers are 932 also protected as payload when using IP security (IPsec) [RFC4301]. 934 UDP options use the TLV syntax similar to that of TCP. This syntax 935 is known to require serial processing and may pose a DOS risk, e.g., 936 if an attacker adds large numbers of unknown options that must be 937 parsed in their entirety. Implementations concerned with the 938 potential for this vulnerability MAY implement only the required 939 options and MAY also limit NOPs (e.g., no more than three 940 consecutive NOPs or some total number that might occur between the 941 required options, if all are present). Because the required options 942 come first and at most once each (and all later duplicates silently 943 ignored), this limits the DOS impact. 945 13. IANA Considerations 947 Upon publication, IANA is hereby requested to create a new registry 948 for UDP Option Kind numbers, similar to that for TCP Option Kinds. 949 Initial values of this registry are as listed in Section 5. 950 Additional values in this registry are to be assigned by IESG 951 Approval or Standards Action [RFC5226]. 953 Upon publication, IANA is hereby requested to create a new registry 954 for UDP Experimental Option Experiment Identifiers (UDP ExIDs) for 955 use in a similar manner as TCP ExIDs [RFC6994]. This registry is 956 initially empty. Values in this registry are to be assigned by IANA 957 using first-come, first-served (FCFS) rules [RFC5226]. 959 14. References 961 14.1. Normative References 963 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 964 Requirement Levels", BCP 14, RFC 2119, March 1997. 966 [RFC768] Postel, J., "User Datagram Protocol", RFC 768, August 967 1980. 969 [RFC791] Postel, J., "Internet Protocol," RFC 791, Sept. 1981. 971 14.2. Informative References 973 [Hi15] Hildebrand, J., B. Trammel, "Substrate Protocol for User 974 Datagrams (SPUD) Prototype," draft-hildebrand-spud- 975 prototype-03, Mar. 2015. 977 [RFC793] Postel, J., "Transmission Control Protocol" RFC 793, 978 September 1981. 980 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -- 981 Communication Layers," RFC 1122, Oct. 1989. 983 [RFC1191] Mogul, J., S. Deering, "Path MTU discovery," RFC 1191, 984 November 1990. 986 [RFC1981] McCann, J., S. Deering, J. Mogul, "Path MTU Discovery for 987 IP version 6," RFC 1981, Aug. 1996. 989 [RFC2140] Touch, J., "TCP Control Block Interdependence," RFC 2140, 990 Apr. 1997. 992 [RFC2460] Deering, S., R. Hinden, "Internet Protocol Version 6 993 (IPv6) Specification," RFC 2460, Dec. 1998. 995 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery," RFC 996 2923, September 2000. 998 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 999 Internet Protocol", RFC 4301, Dec. 2005. 1001 [RFC4340] Kohler, E., M. Handley, and S. Floyd, "Datagram Congestion 1002 Control Protocol (DCCP)", RFC 4340, March 2006. 1004 [RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol", 1005 RFC 4960, September 2007. 1007 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1008 Considered Useful," RFC 3692, Jan. 2004. 1010 [RFC3828] Larzon, L-A., M. Degermark, S. Pink, L-E. Jonsson (Ed.), 1011 G. Fairhurst (Ed.), "The Lightweight User Datagram 1012 Protocol (UDP-Lite)," RFC 3828, July 2004. 1014 [RFC5226] Narten, T., H. Alvestrand, "Guidelines for Writing an IANA 1015 Considerations Section in RFCs," RFC 5226, May 2008. 1017 [RFC5246] Dierks, T., E. Rescorla, "The Transport Layer Security 1018 (TLS) Protocol Version 1.2," RFC 5246, Aug. 2008. 1020 [RFC5925] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication 1021 Option," RFC 5925, June 2010. 1023 [RFC6347] Rescorla, E., N. Modadugu, "Datagram Transport Layer 1024 Security Version 1.2," RFC 6347, Jan. 2012. 1026 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)," 1027 RFC 6691, July 2012. 1029 [RFC6978] Touch, J., "A TCP Authentication Option Extension for NAT 1030 Traversal", RFC 6978, July 2013. 1032 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options," RFC 1033 6994, Aug. 2013. 1035 [RFC7323] Borman, D., R. Braden, V. Jacobson, R. Scheffenegger 1036 (Ed.), "TCP Extensions for High Performance," RFC 7323, 1037 Sep. 2014. 1039 [RFC8085] Eggert, L., G. Fairhurst, G. Shepherd, "UDP Usage 1040 Guidelines," RFC 8085, Feb. 2017. 1042 [To17ao] Touch, J., "A TCP Authentication Option Extension for 1043 Payload Encryption", draft-touch-tcp-ao-encrypt, Apr. 1044 2017. 1046 [To17cb] Touch, J., M. Welzl, S. Islam, J. You, "TCP Control Block 1047 Interdependence," draft-touch-tcpm-2140bis, Jan. 2017. 1049 [Tr15] Trammel, B. (Ed.), M. Kuelewind (Ed.), "Requirements for 1050 the design of a Substrate Protocol for User Datagrams 1051 (SPUD)," draft-trammell-spud-req-04, May 2016. 1053 15. Acknowledgments 1055 This work benefitted from feedback from Bob Briscoe, Ken Calvert, 1056 Ted Faber, Gorry Fairhurst, C. M. Heard (including the FRAG/LITE 1057 combination), Tom Herbert, and Mark Smith, as well as discussions on 1058 the IETF TSVWG and SPUD email lists. 1060 This work is partly supported by USC/ISI's Postel Center. 1062 This document was prepared using 2-Word-v2.0.template.dot. 1064 Authors' Addresses 1066 Joe Touch 1067 USC/ISI 1068 4676 Admiralty Way 1069 Marina del Rey, CA 90292 USA 1071 Phone: +1 (310) 448-9151 1072 Email: touch@isi.edu 1074 Appendix A. Implementation Information 1076 The following information is provided to encourage interoperable API 1077 implementations. 1079 System-level variables (sysctl): 1081 Name default meaning 1082 ---------------------------------------------------- 1083 net.ipv4.udp_opt 0 UDP options available 1084 net.ipv4.udp_opt_ocs 1 Default include OCS 1085 net.ipv4.udp_opt_acs 0 Default include ACS 1086 net.ipv4.udp_opt_lite 0 Default include LITE 1087 net.ipv4.udp_opt_mss 0 Default include MSS 1088 net.ipv4.udp_opt_time 0 Default include TIME 1089 net.ipv4.udp_opt_frag 0 Default include FRAG 1090 net.ipv4.udp_opt_ae 0 Default include AE 1092 Socket options (sockopt), cached for outgoing datagrams: 1094 Name meaning 1095 ---------------------------------------------------- 1096 UDP_OPT Enable UDP options (at all) 1097 UDP_OPT_OCS Enable UDP OCS option 1098 UDP_OPT_ACS Enable UDP ACS option 1099 UDP_OPT_LITE Enable UDP LITE option 1100 UDP_OPT_MSS Enable UDP MSS option 1101 UDP_OPT_TIME Enable UDP TIME option 1102 UDP_OPT_FRAG Enable UDP FRAG option 1103 UDP_OPT_AE Enable UDP AE option 1105 Send/sendto parameters: 1107 (TBD - currently using cached parameters) 1109 Connection parameters (per-socketpair cached state, part UCB): 1111 Name Initial value 1112 ---------------------------------------------------- 1113 opts_enabled net.ipv4.udp_opt 1114 ocs_enabled net.ipv4.udp_opt_ocs 1116 The following option is included for debugging purposes, and MUST 1117 NOT be enabled otherwise. 1119 System variables 1120 net.ipv4.udp_opt_junk 0 1122 System-level variables (sysctl): 1124 Name default meaning 1125 ---------------------------------------------------- 1126 net.ipv4.udp_opt_junk 0 Default use of junk 1128 Socket options (sockopt): 1130 Name params meaning 1131 ------------------------------------------------------ 1132 UDP_JUNK - Enable UDP junk option 1133 UDP_JUNK_VAL fillval Value to use as junk fill 1134 UDP_JUNK_LEN length Length of junk payload in bytes 1136 Connection parameters (per-socketpair cached state, part UCB): 1138 Name Initial value 1139 ---------------------------------------------------- 1140 junk_enabled net.ipv4.udp_opt_junk 1141 junk_value 0xABCD 1142 junk_len 4