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

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Wed, 22 Jan 2014 06:47:53 +0000

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

---

From: Tom Taylor <[email-masked]>
Date: Thu, 23 Jan 2014 19:19:02 -0500

Again, thank you for the work you out into this review. Responses marked
with [PTT].

On 22/01/2014 1:47 AM, Zhangdacheng (Dacheng) wrote:
> 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].
> 
> 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.

[PTT] Proposed to rephrase as follows:

"Conditional access is described in Section 3.4.1 of [RFC5851]. Section
3.4.2.2 mentions a way in which conditional access can be combined with
admission control to allow best effort multicast flows. Section 3.4.2.3
points out the necessary conditions for using both conditional access
and admission control."
> 
> 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.
> 
[PTT] Proposed to rely specifically on RFC 5851 terminology.
Co-authors, please verify that I have this correctly:

 1) The terms "admission control" and "Connection Admission Control
(CAC)" mean the same thing and have to do with bandwidth allocation.

 2) "Conditional access" refers specifically to the use of white, black,
and grey lists.

 3) I don't need any other terms to describe the service control
capabilities specified in this document.

Assuming this is correct, I'll make sure those terms are called out in
Section 2, drop any other text on the topic, and propagate the necessary
changes throughout the rest of the document.

Apologies for being so slow to understand the correct terminology.
> 
> 
> 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.
> 
> 
[PTT] This is an example of "be conservative in what you send and
liberal (i.e, survive gracefully) with what you receive". I had in mind
that the NAS might have a template based on support of grey lists as
well as white and black, and fill it out leaving the grey list empty.
Strictly an implementation shortcut, obviously not the required protocol
behaviour. I don't feel strongly about SHOULD, so I'll replace it with
unless anyone else has a comment.
> 
> 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.
> 
[PTT] Doesn't Section 3.4.2.3 describe a case where the AN does both
admission control and white listing, and sets the conditions for doing that?

  "IPTV is an example of a service that will not be offered as best
   effort, but requires some level of guaranteed quality of service.
   This requires the use of Multicast Admission Control.  Hence, if the
   Access Node wants to autonomously perform the admission process, it
   must be aware of the bandwidth characteristics of multicast flows.
   Otherwise, the Access Node would have to query the NAS for Multicast
   Admission Control (per the grey list behavior); this would defeat the
   purpose of using a white and black list."

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

[PTT] Accepted.
> 
> 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.
> 
[PTT] I can add references to Diameter security (with which I am
familiar) and RADIUS security (which I gather is being worked on)?
Roberta, can you help with the latter?
> 
> 
> 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

[PTT] The general rule is in Section 4:

  "Unless stated otherwise, receivers MUST ignore message contents that
   are not supported by the set of capabilities negotiated between the
   NAS and the Access Node."

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

[PTT] OK
> Section 7:                   An attacker able to to -> An attacker

[PTT] OK

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Sun, 26 Jan 2014 05:53:27 +0000

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

[Dacheng Zhang:] 
Maybe I didn't explain my point view clearly last time. Sorry for that.

If the title of section 6.13 is "Protocol Requirements For Admission Control With White and Black Lists ", then everything is perfect because this TLV is used to indicate that the NAS wishes the AN to do admission control for white-listed flows. The use case you provided above is also one for admission control. But at the moment, the tile of this section is " Protocol Requirements For Conditional Access With White and Black Lists ". That is why I raised a question here for your consideration. ^_^

Cheers

Dacheng

---

From: Tom Taylor <[email-masked]>
Date: Sun, 26 Jan 2014 05:10:15 -0500

OK. let's review this point when I clean up all the terminology. I think 
you may be right and this belongs in one of the combined sections.

---

From: Tom Taylor <[email-masked]>
Date: Fri, 31 Jan 2014 21:20:18 -0500

On 26/01/2014 12:53 AM, Zhangdacheng (Dacheng) wrote:
>>>
>>> 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.
>>>
>> [PTT] Doesn't Section 3.4.2.3 describe a case where the AN does
>> both admission control and white listing, and sets the conditions
>> for doing that?
>>
>> This requires the use of Multicast Admission Control.  Hence, if
>> the Access Node wants to autonomously perform the admission
>> process, it must be aware of the bandwidth characteristics of
>> multicast flows. Otherwise, the Access Node would have to query the
>> NAS for Multicast Admission Control (per the grey list behavior);
>> this would defeat the purpose of using a white and black list."
>>
>
> [Dacheng Zhang:] Maybe I didn't explain my point view clearly last
> time. Sorry for that.
>
> If the title of section 6.13 is "Protocol Requirements For Admission
> Control With White and Black Lists ", then everything is perfect
> because this TLV is used to indicate that the NAS wishes the AN to do
> admission control for white-listed flows. The use case you provided
> above is also one for admission control. But at the moment, the tile
> of this section is " Protocol Requirements For Conditional Access
> With White and Black Lists ". That is why I raised a question here
> for your consideration. ^_^
>
> Cheers
>
> Dacheng
>
>
[PTT] This is the last outstanding item from your review.

The simple resolution is as you suggest: change the names of the 
capabilities. I'll do that.

Tom