[ipv6hackers] Status on NDP Exhaustion Attacks?

Fred fred at fredbovy.Com
Sat Oct 1 17:08:08 CEST 2011

Hi List,

By advance I apologize if the answer was already provided since I jump in this
discussion after a lot of Q&A...

I am just curious about the real potential of such attack.

When a resolution is performed with ND default values, a ND entry is created in
the state INCOMPLETE and a NS is sent. If no NA reply is received after
RetransTimer milliseconds (default: 1 second) it should then retransmit a NS
maximum MAX_MULTICAST_SOLICIT (default: 3) times. Then the entry is cleared from
the cache.

So the entry will not stay in the table more than 3 seconds before it is cleared.

For sure if an attacker keep on scanning, it will fill the table faster than the
table will be purged. But it will take some time to create a fill up the table
and the attack must be quite continuous without interruption or entries will be
deleted automatically. 

This means that is should not be difficult to detect and to isolate the attacker.

If it comes from the outside it must pass firewalls which should be able to
manage this and take appropriate action at least to mitigate so it will not be
able to do much harm if it cannot block it.

If it is local, an IDS capable of detecting port scan and other attacks should
also be able to isolate the attacker.

So is it really such a big threat ?



PS: one more time, if SEND was not only implemented by CISCO, Linux and I have
read something about a WinSEND which gives me hope....

   While awaiting a response, the sender SHOULD retransmit Neighbor
   Solicitation messages approximately every RetransTimer milliseconds,
   even in the absence of additional traffic to the neighbor.
   Retransmissions MUST be rate-limited to at most one solicitation per
   neighbor every RetransTimer milliseconds.

   If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT
   solicitations, address resolution has failed.  The sender MUST return
   ICMP destination unreachable indications with code 3 (Address
   Unreachable) for each packet queued awaiting address resolution.

More information about the Ipv6hackers mailing list