Re: [6lo] FW: I-D Action: draft-ietf-6lo-plc-03.txt

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 21 May 2020 14:59 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2EC3A0D0B for <6lo@ietfa.amsl.com>; Thu, 21 May 2020 07:59:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PgfiR5O73EbN for <6lo@ietfa.amsl.com>; Thu, 21 May 2020 07:59:35 -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 593523A0D00 for <6lo@ietf.org>; Thu, 21 May 2020 07:59:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9D13D38A24; Thu, 21 May 2020 10:57:20 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id L04WGunxOKI4; Thu, 21 May 2020 10:57:19 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9FA4538A1F; Thu, 21 May 2020 10:57:19 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 58BA0451; Thu, 21 May 2020 10:59:31 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Liubing \(Remy\)" <remy.liubing@huawei.com>, "6lo\@ietf.org" <6lo@ietf.org>, Carles Gomez Montenegro <carlesgo@entel.upc.edu>
In-Reply-To: <BB09947B5326FE42BA3918FA28765C2E012BD516@DGGEMM506-MBX.china.huawei.com>
References: <BB09947B5326FE42BA3918FA28765C2E012BD516@DGGEMM506-MBX.china.huawei.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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-sha512; protocol="application/pgp-signature"
Date: Thu, 21 May 2020 10:59:31 -0400
Message-ID: <29443.1590073171@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/IQHRbwOEo3iCJb2CsW9OVEdB_jc>
Subject: Re: [6lo] FW: I-D Action: draft-ietf-6lo-plc-03.txt
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 May 2020 14:59:38 -0000

Liubing (Remy) <remy.liubing@huawei.com> wrote:
    > Is the following understanding correct? The difference between the
    > "one-touch" and the "zero-touch" methods is that whether the key or
    > certificate is provisioned by the manufacturer or by the operator at
    > the deployment site. As long as the key/IDevID/certificate is
    > provisioned before the device goes out of the factory, i.e., the
    > operator doesn't have to provision/touch it on site to get it securely
    > join the network, it can be considered as "zero-touch".

Yes, that's correct. The touches by the manufacturer and/or a VAR don't count.
Or to put it another way, it's the number of touches the by operator that count.
A further characteristic MAY be that it doesn't matter which unit is shipped
to which customer from the warehouse.  (There seem to be use cases in transportation
and manufacturing where it matters due to contractual warantee issues.
I think because refurbished devices may mingle with brand-new devices in the
warehouse.  This is less interesting for enterprise routers and more relevant
for train braking systems)

    > Even though the pledge ID is given privately by the manufacturer, and
    > not as per 802.1 AR, the dtsecurity-zerotouch-join method can be
    > implemented by using the MASA provided by the manufacturer? Is the
    > dtsecurity-zerotouch-join method aimed at a scenario in which a
    > certificate can't be provisioned a priori?

dtsecurity-zerotouch-join assumes a certificate provisioned prior to deployment.
So I can't agree with the last sentence.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-