Subject: [ANCP] Re: ANCP Digest, Vol 16, Issue 6

From: "Hasnaa Moustafa" <[email-masked]>
Date: Mon, 17 Sep 2007 10:31:40 +0200

Dear Francois,

Thanks a lot for reviewing the draft and for all these detailed comments.
Please find our comments below.

Thanks again.

Best Regards,
Hassnaa

> Message: 1
> Date: Mon, 10 Sep 2007 14:55:08 +0200
> From: Francois Le Faucheur IMAP <[email-masked]>
> Subject: Re: [ANCP] Working Group Last Call for
>        draft-ietf-ancp-security-threats-02.txt
> To: MOUSTAFA RD-CORE-ISS Hassnaa
>        <[email-masked]>,  Hannes Tschofenig
>        <[email-masked]>,
> [email-masked]
> Cc: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
>
> Hassnaa, Hannes, Stefaan,
>
> Please find my review comments on draft-ietf-ancp-security-
> threats-02.txt.
> I tried split them into Substantial Comments, Editorial Comments and
> Typos.
> I hope these comments are useful.
>
> Francois
>
>
> 1 Substantial Comments
> ===================
>
> Section 1:
> Is there not a well-established generic categorisation of protocol
> security risks that could be applied here (or is this the generic
> categorization)?

No there is not. This is in RFC 3365 as referenced in the draft.

Section 7:
> In addition to discussing attacks against the 4 uses cases, I suspect
> there would be value in discussing attacks during the "Protocol
> establishment phase" (ie ANCP discovery phase, ANCP peering
> establishment, ANCP Capability negotiation ...), Could this be added?
> Does it lead to any additional security requirements specifically for
> the ANCP Discovery phase? or peering phase?

 In fact, the setup phase is among the protocol details, which will change
nothing in the requirements.
The draft could mention something about "initiating the ANCP
communication". This is already in the draft, but maybe should be made more
clear.

> section 7.4:
> There is an additional type of DOS attack that, I think, is not
> discussed in the current text. Since, in some mode of operation of
> ANCP for multicast, an IGMP join/leave received on AN validly
> triggers an ANCP message from AN to NAS, a HGW/CPE can effectively
> achieve a NAS DOS by generating heaps of IGMP join/leaves. I believe
> this is worth discussing separately because it cannot be addressed
> solely through security mechanisms inside the ANCP protocol. This
> risk is discussed in section "6. Security Considerations" of draft-
> maglione. Could the corresponding text describing the risk be
> incorporated here in section 7.4(with appropraite editing if needed)?

The mentioned risk is not clear for me, I could not understand if the risk
is DoS or anything else, as the section firstly discusses DoS then mentions
the risk.

