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
