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

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Apr 2020 12:05:11 -0400

Some comments/nits:
1) update your RFC2119 text to tbe BCP14 template.

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}

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.

5) comma after "e.g." -> "e.g.," {don't ask me why}

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.

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]"

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.

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.

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

---

From: "Liubing (Remy)" <[email-masked]>
Date: Tue, 28 Apr 2020 08:28:14 +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:[email-masked]] 代表 Michael Richardson
发送时间: 2020年4月24日 0:05
收件人: [email-masked]
主题: [6lo] comments on on draft-ietf-6lo-plc-02

Some comments/nits:
[Remy] Will do.

2) change:
Compared to

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.

[Remy] You're right :)

to:

[Remy] Good suggestion.

[Remy] Lesson learnt.

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,

9) section 3.2:
[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].

Rewrite to say:

11) section 4.4

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.

[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 <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-