Section "6. Security Considerations" of draft-maglione also
> recommends specific mitigation approaches for this ("To mitigate this
> risk,..."). Could this recommendation be added in section 8 of ancp-
> security?

 The cited recommendations go into solutions details, which is not our
objective in Section 8 in our draft (which only gives requirements).
Indeed, overload is something that is not handled in the draft, but is
concerning the scalability of the protocol solution (so not the scope of the
security draft). In any case, it is a good idea to add something about
overload/scalability to the draft without specifying where it could come
from.

section 7.4:
> One of the functions that ANCP has to enable for multicast is
> accounting. So a specific additional risk associated with the
> multicast use cases is tempering with accounting information (eg
> escaping charging or conversely over-charging another user).
> Could you add a statement to that effect? For example, perhaps, at
> teh very end of section 7.4 we could add:
> "       *   Messages's modifications to temper with accounting
> information,
> for example in order to avoid service charges or conversely in order
> to artificially increase service charges on other users"

In this case, we handle the security of the "information" sent between the
AN and the NAS without further detailing what this information is, which can
be accounting information (so in fact, it is covered in the draft). But
something may be mentioned saying that "since this information can be used
for accounting, it is possible to have attacks".

section 8:
> Based on discussions on the list re multicast use case security
> aspects, I'd suggest adding requirements along the line of
> "   o    The protocol solution SHOULD ensure that, by default, IGMP
> join/leave requests received by AN are only relayed to NAS for those
> multicast flows that have been explicitly identified before by the
> NAS through ANCP"

Actually, this is a solution for multicast. There are other solutions where
this is not relevant.

section 8:
> In case of DOS attacks on NAS as a result of IGMP leave/joins
> resulting in ANCP messages from AN to NAS, we would want the NAS to
> be able to stop ANCP messages generated by the AN. I would suggest
> adding a requirement along the lines of:
> "   o    The protocol solution MUST allow the NAS to instruct the AN
> to stop issuing ANCP messages to the NAS on join/leave (i) from a
> particular AN port , (ii) for a particular multicast flow (or ranges
> of multicast flows) or (iii) combination thereof."

 There is a requirment in the draft (The protocol solution MUST be robust
against DoS).  Such requirment covers the case that you state. However if
the case is mentioned as you describe, we believe that it will go into
solutions description which is not the objective of our draft. Indeed, the
requirement is that the protocol MUST be robust against DoS attacks, how it
is done is not the scope of the draft.

2 Editorial Comments
> ================
>
> Abstract:
> s/to configure and manage access equipments and allow them to report
> information to the NAS in order to enable and optimize configuration/
> to allow the NAS to configure, manage and control access equipments,
> including the ability for the access nodes to report information to
> the NAS/

OK.

Section1, 2nd paragraph:
> s/This document/The present document/

OK.

Section 1:
> I don't quite get the exact meaning of the following sentence:
> " and ANCP should also provide such protection as a service to the
> different service parameters between the two peers."
> Is this saying that the protection should ensure protection of the
> various parameters manipulated inside the ANCP message? if yes, then
> I think this is already covered in previous sentence stating that the
> ANCP payload ought to be protected. If not, can you clarify what it
> means?

Yes, it means this. So this sentence will be removed so not to have
redundancy.

Section 1:
> Current text says:
> "  Prevention against Impersonation:
>       It is important that signaling messages are delivered to the
> correct nodes, and nowhere else."
> The description doesn't quite match the title. The description sounds
> more like "mis-delivery of message". Perhaps it should say something
> like:
> "  Prevention against Impersonation:
>       It is important that protection be available against a device
> impersonating an ANCP node (i.e. an unauthorized device generating an
> ANCP message and pretending it was generated by a valid ANCP node) "

Right, modification is considered.

Section 1:

I understood that you mean Section 3.

Current text says:
> "For the threat analysis, the protocol communication between the
> Access Node and the NAS is important whereas the other component,
> such as HGW, CPE, AAA server only play a role in the understanding of
> the system architecture.
> "
> Should this say something like:
> "For the threat analysis, this document focuses on the ANCP protocol
> communication between the Access Node and the NAS. However,
> communications with the other components, such as HGW, CPE, AAA
> server play a role in the understanding of the system architecture
> and of what triggers ANCP protocol communications."

Yes, modification is considered.

Section 4:
> "Also, through replaying old packets, of another privileged client
> for instance, an attacker can configure a better QoS profile on its
> own DSL line increasing its own benefit.
> "
> in previous sentence s/can/can attempt to/

Yes.

Section 7:
> Current text says:
> "However, once the AAA server has the authorization data then it is
> given to the NAS, which is more in the scope of this work. "
> In previous sentence s/which is more/which is/

OK.

Section 7:
> Current text says:
> "Consequently, this document considers the attacks that are related
> to the ANCP operation and are concerning the communication between
> the NAS and the AAA/Policy server."
> I think you want to say that this document is concerned with the ANCP
> communications that result from communications between the NAS and
> AAA/Policy Server. But it is not directly considering "the attacks
> that ....are concerning the communication between teh NAS and the AAA/
> Policy Server.". Right?
> Should this read:
> "Consequently, this document considers the attacks that are related
> to the ANCP operation associated with communication between the NAS
> and the AAA/Policy server."

Right, modification is considered.

section 7.2:
> s/DoS attacks can take place by an attacker/DoS attacks of the AN can
> take place by an attacker/

OK.

section 7.4:
> s/this allows the NAS to follow subscribers' multicast (source,
> group) membership/this allows the NAS to follow subscribers'
> multicast (source, group) membership and control replication
> performed by the AN./

