Subject: RE: Introducing Mutlicast Grey-List (was RE: [ANCP] Commentsondraft-maglione)

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Mon, 3 Dec 2007 23:44:26 +0100

Hi Sven,

catching up on this thread: It seems that to accommodate the "best
effort" proposal below, the AN would need to have some sort of mechanism
that tells it which channel is best effort and which one isn't, and a
white list prioritization. This seems to be a tad bit too complex, so
unless I'm misinterpreting things, it would seem that keeping this sort
of addition to ANCP would be advisable.

Regards,
Woj.

> -----Original Message-----
> From: OOGHE Sven [mailto:[email-masked]] 
> Sent: 27 November 2007 14:29
> To: Francois Le Faucheur (flefauch); Maglione Roberta
> Cc: Ullio Mario; [email-masked]; Michel Platnic
> Subject: RE: Introducing Mutlicast Grey-List (was RE: [ANCP] 
> Commentsondraft-maglione)
> 
> Francois,
> 
> I agree that a catch-all statement can be used to create 
> either "accept all" or "reject all" behavior. Perhaps one 
> nuance: it would make sense to indicate wheher such channels 
> could be accepted as "best effort".
> That means that in case other premium channels are requested 
> lateron, the best effort content (e.g. internet TV) would be 
> the first to suffer.
> 
> Perhaps the way forward is the following:
> - indicate in the framework that by default, all joins for a 
> channel that is not in one of the configured lists, will be rejected.
> - the operator can override this behavior by configuring such 
> a wildcard entry in one of the lists. It should be possible 
> to indicate whether or not the channel is a best effort 
> channel or premium content.
> 
> Comments?
> 
> Regards,
> Sven
> 
> -----Original Message-----
> From: Francois Le Faucheur IMAP [mailto:[email-masked]]
> Sent: maandag 26 november 2007 10:08
> To: Maglione Roberta; OOGHE Sven
> Cc: Francois Le Faucheur IMAP; [email-masked]; Michel Platnic; 
> Ullio Mario
> Subject: Re: Introducing Mutlicast Grey-List (was RE: [ANCP] Comments
> ondraft-maglione)
> 
> Roberta, Sven, and all,
> 
> It is worth noting that Roberta's proposal below allows the 
> behavior described by Sven with very trivial extra config:
> simply add one "catch-all" entry (<S=*,G=*>) in the White List.
> Then any flow that doesn't match the Black or Grey list will 
> be accepted by AN.
> 
> For example, we could add:
> 
> Scenario 4:
> 	* White-List = { <S=*,G=*>}
> 	==> any Join message gets accepted by AN
> 
> Scenario 5:
> 	* White-List = { <S=*,G=*>}
> 	* Black-List = { <S=*,G=G1> , <S=*,G=G2>, ... <S=*,G=Gn> }
> 	==> Join ( S=*,G=Gi) gets rejected by AN  ( 1<=i<=n )
> 	==> everything else gets accepted by AN
> 
> 
> So the choice is between:
> 
> 	* "Black-Default":  proposal below where:
> 		- Default ==> everything that doesn't match 
> Black/Grey gets blocked
> 		- add a single-entry catch-all in White-List==> 
> everything that doesn't match Black/Grey gets accepted
> 
> 	* "White-Default": modified proposal where:
> 		- Default ==> everything that doesn't match 
> Black/Grey gets accepted
> 		- add a single-entry catch-all in Black-List==> 
> everything that doesn't match Black/Grey gets blocked
> 
> Both proposals can easily achieve both required behaviors (ie 
> "block if doesn't match" _and_  "accept if doesn't match"). 
> The only difference is about whether you need to add the 
> single catch-all entry or not to achieve your favorite behavior.
> 
>  From previous discussion on that topic, it sounded to me 
> like several folks were more comfortable with the 
> conservative side (ie if there has not been a conscious 
> decision to allow a flow, then better block it;  it is easy 
> enough to explicitly "allow-all" if operator is so inclined).
> 
> So considering the above ... what do people prefer?
> Perhaps we could also poll the WG in Vancouver on that topic.
> 
> Francois
> 
> On 25 Nov 2007, at 22:26, Maglione Roberta wrote:
> 
> > Hi Sven,
> > 	thanks for your comments;
> > your point makes sense to me, "accept as best effort" is a valid 
> > option for default behavior.
> > The basic idea for the default action is to avoid query the NAS for 
> > all multicast flows that do not match any list:  the reason why we 
> > selected drop as the default behavior for unconfigured 
> multicast flows
> 
> > is in order to be consistent with the typical ACL behavior, 
> and also 
> > because this seemed to be the preferred action according to the 
> > discussion we had in Chicago and on the mailing list, but I open to 
> > modify the default behavior, according to Working group feedback.
> >
> > Regards,
> > Roberta
> >
> >
> > -----Original Message-----
> > From: OOGHE Sven [mailto:[email-masked]]
> > Sent: Fri 11/23/2007 5:16 PM
> > To: Maglione Roberta; [email-masked]
> > Cc: Ullio Mario; Michel Platnic
> > Subject: RE: Introducing Mutlicast Grey-List (was RE: 
> [ANCP] Comments
> > ondraft-maglione)
> >
> > Hello Roberta,
> >
> > Thinking a bit further about the default behavior, I am not 
> sure that 
> > dropping would be the right approach. (cf. "If a Join message is 
> > received by AN for a flow which is not on any list, then it is
> > rejected")
> >
> > Imagine any multicast flow out there on the Internet (e.g. Internet 
> > TV), then if it is not configured on the Access Node, it will be 
> > rejected. I don't think this is what an end-user would want.
> >
> > Instead, I would argue that if the flow is not part of any of the 
> > lists, that the behavior would be to accept it as best effort, i.e.
> > accept without further admission control checks.
> >
> > What do you think?
> >
> > Regards,
> > Sven
> >
> >
> > -----Original Message-----
> > From: Maglione Roberta [mailto:[email-masked]]
> > Sent: vrijdag 23 november 2007 8:36
> > To: [email-masked]
> > Cc: Ullio Mario; Michel Platnic
> > Subject: Introducing Mutlicast Grey-List (was RE: [ANCP] Comments
> > ondraft-maglione)
> >
> > Hello,
> > 	as we discussed during Chicago meeting below is a proposal for 
> > modification to the text of 
> draft-ietf-ancp-framework-04.txt in order 
> > to introduce Multicast Grey List and leave Black List (i.e. 
> deny) as 
> > default behavior.
> > We'd appreciate feedback.
> >
> > Regards,
> > Roberta
> >
> >
> > Section 3.4.1
> > Replace:
> > " Provisioning the conditional access information on the AN can be 
> > done using a "White list" and/or a "Black list".
> > A White list associated with an Access Port identifies the 
> multicast 
> > flows that are allowed to be replicated to that port.  A Black list 
> > associated with an Access Port identifies the multicast 
> flows that are
> 
> > not allowed to be replicated to that port."
> >
> > By:
> > " Provisioning the conditional access information on the AN can be 
> > done using a "White list", "Grey list",  and/or a "Black list". A 
> > White list associated with an Access Port identifies the multicast 
> > flows that are allowed to be replicated to that port.  A Black list 
> > associated with an Access Port identifies the multicast 
> flows that are
> 
> > not allowed to be replicated to that port. A Grey list 
> associated with
> 
> > an Access Port identifies the multicast flows for which the AN on 
> > receiving a Join message, before starting traffic 
> replication queries 
> > NAS for further authorization.
> > Each list contains zero, one or multiple entries and each entry may 
> > specify a single flow or contain ranges (i.e. mask on Group address 
> > and/or mask on Source address).
> >
> >
> > Replace:
> > "Upon receiving a join message on an Access Port, the 
> Access Node will 
> > first check if the requested multicast flow is part of a 
> White list or 
> > a Black list associated with that Access Port.  If it is part of a 
> > White
> > list, the AN can autonomously start replicating multicast    
> > traffic.  If
> > it is part of a Black list, the AN can autonomously discard the 
> > message because the request is not authorized"
> >
> > By:
> >
> > "Upon receiving a join message on an Access Port, the 
> Access Node will 
> > first check if the requested multicast flow is part of a 
> White, Grey 
> > or a Black list associated with that Access Port.  If it is 
> part of a 
> > White list, the AN can autonomously start replicating multicast 
> > traffic.  If it is part of a Black list, the AN can autonomously 
> > discard the message because the request is not authorized. If it is 
> > part of a Grey list the AN uses ANCP to query the NAS, that in turn 
> > will respond to the AN indicating whether the join is to be honored 
> > (and hence replication performed by the AN) or denied (and hence 
> > replication not performed by the AN.) If a Join message is 
> received by 
> > AN for a flow which is not on any list, then it is rejected 
> (i.e. the 
> > default behavior is to drop such
> > messages.) If a join is received by AN for a flow that matches 
> > multiple lists, then a deterministic algorithm (to be specified in 
> > ancp-
> > protocol)
> > is used by the AN to decide which list behavior takes precedence.
> > Following are some example scenarios:
> >
> > Scenario 1:
> > 	* no config:
> > 	==> any Join message gets rejected by AN
> >
> > Scenario 2:
> > 	* White List = { <S=*,G=G1> , <S=*,G=G2>, ... <S=*,G=Gn> }
> > 	==> Join ( S=*,G=Gi) gets honored by AN  ( 1<=i<=n )
> > 	==> everything else gets rejected by AN
> >
> > Scenario 3:
> > 	* White List = { <S=*,G=G1> , <S=*,G=G2>, ... <S=*,G=Gn> }
> > 	* Grey List = { <S=s,G=Gm> }   m>n
> > 	==> Join ( S=*,G=Gi) gets honored by AN  ( 1<=i<=n )
> > 	==> Join ( S=s,G=Gm) triggers ANCP Admission Request to NAS
> > 	==> everything else gets rejected by AN
> >
> >
> > Section 3.4.2
> >
> > Replace:
> > " One approach is for the AN to query the NAS so that both unicast
> >       and multicast CAC for the access line are performed 
> by the NAS.
> >       In this case, the AN can use ANCP to query the NAS, 
> that in turn
> >       performs multicast CAC and responds to the AN 
> indicating whether
> >       the join is to be honored (and hence replication performed by 
> > the
> >       AN) or denied.  In the process, the NAS may communicate with a
> >       Policy Server.
> > "
> > With:
> > " One approach is for the AN to query the NAS so that both unicast
> >       and multicast CAC for the access line are performed 
> by the NAS.
> >       In this case, upon receiving a join to a multicast flow which 
> > matches the Grey List, the AN can use ANCP to query the 
> NAS, that in 
> > turn
> >       performs multicast CAC and responds to the AN 
> indicating whether
> >       the join is to be honored (and hence replication performed by 
> > the
> >       AN) or denied.  In the process, the NAS may communicate with a
> >       Policy Server.
> >
> >
> > Section 4.2
> > Replace
> > " The ANCP MUST support providing multicast conditional access
> >       information to Access Ports on an Access Node, using 
> Black lists
> >       and White lists. "
> > By
> > " The ANCP MUST support providing multicast conditional access
> >       information to Access Ports on an Access Node, using 
> Black, Grey
> >       and White lists. "
> >
> > Replace
> >
> > "The ANCP MUST support binding a particular Black list and White
> >       List to a given Access Port"
> > By:
> >
> > " The ANCP MUST support binding a particular Black, Grey and White
> >       List to a given Access Port
> > "
> > Replace:
> >
> > The ANCP MUST support partial updates of the White lists and Black
> >       lists.
> > by
> > The ANCP MUST support partial updates of the White, Grey and Black
> >       lists.
> >
> > Replace:
> > The ANCP MUST allow the AN to query the NAS to request an
> >       admission decision for replicating a multicast flow to a
> >       particular Access Port.
> >
> > By
> > Upon receiving a join to a multicast flow which matches the 
> Grey List 
> > the ANCP MUST allow the AN to query the NAS to request an admission 
> > decision for replicating that multicast flow to a particular Access 
> > Port.
> >
> >
> >
> > Section 4.7.6
> > Replace and split in two
> >
> > " Upon receiving a join to a multicast flow which does not match any
> >       entry in the Black List nor in the White List for a specific
> >       Access Port, the AN must support using ANCP to query 
> the NAS to
> >       receive a response indicating whether that join is to 
> be honored
> >       or denied."
> >
> > By:
> >
> > " Upon receiving a join to a multicast flow which matches the Grey 
> > List for a specific  Access Port, the AN must support using ANCP to 
> > query the NAS to receive a response indicating whether that 
> join is to 
> > be honored or denied.
> > "
> > " The AN must deny any join to a multicast flow that does not match 
> > any
> >       entry in the Black List nor in the White List  nor 
> Grey List for 
> > the relevant Access Port"
> >
> >
> > Adding the following requirements:
> >
> > "Upon receiving a join to a multicast flow which matches the Grey 
> > List, AN is not allowed to propagate that join request, before the 
> > successful authorization from the NAS is received."
> >
> > "Upon receiving a leave to a multicast flow which matches the Grey 
> > List, AN SHOULD be able to autonomously stop replication 
> and SHOULD be 
> > able to advertise this event to the NAS."
> >
> >
> > Section 4.8.6
> > Adding:
> > The NAS MUST support using ANCP to incrementally add, remove and 
> > modify individual entries in White, Black and Grey lists.
> >
> >
> > -------------------------------------------------------
> > Roberta Maglione  - CCIE #18425
> > Telecom Italia
> > Broadband Network Services Innovation
> > -------------------------------------------------------
> > ________________________________________
> > From: Michel Platnic [mailto:[email-masked]]
> > Sent: Tuesday, July 24, 2007 8:22 PM
> > To: Francois Le Faucheur IMAP
> > Cc: Garofalo Angelo; [email-masked]
> > Subject: RE: [ANCP] Comments on draft-maglione
> >
> > Hi Francois,
> > Please see my comments inline,
> > Regards,
> > Michel.
> >
> >
> > ________________________________________
> > From: Francois Le Faucheur IMAP [mailto:[email-masked]]
> > Sent: Mon 7/23/2007 6:23 PM
> > To: Michel Platnic
> > Cc: Francois Le Faucheur IMAP; OOGHE Sven; [email-masked]; 
> > [email-masked]
> > Subject: Re: [ANCP] Comments on draft-maglione Hi Michel,
> >
> >
> >
> > <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?
> >
> >
> > 
> ______________________________________________________________________
> 
> > __
> > ______
> > I understand that some applications may require 
> sophisticated policy 
> > decision making and that, as a matter of fact, some 
> AN/central policy 
> > server synchronization mechanism should to be proposed, but the 
> > solution must be Robust and Scalable.
> > For now I am not convinced that solution proposed is either 
> Robust or 
> > Scalable.
> >
> > Let us know if you have specific robustness/scalability concerns 
> > (beyond the one discussed above)?
> > Then we could work together on addressing those.
> >
> >  <Michel> Well, there is still this scalable issue when duplicating 
> > the messages that need to be treated in real-time by the NAS. Sven 
> > already made some counting regarding this topic. I believe 
> this point 
> > could lead to scalability issues. If we had the above described 
> > potential disaster, then we end-up getting serious 
> Robustness issues.
> >
> >
> > Thanks
> >
> > Francois
> >
> >
> > Regards,
> > Michel.
> > --------------------------------------------------------------------
> >
> > CONFIDENTIALITY NOTICE
> >
> > This message and its attachments are addressed solely to 
> the persons 
> > above and may contain confidential information. If you have 
> received 
> > the message in error, be informed that any use of the 
> content hereof 
> > is prohibited. Please return it immediately to the sender 
> and delete 
> > the message. Should you have any questions, please contact us by 
> > replying to [email-masked].
> >
> >         Thank you
> >
> >                                         www.telecomitalia.it
> >
> > --------------------------------------------------------------------
> >
> >
> >
> > _______________________________________________
> > ANCP mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ancp
> >
> > --------------------------------------------------------------------
> >
> > CONFIDENTIALITY NOTICE
> >
> > This message and its attachments are addressed solely to 
> the persons 
> > above and may contain confidential information. If you have 
> received 
> > the message in error, be informed that any use of the 
> content hereof 
> > is prohibited. Please return it immediately to the sender 
> and delete 
> > the message. Should you have any questions, please contact us by 
> > replying to [email-masked].
> >
> >         Thank you
> >
> >                                         www.telecomitalia.it
> >
> > --------------------------------------------------------------------
> >
> >
> >
> > _______________________________________________
> > ANCP mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ancp
> 
> 
> _______________________________________________
> ANCP mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ancp
> 

_______________________________________________
ANCP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ancp

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 4 Dec 2007 00:16:58 +0100

ooops, typo, corrected inline

> From: Wojciech Dec (wdec) 
> Sent: 03 December 2007 14:44
> To: OOGHE Sven; Francois Le Faucheur (flefauch); Maglione Roberta
> Cc: Michel Platnic; [email-masked]; Ullio Mario
> [ANCP]Commentsondraft-maglione)
> 
> Hi Sven,
> 
> catching up on this thread: It seems that to accommodate the 
> "best effort" proposal below, the AN would need to have some 
> sort of mechanism that tells it which channel is best effort 
> and which one isn't, and a white list prioritization. This 
> seems to be a tad bit too complex, so unless I'm 
> misinterpreting things, it would seem that keeping this sort 
> of addition FROM BEING ADDED to ANCP would be advisable.
              ^^^^^^^^^^^^^^^^
