idnits 2.17.1 draft-ietf-tram-stun-pmtud-11.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 date (August 1, 2019) is 1729 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.V42.2002' ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Downref: Normative reference to an Experimental RFC: RFC 5780 -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRAM M. Petit-Huguenin 3 Internet-Draft Impedance Mismatch 4 Intended status: Standards Track G. Salgueiro 5 Expires: February 2, 2020 F. Garrido 6 Cisco 7 August 1, 2019 9 Path MTU Discovery Using Session Traversal Utilities for NAT (STUN) 10 draft-ietf-tram-stun-pmtud-11 12 Abstract 14 This document describes a Session Traversal Utilities for NAT (STUN) 15 Usage for Path MTU Discovery (PMTUD) between a client and a server. 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 February 2, 2020. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Overview of Operations . . . . . . . . . . . . . . . . . . . 4 53 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Probing Mechanisms . . . . . . . . . . . . . . . . . . . . . 5 55 4.1. Simple Probing Mechanism . . . . . . . . . . . . . . . . 6 56 4.1.1. Sending a Probe Request . . . . . . . . . . . . . . . 6 57 4.1.2. Receiving a Probe Request . . . . . . . . . . . . . . 6 58 4.1.3. Receiving a Probe Response . . . . . . . . . . . . . 7 59 4.2. Complete Probing Mechanism . . . . . . . . . . . . . . . 7 60 4.2.1. Sending a Probe Indications and Report Request . . . 7 61 4.2.2. Receiving an ICMP Packet . . . . . . . . . . . . . . 8 62 4.2.3. Receiving a Probe Indication and Report Request . . . 8 63 4.2.4. Receiving a Report Response . . . . . . . . . . . . . 9 64 4.2.5. Using Checksums as Packet Identifiers . . . . . . . . 9 65 4.2.6. Using Sequence Numbers as Packet Identifiers . . . . 10 66 5. Probe Support Signaling Mechanisms . . . . . . . . . . . . . 10 67 5.1. Explicit Probe Support Signaling Mechanism . . . . . . . 11 68 5.2. Implicit Probe Support Signaling Mechanism . . . . . . . 11 69 6. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 11 70 6.1. IDENTIFIERS . . . . . . . . . . . . . . . . . . . . . . . 11 71 6.2. PMTUD-SUPPORTED . . . . . . . . . . . . . . . . . . . . . 12 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 8.1. New STUN Methods . . . . . . . . . . . . . . . . . . . . 12 75 8.2. New STUN Attributes . . . . . . . . . . . . . . . . . . . 13 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 78 9.2. Informative References . . . . . . . . . . . . . . . . . 14 79 Appendix A. Release Notes . . . . . . . . . . . . . . . . . . . 14 80 A.1. Modifications between draft-ietf-tram-stun-pmtud-11 and 81 draft-ietf-tram-stun-pmtud-10 . . . . . . . . . . . . . . 14 82 A.2. Modifications between draft-ietf-tram-stun-pmtud-10 and 83 draft-ietf-tram-stun-pmtud-09 . . . . . . . . . . . . . . 14 84 A.3. Modifications between draft-ietf-tram-stun-pmtud-09 and 85 draft-ietf-tram-stun-pmtud-08 . . . . . . . . . . . . . . 14 86 A.4. Modifications between draft-ietf-tram-stun-pmtud-08 and 87 draft-ietf-tram-stun-pmtud-07 . . . . . . . . . . . . . . 15 88 A.5. Modifications between draft-ietf-tram-stun-pmtud-07 and 89 draft-ietf-tram-stun-pmtud-06 . . . . . . . . . . . . . . 15 90 A.6. Modifications between draft-ietf-tram-stun-pmtud-06 and 91 draft-ietf-tram-stun-pmtud-05 . . . . . . . . . . . . . . 15 92 A.7. Modifications between draft-ietf-tram-stun-pmtud-05 and 93 draft-ietf-tram-stun-pmtud-04 . . . . . . . . . . . . . . 15 94 A.8. Modifications between draft-ietf-tram-stun-pmtud-04 and 95 draft-ietf-tram-stun-pmtud-03 . . . . . . . . . . . . . . 15 96 A.9. Modifications between draft-ietf-tram-stun-pmtud-03 and 97 draft-ietf-tram-stun-pmtud-02 . . . . . . . . . . . . . . 15 98 A.10. Modifications between draft-ietf-tram-stun-pmtud-02 and 99 draft-ietf-tram-stun-pmtud-01 . . . . . . . . . . . . . . 16 100 A.11. Modifications between draft-ietf-tram-stun-pmtud-01 and 101 draft-ietf-tram-stun-pmtud-00 . . . . . . . . . . . . . . 16 102 A.12. Modifications between draft-ietf-tram-stun-pmtud-00 and 103 draft-petithuguenin-tram-stun-pmtud-01 . . . . . . . . . 16 104 A.13. Modifications between draft-petithuguenin-tram-stun- 105 pmtud-01 and draft-petithuguenin-tram-stun-pmtud-00 . . . 16 106 A.14. Modifications between draft-petithuguenin-tram-stun- 107 pmtud-00 and draft-petithuguenin-behave-stun-pmtud-03 . . 17 108 A.15. Modifications between draft-petithuguenin-behave-stun- 109 pmtud-03 and draft-petithuguenin-behave-stun-pmtud-02 . . 17 110 A.16. Modifications between draft-petithuguenin-behave-stun- 111 pmtud-02 and draft-petithuguenin-behave-stun-pmtud-01 . . 17 112 A.17. Modifications between draft-petithuguenin-behave-stun- 113 pmtud-01 and draft-petithuguenin-behave-stun-pmtud-00 . . 17 114 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 117 1. Introduction 119 The Packetization Layer Path MTU Discovery (PMTUD) specification 120 [RFC4821] describes a method to discover the Path MTU but does not 121 describe a practical protocol to do so with UDP. 123 Many UDP-based protocols do not implement the Path MTU discovery 124 mechanism described in [RFC4821]. These protocols can make use of 125 the probing mechanisms described in this document instead of 126 designing their own adhoc extension. These probing mechanisms are 127 implemented with Session Traversal Utilities for NAT (STUN), but 128 their usage is not limited to STUN-based protocols. 130 The STUN usage defined in this document for Path MTU Discovery 131 (PMTUD) between a client and a server permits proper operations of 132 UDP-based applications in the network. It also simplifies 133 troubleshooting and has multiple other applications across a wide 134 variety of technologies. 136 Complementary techniques can be used to discover additional network 137 characteristics, such as the network path (using the STUN Traceroute 138 mechanism described in [I-D.martinsen-tram-stuntrace]) and bandwidth 139 availability (using the mechanism described in 140 [I-D.martinsen-tram-turnbandwidthprobe]). 142 2. Overview of Operations 144 This section is meant to be informative only. It is not intended as 145 a replacement for [RFC4821]. 147 A UDP endpoint that uses this specification to discover the Path MTU 148 over UDP and knows that the endpoint it is communicating with also 149 supports this specification can choose to use either the Simple 150 Probing mechanism (as described in Section 4.1) or the Complete 151 Probing mechanism (as described in Section 4.2). The selection of 152 which Probing Mechanism to use is dependent on performance and 153 security and complexity trade-offs. 155 If the Simple Probing mechanism is chosen, then the Client initiates 156 Probe transactions, as shown in Figure 1, which increase in size 157 until transactions timeout, indicating that the Path MTU has been 158 exceeded. It then uses that information to update the Path MTU. 160 Client Server 161 | | 162 | Probe Request | 163 |---------------->| 164 | | 165 | Probe Response | 166 |<----------------| 167 | | 169 Figure 1: Simple Probing Example 171 If the Complete Probing mechanism (as described in Section 4.2) is 172 chosen, then the Client sends Probe Indications of various sizes (as 173 specified in [RFC4821]) interleaved with UDP packets sent by the UDP 174 protocol. The Client then sends a Report Request for the ordered 175 list of identifiers for the UDP packets and Probe Indications 176 received by the Server. The Client then compares the list returned 177 in the Report Response with its own list of identifiers for the UDP 178 packets and Probe Indications it sent. The Client then uses that 179 comparison to find which Probe Indications were dropped by the 180 network as a result of their size. It then uses that information to 181 update the Path MTU. 183 Because of the possibility of amplification attack, the Complete 184 Probing mechanism must be authenticated. Particular care must be 185 taken to prevent amplification when an external mechanism is used to 186 trigger the Complete Probing mechanism. 188 Client Server 189 | UDP Packet | 190 |------------------>| 191 | | 192 | UDP Packet | 193 |------------------>| 194 | | 195 | Probe Indication | 196 |------------------>| 197 | | 198 | UDP Packet | 199 |------------------>| 200 | | 201 | Probe Indication | 202 |------------------>| 203 | | 204 | Report Request | 205 |------------------>| 206 | Report Response | 207 |<------------------| 208 | | 210 Figure 2: Complete Probing Example 212 3. Terminology 214 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 215 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 216 "OPTIONAL" in this document are to be interpreted as described in BCP 217 14 [RFC2119][RFC8174] when, and only when, they appear in all 218 capitals, as shown here. 220 4. Probing Mechanisms 222 The Probing mechanism is used to discover the Path MTU in one 223 direction only, from the client to the server. 225 Two Probing mechanisms are described, a Simple Probing mechanism and 226 a more complete mechanism that can converge quicker and find an 227 appropriate PMTU in the presence of congestion. Additionally, the 228 Simple Probing mechanism does not require authentication except where 229 used as an implicit signaling mechanism, whereas the complete 230 mechanism does. 232 Implementations supporting this specification MUST implement the 233 server side of both the Simple Probing mechanism (Section 4.1) and 234 the Complete Probing mechanism (Section 4.2). 236 Implementations supporting this specification MUST implement the 237 client side of the Complete Probing mechanism. They MAY implement 238 the client side of the Simple Probing mechanism. 240 4.1. Simple Probing Mechanism 242 The Simple Probing mechanism is implemented by sending a Probe 243 Request with a PADDING [RFC5780] attribute over UDP with the DF bit 244 set in the IP header. A router on the path to the server can reject 245 each request with an ICMP message or drop it. 247 4.1.1. Sending a Probe Request 249 A client forms a Probe Request by using the Probe Method and 250 following the rules in Section 7.1 of [RFC5389]. 252 The Probe transaction MUST be authenticated if the Simple Probing 253 mechanism is used in conjunction with the Implicit Probing Support 254 mechanism described in Section 5.2. If not, the Probe transaction 255 MAY be authenticated. 257 The client adds a PADDING [RFC5780] attribute with a length that, 258 when added to the IP and UDP headers and the other STUN components, 259 is equal to the Selected Probe Size, as defined in [RFC4821] 260 Section 7.3. The PADDING bits MUST be set to zero. The client MUST 261 add the FINGERPRINT attribute so the STUN messages are disambiguated 262 from the other protocol packets. 264 Then the client sends the Probe Request to the server over UDP with 265 the DF bit set. For the purpose of this transaction, the Rc 266 parameter specified in Section 7.2.1 of [RFC5389] is set to 3. The 267 initial value for RTO stays at 500 ms. 269 A client MUST NOT send a probe if it does not have knowledge that the 270 server supports this specification. This is done either by external 271 signalling or by a mechanism specific to the UDP protocol to which 272 PMTUD capabilities are added or by one of the mechanisms specified in 273 Section 5. 275 4.1.2. Receiving a Probe Request 277 A server receiving a Probe Request MUST process it as specified in 278 [RFC5389]. 280 The server then creates a Probe Response. The server MUST add the 281 FINGERPRINT attribute so the STUN messages are disambiguated from the 282 other protocol packets. The server then sends the response to the 283 client. 285 4.1.3. Receiving a Probe Response 287 A client receiving a Probe Response MUST process it as specified in 288 [RFC5389] and MUST ignore the PADDING attribute. If a response is 289 received this is interpreted as a Probe Success, as defined in 290 [RFC4821] Section 7.6.1. If an ICMP packet "Fragmentation needed" is 291 received then this is interpreted as a Probe Failure, as defined in 292 [RFC4821] Section 7.6.2. If the Probe transaction times out, then 293 this is interpreted as a Probe Inconclusive, as defined in [RFC4821] 294 Section 7.6.4. 296 4.2. Complete Probing Mechanism 298 The Complete Probing mechanism is implemented by sending one or more 299 Probe Indications with a PADDING attribute over UDP with the DF bit 300 set in the IP header followed by a Report Request to the same server. 301 A router on the path to the server can reject this Indication with an 302 ICMP message or drop it. The server keeps a chronologically ordered 303 list of identifiers for all packets received (including retransmitted 304 packets) and sends this list back to the client in the Report 305 Response. The client analyzes this list to find which packets were 306 not received. Because UDP packets do not contain an identifier, the 307 Complete Probing mechanism needs a way to identify each packet 308 received. 310 Some application layer protocols may already have a way of 311 identifying each individual UDP packet, in which case these 312 identifiers SHOULD be used in the IDENTIFIERS attribute of the Report 313 Response. While there are other possible packet identification 314 schemes, this document describes two different ways to identify a 315 specific packet when no application layer protocol-specific 316 identification mechanism is available. 318 In the first packet identification mechanism, the server computes a 319 checksum over each packet received and sends back to the sender the 320 list of checksums ordered chronologically. The client compares this 321 list to its own list of checksums. 323 In the second packet identification mechanism, the client prepends 324 the UDP data with a header that provides a sequence number. The 325 server sends back the chronologically ordered list of sequence 326 numbers received that the client then compares with its own list. 328 4.2.1. Sending a Probe Indications and Report Request 330 A client forms a Probe Indication by using the Probe Method and 331 following the rules in [RFC5389] Section 7.1. The client adds to a 332 Probe Indication a PADDING [RFC5780] attribute with a size that, when 333 added to the IP and UDP headers and the other STUN components, is 334 equal to the Selected Probe Size, as defined in [RFC4821] 335 Section 7.3. The PADDING bits MUST be set to zero. If the 336 authentication mechanism permits it, then the Indication MUST be 337 authenticated. The client MUST add the FINGERPRINT attribute so the 338 STUN messages are disambiguated from the other protocol packets. 340 Then the client sends a Probe Indication to the server over UDP with 341 the DF bit set. 343 Then the client forms a Report Request by following the rules in 344 [RFC5389] Section 7.1. The Report transaction MUST be authenticated 345 to prevent amplification attacks. The client MUST add the 346 FINGERPRINT attribute so the STUN messages are disambiguated from the 347 other protocol packets. 349 Then the client waits half the RTO after sending the last Probe 350 Indication and then sends the Report Request to the server over UDP. 352 4.2.2. Receiving an ICMP Packet 354 If an ICMP packet "Fragmentation needed" is received then this is 355 interpreted as a Probe Failure, as defined in [RFC4821] Section 7.5. 357 4.2.3. Receiving a Probe Indication and Report Request 359 A server supporting this specification will keep the identifiers of 360 all packets received in a chronologically ordered list. The packets 361 that are to be associated to an identifier are selected according to 362 Section 5.2 of [RFC4821]. The same identifier can appear multiple 363 times in the list because of retransmissions. The maximum size of 364 this list is calculated such that when the list is added to the 365 Report Response, the total size of the packet does not exceed the 366 unknown Path MTU, as defined in [RFC5389] Section 7.1. Older 367 identifiers are removed when new identifiers are added to a list that 368 is already full. 370 A server receiving a Report Request MUST process it as specified in 371 [RFC5389] and MUST ignore the PADDING attribute. 373 The server creates a Report Response and adds an IDENTIFIERS 374 attribute that contains the chronologically ordered list of all 375 identifiers received so far. The server MUST add the FINGERPRINT 376 attribute. The server then sends the response to the client. 378 The exact content of the IDENTIFIERS attribute depends on what type 379 of identifiers have been chosen for the protocol. Each protocol 380 adding PMTUD capabilities as specified by this specification MUST 381 describe the format of the contents of the IDENTIFIERS attribute, 382 unless it is using one of the formats described in this 383 specification. See Section 6.1 for details about the IDENTIFIERS 384 attribute. 386 4.2.4. Receiving a Report Response 388 A client receiving a Report Response processes it as specified in 389 [RFC5389]. If the response IDENTIFIERS attribute contains the 390 identifier of a Probe Indication, then this is interpreted as a Probe 391 Success for this probe, as defined in [RFC4821] Section 7.5. If a 392 Probe Indication identifier cannot be found in the Report Response, 393 this is interpreted as a Probe Failure, as defined in [RFC4821] 394 Section 7.5. If a Probe Indication identifier cannot be found in the 395 Report Response but identifiers for other packets sent before or 396 after the Probe Indication can all be found, this is interpreted as a 397 Probe Failure as defined in [RFC4821] Section 7.5. If the Report 398 Transaction times out, this is interpreted as a Full-Stop Timeout, as 399 defined in [RFC4821] Section 3. 401 4.2.5. Using Checksums as Packet Identifiers 403 When using a checksum as a packet identifier, the client keeps a 404 chronologically ordered list of the packets it transmits, along with 405 an associated checksum value. For STUN Probe Indication or Request 406 packets, the associated checksum value is the FINGERPRINT value from 407 the packet; for other packets a checksum value is computed using a 408 similar algorithm to the FINGERPRINT calculation. (i.e., the CRC-32 409 of the payload XOR'ed with the 32-bit value 0x5354554e 410 [ITU.V42.2002]). 412 For each STUN Probe Indication or Request, the server retrieves the 413 STUN FINGERPRINT value. For all other packets, the server calculates 414 the checksum as described above. It puts these FINGERPRINT and 415 checksum values in a chronologically ordered list that is sent back 416 in the Report Response. 418 The contents of the IDENTIFIERS attribute is a list of 4 byte 419 numbers, each using the same encoding that is used for the contents 420 of the FINGERPRINT attribute. 422 It could have been possible to use the checksum generated in the UDP 423 checksum for this, but this value is generally not accessible to 424 applications. Also, sometimes the checksum is not calculated or is 425 off-loaded to network hardware. 427 4.2.6. Using Sequence Numbers as Packet Identifiers 429 When using sequence numbers, a small header similar to the TURN 430 ChannelData header, as defined in Section 11.4 of [RFC5766], is added 431 in front of all packets that are not a STUN Probe Indication or 432 Request. The sequence number is monotonically incremented by one for 433 each packet sent. The most significant bit of the sequence number is 434 always 0. The server collects the sequence number of the packets 435 sent, or the 4 first bytes of the transaction ID if a STUN Probe 436 Indication or Request is sent. In that case, the most significant 437 bit of the 4 first bytes is set to 1. 439 0 1 2 3 440 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Channel Number | Length | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 |0| Sequence number | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | | 447 / Application Data / 448 / / 449 | | 450 | +-------------------------------+ 451 | | 452 +-------------------------------+ 454 The Channel Number is always 0xFFFF. The Length field specifies the 455 length in bytes of the sequence number and application data fields. 456 The header values are encoded using network order. 458 The contents of the IDENTIFIERS attribute is a chronologically 459 ordered list of 4 byte numbers, each containing either a sequence 460 number, if the packet was not a STUN Probe Indication or Request, or 461 the 4 first bytes of the transaction ID, with the most significant 462 bit forced to 1, if the packet is a STUN Probe Indication or Request. 464 5. Probe Support Signaling Mechanisms 466 The PMTUD mechanism described in this document is intended to be used 467 by any UDP-based protocols that do not have built-in PMTUD 468 capabilities, irrespective of whether those UDP-based protocols are 469 STUN-based or not. So the manner in which a specific protocol 470 discovers that it is safe to send PMTUD probes is largely dependent 471 on the details of that specific protocol, with the exception of the 472 Implicit Mechanism described below, which applies to any protocol. 474 5.1. Explicit Probe Support Signaling Mechanism 476 Some of these mechanisms can use a separate signalling mechanism (for 477 instance, an SDP attribute in an Offer/Answer exchange [RFC3264]), or 478 an optional flag that can be set in the protocol that is augmented 479 with PMTUD capabilities. STUN Usages that can benefit from PMTUD 480 capabilities can signal in-band that they support probing by 481 inserting a PMTUD-SUPPORTED attribute in some STUN methods. The 482 decision of which methods support this attribute is left to each 483 specific STUN Usage. 485 UDP-based protocols that want to use any of these mechanisms, 486 including the PMTUD-SUPPORTED attribute, to signal PMTUD capabilities 487 MUST ensure that it cannot be used to launch an amplification attack. 489 An amplification attack can be prevented using techniques such as: 491 o Authentication, where the source of the packet and the destination 492 share a secret. 494 o 3 way handshake with some form of unpredictable cookie. 496 o Make sure that the total size of the traffic potentially generated 497 is lower than the size of the request that generated it. 499 5.2. Implicit Probe Support Signaling Mechanism 501 As a result of the fact that all endpoints implementing this 502 specification are both clients and servers, a Probe Request or 503 Indication received by an endpoint acting as a server implicitly 504 signals that this server can now act as a client and MAY send a Probe 505 Request or Indication to probe the Path MTU in the reverse direction 506 toward the former client, that will now be acting as a server. 508 The Probe Request or Indication that are used to implicitly signal 509 probing support in the reverse direction MUST be authenticated to 510 prevent amplification attacks. 512 6. STUN Attributes 514 6.1. IDENTIFIERS 516 The IDENTIFIERS attribute carries a chronologically ordered list of 517 UDP packet identifiers. 519 While Section 4.2.5 and Section 4.2.6 describe two possible methods 520 for acquiring and formatting the identifiers used for this purpose, 521 ultimately each protocol has to define how these identifiers are 522 acquired and formatted. Therefore, the contents of the IDENTIFIERS 523 attribute is opaque. 525 6.2. PMTUD-SUPPORTED 527 The PMTUD-SUPPORTED attribute indicates that its sender supports this 528 mechanism, as incorporated into the STUN usage or protocol being 529 used. This attribute has no value part and thus the attribute length 530 field is 0. 532 7. Security Considerations 534 The PMTUD mechanism described in this document, when used without the 535 signalling mechanism described in Section 5.1, does not introduce any 536 specific security considerations beyond those described in [RFC4821]. 538 The attacks described in Section 11 of [RFC4821] apply equally to the 539 mechanism described in this document. 541 The amplification attacks introduced by the signalling mechanism 542 described in Section 5.1 can be prevented by using one of the 543 techniques described in that section. 545 The Simple Probing mechanism may be used without authentication 546 because this usage by itself cannot trigger an amplification attack 547 as the Probe Response is smaller than the Probe Request. An 548 unauthenticated Simple Probing mechanism cannot be used in 549 conjunction with the Implicit Probing Support Signaling mechanism in 550 order to prevent amplification attacks. 552 8. IANA Considerations 554 This specification defines two new STUN methods and two new STUN 555 attributes. 557 8.1. New STUN Methods 559 IANA is requested to add the following methods to the STUN Method 560 Registry: 562 0xXXX : Probe 564 0xXXX : Report 566 See Sections Section 4.1 and Section 4.2 for the semantics of these 567 new methods. 569 8.2. New STUN Attributes 571 IANA is requested to add the following attributes to the STUN Method 572 Registry: 574 Comprehension-required range (0x0000-0x7FFF): 575 0xXXXX: IDENTIFIERS 577 Comprehension-optional range (0x8000-0xFFFF) 578 0xXXXX: PMTUD-SUPPORTED 580 This IDENTIFIERS STUN attribute is defined in Section 6.1, the PMTUD- 581 SUPPORTED STUN attribute is defined in Section 6.2. 583 9. References 585 9.1. Normative References 587 [ITU.V42.2002] 588 International Telecommunications Union, "Error-correcting 589 Procedures for DCEs Using Asynchronous-to-Synchronous 590 Conversion", ITU-T Recommendation V.42, 2002. 592 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 593 Requirement Levels", BCP 14, RFC 2119, 594 DOI 10.17487/RFC2119, March 1997, 595 . 597 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 598 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 599 . 601 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 602 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 603 DOI 10.17487/RFC5389, October 2008, 604 . 606 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 607 Using Session Traversal Utilities for NAT (STUN)", 608 RFC 5780, DOI 10.17487/RFC5780, May 2010, 609 . 611 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 612 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 613 May 2017, . 615 9.2. Informative References 617 [I-D.martinsen-tram-stuntrace] 618 Martinsen, P. and D. Wing, "STUN Traceroute", draft- 619 martinsen-tram-stuntrace-01 (work in progress), June 2015. 621 [I-D.martinsen-tram-turnbandwidthprobe] 622 Martinsen, P., Andersen, T., Salgueiro, G., and M. Petit- 623 Huguenin, "Traversal Using Relays around NAT (TURN) 624 Bandwidth Probe", draft-martinsen-tram- 625 turnbandwidthprobe-00 (work in progress), May 2015. 627 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 628 with Session Description Protocol (SDP)", RFC 3264, 629 DOI 10.17487/RFC3264, June 2002, 630 . 632 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 633 Relays around NAT (TURN): Relay Extensions to Session 634 Traversal Utilities for NAT (STUN)", RFC 5766, 635 DOI 10.17487/RFC5766, April 2010, 636 . 638 Appendix A. Release Notes 640 This section must be removed before publication as an RFC. 642 A.1. Modifications between draft-ietf-tram-stun-pmtud-11 and draft- 643 ietf-tram-stun-pmtud-10 645 o Modifications following IESG review. 647 A.2. Modifications between draft-ietf-tram-stun-pmtud-10 and draft- 648 ietf-tram-stun-pmtud-09 650 o Modifications following reviews for gen-art (Roni Even) and secdir 651 (Carl Wallace). 653 A.3. Modifications between draft-ietf-tram-stun-pmtud-09 and draft- 654 ietf-tram-stun-pmtud-08 656 o Add 3 ways of preventing amplification attacks. 658 A.4. Modifications between draft-ietf-tram-stun-pmtud-08 and draft- 659 ietf-tram-stun-pmtud-07 661 o Updates following Spencer's review. 663 A.5. Modifications between draft-ietf-tram-stun-pmtud-07 and draft- 664 ietf-tram-stun-pmtud-06 666 o Updates following Shepherd review. 668 A.6. Modifications between draft-ietf-tram-stun-pmtud-06 and draft- 669 ietf-tram-stun-pmtud-05 671 o Nits. 673 o Restore missing changelog for previous version. 675 A.7. Modifications between draft-ietf-tram-stun-pmtud-05 and draft- 676 ietf-tram-stun-pmtud-04 678 o Modifications following Brandon Williams review. 680 A.8. Modifications between draft-ietf-tram-stun-pmtud-04 and draft- 681 ietf-tram-stun-pmtud-03 683 o Modifications following Simon Perreault and Brandon Williams 684 reviews. 686 A.9. Modifications between draft-ietf-tram-stun-pmtud-03 and draft- 687 ietf-tram-stun-pmtud-02 689 o Add new Overview of Operations section with ladder diagrams. 691 o Authentication is mandatory for the Complete Probing mechanism, 692 optional for the Simple Probing mechanism. 694 o All the ICE specific text moves to a separate draft to be 695 discussed in the ICE WG. 697 o The TURN usage is removed because probing between a TURN server 698 and TURN client is not useful. 700 o Any usage of PMTUD-SUPPORTED or other signaling mechanisms 701 (formerly knows as discovery mechanisms) must now be 702 authenticated. 704 o Both probing mechanisms are MTI in the server, the complete 705 probing mechanism is MTI in the client. 707 o Make clear that stopping after 3 retransmission is done by 708 changing the STUN parameter. 710 o Define the format of the attributes. 712 o Make clear that the specification is for any UDP protocol that 713 does not already have PMTUD capabilities, not just STUN based 714 protocols. 716 o Change the default delay to send the Report Request to 250 ms 717 after the last Indication if the RTO is unknown. 719 o Each usage of this specification must the format of the 720 IDENTIFIERS attribute contents. 722 o Better define the implicit signaling mechanism. 724 o Extend the Security Consideration section. 726 o Tons of nits. 728 A.10. Modifications between draft-ietf-tram-stun-pmtud-02 and draft- 729 ietf-tram-stun-pmtud-01 731 o Cleaned up references. 733 A.11. Modifications between draft-ietf-tram-stun-pmtud-01 and draft- 734 ietf-tram-stun-pmtud-00 736 o Added Security Considerations Section. 738 o Added IANA Considerations Section. 740 A.12. Modifications between draft-ietf-tram-stun-pmtud-00 and draft- 741 petithuguenin-tram-stun-pmtud-01 743 o Adopted by WG - Text unchanged. 745 A.13. Modifications between draft-petithuguenin-tram-stun-pmtud-01 and 746 draft-petithuguenin-tram-stun-pmtud-00 748 o Moved some Introduction text to the Probing Mechanism section. 750 o Added cross-reference to the other two STUN troubleshooting 751 mechanism drafts. 753 o Updated references. 755 o Added Gonzalo Salgueiro as co-author. 757 A.14. Modifications between draft-petithuguenin-tram-stun-pmtud-00 and 758 draft-petithuguenin-behave-stun-pmtud-03 760 o General refresh for republication. 762 A.15. Modifications between draft-petithuguenin-behave-stun-pmtud-03 763 and draft-petithuguenin-behave-stun-pmtud-02 765 o Changed author address. 767 o Changed the IPR to trust200902. 769 A.16. Modifications between draft-petithuguenin-behave-stun-pmtud-02 770 and draft-petithuguenin-behave-stun-pmtud-01 772 o Defined checksum and sequential numbers as possible packet 773 identifiers. 775 o Updated the reference to RFC 5389 777 o The FINGERPRINT attribute is now mandatory. 779 o Changed the delay between Probe indication and Report request to 780 be RTO/2 or 50 milliseconds. 782 o Added ICMP packet processing. 784 o Added Full-Stop Timeout detection. 786 o Stated that Binding request with PMTUD-SUPPORTED does not start 787 the PMTUD process if already started. 789 A.17. Modifications between draft-petithuguenin-behave-stun-pmtud-01 790 and draft-petithuguenin-behave-stun-pmtud-00 792 o Removed the use of modified STUN transaction but shorten the 793 retransmission for the simple probing mechanism. 795 o Added a complete probing mechanism. 797 o Removed the PADDING-RECEIVED attribute. 799 o Added release notes. 801 Acknowledgements 803 Thanks to Eilon Yardeni, Geir Sandbakken, Paal-Erik Martinsen, 804 Tirumaleswar Reddy, Ram Mohan R, Simon Perreault, Brandon Williams, 805 Tolga Asveren, Spencer Dawkins, Carl Wallace, and Roni Even for their 806 review comments, suggestions and questions that helped to improve 807 this document. 809 Special thanks to Dan Wing, who supported this document since its 810 first publication back in 2008. 812 Authors' Addresses 814 Marc Petit-Huguenin 815 Impedance Mismatch 817 Email: marc@petit-huguenin.org 819 Gonzalo Salgueiro 820 Cisco Systems, Inc. 821 7200-12 Kit Creek Road 822 Research Triangle Park, NC 27709 823 United States 825 Email: gsalguei@cisco.com 827 Felipe Garrido 828 Cisco Systems, Inc. 829 7200-12 Kit Creek Road 830 Research Triangle Park, NC 27709 831 United States 833 Email: fegarrid@cisco.com