Home / Blogs

Anti-Spoofing, BCP 38, and the Tragedy of the Commons

In the seminal 1968 paper "The Tragedy of the Commons" , Garrett Hardin introduced the world to an idea which eventually grew into a household phrase. In this blog article I will explore whether Hardin's tragedy applies to anti-spoofing and Distributed Denial of Service (DDoS) attacks in the Internet, or not.

The Tragedy of the Commons

Hardin was a biologist and ecologist by trade, so he explains "The Tragedy of the Commons" using a field, cattle and herdsmen. To paraphrase by example, imagine a field being used by a group of herdsmen to graze their cattle.

The field is already at its carrying capacity, so if any new cattle are added each cow receives less to eat. The tragedy of the commons strikes when one herdsman adds another cow to the field. This herdsman receives the benefit of an increased cow he can bring to market. All of his cows might be a little skinnier since every cow now has less to eat, but his extra cow more than offsets this loss. Not so for the other herdsmen, all of their cows now receive less food, and they have no extra cow to make up for this loss.

This is the tragedy of the commons in simple terms. An action by one actor results in a substantial gain for that actor and a small loss for everyone else. Now let's think about DDoS attacks, our new anti-spoofing initiative, and the many attempts to get network operators to install filters which prevent IP address source spoofing.

Imagine if almost every network operator installed filters to prevent IP address spoofing ala BCP 38. A network operator who has not yet installed filters has a decision to make not unlike the decision Hardin's herdsman made. It costs money to install filters, albeit a very small amount, but it is not free. Nor is the labour capable of installing those filters cheap. Therefore it makes economic sense for this network operator to not install filters. No one is DDoSing their network, that's someone else's problem. This network operator can save money by not installing filters, and realize none of the loss associated with DDoS attacks.

No Tragedy Here

I have heard this argument made before as a reason why anti-spoofing initiatives have trouble gaining traction. However, this argument starts to break down when we investigate the real costs of DDoS attacks, the real costs associated of installing filters to stop spoofing, and basic network management principles.

Bandwidth is not free. Operators whose network is being used to generate DDoS attacks are paying someone for those packets to egress their network. And unless their customer base consists of people who buy service from them strictly so they can generate DDoS attacks, not a good business plan IMHO, they receive no utility from these DDoS packets egressing their network.

The cost of installing filters to mitigate IP address source spoofing is minimal and continues to decrease. There may have been an argument ten years ago that buying equipment to support mass filtering by IP source address was cost prohibitive. If that argument was once viable, it certainly no longer is. Any carrier grade BGP router can support many more Access Control Lists(ACLs) than are actually needed to support implementation of BCP 38.

What network operator wants malicious traffic on their network? I've talked with hundreds of network operators from around the world in virtually every industry. Never have I met a network operator who wants more malicious traffic on their network, even if they are simply transporting that malicious traffic. Maybe they exist and I just haven't met them, or maybe network operators as a class recognize that malicious traffic, whether bound for them or not, is bad for business. If only because it attracts more bad actors.

No Tragedy Here Either

It was pointed out to me by Jan Žorž that many operators use their older, leftover, networking equipment in places where filtering is required. This older networking equipment may be limited in its filtering ability and not manage well when attempting to block large amounts of traffic. This is a valid point for operators concerned about their capital equipment expenditures, since buying new equipment is a very real cost. However, as this older equipment gradually dies and gets replaced this problem will become moot. This is a problem now, but will eventually phase out.

Another valid argument of anti-spoofing efforts as a tragedy of the commons is the cost associated with training personnel, and maintaining large lists of filters. This is a valid concern and a definite cost. It's why there are multiple initiatives working to provide information on deploying anti-spoofing. We reduce these operational costs by educating operators and providing them with the information they need to implement BCP 38.

New technologies such as Source Address Validation Improvements(SAVI) are also taking the difficulty out of anti-spoofing implementations. For a high level overview of SAVI read this article by Andrei Robachevsky, or read the main SAVI specification, RFC 7039.

Conclusion

While it might be tempting to view the Internet as a commons and DDoS as its tragedy, the comparison doesn't hold up once operator incentives are understood. If the cost of applying filters were increasing, bandwidth was free, and transiting malicious traffic was benign, we may well find that rational acting operators benefit from not addressing IP source address spoofing. Fortunately for the Internet, this is not the case. It is in everyone's interest, even selfish operators, to implement anti-spoofing filters. If not for the Internet's benefit, than for their own.

I am not the first person to make this argument, that honour perhaps going to Joao Luis Silva Damas in this RIPE-NCC document from 2008. Joao describes the business case for filtering quite clearly in self-interested terms similar to those I use in this post.

This post is not meant to trivialize the collective benefits of implementing BCP 38. There has recently been some great work on the Routing Resilience Manifesto for, "Collective Responsibility and Collaboration for Routing Resilience and Security". The Routing Resilience Manifesto is an attempt to codify some of the shared values of network operators into a set of definitions and ideal behaviors. The Routing Resilience Manifesto is very much a work in progress and is always seeking comment. If you would like to contribute to it please visit them or mail them directly.

