[4391] in North American Network Operators' Group
Re: SYN floods (was: does history repeat itself?)
daemon@ATHENA.MIT.EDU (Vadim Antonov)
Sun Sep 15 02:57:50 1996
Date: Sat, 14 Sep 1996 23:50:07 -0700
From: Vadim Antonov <avg@quake.net>
To: alex@relcom.eu.net, jhall@rex.isdn.net
Cc: curtis@ans.net, nanog@merit.edu, perry@piermont.com
Jeremy Hall <jhall@rex.isdn.net> wrote:
>In order for your idea to work, the router where you're doing the
>filtering must know how to get to all destinations on the Internet, must
>not have a default network or route, and they must be symetrical.
Well, that is certainly not the case. For reverse-route filters
to work paths do not have to be symmetrical. In fact, in interdomain
routing the condition for applicability of reverse-route filters is
that filtered AS must not do transit.
(Note that reverse filters i described do _not_ require that the route
back must be best. It just have to be present in the RIB corresponding
to exterior routing session over the interface in question.)
>As far as your other statement, when an instability occurs, all traffic
>starts getting slow because the routers are trying to reroute around a
>flapping t3 or whatever caused the outage. Since the whole point around a
>denial of service attack is to deny service, by adding in the fact that
>we need to know how to get to the source address before we forward the
>packet introduces more problems.
Ughm, i do not see the relation between flapping and more problems
created by reverse-route filtering.
>I think you would find this hurts more
>than it helps.
Would you elaborate? There's certainly little hope that SYN flooding
(as well as most of other denial of service attacks) cannot be effectively
prevented w/o more robust source identification, so pros are quite obvious.
The fact that source identification works, and works well enough even
to do billing is beyond any doubt. RELCOM does that on large scale.
>Even if you limit this kind of lookups to when the packet
>happens to be a TCP packet with the syn option, you still have a problem
>in establishing a connection. This creates frustration on the part of the
>end user.
I will not comment, as that corollary is based on something which is
not likely to be true.
--vadim
