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

Mark ZZZ Smith <> Wed, 22 January 2014 08:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B670C1A02A4 for <>; Wed, 22 Jan 2014 00:33:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.201
X-Spam-Level: **
X-Spam-Status: No, score=2.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lAcE2GKq5Qch for <>; Wed, 22 Jan 2014 00:33:09 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 76BEE1A007B for <>; Wed, 22 Jan 2014 00:33:09 -0800 (PST)
Received: from [] by with NNFMP; 22 Jan 2014 08:33:08 -0000
Received: from [] by with NNFMP; 22 Jan 2014 08:33:08 -0000
Received: from [] by with NNFMP; 22 Jan 2014 08:33:08 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 5968 invoked by uid 60001); 22 Jan 2014 08:33:08 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1390379588; bh=WXTzASW5IKg8hAhHKNOfvlnzuNgLHvyadNCWdrOvLw8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=YcXzJA2rTK22n/OeSJXn5lSg6VQVWp9tUpFpZKs9TM9bQ7uSM+qup9tNPp99r5HfwAwnUtIpwrf8URw2Ko68XBCt8KxKP9JmYcptBH64E+NDF2u/xBB3eVvvzC0rHp8L82Gl0eTHdMmfDqEeFo4Z9xrl/GPvxnEKrkQs2fcRqDA=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=PVpWiYfefcWCIBJRr7fA+G9xpAPifytLOjynf0JsMKTzKSQ4Vp1q3mtf1Px77f3bFL/GzsrCvR6Stz4W+yWJ3eorj3hCeSFLObGyojVpZLOlI0fJXOvgDmwqQWSQLWyv4KzhAuonGICQ6+LKt85k4u0V/q2jf9cRhpEmW1wkWJ0=;
X-YMail-OSG: i7_T3o4VM1lHZ9OymUSMIVZOdSOxOuWIyEhlbkUT3Uglh8F NbIkm4xPXiH03mzw7C6x2TjvGpp3tIAmXu436H83L56HNVJJnl59qM0h2evY RgF2gr_2KegAycFDdC9ACl4mf9DB8YFE60YZoexGjvgalYFAGHhU.FegVzZm oKKYp.LrgrA74LC.mFpf3Iay13RoAfgnnPBTioqMOpOLqVaZc40d_wK6FLXL 0CWmvlSYSMbNXVqJSkUqnSQ_798fXQk9RSS6I32PLRzwYPI7jvy32.Q435I0 cPcpt5wA6l1M5gk9E5E40qv8mfyH4rySNC134yNriCotX7uhsjphhqe6u8O4 s5syYbDmwHumSQ8Iugb1KLaSIYiO11tcjN.pS6m8DVWkmQ0NXSBPkJWdMMav uOmYeEk6NqOqu1m4O4g3YofdOMyRgywfl445U26JaGXrmJKhgIpJ7.ylGiNA N3ogX5nVlwMDPs4CtiYKycMOqsef65z3rSkf.tf8GFgR8mWW1tZeQVoRjHH3 _tzktvqPVynrcauAi3vE4Sl7NaptTzWXF6isaxloLPuLzFYw47OjNfkugJLJ Z9xMDHSOKg332CTUBdAyPCMS9
Received: from [] by via HTTP; Wed, 22 Jan 2014 00:33:08 PST
X-Rocket-MIMEInfo: 002.001, SGkgR3JlZywKCgotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gRnJvbTogR3JlZyBEYWxleSA8Z2RhbGV5QGF1LmxvZ2ljYWxpcy5jb20.Cj4gVG86ICdNYXJrIFpaWiBTbWl0aCcgPG1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU.OyAnSW5nLVdoZXIgQ2hlbicgPGluZy13aGVyLmNoZW5AZXJpY3Nzb24uY29tPjsgImlwdjZAaWV0Zi5vcmciIDxpcHY2QGlldGYub3JnPgo.IENjOiAKPiBTZW50OiBNb25kYXksIDIwIEphbnVhcnkgMjAxNCA5OjUwIEFNCj4gU3ViamVjdDogUkU6IE5ldyBWZXJzaW9uIE4BMAEBAQE-
X-Mailer: YahooMailWebService/
References: <> <> <> <> <>
Message-ID: <>
Date: Wed, 22 Jan 2014 00:33:08 -0800
From: Mark ZZZ Smith <>
Subject: Re: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt
To: Greg Daley <>, 'Ing-Wher Chen' <>, "" <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Mark ZZZ Smith <>
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Jan 2014 08:33:11 -0000

