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

[Erik Kline <[e-mail]>]

On 31 May 2017 at 20:53, Brian Trammell (IETF) <[e-mail]> wrote:

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

My main concern here would be that preserve the ability to migrate
connections.

Allowing on-path but non-endpoint devices to distinguish traffic as you
describe opens up the opportunity for them to do it incorrectly/badly
thereby making some implementations of connection migration unreliable (at
best).

There may still be ways to support connection migration and support this
kind of traffic analysis, though.