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

[Erik Nygren <[e-mail]>]

This is exactly the sort of thing that I think demonstrates the value of
defining something here so we can have one mechanism that a bunch of UDP
protocols can use to allow for several minute state timeouts.

With TCP you need the sequence/ack numbers to get enough entropy due to the
port number being only 16 bits.  If the connection-id is 64 bits (or there
are two 64-bit connection-ids in the packet, one contributed by each
end-point) does this contribute enough entropy to prevent passive adversary
close/reset attacks?  It seems like active adversary close/reset attacks
aren't possible to reliably defend against (without crypto between middle
boxes and endpoint).

A pattern that has been discussed that seems quite valuable would be to
distribute additional connection-ids for mobility and resumption within the
encrypted channel.  This would allow for resumption, mobility, and
periodically cranking the connection-id without linkability.

Having a server-contributed component of the connection-id (perhaps an
initial one in clear-text and later ones through the encrypted channel)
could allow for stateless packet distribution by server-side load balancers
and could also form part of a proof-of-address-ownership
three-way-handshake mechanism to mitigate against DDoS reflection and
spoofed source address attacks.

      Erik



On Thu, Jul 28, 2016 at 11:23 AM, Dave Dolson <[e-mail]> wrote:

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