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

[Mirja Kühlewind <[e-mail]>]

The whole point here is to do the DDoS defense before the traffic reaches your server to e.g. not overload the network between that DDoS defense system and the server. The idea is that you start blocking traffic from an IP address when you never see the third leg of a 2-way exchange (return-routability check). 

Are you proposing that if you don’t see a reply from the server (leg 2) for a while (whatever a while means), you block the incoming traffic from that IP address. That sounds dangerous to me as a middlebox function.

Mirja


> Am 01.06.2017 um 20:16 schrieb 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
>