IETF Logo Mail Archive

RE: [v6ops] SLAAC security concerns

Vasilenko Eduard <vasilenko.eduard@huawei.com> Wed, 05 August 2020 06:26 UTC

Return-Path: <vasilenko.eduard@huawei.com>
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 2CC0A3A11F1; Tue, 4 Aug 2020 23:26:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 JvW5NFlKPhus; Tue, 4 Aug 2020 23:26:57 -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 0B89C3A0CBA; Tue, 4 Aug 2020 23:26:57 -0700 (PDT)
Received: from lhreml722-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 7FE3583233A49753721D; Wed, 5 Aug 2020 07:26:55 +0100 (IST)
Received: from msceml704-chm.china.huawei.com (10.219.141.143) by lhreml722-chm.china.huawei.com (10.201.108.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 5 Aug 2020 07:26:55 +0100
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml704-chm.china.huawei.com (10.219.141.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 5 Aug 2020 09:26:54 +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; Wed, 5 Aug 2020 09:26:54 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Gert Doering <gert@space.net>
CC: Mark Smith <markzzzsmith@gmail.com>, Michael Richardson <mcr+ietf@sandelman.ca>, 6man <ipv6@ietf.org>, v6ops list <v6ops@ietf.org>
Subject: RE: [v6ops] SLAAC security concerns
Thread-Topic: [v6ops] SLAAC security concerns
Thread-Index: AdZqh2IDVN0JAX5fTSutty/fgHiG3P//7l0A//8aecA=
Date: Wed, 05 Aug 2020 06:26:54 +0000
Message-ID: <7105a04994d045b890d04b49ef72c31c@huawei.com>
References: <f52c4463862f44b5ba2a9d41db86d231@huawei.com> <20200804194448.GA2485@Space.Net>
In-Reply-To: <20200804194448.GA2485@Space.Net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.204.128]
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/ipv6/WvlsnFDufHBzSbYIRPM2TpCuHaY>
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: Wed, 05 Aug 2020 06:26:58 -0000

Hi Gert,
SLAAC dependency on multicast is so huge that it is not possible to make it worse by 1 additional function.
If L2 would lose ND packets, then many things in SLAAC would not work.
Eduard
-----Original Message-----
From: Gert Doering [mailto:gert@space.net] 
Sent: 4 августа 2020 г. 22:45
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: Mark Smith <markzzzsmith@gmail.com>; Michael Richardson <mcr+ietf@sandelman.ca>; 6man <ipv6@ietf.org>; v6ops list <v6ops@ietf.org>
Subject: Re: [v6ops] SLAAC security concerns

Hi,

On Tue, Aug 04, 2020 at 06:00:39PM +0000, Vasilenko Eduard wrote:
> I believe that Multicast is so basic function of SLAAC that it does not make sense to delete it.

Have I heard "delete multicast" here?

Yes, please!

There is too many broken switch vendors out there that show again and again that "implementing multicast is hard", breaking IPv6 ND in the process.

The motivation for going to multicast "back in the dark ages" might have been honorable, but in today's networks, it just adds needless complications.

Gert Doering
        -- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

v2.23.0 | Report a Bug | By Email