[Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF)

[Erik Nygren <[e-mail]>]

On Mon, Jul 25, 2016 at 4:20 PM, Mirja Kühlewind <
[e-mail]> wrote:

> As mentioned by Ted, this is actually not what we propose. The mechanism
> we propose is exposing information under endpoint control which is a very
> important point here. The endpoint has to add an option to send (or
> request) a specific bit of information (which also must be registered by
> IANA with IESG approval). This is just the same as TCP options or IP option
> headers. The only difference is that PLUS has a MAC which allows detection
> of middlebox manipulation (which is not the case for other existing
> protocols such as TCP options). This is another a very big and important
> aspect of what we propose with PLUS as our goal is to encrypt everything
> above PLUS including the TCP header and TCP options in future. Especially
> encrypting TCP option is important because TCP options provide much less
> control than what we propose with PLUS today which is a problem (especially
> as currently still unto 90% of the traffic is TCP). So I actually though we
> are on the same page here and have a common goal.
>

I'm not sure that we get enough value out of extensibility or being overly
generic here, at least for practical non-research purposes.  If there is a
tightly defined set of things allowed, we'll quickly ossify on these
anyways.  As firewall vendors will just bake in those registered by IANA
when they ship their product and then we'll be right back where we are
today with IPv6 extension headers.

I'd propose that it may make more sense to define a fixed header prefix
format that contains the right set of features needed to solve the problems
of QUIC and WebRTC (and other future UDP protocols).  Along with this, also
define a common set of requirements for protocols using this header prefix
(eg, around DDoS reflection prevention).

Having a toolkit for things like handling connection ids in a way that
support multipath mobility, stateless load-balancers, DDoS resiliance, and
which minimize linkability would also be a nice-to-have to prevent each UDP
protocol from having to come up with subtly different ways to solve this
set of problems.

For example, a bare minimum set of features might include:

* Opportunistic signalling to middle-boxes (NATs and Firewalls) for when
they can discard connection state.  Unless we want to declare that new UDP
protocols only work with IPv6 (worth seriously considering, but perhaps not
realistic yet), there just aren't enough {IPv4,port} tuples available for
NATs to support large numbers of users with large numbers of UDP
connections without having crazy-short keep-alive lifetimes.  Middle-boxes
will always need to be aware that this is best-effort (the FINs can be
dropped or lost or not sent by malicious clients, especially during
multipath transitions) but this could make life much better for
well-behaved clients and things like the existing NATs which use port
ranges per client might encourage clients to be well-behaved here on
average.

* Negotiating initial PMTU/MSS.  While clients will need to be able to
probe up/down and respond to routing changes that change the PMTU, the TCP
MSS mechanism and ability for middle boxes to decrement/clamp this value
makes a big difference in how quickly clients behind tunnels can converge
without losing round-trips or having very complicated probing.  Especially
if we want to be able to deploy jumbo-frames it will be important to have a
mechanism here.

* Sending signals in both directions that can be correlated to
connections.  Using ICMP/ICMPv6 may be a fine way to do this but having a
common prefix for connection information that can be included in the
message makes some things such as routing the messages through a
load-balancer much more viable).

* ... there may be a few others from the use-cases doc.

Having a fixed header prefix format might also make it much more viable to
implement with today's router/firewall hardware with just firmware/software
updates which might make a big difference for medium-term uptake.
It might be we can get away with something like:

   [MAGIC+VERSION] [CONNECTION_ID] [BITS_FOR_SYN_FIN]
   [MSS_DURING_NEGOTIATION_WHEN_SYN_IS_SET]
   [EXTENSION_SPACE_OSSIFICATION_MAY_NOT_PASS]

It might be reasonable to allow for some padding space for future extension
and research, but with the expectation that this will often get
dropped/filtered and thus would be something clients would need to probe
for (and is something people could find a way to do today regardless).

    Erik