Hi,

----- Original Message -----
> From: Carsten Bormann <c...@tzi.org>
> To: Samita Chakrabarti <samita.chakraba...@ericsson.com>
> Cc: 6man Mailing List <ipv6@ietf.org>
> Sent: Friday, 12 October 2012 5:23 PM
> Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt
> 
>T wo quick comments:
> 
<snip> 

> Clearly, mitigating the external ND table DoS is one of the major pain points 
> addressed by this.  Thinking point: Is there any way to structure the 
> transition 
> from legacy ND to efficient ND in such a way that it becomes easier to reap 
> this 
> benefit?
>
 
I've been thinking about a registration protocol recently, which would have
leveraged the MLDv2 election process at router interface connection  to
discover existing nodes' link local addresses, Inverse Neighbor Discovery
to query the nodes' for their other addresses (other LLs, ULAs, GUAs),
DAD to detect new nodes/addresses, and NUD to detect when nodes/addresses
disappear. The drawback as you indirectly point out is that it requires
all nodes to support the registration protocol before it can be enabled
and the DoS mitigated. So I worked on the following draft first, which
I think mitigates the DoS for routers, and only requires changes to
routers' neighbor discovery operation:

"Mitigating IPv6 Router Neighbor Cache DoS Using Stateless Neighbor Discovery"

http://tools.ietf.org/search/draft-smith-6man-mitigate-nd-cache-dos-slnd-00

I've got a new update nearly finished, which I'll post later today.

I definitely think a registration protocol is necessary. While working on
the above draft, I realised that on-link sources can also cause the off-link
neighbor cache DoS, by using spoofed non-existent source addresses from
within the local subnet, and sending that traffic to a remote host that
sends replies back (e.g. lots of spoofed source addressed outgoing TCP SYNs, 
reply
TCP SYN/ACKs would cause the neighbor cache DoS attack on the router). A
registration protocol would allow individual address-based rather than just 
prefix level
BCP38 protection, because routers now know exactly what devices exist
on-link, and can therefore drop traffic with spoofed local subnet source 
addresses.

Regards,
Mark.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to