If you're interested in becoming more involved in the anti-spoofing or BCP 38 conversation , consider getting involved with the Routing Resilience Manifesto, or joining the IETF SAVI working group. BCP38 even has its own wiki now.

This post originally appeared on the Internet Society's Deploy360 blog.

By Andrew McConachie, Network Engineer

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

VINTON CERF
Co-designer of the TCP/IP Protocols & the Architecture of the Internet

Comments

Possible perverse incentive By The Famous Brett Watson  –  Aug 02, 2014 3:31 am PDT

Operators whose network is being used to generate DDoS attacks are paying someone for those packets to egress their network. And unless their customer base consists of people who buy service from them strictly so they can generate DDoS attacks, not a good business plan IMHO, they receive no utility from these DDoS packets egressing their network.

That's oversimplified to the point that I feel the need to offer a correction.

If you're a data centre owner, and your business involves leasing servers to customers, then your customers are paying you for bandwidth (among other things), and you're paying someone else for bandwidth. Whether or not DDoS attacks are a financial problem for you under these conditions depends on your pricing model on both sides. If customers are paying a surcharge for "excess" bandwidth, then the bandwidth costs of an outgoing DDoS attack will be borne by the customer, should they exceed their allocation in the process. This could easily be a net financial win for you if your outgoing costs remain the same or increase less — a perverse incentive to let the problem persist.

We should also bear in mind that DDoS and source address forgery are related but not synonymous: an anti-forgery egress filter will foil certain kinds of DoS attack, but not a simple brute force one. The most effective kind of DDoS attack which relies on source address forgery is the reflector/amplifier attack, for which the DNS service is a popular attack vector. Given the amplification involved and the distributed nature of the originating packets, the attack-in-progress may not even be noticed for its bandwidth consumption at the point of compromise, even if it's drowning the target in gigabits per second. Thus, from the perspective of the originating network, BCP 38 foils only the least problematic outgoing DoS attacks.

Hi Brett Watson,I admit to oversimplifying in By Andrew McConachie  –  Aug 02, 2014 12:27 pm PDT

Hi Brett Watson,

I admit to oversimplifying in the interests of space. You make a good point, and I want to address it.

There is definitely a perverse incentive for data center operators to allow DDOS attacks to originate from their networks, but it's not sustainable. Their customers will notice their increased bandwidth costs on the next billing cycle and demand some manner of recompense, or they will find another operator. As an operator you can't sustainably allow your customer's networks to be the source of DDOS attacks. Your customers will leave you. It might be because they're disgusted you have such weak security opsec. Or, if they remain ignorant of the DDOSing, because they can get the same service for less somewhere else, by not having to pay for someone else's usage of their bandwidth.

Consider a comparison with electricity usage. Does my electricity provider benefit when someone is stealing electricity from me? Let's say my neighbor decides to start growing marijuana plants in his garage, but doesn't want to get caught, and doesn't want to pay the electric bill, so he steals electricity from me. Just like DDOSing, this activity produces a net increase in load on the operator's network. Had my neighbor been unable to steal my electricity, he would not have started this venture. The operator receives a net benefit from increased usage, and increased revenue from this activity.

The problem for my neighbor is that I'm going to notice this on my bill, and I'm going to do something about it. Most likely I cannot leave my electricity provider, but I can dedinitely leave my data center operator. There are many to choose from, and it would be irrational of me to choose one that costs more without providing better service. This is not to say that everyone acts rationally all the time, we don't. However, the model I'm working with assumes rational actors who always seek to maximize their own net benefit.

To your second point; that BCP38 deployment will not prevent all DDOS attacks, you are exactly correct. If the entire Internet implemented BCP38 type filters tomorrow we would still suffer from DDOS attacks. It would just make it easier to track down who was doing them. Deploying BCP38 is about solving the attribution problem on the Internet. It's not so much about preventing bad acts as it is about discovering who the bad actors are. This has the knock-on effect of preventing bad acts, because typically bad actors don't want their acts attributed to them.

--Andrew

I think Brett was pointing out that By Todd Knarr  –  Aug 02, 2014 4:39 pm PDT

I think Brett was pointing out that for things like the DNS amplification attack the outgoing bandwidth will be small enough compared to normal outbound traffic that the customers won't notice it on their bills. But in addition to egress filtering, networks near the edge should also be doing ingress filtering which would stop the forged packets as they enter the networks the unfiltered network gets it's connectivity from.

And once the source of DDOS attacks can be identified, other costs come into play. Once a network gets a reputation as being a DDOS source, other networks will start blocking traffic from it as much as they can to protect themselves which will cause problems for the legitimate customers of the unfiltered network and encourage them to move to different providers. There'll also be pressure on the bad network's connectivity providers to cut them off. It won't take too long before the unfiltered network has to choose between implementing filters and cleaning up it's act or going out of business.

