Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 03 August 2020 23:57 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 49C673A1185; Mon, 3 Aug 2020 16:57:21 -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=unavailable 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 FeBApgV5Uf68; Mon, 3 Aug 2020 16:57:19 -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 B207B3A1186; Mon, 3 Aug 2020 16:57:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3DB6E389A0; Mon, 3 Aug 2020 19:36:40 -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 3R2FeqftzdXV; Mon, 3 Aug 2020 19:36:39 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6A7AC38999; Mon, 3 Aug 2020 19:36:39 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E31FC63E; Mon, 3 Aug 2020 19:57:16 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Templin \(US\)\, Fred L" <Fred.L.Templin@boeing.com>
cc: "Pascal Thubert \(pthubert\)" <pthubert=40cisco.com@dmarc.ietf.org>, "Mark Smith" <markzzzsmith@gmail.com>, v6ops list <v6ops@ietf.org>, 6man <ipv6@ietf.org>
In-Reply-To: <dfb9ccbfd87140cfba01c69447581aef@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> <dfb9ccbfd87140cfba01c69447581aef@boeing.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 19:57:16 -0400
Message-ID: <15197.1596499036@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/YXzTj7-7Y-K2aGOFMLVqeaiO-qU>
Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns
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: Mon, 03 Aug 2020 23:57:21 -0000

Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
    > I wish this group could open its eyes. ND as defined in the last
    > century is not suited for modern fabrics, virtual machines and
    > wireless. It is a pain for silicon-based forwarding. Time to upgrade is
    > overdue.

You are right!

We either need SEND (RFC3971), or some technology that addresses the same use case (RFC3756).
We need a for nodes to reserve resources on the router.

Many of us would prefer that we avoid making it stateful, but in wifi
networks, are already allocate crypto state, and we should just leverage
that. (ND is just wasted effort on encrypted wifi in my opinion)

    > There is nothing broken with IPv6 ND that needs changing; it just needs a new option.
    > We have seen how that is possible through publications like RFC8801.

Also RFC8505.
I think, it's really really time to stop pretending everything is big-blue coaxial ethernet.

    > BTW, IPv6 itself is a last-century technology but the architects had the wisdom to allow
    > for future extensions without needing to modify the core architecture.

--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-