On 01/26/10 11:44 PM, Mark Smith wrote:
This issue isn't specific to point-to-point links. Any /64 is
vulnerable. People who're advocating longer than /64s for
point-to-point links as a mitigation for this issue can also advocate
using prefix lengths longer than /64 for all IPv6 subnets.
As I'm an advocate for the simplicity of using /64s for all links, I've
been thinking how this issue could be avoided, without having to resort
to longer than /64s, or other manual methods such as traffic filtering
ACLs or static neighbor discovery entries.
At the end of the description of the issue, RFC3756 mentions
"This attack does not directly involve the trust models presented.
However, if access to the link is restricted to registered nodes, and
the access router keeps track of nodes that have registered for access
on the link, the attack may be trivially plugged. However, no such
mechanisms are currently standardized."
I think Multicast Listener Discovery announcements for hosts'
memberships of the Solicited Node multicast addresses could be used as
this "membership registration" mechanism. When a router is asked
to issue a neighbor solicitation for a downstream host, after it
converts the destination address into a Solicited Node multicast
address, is could then validate that multicast address against a list
of known Solicited Node multicast addresses it has learned from the
hosts via their MLD announcements. Neighbor Solications for Solicited
Node multicast addresses that aren't known would be dropped, preventing
off-link nodes from exhausting the router's neighbor discovery
resources.
Do people think using MLD announcements in this way would be suitable
way to mitigate this DoS while preserving the simplicity of
universal /64s?
The "join delay" for MLD is unpredictable since the reliability of the
MLD reports is based on a few initial ones (which could all be lost)
plus router-triggered slow rate MLD queries. That join delay doesn't
seem to cause a problem for today's multicast applications, but I would
be quite concerned if the host couldn't communicate at all during this
delay, which would be the effect of your proposal.
I think the correct thing architecturally is to actually introduce a
reliable "registration" mechanism for hosts. There are other good
reasons for it such as avoiding low-power devices being woken up by
multicast NS messages especially when the L2 uses broadcast to deliver
multicast packets. (Work in 6lowpan has explored this space, but I don't
think draft-ietf-6lowpan-nd is quite what we need.)
If this is construed as a security issue one can probably come up with
combinations of MLD and also the routers hearing the hosts (which they
do if the hosts send RSs as they power on) that could minimize the
probability of hosts being unreachable during the MLD join delay even if
the MLD reports are lost. But I view that as a short-term approach which
needs to be replaced by a registration mechanism.
Note that the RSs don't list all the hosts' IP addresses - the source is
a link-local address. Thus the logic in the router needs to be able to
compare just N low order bits. If a RS has been send from link local
fe80::0:1:2:3 then the router needs to be able to send NSs for anything
in Prefix::0:1:2:3. Listening to the MLD has a similar property since
the solicited-node multicast address is just a match on the bottom 32
bits of the IPv6 address.
Erik
Regards,
Mark.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
