At RIPE66 in Dublin in mid-May, Benno Overeinder from NLNetLabs and I organized a panel: “Seven Years of Anti-Spoofing: What Happened Since the RIPE Task Force and What Still Needs to be Done.” We were lucky to get six great panelists representing ISPs, vendors, and the Dutch National High Tech Crime Unit. The panelists were:
- David Freedman (Claranet)
- Nick Hilliard (INEX)
- Merike Kaeo (IID)
- Marek Moskal (Cisco)
- Eric Osterweil (Verisign)
- Hessel Schut (Dutch High Tech Crime Unit)
The first question we asked the panelists was more of a rhetorical type: Is there a problem? Or, more precisely, is the problem severe enough to take action?
Unsurprisingly, the answer was yes. We know that IP-spoofing techniques offer an inexpensive technology to mount a reflector attack – an attack that significantly contributes to large volume DDoS attacks against various Internet resources and infrastructure (up to 300 Gbps as in a recent attack on Spamhaus).
Backscatter trend as side effect of spoofed DDoS attacks. Data from a darknet with aperture of 25,600 addresses. Source: IBM. X-Force 2012 Mid-year Trend and risk report (http://www-03.ibm.com/security/xforce/)
Seven years ago, the RIPE community decided to take action and form an anti-spoofing task force. The outcome was two documents – one explaining how to prevent spoofing, and the other explaining why these measures are important and useful for ISPs – a business case. Unfortunately that hasn’t radically changed the situation, as manifested by continuously growing volumes of DDoS attacks ever since.
So what is the real challenge?
The main problem is the insufficient business case. ISPs do not see immediate benefits from deploying anti-spoofing measures that exceed the costs and risks associated with them. A resource (e.g. a web server) can still be attacked, even if a network that hosts it uses ingress filtering, and even if other connected networks do take similar actions.
Part of the problem lies in the solutions themselves, although the building blocks are available and the main message hasn’t changed since 2000 – deploy ingress filtering. At the same time there is a need for better documentation and practical use cases to make the costs, risks and benefits more clear.
Partly, it is about awareness – how many ISPs have paused to think about whether they are part of the problem in a recent amplification reflector attack? This is definitely not evident and tracking back the culprit is very difficult.
Is there a way out?
How can these challenges be addressed? Is there a way out? I think visible improvements can be made in all directions.
Making a good anti-spoofing business case is a difficult task. It means growing a sense of collective responsibility. Yes, anti-spoofing doesn’t necessarily protect a network’s own resources, but it creates a benefit for the Internet as a whole by ensuring that this network is not a launch pad for “spoofed” attacks.
Sometimes costs may help in building a business case: costs of not deploying measures, or of non-compliance. I do not think that regulation is the solution, but suspect that many ISPs won’t be opposed to this idea as it creates a level field with regard to costs and risks of taking action vis-a-vis their competitors.
As was mentioned by several panelists, in many cases applying ingress filtering is straightforward and uRPF or simple filters work perfectly well. However, in more complex setups care should be taken and detailed instructions and descriptions of pitfalls could certainly help some to overcome fear and doubt and apply various solutions appropriately.
When talking about raising awareness I am thinking about who the target audience would be. What are the points in the Internet where anti-spoofing measures can be applied more effectively?
- The “edge?” But the continuously growing edge is impossible to make “watertight,” besides with the proliferation of visualizing and cloud computing the very definition of the edge changes.
- The “core?” But tier-1 providers have little information to apply the techniques – the further one gets from the source of the “spoofed” traffic, the less precise and therefore less effective anti-spoofing measures are.
With 80% of all networks being “stub” – i.e. having no customers of their own – perhaps the remaining 20% is the target audience? As for cloud providers and enterprises, there was a suggestion on the panel that egress filtering should be promoted more strongly.
If we talk about collective responsibility, I think that we, collectively, need more data about anti-spoofing capabilities of networks. If we don’t know whether a network allows IP-spoofing or not, we are discussing an abstract problem. Peer pressure is an effective tool, but it doesn’t work without evidence. One of the existing projects, the Spoofer project, measures the Internet’s susceptibility to spoofed source address IP packets and provides such data, but more vantage points are needed. Another possibility that was suggested is using RIPE Atlas probes to probe network capabilities (or shall we say incapabilities?).
I also would like to note that spoofing itself is a technique and there are other enablers for it to be used in a DDoS attack. Open DNS resolvers are usually cited as main culprits. But this is a subject for another blog post.
The discussion during the session was useful, hopefully raising awareness and making operators think more about what could be done and their responsibilities as players in the Internet ecosystem. But I don’t think it on its own will make any difference. For this, more concrete actions are needed, better documentation, targeted outreach and factual data.