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

[Dave Dolson <[e-mail]>]

Regarding the state kept by middle-boxes such as firewalls:
The timeout should be short (a few seconds) until a three-way handshake is complete. This is required to defend against attacks on state memory of the firewall.

In the three-way handshake:
- The server’s SYN-ACK indicates the server is real and willing to talk to the client.
- the client’s ACK of the server’s SYN-ACK provides evidence the client is real (vs. spoofed) and has witnessed the SYN-ACK

The random sequence numbers and ack numbers are valuable in this regard. E.g., a spoofing device cannot simply send the first and third packets because the third packet must correctly ACK the second packet from the server.

Once a three-way handshake is witnessed, TCP state timeout can be several minutes.

The proposal below doesn’t seem to contain enough information for a firewall to know the client is real.
Consider adding a random number that each side can echo back? Perhaps a different connection-ID per direction?

-Dave



From: Spud [mailto:[e-mail]] On Behalf Of Erik Nygren
Sent: Thursday, July 28, 2016 11:03 AM
To: Mirja Kühlewind
Cc: Kyle Rose; [e-mail]
Subject: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF)

On Mon, Jul 25, 2016 at 4:20 PM, Mirja Kühlewind <[e-mail]<mailto:[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