idnits 2.17.1 draft-ietf-tsvwg-udp-options-dplpmtud-03.txt: -(417): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. 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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (25 February 2022) is 789 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) == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-udp-options-13 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Fairhurst 3 Internet-Draft T. Jones 4 Intended status: Standards Track University of Aberdeen 5 Expires: 29 August 2022 25 February 2022 7 Datagram PLPMTUD for UDP Options 8 draft-ietf-tsvwg-udp-options-dplpmtud-03 10 Abstract 12 This document specifies how a UDP Options sender implements Datagram 13 Packetization Layer Path Maximum Transmission Unit Discovery 14 (DPLPMTUD) as a robust method for Path Maximum Transmission Unit 15 discovery. This method uses the UDP Options packetization layer. It 16 allows a datagram application to discover the largest size of 17 datagram that can be sent across a specific network path. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 29 August 2022. 36 Copyright Notice 38 Copyright (c) 2022 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. DPLPMTUD for UDP Options . . . . . . . . . . . . . . . . . . 3 55 4. Sending UDP-Options Probe Packets . . . . . . . . . . . . . . 4 56 4.1. Sending Probe Packets using the Echo Request and Response 57 Options . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.2. DPLPMTUD Procedures for UDP Options . . . . . . . . . . . 5 59 4.2.1. Confirmation of Connectivity across a Path . . . . . 5 60 4.2.2. Sending Probe Packets to Increase the PLPMTU . . . . 6 61 4.2.3. Validating the Path with UDP Options . . . . . . . . 6 62 4.2.4. Probe Packets that do not include Application Data . 7 63 4.2.5. Probe Packets that include Application Data . . . . . 7 64 4.2.6. Changes in the Path . . . . . . . . . . . . . . . . . 7 65 4.3. PTB Message Handling for this Method . . . . . . . . . . 8 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 71 8.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 The User Datagram Protocol [RFC0768] offers a minimal transport 78 service on top of IP and is frequently used as a substrate for other 79 protocols. Section 3.5 of UDP Guidelines [RFC8085] recommends that 80 applications implement some form of Path MTU discovery to avoid the 81 generation of IP fragments: 83 "Consequently, an application SHOULD either use the path MTU 84 information provided by the IP layer or implement Path MTU Discovery 85 (PMTUD)". 87 The UDP API [RFC8304] offers calls for applications to receive ICMP 88 Packet Too Big (PTB) messages and to control the maximum size of 89 datagrams that are sent, but does not offer any automated mechanisms 90 for an application to discover the maximum packet size supported by a 91 path. Upper layer protocols (which can include applications) 92 implement mechanisms for Path MTU discovery above the UDP API. 94 Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] describes 95 a method for a Packetization Layer (PL) (such as UDP Options) to 96 search for the largest Packetization Layer PMTU (PLPMTU) supported on 97 a path. Datagram PLPMTUD (DPLPMTUD) [RFC8899] specifies this support 98 for datagram transports. PLPMTUD and DPLPMTUD gain robustness by 99 using a probing mechanism that does not solely rely on ICMP PTB 100 messages and works on paths that drop ICMP PTB messages. 102 This document specifies how UDP Options [I-D.ietf-tsvwg-udp-options] 103 can be used as a PL to implement DPLPMTUD (see Section 6.1 of 104 [RFC8899]). In summary, UDP Options [I-D.ietf-tsvwg-udp-options] 105 supplies functionality that can be used to implement DPLPMTUD within 106 the UDP transport service. Implementing DPLPMTUD using UDP Options 107 avoids the need for each upper layer protocol or application to 108 implement the DPLPMTUD method. This provides a standard method for 109 applications to discover the current maximum packet size for a path 110 and to detect when this changes. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in BCP 14 [RFC2119] 117 [RFC8174] when, and only when, they appear in all capitals, as shown 118 here. 120 This document uses the terms defined for DPLPMTUD (see Sections 2 and 121 5 of [RFC8899] 123 3. DPLPMTUD for UDP Options 125 There are two ways an upper PL can perform DPLPMTUD: 127 * The UDP Options sender implementing DPLPMTUD uses the method 128 specified in [RFC8899] and the upper PL (or application) does not 129 perform PMTU discovery. In this case, UDP Options processing is 130 responsible for sending probes to determine a PLPMTU, as described 131 in this document. "An application SHOULD avoid using DPLPMTUD 132 when the underlying transport system provides this capability" 133 (Section 6.1 of [RFC8899]). This discovered PLPMTU can be used by 134 UDP Options to either: 136 - set the maximum datagram size for the current path (based on 137 the discovered largest IP packet that can be received across 138 the current path). 140 - set the maximum fragment size when a sender uses the UDP 141 Fragmentation Option to divide a datagram into multiple UDP 142 fragments for transmission. Each UDP fragment is then less 143 than the discovered largest IP packet that can be received 144 across the current path. 146 * An upper PL (or application) performs DPLPMTUD (e.g., QUIC 147 [RFC9000]). This upper PL then uses probes to determine a safe 148 PLPMTU for the datagrams that it sends. The format and content of 149 any probe is determined by the upper PL. Such a design should 150 avoid performing discovery at multiple levels, so, when 151 configurable, this upper PL SHOULD disable DPLPMTUD by UDP 152 Options. 154 The packet formats and procedures for DPLPMTUD using UDP Options are 155 described in this document. 157 4. Sending UDP-Options Probe Packets 159 DPLPMTUD relies upon the ability of a UDP Options sender to generate 160 a probe with a specific size, up to the maximum for the size 161 supported by a local interface. This MUST NOT be constrained by the 162 maximum PMTU set by network layer mechanisms (such as PMTUD 163 [RFC1191][RFC8201] or the PMTU size held in the IP- layer cache), as 164 noted in bullet 2 of Section 3 in [RFC8899]). 166 Probe packets consume network capacity and incur endpoint processing 167 (see Section 4.1 of [RFC8899]). Implementations ought to send a 168 probe with an REQ Option only when required by their local DPLPMTUD 169 state machine, i.e., when confirming the base PMTU for the path, 170 probing to increase the PLPMTU or to confirm the current PLPMTU. 172 4.1. Sending Probe Packets using the Echo Request and Response Options 174 A UDP Options node that supports DPLPMTUD MUST support sending and 175 receiving of the REQ Option and the RES Option. When not supported, 176 DPLPMTUD will be unable to confirm the Path or to discover the PMTU. 178 [RFC8899] (Section 3, item 2) requires the network interface below 179 the PL to provide a way to transmit a probe packet that is larger 180 than the PLPMTU without network layer endpoint fragmentation. This 181 document adds to this: UDP datagrams used as DPLPMTUD probes as 182 described in this document MUST NOT be fragmented at the UDP layer. 184 This section describes a format of probe consisting of an empty UDP 185 datagram, UDP Options area and Padding. 187 A Probe Packet includes the UDP Options area containing a RES Option 188 and any other required options concluded with an EOL Option followed 189 by any padding needed to inflate to the required probe size. 191 The UDP Options used in this document are described in Section 5.11 192 of [I-D.ietf-tsvwg-udp-options]: 194 * The REQ Option is set by a sending PL to solicit a response from a 195 remote UDP Options receiver. A four-byte token identifies each 196 request. 198 * The RES Option is generated by the UDP Options receiver in 199 response to a previously received REQ Option. Each RES Option 200 echoes a previously received four-byte token. 202 * Reception of a RES Option confirms that a specific probe has been 203 received by the remote UDP Options receiver. 205 The token allows a sender to distinguish between acknowledgements for 206 initial probes and acknowledgements confirming receipt of subsequent 207 probes (e.g., travelling along alternate paths with a larger round 208 trip time). This needs each probe to be uniquely identifiable by the 209 UDP Options sender within the Maximum Segment Lifetime (MSL). The 210 UDP Options sender therefore MUST NOT recycle token values until they 211 have expired or have been acknowledged. A four byte value for the 212 token field provides sufficient space for multiple unique probes to 213 be made within the MSL. Since UDP Options operates over UDP, the 214 token values only need to be unique for the specific 5-tuple over 215 which DPLPMTUD is operating. 217 The value of the four byte token field SHOULD be initialised to a 218 randomised value to enhance protection from off-path attacks, as 219 described in Section 5.1 of [RFC8085]). 221 Like other UDP options, each of the two option kinds MUST NOT appear 222 more than once in each UDP datagram. 224 4.2. DPLPMTUD Procedures for UDP Options 226 DPLPMTUD utilises three types of probes. These are described in the 227 following sections: 229 * A probe to confirm the path can support the BASE_PLPMTU (see 230 Section 5.1.4 of [RFC8899]). 232 * A probe to detect whether the path can support a larger PLPMTU. 234 * A probe to validate the path supports the current PLPMTU. 236 4.2.1. Confirmation of Connectivity across a Path 238 The DPLPMTUD method requires a PL to confirm connectivity over the 239 path using the BASE_PLPMTU (see Section 5.1.4 of [RFC8899]), but UDP 240 does not offer a mechanism for this. 242 UDP Options can provide this required functionality. A UDP Options 243 sender implementing this specification MUST elicit a positive 244 confirmation of connectivity for the path, by sending a probe, padded 245 to size BASE_PLPMTU. This confirmation probe MUST include a UDP 246 option that elicits a response from the remote endpoint (e.g., by 247 including the RES and REQ Options) to confirm that a packet of the 248 size traversed the path. This also confirms that the remote receiver 249 supports use of the RES and REQ Options. 251 4.2.2. Sending Probe Packets to Increase the PLPMTU 253 From time to time, DPLPMTUD enters the SEARCHING state [RFC8899] 254 (e.g., after expiry of the PMTU_RAISE_TIMER) to detect whether the 255 current path can support a larger PLPMTU. When the remote endpoint 256 advertises a UDP Maximum Segment Size (MSS) option, this value can be 257 used as a hint to initialise this search to increase the PLPMTU. 259 Probe packets seeking to increase the PLPMTU SHOULD NOT carry 260 application data (see "Probing using padding data" in Section 4.1 of 261 [RFC8899]), since they will be lost whenever their size exceeds the 262 actual PMTU. 264 A probe seeking to increase the PLPMTU needs to elicit a positive 265 acknowledgment that the path has delivered a datagram of the specific 266 probed size and, therefore, MUST include the REQ Option. 268 Received probes that do not carry application data do not form a part 269 of the end-to-end transport data and are not delivered to the upper 270 layer protocol. 272 4.2.3. Validating the Path with UDP Options 274 A PL using DPLPMTUD needs to validate that a path continues to 275 support the PLPMTU discovered in a previous search for a suitable 276 PLPMTU value (see Section 6.1.4 of [RFC8899]). This validation sends 277 probes in the DPLPMTUD SEARCH_COMPLETE state to detect black-holing 278 of data (see Section 4.2 of [RFC8899]). 280 This function can be implemented within UDP Options, by generating a 281 probe of size PLPMTU, which MUST include a REQ Option to elicit a 282 positive confirmation whether the path has delivered the probe. This 283 confirmation probe MAY use "Probing using padding data" or "Probing 284 using application data and padding data" (see Section 4.1 of 285 [RFC8899]) or can construct a probe packet that does not carry any 286 application data, as described in a previous section. 288 4.2.4. Probe Packets that do not include Application Data 290 A simple implementation of the method might be designed to only probe 291 packets formed of a UDP datagram that include no application data. 292 Each probe packet is padded to the required probe size including the 293 REQ Option. This implements "Probing using padding data"(Section 4.1 294 of [RFC8899]), and avoids having to retransmit application data when 295 a probe fails. In this use, the probe packets do not form a part of 296 the end-to-end transport data and a receiver does not deliver them to 297 the upper layer protocol. 299 4.2.5. Probe Packets that include Application Data 301 An implementation always uses the format in the previous section when 302 DPLPMTUD searches to increase the PLPMTU. 304 An alternative format is permitted for a probe that confirms 305 connectivity or that validates the path. These probes are permitted 306 to carry application data. (The data is permitted because these 307 probes perform blackhole detection and will therefore usually have a 308 higher probability of successful transmission, similar to other 309 packets sent by the upper layer protocol.) Section 4.1 of [RFC8899] 310 provides a discussion of the merits and demerits of including 311 application data. For example, this reduces the need to send 312 additional datagrams. 314 The probe could utilise a control message format defined by the upper 315 layer protocol that does not need to be delivered reliably. The RES 316 and REQ Options need to be included by the sending upper layer 317 protocol and the values of the tokens need to be coordinated with 318 values used for other DPLPMTUD probe packets. The DPLPMTUD method 319 tracks the transmission and reception of these probe packets. Probes 320 with this format form a part of the end-to-end transport data and a 321 receiver needs to deliver the RES and REQ Options to the upper layer 322 protocol. 324 4.2.6. Changes in the Path 326 A change in the path or the loss of probe packets can result in a 327 change of the PLPMTU. DPLPMTUD [RFC8899] recommends that methods are 328 robust to path changes that could have occurred since the path 329 characteristics were last confirmed and to the possibility of 330 inconsistent path information being received. For example, a 331 notification that a path could have changed could trigger path 332 validation to provide black hole protection Section 4.3 of 333 [RFC8899]). 335 Section 3 of [RFC8899] requires any methods designed to share the 336 PLPMTU between PLs (such as updating the IP cache PMTU for an 337 interface/destination) to be robust to the wide variety of underlying 338 network forwarding behaviors. For example, an implementation could 339 avoid sharing PMTU information that could potentially relate to 340 packets sent with the same address over a different interface. 342 4.3. PTB Message Handling for this Method 344 Support for receiving ICMP PTB messages is OPTIONAL for use with 345 DPLPMTUD. A UDP Options sender can therefore ignore received ICMP 346 PTB messages. 348 A UDP Options sender that utilises ICMP PTB messages received in 349 response to a probe packet MUST use the quoted packet to validate the 350 UDP port information in combination with the token contained in the 351 UDP Option, before processing the packet using the DPLPMTUD method. 352 Section 4.6.1 of [RFC8899] specifies this validation procedure. An 353 implementation unable to support this validation needs to ignore 354 received ICMP PTB messages. 356 5. Acknowledgements 358 Gorry Fairhurst and Tom Jones are supported by funding provided by 359 the University of Aberdeen. 361 6. IANA Considerations 363 This memo includes no requests to IANA. 365 7. Security Considerations 367 The security considerations for using UDP Options are described in 368 [I-D.ietf-tsvwg-udp-options]. The proposed new method does not 369 change the integrity protection offered by the UDP options method. 371 The security considerations for using DPLPMTUD are described in 372 [RFC8899]. On path attackers could maliciously drop or modify probe 373 packets to seek to decrease the PMTU, or to maliciously modify probe 374 packets in an attempt to blackhole traffic. 376 The specification recommends that the nonce value in the REQ Option 377 is initialised to a randomised value. This is designed to enhance 378 protection from off-path attacks. If subsequent probes use a nonce 379 value that is easily derived from the initial value, (e.g., 380 incrementing the value) then a misbehaving on-path node could then 381 determine the nonce for subsequent probes from that sender, even if 382 these probes are not transiting via the misbehaving node. This would 383 allow probe packets to be forged, with an impact similar to other on- 384 path attacks against probe packets. This attack could be mitigated 385 by using an unpredictable nonce value for each probe. 387 The proposed new method does not change the ICMP PTB message 388 validation method described by DPLPMTUD: A UDP Options sender that 389 utilities ICMP PTB messages received to a probe packet MUST use the 390 quoted packet to validate the UDP port information in combination 391 with the token contained in the UDP Option, before processing the 392 packet using the DPLPMTUD method. 394 8. References 396 8.1. Normative References 398 [I-D.ietf-tsvwg-udp-options] 399 Touch, J. D., "Transport Options for UDP", Work in 400 Progress, Internet-Draft, draft-ietf-tsvwg-udp-options-13, 401 19 June 2021, . 404 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 405 DOI 10.17487/RFC0768, August 1980, 406 . 408 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 409 Requirement Levels", BCP 14, RFC 2119, 410 DOI 10.17487/RFC2119, March 1997, 411 . 413 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 414 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 415 May 2017, . 417 [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. 418 Völker, "Packetization Layer Path MTU Discovery for 419 Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, 420 September 2020, . 422 8.2. Informative References 424 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 425 DOI 10.17487/RFC1191, November 1990, 426 . 428 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 429 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 430 . 432 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 433 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 434 March 2017, . 436 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 437 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 438 DOI 10.17487/RFC8201, July 2017, 439 . 441 [RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the 442 User Datagram Protocol (UDP) and Lightweight UDP (UDP- 443 Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018, 444 . 446 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 447 Multiplexed and Secure Transport", RFC 9000, 448 DOI 10.17487/RFC9000, May 2021, 449 . 451 Appendix A. Revision Notes 453 XXX Note to RFC-Editor: please remove this entire section prior to 454 publication. XXX 456 Individual draft-00. 458 * This version contains a description for consideration and comment 459 by the TSVWG. 461 Individual draft-01. 463 * Address Nits 465 * Change Probe Request and Probe Reponse options to Echo to align 466 names with draft-ietf-tsvwg-udp-options 468 * Remove Appendix B, Informative Description of new UDP Options 470 * Add additional sections around Probe Packet generation 472 Individual draft-02. 474 * Address Nits 476 Individual draft-03. 478 * Referenced DPLPMTUD RFC. 480 * Tidied language to clarify the method. 482 Individual draft-04 484 * Reworded text on probing with data a little 486 * Removed paragraph on suspending ICMP PTB suspension. 488 Working group draft-00 490 * -00 First Working Group Version 492 * RFC8899 call search_done SEARCH_COMPLETE, fix 494 Working group draft -01 496 * Update to reflect new fragmentation design in UDP Options. 498 * Add a description of uses of DPLPMTUD with UDP Options. 500 * Add a description on how to form probe packets with padding. 502 * Say that MSS options can be used to initialise the search 503 algorithm. 505 * Say that the recommended approach is to not use user data for 506 probes. 508 * Attempts to clarify and improve wording throughout. 510 * Remove text saying you can respond to multiple probes in a single 511 packet. 513 * Simplified text by removing options that don't yield benefit. 515 Working group draft -02 517 * Update to reflect comments from MED. 519 * More consistent description of DPLPMTUD with UDP Options. 521 * Clarify the nonce value (token) is intended per 5-tuple, not 522 interface. 524 * BASE_PLPMTU related to RFC8899. 526 * Probes with user data can carry application control data. 528 * Added that application data uses RES and REQ nonce (token) values 529 from the app. 531 * QUIC was intended as an informational reference to an example of 532 RFC8899. 534 Working group draft -03 536 * Update to reflect more comments from MED. 538 * Again more consistent description of DPLPMTUD with UDP Options. 540 * Clarify token/nonce to use "token". 542 * Clarify any use of application data for blackhole detection. 544 * Minor changes to reflect update to UDP Options base spec. 546 Authors' Addresses 548 Godred Fairhurst 549 University of Aberdeen 550 School of Engineering 551 Fraser Noble Building 552 Aberdeen 553 AB24 3UE 554 United Kingdom 555 Email: gorry@erg.abdn.ac.uk 557 Tom Jones 558 University of Aberdeen 559 School of Engineering 560 Fraser Noble Building 561 Aberdeen 562 AB24 3UE 563 United Kingdom 564 Email: tom@erg.abdn.ac.uk