Re: [quicwg/base-drafts] ICMP and ICMPv6 PMTUD with asymmetric connection-ids (#1243)

[Kazuho Oku <[e-mail]>]

FWIW, let me point out that under the current draft it is possible for an endpoint to send a long header packet at any time it wants to observe the MTU, even after the handshake is complete. It's just that the long header packet will be ignored by the client in case it reaches the client.

And with the introduction of coalesced packets, the cost of doing this type of PMTUD has become small.

Whenever an endpoint wants to do PMTUD and it has some outstanding data, is creates a datagram that consists of the following two QUIC packets:
* a long header packet with zero-length payload that contains the server CID (or some other payload that is sufficient to route the ICMP response back to the origin server)
* a short header packet carrying outstanding data

This type of datagram never harms the conncection, because the draft requires the receiver to process each QUIC packet as if it was received as a separate datagram.

Assuming that the server will be performing PMTUD and assuming that the client's CID is zero-sized, the overhead of the long header packet is: 1 (type) + 4 (version) + 1 (cidl) + len(server_CID) + 1 (payload-length).

Actually, this approach (i.e. sending a compound datagram to contain arbitrary information) is flexible enough to carry any data that needs to be exposed to an on-path device. We could use it to expose packet drop rate for example.

I'm not saying we should support these kinds of exposures, but we cannot prohibit such thing to happen, because the receiver cannot determine if an incoming packet was sent from the peer (to expose signal to on-path devices) or from an attacker (to disrupt connection).

-- 
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/issues/1243#issuecomment-394580024