Fwd: Re: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt

[I don't know if this made it to the list]

-------- Original Message --------
Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt
Date: Thu, 01 Nov 2012 14:18:07 -0700
From: Erik Nordmark <nordmark@sonic.net>
To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
CC: Carsten Bormann <cabo@tzi.org>,        Samita Chakrabarti 
<samita.chakrabarti@ericsson.com>,        6man Mailing List <ipv6@ietf.org>

Mark,

We started working on a registration mechanisms (initially scoped for
6lowpan) back at IETF 72 in Dublin. The result of that is
draft-ietf-6lowpan-nd (which is undergoing final edits at the rfc-editor
as we speak).

However, since that was targeting a homogenous 6lowpan where all hosts
and routers do the 6lowpan-nd optimizations.
Thus 6man-efficient-nd is exploring how to handle incremental
introduction of the Address Registration Option to existing IPv6 links,
resulting in mixed-mode operation.

In terms of the ND DoS concerns you might also want to look at RFC 6583,
draft-gashinsky-6man-v6nd-enhance-02.txt, and
draft-ietf-6man-impatient-nud-05.txt.

Regards,
    Erik

  is also
On 10/12/12 4:41 PM, Mark ZZZ Smith wrote:
> Hi,
>
>
> ----- Original Message -----
>> From: Carsten Bormann <cabo@tzi.org>
>> To: Samita Chakrabarti <samita.chakrabarti@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
> --------------------------------------------------------------------
>