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

[Erik Nygren <[e-mail]>]

One proposal based on discussions would be to allow Long headers (with both client and server connection-ids) in certain situations following the handshake.  In particular, when performing a PMTUD probe (or otherwise sending a packet with a larger size than the current PMTU), using a Long form header would mean that a stateless load balancer would still be able to route it based on the payload of the ICMP(v6) message, plus it might make it safer and easier for the server to validate that the packet was send by a device on-path.  Both endpoints would still of course need to have reasonable lower bounds on PMTU as well.

Similarly, such a scheme could also make it more reasonable to support ICMP(v6) destination-unreachable messages in a way that wasn't vulnerable to parallel-to-path resets but could allow devices such as NATs to eventually squelch connections where state is no longer present.  For example, if the Nth and subsequent (3rd?) retransmits of the same data was sent with a full Long header (with both connection-ids) and an ICMP(v6) response is returned that contains both connection-ids (plus enough data from what was sent for validation) then this is a good sign that the node sending is both on-path and that this is a degenerate situation that should only have been reached after multiple losses and thus likely from a legitimate active middle-box.

(Note that client/server above are symmetric as both end-points have the same challenge with roles reversed.)


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