Actually, this is too specific. There is no agreement on how the solution
will look like. So, we should not mention things for which the framework
does not mention anything.
Since a considerable number of people is against that the NAS controls the
replication in the AN, because the zapping delay becomes too high with such
a solution, so let's wait with this.

section 8:
> I don't fully understand how the following translates in terms of
> ANCP Security requirements:
> "   o  The protocol solution SHOULD distinguish the control messages
> from the data."
> Can you elaborate?

 This requirement aims to separate between replay and non integrity
attacks.

section 9:
> s/presenting the security requirements to be considered/presenting
> the security requirements to be considered for design of the ANCP
> protocol/

O K.

3 Typos
> ======
>
> section 7.1:
> s/injecting falsify packets/injecting falsified packets/

Yes, correction is considered.

section 7.3:
> s/carryout/carry out/

Actually, it is carryout

On 3 Sep 2007, at 16:00, BOCCI Matthew wrote:
>
> >
> > This email is to announce the start of a two week Working Group
> > last call for draft-ietf-ancp-security-threats-02.txt.
> >
> > Please read the draft and provide comments to the ANCP list by
> > Tuesday 11th September.
> >
> > As agreed during the Chicago meeting, the following participants
> > kingly volunteered to review the draft as a part of the WG LC:
> >
> > Curtis Sherbo
> > Phillipe Niger
> > Michael Busser
> > Francios LeFaucher
> > Raymond Zhang
> >
> > We would like to thank them in advance for their help.
> >
> > We will not be in a position to progress the draft until we have
> > received comments from at least five reviewers.
> >
> > Regards,
> >
> > Matthew & Woj
> >
> > -----------------------------------------
> > Matthew Bocci
> > IP Division,
> > Alcatel-Lucent Telecom Limited,
> > Registered Office: Christchurch Way, Greenwich, London SE10 0AG.
> > Registered in England & Wales number 02650571
> > -----------------------------------------
> >
> > _______________________________________________
> > ANCP mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ancp
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://www1.ietf.org/pipermail/ancp/attachments/20070910/d7e7e144/attachment-0001.html
>
> ------------------------------
>
> _______________________________________________
> ANCP mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ancp
>
>
> End of ANCP Digest, Vol 16, Issue 6
> ***********************************
>
_______________________________________________
ANCP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ancp

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Tue, 18 Sep 2007 18:01:43 +0200

Hasnaa,

Thanks for looking into my comments.
I cut out all the points which are closed/agreed. A few more thoughts  
on remaining ones below:

> In fact, the setup phase is among the protocol details, which will  
> change nothing in the requirements.
> communication". This is already in the draft, but maybe should be  
> made more clear.

Yes, I think that would help.

> The mentioned risk is not clear for me, I could not understand if  
> the risk is DoS or anything else, as the section firstly discusses  
> DoS then mentions the risk.

I believe the group has agreed to _optionally_ allow an _optional_   
model whereby a join/leave from an enduser will trigger one ANCP  
query/response between AN and NAS.
If an end-device decides to issue join/leave at very high rate, this  
can translate into very high rates of ANCP query/response. I believe  
this is a specific additional risk because this can happen even if  
the AN and NAS are fully secured (ie authenticated/authorized to each  
other).
I believe this risk can translate into a DOS attack, but I leave it  
up to you how to best categorize this risk

I would expect that the ancp-security I-D should describe this sort  
of risk (without having to assume details of ANCP protocols), explain  
that pure ANCP protocol security mechanisms like authentication,  
integrity protection, encryption, that may be operating between AN  
and NAS,  do NOT protect against this risk and therefore the ANCP  
protocol spec needs to think about this and hopefully make some  
recommendations.

