draft-ietf-tram-stun-pmtud-04.txt   draft-ietf-tram-stun-pmtud-05.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: August 20, 2017 Cisco Expires: August 24, 2017 Cisco
February 16, 2017 February 20, 2017
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-04 draft-ietf-tram-stun-pmtud-05
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 32 skipping to change at page 1, line 32
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 August 20, 2017. This Internet-Draft will expire on August 24, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 5, line 16 skipping to change at page 5, line 16
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. When these document are to be interpreted as described in [RFC2119]. When these
words are not in ALL CAPS (such as "must" or "Must"), they have their words are not in ALL CAPS (such as "must" or "Must"), they have their
usual English meanings, and are not to be interpreted as RFC 2119 key usual English meanings, and are not to be interpreted as RFC 2119 key
words. words.
4. Probing Mechanisms 4. Probing Mechanisms
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
signalling or by a mechanism specific to the UDP protocol to which
PMTUD capabilities are added or by one of the mechanisms specified in
Section 5.
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 quicker and find an
appropriate PMTU in the presence of congestion. Additionally, the appropriate PMTU in the presence of congestion. Additionally, the
Simple Probing mechanism does not require authentication, whereas the Simple Probing mechanism does not require authentication, whereas the
complete mechanism does. complete mechanism does.
Implementations supporting this specification MUST implement the Implementations supporting this specification MUST implement the
skipping to change at page 6, line 4 skipping to change at page 5, line 47
UDP. A router on the path to the server can reject this request with UDP. A router on the path to the server can reject this request with
an ICMP message or drop it. 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 transctaion MAY mechanism described in Section 5.2 If not, the Probe transaction MAY
be authenticated. be authenticated.
The client adds a PADDING [RFC5780] attribute with a length that, The client adds a PADDING [RFC5780] attribute with a length that,
when added to the IP and UDP headers and the other STUN components, when added to the IP and UDP headers and the other STUN components,
is equal to the Selected Probe Size, as defined in [RFC4821] is equal to the Selected Probe Size, as defined in [RFC4821]
Section 7.3. The client MUST add the FINGERPRINT attribute. Section 7.3. The client MUST add the FINGERPRINT attribute so the
STUN messages are disambiguated from the 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 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
server supports this specification. This is done either by external
signalling or by a mechanism specific to the UDP protocol to which
PMTUD capabilities are added or by one of the mechanisms specified in
Section 5.
4.1.2. Receiving a Probe Request 4.1.2. Receiving a Probe Request
A server receiving a Probe Request MUST process it as specified in A server receiving a Probe Request MUST process it as specified in
[RFC5389]. [RFC5389].
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.
skipping to change at page 7, line 29 skipping to change at page 7, line 29
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 the Probe Indications and Report Request 4.2.1. Sending the 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 the following the rules in [RFC5389] Section 7.1. The client adds to the
Probe Indication a PADDING attribute with a size that, when added to Probe Indication a PADDING attribute with a size that, when added to
the IP and UDP headers and the other STUN components, is equal to the the IP and UDP headers and the other STUN components, is equal to the
Selected Probe Size, as defined in [RFC4821] Section 7.3. If the Selected Probe Size, as defined in [RFC4821] Section 7.3. If the
authentication mechanism permits it, then the Indication MUST be authentication mechanism permits it, then the Indication MUST be
authenticated. The server MUST add the FINGERPRINT attribute so the authenticated. The client MUST add the FINGERPRINT attribute so the
STUN messages are disambiguated from the other protocol packets. STUN messages are disambiguated from the other protocol packets.
Then the client sends the Probe Indication to the server over UDP Then the client sends the Probe Indication to the server over UDP
with the DF bit set. with the DF bit set.
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.
skipping to change at page 9, line 12 skipping to change at page 9, line 12
If the Report Transaction times out, this is interpreted as a Full- If the Report Transaction times out, this is interpreted as a Full-
Stop Timeout, as defined in [RFC4821] Section 3. Stop Timeout, as defined in [RFC4821] Section 3.
4.2.5. Using Checksums as Packet Identifiers 4.2.5. Using Checksums as Packet Identifiers
When using a checksum as a packet identifier, the client calculates When using a checksum as a packet identifier, the client calculates
the checksum for each packet sent over UDP that is not a STUN Probe the checksum for each packet sent over UDP that is not a STUN Probe
Indication or Request and keeps this checksum in a chronologically Indication or Request and keeps this checksum in a chronologically
ordered list. The client also keeps the checksum of the STUN Probe ordered list. The client also keeps the checksum of the STUN Probe
Indication or Request sent in that same chronologically ordered list. Indication or Request sent in that same chronologically ordered list.
The algorithm used to calculate the checksum is the same as the The algorithm used to calculate the checksum is similar to the
algorithm used for the FINGERPRINT attribute (i.e., the CRC-32 of the algorithm used for the FINGERPRINT attribute (i.e., the CRC-32 of the
payload XOR'ed with the 32-bit value 0x5354554e). payload XOR'ed with the 32-bit value 0x5354554e).
The server calculates the checksum for each received packet that is For each STUN Probe Indication or Request, the server retrieves the
not a STUN Probe Indication or Request and retrieve the FINGERPRINT STUN FINGERPRINT value. For all other packets, the server calculates
attribute value if the packet is a STUN Probe Indication or Request. the checksum as described above. It puts these FINGERPRINT and
It puts these checksums in a chronologically ordered list that is checksum values in a chronologically ordered list that is sent back
sent back in the Report Response. in the Report Response.
The contents of the IDENTIFIERS attribute is a list of 4 byte The contents of the IDENTIFIERS attribute is a list of 4 byte
numbers, each using the same encoding that is used for the contents numbers, each using the same encoding that is used for the contents
of the FINGERPRINT attribute. of the FINGERPRINT attribute.
It could have been possible to use the checksum generated in the UDP It could have been possible to use the checksum generated in the UDP
checksum for this, but this value is generally not accessible to checksum for this, but this value is generally not accessible to
applications. Also, sometimes the checksum is not calculated or is applications. Also, sometimes the checksum is not calculated or is
off-loaded to network hardware. off-loaded to network hardware.
skipping to change at page 11, line 11 skipping to change at page 11, line 11
UDP-based protocols that want to use any of these mechanisms, UDP-based protocols that want to use any of these mechanisms,
including the PMTUD-SUPPORTED attribute, to signal PMTUD capabilities including the PMTUD-SUPPORTED attribute, to signal PMTUD capabilities
MUST ensure that it cannot be used to launch an amplification attack. MUST ensure that it cannot be used to launch an amplification attack.
For example, using authentication can ensure this. For example, using authentication can ensure this.
5.2. Implicit Probe Support Signaling Mechanism 5.2. Implicit Probe Support Signaling Mechanism
As a result of the fact that all endpoints implementing this As a result of the fact that all endpoints implementing this
specification are both clients and servers, a Probe Request or specification are both clients and servers, a Probe Request or
Indication received by an endpoint implicitly signals that its sender Indication received by an endpoint acting as a server implicitly
MAY be used to probe the Path MTU in the reverse direction. signals that this server can now act as a client and MAY send a Probe
Request or Indication to probe the Path MTU in the reverse direction
toward the former client, that will now be acting as a server.
The Probe Request or Indication that are used to implicitly signal The Probe Request or Indication that are used to implicitly signal
probing support in the reverse direction MUST be authenticated to probing support in the reverse direction MUST be authenticated to
prevent amplification attacks. prevent amplification attacks.
6. STUN Attributes 6. STUN Attributes
6.1. IDENTIFIERS 6.1. IDENTIFIERS
The IDENTIFIERS attribute carries a chronologically ordered list of The IDENTIFIERS attribute carries a chronologically ordered list of
UDP packet identifiers. UDP packet identifiers.
Each protocol has to define how these identifiers are acquired and While Sections Section 4.2.5 and Section 4.2.6 describe two possible
formatted, therefore the contents of the IDENTIFIERS attribute is methods for acquiring and formatting the identifiers used for this
opaque. purpose, ultimately each protocol has to define how these identifiers
are acquired and formatted. Therefore, the contents of the
IDENTIFIERS 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
specification. This attribute has no value part and thus the specification. This attribute has no value part and thus the
attribute length field is 0. attribute length field is 0.
7. Security Considerations 7. Security Considerations
The PMTUD mechanism described in this document does not introduce any The PMTUD mechanism described in this document does not introduce any
 End of changes. 12 change blocks. 
24 lines changed or deleted 29 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/