From ancp-bounces@ietf.org Mon Dec 03 17:44:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzK1h-0001Rd-J3; Mon, 03 Dec 2007 17:44:33 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IzK1g-0001J9-AE for ancp-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 17:44:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzK1f-0001IT-Vl for ancp@ietf.org; Mon, 03 Dec 2007 17:44:31 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzK1d-00026g-Io for ancp@ietf.org; Mon, 03 Dec 2007 17:44:31 -0500 X-IronPort-AV: E=Sophos;i="4.23,245,1194217200"; d="scan'208";a="159450140" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Dec 2007 23:44:29 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB3MiS9O030452; Mon, 3 Dec 2007 23:44:28 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lB3MiS3Z005512; Mon, 3 Dec 2007 22:44:28 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 23:44:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Introducing Mutlicast Grey-List (was RE: [ANCP] Commentsondraft-maglione) Date: Mon, 3 Dec 2007 23:44:26 +0100 Message-ID: In-Reply-To: <8144761F31F48D43AD53D09F5350E380020DEE4E@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Introducing Mutlicast Grey-List (was RE: [ANCP] Commentsondraft-maglione) Thread-Index: AcgwC/JfPZ6MmvR4TYies2mWcWFJCQA7HGrQAUEyS8A= References: <8C253CB7-CF45-431D-94B6-4AC1A1653524@cisco.com><9E577E61D0108D4F8CD482029B613F5C0181BF87@PTPEVS108BA020.idc.cww.telecomitalia.it><8144761F31F48D43AD53D09F5350E38002069337@FRVELSMBS22.ad2.ad.alcatel.com><9E577E61D0108D4F8CD482029B613F5C01A7CF5F@PTPEVS108BA020.idc.cww.telecomitalia.it> <8144761F31F48D43AD53D09F5350E380020DEE4E@FRVELSMBS22.ad2.ad.alcatel.com> From: "Wojciech Dec (wdec)" To: "OOGHE Sven" , "Francois Le Faucheur (flefauch)" , "Maglione Roberta" X-OriginalArrivalTime: 03 Dec 2007 22:44:28.0115 (UTC) FILETIME=[0FAEFA30:01C835FE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=21292; t=1196721868; x=1197585868; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20Introducing=20Mutlicast=20Grey-List=20(was=20RE=3A=20 [ANCP]=20Commentsondraft-maglione) |Sender:=20; bh=y8o8xXpnfdaHDkY27Zy6AyPjAC7tvN45mdcG9EdcRsY=; b=gDhFUM1yv6WOU1foKlAQLezbwbMrFzwVtOMWgGUXC/OJbBat2X1MHQUr/17FiqYMzBL3xoFg 8ttXzdHWNipQz+hjhxu4aI374QStJc2AjUsqWNcB2Bq46sBaAqz9Rd3+; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: dae47ebd0d959deee2d6f67621ddb2e3 Cc: Michel Platnic , ancp@ietf.org, Ullio Mario X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org 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:Sven.Ooghe@alcatel-lucent.be]=20 > Sent: 27 November 2007 14:29 > To: Francois Le Faucheur (flefauch); Maglione Roberta > Cc: Ullio Mario; ancp@ietf.org; Michel Platnic > Subject: RE: Introducing Mutlicast Grey-List (was RE: [ANCP]=20 > Commentsondraft-maglione) >=20 > Francois, >=20 > I agree that a catch-all statement can be used to create=20 > either "accept all" or "reject all" behavior. Perhaps one=20 > nuance: it would make sense to indicate wheher such channels=20 > could be accepted as "best effort". > That means that in case other premium channels are requested=20 > lateron, the best effort content (e.g. internet TV) would be=20 > the first to suffer. >=20 > Perhaps the way forward is the following: > - indicate in the framework that by default, all joins for a=20 > channel that is not in one of the configured lists, will be rejected. > - the operator can override this behavior by configuring such=20 > a wildcard entry in one of the lists. It should be possible=20 > to indicate whether or not the channel is a best effort=20 > channel or premium content. >=20 > Comments? >=20 > Regards, > Sven >=20 > -----Original Message----- > From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] > Sent: maandag 26 november 2007 10:08 > To: Maglione Roberta; OOGHE Sven > Cc: Francois Le Faucheur IMAP; ancp@ietf.org; Michel Platnic;=20 > Ullio Mario > Subject: Re: Introducing Mutlicast Grey-List (was RE: [ANCP] Comments > ondraft-maglione) >=20 > Roberta, Sven, and all, >=20 > It is worth noting that Roberta's proposal below allows the=20 > behavior described by Sven with very trivial extra config: > simply add one "catch-all" entry () in the White List. > Then any flow that doesn't match the Black or Grey list will=20 > be accepted by AN. >=20 > For example, we could add: >=20 > Scenario 4: > * White-List =3D { } > =3D=3D> any Join message gets accepted by AN >=20 > Scenario 5: > * White-List =3D { } > * Black-List =3D { , , ... = } > =3D=3D> Join ( S=3D*,G=3DGi) gets rejected by AN ( 1<=3Di<=3Dn ) > =3D=3D> everything else gets accepted by AN >=20 >=20 > So the choice is between: >=20 > * "Black-Default": proposal below where: > - Default =3D=3D> everything that doesn't match=20 > Black/Grey gets blocked > - add a single-entry catch-all in White-List=3D=3D>=20 > everything that doesn't match Black/Grey gets accepted >=20 > * "White-Default": modified proposal where: > - Default =3D=3D> everything that doesn't match=20 > Black/Grey gets accepted > - add a single-entry catch-all in Black-List=3D=3D>=20 > everything that doesn't match Black/Grey gets blocked >=20 > Both proposals can easily achieve both required behaviors (ie=20 > "block if doesn't match" _and_ "accept if doesn't match").=20 > The only difference is about whether you need to add the=20 > single catch-all entry or not to achieve your favorite behavior. >=20 > From previous discussion on that topic, it sounded to me=20 > like several folks were more comfortable with the=20 > conservative side (ie if there has not been a conscious=20 > decision to allow a flow, then better block it; it is easy=20 > enough to explicitly "allow-all" if operator is so inclined). >=20 > So considering the above ... what do people prefer? > Perhaps we could also poll the WG in Vancouver on that topic. >=20 > Francois >=20 > On 25 Nov 2007, at 22:26, Maglione Roberta wrote: >=20 > > Hi Sven, > > thanks for your comments; > > your point makes sense to me, "accept as best effort" is a valid=20 > > option for default behavior. > > The basic idea for the default action is to avoid query the NAS for=20 > > all multicast flows that do not match any list: the reason why we=20 > > selected drop as the default behavior for unconfigured=20 > multicast flows >=20 > > is in order to be consistent with the typical ACL behavior,=20 > and also=20 > > because this seemed to be the preferred action according to the=20 > > discussion we had in Chicago and on the mailing list, but I open to=20 > > modify the default behavior, according to Working group feedback. > > > > Regards, > > Roberta > > > > > > -----Original Message----- > > From: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be] > > Sent: Fri 11/23/2007 5:16 PM > > To: Maglione Roberta; ancp@ietf.org > > Cc: Ullio Mario; Michel Platnic > > Subject: RE: Introducing Mutlicast Grey-List (was RE:=20 > [ANCP] Comments > > ondraft-maglione) > > > > Hello Roberta, > > > > Thinking a bit further about the default behavior, I am not=20 > sure that=20 > > dropping would be the right approach. (cf. "If a Join message is=20 > > 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=20 > > TV), then if it is not configured on the Access Node, it will be=20 > > 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=20 > > 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:roberta.maglione@telecomitalia.it] > > Sent: vrijdag 23 november 2007 8:36 > > To: ancp@ietf.org > > 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=20 > > modification to the text of=20 > draft-ietf-ancp-framework-04.txt in order=20 > > to introduce Multicast Grey List and leave Black List (i.e.=20 > deny) as=20 > > default behavior. > > We'd appreciate feedback. > > > > Regards, > > Roberta > > > > > > Section 3.4.1 > > Replace: > > " Provisioning the conditional access information on the AN can be=20 > > done using a "White list" and/or a "Black list". > > A White list associated with an Access Port identifies the=20 > multicast=20 > > flows that are allowed to be replicated to that port. A Black list=20 > > associated with an Access Port identifies the multicast=20 > flows that are >=20 > > not allowed to be replicated to that port." > > > > By: > > " Provisioning the conditional access information on the AN can be=20 > > done using a "White list", "Grey list", and/or a "Black list". A=20 > > White list associated with an Access Port identifies the multicast=20 > > flows that are allowed to be replicated to that port. A Black list=20 > > associated with an Access Port identifies the multicast=20 > flows that are >=20 > > not allowed to be replicated to that port. A Grey list=20 > associated with >=20 > > an Access Port identifies the multicast flows for which the AN on=20 > > receiving a Join message, before starting traffic=20 > replication queries=20 > > NAS for further authorization. > > Each list contains zero, one or multiple entries and each entry may=20 > > specify a single flow or contain ranges (i.e. mask on Group address=20 > > and/or mask on Source address). > > > > > > Replace: > > "Upon receiving a join message on an Access Port, the=20 > Access Node will=20 > > first check if the requested multicast flow is part of a=20 > White list or=20 > > a Black list associated with that Access Port. If it is part of a=20 > > White > > list, the AN can autonomously start replicating multicast =20 > > traffic. If > > it is part of a Black list, the AN can autonomously discard the=20 > > message because the request is not authorized" > > > > By: > > > > "Upon receiving a join message on an Access Port, the=20 > Access Node will=20 > > first check if the requested multicast flow is part of a=20 > White, Grey=20 > > or a Black list associated with that Access Port. If it is=20 > part of a=20 > > White list, the AN can autonomously start replicating multicast=20 > > traffic. If it is part of a Black list, the AN can autonomously=20 > > discard the message because the request is not authorized. If it is=20 > > part of a Grey list the AN uses ANCP to query the NAS, that in turn=20 > > will respond to the AN indicating whether the join is to be honored=20 > > (and hence replication performed by the AN) or denied (and hence=20 > > replication not performed by the AN.) If a Join message is=20 > received by=20 > > AN for a flow which is not on any list, then it is rejected=20 > (i.e. the=20 > > default behavior is to drop such > > messages.) If a join is received by AN for a flow that matches=20 > > multiple lists, then a deterministic algorithm (to be specified in=20 > > ancp- > > protocol) > > is used by the AN to decide which list behavior takes precedence. > > Following are some example scenarios: > > > > Scenario 1: > > * no config: > > =3D=3D> any Join message gets rejected by AN > > > > Scenario 2: > > * White List =3D { , , ... = } > > =3D=3D> Join ( S=3D*,G=3DGi) gets honored by AN ( 1<=3Di<=3Dn ) > > =3D=3D> everything else gets rejected by AN > > > > Scenario 3: > > * White List =3D { , , ... = } > > * Grey List =3D { } m>n > > =3D=3D> Join ( S=3D*,G=3DGi) gets honored by AN ( 1<=3Di<=3Dn ) > > =3D=3D> Join ( S=3Ds,G=3DGm) triggers ANCP Admission Request to NAS > > =3D=3D> 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=20 > by the NAS. > > In this case, the AN can use ANCP to query the NAS,=20 > that in turn > > performs multicast CAC and responds to the AN=20 > indicating whether > > the join is to be honored (and hence replication performed by=20 > > 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=20 > by the NAS. > > In this case, upon receiving a join to a multicast flow which=20 > > matches the Grey List, the AN can use ANCP to query the=20 > NAS, that in=20 > > turn > > performs multicast CAC and responds to the AN=20 > indicating whether > > the join is to be honored (and hence replication performed by=20 > > 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=20 > Black lists > > and White lists. " > > By > > " The ANCP MUST support providing multicast conditional access > > information to Access Ports on an Access Node, using=20 > 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=20 > Grey List=20 > > the ANCP MUST allow the AN to query the NAS to request an admission=20 > > decision for replicating that multicast flow to a particular Access=20 > > 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=20 > the NAS to > > receive a response indicating whether that join is to=20 > be honored > > or denied." > > > > By: > > > > " Upon receiving a join to a multicast flow which matches the Grey=20 > > List for a specific Access Port, the AN must support using ANCP to=20 > > query the NAS to receive a response indicating whether that=20 > join is to=20 > > be honored or denied. > > " > > " The AN must deny any join to a multicast flow that does not match=20 > > any > > entry in the Black List nor in the White List nor=20 > Grey List for=20 > > the relevant Access Port" > > > > > > Adding the following requirements: > > > > "Upon receiving a join to a multicast flow which matches the Grey=20 > > List, AN is not allowed to propagate that join request, before the=20 > > successful authorization from the NAS is received." > > > > "Upon receiving a leave to a multicast flow which matches the Grey=20 > > List, AN SHOULD be able to autonomously stop replication=20 > and SHOULD be=20 > > able to advertise this event to the NAS." > > > > > > Section 4.8.6 > > Adding: > > The NAS MUST support using ANCP to incrementally add, remove and=20 > > modify individual entries in White, Black and Grey lists. > > > > > > ------------------------------------------------------- > > Roberta Maglione - CCIE #18425 > > Telecom Italia > > Broadband Network Services Innovation > > ------------------------------------------------------- > > ________________________________________ > > From: Michel Platnic [mailto:Michel.Platnic@ecitele.com] > > Sent: Tuesday, July 24, 2007 8:22 PM > > To: Francois Le Faucheur IMAP > > Cc: Garofalo Angelo; ancp@ietf.org > > Subject: RE: [ANCP] Comments on draft-maglione > > > > Hi Francois, > > Please see my comments inline, > > Regards, > > Michel. > > > > > > ________________________________________ > > From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] > > Sent: Mon 7/23/2007 6:23 PM > > To: Michel Platnic > > Cc: Francois Le Faucheur IMAP; OOGHE Sven; ancp@ietf.org;=20 > > angelo.garofalo@telecomitalia.it > > Subject: Re: [ANCP] Comments on draft-maglione Hi Michel, > > > > > > > > Using access control capabilities within the=20 > access network=20 > > provides the two main following benefits: > > - refrain from sending any content to a customer that was=20 > not paid for=20 > > (mostly relevant when Encryption is not used) > > - provides a filter against end-user applications/hackers that may=20 > > send IGMP requests with invalid IP address > > > > A solution where all the IP addresses that are not part of=20 > either the=20 > > Black-list or the White-List are sent to a central policy=20 > server for=20 > > authorization gives me some concerns regarding the=20 > robustness of the=20 > > whole system. Same concern regarding the treatment of unknown IP=20 > > source addresses ('Everything else'). > > > > Agreed. We had these concerns in mind also. This is why the Black-=20 > > Lists and White-Lists include the ability to define=20 > arbitrarily large=20 > > ranges/masks. In particular, as an example, one can easily define a=20 > > Black-List which contains a single "catch-all" entry that=20 > matches any=20 > > Multicast address & Source. Then you can define a=20 > White-List with the=20 > > explicit channels you want to allow. This effectively implements a=20 > > policy whereby everything is blocked by AN, except the=20 > channels that=20 > > have been explicitly allowed in the White-List. > > In other words, the Black-List can be used for explicit listing of=20 > > channels, or it can easily be used as a "catch-all" (for=20 > all, or for=20 > > 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=20 > > 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. ) > > o an exact match for a (S,G) SSM channel (e.g. =20 > > > > > > o a mask-based range match for a (*,G) ASM group (e.g. > > ) > > o a mask-based range match for a (S,G) SSM channel (e.g. > > > > " > > Let me try to rephrase your proposal; there would be a=20 > > default state wherein any channel being neither part of=20 > White-list nor=20 > > Black-list would be discarded. > > If its the case I agree with you that this solution solves the=20 > > security issue. > > > > But what about when AN is not in this default state? > > If "Accept everything else" is used then again same problem of=20 > > security is encountered, and any hacker or application can overload=20 > > the policy server with requests. > > To my understanding, the model proposed, where the NAS is=20 > getting the=20 > > customer request for authorization, requires this mode of operation. > > So we still have the same problem. > > Did I miss anything? > > > > > >=20 > ______________________________________________________________________ >=20 > > __ > > ______ > > I understand that some applications may require=20 > sophisticated policy=20 > > decision making and that, as a matter of fact, some=20 > AN/central policy=20 > > server synchronization mechanism should to be proposed, but the=20 > > solution must be Robust and Scalable. > > For now I am not convinced that solution proposed is either=20 > Robust or=20 > > Scalable. > > > > Let us know if you have specific robustness/scalability concerns=20 > > (beyond the one discussed above)? > > Then we could work together on addressing those. > > > > Well, there is still this scalable issue when duplicating=20 > > the messages that need to be treated in real-time by the NAS. Sven=20 > > already made some counting regarding this topic. I believe=20 > this point=20 > > could lead to scalability issues. If we had the above described=20 > > potential disaster, then we end-up getting serious=20 > Robustness issues. > > > > > > Thanks > > > > Francois > > > > > > Regards, > > Michel. > > -------------------------------------------------------------------- > > > > CONFIDENTIALITY NOTICE > > > > This message and its attachments are addressed solely to=20 > the persons=20 > > above and may contain confidential information. If you have=20 > received=20 > > the message in error, be informed that any use of the=20 > content hereof=20 > > is prohibited. Please return it immediately to the sender=20 > and delete=20 > > the message. Should you have any questions, please contact us by=20 > > replying to webmaster@telecomitalia.it. > > > > Thank you > > > > www.telecomitalia.it > > > > -------------------------------------------------------------------- > > > > > > > > _______________________________________________ > > ANCP mailing list > > ANCP@ietf.org > > https://www1.ietf.org/mailman/listinfo/ancp > > > > -------------------------------------------------------------------- > > > > CONFIDENTIALITY NOTICE > > > > This message and its attachments are addressed solely to=20 > the persons=20 > > above and may contain confidential information. If you have=20 > received=20 > > the message in error, be informed that any use of the=20 > content hereof=20 > > is prohibited. Please return it immediately to the sender=20 > and delete=20 > > the message. Should you have any questions, please contact us by=20 > > replying to webmaster@telecomitalia.it. > > > > Thank you > > > > www.telecomitalia.it > > > > -------------------------------------------------------------------- > > > > > > > > _______________________________________________ > > ANCP mailing list > > ANCP@ietf.org > > https://www1.ietf.org/mailman/listinfo/ancp >=20 >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp >=20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Dec 03 18:17:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzKXE-0003UD-Ps; Mon, 03 Dec 2007 18:17:08 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IzKXD-0003PG-E4 for ancp-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 18:17:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzKXD-0003P5-0s for ancp@ietf.org; Mon, 03 Dec 2007 18:17:07 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzKXA-0007qx-HZ for ancp@ietf.org; Mon, 03 Dec 2007 18:17:06 -0500 X-IronPort-AV: E=Sophos;i="4.23,245,1194217200"; d="scan'208";a="159451180" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 04 Dec 2007 00:17:03 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lB3NH3cl025185; Tue, 4 Dec 2007 00:17:03 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lB3NH33Z012595; Mon, 3 Dec 2007 23:17:03 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 00:17:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Introducing Mutlicast Grey-List (was RE: [ANCP]Commentsondraft-maglione) Date: Tue, 4 Dec 2007 00:16:58 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Introducing Mutlicast Grey-List (was RE: [ANCP]Commentsondraft-maglione) Thread-Index: AcgwC/JfPZ6MmvR4TYies2mWcWFJCQA7HGrQAUEyS8AAAUbaQA== References: <8C253CB7-CF45-431D-94B6-4AC1A1653524@cisco.com><9E577E61D0108D4F8CD482029B613F5C0181BF87@PTPEVS108BA020.idc.cww.telecomitalia.it><8144761F31F48D43AD53D09F5350E38002069337@FRVELSMBS22.ad2.ad.alcatel.com><9E577E61D0108D4F8CD482029B613F5C01A7CF5F@PTPEVS108BA020.idc.cww.telecomitalia.it><8144761F31F48D43AD53D09F5350E380020DEE4E@FRVELSMBS22.ad2.ad.alcatel.com> From: "Wojciech Dec (wdec)" To: "Wojciech Dec (wdec)" , "OOGHE Sven" , "Francois Le Faucheur (flefauch)" , "Maglione Roberta" X-OriginalArrivalTime: 03 Dec 2007 23:17:03.0582 (UTC) FILETIME=[9D3B8FE0:01C83602] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=23029; t=1196723823; x=1197587823; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20Introducing=20Mutlicast=20Grey-List=20(was=20RE=3A=20 [ANCP]Commentsondraft-maglione) |Sender:=20; bh=aD9NVx5AI3Pp4/FuAusmQRo9JMw3aSicYoYPTeyJ7Bw=; b=ndKwhguD9L9/wDQrt/JtXT75rDDFaDanmpwdGvqitCEiN8YWkihTpCP97oxDnsXFLU6qoyWV PiRKlIn6yv8eteWmA7Et9MKYfcjY4v/vRDeL4Jou3V1czrdgGi3v0D55; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea10c7a57c6f5d0512401188e6188235 Cc: Ullio Mario , ancp@ietf.org, Michel Platnic X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org ooops, typo, corrected inline > -----Original Message----- > From: Wojciech Dec (wdec)=20 > Sent: 03 December 2007 14:44 > To: OOGHE Sven; Francois Le Faucheur (flefauch); Maglione Roberta > Cc: Michel Platnic; ancp@ietf.org; Ullio Mario > Subject: RE: Introducing Mutlicast Grey-List (was RE:=20 > [ANCP]Commentsondraft-maglione) >=20 > Hi Sven, >=20 > catching up on this thread: It seems that to accommodate the=20 > "best effort" proposal below, the AN would need to have some=20 > sort of mechanism that tells it which channel is best effort=20 > and which one isn't, and a white list prioritization. This=20 > seems to be a tad bit too complex, so unless I'm=20 > misinterpreting things, it would seem that keeping this sort=20 > of addition FROM BEING ADDED to ANCP would be advisable. ^^^^^^^^^^^^^^^^ >=20 > Regards, > Woj. >=20 > > -----Original Message----- > > From: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be] > > Sent: 27 November 2007 14:29 > > To: Francois Le Faucheur (flefauch); Maglione Roberta > > Cc: Ullio Mario; ancp@ietf.org; Michel Platnic > > Subject: RE: Introducing Mutlicast Grey-List (was RE: [ANCP] > > Commentsondraft-maglione) > >=20 > > Francois, > >=20 > > I agree that a catch-all statement can be used to create either=20 > > "accept all" or "reject all" behavior. Perhaps one > > nuance: it would make sense to indicate wheher such=20 > channels could be=20 > > accepted as "best effort". > > That means that in case other premium channels are=20 > requested lateron,=20 > > the best effort content (e.g. internet TV) would be the first to=20 > > suffer. > >=20 > > Perhaps the way forward is the following: > > - indicate in the framework that by default, all joins for=20 > a channel=20 > > that is not in one of the configured lists, will be rejected. > > - the operator can override this behavior by configuring such a=20 > > wildcard entry in one of the lists. It should be possible=20 > to indicate=20 > > whether or not the channel is a best effort channel or premium=20 > > content. > >=20 > > Comments? > >=20 > > Regards, > > Sven > >=20 > > -----Original Message----- > > From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] > > Sent: maandag 26 november 2007 10:08 > > To: Maglione Roberta; OOGHE Sven > > Cc: Francois Le Faucheur IMAP; ancp@ietf.org; Michel Platnic; Ullio=20 > > Mario > > Subject: Re: Introducing Mutlicast Grey-List (was RE:=20 > [ANCP] Comments > > ondraft-maglione) > >=20 > > Roberta, Sven, and all, > >=20 > > It is worth noting that Roberta's proposal below allows the=20 > behavior=20 > > described by Sven with very trivial extra config: > > simply add one "catch-all" entry () in the White List. > > Then any flow that doesn't match the Black or Grey list will be=20 > > accepted by AN. > >=20 > > For example, we could add: > >=20 > > Scenario 4: > > * White-List =3D { } > > =3D=3D> any Join message gets accepted by AN > >=20 > > Scenario 5: > > * White-List =3D { } > > * Black-List =3D { , , ... = } > > =3D=3D> Join ( S=3D*,G=3DGi) gets rejected by AN ( 1<=3Di<=3Dn ) > > =3D=3D> everything else gets accepted by AN > >=20 > >=20 > > So the choice is between: > >=20 > > * "Black-Default": proposal below where: > > - Default =3D=3D> everything that doesn't match=20 > Black/Grey gets blocked > > - add a single-entry catch-all in White-List=3D=3D>=20 > everything that=20 > > doesn't match Black/Grey gets accepted > >=20 > > * "White-Default": modified proposal where: > > - Default =3D=3D> everything that doesn't match=20 > Black/Grey gets accepted > > - add a single-entry catch-all in Black-List=3D=3D>=20 > everything that=20 > > doesn't match Black/Grey gets blocked > >=20 > > Both proposals can easily achieve both required behaviors=20 > (ie "block=20 > > if doesn't match" _and_ "accept if doesn't match"). > > The only difference is about whether you need to add the single=20 > > catch-all entry or not to achieve your favorite behavior. > >=20 > > From previous discussion on that topic, it sounded to me=20 > like several=20 > > folks were more comfortable with the conservative side (ie if there=20 > > has not been a conscious decision to allow a flow, then=20 > better block=20 > > it; it is easy enough to explicitly "allow-all" if operator is so=20 > > inclined). > >=20 > > So considering the above ... what do people prefer? > > Perhaps we could also poll the WG in Vancouver on that topic. > >=20 > > Francois > >=20 > > On 25 Nov 2007, at 22:26, Maglione Roberta wrote: > >=20 > > > Hi Sven, > > > thanks for your comments; > > > your point makes sense to me, "accept as best effort" is a valid=20 > > > option for default behavior. > > > The basic idea for the default action is to avoid query=20 > the NAS for=20 > > > all multicast flows that do not match any list: the=20 > reason why we=20 > > > selected drop as the default behavior for unconfigured > > multicast flows > >=20 > > > is in order to be consistent with the typical ACL behavior, > > and also > > > because this seemed to be the preferred action according to the=20 > > > discussion we had in Chicago and on the mailing list, but=20 > I open to=20 > > > modify the default behavior, according to Working group feedback. > > > > > > Regards, > > > Roberta > > > > > > > > > -----Original Message----- > > > From: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be] > > > Sent: Fri 11/23/2007 5:16 PM > > > To: Maglione Roberta; ancp@ietf.org > > > Cc: Ullio Mario; Michel Platnic > > > Subject: RE: Introducing Mutlicast Grey-List (was RE:=20 > > [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=20 > > > 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=20 > (e.g. Internet=20 > > > TV), then if it is not configured on the Access Node, it will be=20 > > > 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=20 > > > lists, that the behavior would be to accept it as best=20 > effort, i.e. > > > accept without further admission control checks. > > > > > > What do you think? > > > > > > Regards, > > > Sven > > > > > > > > > -----Original Message----- > > > From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] > > > Sent: vrijdag 23 november 2007 8:36 > > > To: ancp@ietf.org > > > 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=20 > > > modification to the text of > > draft-ietf-ancp-framework-04.txt in order > > > to introduce Multicast Grey List and leave Black List (i.e.=20 > > deny) as > > > default behavior. > > > We'd appreciate feedback. > > > > > > Regards, > > > Roberta > > > > > > > > > Section 3.4.1 > > > Replace: > > > " Provisioning the conditional access information on the=20 > AN can be=20 > > > 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=20 > Black list=20 > > > associated with an Access Port identifies the multicast > > flows that are > >=20 > > > not allowed to be replicated to that port." > > > > > > By: > > > " Provisioning the conditional access information on the=20 > AN can be=20 > > > done using a "White list", "Grey list", and/or a "Black list". A=20 > > > White list associated with an Access Port identifies the=20 > multicast=20 > > > flows that are allowed to be replicated to that port. A=20 > Black list=20 > > > associated with an Access Port identifies the multicast > > flows that are > >=20 > > > not allowed to be replicated to that port. A Grey list > > associated with > >=20 > > > an Access Port identifies the multicast flows for which the AN on=20 > > > receiving a Join message, before starting traffic > > replication queries > > > NAS for further authorization. > > > Each list contains zero, one or multiple entries and each=20 > entry may=20 > > > specify a single flow or contain ranges (i.e. mask on=20 > Group address=20 > > > 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=20 > part of a=20 > > > White > > > list, the AN can autonomously start replicating multicast =20 > > > traffic. If > > > it is part of a Black list, the AN can autonomously discard the=20 > > > 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=20 > > > traffic. If it is part of a Black list, the AN can autonomously=20 > > > discard the message because the request is not=20 > authorized. If it is=20 > > > part of a Grey list the AN uses ANCP to query the NAS,=20 > that in turn=20 > > > will respond to the AN indicating whether the join is to=20 > be honored=20 > > > (and hence replication performed by the AN) or denied (and hence=20 > > > 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=20 > > > 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: > > > =3D=3D> any Join message gets rejected by AN > > > > > > Scenario 2: > > > * White List =3D { , , ... = } > > > =3D=3D> Join ( S=3D*,G=3DGi) gets honored by AN ( 1<=3Di<=3Dn ) > > > =3D=3D> everything else gets rejected by AN > > > > > > Scenario 3: > > > * White List =3D { , , ... = } > > > * Grey List =3D { } m>n > > > =3D=3D> Join ( S=3D*,G=3DGi) gets honored by AN ( 1<=3Di<=3Dn ) > > > =3D=3D> Join ( S=3Ds,G=3DGm) triggers ANCP Admission Request to = NAS > > > =3D=3D> 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=20 > performed by=20 > > > the > > > AN) or denied. In the process, the NAS may=20 > 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=20 > flow which=20 > > > 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=20 > performed by=20 > > > the > > > AN) or denied. In the process, the NAS may=20 > 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=20 > admission=20 > > > decision for replicating that multicast flow to a=20 > particular Access=20 > > > Port. > > > > > > > > > > > > Section 4.7.6 > > > Replace and split in two > > > > > > " Upon receiving a join to a multicast flow which does=20 > 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=20 > the Grey=20 > > > List for a specific Access Port, the AN must support=20 > using ANCP to=20 > > > 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=20 > not match=20 > > > 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=20 > > > List, AN is not allowed to propagate that join request,=20 > before the=20 > > > successful authorization from the NAS is received." > > > > > > "Upon receiving a leave to a multicast flow which matches=20 > the Grey=20 > > > 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=20 > > > modify individual entries in White, Black and Grey lists. > > > > > > > > > ------------------------------------------------------- > > > Roberta Maglione - CCIE #18425 > > > Telecom Italia > > > Broadband Network Services Innovation > > > ------------------------------------------------------- > > > ________________________________________ > > > From: Michel Platnic [mailto:Michel.Platnic@ecitele.com] > > > Sent: Tuesday, July 24, 2007 8:22 PM > > > To: Francois Le Faucheur IMAP > > > Cc: Garofalo Angelo; ancp@ietf.org > > > Subject: RE: [ANCP] Comments on draft-maglione > > > > > > Hi Francois, > > > Please see my comments inline, > > > Regards, > > > Michel. > > > > > > > > > ________________________________________ > > > From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] > > > Sent: Mon 7/23/2007 6:23 PM > > > To: Michel Platnic > > > Cc: Francois Le Faucheur IMAP; OOGHE Sven; ancp@ietf.org;=20 > > > angelo.garofalo@telecomitalia.it > > > Subject: Re: [ANCP] Comments on draft-maglione Hi 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=20 > that may=20 > > > 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=20 > > > source addresses ('Everything else'). > > > > > > Agreed. We had these concerns in mind also. This is why=20 > the Black-=20 > > > Lists and White-Lists include the ability to define > > arbitrarily large > > > ranges/masks. In particular, as an example, one can=20 > easily define a=20 > > > 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=20 > implements a=20 > > > 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=20 > listing of=20 > > > 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=20 > > > 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. ) > > > o an exact match for a (S,G) SSM channel (e.g. =20 > > > > > > > > > o a mask-based range match for a (*,G) ASM group (e.g. > > > ) > > > o a mask-based range match for a (S,G) SSM channel (e.g. > > > " > > > Let me try to rephrase your proposal; there would be a=20 > > > 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=20 > > > security issue. > > > > > > But what about when AN is not in this default state? > > > If "Accept everything else" is used then again same problem of=20 > > > security is encountered, and any hacker or application=20 > can overload=20 > > > 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=20 > operation. > > > So we still have the same problem. > > > Did I miss anything? > > > > > > > > >=20 > >=20 > ______________________________________________________________________ > >=20 > > > __ > > > ______ > > > 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=20 > > > 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=20 > > > (beyond the one discussed above)? > > > Then we could work together on addressing those. > > > > > > Well, there is still this scalable issue when=20 > duplicating=20 > > > the messages that need to be treated in real-time by the=20 > NAS. Sven=20 > > > already made some counting regarding this topic. I believe > > this point > > > could lead to scalability issues. If we had the above described=20 > > > potential disaster, then we end-up getting serious > > Robustness issues. > > > > > > > > > Thanks > > > > > > Francois > > > > > > > > > Regards, > > > Michel. > > >=20 > -------------------------------------------------------------------- > > > > > > 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=20 > > > replying to webmaster@telecomitalia.it. > > > > > > Thank you > > > > > > www.telecomitalia.it > > > > > >=20 > -------------------------------------------------------------------- > > > > > > > > > > > > _______________________________________________ > > > ANCP mailing list > > > ANCP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ancp > > > > > >=20 > -------------------------------------------------------------------- > > > > > > 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=20 > > > replying to webmaster@telecomitalia.it. > > > > > > Thank you > > > > > > www.telecomitalia.it > > > > > >=20 > -------------------------------------------------------------------- > > > > > > > > > > > > _______________________________________________ > > > ANCP mailing list > > > ANCP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ancp > >=20 > >=20 > > _______________________________________________ > > ANCP mailing list > > ANCP@ietf.org > > https://www1.ietf.org/mailman/listinfo/ancp > >=20 >=20 >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp >=20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Dec 05 00:22:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izmi5-00046Z-QW; Wed, 05 Dec 2007 00:22:13 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Izmi3-00040t-Or for ancp-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 00:22:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izmi1-0003wt-T1 for ancp@ietf.org; Wed, 05 Dec 2007 00:22:10 -0500 Received: from exprod7og107.obsmtp.com ([64.18.2.167]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izmi0-0002bH-IM for ancp@ietf.org; Wed, 05 Dec 2007 00:22:09 -0500 Received: from source ([66.129.224.36]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Tue, 04 Dec 2007 21:21:54 PST Received: from proton.jnpr.net ([10.10.2.37]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 21:21:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Introducing Mutlicast Grey-List (was RE: [ANCP] Commentsondraft-maglione) Date: Wed, 5 Dec 2007 00:15:40 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280BD8E78A@proton.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Introducing Mutlicast Grey-List (was RE: [ANCP] Commentsondraft-maglione) Thread-Index: AcgwDAFFnfWHv4j/TOiGf2mtySoP1gG6cHYg From: "Sanjay Wadhwa" To: "Francois Le Faucheur IMAP" , "Maglione Roberta" , "OOGHE Sven" X-OriginalArrivalTime: 05 Dec 2007 05:21:53.0168 (UTC) FILETIME=[BEDB1100:01C836FE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 81161953a609a1ee951e8becddfd92e9 Cc: Michel Platnic , ancp@ietf.org, Ullio Mario X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1572915731==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1572915731== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C836FD.E1FEBD76" This is a multi-part message in MIME format. ------_=_NextPart_001_01C836FD.E1FEBD76 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable 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:flefauch@cisco.com ] Sent: Monday, November 26, 2007 4:08 AM To: Maglione Roberta; OOGHE Sven Cc: Ullio Mario; ancp@ietf.org; 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 () 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 =3D { } =3D=3D> any Join message gets accepted by AN Scenario 5: * White-List =3D { } * Black-List =3D { , , ... = } =3D=3D> Join ( S=3D*,G=3DGi) gets rejected by AN ( 1<=3Di<=3Dn = ) =3D=3D> everything else gets accepted by AN So the choice is between: * "Black-Default": proposal below where: - Default =3D=3D> everything that doesn't match = Black/Grey gets blocked - add a single-entry catch-all in White-List=3D=3D> everything that doesn't match Black/Grey gets accepted * "White-Default": modified proposal where: - Default =3D=3D> everything that doesn't match = Black/Grey gets accepted - add a single-entry catch-all in Black-List=3D=3D> 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:Sven.Ooghe@alcatel-lucent.be ] > Sent: Fri 11/23/2007 5:16 PM > To: Maglione Roberta; ancp@ietf.org > 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:roberta.maglione@telecomitalia.it ] > Sent: vrijdag 23 november 2007 8:36 > To: ancp@ietf.org > 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 =20 > 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: > =3D=3D> any Join message gets rejected by AN > > Scenario 2: > * White List =3D { , , ... = } > =3D=3D> Join ( S=3D*,G=3DGi) gets honored by AN ( 1<=3Di<=3Dn ) > =3D=3D> everything else gets rejected by AN > > Scenario 3: > * White List =3D { , , ... = } > * Grey List =3D { } m>n > =3D=3D> Join ( S=3D*,G=3DGi) gets honored by AN ( 1<=3Di<=3Dn ) > =3D=3D> Join ( S=3Ds,G=3DGm) triggers ANCP Admission Request to = NAS > =3D=3D> 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:Michel.Platnic@ecitele.com ] > Sent: Tuesday, July 24, 2007 8:22 PM > To: Francois Le Faucheur IMAP > Cc: Garofalo Angelo; ancp@ietf.org > Subject: RE: [ANCP] Comments on draft-maglione > > Hi Francois, > Please see my comments inline, > Regards, > Michel. > > > ________________________________________ > From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com ] > Sent: Mon 7/23/2007 6:23 PM > To: Michel Platnic > Cc: Francois Le Faucheur IMAP; OOGHE Sven; ancp@ietf.org; > angelo.garofalo@telecomitalia.it > Subject: Re: [ANCP] Comments on draft-maglione Hi 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. ) > o an exact match for a (S,G) SSM channel (e.g. > > > o a mask-based range match for a (*,G) ASM group (e.g. > ) > o a mask-based range match for a (S,G) SSM channel (e.g. > > " > 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. > > 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 > webmaster@telecomitalia.it. > > Thank you > > www.telecomitalia.it > > -------------------------------------------------------------------- > > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > 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 webmaster@telecomitalia.it. > > Thank you > > www.telecomitalia.it > > -------------------------------------------------------------------- > > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp ------_=_NextPart_001_01C836FD.E1FEBD76 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

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

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

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

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

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

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

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

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

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

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

Regards

-Sanjay

-----Original=20 Message-----
From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com <mailto:flefauch@cisco.com> = ]
Sent:=20 Monday, November 26, 2007 4:08 AM
To: Maglione Roberta; OOGHE = Sven
Cc:=20 Ullio Mario; ancp@ietf.org; Michel Platnic
Subject: Re: Introducing = Mutlicast=20 Grey-List (was RE: [ANCP] Commentsondraft-maglione)

