Inline.
On 3/4/21 9:49 PM, Liubing (Remy) wrote:
Hello Robert,
Thank you very much for your comments. It helps a lot.
Please see our response inline.
Best regards,
Remy
-----邮件原件-----
发件人: Robert Sparks via Datatracker [mailto:[email protected]]
发送时间: 2021年2月15日 6:50
收件人: [email protected]
抄送: [email protected]; [email protected]; [email protected]
主题: Secdir last call review of draft-ietf-6lo-plc-05
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.
[Remy] Yes, this section is more like informational. We'll ask the WG if we
should remove it or not.
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.
[Remy] We would like to extend the description as follows: RFC8065 discusses
the privacy threats when interface identifiers (IID) are generated without
sufficient entropy, including correlation of activities over time, location
tracking, device-specific vulnerability exploitation, and address 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. 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.
Do you think it solves the issue?
It's better, yes, but I hope people with more expertise and experience
with the recommendations than me look closely at it.
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.
[Remy] In the same paragraph we reference RFC8604, we limit the usage of MAC
generated IID as per RFC2464 in link-local address configuration.
Well, that's my point - I think RFC8064 (sorry for my original typo
above) recommends NOT to do the things in 2464 that you are saying to
do. I could be wrong. But having clearer text noting how what you are
requiring avoids the issues 8064 brings up would help. Again, I hope
people with more expertise than me look closely here.
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.
[Remy] The acquirement of layer-2 encryption key is specified in the IEEE and
ITU-T standards and not related to the authentication process in the same
paragraph. Thus this phrase is redundant, and we prefer to remove this phrase.
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"?
[Remy] That's a good point. We would like to simplify the first paragraph of
the section 4.6 as follows: PLC MAC layer provides the function of segmentation
and reassembly, however, Fragmentation and reassembly is still required at the
adaptation layer, if the MAC layer cannot support the minimum MTU demanded by
IPv6, which is 1280 octets.
Yes, we will change it to "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?
[Remy] We meant that link layer security mechanisms are designed in these three
PLC technologies. We will rephrase it.
Nit: Expand LLN on first use.
[Remy] Will update it.
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
