idnits 2.17.1 draft-fairhurst-tsvwg-udp-options-dplpmtud-00.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 (April 25, 2019) is 1829 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 (-22) exists of draft-ietf-tsvwg-datagram-plpmtud-07 == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-udp-options-07 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: October 27, 2019 April 25, 2019 7 Datagram PLPMTUD for UDP Options 8 draft-fairhurst-tsvwg-udp-options-dplpmtud-00 10 Abstract 12 This document describes how a UDP Options sender may implement 13 Datagram Packetization Layer Path Maximum Transmission Unit Discovery 14 (DPLPMTUD) as a robust method for Path Maximum Transmission Unit 15 Discovery. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on October 27, 2019. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. DPLPMTUD for UDP Options . . . . . . . . . . . . . . . . . . 3 54 3.1. Sending Packet Probes using Control Information . . . . . 4 55 3.2. Sending Packet Probes using Application Data . . . . . . 5 56 3.3. Validating the Path with UDP Options . . . . . . . . . . 5 57 3.4. Handling of PTB Messages by UDP Options . . . . . . . . . 5 58 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 63 7.2. Informative References . . . . . . . . . . . . . . . . . 7 64 Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 7 65 Appendix B. Informative Description of new UDP Options . . . . . 7 66 B.1. UDP Probe Request Option . . . . . . . . . . . . . . . . 7 67 B.2. UDP Probe Response Option . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 The User Datagram Protocol [RFC0768] offers a minimal transport 73 service on top of IP and is frequently used as a substrate for other 74 protocols. Applications using UDP frequently have to implement basic 75 transport services such as Path Maximum Transmission Unit Discovery 76 (PMTUD) themselves. Section 3.5 of UDP Guidelines ([RFC8085]) 77 recommends that applications implement some form of Path MTU 78 Discovery to avoid the generation of IP fragments: 80 "Consequently, an application SHOULD either use the path MTU 81 information provided by the IP layer or implement Path MTU Discovery 82 (PMTUD)". 84 The UDP API [RFC8304] offers calls for applications to receive ICMP 85 Packet Too Big (PTB) messages and to control the size of messages 86 that are sent, but does not offer any automatic mechanisms for an 87 application to discover the maximum packet size supported by a path. 88 Applications and upper layer protocols are left to implement robust 89 PMTUD mechanisms of their own. 91 Packetization Layer PMTUD (PLPMTUD) [RFC4821] describes a method for 92 a Packetization Layer (such as UDP with options) to search for the 93 largest MTU supported on a path in the absence of ICMP PTB messages. 94 Datagram PLPMTUD [I-D.ietf-tsvwg-datagram-plpmtud] describes PMTUD 95 probing and search algorithms for datagram transports that does not 96 solely rely on ICMP PTB messages. This allows the Packetization 97 Layer to offer a probing mechanism which works in the presence of 98 lost probes. However, UDP is unable itself to offer the required 99 probing mechanisms to implement DPLPMTUD without some additional 100 transport services. This document specifies the additional 101 functionality required to perform DPLPMTUD with UDP Options as a 102 service to upper-layer protocols. 104 The authors solicit comments from the TSV working group. The working 105 group could decide to incorporate the text in the current 106 contribution into subsequent versions of the UDP Options 107 Specification. 109 The structure of the present document follows the structure used to 110 describe DPLPMTUD for other transports 111 [I-D.ietf-tsvwg-datagram-plpmtud]. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in BCP 14 [RFC2119] 118 [RFC8174] when, and only when, they appear in all capitals, as shown 119 here. 121 3. DPLPMTUD for UDP Options 123 UDP Options[I-D.ietf-tsvwg-udp-options] supplies additional 124 functionality that can be used to implement DPLPMTUD within the UDP 125 transport service. Implementing DPLPMTUD using UDP Options avoids 126 the need for each upper layer protocol or application to implement 127 the DPLPMTUD method. 129 Section 5.6 of[I-D.ietf-tsvwg-udp-options] defines the Maximum 130 Segment Size (MSS) option, which allows the local sender to indicate 131 the EMTU_R to the peer. The value received in this option can be 132 used to initialise MAX_PMTU used by DPLPMTUD. 134 The DPLPMTUD method [I-D.ietf-tsvwg-datagram-plpmtud] relies upon the 135 sender Packetization Layer to be able to generate probe packets with 136 a specific size. UDP Options enables padding to be added to a UDP 137 datagram that is used as these Probe Packets. Feedback confirming 138 reception of each Probe Packet is provided by two UDP Options 139 described in section 6 of [I-D.ietf-tsvwg-udp-options]: 141 o The Probe Request Option (Appendix B.1) is set by a sending PL to 142 solicit a response from a remote endpoint. A four-byte token 143 identifies each request. 145 o The Probe Response Option (Appendix B.2 is generated by the UDP 146 Options receiver in response to reception of a previously received 147 Probe Request Option. Each Probe Response Option echoes a 148 previously received four-byte token. 150 The token value allows implementations to be distinguish between 151 acknowledgements for initial probe packets and acknowledgements 152 confirming receipt of subsequent probe packets (e.g., travelling 153 along alternate paths with a larger RTT). Each probe packet needs to 154 be uniquely identifiable by the UDP Options sender within the Maximum 155 Segment Lifetime (MSL). The UDP Options sender therefore needs to 156 not recycle token values until they have expired or have been 157 acknowledged. A four byte value for the token field provides 158 sufficient space for multiple unique probes to be made within the 159 MSL. 161 The initial value of the four byte token field SHOULD be assigned to 162 a randomised value, as described in section 5.1 of [RFC8085]) to 163 enhance protection from off-path attacks. 165 Implementations ought to only send a probe packet with a Request 166 Probe Option when required by their local state machine, i.e., when 167 probing to grow the PLPMTU or to confirm the current PLPMTU. The 168 procedure to handle the loss of a response packet is the 169 responsibility of the sender of the request. Implementations are 170 allowed to track multiple requests and respond to them with a single 171 packet. 173 A PL needs to determine that the current path can still support the 174 size of datagram that the application is currently sending in the 175 DPLPMTUD search_done state (i.e., to detect black-holing of data). 176 One way to achieve this is to send probe packets of size PLPMTU or to 177 utilise a higher-layer method that provides explicit feedback 178 indicating any packet loss. 180 3.1. Sending Packet Probes using Control Information 182 The recommended approach to implementing DPLPMTUD sends a Probe 183 Packet that contains only control information together with any 184 padding that is needed to be inflated to the size required for the 185 probe packet. These probe packets do not carry an application- 186 supplied data block and therefore they do not typically require 187 retransmission, although they do still consume network capacity and 188 incur endpoint processing (see Section 4.1 of 189 [I-D.ietf-tsvwg-datagram-plpmtud]). 191 3.2. Sending Packet Probes using Application Data 193 Another possibility is to utilise data packets for Probe Packets 194 (Section 4.1 of [I-D.ietf-tsvwg-datagram-plpmtud] discusses the 195 merits and demerits of this approach). A probe packet then contains 196 a data block supplied by an application that is combined with padding 197 to inflate the length of the datagram to the size required for the 198 probe and additionally contains a Timestamp Option. 200 Reception of a valid Timestamp Option that was echoed by the remote 201 endpoint can also be used to infer connectivity. This can provide 202 useful feedback even over paths with asymmetric capacity and/or that 203 carry UDP Option flows that have very asymmetric datagram rates, 204 because an echo of the most recent Timestamp still indicates 205 reception of at least one packet of the transmitted size. This is 206 sufficient to confirm there is no black hole. 208 If the application/transport needs protection from the loss of this 209 Probe Packet, the application/ transport could perform transport- 210 layer retransmission/repair of the data block (e.g., by 211 retransmission after loss is detected or by duplicating the data 212 block in a datagram without the padding) [RFC8085]. 214 When sending a probe to increase the PLPMTU, a Timestamp might be 215 unable to unambiguously identify that a specific probe packet has 216 been received. Timestamp mechanisms cannot be used to confirm the 217 reception of individual probe messages and cannot be used to 218 stimulate a response from the remote peer. 220 3.3. Validating the Path with UDP Options 222 The UDP sender validates the responses to a Packet Probe 223 [I-D.ietf-tsvwg-datagram-plpmtud] using the UDP port information in 224 combination with the token and/or Timestamp value contained in the 225 UDP Option. 227 3.4. Handling of PTB Messages by UDP Options 229 The UDP sender validates any received ICMP PTB message that is 230 received in response to a Packet Probe 231 [I-D.ietf-tsvwg-datagram-plpmtud] using the quoted packet to validate 232 the UDP port information in combination with the token and/or 233 timestamp value contained in the UDP Option. 235 4. Acknowledgements 237 Gorry Fairhurst and Tom Jones are supported by funding provided by 238 the University of Aberdeen. 240 5. IANA Considerations 242 This memo includes no requests to IANA. 244 6. Security Considerations 246 The security considerations for are described in 247 [I-D.ietf-tsvwg-udp-options]. The proposed new method does not 248 change the integrity protection offered by the UDP options method. 250 7. References 252 7.1. Normative References 254 [I-D.ietf-tsvwg-datagram-plpmtud] 255 Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and 256 T. Voelker, "Packetization Layer Path MTU Discovery for 257 Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-07 258 (work in progress), February 2019. 260 [I-D.ietf-tsvwg-udp-options] 261 Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- 262 udp-options-07 (work in progress), March 2019. 264 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 265 DOI 10.17487/RFC0768, August 1980, 266 . 268 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 269 Requirement Levels", BCP 14, RFC 2119, 270 DOI 10.17487/RFC2119, March 1997, 271 . 273 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 274 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 275 . 277 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 278 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 279 March 2017, . 281 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 282 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 283 May 2017, . 285 7.2. Informative References 287 [RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the 288 User Datagram Protocol (UDP) and Lightweight UDP (UDP- 289 Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018, 290 . 292 Appendix A. Revision Notes 294 XXX Note to RFC-Editor: please remove this entire section prior to 295 publication. XXX 297 Individual draft-00. 299 o This version contains a description for consideration and comment 300 by the TSVWG. 302 Appendix B. Informative Description of new UDP Options 304 XXX Note to RFC-Editor: please remove this entire section prior to 305 publication (including subsections) before publication. XXX 307 This annexe contains a provisional description of the UDP Options 308 that will be specified in [I-D.ietf-tsvwg-udp-options]. The 309 information is provided for information only, to enable understanding 310 of the algorithm and will be superseded by text in the UDP Options 311 specification. 313 B.1. UDP Probe Request Option 315 The Probe Request Option allows a sending endpoint to solicit a 316 response from a destination endpoint. 318 The Probe Request Option carries a four byte token set by the sender. 319 This token can be set to a value that is likely to be known only to 320 the sender (and is sent along the end-to-end path). The initial 321 value of the token SHOULD be assigned to a randomised value, as 322 described in section 5.1 of [RFC8085]) to enhance protection from 323 off-path attacks. 325 The sender needs to then check the value returned in the UDP Probe 326 Response Option. The value of the Token field, uniquely identifies a 327 probe within the maximum segment lifetime. 329 +----------+--------+-----------------+ 330 | Kind=TBD | Len=6 | Token | 331 +----------+--------+-----------------+ 332 1 byte 1 byte 4 bytes 334 Figure 1: UDP Probe REQ Option Format 336 B.2. UDP Probe Response Option 338 The Probe Response Option is generated in response to reception of a 339 previously received Probe Request Option. This response is generated 340 by the UDP Option processing. 342 The Probe Response Option carries a four byte Token field. The Token 343 field associates the response with the token value carried in the 344 most recently-received Echo Request. The rate of generation of UDP 345 packets carrying a Probe Response Option is expected to be less than 346 once per RTT and SHOULD be rate-limited (see Section 6). 348 +----------+--------+-----------------+ 349 | Kind=TBD | Len=6 | Token | 350 +----------+--------+-----------------+ 351 1 byte 1 byte 4 bytes 353 Figure 2: UDP Probe RES Option Format 355 Authors' Addresses 357 Godred Fairhurst 358 University of Aberdeen 359 School of Engineering 360 Fraser Noble Building 361 Aberdeen AB24 3UE 362 UK 364 Email: gorry@erg.abdn.ac.uk 366 Tom Jones 367 University of Aberdeen 368 School of Engineering 369 Fraser Noble Building 370 Aberdeen AB24 3UE 371 UK 373 Email: tom@erg.abdn.ac.uk