Re: draft-halpern-6man-nd-pre-resolve-addr-00.txt

Ing-Wher Chen <ing-wher.chen@ericsson.com> Tue, 21 January 2014 00:09 UTC

Return-Path: <ing-wher.chen@ericsson.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69611A027B for <ipv6@ietfa.amsl.com>; Mon, 20 Jan 2014 16:09:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Pl4HnDjilPB for <ipv6@ietfa.amsl.com>; Mon, 20 Jan 2014 16:09:57 -0800 (PST)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id EB0A01A027D for <ipv6@ietf.org>; Mon, 20 Jan 2014 16:09:56 -0800 (PST)
X-AuditID: c618062d-b7f278e000005a8f-60-52ddbad1d11d
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id BD.D7.23183.1DABDD25; Tue, 21 Jan 2014 01:09:54 +0100 (CET)
Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0387.000; Mon, 20 Jan 2014 19:09:56 -0500
From: Ing-Wher Chen <ing-wher.chen@ericsson.com>
To: "ipv6@ietf.org" <ipv6@ietf.org>
Subject: Re: draft-halpern-6man-nd-pre-resolve-addr-00.txt
Thread-Topic: Re: draft-halpern-6man-nd-pre-resolve-addr-00.txt
Thread-Index: Ac8WO612+5i6/7LGRdax1VWN2uymEw==
Date: Tue, 21 Jan 2014 00:09:56 +0000
Message-ID: <BF6E0BD839774345977891C597F8B50C5D07E3@eusaamb109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.9]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrALMWRmVeSWpSXmKPExsUyuXRPuO6lXXeDDPo/MVm8PPueyYHRY8mS n0wBjFFcNimpOZllqUX6dglcGa8mvWErmC1S8W1qL1MD4xyBLkZODgkBE4kDu16zQdhiEhfu rQeyuTiEBI4wSrxsfgTlLGeUePpnKjNIFZuAgcSGj1uYQGwRAWWJGd3nwLqFBawlWvd/YYWI O0i8ObyQBcLWk5j58BdYnEVAFWjDCrA4r4C3REd7IyOIzQi0+fupNWAzmQXEJW49mc8EcZGA xJI955khbFGJl4//sULYihL7+qezQ9TrSCzY/YkNwtaWWLbwNTPEfEGJkzOfsExgFJ6FZOws JC2zkLTMQtKygJFlFSNHaXFqWW66kcEmRmAoH5Ng093BuOel5SFGaQ4WJXHeL2+dg4QE0hNL UrNTUwtSi+KLSnNSiw8xMnFwSjUwrl1hdlPkIP+67DdOBZLuH9jXFEy9UF+cr8nT+iNNQPvs f+P5OQJFpQf/HGfqixZfeMMxw56F8eZ1kyeXjF7bLku4yuo/Memnr8MjFa3LSbYxp1av1vMP Fj2n3StTFtrSYrY9df2Txckdm+Zz15169CFSJbP5LlPW1EeqR3YuNz506XWZntItJZbijERD Leai4kQA/e87ETMCAAA=
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jan 2014 00:09:59 -0000

> -----Original Message-----
> From: Erik Nordmark [mailto:nordmark@acm.org]
> Sent: Friday, January 17, 2014 9:02 PM
> To: Greg Daley; Ing-Wher Chen; ipv6@ietf.org
> Subject: Re: New Version Notification for draft-halpern-6man-nd-pre- 
> resolve-addr-00.txt
>  ...
> In addition to your concern about multicast snooping environments, the 
> DAD packets are not reliably delivered. If e.g. there is a short WiFi 
> drop, the spanning tree is reconverging, etc then the single 
> transmitted DAD packet will not be received.

No ND packets are reliably delivered.  So this is not different from any other ND traffic.

> Thus as best this will collect some entries in the neighbor cache.

We agree that the approach in the draft might not capture all neighbors.
However, when a router is under an off-link attack, having this additional
source of target addresses will mean that the router can continue to service
new hosts, as it sees them.  The alternative, without the approach in the draft,
is that the router does not service any additional new hosts, starting from
the time the router is under attack.  (The DAD-NS approach can be seen as a
heuristic to distinguish legitimate target addresses from invalid target addresses.)  

In short, using the approach in the draft will yield a better result than not using it.
Since DOS attacks are impossible to prevent in the general case, all that can be
done -- by any mechanism -- is to reduce the impact of such attacks.  This approach
does reduce the impact of such attacks.

> It isn't at all clear when a node should discard entries from its 
> neighbor cache. That is potentially problematic when there are lots of 
> devices that pick new temporary IPv6 addresses each time they power on 
> since that will force routers to sooner or later discard entries from 
> the neighbor cache. The routers would have to guess which addresses 
> might still be assigned to the hosts.

We rely on Neighbor Unreachability Detection to remove stale neighbors, as specified
by the existing IETF ND standards.  We believe the standards make this clear.  We are
happy to cite the existing ND standards in this area (NUD to remove stale neighbors)
more explicitly in a future version of this draft.

> Thus all in all this is not a robust approach to the problem.

There is no perfect solution to a DOS attack.  This method yields better results than
not using this method, reducing the severity of the attack in a measurable way.

Thanks,
Helen