Re: [quicwg/base-drafts] PMTUD (#106)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> -size is 1350 bytes for IPv6 and 1370 bytes for IPv4.  To optimize better,
-endpoints MAY use PLPMTUD {{!RFC4821}} for detecting the path's MTU and setting
-the maximum packet size appropriately.
+The Path Maximum Transmission Unit (PTMU) is the maximum size of the entire IP
+header, UDP header, and UDP payload. The UDP payload includes the QUIC public
+header, encrypted payload, and any authentication fields.
+
+All QUIC packets SHOULD be sized to fit within the estimated PMTU to avoid IP
+fragmentation or packet drops. To optimize bandwidth efficiency, endpoints
+SHOULD use Packetization Layer PMTU Discovery ({{!RFC4821}}) and MAY use PMTU
+Discovery ({{!RFC1191}}, {{!RFC1981}}) for detecting the PMTU, setting the PMTU
+appropriately, and storing the result of previous PMTU determinations.
+
+In the absence of these mechanisms, QUIC endpoints SHOULD use a default PMTU of
+1280 octets. Assuming the minimum IP header size, this results in a UDP payload
+length of 1232 octets for IPv6 and 1252 octets for IPv4.

Given that 1280 is the minimum, this really isn't saying that there is a default PMTU, it's more saying that QUIC implementations can assume that 1280 is OK.

> +Discovery ({{!RFC1191}}, {{!RFC1981}}) for detecting the PMTU, setting the PMTU
+appropriately, and storing the result of previous PMTU determinations.
+
+In the absence of these mechanisms, QUIC endpoints SHOULD use a default PMTU of
+1280 octets. Assuming the minimum IP header size, this results in a UDP payload
+length of 1232 octets for IPv6 and 1252 octets for IPv4.
+
+QUIC endpoints that implement any kind of PMTU discovery SHOULD maintain an
+estimate for each combination of local and remote IP addresses (as each pairing
+could have a different maximum MTU in the path).
+
+QUIC connnections MUST NOT operate over a network path with an estimated PMTU
+below 1280 octets. This is equal to the IPv6 minimum. Most modern IPv4 networks
+support at least this packet size. A large packet size allows the first client
+handshake packet to fit in a single datagram, which in turn enables stateless
+rejects by the server.

Nothing in the protocol will stop a QUIC endpoint from using a path with a smaller MTU, especially if they can't set DF.  So I would frame this differently:

> QUIC depends on the network path supporting a MTU of at least 1280 octets.  This is the IPv6 minimum and therefore also supported by most modern IPv4 networks.  An endpoint MUST NOT reduce their MTU below this number, even if it receives signals that indicate a smaller limit might exist.

Then I would follow with the ClientHello paragraph:

> A client MUST construct an initial packet that is at least 1280 octets in size, including IP and UDP headers.  It is RECOMMENDED that a packet be padded to exactly 1280 octets unless the client has a reasonable assurance that the PMTU is larger.  A server MUST reject initial packets that are less than 1280 octets in size (caveat warning: see below).  Sending a packet of this size ensures that the network path supports an MTU of this size and helps mitigate amplification attacks caused by server responses toward an unverified client address.

Then I would include the text on PMTU changes, which isn't as important.

> +
+If a QUIC endpoint determines that the PMTU between any pair of local and remote
+IP addresses has fallen below 1280 octets, it MUST immediately cease sending
+QUIC packets between those IP addresses. This may result in abrupt termination
+of the connection if all pairs are affected. In this case, an endpoint SHOULD
+send a Public Reset packet to indicate the failure. The application SHOULD
+attempt to use TLS over TCP instead.
+
+Clients MUST ensure that the first packet in a connection, and any
+retransmissions of those octets, has a total size (including IP and UDP headers)
+of at least 1280 bytes. This might require inclusion of a PADDING frame. Clients
+MAY use a larger first packet size if it has reasonable assurance of a higher
+PMTU through out-of-band information.
+
+Servers MUST reject the first plaintext packet received from a client if it its
+total size is less than 1280 octets, to mitigate amplification attacks.

Policing this will be difficult, if not impossible, if there are extension headers.  Userspace implementations might not even learn about them.  From what I can tell, there is no limit to the size of extension headers in IPv6, so we can't really require that this enforcement happen.

> +## Special Considerations for PMTU Discovery 
+
+Traditional ICMP-based path MTU discovery in IPv4 ({{!RFC1191}} is potentially
+vulnerable to off-path attacks that successfully guess the IP/port 4-tuple and
+reduce the MTU to a bandwidth-inefficient value. TCP connections mitigate this
+risk by using the (at minimum) 8 bytes of transport header echoed in the ICMP
+message to validate the TCP sequence number as valid for the current
+connection. However, as QUIC operates over UDP, in IPv4 the echoed information
+could consist only of the IP and UDP headers, which usually has insufficient
+entropy to mitigate off-path attacks.
+
+As a result, endpoints that implement PMTUD in IPv4 SHOULD take steps to mitigate
+this risk. For instance, an application could:
+
+* 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.

This is missing the (obvious) and can therefore be easily identified as spurious.

> +reduce the MTU to a bandwidth-inefficient value. TCP connections mitigate this
+risk by using the (at minimum) 8 bytes of transport header echoed in the ICMP
+message to validate the TCP sequence number as valid for the current
+connection. However, as QUIC operates over UDP, in IPv4 the echoed information
+could consist only of the IP and UDP headers, which usually has insufficient
+entropy to mitigate off-path attacks.
+
+As a result, endpoints that implement PMTUD in IPv4 SHOULD take steps to mitigate
+this risk. For instance, an application could:
+
+* 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.
+
+* Store additional information from the IP or UDP headers from DF packets (for
+example, the IP ID or UDP checksum) to further authenticate incoming Packet Too
+Big messages.

RFC 1191 uses "Datagram Too Big" rather than "Packet Too Big".

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/106#pullrequestreview-19246448