> The cited recommendations go into solutions details, which is not  
> our objective in Section 8 in our draft (which only gives  
> requirements).
> Indeed, overload is something that is not handled in the draft, but  
> is concerning the scalability of the protocol solution (so not the  
> scope of the security draft). In any case, it is a good idea to add  
> something about overload/scalability to the draft without  
> specifying where it could come from.

We need to strike the right balance between being too specific and  
being too generic. You may be right that the mechanisms discussed in  
ancp-mcast may be a little too solution-specific. At the same time,  
saying something like "the ANCP protocol must be scalable and robust"  
would not be very helpful. Perhaps the right balance would be to :
	(i) explain that ANCP protocol security mechanisms like  
authentication/encryption cannot protect against that risk
	(ii) specific mechanism for this risk should be discussed in  
protocol document

> In this case, we handle the security of the "information" sent  
> between the AN and the NAS without further detailing what this  
> information is, which can be accounting information (so in fact, it  
> is covered in the draft). But something may be mentioned saying  
> that "since this information can be used for accounting, it is  
> possible to have attacks".

Yes, I would find it useful then to have "accounting" being mentioned  
as a specific example of information and mention the corresponding  
attacks.

> Actually, this is a solution for multicast. There are other  
> solutions where this is not relevant.

I don't fully get what you're saying here.
Are you saying that:
	(i) the above requirements only applies to the multicast use-case , or
	(ii) the above requirements is only applicable to one particular  
protocol solution to handle multicast?

