distributed vs centralized approaches to ND security

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 09 August 2020 20:02 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 E8F763A0DCD; Sun, 9 Aug 2020 13:02:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ttR4K-GD2UT1; Sun, 9 Aug 2020 13:02:33 -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 975DF3A0DBD; Sun, 9 Aug 2020 13:02:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 2870F389D6; Sun, 9 Aug 2020 15:41:49 -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 8bvyobAmlfZx; Sun, 9 Aug 2020 15:41:48 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4E563389D5; Sun, 9 Aug 2020 15:41:48 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EBE6F7D; Sun, 9 Aug 2020 16:02:30 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: v6ops list <v6ops@ietf.org>, 6man <ipv6@ietf.org>
Subject: distributed vs centralized approaches to ND security
In-Reply-To: <e64151b767cc4aef9444a2fe546f474f@huawei.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> <15197.1596499036@localhost> <63afd5c67e7c4520b8b7ebabec69cab7@huawei.com> <MN2PR11MB3565E0E206799B95AE6295D7D84A0@MN2PR11MB3565.namprd11.prod.outlook.com> <e64151b767cc4aef9444a2fe546f474f@huawei.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: Sun, 09 Aug 2020 16:02:30 -0400
Message-ID: <10665.1597003350@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/awl26DUvK40iVYRcYBdYWu-hLKI>
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: Sun, 09 Aug 2020 20:02:47 -0000

Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:
    > Yes, I have made comment below that if Address Allocation would be
    > changed to Centralized, then it is probably not SLAAC anymore. Then it
    > is better to adopt DHCPv6.

SLAAC has the features that it is seems completely stateless for the routers.
One can as many add routers to the network as desired to deal with whatever
resilience issues one has.   Many IPv4 experienced people are startled to
realize that one does not need VRRP or anything to have redundant routers in
IPv6.

Full stateful DHCPv6, can also be made resilient through redundancy, but it
seems significantly less popular, and it isn't particularly more secure when
it comes to ND, just to controlling address allocation.

There are things in between, as Pascal keep repeating: RFC8505 provides for
statefulness ND.  It's not mutually exclusive with SLAAC, as it does not deal
with assignment, just defense (DAD).

    > I have read your https://datatracker.ietf.org/doc/draft-ietf-6lo-backbone-router
    > Proxy is not universal solution and should not be mainstream. It is
    > complicated: IP subnet is split for many broadcast domains, proxy
    > stitch it back.

But, the database which is the proxy is present in almost every single ethernet system today.
It's just that it exists at the layer-2 in the form of MAC address forwarding
tables.  We don't get to see them, don't get to securely update them, and
they are impossible to debug.  These are what I call layer-2 games.
We need to stop playing them, and architecture our layer-3 around the real
physical topology.  We need to do this for security, latency and efficiency
reasons.

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