Re: [tcpm] Faster application handshakes with SYN/ACK payloads (RESEND)

On Fri, Aug 1, 2008 at 12:04 PM, Matt Mathis <mathis@psc.edu> wrote:
> Doesn't this create a huge opportunity for a DoS attack, since an attacker
> can send requests with forged from addresses, and the server has to
> burn cycles and/or commit memory, when it is never going to see the next
> packet?

The additional requirements on the server when processing a SYN under
my scheme are:
  * At most, an additional 12 bytes of state in the request sock. At
least, another 5 bytes (depending on alignment etc)
  * Generating 8 random bytes
  * Transmitting an additional 45 bytes in the SYNACK frame (3 bytes
of option + 8 random bytes + 32 bytes of elliptic curve point + 2
bytes header)

The additional storage isn't that bad. Currently, in Linux a
tcp_request_sock is 96 bytes:
(gdb) print ((struct tcp_request_sock *) 0)[1]
Cannot access memory at address 0x60

So the additional space isn't that great. Random number generation
isn't too bad either. Also, the spec explicitly says that hosts can
decide not to support it under load (e.g. if they are switching to SYN
cookies).

I did consider defining a special echo option to save on the server's
storage, but decided that I didn't think it was worth the extra
complexity.

Of course, these are subjective judgements; one might reasonably
consider that to be too much work for a SYN.

Cheers

AGL

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm