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

[Owen DeLong]

On Mar 5, 2013, at 11:44 , Mark Smith <markzzzsmith at yahoo.com.au> wrote:

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

Bzzt... But thanks for playing.

IIRC, the oldest of the 512 gets tossed in favor of the newest one. However, if a (seemingly unsolicited) answer comes back, I think that result still gets cached.

> 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

I'll take a look, but what's wrong with what Cisco appears to be doing: Toss the oldest INCOMPLETE and accept (seemingly) gratuitous NAs?

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

In most circumstances (other than Universities), if the attacker is on your local LAN, you have already lost. DOS from NTE is among the least of your worries at that point.

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

Spoofing these is immune to the same problems how, exactly? Further, you have the issue of what happens if a router misses a node registration?

Seems to me that node registration would create more new problems than it would solve.

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

Sure, but I think the same mitigation techniques are likely to work as well.

Further, though I agree that these attacks are achievable and should be mitigated, the reality is that if you compare them to other attack vectors, they don't compare favorably. They have higher risk and lower reward.

Owen

> 
> 
> 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
>> 
> _______________________________________________
> Ipv6hackers mailing list
> Ipv6hackers at lists.si6networks.com
> http://lists.si6networks.com/listinfo/ipv6hackers