DDoS and Security Reports

Reading a slew of comments associated with a Slashdot post titled Can You Spoof IP Packets? I found a response stating “…every self-respecting network operator has RPF (or some other antispoof-ingress filter) enabled at the edge. Gone are the days of spoofing”.

For more than a decade now, many folks, myself included, have pushed for vendor support and operator deployment of anti-spoofing measures, be it network ingress filtering (BCP 38), subscriber access mechanisms (e.g., Cisco’s cable source-verify), unicast RPF, or similar capabilities. For those not familiar with unicast RPF, BCP 84 provides some insight to different deployment scenarios.

The basic idea behind unicast RPF is that rather than require the network operator to configure an ingress packet filter explicitly permitting approved IP source addresses for a given interface, why not utilize data contained in the underlying routing information base (RIB) to generate such an ingress network filter dynamically. That is, have a look at the routing tables in the router and if a given interface is used to reach destination x, then allow packets to ingress that interface if their source address is x. Seems simple enough….

However, it’s a bit more complex. In particular, it’s not actually the routing table you’re looking at to make the determination; it’s the forwarding table (a.k.a forwarding information base, or FIB), and the FIB only contains a subset of information that the RIB contains (plus some Link Layer information such as next hop hardware address). Most notably, the RIB may only contain a single entry for an IP address prefix that’s subsequently used to populate a corresponding FIB entry for a given destination address space, even while multiple feasible paths exist in the router.

This occurs because one of the many things routers do is determine the single best path to reach a given destination prefix when presented with multiple feasible paths. A route selection algorithm (e.g., BGP’s best path selection algorithm) is applied within a given routing process to select the best path within that process and the route is presented to the local routing system, which applies varying degrees of preferences to routes learned via different processes (e.g., statically configured routes are more preferable than routes learned via IGPs, IGP-learned routes are more preferable than routes learned via BGP, etc.) to select a [typically] single best route to reach the destination address prefix in question. From there, the route is installed in the router’s RIB, and subsequently, the router’s FIB.

So, the problem is that if I’m employing uRPF for source address verification and uRPF is based on the FIB, and the FIB only contains a subset of the potential feasible paths, and a packet with source address s enters the router on an interface with which no corresponding FIB entry for s exists, the uRPF check will fail and the packet will be discarded. The most obvious place this would occur is with multi-homed networks, though anywhere the possibly of asymmetric forwarding paths exists is candidate for failure (there are many more details that could be provided here, but for sake of brevity – I suggest a good read of BCP 84 for additional pointers).

As a result, this strict mode uRPF behavior saw little deployment in large networks beyond single-homed/static edges. So, the idea of loose mode uRPF was introduced. Loose mode uRPF, rather than requiring a match for the check to pass, simply requires that if ANY FIB entry exists for the source address in question, regardless of the associated interface, allow the check to pass. So, what this means essentially, is that when using loose mode uRPF, you can only spoof routed address spaces – of which there’s a rather large pool to choose from, methinks.

What bothers me with this is that while it does cut down on some garbage on the Internet, it creates a false sense of protection for the confused. For example, the recent reflective DNS amplification attacks employed source address spoofing (as do most reflective attacks) and would work whether or not loose mode uRPF is deployed. As such, I consider loose mode uRPF evil. I’d much prefer to see a true feasible path uRPF implementation from router vendors, though I do understand the complexity associated with such an implementation, in particular the hardware implications. In the coming version of our security survey, we asked 55 network operators whether or not they’ve deployed BCP38/uRPF at the subscriber and peering edges of their network and the results look something like this:

Do you employ uRPF/BCP 38 type filters at the customer/subscriber edge of your network?

• 20% No Answer (probably not)
• 53% Yes
• 16% No
• 11% Other (perhaps partially)

Do you employ uRPF/BCP 38 type filters at the peering edge of your network?

• 18% No Answer (probably not)
• 45% Yes
• 33% No
• 4% Other (perhaps partially)

And, this information represents what I’d consider a more clue-dense pool of network operators then the general population – so my suspicion is that it’s actually MUCH lower than this. It’s also important to note that I should have asked two separate questions here – one regarding whether they employ explicit BCP 38 style network ingress filtering, and one regarding whether they employ uRPF (and which mode).

C’est la vie – we’ll get it in the next revision.

Popularity: 5% [?]

This entry was posted on Thursday, May 4th, 2006 at 9:16 pm and is filed under Arbor Networks - DDoS Experts. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.