Categories
Building Trust Improving Technical Security

Is IP Spoofing A Problem Worth Solving?

During RIPE 71 last week in Bucharest, Benno Overeinder from NLnetLabs and I organised a BoF to discuss the problem of source IP spoofing.

Some may ask with a certain level of frustration, “Anti-spoofing?!! Source address validation?! BCP 38?! Again?!” Indeed, visible progress in anti-spoofing has been quite disappointing. Despite existing technical solutions and more than a decade of consistent evangelizing, not much has changed by the look of the symptom – most notably reflection-amplification DDoS attacks. They have only gotten bigger!

Several aspects make this problem especially tough.

  • Existing technical measures are only effective and applicable close to the edge – computers and other end-devices connected to the net. This requires deployment of anti-spoofing measures by a vast majority of networks on a global scale – something that is not easy to achieve.
  • Accountability is a problem. Tracing spoofed traffic back to its real source is impossible in the majority of cases
  • The business case is very weak. There are network types where confidence in the validity of the source IP address is important for their proper operation, but in general, and coupled with the lack of accountability, implementing source address validation has costs and does not bring real benefits for an individual network.
  • We do not even know where we are. There is a challenge in detecting “spoofable” networks and therefore a lack of statistically representative data regarding the state of affairs. It is impossible to say how the situation has changed over last decade.

And so, we had to pose a question as to whether solving this problem is worth it at all. Should we, as a community and as individual operators, concentrate our efforts on reactive measures of mitigating the outcome of the spoofing – a volumetric DDoS attack? Should we make mitigation measures more accessible, less costly, more automated and more effective?

And, in general:
Are we solving the problem?
Are we solving the right problem?
Are we solving it in the right way?

There was an interesting discussion and people lined up at the microphone. It was hard to expect a breakthrough, but from my perspective three points were reinforced:

Measurements. Being able to identify source address validation capabilities (or lack thereof) is an essential element of any solution in this space. Otherwise, it is like tilting at windmills.

Spoofer is a good start. But the number of measurements is too low and their location is somewhat biased. We need to expand these and find and correlate these data with other sources to produce a more statistically representative set.

Incentives. Without a stronger business case we cannot expect a solution at scale. This is, unfortunately, not telling the BCP38 story better, this means creating better incentives. This might need both a carrot and a stick.

A carrot could be a self-enforcing reputation of a growing group of adopters of these measures that publicly declare their actions – this is what MANRS is doing. The more operators join, the more important anti-spoofing measures become, the stronger the cultural shift toward collaborative security will be.

A stick might be liability. As Paul Vixie wrote recently, “In the world of credit cards, ATM cards, and wire transfers, state and federal law explicitly point the finger of liability for fraudulent transactions toward specific actors. And in that world, those actors make whatever investments they have to make in order to protect themselves from that liability, even if they might feel that the real responsibility for preventing fraud ought to lay elsewhere. We have nothing like that for DDoS. The makers of devices that become part of botnets, the operators of open servers used to reflect and amplify DDoS attacks, and the owners and operators of networks who permit source address forgery, bear none of the costs of inevitable storms of DDoS traffic that result from their malfeasance.”

People still consider this a problem worth solving. The general feeling is that abandoning it will just make the mitigation part harder and harder, not cheaper and simpler. At the same time anything that contributes to the effective mitigation of a DDoS attack should be taken as an integral element of the overall solution.

Please let us know if you have thoughts on anti-spoofing or ideas on how to address it – and whether or not you think it is a problem worth solving. We’ve created a mailing list to follow up the BoF discussions at RIPE, which you can join at https://elists.isoc.org/mailman/listinfo/anti-spoofing. Or, of course, you can always comment here on the blog or on Twitter, Facebook, or Google+.

Categories
Building Trust Improving Technical Security Open Internet Standards Technology

New Whitepaper Explores Ways to Make IP Spoofing a Problem of the Past

In March 2013, Spamhaus was hit by a significant DDoS attack that made its services unavailable. The attack traffic reportedly peaked at 300Gbps with hundreds of millions of packets hitting network equipment on their way. In Q1 2015, Arbor Networks reported a 334Gbps attack targeting a network operator Asia. In the same quarter they also saw 25 attacks larger than 100Gbps globally.

What is really frightening about this is that such attacks were relatively easy to mount. Two things made these attacks possible: bots with the ability to spoof the source IP address (setting it to the IP address of a victim) and “reflectors” – usually open DNS resolvers. A well selected DNS query can offer a 100-times amplification, meaning that one needs only to generate queries totaling 3Gbps to create a merged flow of 300Gbps. A relatively small set of clients can accomplish this.

Of course there are DDoS attacks that do not use these two components; they hit the victim directly from many globally distributed points. But they are traceable and two orders of magnitude more difficult and expensive to accomplish.

Mitigating the reflection component of the attack is one way of addressing the problem. As reported by the OpenResover project, in the last two years the amount of open DNS resolvers has dropped almost by half – from 29M to 15M. However, there are other types of amplifying reflectors – NTP and SSDP are among them, and even TCP-based servers (like web servers, or ftp servers) can reflect and amplify traffic.

And reflectors are just the accomplices. The root cause of the reflection attacks lies in the ability to falsify, or spoof, the source IP address of outgoing packets. As Paul Vixie put it, “Nowhere in the basic architecture of the Internet is there a more hideous flaw than in the lack of enforcement of simple SAV (source-address validation) by most gateways.”

Tackling this problem is hard. Lack of deployment of anti-spoofing measures is aggravated by the fact that the implementation of anti-spoofing measures is often incentive-misaligned, meaning that networks only help other networks by implementing the practice and do not directly help themselves. There are also real costs and risks for implementing anti-spoofing measures.

In February 2015, a group of network operators, security experts, researchers and vendors met at a roundtable meeting organized by the Internet Society with a goal to identify various factors that aggravate or help solve the problem, and to identify paths to improve the situation going forward.

The main conclusion is that there is no silver bullet to this problem and if we want to make substantive progress it has to be addressed from many angles. BCP38, which is sometimes promoted as *the solution* to the problem, – is just one tool, not effective in some cases. Measurements, traceability, deployment scenarios and guidance, as well as possible incentives, communication and awareness – are among the areas identified by the group where positive impact should be made.

For example, measurements and statistically representative data are very important; if we want to make progress, we need to be able to measure it – the ability currently missing to a great extent.

Another recommendation that came out of this meeting was the possibility of anti-spoofing by default. The only place you can really do anti-spoofing is the edge (or as close as possible). Addressing the challenge at the edge seems only possible with automation and if anti-spoofing measures are switched on by default.

Read more about this in a whitepaper that contains the main takeaways from that discussion and articulates possible elements of a comprehensive strategy in addressing source IP address spoofing challenge.

I ask you to read the whitepaper, and ultimately deploy these anti-spoofing technologies in your own network. Can you do your part to prevent DDoS attacks? And if you are willing to do your part, how about signing on to the Mutually Agreed Norms for Routing Security (MANRS) and joining with other members of the industry to make a more secure Internet?