Re: [6lo] Intdir telechat review of draft-ietf-6lo-plc-06

["Liubing (Remy)" <[e-mail]>]

Hello Dave,

Many thanks to your comments. It helps a lot. We will include the modifications in the next version.

Please see our feedback below.

Best regards,
Remy

-----邮件原件-----
发件人: Dave Thaler via Datatracker [mailto:[e-mail]] 
发送时间: 2021年8月7日 10:03
收件人: [e-mail]
抄送: [e-mail]; [e-mail]; [e-mail]
主题: Intdir telechat review of draft-ietf-6lo-plc-06

Reviewer: Dave Thaler
Review result: Almost Ready

I am an assigned INT directorate reviewer for draft-ietf-6lo-plc-06.txt. These comments were written primarily for the benefit of the Internet Area Directors.
Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

Overall I found the document to be fairly well written and understandable. 
There were a couple of areas though where I think additional elaboration is needed.

Technical comments:

1) Page 8 talks about "the" IPv6 address used for communication with the public network, implying there can only be one at a time.  This is not normal in IPv6, where you can have a public address, the current temporary address, and the previous temporary address (to allow for transition to a new one), all at the
same time.   Should this be changed to be plural?  If not, how do you support
privacy addresses in IPv6?  What about cases where you have external connectivity to two public networks each with its own prefix?  I don't see this answered anywhere in the doc.
[Remy] You're right about that. Actually we don't prevent to have multiple IPv6 addresses at the same time. We will change it to plural.

2) Page 8 also mentions that a shared secret "or" version number can be used in a hash to derive an IID, but never defines any hash details.  To me, that implies that this document currently does not provide any guarantee of interoperability, in which case why do you need an IETF RFC at all if every device has to come from the same vendor with an algorithm not specified in the
standard?   I expected this document to specify the details of a hash algorithm
that must be implemented.
[Remy] That's a good suggestion. We suggest to use SHA256 as the hash algorithm, and the version number, the PANID/NID and the short address as the input arguments. Then the 256 bits hash output is truncated by taking the high 64 bits.

3) RFC 8065 explains that privacy of IPv6 link-local addresses is typically uninteresting because on broadcast media all devices can see all the link-layer
addresses and mappings anyway.   At least in the star and tree topologies, I
suspect this is not the case.   However the document doesn't seem to contain
any discussion of the privacy considerations in such a case.
[Remy] The different topologies don't require additional considerations. The topology of the PLC network is decided by the link condition and distance between the devices. Only if a device can hear from another and the link condition is good enough, the two devices are "linked". In star and tree topology, a device may be able to hear a part of the network. For this partition of the network, the privacy of IPv6 link-local addresses is uninteresting. For the rest of the network, the link layer address and IPv6 link local address is not visible to this specific device.

4) RFC 8065 section 4 provides a checklist of what adaptation layer documents like this need to address. I'd recommend addressing each point separately in the Security Considerations section, so it's clear that the draft addresses the whole checklist.  For example, there's nothing in the document that mentions what the typical link lifetime is (years maybe?) As another example, it's really hard to tell from reading the last paragraph of section 4.5 of this draft how it addresses RFC 8065's statement that "any specification using Short Addresses should carefully construct an IID generation mechanism so as to provide sufficient entropy compared to the link lifetime" so elaboration here is warranted here in my opinion.
[Remy] Consider a PLC network with 1024 devices and its link lifetime is 8 years, according to the formula in RFC8065, an entropy of 40 bits is sufficient. Padding the short address (12 or 16 bits) to generate the IID of a routable IPv6 address in the public network may be vulnerable to deal with address scans. Thus As explained in the comment #2, a hash function can be used to generate a 64 bits IID. When the version number of the PLC network is changed, the IPv6 addresses can be changed as well. In another way, the IPv6 addresses can be assigned and changed via DHCP. In a normal situation, a PLC device doesn't "roam". The device leaves the network first and joins in another. And the short address and the IPv6 address should change during this process.

I also have some editorial nits that can be found in a marked up copy at https://www.microsoft.com/en-us/research/uploads/prod/2021/08/draft-ietf-6lo-plc-06.pdf

Dave