Re: [v6ops] SLAAC security concerns

Vasilenko Eduard <vasilenko.eduard@huawei.com> Wed, 05 August 2020 06:32 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 83EAA3A1371; Tue, 4 Aug 2020 23:32:45 -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 3IFnaUgQ2TgT; Tue, 4 Aug 2020 23:32:44 -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 132803A132A; Tue, 4 Aug 2020 23:32:44 -0700 (PDT)
Received: from lhreml736-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 4D987D2620AA74B172E2; Wed, 5 Aug 2020 07:32:42 +0100 (IST)
Received: from msceml705-chm.china.huawei.com (10.219.141.144) by lhreml736-chm.china.huawei.com (10.201.108.87) 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:32:41 +0100
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml705-chm.china.huawei.com (10.219.141.144) 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:32:40 +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:32:40 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Gert Doering <gert@space.net>, Ted Lemon <mellon@fugue.com>
CC: Michael Richardson <mcr+ietf@sandelman.ca>, v6ops list <v6ops@ietf.org>, 6man <ipv6@ietf.org>
Thread-Topic: [v6ops] SLAAC security concerns
Thread-Index: AdZqh2IDVN0JAX5fTSutty/fgHiG3P//7l0AgAAIigCAAAPAgP//JY2A
Date: Wed, 5 Aug 2020 06:32:40 +0000
Message-ID: <3179d46b4edb4058b344cfe1e62b12ad@huawei.com>
References: <f52c4463862f44b5ba2a9d41db86d231@huawei.com> <20200804194448.GA2485@Space.Net> <6370DE53-9EC6-4141-97C6-3B223939012A@fugue.com> <20200804202847.GB2485@Space.Net>
In-Reply-To: <20200804202847.GB2485@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/v6ops/Wq8vva7C6oR5TIpWkKWsOb6zhN8>
Subject: Re: [v6ops] SLAAC 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: Wed, 05 Aug 2020 06:32:49 -0000

Bad vendor problem is rare in Enterprise in Carrier. Because:
1. Carrier do test all equipment heavily before any big purchase. Some Enterprise test too.
2. They both have big influence on vendor (he is interested in other sales) - vendors would fix problems promptly
Unfortunately, even such situation could create pressure on Operational, but it is a different story.

Vendor would not care too much about home user.
Ed/
-----Original Message-----
From: Gert Doering [mailto:gert@space.net] 
Sent: 4 августа 2020 г. 23:29
To: Ted Lemon <mellon@fugue.com>
Cc: Gert Doering <gert@space.net>et>; Vasilenko Eduard <vasilenko.eduard@huawei.com>om>; Michael Richardson <mcr+ietf@sandelman.ca>ca>; v6ops list <v6ops@ietf.org>rg>; 6man <ipv6@ietf.org>
Subject: Re: [v6ops] SLAAC security concerns

Hi,

On Tue, Aug 04, 2020 at 04:15:22PM -0400, Ted Lemon wrote:
> On Aug 4, 2020, at 3:44 PM, Gert Doering <gert@space.net> wrote:
> > 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.
> 
> Why don???t you return that switch for a refund?
> 
> (I???ve never run into a switch that had trouble with IPv6 multicast, 
> but admittedly I only have four different switches in my house, so 
> that???s not a very big sample.)

$20 switches tend to be not affected.

It's the more expensive ones where developers intended to "do the right thing with multicast!" and never came around to actually implement it.

Or where you need to turn on - or *off* - MLD to make link-local multicast work, but the default is the wrong way around.

I have seen this on devices from three different vendors - Extreme, Juniper, and "something that DECIX was using like 15 years ago" - and of course not all models or all firmware versions are affected.  But when it happens, it's life time you won't get back.


If I were to return every device in my network where a developer messed up something the IETF made too complex in protocol design, I would have a very secure, and very power-efficient result - but no network anymore.

(And your response very nicely demonstrates why operators get fed up trying to participate in IETF)

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