IP unicast RPF source verification

We currently block against spoofed addresses using extended router access lists on the inbound interfaces from institutions (departments and colleges).  Whilst this works, it is very tedious to maintain these access lists (including keeping them synchronised across routers, which we do via a complex external script mechanism).

However, Cisco IOS has a feature called "IP Unicast Reverse Path Forwarding Source Verification" which can be used to block spoofed addresses from entering via a routing interface which I've been meaning to look at for ages.

The feature is activated using the interface command "ip verify unicast source reachable-via rx" - this blocks any traffic entering via that interface if it wouldn't be used to send outbound traffic to the source address: an RPF (Reverse Path Forwarding) check, exactly as multicast does.

Once the feature is applied, the "show ip interface" command will display the number of packets which have been blocked due to it:

JANETC#show ip int e1/3 | begin verify

  IP verify source reachable-via RX

   9 verification drops

   0 suppressed verification drops

   0 verification drop-rate

Asymmetric paths

For the feature to work, it is essential that traffic paths are symmetrical across any interfaces on which it is used.  This is normally the case for simple edge interfaces as there can only be a single path to the address ranges which are connected and statically routed across them.

However, on links where dynamic routing takes place, traffic can arrive via the non-reverse path, resulting in asymmetric paths.  On the internal links of a network, this is usually not a problem as long as the traffic across those can be trusted, as long as the edge of the network is protected.

The only place where this presents a problem is where dynamic routing takes place across an administrative boundary (such as those between ASs where eBGP peerings are used).  Here, the obvious solution is to fix the traffic paths such that they are symmetric, which is required if multicast is to function correctly anyway.

However, the verification feature supports an access list to allow packets to pass, even in the event of the RPF check failing.  This is specified on the end of the "ip verify ..." command, e.g.:

ip access-list standard 3

 permit 128.232.0.0 0.0.255.255

 permit 129.169.0.0 0.0.255.255

 permit 131.111.0.0 0.0.255.255

!
interface Ethernet1/3
 ip verify unicast source reachable-via rx 3

The number of packets which have been permitted through this mechanism will also show up in the IP interface information under "suppressed verification drops":

JANETC#show ip int e1/3 | begin verify

  IP verify source reachable-via RX, ACL 3

   31 verification drops

   39 suppressed verification drops

   0 verification drop-rate

Interaction with access lists

When combining this feature with inbound access lists on an interface, the access lists are applied BEFORE the source address verification.  As such, packets which the access list blocks will not show up in the address verification counts, shown above.

The two features can be usefully combined, as access lists do not need to be written to handle the validation of source addresses - they can just permit or deny the traffic required, based on ports and protocols, leaving source address validation to be done by the verification feature.  This is especially useful when multinetting is used.  I expect this will allow us to simplify many of our access lists.