[secdir] secdir review of draft-ietf-ancp-mc-extensions-14

"Zhangdacheng (Dacheng)" <zhangdacheng@huawei.com> Wed, 22 January 2014 06:48 UTC

Return-Path: <zhangdacheng@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id F3E0D1A02E8; Tue, 21 Jan 2014 22:48:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.735
X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id cA4Vu0SJ9Yvy; Tue, 21 Jan 2014 22:48:07 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) by ietfa.amsl.com (Postfix) with ESMTP id 8F7441A02DD; Tue, 21 Jan 2014 22:48:05 -0800 (PST)
Received: from (EHLO lhreml204-edg.china.huawei.com) ([]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCT87475; Wed, 22 Jan 2014 06:48:04 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com ( by lhreml204-edg.china.huawei.com ( with Microsoft SMTP Server (TLS) id; Wed, 22 Jan 2014 06:46:59 +0000
Received: from NKGEML410-HUB.china.huawei.com ( by lhreml405-hub.china.huawei.com ( with Microsoft SMTP Server (TLS) id; Wed, 22 Jan 2014 06:47:59 +0000
Received: from NKGEML507-MBS.china.huawei.com ([]) by nkgeml410-hub.china.huawei.com ([]) with mapi id 14.03.0158.001; Wed, 22 Jan 2014 14:47:54 +0800
From: "Zhangdacheng (Dacheng)" <zhangdacheng@huawei.com>
To: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-ancp-mc-extensions.all@tools.ietf.org" <draft-ietf-ancp-mc-extensions.all@tools.ietf.org>
Thread-Topic: [secdir] secdir review of draft-ietf-ancp-mc-extensions-14
Thread-Index: Ac8XPd+LcI+ULRdMSv6oBbGFFsLvBw==
Date: Wed, 22 Jan 2014 06:47:53 +0000
Message-ID: <C72CBD9FE3CA604887B1B3F1D145D05E3B4292C2@nkgeml507-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_C72CBD9FE3CA604887B1B3F1D145D05E3B4292C2nkgeml507mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [secdir] secdir review of draft-ietf-ancp-mc-extensions-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2014 06:48:10 -0000


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 draft specifies the extensions to the Access Node Control Protocol [RFC6320] required for support of the multicast use cases proposed in [RFC5851].

This huge document is well written. The authors must have spent much energy on this work.

Follows are some questions and comments:


In the introduction, there is a statement “Conditional access is described in Section 3.4.1 and Section of [RFC5851], with the latter section particularly applicable to operation with white and black lists only”

Section of RFC5851 actually discusses how admission control may defeat the purpose of using a white and black list. So, I suggest re-writing this text.


It would make the document easier to understand if the key terms can be clearly introduced. So, I suggest refining Section 2.

In details, terms such as “Conditional Access”, “admission control”, and "conditional access and admission control (CAC)" are widely used in this draft. In addition, this document specifies that conditional access and admission control can consist of two parts: policy-based admission control and resource-based admission control. However, there is no clear definition provided about those terms.

According to RFC5851, conditional access can use white, back, and grey lists to manage the generation of multicast flows, while admission control is used in the cases where the bandwidth reservation for newly generated flows is required.

So, it should be clarified whether there is any relationship between the admission control in RFC5851, and the policy-based admission control and resource-based admission control proposed in this document. Examples will help a lot.

In addition, in RFC 5851, CAC is an abbreviation of Connection Admission Control. This may cause confusing.


In section 4.1.1, there is a statement “The NAS SHOULD NOT include any list type (white, black, or grey) that is not supported by the set of multicast capabilities negotiated between the NAS and the AN.” In section 4.1.2, there is a corresponding statement “In keeping with the general rule stated in Section 4, the AN MUST ignore instances of the List-Action TLV referring to any list type (white, black, or grey) that is not supported by the set of multicast capabilities negotiated between the NAS and the AN.”

So, I suggest using “MUST” to take place of “SHOULD” in the first statement unless we can find out a scenario where the NAS needs to send out a TLV which is not supported by the AN and will be eventually discarded.


Section 6.1.3 lists the protocol elements that MUST be implemented to support the conditional access with white and black lists multicast capability. I found White-List-CAC TLV is included in the list. However, the White-List-CAC TLV is used to indicate that the NAS wishes the AN to do admission control for white-listed flows, and this use case is discussed in Section of RFC 5851 “Multicast Admission Control and White Lists”. So, I doubt whether this TLV needs to be supported is this case.


Section 4.1.2, it is stated “The buffering time specified in an instance of the Report-Buffering- Time TLV applies only to Committed Bandwidth Report messages initiated after the new buffering time is received at the AN, not to any message already in the process of accumulation .”

This policy indicates an implementation may have to maintain two or multiple accumulation processes when NAS frequently sends the Report-Buffering- Time TLVs to the AN and then changes the buffering time. This may not result in serious security problem but will introduce more complexity in the system implementation. So, I suggest changing the text to “The buffering time specified in an instance of the Report-Buffering- Time TLV will not be applied until the current accumulation process of Committed Bandwidth Report messages finishes.”


In the security consideration, the issues with the attacks on the communication channel between AAA and NAS is not sufficient. It is mentioned in this section that it is possible to download per- device policy to the NAS directly so as to eliminate the communication between NAS and AAA. I agree this is an option. However, I believe it is still worthwhile for us to discuss how to secure the communication between NAS and AAA.


1)       Section 4.1.2: In keeping with the general rule stated in Section 4 -> In keeping with the general rule stated in Section 4.1.1


Section 4.4:      first directive that can not -> first directive that cannot

Section 7:                   An attacker able to to -> An attacker able to