[ipv6hackers] (Remote) Neighbor Cache Exhaustion Attacks - Some Discussion

[Mark Smith]

Hi,


----- Original Message -----
> From: Enno Rey <erey at ernw.de>
> To: ipv6hackers at lists.si6networks.com
> Cc: 
> Sent: Tuesday, 5 March 2013 10:58 PM
> Subject: [ipv6hackers] (Remote) Neighbor Cache Exhaustion Attacks - Some Discussion
> 
> Hi,
> 
> I just build a small Cisco-based lab to verify if my (potentially flawed, 
> seriously) understanding of remote neighbor cache exhaustion attacks is correct.
> It seems that Cisco devices never store more than 512 INCOMPLETE entries in 
> their neighbor cache, regardless of the actual number of NS packets sent out 
> (and missing their respective NAs).
> 

I think that is still a Denial of Service attack, as new addresses on the target link can't be resolved, as their is no capacity for their legitimate INCOMPLETE entries. Not as severe as being able to exhaust the complete capacity of the neighbor cache though.

I have been working on a proposal to resort to a stateless form of neighbor (presence) discovery if there is evidence that a neighbor cache DoS attack appears to be occurring. I'd welcome feedback:

"Mitigating IPv6 Neighbor Discovery DoS Attack Using Stateless Neighbor Presence Discovery"
https://tools.ietf.org/html/draft-smith-6man-mitigate-nd-cache-dos-slnd-06



While working on this, I've also realised that it might be possible to launch the attack from the target link itself. The attacker sends out ICMPv6 echo requests with spoofed non-existent source addresses, and then the echo replies create the incomplete neighbor cache entries. BCP38 won't protect against that because the spoofed source addresses are from within legitimate prefix.

It may also be able to launch it using MLDv2 (and perhaps v1). MLDv2 (RFC3810) says that Reports must come from either the unspecified source address (::) or a valid link-local address. The :: source address Reports are ignored by routers, and are to update MLD snooping switches. The RFC doesn't say (or I haven't read enough of it yet) how to determine if the link-local address is valid, so I assume it means verification using the neighbor cache. In that case, it is also not clear if the link-local address is unknown, then neighbor presence discovery is to occur. If the latter is the case, then spoofed source address MLDv2 reports could be used to execute the Neighbor Cache DoS Attack.

Longer term, it seems to me the best option is to have a node registration protocol, so that routers know about the presence of their host neighbors from the time the neighbor attaches to the link. Unfortunately any of those options require changing both hosts and routers, so my thoughts are that what I've proposed is an interim mitigation that would only need changes to be made to routers. I think a simple registration protocol could be achieved by using MLDv2 (to discover existing nodes), ND DAD (to discover new nodes), Inverse ND (to acquire all addresses from the node once link-local is known), and ND NUD (to discover when the node disappears). I started working on that, but then realised that the above was probably more timely because it is an interim step. This would only require hosts to implement Inverse ND.

BTW, hosts are vulnerable to this DoS attack, where the host fills up it's own neighbor cache with bogus entries. On a single user host that would be a bit pointless, but if the host is supporting multiple users, or perhaps is acting as a router for guest virtual machines, it may be an effective attack.


Regards,
Mark.

> Can anybody confirm similar behavior for other vendors' L3 devices or 
> routers based on BSD/Linux/Solaris/whatever?
> I tend to conclude that the actual risk of remote NCE is exaggerated in some 
> circles, but I might have overlooked sth.
> Details as for the testing I did can be found here: 
> http://www.insinuator.net/2013/03/ipv6-neighbor-cache-exhaustion-attacks-risk-assessment-mitigation-strategies-part-1/.
> 
> Happy about any kind of feedback...
> 
> best
> 
> Enno
> 
> 
> 
> -- 
> Enno Rey
> 
> *****************     TROOPERS13    ******************
> ** International IT Security Conference & Workshops **
> ***  Coming Soon / Heidelberg, Germany             ***
> *****************  www.troopers.de  ******************
> 
> ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
> Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 174 3082474
> PGP FP 055F B3F3 FE9D 71DD C0D5  444E C611 033E 3296 1CC1
> 
> Handelsregister Mannheim: HRB 337135
> Geschaeftsfuehrer: Enno Rey
> 
> =======================================================
> Blog: www.insinuator.net || Conference: www.troopers.de
> =======================================================
> _______________________________________________
> Ipv6hackers mailing list
> Ipv6hackers at lists.si6networks.com
> http://lists.si6networks.com/listinfo/ipv6hackers
>