Subject:
Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ?
From:
Philip Homburg <pch-v6...@u-1.phicoh.com>
Date:
Sun, 17 Jul 2011 15:37:00 +0200

To:
Mark Smith <i...@69706e6720323030352d30312d31340a.nosense.org>
CC:
ipv6@ietf.org, IPv6 Operations <v6...@ietf.org>

Precedence:
list
References:
<d4f95c5e-20a3-4b1e-8211-07b7831f3...@gmail.com> <5022da1a-2dad-412f-9742-0780389d8...@bogus.com> <e3161138-0caa-44e8-a329-e71408d0a...@gmail.com> <424d0613-0e51-48ce-aca9-8059d1071...@cisco.com> <20110717113237.0137a...@opy.nosense.org> <m1qin79-0001...@stereo.hq.phicoh.net> <a1924bc2-b42d-4a06-8122-abff325e1...@steffann.nl> <20110717215320.73e71...@opy.nosense.org> <20110717224840.574ab...@opy.nosense.org>
In-Reply-To:
Your message of "Sun, 17 Jul 2011 22:48:40 +0930 ." <20110717224840.574ab...@opy.nosense.org>
Message-ID:
<m1qirwn-0001...@stereo.hq.phicoh.net>
Message:
8


In your letter dated Sun, 17 Jul 2011 22:48:40 +0930 you wrote:
>Actually, that level of change might not be that necessary. If the
>destination address for the Duplicate Address Detection probes was
>changed to the all-nodes rather than the solicited nodes multicast
>address, then all receving nodes could immediately create a neighbor
>cache entry for the new device if one doesn't already exist. From that
>point on, Neighbor Unreachability Detection would then take care of
>maintaining the neighbor cache entry, and deleting it if the host
>disappears.

And then a router reboots. How does it find out about all the nodes already
there?


It's not just a router rebooting that's a problem: a temporarily split-brain L2 link (think spanning tree thrashing at the time when a node registers) could cause the same problem. There has to be some time related or event related (or both) trigger to refresh (not just when a L3 event like a node restart or interface up/down occurs).

Something has to give IMVHO, because AFAIK all of the current mitigation measures all rely on scarcity of either attacker or target addresses, which just isn't reality assuming mass-deployment of SLAAC.

How can you effectively (rate) filter if you can't tell good from bad?

I agree with Philip that there should be a number of options put on the table, and the various trade offs examined.

The conclusion might be that there needs to be various forms of ND, that are media dependent. Or small tweaks might help. Or it might be that the current compromise really is the best achievable. But let's see.

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

Reply via email to