draft-ietf-tsvwg-datagram-plpmtud-05.txt   draft-ietf-tsvwg-datagram-plpmtud-06.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: April 5, 2019 I. Ruengeler Expires: May 24, 2019 I. Ruengeler
Muenster University of Applied Sciences Muenster University of Applied Sciences
October 02, 2018 November 20, 2018
Packetization Layer Path MTU Discovery for Datagram Transports Packetization Layer Path MTU Discovery for Datagram Transports
draft-ietf-tsvwg-datagram-plpmtud-05 draft-ietf-tsvwg-datagram-plpmtud-06
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 2, line 7 skipping to change at page 2, line 7
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 April 5, 2019. This Internet-Draft will expire on May 24, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Classical Path MTU Discovery . . . . . . . . . . . . . . 4 1.1. Classical Path MTU Discovery . . . . . . . . . . . . . . 4
1.2. Packetization Layer Path MTU Discovery . . . . . . . . . 5 1.2. Packetization Layer Path MTU Discovery . . . . . . . . . 6
1.3. Path MTU Discovery for Datagram Services . . . . . . . . 6 1.3. Path MTU Discovery for Datagram Services . . . . . . . . 7
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Features Required to Provide Datagram PLPMTUD . . . . . . . . 9 3. Features Required to Provide Datagram PLPMTUD . . . . . . . . 9
4. DPLPMTUD Mechanisms . . . . . . . . . . . . . . . . . . . . . 11 4. DPLPMTUD Mechanisms . . . . . . . . . . . . . . . . . . . . . 12
4.1. PLPMTU Probe Packets . . . . . . . . . . . . . . . . . . 11 4.1. PLPMTU Probe Packets . . . . . . . . . . . . . . . . . . 12
4.2. Confirmation of Probed Packet Size . . . . . . . . . . . 13 4.2. Confirmation of Probed Packet Size . . . . . . . . . . . 13
4.3. Detection of Black Holes . . . . . . . . . . . . . . . . 13 4.3. Detection of Black Holes . . . . . . . . . . . . . . . . 14
4.4. Response to PTB Messages . . . . . . . . . . . . . . . . 14 4.4. Response to PTB Messages . . . . . . . . . . . . . . . . 14
4.4.1. Validation of PTB Messages . . . . . . . . . . . . . 14 4.4.1. Validation of PTB Messages . . . . . . . . . . . . . 15
4.4.2. Use of PTB Messages . . . . . . . . . . . . . . . . . 15 4.4.2. Use of PTB Messages . . . . . . . . . . . . . . . . . 15
5. Datagram Packetization Layer PMTUD . . . . . . . . . . . . . 16 5. Datagram Packetization Layer PMTUD . . . . . . . . . . . . . 16
5.1. DPLPMTUD Components . . . . . . . . . . . . . . . . . . . 17 5.1. DPLPMTUD Components . . . . . . . . . . . . . . . . . . . 17
5.1.1. Timers . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.1. Timers . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.2. Constants . . . . . . . . . . . . . . . . . . . . . . 17 5.1.2. Constants . . . . . . . . . . . . . . . . . . . . . . 18
5.1.3. Variables . . . . . . . . . . . . . . . . . . . . . . 18 5.1.3. Variables . . . . . . . . . . . . . . . . . . . . . . 19
5.2. DPLPMTUD Phases . . . . . . . . . . . . . . . . . . . . . 19 5.2. DPLPMTUD Phases . . . . . . . . . . . . . . . . . . . . . 19
5.2.1. Path Confirmation Phase . . . . . . . . . . . . . . . 20 5.2.1. Path Confirmation Phase . . . . . . . . . . . . . . . 21
5.2.2. Search Phase . . . . . . . . . . . . . . . . . . . . 21 5.2.2. Search Phase . . . . . . . . . . . . . . . . . . . . 21
5.2.2.1. Resilience to inconsistent path information . . . 21 5.2.2.1. Resilience to inconsistent path information . . . 22
5.2.3. Search Complete Phase . . . . . . . . . . . . . . . . 21 5.2.3. Search Complete Phase . . . . . . . . . . . . . . . . 22
5.2.4. PROBE_BASE Phase . . . . . . . . . . . . . . . . . . 22 5.2.4. PROBE_BASE Phase . . . . . . . . . . . . . . . . . . 23
5.2.5. ERROR Phase . . . . . . . . . . . . . . . . . . . . . 22 5.2.5. ERROR Phase . . . . . . . . . . . . . . . . . . . . . 23
5.2.5.1. Robustness to inconsistent path . . . . . . . . . 23 5.2.5.1. Robustness to inconsistent path . . . . . . . . . 23
5.2.6. DISABLED Phase . . . . . . . . . . . . . . . . . . . 23 5.2.6. DISABLED Phase . . . . . . . . . . . . . . . . . . . 24
5.3. State Machine . . . . . . . . . . . . . . . . . . . . . . 23 5.3. State Machine . . . . . . . . . . . . . . . . . . . . . . 24
5.4. Search to Increase the PLPMTU . . . . . . . . . . . . . . 26 5.4. Search to Increase the PLPMTU . . . . . . . . . . . . . . 27
5.4.1. Probing for a larger PLPMTU . . . . . . . . . . . . . 26 5.4.1. Probing for a larger PLPMTU . . . . . . . . . . . . . 27
5.4.2. Selection of Probe Sizes . . . . . . . . . . . . . . 27 5.4.2. Selection of Probe Sizes . . . . . . . . . . . . . . 28
5.4.3. Resilience to inconsistent Path information . . . . . 28 5.4.3. Resilience to inconsistent Path information . . . . . 29
6. Specification of Protocol-Specific Methods . . . . . . . . . 28 6. Specification of Protocol-Specific Methods . . . . . . . . . 29
6.1. Application support for DPLPMTUD with UDP or UDP-Lite . . 28 6.1. Application support for DPLPMTUD with UDP or UDP-Lite . . 29
6.1.1. Application Request . . . . . . . . . . . . . . . . . 29 6.1.1. Application Request . . . . . . . . . . . . . . . . . 30
6.1.2. Application Response . . . . . . . . . . . . . . . . 29 6.1.2. Application Response . . . . . . . . . . . . . . . . 30
6.1.3. Sending Application Probe Packets . . . . . . . . . . 29 6.1.3. Sending Application Probe Packets . . . . . . . . . . 30
6.1.4. Validating the Path . . . . . . . . . . . . . . . . . 29 6.1.4. Validating the Path . . . . . . . . . . . . . . . . . 30
6.1.5. Handling of PTB Messages . . . . . . . . . . . . . . 29 6.1.5. Handling of PTB Messages . . . . . . . . . . . . . . 30
6.2. DPLPMTUD with UDP Options . . . . . . . . . . . . . . . . 30 6.2. DPLPMTUD with UDP Options . . . . . . . . . . . . . . . . 31
6.2.1. UDP Probe Request Option . . . . . . . . . . . . . . 31 6.2.1. UDP Probe Request Option . . . . . . . . . . . . . . 32
6.2.2. UDP Probe Response Option . . . . . . . . . . . . . . 32 6.2.2. UDP Probe Response Option . . . . . . . . . . . . . . 33
6.3. DPLPMTUD for SCTP . . . . . . . . . . . . . . . . . . . . 32 6.3. DPLPMTUD for SCTP . . . . . . . . . . . . . . . . . . . . 33
6.3.1. SCTP/IPv4 and SCTP/IPv6 . . . . . . . . . . . . . . . 32 6.3.1. SCTP/IPv4 and SCTP/IPv6 . . . . . . . . . . . . . . . 33
6.3.1.1. Sending SCTP Probe Packets . . . . . . . . . . . 32 6.3.1.1. Sending SCTP Probe Packets . . . . . . . . . . . 33
6.3.1.2. Validating the Path with SCTP . . . . . . . . . . 33 6.3.1.2. Validating the Path with SCTP . . . . . . . . . . 34
6.3.1.3. PTB Message Handling by SCTP . . . . . . . . . . 33 6.3.1.3. PTB Message Handling by SCTP . . . . . . . . . . 34
6.3.2. DPLPMTUD for SCTP/UDP . . . . . . . . . . . . . . . . 33 6.3.2. DPLPMTUD for SCTP/UDP . . . . . . . . . . . . . . . . 34
6.3.2.1. Sending SCTP/UDP Probe Packets . . . . . . . . . 33 6.3.2.1. Sending SCTP/UDP Probe Packets . . . . . . . . . 34
6.3.2.2. Validating the Path with SCTP/UDP . . . . . . . . 34 6.3.2.2. Validating the Path with SCTP/UDP . . . . . . . . 35
6.3.2.3. Handling of PTB Messages by SCTP/UDP . . . . . . 34 6.3.2.3. Handling of PTB Messages by SCTP/UDP . . . . . . 35
6.3.3. DPLPMTUD for SCTP/DTLS . . . . . . . . . . . . . . . 34 6.3.3. DPLPMTUD for SCTP/DTLS . . . . . . . . . . . . . . . 35
6.3.3.1. Sending SCTP/DTLS Probe Packets . . . . . . . . . 34 6.3.3.1. Sending SCTP/DTLS Probe Packets . . . . . . . . . 35
6.3.3.2. Validating the Path with SCTP/DTLS . . . . . . . 34 6.3.3.2. Validating the Path with SCTP/DTLS . . . . . . . 35
6.3.3.3. Handling of PTB Messages by SCTP/DTLS . . . . . . 34 6.3.3.3. Handling of PTB Messages by SCTP/DTLS . . . . . . 35
6.4. DPLPMTUD for QUIC . . . . . . . . . . . . . . . . . . . . 34 6.4. DPLPMTUD for QUIC . . . . . . . . . . . . . . . . . . . . 35
6.4.1. Sending QUIC Probe Packets . . . . . . . . . . . . . 35 6.4.1. Sending QUIC Probe Packets . . . . . . . . . . . . . 36
6.4.2. Validating the Path with QUIC . . . . . . . . . . . . 35 6.4.2. Validating the Path with QUIC . . . . . . . . . . . . 36
6.4.3. Handling of PTB Messages by QUIC . . . . . . . . . . 35 6.4.3. Handling of PTB Messages by QUIC . . . . . . . . . . 36
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1. Normative References . . . . . . . . . . . . . . . . . . 37 10.1. Normative References . . . . . . . . . . . . . . . . . . 38
10.2. Informative References . . . . . . . . . . . . . . . . . 39 10.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix A. Event-driven state changes . . . . . . . . . . . . . 39 Appendix A. Event-driven state changes . . . . . . . . . . . . . 40
Appendix B. Revision Notes . . . . . . . . . . . . . . . . . . . 42 Appendix B. Revision Notes . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
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.
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) [RFC0792] and ICMPv6
big messages (Type 2). When a sender receives a PTB message, it packet too big messages (Type 2) [RFC4443]. When a sender receives a
reduces the effective MTU to the value reported in the PTB message PTB message, it reduces the effective MTU to the value reported as
(in this document called the PTB_SIZE). A method from time-to-time the Link MTU in the PTB message, and a method that from time-to-time
increases the packet size in attempt to discover an increase in the increases the packet size in attempt to discover an increase in the
supported PMTU. The packets sent with a size larger than the current supported PMTU. The packets sent with a size larger than the current
effective PMTU are known as probe packets. effective PMTU are known as probe packets.
Packets not intended as probe packets are either fragmented to the Packets not intended as probe packets are either fragmented to the
current effective PMTU, or an attempt to send a packet larger than current effective PMTU, or the attempt to send fails with an error
current effective PMTU fails with an error code. Applications are code. Applications are sometimes provided with a primitive to let
sometimes provided with a primitive to let them read the maximum them read the Maximum Packet Size (MPS), derived from the current
packet size, derived from the current effective PMTU. effective PMTU.
Classical PMTUD is subject to protocol failures. One failure arises Classical PMTUD is subject to protocol failures. One failure arises
when traffic using a packet size larger than the actual PMTU is black when traffic using a packet size larger than the actual PMTU is
holed (all datagrams sent with this size, or larger, are silently black-holed (all datagrams sent with this size, or larger, are
discarded without the sender receiving ICMP PTB messages). This silently discarded without the sender receiving ICMP PTB messages).
could arise when the PTB messages are not delivered back to the This could arise when the PTB messages are not delivered back to the
sender for some reason [RFC2923]). For example, ICMP messages are sender for some reason [RFC2923]).
increasingly filtered by middleboxes (including firewalls) [RFC4890].
A stateful firewall could be configured with a policy to block Examples where PTB messages are not delivered include:
incoming ICMP messages, which would prevent reception of PTB messages
to endpoints behind this firewall. Other examples include cases o The generation of ICMP messages is usually rate limited. This may
where PTB messages are not correctly processed/generated by tunnel result in no PTB messages being sent to the sender (see section
endpoints. 2.4 of [RFC4443]
o ICMP messages are increasingly filtered by middleboxes (including
firewalls) [RFC4890]. A stateful firewall could be configured
with a policy to block incoming ICMP messages, which would prevent
reception of PTB messages to endpoints behind this firewall.
o When the router issuing the ICMP message drops a tunneled packet,
the resulting ICMP message will be directed to the tunnel ingress.
This tunnel endpoint is responsible for forwarding the ICMP
message and also processing the quoted packet within the payload
field to remove the effect of the tunnel, and return a correctly
formatted ICMP message to the sender [I-D.ietf-intarea-tunnels].
Failure to do this results in black-holing.
o Asymmetry in forwarding can result in there being no route back to
the original sender, which would prevent an ICMP message being
delivered to the sender. This can be also be an issue when
policy-based routing is used, Equal Cost Multipath (ECMP) routing
is used, or a middlebox acts as an application load balancer. An
example is where the path towards the server is chosen by ECMP
routing depending on bytes in the IP payload. In this case, when
a packet sent by the server encounters a problem after the ECMP
router, then any resulting ICMP message needs to also be directed
by the ECMP router towards the same server (i.e., ICMP messages
need to follow the same path as the flows to which they
correspond). Failure to do this results in black-holing.
o There are cases where the next hop destination fails to receive a
packet because of its size. This could be due to misconfiguration
of the layer 2 path between nodes, for instance the MTU configured
in a layer 2 switch, or misconfiguration of the Maximum Receive
Unit (MRU). If the packet is dropped by the link, this will not
cause in a PTB to be sent, and result in consequent black-holing.
Another failure could result if a node that is not on the network Another failure could result if a node that is not on the network
path sends a PTB message that attempts to force the sender to change path sends a PTB message that attempts to force the sender to change
the effective PMTU [RFC8201]. A sender can protect itself from the effective PMTU [RFC8201]. A sender can protect itself from
reacting to such messages by utilising the quoted packet within a PTB reacting to such messages by utilising the quoted packet within a PTB
message payload to validate that the received PTB message was message payload to validate that the received PTB message was
generated in response to a packet that had actually originated from generated in response to a packet that had actually originated from
the sender. However, there are situations where a sender would be the sender. However, there are situations where a sender would be
unable to provide this validation. unable to provide this validation.
Examples where validation of the PTB message is not possible include: Examples where validation of the PTB message is not possible include:
o When the router issuing the ICMP message is acting on a tunneled o When a router issuing the ICMP message implements RFC792
packet, the ICMP message will be directed to the tunnel endpoint. [RFC0792], it is only required to include the first 64 bits of the
This tunnel endpoint is responsible for forwarding the ICMP IP payload of the packet within the quoted payload. This may be
message and also processing the quoted packet within the payload insufficient to perform the tunnel processing described in the
field to remove the effect of the tunnel, and return a correctly previous bullet. There could be insufficient bytes remaining for
formatted ICMP message to the sender. Failure to do appropriate the sender to interpret the quoted transport information. The
processing therefore results in black-holing. recommendation in RFC1812 [RFC1812] is that IPv4 routers return a
quoted packet with as much of the original datagram as possible
o When a router issuing the ICMP message implements RFC 792 without the length of the ICMP datagram exceeding 576 bytes.
[RFC0792], it is only required to include (quote) the first 64 (IPv6 routers include as much of invoking packet as possible
bits of the IP payload of the packet within the ICMP payload. without the ICMPv6 packet exceeding 1280 bytes [RFC4443].)
This could be insufficient to perform the tunnel processing
described in the previous bullet. Even if the decapsulated
message is processed by the tunnel endpoint, there could be
insufficient bytes remaining for the sender to interpret the
quoted transport information. RFC 1812 [RFC1812] requires routers
to return the full packet if possible. This can result in black-
holing when used the path includes tunnels.
o When a router issuing the ICMP message quotes a packet with an o The use of tunnels/encryption can reduce the size of the quoted
encrypted transport, it may lack sufficient context to determine packet returned to the original source address, increasing the
the original transport header. risk that there could be insufficient bytes remaining for the
sender to interpret the quoted transport information.
o Even when the PTB message includes sufficient bytes of the quoted o Even when the PTB message includes sufficient bytes of the quoted
packet, the network layer could lack sufficient context to packet, the network layer could lack sufficient context to
validate the ICMP message, because this depends on information validate the message, because validation depends on information
about the active transport flows at an endpoint node (e.g., the about the active transport flows at an endpoint node (e.g., the
socket/address pairs being used, and other protocol header socket/address pairs being used, and other protocol header
information). information).
o When a packet is encapsulated/tunneled over an encrypted
transport, the tunnel/encapsulation ingress might have
insufficient context, or computational power, to reconstruct the
transport header that would be needed to perform validation.
1.2. Packetization Layer Path MTU Discovery 1.2. Packetization Layer Path MTU Discovery
The term Packetization Layer (PL) has been introduced to describe the The term Packetization Layer (PL) has been introduced to describe the
layer that is responsible for placing data blocks into the payload of layer that is responsible for placing data blocks into the payload of
IP packets and selecting an appropriate Maximum Packet Size (MPS). IP packets and selecting an appropriate MPS. This function is often
This function is often performed by a transport protocol, but can performed by a transport protocol, but can also be performed by other
also be performed by other encapsulation methods working above the encapsulation methods working above the transport layer.
transport layer.
In contrast to PMTUD, Packetization Layer Path MTU Discovery In contrast to PMTUD, Packetization Layer Path MTU Discovery
(PLPMTUD) [RFC4821] does not rely upon reception and validation of (PLPMTUD) [RFC4821] does not rely upon reception and validation of
PTB messages. It is therefore more robust than Classical PMTUD. PTB messages. It is therefore more robust than Classical PMTUD.
This has become the recommended approach for implementing PMTU This has become the recommended approach for implementing PMTU
discovery with TCP. discovery with TCP.
It uses a general strategy where the PL sends probe packets to search It uses a general strategy where the PL sends probe packets to search
for the largest size of unfragmented datagram that can be sent over a for the largest size of unfragmented datagram that can be sent over a
network path. The probe packets are sent with a progressively larger network path. The probe packets are sent with a progressively larger
skipping to change at page 34, line 46 skipping to change at page 35, line 46
6.3.3.3. Handling of PTB Messages by SCTP/DTLS 6.3.3.3. Handling of PTB Messages by SCTP/DTLS
It is not possible to perform normal ICMP validation as specified in It is not possible to perform normal ICMP validation as specified in
[RFC4960], since even if the ICMP message payload contains sufficient [RFC4960], since even if the ICMP message payload contains sufficient
information, the reflected SCTP common header would be encrypted. information, the reflected SCTP common header would be encrypted.
Therefore it is not possible to process PTB messages at the PL. Therefore it is not possible to process PTB messages at the PL.
6.4. DPLPMTUD for QUIC 6.4. DPLPMTUD for QUIC
Quick UDP Internet Connection (QUIC) [I-D.ietf-quic-transport] is a Quick UDP Internet Connection (QUIC) [I-D.ietf-quic-transport] is a
UDP-based transport that provides reception feedback. UDP-based transport that provides reception feedback. The UDP
payload includes the QUIC packet header, protected payload, and any
authentication fields. QUIC depends on a PMTU of at least 1280
bytes.
Section 9.2 of [I-D.ietf-quic-transport] describes the path Section 9.2 of [I-D.ietf-quic-transport] describes the path
considerations when sending QUIC packets. It recommends the use of considerations when sending QUIC packets. It recommends the use of
PADDING frames to build the probe packet. This enables probing PADDING frames to build the probe packet. Pure probe-only packets
without affecting the transfer of other QUIC frames. are constructed with PADDING frames and PING frames to create a
padding only packet that will illict an acknowledgement. Padding
only frames enable probing the without affecting the transfer of
other QUIC frames.
This provides an acknowledged PL. A sender can therefore enter the The recommendation for QUIC endpoints implementing DPLPMTUD is
PROBE_BASE state as soon as connectivity has been confirmed. therefore that a MPS is maintained for each combination of local and
remote IP addresses [I-D.ietf-quic-transport]. If a QUIC endpoint
determines that the PMTU between any pair of local and remote IP
addresses has fallen below an acceptable MPS, it needs to immediately
cease sending QUIC packets on the affected path. This could result
in termination of the connection if an alternative path cannot be
found [I-D.ietf-quic-transport].
6.4.1. Sending QUIC Probe Packets 6.4.1. Sending QUIC Probe Packets
A probe packet consists of a QUIC Header and a payload containing A probe packet consists of a QUIC Header and a payload containing
only PADDING Frames. PADDING Frames are a single octet (0x00) and PADDING Frames and a PING Frame. PADDING Frames are a single octet
several of these can be used to create a probe packet of size (0x00) and several of these can be used to create a probe packet of
PROBED_SIZE. QUIC provides an acknowledged PL. A sender can size PROBED_SIZE. QUIC provides an acknowledged PL, A sender can
therefore enter the PROBE_BASE state as soon as connectivity has been therefore enter the PROBE_BASE state as soon as connectivity has been
confirmed. confirmed.
The current specification of QUIC sets the following: The current specification of QUIC sets the following:
o BASE_PMTU: 1200. A QUIC sender needs to pad initial packets to o BASE_PMTU: 1200. A QUIC sender needs to pad initial packets to
1200 bytes to confirm the path can support packets of a useful 1200 bytes to confirm the path can support packets of a useful
size. size.
o MIN_PMTU: 1200 bytes. A QUIC sender that determines the PMTU has o MIN_PMTU: 1200 bytes. A QUIC sender that determines the PMTU has
skipping to change at page 35, line 36 skipping to change at page 36, line 47
6.4.2. Validating the Path with QUIC 6.4.2. Validating the Path with QUIC
QUIC provides an acknowledged PL. A sender therefore MUST NOT QUIC provides an acknowledged PL. A sender therefore MUST NOT
implement the CONFIRMATION_TIMER while in the SEARCH_COMPLETE state. implement the CONFIRMATION_TIMER while in the SEARCH_COMPLETE state.
6.4.3. Handling of PTB Messages by QUIC 6.4.3. Handling of PTB Messages by QUIC
QUIC operates over the UDP transport, and the guidelines on ICMP QUIC operates over the UDP transport, and the guidelines on ICMP
validation as specified in Section 5.2 of [RFC8085] therefore apply. validation as specified in Section 5.2 of [RFC8085] therefore apply.
Although QUIC does not currently specify a method for validating ICMP In addition to UDP Port validation QUIC can validate an ICMP message
responses, it does provide some guidelines to make it harder for an by looking for valid Connection IDs in the quoted packet.
off-path attacker to inject ICMP messages.
o Set the IPv4 Don't Fragment (DF) bit on a small proportion of
packets, so that most invalid ICMP messages arrive when there are
no DF packets outstanding, and can therefore be identified as
spurious.
o Store additional information from the IP or UDP headers from DF
packets (for example, the IP ID or UDP checksum) to further
authenticate incoming Datagram Too Big messages.
o Any reduction in PMTU due to a report contained in an ICMP packet
is provisional until QUIC's loss detection algorithm determines
that the packet is actually lost.
XXX The above list was pulled whole from quic-transport - input is
invited from QUIC contributors. XXX
7. Acknowledgements 7. Acknowledgements
This work was partially funded by the European Union's Horizon 2020 This work was partially funded by the European Union's Horizon 2020
research and innovation programme under grant agreement No. 644334 research and innovation programme under grant agreement No. 644334
(NEAT). The views expressed are solely those of the author(s). (NEAT). The views expressed are solely those of the author(s).
8. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
skipping to change at page 37, line 31 skipping to change at page 38, line 28
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.
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-16 (work
in progress), August 2018. in progress), October 2018.
[I-D.ietf-tsvwg-udp-options] [I-D.ietf-tsvwg-udp-options]
Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- Touch, J., "Transport Options for UDP", draft-ietf-tsvwg-
udp-options-05 (work in progress), July 2018. udp-options-05 (work in progress), July 2018.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
RFC 792, DOI 10.17487/RFC0792, September 1981, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc792>. <https://www.rfc-editor.org/info/rfc1191>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/info/rfc1812>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>. December 1998, <https://www.rfc-editor.org/info/rfc2460>.
skipping to change at page 39, line 12 skipping to change at page 39, line 45
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>.
10.2. Informative References 10.2. Informative References
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [I-D.ietf-intarea-tunnels]
DOI 10.17487/RFC1191, November 1990, Touch, J. and M. Townsley, "IP Tunnels in the Internet
<https://www.rfc-editor.org/info/rfc1191>. Architecture", draft-ietf-intarea-tunnels-09 (work in
progress), July 2018.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/info/rfc1812>.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery",
RFC 2923, DOI 10.17487/RFC2923, September 2000, RFC 2923, DOI 10.17487/RFC2923, September 2000,
<https://www.rfc-editor.org/info/rfc2923>. <https://www.rfc-editor.org/info/rfc2923>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC4340, March 2006, DOI 10.17487/RFC4340, March 2006,
<https://www.rfc-editor.org/info/rfc4340>. <https://www.rfc-editor.org/info/rfc4340>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[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,
<https://www.rfc-editor.org/info/rfc4821>. <https://www.rfc-editor.org/info/rfc4821>.
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering
ICMPv6 Messages in Firewalls", RFC 4890, ICMPv6 Messages in Firewalls", RFC 4890,
DOI 10.17487/RFC4890, May 2007, DOI 10.17487/RFC4890, May 2007,
<https://www.rfc-editor.org/info/rfc4890>. <https://www.rfc-editor.org/info/rfc4890>.
Appendix A. Event-driven state changes Appendix A. Event-driven state changes
skipping to change at page 44, line 26 skipping to change at page 45, line 26
/validation/verification/ added term /Probe Confirmation/ and /validation/verification/ added term /Probe Confirmation/ and
clarified BlackHole detection. clarified BlackHole detection.
Working Group draft -05: Working Group draft -05:
o Updated security considerations. o Updated security considerations.
o Feedback after speaking with Joe Touch helped improve UDP-Options o Feedback after speaking with Joe Touch helped improve UDP-Options
description. description.
Working Group draft -06:
o Updated description of ICMP issues in section 1.1
o Update to description of QUIC.
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 3UE Aberdeen AB24 3UE
UK UK
Email: gorry@erg.abdn.ac.uk Email: gorry@erg.abdn.ac.uk
 End of changes. 31 change blocks. 
148 lines changed or deleted 191 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/