Re: [quicwg/base-drafts] Updated ICMP PMTU section (#1412)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.

Thanks for doing this Igor.

This is a lot of new words, but generally good.  I think that we probably need to do something to break this up a little.

I also think that implementations will not be able to save anything of the IP ID, and won't be inclined to save anything from the packet.  So we might want to suggest a mode switch when a packet is received.

> @@ -3157,9 +3157,9 @@ header, protected 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 ({{!PLPMTUD=RFC4821}}).  Endpoints
-MAY use PMTU Discovery ({{!PMTUDv4=RFC1191}}, {{!PMTUDv6=RFC8201}}) for
-detecting the PMTU, setting the PMTU appropriately, and storing the result of
-previous PMTU determinations.
+MAY use classical PMTU Discovery ({{!PMTUDv4=RFC1191}}, {{!PMTUDv6=RFC8201}})

"classical" isn't a useful description of the mechanism.  If you need to distinguish this between PLPMTUD, talk about using ICMP feedback.

> -Traditional ICMP-based path MTU discovery in IPv4 {{!PMTUDv4}} 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.
+ICMP error messages used in classical Path MTU discovery may be classified into
+messages with an on-path proof and without an on-path proof.  ICMP messages with
+an on-path proof are the messages sent in accordance with {{!ICMPv6=RFC4443}},
+which requires ICMPv6 error messages to contain "as much of invoking packet as
+possible without the ICMPv6 packet exceeding the minimum IPv6 MTU", and
+{{!RFC1812}}, which states that ICMPv4 error messages "SHOULD contain as much of
+the original datagram as possible without the length of the ICMP datagram
+exceeding 576 bytes".  ICMP messages without an on-path prooff are sent in

typo: prooff

>  
-As a result, endpoints that implement PMTUD in IPv4 SHOULD take steps to
-mitigate this risk. For instance, an application could:
+The minimum required validation of ICMP messages with an on-path proof invoves
+verifying that the message was sent by this endpoint with at least 1-2^32
+probability and it is still outstanding (not acknowledged and not deemed lost).

How does one make this determination?

>  
 * 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.
+  most invalid ICMP messages arrive when there are no DF packets outstanding,
+  and can therefore be identified as spurious.
+
+* Store IP ID field of the sent datagrams to validate that ICMP message is
+  refering to an outstanding packet.

More IPv4 advice, which should be called out as such.  I don't think that senders will remember this if it is not predictable.

> +  most invalid ICMP messages arrive when there are no DF packets outstanding,
+  and can therefore be identified as spurious.
+
+* Store IP ID field of the sent datagrams to validate that ICMP message is
+  refering to an outstanding packet.
+
+Any ICMP messages that fail validation MUST be discarded.
+
+It is important that any problems are detected quickly during the connection
+handshake, because the client may be able to mitigate them by switching to
+alternative IP addresses or protocols.  Hence, an endpoint SHOULD reduce Path
+MTU in response to an ICMP Packet Too Big (PTB) message during a handshake,
+unless then would cause a reduction to a Path MTU value smaller than 1280
+octets.
+
+If during a handshake a client receives an ICMP TPB message that requests it to

PTB?

> +  refering to an outstanding packet.
+
+Any ICMP messages that fail validation MUST be discarded.
+
+It is important that any problems are detected quickly during the connection
+handshake, because the client may be able to mitigate them by switching to
+alternative IP addresses or protocols.  Hence, an endpoint SHOULD reduce Path
+MTU in response to an ICMP Packet Too Big (PTB) message during a handshake,
+unless then would cause a reduction to a Path MTU value smaller than 1280
+octets.
+
+If during a handshake a client receives an ICMP TPB message that requests it to
+reduce Path MTU to a value smaller than 1280 octets, then:
+
+* If the client has another IP address for the server to try, the client should
+  restart the connection to another IP.

SHOULD?

> +  and can therefore be identified as spurious.
+
+* Store IP ID field of the sent datagrams to validate that ICMP message is
+  refering to an outstanding packet.
+
+Any ICMP messages that fail validation MUST be discarded.
+
+It is important that any problems are detected quickly during the connection
+handshake, because the client may be able to mitigate them by switching to
+alternative IP addresses or protocols.  Hence, an endpoint SHOULD reduce Path
+MTU in response to an ICMP Packet Too Big (PTB) message during a handshake,
+unless then would cause a reduction to a Path MTU value smaller than 1280
+octets.
+
+If during a handshake a client receives an ICMP TPB message that requests it to
+reduce Path MTU to a value smaller than 1280 octets, then:

I think that this disagrees with the conclusion of the working group - we agreed that a PMTU of 1280 was necessary to support QUIC and that the response to a reduction in size was to ignore the signal.  If the signal is true, this causes the connection to fail, but that's OK.

>  
-* Any reduction in PMTU due to a report contained in an ICMP packet is
+If an ICMP PTB message is received after handshake, and the claimed Path MTU is
+at least 1280 octets for messages with on-path validation or 1392 for messages

Where did this 1392 come from?

> @@ -3228,6 +3261,18 @@ increases in the size of probe packets. As QUIC probe packets need not contain
 application data, aggressive increases in probe size carry fewer consequences.
 
 
+## Responding to ICMP "Unreachable" messages {#icmp-unreach}
+
+When a QUIC endpoint receives an ICMP "Unreachable" message during a handshake,
+the response SHOULD be identical to receiving an ICMP TPB message that announces
+a Path MTU smaller than 1280 octets (see {{icmp-pmtu}}).
+
+When an ICMP "Unreachable" message is received after the handshake, the QUIC
+endpoint should send a PATH_CHALLENGE frame ({{frame-path-challenge}}).  Sending

SHOULD?

If "SHOULD", how does an endpoint decide to do this (or not).  If it is purely a rate-limiting thing, then maybe different words would help.

-- 
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/1412#pullrequestreview-127640520