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

[janaiyengar <[e-mail]>]

janaiyengar commented on this pull request.

Thanks for getting this going, @igorlord ! A few comments, mostly editorial.

> @@ -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}})

I think the context does make it clear, but @martinduke's suggestion seems reasonable.

> @@ -3187,40 +3187,76 @@ QUIC packets on the affected path.  This could result in termination of the
 connection if an alternative path cannot be found.
 
 
-### IPv4 PMTU Discovery {#v4-pmtud}
+### Classical ICMP-based path MTU discovery {#icmp-pmtu}

ditto. Also, Capitalize This Section Title.

> @@ -3187,40 +3187,76 @@ QUIC packets on the affected path.  This could result in termination of the
 connection if an alternative path cannot be found.
 
 
-### IPv4 PMTU Discovery {#v4-pmtud}
+### Classical ICMP-based path MTU discovery {#icmp-pmtu}
+
+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}},

the messages -> messages

> +### Classical ICMP-based path MTU discovery {#icmp-pmtu}
+
+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".  ICMPv4 messages without an on-path proof are sent in
+accordance with the minimum requirments of {{!ICMP=RFC0792}} and contain fewer
+octets past the IP header (typically only 8 octets).
+
+The minimum required validation of ICMP messages with an on-path proof invoves
+verifying that the message was sent by a network element that has observed a
+QUIC packet that is still outstanding (not acknowledged and not deemed lost).

This sentence is a bit hard to follow. Also, it's possible that the ICMP message was received after the sender deemed it lost, since the sender may have been too earnest in marking it lost. Perhaps remove the requirement that it not be marked as lost yet? How about the following: "To validate an ICMP message containing on-path proof, the proof MUST be from a QUIC packet that is not yet acknowledged."

> +
+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".  ICMPv4 messages without an on-path proof are sent in
+accordance with the minimum requirments of {{!ICMP=RFC0792}} and contain fewer
+octets past the IP header (typically only 8 octets).
+
+The minimum required validation of ICMP messages with an on-path proof invoves
+verifying that the message was sent by a network element that has observed a
+QUIC packet that is still outstanding (not acknowledged and not deemed lost).
+To perform the on-path validation, the sender would need to remember at least 8

To perform the on-path validation -> To validate a received ICMP message

> +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".  ICMPv4 messages without an on-path proof are sent in
+accordance with the minimum requirments of {{!ICMP=RFC0792}} and contain fewer
+octets past the IP header (typically only 8 octets).
+
+The minimum required validation of ICMP messages with an on-path proof invoves
+verifying that the message was sent by a network element that has observed a
+QUIC packet that is still outstanding (not acknowledged and not deemed lost).
+To perform the on-path validation, the sender would need to remember at least 8
+octets from the encrypted portion of outstanding QUIC packets.  Alternatively,
+the sender would need to remember a 64-bit hash of the first 64 octets of the
+outstanding QUIC packets.  If a QUIC endpoint does not perform this minimum

the outstanding => outstanding

> +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".  ICMPv4 messages without an on-path proof are sent in
+accordance with the minimum requirments of {{!ICMP=RFC0792}} and contain fewer
+octets past the IP header (typically only 8 octets).
+
+The minimum required validation of ICMP messages with an on-path proof invoves
+verifying that the message was sent by a network element that has observed a
+QUIC packet that is still outstanding (not acknowledged and not deemed lost).
+To perform the on-path validation, the sender would need to remember at least 8
+octets from the encrypted portion of outstanding QUIC packets.  Alternatively,
+the sender would need to remember a 64-bit hash of the first 64 octets of the
+outstanding QUIC packets.  If a QUIC endpoint does not perform this minimum
+validation, it SHOULD treat the packet as an ICMP message without an on-path

SHOULD -> MUST

