On 01/28/10 03:49 AM, Mark Smith wrote:
Just to ensure we're on the same page, this checking of known Solicited
Node addresses would only be performed for Neighbor Solicitations
tiggered by traffic with off-link sources. Hosts within the subnet
would still be able to communicate with each other, even if the MLD
reports were lost.
Sure. But practically all hosts want to communicate off-link e.g. to
reach google.com.
A registration mechanism would definitely address this issue.
I think it is security issue unfortunately. All that is needed to
exploit it is a short script with a looping integer, standard IPv6
ping utility and low numbers of megabits of bandwidth to create
unanswered NSes in the 1000s.
But presumably a router would have some resource limits that can avoid
using up too much memory for incomplete neighbor cache entries. (If they
don't, perhaps the routers need a real OS ;-)
Are there any creative ways we can make the existing MLD mechanisms a
bit more robust, without having to change the protocols, and avoiding
changing the hosts (only having to change router code would be much
easier at this point in time I think)? Maybe something like when a
router responds to a RS, or issues it's periodic RAs, it also issues an
MLD general query to ensure it's Solicited Multicast address list is
kept accurate? Or possibly when a Router Solicitation is received, in
addition to responding with an RA, it also issues a Multicast Address
Specific query for the Solicited Node Address calculated from the
link-local address source of the RS?
If the router is actually aware of how much memory it is using for the
incomplete NCEs then it can have an adaptive mechanism based on a
threshold. Below the threshold nothing changes. If the number exceeds
the threshold it would look for the low order bits using 24 bit matches
against recorded MLD reports and 64 bit matches against existing NCEs.
If it is there no match, then just drop the packet. If there was a
temporary spike in the number of inactive NCEs pushing it above the
threshold, then the number will drop once those inactive NCEs time out,
at which point one can get through even to a host which didn't do the
MLD report.
Note that this requires the routers to remember the MLD state for the
link-local groups; currently routers don't need to do that. The MLD (and
IGMP) reports for link-local groups exist for the sole purpose of making
it easy to have MLD (and IGMP) snooping L2 devices.
* My understanding is that the Solicited Node address is created from
the bottom 24 bits of the IPv6 address, and then the lower 32 bits of
that Solicited Node address is copied into the Ethernet 33:33:
address.
Yes, I misremembered it as 32 bits.
Hmm - seems like there is still a 2^40 (or 2^39 if we discount the group
bit) of attack possibility with the MLD check.
If the attacker knows that there is a host with a particular address on
a subnet, then it can construct 2^40 other IPv6 address that map to the
same solicited-node multicast group. A ping to those addresses would,
even with all the above mechanisms, mean that the router would send the
NSes. Thus you still need a real OS in the router that can limit the
number of (incomplete) NCEs.
Erik
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
