[c-nsp] ACL vs IP verify unicast: TCAM entries

Euan Galloway euang+cisco-nsp at lists.eusahues.co.uk
Fri Oct 3 11:46:16 EDT 2008


On Fri, Oct 03, 2008 at 05:54:31PM +0300, Victor Lyapunov wrote:

> -Creating an ACL that is common for every subscriber (same for all routers)
> that allows incoming traffic
> originating from the address ranges that are assigned to us. This would
> create an incoming ACL with
> roughly 24 entries that would be applied to the Virtual-Access interfaces.

And would allow any user to spoof the IP of any other user.
Better than nothing, but not as good as it could be.
If you already have an access list there (iACL?), then extending it may / 
may not be less expensive (for some value of expensive. Devel time / 
resource utilisation on device / whatever) than depoloying uRPF.

> -Activating "ip verify unicast" in the virtual-template interface

Yup... 
ip verify unicast source reachable-via rx on the virtual-template, 
and you're done.

Impact on a 10K... no idea.
Like a lot of things on a 10K, probably it works fine with no 
performance impact, or blows up horribly (no idea).

> What is the mechanism employed by "ip verify unicast"? Does it create
> on-the-fly an ACL for each
> interface that it is applied to containg in my case just one entry that
> matches the network address
> of the interface? 

uRPF is not ACLs, and is really well documented.

first couple of hits on google for "Cisco uRPF" are good ones.

http://www.cisco.com/web/about/security/intelligence/unicast-rpf.html

nicely shows the logic of what it does....

To quote (for strict as that's what you would be wanting)...

if the source address best path for a prefix is via the source interface
  pass the packet
else
  if the source is 0.0.0.0 and destination is 255.255.255.255 /* BOOTP and DHCP */
    pass the packet
  else if destination is multicast
    pass the packet
  else if packet matches <acl>
    pass the packet
  else
    drop the packet

> In this case in a typical BRAS terminating 16000 users
> would require 16000 dynamically
> created unique ACLs (or policy-lists in the ERX).

uRPF on the access ports is how you do the anti spoofing without 
nasty script created (or dynamic from authentication system) ACLs.

> Obviouly from a security perspective "ip verify unicast" seems to be the
> optimal solution but would
> consume more memory / CAM entries in ERX case. If our primary concern is
> keeping the load in the

Doesn't work like that on the ciscos.
Doubt it works like that on an ERX (ip sa-validate ?)

> routers low, should "ip verify unicast" be considered the best solution?

"Yes"

> >From your experience does applying
> an ACL with one entry creates less load that an ACL with 24? (in theory all
> entries should be processed in parallel)

On a 10K - no idea.
For the more general case, see the recent discussion on normal vs complied/Turbo 
ACLs vs "doing it in hardware". DOn't think anyone chipped in on 10K PXF ACL 
handling in that thread mind you ;-)

-- 
Euan Galloway


More information about the cisco-nsp mailing list