Slashdot Mirror
Bad Behavior on the 'Net - Who Pays the Bandwidth Bill?
rakolam asks: "I am involved with network management in the hosting department of a fairly large ISP. Constantly we have customers who dispute inbound bandwidth spikes and demand service credits on their burstable connections. Events such as the Slammer Virus literally have everyone knocking on their salesperson's door at the end of the billing cycle. My position is that the internet is a public space, and by placing themselves in that space, one has to realize the consequences (and the implications of burstable billing). I'd like Slashdot's perspective on this. Should ISP's ultimately eat the costs of malicious behavior? Is the customer ultimately responsible for the bandwidth they've generated, regardless if it's desired or not? Is this a new frontier for insurance companies?"
Every ISP should base charges only on how much traffic you send. That would give people a real incentive to keep their systems patched and secured. You wouldn't have to pay a ridiculous amount if you're on the receiving end of a DOS. You would have to pay if your systems get hacked or catch a worm though.
Alas, unless every ISP participated, this model wouldn't work well.
Keep up to date on current worms and other bandwidth threats. Notify your customers about these threats, and provide information on how to eliminate or reduce the impact.
Any massive bandwidth they log after that, is their responsibility. You notified them, and they did not listen.
After a few incidents like that, they will start to listen to your warning messages.
...
Considering the variety of bandwidth providers, acceptable terms of service(TOS) and all that, eventually, it will become a matter of taste, preference and terms that can be agreed with. How many subscribers want traffic shaping, inbound or outbound on their interface? Wouldn't customers PAY for making sure that the only traffic spikes they can get are mail or http related? I'm sure a lot of my hosting clients would love a system where they pay for the bandwidth they use, but that limits are in place to make sure excessive bandwidth usage is actually the usage they pay for.
Since DiffServ and other standards based solutions are ready to be implemented, perhaps you should consider talking to your most whiney clients about it?
Yes I know it doesn't apply to all clients, and not every provider has the extra router/switch cpu power to implement them on all links...
But wouldn't such a solution be a good way to keep the more demanding clients(increasing the value they get: bandwidth for the right traffic) and decreasing the tax hackers and Distributed DOS and misconfigured systems make them pay (for undesirable traffic). Maybe you should suggest this as a customer retention measure, for those clients where it makes business sense.
Well, on the one hand you have the credit card company model. They eat unauthorized charges all the time, and generally it is a good thing. Phone companies and other utilities do a similar thing, if you can prove the fraud, then they generally cut you some slack (though they might make you work for it). I think that this is a workable "consumer" friendly model. I think that generally, if one had a choice between two isp's and one said we're gonna charge you no matter what, and the other said that we won't charge you for malicous use, assuming you can prove it, then I think that the choice would be obvious (price comparos not withstanding of course).
I've always wondered where the cost for bandwidth comes from. I've assumed it is related to equipment and line maintenance, costs for professionals to maintain the equipment and expand the networks, and new equipment and housing.
Can someone give me an idea of where the price for bandwidth ultimately comes from?
Someday, you're going to die. Get over it.
I've always wondered about that. If you had your business on the net, and /. linked to it, causing it to go down, would /. be liabel? Assume the following before replying:
/. can't really play dumb, they HAVE TO know the /. effect is going to be too much for a page. It can almost be called a DoS attack at this point.
*/. did NOT warn the page
*The page in question NEVER receives the amount of traffic necessary to bring it down.
*Let's assume it happened on a Saturday, when they had minimal support
*The company can PROVE they lost revenue.
Finally, math books without any of that base 6 crap in them.
My previous employer was unfortunate enough to be attacked by a series of distributed ICMP ping flood attacks. Our bill jumped from under $1K per month (Canadian) to over $10K in less than a day.
We adjusted our monitoring process to detect these spikes early and contact our ISP to deny traffic from the offending subnets. Luckily, our ISP was willing to do this, even though they still incurred traffic from inbound packets. Luckily, these attacks originated from a few subnets that could be isolated.
As a further kludge, we eventually disabled ICMP altogether on our routers, and lived without ping and traceroute.
Having a host on the net is a risky proposition. You pay for inbound and outbound traffic, regardless of the source, packet type, or quantity. DDoS attacks can not only prevent your server from being accessable, they could literally bankrupt you if you become a target and don't take preventative measures.
Hmm... One click bankruptcy. I wonder if anyone has tried to patent this yet...
Our ISP was technically capable of detecting and thwarting various attacks. Ultimately, the policy of monitoring and contacting an ISP when traffic exceeds a certain threshold seems like a workable solution for average co-locaters.
Given the architecture of the Internet, it's difficult to see how we could shift the burden to pay away from the server to the client. It seems like a problem remarkably similar to the problem of spam.
My car gets 40 rods to the hogshead, and that's the way I likes it!
I work for a small local ISP, before making any decisions we always look at it historically using MRTG. If the customer all of a sudden starts spiking up from their normal amount of traffic, then we will let it slide at first. We will warn them that they may need to check to see if there are any updates for their computers that can help. Also we tell them what to check for regarding P2P programs on computers that they may not know about. If it continues then we are justified in charging them more, because they didn't heed our warnings the first time. Most of the time the customers computer(s) are at fault for the bursts that are coming on their connection. Don't know if this helps in your case, but it seems to work well for us.
Of course my small scale situation may not translate to a large business account.
I'm the big fish in the big pond bitch.
I work for company that writes Utility Billing Software.. from the way that we see it... there's fixed and variable pricing.. make a cost benefit analysis and figure out where the break should be for people to have a fixed fee versus variable.. in events such as the slammer virus.. treat it like a water main break and eat the cost.. it's like telling someone it's there fault they drive a car, that it got broken in to.. if the bandwidth is directly attributed to a situation that is out of the users control, then don't charge them for it.. but if they don't patch up once a patch becomes available (this should also mean that you, the ISP, has the patches readily available so there is no excuse by the user for not doing it), then those later fees should be attributed to the customer..
How shortsighted.
For one thing, the packets go down the wire wether the service is running or not. Thousands of requests per second to a box that isn't running the service still has to respond and say "sorry, not running here". Even if it's a few bytes per, it adds up quickly.
Should a customer be charged for requests coming in for a service they don't offer? No, that's the point of the firewall (or packet filter really).
ISPs could have a new revenue stream by looking at this problem differently.
They can offer a firewall for a per-month fee and waive any bandwith increases as a result of DDOS attack or other work-checking that could be blocked by the firewall. An active firewall could proxy HTTP requests, also filtering out common IIS exploits.
User doesn't want the firewall? Fine, you're responsible for all charges.
This would at least give end users an option instead of what will border on collusion when all the AUP/TOSs change to read the same thing.
Every ISP should base charges only on how much traffic you send. That would give people a real incentive to keep their systems patched and secured. You wouldn't have to pay a ridiculous amount if you're on the receiving end of a DOS. You would have to pay if your systems get hacked or catch a worm though.
Good idea but it doesn't quite go far enough.
You should be billed for the traffic you CAUSE or SOLICIT, and thus have control over. Much of internet traffic is things like web browsing, which invovles a small request soliciting a large reply. If you suck down 60 megabytes of web porn, MP3s, or ftp downloads, it's your bill. Similarly if you host a server, which accepts little requests and pours out data, it's your bill.
But if somebody starts sending you unsolicited packets, that's like somebody making nuisance calls or pages. (You will notice that pagers, at least, are generally NOT billed by the page. They tried that, and the customers rebelled because they had no way to block idiots with autodialers.)
So something with a little deeper visibility is in order. Here's a fair approach:
TCP: You get billed if you make, attempt to make, or accept, a connection. You don't get billed for attempted connections you refuse or that don't get completed (i.e. SYN and other DOS attacks).
UDP: You get billed for outgoing UDP packets. If the billing machine is sufficiently stateful, you might also be billed for incoming UDP packets that ARE replies to a recent outgoing UDP request using a well-known UDP request/reply protocol. (This would prevent cheating but still protect you against getting billed for both DOS attacks and forged-reply billing attacks.)
ICMP: All are free except outgoing EHCO REQUEST (ping), because they're a mandated part of the network overhead. (You don't want to bill inbound ECHO REPLIES to prevent billing for forged reply attacks. But you might bill ECHO REQUEST as if it went both inbound and outbound, to cover the expected ECHO REPLY without making the billing machine stateful about ping "connections".)
That should pretty much cover it. Customers would:
- be fairly billed for the bandwidth they used, caused to be used, or allowed to be used,
- not be billed for unsolicited "phone calls", DoS attacks, or mandated network overhed, and
- have a strong financial incentive to keep their system secured against crackers and malware (such as viruses and worms).
And installing a get-around-the-billing hack (like PPP-over-ECHOREPLY) would be a violation of terms-of-service and cause for disconnection - or changing the billing of that customer back to "all bandwidth co$t$" B-)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Big attacks should be reported to Homeland Security. (Really. Effective March 1, Homeland Security runs the National Infrastructure Protection Center. ISPs are going to be dealing with them on a regular basis.)
Suppose you live on a crosspoint of several countries. Your house happens to be located in a dangerous curve on the road. Also for some reason your house looks to some kiddies like it asks to be vandalized.
For these reasons you get a lot of breakin attempts, occasionally a truck crashes through your walls. All this is not only by people from your own country, but from neighbouring countries as well.
You install warning lights and other measures so cars and trucks don't come in crashing. You call the police when kiddies vandalize your home, but they says they can't do anything.
All this costs you a lot of money and headaches.
In real life there are several ways to defend yourself:
Now apply these principles to your hosting server.
Suppose your house is rented. Is the person renting you the house responsible for every breach? Did he warn you before you signed the contract? Is it his responsability to call you every time some vandals are passing on the road? Or some truck may crash into your home?
Of course your ISP can warn you for every threat that may be coming, but what if there's no warning time? Or he misses a small thing that happens to affect your server bigtime? Is the ISP really responsible?
Be careful out there...
ISP A has customer X. ISP B has malicious user Y. Malicious user Y sends huge quantities of packets to user X.
The question seems to be, should ISP A eat the cost, or should customer X eat it? Why the hell are those the only two options?! It seems to me like ISP *B* should eat the cost, since the malicious packets were sent through their network in the first place. ISP B can attempt to recover their loss directly from malicious user Y.
The ISP *and* the customer are both victims in a DOS attack. Whoever runs the network which *initiated* the attack should be responsible.
There is mod_throttle for Apache which can be set up along with some scripting to activate/deactivate a virtual host. I have done this myself for a webhosting company. The problem is that the web hosting companies decide it is better not to have this option and force clients to charge the extra bandwidth. It is a business policy and not a technical impediment.
No law against this. It like me providing you with a doorbell service. If I want more money, I just keep pushing the button. If you were dumb enough to sign up for this then you'd better trust me.
Clickety Click
People should be accountable. If their PC is infected with a worm or virus which results in a large bandwidth bill, the customer is responsible to pay it. Afterall, the ISP has a bandwidth bill to pay too, and they certainly don't get a "service credit" just because your Windoze box has W32@Klez.
In addition, Making the people responsible for their personal worm/virus traffic would make folks would be more proactive about virus prevention and more cautious of which sites they visit. This IMHO is a Good Thing.
Another potential positive would be that people might start wondering "Why does my friend/relative who runs Linux never complain about viruses?" and "Gee with all these viruses that only affect microsoft products, maybe I should look elsewhere for my software needs."
At least in my state, you are responsible for your car's emissions. If your car is polluting above the state limit, regardless of the reason, it is your responsibility to fix it. They don't care what the reason is for your excessive emissions, whether it was rust, hungry chipmunks, incompetant redneck mechanics, or just a poorly built ford suv. And they have a system of mandatory repairs and/or fines in place to enforce this. This is a Good Thing.
I'd rather be a conservative nutjob than a liberal with no nuts and no job.