Re: [6lo] comments on on draft-ietf-6lo-plc-02

"Liubing (Remy)" <remy.liubing@huawei.com> Tue, 28 April 2020 08:28 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 566E13A0F67 for <6lo@ietfa.amsl.com>; Tue, 28 Apr 2020 01:28:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jeOlstBuiQkg for <6lo@ietfa.amsl.com>; Tue, 28 Apr 2020 01:28:22 -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 823743A0F6F for <6lo@ietf.org>; Tue, 28 Apr 2020 01:28:22 -0700 (PDT)
Received: from lhreml735-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id B834DFA83AB2EBE70FD0; Tue, 28 Apr 2020 09:28:17 +0100 (IST)
Received: from lhreml735-chm.china.huawei.com (10.201.108.86) by lhreml735-chm.china.huawei.com (10.201.108.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 28 Apr 2020 09:28:17 +0100
Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml735-chm.china.huawei.com (10.201.108.86) 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, 28 Apr 2020 09:28:17 +0100
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.9]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0487.000; Tue, 28 Apr 2020 16:28:14 +0800
From: "Liubing (Remy)" <remy.liubing@huawei.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: [6lo] comments on on draft-ietf-6lo-plc-02
Thread-Index: AdYdKgn/kn6AoFSfQjy61eEauE15pQ==
Date: Tue, 28 Apr 2020 08:28:14 +0000
Message-ID: <BB09947B5326FE42BA3918FA28765C2E01289E32@DGGEMM506-MBX.china.huawei.com>
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/ZQ2LC9iFdE3Jn8PCEF0PjxWxVtg>
Subject: Re: [6lo] comments on on draft-ietf-6lo-plc-02
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, 28 Apr 2020 08:28:25 -0000

Hello Michael,

Thank you very much for your comments. We would love to follow your suggestions and make changes in the upcoming version in a couple of days.

Please check my response below.

Best regards,
Remy

-----邮件原件-----
发件人: 6lo [mailto:6lo-bounces@ietf.org] 代表 Michael Richardson
发送时间: 2020年4月24日 0:05
收件人: 6lo@ietf.org
主题: [6lo] comments on on draft-ietf-6lo-plc-02


Some comments/nits:
1) update your RFC2119 text to tbe BCP14 template.
[Remy] Will do.

2) change:
Compared to
   [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks], this document
   provides a structured and greatly expanded specification of an
   adaptation layer for IPv6 over PLC (6LoPLC) networks.

to:
There was work previously proposed as [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks]
which did not reach consensus.  This document provides a more structured specification than the previous work, expanding to a larger variety of PLC networks.

{assuming that I got it right}

[Remy] You're right :)

3)    PAN device:  An entity follows the PLC standards and implements the
         protocol stack described in this draft.

to:
   PLC/PAN device:  An entity that follows the PLC standards and implements the
         protocol stack described in this draft.

4) the table mapping is good.  Can you add a fourth column which is the term
   that this document will use?
   Or maybe put a (*) next to the name used.
[Remy] Good suggestion.

5) comma after "e.g." -> "e.g.," {don't ask me why}
[Remy] Lesson learnt.

6) split up section 3.0 into multiple paragraphs.
   maybe: Various...
          Moreoever,...
          Currently,...

7) I don't know if you are numbering your figures and tables manually or if
   xml2rfc is doing it. Maybe they should be numbered from the same sequence.
   I never looked at what xml2rfc does anyway.  Not a big deal.
[Remy] We were doing it manually. Will double check it.

8) 3.1,
   The routes can be built in mesh-under
   mode at layer 2 or in route-over mode at layer 3
        add: as explained in section 3.4.


9) section 3.2:
   Each PLC device joins the network by using the long address and
   communicates with other devices by using the short address after
   joining the network.
           add "Short addresses can be assigned during the onboarding
               process, such as by using CoJP [I.D-ietf-6tisch-minimal-security]"
[Remy] Of course CoJP is one possible option, but before that each PLC technology has its own way to assign the short address. How about making the text like this: Short addresses can be assigned during the onboarding process, by the PANC or the JRC in CoJP [I.D-ietf-6tisch-minimal-security].

10) You will get pushback by using RFC4291 on privacy issues.
    I would change that.

Rewrite to say:
   As explained in [RFC4291], the IPv6 link-local address for a PLC interface
   may be formed by appending the IID, as defined above, to the prefix FE80::/64 (see
   Figure 2).  Implementations should look at RFC8064 as well.

11) section 4.4
    In this case, the prefix information option
    (PIO) MUST NOT be included in the Router Advertisement.

that isn't necessarily the case.  The rpl-unaware-leaves document says more, and probably should be referenced instead.
[Remy] You're right about this. MUST NOT is too heavy. It should be allowed to configure a PLC device to be a leaf, and RPL-unaware. In this case, the leaf device has to learn the prefix form the PIO carried in RA. 

12) section 7.

>   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.  The security can be enhanced
>   by using DTLS to authenticate a PLC device when it enrolles itself.  If
>   the PLC device is not direct neighbor to the PANC, where the authenticate
>   is conducted, another PLC device which has joined the network can act as
>   a proxy to help exchange the authenticate messages.  The key used for
>   encryption can also be negociated via DTLS.

"Just use DTLS" doesn't really work.
Please reference 6tisch-minimal-security instead.


[Remy] You're right that we need more clarification here. We meant to use DTLS to transport the certificate to authenticate the PLC-PAN device. Alternatively, PSK(pre-shared keys) can also be used to authenticate a device as per [I.D-ietf-6tisch-minimal-security]. How about changing the text as follows:

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. Thus it is highly recommended to conduct a mutual authentication between the network and the device tending to join in it. Pre-installed certificates can be transported over DTLS to facilitate the authentication. Alternatively, as per [I.D-ietf-6tisch-minimal-security], provisioning a unique pre-shared keys (PSKs) to each PLC device is also feasible. In both cases, if the PLC device is not direct neighbor to the PANC/JRC, where the authenticate is conducted, another PLC device which has joined the network can act as a proxy to help exchange the authentication messages.
--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works  -= IPv6 IoT consulting =-