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

[Christian Huitema <[e-mail]>]

On 6/1/2017 6:41 AM, Brian Trammell (IETF) wrote:

> Yep. This indicates another way to split this question: how important is it to be able to distinguish spoofed from non-spoofed sources for initial packets in a flow, versus to be able to do so in the middle of a connection?

OK. Let's tease that apart a bit more.

QUIC runs over UDP. The UDP flow can be observed both during the initial
phase and in the middle of the connection. As long as the routing is
symmetric, the intermediate nodes can see that there are packets flowing
in both directions. That's something of a baseline.

I suppose the question is then about assumptions that these intermediate
nodes can make. For example, a classic example is the need to separate
legitimate traffic from a DOS attack. We can assume that in a basic DOS
attack, packets will flow in just one direction, from the attacker to
the target. So, a firewall that sees packet flowing in just one
direction might detect an attack, and slow it down or filter it
completely. It could do that by looking at nothing more than the UDP
headers. But there may well be some packets coming back from the server,
such as public reset packets. And then the naive firewall might
mistakenly think that the traffic is legit, because the server is
responding.

At that point, there are two lines of thought. One is to provide
information from the sever to the intermediate nodes. For example, if a
smarter firewall would know that this is QUIC traffic, that public reset
packets are not a sign that the server finds the traffic legit, and that
the offending traffic should thus be slowed down or cut. But that means
reliably distinguishing QUIC from other traffic, and letting nodes
distinguish public reset from other packets. There is a slippery slope
there, because nodes may also want to understand acknowledgements and
progress, not just reset packets.

The other line of thought is to place some of the defense against DOS
burden on the server, and to ask it to just completely stop responding
to any traffic that looks like an attack, so that intermediate firewalls
can react to "absence of response". That is, the server can predict how
the network will react to blow-back traffic, and thus thinks of
consequences before sending packets.

I kind of like the second approach. Servers would depend on some well
known behavior of intermediate nodes, which would in fact force these
nodes to be public about their behavior, even to standardize it.
Something like standardizing AQM. That seems like a good path towards
sanity.

-- Christian Huitema