> +the original datagram as possible without the length of the ICMP datagram
+exceeding 576 bytes".  ICMPv4 messages without an on-path proof are sent in
+accordance with the minimum requirments of {{!ICMP=RFC0792}} and contain fewer
+octets past the IP header (typically only 8 octets).
+
+The minimum required validation of ICMP messages with an on-path proof invoves
+verifying that the message was sent by a network element that has observed a
+QUIC packet that is still outstanding (not acknowledged and not deemed lost).
+To perform the on-path validation, the sender would need to remember at least 8
+octets from the encrypted portion of outstanding QUIC packets.  Alternatively,
+the sender would need to remember a 64-bit hash of the first 64 octets of the
+outstanding QUIC packets.  If a QUIC endpoint does not perform this minimum
+validation, it SHOULD treat the packet as an ICMP message without an on-path
+proof.
+
+As noted in {{?RFC5927}}, using ICMP messages without an on-path proof exposes

an on-path proof -> on-path proof

> +exceeding 576 bytes".  ICMPv4 messages without an on-path proof are sent in
+accordance with the minimum requirments of {{!ICMP=RFC0792}} and contain fewer
+octets past the IP header (typically only 8 octets).
+
+The minimum required validation of ICMP messages with an on-path proof invoves
+verifying that the message was sent by a network element that has observed a
+QUIC packet that is still outstanding (not acknowledged and not deemed lost).
+To perform the on-path validation, the sender would need to remember at least 8
+octets from the encrypted portion of outstanding QUIC packets.  Alternatively,
+the sender would need to remember a 64-bit hash of the first 64 octets of the
+outstanding QUIC packets.  If a QUIC endpoint does not perform this minimum
+validation, it SHOULD treat the packet as an ICMP message without an on-path
+proof.
+
+As noted in {{?RFC5927}}, using ICMP messages without an on-path proof exposes
+the protocol implementation to off-path attacks and requires mitigations.

the protocol implementation -> an endpoint

> +octets past the IP header (typically only 8 octets).
+
+The minimum required validation of ICMP messages with an on-path proof invoves
+verifying that the message was sent by a network element that has observed a
+QUIC packet that is still outstanding (not acknowledged and not deemed lost).
+To perform the on-path validation, the sender would need to remember at least 8
+octets from the encrypted portion of outstanding QUIC packets.  Alternatively,
+the sender would need to remember a 64-bit hash of the first 64 octets of the
+outstanding QUIC packets.  If a QUIC endpoint does not perform this minimum
+validation, it SHOULD treat the packet as an ICMP message without an on-path
+proof.
+
+As noted in {{?RFC5927}}, using ICMP messages without an on-path proof exposes
+the protocol implementation to off-path attacks and requires mitigations.
+
+ICMP messages without an on-path proof SHOULD undergo as much validation as

an on-path proof -> on-path proof

> +verifying that the message was sent by a network element that has observed a
+QUIC packet that is still outstanding (not acknowledged and not deemed lost).
+To perform the on-path validation, the sender would need to remember at least 8
+octets from the encrypted portion of outstanding QUIC packets.  Alternatively,
+the sender would need to remember a 64-bit hash of the first 64 octets of the
+outstanding QUIC packets.  If a QUIC endpoint does not perform this minimum
+validation, it SHOULD treat the packet as an ICMP message without an on-path
+proof.
+
+As noted in {{?RFC5927}}, using ICMP messages without an on-path proof exposes
+the protocol implementation to off-path attacks and requires mitigations.
+
+ICMP messages without an on-path proof SHOULD undergo as much validation as
+possible.  For example, such validation could include storing IP ID fields of
+sent datagrams to validate that received ICMP messages are refering to
+outstanding packets.

This paragraph seems quite redundant. I would replace it with one sentence with recommendation for what state a sender can store to validate proof in ICMP messages.

>  
-As a result, endpoints that implement PMTUD in IPv4 SHOULD take steps to
-mitigate this risk. For instance, an application could:
+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 PTB message during a handshake, unless then would

then -> they

-- 
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-129770367