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

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 31 May 2017 13:53:21 +0200

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

---

From: Erik Kline <[email-masked]>
Date: Wed, 31 May 2017 21:04:03 +0900

On 31 May 2017 at 20:53, Brian Trammell (IETF) <[email-masked]> 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)."
>
> "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.

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 31 May 2017 15:22:40 +0200

Hi, Erik,

> On 31 May 2017, at 14:04, Erik Kline <[email-masked]> wrote:
> 

<snip>

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

<snip>

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

Okay... so I'll mark that down "this seems useful, but not at the cost of any flexibility in connection migration."

Actually, your answer suggests an alternate and potentially more useful framing for this question: "which design properties are you not willing to sacrifice to get the ability for devices on path to distinguish QUIC traffic with valid source addresses from traffic with spoofed source addresses?", which captures the risk/utility tradeoff nicely.

Thanks, cheers,

Brian

---

From: Erik Kline <[email-masked]>
Date: Wed, 31 May 2017 22:43:13 +0900

On 31 May 2017 at 22:22, Brian Trammell (IETF) <[email-masked]> wrote:

> >> "Shoud QUIC allow devices on path to distinguish QUIC traffic with
> valid source addresses from traffic with spoofed source addresses?"
>
> <snip>
>
> Okay... so I'll mark that down "this seems useful, but not at the cost of
> any flexibility in connection migration."
>
> Actually, your answer suggests an alternate and potentially more useful
> framing for this question: "which design properties are you not willing to
> sacrifice to get the ability for devices on path to distinguish QUIC
> traffic with valid source addresses from traffic with spoofed source
> addresses?", which captures the risk/utility tradeoff nicely.
>
> Thanks, cheers,
>
> Brian
>

A comment and request to make a distinction (though I know it's
complicated).

[ comment ]
Anything on-path boxes can do analytically can become a point of policy
control in a vendor's marketing slide deck.  There is only embrittlement
down this road, I fear.

[ (complicated) distinction ]
I would like to argue that there is a distinction between:

    [1] on-path elements that are within the administrative domains of
either end-point ("administratively related to an endpoint") and

    [2] on-path elements in administrative domains not associated (except
by peering/transit) with either endpoint.

It might be possible to permit analysis (and therefore policy enforcement)
by the former and not the latter, if we assume there can be some
cooperation with endpoints and on-path elements in their administrative
domain.  If possible, I think this might give the best of both worlds: the
benefits of analysis and policy enforcement but only afforded to the
endpoints and their administrative domains (no interference from unrelated
parties).

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 31 May 2017 17:31:15 +0200

> On 31 May 2017, at 15:43, Erik Kline <[email-masked]> wrote:
> 
> A comment and request to make a distinction (though I know it's complicated).
> 
> [ comment ]
> Anything on-path boxes can do analytically can become a point of policy control in a vendor's marketing slide deck.  There is only embrittlement down this road, I fear.

Of course.

The higher-level argument I'm making behind this whole line of questioning is that there is a principle of conservation of (perceived) control in the deployed Internet, and that this will cause embrittlement to happen anyway. By being explicit and conservative about our aims for what can be done with the QUIC wire image by devices on path, we as protocol designers gain some measure of control over where this embrittlement occurs.

>     [1] on-path elements that are within the administrative domains of either end-point ("administratively related to an endpoint") and
> 
>     [2] on-path elements in administrative domains not associated (except by peering/transit) with either endpoint.
> 
> It might be possible to permit analysis (and therefore policy enforcement) by the former and not the latter, if we assume there can be some cooperation with endpoints and on-path elements in their administrative domain.  If possible, I think this might give the best of both worlds: the benefits of analysis and policy enforcement but only afforded to the endpoints and their administrative domains (no interference from unrelated parties).

In general, I agree with you that there's a useful distinction here. And I agree completely that this function, spoofed traffic recognition and rejection, only really makes sense within the receiver's administrative domain.

(...and now, ignoring my own entreaty to focus on requirements as opposed to mechanisms in this aside...)

Making this distinction leveragable at runtime, however, is tricky: you need some way to establish trust with those devices; and either something like out-of-band like PCP, relying on on the "local to the path" endpoint to use it; or a much more elaborate inline signaling mechanism than IMO it makes sense to wedge into QUIC.

With respect to this *specific* question, though, I don't see how this would work with respect to spoofed traffic detection/rejection, since any design pattern leveraging this distinction necessarily involves the endpoints, and the whole point of spoof rejection as it's currently deployed is to reduce load on the endpoints.

Cheers,

Brian

---

From: Dave Dolson <[email-masked]>
Date: Wed, 31 May 2017 17:14:01 +0000

> ... the whole point of spoof rejection as it's currently deployed is to reduce load on the endpoints

I would add, to also reduce load on the network. 
In many cases the network (or one link thereof) presents more of a bottleneck than the capacity of the endpoint.
In such cases, mitigation at the receiver is too late.

-Dave

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Brian Trammell (IETF)
Sent: Wednesday, May 31, 2017 11:31 AM
To: Erik Kline
Cc: QUIC WG
Subject: Re: Should QUIC have a path-verifiable proof of source address?

Of course.

Cheers,

Brian

---

From: Christian Huitema <[email-masked]>
Date: Wed, 31 May 2017 13:09:19 -0700

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

-- Christian Huitema

---

From: Martin Thomson <[email-masked]>
Date: Thu, 1 Jun 2017 11:29:33 +1000

> the device is allowed to use the source address?

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.

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?")