Roberta, = Sven, and=20 all,

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

For example, we = could=20 add:

Scenario 4:
        *=20 White-List =3D { = <S=3D*,G=3D*>}
       =20 =3D=3D> any Join message gets accepted by AN

Scenario=20 5:
        * White-List =3D {=20 <S=3D*,G=3D*>}
        * = Black-List =3D {=20 <S=3D*,G=3DG1> , <S=3D*,G=3DG2>, ... <S=3D*,G=3DGn>=20 }
        =3D=3D> Join ( = S=3D*,G=3DGi) gets=20 rejected by AN  ( 1<=3Di<=3Dn=20 )
        =3D=3D> everything = else gets=20 accepted by AN


So the choice is=20 between:

        *=20 "Black-Default":  proposal below=20 where:
          &nb= sp;    =20 - Default =3D=3D> everything that doesn't match Black/Grey gets=20 blocked
          &n= bsp;    =20 - add a single-entry catch-all in White-List=3D=3D> everything that = doesn't match=20 Black/Grey gets = accepted

        *=20 "White-Default": modified proposal=20 where:
          &nb= sp;    =20 - Default =3D=3D> everything that doesn't match Black/Grey gets=20 accepted
          &= nbsp;    =20 - add a single-entry catch-all in Black-List=3D=3D> everything that = doesn't match=20 Black/Grey gets blocked

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

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

