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

From: Brian Trammell (IETF) <[email-masked]>
Date: Thu, 1 Jun 2017 10:08:40 +0200

hi Christian,

> On 31 May 2017, at 22:09, Christian Huitema <[email-masked]> wrote:
> 
> 
> 
> On 5/31/2017 4:53 AM, Brian Trammell (IETF) wrote:
>> "Shoud QUIC allow devices on path to distinguish QUIC traffic with valid source addresses from traffic with spoofed source addresses?"
> 
> Brian, I am not sure I understand your requirement. Do you mean
> something like the reachability verification implicit in the three ways
> handshake of TCP? Or do you mean some kind of cryptographic proof that
> the device is allowed to use the source address?

Excellent question. I left this intentionally vague, since I didn't want to prejudice a selection of technique, just discuss the utility of the property. (Also, by "a cryptographic proof that the device is allowed to use the source address", I understand "a cryptographic proof that the device can receive packets sent to the source address it uses", since the notion of permission to use here beyond "gets packets routed to it" would require a degree of integration between the control plane and the data plane that would put us in future Internet territory.)

As I see it, this is a question of degree: TCP provides a few bits of entropy (by comparing SEQ/ACK), a cryptographic proof provides many more. The tradeoffs are also different: the former requires a few extra bits in the long header (during initial handshake) and possibly the short header (for resumption and/or continuous proof during a connection), but doesn't provide a very strong proof. The latter provides a very strong proof, but has higher overhead requires sharing a key with the device doing the verification.

Thanks, cheers,

Brian

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 1 Jun 2017 10:37:49 +0200

Hi all,

On 01.06.2017 03:29, Martin Thomson wrote:
> On 1 June 2017 at 06:09, Christian Huitema <[email-masked]> wrote:
> At risk of speaking for Brian, I think that this is intended to cover
> the simple reachability verification implicit in TCP.  That is, proof
> that the endpoint was able to see a packet that was sent to their
> claimed address.

I just would like to note that TCP has a three-way handshake for this purpose 
but also during the connection you have the ack number that is visible to the 
network and also provides some proof that the sender is able to receive 
packets at the indicated source address.

Mirja

>
> The verification provided by ICE also works.  There, it's not a
> three-way handshake, but two independent request/response validations.
>
> (I think that I see a companion to Brian's "what is an endpoint?" doc:
> "what is a path?")
>

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 1 Jun 2017 15:41:17 +0200

> On 01 Jun 2017, at 10:37, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi all,
> 

Or, yeah, what Martin said.

> I just would like to note that TCP has a three-way handshake for this purpose but also during the connection you have the ack number that is visible to the network and also provides some proof that the sender is able to receive packets at the indicated source address.

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?

Thanks, cheers,

Brian

---

From: Christian Huitema <[email-masked]>
Date: Thu, 1 Jun 2017 11:16:34 -0700

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

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

---

From: Mirja Kühlewind <[email-masked]>
Date: Sat, 3 Jun 2017 16:22:46 +0200

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 <[email-masked]>:
>

---

From: "Eggert, Lars" <[email-masked]>
Date: Sat, 3 Jun 2017 14:48:44 +0000

Hi,

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

but that's what middleboxes already do - they drop the binding if there is no bidirectional traffic for a while. Maybe the timeout for this is longer than is needed for DDoS defense, but it's not a new behavior.

Lars

---

From: "Eggert, Lars" <[email-masked]>
Date: Sat, 3 Jun 2017 15:11:00 +0000

> but that's what middleboxes already do - they drop the binding if there is no bidirectional traffic for a while. Maybe the timeout for this is longer than is needed for DDoS defense, but it's not a…

Ah. You said "IP address". That's obviously a broader block than one binding.

Lars

---

From: Christian Huitema <[email-masked]>
Date: Sat, 3 Jun 2017 12:25:45 -0700

> Ah. You said "IP address". That's obviously a broader block than one binding.
Mirja, I was not so much proposing anything as stating the baseline.
Exactly what Lars said. In the absence of some additional QUIC-specific
smarts, middleboxes might do what firewalls and NAT commonly do today:
drop the traffic, or in case of NAT drop the mapping for the 5-tuple if
they don't see bidirectional traffic. This "bidirectional five-tuple"
behavior is widely deployed. It is specified for NAT in RFC 4787,
updated by RFC 7857 and RFC 6888.

One possibility would be to start from there and look at improvements.
We may discuss on the proper timeout -- such as short timeout if this is
the first time a 5-tuple appears at all, longer timer if some
bidirectional traffic has been seen. We may also discuss whether the
drop should be hard, block everything, or soft, put the 5 tuple in some
bandwidth restricted queue. And we may also discuss what else could be
done if the middleboxes could reason on the QUIC headers. But there is
definitely a baseline.

Also note that the problem is twofold. I hear the desire of middlebox
developers to implement some smarts in their devices. But there is the
symmetric desire from application and transport to make the network
behavior predictable. The current state is somewhat predictable:
transports "know" that if the bidirectional traffic is not sustained,
some middlebox might close the connection. So the implementations do
send keep alive traffic. This is not a glorious state, but at least it
is reasonably simple to understand. Part of the issue with "smarts in
the middleboxes" is that it makes the network less predictable, and
transports will have to invent new way to deal with what for them is new
breakage.

-- Christian Huitema

-- Christian Huitema

---

From: Watson Ladd <[email-masked]>
Date: Sat, 3 Jun 2017 12:32:21 -0700

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

How on earth do you have a fatter pipe from outside than inside?
Whatever happened to smart hosts, dumb network? We can't even get
explicit congestion notification deployed or multicast: things hosts
actually need.
> 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 m…
<chop>