--- 1/draft-ietf-tsvwg-datagram-plpmtud-15.txt 2020-03-09 08:14:11.726863532 -0700 +++ 2/draft-ietf-tsvwg-datagram-plpmtud-16.txt 2020-03-09 08:14:11.822865969 -0700 @@ -1,22 +1,22 @@ Internet Engineering Task Force G. Fairhurst Internet-Draft T. Jones Updates: 4821, 4960, 6951, 8085, 8261 (if University of Aberdeen approved) M. Tuexen Intended status: Standards Track I. Ruengeler -Expires: 27 August 2020 T. Voelker +Expires: 10 September 2020 T. Voelker Muenster University of Applied Sciences - 24 February 2020 + 9 March 2020 Packetization Layer Path MTU Discovery for Datagram Transports - draft-ietf-tsvwg-datagram-plpmtud-15 + draft-ietf-tsvwg-datagram-plpmtud-16 Abstract This document describes a robust method for Path MTU Discovery (PMTUD) for datagram Packetization Layers (PLs). It 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 packet @@ -50,21 +50,21 @@ 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 27 August 2020. + This Internet-Draft will expire on 10 September 2020. Copyright Notice Copyright (c) 2020 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 carefully, as they describe your rights @@ -127,22 +127,22 @@ 6.2.3.3. Validating the Path with SCTP/DTLS . . . . . . . 33 6.2.3.4. Handling of PTB Messages by SCTP/DTLS . . . . . . 34 6.3. DPLPMTUD for QUIC . . . . . . . . . . . . . . . . . . . . 34 6.3.1. Initial Connectivity . . . . . . . . . . . . . . . . 34 6.3.2. Sending QUIC Probe Packets . . . . . . . . . . . . . 34 6.3.3. Validating the Path with QUIC . . . . . . . . . . . . 35 6.3.4. Handling of PTB Messages by QUIC . . . . . . . . . . 35 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 36 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 37 10.2. Informative References . . . . . . . . . . . . . . . . . 38 Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 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 @@ -593,61 +593,58 @@ The DPLPMTUD method relies upon the PL sender being able to generate probe packets with a specific size. TCP is able to generate these probe packets by choosing to appropriately segment data being sent [RFC4821]. In contrast, a datagram PL that constructs a probe packet has to either request an application to send a data block that is larger than that generated by an application, or to utilize padding functions to extend a datagram beyond the size of the application data block. Protocols that permit exchange of control messages (without an application data block) can generate a probe packet by - extending a control message with padding data. + extending a control message with padding data. The total size of a + probe packet includes all headers and padding added to the payload + data being sent (e.g., including protocol option fields, security- + related fields such as an AEAD tag and TLS record layer padding). A receiver is REQUIRED to be able to distinguish an in-band data block from any added padding. This is needed to ensure that any added padding is not passed on to an application at the receiver. This results in three possible ways that a sender can create a probe packet: Probing using padding data: A probe packet that contains only control information together with any padding, which is needed to be inflated to the size of the probe packet. Since these probe packets do not carry an application-supplied data block, they do not typically require retransmission, although they do still consume network capacity and incur endpoint processing. Probing using application data and padding data: A probe packet that contains a data block supplied by an application that is combined with padding to inflate the length of the datagram to the size of - the probe packet. If the application/transport needs protection - from the loss of this probe packet, the application/transport - could perform transport-layer retransmission/repair of the data - block (e.g., by retransmission after loss is detected or by - duplicating the data block in a datagram without the padding - data). + the probe packet. Probing using application data: A probe packet that contains a data block supplied by an application that matches the size of the probe packet. This method requests the application to issue a - data block of the desired probe size. If the application/ - transport needs protection from the loss of an unsuccessful probe - packet, the application/transport needs then to perform transport- - layer retransmission/repair of the data block (e.g., by - retransmission after loss is detected). + data block of the desired probe size. - A PL that uses a probe packet carrying an application data block, - could need to retransmit this application data block if the probe - fails, possibly using a smaller PLPMTU. This could need the PL to to - use a smaller packet size to traverse the end-to-end path (which - could utilize endpoint network-layer or a PL that can re-segment the - data block into multiple datagrams). + A PL that uses a probe packet carrying an application data and needs + protection from the loss of this probe packet, could perform + transport-layer retransmission/repair of the data block (e.g., by + retransmission after loss is detected or by duplicating the data + block in a datagram without the padding data). This retransmited + data block might possibly need to be sent using a smaller PLPMTU, + which could need the PL to to use a smaller packet size to traverse + the end-to-end path. (This could utilize endpoint network-layer or a + PL that can re-segment the data block into multiple datagrams). DPLPMTUD MAY choose to use only one of these methods to simplify the implementation. Probe messages sent by a PL MUST contain enough information to uniquely identify the probe within Maximum Segment Lifetime, while being robust to reordering and replay of probe response and PTB messages. 4.2. Confirmation of Probed Packet Size @@ -705,23 +702,25 @@ When the method detects the current PLPMTU is not supported, DPLPMTUD sets a lower PLPMTU, and sets a lower MPS. The PL then confirms that the new PLPMTU can be successfully used across the path. A probe packet could need to have a size less than the size of the data block generated by the application. 4.4. The Maximum Packet Size (MPS) The result of probing determines a usable PLPMTU, which is used to set the MPS used by the application. The MPS is smaller than the - PLPMTU because of the presence of PL headers and any IP options or - extensions added to the PL packet. The relationship between the MPS - and the PLPMTUD is illustrated in Figure 1. + PLPMTU because it is reduced by the size of PL headers (including the + overhead of security-related fields such as an AEAD tag and TLS + record layer padding) and any IP options or extensions added to the + PL packet. The relationship between the MPS and the PLPMTUD is + illustrated in Figure 1. any additional headers .--- MPS -----. | | | v v v +------------------------------+ | IP | ** | PL | protocol data | +------------------------------+ <---------- PLPMTU ------------> @@ -1682,20 +1681,33 @@ identifies the need for robustness in the method because the path information might 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 packets not being delivered (black holed) when the PLPMTU is larger than the smallest actual PMTU. + DPLPMTUD methods can introduce padding data to inflate the length of + the datagram to the total size required for a probe packet. The + total size of a probe packet includes all headers and padding added + to the payload data being sent (e.g., including security-related + fields such as an AEAD tag and TLS record layer padding). The value + of the padding data does not influence the DPLPMTUD search algorithm, + and therefore needs to be set consistent with the policy of the PL. + + If a PL can make use of cryptographic confidentiality or data- + integrity mechanisms, then adding anything (e.g., padding) for + DPLPMTUD that is not protected by those cryptographic mechanisms is + an anti-pattern to be avoided. + 10. References 10.1. Normative References [I-D.ietf-quic-transport] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", Work in Progress, Internet-Draft, draft-ietf-quic-transport-27, 21 February 2020, .