Should QUIC have a path-verifiable proof of source address?

["Brian Trammell (IETF)" <[e-mail]>]

Greetings, all,

We have a few contentious points in the design of QUIC, and how that design interacts with devices deployed in the Internet. I'd like to start the discussion on two such points, to see if we can come to some kind of consensus as to what we want QUIC to do without regard to how it does it, keeping in mind our charter requirement that QUIC have "security and privacy properties that are at least as good as a stack composed of TLS 1.3 using TCP (or MPTCP when using multipath)."

I'll start with the easier one:

"Shoud QUIC allow devices on path to distinguish QUIC traffic with valid source addresses from traffic with spoofed source addresses?"

The utility of this property is obvious: it would allow in-network reflection/amplification, backscatter, and spoofed-DoS protection equivalent to that available with TCP. This is already provided by TCP state tracking devices for TCP endpoints more or less as a side effect of their operation.

One could argue that this is pointless, since botnets-of-things have made spoofing irrelevant, and careful design (of new UDP protocols), aggressive patching (e.g. of ntpd), and lagging DNSSEC deployment are taking care of the most severe amplification vectors. The other side of that argument is essentially that every little bit helps.

The risks and efficiency tradeoffs are a matter of the exact design used, of course. However, it seems to me that establishing whether this is a desirable feature, and at what cost, seems like a good way to decide whether we should design for it, as opposed to letting discussion of mechanisms drive discussion of requirements.

Cheers,

Brian