Last Call Review of draft-ietf-ancp-mc-extensions-14
review-ietf-ancp-mc-extensions-14-secdir-lc-zhang-2014-01-23-00

Hello

：



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:

1)

In the introduction, there is a statement

“

Conditional access is described in Section 3.4.1 and Section 3.4.2.3 of
[RFC5851], with the latter section particularly applicable to operation with
white and black lists
 only

”

Section 3.4.2.3 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.

2)

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.



3)

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.



4)

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 3.4.2.3 of RFC 5851

“

Multicast Admission Control and White Lists

”

. So, I doubt whether this TLV needs to
 be supported is this case.



5)



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.”



6)

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.



Nits:

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

Typos:

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

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



Cheers



Dacheng