Re: [v6ops] [EXTERNAL] Improving ND security

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Tue, 04 August 2020 18:02 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22B83A0ED3; Tue, 4 Aug 2020 11:02:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, 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 fduX-WJL4lMI; Tue, 4 Aug 2020 11:02:49 -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 1F55F3A0ECC; Tue, 4 Aug 2020 11:02:46 -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 074I2iol031791; Tue, 4 Aug 2020 14:02:44 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1596564164; bh=1RD3gY5/uD4z874aauApYNTpccPndQ8zHNjiSTQ9lBs=; h=From:To:Subject:Date:References:In-Reply-To:From; b=uhDyYt7gwx/wJPd7VX8LRMR3hajkYt1tWTVSur+KqVz/BKinCG2Zh8I96yWkGhkD7 gnWdNPHCW6MogY125WTTKHSjTKIy0q7hcTMaa9ssENRSDANf66/UyfZmLn164mE+Ih 9Ah7t5/DqNqm0zPBldF4oulTYv5czhEsLC84926tBr2e2sRKRkrO8u9OPZxgFNtNIQ 5ZIzQPtGE/CLFP+2fCYiqjEHkWb4Z+1MOHzzGr7yaLpX/3f//Rhi5VPSRpLabqr12s YhjXIEB3dJL+sL0lQCPubMafjhw/8xRq0pSRL2ARW9lG2JqU8bU9A6c31kZeYvmCM/ pgr3M8axSK2fA==
Received: from XCH16-07-07.nos.boeing.com (xch16-07-07.nos.boeing.com [144.115.66.109]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 074I2ZuW030722 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 4 Aug 2020 14:02:35 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-07.nos.boeing.com (144.115.66.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Tue, 4 Aug 2020 11:02:34 -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; Tue, 4 Aug 2020 11:02:34 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, Ted Lemon <mellon@fugue.com>, v6ops list <v6ops@ietf.org>, 6man <ipv6@ietf.org>
Thread-Topic: [EXTERNAL] Improving ND security
Thread-Index: AQHWZ1UXpJjqh6zAPESbZadyenD7WakiUY2A//+bayCABTPJrYABISQg
Date: Tue, 4 Aug 2020 18:02:34 +0000
Message-ID: <1f65a6e1edc343caa3b5e61d60a6d423@boeing.com>
References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <CAFU7BARePzdeU5DFgoOWyrF0xZCj67_xkC2t8vMN2nH0d8aUig@mail.gmail.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <CAFU7BATiD8RkiWXjrxGuAJU-BUwRQCErYZivUPZ-Mc_up_qGxQ@mail.gmail.com> <aebc46c9b813477b9ae0db0ef33e7bd9@huawei.com> <CAO42Z2yL7+GbO6QRaNzFYoBXLF-JZ2NfwgTTt2zerKhJLwt2Lw@mail.gmail.com> <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com> <91D98D51-4045-4331-A711-8387ECE73400@fugue.com> <a43ffd94d6364a0f869cd4c694ab7432@boeing.com> <5FB3E98B-6CEE-458C-90B7-E6FD73C7AFDE@fugue.com> <caa62d8d93594f7ea445a403fac8c140@boeing.com> <25FAEE9A-3D14-4428-A573-5EFE863219D2@fugue.com> <a1881d0c6d3748fa8cec8ea2b2c6559b@boeing.com> <1766B530-1683-403B-BC7D-90C4B056B739@fugue.com> <25494.1596501526@localhost>
In-Reply-To: <25494.1596501526@localhost>
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: F2E06C32B5FFF9D247945C8503BB8C4AAA86FDEA0DCA55F8E5967DE0DC6FCCB52000:8
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/SnBT3iRLoq3v2sQoj2vmJUV-DOA>
Subject: Re: [v6ops] [EXTERNAL] Improving ND security
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Aug 2020 18:02:51 -0000

Hi, about SEND I was just doing a maintenance update of the AERO draft and noticed
that the subject is already covered there in full detail in Section 3.22:

https://datatracker.ietf.org/doc/draft-templin-intarea-6706bis/

So, for those who have participated in this discussion, please refer to the AERO spec
and realize that the only thing missing in OMNI is an appropriate reference citation
to AERO. However, a point that could be considered by the OMNI design team is
whether the SEND text in AERO should instead be moved into the OMNI draft.

Please review and comment,

Fred

> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Michael Richardson
> Sent: Monday, August 03, 2020 5:39 PM
> To: Ted Lemon <mellon@fugue.com>om>; v6ops list <v6ops@ietf.org>rg>; 6man <ipv6@ietf.org>
> Subject: Re: [EXTERNAL] Improving ND security
> 
> 
> Ted Lemon <mellon@fugue.com> wrote:
>     > On Jul 31, 2020, at 1:17 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
>     >> Ted, I think SEND would solve the neighbor cache resource exhaustion attack since a NCE is
>     >> only created on receipt of an authentic (SEND-protected) IPv6 ND message.
> 
>     > OK, but an attacker can just generate a bazillion key pairs, right? So
>     > it can still exhaust the cache, at the cost of some computation work.
> 
> If you do a TUFO trust model, yes.
> If you do something else, because you are in a different environment than a
> IETF meeting network^W^W^Wcoffee shop, then the potential win is quite large.
> 
> Even if you do a TOFU trust model, keys which were first used prior to the
> attack, could continue to be be used, protecting the cache.
> 
> This pushes the exhaustion attack from one part of the control plane (where
> ND messages are processed), to another part of the control plane (where keys
> are trusted on first use).
> Is that a good thing?  Maybe.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
>