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?"
Thats because they pass that cost on to the vendor, for not validating enough information about who the purchaser was.
The CC company doesn't eat that. The vendor does for accepting the stolen card
The problem with billing for excessive inbound traffic is that the user has absolutely no control over what they receive.
You can have the most sophisticated firewall on the planet, but due the immutable laws of IPv4 you can NOT drop a packet until you see the packet. At which point you've already used the bandwidth (and incurred the cost) required to transport the packet that you're just going to drop.
This has nothing to do with patching your server. If you don't patch your server, and you get hit with a worm, and your box starts consuming huge amounts of bandwidth to attack other hosts, then it's your fault, and its OUTBOUND traffic, and you absolutely should pay for it. But having your server patched does not stop you from receiving inbound packets. They may not harm your server when they get to it, but you already paid for the transit.
BTW, This is why it's illegal for a telemarketer to call you on your cell phone. Because in theory you had to answer the call (and incur expense) BEFORE you knew who was on the other end.
This is a similar issue, except that we're not talking about telemarketers... which are businesses that more or less follow the rules. We're talking about script kiddies that don't care about the rules. Or in a worse case, we're talking about a competitor, or enemy, or rival that just wants to DOS you for a month until you go out of business because of all the excess bandwidth charges you're paying!
The technology limits the liability of the consumer. The ISP must take some responsibility here and put systems in place that protect the consumer.
-JE
There are several Apache mods that will either limit total useage or shut off files on the end of large spikes.
The original question though is what should the ISP have done. IMO they should have firewalled access to the affected ports and then split the cost.
Presumably this refers to hosted server connections, rather than a simple virtual web server account. For this sort of connection, I would want a true Internet connection, instead of some firewalled lan port. I would be very upset if the ISP did ANY filtering on my connection without my specific request or knowledge. It's none of the ISP's business what I do with my end of the network cable (aside from spam policies) - they don't need to know if I'm running a web server, SQL server, or some custom game server that happens to use UDP/1443.
Most colo providers I'm familiar with bill on 95th percentile bandwidth, which means that they drop the top 5% of samples (typically 5-minute average) and bill you for the bandwidth of the highest remaining sample. This means that you can absorb short-term heavy bandwidth spikes without being charged, up to about a day and a half worth of time per month.
In any case, the ISP should have no way of knowing WHAT traffic creates the bandwidth spike, unless I specifically request that they monitor my port. Of course, smart ISPs will exploit these incidents by offering firewalling services as a value-add, even if it's just stateless filtering at the router, as a way for customers to "insure against unexpected traffic spikes from virus/worm activity".
Of course, if I was paying for virtual web service, rather than a server colo and bandwidth fee, I should not be charged for non-web traffic, and I doubt any ISP would have the balls to do so.
The City of Portland Water Bureau will forgive excess water bills due to undetected leaks or the like if you show that you've fixed the problem. Often leaks aren't detectable and a large water bill is the first clue the homeowner sees (western Oregon is very wet, water water everywhere)
A few notes about charging for bandwidth:
These are some of the steps we use to protect ourselves and our customers. Your milage may vary.
(We use packeteer for rate limiting, but I keep eyeballing OpenBSD/AltQ/PF for both rate limiting and firewalling for our customers).
Compare this to someone constantly text-messaging spam to your wireless phone. You could quickly run up an insane bill that way, and there's really nothing you could do about it. The wireless company is contractually in its rights to charge you.
But it won't.
That's how they work. Someone screws with you, typically the provider eats it, especially if there was nothing you could do about it. That puts the incentive back onto the one entity who can actually do something about it: the providers. True for wireless. True for credit cards. True for just about anything where the end user can't do anything to stop the abuse.
The ISPs can do something about it. They have chosen not to because of how we (the geeks) developed the internet. It's too trusting. But at the end of the day, your ISP does know who you are, because they send you a bill. And they could apply uniform terms of service if they chose to, and only talk to other ISPs who have similar terms.
The RBLs are the future. They just don't go far enough. When they're willing to not just cut off SMTP but entire connectivity to other ISPs who aren't willing to play by uniform rules, then we'll start to see some changes. What kinds of rules? Here's some for starters:
- Authenticated mail only. Yep, this looks like banks' "know your customer" rules. You can be anonymous all you like up to the point that you connect to the mailer. But the guy who forwards mail for you is going to be held responsible for your behavior. Yes, that will radically change the free-service providers (yahoo, hotmail, etc). They're free to come up with solutions that don't require them to know exactly who you are, but if they host spammers, we're not going to talk to them. This is just the logical extension of RBLs.
- Same deal for acting as a DDoS zombie. The owner of the unpatched box is responsible, but it's the responsibility of the ISP to be able to identify that person for legal action. If they can't or won't, then we don't talk to them.
None of this says that you can't be anonymous most of the time. It just says that if you're disrupting service and causing real losses due to your actions or lack of actions, your ISP is going to have to hand you over, or they're going to be held responsible. The right to privacy has to be balance with responsibility for your actions.The old-world networks (phones) have worked this way for years. I can block my out-bound caller-id. I can have an unlisted phone number. I can be very anonymous on the phone. But if I'm named in a law suit or criminal complaint, the phone company will hand me over in a heart beat. The only way around this is pay phones with cash. It's hard to run a large-scale scam that way.
And no, this doesn't mean that an ISP's logs are free game to the RIAA. But it does mean that if the RIAA wants to name a specific "unknown party" in a lawsuit, the ISP is obligated to identify them. Before you get excited, that's exactly the current situation. The RIAA just wants to get the info without actually suing you (which is wrong, and luckily some ISPs have resisted). ISPs need to be willing to say they will only interconnect with other ISPs who play by the same rules.
Yes, this will fragment the internet for a short period of time. So do the RBLs. But economics will fix it fast enough, especially if entire connectivity is cut off.
So far, I think many posters have forgotten one simple fact.
.. Now for the juicy bits. This happens. Every day. The large network NOCs are in constant communication with each other about large DDoS attacks. The little ones slip through the cracks until people complain but generally the large network NOCs will have many other issues to deal with so in a way I don't really blame them.
ISPs don't have infinite bandwidth.
I know, its quite a strange idea. But think of this.
If you're a ISP in a single location, chances are you're buying a few (hundred?) megabits off your upstreams. Unless your upstreams are happy to filter traffic they send to you (and unless its a very large DDoS, most of them will take a while to implement any access control), the ISP will still be charged for traffic sent to a customer even if the customer chooses to reject it.
Similarly, if the ISP provides filtering support for their customers, they still receieve the traffic and bite the usage.
Now, if you're a large ISP and have links to other peering exchanges. Even, say, you peer enough to not really need transit. These inter-state links still cost money. And they're fixed. So if a customer is hit with a DDoS they'll still be carrying it _somewhere_.
Even if this mythical tier-${LOWNUM} ISP with lots of fat peering links has some magical scripts to filter out DDoS traffic to a given customer range, it still will hit their border routers. So their peering cross connects have already been filled. The only way around this is to deal with their peers..
But they don't really have the incentive to spend all their time dealing with smaller networks being attacked. They'd be worried with keeping their network from melting under a few larger ones.
The flipside. If you're an ISP with enough bandwidth (and not high-profile sites like irc servers or pr0n) you might be willing to bite the costs of various attacks as part of a marketing point. Customers may come to you because you have a reputation of being lenient under attacks. Perhaps. But thats a delicate line.
Me, I dig flatrate pipes. Usage based pipes is just asking to be owned by excess traffic. If I buy a megabit then all I really have to worry about is service degradation due to DoS. ISPs, in my experience, will help you with that. But if you're on a usage based pipe which then gets owned by a DDoS you're struggling after the fact to get a rebate. Good luck.
(Although, that said, perhaps you guys should consider asking for usage based pipes that _have_ a bandwidth cap. Figure out what your maximum spend amount is, say 5mbit, and then ask for a usage-based pipe based on that. That way you limit your liability _AND_ getting the cheaper transit. Most of the time.)