This presentation provides background information to the problems and provides insight into mitigations.

1. IPv6 Neighbor Discovery Problems
(and mitigations)
Joel Jaeggli
For BaJUG
October 2012
1

2. 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

3. 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

4. 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.

5. 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.
5

6. 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

7. 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.
7

8. 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

9. 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

10. 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

11. 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.
 http://www.juniper.net/techpubs/en_US/junos12.2/information-products/pathway-pages/config-guide-routing/config-guide-routing-neighbor-discovery.pdf
11

12. 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