Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-6lo-plc-05

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 12 Aug 2021 12:25:36 -0700

Hi Robert,

Many thanks for this review; I entered a discuss ballot for some of the
topics you identified.

-Ben

On Sun, Feb 14, 2021 at 02:50:09PM -0800, Robert Sparks via Datatracker wrote:
> Reviewer: Robert Sparks
> Review result: Has Issues
> 
> 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.
> 
> 
> -- 
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call