If (i), then yes. But it is still a valid concern/requirement for  
multicast use-case.
If (ii), then you could try make it a bit more generic (like "the  
protocol should ensure that operations in default configuration  
guarantees low level of AN/NAS protocol interactions").

Saying nothing about this problem is not very helpful. There has been  
several messages on the list expressing a security consideration on  
that exact issue and we are modifying the ANCP proposal to address  
it.  ancp-security ought to document such security requirements.

> There is a requirment in the draft (The protocol solution MUST be  
> robust against DoS).  Such requirment covers the case that you  
> state. However if the case is mentioned as you describe, we believe  
> that it will go into solutions description which is not the  
> objective of our draft. Indeed, the requirement is that the  
> protocol MUST be robust against DoS attacks, how it is done is not  
> the scope of the draft.

Again, my view is that requirements like " the protocol must be  
secure, scalable, robust and protect against DOS attacks" are of  
limited value for developing the ANCP protocol. I think we need to go  
one level more specific.
If the requirement proposed above is too specific, perhaps it could  
be generalized along the lines of:
"the protocol MUST facilitate pushing of DOS mitigation enforcement  
from the NAS into the AN".
Just to be clear, all I am saying is that we want to make sure that  
in case there is some attack resulting in a high ANCP load on NAS, we  
want to facilitate pushing some rule in AN via ANCP to basically  
block the attack at the level of the AN.

> Actually, this is too specific. There is no agreement on how the  
> solution will look like.

There is no agreement as to the protocol details.
However I believe there is clear agreement on the fact that ANCP will  
_optionally_ allow decision to be taken by the NAS and replication  
control in AN controlled via ANCP.

Please see the ANCP WG minutes. In particular the final conclusion of  
the discussion:
"
Woj: Take flexibility as key thing. Lot of support, individual  
opposition.
"

> So, we should not mention things for which the framework does not  
> mention anything.
> Since a considerable number of people is against that the NAS  
> controls the replication in the AN,

This has been extensively discussed in Chicago.
I heard Roberta, Francois, Mike Mc Bride (PIM WG Chair), Hiroshi Ohta  
(MBONED chair), Sanjay and Curtis expressing support for NAS control.  
I heard only Dong expressing concerns with NAS control.

> because the zapping delay becomes too high with such a solution, so  
> let's wait with this.

In any case, I understand there is WG agreement to allow this  
optional flexibility. If you woudl like to revert that decision,  
please discuss this specifically on the list, but for now I think we  
should adhere to the current decision.

Cheers

Francois

---

From: Stefaan DE CNODDER <[email-masked]>
Date: Wed, 19 Sep 2007 09:52:33 +0200

Hi Francois,

The DOS attacks that a user might create by sending many IGMP messages, 
is indeed a security problem totally missing in the draft and has to be 
added.  The DOS attacks mentioned in the draft, and the mechanisms like 
authentication are not related to it, so this new type of DOS attack 
has to be discussed seperately.  The draft will however not propose any 
solutions for it, just like the draft does not propose any solutions for 
authentication, or for the other threats.  I can imagine many solutions 
for it (e.g., AN already can do a lot to protect itself independent from 
ANCP, and creating extra filters (say ACL lists) in the AN to limit the 
ANCP messages).

see further below...

Francois Le Faucheur IMAP wrote:

> I cut out all the points which are closed/agreed. A few more thoughts on 
> remaining ones below:
> 
>>
>>     Section 7:
>> communication". This is already in the draft, but maybe should be made 
>> more clear.  
> 
> 
>> The mentioned risk is not clear for me, I could not understand if the 
>> risk is DoS or anything else, as the section firstly discusses DoS 
>> then mentions the risk.  
> 
> 
> If an end-device decides to issue join/leave at very high rate, this can 
> translate into very high rates of ANCP query/response. I believe this is 
> a specific additional risk because this can happen even if the AN and 
> NAS are fully secured (ie authenticated/authorized to each other).
> I believe this risk can translate into a DOS attack, but I leave it up 
> to you how to best categorize this risk
> 
> I would expect that the ancp-security I-D should describe this sort of 
> risk (without having to assume details of ANCP protocols), explain that 
> pure ANCP protocol security mechanisms like authentication, integrity 
> protection, encryption, that may be operating between AN and NAS,  do 
> NOT protect against this risk and therefore the ANCP protocol spec needs 
> to think about this and hopefully make some recommendations.
> 
> 
>>  
>>
>> concerning the scalability of the protocol solution (so not the scope 
>> of the security draft). In any case, it is a good idea to add 
>> something about overload/scalability to the draft without specifying 
>> where it could come from.
> 
> 
> We need to strike the right balance between being too specific and being 
> too generic. You may be right that the mechanisms discussed in 
> (ii) specific mechanism for this risk should be discussed in protocol 
> document 
> 
>>  
>>
>>     section 7.4:
>> In this case, we handle the security of the "information" sent between 
>> the AN and the NAS without further detailing what this information is, 
>> which can be accounting information (so in fact, it is covered in the 
>> draft). But something may be mentioned saying that "since this 
>> information can be used for accounting, it is possible to have attacks".
> 
> 
> Yes, I would find it useful then to have "accounting" being mentioned as 
> a specific example of information and mention the corresponding attacks.
> 
>>  
>>
>>     section 8:
>> Actually, this is a solution for multicast. There are other solutions 
>> where this is not relevant. 
> 
> 

As said above, saying something like "The protocol solution SHOULD 
ensure that, by default, IGMP join/leave requests received by AN are 
only relayed to NAS for those multicast flows that have been explicitly 
identified before by the NAS through ANCP" is one way to achieve it and 
you second wording above sounds better.  In fact the first requirement 
also has problems in the sense that as soon the AN is allowed to sent 
IGMP requests to the NAS for 1 multicast stream, an attacker might send 
many join/leaves for this multicast stream and then no security issue is 
solved.  Even when the AN has been explicitely configured to send 
requests to the NAS, it still has to limit the protocol exchange in some 
way.

> several messages on the list expressing a security consideration on that 
> exact issue and we are modifying the ANCP proposal to address it.  
> ancp-security ought to document such security requirements.
> 
>>  
>>
>>     section 8:
>> robust against DoS).  Such requirment covers the case that you state. 
>> However if the case is mentioned as you describe, we believe that it 
>> will go into solutions description which is not the objective of our 
>> draft. Indeed, the requirement is that the protocol MUST be robust 
>> against DoS attacks, how it is done is not the scope of the draft.
> 
> 
> Again, my view is that requirements like " the protocol must be secure, 
> scalable, robust and protect against DOS attacks" are of limited value 
> for developing the ANCP protocol. I think we need to go one level more 
> specific. 
> "the protocol MUST facilitate pushing of DOS mitigation enforcement from 
> the NAS into the AN". 
> Just to be clear, all I am saying is that we want to make sure that in 
> case there is some attack resulting in a high ANCP load on NAS, we want 
> to facilitate pushing some rule in AN via ANCP to basically block the 
> attack at the level of the AN. 
> 
>>
>>     section 7.4:

For all use cases, the framework document is not listing the exact 
parameters/information that is exchanged between AN and NAS, and hence 
also in the security draft we are not further detailing this.  If it is 
agreed to furhter describe details, then the security draft has to 
follow that.  Apparantly specificaly for the multicast use case there is 
interest to make the high level description more detailed, and that's 
good for the security draft because then also more specific security 
issues can be discussed.

regards,
Stefaan

> Woj: Take flexibility as key thing. Lot of support, individual opposition.
> "
> 
>> Since a considerable number of people is against that the NAS controls 
>> the replication in the AN,
> 
> 
> (MBONED chair), Sanjay and Curtis expressing support for NAS control. I 
> heard only Dong expressing concerns with NAS control.
> 
> 
> In any case, I understand there is WG agreement to allow this optional 
> flexibility. If you woudl like to revert that decision, please discuss 
> this specifically on the list, but for now I think we should adhere 
> to the current decision.
> 
> Cheers
> 
> Francois

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 19 Sep 2007 10:06:29 +0200

Hi Stefaan,

On 19 Sep 2007, at 09:52, Stefaan DE CNODDER wrote:

>
> Hi Francois,
>
> The DOS attacks that a user might create by sending many IGMP  
> messages, is indeed a security problem totally missing in the draft  
> and has to be added.  The DOS attacks mentioned in the draft, and  
> the mechanisms like authentication are not related to it, so this  
> new type of DOS attack has to be discussed seperately.  The draft  
> will however not propose any solutions for it, just like the draft  
> does not propose any solutions for authentication, or for the other  
> threats.

Agreed.
I am also in general agreement with your comments below. I think it  
will be good to have this reflected in the next version.
Cheers

Francois