> > I agree that a catch-all statement can be used to create either 
> > "accept all" or "reject all" behavior. Perhaps one
> > nuance: it would make sense to indicate wheher such 
> channels could be 
> > accepted as "best effort".
> > That means that in case other premium channels are 
> requested lateron, 
> > the best effort content (e.g. internet TV) would be the first to 
> > suffer.
> > 
> > - indicate in the framework that by default, all joins for 
> a channel 
> > that is not in one of the configured lists, will be rejected.
> > - the operator can override this behavior by configuring such a 
> > wildcard entry in one of the lists. It should be possible 
> to indicate 
> > whether or not the channel is a best effort channel or premium 
> > content.
> > 
> > Comments?
> > 
> > Regards,
> > Sven
> > 
> > Cc: Francois Le Faucheur IMAP; [email-masked]; Michel Platnic; Ullio 
> > Mario
> behavior 
> > described by Sven with very trivial extra config:
> > Then any flow that doesn't match the Black or Grey list will be 
> > accepted by AN.
> > 
> > Both proposals can easily achieve both required behaviors 
> (ie "block 
> > if doesn't match" _and_  "accept if doesn't match").
> > The only difference is about whether you need to add the single 
> > catch-all entry or not to achieve your favorite behavior.
> > 
> like several 
> > folks were more comfortable with the conservative side (ie if there 
> > has not been a conscious decision to allow a flow, then 
> better block 
> > it;  it is easy enough to explicitly "allow-all" if operator is so 
> > inclined).
> > 
> > >       <S=s.t.u.v/Mask,G=g.h.i.l/Mask> "

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Wed, 5 Dec 2007 00:15:40 -0500

Francois/Maglione
   Reviving this discussion, since Francois asked for people's
preference. I would vote for flexibility with network level conditional
access. If there is no match in white/black/grey lists, then the default
behaviour on the AN should be configurable, and allow any of the
following:
1. REJECT on "no match" - i.e. if none of the access control lists
matched, the Join will NOT result in replication
2. ADMIT on "no match" - i.e. if none of the access control lists
matched, the Join will result in replication
3. "QUERY NAS" on "no match" - i.e. if none of the access control lists
matched, the Join will result in query to the NAS.

The issue I have with "catch-all" in the lists is that it makes the
right behaviour dependent on order of application of these lists e.g. if
you want to always query NAS on no-match, you could put a "catch-all" in
the grey list. However, this means that the grey list needs to be
applied after white and black lists. On the other end if the desired
behaviour is to reject a join on "no-match", then you could configure a
"catch-all" in the black list. However, the black list will then need to
be applied after the white and grey list.
Maybe the right approach is for AN to have a configurable "default
action" on "no match" in addition to the three lists. If there is no
match in any of the lists (or if there are no lists), the configured
default-action is applied. The default-action could be configured
globally on the AN or configured (or downloaded from NAS to the AN) on
per access-line basis.

With the default actions defined above, we should be able to accommodate
various scenarios with network level conditional access:

1. Network level conditional Access completely on NAS (i.e. all joins
should result in query to NAS)
   No white/black/grey list defined, "no match" default-action
configured as "QUERY-NAS".

2. No network level conditional access on AN or NAS (DRM at application
level deemed sufficient) - all joins admitted on AN.
     No white/black/grey lists defined, "no match" default-action
configured as "ADMIT"

3. Network level conditional access completely on AN (i.e. no join
should ever trigger a query to NAS), and operator wants to reject a join
if it doesn't match any access control lists.
    white list +  "no match" default-action configured as "REJECT"

4. Network level conditional access completely on AN (i.e. no join
should every trigger a query to NAS), and operator wants to admit a join
if it doesn't match any access control list
    black list + "no match" default-action configured as "ADMIT"

5. Network level conditional access distributed between AN and NAS on
flow basis, and operator wants to reject a join if it doesn't match any
access control list
      white list + grey list +  "no match default-action configured as
"REJECT"

6. Network level conditional access distributed between AN and NAS on
flow basis, and operator wants to admit a join if it doesn't match any
access control list
     black list + grey list + "no match" default-action configured as
"ADMIT"

7. Network level conditional access distributed between AN and NAS on
flow basis, and operator wants to query a NAS if it doesn't match any
access control list
     black list + grey list + "no match" default-action configured as
"QUERY NAS"

Regards

-Sanjay

-----Original Message-----
From: Francois Le Faucheur IMAP [mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Monday, November 26, 2007 4:08 AM
To: Maglione Roberta; OOGHE Sven
Cc: Ullio Mario; [email-masked]; Michel Platnic
Subject: Re: Introducing Mutlicast Grey-List (was RE: [ANCP]
Commentsondraft-maglione)

Roberta, Sven, and all,

It is worth noting that Roberta's proposal below allows the behavior
described by Sven with very trivial extra config:
simply add one "catch-all" entry (<S=*,G=*>) in the White List.
Then any flow that doesn't match the Black or Grey list will be accepted
by AN.

Scenario 4:

Scenario 5:

        * "Black-Default":  proposal below where:
                - Default ==> everything that doesn't match Black/Grey
gets blocked
                - add a single-entry catch-all in White-List==>
everything that doesn't match Black/Grey gets accepted

        * "White-Default": modified proposal where:
                - Default ==> everything that doesn't match Black/Grey
gets accepted
                - add a single-entry catch-all in Black-List==>
everything that doesn't match Black/Grey gets blocked

Both proposals can easily achieve both required behaviors (ie "block if
doesn't match" _and_  "accept if doesn't match"). The only difference is
about whether you need to add the single catch-all entry or not to
achieve your favorite behavior.

 From previous discussion on that topic, it sounded to me like several
folks were more comfortable with the conservative side (ie if there has
not been a conscious decision to allow a flow, then better block it;  it
is easy enough to explicitly "allow-all" if operator is so inclined).

Francois

On 25 Nov 2007, at 22:26, Maglione Roberta wrote:

> selected drop as the default behavior for unconfigured multicast flows
> is in order to be consistent with the typical ACL behavior, and also
> From: OOGHE Sven [mailto:[email-masked]
<mailto:[email-masked]> ]
> Subject: RE: Introducing Mutlicast Grey-List (was RE: [ANCP] Comments
> ondraft-maglione)
>
> Hello Roberta,
>
> Thinking a bit further about the default behavior, I am not sure that
> From: Maglione Roberta [mailto:[email-masked]
<mailto:[email-masked]> ]
> modification to the text of draft-ietf-ancp-framework-04.txt in order
> to introduce Multicast Grey List and leave Black List (i.e. deny) as
> default behavior.
> A White list associated with an Access Port identifies the multicast
> associated with an Access Port identifies the multicast flows that are
> associated with an Access Port identifies the multicast flows that are
> not allowed to be replicated to that port. A Grey list associated with
> receiving a Join message, before starting traffic replication queries
> "Upon receiving a join message on an Access Port, the Access Node will
> first check if the requested multicast flow is part of a White list
> or a
> Black list associated with that Access Port.  If it is part of a White
> "Upon receiving a join message on an Access Port, the Access Node will
> first check if the requested multicast flow is part of a White,
> Grey or
> list, the AN can autonomously start replicating multicast traffic.  If
> message
> because the request is not authorized. If it is part of a Grey list
> the
> AN uses ANCP to query the NAS, that in turn will respond to the AN
> indicating whether the join is to be honored (and hence replication
> performed by the AN) or denied (and hence replication not performed by
> the AN.) If a Join message is received by AN for a flow which is
> not on
> any list, then it is rejected (i.e. the default behavior is to drop
> such
> multiple
> lists, then a deterministic algorithm (to be specified in ancp-
> protocol)
>       and multicast CAC for the access line are performed by the NAS.
>       In this case, the AN can use ANCP to query the NAS, that in turn
>       performs multicast CAC and responds to the AN indicating whether
>       and multicast CAC for the access line are performed by the NAS.
> matches the Grey List, the AN can use ANCP to query the NAS, that in
> turn
>       performs multicast CAC and responds to the AN indicating whether
>       information to Access Ports on an Access Node, using Black lists
>       and White lists. "
> By
>       information to Access Ports on an Access Node, using Black, Grey
>       and White lists. "
>
> Replace
>
> Upon receiving a join to a multicast flow which matches the Grey List
>       Access Port, the AN must support using ANCP to query the NAS to
>       receive a response indicating whether that join is to be honored
>       or denied."
>
> By:
>
> List
> for a specific  Access Port, the AN must support using ANCP to
> query the
> NAS to receive a response indicating whether that join is to be
> honored
> or denied.
> "
>       entry in the Black List nor in the White List  nor Grey List for
> List,
> AN is not allowed to propagate that join request, before the
> successful
> List,
> AN SHOULD be able to autonomously stop replication and SHOULD be
> able to
> modify
> individual entries in White, Black and Grey lists.
>
>
> From: Michel Platnic [mailto:[email-masked]
<mailto:[email-masked]> ]
> From: Francois Le Faucheur IMAP [mailto:[email-masked]
<mailto:[email-masked]> ]
> <Michel> Using access control capabilities within the access network
> - refrain from sending any content to a customer that was not paid for
> 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
> Lists
> and White-Lists include the ability to define arbitrarily large
> Black-List which contains a single "catch-all" entry that matches any
> Multicast address & Source. Then you can define a White-List with the
> policy whereby everything is blocked by AN, except the channels that
> channels, or it can easily be used as a "catch-all" (for all, or for
> default
> state wherein any channel being neither part of White-list nor
> security
> issue.
> 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
> I understand that some applications may require sophisticated policy
> decision making and that, as a matter of fact, some AN/central policy
> For now I am not convinced that solution proposed is either Robust or
> Scalable.
>
> messages that need to be treated in real-time by the NAS. Sven already
> made some counting regarding this topic. I believe this point could
> lead
> to scalability issues. If we had the above described potential
> disaster,
> then we end-up getting serious Robustness issues.
>
>
> Thanks
>
> Francois
>
>
> Regards,
> Michel.
> This message and its attachments are addressed solely to the persons
> received the
> message in error, be informed that any use of the content hereof is
> prohibited. Please return it immediately to the sender and delete the
> message. Should you have any questions, please contact us by
> replying to
<https://www1.ietf.org/mailman/listinfo/ancp>
> This message and its attachments are addressed solely to the
> persons above and may contain confidential information. If you have
> received the message in error, be informed that any use of the
> content hereof is prohibited. Please return it immediately to the
> sender and delete the message. Should you have any questions,
> please contact us by replying to [email-masked].
>
>         Thank you
>
>                                         www.telecomitalia.it
>
<https://www1.ietf.org/mailman/listinfo/ancp>

_______________________________________________
ANCP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ancp
<https://www1.ietf.org/mailman/listinfo/ancp>

---

From: Stefaan DE CNODDER <[email-masked]>
Date: Wed, 05 Dec 2007 22:45:05 +0100

I understood that the 3 lists are not checked in a particular order, but 
that the most specific entry that the join matches with is selected, 
independent in which list it is.  A catch-all entry is always the least 
specific entry, and therefore always the least prefered entry.  In fact, 
the terms white/black/grey list are not really good because it is more 
an action that applies to a particular entry that is in one big list: 
accept, reject or query.  With such a catch-all entry, any desired 
default behavior can be easily achieved, and therefore what the real 
default behavior is (i.e., when there would be no catch-all entry), is 
not really that important anymore, as long it is not query.

regards,
Stefaan

Sanjay Wadhwa wrote:
> behaviour on the AN should be configurable, and allow any of the following:
> *1. Network level conditional Access completely on NAS* (i.e. all joins 
> *2. No network level conditional access on AN or NAS (DRM at application 
> level deemed sufficient)* - all joins admitted on AN.
> *3. Network level conditional access completely on AN (i.e. no join 
> *    white list +  "no match" default-action configured as "REJECT"
> 
> *4. Network level conditional access completely on AN (i.e. no join 
> if it doesn’t match any access control list
> *    black list + "no match" default-action configured as "ADMIT"
> 
> *5. Network level conditional access distributed between AN and NAS on 
> access control list*
> *6. Network level conditional access distributed between AN and NAS on 
> *     black list + grey list + "no match" default-action configured as 
> "ADMIT"
> 
> *7. Network level conditional access distributed between AN and NAS on 
> *     black list + grey list + "no match" default-action configured as 
> "QUERY NAS"
> 
> Regards
> 
> -Sanjay
> 
>  > because the request is not authorized"
>  >
>  > By:
>  >
> ------------------------------------------------------------------------
>

---

From: "Philippe Champagne (pchamp)" <[email-masked]>
Date: Wed, 5 Dec 2007 15:12:32 -0800

I agree

All the rules are looked at from the most specific to the least specific
- regardless of which list they are part of (ie: regardless if in
white/grey or black). Assuming all rules (ACL) are unique ( the same
rule can only be in one given list - white grey or black)

Order of processing: Most specific rule to least
Rules            List to apply to
S1/30  G1/30     Grey    (/30 means most specific, first looked at)
S2/24  G2/24     White
S3/24  G3/24     Black
S4/16  G4/24     White
S5/16  G5/16     Grey
0/0    0/0       Black   (catch all, least specific since /0 - last in
the list)

Note that if S2 == S3 then  G2 must be != G3 You can't have Sn == Sm  &&
Gn == Gm at the same time.

I understand your point Stefaan about the white/grey/black driving an
action rather than being a list.
I do like the white/grey/black list from the general concept though -
easier for an outsider to catch this.
Perhaps we should see this as a classification into a list which drives
the action for 
white:accept, 
grey:query, 
black:deny

So introducing the action keyword but leaving the terms white/grey/black
-Phil

-----Original Message-----
From: Stefaan DE CNODDER [mailto:[email-masked]] 
Sent: Wednesday, December 05, 2007 4:45 PM
To: Sanjay Wadhwa
Cc: [email-masked]
Subject: Re: Introducing Mutlicast Grey-List (was RE:[ANCP] 

I understood that the 3 lists are not checked in a particular 
order, but that the most specific entry that the join matches 
with is selected, independent in which list it is.  A catch-all 
entry is always the least specific entry, and therefore always 
the least prefered entry.  In fact, the terms white/black/grey 
list are not really good because it is more an action that 
applies to a particular entry that is in one big list: 
accept, reject or query.  With such a catch-all entry, any 
desired default behavior can be easily achieved, and therefore 
what the real default behavior is (i.e., when there would be no 
catch-all entry), is not really that important anymore, as long 
it is not query.

regards,
Stefaan

Sanjay Wadhwa wrote:
> preference. I would vote for flexibility with network level 
> conditional access. If there is no match in white/black/grey lists, 
> then the default behaviour on the AN should be configurable, 
and allow any of the following:
> matched, the Join will NOT result in replication 2. ADMIT on "no 
> match" - i.e. if none of the access control lists matched, the Join 
> will result in replication 3. "QUERY NAS" on "no match" - 
i.e. if none 
> of the access control lists matched, the Join will result in query to 
> the NAS.
> 
> right behaviour dependent on order of application of these lists e.g. 
> if you want to always query NAS on no-match, you could put a 
> "catch-all" in the grey list. However, this means that the grey list 
> needs to be applied after white and black lists. On the other end if 
> the desired behaviour is to reject a join on "no-match", then you 
> could configure a "catch-all" in the black list. However, the black 
> list will then need to be applied after the white and grey list.
> With the default actions defined above, we should be able to 
> accommodate various scenarios with network level conditional access:
> 
> *1. Network level conditional Access completely on NAS* (i.e. all 
> joins should result in query to NAS)
> *2. No network level conditional access on AN or NAS (DRM at 
> application level deemed sufficient)* - all joins admitted on AN.
> should ever trigger a query to NAS), and operator wants to reject a 
> join if it doesn't match any access control lists.
> should every trigger a query to NAS), and operator wants to admit a 
> join if it doesn't match any access control list
> flow basis, and operator wants to reject a join if it doesn't match 
> any access control list*
Black/Grey 
>                 - Default ==> everything that doesn't match 
Black/Grey 
> Both proposals can easily achieve both required behaviors (ie "block 
> if doesn't match" _and_  "accept if doesn't match"). The only 
> difference is about whether you need to add the single 
catch-all entry 
> or not to achieve your favorite behavior.
> 
like several 
> has not been a conscious decision to allow a flow, then better block 
> it;  it is easy enough to explicitly "allow-all" if operator 
is so inclined).
>  > your point makes sense to me, "accept as best effort" is a 
valid  > 
> > selected drop as the default behavior for unconfigured multicast 
> flows  > is in order to be consistent with the typical ACL behavior, 
> and also  > because this seemed to be the preferred action according 
> to the  > discussion we had in Chicago and on the mailing list, but I 
> open to  > modify the default behavior, according to Working 
group feedback.
> <mailto:[email-masked]> ]  > Sent: Fri 11/23/2007 5:16 
> PM  > To: Maglione Roberta; [email-masked]  > Cc: Ullio Mario; Michel 
> Platnic  > Subject: RE: Introducing Mutlicast Grey-List (was RE: 
> [ANCP] Comments  > ondraft-maglione)  >  > Hello Roberta,  >  > 
sure that  
> > dropping would be the right approach. (cf. "If a Join message is  > 
> received by AN for a flow which is not on any list, then it is  > 
> rejected")  >  > Imagine any multicast flow out there on the Internet 
> (e.g. Internet  > TV), then if it is not configured on the Access 
> Node, it will be  > rejected. I don't think this is what an end-user 
> would want.
>  >
> <mailto:[email-masked]> ]  > Sent: vrijdag 23 
> november 2007 8:36  > To: [email-masked]  > Cc: Ullio Mario; Michel 
> Platnic  > Subject: Introducing Mutlicast Grey-List (was RE: [ANCP] 
> Comments  > ondraft-maglione)  >  > Hello,
>  > modification to the text of draft-ietf-ancp-framework-04.txt in 
> order  > to introduce Multicast Grey List and leave Black List (i.e. 
> deny) as  > default behavior.
> multicast  > flows that are allowed to be replicated to that port.  A 
> Black list  > associated with an Access Port identifies the multicast 
> flows that are  > not allowed to be replicated to that port."
>  >
>  > By:
> > done using a "White list", "Grey list",  and/or a "Black 
list". A  > 
> White list associated with an Access Port identifies the multicast  > 
> flows that are allowed to be replicated to that port.  A 
Black list  > 
> > not allowed to be replicated to that port. A Grey list associated 
> with  > an Access Port identifies the multicast flows for 
which the AN 
> on  > receiving a Join message, before starting traffic replication 
> queries  > NAS for further authorization.
>  > "Upon receiving a join message on an Access Port, the Access Node 
> will  > first check if the requested multicast flow is part 
of a White 
> list  > or a  > Black list associated with that Access Port.  
If it is 
> part of a White  > list, the AN can autonomously start replicating 
> multicast  > traffic.  If  > it is part of a Black list, the AN can 
> autonomously discard the  > message  > because the request is not 
> authorized"
>  >
>  > By:
>  >
>  > "Upon receiving a join message on an Access Port, the Access Node 
> will  > first check if the requested multicast flow is part of a 
> White,  > Grey or  > a Black list associated with that Access Port.  
> If it is part of a  > White  > list, the AN can autonomously start 
> replicating multicast traffic.  If  > it is part of a Black list, the 
> AN can autonomously discard the  > message  > because the request is 
> not authorized. If it is part of a Grey list  > the  > AN 
uses ANCP to 
> query the NAS, that in turn will respond to the AN  > indicating 
> whether the join is to be honored (and hence replication  > performed 
> by the AN) or denied (and hence replication not performed by  > the 
> AN.) If a Join message is received by AN for a flow which is  
> not on  
> > such  > messages.) If a join is received by AN for a flow that 
> matches  > multiple  > lists, then a deterministic algorithm (to be 
> specified in ancp-  > protocol)  > is used by the AN to decide which 
> list behavior takes precedence.
by the NAS.
that in turn
indicating whether
by the NAS.
>  > matches the Grey List, the AN can use ANCP to query the NAS, that 
> in  > turn
indicating whether
Black lists
Black, Grey
>  > Upon receiving a join to a multicast flow which matches the Grey 
> List  > the ANCP MUST allow the AN to query the NAS to request an 
> admission  > decision for replicating that multicast flow to a 
> particular Access  > Port.
>  >
>  >
>  >
>  > Section 4.7.6
>  > Replace and split in two
>  >
the NAS to
> > List  > for a specific  Access Port, the AN must support using ANCP 
> to  > query the  > NAS to receive a response indicating whether that 
> join is to be  > honored  > or denied.
>  > "
Grey List for
> > List,  > AN is not allowed to propagate that join request, before 
> the  > successful  > authorization from the NAS is received."
>  >
> > List,  > AN SHOULD be able to autonomously stop replication and 
> SHOULD be  > able to  > advertise this event to the NAS."
>  >
>  >
>  > Section 4.8.6
>  > Adding:
>  > The NAS MUST support using ANCP to incrementally add, 
remove and  > 
> modify  > individual entries in White, Black and Grey lists.
>  >
>  >
>  > Broadband Network Services Innovation  > 
>  > Sent: Tuesday, July 24, 2007 8:22 PM  > To: Francois Le Faucheur 
> IMAP  > Cc: Garofalo Angelo; [email-masked]  > Subject: RE: [ANCP] 
> Comments on draft-maglione  >  > Hi Francois,  > Please see my 
> comments inline,  > Regards,  > Michel.
>  >
>  >
> <mailto:[email-masked]> ]  > Sent: Mon 7/23/2007 6:23 PM  > To: 
> Michel Platnic  > Cc: Francois Le Faucheur IMAP; OOGHE Sven; 
> [email-masked];  > [email-masked]  > Subject: Re: 
> [ANCP] Comments on draft-maglione Hi Michel,  >  >  >  > <Michel> 
> Using access control capabilities within the access network  > 
>  > - 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').
>  >
> > 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.
all, or for  
>  > behavior for any non-explicitly defined channel is not to query  > 
> NAS/Central_server.
>  >
>  > See in draft-maglione:
>  > "
>  >  <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.
>  >
>  > 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.
>  > I understand that some applications may require sophisticated 
> policy  > decision making and that, as a matter of fact, some 
> AN/central policy  > server synchronization mechanism should to be 
> proposed, but the  > solution  > must be Robust and Scalable.
>  > For now I am not convinced that solution proposed is either Robust 
> or  > Scalable.
>  >
>  > Let us know if you have specific robustness/scalability 
concerns  > 
> (beyond  > the one discussed above)?
> > the  > messages that need to be treated in real-time by the NAS. 
> Sven already  > made some counting regarding this topic. I believe 
> this point could  > lead  > to scalability issues. If we had 
the above 
> described potential  > disaster,  > then we end-up getting serious 
> Robustness issues.
>  >
>  >
>  > Thanks
>  >
>  > Francois
>  >
>  >
>  > Regards,
>  > Michel.
>  > 
> persons  > above and may contain confidential information. If 
you have  
> > received the  > message in error, be informed that any use of the 
> content hereof is  > prohibited. Please return it immediately to the 
> sender and delete the  > message. Should you have any questions, 
> please contact us by  > replying to  > [email-masked].
>  >
>  >         Thank you
>  >
>  >                                         www.telecomitalia.it
>  >
>  > 
>  > This message and its attachments are addressed solely to the  > 
> persons above and may contain confidential information. If 
you have  > 
> received the message in error, be informed that any use of the  > 
> content hereof is prohibited. Please return it immediately to the  > 
> sender and delete the message. Should you have any questions,  >

---

From: "OOGHE Sven" <[email-masked]>
Date: Thu, 6 Dec 2007 13:41:25 +0100

Woj,

The reason I introduced the notion of "accept as best effort" is that I
believe this makes sense when supporting "Internet TV" kind or programs.
Operators want to have a means to avoid "over the top" multicast content
from impacting the quality of premium content (e.g. walled-garden via a
partnership with a content provider).

I don't think it presents that much additional effort - in fact I think
it is fairly straightforward and can be implemented by means of a flag
on those entries in the white list that require such behavior.

Perhaps operators can provide guidance whether or not this scheme is
useful for Interent multicast content.

Regards,
Sven 

-----Original Message-----
From: Wojciech Dec (wdec) [mailto:[email-masked]] 
Sent: dinsdag 4 december 2007 0:17
To: Wojciech Dec (wdec); OOGHE Sven; Francois Le Faucheur (flefauch);
Maglione Roberta

> effort" proposal below, the AN would need to have some sort of 
> mechanism that tells it which channel is best effort and which one 
> isn't, and a white list prioritization. This seems to be a tad bit too

> complex, so unless I'm misinterpreting things, it would seem that 
> keeping this sort of addition FROM BEING ADDED to ANCP would be 
> advisable.
              ^^^^^^^^^^^^^^^^
> Black list
> Black list