IPv6 Neighbor Discovery Problems (and mitigations) Joel Jaeggli For BaJUG October 2012 1
Background IPv4 subnets typically span rather small address ranges. In IPv6 however the default subnet size is a /64. As a result implementations of the Neighbor Discovery Protocol, which replaces the functionality of IPv4 ARP are typically vulnerable to deliberate or accidental denial of service due to the large address span. Myself plus colleagues from Yahoo Google and elsewhere saw this as enoguh of a problem to put pen to paper. 2
Background continued Result: – RFC 6583 Operational Neighbor Discovery Problems Work in progress – draft-ietf-6man-impatient-nud-02 – draft-gashinsky-6man-v6nd-enhance-01 3
Nature of the problem
Simplistic implementations of Neighbor Discovery may fail to perform as desired when they perform address resolution of large numbers of unassigned addresses.
Failures can be triggered either: – intentionally by an attacker launching a denial-of- service attack (DoS) – Unintentionally due to the use of legitimate operational tools that scan networks for inventory and other purposes. – e.g. a couple of instances of the equivalent of nmap -sn -6 2001:DB8::/64 (nmap doesn't support masks on v6 address) starting at different offsets is enough to blow up the NDP 4 process on plently of existing routers.
What causes this? The router's process of testing (RFC 4861) for the (non)existence of neighbors can induce a denial-of-service condition, where: – The number of necessary Neighbor Discovery requests overwhelms the implementation's capacity to process them. – Exhausts available memory. – And/or replaces existing in-use mappings with incomplete entries that will never be completed.
Continued When a packet arrives at (or is generated by) a router for a destination on an attached link, the router needs to determine the correct link-layer address to use in the destination field of the Layer 2 encapsulation. The router checks the Neighbor Cache for an existing Neighbor Cache Entry for the neighbor. If none exists, the router invokes the address resolution portions of the IPv6 Neighbor Discovery protocol to determine the link-layer address of the neighbor. 6
What can be done about this? Implementation and protocol changes are possible and several implementations have been tweaked to good effect... Some techniques are suitable for hardening networks that provide public facing internet services that are not in fact feasible elsewhere. – e.g. subnets where SLAAC, Privacy addresses and so forth are required are not good candidates for these mitigations.
Operational Mitigations. Filter unused space. – Have a /64 subnet, but assigning addresses using stateful dhcpv6 (or static). Apply an ACL limiting access to only the address range in use. – A /120 or even something as large as a /112 is a dramatic reduction in surface area. – Means you're not using SLAAC or privacy addresses. 8
Continued. Use genuinely smaller subnets. – RFC 6164 says we can use /127 for point-to- point links. – If SLAAC is not required either because devices are statically or programmaticaly configured prefixes longer than a /64 can be used. – Example load-balancer tier using /120 sized subnet. 9
Routing mitigation Limit which subnets appear in the FIB of upstream routers such that only more specific routes injected by the hosts using EBGP appear in the routing table. – Example a load balancer tier which inject's /128 prefixes into upstream router(s) routing table. – This is analogous to the IPv4 approach of using private address space to number the subnet in front of a public service. 10
Router knobs. The most dire condition when dealing with NDP related resource starvation is losing track of existing peers. If you have the knob available (and Junos does) you can allow the interval that you'll continue to consider a node reachable once NUD kicks off to be longer than the default (which is 0) This will help in degenerate circumstances from losing track of existing neighbors.
Limitations. None of these mitigations is a general purpose solution. /64 subnets are still required in many circumstances. Hardening public facing infrastructure was really our principle consideration for undertaking this work. Longer term implementors have a pretty good idea how to address the business as usual interal cases. 12