Last Call Review of draft-ietf-6lo-plc-05

Request Review of draft-ietf-6lo-plc
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2021-02-15
Requested 2021-02-01
Authors Jianqiang Hou, Bing Liu, Yong-Geun Hong, Xiaojun Tang, Charles Perkins
Draft last updated 2021-02-14
Completed reviews Tsvart Last Call review of -05 by Joseph Touch (diff)
Opsdir Last Call review of -05 by Dan Romascanu (diff)
Secdir Last Call review of -05 by Robert Sparks (diff)
Genart Last Call review of -05 by Meral Shirazipour (diff)
Assignment Reviewer Robert Sparks 
State Completed
Review review-ietf-6lo-plc-05-secdir-lc-sparks-2021-02-14
Posted at
Reviewed rev. 05 (document currently at 06)
Review result Has Issues
Review completed: 2021-02-14


I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This document has issues that should be addressed before publication as Proposed Standard RFC.

Document reviewed: draft-ietf-6lo-plc-05

This document's primary point is to standardize mappings of ipv6 identifiers for using ipv6 over IEEE 1901.1, 1901.2, and IT-T G.9903 networks.

Those standards are not publicy available, and I have not reviewed how these mappings and the security mechanisms in those protocols interact.

The document has content that is not needed for its purpose. Section 5 in particular might be useful in an informational RFC, but is has no impact on someone implementing what this document is trying to standardize.

The security considerations section speaks primarily to generic considerations for 6lo-like networks. There is no specific discussion of the impact of the identifier mappings with the underlying protocols, in particular the constraints that don't allow using the full number of bits of entropy in the identifiers in those underlying protocols. There is only a passing mention of RFC8065.

Implementors are advised to "look at" RFC8604 when considering building stable addresses, but this document specifies doing things that RFC8604 recommends against (see the use of RFC2464, for example). More discussion seems warranted. 

There is a short mention of the possibility of acquiring a network encryption key during onboarding but there's no discussion about what that means for these specific layer-2 protocols.

Editorial comments:

At section 4.6, the first paragraph can make its point more clearly. All that's needed to say is that the lower layers handle segmentation and reassembly, but the adaptation layer still needs to be ready to do so in the lower layer cant handle the 1280 octet MTU. At the last paragraph, when you say "referring to" do you mean "as specified in"?

At section 7, "For security consideration, link layer security is guaranteed in every PLC technology." needs clarification. Do you mean the three protocols discussed here provide link layer security? Or do you mean to say that if anyone plans to provide an adaptation layer to some other PLC protocol, that it must provide link layer security? Or do you mean something else? 

Nit: Expand LLN on first use.