Subject: SYN-flood protection - in a router

From: [email-masked]
Date: Wed, 18 Apr 2001 12:29:45 -0700 (PDT)

Hello all,

First let me provide a bit of background behind the motivation for this
post.  I first stumbled on the archive of this WG mailing list a few days
ago, and have been busily reading as much of the history as possible
(particularly the existing threads on SYN-flood protection, including
SYN-cookies).  I have also read the code for SYN/RST-cookies in Linux-2.0
(dated).  It is quite a fascinating subject. :-)

I believe I have a relatively sound (though not complete) grasp on the
subject, where the point of implementation is the server TCP.  However, I
could find no reference to prevention (or hindrance) of SYN-flood attacks
at the router, for the benefit of client TCP's on the other side.  I have
given considerable thought over the last few weeks to how such a solution
could be implemented with the least amount of state-tracking and latency.
I am curious to know if there have been any other such (documented)
projects, and if anyone would be interested to discuss the idea further.

Cordially,
- -bp
- --
# bp at terran dot org
# http://www.terran.org/~bryan

---

From: Alan Cox <[email-masked]>
Date: Wed, 18 Apr 2001 21:13:31 +0100 (BST)

> at the router, for the benefit of client TCP's on the other side.  I have

Why bother ?  Its solved at the client now

> could be implemented with the least amount of state-tracking and latency.

And multipath handling, and failover and ...

All of a sudden the router one looks extremely unattractive. As is normally
the case.

---

From: [email-masked]
Date: Wed, 18 Apr 2001 13:37:35 -0700 (PDT)

On Wed, 18 Apr 2001, Alan Cox wrote:

> > subject, where the point of implementation is the server TCP.  However,
> > I could find no reference to prevention (or hindrance) of SYN-flood
> > attacks at the router, for the benefit of client TCP's on the other
> > side.  I have
>

[correction on my part: s/client/server/ above, though the discussion is
not affected by said substituion]

If the server is too lame to provide SYN-flood countermeasures itself, then
the router [read: firewall] could provide it, and protect multiple such
lame systems at once.  I have read documentation on how at least one rather
large vendor designed such a solution in their firewall product.

> All of a sudden the router one looks extremely unattractive. As is normally

SYN-flood countermeasures in a firewall are quite common today (IINM, more
offer it than don't).  I am not arguing that it is the ideal solution (or
even a preferable one), only that it can be done and does seem to offer
some advantages.

I am hoping to learn more about the practical and technical aspects of such
designs.

Respectfully,
- -bp
- --
# bp at terran dot org

---

From: Drew Simonis <[email-masked]>
Date: Thu, 19 Apr 2001 14:42:05 -0400

[email-masked] wrote:
> at the router, for the benefit of client TCP's on the other side.

I'm surprised at this.  Cisco routers have been dealing with 
SYN floods for some time now.  Maybe not in the way you imagine,
but it is somewhat effective.  One can choose from several methods,
includind using QoS and WFQ, or you can use other traffic shaping
methods.  Most people, however, use Commited Access Rate, or CAR
filtering.

Furthermore, Cisco router models > 4000 support TCP Intercept,
which is designed specifically to combat SYN floods.  

Other vendors, I don't know, but there are well documented and
well known methods for combating SYN flooding at the transit level.