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

"Liubing (Remy)" <remy.liubing@huawei.com> Fri, 22 May 2020 09:54 UTC

Return-Path: <remy.liubing@huawei.com>
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 643A03A09F2 for <6lo@ietfa.amsl.com>; Fri, 22 May 2020 02:54:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 9J-IG9-1_Vxu for <6lo@ietfa.amsl.com>; Fri, 22 May 2020 02:54:35 -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 E51AB3A09DC for <6lo@ietf.org>; Fri, 22 May 2020 02:54:34 -0700 (PDT)
Received: from lhreml734-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id A3ABE95AC08EC88EAF0C; Fri, 22 May 2020 10:54:32 +0100 (IST)
Received: from lhreml734-chm.china.huawei.com (10.201.108.85) by lhreml734-chm.china.huawei.com (10.201.108.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 22 May 2020 10:54:32 +0100
Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml734-chm.china.huawei.com (10.201.108.85) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Fri, 22 May 2020 10:54:32 +0100
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.4]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0487.000; Fri, 22 May 2020 17:54:29 +0800
From: "Liubing (Remy)" <remy.liubing@huawei.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "6lo@ietf.org" <6lo@ietf.org>, Carles Gomez Montenegro <carlesgo@entel.upc.edu>
Thread-Topic: [6lo] FW: I-D Action: draft-ietf-6lo-plc-03.txt
Thread-Index: AdYvTxsGcOwTY46vSwCav5/pg9mPN///3IqA//5JzTA=
Date: Fri, 22 May 2020 09:54:29 +0000
Message-ID: <BB09947B5326FE42BA3918FA28765C2E012BEAA2@DGGEMM506-MBX.china.huawei.com>
References: <BB09947B5326FE42BA3918FA28765C2E012BD516@DGGEMM506-MBX.china.huawei.com> <29443.1590073171@localhost>
In-Reply-To: <29443.1590073171@localhost>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.203.246]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/NPDVFVyQ2Gpe8WzSuWTDCs61_Yw>
Subject: [6lo] =?gb2312?b?tPC4tDogIEZXOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRm?= =?gb2312?b?LTZsby1wbGMtMDMudHh0?=
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: Fri, 22 May 2020 09:54:38 -0000

Hello Michael,

Thank you for your explanation.

I think I can rewrite some sentences in the security considerations. Please tell me the following text is correct or not.

It is highly recommended to conduct a mutual authentication between the network and the device tending to join in it. The authentication can be accomplished with the help of certificates or pre-shared keys [I-D.ietf-6tisch-minimal-security] provisioned by the operator at the deployment site. Alternatively, the certificates could be provisioned by the manufacturer or the vendor before the shipment, and in this case the authentication can be accomplished with the help of a MASA service on the Internet [dtsecurity-zerotouch-join].

Best regards.
Remy

-----邮件原件-----
发件人: Michael Richardson [mailto:mcr+ietf@sandelman.ca] 
发送时间: 2020年5月21日 23:00
收件人: Liubing (Remy) <remy.liubing@huawei.com>om>; 6lo@ietf.org; Carles Gomez Montenegro <carlesgo@entel.upc.edu>
主题: Re: [6lo] FW: I-D Action: draft-ietf-6lo-plc-03.txt


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>ca>, Sandelman Software Works  -= IPv6 IoT consulting =-