Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 16 July 2019 19:47 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B700412067A for <anima@ietfa.amsl.com>; Tue, 16 Jul 2019 12:47:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 jOuT4ImaMl07 for <anima@ietfa.amsl.com>; Tue, 16 Jul 2019 12:47:15 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1690E120610 for <anima@ietf.org>; Tue, 16 Jul 2019 12:47:14 -0700 (PDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id B7F603808A; Tue, 16 Jul 2019 15:47:10 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8237DB52; Tue, 16 Jul 2019 15:47:13 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Joel Halpern Direct <jmh.direct@joelhalpern.com>
cc: Eliot Lear <lear@cisco.com>, Adam Roach <adam@nostrum.com>, anima@ietf.org
In-Reply-To: <a544c69a-38e2-4e6e-bc4f-752bbe524fa8@joelhalpern.com>
References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <ACEB4033-707F-47AF-B58A-5227B444BEAB@cisco.com> <E2DA8D30-805E-478D-925D-534C04A0727F@cisco.com> <8869.1563140002@dooku.sandelman.ca> <cedc515e-22ab-94a9-e6ef-c55b345687ba@joelhalpern.com> <376eee31-0264-38a8-1d32-901bb1a0671b@gmail.com> <9e341730-dc47-8860-47d4-6421ab04d0dc@nostrum.com> <6ecdae7f-4fb7-d9fc-f19f-bf742c6fe83c@joelhalpern.com> <193EB8D1-3E58-4570-AC4D-55737E3D36CF@cisco.com> <a544c69a-38e2-4e6e-bc4f-752bbe524fa8@joelhalpern.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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-sha256"; protocol="application/pgp-signature"
Date: Tue, 16 Jul 2019 15:47:13 -0400
Message-ID: <5240.1563306433@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/VPJAX-adDbrbBuKqkRW7sGVkc7U>
Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2019 19:47:23 -0000

Joel Halpern Direct <jmh.direct@joelhalpern.com> wrote:
    > It allows someone who
    > controls their network, and who physically controls a new device, to
    > put that new device in their network without asking anyone's
    > permission.

Right, get your "blue cable" out, connect it to the serial console, bring up
minicom, and tell the device to enroll.  Verify the registrar's certificate
when prompted, perhaps.

You can still use GRASP to find the Registrar, and all the rest of the ACP
mechanism....  or not.

That's been in section 7.2, but the complaint was that it was not normative.
So, we have added in section 9, for the ACP use case, that implementing
something is a MUST.  I don't think it will work for lightbulbs, but whomever
writes that Applicability Statement will have to cope with that.
(it will be me: I have a document in 6tisch, which is that document. I would
appreciate your thoughts on what might be acceptable there)

BTW: A number of router manufacturers have BRSKI-like mechanisms already, but they
only really work when you drink all their koolaid, and build your network
exclusively with their equipment.  At one ISP that I consult for, they wound
up turning the super-duper auto-join management system off because it ate all
of a very high end VM platform, and they just couldn't afford that at the
time...   Maybe cross-vendor mechanisms will result in some competition and
some better products. 

    > Now it may be that the particular approach I suggested won't work.  But
    > it seems to me that there needs to be a way for folks to keep using,
    > and to keep re-selling, devices without the support of the vendor.
    > That usage may not get all the zero-touch advantages that supported
    > re-sale would get.  But it has to work.  And putting the onus for that
    > on the original vendor does NOT seem an effective solution.

As long as vendors support blue cables, and are willing to provide firmware
updates, I don't see any change. 

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [