IETF Logo Mail Archive

Re: [EXTERNAL] Improving ND security

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 04 August 2020 00:38 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 A45B93A118F; Mon, 3 Aug 2020 17:38:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 VSPo7UI0V_TT; Mon, 3 Aug 2020 17:38:58 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD7FA3A1195; Mon, 3 Aug 2020 17:38:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E9BE5389A5; Mon, 3 Aug 2020 20:18:12 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id z05Xzk5sGs4p; Mon, 3 Aug 2020 20:18:09 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 17F35389A2; Mon, 3 Aug 2020 20:18:09 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9A79163E; Mon, 3 Aug 2020 20:38:46 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Ted Lemon <mellon@fugue.com>, v6ops list <v6ops@ietf.org>, 6man <ipv6@ietf.org>
Subject: Re: [EXTERNAL] Improving ND security
In-Reply-To: <1766B530-1683-403B-BC7D-90C4B056B739@fugue.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>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Mon, 03 Aug 2020 20:38:46 -0400
Message-ID: <25494.1596501526@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/PLoSVOMQwMSI-L9T_NF9n7n7WZY>
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: Tue, 04 Aug 2020 00:39:00 -0000

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>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email