Hi Greg,

----- Original Message -----
> From: Greg Daley <>
> To: 'Mark ZZZ Smith' <>; 'Ing-Wher Chen' <>; "" <>
> Cc: 
> Sent: Monday, 20 January 2014 9:50 AM
> Subject: RE: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt
> Hi Mark, 
> When we were looking at accelerating DAD for mobile nodes a while ago, I 
> investigated the state held by MLD and wrote a draft.
> (Now expired
> A much better solution was found (now RFC 4429), but the consistent state 
> keeping by the MLD querier (and other routers) is still present (particularly 
> for MLDv2).
> (I am now thinking out loud, so please bear with me)
> The difference is that the solicited nodes' address was not identical to an 
> address binding and that (after listener state synchronization) only the 
> non-presence of an MLD listener on the solicited nodes address could be used to 
> prove the address was absent.  For relatively sparse links and subnets this 
> would allow the router to state explicitly that the address was not in use.
> For ND cache protection, the presence of any MLD listener on the solicited 
> nodes' activates the group, and no-listeners means there isn't even a 
> reason to transmit the neighbour solicitation.


> 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. 

This method wouldn't achieve the efficiency goals of draft-chakrabarti-nordmark-6man-efficient-nd. I think its value would be that it leverages existing mechanisms such as MLDv2 and Inverse ND, and would have a relatively low implementation cost.


+  or perhaps RFC4620 Node Information Queries, although I think Inverse ND might be better because it is likely to be simpler to implement, and isn't Experimental.

> Sincerely, 
> Greg Daley
> -----Original Message-----
> From: Mark ZZZ Smith [] 
> Sent: Saturday, 18 January 2014 7:58 PM
> To: Greg Daley; 'Ing-Wher Chen';
> Subject: Re: New Version Notification for 
> draft-halpern-6man-nd-pre-resolve-addr-00.txt
> ----- Original Message -----
>>  From: Greg Daley <>
>>  To: 'Ing-Wher Chen' <>; 
> "" 
>>  <>
>>  Cc: 
>>  Sent: Friday, 17 January 2014 1:14 PM
>>  Subject: RE: New Version Notification for 
>>  draft-halpern-6man-nd-pre-resolve-addr-00.txt
>>  Hi Helen,
> <snip>
>>  3/ Monitor the solicited nodes' addresses in the MLD querier router, 
>>  and do not transmit an NS from off-link for an incomplete address 
>>  unless someone is listening.
> So I've been thinking for the last few months that this method could be a 
> useful further mitigation to off-link ND cache attacks for routers. I've 
> been writing something up which I've been planning to finish and post in the 
> next week or so.
> I think it could be fairly effective - there are a total possible 2^24 
> solicited-node multicast groups on a link, where as there will only be as many 
> present ones as there are IIDs with unique lower 24 bits. For most subnets I 
> think that will number in the order of 10s or 100s, and perhaps on rare 
> occasions in the low 1000s. So NSes would only be necessary for e.g. 1000/2^24 
> portion of the unicast address space, otherwise the packets that would trigger 
> them can be dropped (or perhaps sent to an RFC6018 greynet collector).
> A neighbor cache attack is likely to be still be possible for the 2^40 portions 
> of unicast address space covered by each of the the present solicited-multicast 
> groups, however Fernando's Stable/Opaque IID draft would make them harder to 
> find, even though it will increase the number of them, as there is an unique 
> Opaque IID per prefix.
> All routers listening to MLD track group membership, not just the MLD querier, 
> so all routers on the link could implement this method.
> Regards,
> Mark.