User: Password:
Subscribe / Log in / New account



Posted Apr 10, 2008 23:40 UTC (Thu) by jzbiciak (subscriber, #5246)
Parent article: Improving syncookies

If I understood correctly, we have a dozen or so bits in the syncookie to store TCP options.
Right now, the options are being stored with an ad hoc encoding that doesn't evolve.

Syncookies only kick in when there's a certain connection backlog, and so represent a graceful
failure strategy.  As a result, most connections are legitimate, and the kernel could keep
some statistics on what option sets are "popular" among legitimate connections.  From this, it
could build a table with the "N" most popular option sets, in essence defining an ad hoc
encoding rather than a rigorous encoding.  Such an ad hoc encoding would evolve as protocols

Within 12 bits, we can represent 4096 such sets.  Even if an option set required 64 bits (8
bytes) (that's including its "popularity histogram"), that's only 32K of storage.  If we
reserve some subset of these as "static", for mapping connections onto when syncookies are
enabled and there's no perfect match, then we have a graceful fallback mechanism that also
evolves.  You'd probably need some additional storage to keep track of "most popular recent
misses" to allow new entries to climb their way into the table.

Since I suspect there's strong correlation between certain feature combinations, I imagine
such a table will be fairly stable most of the time.

Or is this too crazy?

(Log in to post comments)


Posted Apr 11, 2008 15:14 UTC (Fri) by Randakar (guest, #27808) [Link]

One consideration is that with DOS attacks the attacker is trying to make the receiving end do
as much work as possible for as little cost to the attacker as possible. So with this
implementation he'd use an odd combination of option flags to make your server burn as much
bandwidth as possible. More than he is using in sending out SYN packets.

You can't really put more data in your ACK than he is putting in his SYN or you will lose.

Good security requires careful thought :-)


Posted Apr 14, 2008 20:42 UTC (Mon) by jzbiciak (subscriber, #5246) [Link]

I don't know that such a lookup is terribly expensive at all.  If someone shows up with
options that aren't in your "greatest hits" list, you don't need to update anything until the
person makes a complete connection.

Initially, syncookies don't even get engaged at all anyway.  Once they do get engaged, all
you're left with is a table lookup to find hit/miss in the greatest hits table, and a version
of the existing cryptographic hash if the pattern's a miss.  With a properly designed
(non-cryptographic) hash for the "greatest hits" lookup, that should go very quickly and
cheaply, and can even save you from doing the cryptographic hash for the syncookie.  You could
actually end up ahead of the curve in terms of computational load.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds