[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 <nordm...@sonic.net>
To: Mark ZZZ Smith <markzzzsm...@yahoo.com.au>
CC: Carsten Bormann <c...@tzi.org>, Samita Chakrabarti
<samita.chakraba...@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 <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
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