> I can imagine many solutions for it (e.g., AN already can do a lot  
> to protect itself independent from ANCP, and creating extra filters  
> (say ACL lists) in the AN to limit the ANCP messages).
>
> see further below...
>
>> I cut out all the points which are closed/agreed. A few more  
>> thoughts on remaining ones below:
>>>
>>>     Section 7:
>>>  In fact, the setup phase is among the protocol details, which  
>>> will change nothing in the requirements.
>>>  The mentioned risk is not clear for me, I could not understand  
>>> if the risk is DoS or anything else, as the section firstly  
>>> discusses DoS then mentions the risk.
>> I believe the group has agreed to _optionally_ allow an  
>> _optional_  model whereby a join/leave from an enduser will  
>> trigger one ANCP query/response between AN and NAS. If an end- 
>> device decides to issue join/leave at very high rate, this can  
>> translate into very high rates of ANCP query/response. I believe  
>> the AN and NAS are fully secured (ie authenticated/authorized to  
>> each other).
>> I believe this risk can translate into a DOS attack, but I leave  
>> it up to you how to best categorize this risk
>> I would expect that the ancp-security I-D should describe this  
>> sort of risk (without having to assume details of ANCP protocols),  
>> explain that pure ANCP protocol security mechanisms like  
>> authentication, integrity protection, encryption, that may be  
>> operating between AN and NAS,  do NOT protect against this risk  
>> and therefore the ANCP protocol spec needs to think about this and  
>> hopefully make some recommendations.
>>>
>>>  The cited recommendations go into solutions details, which is  
>>> not our objective in Section 8 in our draft (which only gives  
>>> requirements).
>>> Indeed, overload is something that is not handled in the draft,  
>>> but is concerning the scalability of the protocol solution (so  
>>> not the scope of the security draft). In any case, it is a good  
>>> idea to add something about overload/scalability to the draft  
>>> without specifying where it could come from.
>> being too generic. You may be right that the mechanisms discussed  
>> in ancp-mcast may be a little too solution-specific. At the same  
>> time, saying something like "the ANCP protocol must be scalable  
>> and robust" would not be very helpful. Perhaps the right balance  
>> would be to :
>>> information is, which can be accounting information (so in fact,  
>>> it is covered in the draft). But something may be mentioned  
>>> saying that "since this information can be used for accounting,  
>>> it is possible to have attacks".
>> Yes, I would find it useful then to have "accounting" being  
>> mentioned as a specific example of information and mention the  
>> corresponding attacks.
>>>
>>>     section 8:
> ensure that, by default, IGMP join/leave requests received by AN  
> are only relayed to NAS for those multicast flows that have been  
> explicitly identified before by the NAS through ANCP" is one way to  
> achieve it and you second wording above sounds better.  In fact the  
> first requirement also has problems in the sense that as soon the  
> AN is allowed to sent IGMP requests to the NAS for 1 multicast  
> stream, an attacker might send many join/leaves for this multicast  
> stream and then no security issue is solved.  Even when the AN has  
> been explicitely configured to send requests to the NAS, it still  
> has to limit the protocol exchange in some way.
>
>
>> Saying nothing about this problem is not very helpful. There has  
>> been several messages on the list expressing a security  
>> consideration on that exact issue and we are modifying the ANCP  
>> proposal to address it.  ancp-security ought to document such  
>> security requirements.
>>>
>>>     section 8:
>>>  There is a requirment in the draft (The protocol solution MUST  
>>> be robust against DoS).  Such requirment covers the case that you  
>>> state. However if the case is mentioned as you describe, we  
>>> believe that it will go into solutions description which is not  
>>> the objective of our draft. Indeed, the requirement is that the  
>>> protocol MUST be robust against DoS attacks, how it is done is  
>>> not the scope of the draft.
>> limited value for developing the ANCP protocol. I think we need to  
>> go one level more specific. If the requirement proposed above is  
>> too specific, perhaps it could be generalized along the lines of:
>> "the protocol MUST facilitate pushing of DOS mitigation  
>> enforcement from the NAS into the AN". Just to be clear, all I am  
>> saying is that we want to make sure that in case there is some  
>> attack resulting in a high ANCP load on NAS, we want to facilitate  
>> pushing some rule in AN via ANCP to basically block the attack at  
>> the level of the AN.
>>>
>>>     section 7.4:
>> However I believe there is clear agreement on the fact that ANCP  
>> will _optionally_ allow decision to be taken by the NAS and  
>> replication control in AN controlled via ANCP.
>
>
> parameters/information that is exchanged between AN and NAS, and  
> hence also in the security draft we are not further detailing  
> this.  If it is agreed to furhter describe details, then the  
> security draft has to follow that.  Apparantly specificaly for the  
> multicast use case there is interest to make the high level  
> description more detailed, and that's good for the security draft  
> because then also more specific security issues can be discussed.
>
> regards,
> Stefaan
>
>
>
>> Please see the ANCP WG minutes. In particular the final conclusion  
>> of the discussion:
>> "
>> I heard Roberta, Francois, Mike Mc Bride (PIM WG Chair), Hiroshi  
>> Ohta (MBONED chair), Sanjay and Curtis expressing support for NAS  
>> control. I heard only Dong expressing concerns with NAS control.
>>> because the zapping delay becomes too high with such a solution,  
>>> so let's wait with this.
>> please discuss this specifically on the list, but for now I think  
>> we should adhere to the current decision.
>> Cheers
>> Francois