In message <[EMAIL PROTECTED]>, "Steven M. Bell
ovin" typed:
>>Right. Yahoo, though, was flooded mostly by the volume. I worry about
>>high-volume TCP garbage sent to port 80, which you can't filter.
Steve
so in the case that the server resource is overloaded, but not the
link, what you can do is extend the servers scheduling discipline
(e.g. in dealing with existing connexions at a higher priority than
new ones, and applying filters to new ones based on content/application
level metrics (e.g. popularity indices, which is something many
web servers have got anyhow), to priortise and starve the bad guys...
if the links/routers near you are also being clobbered, than some form
of "loose unicast RPF source quench" mechanism would be a
semi-automated way that server sites could extend this scheduling back
"towards" the bad guys - the idea is to take a mix of modified
versions of the resource control messages such as
icmp source quench
ECN
RSVP Reject
etc, and use them to install soft state upstream towarasd the bad guy
this state can either block, or just add a weighted RED higher
drop probability, or eeven move traffic into a lower class in a
diffserv priority, CBQ, WFQ or other...
- but note unlike intserv/rsvp, this state doesnt have to be in all
hops - just the appropriate border/choke point....so it has lots of
nice scaling properties (its only their for a minority of
addresses/flows/ports, its only in a few places, and only when you
need it) - now if someone spoofs a real source address, this
represrents a problem since you can use this mechanism or something
like it to launch an indirect attack using this ....but there are ways
to block that (including making it mandatory to use ipsec to use this
mechanism...)
anyhow, its basically a sort of BGP policy controllable, interne
friendly scalable automated version of phoning up your ISP
and having them back track through all the further ISPs...
cheers
jon
