BCP 38 - Or why all edge networks need some form of valid prefix filtering
The Internet has been dealing with amplification attacks dependent on source address spoofing at least as far back as the mid to late 1990s. Smurf attacks were the first such attack to which I had any exposure. In a smurf attack, the attacker would send large numbers of ping packets (icmp echo requests) to the broadcast addresses on a large number of networks with the source IP address spoofed to be their DDoS target's IP. All of the hosts on these networks would receive the broadcast echo requests and many or all would respond en-masse, flooding the spoofed target IP with echo replies. It wasn't hard to fill a T1 with one of these attacks. T1's were pretty common transit pipes for small to mid sized ISPs back in the 90s. Over time, most networks disabled directed broadcast, and Smurf attacks became relatively ineffective and went out of style.
Today, the hip method for DDoSing is the DNS amplification attack. In this attack, the attacker sends queries as fast as they can for some DNS record of large size to a large list of "open recursive DNS servers". These are DNS servers willing to answer recursive queries for anyone on the Internet. It's believed there are currently roughly 27 million such DNS servers. The queries are sent with the source address forged to be the DDoS target's IP. Amplification factors of >70x can be achieved with these attacks due to the difference in size between the DNS query and the response. This means for every 1gb/s of available bandwidth to the attacker, they can generate ~70gb/s of attack traffic. Using this type of attack, someone with comparatively little bandwidth can generate an attack large enough to overwhelm nearly any network.
The common thread here is that both Smurf and DNS amplification attacks wouldn't be possible if the attackers couldn't spoof their target's IP address.
BCP 38 was written thirteen years ago (May, 2000), to encourage network operators to institute source address validity filters in their networks. i.e. if a packet enters your network from a customer, you should drop that packet if its source address is not known to be one of your customer's addresses. Router vendors have implemented such filtering as an automated feature, but not on all platforms. Cisco calls it Unicast Reverse Path Forwarding or uRPF. With uRPF enabled on an interface, traffic entering via that interface is dropped if its source address is not covered by a route pointing to that interface. i.e. suppose you have a customer on an interface such as:
interface FastEthernet1/0 ip address 10.0.0.1 255.255.255.0 ip verify unicast source reachable-via rx allow-self-ping ... ip route 192.168.0.0 255.255.255.0 10.0.0.2
With the above interface and route statement, only traffic received on FastEthernet1/0 with source addresses in 10.0.0.0/24 or 192.168.0.0/24 will be forwarded. Traffic arriving via FastEthernet1/0 with any other source address will be dropped.
Unfortunately, not all gear supports this feature. Some gear "supports it", but with such severe limitations as to make it unusuable. This is likely why BCP38 has made so little traction over the years. On gear where uRPF is not supported or not usable, you're left with having to write and maintain an input ACL for every customer interface. On a layer 3 switch with 48 customer ports, that's 48 ACLs, and some multiple of 48 chances to screw up which might cause customer outages, hundreds of additional lines of config, and for no obvious benefit to you or your customers.
For these reasons, many networks have gone without BCP38-style filtering.
This can't be allowed to continue. Attackers have recently demonstrated, using DNS amplification, that attacks in the hundreds of gbit/s are possible. Presumably, they're only limited by the number of either hacked or other high bandwidth hosts they have access to, and their imagination. Spamhaus has been the recent high profile target. Next week, it could be the major stock exchanges or entire countries. It's time for all networks to take responsibility for their traffic and stop spoofed source address packets from making it out to the Internet.
If you haven't implemented BCP38 filtering because your gear doesn't do uRPF and maintaining an ACL for every customer is "too hard", "doesn't scale", or perhaps is more ACL/config than your gear can handle, consider this alternative solution.
On a typical small ISP / service provider / hosting provider network, if you were to ACL every customer, you might need hundreds or even thousands of ACLs. However, if you were to put output filters on your transit connections, allowing traffic sourced from all IP networks "valid" inside your network, you might find that all you need is a single ACL of a handful to several dozen entries. i.e. All your transit output ACL needs to list are all of your IP space, and any IP spaces belonging to your customers who have their own IP space.
Having one ACL to maintain that only needs changing if you get a new IP allocation or add/remove a customer who has their own IPs really isn't all that difficult. As far at the rest of the internet is concerned, this solves the issue of spoofed IP packets leaving your network.
If you want to test your ISP to see if it allows spoofing, the MIT Spoofer Project has binaries for common OS's and source code that can be downloaded and run to test various classes of spoofing from a host.
[/internet/routing] permanent link