[ipv6hackers] Status on NDP Exhaustion Attacks?

[Owen DeLong]

On Sep 28, 2011, at 2:39 PM, Fernando Gont wrote:

> On 09/28/2011 02:16 PM, Owen DeLong wrote:
>>>>>>> * A possible additional improvement (which "violates the spec") could be
>>>>>>> that when an IPv6 address needs to be mapped to a MAC address, an NS is
>>>>>>> sent, but no entry is created in the NC... and you'd create an entry
>>>>>>> when receiving the corresponding NA (which would look as a "gratuitous
>>>>>>> NA", since you would not be keeping track of the NS you had sent in the
>>>>>>> first place)
>>>>>>> 
>>>>>> Since we're talking about security, wouldn't that basically open you up to NC
>>>>>> poisoning attacks where someone could inject a gratuitous NA for $IMPORTANT_HOST
>>>>>> and intercept it's traffic?
>>>>> 
>>>>> The aforementioned behavior does not affect any entries already present
>>>>> in the NC, and hence does not the vulnerability you describe any different.
>>>> 
>>>> Sure it does, it just means you have to get your gratuitous NA in ahead of the
>>>> real one.
>>> 
>>> How is this different from a normal NA-spoofing attack in which the
>>> target does not honour gratuitous NAs?
>> 
>> It's all about window of opportunity.
>> 
>> If it honors gratuitous NA, you can send your NA attack any time before it has
>> a proper NA from the real host, If it does not, then, you have to get in between
>> the NS and the real NA, which is a much smaller window.
> 
> Since NS messages are typically sent from time to time for the purpose
> of NUD, it's always possible to perform this sort of attack.
> 
An NS message for NUD is only sent after a neighbor has been discovered and
has an entry in the table.

In the case of these NS packets, you're still in a race with the actual host to
respond before it does.

> That said, you don't need to permanently enable the aforementioned
> behavior. i.e., you could enable it only when the number of entries in
> the NC reaches some threshold. *And* it would take effect only for *new*
> NC entries.
> 

Right, so, you want to make it easy for me to poison the NC by first
engaging in an NDT overflow attack.

I think the better approach is to deal with NDT overflow as follows:

1.	Operate as normal until the table is full.
2.	If a new NDT incomplete is needed, age out the oldest one.
3.	If an apparently gratuitous NA is received, send an NS and
	create a new incomplete entry with a flag indicating it is
	not to be aged prematurely. Give it a relatively short fuse,
	like 5-10 seconds to age naturally.

In this way, you at least reduce the reliability of the attack while
making it much harder to carry out without being easily detected
by an IDS/IPS or other monitoring.

I'm also inclined to believe it might be worth modifying the ND
code to send the initial NS for addresses that match the pattern:
^[^0][^0][^0].::....:..ff:fe..:....$ to the appropriate MAC as a MAC
layer unicast rather than MAC layer broadcast packet. (it would
still go to the IP layer solicited node multicast address.) In this
way, it might be harder for the attacker to time his cache
poisoning effort. Of course, if the node doesn't answer after
some time, you'll have to fall back to sending the broadcast
packet, but, for host addresses matching that pattern, this
should not happen, so, it should at least be very rare in the
real world.

Owen