So considering the above ... what do = people=20 prefer?
Perhaps we could also poll the WG in Vancouver on that=20 topic.

Francois

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

> Hi Sven,
>       = thanks=20 for your comments;
> your point makes sense to me, "accept as best = effort"=20 is a valid
> option for default behavior.
> The basic idea = for the=20 default action is to avoid query the NAS for
> all multicast flows = that do=20 not match any list:  the reason why we
> selected drop as the = default=20 behavior for unconfigured multicast flows
> is in order to be = consistent=20 with the typical ACL behavior, and also
> because this seemed to = be the=20 preferred action according to the
> discussion we had in Chicago = and on=20 the mailing list, but I open to
> modify the default behavior, = according=20 to Working group feedback.
>
> Regards,
>=20 Roberta
>
>
> -----Original Message-----
> From: = OOGHE=20 Sven [mailto:Sven.Ooghe@alcatel-lu= cent.be=20 <mailto:Sven.Ooghe@alcatel-lu= cent.be>=20 ]
> Sent: Fri 11/23/2007 5:16 PM
> To: Maglione Roberta;=20 ancp@ietf.org
> Cc: Ullio Mario; Michel Platnic
> Subject: = RE:=20 Introducing Mutlicast Grey-List (was RE: [ANCP] Comments
>=20 ondraft-maglione)
>
> Hello Roberta,
>
> = Thinking a bit=20 further about the default behavior, I am not sure that
> dropping = would be=20 the right approach. (cf. "If a Join message is
> received by AN = for a flow=20 which is not on any list, then it is
> rejected")
>
> = Imagine=20 any multicast flow out there on the Internet (e.g. Internet
> TV), = then if=20 it is not configured on the Access Node, it will be
> rejected. I = don't=20 think this is what an end-user would want.
>
> Instead, I = would=20 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=20 further admission control checks.
>
> What do you=20 think?
>
> Regards,
> Sven
>
>
>=20 -----Original Message-----
> From: Maglione Roberta [mailto:roberta.maglione= @telecomitalia.it=20 <mailto:roberta.maglione= @telecomitalia.it>=20 ]
> Sent: vrijdag 23 november 2007 8:36
> To: = ancp@ietf.org
>=20 Cc: Ullio Mario; Michel Platnic
> Subject: Introducing Mutlicast = Grey-List=20 (was RE: [ANCP] Comments
> ondraft-maglione)
>
>=20 Hello,
>       as we discussed = during=20 Chicago meeting below is a proposal for
> modification to the text = of=20 draft-ietf-ancp-framework-04.txt in order
> to introduce Multicast = Grey=20 List and leave Black List (i.e. deny) as
> default = behavior.
> We'd=20 appreciate feedback.
>
> Regards,
>=20 Roberta
>
>
> Section 3.4.1
> Replace:
> " = Provisioning the conditional access information on the AN can be
> = done=20 using a "White list" and/or a "Black list".
> A White list = associated with=20 an Access Port identifies the multicast
> flows that are allowed = to be=20 replicated to that port.  A Black list
> associated with an = Access=20 Port identifies the multicast flows that are
> not allowed to be=20 replicated to that port."
>
> By:
> " Provisioning the = conditional access information on the AN can be
> done using a = "White=20 list", "Grey list",  and/or a "Black list". A
> White list = associated=20 with an Access Port identifies the multicast
> flows that are = allowed to=20 be replicated to that port.  A Black list
> associated with = an Access=20 Port identifies the multicast flows that are
> not allowed to be=20 replicated to that port. A Grey list associated with
> an Access = Port=20 identifies the multicast flows for which the AN on
> receiving a = Join=20 message, before starting traffic replication queries
> NAS for = further=20 authorization.
> Each list contains zero, one or multiple entries = and each=20 entry may
> specify a single flow or contain ranges (i.e. mask on = Group=20 address
> and/or mask on Source address).
>
>
>=20 Replace:
> "Upon receiving a join message on an Access Port, the = Access=20 Node will
> first check if the requested multicast flow is part of = a White=20 list
> or a
> Black list associated with that Access = Port.  If=20 it is part of a White
> list, the AN can autonomously start = replicating=20 multicast  
> traffic.  If
> it is part of a = Black=20 list, the AN can autonomously discard the
> message
> = because the=20 request is not authorized"
>
> By:
>
> "Upon = receiving a=20 join message on an Access Port, the Access Node will
> first check = if the=20 requested multicast flow is part of a White,
> Grey or
> a = Black=20 list associated with that Access Port.  If it is part of a
>=20 White
> list, the AN can autonomously start replicating multicast=20 traffic.  If
> it is part of a Black list, the AN can = autonomously=20 discard the
> message
> because the request is not = authorized. If it=20 is part of a Grey list
> the
> AN uses ANCP to query the = NAS, that=20 in turn will respond to the AN
> indicating whether the join is to = be=20 honored (and hence replication
> performed by the AN) or denied = (and hence=20 replication not performed by
> the AN.) If a Join message is = received by=20 AN for a flow which is
> not on
> any list, then it is = rejected=20 (i.e. the default behavior is to drop
> such
> messages.) If = a join=20 is received by AN for a flow that matches
> multiple
> = lists, then a=20 deterministic algorithm (to be specified in ancp-
> = protocol)
> is=20 used by the AN to decide which list behavior takes precedence.
> = Following=20 are some example scenarios:
>
> Scenario=20 1:
>       * no=20 config:
>       =3D=3D> any Join = message gets=20 rejected by AN
>
> Scenario=20 2:
>       * White List =3D { = <S=3D*,G=3DG1>=20 , <S=3D*,G=3DG2>, ... <S=3D*,G=3DGn>=20 }
>       =3D=3D> Join ( = S=3D*,G=3DGi) gets=20 honored by AN  ( 1<=3Di<=3Dn=20 )
>       =3D=3D> everything else = gets=20 rejected by AN
>
> Scenario=20 3:
>       * White List =3D { = <S=3D*,G=3DG1>=20 , <S=3D*,G=3DG2>, ... <S=3D*,G=3DGn>=20 }
>       * Grey List =3D { = <S=3Ds,G=3DGm>=20 }   m>n
>       = =3D=3D> Join (=20 S=3D*,G=3DGi) gets honored by AN  ( 1<=3Di<=3Dn=20 )
>       =3D=3D> Join ( = S=3Ds,G=3DGm) triggers=20 ANCP Admission Request to = NAS
>       =3D=3D>=20 everything else gets rejected by AN
>
>
> Section=20 3.4.2
>
> Replace:
> " One approach is for the AN to = query the=20 NAS so that both unicast
>       and = multicast CAC for the access line are performed by the=20 NAS.
>       In this case, the AN = can use=20 ANCP to query the NAS, that in = turn
>      =20 performs multicast CAC and responds to the AN indicating=20 whether
>       the join is to be = honored=20 (and hence replication performed by
>=20 the
>       AN) or denied.  In = the=20 process, the NAS may communicate with=20 a
>       Policy Server.
> = "
>=20 With:
> " One approach is for the AN to query the NAS so that both = unicast
>       and multicast CAC = for the=20 access line are performed by the=20 NAS.
>       In this case, upon = receiving a=20 join to a multicast flow which
> matches the Grey List, the AN can = use=20 ANCP to query the NAS, that in
>=20 turn
>       performs multicast CAC = and=20 responds to the AN indicating=20 whether
>       the join is to be = honored=20 (and hence replication performed by
>=20 the
>       AN) or denied.  In = the=20 process, the NAS may communicate with=20 a
>       Policy=20 Server.
>
>
> Section 4.2
> Replace
> " = The ANCP=20 MUST support providing multicast conditional=20 access
>       information to Access = Ports=20 on an Access Node, using Black = lists
>      =20 and White lists. "
> By
> " The ANCP MUST support providing=20 multicast conditional access
>       = information to Access Ports on an Access Node, using Black,=20 Grey
>       and White lists.=20 "
>
> Replace
>
> "The ANCP MUST support binding = a=20 particular Black list and = White
>       List=20 to a given Access Port"
> By:
>
> " The ANCP MUST = support=20 binding a particular Black, Grey and=20 White
>       List to a given Access = Port
> "
> Replace:
>
> The ANCP MUST support = partial=20 updates of the White lists and = Black
>      =20 lists.
> by
> The ANCP MUST support partial updates of the = White,=20 Grey and Black
>      =20 lists.
>
> Replace:
> The ANCP MUST allow the AN to = query the=20 NAS to request an
>       admission = decision=20 for replicating a multicast flow to=20 a
>       particular Access=20 Port.
>
> By
> Upon receiving a join to a multicast = flow which=20 matches the Grey List
> the ANCP MUST allow the AN to query the = NAS to=20 request an admission
> decision for replicating that multicast = flow to a=20 particular Access
> Port.
>
>
>
> Section=20 4.7.6
> Replace and split in two
>
> " Upon receiving = a join=20 to a multicast flow which does not match=20 any
>       entry in the Black List = nor in=20 the White List for a = specific
>       Access=20 Port, the AN must support using ANCP to query the NAS=20 to
>       receive a response = indicating=20 whether that join is to be = honored
>      =20 or denied."
>
> By:
>
> " Upon receiving a join = to a=20 multicast flow which matches the Grey
> List
> for a = specific =20 Access Port, the AN must support using ANCP to
> query the
> = NAS to=20 receive a response indicating whether that join is to be
> = honored
>=20 or denied.
> "
> " The AN must deny any join to a multicast = flow=20 that does not match
> = any
>      =20 entry in the Black List nor in the White List  nor Grey List = for
>=20 the relevant Access Port"
>
>
> Adding the following=20 requirements:
>
> "Upon receiving a join to a multicast flow = which=20 matches the Grey
> List,
> AN is not allowed to propagate = that join=20 request, before the
> successful
> authorization from the = NAS is=20 received."
>
> "Upon receiving a leave to a multicast flow = which=20 matches the Grey
> List,
> AN SHOULD be able to autonomously = stop=20 replication and SHOULD be
> able to
> advertise this event = to the=20 NAS."
>
>
> Section 4.8.6
> Adding:
> The = NAS MUST=20 support using ANCP to incrementally add, remove and
> = modify
>=20 individual entries in White, Black and Grey = lists.
>
>
>=20 -------------------------------------------------------
> Roberta=20 Maglione  - CCIE #18425
> Telecom Italia
> Broadband = Network=20 Services Innovation
>=20 -------------------------------------------------------
>=20 ________________________________________
> From: Michel Platnic = [mailto:Michel.Platnic@ecitele.= com=20 <mailto:Michel.Platnic@ecitele.= com>=20 ]
> Sent: Tuesday, July 24, 2007 8:22 PM
> To: Francois Le = Faucheur=20 IMAP
> Cc: Garofalo Angelo; ancp@ietf.org
> Subject: RE: = [ANCP]=20 Comments on draft-maglione
>
> Hi Francois,
> Please = see my=20 comments inline,
> Regards,
> = Michel.
>
>
>=20 ________________________________________
> From: Francois Le = Faucheur IMAP=20 [mailto:flefauch@cisco.com = <mailto:flefauch@cisco.com> = ]
>=20 Sent: Mon 7/23/2007 6:23 PM
> To: Michel Platnic
> Cc: = Francois Le=20 Faucheur IMAP; OOGHE Sven; ancp@ietf.org;
>=20 angelo.garofalo@telecomitalia.it
> Subject: Re: [ANCP] Comments on = draft-maglione Hi Michel,
>
>
>
> <Michel> = Using=20 access control capabilities within the access network
> provides = the two=20 main following benefits:
> - refrain from sending any content to a = customer that was not paid for
> (mostly relevant when Encryption = is not=20 used)
> - provides a filter against end-user applications/hackers = that=20 may
> send
> IGMP requests with invalid IP = address
>
> A=20 solution where all the IP addresses that are not part of either = the
>=20 Black-list or the White-List are sent to a central policy server = for
>=20 authorization gives me some concerns regarding the robustness of = the
>=20 whole system. Same concern regarding the treatment of unknown IP
> = source
> addresses ('Everything else').
>
> Agreed. We = had=20 these concerns in mind also. This is why the Black-
> = Lists
> and=20 White-Lists include the ability to define arbitrarily large
>=20 ranges/masks. In particular, as an example, one can easily define = a
>=20 Black-List which contains a single "catch-all" entry that matches = any
>=20 Multicast address & Source. Then you can define a White-List with=20 the
> explicit channels you want to allow. This effectively = implements=20 a
> policy whereby everything is blocked by AN, except the = channels=20 that
> have been explicitly allowed in the White-List.
> In = other=20 words, the Black-List can be used for explicit listing of
> = channels, or=20 it can easily be used as a "catch-all" (for all, or for
> = arbitrarily=20 large ranges of channels).
>
> This should address your = concern of=20 making sure that the "default"
> behavior for any non-explicitly = defined=20 channel is not to query
> NAS/Central_server.
>
> See = in=20 draft-maglione:
> "
> The White List and Black List can = contain=20 entries allowing:
>    o  an exact match for a = (*,G)=20 ASM group (e.g. <G=3Dg.h.i.l>)
>    o  = an exact=20 match for a (S,G) SSM channel (e.g.
>=20 <S=3Ds.t.u.v,G=3Dg.h.i.l>
>
>    = o  a=20 mask-based range match for a (*,G) ASM group=20 (e.g.
>      =20 <G=3Dg.h.i.l/Mask>)
>    o  a mask-based = range=20 match for a (S,G) SSM channel = (e.g.
>      =20 <S=3Ds.t.u.v/Mask,G=3Dg.h.i.l/Mask>
> "
>  = <Michel> Let=20 me try to rephrase your proposal; there would be a
> = default
> state=20 wherein any channel being neither part of White-list nor
> = Black-list=20 would be discarded.
> If its the case I agree with you that this = solution=20 solves the
> security
> issue.
>
> But what = about when=20 AN is not in this default state?
> If "Accept everything else" is = used=20 then again same problem of
> security
> is encountered, and = any=20 hacker or application can overload the policy
> server with=20 requests.
> To my understanding, the model proposed, where the NAS = is=20 getting the
> customer request for authorization, requires this = mode of=20 operation.
> So we still have the same problem.
> Did I miss = anything?
>
>
>=20 ______________________________________________________________________>=20 __
> ______
> I understand that some applications may = require=20 sophisticated policy
> decision making and that, as a matter of = fact, some=20 AN/central policy
> server synchronization mechanism should to be=20 proposed, but the
> solution
> must be Robust and = Scalable.
>=20 For now I am not convinced that solution proposed is either Robust = or
>=20 Scalable.
>
> Let us know if you have specific=20 robustness/scalability concerns
> (beyond
> the one = discussed=20 above)?
> Then we could work together on addressing=20 those.
>
>  <Michel> Well, there is still this = scalable=20 issue when duplicating
> the
> messages that need to be = treated in=20 real-time by the NAS. Sven already
> made some counting regarding = this=20 topic. I believe this point could
> lead
> to scalability = issues. If=20 we had the above described potential
> disaster,
> then we = end-up=20 getting serious Robustness issues.
>
>
>=20 Thanks
>
> Francois
>
>
> Regards,
> = Michel.
>=20 --------------------------------------------------------------------
&= gt;
>=20 CONFIDENTIALITY NOTICE
>
> This message and its attachments = are=20 addressed solely to the persons
> above and may contain = confidential=20 information. If you have
> received the
> message in error, = be=20 informed that any use of the content hereof is
> prohibited. = Please return=20 it immediately to the sender and delete the
> message. Should you = have any=20 questions, please contact us by
> replying to
>=20 webmaster@telecomitalia.it.
>
>     =    =20 Thank=20 you
>
>         =             &= nbsp;           &n= bsp;      =20 www.telecomitalia.it
>
>=20 --------------------------------------------------------------------
&= gt;
>
>
>=20 _______________________________________________
> ANCP mailing=20 list
> ANCP@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/ancp=20 <https://www1.ietf.or= g/mailman/listinfo/ancp>
>
>=20 --------------------------------------------------------------------
&= gt;
>=20 CONFIDENTIALITY NOTICE
>
> This message and its attachments = are=20 addressed solely to the
> persons above and may contain = confidential=20 information. If you have
> received the message in error, be = informed that=20 any use of the
> content hereof is prohibited. Please return it=20 immediately to the
> sender and delete the message. Should you = have any=20 questions,
> please contact us by replying to=20 webmaster@telecomitalia.it.
>
>     =    =20 Thank=20 you
>
>         =             &= nbsp;           &n= bsp;      =20 www.telecomitalia.it
>
>=20 --------------------------------------------------------------------
&= gt;
>
>
>=20 _______________________________________________
> ANCP mailing=20 list
> ANCP@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/ancp=20 <https://www1.ietf.or= g/mailman/listinfo/ancp>


______________________________= _________________
ANCP=20 mailing list
ANCP@ietf.org
https://www1.ietf.or= g/mailman/listinfo/ancp=20 <https://www1.ietf.or= g/mailman/listinfo/ancp>


------_=_NextPart_001_01C836FD.E1FEBD76-- --===============1572915731== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============1572915731==-- From ancp-bounces@ietf.org Wed Dec 05 06:46:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzshR-0003kI-1k; Wed, 05 Dec 2007 06:45:57 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IzshP-0003gI-NL for ancp-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 06:45:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzshJ-0003au-MO for ancp@ietf.org; Wed, 05 Dec 2007 06:45:49 -0500 Received: from exprod7og103.obsmtp.com ([64.18.2.159]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzshI-0002eB-Ia for ancp@ietf.org; Wed, 05 Dec 2007 06:45:49 -0500 Received: from source ([66.129.224.36]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Wed, 05 Dec 2007 03:43:30 PST Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Dec 2007 03:45:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] Which GSMP document? Date: Wed, 5 Dec 2007 06:45:12 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280BD8E7B0@proton.jnpr.net> In-Reply-To: <1B6169C658325341A3B8066E23919E1C1066AF@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Which GSMP document? Thread-Index: AcgnTcX0dUTE19zOS/+7LYajpXJgLAARZtxAACQ/03ADwzNl8A== From: "Sanjay Wadhwa" To: "Busser, M" , X-OriginalArrivalTime: 05 Dec 2007 11:45:14.0979 (UTC) FILETIME=[4D00E330:01C83734] X-Spam-Score: -4.0 (----) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 Cc: X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1271513862==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1271513862== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83734.4BE191D6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C83734.4BE191D6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Michael As mentioned in a response to a mail from Stefaan in October, = x-function field has been retained for use in the future to pass any = "function" specific data. 1 byte for the main function field seems = adequate. For the currently defined use-cases, x-function field should = be set to 0. In the updated version (02) of the draft, I have added text = to section 5.4.3 to clarify this.=20 We do need to fix the action code, as 0x08 is already defined in GSMPv3 = (this was also covered in response to Stefaans mail). We will address = this in the next rev of the draft. However, before we make that change, = I would like to verify if there are an implementations for line = configuration use case today that will be impacted by this change.=20 Regards -Sanjay ________________________________ From: Busser, M [mailto:Michael.Busser@t-systems.com]=20 Sent: Friday, November 16, 2007 3:25 AM To: ancp@ietf.org Subject: [ANCP] Which GSMP document? Hello Smita, all =20 The actual version of the ANCP draft refeers to:=20 [4] Doria, A. et al, "General Switch Management Protocol- V3" = (GSMPv3), RFC 3292, June 2002. =20 The first figure in section 5.4.3 fits to some later revisions of the = GSMP document=20 (e.g. draft-ietf-gsmp-v3-base-spec-06.txt or = draft-ietf-gsmp-v3-base-spec-08.txt). =20 There are some differences between this both documents, we should take = into account: =20 GSMPv3:=20 - The document does not have a field X-Function in the PORT MANAGEMENT = message It only contains a field Function wich is 16 bits long.=20 - The field "Transmit Data Rate" does exist - action code 0x8 is already defined as "Set Transmit Data Rate" =20 =20 A later revisions of the GSMP document (e.g. = draft-ietf-gsmp-v3-base-spec-06.txt or = draft-ietf-gsmp-v3-base-spec-08.txt): - The 16 bit field Function is splitted up into two 8 bit fields named = Function and X-Funtion=20 - The field "Transmit Data Rate" does not exist - action code 8 is not defined =20 =20 Shouldn't we describe the changes of the GSMP messages, which we need = for ANCP according to GSMPv3 RFC ? All later revisions of the GSMP document are already expired, as far as = i know. =20 =20 Best regard=20 =20 Michael Busser T-Systems Enterprise Services GmbH=20 Production Line Network Centric Systems ICT-Systems Integration Network Integration Services =20 =20 -----Urspr=FCngliche Nachricht----- Von: smita_selot@agilent.com [mailto:smita_selot@agilent.com]=20 Gesendet: Donnerstag, 15. November 2007 07:07 An: ancp@ietf.org Betreff: [ANCP] Query about ANCP The field X-Function which is sent in the Line Configuration Extension = block sent by NAS(Refer To section 5.4.3 in draft-ietf-ancp-protocol-01.txt) is not defined in = the=20 Draft. Where can this definition be found?=20 =20 Regards, Smita. ------_=_NextPart_001_01C83734.4BE191D6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nachricht
Hi Michael
 As mentioned in a response to a mail from = Stefaan in=20 October, x-function field has been retained for use in the future to = pass any=20 "function" specific data. 1 byte for the main function field seems = adequate. For=20 the currently defined use-cases, x-function field should be set to 0. In = the=20 updated version (02) of the draft, I have added text to section 5.4.3 to = clarify=20 this.
We do need to fix the action code, as 0x08 is = already=20 defined in GSMPv3 (this was also covered in response to Stefaans mail). = We will=20 address this in the next rev of the draft. However, before we make that = change,=20 I would like to verify if there are an implementations for line = configuration=20 use case today that will be impacted by this change. =

Regards
-Sanjay

From: Busser, M=20 [mailto:Michael.Busser@t-systems.com]
Sent: Friday, November = 16, 2007=20 3:25 AM
To: ancp@ietf.org
Subject: [ANCP] Which GSMP = document?

Hello Smita,=20 all
 
The=20 actual version of the ANCP draft refeers to:
[4]   Doria, = A. et al,=20 "General Switch Management Protocol- V3" (GSMPv3), RFC 3292, June=20 2002.
 
The=20 first figure in section 5.4.3 fits to some later revisions of the GSMP = document=20
(e.g. draft-ietf-gsmp-v3-base-spec-06.txt  or  = draft-ietf-gsmp-v3-base-spec-08.txt).
 
There=20 are some differences between this both documents, we should take into=20 account:
 
GSMPv3: 
- The=20 document does not have a field X-Function in the PORT MANAGEMENT=20 message
  It only=20 contains a field Function wich is 16 bits = long. 
- The field "Transmit Data Rate" does=20 exist
- action code 0x8 is already defined as "Set = Transmit=20 Data Rate"
 
 
A=20 later revisions of the GSMP document (e.g.=20 draft-ietf-gsmp-v3-base-spec-06.txt  or =20 draft-ietf-gsmp-v3-base-spec-08.txt):
- The = 16 bit field=20 Function is splitted up into two 8 bit fields named Function = and X-Funtion=20
- The = field=20 "Transmit Data Rate" does not exist
- = action code 8 is=20 not defined
 
 
Shouldn't we=20 describe the changes of the GSMP messages, which we need for ANCP = according to=20 GSMPv3 =20 RFC ?
All = later revisions=20 of the GSMP document are already expired, as far as i = know.
 
 
Best = regard=20
 
Michael Busser
T-Systems=20 Enterprise Services GmbH
Production Line Network Centric Systems
ICT-Systems Integration
Network Integration Services
 
 
-----Urspr=FCngliche Nachricht-----
Von: = smita_selot@agilent.com=20 [mailto:smita_selot@agilent.com]
Gesendet: Donnerstag, 15. = November=20 2007 07:07
An: ancp@ietf.org
Betreff: [ANCP] Query = about=20 ANCP

The field X-Function which = is sent=20 in the Line Configuration Extension block sent by=20 NAS(Refer

To section 5.4.3 in=20 draft-ietf-ancp-protocol-01.txt)=20 is not defined in the

Draft. Where can = this=20 definition be found?

 

Regards,

Smita.

------_=_NextPart_001_01C83734.4BE191D6-- --===============1271513862== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============1271513862==-- From ancp-bounces@ietf.org Wed Dec 05 16:45:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J023V-0006zo-Hi; Wed, 05 Dec 2007 16:45:21 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1J023U-0006zZ-DR for ancp-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 16:45:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J023U-0006zL-00 for ancp@ietf.org; Wed, 05 Dec 2007 16:45:20 -0500 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J023R-00034B-Dh for ancp@ietf.org; Wed, 05 Dec 2007 16:45:19 -0500 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id lB5LhdIQ021117; Wed, 5 Dec 2007 22:43:39 +0100 Received: from [172.17.251.128] ([172.17.251.128]) by FRVELSBHS05.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Wed, 5 Dec 2007 22:45:11 +0100 Message-ID: <47571BE1.9090408@alcatel-lucent.be> Date: Wed, 05 Dec 2007 22:45:05 +0100 From: Stefaan DE CNODDER User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sanjay Wadhwa Subject: Re: Introducing Mutlicast Grey-List (was RE: [ANCP] Commentsondraft-maglione) References: <9BD5D7887235424FA97DFC223CAE3C280BD8E78A@proton.jnpr.net> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280BD8E78A@proton.jnpr.net> Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 05 Dec 2007 21:45:12.0033 (UTC) FILETIME=[1CEB6D10:01C83788] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smail6.alcatel.fr id lB5LhdIQ021117 X-Spam-Score: 0.0 (/) X-Scan-Signature: d1013c8bad83fa4e4ccb34a7376b19d5 Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org I understood that the 3 lists are not checked in a particular order, but=20 that the most specific entry that the join matches with is selected,=20 independent in which list it is. A catch-all entry is always the least=20 specific entry, and therefore always the least prefered entry. In fact,=20 the terms white/black/grey list are not really good because it is more=20 an action that applies to a particular entry that is in one big list:=20 accept, reject or query. With such a catch-all entry, any desired=20 default behavior can be easily achieved, and therefore what the real=20 default behavior is (i.e., when there would be no catch-all entry), is=20 not really that important anymore, as long it is not query. regards, Stefaan Sanjay Wadhwa wrote: > Francois/Maglione > Reviving this discussion, since Francois asked for people's=20 > preference. I would vote for flexibility with network level conditional= =20 > access. If there is no match in white/black/grey lists, then the defaul= t=20 > behaviour on the AN should be configurable, and allow any of the follow= ing: > 1. REJECT on "no match" - i.e. if none of the access control lists=20 > matched, the Join will NOT result in replication > 2. ADMIT on "no match" - i.e. if none of the access control lists=20 > matched, the Join will result in replication > 3. "QUERY NAS" on "no match" - i.e. if none of the access control lists= =20 > matched, the Join will result in query to the NAS. >=20 > The issue I have with "catch-all" in the lists is that it makes the=20 > right behaviour dependent on order of application of these lists e.g. i= f=20 > you want to always query NAS on no-match, you could put a "catch-all" i= n=20 > the grey list. However, this means that the grey list needs to be=20 > applied after white and black lists. On the other end if the desired=20 > behaviour is to reject a join on "no-match", then you could configure a= =20 > "catch-all" in the black list. However, the black list will then need t= o=20 > be applied after the white and grey list. > Maybe the right approach is for AN to have a configurable "default=20 > action" on "no match" in addition to the three lists. If there is no=20 > match in any of the lists (or if there are no lists), the configured=20 > default-action is applied. The default-action could be configured=20 > globally on the AN or configured (or downloaded from NAS to the AN) on=20 > per access-line basis. >=20 > With the default actions defined above, we should be able to accommodat= e=20 > various scenarios with network level conditional access: >=20 > *1. Network level conditional Access completely on NAS* (i.e. all joins= =20 > should result in query to NAS) > No white/black/grey list defined, "no match" default-action=20 > configured as "QUERY-NAS". >=20 > *2. No network level conditional access on AN or NAS (DRM at applicatio= n=20 > level deemed sufficient)* - all joins admitted on AN. > No white/black/grey lists defined, "no match" default-action=20 > configured as "ADMIT" >=20 > *3. Network level conditional access completely on AN (i.e. no join=20 > should ever trigger a query to NAS), and operator wants to reject a joi= n=20 > if it doesn't match any access control lists. > * white list + "no match" default-action configured as "REJECT" >=20 > *4. Network level conditional access completely on AN (i.e. no join=20 > should every trigger a query to NAS), and operator wants to admit a joi= n=20 > if it doesn=92t match any access control list > * black list + "no match" default-action configured as "ADMIT" >=20 > *5. Network level conditional access distributed between AN and NAS on=20 > flow basis, and operator wants to reject a join if it doesn't match any= =20 > access control list* > white list + grey list + "no match default-action configured as=20 > "REJECT" >=20 > *6. Network level conditional access distributed between AN and NAS on=20 > flow basis, and operator wants to admit a join if it doesn't match any=20 > access control list > * black list + grey list + "no match" default-action configured as=20 > "ADMIT" >=20 > *7. Network level conditional access distributed between AN and NAS on=20 > flow basis, and operator wants to query a NAS if it doesn't match any=20 > access control list > * black list + grey list + "no match" default-action configured as=20 > "QUERY NAS" >=20 > Regards >=20 > -Sanjay >=20 > -----Original Message----- > From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com=20 > ] > Sent: Monday, November 26, 2007 4:08 AM > To: Maglione Roberta; OOGHE Sven > Cc: Ullio Mario; ancp@ietf.org; Michel Platnic > Subject: Re: Introducing Mutlicast Grey-List (was RE: [ANCP]=20 > Commentsondraft-maglione) >=20 > Roberta, Sven, and all, >=20 > It is worth noting that Roberta's proposal below allows the behavior=20 > described by Sven with very trivial extra config: > simply add one "catch-all" entry () in the White List. > Then any flow that doesn't match the Black or Grey list will be accepte= d=20 > by AN. >=20 > For example, we could add: >=20 > Scenario 4: > * White-List =3D { } > =3D=3D> any Join message gets accepted by AN >=20 > Scenario 5: > * White-List =3D { } > * Black-List =3D { , , ... } > =3D=3D> Join ( S=3D*,G=3DGi) gets rejected by AN ( 1<=3Di<=3Dn= ) > =3D=3D> everything else gets accepted by AN >=20 >=20 > So the choice is between: >=20 > * "Black-Default": proposal below where: > - Default =3D=3D> everything that doesn't match Black/G= rey=20 > gets blocked > - add a single-entry catch-all in White-List=3D=3D>=20 > everything that doesn't match Black/Grey gets accepted >=20 > * "White-Default": modified proposal where: > - Default =3D=3D> everything that doesn't match Black/G= rey=20 > gets accepted > - add a single-entry catch-all in Black-List=3D=3D>=20 > everything that doesn't match Black/Grey gets blocked >=20 > Both proposals can easily achieve both required behaviors (ie "block if= =20 > doesn't match" _and_ "accept if doesn't match"). The only difference i= s=20 > about whether you need to add the single catch-all entry or not to=20 > achieve your favorite behavior. >=20 > From previous discussion on that topic, it sounded to me like several=20 > folks were more comfortable with the conservative side (ie if there has= =20 > not been a conscious decision to allow a flow, then better block it; i= t=20 > is easy enough to explicitly "allow-all" if operator is so inclined). >=20 > So considering the above ... what do people prefer? > Perhaps we could also poll the WG in Vancouver on that topic. >=20 > Francois >=20 > On 25 Nov 2007, at 22:26, Maglione Roberta wrote: >=20 > > 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 flo= ws > > 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:Sven.Ooghe@alcatel-lucent.be=20 > ] > > Sent: Fri 11/23/2007 5:16 PM > > To: Maglione Roberta; ancp@ietf.org > > Cc: Ullio Mario; Michel Platnic > > Subject: RE: Introducing Mutlicast Grey-List (was RE: [ANCP] Comment= s > > ondraft-maglione) > > > > Hello Roberta, > > > > Thinking a bit further about the default behavior, I am not sure tha= t > > 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:roberta.maglione@telecomitalia.it=20 > ] > > Sent: vrijdag 23 november 2007 8:36 > > To: ancp@ietf.org > > 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 orde= r > > 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 a= re > > 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 a= re > > not allowed to be replicated to that port. A Grey list associated wi= th > > an Access Port identifies the multicast flows for which the AN on > > receiving a Join message, before starting traffic replication querie= s > > 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 wi= ll > > 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 Whi= te > > list, the AN can autonomously start replicating multicast =20 > > 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 wi= ll > > 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: > > =3D=3D> any Join message gets rejected by AN > > > > Scenario 2: > > * White List =3D { , , ... } > > =3D=3D> Join ( S=3D*,G=3DGi) gets honored by AN ( 1<=3Di<=3Dn= ) > > =3D=3D> everything else gets rejected by AN > > > > Scenario 3: > > * White List =3D { , , ... } > > * Grey List =3D { } m>n > > =3D=3D> Join ( S=3D*,G=3DGi) gets honored by AN ( 1<=3Di<=3Dn= ) > > =3D=3D> Join ( S=3Ds,G=3DGm) triggers ANCP Admission Request t= o NAS > > =3D=3D> 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 tu= rn > > performs multicast CAC and responds to the AN indicating wheth= er > > 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 wheth= er > > 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 lis= ts > > and White lists. " > > By > > " The ANCP MUST support providing multicast conditional access > > information to Access Ports on an Access Node, using Black, Gr= ey > > 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 Lis= t > > 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 t= o > > receive a response indicating whether that join is to be honor= ed > > 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 f= or > > 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:Michel.Platnic@ecitele.com=20 > ] > > Sent: Tuesday, July 24, 2007 8:22 PM > > To: Francois Le Faucheur IMAP > > Cc: Garofalo Angelo; ancp@ietf.org > > Subject: RE: [ANCP] Comments on draft-maglione > > > > Hi Francois, > > Please see my comments inline, > > Regards, > > Michel. > > > > > > ________________________________________ > > From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com=20 > ] > > Sent: Mon 7/23/2007 6:23 PM > > To: Michel Platnic > > Cc: Francois Le Faucheur IMAP; OOGHE Sven; ancp@ietf.org; > > angelo.garofalo@telecomitalia.it > > Subject: Re: [ANCP] Comments on draft-maglione Hi 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 f= or > > (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 th= e > > 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 an= y > > Multicast address & Source. Then you can define a White-List with th= e > > 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. ) > > o an exact match for a (S,G) SSM channel (e.g. > > > > > > o a mask-based range match for a (*,G) ASM group (e.g. > > ) > > o a mask-based range match for a (S,G) SSM channel (e.g. > > > > " > > 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 polic= y > > server with requests. > > To my understanding, the model proposed, where the NAS is getting th= e > > 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 polic= y > > 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 o= r > > Scalable. > > > > Let us know if you have specific robustness/scalability concerns > > (beyond > > the one discussed above)? > > Then we could work together on addressing those. > > > > Well, there is still this scalable issue when duplicating > > the > > messages that need to be treated in real-time by the NAS. Sven alrea= dy > > 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 th= e > > message. Should you have any questions, please contact us by > > replying to > > webmaster@telecomitalia.it. > > > > Thank you > > > > www.telecomitalia.it > > > > -------------------------------------------------------------------- > > > > > > > > _______________________________________________ > > ANCP mailing list > > ANCP@ietf.org > > https://www1.ietf.org/mailman/listinfo/ancp=20 > > > > > -------------------------------------------------------------------- > > > > 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 webmaster@telecomitalia.it. > > > > Thank you > > > > www.telecomitalia.it > > > > -------------------------------------------------------------------- > > > > > > > > _______________________________________________ > > ANCP mailing list > > ANCP@ietf.org > > https://www1.ietf.org/mailman/listinfo/ancp=20 > >=20 >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp=20 > >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Dec 05 18:12:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J03Py-0003iQ-6q; Wed, 05 Dec 2007 18:12:38 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1J03Pw-0003i5-HW for ancp-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 18:12:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J03Pw-0003hu-4O for ancp@ietf.org; Wed, 05 Dec 2007 18:12:36 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J03Pt-00043J-CW for ancp@ietf.org; Wed, 05 Dec 2007 18:12:36 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 05 Dec 2007 15:12:33 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB5NCWXl031144; Wed, 5 Dec 2007 15:12:32 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lB5NCS1f005199; Wed, 5 Dec 2007 23:12:28 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 15:12:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Introducing Mutlicast Grey-List (was RE:[ANCP] Commentsondraft-maglione) Date: Wed, 5 Dec 2007 15:12:32 -0800 Message-ID: <48214755113BB04F84D958B4F0DE261C04C4F8D0@xmb-sjc-222.amer.cisco.com> In-Reply-To: <47571BE1.9090408@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Introducing Mutlicast Grey-List (was RE:[ANCP] Commentsondraft-maglione) Thread-Index: Acg3iCgbocD46RldR2WZopLIXhvBrAACs5VA References: <9BD5D7887235424FA97DFC223CAE3C280BD8E78A@proton.jnpr.net> <47571BE1.9090408@alcatel-lucent.be> From: "Philippe Champagne (pchamp)" To: "Stefaan DE CNODDER" , "Sanjay Wadhwa" X-OriginalArrivalTime: 05 Dec 2007 23:12:27.0451 (UTC) FILETIME=[4D78D0B0:01C83794] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=26843; t=1196896352; x=1197760352; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pchamp@cisco.com; z=From:=20=22Philippe=20Champagne=20(pchamp)=22=20 |Subject:=20RE=3A=20Introducing=20Mutlicast=20Grey-List=20(was=20RE=3A[AN CP]=09Commentsondraft-maglione) |Sender:=20; bh=45cKF72cZJqMD32N7HE/I7skS4H7hWUa/qAGUXI+PF0=; b=0j33NQT+QzUpfpDxAo86APNoxAY1qK9iqtLwKhxqzUT57jI0hnjQJi9hmtXxQtfp2uBoUlPr 2d1uiSPfDXSl2EWFGG8icMJLfnzPRETLJHb4z9A4ZtNXoPGvvD4iFobj; Authentication-Results: sj-dkim-2; header.From=pchamp@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e05124dbe0e171b371ff9d88326a1ab7 Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org 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 =3D=3D S3 then G2 must be !=3D G3 You can't have Sn = =3D=3D Sm && Gn =3D=3D 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=20 white:accept,=20 grey:query,=20 black:deny So introducing the action keyword but leaving the terms white/grey/black -Phil =20 -----Original Message----- From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: Wednesday, December 05, 2007 4:45 PM To: Sanjay Wadhwa Cc: ancp@ietf.org Subject: Re: Introducing Mutlicast Grey-List (was RE:[ANCP]=20 Commentsondraft-maglione) I understood that the 3 lists are not checked in a particular=20 order, but that the most specific entry that the join matches=20 with is selected, independent in which list it is. A catch-all=20 entry is always the least specific entry, and therefore always=20 the least prefered entry. In fact, the terms white/black/grey=20 list are not really good because it is more an action that=20 applies to a particular entry that is in one big list:=20 accept, reject or query. With such a catch-all entry, any=20 desired default behavior can be easily achieved, and therefore=20 what the real default behavior is (i.e., when there would be no=20 catch-all entry), is not really that important anymore, as long=20 it is not query. regards, Stefaan Sanjay Wadhwa wrote: > Francois/Maglione > Reviving this discussion, since Francois asked for people's=20 > preference. I would vote for flexibility with network level=20 > conditional access. If there is no match in white/black/grey lists,=20 > then the default behaviour on the AN should be configurable,=20 and allow any of the following: > 1. REJECT on "no match" - i.e. if none of the access control lists=20 > matched, the Join will NOT result in replication 2. ADMIT on "no=20 > match" - i.e. if none of the access control lists matched, the Join=20 > will result in replication 3. "QUERY NAS" on "no match" -=20 i.e. if none=20 > of the access control lists matched, the Join will result in query to=20 > the NAS. >=20 > The issue I have with "catch-all" in the lists is that it makes the=20 > right behaviour dependent on order of application of these lists e.g.=20 > if you want to always query NAS on no-match, you could put a=20 > "catch-all" in the grey list. However, this means that the grey list=20 > needs to be applied after white and black lists. On the other end if=20 > the desired behaviour is to reject a join on "no-match", then you=20 > could configure a "catch-all" in the black list. However, the black=20 > 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=20 > action" on "no match" in addition to the three lists. If there is no=20 > match in any of the lists (or if there are no lists), the configured=20 > default-action is applied. The default-action could be configured=20 > globally on the AN or configured (or downloaded from NAS to=20 the AN) on=20 > per access-line basis. >=20 > With the default actions defined above, we should be able to=20 > accommodate various scenarios with network level conditional access: >=20 > *1. Network level conditional Access completely on NAS* (i.e. all=20 > joins should result in query to NAS) > No white/black/grey list defined, "no match" default-action=20 > configured as "QUERY-NAS". >=20 > *2. No network level conditional access on AN or NAS (DRM at=20 > application level deemed sufficient)* - all joins admitted on AN. > No white/black/grey lists defined, "no match" default-action=20 > configured as "ADMIT" >=20 > *3. Network level conditional access completely on AN (i.e. no join=20 > should ever trigger a query to NAS), and operator wants to reject a=20 > join if it doesn't match any access control lists. > * white list + "no match" default-action configured as "REJECT" >=20 > *4. Network level conditional access completely on AN (i.e. no join=20 > should every trigger a query to NAS), and operator wants to admit a=20 > join if it doesn't match any access control list > * black list + "no match" default-action configured as "ADMIT" >=20 > *5. Network level conditional access distributed between AN=20 and NAS on=20 > flow basis, and operator wants to reject a join if it doesn't match=20 > any access control list* > white list + grey list + "no match default-action=20 configured as=20 > "REJECT" >=20 > *6. Network level conditional access distributed between AN=20 and NAS on=20 > flow basis, and operator wants to admit a join if it doesn't=20 match any=20 > access control list > * black list + grey list + "no match" default-action=20 configured as=20 > "ADMIT" >=20 > *7. Network level conditional access distributed between AN=20 and NAS on=20 > flow basis, and operator wants to query a NAS if it doesn't match any=20 > access control list > * black list + grey list + "no match" default-action=20 configured as=20 > "QUERY NAS" >=20 > Regards >=20 > -Sanjay >=20 > -----Original Message----- > From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com=20 > ] > Sent: Monday, November 26, 2007 4:08 AM > To: Maglione Roberta; OOGHE Sven > Cc: Ullio Mario; ancp@ietf.org; Michel Platnic > Subject: Re: Introducing Mutlicast Grey-List (was RE: [ANCP] > Commentsondraft-maglione) >=20 > Roberta, Sven, and all, >=20 > It is worth noting that Roberta's proposal below allows the behavior=20 > described by Sven with very trivial extra config: > simply add one "catch-all" entry () in the White List. > Then any flow that doesn't match the Black or Grey list will be=20 > accepted by AN. >=20 > For example, we could add: >=20 > Scenario 4: > * White-List =3D { } > =3D=3D> any Join message gets accepted by AN >=20 > Scenario 5: > * White-List =3D { } > * Black-List =3D { , , ... = } > =3D=3D> Join ( S=3D*,G=3DGi) gets rejected by AN ( = 1<=3Di<=3Dn ) > =3D=3D> everything else gets accepted by AN >=20 >=20 > So the choice is between: >=20 > * "Black-Default": proposal below where: > - Default =3D=3D> everything that doesn't match=20 Black/Grey=20 > gets blocked > - add a single-entry catch-all in White-List=3D=3D>=20 > everything that doesn't match Black/Grey gets accepted >=20 > * "White-Default": modified proposal where: > - Default =3D=3D> everything that doesn't match=20 Black/Grey=20 > gets accepted > - add a single-entry catch-all in Black-List=3D=3D>=20 > everything that doesn't match Black/Grey gets blocked >=20 > Both proposals can easily achieve both required behaviors (ie "block=20 > if doesn't match" _and_ "accept if doesn't match"). The only=20 > difference is about whether you need to add the single=20 catch-all entry=20 > or not to achieve your favorite behavior. >=20 > From previous discussion on that topic, it sounded to me=20 like several=20 > folks were more comfortable with the conservative side (ie if there=20 > has not been a conscious decision to allow a flow, then better block=20 > it; it is easy enough to explicitly "allow-all" if operator=20 is so inclined). >=20 > So considering the above ... what do people prefer? > Perhaps we could also poll the WG in Vancouver on that topic. >=20 > Francois >=20 > On 25 Nov 2007, at 22:26, Maglione Roberta wrote: >=20 > > Hi Sven, > > thanks for your comments; > > your point makes sense to me, "accept as best effort" is a=20 valid >=20 > option for default behavior. > > The basic idea for the default action is to avoid query=20 the NAS for =20 > > all multicast flows that do not match any list: the reason why we =20 > > selected drop as the default behavior for unconfigured multicast=20 > flows > is in order to be consistent with the typical ACL behavior,=20 > and also > because this seemed to be the preferred action according=20 > to the > discussion we had in Chicago and on the mailing list, but I=20 > open to > modify the default behavior, according to Working=20 group feedback. > > > > Regards, > > Roberta > > > > > > -----Original Message----- > > From: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be > ] > Sent: Fri 11/23/2007 5:16=20 > PM > To: Maglione Roberta; ancp@ietf.org > Cc: Ullio Mario; Michel=20 > Platnic > Subject: RE: Introducing Mutlicast Grey-List (was RE:=20 > [ANCP] Comments > ondraft-maglione) > > Hello Roberta, > >=20 > Thinking a bit further about the default behavior, I am not=20 sure that =20 > > dropping would be the right approach. (cf. "If a Join message is >=20 > received by AN for a flow which is not on any list, then it is >=20 > rejected") > > Imagine any multicast flow out there on the Internet=20 > (e.g. Internet > TV), then if it is not configured on the Access=20 > Node, it will be > rejected. I don't think this is what an end-user=20 > would want. > > > > Instead, I would argue that if the flow is not part of any of the =20 > > 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:roberta.maglione@telecomitalia.it > ] > Sent: vrijdag 23=20 > november 2007 8:36 > To: ancp@ietf.org > Cc: Ullio Mario; Michel=20 > Platnic > Subject: Introducing Mutlicast Grey-List (was RE: [ANCP]=20 > Comments > ondraft-maglione) > > Hello, > > as we discussed during Chicago meeting below is a=20 proposal for > > modification to the text of draft-ietf-ancp-framework-04.txt in=20 > order > to introduce Multicast Grey List and leave Black List (i.e.=20 > deny) as > default behavior. > > We'd appreciate feedback. > > > > Regards, > > Roberta > > > > > > Section 3.4.1 > > Replace: > > " Provisioning the conditional access information on the=20 AN can be =20 > > done using a "White list" and/or a "Black list". > > A White list associated with an Access Port identifies the=20 > multicast > flows that are allowed to be replicated to that port. A=20 > Black list > associated with an Access Port identifies the multicast=20 > flows that are > not allowed to be replicated to that port." > > > > By: > > " Provisioning the conditional access information on the=20 AN can be =20 > > done using a "White list", "Grey list", and/or a "Black=20 list". A >=20 > White list associated with an Access Port identifies the multicast >=20 > flows that are allowed to be replicated to that port. A=20 Black list >=20 > associated with an Access Port identifies the multicast flows=20 that are =20 > > not allowed to be replicated to that port. A Grey list associated=20 > with > an Access Port identifies the multicast flows for=20 which the AN=20 > on > receiving a Join message, before starting traffic replication=20 > queries > NAS for further authorization. > > Each list contains zero, one or multiple entries and each=20 entry may =20 > > specify a single flow or contain ranges (i.e. mask on Group=20 address =20 > > and/or mask on Source address). > > > > > > Replace: > > "Upon receiving a join message on an Access Port, the Access Node=20 > will > first check if the requested multicast flow is part=20 of a White=20 > list > or a > Black list associated with that Access Port. =20 If it is=20 > part of a White > list, the AN can autonomously start replicating=20 > multicast > traffic. If > it is part of a Black list, the AN can=20 > autonomously discard the > message > because the request is not=20 > authorized" > > > > By: > > > > "Upon receiving a join message on an Access Port, the Access Node=20 > will > first check if the requested multicast flow is part of a=20 > White, > Grey or > a Black list associated with that Access Port. =20 > If it is part of a > White > list, the AN can autonomously start=20 > replicating multicast traffic. If > it is part of a Black list, the=20 > AN can autonomously discard the > message > because the request is=20 > not authorized. If it is part of a Grey list > the > AN=20 uses ANCP to=20 > query the NAS, that in turn will respond to the AN > indicating=20 > whether the join is to be honored (and hence replication > performed=20 > by the AN) or denied (and hence replication not performed by > the=20 > AN.) If a Join message is received by AN for a flow which is =20 > not on =20 > > any list, then it is rejected (i.e. the default behavior is=20 to drop =20 > > such > messages.) If a join is received by AN for a flow that=20 > matches > multiple > lists, then a deterministic algorithm (to be=20 > specified in ancp- > protocol) > is used by the AN to decide which=20 > list behavior takes precedence. > > Following are some example scenarios: > > > > Scenario 1: > > * no config: > > =3D=3D> any Join message gets rejected by AN > > > > Scenario 2: > > * White List =3D { , , ... = } > > =3D=3D> Join ( S=3D*,G=3DGi) gets honored by AN ( = 1<=3Di<=3Dn ) > > =3D=3D> everything else gets rejected by AN > > > > Scenario 3: > > * White List =3D { , , ... = } > > * Grey List =3D { } m>n > > =3D=3D> Join ( S=3D*,G=3DGi) gets honored by AN ( = 1<=3Di<=3Dn ) > > =3D=3D> Join ( S=3Ds,G=3DGm) triggers ANCP Admission Request = to NAS > > =3D=3D> 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=20 by the NAS. > > In this case, the AN can use ANCP to query the NAS,=20 that in turn > > performs multicast CAC and responds to the AN=20 indicating whether > > the join is to be honored (and hence replication performed by > > the > > AN) or denied. In the process, the NAS may=20 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=20 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=20 > in > turn > > performs multicast CAC and responds to the AN=20 indicating whether > > the join is to be honored (and hence replication performed by > > the > > AN) or denied. In the process, the NAS may=20 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=20 Black lists > > and White lists. " > > By > > " The ANCP MUST support providing multicast conditional access > > information to Access Ports on an Access Node, using=20 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=20 > List > the ANCP MUST allow the AN to query the NAS to request an=20 > admission > decision for replicating that multicast flow to a=20 > particular Access > Port. > > > > > > > > Section 4.7.6 > > Replace and split in two > > > > " Upon receiving a join to a multicast flow which does not=20 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=20 the NAS to > > receive a response indicating whether that join is=20 to be honored > > or denied." > > > > By: > > > > " Upon receiving a join to a multicast flow which matches=20 the Grey =20 > > List > for a specific Access Port, the AN must support using ANCP=20 > to > query the > NAS to receive a response indicating whether that=20 > join is to be > honored > or denied. > > " > > " The AN must deny any join to a multicast flow that does=20 not match =20 > > any > > entry in the Black List nor in the White List nor=20 Grey List for > > the relevant Access Port" > > > > > > Adding the following requirements: > > > > "Upon receiving a join to a multicast flow which matches the Grey =20 > > List, > AN is not allowed to propagate that join request, before=20 > the > successful > authorization from the NAS is received." > > > > "Upon receiving a leave to a multicast flow which matches=20 the Grey =20 > > List, > AN SHOULD be able to autonomously stop replication and=20 > SHOULD be > able to > advertise this event to the NAS." > > > > > > Section 4.8.6 > > Adding: > > The NAS MUST support using ANCP to incrementally add,=20 remove and >=20 > modify > individual entries in White, Black and Grey lists. > > > > > > ------------------------------------------------------- > > Roberta Maglione - CCIE #18425 > > Telecom Italia > > Broadband Network Services Innovation >=20 > ------------------------------------------------------- > > ________________________________________ > > From: Michel Platnic [mailto:Michel.Platnic@ecitele.com > ] > > Sent: Tuesday, July 24, 2007 8:22 PM > To: Francois Le Faucheur=20 > IMAP > Cc: Garofalo Angelo; ancp@ietf.org > Subject: RE: [ANCP]=20 > Comments on draft-maglione > > Hi Francois, > Please see my=20 > comments inline, > Regards, > Michel. > > > > > > ________________________________________ > > From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com=20 > ] > Sent: Mon 7/23/2007 6:23 PM > To:=20 > Michel Platnic > Cc: Francois Le Faucheur IMAP; OOGHE Sven;=20 > ancp@ietf.org; > angelo.garofalo@telecomitalia.it > Subject: Re:=20 > [ANCP] Comments on draft-maglione Hi Michel, > > > > =20 > Using access control capabilities within the access network >=20 > provides the two main following benefits: > > - refrain from sending any content to a customer that was not paid=20 > for > (mostly relevant when Encryption is not used) > - provides a=20 > filter against end-user applications/hackers that may > send > IGMP=20 > requests with invalid IP address > > A solution where all the IP=20 > addresses that are not part of either the > Black-list or the=20 > White-List are sent to a central policy server for > authorization=20 > gives me some concerns regarding the robustness of the > whole=20 > system. Same concern regarding the treatment of unknown IP > source =20 > > addresses ('Everything else'). > > > > Agreed. We had these concerns in mind also. This is why=20 the Black- =20 > > Lists > and White-Lists include the ability to define arbitrarily=20 > large > ranges/masks. In particular, as an example, one can easily=20 > define a > Black-List which contains a single "catch-all" entry that=20 > matches any > Multicast address & Source. Then you can define a=20 > White-List with the > explicit channels you want to allow. This=20 > effectively implements a > policy whereby everything is blocked by=20 > AN, except the channels that > have been explicitly allowed in the=20 > White-List. > > In other words, the Black-List can be used for explicit=20 listing of =20 > > channels, or it can easily be used as a "catch-all" (for=20 all, or for =20 > > 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 >=20 > 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. ) > > o an exact match for a (S,G) SSM channel (e.g. > > > > > > o a mask-based range match for a (*,G) ASM group (e.g. > > ) > > o a mask-based range match for a (S,G) SSM channel (e.g. > > > > " > > Let me try to rephrase your proposal; there=20 would be a >=20 > default > state wherein any channel being neither part of White-list=20 > nor > Black-list would be discarded. > > If its the case I agree with you that this solution solves the >=20 > security > issue. > > > > But what about when AN is not in this default state? > > If "Accept everything else" is used then again same problem of >=20 > security > is encountered, and any hacker or application can=20 overload=20 > the policy > server with requests. > > To my understanding, the model proposed, where the NAS is getting=20 > the > customer request for authorization, requires this mode=20 of operation. > > So we still have the same problem. > > Did I miss anything? > > > > > >=20 > ______________________________________________________________________ > > __ > > ______ > > I understand that some applications may require sophisticated=20 > policy > decision making and that, as a matter of fact, some=20 > AN/central policy > server synchronization mechanism should to be=20 > proposed, but the > solution > must be Robust and Scalable. > > For now I am not convinced that solution proposed is either Robust=20 > or > Scalable. > > > > Let us know if you have specific robustness/scalability=20 concerns >=20 > (beyond > the one discussed above)? > > Then we could work together on addressing those. > > > > Well, there is still this scalable issue when=20 duplicating =20 > > the > messages that need to be treated in real-time by the NAS.=20 > Sven already > made some counting regarding this topic. I believe=20 > this point could > lead > to scalability issues. If we had=20 the above=20 > described potential > disaster, > then we end-up getting serious=20 > Robustness issues. > > > > > > Thanks > > > > Francois > > > > > > Regards, > > Michel. > >=20 > -------------------------------------------------------------------- > > > > CONFIDENTIALITY NOTICE > > > > This message and its attachments are addressed solely to the=20 > persons > above and may contain confidential information. If=20 you have =20 > > received the > message in error, be informed that any use of the=20 > content hereof is > prohibited. Please return it immediately to the=20 > sender and delete the > message. Should you have any questions,=20 > please contact us by > replying to > webmaster@telecomitalia.it. > > > > Thank you > > > > www.telecomitalia.it > > > >=20 > -------------------------------------------------------------------- > > > > > > > > _______________________________________________ > > ANCP mailing list > > ANCP@ietf.org > > https://www1.ietf.org/mailman/listinfo/ancp > > > > >=20 > -------------------------------------------------------------------- > > > > CONFIDENTIALITY NOTICE > > > > This message and its attachments are addressed solely to the >=20 > persons above and may contain confidential information. If=20 you have >=20 > received the message in error, be informed that any use of the >=20 > content hereof is prohibited. Please return it immediately to the >=20 > sender and delete the message. Should you have any questions, >=20 > please contact us by replying to webmaster@telecomitalia.it. > > > > Thank you > > > > www.telecomitalia.it > > > >=20 > -------------------------------------------------------------------- > > > > > > > > _______________________________________________ > > ANCP mailing list > > ANCP@ietf.org > > https://www1.ietf.org/mailman/listinfo/ancp > >=20 >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp > >=20 >=20 >=20 > ---------------------------------------------------------------------- > -- >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Dec 06 07:56:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0GHA-0001sL-S5; Thu, 06 Dec 2007 07:56:24 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1J0GH9-0001sC-AR for ancp-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 07:56:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0GH8-0001rz-Ne for ancp@ietf.org; Thu, 06 Dec 2007 07:56:22 -0500 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0GH5-0002UG-KY for ancp@ietf.org; Thu, 06 Dec 2007 07:56:22 -0500 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id lB6CdrK6028447; Thu, 6 Dec 2007 13:39:53 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 6 Dec 2007 13:41:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Introducing Mutlicast Grey-List (was RE: [ANCP]Commentsondraft-maglione) Date: Thu, 6 Dec 2007 13:41:25 +0100 Message-ID: <8144761F31F48D43AD53D09F5350E3800222A3F9@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Introducing Mutlicast Grey-List (was RE: [ANCP]Commentsondraft-maglione) Thread-Index: AcgwC/JfPZ6MmvR4TYies2mWcWFJCQA7HGrQAUEyS8AAAUbaQACAg5AQ References: <8C253CB7-CF45-431D-94B6-4AC1A1653524@cisco.com><9E577E61D0108D4F8CD482029B613F5C0181BF87@PTPEVS108BA020.idc.cww.telecomitalia.it><8144761F31F48D43AD53D09F5350E38002069337@FRVELSMBS22.ad2.ad.alcatel.com><9E577E61D0108D4F8CD482029B613F5C01A7CF5F@PTPEVS108BA020.idc.cww.telecomitalia.it><8144761F31F48D43AD53D09F5350E380020DEE4E@FRVELSMBS22.ad2.ad.alcatel.com> From: "OOGHE Sven" To: "Wojciech Dec (wdec)" , "Francois Le Faucheur (flefauch)" , "Maglione Roberta" , X-OriginalArrivalTime: 06 Dec 2007 12:41:26.0628 (UTC) FILETIME=[51137240:01C83805] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: fe6e20eef2d8927c50910823cd0d1c84 Cc: Ullio Mario , Michel Platnic X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org 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=20 -----Original Message----- From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: dinsdag 4 december 2007 0:17 To: Wojciech Dec (wdec); OOGHE Sven; Francois Le Faucheur (flefauch); Maglione Roberta Cc: Michel Platnic; ancp@ietf.org; Ullio Mario Subject: RE: Introducing Mutlicast Grey-List (was RE: [ANCP]Commentsondraft-maglione) ooops, typo, corrected inline > -----Original Message----- > From: Wojciech Dec (wdec) > Sent: 03 December 2007 14:44 > To: OOGHE Sven; Francois Le Faucheur (flefauch); Maglione Roberta > Cc: Michel Platnic; ancp@ietf.org; Ullio Mario > Subject: RE: Introducing Mutlicast Grey-List (was RE:=20 > [ANCP]Commentsondraft-maglione) >=20 > Hi Sven, >=20 > catching up on this thread: It seems that to accommodate the "best=20 > effort" proposal below, the AN would need to have some sort of=20 > mechanism that tells it which channel is best effort and which one=20 > 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=20 > keeping this sort of addition FROM BEING ADDED to ANCP would be=20 > advisable. ^^^^^^^^^^^^^^^^ >=20 > Regards, > Woj. >=20 > > -----Original Message----- > > From: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be] > > Sent: 27 November 2007 14:29 > > To: Francois Le Faucheur (flefauch); Maglione Roberta > > Cc: Ullio Mario; ancp@ietf.org; Michel Platnic > > Subject: RE: Introducing Mutlicast Grey-List (was RE: [ANCP] > > Commentsondraft-maglione) > >=20 > > Francois, > >=20 > > I agree that a catch-all statement can be used to create either=20 > > "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=20 > > suffer. > >=20 > > 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=20 > > 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=20 > > content. > >=20 > > Comments? > >=20 > > Regards, > > Sven > >=20 > > -----Original Message----- > > From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] > > Sent: maandag 26 november 2007 10:08 > > To: Maglione Roberta; OOGHE Sven > > Cc: Francois Le Faucheur IMAP; ancp@ietf.org; Michel Platnic; Ullio=20 > > Mario > > Subject: Re: Introducing Mutlicast Grey-List (was RE:=20 > [ANCP] Comments > > ondraft-maglione) > >=20 > > Roberta, Sven, and all, > >=20 > > 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 () in the White List. > > Then any flow that doesn't match the Black or Grey list will be=20 > > accepted by AN. > >=20 > > For example, we could add: > >=20 > > Scenario 4: > > * White-List =3D { } > > =3D=3D> any Join message gets accepted by AN > >=20 > > Scenario 5: > > * White-List =3D { } > > * Black-List =3D { , , ... = } > > =3D=3D> Join ( S=3D*,G=3DGi) gets rejected by AN ( 1<=3Di<=3Dn ) > > =3D=3D> everything else gets accepted by AN > >=20 > >=20 > > So the choice is between: > >=20 > > * "Black-Default": proposal below where: > > - Default =3D=3D> everything that doesn't match > Black/Grey gets blocked > > - add a single-entry catch-all in White-List=3D=3D> > everything that > > doesn't match Black/Grey gets accepted > >=20 > > * "White-Default": modified proposal where: > > - Default =3D=3D> everything that doesn't match > Black/Grey gets accepted > > - add a single-entry catch-all in Black-List=3D=3D> > everything that > > doesn't match Black/Grey gets blocked > >=20 > > 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=20 > > catch-all entry or not to achieve your favorite behavior. > >=20 > > From previous discussion on that topic, it sounded to me > like several > > folks were more comfortable with the conservative side (ie if there=20 > > 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=20 > > inclined). > >=20 > > So considering the above ... what do people prefer? > > Perhaps we could also poll the WG in Vancouver on that topic. > >=20 > > Francois > >=20 > > On 25 Nov 2007, at 22:26, Maglione Roberta wrote: > >=20 > > > Hi Sven, > > > thanks for your comments; > > > your point makes sense to me, "accept as best effort" is a valid=20 > > > 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 > >=20 > > > is in order to be consistent with the typical ACL behavior, > > and also > > > because this seemed to be the preferred action according to the=20 > > > 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:Sven.Ooghe@alcatel-lucent.be] > > > Sent: Fri 11/23/2007 5:16 PM > > > To: Maglione Roberta; ancp@ietf.org > > > Cc: Ullio Mario; Michel Platnic > > > Subject: RE: Introducing Mutlicast Grey-List (was RE:=20 > > [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=20 > > > 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=20 > > > 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=20 > > > 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:roberta.maglione@telecomitalia.it] > > > Sent: vrijdag 23 november 2007 8:36 > > > To: ancp@ietf.org > > > 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=20 > > > modification to the text of > > draft-ietf-ancp-framework-04.txt in order > > > to introduce Multicast Grey List and leave Black List (i.e.=20 > > 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 > >=20 > > > 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=20 > > > 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 > >=20 > > > not allowed to be replicated to that port. A Grey list > > associated with > >=20 > > > an Access Port identifies the multicast flows for which the AN on=20 > > > 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 =20 > > > traffic. If > > > it is part of a Black list, the AN can autonomously discard the=20 > > > 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=20 > > > traffic. If it is part of a Black list, the AN can autonomously=20 > > > 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=20 > > > 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=20 > > > 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: > > > =3D=3D> any Join message gets rejected by AN > > > > > > Scenario 2: > > > * White List =3D { , , ... = } > > > =3D=3D> Join ( S=3D*,G=3DGi) gets honored by AN ( 1<=3Di<=3Dn ) > > > =3D=3D> everything else gets rejected by AN > > > > > > Scenario 3: > > > * White List =3D { , , ... = } > > > * Grey List =3D { } m>n > > > =3D=3D> Join ( S=3D*,G=3DGi) gets honored by AN ( 1<=3Di<=3Dn ) > > > =3D=3D> Join ( S=3Ds,G=3DGm) triggers ANCP Admission Request to = NAS > > > =3D=3D> 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=20 > > > 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=20 > > > modify individual entries in White, Black and Grey lists. > > > > > > > > > ------------------------------------------------------- > > > Roberta Maglione - CCIE #18425 > > > Telecom Italia > > > Broadband Network Services Innovation > > > ------------------------------------------------------- > > > ________________________________________ > > > From: Michel Platnic [mailto:Michel.Platnic@ecitele.com] > > > Sent: Tuesday, July 24, 2007 8:22 PM > > > To: Francois Le Faucheur IMAP > > > Cc: Garofalo Angelo; ancp@ietf.org > > > Subject: RE: [ANCP] Comments on draft-maglione > > > > > > Hi Francois, > > > Please see my comments inline, > > > Regards, > > > Michel. > > > > > > > > > ________________________________________ > > > From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] > > > Sent: Mon 7/23/2007 6:23 PM > > > To: Michel Platnic > > > Cc: Francois Le Faucheur IMAP; OOGHE Sven; ancp@ietf.org;=20 > > > angelo.garofalo@telecomitalia.it > > > Subject: Re: [ANCP] Comments on draft-maglione Hi 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=20 > > > 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=20 > > > 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. ) > > > o an exact match for a (S,G) SSM channel (e.g. =20 > > > > > > > > > o a mask-based range match for a (*,G) ASM group (e.g. > > > ) > > > o a mask-based range match for a (S,G) SSM channel (e.g. > > > " > > > Let me try to rephrase your proposal; there would be a=20 > > > 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=20 > > > security issue. > > > > > > But what about when AN is not in this default state? > > > If "Accept everything else" is used then again same problem of=20 > > > 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? > > > > > > > > >=20 > >=20 > ______________________________________________________________________ > >=20 > > > __ > > > ______ > > > 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=20 > > > 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=20 > > > (beyond the one discussed above)? > > > Then we could work together on addressing those. > > > > > > 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=20 > > > potential disaster, then we end-up getting serious > > Robustness issues. > > > > > > > > > Thanks > > > > > > Francois > > > > > > > > > Regards, > > > Michel. > > >=20 > -------------------------------------------------------------------- > > > > > > 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=20 > > > replying to webmaster@telecomitalia.it. > > > > > > Thank you > > > > > > www.telecomitalia.it > > > > > >=20 > -------------------------------------------------------------------- > > > > > > > > > > > > _______________________________________________ > > > ANCP mailing list > > > ANCP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ancp > > > > > >=20 > -------------------------------------------------------------------- > > > > > > 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=20 > > > replying to webmaster@telecomitalia.it. > > > > > > Thank you > > > > > > www.telecomitalia.it > > > > > >=20 > -------------------------------------------------------------------- > > > > > > > > > > > > _______________________________________________ > > > ANCP mailing list > > > ANCP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ancp > >=20 > >=20 > > _______________________________________________ > > ANCP mailing list > > ANCP@ietf.org > > https://www1.ietf.org/mailman/listinfo/ancp > >=20 >=20 >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp >=20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Dec 18 00:58:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4VSy-00077j-K6; Tue, 18 Dec 2007 00:58:08 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1J4VSx-000717-Gj for ancp-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 00:58:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4VSx-0006wn-36 for ancp@ietf.org; Tue, 18 Dec 2007 00:58:07 -0500 Received: from aglsgpbs05.sgp.agilent.com ([192.25.82.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4VSw-0004gl-2X for ancp@ietf.org; Tue, 18 Dec 2007 00:58:06 -0500 Received: from sgp-sg-bh01.sgp.agilent.com (sgp-sg-bh01.sgp.agilent.com [141.183.6.35]) by aglsgpbs05.sgp.agilent.com (Postfix) with ESMTP id 7CC957412B for ; Tue, 18 Dec 2007 05:58:04 +0000 (GMT) Received: from sgp-sg-mb02.sgp.agilent.com ([141.183.6.33]) by sgp-sg-bh01.sgp.agilent.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Dec 2007 13:58:04 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Dec 2007 13:58:04 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification about the Label field in Topology Discovery message Thread-Index: AchBOvRhDzYdKk/5QSmttiIUDKjooQ== From: To: X-OriginalArrivalTime: 18 Dec 2007 05:58:04.0588 (UTC) FILETIME=[F47E36C0:01C8413A] X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Subject: [ANCP] Clarification about the Label field in Topology Discovery message X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2072058239==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============2072058239== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8413A.F44C96F1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8413A.F44C96F1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, While going through the Topology Discovery Message format in the draft version 02, I had the following question. 1. The draft says that the label field should be set to zero. a. However the length of the label field is variable according to RFC = 3292(GSMP v3). b. Since the label type(Sec 3.1.3, RFC 3292) is set to zero, there = will be no way to identify the label type and hence its length. 2. Since the minimum length of the label field(according to RFC3292) = is 8 bytes(64 bits). This includes the bits |x|S|x|x|. Therefore we can set the length of the = Label field to 8 bytes(64 bits) and the value is set to 0. =20 Regards, Nagendra =20 =20 ------_=_NextPart_001_01C8413A.F44C96F1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

While going through the Topology Discovery = Message format

in the draft version 02, I had the following = question.

1.    The = draft says that the label field should be set to zero.

a.    However = the length of the label field is variable according to RFC 3292(GSMP = v3).

b.    Since = the label type(Sec 3.1.3, RFC 3292) is set to zero, there will be no = way

to identify the label type and = hence its length.

2.    Since = the minimum length of the label field(according to RFC3292) is 8 bytes(64 = bits).

This includes the bits = |x|S|x|x|. Therefore we can set the length of the Label field = to

8 bytes(64 bits) and the value is = set to 0.

 

Regards,

Nagendra

 

 

------_=_NextPart_001_01C8413A.F44C96F1-- --===============2072058239== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============2072058239==--