Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04

Ole Troan <otroan@employees.org> Thu, 09 January 2014 09:38 UTC

Return-Path: <otroan@employees.org>
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 7DE961AE157 for <ipv6@ietfa.amsl.com>; Thu, 9 Jan 2014 01:38:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no
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 iFDcRTu7beoQ for <ipv6@ietfa.amsl.com>; Thu, 9 Jan 2014 01:38:34 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 549A91AE160 for <ipv6@ietf.org>; Thu, 9 Jan 2014 01:38:29 -0800 (PST)
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAIttzlKQ/khL/2dsb2JhbABZgws4uhqBDRZ0giUBAQECAQF5BQsLDgouVwYTGwOHXggNxHoXjwUHgySBEwSQM5l5gy47
X-IronPort-AV: E=Sophos; i="4.95,630,1384300800"; d="asc'?scan'208"; a="3376606"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 09 Jan 2014 09:38:19 +0000
Received: from dhcp-lys02-vla252-10-147-116-56.cisco.com (dhcp-lys02-vla252-10-147-116-56.cisco.com [10.147.116.56]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s099cH2o027322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jan 2014 09:38:18 GMT
Content-Type: multipart/signed; boundary="Apple-Mail=_94E8FEDD-DE7E-42FA-9044-CB664383ECB3"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04
From: Ole Troan <otroan@employees.org>
In-Reply-To: <alpine.DEB.2.02.1401090853090.20074@uplift.swm.pp.se>
Date: Thu, 09 Jan 2014 10:38:16 +0100
Message-Id: <27F0E5E5-50C1-4B92-AA4F-A849BA10FC9C@employees.org>
References: <1F653502-AD41-4EB6-A43D-541356810DF2@employees.org> <CAKD1Yr1XPKibHenLMcNDRnfCht6X8tF2nMq1HgOiQv6eR9m6Yg@mail.gmail.com> <alpine.DEB.2.02.1401081305120.20074@uplift.swm.pp.se> <CAKD1Yr2AtF1CMqFxE1W63tXrS5OsbhJGfktN=sAaZtsBOSVg2Q@mail.gmail.com> <alpine.DEB.2.02.1401090707580.20074@uplift.swm.pp.se> <CAKD1Yr2yjPOWWHBx5dzwhNCT8fx9SEQg1wbPgGJSN3aS5bg5tg@mail.gmail.com> <alpine.DEB.2.02.1401090803040.20074@uplift.swm.pp.se> <CAKD1Yr25XJejF7sdHE2ycpcHNSyq=07+mKeLdj338=-LvsME-Q@mail.gmail.com> <alpine.DEB.2.02.1401090853090.20074@uplift.swm.pp.se>
To: Mikael Abrahamsson <swmike@swm.pp.se>
X-Mailer: Apple Mail (2.1827)
Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG <ipv6@ietf.org>
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: Thu, 09 Jan 2014 09:38:35 -0000

On 09 Jan 2014, at 8:57 , Mikael Abrahamsson <swmike@swm.pp.se> wrote:

> On Thu, 9 Jan 2014, Lorenzo Colitti wrote:
> 
>> Why not? What's the downside of sending out an NS for an address that's not there? You consume an ND cache slot for the incomplete entry, but if you use the optimizations you'll always have enough space to avoid a DoS scenario.
> 
> Because potentially this would cause hundreds or thousands of NS multicast packets on the LAN per second in a ddos scenario?
> 
> If we can avoid the router having to learn anything by means of external packet triggers, I think it would be a big win.

a game of whac-a-mole? ;-)
at least you have a new set of problems that needs to be solved.

- how is state maintained on the first-hop router(s)?
  how does the host detect that the first-hop router has lost state?
  how do you synchronize state between the set of routers on the link?
- while ND classic scales by the number of active addresses on the link,
  you'll now scale by the total number of addresses on the link
- how do routers garbage collect? i.e. how do routers detect that an address is no longer in use, 
  the node has left the link?

as Lorenzo stated I believe the external DOS attacks on the ND cache can be mostly mitigated
by a good implementation. prioritising the active speakers, rate-limiting the number of request per second,
use a circular buffer and so on. it wouldn't be completely unexpected if there was some level of
stateful or stateless filtering being done on the borders stopping these forms of attacks either.

that said, vendors do implement snooping solutions e.g. 
http://www.cisco.com/en/US/docs/ios-xml/ios/ipv6_fhsec/configuration/xe-3s/ip6f-xe-3s-book.pdf
(not touting cisco's solution here, I'm sure all the other vendors have similar, but it was the
first I found). 

that use ND and DHCP snooping to maintain a stateful table on the first-hop routers and switches.
address registration may make such solutions easier to implement.

cheers,
Ole