Re: [v6ops] SLAAC security concerns

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 04 August 2020 20:54 UTC

Return-Path: <brian.e.carpenter@gmail.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 92D0C3A0B81; Tue, 4 Aug 2020 13:54:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.047
X-Spam-Level:
X-Spam-Status: No, score=-3.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 0bt2cC73o8xV; Tue, 4 Aug 2020 13:54:11 -0700 (PDT)
Received: from mail-pg1-x542.google.com (mail-pg1-x542.google.com [IPv6:2607:f8b0:4864:20::542]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 568C63A0B4B; Tue, 4 Aug 2020 13:54:11 -0700 (PDT)
Received: by mail-pg1-x542.google.com with SMTP id z5so23146782pgb.6; Tue, 04 Aug 2020 13:54:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=P5BpwR/IgOchApJG8VHfqIA6p661UpuwKMxcRqy5KHQ=; b=WTPKCc92Cd2zT2f3ClQYDFDSp9KpUVQTbLc6Ec9UJdmPCcpZRqAb9HrZU67vDwlETJ ACnwjzvxKEjPYofxRVBknes6lrFATO+xWoruL0Mca+GnhzuIAzGKu3o7sJRcduYMHPb8 NGg90FQZQnSfhIHJEYcNMiVXRy6AYcwt0CnerRlcUTC8soh59HhIVa+va+lA7qMAbhGR U4MJ1Fj0DfneIWVowyu5WAmStlz7apDhyff3IbnIVGnqwnTAOp4IlKAVY8Wim5sCIM/X kAKuVICeF7azKrGhzCUi5XUJtyhVd3RBcbS5P3Cac9NGC9P3xTZBMoa0KEAu+5xGSTLY 72BA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=P5BpwR/IgOchApJG8VHfqIA6p661UpuwKMxcRqy5KHQ=; b=LgBKToPd+T+Tin2nfDuCnayC81+w7HZLrjxK1uLhTiw3ji8gKFL8daiAEaI5z0sh7c cHHJus5AOb+XcPF6owf0Zz8zBNvS6dVzlhDtMUS7ILGDAcZydZ6I//HVWlmqWCHZ7nOD RnnAtNvLG5ou2X9C+LxmH3xuF5CJJ7XFbVVfNrAwcSAXOZHKcaDCSzEV31uSrkfGAJ/y 6KTTYsRyrmSKTHdnBNhiLI56WKbY2f94VHRyeeMTeD7ZFhtQjO2Lw5xmoBpzBQzFEGkP kNaBZX5YYd2Kco5o0XbDHRFScuLaWAa2WtfvoLUEO7VJLOD+UF/vdlTVyqaugSzx4Q8/ oVgg==
X-Gm-Message-State: AOAM531CB/Mc4Mm/ETxJeb4IdSQAv5j7WUSYQgjNNCcB+Dn29123z7Wq DZ6tHQGjc31Bw0jcUy+1i44IAHlECGs=
X-Google-Smtp-Source: ABdhPJwjjPhxC0v7dEsg0YFvbPDtnBeu8QTNOu1QteciN7QnfNC9+0p8tpDiqLnIt5YeBMPQknZdpg==
X-Received: by 2002:a62:647:: with SMTP id 68mr206653pfg.45.1596574450427; Tue, 04 Aug 2020 13:54:10 -0700 (PDT)
Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id w2sm3646173pjt.19.2020.08.04.13.54.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Aug 2020 13:54:09 -0700 (PDT)
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>
References: <f52c4463862f44b5ba2a9d41db86d231@huawei.com> <20200804194448.GA2485@Space.Net> <6370DE53-9EC6-4141-97C6-3B223939012A@fugue.com> <20200804202847.GB2485@Space.Net>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <f8d5457d-0e40-2a59-c7bf-fe5705ecaee3@gmail.com>
Date: Wed, 5 Aug 2020 08:54:06 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <20200804202847.GB2485@Space.Net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/I1c7M1jZ90FMZTqJLrfYLbaI3kY>
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: Tue, 04 Aug 2020 20:54:13 -0000

On 05-Aug-20 08:28, Gert Doering wrote:
> 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.

It's also a matter of scale. Multicast-dependent code that runs perfectly
on a small home network fails dramatically on a site network with defective
MLD implementation, and misbehaves significantly on a network with correct
MLD implementation but very heavy load. (I speak from experience with
the ANIMA GRASP protocol, that uses low rate multicast. On the IETF network,
for example, only about 10% of its multicasts were delivered, and this was
because the switches were doing MLD correctly and behaving exactly as intended
by the NOC. If you care, you can see that draft-ietf-anima-autonomic-control-plane
provides NBMA service for GRASP, even though it doesn't use that term.) 

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

All the same, Gert, we need frequent injections of reality. Thanks!

   Brian