[6lo] Updates on draft-ietf-6lo-plc

"Liubing (Remy)" <remy.liubing@huawei.com> Sat, 18 April 2020 03:49 UTC

Return-Path: <remy.liubing@huawei.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 972743A0EF1; Fri, 17 Apr 2020 20:49:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id nhTPZZp_kE-p; Fri, 17 Apr 2020 20:49:53 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com []) (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 D75533A0EF0; Fri, 17 Apr 2020 20:49:52 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown []) by Forcepoint Email with ESMTP id 98F2DCA7AB7DB77EB6E2; Sat, 18 Apr 2020 04:49:51 +0100 (IST)
Received: from DGGEMM403-HUB.china.huawei.com ( by lhreml707-cah.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.3.487.0; Sat, 18 Apr 2020 04:49:51 +0100
Received: from DGGEMM526-MBS.china.huawei.com ([]) by DGGEMM403-HUB.china.huawei.com ([]) with mapi id 14.03.0487.000; Sat, 18 Apr 2020 11:49:39 +0800
From: "Liubing (Remy)" <remy.liubing@huawei.com>
To: "6lo@ietf.org" <6lo@ietf.org>
CC: "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>
Thread-Topic: Updates on draft-ietf-6lo-plc
Thread-Index: AdYVM6tsu5roOZeCSyq4pyv0POi3LQ==
Date: Sat, 18 Apr 2020 03:49:39 +0000
Message-ID: <BB09947B5326FE42BA3918FA28765C2E01275358@dggemm526-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_BB09947B5326FE42BA3918FA28765C2E01275358dggemm526mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/hY90XozxlP1ItgUK5cXYqyl0ax8>
Subject: [6lo] Updates on draft-ietf-6lo-plc
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: Sat, 18 Apr 2020 03:49:55 -0000

Hello 6lo WG,

As you may noticed that we have uploaded a new version of the draft "Transmission of IPv6 Packets over PLC Networks". In this latest version, we've enhanced the security consideration section.

A paragraph on authentication is added. Without authentication, malicious PLC devices can easily join the network and starts attacks such as keep joining and leaving the network, or sending routing messages with fake metrics to declare itself as a better parent to the gateway (PANC). The authentication can be done with the support of DTLS. When the device is an immediate neighbor of the PANC, the PANC authenticates the device via the certificate in DTLS. Otherwise, the device will choose a neighbor which has joined in the network as a proxy to relay its certificate to the PANC. In both of the two cases, before the authentication has been accomplished, the device enrolling itself will be limited within link-local, preventing the rest of the network from potential attack. After the authentication, the device can actually be part of the network, e.g. get the address within the network, the route to the PANC, etc.

>From the authors' perspective, we think that the draft is stable and ready for the last call.

Your comments will be more than welcome and appreciated.

Many thanks and best regards,