[ipv6hackers] Status on NDP Exhaustion Attacks?

[Eric Vyncke (evyncke)]

NDP exhaustion from remote is a real threat indeed. Even with the 3 seconds time-out, anybody can scan at 50 kpps and honestly (see my affiliation) if routers were not implementing NDP throttling this would be a big mess. Years ago, a worm was aggressively scanning IPv4 address and it killed some routers... The industry has learned this lesson for IPv6 :-)

Firewalls are not really the best place to throttle packets to 'so many' destinations. The best place is to rate-limit NS at the last-hop router (some vendors do it at 100 per second for IPv6 again see my email address :-O).

IDS/IPS will do it too late because the target is the last hop router. SO, the only place where this should be implemented is the last hop router.

BTW, this also applies for IPv4 if the attached networks are wide such as 10.1/16 :-)

Hope this helps

-éric

> -----Original Message-----
> From: ipv6hackers-bounces at lists.si6networks.com [mailto:ipv6hackers-
> bounces at lists.si6networks.com] On Behalf Of Fred
> Sent: samedi 1 octobre 2011 17:08
> To: ipv6hackers at lists.si6networks.com
> Subject: Re: [ipv6hackers] Status on NDP Exhaustion Attacks?
> 
> 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 ?
> 
> TIA
> 
> Fred
> 
> 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....
> 
> 
> 
> RFC4861
>    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.
> 
> 
> _______________________________________________
> Ipv6hackers mailing list
> Ipv6hackers at lists.si6networks.com
> http://lists.si6networks.com/listinfo/ipv6hackers