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

From: Erik Nygren <[email-masked]>
Date: Mon, 19 Mar 2018 22:14:41 +0000 (UTC)

Asymmetric connection-ids introduce problems for handling ICMP and ICMPv6 PMTUD messages (such as ICMPv6 packet-too-big) in conjunction with stateless load balancers.  For example, if a server sends out a packet containing a client connection-id that is too big, a router or tunnel end-point may send back an ICMPv6 PTB message containing the packet header.  Because the PTB message with the packet header only contains the client connecton-id, it isn't possible to route to the proper server.

While ICMP/ICMPv6 PTB messages are best treated as optimizations, being able to get them can be very useful for identifying the source off loss quickly as being a too-large packet.

Note that other ICMP(v6) messages such as destination-unreachable also have a similar problem with asymmetric connection-ids.

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

---

From: Erik Nygren <[email-masked]>
Date: Mon, 19 Mar 2018 15:31:13 -0700

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

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 19 Mar 2018 16:36:40 -0700

We used to allow long-header packets after handshake, but got rid of them for the lack of a use case.  This is a valid use case, so it would be good to bring back these long-header packets.

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