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

From: Liyizhou <[email-masked]>
Date: Sat, 2 May 2020 04:45:20 +0000

Hi all,

I am fine with the updated version. Thanks to the authors.

Rgds,
Yizhou

-----Original Message-----
From: Carles Gomez Montenegro [mailto:[email-masked]] 
Sent: Thursday, April 30, 2020 11:38 PM
To: Liubing (Remy) <[email-masked]>
Cc: [email-masked]; Michael Richardson <[email-masked]>; Liyizhou <[email-masked]>
Subject: Re: [6lo] FW: I-D Action: draft-ietf-6lo-plc-03.txt

Hello,

Thanks a lot to Michael and Yizhou for providing comments, and thanks also to the authors for updating the draft!

Michael, Yizhou: could you please let us know whether the last draft update addresses your comments satisfactorily?

Gentle reminder for the WG: the WGLC for this document ends on Monday, 4th of May. Please provide your opinions/comments on the document, even if it is just a short "looks good", by the due date.

Thanks,

Shwetha and Carles

> Hello 6lo,
>
> We've updated the draft according to Michael and Yizhou's comments.
>
> Please let us know your opinion on this latest version.
>
> Many thanks.
>
> Remy
>
> -----ÓÊ¼þÔ­¼þ-----
> ·¢¼þÈË: 6lo [mailto:[email-masked]] ´ú±í 
> [email-masked]
> ·¢ËÍÊ±¼ä: 2020Äê4ÔÂ30ÈÕ 10:56
> ÊÕ¼þÈË: [email-masked]
> ³ËÍ: [email-masked]
> Ö÷Ìâ: [6lo] I-D Action: draft-ietf-6lo-plc-03.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the IPv6 over Networks of 
> Resource-constrained Nodes WG of the IETF.
>
>         Title           : Transmission of IPv6 Packets over PLC Networks
>         Authors         : Jianqiang Hou
>                           Bing Liu
>                           Yong-Geun Hong
>                           Xiaojun Tang
>                           Charles E. Perkins
> 	Filename        : draft-ietf-6lo-plc-03.txt
> 	Pages           : 19
> 	Date            : 2020-04-29
>
> Abstract:
>    Power Line Communication (PLC), namely using the electric-power lines
>    for indoor and outdoor communications, has been widely applied to
>    support Advanced Metering Infrastructure (AMI), especially smart
>    meters for electricity.  The inherent advantage of existing
>    electricity infrastructure facilitates the expansion of PLC
>    deployments, and moreover, a wide variety of accessible devices
>    raises the potential demand of IPv6 for future applications.  This
>    document describes how IPv6 packets are transported over constrained
>    PLC networks, such as ITU-T G.9903, IEEE 1901.1 and IEEE 1901.2.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6lo-plc/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-6lo-plc-03
> https://datatracker.ietf.org/doc/html/draft-ietf-6lo-plc-03
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-plc-03
>
>
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at 
> tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/

---

From: Michael Richardson <[email-masked]>
Date: Sat, 16 May 2020 19:39:15 -0400

Hi, I have reviewed the changes from 02 to 03.
I had suggested that the term PLC Device be used consistently, and I see
that.
At the end of the first paragraph of 3.2, "PANC" is used which surprised me,
but I see it in the glossary.  I'm not sure if you want to add "JRC"
to the list of aliases for PANC.

Thank you for mentioning 6tisch-minimal-security.
There is also a BRSKI-like 6tisch mechanism that uses IDevID.

Is it the case that the PLC devices can have no L2 security as an option?
I believe that you may wish to outlaw that situation.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Liubing (Remy)" <[email-masked]>
Date: Wed, 20 May 2020 07:46:16 +0000

Hello Michael,

Sorry for this late reply. Thank you for your review.

Please see my response below.

Best regards,
Remy

-----邮件原件-----
发件人: 6lo [mailto:[email-masked]] 代表 Michael Richardson
发送时间: 2020年5月17日 7:39
收件人: [email-masked]
抄送: Liubing (Remy) <[email-masked]>; Carles Gomez Montenegro <[email-masked]>; Liyizhou <[email-masked]>
主题: Re: [6lo] FW: I-D Action: draft-ietf-6lo-plc-03.txt

Hi, I have reviewed the changes from 02 to 03.
I had suggested that the term PLC Device be used consistently, and I see that.
At the end of the first paragraph of 3.2, "PANC" is used which surprised me, but I see it in the glossary.  I'm not sure if you want to add "JRC"
to the list of aliases for PANC.
[Remy] I can add the full name in 3.2. "PAN Coordinator" is a term that is inherited form the PLC standards. We wanted to abbreviate it as "PCO", but PCO refer to "proxy coordinator" in IEEE 1901.1. Thus we use PANC instead. Do you have any suggestion on this abbreviation? In term of the functionality during the joining process, JRC is an alias of the PAN coordinator.

Thank you for mentioning 6tisch-minimal-security.
There is also a BRSKI-like 6tisch mechanism that uses IDevID.
[Remy] I think you must be talking about [draft-ietf-6tisch-dtsecurity-zerotouch-join]. The minimal security is considered to be one-touch since the PSK has to be configured a priori. And this document provides a zero-touch method, in which the IDevID (provided by the manufacturer) in 802.1AR is used as the credential for authentication. The authentication is done with the help of the MASA. Am I understanding it correctly? I think the method simplifies the provisioning procedure. However, the PLC standards have not supported 802.1AR yet, thus this zero-touch method couldn't be used in the implementation at this moment.

[Remy] All the PLC standards we mentioned in this document have L2 security mechanisms, such as encryption, data integrity, and anti-replay. Since this document is focused on the adaptation layer and above, the L2 security is considered to be applied by default. 
--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 May 2020 11:09:32 -0400

Liubing (Remy) <[email-masked]> wrote:
    > Thank you for mentioning 6tisch-minimal-security.  There is also a
    > BRSKI-like 6tisch mechanism that uses IDevID.

    >   [Remy] I think you must
    > be talking about [draft-ietf-6tisch-dtsecurity-zerotouch-join]. The
    > minimal security is considered to be one-touch since the PSK has to be
    > configured a priori. And this document provides a zero-touch method, in
    > which the IDevID (provided by the manufacturer) in 802.1AR is used as
    > the credential for authentication. The authentication is done with the
    > help of the MASA. Am I understanding it correctly? I think the method
    > simplifies the provisioning procedure. However, the PLC standards have
    > not supported 802.1AR yet, thus this zero-touch method couldn't be used
    > in the implementation at this moment.

Whether or not the *PLC* documents specify 802.1AR is not really relevant.
They also don't specify any useful secure join mechanism at all.

The device either has a manufacturer provided keypair, or it has to be
provisioned with a key by the operator.

    > Is it the case that the PLC devices can have no L2 security as an
    > option?  I believe that you may wish to outlaw that situation.

    > [Remy] All the PLC standards we mentioned in this document have L2
    > security mechanisms, such as encryption, data integrity, and
    > anti-replay. Since this document is focused on the adaptation layer and
    > above, the L2 security is considered to be applied by default.

Then uou can use dtsecurity-zerotouch-join or 6tisch-minimal-security.