Hello Roman, Thanks to your comments.
Please find the response inline. Remy -----邮件原件----- 发件人: Roman Danyliw via Datatracker [mailto:[email protected]] 发送时间: 2021年8月10日 6:21 收件人: The IESG <[email protected]> 抄送: [email protected]; [email protected]; [email protected]; Carles Gomez <[email protected]>; [email protected] 主题: Roman Danyliw's Discuss on draft-ietf-6lo-plc-06: (with DISCUSS and COMMENT) Roman Danyliw 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: ---------------------------------------------------------------------- ** Section 8. A few additional threats should be mentioned. Note that a robust treatment is not needed here (and likely not possible due to the generality of this document). However, they should be acknowledged. -- This section mentions both availability (DoS) and confidentiality (eavesdropping) concerns. Thank you. Wouldn’t there also be the possibility of significant integrity risks given that possible actuators or sensors being controlled? Note if the referenced link layer security mechanisms would be useful. [Remy] First of all, all the PLC devices try to join in the network should be authenticated. After that, an onboarded device can communicate with other devices in the PLC network. Protecting a network under attack is not the responsibility of a single layer of the network. As to the situation you mentioned, sensors being controlled, if the sensor is a legal device from the perspective of the link layer, the link layer security mechanisms are not helpful. In this case, higher layer mechanisms can be used, such as authentication of credentials or analysis of the application layer behaviors. -- Figures 5 – 7 seems to present architectures which connects operational technology to the Internet via the PANC. However, this section doesn’t acknowledgement of that risk outright or by citation. ** Section 8. Per “Thus link layer security mechanisms are designed in the PLC technologies mentioned in this document”, which specific mechanisms were being cited is not clear. Is their use required or are they use case dependent? [Remy] The link layer security for each PLC technology is defined in their individual standards, and is out of scope for this draft. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Robert Sparks for the SECDIR review. ** Section 6. Per “The onboard status of the devices and the topology of the PLC network can be visualized via the gateway”, this is the first the architectural element of a “gateway” is mentioned. What does it mean to “visualize via the gateway”? [Remy]You're right. The term "gateway" should be changed to "PANC". Since the PANC acts as the controller of the PLC network, and it is in charge of the authentication of the onboarding devices, the link layer address allocation and build routes to the devices, the PANC is aware of all the information above. Thus the operator can check the information via CLI or a remote dashboard visualizing it. ** Section 6. Per “The recently-formed iotops WG in IETF is aming to design more features for the management of IOT networks”, I don’t follow the intent of this sentence as IOTOPS is not chartered for new protocol work (only requirements and operational practices). [Remy] Good point. This sentence needs to be more accurate. How about " The recently-formed iotops WG in IETF is aiming to identify the requirements in IoT network management, and operational practices will be published. Developers and operators of PLC networks should be able to learn operational experiences from this WG."? ** Editorial nits -- Section 1. Typo. s/efficent/efficient/ -- Section 4.4. Typo. s/Solicitaitons/ Solicitations/ -- Section 4.5. s/elided.The/elided. The/ -- Section 4.6. Typo. s/octects/octets/ -- Section 4.6. Typo. s/constranied/constrained/ -- Section 4.6. Typo. s/fragements/fragments/ -- Section 6. s/aming/aiming/ [Remy] Will fix these typos. Thanks. _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
