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

[Ben Laurie <[e-mail]>]

On 24 January 2014 00:43, Roberta Maglione (robmgl) <[e-mail]> wrote:
> Tom,
>
> Regarding this point:
>>[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?
>
> I'm not very familiar with security, but as far as I know RADIUS security is based on the MD5 algorithm, which has been proven to be  insecure.

Whilst it is generally a good idea to retire MD5, it hasn't actually
been proved insecure for the use RADIUS makes of it.

> In order to overcome this issue " Transport Layer Security (TLS) Encryption for RADIUS" has been specified in RFC 6614, I think we should add a reference to this RFC.
> I'm cc-ing Klaas who is one of the author of this RFC in order to get his feedback too.
>
> Thanks
> Regards
> Roberta
>
> -----Original Message-----
> From: Tom Taylor [mailto:[e-mail]]
> Sent: Thursday, January 23, 2014 7:19 PM
> To: Zhangdacheng (Dacheng); [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [spam] [secdir] secdir review of draft-ietf-ancp-mc-extensions-14
>
> 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].
>>
>> 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.
>
> [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."
>
>>
>> Typos:
>>
>> Section 4.4:      first directive that can not -> first directive
>> that cannot
>
> [PTT] OK
>>
>> Section 7:                   An attacker able to to -> An attacker
>> able to
>
> [PTT] OK
>>
>> Cheers
>>
>> Dacheng
>>
> _______________________________________________
> secdir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview