Re: [secdir] Secdir last call review of draft-wu-l3sm-rfc8049bis-05

Qin Wu <> Thu, 28 September 2017 03:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C82E1352A4; Wed, 27 Sep 2017 20:59:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CFRUfp_FlOXQ; Wed, 27 Sep 2017 20:59:06 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 30C491352A0; Wed, 27 Sep 2017 20:59:05 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id DWK41398; Thu, 28 Sep 2017 03:59:03 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 28 Sep 2017 04:58:55 +0100
Received: from ([]) by ([]) with mapi id 14.03.0235.001; Thu, 28 Sep 2017 11:58:49 +0800
From: Qin Wu <>
To: Rifaat Shekh-Yusef <>, "" <>
CC: "" <>, "" <>
Thread-Topic: Secdir last call review of draft-wu-l3sm-rfc8049bis-05
Thread-Index: AQHTN5R+aJprcuiMT0iB9NGywBubdqLJorXQ
Date: Thu, 28 Sep 2017 03:58:48 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.59CC7387.0095, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 3fd39385ea9c265b2788f43232f87fa5
Archived-At: <>
Subject: Re: [secdir] Secdir last call review of draft-wu-l3sm-rfc8049bis-05
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 28 Sep 2017 03:59:07 -0000

Thank Rifaat to review this document, please see my replies inline below.

发件人: Rifaat Shekh-Yusef [] 
发送时间: 2017年9月27日 21:28
主题: Secdir last call review of draft-wu-l3sm-rfc8049bis-05

Reviewer: Rifaat Shekh-Yusef
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.

Summary: Ready with issues

The document defines a YANG data model that defines service configuration elements that can be used in communication protocols between customers and network operators. Those elements can also be used as input to automated control and configuration applications.


* Section 6.9, Security

This section has an Authentication and Encryption sub-sections that apply to the site.

As per section 6:
   "Authorization of traffic exchange is done through what we call a VPN
    policy or VPN service topology defining routing exchange rules
    between sites."

It might be useful to add an Authorization sub-section to section 6.9 to capture that security aspect of the model.

[Qin]: As described above, authorization of traffic exchange is done through VPN policy and VPN service topology.
VPN policy and VPN service topology are specified in section 6.2.1 and section It is not necessary to repeatedly
Discuss it in a new section. 

* Section 10, Security Considerations

"..., and the server MUST authenticate client access to any protected resource."

There is a need to differentiate between authentication and authorization.
How about the following:
    "..., and the server MUST authenticate the client and authorize access
    to any protected resource."

[Qin]: Sounds a good suggestion. Thanks.

* Section 10, Security Considerations

"The data nodes defined in the "ietf-l3vpn-svc" YANG module MUST be carefully created, read, updated, or deleted as appropriate."

I think the above statement is too general, and need to be more specific.
I am assuming that the above statement is trying to say that the identity of the requestor must be authenticated, and the operations on the model must be controlled based on authorization associated with the authenticated entity.

If that is the case, then this should be clearly spelled out.

[Qin]: I think this statement convey two meanings:
For writable/creatable/deletable data nodes defined in this YANG module, these data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations.
For the readable data nodes in this YANG module, these data nodes may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes.

Secondly, if you keep on reading the subsequent sentence after this statement in the paragraph 2 of section 10, you will see this is exactly what you proposed to do.
BTW, this is bis of RFC8049 and we didn't propose any new change to RFC8049.


* Section 6.9.2. Encryption

"A hitless key-change mechanism may be added through augmentation."
Replace "key-change" with "key-exchange"

[Qin]: regarding "key-change", one example given in the section 6.9.2 is about
customer changes the pre-shared key on a regular basis. So I think this is not about
key exchange between two parties, two way or three way handshakes. Using key-change is consistent with the example in the section 6.9.2.
Maybe we can change "key-change" into "key change". 
BTW, I believe hitless key change is related to keychain
and can also be referred to as hitless key rollover.