Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-plc-06: (with DISCUSS and COMMENT)

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

Hello Benjamin,

Many thanks to your comments. Please find my response inline.

Best regards,
Remy

-----邮件原件-----
发件人: Benjamin Kaduk via Datatracker [mailto:[e-mail]]
发送时间: 2021年8月12日 1:13
收件人: The IESG <[e-mail]>
抄送: [e-mail]; [e-mail]; [e-mail]; Carles Gomez <[e-mail]>; [e-mail]
主题: Benjamin Kaduk's Discuss on draft-ietf-6lo-plc-06: (with DISCUSS and COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-6lo-plc-06: Discuss

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6lo-plc/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Further details in the COMMENT, but can we briefly discuss the apparent requirement for the PANID/NID to have a couple bits set to zero (the ones that would be U/L and Individual/Group in the resulting IID)?  It seems like (but is not entirely clear to me) this is a new requirement on the layer-2 behavior that is being imposed by the IPv6 adaptation layer, and in particular that this is setting up a scenario where certain existing layer-2 deployments would be unable to utilize the IPv6 adaptation layer, which would be a very surprising behavior for an IETF Proposed Standard.  What alternatives were explored and rejected before settling on this approach that introduces new limitations on the underlying PLC deployments?
[Remy] Thanks for raising a very good point. We wanted to make our design complying with RFC4291, i.e., to keep semantics of the U/L and the I/G bits, so that the IID can be transformed to the link layer address directly without a mapping lookup in the memory. Indeed, the design brought constraints to the layer-2, i.e., the network operator can't assign a PANID or NID with the related bits set to 1. After some research, we find that similar situations have been investigated in RFC7136, and the conclusion is that "u" and "g" bits do not have a reliable meaning in an IID except an IID generated by an IEEE MAC address. 
Quote from RFC7136, "The EUI-64 to IID transformation defined in the IPv6 addressing architecture [RFC4291] MUST be used for all cases where an IPv6 IID is derived from an IEEE MAC or EUI-64 address" (that's what we do in our draft). And " Specifications of other forms of 64-bit IIDs MUST specify how all 64 bits are set, but a generic semantic meaning for the "u" and "g" bits MUST NOT be defined.  However, the method of generating IIDs for specific link types MAY define some local significance for certain bits." Thus we decided to give two options to the PLC network operators when short link layer addresses are used to generate IIDs. Please find more details in the COMMENT part.

I mention in a few places in the COMMENT scenarios where we pull in part of the functionality from RFC 6282 and RFC 4944, e.g., the IP header compression scheme and the fragmentation format.  It seems to me that the intent is that our payload always use the RFC 4944 "dispatch" scheme and that we only use a subset of (and only sometimes?) the particular functionality that RFC 4944/6282 can dispatch to.  But the current text doesn't mention the dispatch behavior at all, so it's hard for me to be certain that my understanding is correct.  It seems that some more explicit treatment in the document of how what we are specifying interacts with/uses the RFC 4944 dispatch layer would be important in order for someone to be able to implement from this document.
[Remy] Your understanding is correct. Please find more details below.

I support Roman and Éric's Discusses.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 4.1

   Since the derived Interface ID is not global, the "Universal/Local"
   (U/L) bit (7th bit) and the Individual/Group bit (8th bit) MUST both
   be set to zero.  In order to avoid any ambiguity in the derived
   Interface ID, these two bits MUST NOT be used to generate the PANID
   (for IEEE 1901.2 and ITU-T G.9903) or NID (for IEEE 1901.1).  In
   other words, the PANID or NID MUST always be chosen so that these
   bits are zeros.

Is this a new requirement on the PANID/NID not already imposed by the underlying specifications?  If so, it seems that it presents a limitation on the ability of already deployed PLC networks to adopt this
IPv6 adaptation layer.
[Remy] As discussed above, we realized that the constraint was too strong. And we decide to give right to the network operators to decide whether to assign local significance to these bits in a PLC network or not. If the operator decides to do so, these two bits MUST be set to zero and the IID can be transformed into short link layer address directly. If not, the operator must keep in mind that these bits don't have specific meaning and the IID cannot be transformed back into a short link layer address via a reverse operation.

   For privacy reasons, the IID derived from the MAC address SHOULD only
   be used for link-local address configuration.  A PLC host SHOULD use
   the IID derived from the link-layer short address to configure the
   IPv6 address used for communication with the public network;
   otherwise, the host's MAC address is exposed.  As per [RFC8065], when
   short addresses are used on PLC links, a shared secret key or version
   number from the Authoritative Border Router Option [RFC6775] can be
   used to improve the entropy of the hash input, thus the generated IID
   can be spread out to the full range of the IID address space while
   stateless address compression is still allowed.

The phrasing "derived from" is a little ambiguous to me, since it can encompass procedures ranging from the "flip the U/L bit and append PLC IID to the network's prefix" procedure to RFC 7217-style stable but opaque IIDs that incorporate the MAC address into the pseudorandom function's inputs.  Given the follow-up text about "host's MAC address is exposed", it feels like this is implying more of the former procedure.  Wouldn't the latter type of procedure be preferred, though (as implied by the "hash input" in the last sentence)?  In particular, the last sentence seems to imply that there is *always* a hash input, which is at odds with the "former" interpretation that I present for "derived from".  I'm not confident that I understand the intent of this paragraph.
[Remy] It refers to the former procedure. The intent of this paragraph is: using an IID derived from the "padding and bits flipping of MAC address" in an IPv6 address other than the link-local address has privacy issues. And padding the short link layer address to obtain an IID for a public IPv6 address may be vulnerable to deal with address scans. Thus the hash method is used to increase the entropy of the IID. Please refer to my discussion with Dave.

Section 4.3.1

   In order to avoid the possibility of duplicated IPv6 addresses, the
   value of the NID MUST be chosen so that the 7th and 8th bits of the
   first byte of the NID are both zero.

As above, it's not clear that the NID is something that this adaptation layer can assert control over.
[Remy] The adaptation layer doesn't have direct control of the link layer. We should have the NID first, then we can generate the IID accordingly. However, as specified above, the operator of the PLC network have right to decide the way to assign the NID.

Section 4.3.2

   In order to avoid the possibility of duplicated IPv6 addresses, the
   value of the PAN ID MUST be chosen so that the 7th and 8th bits of
   the first byte of the PAN ID are both zero.

(likewise)

Section 4.5

   The compression of IPv6 datagrams within PLC MAC frames refers to
   [RFC6282], which updates [RFC4944].  Header compression as defined in
   [RFC6282] which specifies the compression format for IPv6 datagrams
   on top of IEEE 802.15.4, is the basis for IPv6 header compression in
   PLC.  For situations when PLC MAC MTU cannot support the 1280-octet
   IPv6 packet, headers MUST be compressed according to [RFC6282]
   encoding formats.

RFC 6282 refers to both a "Dispatch" value and the LOWPAN_IPHC header compression encoding.  I strongly suggest clarifying whether both, or just LOWPAN_IPHC, is used.
[Remy] The dispatch and the LOWPAN_IPHC are both used. We can add clarifications.

   For IEEE 1901.2 and G.9903, the IP header compression follows the
   instruction in [RFC6282].  However, additional adaptation MUST be
   considered for IEEE 1901.1 since it has a short address of 12 bits
   instead of 16 bits.  The only modification is the semantics of the
   "Source Address Mode" when set as "10" in the section 3.1 of
   [RFC6282], which is illustrated as following.

Is there anything useful to say about how carrying 12 vs 16 bits affects byte alignment of the overal compressed message?  A quick survey of RFC
6282 finds many items that retain byte alignment, and I didn't actually find anything that left the encoded bit stream in a non-aligned state.
[Remy]Thanks for indicating this item. The residue with indicator "10" in SAM and DAM for IEEE 1901.1 should also be 16 bits to keep byte alignment with the lower 12 bits be the TID, and the higher 4 bits padded which don't have specific meaning.

   SAM: Source Address Mode:

I see that RFC 6282 also has procedures for Destination Address Mode (DAM), including a scenario that involves conveying a 16-bit address component.  Do we need to treat that DAM analogously to how we treat the SAM here?  (This might also handle the byte alignment question from my previous remark...) 
[Remy] DAM also needs compression in the same way. A specific clarification will be added.


Section 4.6

   In IEEE 1901.1 and IEEE 1901.2, the MAC layer supports payloads as
   big as 2031 octets and 1576 octets respectively.  However when the
   channel condition is noisy, it is possible to configure smaller MTU
   at the MAC layer.  If the configured MTU is smaller than 1280
   octects, the fragmentation and reassembly defined in [RFC4944] MUST
   be used.

Does this imply that implementing the IPv6 adaptation layer
fragmentation+reassembly logic is mandatory for implementations of IPv6
over IEEE 1901.1 and 1901.2, since the implementation might be configured in a way that requires that support?  Please be clear about what is required of implementations and in what circumstances.
[Remy] The default MTUs of IEEE1901.1 and IEEE 1901.2 don't require fragmentation and reassembly at the adaptation layer. However, when the network channel condition is noisy, e.g. when the inference is strong, the PLC devices can be configured to have smaller MTU. When the MTU is configured to be below 1280 octets, the fragmentation and reassembly of the adaptation layer must be enabled.

Also, as above, please be clear about the interaction with the RFC 4944 dispatch layer.

Section 5

   node; PAN Devices are typically PLC meters and sensors.  The PANC
   also serves as the Routing Registrar for proxy registration and DAD
   procedures, making use of the updated registration procedures in
   [RFC8505].  IPv6 over PLC networks are built as tree, mesh or star

If the PANC always serves as the Routing Registrar (and thus the RFC
8505 procedures are always used), why do we allow for both RFC 6775 and
8505 DAD procedures up in §4.4?
[Remy] There is a misunderstanding here. The PANC can be the 6LBR in RFC6775, or a routing registrar in RFC 8505. In section 4.4, the one of the two DAD procedures is used, not both of them.

Section 8

We should probably incorporate by reference the security considerations of the documents whose technologies we are adopting.
[Remy] Will check if we have something missing that applies to PLC network.
One might hope that it goes without saying, but it's nonetheless probably worth noting that the PANC, being in a position to observe all traffic, is necessarily a trusted entity.
[Remy] Yes, that's why we need mutual authentication. The onboarding PLC devices should authenticate the network it is joining in. 

   Due to the high accessibility of power grid, PLC might be susceptible
   to eavesdropping within its communication coverage, e.g., one
   apartment tenant may have the chance to monitor the other smart
   meters in the same apartment building.  Thus link layer security
   mechanisms are designed in the PLC technologies mentioned in this
   document.

Key management for these security mechanisms will of course be quite important.  IoT devices are notoriously vulnerable to physical attacks and key extraction, so there may be something useful to say about the importance of key management and what is exposed if the key material available to a single device is compromised.
[Remy] That's a good point. Will add related description. If the physical attacks is considered to be relatively highly possible, several mechanisms can be used together to limit the affected radius. For example, per device credential, or behavior analysis to detect malicious devices. 

It's quite hard to make an evaluation of the actual security properties provided by the link-layer mechanisms without access to the actual specification documents for those technologies.  I'd actually seriously consider adding another clause that "and additional end-to-end security services can be used for sensitive traffic and as additional protection against compromised PLC nodes" (or something in that general vein).
[Remy] "Additional end-to-end security services" is a complementary to the network side security mechanisms. E.g. if a devices is compromised and it has joined in the network, and then it claims itself as the PANC and try to make the rest devices join its network, in this situation, the real PANC can send an alarm to the operator to acknowledge the risk.
Additionally, it's often the case that the link-layer security mechanisms involve group-shared symmetric keys, so that a compromise of even a single device puts the entire network, or a large chunk of the network, at risk.  If this is the case for the PLC link layers, it seems imperative to mention that risk in this document.
[Remy] Will add related description. 

   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

Is there potential for interfering with/corrupting legitimate traffic as a DoS vector, as well?
[Remy] We mentioned the DOS attack based on the control plane messages. And the DoS attack could be based on the data plane messages, but only when the malicious device has joined in the network, and it can sends spoofed messages which cause the system to take wrong actions.

   illegal users.  Mutual authentication of network and new device can
   be conducted during the onboarding process of the new device.
   Methods include protocols such as [RFC7925] (exchanging pre-installed
   certificates over DTLS) , [I-D.ietf-6tisch-minimal-security] (which
   uses pre-shared keys), and
   [I-D.ietf-6tisch-dtsecurity-zerotouch-join] (which uses IDevID and
   MASA service).  It is also possible to use EAP methods such as
   [I-D.ietf-emu-eap-noob] via transports like PANA [RFC5191].  No
   specific mechanism is specified by this document as an appropriate
   mechanism will depend upon deployment circumstances.

Would SZTP (RFC 8572) be applicable for these scenarios?
(Also, I would recognize "BRSKI" more than "IDevID and [a] MASA service", though I don't know if I am the right population to be sampling for readibility data.)

[Remy] RFC 8572 is based on netconf and restconf, which could be too heavy for PLC devices, whose transportation layer is often UDP. However, the PANC, with higher processing capabilities, could implement RFC 8572 to achieve the "secure and zero-touch configuration" feature. [I-D.ietf-6tisch-dtsecurity-zerotouch-join] can be considered as a light version of BRSKI, an alias can be used in this sentence to make it more recognizable.
	
   scanning.  Schemes such as limited lease period in DHCPv6 [RFC3315],
   Cryptographically Generated Addresses (CGAs) [RFC3972], privacy
   extensions [RFC4941], Hash-Based Addresses (HBAs) [RFC5535], or
   semantically opaque addresses [RFC7217] SHOULD be considered to
   enhance the IID privacy.

"SHOULD be considered" is a fairly weak guidance; I would think that "SHOULD be used" would be more consistent with the IETF consensus position, while still leaving ample space for other behaviors.
[Remy] Good idea. 

Section 10.2

I would consider classifying RFC 4291 as normative.

NITS

   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

"Advantage" typically implies a comparison with some other thing or things as measured on a particular axis or axes.  While one might presume that this refers to the advantages of using existing wires over new wires in terms of cost and ease of deployment, it's probably worth stating it more clearly.

Section 1

   century.  With the advantage of existing power grid, Power Line
   Communication (PLC) is a good candidate for supporting various
   service scenarios such as in houses and offices, in trains and

As above, what is "the advantage of existing power grid"?
[Remy] PLC devices utilizes the existing cables of the power grid to transmit messages, thus there is no need to add cables.

Section 2

   PANC: PAN Coordinator, a coordinator which also acts as the primary
         controller of a PAN.

PAN is not marked as "well-known" at
https://www.rfc-editor.org/materials/abbrev.expansion.txt (in fact, is not even defined there), and thus should get its own expansion.

Section 4.4

   information in the replied Neighbor Advertisements from the 6LR.  If
   DHCPv6 is used to assign addresses or the IPv6 address is derived
   from unique long or short link layer address, Duplicate Address
   Detection (DAD) MUST NOT be utilized.  Otherwise, the DAD MUST be
   performed at the 6LBR (as per [RFC6775]) or proxied by the routing
   registrar (as per [RFC8505]).  The registration status is feedbacked
   via the DAC or EDAC message from the 6LBR and the Neighbor
   Advertisement (NA) from the 6LR.

A few words on how the 6LR+6LBR must know whether 6775 or 8505 is in use on the network, and thus there is no ambiguity about which entity is performing DAD, might be helpful.

Section 4.5

   10:   12 bits.  The first 116 bits of the address are elided.The
         value of the first 64 bits is the link-local prefix padded with

spaces after the sentence break.

Section 5

   [RFC8505].  IPv6 over PLC networks are built as tree, mesh or star
   according to the use cases.  Generally, each PLC network has one

I think "as a tree, mesh or star topology"

   the size of PLC networks.  A simple use case is the smart home
   scenario where the ON/OFF state of air conditioning is controlled by
   the state of home lights (ON/OFF) and doors (OPEN/CLOSE).  AODV-RPL

Almost all the other examples in the document refer to PLC meters or sensors (mostly meters), so the "smart home" scenario sticks out as being rather different when only mentioned in passing like this.  I don't question the conclusion, but the overall writing style of the document might be improved if we introduced this scenario earlier on so that it was a more continual theme.

   enables direct PAN device to PAN device communication, without being
   obliged to transmit frames through the PANC, which is a requirement
   often cited for AMI infrastructure.

The only earlier mention of AODV-RPL was in §3.4; we might consider repeating the reference here in case the reader missed it the previous time.

Section 6

   self-managed.  The software or firmware is flushed into the devices

s/flushed/flashed/?

   before deployment by the vendor or operator.  And during the
   deployment process, the devices are bootstrapped, and no extra
   configuration is needed to get the device connected to each other.

s/device/devices/

   gateway.  The recently-formed iotops WG in IETF is aming to design
   more features for the management of IOT networks.

s/aming/aiming/
Also, a reference to the WG's datatracker page might be worthwhile.

Section 8

   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

I think s/multicast/sending/multicast/

   also join a wrong or even malicious network, exposing its data to
   illegal users.  Mutual authentication of network and new device can

Maybe "inadvertently join"?

   IP addresses may be used to track devices on the Internet; such
   devices can in turn be linked to individuals and their activities.

I think s/can in turn/can often in turn/.  There are some IoT devices that are basically uncorrelated to individual humans.

   Cryptographically Generated Addresses (CGAs) [RFC3972], privacy
   extensions [RFC4941], Hash-Based Addresses (HBAs) [RFC5535], or

RFC 4941 has been obsoleted by RFC 8981.