RE: [EXTERNAL] Re: Improving ND security

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Fri, 31 July 2020 22:13 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 544BD3A0C78; Fri, 31 Jul 2020 15:13:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com
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 31I96VmFcF6R; Fri, 31 Jul 2020 15:13:17 -0700 (PDT)
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B5543A0C68; Fri, 31 Jul 2020 15:13:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 06VMDDbu008008; Fri, 31 Jul 2020 18:13:13 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1596233593; bh=f8+ayfROWdmq4rdE0+JGz8/wI+mJQP1EG5L/68paT6Q=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=HWNbTxAnbvqLV3ap8M2gvsAueb9FbIQpQ3CGyY30S9Atzwx1hEOYZB0Dbn2Y/gmJp bKiuWjsQOpy0An3OsehhVoW/FJR5lVkz4iYZzmHOs8iuA6+a2hZKcdsyaIdG86SBkJ ot18G4TUN1Ac2RPJ2hQvY+s5dsvsQnjEYyDlCcuP6h7InMplu7JIYRuEMQ7F3J00Up tgkwkC2YaPDnX55HRtvwg3c0jtTNMUSeNnc+7HevtUYcuVi1FCA6spPqnHVZVOeTF9 0y7xVlkKIwsBxLXuMk1OHL30M3jCowu9x9ElGx3y+P5jA5ECw+7p/P315Zwyb4i2NF vpQAFnm85NQ+A==
Received: from XCH16-07-09.nos.boeing.com (xch16-07-09.nos.boeing.com [144.115.66.111]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 06VMD6Dk006965 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 31 Jul 2020 18:13:06 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-09.nos.boeing.com (144.115.66.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1979.3; Fri, 31 Jul 2020 15:13:05 -0700
Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.1979.003; Fri, 31 Jul 2020 15:13:05 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
CC: Ted Lemon <mellon@fugue.com>, v6ops list <v6ops@ietf.org>, 6man <ipv6@ietf.org>
Subject: RE: [EXTERNAL] Re: Improving ND security
Thread-Topic: [EXTERNAL] Re: Improving ND security
Thread-Index: AdZnYGykJNK1kk2zSneWe05yLDtm6gAO/XoAAA6T6+D//9BAgIAAcUNg
Date: Fri, 31 Jul 2020 22:13:05 +0000
Message-ID: <4907a159683346789bef5c495f03f95d@boeing.com>
References: <d5c245f216c3409f826f8132e532a882@boeing.com> <860E06E2-2650-4AAE-AD33-D4D12B0290DC@fugue.com>, <b66ce3d9c75d4a39b5336dcdf9929411@boeing.com> <0DDEBA6C-3933-40FC-BB9C-33FA59DC9D76@cisco.com>
In-Reply-To: <0DDEBA6C-3933-40FC-BB9C-33FA59DC9D76@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 58D04A679D3548070B2CE19C830C6E20DB18B25CCB3267F92982369E5D4E23AF2000:8
Content-Type: multipart/alternative; boundary="_000_4907a159683346789bef5c495f03f95dboeingcom_"
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/5SW8a_FfprSexXmYa_IVBAueT0Q>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 31 Jul 2020 22:13:20 -0000

Hi Pascal, see below:

A major attack vector is an external attacker sending packets to the 2^64 or so possible addresses in the subnet.
[>] Subnet?? As in, an on-link IPv6 prefix? The large NBMA link that I want to use SEND
on will not have any of those – link-local only.

The attack causes a denial of service at the router that MUST store one packet for one second and multicast a NS lookup, which multiplies the effect.
[>] Again, we are talking about different kinds of links; there will not be any sort of
multicast explosion on the NBMA link based on a router receiving a SEND-protected
IPv6 ND message.

The attack is easy to perform from the outside and send offers no protection.
[>] For the OMNI NBMA link, the process is based on a Client sending a SEND-protected
RS message to exactly one router. The router authenticates the RS before processing it
further, which may include returning a unicasted RA. No NCEs are created until the RS
has been authenticated, and no multicast storms are initiated.

The only clear protection is to know in advance all the addresses present in the network and drop the rest. GRAND offers a way to preset the ND cache which is better than nothing but it offers no guarantee that the router has the full set of addresses I. Cache. In fact the concept of a cache is dated from the days memory was scarce and expensive. This concept is not needed And rather harmful in modern networks.
[>] The OMNI routers are not going to require any kind of ND cache presets; they
simply establish NCEs upon receipt *and* authentication of good RS messages.

Thanks - Fred

Regards,

Pascal


Le 31 juil. 2020 à 19:49, Templin (US), Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>> a écrit :

Hi Ted,

By “NM” I think you mean “Mobile Node?” That’s not really one of the use cases we’re talking about here. Or am I missing something?
[>]
Or, just call it a (mobile) “Stub-Network” – I think we are talking about the same
thing here.

In any case, you’re presuming some kind of trust establishment for non-router nodes, right? SEND only talks about trust establishment for routers. And, let’s be frank, doesn’t actually give us enough operational guidance that we would expect what _is_ said to be generally practicable.
[>]
OK, the specs I have been working dip their toes into the SEND pool but maybe they
should be updated to dive in completely? With an adoption call in progress, I don’t
know if it would be a good idea to make changes right now but be assured that it
will be added to the TODO list – would that be acceptable for now?

Thanks - Fred