Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

It could've been worse (was Re: DoS (Denial of Service) Attack resource page)

  • From: Sean Donelan
  • Date: Tue Feb 15 07:08:50 2000

On Mon, 14 February 2000, Randy Bush wrote:
> ettore bugatti, maker of the finest cars of his day, was once asked why his
> cars had less than perfect brakes.  he replied something like, "any fool can
> make a car stop.  it takes a genius to make a car go."

The scary thing is this was really only a moderate attack.  Network engineers
created worse Internet disruptions by accident in the past.  The difference
is intent, not result.

The good news is you can use the same techniques to protect against many
different causes of service disruptions. Does it matter whether you get
hammered by the slashdot effect, or a denial of service attack; a F5 tornado
or a ryder truck; a backhoe or a gopher; or the scariest of them all, a Bell
technician?

I know some people joked when I suggested QoS might be a way to look at DoS,
because attackers wouldn't set the low priority bit on their packets.  But
one way to protect against the slashdot effect or a DoS would be for a host
to advertise how much available bandwidth they have, and when it is exceeded
start "call gapping" (if I might borrow that term) at the edges.  If Yahoo!
couldn't handle 1Gigabit(byte) of traffic, their enginers could set their
QoS/RSVP/RED with their providers to how much traffic they can handled.  This
might allow excess traffic to get dropped sooner on a more distributed basis,
hopefully preventing single routers or hosts from getting overwhelmed and
falling over.

Since I've haven't thought QoS was good for anything in the past, maybe this
could be the problem the QoS people have been looking to solve.

>From what I've heard, the way most providers combatted the current attacks
was installing filters and rate-limits on identifiable traffic.  The protection
depends on the attacker using packets which aren't necessary for the normal
functioning of the site.







Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.