draft-ietf-tsvwg-datagram-plpmtud-04.txt   draft-ietf-tsvwg-datagram-plpmtud-05.txt 
Internet Engineering Task Force G. Fairhurst Internet Engineering Task Force G. Fairhurst
Internet-Draft T. Jones Internet-Draft T. Jones
Updates: 4821 (if approved) University of Aberdeen Updates: 4821 (if approved) University of Aberdeen
Intended status: Standards Track M. Tuexen Intended status: Standards Track M. Tuexen
Expires: March 9, 2019 I. Ruengeler Expires: April 5, 2019 I. Ruengeler
Muenster University of Applied Sciences Muenster University of Applied Sciences
September 5, 2018 October 02, 2018
Packetization Layer Path MTU Discovery for Datagram Transports Packetization Layer Path MTU Discovery for Datagram Transports
draft-ietf-tsvwg-datagram-plpmtud-04 draft-ietf-tsvwg-datagram-plpmtud-05
Abstract Abstract
This document describes a robust method for Path MTU Discovery This document describes a robust method for Path MTU Discovery
(PMTUD) for datagram Packetization Layers (PLs). The document (PMTUD) for datagram Packetization Layers (PLs). The document
describes an extension to RFC 1191 and RFC 8201, which specifies describes an extension to RFC 1191 and RFC 8201, which specifies
ICMP-based Path MTU Discovery for IPv4 and IPv6. The method allows a ICMP-based Path MTU Discovery for IPv4 and IPv6. The method allows a
PL, or a datagram application that uses a PL, to discover whether a PL, or a datagram application that uses a PL, to discover whether a
network path can support the current size of datagram. This can be network path can support the current size of datagram. This can be
used to detect and reduce the message size when a sender encounters a used to detect and reduce the message size when a sender encounters a
skipping to change at page 1, line 35 skipping to change at page 1, line 35
progressively larger packets to find whether the maximum packet size progressively larger packets to find whether the maximum packet size
can be increased. This allows a sender to determine an appropriate can be increased. This allows a sender to determine an appropriate
packet size, providing functionally for datagram transports that is packet size, providing functionally for datagram transports that is
equivalent to the Packetization layer PMTUD specification for TCP, equivalent to the Packetization layer PMTUD specification for TCP,
specified in RFC 4821. specified in RFC 4821.
The document also provides implementation notes for incorporating The document also provides implementation notes for incorporating
Datagram PMTUD into IETF datagram transports or applications that use Datagram PMTUD into IETF datagram transports or applications that use
datagram transports. datagram transports.
When published, this specification updates RFC 4821 when used with When published, this specification updates RFC 4821.
datagram transports.
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.
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 March 9, 2019. This Internet-Draft will expire on April 5, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 3, line 20 skipping to change at page 3, line 20
5.4.3. Resilience to inconsistent Path information . . . . . 28 5.4.3. Resilience to inconsistent Path information . . . . . 28
6. Specification of Protocol-Specific Methods . . . . . . . . . 28 6. Specification of Protocol-Specific Methods . . . . . . . . . 28
6.1. Application support for DPLPMTUD with UDP or UDP-Lite . . 28 6.1. Application support for DPLPMTUD with UDP or UDP-Lite . . 28
6.1.1. Application Request . . . . . . . . . . . . . . . . . 29 6.1.1. Application Request . . . . . . . . . . . . . . . . . 29
6.1.2. Application Response . . . . . . . . . . . . . . . . 29 6.1.2. Application Response . . . . . . . . . . . . . . . . 29
6.1.3. Sending Application Probe Packets . . . . . . . . . . 29 6.1.3. Sending Application Probe Packets . . . . . . . . . . 29
6.1.4. Validating the Path . . . . . . . . . . . . . . . . . 29 6.1.4. Validating the Path . . . . . . . . . . . . . . . . . 29
6.1.5. Handling of PTB Messages . . . . . . . . . . . . . . 29 6.1.5. Handling of PTB Messages . . . . . . . . . . . . . . 29
6.2. DPLPMTUD with UDP Options . . . . . . . . . . . . . . . . 30 6.2. DPLPMTUD with UDP Options . . . . . . . . . . . . . . . . 30
6.2.1. UDP Probe Request Option . . . . . . . . . . . . . . 31 6.2.1. UDP Probe Request Option . . . . . . . . . . . . . . 31
6.2.2. UDP Probe Response Option . . . . . . . . . . . . . . 31 6.2.2. UDP Probe Response Option . . . . . . . . . . . . . . 32
6.3. DPLPMTUD for SCTP . . . . . . . . . . . . . . . . . . . . 32 6.3. DPLPMTUD for SCTP . . . . . . . . . . . . . . . . . . . . 32
6.3.1. SCTP/IPv4 and SCTP/IPv6 . . . . . . . . . . . . . . . 32 6.3.1. SCTP/IPv4 and SCTP/IPv6 . . . . . . . . . . . . . . . 32
6.3.1.1. Sending SCTP Probe Packets . . . . . . . . . . . 32 6.3.1.1. Sending SCTP Probe Packets . . . . . . . . . . . 32
6.3.1.2. Validating the Path with SCTP . . . . . . . . . . 33 6.3.1.2. Validating the Path with SCTP . . . . . . . . . . 33
6.3.1.3. PTB Message Handling by SCTP . . . . . . . . . . 33 6.3.1.3. PTB Message Handling by SCTP . . . . . . . . . . 33
6.3.2. DPLPMTUD for SCTP/UDP . . . . . . . . . . . . . . . . 33 6.3.2. DPLPMTUD for SCTP/UDP . . . . . . . . . . . . . . . . 33
6.3.2.1. Sending SCTP/UDP Probe Packets . . . . . . . . . 33 6.3.2.1. Sending SCTP/UDP Probe Packets . . . . . . . . . 33
6.3.2.2. Validating the Path with SCTP/UDP . . . . . . . . 33 6.3.2.2. Validating the Path with SCTP/UDP . . . . . . . . 34
6.3.2.3. Handling of PTB Messages by SCTP/UDP . . . . . . 33 6.3.2.3. Handling of PTB Messages by SCTP/UDP . . . . . . 34
6.3.3. DPLPMTUD for SCTP/DTLS . . . . . . . . . . . . . . . 33 6.3.3. DPLPMTUD for SCTP/DTLS . . . . . . . . . . . . . . . 34
6.3.3.1. Sending SCTP/DTLS Probe Packets . . . . . . . . . 34 6.3.3.1. Sending SCTP/DTLS Probe Packets . . . . . . . . . 34
6.3.3.2. Validating the Path with SCTP/DTLS . . . . . . . 34 6.3.3.2. Validating the Path with SCTP/DTLS . . . . . . . 34
6.3.3.3. Handling of PTB Messages by SCTP/DTLS . . . . . . 34 6.3.3.3. Handling of PTB Messages by SCTP/DTLS . . . . . . 34
6.4. DPLPMTUD for QUIC . . . . . . . . . . . . . . . . . . . . 34 6.4. DPLPMTUD for QUIC . . . . . . . . . . . . . . . . . . . . 34
6.4.1. Sending QUIC Probe Packets . . . . . . . . . . . . . 34 6.4.1. Sending QUIC Probe Packets . . . . . . . . . . . . . 35
6.4.2. Validating the Path with QUIC . . . . . . . . . . . . 35 6.4.2. Validating the Path with QUIC . . . . . . . . . . . . 35
6.4.3. Handling of PTB Messages by QUIC . . . . . . . . . . 35 6.4.3. Handling of PTB Messages by QUIC . . . . . . . . . . 35
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.1. Normative References . . . . . . . . . . . . . . . . . . 36 10.1. Normative References . . . . . . . . . . . . . . . . . . 37
10.2. Informative References . . . . . . . . . . . . . . . . . 38 10.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix A. Event-driven state changes . . . . . . . . . . . . . 38 Appendix A. Event-driven state changes . . . . . . . . . . . . . 39
Appendix B. Revision Notes . . . . . . . . . . . . . . . . . . . 41 Appendix B. Revision Notes . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
The IETF has specified datagram transport using UDP, SCTP, and DCCP, The IETF has specified datagram transport using UDP, SCTP, and DCCP,
as well as protocols layered on top of these transports (e.g., SCTP/ as well as protocols layered on top of these transports (e.g., SCTP/
UDP, DCCP/UDP, QUIC/UDP), and direct datagram transport over the IP UDP, DCCP/UDP, QUIC/UDP), and direct datagram transport over the IP
network layer. This document describes a robust method for Path MTU network layer. This document describes a robust method for Path MTU
Discovery (PMTUD) that may be used with these transport protocols (or Discovery (PMTUD) that may be used with these transport protocols (or
the applications that use their transport service) to discover an the applications that use their transport service) to discover an
appropriate size of packet to use across an Internet path. appropriate size of packet to use across an Internet path.
This specification clarifies the PLPMTUD method for SCTP described in
section 10.2 of [RFC4821] by specifying the procedure in Section 6.3
of this document.
1.1. Classical Path MTU Discovery 1.1. Classical Path MTU Discovery
Classical Path Maximum Transmission Unit Discovery (PMTUD) can be Classical Path Maximum Transmission Unit Discovery (PMTUD) can be
used with any transport that is able to process ICMP Packet Too Big used with any transport that is able to process ICMP Packet Too Big
(PTB) messages (e.g., [RFC1191] and [RFC8201]). The term PTB message (PTB) messages (e.g., [RFC1191] and [RFC8201]). The term PTB message
is applied to both IPv4 ICMP Unreachable messages (Type 3) that carry is applied to both IPv4 ICMP Unreachable messages (Type 3) that carry
the error Fragmentation Needed (Type 3, Code 4) and ICMPv6 packet too the error Fragmentation Needed (Type 3, Code 4) and ICMPv6 packet too
big messages (Type 2). When a sender receives a PTB message, it big messages (Type 2). When a sender receives a PTB message, it
reduces the effective MTU to the value reported in the PTB message reduces the effective MTU to the value reported in the PTB message
(in this document called the PTB_SIZE). A method from time-to-time (in this document called the PTB_SIZE). A method from time-to-time
skipping to change at page 7, line 18 skipping to change at page 7, line 12
not risk application data loss. The method defined in this not risk application data loss. The method defined in this
specification could be used with DCCP. specification could be used with DCCP.
Section 6 specifies the method for a set of transports, and provides Section 6 specifies the method for a set of transports, and provides
information to enable the implementation of PLPMTUD with other information to enable the implementation of PLPMTUD with other
datagram transports and applications that use datagram transports. datagram transports and applications that use datagram transports.
2. Terminology 2. Terminology
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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [[RFC8174]] when, and only when, they appear in all
capitals, as shown here.
Other terminology is directly copied from [RFC4821], and the Other terminology is directly copied from [RFC4821], and the
definitions in [RFC1122]. definitions in [RFC1122].
Actual PMTU: The Actual PMTU is the PMTU of a network path between a Actual PMTU: The Actual PMTU is the PMTU of a network path between a
sender PL and a destination PL, which the DPLPMTUD algorithm seeks sender PL and a destination PL, which the DPLPMTUD algorithm seeks
to determine. to determine.
Black Holed: Packets are Black holed when the sender is unaware that Black Holed: Packets are Black holed when the sender is unaware that
packets are not delivered to the destination endpoint (e.g., when packets are not delivered to the destination endpoint (e.g., when
skipping to change at page 24, line 16 skipping to change at page 24, line 16
(PROBE_COUNT = MAX_PROBES) (PROBE_COUNT = MAX_PROBES)
+-------------------+ +--------------+ +-------------------+ +--------------+
| PROBE_START +------>|PROBE_DISABLED| | PROBE_START +------>|PROBE_DISABLED|
+-------------------+ +--------------+ +-------------------+ +--------------+
| ^ | ^
| Path confirmed | | Path confirmed |
v | v |
MAX_PMTU acked or +--------------+-+ (PROBE_COUNT | MAX_PMTU acked or +--------------+-+ (PROBE_COUNT |
PTB (BASE_PMTU <= +---------| PROBE_SEARCH | | < MAX_PROBES) | PTB (BASE_PMTU <= +---------| PROBE_SEARCH | | < MAX_PROBES) |
PTB_SIZE | +--> +--------------+<+ or Probe acked | PTB_SIZE | +--> +--------------+<+ or Probe acked |
<PROBED_SIZE) | | | ^ | <PROBED_SIZE) | | | ^ | |
or | | | | | or | | | | | |
(PROBE_COUNT | | | | | (PROBE_COUNT | | | | |((PTB_SIZE < |
=MAX_PROBES) | | | | | =MAX_PROBES) | | | | | BASE_PMTU) |
+---------------+ | | | | +---------------+ | | | | or |
| | | | | | | | | |(PLPMTU < BASE_MTU)) |
| | | | | | | | | |and (PROBE_COUNT = |
| PMTU_RAISE_TIMER | | | | | PMTU_RAISE_TIMER | | | | MAX_PROBES) |
| | | | | | | | | | |
| | | | | | | | | \ |
| +-----------+ | | | | +-----------+ | | \ Suspend DPLPDMTUD:|
| | | | | | | | | \ |
| | | | | | | | | \---------+ |
| | (PTB_SIZE < PLPMTU)| | | | | (PTB_SIZE < PLPMTU)| | | |
| | or | | BASE_PMTU | | | or | | BASE_PMTU | |
| | Black hole detected | | Probe acked | | | Black hole detected | | Probe acked | |
v | v | | v | v | v |
+----------+----+ +--------------+ +-------------+ +----------+----+ +--------------+ +-------------+
|SEARCH_COMPLETE|----------->| PROBE_BASE |<-------| PROBE_ERROR | |SEARCH_COMPLETE|----------->| PROBE_BASE |<-------| PROBE_ERROR |
+------+--------+ +--------------+ +-------------+ +------+--------+ +--------------+ +-------------+
/\ | Black hole detected ^ | | BASE_PMTU Probe acked: ^ /\ | Black hole detected ^ | | BASE_PMTU Probe acked: ^
| | or | | | | | | or | | | |
| | (PTB_SIZE < PLPMTU) | | | Probe BASE_PMTU: | | | (PTB_SIZE < PLPMTU) | | | Probe BASE_PMTU: |
| | | | | (PROBE_COUNT = MAX_PROBES)| | | | | | (PROBE_COUNT = MAX_PROBES)|
| | | | +---------------------------+ | | | | +---------------------------+
+----+ +--+ +----+ +--+
Confirmation: PROBE_TIMER expiry: Confirmation: PROBE_TIMER expiry:
skipping to change at page 30, line 12 skipping to change at page 30, line 12
probed size. A validated PTB message MAY be used as input to the probed size. A validated PTB message MAY be used as input to the
DPLPMTUD algorithm, but MUST NOT be used directly to set the PLPMTU. DPLPMTUD algorithm, but MUST NOT be used directly to set the PLPMTU.
6.2. DPLPMTUD with UDP Options 6.2. DPLPMTUD with UDP Options
UDP Options[I-D.ietf-tsvwg-udp-options] can supply the additional UDP Options[I-D.ietf-tsvwg-udp-options] can supply the additional
functionality required to implement DPLPMTUD within the UDP transport functionality required to implement DPLPMTUD within the UDP transport
service. Implementing DPLPMTU using UDP Options avoids the need for service. Implementing DPLPMTU using UDP Options avoids the need for
each application to implement the DPLPMTUD method. each application to implement the DPLPMTUD method.
Section 5.6 of[I-D.ietf-tsvwg-udp-options] defines the MSS option, Section 5.6 of[I-D.ietf-tsvwg-udp-options] defines the Maximum
which allows the local sender to indicate the EMTU_R to the peer. Segment Size (MSS) option, which allows the local sender to indicate
The value received in this option can be used to initialise PMTU_MAX. the EMTU_R to the peer. The value received in this option can be
used to initialise PMTU_MAX.
UDP Options enables padding to be added to UDP datagrams that are UDP Options enables padding to be added to UDP datagrams that are
used as Probe Packets. Feedback confirming reception of each Probe used as Probe Packets. Feedback confirming reception of each Probe
Packet is provided by two new UDP Options: Packet is provided by two new UDP Options:
o The Probe Request Option (Section 6.2.1) is set by a sending PL to o The Probe Request Option (Section 6.2.1) is set by a sending PL to
solicit a response from a remote endpoint. A four-byte token solicit a response from a remote endpoint. A four-byte token
identifies each request. identifies each request.
o The Probe Response Option (Section 6.2.2 is generated by the UDP o The Probe Response Option (Section 6.2.2 is generated by the UDP
skipping to change at page 30, line 39 skipping to change at page 30, line 40
The token value allows implementations to be distinguish between The token value allows implementations to be distinguish between
acknowledgements for initial probe packets and acknowledgements acknowledgements for initial probe packets and acknowledgements
confirming receipt of subsequent probe packets (e.g., travelling confirming receipt of subsequent probe packets (e.g., travelling
along alternate paths with a larger RTT). Each probe packet needs to along alternate paths with a larger RTT). Each probe packet needs to
be uniquely identifiable by the UDP Options sender within the Maximum be uniquely identifiable by the UDP Options sender within the Maximum
Segment Lifetime (MSL). The UDP Options sender therefore needs to Segment Lifetime (MSL). The UDP Options sender therefore needs to
not recycle token values until they have expired or have been not recycle token values until they have expired or have been
acknowledged. A 4 byte value for the token field provides sufficient acknowledged. A 4 byte value for the token field provides sufficient
space for multiple unique probes to be made within the MSL. space for multiple unique probes to be made within the MSL.
Implementations ought to only send a probe packet with a Probe The initial value of the four byte token field SHOULD be assigned to
Request Option when required by their local state machine, i.e., when a randomised value, as described in section 5.1 of [RFC8085]) to
enhance protection from off-path attacks.
Implementations ought to only send a probe packet with a Request
Probe Option when required by their local state machine, i.e., when
probing to grow the PLPMTU or to confirm the current PLPMTU. The probing to grow the PLPMTU or to confirm the current PLPMTU. The
procedure to handle the loss of a response packet is the procedure to handle the loss of a response packet is the
responsibility of the sender of the request. responsibility of the sender of the request. Implementations are
allowed to track multiple requests and respond to them with a single
packet.
A PL needs to determine that the path can still support the size of A PL needs to determine that the path can still support the size of
datagram that the application is currently sending in the DPLPMTUD datagram that the application is currently sending in the DPLPMTUD
search_done state (i.e., to detect black-holing of data). One way to search_done state (i.e., to detect black-holing of data). One way to
achieve this is to send probe packets of size PLPMTU or to utilise a achieve this is to send probe packets of size PLPMTU or to utilise a
higher-layer method that provides explicit feedback indicating any higher-layer method that provides explicit feedback indicating any
packet loss. Another possibility is to utilise data packets that packet loss. Another possibility is to utilise data packets that
carry a Timestamp Option. Reception of a valid timestamp that was carry a Timestamp Option. Reception of a valid timestamp that was
echoed by the remote endpoint can be used to infer connectivity. echoed by the remote endpoint can be used to infer connectivity.
This can provide useful feedback even over paths with asymmetric This can provide useful feedback even over paths with asymmetric
capacity and/or that carry UDP Option flows that have very asymmetric capacity and/or that carry UDP Option flows that have very asymmetric
datagram rates, because an echo of the most recent timestamp still datagram rates, because an echo of the most recent timestamp still
indicates reception of at least one packet of the transmitted size. indicates reception of at least one packet of the transmitted size.
This is sufficient to confirm there is no black hole. This is sufficient to confirm there is no black hole.
In contrast, when sending a probe to increase the PLPMTU, a timestamp In contrast, when sending a probe to increase the PLPMTU, a timestamp
may be unable to unambiguously identify that a specific probe packet might be unable to unambiguously identify that a specific probe
has been received. Timestamp mechanisms cannot be used to confirm packet has been received. Timestamp mechanisms cannot be used to
the reception of individual probe messages and cannot be used to confirm the reception of individual probe messages and cannot be used
stimulate a response from the remote peer. to stimulate a response from the remote peer.
6.2.1. UDP Probe Request Option 6.2.1. UDP Probe Request Option
The Probe Request Option allows a sending endpoint to solicit a The Probe Request Option allows a sending endpoint to solicit a
response from a destination endpoint. response from a destination endpoint.
The Probe Request Option carries a four byte token set by the sender. The Probe Request Option carries a four byte token set by the sender.
This token can be set to a value that is likely to be known only to This token can be set to a value that is likely to be known only to
the sender (and is sent along the end-to-end path). The sender can the sender (and is sent along the end-to-end path). The initial
then check the value returned in the UDP Probe Response Option. The value of the token SHOULD be assigned to a randomised value, as
value of the Token field, uniquely identifies a probe within the described in section 5.1 of [RFC8085]) to enhance protection from
maximum segment lifetime and can also provide additional protection off-path attacks.
from off-path insertion of data[RFC8085].
+---------+--------+-----------------+ The sender needs to then check the value returned in the UDP Probe
| Kind=9 | Len=6 | Token | Response Option. The value of the Token field, uniquely identifies a
+---------+--------+-----------------+ probe within the maximum segment lifetime.
+----------+--------+-----------------+
| Kind=9* | Len=6 | Token |
+----------+--------+-----------------+
1 byte 1 byte 4 bytes 1 byte 1 byte 4 bytes
* To be confirmed by IANA.
Figure 5: UDP Probe REQ Option Format Figure 5: UDP Probe REQ Option Format
6.2.2. UDP Probe Response Option 6.2.2. UDP Probe Response Option
The Probe Response Option is generated in response to reception of a The Probe Response Option is generated in response to reception of a
previously received Probe Request Option. previously received Probe Request Option. This response is generated
by the UDP Option processing.
The Probe Response Option carries a four byte token field. The Token The Probe Response Option carries a four byte token field. The Token
field associates the response with the Token value carried in the field associates the response with the Token value carried in the
most recently-received Echo Request. The rate of generation of UDP most recently-received Echo Request. The rate of generation of UDP
packets carrying a Probe Response Option MAY be rate-limited. packets carrying a Probe Response Option is expected to be less than
once per RTT and SHOULD be rate-limited (see Section 9).
+---------+--------+-----------------+ +----------+--------+-----------------+
| Kind=10 | Len=6 | Token | | Kind=10* | Len=6 | Token |
+---------+--------+-----------------+ +----------+--------+-----------------+
1 byte 1 byte 4 bytes 1 byte 1 byte 4 bytes
* To be confirmed by IANA.
Figure 6: UDP Probe RES Option Format Figure 6: UDP Probe RES Option Format
6.3. DPLPMTUD for SCTP 6.3. DPLPMTUD for SCTP
Section 10.2 of [RFC4821] specifies a recommended PLPMTUD probing Section 10.2 of [RFC4821] specifies a recommended PLPMTUD probing
method for SCTP. It recommends the use of the PAD chunk, defined in method for SCTP. It recommends the use of the PAD chunk, defined in
[RFC4820] to be attached to a minimum length HEARTBEAT chunk to build [RFC4820] to be attached to a minimum length HEARTBEAT chunk to build
a probe packet. This enables probing without affecting the transfer a probe packet. This enables probing without affecting the transfer
of user messages and without interfering with congestion control. of user messages and without interfering with congestion control.
This is preferred to using DATA chunks (with padding as required) as This is preferred to using DATA chunks (with padding as required) as
skipping to change at page 36, line 9 skipping to change at page 36, line 28
XXX If new UDP Options are specified in this document, a request to XXX If new UDP Options are specified in this document, a request to
IANA will be included here. XXX IANA will be included here. XXX
If there are no requirements for IANA, the section will be removed If there are no requirements for IANA, the section will be removed
during conversion into an RFC by the RFC Editor. during conversion into an RFC by the RFC Editor.
9. Security Considerations 9. Security Considerations
The security considerations for the use of UDP and SCTP are provided The security considerations for the use of UDP and SCTP are provided
in the references RFCs. Security guidance for applications using UDP in the references RFCs. Security guidance for applications using UDP
is provided in the UDP Usage Guidelines [RFC8085]. is provided in the UDP Usage Guidelines [RFC8085], specifically the
generation of probe packets is regarded as a "Low Data-Volume
Application", described in section 3.1.3 of this document. This
recommends that sender limits generation of probe packets to an
average rate lower than one probe per 3 seconds.
A PL sender needs to ensure that the method used to confirm reception
of probe packets offers protection from off-path attackers injecting
packets into the path. This protection if provided in IETF-defined
protocols (e.g., TCP, SCTP) using a randomly-initialised sequence
number. A description of one way to do this when using UDP is
provided in section 5.1 of [RFC8085]).
There are cases where PTB messages are not delivered due to policy, There are cases where PTB messages are not delivered due to policy,
configuration or equipment design (see Section 1.1), this method configuration or equipment design (see Section 1.1), this method
therefore does not rely upon PTB messages being received, but is able therefore does not rely upon PTB messages being received, but is able
to utilise these when they are received by the sender. PTB messages to utilise these when they are received by the sender. PTB messages
could potentially be used to cause a node to inappropriately reduce could potentially be used to cause a node to inappropriately reduce
the PLPMTU. A node supporting DPLPMTUD MUST therefore appropriately the PLPMTU. A node supporting DPLPMTUD MUST therefore appropriately
validate the payload of PTB messages to ensure these are received in validate the payload of PTB messages to ensure these are received in
response to transmitted traffic (i.e., a reported error condition response to transmitted traffic (i.e., a reported error condition
that corresponds to a datagram actually sent by the path layer). that corresponds to a datagram actually sent by the path layer).
Parallel forwarding paths may need to be considered. Section 5.2.5.1 An on-path attacker, able to create a PTB message could forge PTB
messages that include a valid quoted IP packet. Such an attack could
be used to drive down the PLPMTU. There are two ways this method can
be mitigated against such attacks: First, by ensuring that a PL
sender never reduces the PLPMTU below the base size, solely in
response to receiving a PTB message. This is achieved by first
entering the PROBE_BASE state when such a message is received.
Second, the design does not require processing of PTB messages, a PL
sender could therefore suspend processing of PTB messages (e.g., in a
robustness mode after detecting that subsequent probes actually
confirm that a size larger than the PTB_SIZE is supported by a path).
Parallel forwarding paths SHOULD be considered. Section 5.2.5.1
identifies the need for robustness in the method when the path identifies the need for robustness in the method when the path
information may be inconsistent. information may be inconsistent.
A node performing DPLPMTUD could experience conflicting information A node performing DPLPMTUD could experience conflicting information
about the size of supported probe packets. This could occur when about the size of supported probe packets. This could occur when
there are multiple paths are concurrently in use and these exhibit a there are multiple paths are concurrently in use and these exhibit a
different PMTU. If not considered, this could result in data being different PMTU. If not considered, this could result in data being
black holed when the PLPMTU is larger than the smallest PMTU across black holed when the PLPMTU is larger than the smallest PMTU across
the current paths. the current paths.
An on-path attacker could forge PTB messages to drive down the PLPMTU
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-quic-transport] [I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-14 (work and Secure Transport", draft-ietf-quic-transport-14 (work
in progress), August 2018. in progress), August 2018.
[I-D.ietf-tsvwg-udp-options] [I-D.ietf-tsvwg-udp-options]
skipping to change at page 38, line 5 skipping to change at page 38, line 42
[RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
Control Transmission Protocol (SCTP) Packets for End-Host Control Transmission Protocol (SCTP) Packets for End-Host
to End-Host Communication", RFC 6951, to End-Host Communication", RFC 6951,
DOI 10.17487/RFC6951, May 2013, DOI 10.17487/RFC6951, May 2013,
<https://www.rfc-editor.org/info/rfc6951>. <https://www.rfc-editor.org/info/rfc6951>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201, "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017, DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>. <https://www.rfc-editor.org/info/rfc8201>.
[RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, [RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto,
"Datagram Transport Layer Security (DTLS) Encapsulation of "Datagram Transport Layer Security (DTLS) Encapsulation of
SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November
2017, <https://www.rfc-editor.org/info/rfc8261>. 2017, <https://www.rfc-editor.org/info/rfc8261>.
skipping to change at page 43, line 19 skipping to change at page 44, line 19
o Clarified supsending DPLPMTUD. o Clarified supsending DPLPMTUD.
o Verified normative text in requirements section. o Verified normative text in requirements section.
o Removed duplicate text. o Removed duplicate text.
o Changed all text to refer to /packet probe/probe packet/ o Changed all text to refer to /packet probe/probe packet/
/validation/verification/ added term /Probe Confirmation/ and /validation/verification/ added term /Probe Confirmation/ and
clarified BlackHole detection. clarified BlackHole detection.
Working Group draft -05:
o Updated security considerations.
o Feedback after speaking with Joe Touch helped improve UDP-Options
description.
Authors' Addresses Authors' Addresses
Godred Fairhurst Godred Fairhurst
University of Aberdeen University of Aberdeen
School of Engineering School of Engineering
Fraser Noble Building Fraser Noble Building
Aberdeen AB24 3U Aberdeen AB24 3UE
UK UK
Email: gorry@erg.abdn.ac.uk Email: gorry@erg.abdn.ac.uk
Tom Jones Tom Jones
University of Aberdeen University of Aberdeen
School of Engineering School of Engineering
Fraser Noble Building Fraser Noble Building
Aberdeen AB24 3U Aberdeen AB24 3UE
UK UK
Email: tom@erg.abdn.ac.uk Email: tom@erg.abdn.ac.uk
Michael Tuexen Michael Tuexen
Muenster University of Applied Sciences Muenster University of Applied Sciences
Stegerwaldstrasse 39 Stegerwaldstrasse 39
Stein fart 48565 Stein fart 48565
DE DE
Email: tuexen@fh-muenster.de Email: tuexen@fh-muenster.de
Irene Ruengeler Irene Ruengeler
Muenster University of Applied Sciences Muenster University of Applied Sciences
Stegerwaldstrasse 39 Stegerwaldstrasse 39
Stein fart 48565 Stein fart 48565
DE DE
Email: i.ruengeler@fh-muenster.de Email: i.ruengeler@fh-muenster.de
 End of changes. 34 change blocks. 
73 lines changed or deleted 117 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/