idnits 2.17.1 draft-fairhurst-tsvwg-udp-options-dplpmtud-03.txt: 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: ---------------------------------------------------------------------------- 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 == 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 (September 30, 2020) is 1297 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-08 -- Obsolete informational reference (is this intentional?): RFC 1063 (Obsoleted by RFC 1191) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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: April 3, 2021 September 30, 2020 7 Datagram PLPMTUD for UDP Options 8 draft-fairhurst-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 is a robust method for Path MTU Discovery (PMTUD) 16 that uses the UDP Options Packetization Layer (PL). It allows a 17 datagram application that uses this PL, to discover the largest size 18 of datagram that can be sent across a network path. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 3, 2021. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. DPLPMTUD for UDP Options . . . . . . . . . . . . . . . . . . 3 57 3.1. Confirmation of Connectivity across a Path . . . . . . . 3 58 3.2. Sending UDP-Options Probe Packets . . . . . . . . . . . . 3 59 3.2.1. Sending Packet Probes using the Echo Request Option 60 Request Option . . . . . . . . . . . . . . . . . . . 4 61 3.2.2. Sending Packet Probes that include Application Data . 5 62 3.3. Validating the Path with UDP Options . . . . . . . . . . 5 63 3.3.1. Sending Packet Probes using Timestamps . . . . . . . 6 64 3.4. PTB Message Handling for this Method . . . . . . . . . . 6 65 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 7.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 The User Datagram Protocol [RFC0768] offers a minimal transport 77 service on top of IP and is frequently used as a substrate for other 78 protocols. Section 3.5 of UDP Guidelines [RFC8085] recommends that 79 applications implement some form of Path MTU Discovery to avoid the 80 generation of IP fragments: 82 "Consequently, an application SHOULD either use the path MTU 83 information provided by the IP layer or implement Path MTU Discovery 84 (PMTUD)". 86 The UDP API [RFC8304] offer calls for applications to receive ICMP 87 Packet Too Big (PTB) messages and to control the maxmium size of 88 datagrams that are sent, but does not offer any automated mechanisms 89 for an application to discover the maximum packet size supported by a 90 path. Applications and upper layer protocols implement mechanisms 91 for path MTU discovery above the UDP API. 93 Packetization Layer PMTUD (PLPMTUD) [RFC4821] describes a method for 94 a Packetization Layer (PL) (such as UDP with options) to search for 95 the largest Packetization Layer PMTU (PLPMTU) supported on a path. 96 Datagram PLPMTUD (DPLPMTUD) [RFC8899] specifies this support for 97 datagram transports. PLPMTUD and DPLPMTUD use a probing mechanism 98 that does not solely rely on ICMP PTB messages and works in the 99 presence of lost probes. 101 UDP Options [I-D.ietf-tsvwg-udp-options] supplies functionality that 102 can be used to implement DPLPMTUD within the UDP transport service. 103 This document specifies this additional functionality. Implementing 104 DPLPMTUD using UDP Options avoids the need for each upper layer 105 protocol or application to implement the DPLPMTUD method. This 106 provides a standard method for applications to discover the current 107 maximum packet size for a path and to detect when this changes. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in BCP 14 [RFC2119] 114 [RFC8174] when, and only when, they appear in all capitals, as shown 115 here. 117 The structure of the present document follows the structure used to 118 describe DPLPMTUD for other transports [RFC8899]. 120 3. DPLPMTUD for UDP Options 122 The DPLPMTUD PL endpoint implements the method specified in 123 [RFC8899]. 125 3.1. Confirmation of Connectivity across a Path 127 The DPLPMTUD method requires a PL to be able to confirm connectivity 128 on the path (see Section 5.1.4 of [RFC8899]), but UDP does not offer 129 a mechanism for this. 131 UDP Options can provide this required functionality. A UDP Options 132 sender implementing this specification SHOULD elicit a positive 133 confirmation of connectivity of the path, using a suitable confirmed 134 UDP Option (i.e., Timestamps, ECHO Request/Response) to . 136 3.2. Sending UDP-Options Probe Packets 138 DPLPMTUD relies upon the ability of a sender PL to generate probe 139 packets with a specific size, and to confirm when these are delivered 140 across the path. Therefore, a UDP options sender needs to be able to 141 send probes up to the maximum for the size the local interface 142 supports, which MUST NOT be further constrained by the maximum PMTU 143 set by network layer mechanisms (such as PMTUD [RFC1063][RFC8201]). 145 DPLPMTUD needs to be able to generate probe packets that are not 146 delivered to the upper layer protocol as a part of the end-to-end 147 transport data (i.e. ensure any added padding data is not delivered 148 to the upper layer protocol at the receiver). UDP Options provide 149 the necessary additional support required to do this within the 150 transport layer. 152 There are various designs described in DPLPMTUD to send a Packet 153 Probe to test the size of packet supported by a path (see Section 4.1 154 of [RFC8899]). This prevents "Probing using padding data" or 155 "Probing using application data and padding data" (see Section 4.1 of 156 [RFC8899]). 158 A PL needs to determine whether the current path supports datagrams 159 used as Probe Packets. DPLPMTUD SHOULD send (or add) a UDP Option 160 (e.g., Timestamps, ECHO Request/Response) to a Packet Probe to elicit 161 a positive confirmation that the path has delivered the Probe Packet 162 of the corresponding size. From time to time, such probes can also 163 be used to determine whether the current path can support a larger 164 size of datagram that the current PLPMTU. 166 A PL also needs to determine that the current path supports the size 167 of datagram that the application is currently sending when in the 168 DPLPMTUD search_done state i.e., to detect black-holing of data (see 169 Section 4.2 of [RFC8899]). UDP Options can provide this by eliciting 170 a positive confirmation that the path has delivered a Datagram of the 171 corresponding size. 173 3.2.1. Sending Packet Probes using the Echo Request Option Request 174 Option 176 The RECOMMENDED method sends a Probe Packet with the Echo Request 177 Option (RES) together with any padding needed to inflate the required 178 size. The reception of this option generates an Echo Response Option 179 that confirms reception of each received Probe Packet. 181 Probe Packets consume network capacity and incur endpoint processing 182 (see Section 4.1 of [RFC8899]). Implementations ought to send a 183 Probe Packet with a Request Probe Option only when required by their 184 local DPLPMTUD state machine, i.e., when probing to grow the PLPMTU 185 or to confirm the current PLPMTU. 187 Implementations MAY track multiple requests and respond acknowledging 188 them with a single packet. 190 The UDP Options used in this method are described in section 6 of 191 [I-D.ietf-tsvwg-udp-options]: 193 o The Echo Request Option (RES) is set by a sending PL to solicit a 194 response from a remote endpoint. A four-byte token identifies 195 each request. 197 o The Echo Response Option (REQ) is generated by the UDP Options 198 receiver in response to reception of a previously received Echo 199 Request Option. Each Echo Response Option echoes a previously 200 received four-byte token. 202 The token value allows implementations to distinguish between 203 acknowledgements for initial Probe Packets and acknowledgements 204 confirming receipt of subsequent Probe Packets (e.g., travelling 205 along alternate paths with a larger round trip time). This needs 206 each Probe Packet needs to be uniquely identifiable by the UDP 207 Options sender within the Maximum Segment Lifetime (MSL). The UDP 208 Options sender therefore MUST NOT recycle token values until they 209 have expired or have been acknowledged. A four byte value for the 210 token field provides sufficient space for multiple unique probes to 211 be made within the MSL. 213 The initial value of the four byte token field SHOULD be assigned to 214 a randomised value to enhance protection from off-path attacks, as 215 described in section 5.1 of [RFC8085]). 217 The procedure to handle the loss of a datagram is the responsibility 218 of the sender of the request. Implementations MAY track multiple 219 requests and respond to them with a single packet carrying the Echo 220 Response Option (REQ). 222 3.2.2. Sending Packet Probes that include Application Data 224 The RECOMMENDED approach to generating a Probe Packet is to send a 225 probe formed of a UDP Options datagram contains only control 226 information, padded to the size required for the probe. This allows 227 "Probing using padding data", and avoids having to retransmit 228 application data when a probe fails. 230 If an application/transport needs protection from the loss of data in 231 the Probe Packet payload, the application/ transport could perform 232 transport-layer retransmission/repair of the data block (e.g., by 233 retransmission after loss is detected or by duplicating the data 234 block in a datagram without the padding) [RFC8085]. 236 3.3. Validating the Path with UDP Options 238 A PL also needs to validate that the path continues to support the 239 PLPMTU discovered in a previous search for a suitable PLPMTU value 240 (see Section 6.1.4 of [RFC8899]). This confirmation MAY be provided 241 by an upper layer protocol confirming correct reception of data by 242 the remote PL, but there is no generic mechanism to access this upper 243 layer information. 245 This function can be implemented within UDP Options, by generating a 246 Probe Packet of size PLPMTU to confirm the path. This Probe Packet 247 MUST elicit a response from the remote PL and could use either the 248 ECHO Response Option or the TimeStamp option (see Section 5.9 249 [I-D.ietf-tsvwg-udp-options]). 251 A sender MAY choose to include application data in Probe Packets (see 252 Section 4.1 of [RFC8899] discusses the merits and demerits of this 253 approach). For example, this might reduce the need to send an 254 additional datagram when confirming that the current path supports 255 datagrams of size PLPMTU. 257 3.3.1. Sending Packet Probes using Timestamps 259 Reception of a valid Timestamp Option echoed by the remote endpoint 260 can be used to infer connectivity. It can also confirm that packets 261 of the current size are being received by the remote PL. This can 262 provide useful feedback, even over paths with asymmetric capacity 263 and/or that carry UDP Option flows that have asymmetric datagram 264 rates, because an echo of the most recent timestamp still indicates 265 reception of at least one packet of the transmitted size. This is 266 sufficient to confirm there is no black hole (see Section 2.1 of 267 [RFC2923]). 269 When sending a probe to increase the PLPMTU, such a Timestamp might 270 be unable to unambiguously identify that a specific Probe Packet has 271 been received [KP87]. Timestamp mechanisms therefore cannot be used 272 to confirm the reception of individual probe messages and cannot be 273 used to stimulate a response from the remote peer. 275 Note: Probe Packets used to search for a larger PLPMTU MUST include 276 the Echo Request Option. 278 3.4. PTB Message Handling for this Method 280 A UDP Options sender can ignore received ICMP PTB messages, and this 281 support is OPTIONAL for use with DPLPMTUD. 283 A UDP Options sender that utilises ICMP PTB messages received to a 284 Probe Packet MUST use the quoted packet to validate the UDP port 285 information in combination with the token and/or timestamp value 286 contained in the UDP Option, before processing the packet using the 287 DPLPMTUD method (see Section 4.4.1 of [RFC8899]). An implementation 288 unable to support this validation needs to ignore received ICMP PTB 289 messages. 291 As in other implementations of DPLPMTUD, a PL implementing this 292 specification MUST suspend processing of ICMP PTB messages by the 293 network layer (as specified in PMTUD [RFC1191] [RFC8201]) for each 294 flow that utilises DPLPMTUD. 296 4. Acknowledgements 298 Gorry Fairhurst and Tom Jones are supported by funding provided by 299 the University of Aberdeen. 301 5. IANA Considerations 303 This memo includes no requests to IANA. 305 6. Security Considerations 307 The security considerations for using UDP Options are described in 308 [I-D.ietf-tsvwg-udp-options]. The proposed new method does not 309 change the integrity protection offered by the UDP options method. 311 The specification recommends that the token in the REQ/RES message is 312 initialised to a randomised value to enhance protection from off-path 313 attacks. 315 The security considerations for using DPLPMTUD are described in 316 [RFC8899]. The proposed new method does not change the ICMP PTB 317 message validation method described DPLPMTUD: A UDP Options sender 318 that utilises ICMP PTB messages received to a Probe Packet MUST use 319 the quoted packet to validate the UDP port information in combination 320 with the token and/or timestamp value contained in the UDP Option, 321 before processing the packet using the DPLPMTUD method. 323 7. References 325 7.1. Normative References 327 [I-D.ietf-tsvwg-udp-options] 328 Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- 329 udp-options-08 (work in progress), September 2019. 331 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 332 DOI 10.17487/RFC0768, August 1980, 333 . 335 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 336 DOI 10.17487/RFC1191, November 1990, 337 . 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", BCP 14, RFC 2119, 341 DOI 10.17487/RFC2119, March 1997, 342 . 344 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 345 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 346 May 2017, . 348 [RFC8899] Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and 349 T. Voelker, "Packetization Layer Path MTU Discovery for 350 Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, 351 September 2020, . 353 7.2. Informative References 355 [KP87] Karn, P. and C. Partridge, "Improving Round-Trip Time 356 Estimates in Reliable Transport Protocols", 1987. 358 [RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP 359 MTU discovery options", RFC 1063, DOI 10.17487/RFC1063, 360 July 1988, . 362 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 363 RFC 2923, DOI 10.17487/RFC2923, September 2000, 364 . 366 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 367 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 368 . 370 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 371 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 372 March 2017, . 374 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 375 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 376 DOI 10.17487/RFC8201, July 2017, 377 . 379 [RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the 380 User Datagram Protocol (UDP) and Lightweight UDP (UDP- 381 Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018, 382 . 384 Appendix A. Revision Notes 386 XXX Note to RFC-Editor: please remove this entire section prior to 387 publication. XXX 389 Individual draft-00. 391 o This version contains a description for consideration and comment 392 by the TSVWG. 394 Individual draft-01. 396 o Address Nits 398 o Change Probe Request and Probe Reponse options to Echo to align 399 names with draft-ietf-tsvwg-udp-options 401 o Remove Appendix B, Informative Description of new UDP Options 403 o Add additional sections around Probe Packet generation 405 Individual draft-02. 407 o Address Nits 409 Individual draft-03. 411 o Referenced DPLPMTUD RFC. 413 o Tidied language to clarify the method. 415 Authors' Addresses 417 Godred Fairhurst 418 University of Aberdeen 419 School of Engineering 420 Fraser Noble Building 421 Aberdeen AB24 3UE 422 UK 424 Email: gorry@erg.abdn.ac.uk 425 Tom Jones 426 University of Aberdeen 427 School of Engineering 428 Fraser Noble Building 429 Aberdeen AB24 3UE 430 UK 432 Email: tom@erg.abdn.ac.uk