--- 1/draft-ietf-tsvwg-datagram-plpmtud-04.txt 2018-10-02 01:13:18.924688476 -0700 +++ 2/draft-ietf-tsvwg-datagram-plpmtud-05.txt 2018-10-02 01:13:19.020690792 -0700 @@ -1,21 +1,21 @@ Internet Engineering Task Force G. Fairhurst Internet-Draft T. Jones Updates: 4821 (if approved) University of Aberdeen Intended status: Standards Track M. Tuexen -Expires: March 9, 2019 I. Ruengeler +Expires: April 5, 2019 I. Ruengeler Muenster University of Applied Sciences - September 5, 2018 + October 02, 2018 Packetization Layer Path MTU Discovery for Datagram Transports - draft-ietf-tsvwg-datagram-plpmtud-04 + draft-ietf-tsvwg-datagram-plpmtud-05 Abstract This document describes a robust method for Path MTU Discovery (PMTUD) for datagram Packetization Layers (PLs). The document describes an extension to RFC 1191 and RFC 8201, which specifies 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 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 @@ -24,39 +24,38 @@ progressively larger packets to find whether the maximum packet size can be increased. This allows a sender to determine an appropriate packet size, providing functionally for datagram transports that is equivalent to the Packetization layer PMTUD specification for TCP, specified in RFC 4821. The document also provides implementation notes for incorporating Datagram PMTUD into IETF datagram transports or applications that use datagram transports. - When published, this specification updates RFC 4821 when used with - datagram transports. + When published, this specification updates RFC 4821. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -103,62 +102,58 @@ 5.4.3. Resilience to inconsistent Path information . . . . . 28 6. Specification of Protocol-Specific Methods . . . . . . . . . 28 6.1. Application support for DPLPMTUD with UDP or UDP-Lite . . 28 6.1.1. Application Request . . . . . . . . . . . . . . . . . 29 6.1.2. Application Response . . . . . . . . . . . . . . . . 29 6.1.3. Sending Application Probe Packets . . . . . . . . . . 29 6.1.4. Validating the Path . . . . . . . . . . . . . . . . . 29 6.1.5. Handling of PTB Messages . . . . . . . . . . . . . . 29 6.2. DPLPMTUD with UDP Options . . . . . . . . . . . . . . . . 30 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.1. SCTP/IPv4 and SCTP/IPv6 . . . . . . . . . . . . . . . 32 6.3.1.1. Sending SCTP Probe Packets . . . . . . . . . . . 32 6.3.1.2. Validating the Path with SCTP . . . . . . . . . . 33 6.3.1.3. PTB Message Handling by SCTP . . . . . . . . . . 33 6.3.2. DPLPMTUD for SCTP/UDP . . . . . . . . . . . . . . . . 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.3. Handling of PTB Messages by SCTP/UDP . . . . . . 33 - 6.3.3. DPLPMTUD for SCTP/DTLS . . . . . . . . . . . . . . . 33 + 6.3.2.2. Validating the Path with SCTP/UDP . . . . . . . . 34 + 6.3.2.3. Handling of PTB Messages by SCTP/UDP . . . . . . 34 + 6.3.3. DPLPMTUD for SCTP/DTLS . . . . . . . . . . . . . . . 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.3. Handling of PTB Messages by SCTP/DTLS . . . . . . 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.3. Handling of PTB Messages by QUIC . . . . . . . . . . 35 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 36 - 10.2. Informative References . . . . . . . . . . . . . . . . . 38 - Appendix A. Event-driven state changes . . . . . . . . . . . . . 38 - Appendix B. Revision Notes . . . . . . . . . . . . . . . . . . . 41 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 37 + 10.2. Informative References . . . . . . . . . . . . . . . . . 39 + Appendix A. Event-driven state changes . . . . . . . . . . . . . 39 + Appendix B. Revision Notes . . . . . . . . . . . . . . . . . . . 42 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 1. Introduction The IETF has specified datagram transport using UDP, SCTP, and DCCP, 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 network layer. This document describes a robust method for Path MTU Discovery (PMTUD) that may be used with these transport protocols (or the applications that use their transport service) to discover an 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 Classical Path Maximum Transmission Unit Discovery (PMTUD) can be used with any transport that is able to process ICMP Packet Too Big (PTB) messages (e.g., [RFC1191] and [RFC8201]). The term PTB message is applied to both IPv4 ICMP Unreachable messages (Type 3) that carry the error Fragmentation Needed (Type 3, Code 4) and ICMPv6 packet too big messages (Type 2). When a sender receives a PTB message, it 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 @@ -294,22 +288,24 @@ not risk application data loss. The method defined in this specification could be used with DCCP. Section 6 specifies the method for a set of transports, and provides information to enable the implementation of PLPMTUD with other datagram transports and applications that use datagram transports. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "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 definitions in [RFC1122]. 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 to determine. Black Holed: Packets are Black holed when the sender is unaware that packets are not delivered to the destination endpoint (e.g., when @@ -1079,37 +1075,37 @@ (PROBE_COUNT = MAX_PROBES) +-------------------+ +--------------+ | PROBE_START +------>|PROBE_DISABLED| +-------------------+ +--------------+ | ^ | Path confirmed | v | MAX_PMTU acked or +--------------+-+ (PROBE_COUNT | PTB (BASE_PMTU <= +---------| PROBE_SEARCH | | < MAX_PROBES) | PTB_SIZE | +--> +--------------+<+ or Probe acked | - | PROBE_BASE |<-------| PROBE_ERROR | +------+--------+ +--------------+ +-------------+ /\ | Black hole detected ^ | | BASE_PMTU Probe acked: ^ | | or | | | | | | (PTB_SIZE < PLPMTU) | | | Probe BASE_PMTU: | | | | | | (PROBE_COUNT = MAX_PROBES)| | | | | +---------------------------+ +----+ +--+ Confirmation: PROBE_TIMER expiry: @@ -1359,23 +1355,24 @@ 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. 6.2. DPLPMTUD with UDP Options UDP Options[I-D.ietf-tsvwg-udp-options] can supply the additional functionality required to implement DPLPMTUD within the UDP transport service. Implementing DPLPMTU using UDP Options avoids the need for each application to implement the DPLPMTUD method. - Section 5.6 of[I-D.ietf-tsvwg-udp-options] defines the MSS option, - which allows the local sender to indicate the EMTU_R to the peer. - The value received in this option can be used to initialise PMTU_MAX. + Section 5.6 of[I-D.ietf-tsvwg-udp-options] defines the Maximum + Segment Size (MSS) option, which allows the local sender to indicate + 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 used as Probe Packets. Feedback confirming reception of each Probe Packet is provided by two new UDP Options: 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 identifies each request. o The Probe Response Option (Section 6.2.2 is generated by the UDP @@ -1386,82 +1383,96 @@ The token value allows implementations to be distinguish between acknowledgements for initial probe packets and acknowledgements confirming receipt of subsequent probe packets (e.g., travelling along alternate paths with a larger RTT). Each probe packet needs to be uniquely identifiable by the UDP Options sender within the Maximum Segment Lifetime (MSL). The UDP Options sender therefore needs to not recycle token values until they have expired or have been acknowledged. A 4 byte value for the token field provides sufficient space for multiple unique probes to be made within the MSL. - Implementations ought to only send a probe packet with a Probe - Request Option when required by their local state machine, i.e., when + The initial value of the four byte token field SHOULD be assigned to + 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 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 datagram that the application is currently sending in the DPLPMTUD 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 higher-layer method that provides explicit feedback indicating any packet loss. Another possibility is to utilise data packets that carry a Timestamp Option. Reception of a valid timestamp that was echoed by the remote endpoint can be used to infer connectivity. - This can provide useful feedback even over paths with asymmetric capacity and/or that carry UDP Option flows that have very asymmetric datagram rates, because an echo of the most recent timestamp still indicates reception of at least one packet of the transmitted size. This is sufficient to confirm there is no black hole. In contrast, when sending a probe to increase the PLPMTU, a timestamp - may be unable to unambiguously identify that a specific probe packet - has been received. Timestamp mechanisms cannot be used to confirm - the reception of individual probe messages and cannot be used to - stimulate a response from the remote peer. + might be unable to unambiguously identify that a specific probe + packet has been received. Timestamp mechanisms cannot be used to + confirm the reception of individual probe messages and cannot be used + to stimulate a response from the remote peer. 6.2.1. UDP Probe Request Option The Probe Request Option allows a sending endpoint to solicit a response from a destination endpoint. 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 - the sender (and is sent along the end-to-end path). The sender can - then check the value returned in the UDP Probe Response Option. The - value of the Token field, uniquely identifies a probe within the - maximum segment lifetime and can also provide additional protection - from off-path insertion of data[RFC8085]. + the sender (and is sent along the end-to-end path). The initial + value of the token SHOULD be assigned to a randomised value, as + described in section 5.1 of [RFC8085]) to enhance protection from + off-path attacks. - +---------+--------+-----------------+ - | Kind=9 | Len=6 | Token | - +---------+--------+-----------------+ + The sender needs to then check the value returned in the UDP Probe + 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 + * To be confirmed by IANA. + Figure 5: UDP Probe REQ Option Format 6.2.2. UDP Probe Response Option 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 field associates the response with the Token value carried in the 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 + * To be confirmed by IANA. + Figure 6: UDP Probe RES Option Format 6.3. DPLPMTUD for SCTP Section 10.2 of [RFC4821] specifies a recommended PLPMTUD probing 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 a probe packet. This enables probing without affecting the transfer of user messages and without interfering with congestion control. This is preferred to using DATA chunks (with padding as required) as @@ -1639,45 +1650,66 @@ XXX If new UDP Options are specified in this document, a request to IANA will be included here. XXX If there are no requirements for IANA, the section will be removed during conversion into an RFC by the RFC Editor. 9. Security Considerations The security considerations for the use of UDP and SCTP are provided 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, configuration or equipment design (see Section 1.1), this method therefore does not rely upon PTB messages being received, but is able to utilise these when they are received by the sender. PTB messages could potentially be used to cause a node to inappropriately reduce the PLPMTU. A node supporting DPLPMTUD MUST therefore appropriately validate the payload of PTB messages to ensure these are received in response to transmitted traffic (i.e., a reported error condition 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 information may be inconsistent. A node performing DPLPMTUD could experience conflicting information about the size of supported probe packets. This could occur when there are multiple paths are concurrently in use and these exhibit a different PMTU. If not considered, this could result in data being black holed when the PLPMTU is larger than the smallest PMTU across the current paths. - An on-path attacker could forge PTB messages to drive down the PLPMTU - 10. References 10.1. Normative References [I-D.ietf-quic-transport] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", draft-ietf-quic-transport-14 (work in progress), August 2018. [I-D.ietf-tsvwg-udp-options] @@ -1727,20 +1759,24 @@ [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication", RFC 6951, DOI 10.17487/RFC6951, May 2013, . [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, . [RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November 2017, . @@ -1973,44 +2009,51 @@ o Clarified supsending DPLPMTUD. o Verified normative text in requirements section. o Removed duplicate text. o Changed all text to refer to /packet probe/probe packet/ /validation/verification/ added term /Probe Confirmation/ and 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 Godred Fairhurst University of Aberdeen School of Engineering Fraser Noble Building - Aberdeen AB24 3U + Aberdeen AB24 3UE UK Email: gorry@erg.abdn.ac.uk Tom Jones University of Aberdeen School of Engineering Fraser Noble Building - Aberdeen AB24 3U + Aberdeen AB24 3UE UK Email: tom@erg.abdn.ac.uk - Michael Tuexen Muenster University of Applied Sciences Stegerwaldstrasse 39 Stein fart 48565 DE Email: tuexen@fh-muenster.de + Irene Ruengeler Muenster University of Applied Sciences Stegerwaldstrasse 39 Stein fart 48565 DE Email: i.ruengeler@fh-muenster.de