My point still stands By The Famous Brett Watson  –  Aug 02, 2014 9:12 pm PDT

If you are talking about managed hosting providers, then you have a point, but for unmanaged hosting, security is the customer's problem. Why is the customer's host a source of DDoS? Because an attacker has successfully breached security on that host, exploiting some vulnerable software. In an unmanaged environment, that software is the sole responsibility of the customer who is leasing the host. To use your "stealing electricity" analogy, if someone is stealing electricity on the supplier's side of the meter, that's the supplier's problem, but if your neighbour has surreptitiously hooked up an extension lead from your garden shed and is stealing electricity from that, then that's your security problem, and it's completely unreasonable to expect the electricity supplier to do anything about it, or waive the associated costs.

On the question of "solving the attribution problem", it's naive to think that bad actors will be frightened off by IP source address enforcement. The competent bad actors are already hiding behind multiple proxy hosts across multiple jurisdictions. They don't use source address forgery as a means to hide their identity: they use it as a means to conduct specialised attacks, such as reflector/amplifier attacks, which require it. Solve the address forgery problem, and you eliminate the class of attacks which rely on it, but expect the attackers to simply refocus their efforts in a different direction as a consequence. Many of these attackers have a strong financial incentive for their behaviour, and won't be easily deterred.

You're right, if someone is stealing my By Andrew McConachie  –  Aug 03, 2014 9:25 pm PDT

You're right, if someone is stealing my [electricity|bandwidth] then I have every incentive to make them stop. Whoever is paying the bill has an incentive to pay less. Whether that person is the ISP, or a customer renting an unmanaged server. It doesn't really matter as someone whose [electricity|bandwidth] is being used will want to save money.

This assumes perfect knowledge by all participants, and assumes that everyone is capable of perfect security. Those assumptions are the real problem with the model, which is why I believe increasing knowledge about source-address filtering is key.

To your second point, we should be under no no illusion that source-address filtering will somehow stop DDOSing on the Internet. Source-address filtering is just one thing we can do. Maybe it's just one mole we can whack. Other things like limiting amplification via DNS or NTP are also important. We have to try everything.

Implementing BCP 38 is hard By John Levine  –  Aug 02, 2014 7:48 pm PDT

I've talked to people at large ISPs who tell me that they'd be delighted to do strict ingress filtering, but their big customers won't let them. Most big customers are multi-homed, they get address space from several upstreams, and for reasons that are not entirely stupid, they can't send all the traffic from each IP out via the interface to the provider that gave them that address.

This bookkeeping problem could probably be helped by some work at the IETF to develop better ways for downstream networks to say "this block is mine but I don't want you to route traffic to it", and then persuading router makers to implement it.

I've seen that kind of configuration. How By Todd Knarr  –  Aug 02, 2014 8:00 pm PDT

I've seen that kind of configuration. How quickly do the address block assignments change, though? I'd think this wouldn't be something to go in the routing layer, you'd send each upstream a list of all the netblocks from all providers that you own and they use that to build the ingress filter independent of the routing tables. As long as block assignments don't change too often (and that's entire assigned netblocks, not individual IP addresses), it should be feasible for networks towards the edge of the net. It could even be managed by the customers themselves via a form-based Web app, but you'd want good security on it to prevent abuse/misuse.

In real life ... By John Levine  –  Aug 02, 2014 8:03 pm PDT

the customers have a mish mosh of IP ranges from a bunch of upstreams, and no central log of what's connected to what.  If you push too hard on them, they say "If you don't want our money, we're sure we can find other ISPs who do."

Nobody's opposed to proper ingress filtering, but they're definitely opposed to spending a lot of time and money to do it. That's why we need better tools.

Multi-homing and customers wanting LIR space are By Andrew McConachie  –  Aug 03, 2014 9:39 pm PDT

Multi-homing and customers wanting LIR space are the big gotchas with ingress filtering implementations. There is no easy way around it.

If I were a customer who had multiple blocks from multiple ISPs I would egress filter at my edges. I know what addresses I have, and I know that I don't want to be egressing packets which don't have one of them as their source IP. As long as my equipment supports egress filtering without additional cost, I have a financial incentive to egress filter.

So anyway By John Levine  –  Aug 02, 2014 8:04 pm PDT

I would strongly suggest you chat up some ops people at real ISPs and find out what the practical issues are, rather than pontificating in a vacuum.

Add Your Comments

 To post your comments, please login or create an account.

Related

Topics

Cybersecurity

Sponsored byVerisign

Brand Protection

Sponsored byAppdetex

Domain Names

Sponsored byVerisign

Threat Intelligence

Sponsored byWhoisXML API

Domain Management

Sponsored byMarkMonitor

IPv4 Markets

Sponsored byIPXO