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

[Dave Dolson <[e-mail]>]

> ... 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:[e-mail]] 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?


> On 31 May 2017, at 15:43, Erik Kline <[e-mail]> 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.

> [ (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).

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