IPv6 NDP exhaustion or lack of it

[Mark Pace Balzan]

Hi,

Ive done quite some reading about IPv6 NDP, exhaustion issues, Cisco First Hop Security etc...

To come straight to the point, Ive flooded various cisco platforms with ICMPv6 Echo Request to a directly connected /64 at ~40kpps to simulate remote NDP attack.

In all cases, "sh ipv6 ne stat" never showed me more than 513 Entries and High Water-Mark with of course many failed etc..

CPU increased a little bit, but the box didnt break at all and traffic through it was fine with no issues

I also understand that IOS will inherently limit the NDP/ARP requests as a protection mechanism, so I believe thats the reason for the 513 Entries I dont seem to exceed.

So the real question is:  If IOS seems to handle this pretty well, why is First Hop Security, Destination Guard etc... given so much importance ?

Do they address another issue, or is there something Im not seeing ?

cheers

Mark

[Andrew Yourtchenko]

Hi Mark,

Brute-force exhaustion of the ND cache on the router by the packets coming from the internet is only one facet of the issues covered by the First Hop Security functions - and even while it handles it relatively well, there can be conditions where it may not be a 100% solution given the load profile on the box.

Also consider a set of following issues, which are primarily limited to the same-link (hence the "first hop"):

- someone sending out an RA, making all clients to send the traffic that node.

- someone sending out an RA with different prefixes, making clients configure different addresses, and thus get filtered by the router or blackholed because there is no return route.

- someone sending a flood of RAs with random prefixes, crashing the clients that do not have the built in restrictions on the number of addresses they configure.

- someone responding to the DAD NS packets with Neighbor Advertisements - which means "this address is already in use" - with this approach you can effectively prevent the nodes on the segment to use IPv6.

- erroneous configuration on the newly introduced router, misconfiguring the hosts with a single RA.

- someone sending packets from a spoofed IPv6 address within the same subnet.

These are the issues that you can't tackle on the router. You need to do it on the switch. Pretty much like IPv4 first hop security features - ARP guard, DHCP guard, etc.

If you want to learn a bit more about FHS and the scenarios it covers, and have 1.5 hours of the time, you might want to go to http://ciscolive365.com, register (free), and search for BRKSEC-3003 session which is dedicated to First Hop Security.

Alternatively, you can watch a few demos on the youtube:

http://www.youtube.com/results?search_query=first+hop+security+getyourbuildon - they take about 15 minutes all together, but of course there is no surrounding theory.

Hopefully you find the above materials interesting - and if after looking at them you have additional questions, I'll be happy to answer them here!

--a

[Mark Pace Balzan]

Hi Andrew,

thanks for your reply - i have had a look at the sessions on cisco live already - great stuff btw, and probably need to go through them again at some point

few follow up questions:

1.  Considering a layer2 segment where im using static ipv6 addresses and ospfv3, and not using SLAAC or DHCPv6:

          - I believe rogue RAs and other RA issues you mention above are not really an issue in such case - ie with           static IPv6 and OSPF  ? 

          - even if intentionally or unintentionally sending out RAs in that segment with compromsing data inside ?  

          - or can DAD block a device from using a legit statically configured IPv6 address ?

2. For the NDP exhaustion issue we mention above (not the rogue RA issue), this is a potential issue on the Layer3 device filling up the cache. A layer2 only switch connecting such Layer 3 devices under attack does not need any attention here right ?  Layer2 needs attention for items like RA guard to define switchports as host or router to drop bad RAs, and not for NDP exhaustion ?

3. Is Destination Guard the solution to the remaining potential issues with NDP exhaustion ?

thanks for your time

Mark

[Andrew Yourtchenko]

Hi Mark,

cool, glad you liked the CL session stuff!

for (1):

- rogue RAs are indeed not an issue if it's only routers with static addresses and no endpoints.

- the DAD is indeed still a potential problem - if someone has the access to the segment *AND* the router reboots *AND* they reply to the DAD NS the router would not be able to use address (be it global or local).

Whether you want FHS in this case depends on the threat assessment for this particular setup - usually the router-only links are reasonably localized and isolated from physical intrusion. In the high security setup you might still use source-guard and static configuration of the binding table entries. Of course, it's additional overhead, so needs to be carefully evaluated whether the increased overhead is worth it.

for (2):

"it depends". e.g. consider this situation: a wireless user roaming on campus segment somewhere sending spoofed ICMPv6 echo packets to the router. You can argue that the router *may* try to handle the situation, but it might be simpler to limit the # of IPv6 addresses per host - and by the way WLC does have a hardcoded limit of 8 - so you'd need a standalone AP to try this out! By having a limit on the number of the addresses, you dramatically limit the damage from the particular client. Or if you talk a server segment with a lot of entries - the NUD (which by the way might need to be tuned in this case) needs some cycles too - and at some point router's handling alone might not be sufficient.

for (3):

yes, the destination guard allows to completely avoid the bogus ND traffic - because of the way the binding table is built, the assumption is that it represents the accurate picture of the network. Therefore if we need to perform ND, the node probably does not exist - so we can avoid it altogether. Of course, there's always a "but":

a) binding table is another collection of state, so e.g. if the switch is rebooted, then it might not correspond to the real situation on the network, which might result in longer unreachability times after the switch reboots.

b) again, being a collection of state, binding table needs to be limit-managed by itself. WLC does it for you, on IOS you need to define the limits manually. Otherwise a malicious node can fill up the table by itself.

We're preparing a page on docwiki.cisco.com which will discuss the FHS - and become an editable resource. I'll post the link here once we publish the "first version" of it.

--a

[Mark Pace Balzan]

Hi Andrew,

thanks - that clarifies a bunch of things !

so looks like in summary for ndp issues:

• box has some level of inbuilt protection but perhaps not sufficient in some cases
• we can specify 'ipv6 nd cache interface limit' to limit ndp cache size
• we can use destination guard for best protection which requires mantaining binding table

Thats great for IOS, IOS-XE, but cant find much reference to IOS-XR. do you have any pointers for this ?

cheers

Mark

[Andrew Yourtchenko]

Hi Mark,

yes, though again this is centered on the outside->LAN threats. For the case of a malicious host on the same LAN, router alone can not handle that, you need FHS.

For the IOS XR - given that the traditional application was routing, and the FHS is an L2 switching feature, currently there is no shipping code with FHS. If you have a good use case for it - certainly drop me a mail, will be happy to discuss!

--a

[Andrew Yourtchenko]

Related piece of info: we have published a page on docwiki at

http://docwiki.cisco.com/wiki/FHS to cover some (gradually more :-) of the aspects of the First Hop Security, feel free to have a look and tell us what you think!