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

"Liubing (Remy)" <remy.liubing@huawei.com> Thu, 01 April 2021 09:00 UTC

Return-Path: <remy.liubing@huawei.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25DD13A10FE for <6lo@ietfa.amsl.com>; Thu, 1 Apr 2021 02:00:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level:
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATAiq2oP4I5s for <6lo@ietfa.amsl.com>; Thu, 1 Apr 2021 02:00:31 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E41653A10FF for <6lo@ietf.org>; Thu, 1 Apr 2021 02:00:30 -0700 (PDT)
Received: from fraeml712-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4F9xjv2CKwz67y9v; Thu, 1 Apr 2021 16:51:15 +0800 (CST)
Received: from dggpeml500010.china.huawei.com (7.185.36.155) by fraeml712-chm.china.huawei.com (10.206.15.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 1 Apr 2021 11:00:25 +0200
Received: from dggpeml500011.china.huawei.com (7.185.36.84) by dggpeml500010.china.huawei.com (7.185.36.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 1 Apr 2021 17:00:23 +0800
Received: from dggpeml500011.china.huawei.com ([7.185.36.84]) by dggpeml500011.china.huawei.com ([7.185.36.84]) with mapi id 15.01.2106.013; Thu, 1 Apr 2021 17:00:23 +0800
From: "Liubing (Remy)" <remy.liubing@huawei.com>
To: Shwetha <shwetha.bhandari@gmail.com>
CC: "6lo@ietf.org" <6lo@ietf.org>, Erik Kline <ek.ietf@gmail.com>, Carles Gomez Montenegro <carlesgo@entel.upc.edu>
Thread-Topic: [6lo] Secdir last call review of draft-ietf-6lo-plc-05
Thread-Index: Adcm1XF/Fq8RKx3AYUa1Z461zZuABQ==
Date: Thu, 01 Apr 2021 09:00:23 +0000
Message-ID: <f114700e8552454b9699cf4980c13f24@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.242.194]
Content-Type: multipart/alternative; boundary="_000_f114700e8552454b9699cf4980c13f24huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/ooSfbpLEl2QsMP1Mx6JlgXvxd0Y>
Subject: Re: [6lo] Secdir last call review of draft-ietf-6lo-plc-05
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Apr 2021 09:00:36 -0000

Hello Shwetha,

Thanks for the comments. As mentioned in the mail with Robert, we will change the sentence to the followings:

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.


1.  A cleanup of references for security and privacy considerations is needed : 7217, 8981, 8065 should suffice?
[Remy] We can update the reference to RFC4941 into RFC8981. For the others, if there are some overlaps, we can have a shorter list. Could you help indicate some specific overlaps?
2. Do we need the reference to SeND RFC 3972?
[Remy] Do you mean RFC3971?

Best regards,
Remy
发件人: Shwetha [mailto:shwetha.bhandari@gmail.com]
发送时间: 2021年3月28日 16:29
收件人: Liubing (Remy) <remy.liubing@huawei.com>
抄送: 6lo@ietf.org; Erik Kline <ek.ietf@gmail.com>; Carles Gomez Montenegro <carlesgo@entel.upc.edu>
主题: Re: [6lo] Secdir last call review of draft-ietf-6lo-plc-05

Following up on this, from the discussion at IETF 110:
The privacy and security considerations in the PLC drafts:
Specifically:

[RFC3315], [RFC3972], [RFC4941],
   [RFC5535], [RFC7217], and [RFC8065] provide valuable information for IID formation with improved privacy, and are RECOMMENDED for IPv6 networks.

1. A cleanup of references for security and privacy considerations is needed : 7217, 8981, 8065 should suffice?
2. Do we need the reference to SeND RFC 3972?

Thanks
Shwetha

Tue, 09 March 2021 03:30 UTCShow header

Hello Robert,

Thank you for your reply. Please find my text inline.

Best regards,
Remy
-----邮件原件-----
发件人: Robert Sparks [mailto:rjsparks@nostrum.com<mailto:rjsparks@nostrum.com>]
发送时间: 2021年3月5日 23:58
收件人: Liubing (Remy) <remy.liubing@huawei.com<mailto:remy.liubing@huawei.com>>om>; secdir@ietf.org<mailto:secdir@ietf.org>
抄送: 6lo@ietf.org<mailto:6lo@ietf.org>; draft-ietf-6lo-plc.all@ietf.org<mailto:draft-ietf-6lo-plc.all@ietf.org>; last-call@ietf.org<mailto:last-call@ietf.org>
主题: Re: Secdir last call review of draft-ietf-6lo-plc-05

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:noreply@ietf.org<mailto:noreply@ietf.org>]
> 发送时间: 2021年2月15日 6:50
> 收件人: secdir@ietf.org<mailto:secdir@ietf.org>
> 抄送: 6lo@ietf.org<mailto:6lo@ietf.org>; draft-ietf-6lo-plc.all@ietf.org<mailto:draft-ietf-6lo-plc.all@ietf.org>; last-call@ietf.org<mailto:last-call@ietf.org>
> 主题: 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.

[Remy] The problem has been solved in RFC8065 (designed in 6lo), when short addresses (the 16 or 12 bits link layer address) 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. We will update the draft to change the reference to RFC8064 into the reference to RFC8065, and specify the solution in section 4.1 instead of the security considerations.
>
> 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.
>