Economics of flooding

Hi, we are doing research on the economics of flooding attacks and we have a few questions;
help would be greatly appreciated.

Is anyone aware of a process for claiming a deduction in charges when fees are associated with a
flooding attack?

In particular, attacks may push up the 95% usage or (more commonly) attacks may create prolonged
loss of network availability; Both outcomes may result in a claim for deduction.

Has anyone ever dealt with something like this? How is this handled today? What evidence or proof has
to be provided to get the deductions (if any)?

Thanks in advance,

Livio.

Is anyone aware of a process for claiming a deduction in charges when
fees are associated with a flooding attack?

In particular, attacks may push up the 95% usage or (more commonly)
attacks may create prolonged
loss of network availability; Both outcomes may result in a claim for
deduction.

This goes to big-boys - it's easier to kick the customer out
then to deal with it, especially if you're running an irc server or similar
things like customers hosting shells/bots/etc.

Has anyone ever dealt with something like this? How is this handled
today? What evidence or proof has
to be provided to get the deductions (if any)?

In general, if you say commit to say 20-30Mbps+ on 95th % up to 100Mbps
burstable, they will ask how often those attacks happen, if it's <5-10 a
month, then it's nothing, regardless how hard you get hit, just make sure
to give them a call and request filters if it's above your 95th % line.

If you get 5+ weekly or *daily* and if NSP cannot put some semi-permanent
solution, other than some pathetic 24h policy or alike, then eventually
they *will* stop working with you. They have other customers and issues
attend to and they will not break the 24h-acl policy rule for just one
customer.

If those attacks overrun their pipes or cpu in routers, thus causing the
downtime, downtime = SLA credits to other customers; and if they can't work
with their peers/transits or peers/transits refuse to work with
your NSP, then at some point they will stop working with you or/and kick
you out per contract/AUP - been there, done that.

Of the top of my head, not UUnet, C&W, Sprint, Genuity, Exodus, Globix,
Verio, to name a few, will go thus far to fix the billing issue, they have
different chain of people working at each level/department, they might bend
once but that's as far as it goes. 9 out of 10 times they'll ask you to
commit to more transit or/and get a flat pipe.

It's about making $ at the end, always, never forget.

-Basil

In my past life at Globix, I was occasionally able to get the fees
reduced and a customer slapped on the hand. What it comes down to as
Basil hinted is a finite resource is being used, and somebody needs to
play for it.

Livio asked for a process...while informal, this was usually ours:
* Customer gets bill at end of month, sees huge number, screams bloody
   murder to sales rep.
* Sales rep pulls up Concord NetHealth (or whatever it's called
   nowdays) and looks at traffic graph for last month. More than likely
   sees huge spike somewhere durning the month, or if box was turned
   into a warez site, a dramatic change in average traffic flow. Sales
   guy prints out page and wanders over to a tech to ask what the
   picture means.
* Techie laughs, takes page and shows to fellow coworkers, who also
   laugh, then groan, recognizing there will be multiple phone
   calls/meetings with client and sales to explain, several time over,
   what probably happened and why we're not going to just wave the bill
   because it was an accident.
* After a few months, client would usually get a credit, if they agreed
   to buy more services or something similar.

In the event of a clued client recognizing an attack, or something
significant enough happening that it had noticable effects on our gear,
it went something like this:
* Either client calling our NOC, or one of us realizing that something
   just went *snap*
* Issue getting escallated fairly quickly up to somebody senior
* Customer either working with us to stop attack, or we down their port
   until they arrive at the DC to fix their server.

...usually in the second case, things are recognized quickly enough that
it falls into the 36 hr window of available bursting for the month.

John

Hi, we are doing research on the economics of flooding attacks and we
have a few questions;
help would be greatly appreciated.

Is anyone aware of a process for claiming a deduction in charges when
fees are associated with a
flooding attack?

*blink* deduction?

In particular, attacks may push up the 95% usage or (more commonly)
attacks may create prolonged
loss of network availability; Both outcomes may result in a claim for
deduction.

There's two things to look at:

* flood doesn't impact much on your upstream provider, but kills your
  port
* flood impacts upstream's gear, affecting more customers than you

In the first case, you'll be hard pressed to find a large provider
that'll help you out. You're better off picking someone a little
smaller than your uunet - you may have a better chance.

In the second case, you might find that your contract allows them
to pull your connection if its affecting their customers somehow.
In any case, you'll find them quick to respond - maybe they're able
to find the source of the DoS attack (into their network) and quash
it - or maybe they determine that the irc server or shell box you're
running just isn't worth the hassle and turns you off.

Another reply to this post referenced warez and the like - damn,
what ever happened to taking responsibility of your own servers?

Adrian