- A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
Re: Unicast RPF posted 09/24/2004
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]

On Fri, Sep 24, 2004 at 10:09:36AM +0200, jean.paul.baaklini@xxxxxxxxxxxxx wrote:
> James,
> Thanks for your comments. I see what the issues are with URPF, what I
> don't see is what the advantages are? Is it useful? 

It is a good BCP (Best Common Practice) to always enable uRPF at the edges of
your network. Edge, as in mostly aggregation routers that home in downstream
customers. uRPF not only helps you prevent your downstreams from spoofing their
source addresses, it helps the integrity of the internet as a whole. Things like
the recent "TCP scare" with respect to BGP sessions when someone found 
"vulnerability" with TCP (remember how everyone started crawling trying to md5
their bgp sessions a months ago?), would not have been *too* serioous if many more
ISP's utilized uRPF to prevent spoofed source addresses. 

Many service providers (not all of them) also employ uRPF at their border routers
with peering parties and transit providers (loose-mode uRPF in this case, while
using strict-mode on customer facing edge routers). Like I mentioned in
previous email, having uRPF at the complete border line of your network allows
you to have another key security tool by having a scaled pseudo autonomous
firewall for simple source address blocking thru a single ibgp/igp advertisement.

The industry trend today is that more and more providers are enabling uRPF at
least on their edge routers. At least one BIG "tier-1" backbone (Qwest) recently
enabled uRPF on almost all of their edge routers, and they are continuing to do
that to remaining routers, as a security policy change. And a lot of small to
medium sized networks, including former AT&T Broadband (now Comcast) areas, and
Road Runner also tend to install networks with uRPF enabled as well to prevent
their customers from spoofing their source addresses.

Lastly though, one should be careful about potential performance impact when using
uRPF. Know your router first (although if it is all same, its probably not much
of an issue. but if your network uses different vendors, you shoud know the limits
of each product first before being too liberal with network changes) before you
really go out and do it. While uRPF is not a huge problem for an edge router in
general, it can become a performance issue when you put this on a border router
moving lots of bits, when the border router does not have an ASIC to deal with
this specific task. This is just like potential performance implication as with
adding an ACL on a router moving tons of bits :)

What you have to know is when you turn on uRPF, your router now has to lookup
the FIB two times instead of once. First, to check the source address against the
FIB for RPF check, second to check the destination IP for respective route. This
may or may not be better as opposed to using ACL's depending on your config..
Cisco recommends uRPF as less-cpu-burden tool, but experiences from certain
network implementations show exceptional cases as well. (Like for example,
checking against a two-line long input ACL will most likely be better over uRPF in
most cases[1]).

[1] Two line long linear ACL being O(2) constant, where as MTRIE FIB is mostly
    O(5) constant to come to a lookup match. Ofcourse there are other factors
    involved too as algorithm between linear and trie, and RPF implementation
    is a bit different.


James Jun                                            TowardEX Technologies, Inc.
Technical Lead                        Network Design, Consulting, IT Outsourcing
james@xxxxxxxxxxxx                  Boston-based Colocation & Bandwidth Services
cell: 1(978)-394-2867           web: , noc: