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

"Liubing (Remy)" <remy.liubing@huawei.com> Tue, 26 May 2020 07:46 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 C14293A0C80 for <6lo@ietfa.amsl.com>; Tue, 26 May 2020 00:46:45 -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 NZPKZsX8mUPa for <6lo@ietfa.amsl.com>; Tue, 26 May 2020 00:46:41 -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 AB0563A0C7A for <6lo@ietf.org>; Tue, 26 May 2020 00:46:41 -0700 (PDT)
Received: from lhreml716-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 4D51AFDCD90AADCD4729; Tue, 26 May 2020 08:46:37 +0100 (IST)
Received: from lhreml716-chm.china.huawei.com (10.201.108.67) by lhreml716-chm.china.huawei.com (10.201.108.67) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 26 May 2020 08:46:37 +0100
Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml716-chm.china.huawei.com (10.201.108.67) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Tue, 26 May 2020 08:46:36 +0100
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.4]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0487.000; Tue, 26 May 2020 15:46:33 +0800
From: "Liubing (Remy)" <remy.liubing@huawei.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
CC: "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//5JzTCAA05bAP/5uxeA
Date: Tue, 26 May 2020 07:46:33 +0000
Message-ID: <BB09947B5326FE42BA3918FA28765C2E012BF5E9@DGGEMM506-MBX.china.huawei.com>
References: <BB09947B5326FE42BA3918FA28765C2E012BD516@DGGEMM506-MBX.china.huawei.com> <29443.1590073171@localhost> <BB09947B5326FE42BA3918FA28765C2E012BEAA2@DGGEMM506-MBX.china.huawei.com> <4328.1590160822@localhost>
In-Reply-To: <4328.1590160822@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/nvvvbpGDUhEcwETCh8VlAnYNcZM>
Subject: [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: Tue, 26 May 2020 07:46:46 -0000

Hello Michael,

Thank you for your suggestion. I prefer not to include [I-D.ietf-anima-bootstrapping-keyinfra], since it is not as directly related to PLC as [I-D.ietf-6tisch-dtsecurity-zerotouch-join]. How about make a very brief explanation just like you made for [I-D.ietf-6tisch-minimal-security]?

I post the second paragraph of the security considerations below. Please tell me your opinion. Thank you.

Malicious PLC devices could paralyze the whole network via DOS attacks, e.g., keep joining and leaving the network frequently, or multicast routing messages containing fake metrics. A device may also join a wrong or even malicious network, exposing its data to illegal users. Mutual authentication of network and new device can be conducted during the onboarding process of the new device. Methods include protocols such as [RFC7925] (exchanging pre-installed certificates over DTLS), [I-D.ietf-6tisch-minimal-security] (which uses pre-shared keys), and [I-D.ietf-6tisch-dtsecurity-zerotouch-join] (which uses IDevID and MASA service). It is also possible to use EAP methods such as [I-D.ietf-emu-eap-noob] via transports like PANA [RFC5191]. No specific mechanism is specified by this document as an appropriate mechanism will depend upon deployment circumstances. The network encryption key appropriate for the layer-2 can also be acquired during the onboarding process.

Best regards,
Remy

-----邮件原件-----
发件人: Michael Richardson [mailto:mcr+ietf@sandelman.ca] 
发送时间: 2020年5月22日 23:20
收件人: Liubing (Remy) <remy.liubing@huawei.com>
抄送: 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:
    > 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].

I suggest:

An onboarding process is required to enabled a new PLC node to join the network.  This is required in order for the new node to acquire the network encryption key appropriate for the layer-2.
Automated processes perform a mutual authentication of network and new node.
Methods include protocols such as [I-D.ietf-6tisch-minimal-security] (which uses pre-shared keys), and constrained variations of [I-D.ietf-anima-bootstrapping-keyinfra] such [I-D.ietf-6tisch-dtsecurity-zerotouch-join].
It is also possible to use EAP methods such as [I-D.ietf-emu-eap-noob] via transports like PANA [RFC5191].  No specific mechanism is specified by this document as an appropriate mechanism will depend upon deployment circumstances.

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