Re: [quicwg/base-drafts] Rewrite Packet Size section (#2036)

[Nick Banks <[e-mail]>]

nibanks approved this pull request.

Generally looks good to me.

> -The PADDING frame provides a useful option for PMTU probe packets. PADDING
-frames generate acknowledgements, but they need not be delivered reliably. As a
-result, the loss of PADDING frames in probe packets does not require
-delay-inducing retransmission. However, PADDING frames do consume congestion
-window, which may delay the transmission of subsequent application data.
-
-When implementing the algorithm in Section 7.2 of {{!PLPMTUD}}, the initial
-value of search_low SHOULD be consistent with the IPv6 minimum packet size.
-Paths that do not support this size cannot deliver Initial packets, and
-therefore are not QUIC-compliant.
-
-Section 7.3 of {{!PLPMTUD}} discusses trade-offs between small and large
-increases in the size of probe packets. As QUIC probe packets need not contain
-application data, aggressive increases in probe size carry fewer consequences.
-
+larger than 1280 bytes (assuming the minimum IP header size).  This results in

I feel like this `(assuming the minimum IP header size)` should be moved to the end of the following sentence instead of here.

> +Each pair of local and remote addresses could have a different PMTU.  QUIC
+implementations that implement any kind of PMTU discovery therefore SHOULD
+maintain a MPS for each combination of local and remote IP addresses.
+
+If a QUIC endpoint determines that the PMTU between any pair of local and
+remote IP addresses has fallen below the size needed to support the smallest
+allowed MPS, it MUST immediately cease sending QUIC packets on the
+affected path.  This could result in termination of the connection if an
+alternative path cannot be found.
+
+### Processing ICMP Messages to reduce the PMTU {#icmp-pmtud}
+
+PMTU discovery {{!RFC1191}} {{!RFC8201}} relies on reception of ICMP messages
+(e.g., IPv6 Packet Too Big, PTB, messages) that indicate when a packet is
+dropped because it is larger than the local router MTU. DPLPMTUD can also
+optionally utilise these messages.  This use of ICMP messages is

```suggestion
optionally utilize these messages.  This use of ICMP messages is
```

> +
+### Processing ICMP Messages to reduce the PMTU {#icmp-pmtud}
+
+PMTU discovery {{!RFC1191}} {{!RFC8201}} relies on reception of ICMP messages
+(e.g., IPv6 Packet Too Big, PTB, messages) that indicate when a packet is
+dropped because it is larger than the local router MTU. DPLPMTUD can also
+optionally utilise these messages.  This use of ICMP messages is
+potentially vulnerable to off-path attacks that successfully guess the IP
+address 3-tuple and reduce the PMTU to a bandwidth-inefficient value
+{{!RFC8201}}.
+
+QUIC endpoints SHOULD provide validation to protect from off-path injection of
+ICMP messages as specified in {{!RFC8201}} and Section 5.2 of {{!RFC8085}}.
+This uses the quoted packet supplied in the payload of an ICMP message, which,
+when present, can be used to associate the message with a corresponding
+transport connection {{!DPLPMTUD}}.

Is it acceptable that a man-on-the-side could use received packets to spoof the ICMP messages?

> +that connection ID information corresponds to an active session.
+
+Further validation can also be provided:
+
+* An IPv4 endpoint could set the 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.
+
+* An endpoint could store additional information from the IP or UDP headers to
+  use for validation (for example, the IP ID or UDP checksum).
+
+The endpoint SHOULD ignore all ICMP messages that are not validated or do not
+carry sufficient quoted packet payload to perform validation.  Any reduction in
+the QUIC MPS MAY be provisional until QUIC's loss detection algorithm
+determines that the quoted packet has actually been lost.
+

Since there should be enough quoted text to decode the packet number of the QUIC packet, you could save a hash/checksum of the first X bytes of the QUIC packet and validate that matches. 

-- 
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/2036#pullrequestreview-177318978