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:
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 ?
- 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.
"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.
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.
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!
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts The ProblemOn traditional
switches whenever we have a trunk interface we use the VLAN tag to
demultiplex the VLANs. The switch needs to determine which MAC ...
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts Introduction: Netdr is a tool
available on a RSP720, Sup720 or Sup32 that allows one to capture
packets on the RP or SP inband. The netdr command can be use...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...