Subject: Grey List & Default Behavior (was Re: [ANCP] Comments on draft-maglione)

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Fri, 7 Sep 2007 15:19:13 +0200

Michel, Sanjay and all,

The current proposal can support a mode where any "multicast flow" is  
denied by AN unless it has been explicitly identified/provisioned  
before. However, there has been several comments on the list  
expressing security concern that this should not just be a possible  
behavior, but should also be the DEFAULT behavior.

Sanjay also suggested that a Grey List may be useful. As mentioned in  
Chicago, Roberta's proposal initially had the Grey List. It was then  
taken out on the grounds that we could functionally achieve the same  
behavior with only Black/White List and making Grey List the default  
behavior. SInce the WG seems more comfortable with a default behavior  
of Black List (ie deny), the Grey List seems in order again.

To address the range WG comments on this topic, we would like to  
propose the following updated proposal:
	* we have White, Black and Grey lists
	* each list contains zero, one or multiple entries
	* each entry may specify a single flow or contain ranges (ie mask on  
Group address and/or mask on Source address)
	* ANCP primitives allow BNG to add/remove/modify individual entries  
in each list
	* if a join is received by AN for a flow which is not in any of the  
three list, then it is rejected by AN (ie Default is reject)
	* the lists have a relative priority
	* by default relative priority is Black>Grey>White
	* this priority is reconfigurable (eg one could decide that  
White>Grey>Black)
	* if a join is received by AN for a flow which is in multiple lists,  
then AN applies behavior of highest priority list

Example scenarios:

Scenario 1:
	* no config:
	==> any join gets rejected by AN

Scenario 2:
	* White List = {Flow1,... FlowN}
	==> Join (Flowi) gets honored by AN,
	==> everything else gets rejected by AN

Scenario 3:
	* White List = {Flow1,... FlowN}
	* Grey LIst= {(S=SpecialSource, G=*.*.*.*)}
	==> Join (Flowi) gets honored by AN
	==> Join (Flow from SpecialSource) triggers ANCP request to BNG
	==> everything else gets rejected by AN

Scenario 4:
	* Grey List= {(S=SpecialSource, G=*.*.*.*)}
	* White List = {(S=SpecialSource, G=SpecialGroup)}
	* White>Grey>Black
	==> Join (Flow from Special Source to SpecialGroup) gets authorised  
by AN
	==> Join (Flow from SpecialSource) triggers ANCP request to BNG
	==> everything else gets rejected by AN

Francois

On 24 Jul 2007, at 20:22, Michel Platnic wrote:

>
>> <Michel> Using access control capabilities within the access  
>> network provides the two main following benefits:
>> - refrain from sending any content to a customer that was not paid  
>> for (mostly relevant when Encryption is not used)
>> - provides a filter against end-user applications/hackers that may  
>> send IGMP requests with invalid IP address
>>
>> A solution where all the IP addresses that are not part of either  
>> the Black-list or the White-List are sent to a central policy  
>> server for authorization gives me some concerns regarding the  
>> robustness of the whole system. Same concern regarding the  
>> treatment of unknown IP source addresses ('Everything else').
>
> Agreed. We had these concerns in mind also. This is why the Black- 
> Lists and White-Lists include the ability to define arbitrarily  
> large ranges/masks. In particular, as an example, one can easily  
> define a Black-List which contains a single "catch-all" entry that  
> matches any Multicast address & Source. Then you can define a White- 
> List with the explicit channels you want to allow. This effectively  
> implements a policy whereby everything is blocked by AN, except the  
> channels that have been explicitly allowed in the White-List.
> In other words, the Black-List can be used for explicit listing of  
> channels, or it can easily be used as a "catch-all" (for all, or  
> for arbitrarily large ranges of channels).
>
> This should address your concern of making sure that the "default"  
> behavior for any non-explicitly defined channel is not to query NAS/ 
> Central_server.
>
> See in draft-maglione:
> "
> The White List and Black List can contain entries allowing:
>    o  an exact match for a (*,G) ASM group (e.g. <G=g.h.i.l>)
>    o  an exact match for a (S,G) SSM channel (e.g.  
> <S=s.t.u.v,G=g.h.i.l>
>    o  a mask-based range match for a (*,G) ASM group (e.g.
>       <G=g.h.i.l/Mask>)
>    o  a mask-based range match for a (S,G) SSM channel (e.g.
>       <S=s.t.u.v/Mask,G=g.h.i.l/Mask>
> "
>  <Michel> Let me try to rephrase your proposal; there would be a  
> default state wherein any channel being neither part of White-list  
> nor Black-list would be discarded.
> If its the case I agree with you that this solution solves the  
> security issue.
>
> But what about when AN is not in this default state?
> If "Accept everything else" is used then again same problem of  
> security is encountered, and any hacker or application can overload  
> the policy server with requests.
> To my understanding, the model proposed, where the NAS is getting  
> the customer request for authorization, requires this mode of  
> operation.
> So we still have the same problem.
> Did I miss anything?
>
>
_______________________________________________
ANCP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ancp