RE: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt

Greg Daley <> Thu, 23 January 2014 22:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 185B31A0182 for <>; Thu, 23 Jan 2014 14:56:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.442
X-Spam-Status: No, score=-1.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PpIXYdf14mC5 for <>; Thu, 23 Jan 2014 14:56:54 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B2D4B1A00B6 for <>; Thu, 23 Jan 2014 14:56:53 -0800 (PST)
Received-SPF: None ( no sender authenticity information available from domain of identity=mailfrom; client-ip=;; envelope-from=""; x-sender=""; x-conformance=spf_only
Received-SPF: None ( no sender authenticity information available from domain of identity=helo; client-ip=;; envelope-from=""; x-sender=""; x-conformance=spf_only
Received: from unknown (HELO ([]) by with ESMTP; 24 Jan 2014 10:03:05 +1100
Received: from ([]) by ([fe80::68b7:8880:fefb:f742%12]) with mapi id 14.02.0347.000; Fri, 24 Jan 2014 09:56:51 +1100
From: Greg Daley <>
To: 'Mark ZZZ Smith' <>, 'Ing-Wher Chen' <>, "" <>
Subject: RE: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt
Thread-Topic: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt
Date: Thu, 23 Jan 2014 22:56:50 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US, en-AU
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Jan 2014 22:56:56 -0000

Hi Mark, 

I guess it is for others to identify if the protection is sufficient, I would just like to show that there is a feasible mitigation with MLD.


>> Unless the router maintains additional ND cache state, it cannot 
>> distinguish between an activated group and which of the addresses is 
>> active, and thus a subset of the addresses (e.g. the globally routable 
>> equivalent of a Link-local address with a particular solicited nodes 
>> [and anything with the same IID lower order bits]).

> True. The presence of a solicited-node group on a link only indicates at least one of the addresses that would map to it is present.

>> Is this sufficient protection, or does there have to be more specific 
>> state gathered in the ND cache, perhaps through the discussed draft?

> I see this idea as another quite useful mitigation, but certainly not a prevention of the ND cache DoS attack.

> As the number of present solicited-node groups is very unlikely to ever exceed 1% of the total available solicited-node groups (2^24/16M), that means
> that NSes don't have to be performed for destination addresses that map the the remaining 99% of solicited-node groups. This is in comparison to
> today where NSes would be performed for any unknown destination within the /64. I think that would be another measure that usefully reduces the
> effectiveness of the off-link ND cache DoS attack against a router. Less predictable solicited-node groups, as a result of
> draft-ietf-6man-stable-privacy-addresses, would further reduce the effectiveness of the off-link ND cache DoS.

> I though of this idea while thinking about how MLD/solicited-node group membership might be able used to facilitate node registration, preventing
> the router ND cache DoS attack. It previously occurred to me that if nodes are using MLDv2, meaning that all nodes report their membership of all
> groups, then routers tracking solicited-node membership would now have knowledge of one of all of the attached nodes' link-local addresses (either as
> the nodes initialise their addresses, or because a router initiates a querier election when it initialises) . If the nodes then supported Inverse ND+,
> then the routers could query the nodes for their other addresses, giving them complete knowledge of all unicast addresses on all nodes, achieving
> complete node registration. NUD would then take care of expiring node registrations when the nodes disappear. 

I think that the value principally comes from the mandatory nature of MLD (though in MLDv1, a node can fail to transmit a report IFF there is another member of the group that has visibly reported - which activates the group anyway).

Additional information is probably extraneous and is limited by the fact that devices may not have implemented particular capabilities (i.e. they are not required by the Node Requirements RFC6434)

Greg Daley