| draft-ietf-tram-stun-pmtud-11.txt | draft-ietf-tram-stun-pmtud-12.txt | |||
|---|---|---|---|---|
| TRAM M. Petit-Huguenin | TRAM M. Petit-Huguenin | |||
| Internet-Draft Impedance Mismatch | Internet-Draft Impedance Mismatch | |||
| Intended status: Standards Track G. Salgueiro | Intended status: Standards Track G. Salgueiro | |||
| Expires: February 2, 2020 F. Garrido | Expires: March 12, 2020 F. Garrido | |||
| Cisco | Cisco | |||
| August 1, 2019 | September 9, 2019 | |||
| Path MTU Discovery Using Session Traversal Utilities for NAT (STUN) | Path MTU Discovery Using Session Traversal Utilities for NAT (STUN) | |||
| draft-ietf-tram-stun-pmtud-11 | draft-ietf-tram-stun-pmtud-12 | |||
| Abstract | Abstract | |||
| This document describes a Session Traversal Utilities for NAT (STUN) | This document describes a Session Traversal Utilities for NAT (STUN) | |||
| Usage for Path MTU Discovery (PMTUD) between a client and a server. | Usage for Path MTU Discovery (PMTUD) between a client and a server. | |||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| skipping to change at page 1, line 33 ¶ | skipping to change at page 1, line 33 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on February 2, 2020. | This Internet-Draft will expire on March 12, 2020. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| skipping to change at page 2, line 16 ¶ | skipping to change at page 2, line 16 ¶ | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Overview of Operations . . . . . . . . . . . . . . . . . . . 4 | 2. Overview of Operations . . . . . . . . . . . . . . . . . . . 4 | |||
| 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 4. Probing Mechanisms . . . . . . . . . . . . . . . . . . . . . 5 | 4. Probing Mechanisms . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 4.1. Simple Probing Mechanism . . . . . . . . . . . . . . . . 6 | 4.1. Simple Probing Mechanism . . . . . . . . . . . . . . . . 6 | |||
| 4.1.1. Sending a Probe Request . . . . . . . . . . . . . . . 6 | 4.1.1. Sending a Probe Request . . . . . . . . . . . . . . . 6 | |||
| 4.1.2. Receiving a Probe Request . . . . . . . . . . . . . . 6 | 4.1.2. Receiving a Probe Request . . . . . . . . . . . . . . 6 | |||
| 4.1.3. Receiving a Probe Response . . . . . . . . . . . . . 7 | 4.1.3. Receiving a Probe Response . . . . . . . . . . . . . 7 | |||
| 4.2. Complete Probing Mechanism . . . . . . . . . . . . . . . 7 | 4.2. Complete Probing Mechanism . . . . . . . . . . . . . . . 7 | |||
| 4.2.1. Sending a Probe Indications and Report Request . . . 7 | 4.2.1. Sending a Probe Indications and Report Request . . . 8 | |||
| 4.2.2. Receiving an ICMP Packet . . . . . . . . . . . . . . 8 | 4.2.2. Receiving an ICMP Packet . . . . . . . . . . . . . . 8 | |||
| 4.2.3. Receiving a Probe Indication and Report Request . . . 8 | 4.2.3. Receiving a Probe Indication and Report Request . . . 8 | |||
| 4.2.4. Receiving a Report Response . . . . . . . . . . . . . 9 | 4.2.4. Receiving a Report Response . . . . . . . . . . . . . 9 | |||
| 4.2.5. Using Checksums as Packet Identifiers . . . . . . . . 9 | 4.2.5. Using Checksums as Packet Identifiers . . . . . . . . 9 | |||
| 4.2.6. Using Sequence Numbers as Packet Identifiers . . . . 10 | 4.2.6. Using Sequence Numbers as Packet Identifiers . . . . 10 | |||
| 5. Probe Support Signaling Mechanisms . . . . . . . . . . . . . 10 | 5. Probe Support Signaling Mechanisms . . . . . . . . . . . . . 10 | |||
| 5.1. Explicit Probe Support Signaling Mechanism . . . . . . . 11 | 5.1. Explicit Probe Support Signaling Mechanism . . . . . . . 11 | |||
| 5.2. Implicit Probe Support Signaling Mechanism . . . . . . . 11 | 5.2. Implicit Probe Support Signaling Mechanism . . . . . . . 11 | |||
| 6. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 11 | 6. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 6.1. IDENTIFIERS . . . . . . . . . . . . . . . . . . . . . . . 11 | 6.1. IDENTIFIERS . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 6.2. PMTUD-SUPPORTED . . . . . . . . . . . . . . . . . . . . . 12 | 6.2. PMTUD-SUPPORTED . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 6.3. PADDING . . . . . . . . . . . . . . . . . . . . . . . . . 12 | ||||
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 8.1. New STUN Methods . . . . . . . . . . . . . . . . . . . . 12 | 8.1. New STUN Methods . . . . . . . . . . . . . . . . . . . . 13 | |||
| 8.2. New STUN Attributes . . . . . . . . . . . . . . . . . . . 13 | 8.2. New STUN Attributes . . . . . . . . . . . . . . . . . . . 13 | |||
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 | |||
| 9.2. Informative References . . . . . . . . . . . . . . . . . 14 | 9.2. Informative References . . . . . . . . . . . . . . . . . 14 | |||
| Appendix A. Release Notes . . . . . . . . . . . . . . . . . . . 14 | Appendix A. Release Notes . . . . . . . . . . . . . . . . . . . 15 | |||
| A.1. Modifications between draft-ietf-tram-stun-pmtud-11 and | A.1. Modifications between draft-ietf-tram-stun-pmtud-12 and | |||
| draft-ietf-tram-stun-pmtud-10 . . . . . . . . . . . . . . 14 | draft-ietf-tram-stun-pmtud-11 . . . . . . . . . . . . . . 15 | |||
| A.2. Modifications between draft-ietf-tram-stun-pmtud-10 and | A.2. Modifications between draft-ietf-tram-stun-pmtud-11 and | |||
| draft-ietf-tram-stun-pmtud-09 . . . . . . . . . . . . . . 14 | draft-ietf-tram-stun-pmtud-10 . . . . . . . . . . . . . . 15 | |||
| A.3. Modifications between draft-ietf-tram-stun-pmtud-09 and | A.3. Modifications between draft-ietf-tram-stun-pmtud-10 and | |||
| draft-ietf-tram-stun-pmtud-08 . . . . . . . . . . . . . . 14 | draft-ietf-tram-stun-pmtud-09 . . . . . . . . . . . . . . 15 | |||
| A.4. Modifications between draft-ietf-tram-stun-pmtud-08 and | A.4. Modifications between draft-ietf-tram-stun-pmtud-09 and | |||
| draft-ietf-tram-stun-pmtud-08 . . . . . . . . . . . . . . 15 | ||||
| A.5. Modifications between draft-ietf-tram-stun-pmtud-08 and | ||||
| draft-ietf-tram-stun-pmtud-07 . . . . . . . . . . . . . . 15 | draft-ietf-tram-stun-pmtud-07 . . . . . . . . . . . . . . 15 | |||
| A.5. Modifications between draft-ietf-tram-stun-pmtud-07 and | A.6. Modifications between draft-ietf-tram-stun-pmtud-07 and | |||
| draft-ietf-tram-stun-pmtud-06 . . . . . . . . . . . . . . 15 | draft-ietf-tram-stun-pmtud-06 . . . . . . . . . . . . . . 15 | |||
| A.6. Modifications between draft-ietf-tram-stun-pmtud-06 and | A.7. Modifications between draft-ietf-tram-stun-pmtud-06 and | |||
| draft-ietf-tram-stun-pmtud-05 . . . . . . . . . . . . . . 15 | draft-ietf-tram-stun-pmtud-05 . . . . . . . . . . . . . . 16 | |||
| A.7. Modifications between draft-ietf-tram-stun-pmtud-05 and | A.8. Modifications between draft-ietf-tram-stun-pmtud-05 and | |||
| draft-ietf-tram-stun-pmtud-04 . . . . . . . . . . . . . . 15 | draft-ietf-tram-stun-pmtud-04 . . . . . . . . . . . . . . 16 | |||
| A.8. Modifications between draft-ietf-tram-stun-pmtud-04 and | ||||
| draft-ietf-tram-stun-pmtud-03 . . . . . . . . . . . . . . 15 | A.9. Modifications between draft-ietf-tram-stun-pmtud-04 and | |||
| A.9. Modifications between draft-ietf-tram-stun-pmtud-03 and | draft-ietf-tram-stun-pmtud-03 . . . . . . . . . . . . . . 16 | |||
| draft-ietf-tram-stun-pmtud-02 . . . . . . . . . . . . . . 15 | A.10. Modifications between draft-ietf-tram-stun-pmtud-03 and | |||
| A.10. Modifications between draft-ietf-tram-stun-pmtud-02 and | draft-ietf-tram-stun-pmtud-02 . . . . . . . . . . . . . . 16 | |||
| draft-ietf-tram-stun-pmtud-01 . . . . . . . . . . . . . . 16 | A.11. Modifications between draft-ietf-tram-stun-pmtud-02 and | |||
| A.11. Modifications between draft-ietf-tram-stun-pmtud-01 and | draft-ietf-tram-stun-pmtud-01 . . . . . . . . . . . . . . 17 | |||
| draft-ietf-tram-stun-pmtud-00 . . . . . . . . . . . . . . 16 | A.12. Modifications between draft-ietf-tram-stun-pmtud-01 and | |||
| A.12. Modifications between draft-ietf-tram-stun-pmtud-00 and | draft-ietf-tram-stun-pmtud-00 . . . . . . . . . . . . . . 17 | |||
| draft-petithuguenin-tram-stun-pmtud-01 . . . . . . . . . 16 | A.13. Modifications between draft-ietf-tram-stun-pmtud-00 and | |||
| A.13. Modifications between draft-petithuguenin-tram-stun- | draft-petithuguenin-tram-stun-pmtud-01 . . . . . . . . . 17 | |||
| pmtud-01 and draft-petithuguenin-tram-stun-pmtud-00 . . . 16 | ||||
| A.14. Modifications between draft-petithuguenin-tram-stun- | A.14. Modifications between draft-petithuguenin-tram-stun- | |||
| pmtud-01 and draft-petithuguenin-tram-stun-pmtud-00 . . . 17 | ||||
| A.15. Modifications between draft-petithuguenin-tram-stun- | ||||
| pmtud-00 and draft-petithuguenin-behave-stun-pmtud-03 . . 17 | pmtud-00 and draft-petithuguenin-behave-stun-pmtud-03 . . 17 | |||
| A.15. Modifications between draft-petithuguenin-behave-stun- | ||||
| pmtud-03 and draft-petithuguenin-behave-stun-pmtud-02 . . 17 | ||||
| A.16. Modifications between draft-petithuguenin-behave-stun- | A.16. Modifications between draft-petithuguenin-behave-stun- | |||
| pmtud-02 and draft-petithuguenin-behave-stun-pmtud-01 . . 17 | pmtud-03 and draft-petithuguenin-behave-stun-pmtud-02 . . 18 | |||
| A.17. Modifications between draft-petithuguenin-behave-stun- | A.17. Modifications between draft-petithuguenin-behave-stun- | |||
| pmtud-01 and draft-petithuguenin-behave-stun-pmtud-00 . . 17 | pmtud-02 and draft-petithuguenin-behave-stun-pmtud-01 . . 18 | |||
| A.18. Modifications between draft-petithuguenin-behave-stun- | ||||
| pmtud-01 and draft-petithuguenin-behave-stun-pmtud-00 . . 18 | ||||
| Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 | Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 1. Introduction | 1. Introduction | |||
| The Packetization Layer Path MTU Discovery (PMTUD) specification | The Packetization Layer Path MTU Discovery (PMTUD) specification | |||
| [RFC4821] describes a method to discover the Path MTU but does not | [RFC4821] describes a method to discover the Path MTU but does not | |||
| describe a practical protocol to do so with UDP. | describe a practical protocol to do so with UDP. | |||
| Many UDP-based protocols do not implement the Path MTU discovery | Many UDP-based protocols do not implement the Path MTU discovery | |||
| mechanism described in [RFC4821]. These protocols can make use of | mechanism described in [RFC4821]. These protocols can make use of | |||
| the probing mechanisms described in this document instead of | the probing mechanisms described in this document instead of | |||
| skipping to change at page 5, line 40 ¶ | skipping to change at page 5, line 40 ¶ | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14 [RFC2119][RFC8174] when, and only when, they appear in all | 14 [RFC2119][RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 4. Probing Mechanisms | 4. Probing Mechanisms | |||
| The Probing mechanism is used to discover the Path MTU in one | The Probing mechanism is used to discover the Path MTU in one | |||
| direction only, from the client to the server. | direction only: from the client to the server. | |||
| Two Probing mechanisms are described, a Simple Probing mechanism and | Two Probing mechanisms are described: a Simple Probing mechanism and | |||
| a more complete mechanism that can converge quicker and find an | a more complete mechanism that can converge more quickly and find an | |||
| appropriate PMTU in the presence of congestion. Additionally, the | appropriate Path MTU in the presence of congestion. Additionally, | |||
| Simple Probing mechanism does not require authentication except where | the Simple Probing mechanism does not require authentication except | |||
| used as an implicit signaling mechanism, whereas the complete | where used as an implicit signaling mechanism, whereas the complete | |||
| mechanism does. | mechanism does. | |||
| Implementations supporting this specification MUST implement the | Implementations supporting this specification MUST implement the | |||
| server side of both the Simple Probing mechanism (Section 4.1) and | server side of both the Simple Probing mechanism (Section 4.1) and | |||
| the Complete Probing mechanism (Section 4.2). | the Complete Probing mechanism (Section 4.2). | |||
| Implementations supporting this specification MUST implement the | Implementations supporting this specification MUST implement the | |||
| client side of the Complete Probing mechanism. They MAY implement | client side of the Complete Probing mechanism. They MAY implement | |||
| the client side of the Simple Probing mechanism. | the client side of the Simple Probing mechanism. | |||
| 4.1. Simple Probing Mechanism | 4.1. Simple Probing Mechanism | |||
| The Simple Probing mechanism is implemented by sending a Probe | The Simple Probing mechanism is implemented by sending a Probe | |||
| Request with a PADDING [RFC5780] attribute over UDP with the DF bit | Request with a PADDING attribute over UDP with the DF bit set in the | |||
| set in the IP header. A router on the path to the server can reject | IP header for IPv4 packets and IPv6 packets without the Fragment | |||
| each request with an ICMP message or drop it. | Header included. A router on the path to the server can reject each | |||
| request with an ICMP message or drop it. | ||||
| 4.1.1. Sending a Probe Request | 4.1.1. Sending a Probe Request | |||
| A client forms a Probe Request by using the Probe Method and | A client forms a Probe Request by using the Probe Method and | |||
| following the rules in Section 7.1 of [RFC5389]. | following the rules in Section 7.1 of [RFC5389]. | |||
| The Probe transaction MUST be authenticated if the Simple Probing | The Probe transaction MUST be authenticated if the Simple Probing | |||
| mechanism is used in conjunction with the Implicit Probing Support | mechanism is used in conjunction with the Implicit Probing Support | |||
| mechanism described in Section 5.2. If not, the Probe transaction | mechanism described in Section 5.2. If not, the Probe transaction | |||
| MAY be authenticated. | MAY be authenticated. | |||
| The client adds a PADDING [RFC5780] attribute with a length that, | The client adds a PADDING attribute with a length that, when added to | |||
| when added to the IP and UDP headers and the other STUN components, | the IP and UDP headers and the other STUN components, is equal to the | |||
| is equal to the Selected Probe Size, as defined in [RFC4821] | Selected Probe Size, as defined in [RFC4821] Section 7.3. The | |||
| Section 7.3. The PADDING bits MUST be set to zero. The client MUST | PADDING bits SHOULD be set to zero. The client MUST add the | |||
| add the FINGERPRINT attribute so the STUN messages are disambiguated | FINGERPRINT attribute so the STUN messages are disambiguated from the | |||
| from the other protocol packets. | other protocol packets. | |||
| Then the client sends the Probe Request to the server over UDP with | Then the client sends the Probe Request to the server over UDP with | |||
| the DF bit set. For the purpose of this transaction, the Rc | the DF bit set for IPv4 packets and IPv6 packets without the Fragment | |||
| Header included. For the purpose of this transaction, the Rc | ||||
| parameter specified in Section 7.2.1 of [RFC5389] is set to 3. The | parameter specified in Section 7.2.1 of [RFC5389] is set to 3. The | |||
| initial value for RTO stays at 500 ms. | initial value for RTO stays at 500 ms. | |||
| A client MUST NOT send a probe if it does not have knowledge that the | A client MUST NOT send a probe if it does not have knowledge that the | |||
| server supports this specification. This is done either by external | server supports this specification. This is done either by external | |||
| signalling or by a mechanism specific to the UDP protocol to which | signalling or by a mechanism specific to the UDP protocol to which | |||
| PMTUD capabilities are added or by one of the mechanisms specified in | PMTUD capabilities are added or by one of the mechanisms specified in | |||
| Section 5. | Section 5. | |||
| 4.1.2. Receiving a Probe Request | 4.1.2. Receiving a Probe Request | |||
| skipping to change at page 7, line 10 ¶ | skipping to change at page 7, line 12 ¶ | |||
| The server then creates a Probe Response. The server MUST add the | The server then creates a Probe Response. The server MUST add the | |||
| FINGERPRINT attribute so the STUN messages are disambiguated from the | FINGERPRINT attribute so the STUN messages are disambiguated from the | |||
| other protocol packets. The server then sends the response to the | other protocol packets. The server then sends the response to the | |||
| client. | client. | |||
| 4.1.3. Receiving a Probe Response | 4.1.3. Receiving a Probe Response | |||
| A client receiving a Probe Response MUST process it as specified in | A client receiving a Probe Response MUST process it as specified in | |||
| [RFC5389] and MUST ignore the PADDING attribute. If a response is | [RFC5389] and MUST ignore the PADDING attribute. If a response is | |||
| received this is interpreted as a Probe Success, as defined in | received this is interpreted as a Probe Success, as defined in | |||
| [RFC4821] Section 7.6.1. If an ICMP packet "Fragmentation needed" is | [RFC4821] Section 7.6.1. If an ICMP packet "Fragmentation needed" or | |||
| received then this is interpreted as a Probe Failure, as defined in | "Packet Too Big" is received then this is interpreted as a Probe | |||
| [RFC4821] Section 7.6.2. If the Probe transaction times out, then | Failure, as defined in [RFC4821] Section 7.6.2. If the Probe | |||
| this is interpreted as a Probe Inconclusive, as defined in [RFC4821] | transaction times out, then this is interpreted as a Probe | |||
| Section 7.6.4. | Inconclusive, as defined in [RFC4821] Section 7.6.4. | |||
| 4.2. Complete Probing Mechanism | 4.2. Complete Probing Mechanism | |||
| The Complete Probing mechanism is implemented by sending one or more | The Complete Probing mechanism is implemented by sending one or more | |||
| Probe Indications with a PADDING attribute over UDP with the DF bit | Probe Indications with a PADDING attribute over UDP with the DF bit | |||
| set in the IP header followed by a Report Request to the same server. | set in the IP header for IPv4 packets and IPv6 packets without the | |||
| A router on the path to the server can reject this Indication with an | Fragment Header included followed by a Report Request to the same | |||
| ICMP message or drop it. The server keeps a chronologically ordered | server. A router on the path to the server can reject this | |||
| list of identifiers for all packets received (including retransmitted | Indication with an ICMP message or drop it. The server keeps a | |||
| packets) and sends this list back to the client in the Report | chronologically ordered list of identifiers for all packets received | |||
| Response. The client analyzes this list to find which packets were | (including retransmitted packets) and sends this list back to the | |||
| not received. Because UDP packets do not contain an identifier, the | client in the Report Response. The client analyzes this list to find | |||
| Complete Probing mechanism needs a way to identify each packet | which packets were not received. Because UDP packets do not contain | |||
| received. | an identifier, the Complete Probing mechanism needs a way to identify | |||
| each packet received. | ||||
| Some application layer protocols may already have a way of | Some application layer protocols may already have a way of | |||
| identifying each individual UDP packet, in which case these | identifying each individual UDP packet, in which case these | |||
| identifiers SHOULD be used in the IDENTIFIERS attribute of the Report | identifiers SHOULD be used in the IDENTIFIERS attribute of the Report | |||
| Response. While there are other possible packet identification | Response. While there are other possible packet identification | |||
| schemes, this document describes two different ways to identify a | schemes, this document describes two different ways to identify a | |||
| specific packet when no application layer protocol-specific | specific packet when no application layer protocol-specific | |||
| identification mechanism is available. | identification mechanism is available. | |||
| In the first packet identification mechanism, the server computes a | In the first packet identification mechanism, the server computes a | |||
| skipping to change at page 7, line 52 ¶ | skipping to change at page 8, line 9 ¶ | |||
| In the second packet identification mechanism, the client prepends | In the second packet identification mechanism, the client prepends | |||
| the UDP data with a header that provides a sequence number. The | the UDP data with a header that provides a sequence number. The | |||
| server sends back the chronologically ordered list of sequence | server sends back the chronologically ordered list of sequence | |||
| numbers received that the client then compares with its own list. | numbers received that the client then compares with its own list. | |||
| 4.2.1. Sending a Probe Indications and Report Request | 4.2.1. Sending a Probe Indications and Report Request | |||
| A client forms a Probe Indication by using the Probe Method and | A client forms a Probe Indication by using the Probe Method and | |||
| following the rules in [RFC5389] Section 7.1. The client adds to a | following the rules in [RFC5389] Section 7.1. The client adds to a | |||
| Probe Indication a PADDING [RFC5780] attribute with a size that, when | Probe Indication a PADDING attribute with a size that, when added to | |||
| added to the IP and UDP headers and the other STUN components, is | the IP and UDP headers and the other STUN components, is equal to the | |||
| equal to the Selected Probe Size, as defined in [RFC4821] | Selected Probe Size, as defined in [RFC4821] Section 7.3. The | |||
| Section 7.3. The PADDING bits MUST be set to zero. If the | PADDING bits SHOULD be set to zero. If the authentication mechanism | |||
| authentication mechanism permits it, then the Indication MUST be | permits it, then the Indication MUST be authenticated. The client | |||
| authenticated. The client MUST add the FINGERPRINT attribute so the | MUST add the FINGERPRINT attribute so the STUN messages are | |||
| STUN messages are disambiguated from the other protocol packets. | disambiguated from the other protocol packets. | |||
| Then the client sends a Probe Indication to the server over UDP with | Then the client sends a Probe Indication to the server over UDP with | |||
| the DF bit set. | the DF bit set for IPv4 packets and IPv6 packets without the Fragment | |||
| Header included. | ||||
| Then the client forms a Report Request by following the rules in | Then the client forms a Report Request by following the rules in | |||
| [RFC5389] Section 7.1. The Report transaction MUST be authenticated | [RFC5389] Section 7.1. The Report transaction MUST be authenticated | |||
| to prevent amplification attacks. The client MUST add the | to prevent amplification attacks. The client MUST add the | |||
| FINGERPRINT attribute so the STUN messages are disambiguated from the | FINGERPRINT attribute so the STUN messages are disambiguated from the | |||
| other protocol packets. | other protocol packets. | |||
| Then the client waits half the RTO after sending the last Probe | Then the client waits half the RTO after sending the last Probe | |||
| Indication and then sends the Report Request to the server over UDP. | Indication and then sends the Report Request to the server over UDP. | |||
| 4.2.2. Receiving an ICMP Packet | 4.2.2. Receiving an ICMP Packet | |||
| If an ICMP packet "Fragmentation needed" is received then this is | If an ICMP packet "Fragmentation needed" or "Packet Too Big" is | |||
| interpreted as a Probe Failure, as defined in [RFC4821] Section 7.5. | received then this is interpreted as a Probe Failure, as defined in | |||
| [RFC4821] Section 7.5. | ||||
| 4.2.3. Receiving a Probe Indication and Report Request | 4.2.3. Receiving a Probe Indication and Report Request | |||
| A server supporting this specification will keep the identifiers of | A server supporting this specification will keep the identifiers of | |||
| all packets received in a chronologically ordered list. The packets | all packets received in a chronologically ordered list. The packets | |||
| that are to be associated to an identifier are selected according to | that are to be associated to a given flow's identifier are selected | |||
| Section 5.2 of [RFC4821]. The same identifier can appear multiple | according to Section 5.2 of [RFC4821]. The same identifier can | |||
| times in the list because of retransmissions. The maximum size of | appear multiple times in the list because of retransmissions. The | |||
| this list is calculated such that when the list is added to the | maximum size of this list is calculated such that when the list is | |||
| Report Response, the total size of the packet does not exceed the | added to the Report Response, the total size of the packet does not | |||
| unknown Path MTU, as defined in [RFC5389] Section 7.1. Older | exceed the unknown Path MTU, as defined in [RFC5389] Section 7.1. | |||
| identifiers are removed when new identifiers are added to a list that | Older identifiers are removed when new identifiers are added to a | |||
| is already full. | list that is already full. | |||
| A server receiving a Report Request MUST process it as specified in | A server receiving a Report Request MUST process it as specified in | |||
| [RFC5389] and MUST ignore the PADDING attribute. | [RFC5389] and MUST ignore the PADDING attribute. | |||
| The server creates a Report Response and adds an IDENTIFIERS | The server creates a Report Response and adds an IDENTIFIERS | |||
| attribute that contains the chronologically ordered list of all | attribute that contains the chronologically ordered list of all | |||
| identifiers received so far. The server MUST add the FINGERPRINT | identifiers received so far. The server MUST add the FINGERPRINT | |||
| attribute. The server then sends the response to the client. | attribute. The server then sends the response to the client. | |||
| The exact content of the IDENTIFIERS attribute depends on what type | The exact content of the IDENTIFIERS attribute depends on what type | |||
| skipping to change at page 12, line 14 ¶ | skipping to change at page 12, line 22 ¶ | |||
| acquired and formatted. Therefore, the contents of the IDENTIFIERS | acquired and formatted. Therefore, the contents of the IDENTIFIERS | |||
| attribute is opaque. | attribute is opaque. | |||
| 6.2. PMTUD-SUPPORTED | 6.2. PMTUD-SUPPORTED | |||
| The PMTUD-SUPPORTED attribute indicates that its sender supports this | The PMTUD-SUPPORTED attribute indicates that its sender supports this | |||
| mechanism, as incorporated into the STUN usage or protocol being | mechanism, as incorporated into the STUN usage or protocol being | |||
| used. This attribute has no value part and thus the attribute length | used. This attribute has no value part and thus the attribute length | |||
| field is 0. | field is 0. | |||
| 6.3. PADDING | ||||
| The PADDING attribute allows for the entire message to be padded to | ||||
| force the STUN message to be divided into IP fragments. PADDING | ||||
| consists entirely of a free-form string, the value of which does not | ||||
| matter. PADDING can be used in either Binding Requests or Binding | ||||
| Responses. | ||||
| PADDING MUST NOT be longer than the length that brings the total IP | ||||
| datagram size to 64K. It SHOULD be equal in length to the MTU of the | ||||
| outgoing interface, rounded up to an even multiple of four bytes. | ||||
| Because STUN messages with PADDING are intended to test the behavior | ||||
| of UDP fragments, they are an exception to the usual rule that STUN | ||||
| messages be less than the MTU of the path. | ||||
| 7. Security Considerations | 7. Security Considerations | |||
| The PMTUD mechanism described in this document, when used without the | The PMTUD mechanism described in this document, when used without the | |||
| signalling mechanism described in Section 5.1, does not introduce any | signalling mechanism described in Section 5.1, does not introduce any | |||
| specific security considerations beyond those described in [RFC4821]. | specific security considerations beyond those described in [RFC4821]. | |||
| The attacks described in Section 11 of [RFC4821] apply equally to the | The attacks described in Section 11 of [RFC4821] apply equally to the | |||
| mechanism described in this document. | mechanism described in this document. | |||
| The amplification attacks introduced by the signalling mechanism | The amplification attacks introduced by the signalling mechanism | |||
| skipping to change at page 13, line 16 ¶ | skipping to change at page 13, line 37 ¶ | |||
| IANA is requested to add the following attributes to the STUN Method | IANA is requested to add the following attributes to the STUN Method | |||
| Registry: | Registry: | |||
| Comprehension-required range (0x0000-0x7FFF): | Comprehension-required range (0x0000-0x7FFF): | |||
| 0xXXXX: IDENTIFIERS | 0xXXXX: IDENTIFIERS | |||
| Comprehension-optional range (0x8000-0xFFFF) | Comprehension-optional range (0x8000-0xFFFF) | |||
| 0xXXXX: PMTUD-SUPPORTED | 0xXXXX: PMTUD-SUPPORTED | |||
| This IDENTIFIERS STUN attribute is defined in Section 6.1, the PMTUD- | 0x0026: PADDING | |||
| SUPPORTED STUN attribute is defined in Section 6.2. | ||||
| The IDENTIFIERS STUN attribute is defined in Section 6.1, the PMTUD- | ||||
| SUPPORTED STUN attribute is defined in Section 6.2; the PADDING STUN | ||||
| attribute is defined in Section 6.3. | ||||
| NOTE: TO BE DELETED BEFORE PUBLICATION. PLEASE NOTE THAT THE PADDING | ||||
| ATTRIBUTE ENTRY IS REPLACING THE ENTRY MADE BY RFC5780 | ||||
| (EXPERIMENTAL). THE SAME VALUE AND NAME ARE USED BUT THE REFERENCE | ||||
| SHOULD BE CHANGED TO THIS STANDARDS TRACK DOCUMENT. | ||||
| 9. References | 9. References | |||
| 9.1. Normative References | 9.1. Normative References | |||
| [ITU.V42.2002] | [ITU.V42.2002] | |||
| International Telecommunications Union, "Error-correcting | International Telecommunications Union, "Error-correcting | |||
| Procedures for DCEs Using Asynchronous-to-Synchronous | Procedures for DCEs Using Asynchronous-to-Synchronous | |||
| Conversion", ITU-T Recommendation V.42, 2002. | Conversion", ITU-T Recommendation V.42, 2002. | |||
| skipping to change at page 13, line 42 ¶ | skipping to change at page 14, line 28 ¶ | |||
| [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU | [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU | |||
| Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, | Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, | |||
| <http://www.rfc-editor.org/info/rfc4821>. | <http://www.rfc-editor.org/info/rfc4821>. | |||
| [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, | [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, | |||
| "Session Traversal Utilities for NAT (STUN)", RFC 5389, | "Session Traversal Utilities for NAT (STUN)", RFC 5389, | |||
| DOI 10.17487/RFC5389, October 2008, | DOI 10.17487/RFC5389, October 2008, | |||
| <http://www.rfc-editor.org/info/rfc5389>. | <http://www.rfc-editor.org/info/rfc5389>. | |||
| [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery | ||||
| Using Session Traversal Utilities for NAT (STUN)", | ||||
| RFC 5780, DOI 10.17487/RFC5780, May 2010, | ||||
| <http://www.rfc-editor.org/info/rfc5780>. | ||||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
| May 2017, <http://www.rfc-editor.org/info/rfc8174>. | May 2017, <http://www.rfc-editor.org/info/rfc8174>. | |||
| 9.2. Informative References | 9.2. Informative References | |||
| [I-D.martinsen-tram-stuntrace] | [I-D.martinsen-tram-stuntrace] | |||
| Martinsen, P. and D. Wing, "STUN Traceroute", draft- | Martinsen, P. and D. Wing, "STUN Traceroute", draft- | |||
| martinsen-tram-stuntrace-01 (work in progress), June 2015. | martinsen-tram-stuntrace-01 (work in progress), June 2015. | |||
| skipping to change at page 14, line 32 ¶ | skipping to change at page 15, line 15 ¶ | |||
| [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using | [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using | |||
| Relays around NAT (TURN): Relay Extensions to Session | Relays around NAT (TURN): Relay Extensions to Session | |||
| Traversal Utilities for NAT (STUN)", RFC 5766, | Traversal Utilities for NAT (STUN)", RFC 5766, | |||
| DOI 10.17487/RFC5766, April 2010, | DOI 10.17487/RFC5766, April 2010, | |||
| <https://www.rfc-editor.org/info/rfc5766>. | <https://www.rfc-editor.org/info/rfc5766>. | |||
| Appendix A. Release Notes | Appendix A. Release Notes | |||
| This section must be removed before publication as an RFC. | This section must be removed before publication as an RFC. | |||
| A.1. Modifications between draft-ietf-tram-stun-pmtud-11 and draft- | A.1. Modifications between draft-ietf-tram-stun-pmtud-12 and draft- | |||
| ietf-tram-stun-pmtud-11 | ||||
| o Modifications following IESG review. Incorporated RFC5780 PADDING | ||||
| attribute (Adam's Discuss) and added IPv6 language (Suresh's | ||||
| Discuss). | ||||
| A.2. Modifications between draft-ietf-tram-stun-pmtud-11 and draft- | ||||
| ietf-tram-stun-pmtud-10 | ietf-tram-stun-pmtud-10 | |||
| o Modifications following IESG review. | o Modifications following IESG review. | |||
| A.2. Modifications between draft-ietf-tram-stun-pmtud-10 and draft- | A.3. Modifications between draft-ietf-tram-stun-pmtud-10 and draft- | |||
| ietf-tram-stun-pmtud-09 | ietf-tram-stun-pmtud-09 | |||
| o Modifications following reviews for gen-art (Roni Even) and secdir | o Modifications following reviews for gen-art (Roni Even) and secdir | |||
| (Carl Wallace). | (Carl Wallace). | |||
| A.3. Modifications between draft-ietf-tram-stun-pmtud-09 and draft- | A.4. Modifications between draft-ietf-tram-stun-pmtud-09 and draft- | |||
| ietf-tram-stun-pmtud-08 | ietf-tram-stun-pmtud-08 | |||
| o Add 3 ways of preventing amplification attacks. | o Add 3 ways of preventing amplification attacks. | |||
| A.4. Modifications between draft-ietf-tram-stun-pmtud-08 and draft- | A.5. Modifications between draft-ietf-tram-stun-pmtud-08 and draft- | |||
| ietf-tram-stun-pmtud-07 | ietf-tram-stun-pmtud-07 | |||
| o Updates following Spencer's review. | o Updates following Spencer's review. | |||
| A.5. Modifications between draft-ietf-tram-stun-pmtud-07 and draft- | A.6. Modifications between draft-ietf-tram-stun-pmtud-07 and draft- | |||
| ietf-tram-stun-pmtud-06 | ietf-tram-stun-pmtud-06 | |||
| o Updates following Shepherd review. | o Updates following Shepherd review. | |||
| A.6. Modifications between draft-ietf-tram-stun-pmtud-06 and draft- | A.7. Modifications between draft-ietf-tram-stun-pmtud-06 and draft- | |||
| ietf-tram-stun-pmtud-05 | ietf-tram-stun-pmtud-05 | |||
| o Nits. | o Nits. | |||
| o Restore missing changelog for previous version. | o Restore missing changelog for previous version. | |||
| A.7. Modifications between draft-ietf-tram-stun-pmtud-05 and draft- | A.8. Modifications between draft-ietf-tram-stun-pmtud-05 and draft- | |||
| ietf-tram-stun-pmtud-04 | ietf-tram-stun-pmtud-04 | |||
| o Modifications following Brandon Williams review. | o Modifications following Brandon Williams review. | |||
| A.8. Modifications between draft-ietf-tram-stun-pmtud-04 and draft- | A.9. Modifications between draft-ietf-tram-stun-pmtud-04 and draft- | |||
| ietf-tram-stun-pmtud-03 | ietf-tram-stun-pmtud-03 | |||
| o Modifications following Simon Perreault and Brandon Williams | o Modifications following Simon Perreault and Brandon Williams | |||
| reviews. | reviews. | |||
| A.9. Modifications between draft-ietf-tram-stun-pmtud-03 and draft- | A.10. Modifications between draft-ietf-tram-stun-pmtud-03 and draft- | |||
| ietf-tram-stun-pmtud-02 | ietf-tram-stun-pmtud-02 | |||
| o Add new Overview of Operations section with ladder diagrams. | o Add new Overview of Operations section with ladder diagrams. | |||
| o Authentication is mandatory for the Complete Probing mechanism, | o Authentication is mandatory for the Complete Probing mechanism, | |||
| optional for the Simple Probing mechanism. | optional for the Simple Probing mechanism. | |||
| o All the ICE specific text moves to a separate draft to be | o All the ICE specific text moves to a separate draft to be | |||
| discussed in the ICE WG. | discussed in the ICE WG. | |||
| o The TURN usage is removed because probing between a TURN server | o The TURN usage is removed because probing between a TURN server | |||
| skipping to change at page 16, line 26 ¶ | skipping to change at page 17, line 17 ¶ | |||
| o Each usage of this specification must the format of the | o Each usage of this specification must the format of the | |||
| IDENTIFIERS attribute contents. | IDENTIFIERS attribute contents. | |||
| o Better define the implicit signaling mechanism. | o Better define the implicit signaling mechanism. | |||
| o Extend the Security Consideration section. | o Extend the Security Consideration section. | |||
| o Tons of nits. | o Tons of nits. | |||
| A.10. Modifications between draft-ietf-tram-stun-pmtud-02 and draft- | A.11. Modifications between draft-ietf-tram-stun-pmtud-02 and draft- | |||
| ietf-tram-stun-pmtud-01 | ietf-tram-stun-pmtud-01 | |||
| o Cleaned up references. | o Cleaned up references. | |||
| A.11. Modifications between draft-ietf-tram-stun-pmtud-01 and draft- | A.12. Modifications between draft-ietf-tram-stun-pmtud-01 and draft- | |||
| ietf-tram-stun-pmtud-00 | ietf-tram-stun-pmtud-00 | |||
| o Added Security Considerations Section. | o Added Security Considerations Section. | |||
| o Added IANA Considerations Section. | o Added IANA Considerations Section. | |||
| A.12. Modifications between draft-ietf-tram-stun-pmtud-00 and draft- | A.13. Modifications between draft-ietf-tram-stun-pmtud-00 and draft- | |||
| petithuguenin-tram-stun-pmtud-01 | petithuguenin-tram-stun-pmtud-01 | |||
| o Adopted by WG - Text unchanged. | o Adopted by WG - Text unchanged. | |||
| A.13. Modifications between draft-petithuguenin-tram-stun-pmtud-01 and | A.14. Modifications between draft-petithuguenin-tram-stun-pmtud-01 and | |||
| draft-petithuguenin-tram-stun-pmtud-00 | draft-petithuguenin-tram-stun-pmtud-00 | |||
| o Moved some Introduction text to the Probing Mechanism section. | o Moved some Introduction text to the Probing Mechanism section. | |||
| o Added cross-reference to the other two STUN troubleshooting | o Added cross-reference to the other two STUN troubleshooting | |||
| mechanism drafts. | mechanism drafts. | |||
| o Updated references. | o Updated references. | |||
| o Added Gonzalo Salgueiro as co-author. | o Added Gonzalo Salgueiro as co-author. | |||
| A.14. Modifications between draft-petithuguenin-tram-stun-pmtud-00 and | A.15. Modifications between draft-petithuguenin-tram-stun-pmtud-00 and | |||
| draft-petithuguenin-behave-stun-pmtud-03 | draft-petithuguenin-behave-stun-pmtud-03 | |||
| o General refresh for republication. | o General refresh for republication. | |||
| A.15. Modifications between draft-petithuguenin-behave-stun-pmtud-03 | A.16. Modifications between draft-petithuguenin-behave-stun-pmtud-03 | |||
| and draft-petithuguenin-behave-stun-pmtud-02 | and draft-petithuguenin-behave-stun-pmtud-02 | |||
| o Changed author address. | o Changed author address. | |||
| o Changed the IPR to trust200902. | o Changed the IPR to trust200902. | |||
| A.16. Modifications between draft-petithuguenin-behave-stun-pmtud-02 | A.17. Modifications between draft-petithuguenin-behave-stun-pmtud-02 | |||
| and draft-petithuguenin-behave-stun-pmtud-01 | and draft-petithuguenin-behave-stun-pmtud-01 | |||
| o Defined checksum and sequential numbers as possible packet | o Defined checksum and sequential numbers as possible packet | |||
| identifiers. | identifiers. | |||
| o Updated the reference to RFC 5389 | o Updated the reference to RFC 5389 | |||
| o The FINGERPRINT attribute is now mandatory. | o The FINGERPRINT attribute is now mandatory. | |||
| o Changed the delay between Probe indication and Report request to | o Changed the delay between Probe indication and Report request to | |||
| be RTO/2 or 50 milliseconds. | be RTO/2 or 50 milliseconds. | |||
| o Added ICMP packet processing. | o Added ICMP packet processing. | |||
| o Added Full-Stop Timeout detection. | o Added Full-Stop Timeout detection. | |||
| o Stated that Binding request with PMTUD-SUPPORTED does not start | o Stated that Binding request with PMTUD-SUPPORTED does not start | |||
| the PMTUD process if already started. | the PMTUD process if already started. | |||
| A.17. Modifications between draft-petithuguenin-behave-stun-pmtud-01 | A.18. Modifications between draft-petithuguenin-behave-stun-pmtud-01 | |||
| and draft-petithuguenin-behave-stun-pmtud-00 | and draft-petithuguenin-behave-stun-pmtud-00 | |||
| o Removed the use of modified STUN transaction but shorten the | o Removed the use of modified STUN transaction but shorten the | |||
| retransmission for the simple probing mechanism. | retransmission for the simple probing mechanism. | |||
| o Added a complete probing mechanism. | o Added a complete probing mechanism. | |||
| o Removed the PADDING-RECEIVED attribute. | o Removed the PADDING-RECEIVED attribute. | |||
| o Added release notes. | o Added release notes. | |||
| End of changes. 48 change blocks. | ||||
| 113 lines changed or deleted | 147 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||