Re: [tcpm] TCP Long Options - Why not as payload in SYNs?

[Christian Huitema <[e-mail]>]

> >> Any stack that uses SYN Cookies, or wants the option to, will reject
> >> any SYN that has payload.
> >
> > Why couldn't it ACK the SYN but not the data, and compute the cookie
> > based on the header only (as with an 'empty' SYN?)
>
> Note that this is a valid response only where the data is NOT
> interpreted as extended option space.
>
> AFAICT, SYN cookies are incompatible with long options, and yes,
> rejecting them is the appropriate response if cookies are required for
> all connections.

Also, SYN cookies are only one specific defense against SYN flooding attacks. They are a good defense if the main worry is the memory consumed by connection state. They have however two drawbacks: they do nothing about "back flood", i.e. saturating the output NIC and link with SYN-ACK; and they diminish the robustness of the connection set-up for all applications where the first message comes from the server.

When experimenting with these attacks, I found that we can achieve a good defense with a combination of "short" state information in memory for the "half open" connections, and rate limiting of the number of SYN that a system is willing to process. Cookies would not help much, if at all.

-- Christian Huitema


_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm