Re: Using Long Header packets for PMTUD probes

[Christian Huitema <[e-mail]>]

On 6/29/2018 2:00 PM, Lubashev, Igor wrote:

> We talked briefly in Kista about the possibility of using Long Header
> packets for PMTUD probes.  See Issue 1243
> (https://github.com/quicwg/base-drafts/issues/1243) for context. 
> Briefly, load balancers that use server CID need that server CID to
> route ICMPv6 packets back to the server doing PMTUD.
>
>  
>
> @'Kazuho Oku' <mailto:[e-mail]> suggested using the new
> packet coalescing functionality by sending an invalid long-header
> packet and coalescing it with a valid short-header packet.  This would
> have to work, if one follows the current spec strictly.  This is
> definitely a hack, however.
>
>  
>
> I would like to come up with something that is not a hack, does not
> require sending deliberately invalid packets, but also not to
> complicate the design with the need to care about key phase and
> whatever else one wants to put in the short-header in the future.
>
>  
>
> What do people think about a new “0x7B – PMTU Probe” long header
> packet type?
>
> A packet of that type would just be a bare minimum long header packet
> per Invariants (nothing after source CID), and its only purpose would
> be to be coalesced with other QUIC packets.
>

My personal inclination is to just ignore ICMP, and thus not have to
deal with related attacks. My limited experience so far is that active
PMTU discovery succeeds after just a couple of probes.

In any case, I would rather not have a specific "PMTU Probe" long header
-- I would rather not disclose to middleboxes that the node is engaged
in PMTUD. But I could see the point of a generic "1-RTT" long header. It
could help make stateless reset work. And it could be sent proactively,
say every few RTT, as a form of greasing.

-- Christian Huitema