Re: Feedback on TCP Fast Open?

Hi Amos,

On Sat, Aug 03, 2013 at 12:05:15PM +1200, Amos Jeffries wrote:
> On 3/08/2013 11:19 a.m., Peter Lepeska wrote:
> >"it's unclear how beneficial it would
> >> be for us since we already have such gains for browser preconnect (our
> >> browser feature that learns from past web browsing to speculatively
> >> establish connections, typically just TCP connections but perhaps doing a
> >> TLS or other handshakes too as needed)"
> >
> >It would benefit any time you encounter a host that preconnect has not 
> >learned about yet. Surely this provides a benefit.
> 
> Yet assuming TFO does require that prior key exchange mentioned by Nico 
> (I have not yet read the TFO spec). That means that preconnect will has 
> also already been done right?
> So gains are 0 in that case.

Not exactly, just that an earlier connection would have already been made
to the same site, so exactly as for preconnect as William described it
(since the browser decides to connect based on browsing history). So from
this point it is similar.

> Its main benefit seems to be allowing for prefetching to be skipped or 
> short-circuited if it is used as the initial step of such prefetch.

The benefit I'm seeing mainly is not to maintain idle connections to
servers which do not know if they can kill them or not. However we don't
know if the TFO SYN will pass, which is a real issue (hence my proposal to
use TFO in preconnect and to send a harmless request such as GET favicon).

> >It also has lower cost since it will result in fewer (zero) connection 
> >mistakes since it's not doing anything speculatively. Don't get me 
> >wrong I'm a big fan of the benefits of speculative prefetching in 
> >general, but only in the case where the underlying protocol can't 
> >solve the problem without mistakes.
> >
> >TCP Fast Open seems great as long as it doesn't introduce any other 
> >problems (such as increased DoS vulnerability).
> 
> It is clearly lowering the capacity barrier SYN-flood DDoS need to reach 
> in exchange for 1 RTT on legitimate TCP setup.
> The big question though is; overall which are more common: DDoS 
> SYN-flood packets or legitimate SYN?

It depends. I've been involved in dealing with multi-10G SYN flood attacks
on some large infrastructures which surprizingly did not get that many
connections normally. So if we do the math, 30-40 Mpps for 4 hours is
about 500 billion SYN, which is about 200k SYN/s over one month. So such
an attack for 4 hours every month produces 10 times more SYNs than clients
running at 20k conn/s. But what matters really is the user experience.

That said, I'm not that much afraid of SYN floods with TFO at the moment,
for multiple reasons :
  - attackers still don't send TFO and will probably not do for a long
    time since it reduces the reach probability
  - normal SYN floods are already enough
  - one of the benefits of TFO is that you don't have to respond to validate
    the packet. So you have everything in it to decide whether it's valid or
    not. OK it takes CPU time, but not much more than building a SYN cookie
    and sending it back.

I also remember when experimenting with TFO on Linux that sometimes it stopped
accepting it when I was flooding it, I suspect that if the failure rate is too
high, it might decide to disable it, but I'm not sure about this since it was
a very early implementation (so it might as well have been a bug).

Best regards,
Willy

Received on Saturday, 3 August 2013 05:37:00 UTC