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

Vasilenko Eduard <vasilenko.eduard@huawei.com> Tue, 04 August 2020 09:07 UTC

Return-Path: <vasilenko.eduard@huawei.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 2623B3A0C9D; Tue, 4 Aug 2020 02:07:55 -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=[RCVD_IN_MSPIKE_H2=-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 sBHyKeg07EtN; Tue, 4 Aug 2020 02:07:53 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 F05903A0C92; Tue, 4 Aug 2020 02:07:52 -0700 (PDT)
Received: from lhreml705-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id E5A02550762A6DFE3DFB; Tue, 4 Aug 2020 10:07:50 +0100 (IST)
Received: from msceml701-chm.china.huawei.com (10.219.141.159) by lhreml705-chm.china.huawei.com (10.201.108.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Tue, 4 Aug 2020 10:07:50 +0100
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml701-chm.china.huawei.com (10.219.141.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 4 Aug 2020 12:07:49 +0300
Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Tue, 4 Aug 2020 12:07:49 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
CC: "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>, "v6ops list" <v6ops@ietf.org>, 6man <ipv6@ietf.org>
Thread-Topic: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns
Thread-Index: AdZl2/KmEr6Lt/NERGGqFiMA7k1/CAAIPvAAABH5AHD///P/gP//vOiggAECawCAABGlgIABDy+AgAVTiwD//z22UA==
Date: Tue, 4 Aug 2020 09:07:49 +0000
Message-ID: <63afd5c67e7c4520b8b7ebabec69cab7@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>
In-Reply-To: <15197.1596499036@localhost>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.200.175]
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Uf6Iw1l9oicSqRrNsI6_1R6LpWQ>
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: Tue, 04 Aug 2020 09:07:55 -0000

Hi Michael,
It is strange that most dangerous attack (unsolicited NA - leading to leakage of information) was not mentioned in RFC 3756.

>We need a for nodes to reserve resources on the router.
Then router would be stateful (in respect of ND) - it is a very big architecture change. The industry has the big inertia - I do not believe that it is possible to return IPv6 address management to stateful model (except government intrusion - see below).
By the way, stateful DHCPv6 exist. Switch could easily snoop all messages and assist to IPv6 in security (like it is done for IPv4).
I propose do not push SLAAC in stateful direction - anyone who would like - could use DHCPv6 or 6lo (stateful on router too).
I propose to think how to save SLAAC - keeping it with distributed address management.

> 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.
Our days big campuses are deployed without CAT5/6 cabling - everything is WiFi.
SLAAC for WiFi looks like not the best technology. State repository (AP) is mandatory anyway. But anyone could use 6lo - it is developed specifically for such environment (not effective multicast, frame loss).
IMHO: It does not make sense to reinvent the wheel. RFC 6775 and 8505 do have good stateful solution for WiFi.
SLAAC has been left with the small niche for the future - if it would have fixes for biggest security problems (personal data protection).

Looking to all these "data privacy protection legislation" world-wide (in many countries): SLAAC could be banned by some government at any movement.
Experts would easily point to alternative: (1) stateful DHCPv6 (natural IPv4 prolong); (2) 6lo (it is optimized for wireless).
Probably DHCPv6 would win, because it is easy to understand for IT&IP professionals.
If any government would push - switchover to DHCPv6 would be fast.
Then fixing SLAAC would be too late. It would be the time for deprecation RFC.

Eduard
-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Michael Richardson
Sent: 4 августа 2020 г. 2:57
To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
Cc: Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org>rg>; v6ops list <v6ops@ietf.org>rg>; 6man <ipv6@ietf.org>
Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns


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 =-