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

[Mike Bishop <[e-mail]>]

MikeBishop commented on this pull request.



>  
-## Path Maximum Transmission Unit
+The PMTU is the maximum size of the entire IP datagram including the IP header,
+UDP header, and UDP payload.  The UDP payload includes the QUIC packet header,
+protected payload, and any authentication fields. This can be depend upon the

```suggestion
protected payload, and any authentication fields. This can depend upon the
```

>  
-## Path Maximum Transmission Unit
+The PMTU is the maximum size of the entire IP datagram including the IP header,
+UDP header, and UDP payload.  The UDP payload includes the QUIC packet header,
+protected payload, and any authentication fields. This can be depend upon the
+current path characteristics.  Therefore, the current largest UDP payload an
+implementation will send is referred to as QUIC Maximum Packet Size (MPS).

Do we need a new defined-and-capitalized term for this? Is there a reason this would be different from "current estimated PMTU"?

>  
-The Path Maximum Transmission Unit (PMTU) is the maximum size of the entire IP
-header, UDP header, and UDP payload. The UDP payload includes the QUIC packet
-header, protected payload, and any authentication fields.
+QUIC depends on a PMTU of at least 1280 bytes. This is the IPv6 minimum size
+{{!RFC8200}} and is also supported by most modern IPv4 networks.  All QUIC
+packets (except for PMTU probe packets) SHOULD be sized to fit within the MPS
+to avoid IP fragmentation or packet drop along the path {{!RFC8805}.

"to avoid packet drop" feels like it's missing a word, or at least a letter.  "to avoid packet drops"?  Seems a little colloquial, but if it's accurate, maybe.  "to avoid the packet being fragmented or dropped", perhaps?

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

RFC7322:
> The RFC publication language is English.  Spelling may be either American or British, as long as an individual document is internally consistent.  Where both American and British English spelling are used within a document or cluster of documents, the text will be modified to be consistent with American English spelling.

> +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.
+

That guards against an ICMP message that's wholly fabricated, but not against the man-on-the-side attack.  If the attacker legitimately saw a packet, the only way you detect the attack is when the peer acks the supposedly-too-big packet.

> +
+### 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}}.

Unfortunately, the best security we have when trying to confirm that a message came from someone on path is that it saw the packet.  We should be wary of believing such unauthenticated messages blindly, however -- this might instead be a signal to re-do PMTUD, or as noted below, be a provisional signal until the packet is independently declared lost.

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