From ancp-bounces@ietf.org Mon Sep 03 08:41: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 1ISBEr-0008VK-0s; Mon, 03 Sep 2007 08:41:09 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1ISBEo-0008VE-J6 for ancp-confirm+ok@megatron.ietf.org; Mon, 03 Sep 2007 08:41:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISBEk-0008V3-Pb for ancp@ietf.org; Mon, 03 Sep 2007 08:41:02 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISBEi-0003RA-UH for ancp@ietf.org; Mon, 03 Sep 2007 08:41:02 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-1.cisco.com with ESMTP; 03 Sep 2007 05:41:00 -0700 X-IronPort-AV: i="4.20,201,1186383600"; d="scan'208"; a="16202500:sNHT23359998" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l83Cexbr002259 for ; Mon, 3 Sep 2007 08:40:59 -0400 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l83CeD6K015983 for ; Mon, 3 Sep 2007 12:40:59 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 Sep 2007 14:40:50 +0200 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 Date: Mon, 3 Sep 2007 14:38:41 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANCP WG follow-up Thread-Index: Acfsnl4SvSbv5OpeRkO1b6AIPY3/2ABhuzwg From: "Wojciech Dec \(wdec\)" To: X-OriginalArrivalTime: 03 Sep 2007 12:40:50.0832 (UTC) FILETIME=[A8E8E900:01C7EE27] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1595; t=1188823259; x=1189687259; c=relaxed/simple; s=rtpdkim2001; 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:=20ANCP=20WG=20follow-up |Sender:=20 |To:=20; bh=noP2eXyO7ZUDnIaXqqcFQlP+/OPG3oVCLc6sDLSiE44=; b=AvAoaqetHtjB9DZgkRUMoVFXoW8YGu33CcNvwh5sM4GHzJQgopDuQk50WmPu//bbJppNB0j2 6qM2zP9laPVEjqhOkj8cdgz14bA1kPG1Al37my01wWO5Wqal7jYyIMS+; Authentication-Results: rtp-dkim-2; header.From=wdec@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [ANCP] ANCP WG follow-up 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 All, At the recent IETF meeting we've heard a fair amount of debate regarding the subject of multicast. The debate spanned multiple camps and went over both the whys, the why not's, as well as pros and cons. The general consensus formed at the meeting was that the framework and requirements document needs to cover all use cases to the same level of depth, and to have sufficient detail to design the protocol. This in effect means the definition of the message primitives for supporting the use-case(s).=20 We also heard there being significantly more support than not for introducing into the protocol the flexibility offered by the request-response message set as proposed in draft-maglione, along with the use-cases. Hence, we would like to confirm the following direction with the working group for carrying out the following two points: 1. Introduce into the latest draft-ietf-ancp-framework changes and text that covers the following: - High level message diagram including query/response primitives - Description of the following multicast-use cases;=20 * Multicast Conditional Access * Multicast Admission Control * Multicast Accounting * Multicast Termination Some solidification of the final text will be required and ought to take place on the alias. For the above however draft-maglione appears to contain a fair base of the material required. 2. The WG commences work on defining the necessary protocol extensions for inclusion in draft-ietf-ancp-protocol, based on the protocol specific text in draft-maglione. Regards, Woj and Matthew. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Sep 03 10:00:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISCTZ-0006PT-CZ; Mon, 03 Sep 2007 10:00:25 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1ISCTY-0006Oq-M9 for ancp-confirm+ok@megatron.ietf.org; Mon, 03 Sep 2007 10:00:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISCTY-0006Oh-8w for ancp@ietf.org; Mon, 03 Sep 2007 10:00:24 -0400 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISCTW-0004km-JD for ancp@ietf.org; Mon, 03 Sep 2007 10:00:24 -0400 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l83DxsJF024497 for ; Mon, 3 Sep 2007 15:59:54 +0200 Received: from FRVELSMBS11.ad2.ad.alcatel.com ([155.132.6.35]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 3 Sep 2007 16:00:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Sep 2007 16:00:16 +0200 Message-ID: <8022200B15317E4CBFEC624DCED654027EC5AB@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Working Group Last Call for draft-ietf-ancp-security-threats-02.txt Thread-Index: AcfuMsFAUilnMmtMQbm1iHfdvUDDLw== From: "BOCCI Matthew" To: X-OriginalArrivalTime: 03 Sep 2007 14:00:21.0190 (UTC) FILETIME=[C443C660:01C7EE32] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Subject: [ANCP] Working Group Last Call for draft-ietf-ancp-security-threats-02.txt 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="===============2127673479==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============2127673479== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7EE32.C43152E7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7EE32.C43152E7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This email is to announce the start of a two week Working Group last call for draft-ietf-ancp-security-threats-02.txt. Please read the draft and provide comments to the ANCP list by Tuesday 11th September. As agreed during the Chicago meeting, the following participants kingly volunteered to review the draft as a part of the WG LC: Curtis Sherbo Phillipe Niger Michael Busser Francios LeFaucher Raymond Zhang We would like to thank them in advance for their help. We will not be in a position to progress the draft until we have received comments from at least five reviewers.=20 Regards, Matthew & Woj ----------------------------------------- Matthew Bocci IP Division, Alcatel-Lucent Telecom Limited,=20 Registered Office: Christchurch Way, Greenwich, London SE10 0AG.=20 Registered in England & Wales number 02650571 ----------------------------------------- ------_=_NextPart_001_01C7EE32.C43152E7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Working Group Last Call for = draft-ietf-ancp-security-threats-02.txt

This email is to announce the = start of a two week Working Group last call for draft-ietf-ancp-security-threats-02.txt.

Please read the draft and provide = comments to the ANCP list by Tuesday 11th September.

As agreed during the Chicago = meeting, the following participants kingly volunteered to review the = draft as a part of the WG LC:

Curtis Sherbo
Phillipe Niger
Michael Busser
Francios LeFaucher
Raymond Zhang

We would like to thank them in = advance for their help.

We will not be in a position to = progress the draft until we have received comments from at least five = reviewers.

Regards,

Matthew & Woj

-----------------------------------------
Matthew Bocci
IP Division,
Alcatel-Lucent = Telecom Limited,
Registered Office: = Christchurch Way, Greenwich, London SE10 0AG.
Registered in England = & Wales number 02650571
-----------------------------------------

------_=_NextPart_001_01C7EE32.C43152E7-- --===============2127673479== 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 --===============2127673479==-- From ancp-bounces@ietf.org Tue Sep 04 00:49:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISQM5-0004zS-1J; Tue, 04 Sep 2007 00:49:37 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1ISQM3-0004z2-Mc for ancp-confirm+ok@megatron.ietf.org; Tue, 04 Sep 2007 00:49:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISQM2-0004ys-Er for ancp@ietf.org; Tue, 04 Sep 2007 00:49:34 -0400 Received: from smtpa.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISQM1-00041l-4y for ancp@ietf.org; Tue, 04 Sep 2007 00:49:34 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpa.juniper.net with ESMTP; 03 Sep 2007 21:49:32 -0700 X-IronPort-AV: i="4.20,203,1186383600"; d="scan'208"; a="73988578:sNHT57302638" 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: [ANCP] ANCP WG follow-up Date: Tue, 4 Sep 2007 00:49:30 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2803B762FE@proton.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANCP WG follow-up Thread-Index: Acfsnl4SvSbv5OpeRkO1b6AIPY3/2ABhuzwgACBLTKA= From: "Sanjay Wadhwa" To: "Wojciech Dec (wdec)" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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: , Errors-To: ancp-bounces@ietf.org Woj/Matthew There was some support for multicast use-cases in general amongst the folks who were in attendence at the last WG meeting. However, specifally on draft-maglione, while it sets good context for the multicast use cases, the mechanism (and corresponding message flows) suggested in the draft only cover a single deployment scenario. It does not cover the case where the AN does not do or is incapable of IGMP snooping, and the BNG controls the replication on the AN via ANCP.=20 Adding general text on multicast use-cases (conditional access/CAC/accounting) in the framework draft is fine. However, choosing a single deployment model, and adding message flows for it in the framework draft, is not ideal.=20 Also, there were specific questions raised on the mailing list on some of the suggestions in the draft (specifically pertaining to flow-group optimization). We haven't seen any responses.=20 IMHO, we need to make progress on both these fronts (describing alternate deployment model, and providing clarity on mechanisms defined in draft-maglione) before we can make progress on adding detailed message flows and corresponding protocol machinery to framework and protocol drafts. Regards -Sanjay =20 >-----Original Message----- >From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] >Sent: Monday, September 03, 2007 8:39 AM >To: ancp@ietf.org >Subject: [ANCP] ANCP WG follow-up > > >Hi All, > >At the recent IETF meeting we've heard a fair amount of debate=20 >regarding >the subject of multicast. The debate spanned multiple camps and went >over both the whys, the why not's, as well as pros and cons.=20 >The general >consensus formed at the meeting was that the framework and requirements >document needs to cover all use cases to the same level of=20 >depth, and to >have sufficient detail to design the protocol. This in effect means the >definition of the message primitives for supporting the use-case(s).=20 >We also heard there being significantly more support than not for >introducing into the protocol the flexibility offered by the >request-response message set as proposed in draft-maglione, along with >the use-cases. Hence, we would like to confirm the following direction >with the working group for carrying out the following two points: > >1. Introduce into the latest draft-ietf-ancp-framework changes and text >that covers the following: >- High level message diagram including query/response primitives >- Description of the following multicast-use cases;=20 >* Multicast Conditional Access >* Multicast Admission Control >* Multicast Accounting >* Multicast Termination > >Some solidification of the final text will be required and=20 >ought to take >place on the alias. For the above however draft-maglione appears to >contain a fair base of the material required. > >2. The WG commences work on defining the necessary protocol extensions >for inclusion in draft-ietf-ancp-protocol, based on the protocol >specific text in draft-maglione. > >Regards, >Woj and Matthew. > > > > >_______________________________________________ >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 Tue Sep 04 07:04:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISWCf-0001Ys-Sr; Tue, 04 Sep 2007 07:04:17 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1ISWCe-0001Yi-NC for ancp-confirm+ok@megatron.ietf.org; Tue, 04 Sep 2007 07:04:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISWCe-0001Ya-Db for ancp@ietf.org; Tue, 04 Sep 2007 07:04:16 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISWCc-0005Yb-Tv for ancp@ietf.org; Tue, 04 Sep 2007 07:04:16 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 04 Sep 2007 13:04:06 +0200 X-IronPort-AV: i="4.20,206,1186351200"; d="scan'208"; a="152155876:sNHT17659551238" 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 l84B456k013915; Tue, 4 Sep 2007 13:04:05 +0200 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 l84B459q001373; Tue, 4 Sep 2007 11:04:05 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); Tue, 4 Sep 2007 13:04:05 +0200 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: [ANCP] ANCP WG follow-up Date: Tue, 4 Sep 2007 13:02:33 +0200 Message-ID: In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2803B762FE@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP WG follow-up Thread-Index: Acfsnl4SvSbv5OpeRkO1b6AIPY3/2ABhuzwgACBLTKAADmoY4A== References: <9BD5D7887235424FA97DFC223CAE3C2803B762FE@proton.jnpr.net> From: "Wojciech Dec \(wdec\)" To: "Sanjay Wadhwa" , , X-OriginalArrivalTime: 04 Sep 2007 11:04:05.0377 (UTC) FILETIME=[4F008710:01C7EEE3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4679; t=1188903845; x=1189767845; 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=20[ANCP]=20ANCP=20WG=20follow-up |Sender:=20; bh=43dEG1zwn+DjU/jVcSfUhdzqv0+fhSgmWHLSB5NTU2I=; b=Vwgy8nj0XnU7q+cioW9XhSwNnmFUeD1rUk3mcPnMYmVhYfmFy0U7DcoW827PEFonnL+0JkEW 9KYnC5JwzV0rg3N61Z0Dj8kIQXtIE5pn9zKMKNSOZ8E93Ks+XnsZUwF8; 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: 36c793b20164cfe75332aa66ddb21196 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: , Errors-To: ancp-bounces@ietf.org Sanjay, The points you raise regarding more specifics around flow groups are fine, and should take place on the alias as part of the work on the protocol draft text. Also for scenarios where the AN is not capable of for example IGMP processing (which is precisely the functional model you seem to say needs to be added), feel free to propose for discussion the use-case and a mechanism that fits with the draft-maglione proposal. As a side-note: I do remember hearing from several group participants opinions that "legacy ATM" use-cases (and non IGMP capable access-nodes could likely fall in that category) should be placed on a lower footing than the others in relation to new use-cases. The complexity of any mechanism aimed at supporting these use-cases in this category vs their benefit needs to be one of the considerations for the WG.=20 Regards, Woj. > -----Original Message----- > From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 > Sent: 04 September 2007 06:50 > To: Wojciech Dec (wdec); ancp@ietf.org;=20 > Matthew.Bocci@alcatel-lucent.co.uk > Subject: RE: [ANCP] ANCP WG follow-up >=20 > Woj/Matthew > There was some support for multicast use-cases in general=20 > amongst the folks who were in attendence at the last WG=20 > meeting. However, specifally on draft-maglione, while it sets=20 > good context for the multicast use cases, the mechanism (and=20 > corresponding message flows) suggested in the draft only=20 > cover a single deployment scenario. It does not cover the=20 > case where the AN does not do or is incapable of IGMP=20 > snooping, and the BNG controls the replication on the AN via ANCP.=20 > Adding general text on multicast use-cases (conditional > access/CAC/accounting) in the framework draft is fine.=20 > However, choosing a single deployment model, and adding=20 > message flows for it in the framework draft, is not ideal.=20 > Also, there were specific questions raised on the mailing=20 > list on some of the suggestions in the draft (specifically=20 > pertaining to flow-group optimization). We haven't seen any=20 > responses.=20 > IMHO, we need to make progress on both these fronts=20 > (describing alternate deployment model, and providing clarity=20 > on mechanisms defined in draft-maglione) before we can make=20 > progress on adding detailed message flows and corresponding=20 > protocol machinery to framework and protocol drafts. >=20 > Regards > -Sanjay =20 >=20 > >-----Original Message----- > >From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] > >Sent: Monday, September 03, 2007 8:39 AM > >To: ancp@ietf.org > >Subject: [ANCP] ANCP WG follow-up > > > > > >Hi All, > > > >At the recent IETF meeting we've heard a fair amount of debate=20 > >regarding the subject of multicast. The debate spanned=20 > multiple camps=20 > >and went over both the whys, the why not's, as well as pros and cons. > >The general > >consensus formed at the meeting was that the framework and=20 > requirements=20 > >document needs to cover all use cases to the same level of=20 > depth, and=20 > >to have sufficient detail to design the protocol. This in=20 > effect means=20 > >the definition of the message primitives for supporting the=20 > >use-case(s). > >We also heard there being significantly more support than not for=20 > >introducing into the protocol the flexibility offered by the=20 > >request-response message set as proposed in draft-maglione,=20 > along with=20 > >the use-cases. Hence, we would like to confirm the following=20 > direction=20 > >with the working group for carrying out the following two points: > > > >1. Introduce into the latest draft-ietf-ancp-framework=20 > changes and text=20 > >that covers the following: > >- High level message diagram including query/response primitives > >- Description of the following multicast-use cases; > >* Multicast Conditional Access > >* Multicast Admission Control > >* Multicast Accounting > >* Multicast Termination > > > >Some solidification of the final text will be required and ought to=20 > >take place on the alias. For the above however=20 > draft-maglione appears=20 > >to contain a fair base of the material required. > > > >2. The WG commences work on defining the necessary protocol=20 > extensions=20 > >for inclusion in draft-ietf-ancp-protocol, based on the protocol=20 > >specific text in draft-maglione. > > > >Regards, > >Woj and Matthew. > > > > > > > > > >_______________________________________________ > >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 Sep 04 09:18: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 1ISYI4-0002c5-D8; Tue, 04 Sep 2007 09:18:00 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1ISYI4-0002c0-0Y for ancp-confirm+ok@megatron.ietf.org; Tue, 04 Sep 2007 09:18:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISYI3-0002bs-LX for ancp@ietf.org; Tue, 04 Sep 2007 09:17:59 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISYI2-0000XI-PD for ancp@ietf.org; Tue, 04 Sep 2007 09:17:59 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpb.juniper.net with ESMTP; 04 Sep 2007 06:17:57 -0700 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: [ANCP] ANCP WG follow-up Date: Tue, 4 Sep 2007 09:17:55 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280A632744@proton.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP WG follow-up Thread-Index: Acfsnl4SvSbv5OpeRkO1b6AIPY3/2ABhuzwgACBLTKAADmoY4AADyPrw From: "Sanjay Wadhwa" To: "Wojciech Dec (wdec)" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f 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: , Errors-To: ancp-bounces@ietf.org Woj There are questions with the flow-group concept (and other mechanisms in the draft), that have already been raised in email threads. Since you are suggesting, the framework document should contain message flows for a specific solution, it needs to be made sure that the solution is a workable solution, and does not ignore viable deployment options, before we do anything with the framework draft. Ideally, the framework draft should not contain message flows for a specific solution/implementation. On the second issue, IGMP snooping capability or lack of (for both IP and PPP) on an "AN" or the necessity for a deployment to use it, if supported, has nothing to do with ATM or Ethernet. By lumping these together one could conveniently ignore viable deployment scenarios, which is not justified.=20 There are tier-1 deployments today, where the replication as well as all the necessary multicast control happens on the BNG. It is desirable to move the replication to the AN. However, this should not come with the need and complexity to move all the necessary multicast control processing to the AN. The use-cases for both models are the same (conditional access, multi-service CAC, accounting etc). The message-flows, *complexity* and the extent to which ANCP is leveraged in each case is different.=20 Regards -Sanjay -----Original Message----- From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: Tuesday, September 04, 2007 7:03 AM To: Sanjay Wadhwa; ancp@ietf.org; Matthew.Bocci@alcatel-lucent.co.uk Subject: RE: [ANCP] ANCP WG follow-up Sanjay, The points you raise regarding more specifics around flow groups are fine, and should take place on the alias as part of the work on the protocol draft text. Also for scenarios where the AN is not capable of for example IGMP processing (which is precisely the functional model you seem to say needs to be added), feel free to propose for discussion the use-case and a mechanism that fits with the draft-maglione proposal. As a side-note: I do remember hearing from several group participants opinions that "legacy ATM" use-cases (and non IGMP capable access-nodes could likely fall in that category) should be placed on a lower footing than the others in relation to new use-cases. The complexity of any mechanism aimed at supporting these use-cases in this category vs their benefit needs to be one of the considerations for the WG.=20 Regards, Woj. > -----Original Message----- > From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 > Sent: 04 September 2007 06:50 > To: Wojciech Dec (wdec); ancp@ietf.org;=20 > Matthew.Bocci@alcatel-lucent.co.uk > Subject: RE: [ANCP] ANCP WG follow-up >=20 > Woj/Matthew > There was some support for multicast use-cases in general=20 > amongst the folks who were in attendence at the last WG=20 > meeting. However, specifally on draft-maglione, while it sets=20 > good context for the multicast use cases, the mechanism (and=20 > corresponding message flows) suggested in the draft only=20 > cover a single deployment scenario. It does not cover the=20 > case where the AN does not do or is incapable of IGMP=20 > snooping, and the BNG controls the replication on the AN via ANCP.=20 > Adding general text on multicast use-cases (conditional > access/CAC/accounting) in the framework draft is fine.=20 > However, choosing a single deployment model, and adding=20 > message flows for it in the framework draft, is not ideal.=20 > Also, there were specific questions raised on the mailing=20 > list on some of the suggestions in the draft (specifically=20 > pertaining to flow-group optimization). We haven't seen any=20 > responses.=20 > IMHO, we need to make progress on both these fronts=20 > (describing alternate deployment model, and providing clarity=20 > on mechanisms defined in draft-maglione) before we can make=20 > progress on adding detailed message flows and corresponding=20 > protocol machinery to framework and protocol drafts. >=20 > Regards > -Sanjay =20 >=20 > >-----Original Message----- > >From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] > >Sent: Monday, September 03, 2007 8:39 AM > >To: ancp@ietf.org > >Subject: [ANCP] ANCP WG follow-up > > > > > >Hi All, > > > >At the recent IETF meeting we've heard a fair amount of debate=20 > >regarding the subject of multicast. The debate spanned=20 > multiple camps=20 > >and went over both the whys, the why not's, as well as pros and cons. > >The general > >consensus formed at the meeting was that the framework and=20 > requirements=20 > >document needs to cover all use cases to the same level of=20 > depth, and=20 > >to have sufficient detail to design the protocol. This in=20 > effect means=20 > >the definition of the message primitives for supporting the=20 > >use-case(s). > >We also heard there being significantly more support than not for=20 > >introducing into the protocol the flexibility offered by the=20 > >request-response message set as proposed in draft-maglione,=20 > along with=20 > >the use-cases. Hence, we would like to confirm the following=20 > direction=20 > >with the working group for carrying out the following two points: > > > >1. Introduce into the latest draft-ietf-ancp-framework=20 > changes and text=20 > >that covers the following: > >- High level message diagram including query/response primitives > >- Description of the following multicast-use cases; > >* Multicast Conditional Access > >* Multicast Admission Control > >* Multicast Accounting > >* Multicast Termination > > > >Some solidification of the final text will be required and ought to=20 > >take place on the alias. For the above however=20 > draft-maglione appears=20 > >to contain a fair base of the material required. > > > >2. The WG commences work on defining the necessary protocol=20 > extensions=20 > >for inclusion in draft-ietf-ancp-protocol, based on the protocol=20 > >specific text in draft-maglione. > > > >Regards, > >Woj and Matthew. > > > > > > > > > >_______________________________________________ > >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 Sep 05 06:44:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISsNB-0007DE-Ds; Wed, 05 Sep 2007 06:44:37 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1ISsNA-0007Cy-8E for ancp-confirm+ok@megatron.ietf.org; Wed, 05 Sep 2007 06:44:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISsN9-0007Cp-SL for ancp@ietf.org; Wed, 05 Sep 2007 06:44:35 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISsN8-0007Tm-C1 for ancp@ietf.org; Wed, 05 Sep 2007 06:44:35 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 05 Sep 2007 12:44:34 +0200 X-IronPort-AV: i="4.20,210,1186351200"; d="scan'208"; a="152266587:sNHT72476532" 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 l85AiX4M000420; Wed, 5 Sep 2007 12:44:33 +0200 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 l85AiLS6017215; Wed, 5 Sep 2007 10:44:29 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); Wed, 5 Sep 2007 12:44:21 +0200 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: [ANCP] ANCP WG follow-up Date: Wed, 5 Sep 2007 12:43:02 +0200 Message-ID: In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280A632744@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP WG follow-up Thread-Index: Acfsnl4SvSbv5OpeRkO1b6AIPY3/2ABhuzwgACBLTKAADmoY4AADyPrwACtjLDA= References: <9BD5D7887235424FA97DFC223CAE3C280A632744@proton.jnpr.net> From: "Wojciech Dec \(wdec\)" To: "Sanjay Wadhwa" , , X-OriginalArrivalTime: 05 Sep 2007 10:44:21.0212 (UTC) FILETIME=[B79909C0:01C7EFA9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9234; t=1188989073; x=1189853073; 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=20[ANCP]=20ANCP=20WG=20follow-up |Sender:=20; bh=IO1qCzfjjsU3vFeC1TX4/xyNjPp5jIXMcWkuHKaRy/4=; b=FFFQPg8XAp8SGZYvmeG0I+YRwTjLxghF6Y7+rFkSXXUlLlugJhzNmcZAgPVD/GQmFxOERlzM cDcIxDMJjRRdDlClLAXTVak2PRHDC/+xi0vurMXV9VVBt9hL7JywgB/R; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 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: , Errors-To: ancp-bounces@ietf.org Sanjay, The framework document is the place to define the message primitives and use-cases - this is intended not to drive any specific solution but rather the overall fundamental protocol messaging capability. I would also like to point out that this is not *my* suggestion, but rather the conclusion reached by the WG at the meeting.=20 Flow groups or not, the primitives that appear to be required for the multicast case(s) are the Request/Response ones (see Figure 1 of the ancp-framework document for an example of other primitives). So, to re-iterate the direction for the WG is to;=20 * include in the framework document such message primitives and a description of the use-cases.=20 * Work on message specifics for protocol draft.=20 In the above review and comments on the specific text for each of the drafts will take place as usual though discussion on the alias. Now let's delve into the two specific issues you raise and open up the discussion to the WG as a whole: 1. The flow-group concept is generally understood to be an intended to reduce/optimize the number of ANCP messaging transactions subject to certain conditions related to the multicast-use case(s). This seems to be a worthwhile goal, and even though the current flow-group text is not perfect and protocol details are not sufficient, there is no other optimization mechanism on the table. It's clearly up to further debate by the WG on how the optimization behaviour should be realized in protocol specifics, eg by using a type-of-Response message, or though a change-of-configuration message. Now, could you, or anyone present an alternative proposal for such optimization? Or are you objecting to the whole concept? 2. Alternative Deployment scenarios. Can you please prepare a *concrete proposal* regarding the scenario you describe, and the modifications to the high-level (primitives) mechanism in draft-maglione required to support it? Before this is presented, saying that there are other "viable deployment scenarios" is not very constructive and doesn't allow the WG to make an assessment on what to do with it. Regards, Woj. =20 > -----Original Message----- > From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 > Sent: 04 September 2007 15:18 > To: Wojciech Dec (wdec); ancp@ietf.org;=20 > Matthew.Bocci@alcatel-lucent.co.uk > Subject: RE: [ANCP] ANCP WG follow-up >=20 > Woj > There are questions with the flow-group concept (and other=20 > mechanisms in the draft), that have already been raised in=20 > email threads. Since you are suggesting, the framework=20 > document should contain message flows for a specific=20 > solution, it needs to be made sure that the solution is a=20 > workable solution, and does not ignore viable deployment=20 > options, before we do anything with the framework draft.=20 > Ideally, the framework draft should not contain message flows=20 > for a specific solution/implementation. >=20 > On the second issue, IGMP snooping capability or lack of (for=20 > both IP and PPP) on an "AN" or the necessity for a deployment=20 > to use it, if supported, has nothing to do with ATM or=20 > Ethernet. By lumping these together one could conveniently=20 > ignore viable deployment scenarios, which is not justified.=20 > There are tier-1 deployments today, where the replication as=20 > well as all the necessary multicast control happens on the=20 > BNG. It is desirable to move the replication to the AN.=20 > However, this should not come with the need and complexity to=20 > move all the necessary multicast control processing to the AN. >=20 > The use-cases for both models are the same (conditional=20 > access, multi-service CAC, accounting etc). The=20 > message-flows, *complexity* and the extent to which ANCP is=20 > leveraged in each case is different.=20 >=20 > Regards > -Sanjay >=20 > -----Original Message----- > From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] > Sent: Tuesday, September 04, 2007 7:03 AM > To: Sanjay Wadhwa; ancp@ietf.org; Matthew.Bocci@alcatel-lucent.co.uk > Subject: RE: [ANCP] ANCP WG follow-up >=20 > Sanjay, >=20 > The points you raise regarding more specifics around flow=20 > groups are fine, and should take place on the alias as part=20 > of the work on the protocol draft text. > Also for scenarios where the AN is not capable of for example=20 > IGMP processing (which is precisely the functional model you=20 > seem to say needs to be added), feel free to propose for=20 > discussion the use-case and a mechanism that fits with the=20 > draft-maglione proposal. >=20 > As a side-note: I do remember hearing from several group=20 > participants opinions that "legacy ATM" use-cases (and non=20 > IGMP capable access-nodes could likely fall in that category)=20 > should be placed on a lower footing than the others in=20 > relation to new use-cases. The complexity of any mechanism=20 > aimed at supporting these use-cases in this category vs their=20 > benefit needs to be one of the considerations for the WG.=20 >=20 > Regards, > Woj. >=20 > > -----Original Message----- > > From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] > > Sent: 04 September 2007 06:50 > > To: Wojciech Dec (wdec); ancp@ietf.org;=20 > > Matthew.Bocci@alcatel-lucent.co.uk > > Subject: RE: [ANCP] ANCP WG follow-up > >=20 > > Woj/Matthew > > There was some support for multicast use-cases in=20 > general amongst=20 > > the folks who were in attendence at the last WG meeting. However,=20 > > specifally on draft-maglione, while it sets good context for the=20 > > multicast use cases, the mechanism (and corresponding=20 > message flows)=20 > > suggested in the draft only cover a single deployment scenario. It=20 > > does not cover the case where the AN does not do or is incapable of=20 > > IGMP snooping, and the BNG controls the replication on the AN via=20 > > ANCP. > > Adding general text on multicast use-cases (conditional > > access/CAC/accounting) in the framework draft is fine.=20 > > However, choosing a single deployment model, and adding=20 > message flows=20 > > for it in the framework draft, is not ideal. > > Also, there were specific questions raised on the mailing=20 > list on some=20 > > of the suggestions in the draft (specifically pertaining to=20 > flow-group=20 > > optimization). We haven't seen any responses. > > IMHO, we need to make progress on both these fronts (describing=20 > > alternate deployment model, and providing clarity on mechanisms=20 > > defined in draft-maglione) before we can make progress on adding=20 > > detailed message flows and corresponding protocol machinery to=20 > > framework and protocol drafts. > >=20 > > Regards > > -Sanjay =20 > >=20 > > >-----Original Message----- > > >From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] > > >Sent: Monday, September 03, 2007 8:39 AM > > >To: ancp@ietf.org > > >Subject: [ANCP] ANCP WG follow-up > > > > > > > > >Hi All, > > > > > >At the recent IETF meeting we've heard a fair amount of debate=20 > > >regarding the subject of multicast. The debate spanned > > multiple camps > > >and went over both the whys, the why not's, as well as=20 > pros and cons. > > >The general > > >consensus formed at the meeting was that the framework and > > requirements > > >document needs to cover all use cases to the same level of > > depth, and > > >to have sufficient detail to design the protocol. This in > > effect means > > >the definition of the message primitives for supporting the=20 > > >use-case(s). > > >We also heard there being significantly more support than not for=20 > > >introducing into the protocol the flexibility offered by the=20 > > >request-response message set as proposed in draft-maglione, > > along with > > >the use-cases. Hence, we would like to confirm the following > > direction > > >with the working group for carrying out the following two points: > > > > > >1. Introduce into the latest draft-ietf-ancp-framework > > changes and text > > >that covers the following: > > >- High level message diagram including query/response primitives > > >- Description of the following multicast-use cases; > > >* Multicast Conditional Access > > >* Multicast Admission Control > > >* Multicast Accounting > > >* Multicast Termination > > > > > >Some solidification of the final text will be required and=20 > ought to=20 > > >take place on the alias. For the above however > > draft-maglione appears > > >to contain a fair base of the material required. > > > > > >2. The WG commences work on defining the necessary protocol > > extensions > > >for inclusion in draft-ietf-ancp-protocol, based on the protocol=20 > > >specific text in draft-maglione. > > > > > >Regards, > > >Woj and Matthew. > > > > > > > > > > > > > > >_______________________________________________ > > >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 Sep 05 16:39: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 1IT1eX-0003la-Ih; Wed, 05 Sep 2007 16:39:09 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IT1eW-0003lS-O4 for ancp-confirm+ok@megatron.ietf.org; Wed, 05 Sep 2007 16:39:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT1eW-0003ks-E2 for ancp@ietf.org; Wed, 05 Sep 2007 16:39:08 -0400 Received: from smtpa.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IT1eU-0007sO-VF for ancp@ietf.org; Wed, 05 Sep 2007 16:39:08 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpa.juniper.net with ESMTP; 05 Sep 2007 13:39:05 -0700 X-IronPort-AV: i="4.20,211,1186383600"; d="scan'208"; a="75413741:sNHT89382502" 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: [ANCP] ANCP WG follow-up Date: Wed, 5 Sep 2007 16:39:04 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280A7B43B7@proton.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP WG follow-up Thread-Index: Acfsnl4SvSbv5OpeRkO1b6AIPY3/2ABhuzwgACBLTKAADmoY4AADyPrwACtjLDAAFIdA4A== From: "Sanjay Wadhwa" To: "Wojciech Dec (wdec)" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb 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: , Errors-To: ancp-bounces@ietf.org Woj Framework draft needs to contain requirements and use-cases for ANCP. This is the model used until now in the framework draft. There is a single high-level communication flow (figure 1) for ANCP mechanism in general. This is equally applicable to multicast use-case. As you will notice, there is no other use-case specific message exchange in the framework draft.=20 Adding message flows from draft-maglione to the framework draft is solution-creep, which has been avoided until now. Message flows in draft-maglione are tied to the proposed solution. As an example consider the message flow in figure 9 from the draft. It is related to the suggested solution as it refers to flow-groups in message exchange.=20 With respect to #1 in your mail below, I am not opposed to any optimizations aimed at reducing message load. However, the optimization as a concept has to gurantee correctness and simplicity, both of which are independent of the protocol messages used to implement the concept. A more constructive approach would be for the authors of the draft to consider issues raised thus far to ensure a workable solution, before any push from WG chair for inclusion of content into the framework draft. With respect to #2, draft-maglione requires/mandates IGMP snooping and full IGMP control on the AN, which is a valid option. However, we also need to consider the option where the AN does the replication, but is not burdened with all the associated IGMP control. And again this has nothing to do with ATM or Ethernet in the aggregation network. The concreate proposal is for the "Home Gateway" to send per-subscriber IGMP to the BNG, which triggers per-subscriber conditional-access, admission-control, and accounting on the BNG. If both access and admission control passes, the BNG can use ANCP to set multicast replication state on the AN.=20 A variation here could be that the AN transparently snoops, but autonomously acts on IGMP leaves to implement a "fast leave". However, the creation of the replication state on AN is still controlled by the BNG via ANCP, subject to access and admission control.=20 Regards -Sanjay =20 -----Original Message----- From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: Wednesday, September 05, 2007 6:43 AM To: Sanjay Wadhwa; ancp@ietf.org; Matthew.Bocci@alcatel-lucent.co.uk Subject: RE: [ANCP] ANCP WG follow-up Sanjay, The framework document is the place to define the message primitives and use-cases - this is intended not to drive any specific solution but rather the overall fundamental protocol messaging capability. I would also like to point out that this is not *my* suggestion, but rather the conclusion reached by the WG at the meeting.=20 Flow groups or not, the primitives that appear to be required for the multicast case(s) are the Request/Response ones (see Figure 1 of the ancp-framework document for an example of other primitives). So, to re-iterate the direction for the WG is to; * include in the framework document such message primitives and a description of the use-cases.=20 * Work on message specifics for protocol draft.=20 In the above review and comments on the specific text for each of the drafts will take place as usual though discussion on the alias. Now let's delve into the two specific issues you raise and open up the discussion to the WG as a whole: 1. The flow-group concept is generally understood to be an intended to reduce/optimize the number of ANCP messaging transactions subject to certain conditions related to the multicast-use case(s). This seems to be a worthwhile goal, and even though the current flow-group text is not perfect and protocol details are not sufficient, there is no other optimization mechanism on the table. It's clearly up to further debate by the WG on how the optimization behaviour should be realized in protocol specifics, eg by using a type-of-Response message, or though a change-of-configuration message. Now, could you, or anyone present an alternative proposal for such optimization? Or are you objecting to the whole concept? 2. Alternative Deployment scenarios. Can you please prepare a *concrete proposal* regarding the scenario you describe, and the modifications to the high-level (primitives) mechanism in draft-maglione required to support it? Before this is presented, saying that there are other "viable deployment scenarios" is not very constructive and doesn't allow the WG to make an assessment on what to do with it. Regards, Woj. =20 > -----Original Message----- > From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] > Sent: 04 September 2007 15:18 > To: Wojciech Dec (wdec); ancp@ietf.org;=20 > Matthew.Bocci@alcatel-lucent.co.uk > Subject: RE: [ANCP] ANCP WG follow-up >=20 > Woj > There are questions with the flow-group concept (and other=20 > mechanisms in the draft), that have already been raised in email=20 > threads. Since you are suggesting, the framework document should=20 > contain message flows for a specific solution, it needs to be made=20 > sure that the solution is a workable solution, and does not ignore=20 > viable deployment options, before we do anything with the framework=20 > draft. > Ideally, the framework draft should not contain message flows for a=20 > specific solution/implementation. >=20 > On the second issue, IGMP snooping capability or lack of (for both IP=20 > and PPP) on an "AN" or the necessity for a deployment to use it, if=20 > supported, has nothing to do with ATM or Ethernet. By lumping these=20 > together one could conveniently ignore viable deployment scenarios,=20 > which is not justified. > There are tier-1 deployments today, where the replication as well as=20 > all the necessary multicast control happens on the BNG. It is=20 > desirable to move the replication to the AN. > However, this should not come with the need and complexity to move all > the necessary multicast control processing to the AN. >=20 > The use-cases for both models are the same (conditional access,=20 > multi-service CAC, accounting etc). The message-flows, *complexity*=20 > and the extent to which ANCP is leveraged in each case is different. >=20 > Regards > -Sanjay >=20 > -----Original Message----- > From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] > Sent: Tuesday, September 04, 2007 7:03 AM > To: Sanjay Wadhwa; ancp@ietf.org; Matthew.Bocci@alcatel-lucent.co.uk > Subject: RE: [ANCP] ANCP WG follow-up >=20 > Sanjay, >=20 > The points you raise regarding more specifics around flow groups are=20 > fine, and should take place on the alias as part of the work on the=20 > protocol draft text. > Also for scenarios where the AN is not capable of for example IGMP=20 > processing (which is precisely the functional model you seem to say=20 > needs to be added), feel free to propose for discussion the use-case=20 > and a mechanism that fits with the draft-maglione proposal. >=20 > As a side-note: I do remember hearing from several group participants=20 > opinions that "legacy ATM" use-cases (and non IGMP capable=20 > access-nodes could likely fall in that category) should be placed on a > lower footing than the others in relation to new use-cases. The=20 > complexity of any mechanism aimed at supporting these use-cases in=20 > this category vs their benefit needs to be one of the considerations=20 > for the WG. >=20 > Regards, > Woj. >=20 > > -----Original Message----- > > From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] > > Sent: 04 September 2007 06:50 > > To: Wojciech Dec (wdec); ancp@ietf.org;=20 > > Matthew.Bocci@alcatel-lucent.co.uk > > Subject: RE: [ANCP] ANCP WG follow-up > >=20 > > Woj/Matthew > > There was some support for multicast use-cases in > general amongst > > the folks who were in attendence at the last WG meeting. However,=20 > > specifally on draft-maglione, while it sets good context for the=20 > > multicast use cases, the mechanism (and corresponding > message flows) > > suggested in the draft only cover a single deployment scenario. It=20 > > does not cover the case where the AN does not do or is incapable of=20 > > IGMP snooping, and the BNG controls the replication on the AN via=20 > > ANCP. > > Adding general text on multicast use-cases (conditional > > access/CAC/accounting) in the framework draft is fine.=20 > > However, choosing a single deployment model, and adding > message flows > > for it in the framework draft, is not ideal. > > Also, there were specific questions raised on the mailing > list on some > > of the suggestions in the draft (specifically pertaining to > flow-group > > optimization). We haven't seen any responses. > > IMHO, we need to make progress on both these fronts (describing=20 > > alternate deployment model, and providing clarity on mechanisms=20 > > defined in draft-maglione) before we can make progress on adding=20 > > detailed message flows and corresponding protocol machinery to=20 > > framework and protocol drafts. > >=20 > > Regards > > -Sanjay =20 > >=20 > > >-----Original Message----- > > >From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] > > >Sent: Monday, September 03, 2007 8:39 AM > > >To: ancp@ietf.org > > >Subject: [ANCP] ANCP WG follow-up > > > > > > > > >Hi All, > > > > > >At the recent IETF meeting we've heard a fair amount of debate=20 > > >regarding the subject of multicast. The debate spanned > > multiple camps > > >and went over both the whys, the why not's, as well as > pros and cons. > > >The general > > >consensus formed at the meeting was that the framework and > > requirements > > >document needs to cover all use cases to the same level of > > depth, and > > >to have sufficient detail to design the protocol. This in > > effect means > > >the definition of the message primitives for supporting the=20 > > >use-case(s). > > >We also heard there being significantly more support than not for=20 > > >introducing into the protocol the flexibility offered by the=20 > > >request-response message set as proposed in draft-maglione, > > along with > > >the use-cases. Hence, we would like to confirm the following > > direction > > >with the working group for carrying out the following two points: > > > > > >1. Introduce into the latest draft-ietf-ancp-framework > > changes and text > > >that covers the following: > > >- High level message diagram including query/response primitives > > >- Description of the following multicast-use cases; > > >* Multicast Conditional Access > > >* Multicast Admission Control > > >* Multicast Accounting > > >* Multicast Termination > > > > > >Some solidification of the final text will be required and > ought to > > >take place on the alias. For the above however > > draft-maglione appears > > >to contain a fair base of the material required. > > > > > >2. The WG commences work on defining the necessary protocol > > extensions > > >for inclusion in draft-ietf-ancp-protocol, based on the protocol=20 > > >specific text in draft-maglione. > > > > > >Regards, > > >Woj and Matthew. > > > > > > > > > > > > > > >_______________________________________________ > > >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 Thu Sep 06 06:25: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 1ITEXj-0000TP-QL; Thu, 06 Sep 2007 06:24:59 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1ITEXi-0000TG-Dy for ancp-confirm+ok@megatron.ietf.org; Thu, 06 Sep 2007 06:24:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITEXi-0000T6-1W for ancp@ietf.org; Thu, 06 Sep 2007 06:24:58 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITEXg-0002Fj-5P for ancp@ietf.org; Thu, 06 Sep 2007 06:24:57 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 06 Sep 2007 12:24:56 +0200 X-IronPort-AV: i="4.20,215,1186351200"; d="scan'208"; a="152371663:sNHT119430384" 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 l86AOtoi025538; Thu, 6 Sep 2007 12:24:55 +0200 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 l86AOjgX027503; Thu, 6 Sep 2007 10:24:55 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 12:24:44 +0200 Received: from [144.254.53.188] ([144.254.53.188]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 12:24:44 +0200 In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280A7B43B7@proton.jnpr.net> References: <9BD5D7887235424FA97DFC223CAE3C280A7B43B7@proton.jnpr.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <993FAD2C-746F-4F59-B523-CF2CCA1BEFD0@cisco.com> Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Subject: Re: [ANCP] ANCP WG follow-up Date: Thu, 6 Sep 2007 12:24:40 +0200 To: Sanjay Wadhwa X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 06 Sep 2007 10:24:44.0521 (UTC) FILETIME=[24A5FD90:01C7F070] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=15674; t=1189074295; x=1189938295; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[ANCP]=20ANCP=20WG=20follow-up |Sender:=20; bh=bb1GmLwBKsYscgrI105wgMwjdhfZtFx47/QHdmfgsbc=; b=EuggHqTlrPfiwsGeiV3Zx88vJbJPC+AyhgWSnCfVTmrfDfgEdvlNGmKALan2Dzl1FfZCTZQa m4/TGgk1oP0fcHYJDrxtLGMQ5x7dW8idjfTfrCh+OEcvxG7uiI4eto0x; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: df1883a27a831c1ea5e8cfe5eb3ad38e 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 Hi Sanjay, On 5 Sep 2007, at 22:39, Sanjay Wadhwa wrote: > Woj > Framework draft needs to contain requirements and use-cases for ANCP. > This is the model used until now in the framework draft. There is a > single high-level communication flow (figure 1) for ANCP mechanism in > general. This is equally applicable to multicast use-case. As you will > notice, there is no other use-case specific message exchange in the > framework draft. Very true. But as you will notice, the primitives and parameters are indeed defined in the framework for each use case. Example of primitives discussed include: " The NAS may then use the Configure Request message to send a reference to the right profile to the Access Node. The NAS may also update the Access Loop configuration due to a Subscriber service change (e.g. triggered by the policy server)." Example of parameters listed for these primitives include: " In case of DSL Access Loops, the following Access Loop characteristics can be sent to the NAS (cf. ITU-T Recommendation G.997.1 [G.997.1]): o DSL Type (e.g. ADSL1, ADSL2, SDSL, ADSL2+, VDSL, VDSL2) o Framing mode (e.g. ATM, ITU-T Packet Transfer Mode (PTM), IEEE 802.3 Ethernet in the First Mile (EFM)) o DSL port state (e.g. synchronized/showtime, low power, no power/ idle) o Actual net data rate (upstream/downstream) o Maximum achievable/attainable data rate (upstream/downstream) o Minimum data rate configured for the Access Loop (upstream/ downstream) o Maximum data rate configured for the Access Loop (upstream/ downstream) o Minimum data rate in low power state configured for the Access Loop (upstream/downstream) o Maximum achievable interleaving delay (upstream/downstream) o Actual interleaving delay (upstream/downstream) " > Adding message flows from draft-maglione to the framework draft is > solution-creep, which has been avoided until now. Message flows in > draft-maglione are tied to the proposed solution. As an example > consider > the message flow in figure 9 from the draft. The topic of "what belongs to the framework draft and what belongs to the protocol draft" has come up before. I believe the agreed conclusion is: * the framework document ought to include: (1) requirements (2) use-cases (3) primitives/parameters (REPEAT: primitives and parameters) * the protocol document ought to include: (1) actual message flows. This is what has been done for all the existing use cases in the current framework. I believe this is what we have also re-established during the Chicago meeting. Do you agree with this breakout? draft-maglione explicitly says: "This proposal aims at collecting feedback from this community in order to work towards consensus. Eventually, text derived from the material in section 3. and 4. would be intended to be incorporated in "ANCP Framework I-D" [1]. Similarly, text derived from the material of section 5. would be intended to be incorporated in "ANCP Protocol I-D" [2] and to be extended with actual protocol extensions. " So it is NOT proposing to incorporate message flows (such as the one in figure 9) into the framework, but rather into the protocol document. In his message below, while Woj is proposing that primitives/ parameters be included into the framework, he is NOT proposing that message flows be incorporated into the framework. Is it clear to you now that neither the draft-maglione co-authors nor Woj are trying to push any message flow into the framework? > It is related to the > suggested solution as it refers to flow-groups in message exchange. > > With respect to #1 in your mail below, I am not opposed to any > optimizations aimed at reducing message load. However, the > optimization > as a concept has to gurantee correctness and simplicity, both of which > are independent of the protocol messages used to implement the > concept. > A more constructive approach would be for the authors of the draft to > consider issues raised thus far to ensure a workable solution, before > any push from WG chair for inclusion of content into the framework > draft. Yes, we need to further discuss the comments/suggestions brought up on the list on the primitives discussed in draft-maglione before they can be incorporated in the framework document. We'll try get onto this soon, and see if we can work towards some converged approach. > > With respect to #2, draft-maglione requires/mandates IGMP snooping and > full IGMP control on the AN, which is a valid option. However, we also > need to consider the option where the AN does the replication, but is > not burdened with all the associated IGMP control. If the WG decides to incorporate that approach into the framework also, a possible approach could be to try make the draft-maglione approach more explicitly modular whereby one could either : - deploy the full ANCP solution : ie ANCP for relaying leave/join from AN to BNG + ANCP for controlling replication by BNG, or - hybrid solution: ie IGMP for relaying leave/join from AN to BNG + ANCP for controlling replication by BNG It would be good to hear other opinions from WG about whether we need to do this. Cheers Francois > And again this has > nothing to do with ATM or Ethernet in the aggregation network. > The concreate proposal is for the "Home Gateway" to send per- > subscriber > IGMP to the BNG, which triggers per-subscriber conditional-access, > admission-control, and accounting on the BNG. If both access and > admission control passes, the BNG can use ANCP to set multicast > replication state on the AN. > A variation here could be that the AN transparently snoops, but > autonomously acts on IGMP leaves to implement a "fast leave". However, > the creation of the replication state on AN is still controlled by the > BNG via ANCP, subject to access and admission control. > > Regards > -Sanjay > > > > -----Original Message----- > From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] > Sent: Wednesday, September 05, 2007 6:43 AM > To: Sanjay Wadhwa; ancp@ietf.org; Matthew.Bocci@alcatel-lucent.co.uk > Subject: RE: [ANCP] ANCP WG follow-up > > Sanjay, > > The framework document is the place to define the message > primitives and > use-cases - this is intended not to drive any specific solution but > rather the overall fundamental protocol messaging capability. I would > also like to point out that this is not *my* suggestion, but rather > the > conclusion reached by the WG at the meeting. > Flow groups or not, the primitives that appear to be required for the > multicast case(s) are the Request/Response ones (see Figure 1 of the > ancp-framework document for an example of other primitives). So, to > re-iterate the direction for the WG is to; > * include in the framework document such message primitives and a > description of the use-cases. > * Work on message specifics for protocol draft. > In the above review and comments on the specific text for each of the > drafts will take place as usual though discussion on the alias. > > Now let's delve into the two specific issues you raise and open up the > discussion to the WG as a whole: > > 1. The flow-group concept is generally understood to be an intended to > reduce/optimize the number of ANCP messaging transactions subject to > certain conditions related to the multicast-use case(s). This seems to > be a worthwhile goal, and even though the current flow-group text > is not > perfect and protocol details are not sufficient, there is no other > optimization mechanism on the table. It's clearly up to further debate > by the WG on how the optimization behaviour should be realized in > protocol specifics, eg by using a type-of-Response message, or > though a > change-of-configuration message. > > Now, could you, or anyone present an alternative proposal for such > optimization? Or are you objecting to the whole concept? > > 2. Alternative Deployment scenarios. > Can you please prepare a *concrete proposal* regarding the scenario > you > describe, and the modifications to the high-level (primitives) > mechanism > in draft-maglione required to support it? Before this is presented, > saying that there are other "viable deployment scenarios" is not very > constructive and doesn't allow the WG to make an assessment on what to > do with it. > > Regards, > Woj. > > >> -----Original Message----- >> From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] >> Sent: 04 September 2007 15:18 >> To: Wojciech Dec (wdec); ancp@ietf.org; >> Matthew.Bocci@alcatel-lucent.co.uk >> Subject: RE: [ANCP] ANCP WG follow-up >> >> Woj >> There are questions with the flow-group concept (and other >> mechanisms in the draft), that have already been raised in email >> threads. Since you are suggesting, the framework document should >> contain message flows for a specific solution, it needs to be made >> sure that the solution is a workable solution, and does not ignore >> viable deployment options, before we do anything with the framework >> draft. >> Ideally, the framework draft should not contain message flows for a >> specific solution/implementation. >> >> On the second issue, IGMP snooping capability or lack of (for both IP >> and PPP) on an "AN" or the necessity for a deployment to use it, if >> supported, has nothing to do with ATM or Ethernet. By lumping these >> together one could conveniently ignore viable deployment scenarios, >> which is not justified. >> There are tier-1 deployments today, where the replication as well as >> all the necessary multicast control happens on the BNG. It is >> desirable to move the replication to the AN. >> However, this should not come with the need and complexity to move >> all > >> the necessary multicast control processing to the AN. >> >> The use-cases for both models are the same (conditional access, >> multi-service CAC, accounting etc). The message-flows, *complexity* >> and the extent to which ANCP is leveraged in each case is different. >> >> Regards >> -Sanjay >> >> -----Original Message----- >> From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] >> Sent: Tuesday, September 04, 2007 7:03 AM >> To: Sanjay Wadhwa; ancp@ietf.org; Matthew.Bocci@alcatel-lucent.co.uk >> Subject: RE: [ANCP] ANCP WG follow-up >> >> Sanjay, >> >> The points you raise regarding more specifics around flow groups are >> fine, and should take place on the alias as part of the work on the >> protocol draft text. >> Also for scenarios where the AN is not capable of for example IGMP >> processing (which is precisely the functional model you seem to say >> needs to be added), feel free to propose for discussion the use-case >> and a mechanism that fits with the draft-maglione proposal. >> >> As a side-note: I do remember hearing from several group participants >> opinions that "legacy ATM" use-cases (and non IGMP capable >> access-nodes could likely fall in that category) should be placed >> on a > >> lower footing than the others in relation to new use-cases. The >> complexity of any mechanism aimed at supporting these use-cases in >> this category vs their benefit needs to be one of the considerations >> for the WG. >> >> Regards, >> Woj. >> >>> -----Original Message----- >>> From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] >>> Sent: 04 September 2007 06:50 >>> To: Wojciech Dec (wdec); ancp@ietf.org; >>> Matthew.Bocci@alcatel-lucent.co.uk >>> Subject: RE: [ANCP] ANCP WG follow-up >>> >>> Woj/Matthew >>> There was some support for multicast use-cases in >> general amongst >>> the folks who were in attendence at the last WG meeting. However, >>> specifally on draft-maglione, while it sets good context for the >>> multicast use cases, the mechanism (and corresponding >> message flows) >>> suggested in the draft only cover a single deployment scenario. It >>> does not cover the case where the AN does not do or is incapable of >>> IGMP snooping, and the BNG controls the replication on the AN via >>> ANCP. >>> Adding general text on multicast use-cases (conditional >>> access/CAC/accounting) in the framework draft is fine. >>> However, choosing a single deployment model, and adding >> message flows >>> for it in the framework draft, is not ideal. >>> Also, there were specific questions raised on the mailing >> list on some >>> of the suggestions in the draft (specifically pertaining to >> flow-group >>> optimization). We haven't seen any responses. >>> IMHO, we need to make progress on both these fronts (describing >>> alternate deployment model, and providing clarity on mechanisms >>> defined in draft-maglione) before we can make progress on adding >>> detailed message flows and corresponding protocol machinery to >>> framework and protocol drafts. >>> >>> Regards >>> -Sanjay >>> >>>> -----Original Message----- >>>> From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] >>>> Sent: Monday, September 03, 2007 8:39 AM >>>> To: ancp@ietf.org >>>> Subject: [ANCP] ANCP WG follow-up >>>> >>>> >>>> Hi All, >>>> >>>> At the recent IETF meeting we've heard a fair amount of debate >>>> regarding the subject of multicast. The debate spanned >>> multiple camps >>>> and went over both the whys, the why not's, as well as >> pros and cons. >>>> The general >>>> consensus formed at the meeting was that the framework and >>> requirements >>>> document needs to cover all use cases to the same level of >>> depth, and >>>> to have sufficient detail to design the protocol. This in >>> effect means >>>> the definition of the message primitives for supporting the >>>> use-case(s). >>>> We also heard there being significantly more support than not for >>>> introducing into the protocol the flexibility offered by the >>>> request-response message set as proposed in draft-maglione, >>> along with >>>> the use-cases. Hence, we would like to confirm the following >>> direction >>>> with the working group for carrying out the following two points: >>>> >>>> 1. Introduce into the latest draft-ietf-ancp-framework >>> changes and text >>>> that covers the following: >>>> - High level message diagram including query/response primitives >>>> - Description of the following multicast-use cases; >>>> * Multicast Conditional Access >>>> * Multicast Admission Control >>>> * Multicast Accounting >>>> * Multicast Termination >>>> >>>> Some solidification of the final text will be required and >> ought to >>>> take place on the alias. For the above however >>> draft-maglione appears >>>> to contain a fair base of the material required. >>>> >>>> 2. The WG commences work on defining the necessary protocol >>> extensions >>>> for inclusion in draft-ietf-ancp-protocol, based on the protocol >>>> specific text in draft-maglione. >>>> >>>> Regards, >>>> Woj and Matthew. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Sep 07 08:00:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITcVK-0007sF-BC; Fri, 07 Sep 2007 08:00:06 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1ITcVH-0007pz-0F for ancp-confirm+ok@megatron.ietf.org; Fri, 07 Sep 2007 08:00:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITcVC-0007pU-TW for ancp@ietf.org; Fri, 07 Sep 2007 07:59:58 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITcVB-0006zO-Fu for ancp@ietf.org; Fri, 07 Sep 2007 07:59:58 -0400 X-IronPort-AV: E=Sophos;i="4.20,220,1186351200"; d="scan'208,217";a="152496624" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Sep 2007 13:58:28 +0200 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 l87BwSrg027444; Fri, 7 Sep 2007 13:58:28 +0200 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 l87Bw8gl015109; Fri, 7 Sep 2007 11:58:28 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 13:58:22 +0200 Received: from [144.254.53.188] ([144.254.53.188]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 13:58:22 +0200 In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2803B76297@proton.jnpr.net> References: <9BD5D7887235424FA97DFC223CAE3C2803B76297@proton.jnpr.net> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <441751AB-C67D-4CF7-BACF-7A0310D37BA4@cisco.com> From: Francois Le Faucheur IMAP Subject: Admission Request message Re: [ANCP] Comments on draft-maglione Date: Fri, 7 Sep 2007 13:58:17 +0200 To: Sanjay Wadhwa X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 07 Sep 2007 11:58:22.0224 (UTC) FILETIME=[63793100:01C7F146] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4272; t=1189166308; x=1190030308; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Admission=20Request=20message=20Re=3A=20[ANCP]=20Comments=20o n=20draft-maglione |Sender:=20; bh=oxYsYJwaIwY/7CsLytTE4NibYY0TcD4+O+BSN4LBpGA=; b=bljRZJe3XUHnlj9wQqeVWupaQTxQaXQoiIKnUf7mL1wxVqAm5XhHW5IizGSIJRyVEd7yuvRX A5VtrlPsfLbMNTKWJjWuja19MfJBQAyPXi7qJ6pR5Gc0eyRvVKwaj1Dq; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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: , Content-Type: multipart/mixed; boundary="===============0543824383==" Errors-To: ancp-bounces@ietf.org --===============0543824383== Content-Type: multipart/alternative; boundary=Apple-Mail-18-405700217 --Apple-Mail-18-405700217 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Sanjay et al, > 4.2 Conditional access and admission control with NAS decision > It is not clear what information is required / envisaged for the > Admission Request / Response messages - > Multicast Flow and ACI at a minimum seems to be needed. The document lists the parameters for Admission Requests in the "Message Flows" section, but I agree that those need to be listed first in the "Protocol Requirements" sections. The parameters currently identified for Admission Request are: - Flow_Id - Port_Id Flow_Id = (S,G) or (*,G) Do you see other parameters that need to be added to Admission Request? The parameters currently identified for Admission Response are: - Accounting_Flag (which allows the NAS to tell AN if accounting is required for this flow). Do you see other parameters that need to be added to Admission Response? > It will be useful to clarify that the NAS is expected to know the > BW information for the multicast flow (flow-group) for which > admission control is being requested. Agreed. > This could be locally configured on the NAS, could be provided at > auth time from radius/policy server, or could be dynamically auto- > sensed (measured) on the NAS. Agreed. In the future it could also potentially be explicitely signaled by the source. Francois --Apple-Mail-18-405700217 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Sanjay et al,

=
4.2 Conditional access and admission = control with NAS decision
It is not clear what information is = required / envisaged for the Admission Request / Response messages - =
Multicast Flow and ACI at a minimum seems to be = needed.

The document lists the = parameters for Admission Requests in the "Message Flows" section, but I = agree that those need to be listed first in the "Protocol Requirements" = sections.

The = parameters currently identified for Admission Request = are:
= - Flow_Id
- Port_Id=A0
Flow_Id =3D = (S,G) or (*,G)
Do you see other parameters that need to be = added to Admission Request?

The parameters currently = identified for Admission Response are:
- = Accounting_Flag (which allows the NAS to tell AN if accounting is = required for this flow).
Do you see other parameters that need = to be added to Admission Response?

It will be useful to clarify that the NAS = is expected to know the BW information for the multicast flow = (flow-group) for which admission control is being requested. =

Agreed.

This could be locally configured on the = NAS, could be provided at auth time from radius/policy server, or could = be dynamically auto-sensed (measured) on the NAS.
=

Agreed. In=A0the future it could also = potentially be explicitely signaled by=A0the source.

Francois

=
= --Apple-Mail-18-405700217-- --===============0543824383== 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 --===============0543824383==-- From ancp-bounces@ietf.org Fri Sep 07 09:19:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdkA-00025k-MS; Fri, 07 Sep 2007 09:19:30 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1ITdk9-00025f-Nl for ancp-confirm+ok@megatron.ietf.org; Fri, 07 Sep 2007 09:19:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdk9-00025X-EB for ancp@ietf.org; Fri, 07 Sep 2007 09:19:29 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITdk7-0000NN-52 for ancp@ietf.org; Fri, 07 Sep 2007 09:19:28 -0400 X-IronPort-AV: E=Sophos;i="4.20,221,1186351200"; d="scan'208,217";a="152509796" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Sep 2007 15:19:26 +0200 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 l87DJQVd026163; Fri, 7 Sep 2007 15:19:26 +0200 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 l87DJKgX023812; Fri, 7 Sep 2007 13:19:20 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 15:19:20 +0200 Received: from [144.254.53.188] ([144.254.53.188]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 15:19:19 +0200 In-Reply-To: References: <8C253CB7-CF45-431D-94B6-4AC1A1653524@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <3D908F95-34E1-448C-900D-DE4C413994D8@cisco.com> From: Francois Le Faucheur IMAP Subject: Grey List & Default Behavior (was Re: [ANCP] Comments on draft-maglione) Date: Fri, 7 Sep 2007 15:19:13 +0200 To: Michel Platnic , Sanjay Wadhwa X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 07 Sep 2007 13:19:19.0212 (UTC) FILETIME=[B276BEC0:01C7F151] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=18874; t=1189171166; x=1190035166; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Grey=20List=20&=20Default=20Behavior=20(was=20Re=3A=20[ANCP]= 20Comments=20on=20draft-maglione) |Sender:=20; bh=z8nB+AqHxuOAboHmMkjqxYyT85rYiH09En9APxv67Is=; b=s1/QTAw0JOO+h42IFP8DXQSiZBFif/JAD92wotUtfo4UQm1bAQoHXc6sBe9CveGslUle5a2c wMchs/jcjMld3ESE4C7/Dz9XQe3XHJW/aOOYahP0h/alfbxJTTqXnjDN; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad Cc: angelo.garofalo@telecomitalia.it, 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: , Content-Type: multipart/mixed; boundary="===============1723053126==" Errors-To: ancp-bounces@ietf.org --===============1723053126== Content-Type: multipart/alternative; boundary=Apple-Mail-19-410556486 --Apple-Mail-19-410556486 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Michel, Sanjay and all, The current proposal can support a mode where any "multicast flow" is denied by AN unless it has been explicitly identified/provisioned before. However, there has been several comments on the list expressing security concern that this should not just be a possible behavior, but should also be the DEFAULT behavior. Sanjay also suggested that a Grey List may be useful. As mentioned in Chicago, Roberta's proposal initially had the Grey List. It was then taken out on the grounds that we could functionally achieve the same behavior with only Black/White List and making Grey List the default behavior. SInce the WG seems more comfortable with a default behavior of Black List (ie deny), the Grey List seems in order again. To address the range WG comments on this topic, we would like to propose the following updated proposal: * we have White, Black and Grey lists * each list contains zero, one or multiple entries * each entry may specify a single flow or contain ranges (ie mask on Group address and/or mask on Source address) * ANCP primitives allow BNG to add/remove/modify individual entries in each list * if a join is received by AN for a flow which is not in any of the three list, then it is rejected by AN (ie Default is reject) * the lists have a relative priority * by default relative priority is Black>Grey>White * this priority is reconfigurable (eg one could decide that White>Grey>Black) * if a join is received by AN for a flow which is in multiple lists, then AN applies behavior of highest priority list Example scenarios: Scenario 1: * no config: ==> any join gets rejected by AN Scenario 2: * White List = {Flow1,... FlowN} ==> Join (Flowi) gets honored by AN, ==> everything else gets rejected by AN Scenario 3: * White List = {Flow1,... FlowN} * Grey LIst= {(S=SpecialSource, G=*.*.*.*)} ==> Join (Flowi) gets honored by AN ==> Join (Flow from SpecialSource) triggers ANCP request to BNG ==> everything else gets rejected by AN Scenario 4: * Grey List= {(S=SpecialSource, G=*.*.*.*)} * White List = {(S=SpecialSource, G=SpecialGroup)} * White>Grey>Black ==> Join (Flow from Special Source to SpecialGroup) gets authorised by AN ==> Join (Flow from SpecialSource) triggers ANCP request to BNG ==> everything else gets rejected by AN Francois On 24 Jul 2007, at 20:22, Michel Platnic wrote: > >> 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? > > --Apple-Mail-19-410556486 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Michel, Sanjay and = all,

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

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

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

Example scenarios:

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

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

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

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


Francois

O= n 24 Jul 2007, at 20:22, Michel Platnic wrote:


<Michel>=A0Using access control capabilities within = the access network provides the two = main=A0following=A0benefits:
- = refrain from sending=A0any content to a customer=A0that was not paid for = (mostly relevant when Encryption is not used)
=
- provides a filter=A0against end-user = applications/hackers that may send IGMP requests with invalid IP = address
=A0
=
A solution where all the IP addresses that = are not part of either=A0the Black-list or=A0the=A0White-List are=A0sent = to a central policy server for authorization gives me some concerns = regarding the robustness of the whole system. Same concern regarding the = treatment of=A0unknown 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=A0the channels that have = been=A0explicitly allowed in=A0the 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:
=A0 =A0o=A0 an exact match for = a (*,G) ASM group (e.g. <G=3Dg.h.i.l>)
=A0 =A0o=A0 an = exact match for a (S,G) SSM channel (e.g. <S=3Ds.t.u.v,G=3Dg.h.i.l> =
=A0 =A0o=A0 a mask-based range match for a (*,G) ASM group = (e.g.
=A0 =A0 =A0 <G=3Dg.h.i.l/Mask>)
=A0 = =A0o=A0 a mask-based range match for a (S,G) SSM channel (e.g.
=
=A0 =A0 =A0 <S=3Ds.t.u.v/Mask,G=3Dg.h.i.l/Mask>
=
"
=A0<Michel> Let me try to rephrase = your proposal; there would be a default state wherein any channel being = neither part of White-list nor Black-list would be discarded. =
If its the case I agree with you that this solution solves = the security issue.
=A0
But what about when=A0AN is = not in this default state?
If "Accept everything else" is used = then again same problem of security is encountered, and any=A0hacker 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?
=A0
=
=A0
= --Apple-Mail-19-410556486-- --===============1723053126== 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 --===============1723053126==-- From ancp-bounces@ietf.org Mon Sep 10 08:55:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUinQ-0001KS-DO; Mon, 10 Sep 2007 08:55:20 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IUinP-0001KN-Iu for ancp-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 08:55:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUinP-0001JN-8e for ancp@ietf.org; Mon, 10 Sep 2007 08:55:19 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUinN-0004Ao-9n for ancp@ietf.org; Mon, 10 Sep 2007 08:55:19 -0400 X-IronPort-AV: E=Sophos;i="4.20,231,1186351200"; d="scan'208,217";a="152699349" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 10 Sep 2007 14:55:19 +0200 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 l8ACtGWm015415; Mon, 10 Sep 2007 14:55:16 +0200 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 l8ACtEEN017822; Mon, 10 Sep 2007 12:55:14 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 14:55:14 +0200 Received: from [144.254.53.188] ([144.254.53.188]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 14:55:13 +0200 In-Reply-To: <8022200B15317E4CBFEC624DCED654027EC5AB@FRVELSMBS11.ad2.ad.alcatel.com> References: <8022200B15317E4CBFEC624DCED654027EC5AB@FRVELSMBS11.ad2.ad.alcatel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Francois Le Faucheur IMAP Subject: Re: [ANCP] Working Group Last Call for draft-ietf-ancp-security-threats-02.txt Date: Mon, 10 Sep 2007 14:55:08 +0200 To: MOUSTAFA RD-CORE-ISS Hassnaa , Hannes Tschofenig , stefaan.de_cnodder@alcatel-lucent.be X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 Sep 2007 12:55:13.0403 (UTC) FILETIME=[D3EF0CB0:01C7F3A9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=22021; t=1189428916; x=1190292916; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[ANCP]=20Working=20Group=20Last=20Call=20for=20draft- ietf-ancp-security-threats-02.txt |Sender:=20; bh=tbjU6mNZDFSCfZr9ag+AU2U9Xu8vn0cML1Mymk3qhnE=; b=tWDhgJmnoa7Kgsb10rnGcw5XI6rnYjk4b3WzxZ2znqid80Uk1UXD8feAXCiCQk69EsmumnmD p1pGQIxOF6EX5CaSMw28KhnyywWTAtirpNE8cBsBhw/GuaHRqHdztoEp; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 2ce306e4307a2c0b518ae453b13efdd0 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: , Content-Type: multipart/mixed; boundary="===============2080771685==" Errors-To: ancp-bounces@ietf.org --===============2080771685== Content-Type: multipart/alternative; boundary=Apple-Mail-12-668311511 --Apple-Mail-12-668311511 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hassnaa, Hannes, Stefaan, Please find my review comments on draft-ietf-ancp-security- threats-02.txt. I tried split them into Substantial Comments, Editorial Comments and Typos. I hope these comments are useful. Francois 1 Substantial Comments =================== Section 1: Is there not a well-established generic categorisation of protocol security risks that could be applied here (or is this the generic categorization)? Section 7: In addition to discussing attacks against the 4 uses cases, I suspect there would be value in discussing attacks during the "Protocol establishment phase" (ie ANCP discovery phase, ANCP peering establishment, ANCP Capability negotiation ...), Could this be added? Does it lead to any additional security requirements specifically for the ANCP Discovery phase? or peering phase? section 7.4: There is an additional type of DOS attack that, I think, is not discussed in the current text. Since, in some mode of operation of ANCP for multicast, an IGMP join/leave received on AN validly triggers an ANCP message from AN to NAS, a HGW/CPE can effectively achieve a NAS DOS by generating heaps of IGMP join/leaves. I believe this is worth discussing separately because it cannot be addressed solely through security mechanisms inside the ANCP protocol. This risk is discussed in section "6. Security Considerations" of draft- maglione. Could the corresponding text describing the risk be incorporated here in section 7.4(with appropraite editing if needed)? Section "6. Security Considerations" of draft-maglione also recommends specific mitigation approaches for this ("To mitigate this risk,..."). Could this recommendation be added in section 8 of ancp- security? section 7.4: One of the functions that ANCP has to enable for multicast is accounting. So a specific additional risk associated with the multicast use cases is tempering with accounting information (eg escaping charging or conversely over-charging another user). Could you add a statement to that effect? For example, perhaps, at teh very end of section 7.4 we could add: " * Messages's modifications to temper with accounting information, for example in order to avoid service charges or conversely in order to artificially increase service charges on other users" section 8: Based on discussions on the list re multicast use case security aspects, I'd suggest adding requirements along the line of " o The protocol solution SHOULD ensure that, by default, IGMP join/leave requests received by AN are only relayed to NAS for those multicast flows that have been explicitly identified before by the NAS through ANCP" section 8: In case of DOS attacks on NAS as a result of IGMP leave/joins resulting in ANCP messages from AN to NAS, we would want the NAS to be able to stop ANCP messages generated by the AN. I would suggest adding a requirement along the lines of: " o The protocol solution MUST allow the NAS to instruct the AN to stop issuing ANCP messages to the NAS on join/leave (i) from a particular AN port , (ii) for a particular multicast flow (or ranges of multicast flows) or (iii) combination thereof." 2 Editorial Comments ================ Abstract: s/to configure and manage access equipments and allow them to report information to the NAS in order to enable and optimize configuration/ to allow the NAS to configure, manage and control access equipments, including the ability for the access nodes to report information to the NAS/ Section1, 2nd paragraph: s/This document/The present document/ Section 1: I don't quite get the exact meaning of the following sentence: " and ANCP should also provide such protection as a service to the different service parameters between the two peers." Is this saying that the protection should ensure protection of the various parameters manipulated inside the ANCP message? if yes, then I think this is already covered in previous sentence stating that the ANCP payload ought to be protected. If not, can you clarify what it means? Section 1: Current text says: " Prevention against Impersonation: It is important that signaling messages are delivered to the correct nodes, and nowhere else." The description doesn't quite match the title. The description sounds more like "mis-delivery of message". Perhaps it should say something like: " Prevention against Impersonation: It is important that protection be available against a device impersonating an ANCP node (i.e. an unauthorized device generating an ANCP message and pretending it was generated by a valid ANCP node) " Section 1: Current text says: "For the threat analysis, the protocol communication between the Access Node and the NAS is important whereas the other component, such as HGW, CPE, AAA server only play a role in the understanding of the system architecture. " Should this say something like: "For the threat analysis, this document focuses on the ANCP protocol communication between the Access Node and the NAS. However, communications with the other components, such as HGW, CPE, AAA server play a role in the understanding of the system architecture and of what triggers ANCP protocol communications." Section 4: "Also, through replaying old packets, of another privileged client for instance, an attacker can configure a better QoS profile on its own DSL line increasing its own benefit. " in previous sentence s/can/can attempt to/ Section 7: Current text says: "However, once the AAA server has the authorization data then it is given to the NAS, which is more in the scope of this work. " In previous sentence s/which is more/which is/ Section 7: Current text says: "Consequently, this document considers the attacks that are related to the ANCP operation and are concerning the communication between the NAS and the AAA/Policy server." I think you want to say that this document is concerned with the ANCP communications that result from communications between the NAS and AAA/Policy Server. But it is not directly considering "the attacks that ....are concerning the communication between teh NAS and the AAA/ Policy Server.". Right? Should this read: "Consequently, this document considers the attacks that are related to the ANCP operation associated with communication between the NAS and the AAA/Policy server." section 7.2: s/DoS attacks can take place by an attacker/DoS attacks of the AN can take place by an attacker/ section 7.4: s/this allows the NAS to follow subscribers' multicast (source, group) membership/this allows the NAS to follow subscribers' multicast (source, group) membership and control replication performed by the AN./ section 8: I don't fully understand how the following translates in terms of ANCP Security requirements: " o The protocol solution SHOULD distinguish the control messages from the data." Can you elaborate? section 9: s/presenting the security requirements to be considered/presenting the security requirements to be considered for design of the ANCP protocol/ 3 Typos ====== section 7.1: s/injecting falsify packets/injecting falsified packets/ section 7.3: s/carryout/carry out/ On 3 Sep 2007, at 16:00, BOCCI Matthew wrote: > > This email is to announce the start of a two week Working Group > last call for draft-ietf-ancp-security-threats-02.txt. > > Please read the draft and provide comments to the ANCP list by > Tuesday 11th September. > > As agreed during the Chicago meeting, the following participants > kingly volunteered to review the draft as a part of the WG LC: > > Curtis Sherbo > Phillipe Niger > Michael Busser > Francios LeFaucher > Raymond Zhang > > We would like to thank them in advance for their help. > > We will not be in a position to progress the draft until we have > received comments from at least five reviewers. > > Regards, > > Matthew & Woj > > ----------------------------------------- > Matthew Bocci > IP Division, > Alcatel-Lucent Telecom Limited, > Registered Office: Christchurch Way, Greenwich, London SE10 0AG. > Registered in England & Wales number 02650571 > ----------------------------------------- > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp --Apple-Mail-12-668311511 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Hassnaa, Hannes, = Stefaan,

Please= find my review comments = on=A0draft-ietf-ancp-security-threats-02.txt.
I tried split = them into Substantial Comments, Editorial Comments and = Typos.
I hope these comments are useful.

Francois


1 Substantial = Comments
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Section = 1:
Is there not a well-established generic categorisation of = protocol security risks that could be applied here (or is = this=A0the=A0generic=A0categorization)?

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

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

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

section 8:
Based = on discussions on=A0the=A0list re multicast use case security aspects, = I'd suggest adding requirements along the line of=A0
"=A0 =A0o = =A0 =A0The protocol solution SHOULD ensure that, by default, IGMP = join/leave requests received by AN are only relayed to NAS for those = multicast flows that have been=A0explicitly=A0identified=A0before by the = NAS through ANCP"

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



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

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

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

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

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

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

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

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

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

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

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

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



3 = Typos
=3D=3D=3D=3D=3D=3D

section = 7.1:
s/injecting falsify packets/injecting falsified = packets/

section = 7.3:
s/carryout/carry out/



On 3 Sep 2007, at = 16:00, BOCCI Matthew wrote:

=

This email is to announce = the start of a two week Working Group last call for draft-ietf-ancp-security-threats-02.txt. =

Please read the draft and = provide comments to the ANCP list by Tuesday 11th September. =

As agreed during the = Chicago meeting, the following participants kingly volunteered to review = the draft as a part of the WG LC:

Curtis Sherbo
Phillipe Niger
Michael = Busser
Francios LeFaucher
Raymond Zhang

We would like to thank them in advance = for their help.

We = will not be in a position to progress the draft until we have received = comments from at least five reviewers.

Regards, =

Matthew & Woj =

-----------------------------------------
Matthew Bocci =
IP Division, =
Alcatel-Lucent = Telecom Limited,
Registered Office: Christchurch Way, Greenwich, London = SE10 0AG.
Registered in England & Wales number 02650571 =
-----------------------------------------

ANCP mailing list

= --Apple-Mail-12-668311511-- --===============2080771685== 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 --===============2080771685==-- From ancp-bounces@ietf.org Tue Sep 11 09:41:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV5zC-0005q0-6S; Tue, 11 Sep 2007 09:41:02 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IV5zB-0005pu-Sx for ancp-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 09:41:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV5zB-0005pm-JM for ancp@ietf.org; Tue, 11 Sep 2007 09:41:01 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV5z9-00030n-QM for ancp@ietf.org; Tue, 11 Sep 2007 09:41:01 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Tue, 11 Sep 2007 15:40:57 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Sep 2007 15:40:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: AW: [ANCP] Working Group Last Call fordraft-ietf-ancp-security-threats-02.txt Date: Tue, 11 Sep 2007 15:40:53 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C1065CD@S4DE8PSAANK.mitte.t-com.de> In-reply-to: <8022200B15317E4CBFEC624DCED654027EC5AB@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Working Group Last Call fordraft-ietf-ancp-security-threats-02.txt Thread-Index: AcfuMsFAUilnMmtMQbm1iHfdvUDDLwGPgu0A From: "Busser, M" To: , , X-OriginalArrivalTime: 11 Sep 2007 13:40:56.0012 (UTC) FILETIME=[6111B8C0:01C7F479] X-Spam-Score: -1.0 (-) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 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: , Content-Type: multipart/mixed; boundary="===============0304096936==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0304096936== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F479.5FDE1973" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F479.5FDE1973 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Hassnaa, Hannes and Stefaan. =20 After reviewing the draft, i have the following comment: =20 Section 7: Do we have some additional security requirements, when taking the = "protocol setup phase" into account (beside the 4 use cases)? =20 =20 Best Regards; Freundliche Gr=FC=DFe=20 Michael Busser T-Systems Enterprise Services GmbH=20 Production Line Network Centric Systems ICT-Systems Integration Network Integration Services =20 Br=FCckes 2 -8, 55545 Bad Kreuznach Postfach 9100, 55541 Bad Kreuznach +49 671 8333 8911 (Phone) +49 521 9210 3859 (Fax) +49 151 1211 9689 (Mobile) E-Mail: michael.busser@t-systems.com Internet: http://www.t-systems.com=20 =20 =20 T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Helmut Binder, Albert Henn, Olaf Heyden*, Katrin = Horstmann, Ulrich Kemp, Wilfried Peters*,=20 Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG=20 Notice: This transmittal and/or attachments may be privileged or = confidential. If you are not the intended recipient, you are hereby = notified that you have received this transmittal in error; any review, = dissemination, or copying is strictly prohibited. If you received this = transmittal in error, please notify us immediately by reply and = immediately delete this message and all its attachments. Thank you.=20 T-Systems - Business flexibility=20 =20 -----Urspr=FCngliche Nachricht----- Von: BOCCI Matthew [mailto:Matthew.Bocci@alcatel-lucent.co.uk]=20 Gesendet: Montag, 3. September 2007 16:00 An: ancp@ietf.org Betreff: [ANCP] Working Group Last Call = fordraft-ietf-ancp-security-threats-02.txt This email is to announce the start of a two week Working Group last = call for draft-ietf-ancp-security-threats-02.txt.=20 Please read the draft and provide comments to the ANCP list by Tuesday = 11th September.=20 As agreed during the Chicago meeting, the following participants kingly = volunteered to review the draft as a part of the WG LC: Curtis Sherbo Phillipe Niger Michael Busser Francios LeFaucher Raymond Zhang=20 We would like to thank them in advance for their help.=20 We will not be in a position to progress the draft until we have = received comments from at least five reviewers.=20 Regards,=20 Matthew & Woj=20 -----------------------------------------=20 Matthew Bocci=20 IP Division,=20 Alcatel-Lucent Telecom Limited,=20 Registered Office: Christchurch Way, Greenwich, London SE10 0AG.=20 Registered in England & Wales number 02650571=20 -----------------------------------------=20 ------_=_NextPart_001_01C7F479.5FDE1973 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nachricht
Hi=20 Hassnaa, Hannes and Stefaan.
 
After=20 reviewing the draft, i have the following comment:
 
Section 7:
Do we=20 have some additional security requirements, when taking the = "protocol setup=20 phase" into account (beside the 4 use cases)?
 
 

Best Regards; Freundliche Gr=FC=DFe

Michael Busser
T-Systems=20 Enterprise Services GmbH
Production Line Network Centric Systems
ICT-Systems Integration
Network Integration Services
 
Br=FCckes 2 -8,=20 55545 Bad Kreuznach
Postfach 9100, 55541 Bad Kreuznach
+49 671 = 8333 8911=20 (Phone)
+49 521 9210 3859 (Fax)
+49 151 1211 9689=20 (Mobile)
E-Mail: michael.busser@t-systems.com=
Internet:=20 http://www.t-systems.com
 
 =20
T-Systems Enterprise Services=20 GmbH
Aufsichtsrat: Ren=E9 Obermann (Vorsitzender)
Executive = Committee:=20 Helmut Binder, Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, = Wilfried Peters*,
Dr. Herbert Schaaff*, Zvezdana = Seeger*
Handelsregister:=20 Amtsgericht Frankfurt am Main HRB 55933
Sitz der Gesellschaft: = Frankfurt am=20 Main
WEEE-Reg.-Nr. DE87523644
*Gesch=E4ftsf=FChrer gem. =A7 35 = GmbHG=20

Notice: This transmittal and/or attachments may be = privileged or=20 confidential. If you are not the intended recipient, you are hereby = notified=20 that you have received this transmittal in error; any review, = dissemination, or=20 copying is strictly prohibited. If you received this transmittal in = error,=20 please notify us immediately by reply and immediately delete this = message and=20 all its attachments. Thank you.
T-Systems = – Business=20 flexibility

 
-----Urspr=FCngliche Nachricht-----
Von: BOCCI = Matthew=20 [mailto:Matthew.Bocci@alcatel-lucent.co.uk]
Gesendet: = Montag, 3.=20 September 2007 16:00
An: ancp@ietf.org
Betreff: = [ANCP]=20 Working Group Last Call=20 fordraft-ietf-ancp-security-threats-02.txt


This email is to announce the = start of a=20 two week Working Group last call for draft-ietf-ancp-security-threats-02.txt.

Please read the draft and = provide comments=20 to the ANCP list by Tuesday 11th September.

As agreed during the Chicago = meeting, the=20 following participants kingly volunteered to review the draft as a = part of the=20 WG LC:

Curtis Sherbo
Phillipe = Niger
Michael=20 Busser
Francios LeFaucher
Raymond Zhang

We would like to thank them in = advance for=20 their help.

We will not be in a position to = progress=20 the draft until we have received comments from at least five=20 reviewers.

Regards,

Matthew & Woj

-----------------------------------------
Matthew Bocci
IP Division,
Alcatel-Lucent Telecom Limited,
Registered Office: Christchurch Way, = Greenwich, London=20 SE10 0AG.
Registered in=20 England & Wales number 02650571
-----------------------------------------=20

------_=_NextPart_001_01C7F479.5FDE1973-- --===============0304096936== 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 --===============0304096936==-- From ancp-bounces@ietf.org Wed Sep 12 05:27:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVOV8-0000Gf-UV; Wed, 12 Sep 2007 05:27:14 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IVOV7-0000Ga-H5 for ancp-confirm+ok@megatron.ietf.org; Wed, 12 Sep 2007 05:27:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVOV3-0000Fy-5Z for ancp@ietf.org; Wed, 12 Sep 2007 05:27:09 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVOV1-0006LD-7M for ancp@ietf.org; Wed, 12 Sep 2007 05:27:09 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Sep 2007 11:27:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] Working Group Last Call fordraft-ietf-ancp-security-threats-02.txt Date: Wed, 12 Sep 2007 11:27:00 +0200 Message-ID: In-Reply-To: <8022200B15317E4CBFEC624DCED654027EC5AB@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Working Group Last Call fordraft-ietf-ancp-security-threats-02.txt thread-index: AcfuMsFAUilnMmtMQbm1iHfdvUDDLwG7Ct3w References: <8022200B15317E4CBFEC624DCED654027EC5AB@FRVELSMBS11.ad2.ad.alcatel.com> From: "NIGER Philippe RD-RESA-LAN" To: X-OriginalArrivalTime: 12 Sep 2007 09:27:00.0998 (UTC) FILETIME=[12B4D260:01C7F51F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 94ddbad0060c343c23e74ba9bbebbccf 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="===============0063875528==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0063875528== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F51F.126445EF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F51F.126445EF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, =20 After reviewing the draft, please find my comments below. =20 =20 Regards, =20 Philippe Niger. =20 ------------------------------------------------------------------ =20 No major comments. =20 Important comments. - In the section 3 it is indicated that "the NAS and AN might belong to = two different administrative realms". It could be useful to indicate = here if the threat model and the derived requirements apply also in that = configuration or are limited to a configuration in which the NAS and the = AN belong to the same administrative entitiy. - At the end of the first paragraph of section 7 it is indicated that = "this document considers the attacks that are related to the ANCP = operation and are concerning the communication between the NAS and the = AAA/Policy server". As ANCP is running between the AN and the NAS this = sentence should be clarified (e.g. indicating that the data targeted by = the attacks are those exchanged between the NAS and the AAA server and = the derived security requirements applied when these data are = transported over ANCP between the AN and the NAS). =20 Minor comments (editorial). -0- Abstract : The Access Node Control Protocol (ANCP) aims to communicate QoS-, = service- and subscriber-related configurations...=20 Change to : The Access Node Control Protocol (ANCP) aims to communicate = QoS-[related], service-[related] and subscriber-related = configurations...=20 -1- Introduction : Same change as described above. =20 -2- Terminology This section should be renamed as "Specification of requirements" and = moved before the "Introduction" section. =20 -3- Systeme Overview and Threat Model =20 - Home Gateway (HGW): The HGW connects the different Customer Premises = Equipment (CPE)...=20 Change to : Home Gateway (HGW): The HGW connects the different Customer = Premises Equipment [s] (CPE)...=20 =20 - Aggregation Network: The aggregation network provides traffic = aggregation from multiple ANs towards the NAS. ATM or Ethernet = technologies can be used.=20 Change to : Aggregation Network: The aggregation network provides = traffic aggregation from multiple ANs towards the NAS. ATM or Ethernet = [transport] technologies can be used.=20 =20 - Attackers can be: o off-path, i.e., it cannot see packets between the = AN and the NAS; o on-path, i.e., they can see the message exchange = between the AN and the NAS.=20 Change to : Attackers can be: o off-path, i.e., [they] cannot see = packets between the AN and the NAS; o on-path, i.e., they can see the = message exchange[s] between the AN and the NAS.=20 =20 - Both off-path and on-path attackers can be: o passive, i.e., they do = not participate in the network but rather listen to all transfer to = obtain the maximum possible information; o active, i.e., they = participate to the network and can inject falsify packets.=20 Change to : Both off-path and on-path attackers can be: o passive, i.e., = they do not participate in the network [operation] but rather listen to = all transfer[s] to obtain the maximum possible information; o active, = i.e., they participate to the network [operation] and can inject = falsif[ied] packets.=20 =20 -5- Potential Attacks - paragraph 5.1 : ... is a chance to mount denial of services attacks... Change to : ...is a chance to mount denial of service[] attacks... - paragraph 5.3 : An insecure parameter exchange or security negotiation = protocol can help an adversary to mount a downgrading attack... Change to : An insecure parameter exchange or security negotiation = protocol can [give the opportunity to] an adversary to mount a = downgrading attack... - paragraph 5.4 : ...capturing all traversed packets Change to : ...capturing all [traversing] packets - paragraph 5.4 : ...containing some information related to the = connected client, indicating the client's existing at home.=20 Change to : ...containing some information related to the connected = client []. Or clarify the end of the sentence [indicating the client's = existing at home]. =20 -6- Attacks Forms - title : Attacks Forms Change to : Attack[] Forms. - Through replaying of signaling messages, an adversary might mount a = denial of service and theft of service attacks. Change to : Through replaying of signaling messages, an adversary might = mount a denial of service and [a] theft of service attacks. - This could be at the signaling protocol level, at the level of a = specific signaling parameters (e.g., QoS information), or the transport = layer. An adversary might, for example, inject signaling message...=20 Change to : This could be [achieved] at the signaling protocol level, at = the level of a specific signaling parameters (e.g., QoS information), or = [at] the transport layer. An adversary might, for example, inject [a] = signaling message... - ... reordering and delaying of messages causing a protocol's process = failures.=20 Change to : ...reordering and delaying of messages causing a protocol's = process failure[].=20 - In this case the protocol could appear to continue correctly.=20 Change to : In this case the protocol could appear to continue [working] = correctly.=20 =20 -7- Attacks against ANCP Defined Use Cases - ... concerning how the user gets authenticated and how the AAA server = gets... Change to : ...concerning how the user [are] authenticated and how the = AAA server gets... - paragraph 7.1 : Active, acting on the transferred attributes and = injecting falsify packets. Change to : Active, acting on the transferred attributes and injecting = falsif[ied] packets. - paragraph 7.1 : Passive gaining information of the access loop = attributes. Change to : Passive gaining information [on] the access loop attributes. - paragraph 7.3 : Most of the attacks in this use case concern the = network functionality. Change to : Most of the attacks in this use case concern the network = [operation]. - paragraph 7.3 : ...where an adversary can inject falsify signals or = can truncate the triggering. Change to : where an adversary can inject falsif[ied] signals or can = truncate the triggering =20 -11- IANA Considerations This section should be moved before the "Acknowledgments" section. -12- References The reference to the Framework document should be updated (version -02). =20 ________________________________ De : BOCCI Matthew [mailto:Matthew.Bocci@alcatel-lucent.co.uk]=20 Envoy=E9 : lundi 3 septembre 2007 16:00 =C0 : ancp@ietf.org Objet : [ANCP] Working Group Last Call = fordraft-ietf-ancp-security-threats-02.txt This email is to announce the start of a two week Working Group last = call for draft-ietf-ancp-security-threats-02.txt.=20 Please read the draft and provide comments to the ANCP list by Tuesday = 11th September.=20 As agreed during the Chicago meeting, the following participants kingly = volunteered to review the draft as a part of the WG LC: Curtis Sherbo Phillipe Niger Michael Busser Francios LeFaucher Raymond Zhang=20 We would like to thank them in advance for their help.=20 We will not be in a position to progress the draft until we have = received comments from at least five reviewers.=20 Regards,=20 Matthew & Woj=20 -----------------------------------------=20 Matthew Bocci=20 IP Division,=20 Alcatel-Lucent Telecom Limited,=20 Registered Office: Christchurch Way, Greenwich, London SE10 0AG.=20 Registered in England & Wales number 02650571=20 -----------------------------------------=20 ------_=_NextPart_001_01C7F51F.126445EF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Working Group Last Call for = draft-ietf-ancp-security-threats-02.txt
Hi All,
 
After = reviewing the=20 draft, please find my comments=20 below.
 
 
Regards,
 
Philippe Niger.
 
----------------------------------------------= --------------------
 

No major comments.

 

Important comments.

- In the section 3 it is indicated that "the = NAS and AN=20 might belong to two different administrative realms". It could be useful = to=20 indicate here if the threat model and the derived requirements apply = also in=20 that configuration or are limited to a configuration in which the NAS = and the AN=20 belong to the same administrative entitiy.

- At the end of the first paragraph of section = 7 it is=20 indicated that "this document considers the attacks that are related to the = ANCP=20 operation and are concerning the communication between the NAS and the=20 AAA/Policy server". As ANCP is running between the AN and the NAS this = sentence=20 should be clarified (e.g. indicating that the data targeted by the = attacks are=20 those exchanged between the NAS and the AAA server and the derived = security=20 requirements applied when these data are transported over ANCP between = the AN=20 and the NAS).

 

Minor comments (editorial).

-0- Abstract :

The Access Node Control Protocol (ANCP) aims to communicate QoS-, = service-=20 and subscriber-related configurations...

Change to : The Access Node = Control=20 Protocol (ANCP) aims to communicate QoS-[related], service-[related] and = subscriber-related configurations...

-1- Introduction :

Same change as described above.

 

-2- Terminology

This section should be renamed as = "Specification of=20 requirements" and moved before the "Introduction" section.

 

-3- Systeme Overview and Threat = Model

 

- Home Gateway (HGW): The HGW connects the different Customer = Premises=20 Equipment (CPE)...

Change to : Home Gateway = (HGW): The HGW=20 connects the different Customer Premises Equipment [s] (CPE)...=20

 

- Aggregation Network: The aggregation network provides traffic = aggregation=20 from multiple ANs towards the NAS. ATM or Ethernet technologies can be = used.=20

Change to : Aggregation = Network: The=20 aggregation network provides traffic aggregation from multiple ANs = towards the=20 NAS. ATM or Ethernet [transport] technologies can be used. =

 

- Attackers can be: o off-path, i.e., it cannot see packets between = the AN=20 and the NAS; o on-path, i.e., they can see the message exchange between = the AN=20 and the NAS.

Change to : Attackers can = be: o off-path,=20 i.e., [they] cannot see packets between the AN and the NAS; o on-path, = i.e.,=20 they can see the message exchange[s] between the AN and the NAS.=20

 

- Both off-path and on-path attackers can be: o passive, i.e., they = do not=20 participate in the network but rather listen to all transfer to obtain = the=20 maximum possible information; o active, i.e., they participate to the = network=20 and can inject falsify packets.

Change to : Both off-path = and on-path=20 attackers can be: o passive, i.e., they do not participate in the = network=20 [operation] but rather listen to all transfer[s] to obtain the maximum = possible=20 information; o active, i.e., they participate to the network [operation] = and can=20 inject falsif[ied] packets.

 

-5- Potential Attacks

- paragraph 5.1 : =85 is a chance to mount = denial of=20 services attacks...

Change to : ...is a chance to mount denial of = service[]=20 attacks...

- paragraph 5.3 : An insecure parameter = exchange or=20 security negotiation protocol can help an adversary to mount a = downgrading=20 attack=85

Change to : An insecure parameter exchange or = security=20 negotiation protocol can [give the opportunity to] an adversary to mount = a=20 downgrading attack...

- paragraph 5.4 : =85capturing all traversed=20 packets

Change to : ...capturing all [traversing]=20 packets

- paragraph 5.4 : ...containing some = information related=20 to the connected client, indicating the client's existing at home. =

Change to : ...containing some information = related to the=20 connected client []. Or clarify the end of the sentence [indicating the = client's=20 existing at home].

 

-6- Attacks Forms

- title : Attacks Forms

Change to : Attack[] Forms.

- Through replaying of signaling messages, an = adversary=20 might mount a denial of service and theft of service attacks.

Change to : Through replaying of signaling = messages, an=20 adversary might mount a denial of service and [a] theft of service=20 attacks.

- This could be at the signaling protocol = level, at the=20 level of a specific signaling parameters (e.g., QoS information), or the = transport layer. An adversary might, for example, inject signaling = message...=20

Change to : This could be [achieved] at the = signaling=20 protocol level, at the level of a specific signaling parameters (e.g., = QoS=20 information), or [at] the transport layer. An adversary might, for = example,=20 inject [a] signaling message=85

- =85 reordering and delaying of messages = causing a=20 protocol's process failures.

Change to : ...reordering and delaying of = messages=20 causing a protocol's process failure[].

- In this case the protocol could appear to = continue=20 correctly.

Change to : In this case the protocol could = appear to=20 continue [working] correctly.

 

-7- Attacks against ANCP Defined Use = Cases

- =85 concerning how the user gets = authenticated and how=20 the AAA server gets=85

Change to : ...concerning how the user [are]=20 authenticated and how the AAA server gets=85

- paragraph 7.1 : Active, acting on the = transferred=20 attributes and injecting falsify packets.

Change to : Active, acting on the transferred = attributes=20 and injecting falsif[ied] packets.

- paragraph 7.1 : Passive gaining information = of the=20 access loop attributes.

Change to : Passive gaining information [on] = the access=20 loop attributes.

- paragraph 7.3 : Most of the attacks in this = use case=20 concern the network functionality.

Change to : Most of the attacks in this use = case concern=20 the network [operation].

- paragraph 7.3 : ...where an adversary can = inject=20 falsify signals or can truncate the triggering.

Change to : where an adversary can inject = falsif[ied]=20 signals or can truncate the triggering

 

-11- IANA Considerations

This section should be moved before the = "Acknowledgments"=20 section.

-12- References

The reference to the Framework document should = be updated=20 (version -02).

 

De : BOCCI Matthew=20 [mailto:Matthew.Bocci@alcatel-lucent.co.uk]
Envoy=E9 : = lundi 3=20 septembre 2007 16:00
=C0 : = ancp@ietf.org
Objet :=20 [ANCP] Working Group Last Call=20 fordraft-ietf-ancp-security-threats-02.txt


This email is to announce the = start of a two=20 week Working Group last call for draft-ietf-ancp-security-threats-02.txt.

Please read the draft and provide = comments to=20 the ANCP list by Tuesday 11th September.

As agreed during the Chicago = meeting, the=20 following participants kingly volunteered to review the draft as a part = of the=20 WG LC:

Curtis Sherbo
Phillipe = Niger
Michael=20 Busser
Francios LeFaucher
Raymond Zhang

We would like to thank them in = advance for=20 their help.

We will not be in a position to = progress the=20 draft until we have received comments from at least five = reviewers.

Regards,

Matthew & Woj

-----------------------------------------
Matthew Bocci
IP Division,
Alcatel-Lucent Telecom Limited,
Registered Office: Christchurch Way, Greenwich, London SE10 = 0AG.=20
Registered in = England &=20 Wales number 02650571
----------------------------------------- =

------_=_NextPart_001_01C7F51F.126445EF-- --===============0063875528== 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 --===============0063875528==-- From ancp-bounces@ietf.org Wed Sep 12 14:09:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVWeq-0005lQ-SO; Wed, 12 Sep 2007 14:09:48 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IVWep-0005lL-Pd for ancp-confirm+ok@megatron.ietf.org; Wed, 12 Sep 2007 14:09:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVWep-0005lC-Fd for ancp@ietf.org; Wed, 12 Sep 2007 14:09:47 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVWen-00066b-TH for ancp@ietf.org; Wed, 12 Sep 2007 14:09:47 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 5FFC93BCC1C; Wed, 12 Sep 2007 11:09:45 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23402-02; Wed, 12 Sep 2007 11:09:45 -0700 (PDT) Received: from CSHERBOTM5XP (dhcp-36-36.van.redback.com [172.19.36.36]) by prattle.redback.com (Postfix) with ESMTP id 12AC03BCC19; Wed, 12 Sep 2007 11:09:45 -0700 (PDT) From: "Curtis Sherbo" To: "'BOCCI Matthew'" , Subject: RE: [ANCP] Working Group Last Call fordraft-ietf-ancp-security-threats-02.txt Date: Wed, 12 Sep 2007 11:09:41 -0700 Message-ID: <004c01c7f568$17568ae0$242413ac@ad.redback.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 thread-index: AcfuMsFAUilnMmtMQbm1iHfdvUDDLwHNJdbw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <8022200B15317E4CBFEC624DCED654027EC5AB@FRVELSMBS11.ad2.ad.alcatel.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 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="===============0112230550==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0112230550== Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01C7F52D.6AF7B2E0" This is a multi-part message in MIME format. ------=_NextPart_000_004D_01C7F52D.6AF7B2E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have reviewed the draft and have the following editorial comments: 5.4. Traffic Analysis An adversary can be placed at the NAS, or the AN, or any other network element capturing all traversed packets. Adversaries can Internet-Draft ANCP Threats July 2007 thus have unauthorized information access. As well, they can gather information relevant to the network and then use this information in gaining later unauthorized access. This attack can also help adversaries in other malicious purposes, as for example capturing messages sent from the AN to the NAS announcing that a DSL line is up and containing some information related to the connected client, indicating the client's existing at home. <<--- Don't know what this means? 6. Attacks Forms Should Read Attack Forms The text in read perhaps would read better if it said "which is in scope of this work". 7.However, once the AAA server has the authorization data then it is given to the NAS, which is more in the scope of this work. Consequently, this document considers the attacks that are related to the ANCP operation and are concerning the communication between the NAS and the AAA/Policy server. 7.1 Active, acting on the transferred attributes and injecting falsify packets. The main attacks here are: Should perhaps be falsified Curtis Sherbo _____ From: BOCCI Matthew [mailto:Matthew.Bocci@alcatel-lucent.co.uk] Sent: Monday, September 03, 2007 7:00 AM To: ancp@ietf.org Subject: [ANCP] Working Group Last Call fordraft-ietf-ancp-security-threats-02.txt This email is to announce the start of a two week Working Group last call for draft-ietf-ancp-security-threats-02.txt. Please read the draft and provide comments to the ANCP list by Tuesday 11th September. As agreed during the Chicago meeting, the following participants kingly volunteered to review the draft as a part of the WG LC: Curtis Sherbo Phillipe Niger Michael Busser Francios LeFaucher Raymond Zhang We would like to thank them in advance for their help. We will not be in a position to progress the draft until we have received comments from at least five reviewers. Regards, Matthew & Woj ----------------------------------------- Matthew Bocci IP Division, Alcatel-Lucent Telecom Limited, Registered Office: Christchurch Way, Greenwich, London SE10 0AG. Registered in England & Wales number 02650571 ----------------------------------------- ------=_NextPart_000_004D_01C7F52D.6AF7B2E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Working Group Last Call for = draft-ietf-ancp-security-threats-02.txt

I have reviewed the draft and have the = following=20 editorial comments:

5.4. Traffic Analysis An adversary can be = placed at=20 the NAS, or the AN, or any other network element capturing all traversed = packets. Adversaries can

Internet-Draft ANCP Threats July = 2007 thus have=20 unauthorized information access. As well, they can gather information = relevant=20 to the network and then use this information in gaining later = unauthorized=20 access. This attack can also help adversaries in other malicious = purposes, as=20 for example capturing messages sent from the AN to the NAS announcing = that a DSL=20 line is up and containing some information related to the connected = client,=20 indicating the client's existing=20 at home. <<--- Don't know what this=20 means?

6. Attacks Forms

Should Read Attack Forms

The text in read perhaps would read better if = it said=20 "which is in scope of this work".

7.However, once the AAA server has the = authorization=20 data then it is given to the NAS, which is more in = the scope=20 of this work. Consequently, this document considers the attacks = that are=20 related to the ANCP operation and are concerning the communication = between the=20 NAS and the AAA/Policy server.

7.1=20 Active, acting on the transferred attributes and injecting = falsify=20 packets. The main attacks here are:

Should perhaps be falsified

 

Curtis Sherbo 

 

From: BOCCI Matthew=20 [mailto:Matthew.Bocci@alcatel-lucent.co.uk]
Sent: Monday, = September=20 03, 2007 7:00 AM
To: ancp@ietf.org
Subject: [ANCP] = Working=20 Group Last Call=20 fordraft-ietf-ancp-security-threats-02.txt


This email is to announce the = start of a two=20 week Working Group last call for draft-ietf-ancp-security-threats-02.txt.

Please read the draft and provide = comments to=20 the ANCP list by Tuesday 11th September.

As agreed during the Chicago = meeting, the=20 following participants kingly volunteered to review the draft as a part = of the=20 WG LC:

Curtis Sherbo
Phillipe = Niger
Michael=20 Busser
Francios LeFaucher
Raymond Zhang

We would like to thank them in = advance for=20 their help.

We will not be in a position to = progress the=20 draft until we have received comments from at least five = reviewers.

Regards,

Matthew & Woj

-----------------------------------------
Matthew Bocci
IP Division,
Alcatel-Lucent Telecom Limited,
Registered Office: Christchurch Way, Greenwich, London SE10 = 0AG.=20
Registered in = England &=20 Wales number 02650571
----------------------------------------- =

------=_NextPart_000_004D_01C7F52D.6AF7B2E0-- --===============0112230550== 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 --===============0112230550==-- From ancp-bounces@ietf.org Mon Sep 17 04:31:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXC1A-0006ez-4k; Mon, 17 Sep 2007 04:31:44 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IXC19-0006WK-8h for ancp-confirm+ok@megatron.ietf.org; Mon, 17 Sep 2007 04:31:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXC18-0006TR-Qt for ancp@ietf.org; Mon, 17 Sep 2007 04:31:42 -0400 Received: from rv-out-0910.google.com ([209.85.198.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXC16-0004LA-Vs for ancp@ietf.org; Mon, 17 Sep 2007 04:31:42 -0400 Received: by rv-out-0910.google.com with SMTP id l15so1246870rvb for ; Mon, 17 Sep 2007 01:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=Th1M84FOW0eRQWt7katGZ/AHoaUZlKEZkjGjFDjJGXw=; b=DP3832eI325LbVggvCzLCRd3Djr712BXi7Z/vDdT7Z+l73Y7WMQCBI7JUPfQ1o+tWuSjqlEw7a1jZPpSqw0W2pWYtQ7vpwqgzNCcQ67IzIHbe0b0oRS8h5y7gTqiaflBqNb7GrFvd2f59drM6DGtMgOyN2woBUSUwynGvZg3SHs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ieBTwAJfROv556qPJXvZJ8pSgJ3eBwkytV3IbO4Xdp64Vm7ynnjv9iILgIH/2CIEMkc15K9fXFP38tXcryMOnH1sU4RwPZFhEhBL651PULLoj2At5ot/EexSjol7PHXnE264zvnZ3PkdhcbQAbG68+cNt1wIvX92t8DoMT0t2mA= Received: by 10.141.21.19 with SMTP id y19mr753014rvi.1190017900140; Mon, 17 Sep 2007 01:31:40 -0700 (PDT) Received: by 10.141.68.16 with HTTP; Mon, 17 Sep 2007 01:31:40 -0700 (PDT) Message-ID: Date: Mon, 17 Sep 2007 10:31:40 +0200 From: "Hasnaa Moustafa" To: "Francois Le Faucheur IMAP" , ancp@ietf.org In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93ea548d5fde6eb89af31f1faab96344 Cc: Hannes.Tschofenig@nsn.com, hassnaa.moustafa@orange-ftgroup.com Subject: [ANCP] Re: ANCP Digest, Vol 16, Issue 6 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="===============1569600856==" Errors-To: ancp-bounces@ietf.org --===============1569600856== Content-Type: multipart/alternative; boundary="----=_Part_3203_17860018.1190017900139" ------=_Part_3203_17860018.1190017900139 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear Francois, Thanks a lot for reviewing the draft and for all these detailed comments. Please find our comments below. Thanks again. Best Regards, Hassnaa > Message: 1 > Date: Mon, 10 Sep 2007 14:55:08 +0200 > From: Francois Le Faucheur IMAP > Subject: Re: [ANCP] Working Group Last Call for > draft-ietf-ancp-security-threats-02.txt > To: MOUSTAFA RD-CORE-ISS Hassnaa > , Hannes Tschofenig > , > stefaan.de_cnodder@alcatel-lucent.be > Cc: ancp@ietf.org > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > Hassnaa, Hannes, Stefaan, > > Please find my review comments on draft-ietf-ancp-security- > threats-02.txt. > I tried split them into Substantial Comments, Editorial Comments and > Typos. > I hope these comments are useful. > > Francois > > > 1 Substantial Comments > =================== > > Section 1: > Is there not a well-established generic categorisation of protocol > security risks that could be applied here (or is this the generic > categorization)? No there is not. This is in RFC 3365 as referenced in the draft. Section 7: > In addition to discussing attacks against the 4 uses cases, I suspect > there would be value in discussing attacks during the "Protocol > establishment phase" (ie ANCP discovery phase, ANCP peering > establishment, ANCP Capability negotiation ...), Could this be added? > Does it lead to any additional security requirements specifically for > the ANCP Discovery phase? or peering phase? In fact, the setup phase is among the protocol details, which will change nothing in the requirements. The draft could mention something about "initiating the ANCP communication". This is already in the draft, but maybe should be made more clear. > section 7.4: > There is an additional type of DOS attack that, I think, is not > discussed in the current text. Since, in some mode of operation of > ANCP for multicast, an IGMP join/leave received on AN validly > triggers an ANCP message from AN to NAS, a HGW/CPE can effectively > achieve a NAS DOS by generating heaps of IGMP join/leaves. I believe > this is worth discussing separately because it cannot be addressed > solely through security mechanisms inside the ANCP protocol. This > risk is discussed in section "6. Security Considerations" of draft- > maglione. Could the corresponding text describing the risk be > incorporated here in section 7.4(with appropraite editing if needed)? The mentioned risk is not clear for me, I could not understand if the risk is DoS or anything else, as the section firstly discusses DoS then mentions the risk. Section "6. Security Considerations" of draft-maglione also > recommends specific mitigation approaches for this ("To mitigate this > risk,..."). Could this recommendation be added in section 8 of ancp- > security? The cited recommendations go into solutions details, which is not our objective in Section 8 in our draft (which only gives requirements). Indeed, overload is something that is not handled in the draft, but is concerning the scalability of the protocol solution (so not the scope of the security draft). In any case, it is a good idea to add something about overload/scalability to the draft without specifying where it could come from. section 7.4: > One of the functions that ANCP has to enable for multicast is > accounting. So a specific additional risk associated with the > multicast use cases is tempering with accounting information (eg > escaping charging or conversely over-charging another user). > Could you add a statement to that effect? For example, perhaps, at > teh very end of section 7.4 we could add: > " * Messages's modifications to temper with accounting > information, > for example in order to avoid service charges or conversely in order > to artificially increase service charges on other users" In this case, we handle the security of the "information" sent between the AN and the NAS without further detailing what this information is, which can be accounting information (so in fact, it is covered in the draft). But something may be mentioned saying that "since this information can be used for accounting, it is possible to have attacks". section 8: > Based on discussions on the list re multicast use case security > aspects, I'd suggest adding requirements along the line of > " o The protocol solution SHOULD ensure that, by default, IGMP > join/leave requests received by AN are only relayed to NAS for those > multicast flows that have been explicitly identified before by the > NAS through ANCP" Actually, this is a solution for multicast. There are other solutions where this is not relevant. section 8: > In case of DOS attacks on NAS as a result of IGMP leave/joins > resulting in ANCP messages from AN to NAS, we would want the NAS to > be able to stop ANCP messages generated by the AN. I would suggest > adding a requirement along the lines of: > " o The protocol solution MUST allow the NAS to instruct the AN > to stop issuing ANCP messages to the NAS on join/leave (i) from a > particular AN port , (ii) for a particular multicast flow (or ranges > of multicast flows) or (iii) combination thereof." There is a requirment in the draft (The protocol solution MUST be robust against DoS). Such requirment covers the case that you state. However if the case is mentioned as you describe, we believe that it will go into solutions description which is not the objective of our draft. Indeed, the requirement is that the protocol MUST be robust against DoS attacks, how it is done is not the scope of the draft. 2 Editorial Comments > ================ > > Abstract: > s/to configure and manage access equipments and allow them to report > information to the NAS in order to enable and optimize configuration/ > to allow the NAS to configure, manage and control access equipments, > including the ability for the access nodes to report information to > the NAS/ OK. Section1, 2nd paragraph: > s/This document/The present document/ OK. Section 1: > I don't quite get the exact meaning of the following sentence: > " and ANCP should also provide such protection as a service to the > different service parameters between the two peers." > Is this saying that the protection should ensure protection of the > various parameters manipulated inside the ANCP message? if yes, then > I think this is already covered in previous sentence stating that the > ANCP payload ought to be protected. If not, can you clarify what it > means? Yes, it means this. So this sentence will be removed so not to have redundancy. Section 1: > Current text says: > " Prevention against Impersonation: > It is important that signaling messages are delivered to the > correct nodes, and nowhere else." > The description doesn't quite match the title. The description sounds > more like "mis-delivery of message". Perhaps it should say something > like: > " Prevention against Impersonation: > It is important that protection be available against a device > impersonating an ANCP node (i.e. an unauthorized device generating an > ANCP message and pretending it was generated by a valid ANCP node) " Right, modification is considered. Section 1: I understood that you mean Section 3. Current text says: > "For the threat analysis, the protocol communication between the > Access Node and the NAS is important whereas the other component, > such as HGW, CPE, AAA server only play a role in the understanding of > the system architecture. > " > Should this say something like: > "For the threat analysis, this document focuses on the ANCP protocol > communication between the Access Node and the NAS. However, > communications with the other components, such as HGW, CPE, AAA > server play a role in the understanding of the system architecture > and of what triggers ANCP protocol communications." Yes, modification is considered. Section 4: > "Also, through replaying old packets, of another privileged client > for instance, an attacker can configure a better QoS profile on its > own DSL line increasing its own benefit. > " > in previous sentence s/can/can attempt to/ Yes. Section 7: > Current text says: > "However, once the AAA server has the authorization data then it is > given to the NAS, which is more in the scope of this work. " > In previous sentence s/which is more/which is/ OK. Section 7: > Current text says: > "Consequently, this document considers the attacks that are related > to the ANCP operation and are concerning the communication between > the NAS and the AAA/Policy server." > I think you want to say that this document is concerned with the ANCP > communications that result from communications between the NAS and > AAA/Policy Server. But it is not directly considering "the attacks > that ....are concerning the communication between teh NAS and the AAA/ > Policy Server.". Right? > Should this read: > "Consequently, this document considers the attacks that are related > to the ANCP operation associated with communication between the NAS > and the AAA/Policy server." Right, modification is considered. section 7.2: > s/DoS attacks can take place by an attacker/DoS attacks of the AN can > take place by an attacker/ OK. section 7.4: > s/this allows the NAS to follow subscribers' multicast (source, > group) membership/this allows the NAS to follow subscribers' > multicast (source, group) membership and control replication > performed by the AN./ Actually, this is too specific. There is no agreement on how the solution will look like. So, we should not mention things for which the framework does not mention anything. Since a considerable number of people is against that the NAS controls the replication in the AN, because the zapping delay becomes too high with such a solution, so let's wait with this. section 8: > I don't fully understand how the following translates in terms of > ANCP Security requirements: > " o The protocol solution SHOULD distinguish the control messages > from the data." > Can you elaborate? This requirement aims to separate between replay and non integrity attacks. section 9: > s/presenting the security requirements to be considered/presenting > the security requirements to be considered for design of the ANCP > protocol/ O K. 3 Typos > ====== > > section 7.1: > s/injecting falsify packets/injecting falsified packets/ Yes, correction is considered. section 7.3: > s/carryout/carry out/ Actually, it is carryout On 3 Sep 2007, at 16:00, BOCCI Matthew wrote: > > > > > This email is to announce the start of a two week Working Group > > last call for draft-ietf-ancp-security-threats-02.txt. > > > > Please read the draft and provide comments to the ANCP list by > > Tuesday 11th September. > > > > As agreed during the Chicago meeting, the following participants > > kingly volunteered to review the draft as a part of the WG LC: > > > > Curtis Sherbo > > Phillipe Niger > > Michael Busser > > Francios LeFaucher > > Raymond Zhang > > > > We would like to thank them in advance for their help. > > > > We will not be in a position to progress the draft until we have > > received comments from at least five reviewers. > > > > Regards, > > > > Matthew & Woj > > > > ----------------------------------------- > > Matthew Bocci > > IP Division, > > Alcatel-Lucent Telecom Limited, > > Registered Office: Christchurch Way, Greenwich, London SE10 0AG. > > Registered in England & Wales number 02650571 > > ----------------------------------------- > > > > _______________________________________________ > > ANCP mailing list > > ANCP@ietf.org > > https://www1.ietf.org/mailman/listinfo/ancp > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://www1.ietf.org/pipermail/ancp/attachments/20070910/d7e7e144/attachment-0001.html > > ------------------------------ > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp > > > End of ANCP Digest, Vol 16, Issue 6 > *********************************** > ------=_Part_3203_17860018.1190017900139 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
 
Dear Francois,
 
Thanks a lot for reviewing the draft and for all these detailed comments.
Please find our comments below.
 
Thanks again.
 
Best Regards,
Hassnaa

 
Message: 1
Date: Mon, 10 Sep 2007 14:55:08 +0200
From: Francois Le Faucheur IMAP < flefauch@cisco.com>
Subject: Re: [ANCP] Working Group Last Call for
       draft-ietf-ancp-security-threats-02.txt
To: MOUSTAFA RD-CORE-ISS Hassnaa
       < hassnaa.moustafa@orange-ftgroup.com>,  Hannes Tschofenig
       <Hannes.Tschofenig@nsn.com>,    stefaan.de_cnodder@alcatel-lucent.be
Cc: ancp@ietf.org
Message-ID: <B4F5561D-CDDE-45F0-874A-D11882AC4B02@cisco.com>
Content-Type: text/plain; charset="us-ascii"

Hassnaa, Hannes, Stefaan,

Please find my review comments on draft-ietf-ancp-security-
threats-02.txt.
I tried split them into Substantial Comments, Editorial Comments and
Typos.
I hope these comments are useful.

Francois


1 Substantial Comments
===================

Section 1:
Is there not a well-established generic categorisation of protocol
security risks that could be applied here (or is this the generic
categorization)?
 
No there is not. This is in RFC 3365 as referenced in the draft.

Section 7:
In addition to discussing attacks against the 4 uses cases, I suspect
there would be value in discussing attacks during the "Protocol
establishment phase" (ie ANCP discovery phase, ANCP peering
establishment, ANCP Capability negotiation ...), Could this be added?
Does it lead to any additional security requirements specifically for
the ANCP Discovery phase? or peering phase?
 
In fact, the setup phase is among the protocol details, which will change nothing in the requirements.
The draft could mention something about "initiating the ANCP communication". This is already in the draft, but maybe should be made more clear.  
 
section 7.4:
There is an additional type of DOS attack that, I think, is not
discussed in the current text. Since, in some mode of operation of
ANCP for multicast, an IGMP join/leave received on AN validly
triggers an ANCP message from AN to NAS, a HGW/CPE can effectively
achieve a NAS DOS by generating heaps of IGMP join/leaves. I believe
this is worth discussing separately because it cannot be addressed
solely through security mechanisms inside the ANCP protocol. This
risk is discussed in section "6. Security Considerations" of draft-
maglione. Could the corresponding text describing the risk be
incorporated here in section 7.4(with appropraite editing if needed)?
 
The mentioned risk is not clear for me, I could not understand if the risk is DoS or anything else, as the section firstly discusses DoS then mentions the risk.  
 

Section "6. Security Considerations" of draft-maglione also
recommends specific mitigation approaches for this ("To mitigate this
risk,..."). Could this recommendation be added in section 8 of ancp-
security?
 
The cited recommendations go into solutions details, which is not our objective in Section 8 in our draft (which only gives requirements).
Indeed, overload is something that is not handled in the draft, but is concerning the scalability of the protocol solution (so not the scope of the security draft). In any case, it is a good idea to add something about overload/scalability to the draft without specifying where it could come from.
 

section 7.4:
One of the functions that ANCP has to enable for multicast is
accounting. So a specific additional risk associated with the
multicast use cases is tempering with accounting information (eg
escaping charging or conversely over-charging another user).
Could you add a statement to that effect? For example, perhaps, at
teh very end of section 7.4 we could add:
"       *   Messages's modifications to temper with accounting information,
for example in order to avoid service charges or conversely in order
to artificially increase service charges on other users"
 
In this case, we handle the security of the "information" sent between the AN and the NAS without further detailing what this information is, which can be accounting information (so in fact, it is covered in the draft). But something may be mentioned saying that "since this information can be used for accounting, it is possible to have attacks".
 

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

section 8:
In case of DOS attacks on NAS as a result of IGMP leave/joins
resulting in ANCP messages from AN to NAS, we would want the NAS to
be able to stop ANCP messages generated by the AN. I would suggest
adding a requirement along the lines of:
"   o    The protocol solution MUST allow the NAS to instruct the AN
to stop issuing ANCP messages to the NAS on join/leave (i) from a
particular AN port , (ii) for a particular multicast flow (or ranges
of multicast flows) or (iii) combination thereof."
 
There is a requirment in the draft (The protocol solution MUST be robust against DoS).  Such requirment covers the case that you state. However if the case is mentioned as you describe, we believe that it will go into solutions description which is not the objective of our draft. Indeed, the requirement is that the protocol MUST be robust against DoS attacks, how it is done is not the scope of the draft.


2 Editorial Comments
================

Abstract:
s/to configure and manage access equipments and allow them to report
information to the NAS in order to enable and optimize configuration/
to allow the NAS to configure, manage and control access equipments,
including the ability for the access nodes to report information to
the NAS/
 
OK. 

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

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

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

Section 1:
 
I understood that you mean Section 3.

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

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

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

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

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

section 7.4:
s/this allows the NAS to follow subscribers' multicast (source,
group) membership/this allows the NAS to follow subscribers'
multicast (source, group) membership and control replication
performed by the AN./
 
Actually, this is too specific. There is no agreement on how the solution will look like. So, we should not mention things for which the framework does not mention anything.
Since a considerable number of people is against that the NAS controls the replication in the AN, because the zapping delay becomes too high with such a solution, so let's wait with this.

section 8:
I don't fully understand how the following translates in terms of
ANCP Security requirements:
"   o  The protocol solution SHOULD distinguish the control messages
from the data."
Can you elaborate?
 
This requirement aims to separate between replay and non integrity attacks.  

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

3 Typos
======

section 7.1:
s/injecting falsify packets/injecting falsified packets/
 
Yes, correction is considered. 

section 7.3:
s/carryout/carry out/
 
Actually, it is carryout 

On 3 Sep 2007, at 16:00, BOCCI Matthew wrote:

>
> This email is to announce the start of a two week Working Group
> last call for draft-ietf-ancp-security-threats-02.txt.
>
> Please read the draft and provide comments to the ANCP list by
> Tuesday 11th September.
>
> As agreed during the Chicago meeting, the following participants
> kingly volunteered to review the draft as a part of the WG LC:
>
> Curtis Sherbo
> Phillipe Niger
> Michael Busser
> Francios LeFaucher
> Raymond Zhang
>
> We would like to thank them in advance for their help.
>
> We will not be in a position to progress the draft until we have
> received comments from at least five reviewers.
>
> Regards,
>
> Matthew & Woj
>
> -----------------------------------------
> Matthew Bocci
> IP Division,
> Alcatel-Lucent Telecom Limited,
> Registered Office: Christchurch Way, Greenwich, London SE10 0AG.
> Registered in England & Wales number 02650571
> -----------------------------------------
>
> _______________________________________________
> ANCP mailing list
> ANCP@ietf.org
> https://www1.ietf.org/mailman/listinfo/ancp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www1.ietf.org/pipermail/ancp/attachments/20070910/d7e7e144/attachment-0001.html

------------------------------

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp


End of ANCP Digest, Vol 16, Issue 6
***********************************

------=_Part_3203_17860018.1190017900139-- --===============1569600856== 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 --===============1569600856==-- From ancp-bounces@ietf.org Mon Sep 17 04:47:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXCGV-0002T2-0k; Mon, 17 Sep 2007 04:47:35 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IXCGU-0002Sw-Be for ancp-confirm+ok@megatron.ietf.org; Mon, 17 Sep 2007 04:47:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXCGU-0002Se-1d for ancp@ietf.org; Mon, 17 Sep 2007 04:47:34 -0400 Received: from rv-out-0910.google.com ([209.85.198.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXCGS-0004ph-My for ancp@ietf.org; Mon, 17 Sep 2007 04:47:34 -0400 Received: by rv-out-0910.google.com with SMTP id l15so1250103rvb for ; Mon, 17 Sep 2007 01:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=+QEhnkCYO0ZMNuJ45WhFQPirbDeuwmbQhi5uBr+34og=; b=nCwRNhVU20Bg2wP2LwYK1N4SZAisDpM2qv3Za54E+ygwn4CGOBDlPCKY7TjnrVWMl/mj9qDwFXm4W9WhPgclL7LR6FHdsYSn+jUrzLcxVe32FxeAKCqQqjzw4fjMC5Tsz6MiyjnD2P+p/+oBUfg6c+5ziYd0kpPv3y0yLIqtJ9M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ANZURas/qr03rt32KqhlycUBpc/6eStyaHP9O9wOEZUANuxTjEJfuen+WXpvGns6xomJkX+ucutlt33pO4d+mvZSmVw6VB2WtCTSV0YkW3YazAoeXLNEwf+Sun0JzdDAitjWUvfVn41eiWoiiTpss1adjlSKstEKcwebyVNGznw= Received: by 10.141.15.19 with SMTP id s19mr756284rvi.1190018852076; Mon, 17 Sep 2007 01:47:32 -0700 (PDT) Received: by 10.141.68.16 with HTTP; Mon, 17 Sep 2007 01:47:32 -0700 (PDT) Message-ID: Date: Mon, 17 Sep 2007 10:47:32 +0200 From: "Hasnaa Moustafa" To: Michael.Busser@t-systems.com, ancp@ietf.org In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.0 (/) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd Cc: Hannes.Tschofenig@nsn.com, hassnaa.moustafa@orange-ftgroup.com Subject: [ANCP] Re: ANCP Digest, Vol 16, Issue 7 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="===============0797998893==" Errors-To: ancp-bounces@ietf.org --===============0797998893== Content-Type: multipart/alternative; boundary="----=_Part_3230_23466160.1190018852078" ------=_Part_3230_23466160.1190018852078 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline * Dear Michael, Firstly, thank you for reviewing the draft. Replying to your question: We do not think of any need for an additional security requirement concerning the setup phase. The existing requirements cover this case. Mayb= e a small section has to be added about setting a secure session and what can go wrong there, but at the end it will not change the requirements. Thanks again. Best Regards, Hassnaa * > > Date: Tue, 11 Sep 2007 15:40:53 +0200 > From: "Busser, M" > Subject: AW: [ANCP] Working Group Last Call > fordraft-ietf-ancp-security-threats-02.txt > To: , > , < > stefaan.de_cnodder@alcatel-lucent.be> > Cc: ancp@ietf.org > Message-ID: > < 1B6169C658325341A3B8066E23919E1C1065CD@S4DE8PSAANK.mitte.t-com.d= e > > > Content-Type: text/plain; charset=3D"iso-8859-1" > > Hi Hassnaa, Hannes and Stefaan. > > After reviewing the draft, i have the following comment: > > Section 7: > Do we have some additional security requirements, when taking the > "protocol setup phase" into account (beside the 4 use cases)? > > > Best Regards; Freundliche Gr=FC=DFe > > Michael Busser > > T-Systems Enterprise Services GmbH > Production Line Network Centric Systems > ICT-Systems Integration > Network Integration Services > > Br=FCckes 2 -8, 55545 Bad Kreuznach > Postfach 9100, 55541 Bad Kreuznach > +49 671 8333 8911 (Phone) > +49 521 9210 3859 (Fax) > +49 151 1211 9689 (Mobile) > E-Mail: michael.busser@t-systems.com > Internet: < http://www.t-systems.com/> http://www.t-systems.com > > > T-Systems Enterprise Services GmbH > Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) > Executive Committee: Helmut Binder, Albert Henn, Olaf Heyden*, Katrin > Horstmann, Ulrich Kemp, Wilfried Peters*, > Dr. Herbert Schaaff*, Zvezdana Seeger* > Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 > Sitz der Gesellschaft: Frankfurt am Main > WEEE-Reg.-Nr. DE87523644 > *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG > > Notice: This transmittal and/or attachments may be privileged or > confidential. If you are not the intended recipient, you are hereby notif= ied > that you have received this transmittal in error; any review, disseminati= on, > or copying is strictly prohibited. If you received this transmittal in > error, please notify us immediately by reply and immediately delete this > message and all its attachments. Thank you. > T-Systems - Business flexibility > > > > -----Urspr=FCngliche Nachricht----- > Von: BOCCI Matthew [mailto:Matthew.Bocci@alcatel-lucent.co.uk] > Gesendet: Montag, 3. September 2007 16:00 > An: ancp@ietf.org > Betreff: [ANCP] Working Group Last Call > fordraft-ietf-ancp-security-threats-02.txt > > > > > This email is to announce the start of a two week Working Group last call > for draft-ietf-ancp-security-threats-02.txt. > > Please read the draft and provide comments to the ANCP list by Tuesday > 11th September. > > As agreed during the Chicago meeting, the following participants kingly > volunteered to review the draft as a part of the WG LC: > > Curtis Sherbo > Phillipe Niger > Michael Busser > Francios LeFaucher > Raymond Zhang > > We would like to thank them in advance for their help. > > We will not be in a position to progress the draft until we have received > comments from at least five reviewers. > > Regards, > > Matthew & Woj > > ----------------------------------------- > Matthew Bocci > IP Division, > Alcatel-Lucent Telecom Limited, > Registered Office: Christchurch Way, Greenwich, London SE10 0AG. > Registered in England & Wales number 02650571 > ----------------------------------------- > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://www1.ietf.org/pipermail/ancp/attachments/20070911/f2a42501/attachm= ent-0001.html > > ------------------------------ > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp > > > End of ANCP Digest, Vol 16, Issue 7 > *********************************** > ------=_Part_3230_23466160.1190018852078 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Dear Michael,

&n= bsp;

Firstly, thank you for reviewing the draft= .

&n= bsp;

Replying to your question:

We do not think of any need for an additional s= ecurity requirement concerning the setup phase. The existing requirements c= over this case. Maybe a small section has to be added about setting a secur= e session and what can go wrong there, but at the end it will not change th= e requirements.

&n= bsp;

Thanks again.=

 

Best Regards,=

Hassnaa

 

 


 

Date: Tue, 11 Sep 20= 07 15:40:53 +0200
From: "Busser, M" < Michael.Busser@t-systems.com>
Subject: AW: [ANCP] Working Group L= ast Call
       fordraft-ietf-ancp-securi= ty-threats-02.txt
To: < hassnaa.moustafa@orange-ftgroup.com>,
    &nb= sp;  <Hannes.Tschofeni= g@nsn.com >,    < stefaan.de_cnodder@alcatel-lucent.be>
Cc: ancp@ietf.org
Message-ID:
    &nb= sp;  < 1B6169C658325341A3B8066E23919E1C1065CD@S4DE8PSAANK.mitte.t-com.de><= br>Content-Type: text/plain; charset=3D"iso-8859-1"

Hi Has= snaa, Hannes and Stefaan.

After reviewing the draft, i have the foll= owing comment:=20

Section 7:
Do we have some additional security requirements, whe= n taking the "protocol setup phase" into account (beside the 4 us= e cases)?


Best Regards; Freundliche Gr=FC=DFe

Michael Bus= ser=20

T-Systems Enterprise Services GmbH
Production Line Network Centr= ic Systems
ICT-Systems Integration
Network Integration Services
Br=FCckes 2 -8, 55545 Bad Kreuznach
Postfach 9100, 55541 Bad Kreuznach= =20
+49 671 8333 8911 (Phone)
+49 521 9210 3859 (Fax)
+49 151 1211 96= 89 (Mobile)
E-Mail: mich= ael.busser@t-systems.com
Internet:  < htt= p://www.t-systems.com/> http://www.t-systems.com


T-Systems Enterprise Services GmbH<= br>Aufsichtsrat: Ren=E9 Obermann (Vorsitzender)
Executive Committee: Hel= mut Binder, Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Wilfr= ied Peters*,=20
Dr. Herbert Schaaff*, Zvezdana Seeger*
Handelsregister: Amtsgericht = Frankfurt am Main HRB 55933
Sitz der Gesellschaft: Frankfurt am Main
= WEEE-Reg.-Nr. DE87523644
*Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG

N= otice: This transmittal and/or attachments may be privileged or confidentia= l. If you are not the intended recipient, you are hereby notified that you = have received this transmittal in error; any review, dissemination, or copy= ing is strictly prohibited. If you received this transmittal in error, plea= se notify us immediately by reply and immediately delete this message and a= ll its attachments. Thank you.=20
T-Systems - Business flexibility



-----Urspr=FCngliche Na= chricht-----
Von: BOCCI Matthew [mailto: Matthew.Bocci@alcatel-lucent.co.uk]
Gesendet: Montag, 3. September 2= 007 16:00
An: ancp@ietf.org
Bet= reff: [ANCP] Working Group Last Call=20 fordraft-ietf-ancp-security-threats-02.txt




This email is= to announce the start of a two week Working Group last call for draft-ietf= -ancp-security-threats-02.txt.

Please read the draft and provide com= ments to the ANCP list by Tuesday 11th September.

As agreed during the Chicago meeting, the following participants ki= ngly volunteered to review the draft as a part of the WG LC:

Curtis= Sherbo
Phillipe Niger
Michael Busser
Francios LeFaucher
Raymon= d Zhang

We would like to thank them in advance for their help.

We wi= ll not be in a position to progress the draft until we have received commen= ts from at least five reviewers.

Regards,

Matthew & Woj

-----------------------------------------
Matthew Bocci
IP Di= vision,
Alcatel-Lucent Telecom Limited,
Registered Office: Christchur= ch Way, Greenwich, London SE10 0AG.
Registered in England & Wales n= umber 02650571
-----------------------------------------

-------------- next pa= rt --------------
An HTML attachment was scrubbed...
URL: http://www1.ietf.org/pipermail/ancp/attachments/20070911/f2a42501/attachmen= t-0001.html

------------------------------

______________= _________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp


End of ANCP Di= gest, Vol 16, Issue 7
***********************************
=
------=_Part_3230_23466160.1190018852078-- --===============0797998893== 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 --===============0797998893==-- From ancp-bounces@ietf.org Mon Sep 17 05:19:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXClg-0007YY-39; Mon, 17 Sep 2007 05:19:48 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IXClf-0007YS-Ga for ancp-confirm+ok@megatron.ietf.org; Mon, 17 Sep 2007 05:19:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXClf-0007YJ-6j for ancp@ietf.org; Mon, 17 Sep 2007 05:19:47 -0400 Received: from rv-out-0910.google.com ([209.85.198.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXCld-0005sG-KG for ancp@ietf.org; Mon, 17 Sep 2007 05:19:47 -0400 Received: by rv-out-0910.google.com with SMTP id l15so1256537rvb for ; Mon, 17 Sep 2007 02:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=X0Dd6QTWCxNYu541RWiWvv+wPpkpCJElLWKXo+WTTI0=; b=ZE2PZrZ3UAPMU4llgh303bc9ALiyRWvulEINYoc6iRuQFG+pKbj1wrV9Xdjr+hT5IQP0yl55p3/PaIaKYYhuubuDpdtLy0ueaHIknquIJOkzEBoBXUOPlVUSjAIVyl2ZVyDvL9eaLilKhREkmLcLXylw2YeF9ayXa+4M5zuAFgs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=qYgS6SYVUGKPFPHyl98j+IGekbtcaFHnyXNJWbFdZxx6NvGkDX2jXmWHnyrL1c0oJM7aPtWHDYoCaJ8bc0y+LRC24QEfYkZObMuHK6rXnr4j95t9g/ImzNai4tDRXNprHKZ5J38t02r+FUtXXaP1rOl8OGBg0iuHWEWUdY3SgkY= Received: by 10.141.197.18 with SMTP id z18mr895280rvp.1190020784954; Mon, 17 Sep 2007 02:19:44 -0700 (PDT) Received: by 10.141.68.16 with HTTP; Mon, 17 Sep 2007 02:19:44 -0700 (PDT) Message-ID: Date: Mon, 17 Sep 2007 11:19:44 +0200 From: "Hasnaa Moustafa" To: philippe.niger@orange-ftgroup.com, ancp@ietf.org In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 22f8e36c8d8be0bcbb9bf02fb6ce7335 Cc: Hannes.Tschofenig@nsn.com, hassnaa.moustafa@orange-ftgroup.com Subject: [ANCP] Re: ANCP Digest, Vol 16, Issue 8 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="===============0965415123==" Errors-To: ancp-bounces@ietf.org --===============0965415123== Content-Type: multipart/alternative; boundary="----=_Part_3310_19245700.1190020784960" ------=_Part_3310_19245700.1190020784960 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dear Philippe, Thanks you a lot for reviewing and for all your remarks. Please find our replies below. Best Regards, Hassnaa Date: Wed, 12 Sep 2007 11:27:00 +0200 > From: "NIGER Philippe RD-RESA-LAN" > Subject: RE: [ANCP] Working Group Last Call > fordraft-ietf-ancp-security-threats-02.txt > To: > Message-ID: > Content-Type: text/plain; charset=3D"iso-8859-1" > > Hi All, > > After reviewing the draft, please find my comments below. > > > Regards, > > Philippe Niger. > > ------------------------------------------------------------------ > > > No major comments. > > > > Important comments. > > - In the section 3 it is indicated that "the NAS and AN might belong to > two different administrative realms". It could be useful to indicate here= if > the threat model and the derived requirements apply also in that > configuration or are limited to a configuration in which the NAS and the = AN > belong to the same administrative entitiy. Actually, the threat model in the draft and the security requirements apply to this case. So a statement will be added here to confirm this point. - At the end of the first paragraph of section 7 it is indicated that "this > document considers the attacks that are related to the ANCP operation and > are concerning the communication between the NAS and the AAA/Policy serve= r". > As ANCP is running between the AN and the NAS this sentence should be > clarified (e.g. indicating that the data targeted by the attacks are thos= e > exchanged between the NAS and the AAA server and the derived security > requirements applied when these data are transported over ANCP between th= e > AN and the NAS). Ok, may be more clarification is needed to show that the threat model and the security requirements takes into consideration the data transfer betwee= n the NAS and the AAA server, when this data is used within the ANCP operation. Minor comments (editorial). We agree with most of the coming comments concerning some editorial modifications. -0- Abstract : > > The Access Node Control Protocol (ANCP) aims to communicate QoS-, service= - > and subscriber-related configurations... > > Change to : The Access Node Control Protocol (ANCP) aims to communicate > QoS-[related], service-[related] and subscriber-related configurations... > > -1- Introduction : > > Same change as described above. > > > > -2- Terminology > > This section should be renamed as "Specification of requirements" and > moved before the "Introduction" section. > > > > -3- Systeme Overview and Threat Model > > > > - Home Gateway (HGW): The HGW connects the different Customer Premises > Equipment (CPE)... > > Change to : Home Gateway (HGW): The HGW connects the different Customer > Premises Equipment [s] (CPE)... > > > > - Aggregation Network: The aggregation network provides traffic > aggregation from multiple ANs towards the NAS. ATM or Ethernet technologi= es > can be used. > > Change to : Aggregation Network: The aggregation network provides traffic > aggregation from multiple ANs towards the NAS. ATM or Ethernet [transport= ] > technologies can be used. > > > > - Attackers can be: o off-path, i.e., it cannot see packets between the A= N > and the NAS; o on-path, i.e., they can see the message exchange between > the AN and the NAS. > > Change to : Attackers can be: o off-path, i.e., [they] cannot see packets > between the AN and the NAS; o on-path, i.e., they can see the message > exchange[s] between the AN and the NAS. > > > > - Both off-path and on-path attackers can be: o passive, i.e., they do no= t > participate in the network but rather listen to all transfer to obtain th= e > maximum possible information; o active, i.e., they participate to the > network and can inject falsify packets. > > Change to : Both off-path and on-path attackers can be: o passive, i.e., > they do not participate in the network [operation] but rather listen to a= ll > transfer[s] to obtain the maximum possible information; o active, i.e., > they participate to the network [operation] and can inject falsif[ied] > packets. > > > > -5- Potential Attacks > > - paragraph 5.1 : ... is a chance to mount denial of services attacks... > > Change to : ...is a chance to mount denial of service[] attacks... > > - paragraph 5.3 : An insecure parameter exchange or security negotiation > protocol can help an adversary to mount a downgrading attack... > > Change to : An insecure parameter exchange or security negotiation > protocol can [give the opportunity to] an adversary to mount a downgradin= g > attack... > > - paragraph 5.4 : ...capturing all traversed packets > > Change to : ...capturing all [traversing] packets > > - paragraph 5.4 : ...containing some information related to the connected > client, indicating the client's existing at home. > > Change to : ...containing some information related to the connected clien= t > []. Or clarify the end of the sentence [indicating the client's existing = at > home]. > > > > -6- Attacks Forms > > - title : Attacks Forms > > Change to : Attack[] Forms. > > - Through replaying of signaling messages, an adversary might mount a > denial of service and theft of service attacks. > > Change to : Through replaying of signaling messages, an adversary might > mount a denial of service and [a] theft of service attacks. > > - This could be at the signaling protocol level, at the level of a > specific signaling parameters (e.g., QoS information), or the transport > layer. An adversary might, for example, inject signaling message... > > Change to : This could be [achieved] at the signaling protocol level, at > the level of a specific signaling parameters (e.g., QoS information), or > [at] the transport layer. An adversary might, for example, inject [a] > signaling message... > > - ... reordering and delaying of messages causing a protocol's process > failures. > > Change to : ...reordering and delaying of messages causing a protocol's > process failure[]. > > - In this case the protocol could appear to continue correctly. > > Change to : In this case the protocol could appear to continue [working] > correctly. > > > > -7- Attacks against ANCP Defined Use Cases > > - ... concerning how the user gets authenticated and how the AAA server > gets... > > Change to : ...concerning how the user [are] authenticated and how the AA= A > server gets... > > - paragraph 7.1 : Active, acting on the transferred attributes and > injecting falsify packets. > > Change to : Active, acting on the transferred attributes and injecting > falsif[ied] packets. > > - paragraph 7.1 : Passive gaining information of the access loop > attributes. > > Change to : Passive gaining information [on] the access loop attributes. > > - paragraph 7.3 : Most of the attacks in this use case concern the networ= k > functionality. > > Change to : Most of the attacks in this use case concern the network > [operation]. > > - paragraph 7.3 : ...where an adversary can inject falsify signals or can > truncate the triggering. > > Change to : where an adversary can inject falsif[ied] signals or can > truncate the triggering > > > > -11- IANA Considerations > > This section should be moved before the "Acknowledgments" section. > > -12- References > > The reference to the Framework document should be updated (version -02). > > > > ________________________________ > > De : BOCCI Matthew [mailto:Matthew.Bocci@alcatel-lucent.co.uk] > Envoy=E9 : lundi 3 septembre 2007 16:00 > =C0 : ancp@ietf.org > Objet : [ANCP] Working Group Last Call > fordraft-ietf-ancp-security-threats-02.txt > > > > > This email is to announce the start of a two week Working Group last call > for draft-ietf-ancp-security-threats-02.txt. > > Please read the draft and provide comments to the ANCP list by Tuesday > 11th September. > > As agreed during the Chicago meeting, the following participants kingly > volunteered to review the draft as a part of the WG LC: > > Curtis Sherbo > Phillipe Niger > Michael Busser > Francios LeFaucher > Raymond Zhang > > We would like to thank them in advance for their help. > > We will not be in a position to progress the draft until we have received > comments from at least five reviewers. > > Regards, > > Matthew & Woj > > ----------------------------------------- > Matthew Bocci > IP Division, > Alcatel-Lucent Telecom Limited, > Registered Office: Christchurch Way, Greenwich, London SE10 0AG. > Registered in England & Wales number 02650571 > ----------------------------------------- > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://www1.ietf.org/pipermail/ancp/attachments/20070912/fa7a3089/attachm= ent-0001.html > > ------------------------------ > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp > > > End of ANCP Digest, Vol 16, Issue 8 > *********************************** > ------=_Part_3310_19245700.1190020784960 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
 
Dear Philippe,
 
Thanks you a lot for reviewing and for all your remarks.
 
Please find our replies below.
 
Best Regards,
Hassnaa

Date: Wed, 12 Sep 2007 11:27:00 = +0200
From: "NIGER Philippe RD-RESA-LAN" < philippe.niger@orange-ftgroup.com>
Subject: RE: [ANCP] Working Gr= oup Last Call
       fordraft-ietf-ancp-se= curity-threats-02.txt
To: <ancp@ietf= .org>
Message-ID: < BBBE5BAA3B351C488C415EA662EA8840047F8FB9@ftrdmel2>
Content-Type: text= /plain; charset=3D"iso-8859-1"

Hi All,

After review= ing the draft, please find my comments below.


Regards,

Philippe Niger.

----------------------------------------------------= --------------


No major comments.



Important comme= nts.

- In the section 3 it is indicated that "the NAS and AN mi= ght belong to two different administrative realms". It could be useful= to indicate here if the threat model and the derived requirements apply al= so in that configuration or are limited to a configuration in which the NAS= and the AN belong to the same administrative entitiy.
 
 
Actually, the threat model in the draft and the security requirements = apply to this case. So a statement will be added here to confirm this point= .
 

- At the end of the first paragr= aph of section 7 it is indicated that "this document considers the att= acks that are related to the ANCP operation and are concerning the communic= ation between the NAS and the AAA/Policy server". As ANCP is running b= etween the AN and the NAS this sentence should be clarified ( e.g. indicating that the data targeted by the attacks are those exchanged b= etween the NAS and the AAA server and the derived security requirements app= lied when these data are transported over ANCP between the AN and the NAS).
 
Ok, may be more clarification is needed to show that the threat model = and the security requirements takes into consideration the data transfer be= tween the NAS and the AAA server, when this data is used within the ANCP op= eration.

Minor comments (editorial).
 
 
We agree with most of the coming comments concerning some editorial mo= difications.

-0- Abstract :

The Access= Node Control Protocol (ANCP) aims to communicate QoS-, service- and subscr= iber-related configurations...

Change to : The Access Node Control Protocol (ANCP) aims to communi= cate QoS-[related], service-[related] and subscriber-related configurations= ...

-1- Introduction :

Same change as described above.



-2- Terminology

This section should be renamed as "= Specification of requirements" and moved before the "Introduction= " section.



-3- Systeme Overview and Threat Model



- Home Gateway (HGW): The HGW connects the different Customer P= remises Equipment (CPE)...

Change to : Home Gateway (HGW): The HGW c= onnects the different Customer Premises Equipment [s] (CPE)...



- Aggregation Network: The aggregation network provides traffic aggrega= tion from multiple ANs towards the NAS. ATM or Ethernet technologies can be= used.

Change to : Aggregation Network: The aggregation network prov= ides traffic aggregation from multiple ANs towards the NAS. ATM or Ethernet= [transport] technologies can be used.



- Attackers can be: o off-path, i.e., it cannot see packets= between the AN and the NAS; o on-path, i.e., they can see the message exch= ange between the AN and the NAS.

Change to : Attackers can be: o off= -path,=20 i.e., [they] cannot see packets between the AN and the NAS; o on-path, i.e.= , they can see the message exchange[s] between the AN and the NAS.

<= br>
- Both off-path and on-path attackers can be: o passive, i.e., they = do not participate in the network but rather listen to all transfer to obta= in the maximum possible information; o active,=20 i.e., they participate to the network and can inject falsify packets.
Change to : Both off-path and on-path attackers can be: o passive, i.e., = they do not participate in the network [operation] but rather listen to all= transfer[s] to obtain the maximum possible information; o active,=20 i.e., they participate to the network [operation] and can inject falsif[ied= ] packets.



-5- Potential Attacks

- paragraph 5.1 : ..= . is a chance to mount denial of services attacks...

Change to : ...= is a chance to mount denial of service[] attacks...

- paragraph 5.3 : An insecure parameter exchange or security negoti= ation protocol can help an adversary to mount a downgrading attack...
Change to : An insecure parameter exchange or security negotiation protoc= ol can [give the opportunity to] an adversary to mount a downgrading attack= ...

- paragraph 5.4 : ...capturing all traversed packets

Change = to : ...capturing all [traversing] packets

- paragraph 5.4 : ...cont= aining some information related to the connected client, indicating the cli= ent's existing at home.

Change to : ...containing some information related to the connected= client []. Or clarify the end of the sentence [indicating the client's= existing at home].



-6- Attacks Forms

- title : Attac= ks Forms

Change to : Attack[] Forms.

- Through replaying of signaling= messages, an adversary might mount a denial of service and theft of servic= e attacks.

Change to : Through replaying of signaling messages, an a= dversary might mount a denial of service and [a] theft of service attacks.

- This could be at the signaling protocol level, at the level of a = specific signaling parameters (e.g., QoS information), or the transport lay= er. An adversary might, for example, inject signaling message...

Change to : This could be [achieved] at the signaling protocol level, at th= e level of a specific signaling parameters (e.g., QoS information), or [at]= the transport layer. An adversary might, for example, inject [a] signaling= message...

- ... reordering and delaying of messages causing a protocol's = process failures.

Change to : ...reordering and delaying of messages= causing a protocol's process failure[].

- In this case the prot= ocol could appear to continue correctly.

Change to : In this case the protocol could appear to continue [wor= king] correctly.



-7- Attacks against ANCP Defined Use Cases<= br>
- ... concerning how the user gets authenticated and how the AAA ser= ver gets...

Change to : ...concerning how the user [are] authenticated and how = the AAA server gets...

- paragraph 7.1 : Active, acting on the trans= ferred attributes and injecting falsify packets.

Change to : Active,= acting on the transferred attributes and injecting falsif[ied] packets.

- paragraph 7.1 : Passive gaining information of the access loop at= tributes.

Change to : Passive gaining information [on] the access lo= op attributes.

- paragraph 7.3 : Most of the attacks in this use cas= e concern the network functionality.

Change to : Most of the attacks in this use case concern the networ= k [operation].

- paragraph 7.3 : ...where an adversary can inject fa= lsify signals or can truncate the triggering.

Change to : where an a= dversary can inject falsif[ied] signals or can truncate the triggering



-11- IANA Considerations

This section should be move= d before the "Acknowledgments" section.

-12- References
The reference to the Framework document should be updated (version -02= ).



________________________________

De : BOCCI Matthew = [mailto:Matthew.Bocci= @alcatel-lucent.co.uk]
Envoy=E9 : lundi 3 septembre 2007 16:00
= =C0 :=20 ancp@ietf.org
Objet : [ANCP] Workin= g Group Last Call fordraft-ietf-ancp-security-threats-02.txt



This email is to announce the start of a two week Working Group last c= all for=20 draft-ietf-ancp-security-threats-02.txt.

Please read the draft and p= rovide comments to the ANCP list by Tuesday 11th September.

As agree= d during the Chicago meeting, the following participants kingly volunteered= to review the draft as a part of the WG LC:

Curtis Sherbo
Phillipe Niger
Michael Busser
Francios LeFau= cher
Raymond Zhang

We would like to thank them in advance for the= ir help.

We will not be in a position to progress the draft until we= have received comments from at least five reviewers.

Regards,

Matthew & Woj

--------------------------= ---------------
Matthew Bocci
IP Division,
Alcatel-Lucent Telecom = Limited,
Registered Office: Christchurch Way, Greenwich, London SE10 0AG= .
Registered in England & Wales number 02650571
------------------= -----------------------

-------------- next part --------------
A= n HTML attachment was scrubbed...
URL: http://www1.ietf.org/pipermail/ancp/attachments/20070912/fa7a3089/attachmen= t-0001.html

------------------------------

______________= _________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp


End of ANCP Di= gest, Vol 16, Issue 8
***********************************

------=_Part_3310_19245700.1190020784960-- --===============0965415123== 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 --===============0965415123==-- From ancp-bounces@ietf.org Mon Sep 17 05:37: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 1IXD2c-0007Tf-LH; Mon, 17 Sep 2007 05:37:18 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IXD2c-0007Ta-83 for ancp-confirm+ok@megatron.ietf.org; Mon, 17 Sep 2007 05:37:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXD2b-0007TS-UV for ancp@ietf.org; Mon, 17 Sep 2007 05:37:17 -0400 Received: from rv-out-0910.google.com ([209.85.198.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXD2a-0006Mc-FD for ancp@ietf.org; Mon, 17 Sep 2007 05:37:17 -0400 Received: by rv-out-0910.google.com with SMTP id l15so1259993rvb for ; Mon, 17 Sep 2007 02:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=kZzOkW8OfGj7N+YsVwWsqvrJSeyWckLIPN/iDEIxyOE=; b=lBRq8LhTlMKu7RmfA04vshce+7HxSig4HFyCH+iiVrmO/Rsp4lC1Qjqr1fdyPwrPannrgiDXckaqkssPymOW46DorReMYAaDjjMioYkRgbW9dTSULWYm8UmxvGoFpfy6vntewoak18+2/c3GriBE5gTfyFw2ySEk9Tv/OA30zBA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=THSGqjkaZPaCd4l1u4THsY0TmLA/HL8jDzT1WPJ3/tX6U8gR/vrwSnxdIP0xfucdr3oi1WU/zXsyE3V5uw7HXdAHTW8vsP8LNtQ61n4PHFytq0SEDfWFzpjNKPSEnuTAID/wJkcEO34I/bHMUowH5U2GSzHc8nVNf1HRw8yXOCE= Received: by 10.141.197.18 with SMTP id z18mr763152rvp.1190021835687; Mon, 17 Sep 2007 02:37:15 -0700 (PDT) Received: by 10.141.68.16 with HTTP; Mon, 17 Sep 2007 02:37:15 -0700 (PDT) Message-ID: Date: Mon, 17 Sep 2007 11:37:15 +0200 From: "Hasnaa Moustafa" To: csherbo@redback.com, ancp@ietf.org In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: Hannes.Tschofenig@nsn.com, hassnaa.moustafa@orange-ftgroup.com Subject: [ANCP] Re: ANCP Digest, Vol 16, Issue 9 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="===============1444475712==" Errors-To: ancp-bounces@ietf.org --===============1444475712== Content-Type: multipart/alternative; boundary="----=_Part_3372_32727099.1190021835696" ------=_Part_3372_32727099.1190021835696 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear Curtis, Thank you for reviewing the draft and for your useful comments. Please find the replies below. Best regards, Hassnaa Date: Wed, 12 Sep 2007 11:09:41 -0700 > From: "Curtis Sherbo" > Subject: RE: [ANCP] Working Group Last Call > fordraft-ietf-ancp-security-threats-02.txt > To: "'BOCCI Matthew'" , > < ancp@ietf.org> > Message-ID: <004c01c7f568$17568ae0$242413ac@ad.redback.com> > Content-Type: text/plain; charset="us-ascii" > > I have reviewed the draft and have the following editorial comments: > > 5.4. Traffic Analysis An adversary can be placed at the NAS, or the AN, or > any other network element capturing all traversed packets. Adversaries can > > > Internet-Draft ANCP Threats July 2007 thus have unauthorized information > access. As well, they can gather information relevant to the network and > then use this information in gaining later unauthorized access. This > attack > can also help adversaries in other malicious purposes, as for example > capturing messages sent from the AN to the NAS announcing that a DSL line > is > up and containing some information related to the connected client, > indicating the client's existing at home. <<--- Don't know what this > means? > We also got a previous comment on this part, so we will clarify it more. 6. Attacks Forms > > Should Read Attack Forms > OK. The text in read perhaps would read better if it said "which is in scope of > > this work". > OK, this point will be considered. 7.However, once the AAA server has the authorization data then it is given > to the NAS, which is more in the scope of this work. Consequently, this > document considers the attacks that are related to the ANCP operation and > are concerning the communication between the NAS and the AAA/Policy > server. > This part will be re-formulated. 7.1 Active, acting on the transferred attributes and injecting falsify > packets. The main attacks here are: > > Should perhaps be falsified > Right. Curtis Sherbo > > > > > _____ > > From: BOCCI Matthew [mailto:Matthew.Bocci@alcatel-lucent.co.uk] > Sent: Monday, September 03, 2007 7:00 AM > To: ancp@ietf.org > Subject: [ANCP] Working Group Last Call > fordraft-ietf-ancp-security-threats-02.txt > > > > > This email is to announce the start of a two week Working Group last call > for draft-ietf-ancp-security-threats-02.txt. > > Please read the draft and provide comments to the ANCP list by Tuesday > 11th > September. > > As agreed during the Chicago meeting, the following participants kingly > volunteered to review the draft as a part of the WG LC: > > Curtis Sherbo > Phillipe Niger > Michael Busser > Francios LeFaucher > Raymond Zhang > > We would like to thank them in advance for their help. > > We will not be in a position to progress the draft until we have received > comments from at least five reviewers. > > Regards, > > Matthew & Woj > > ----------------------------------------- > Matthew Bocci > IP Division, > Alcatel-Lucent Telecom Limited, > Registered Office: Christchurch Way, Greenwich, London SE10 0AG. > Registered in England & Wales number 02650571 > ----------------------------------------- > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://www1.ietf.org/pipermail/ancp/attachments/20070912/acd06f8e/attachment-0001.html > > > ------------------------------ > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp > > > End of ANCP Digest, Vol 16, Issue 9 > *********************************** > ------=_Part_3372_32727099.1190021835696 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
 
Dear Curtis,
 
Thank you for reviewing the draft and for your useful comments.
 
Please find the replies below.
 
Best regards,
Hassnaa
 
 

Date: Wed, 12 Sep 2007 11:09:41 -0700
From: "Curtis Sherbo" < csherbo@redback.com>
Subject: RE: [ANCP] Working Group Last Call
       fordraft-ietf-ancp-security-threats-02.txt
To: "'BOCCI Matthew'" < Matthew.Bocci@alcatel-lucent.co.uk>,
       < ancp@ietf.org>
Message-ID: < 004c01c7f568$17568ae0$242413ac@ad.redback.com>
Content-Type: text/plain; charset="us-ascii"

I have reviewed the draft and have the following editorial comments:

5.4. Traffic Analysis An adversary can be placed at the NAS, or the AN, or
any other network element capturing all traversed packets. Adversaries can

Internet-Draft ANCP Threats July 2007 thus have unauthorized information
access. As well, they can gather information relevant to the network and
then use this information in gaining later unauthorized access. This attack
can also help adversaries in other malicious purposes, as for example
capturing messages sent from the AN to the NAS announcing that a DSL line is
up and containing some information related to the connected client,
indicating the client's existing at home. <<--- Don't know what this means?
 
 
We also got a previous comment on this part, so we will clarify it more.

6. Attacks Forms

Should Read Attack Forms
 
OK.

The text in read perhaps would read better if it said "which is in scope of
this work".
 
OK, this point will be considered.

7.However, once the AAA server has the authorization data then it is given
to the NAS, which is more in the scope of this work. Consequently, this
document considers the attacks that are related to the ANCP operation and
are concerning the communication between the NAS and the AAA/Policy server.
 
This part will be re-formulated.

7.1 Active, acting on the transferred attributes and injecting falsify
packets. The main attacks here are:

Should perhaps be falsified
 
Right.

Curtis Sherbo




_____

From: BOCCI Matthew [mailto: Matthew.Bocci@alcatel-lucent.co.uk]
Sent: Monday, September 03, 2007 7:00 AM
To: ancp@ietf.org
Subject: [ANCP] Working Group Last Call
fordraft-ietf-ancp-security-threats-02.txt




This email is to announce the start of a two week Working Group last call
for draft-ietf-ancp-security-threats-02.txt.

Please read the draft and provide comments to the ANCP list by Tuesday 11th
September.

As agreed during the Chicago meeting, the following participants kingly
volunteered to review the draft as a part of the WG LC:

Curtis Sherbo
Phillipe Niger
Michael Busser
Francios LeFaucher
Raymond Zhang

We would like to thank them in advance for their help.

We will not be in a position to progress the draft until we have received
comments from at least five reviewers.

Regards,

Matthew & Woj

-----------------------------------------
Matthew Bocci
IP Division,
Alcatel-Lucent Telecom Limited,
Registered Office: Christchurch Way, Greenwich, London SE10 0AG.
Registered in England & Wales number 02650571
-----------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www1.ietf.org/pipermail/ancp/attachments/20070912/acd06f8e/attachment-0001.html

------------------------------

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp


End of ANCP Digest, Vol 16, Issue 9
***********************************

------=_Part_3372_32727099.1190021835696-- --===============1444475712== 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 --===============1444475712==-- From ancp-bounces@ietf.org Tue Sep 18 12:02:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXfWe-0006eV-3b; Tue, 18 Sep 2007 12:02:12 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IXfWc-0006az-Mg for ancp-confirm+ok@megatron.ietf.org; Tue, 18 Sep 2007 12:02:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXfWc-0006Zp-CE for ancp@ietf.org; Tue, 18 Sep 2007 12:02:10 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXfWa-0002ue-Dy for ancp@ietf.org; Tue, 18 Sep 2007 12:02:10 -0400 X-IronPort-AV: E=Sophos;i="4.20,269,1186351200"; d="scan'208,217";a="153481489" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 18 Sep 2007 18:02:06 +0200 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 l8IG25GJ002722; Tue, 18 Sep 2007 18:02:05 +0200 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 l8IG21WX021623; Tue, 18 Sep 2007 16:02:01 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 18:01:54 +0200 Received: from [144.254.53.188] ([144.254.53.188]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 18:01:53 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <8389FA73-DB6E-405C-85BF-83685E709432@cisco.com> From: Francois Le Faucheur IMAP Date: Tue, 18 Sep 2007 18:01:43 +0200 To: Hasnaa Moustafa X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 18 Sep 2007 16:01:53.0574 (UTC) FILETIME=[3B0F8460:01C7FA0D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=25186; t=1190131325; x=1190995325; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20ANCP=20Digest,=20Vol=2016,=20Issue=206 |Sender:=20; bh=YkVKlzPjFxNttw56LgKFNIEYwVtfryEVk4Z9lrwfE8E=; b=YwWsXaM1PGD4Pc2g4lS1Sb9BnyDms4U99w3UMWxYHlfYV9cvlaJB+LpUfQD6xml97MSH8vtL zxU/a1IvS+T7bda+F6UsHHNuGy1qyRf4WSVQ3JzIpU5WVUD/Z+394tnM; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 22e211536bda974b2dcf811522dc525d Cc: Hannes.Tschofenig@nsn.com, ancp@ietf.org, hassnaa.moustafa@orange-ftgroup.com Subject: [ANCP] Re: ANCP Digest, Vol 16, Issue 6 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="===============2003596245==" Errors-To: ancp-bounces@ietf.org --===============2003596245== Content-Type: multipart/alternative; boundary=Apple-Mail-17--776777552 --Apple-Mail-17--776777552 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hasnaa, Thanks for looking into my comments. I cut out all the points which are closed/agreed. A few more thoughts on remaining ones below: > > Section 7: > In addition to discussing attacks against the 4 uses cases, I suspect > there would be value in discussing attacks during the "Protocol > establishment phase" (ie ANCP discovery phase, ANCP peering > establishment, ANCP Capability negotiation ...), Could this be added? > Does it lead to any additional security requirements specifically for > the ANCP Discovery phase? or peering phase? > > In fact, the setup phase is among the protocol details, which will > change nothing in the requirements. > The draft could mention something about "initiating the ANCP > communication". This is already in the draft, but maybe should be > made more clear. Yes, I think that would help. > > section 7.4: > There is an additional type of DOS attack that, I think, is not > discussed in the current text. Since, in some mode of operation of > ANCP for multicast, an IGMP join/leave received on AN validly > triggers an ANCP message from AN to NAS, a HGW/CPE can effectively > achieve a NAS DOS by generating heaps of IGMP join/leaves. I believe > this is worth discussing separately because it cannot be addressed > solely through security mechanisms inside the ANCP protocol. This > risk is discussed in section "6. Security Considerations" of draft- > maglione. Could the corresponding text describing the risk be > incorporated here in section 7.4(with appropraite editing if needed)? > > The mentioned risk is not clear for me, I could not understand if > the risk is DoS or anything else, as the section firstly discusses > DoS then mentions the risk. I believe the group has agreed to _optionally_ allow an _optional_ model whereby a join/leave from an enduser will trigger one ANCP query/response between AN and NAS. If an end-device decides to issue join/leave at very high rate, this can translate into very high rates of ANCP query/response. I believe this is a specific additional risk because this can happen even if the AN and NAS are fully secured (ie authenticated/authorized to each other). I believe this risk can translate into a DOS attack, but I leave it up to you how to best categorize this risk I would expect that the ancp-security I-D should describe this sort of risk (without having to assume details of ANCP protocols), explain that pure ANCP protocol security mechanisms like authentication, integrity protection, encryption, that may be operating between AN and NAS, do NOT protect against this risk and therefore the ANCP protocol spec needs to think about this and hopefully make some recommendations. > > > Section "6. Security Considerations" of draft-maglione also > recommends specific mitigation approaches for this ("To mitigate this > risk,..."). Could this recommendation be added in section 8 of ancp- > security? > > The cited recommendations go into solutions details, which is not > our objective in Section 8 in our draft (which only gives > requirements). > Indeed, overload is something that is not handled in the draft, but > is concerning the scalability of the protocol solution (so not the > scope of the security draft). In any case, it is a good idea to add > something about overload/scalability to the draft without > specifying where it could come from. We need to strike the right balance between being too specific and being too generic. You may be right that the mechanisms discussed in ancp-mcast may be a little too solution-specific. At the same time, saying something like "the ANCP protocol must be scalable and robust" would not be very helpful. Perhaps the right balance would be to : (i) explain that ANCP protocol security mechanisms like authentication/encryption cannot protect against that risk (ii) specific mechanism for this risk should be discussed in protocol document > > > section 7.4: > One of the functions that ANCP has to enable for multicast is > accounting. So a specific additional risk associated with the > multicast use cases is tempering with accounting information (eg > escaping charging or conversely over-charging another user). > Could you add a statement to that effect? For example, perhaps, at > teh very end of section 7.4 we could add: > " * Messages's modifications to temper with accounting > information, > for example in order to avoid service charges or conversely in order > to artificially increase service charges on other users" > > In this case, we handle the security of the "information" sent > between the AN and the NAS without further detailing what this > information is, which can be accounting information (so in fact, it > is covered in the draft). But something may be mentioned saying > that "since this information can be used for accounting, it is > possible to have attacks". Yes, I would find it useful then to have "accounting" being mentioned as a specific example of information and mention the corresponding attacks. > > > section 8: > Based on discussions on the list re multicast use case security > aspects, I'd suggest adding requirements along the line of > " o The protocol solution SHOULD ensure that, by default, IGMP > join/leave requests received by AN are only relayed to NAS for those > multicast flows that have been explicitly identified before by the > NAS through ANCP" > > Actually, this is a solution for multicast. There are other > solutions where this is not relevant. I don't fully get what you're saying here. Are you saying that: (i) the above requirements only applies to the multicast use-case , or (ii) the above requirements is only applicable to one particular protocol solution to handle multicast? If (i), then yes. But it is still a valid concern/requirement for multicast use-case. If (ii), then you could try make it a bit more generic (like "the protocol should ensure that operations in default configuration guarantees low level of AN/NAS protocol interactions"). Saying nothing about this problem is not very helpful. There has been several messages on the list expressing a security consideration on that exact issue and we are modifying the ANCP proposal to address it. ancp-security ought to document such security requirements. > > > section 8: > In case of DOS attacks on NAS as a result of IGMP leave/joins > resulting in ANCP messages from AN to NAS, we would want the NAS to > be able to stop ANCP messages generated by the AN. I would suggest > adding a requirement along the lines of: > " o The protocol solution MUST allow the NAS to instruct the AN > to stop issuing ANCP messages to the NAS on join/leave (i) from a > particular AN port , (ii) for a particular multicast flow (or ranges > of multicast flows) or (iii) combination thereof." > > There is a requirment in the draft (The protocol solution MUST be > robust against DoS). Such requirment covers the case that you > state. However if the case is mentioned as you describe, we believe > that it will go into solutions description which is not the > objective of our draft. Indeed, the requirement is that the > protocol MUST be robust against DoS attacks, how it is done is not > the scope of the draft. Again, my view is that requirements like " the protocol must be secure, scalable, robust and protect against DOS attacks" are of limited value for developing the ANCP protocol. I think we need to go one level more specific. If the requirement proposed above is too specific, perhaps it could be generalized along the lines of: "the protocol MUST facilitate pushing of DOS mitigation enforcement from the NAS into the AN". Just to be clear, all I am saying is that we want to make sure that in case there is some attack resulting in a high ANCP load on NAS, we want to facilitate pushing some rule in AN via ANCP to basically block the attack at the level of the AN. > > section 7.4: > s/this allows the NAS to follow subscribers' multicast (source, > group) membership/this allows the NAS to follow subscribers' > multicast (source, group) membership and control replication > performed by the AN./ > > Actually, this is too specific. There is no agreement on how the > solution will look like. There is no agreement as to the protocol details. However I believe there is clear agreement on the fact that ANCP will _optionally_ allow decision to be taken by the NAS and replication control in AN controlled via ANCP. Please see the ANCP WG minutes. In particular the final conclusion of the discussion: " Woj: Take flexibility as key thing. Lot of support, individual opposition. " > So, we should not mention things for which the framework does not > mention anything. > Since a considerable number of people is against that the NAS > controls the replication in the AN, This has been extensively discussed in Chicago. I heard Roberta, Francois, Mike Mc Bride (PIM WG Chair), Hiroshi Ohta (MBONED chair), Sanjay and Curtis expressing support for NAS control. I heard only Dong expressing concerns with NAS control. > because the zapping delay becomes too high with such a solution, so > let's wait with this. In any case, I understand there is WG agreement to allow this optional flexibility. If you woudl like to revert that decision, please discuss this specifically on the list, but for now I think we should adhere to the current decision. Cheers Francois --Apple-Mail-17--776777552 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hasnaa,

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


Section 7:
In addition to discussing attacks against the 4 = uses cases, I suspect
there would be value in discussing attacks = during the "Protocol
establishment phase" (ie ANCP discovery phase, = ANCP peering
establishment, ANCP Capability negotiation ...), Could = this be added?
Does it lead to any additional security requirements = specifically for
the ANCP Discovery phase? or peering phase? =
=A0
In fact, the setup phase is among the protocol details, which = will change nothing in the requirements.
The draft could mention something about "initiating the ANCP = communication".=A0This is already in the draft, but maybe should be made = more clear. =A0

Yes, I think that would = help.

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

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

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


=A0

Section "6. Security Considerations" of draft-maglione = also
recommends specific mitigation approaches for this ("To mitigate = this
risk,..."). Could this recommendation be added in section 8 of = ancp-
security?
=A0
The cited recommendations go into solutions details, which is = not our objective in Section 8 in our draft (which only gives = requirements).
Indeed, = overload is something that is not handled in the draft, but=A0is = concerning the scalability of the protocol solution (so not the scope of = the security draft). In any case, it is a good idea to add something = about overload/scalability to the draft without specifying where it = could come = from.

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

=A0

section 7.4:
One of the functions = that ANCP has to enable for multicast is
accounting. So a specific = additional risk associated with the
multicast use cases is tempering = with accounting information (eg
escaping charging or conversely = over-charging another user).
Could you add a statement to that = effect? For example, perhaps, at
teh very end of section 7.4 we could = add:
"=A0=A0=A0=A0=A0=A0 *=A0=A0 Messages's modifications to temper = with accounting information,
for example in order to avoid service = charges or conversely in order
to artificially increase service = charges on other users"
=A0
In this case, we handle the security of the = "information" sent between the AN and the NAS without further detailing = what this information is, which can be accounting information (so in = fact, it is covered in the draft). But something may be mentioned saying = that "since this information can be used for accounting, it is possible = to have attacks".

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

=
=A0

=
section 8:
Based on = discussions on the list re multicast use case security
aspects, I'd = suggest adding requirements along the line of
"=A0=A0 o=A0=A0=A0=A0The= protocol solution SHOULD ensure that, by default, IGMP
join/leave = requests received by AN are only relayed to NAS for those
multicast = flows that have been explicitly identified before by the
NAS through = ANCP"
=A0
Actually, this is a solution for multicast. There are other = solutions where this is not = relevant.=A0

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

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

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

=A0

section 8:
In case of DOS attacks = on NAS as a result of IGMP leave/joins
resulting in ANCP messages = from AN to NAS, we would want the NAS to
be able to stop ANCP = messages generated by the AN. I would suggest
adding a requirement = along the lines of:
"=A0=A0 o=A0=A0=A0=A0The protocol solution MUST = allow the NAS to instruct the AN
to stop issuing ANCP messages to the = NAS on join/leave (i) from a
particular AN port , (ii) for a = particular multicast flow (or ranges
of multicast flows) or (iii) = combination thereof."
=A0
There is a requirment=A0in the draft (The = protocol solution=A0MUST be robust against DoS).=A0=A0Such requirment = covers the case that you state. However if the case is mentioned as you = describe, we believe that it will go into solutions description which is = not the objective of our draft. Indeed, the requirement is that the = protocol MUST be robust against DoS attacks, how it is done is not the = scope of the draft.

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


section 7.4:
s/this allows the = NAS to follow subscribers' multicast (source,
group) membership/this = allows the NAS to follow subscribers'
multicast (source, group) = membership and control replication
performed by the AN./
=
=A0
Actually, this is too specific. There is no = agreement on how the solution will look like. =

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

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

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

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


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

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

Cheers

Francois
= --Apple-Mail-17--776777552-- --===============2003596245== 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 --===============2003596245==-- From ancp-bounces@ietf.org Tue Sep 18 17:37: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 1IXkky-0007Nz-Jn; Tue, 18 Sep 2007 17:37:20 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IXkkw-0007N5-PZ for ancp-confirm+ok@megatron.ietf.org; Tue, 18 Sep 2007 17:37:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXkkw-0007Mx-Fb for ancp@ietf.org; Tue, 18 Sep 2007 17:37:18 -0400 Received: from exprod7og55.obsmtp.com ([64.18.2.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXkkq-0004Yp-1u for ancp@ietf.org; Tue, 18 Sep 2007 17:37:18 -0400 Received: from source ([66.129.224.36]) by exprod7ob55.obsmtp.com ([64.18.6.12]) with SMTP; Tue, 18 Sep 2007 14:36:54 PDT Received: from beta.jnpr.net ([172.24.18.109]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 14:36:49 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 14:36:49 -0700 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: [ANCP] ANCP WG follow-up Date: Tue, 18 Sep 2007 17:36:44 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2803B76378@proton.jnpr.net> In-Reply-To: <993FAD2C-746F-4F59-B523-CF2CCA1BEFD0@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP WG follow-up Thread-Index: AcfwcDLhEbEgGkYMSc+Nth9qqjtKBQJxaA1A From: "Sanjay Wadhwa" To: "Francois Le Faucheur IMAP" X-OriginalArrivalTime: 18 Sep 2007 21:36:49.0486 (UTC) FILETIME=[052856E0:01C7FA3C] X-Spam-Score: -4.0 (----) X-Scan-Signature: b5216aa5b0df24d46eaed76d4f65aa31 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 Francois Reviving the thread... Please see inline.=20 >-----Original Message----- >From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] >Sent: Thursday, September 06, 2007 6:25 AM >To: Sanjay Wadhwa >Cc: Francois Le Faucheur IMAP; Wojciech Dec (wdec); ancp@ietf.org; >Matthew.Bocci@alcatel-lucent.co.uk >Subject: Re: [ANCP] ANCP WG follow-up > > >Hi Sanjay, > >> >> Adding message flows from draft-maglione to the framework draft is >> solution-creep, which has been avoided until now. Message flows in >> draft-maglione are tied to the proposed solution. As an example =20 >> consider >> the message flow in figure 9 from the draft. > >The topic of "what belongs to the framework draft and what belongs to =20 >the protocol draft" has come up before. I believe the agreed =20 >conclusion is: > * the framework document ought to include: > (1) requirements > (2) use-cases > (3) primitives/parameters (REPEAT: primitives=20 >and parameters) > * the protocol document ought to include: > (1) actual message flows. >This is what has been done for all the existing use cases in the =20 >current framework. >I believe this is what we have also re-established during the Chicago =20 >meeting. > >Do you agree with this breakout? I don't think we are dis-agreeing. However, I want to clarify the following (at the risk of repeating).=20 Draft-maglione defines one possible option/architecture for multicast, where per-subscriber IGMP terminates on the DSLAM. It is reasonable for the framework draft to describe this as *one* of the possible options for multicast, and for this option, it is also reasonable to define high-level exchange between AN and BNG to implement each of the use-cases (e.g. it is reasonable to say and "Admission-Control-Request" in ANCP will be sent from AN to BNG on reception of IGMP).=20 One would assume the same level of detail goes in for other alternate/viable options/architectures for multicast.=20 >draft-maglione explicitly says: >"This proposal aims at collecting feedback from this community in =20 >order to work towards consensus. Eventually, text derived from the > material in section 3. and 4. would be intended to be =20 >incorporated in "ANCP Framework I-D" [1]. Similarly, text derived =20 >from the material > of section 5. would be intended to be incorporated in "ANCP =20 >Protocol I-D" [2] and to be extended with actual protocol extensions. >" >So it is NOT proposing to incorporate message flows (such as the one =20 >in figure 9) into the framework, but rather into the protocol document. I was hoping the base description of use-cases that are added into the framework draft remain generic i.e. not tied to a specific option/architecture. For example text in section 3 of draft-maglioine defines the use-cases assuming per-subscriber IGMP is terminated on the AN. Ideally, we should have a section that defines the basic use-cases in a generic manner, and then add anything that is specific to a paritcular multicast option in a sub-section specific to that option. Same goes for section 4 of the draft. It assumes a particular multicast architecture and goes into the details (including optimizations) for that architecture. >In his message below, while Woj is proposing that primitives/=20 >parameters be included into the framework, he is NOT proposing that =20 >message flows be incorporated into the framework. > >Is it clear to you now that neither the draft-maglione co-authors nor =20 >Woj are trying to push any message flow into the framework? > > >> It is related to the >> suggested solution as it refers to flow-groups in message exchange. >> >> With respect to #1 in your mail below, I am not opposed to any >> optimizations aimed at reducing message load. However, the =20 >> optimization >> as a concept has to gurantee correctness and simplicity,=20 >both of which >> are independent of the protocol messages used to implement the =20 >> concept. >> A more constructive approach would be for the authors of the draft to >> consider issues raised thus far to ensure a workable solution, before >> any push from WG chair for inclusion of content into the framework >> draft. > >Yes, we need to further discuss the comments/suggestions brought up =20 >on the list on the primitives discussed in draft-maglione before they =20 >can be incorporated in the framework document. We'll try get onto =20 >this soon, and see if we can work towards some converged approach. > >> >> With respect to #2, draft-maglione requires/mandates IGMP=20 >snooping and >> full IGMP control on the AN, which is a valid option.=20 >However, we also >> need to consider the option where the AN does the replication, but is >> not burdened with all the associated IGMP control. > >If the WG decides to incorporate that approach into the framework =20 >also, a possible approach could be to try make the draft-maglione =20 >approach more explicitly modular whereby one could either : > - deploy the full ANCP solution : ie ANCP for relaying=20 >leave/join =20 >from AN to BNG + ANCP for controlling replication by BNG, or > - hybrid solution: ie IGMP for relaying leave/join from=20 >AN to BNG + =20 >ANCP for controlling replication by BNG The option I alluded to is IGMP from RG to BNG, and replication on the AN. The replication state on the AN created/controlled via ANCP by BNG. An optimization could be optional transparent snooping of IGMP on the AN to act on IGMP reports for leave only (to implement "fast leave").=20 Thanks -Sanjay >It would be good to hear other opinions from WG about whether we need =20 >to do this. > >Cheers > >Francois > >> And again this has >> nothing to do with ATM or Ethernet in the aggregation network. >> The concreate proposal is for the "Home Gateway" to send per-=20 >> subscriber >> IGMP to the BNG, which triggers per-subscriber conditional-access, >> admission-control, and accounting on the BNG. If both access and >> admission control passes, the BNG can use ANCP to set multicast >> replication state on the AN. >> A variation here could be that the AN transparently snoops, but >> autonomously acts on IGMP leaves to implement a "fast=20 >leave". However, >> the creation of the replication state on AN is still=20 >controlled by the >> BNG via ANCP, subject to access and admission control. >> >> Regards >> -Sanjay >> >> >> >> -----Original Message----- >> From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] >> Sent: Wednesday, September 05, 2007 6:43 AM >> To: Sanjay Wadhwa; ancp@ietf.org; Matthew.Bocci@alcatel-lucent.co.uk >> Subject: RE: [ANCP] ANCP WG follow-up >> >> Sanjay, >> >> The framework document is the place to define the message =20 >> primitives and >> use-cases - this is intended not to drive any specific solution but >> rather the overall fundamental protocol messaging capability. I would >> also like to point out that this is not *my* suggestion, but rather =20 >> the >> conclusion reached by the WG at the meeting. >> Flow groups or not, the primitives that appear to be required for the >> multicast case(s) are the Request/Response ones (see Figure 1 of the >> ancp-framework document for an example of other primitives). So, to >> re-iterate the direction for the WG is to; >> * include in the framework document such message primitives and a >> description of the use-cases. >> * Work on message specifics for protocol draft. >> In the above review and comments on the specific text for each of the >> drafts will take place as usual though discussion on the alias. >> >> Now let's delve into the two specific issues you raise and=20 >open up the >> discussion to the WG as a whole: >> >> 1. The flow-group concept is generally understood to be an=20 >intended to >> reduce/optimize the number of ANCP messaging transactions subject to >> certain conditions related to the multicast-use case(s).=20 >This seems to >> be a worthwhile goal, and even though the current flow-group text =20 >> is not >> perfect and protocol details are not sufficient, there is no other >> optimization mechanism on the table. It's clearly up to=20 >further debate >> by the WG on how the optimization behaviour should be realized in >> protocol specifics, eg by using a type-of-Response message, or =20 >> though a >> change-of-configuration message. >> >> Now, could you, or anyone present an alternative proposal for such >> optimization? Or are you objecting to the whole concept? >> >> 2. Alternative Deployment scenarios. >> Can you please prepare a *concrete proposal* regarding the scenario =20 >> you >> describe, and the modifications to the high-level (primitives) =20 >> mechanism >> in draft-maglione required to support it? Before this is presented, >> saying that there are other "viable deployment scenarios" is not very >> constructive and doesn't allow the WG to make an assessment=20 >on what to >> do with it. >> >> Regards, >> Woj. >> >> >>> -----Original Message----- >>> From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] >>> Sent: 04 September 2007 15:18 >>> To: Wojciech Dec (wdec); ancp@ietf.org; >>> Matthew.Bocci@alcatel-lucent.co.uk >>> Subject: RE: [ANCP] ANCP WG follow-up >>> >>> Woj >>> There are questions with the flow-group concept (and other >>> mechanisms in the draft), that have already been raised in email >>> threads. Since you are suggesting, the framework document should >>> contain message flows for a specific solution, it needs to be made >>> sure that the solution is a workable solution, and does not ignore >>> viable deployment options, before we do anything with the framework >>> draft. >>> Ideally, the framework draft should not contain message flows for a >>> specific solution/implementation. >>> >>> On the second issue, IGMP snooping capability or lack of=20 >(for both IP >>> and PPP) on an "AN" or the necessity for a deployment to use it, if >>> supported, has nothing to do with ATM or Ethernet. By lumping these >>> together one could conveniently ignore viable deployment scenarios, >>> which is not justified. >>> There are tier-1 deployments today, where the replication as well as >>> all the necessary multicast control happens on the BNG. It is >>> desirable to move the replication to the AN. >>> However, this should not come with the need and complexity to move =20 >>> all >> >>> the necessary multicast control processing to the AN. >>> >>> The use-cases for both models are the same (conditional access, >>> multi-service CAC, accounting etc). The message-flows, *complexity* >>> and the extent to which ANCP is leveraged in each case is different. >>> >>> Regards >>> -Sanjay >>> >>> -----Original Message----- >>> From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] >>> Sent: Tuesday, September 04, 2007 7:03 AM >>> To: Sanjay Wadhwa; ancp@ietf.org; Matthew.Bocci@alcatel-lucent.co.uk >>> Subject: RE: [ANCP] ANCP WG follow-up >>> >>> Sanjay, >>> >>> The points you raise regarding more specifics around flow groups are >>> fine, and should take place on the alias as part of the work on the >>> protocol draft text. >>> Also for scenarios where the AN is not capable of for example IGMP >>> processing (which is precisely the functional model you seem to say >>> needs to be added), feel free to propose for discussion the use-case >>> and a mechanism that fits with the draft-maglione proposal. >>> >>> As a side-note: I do remember hearing from several group=20 >participants >>> opinions that "legacy ATM" use-cases (and non IGMP capable >>> access-nodes could likely fall in that category) should be placed =20 >>> on a >> >>> lower footing than the others in relation to new use-cases. The >>> complexity of any mechanism aimed at supporting these use-cases in >>> this category vs their benefit needs to be one of the considerations >>> for the WG. >>> >>> Regards, >>> Woj. >>> >>>> -----Original Message----- >>>> From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] >>>> Sent: 04 September 2007 06:50 >>>> To: Wojciech Dec (wdec); ancp@ietf.org; >>>> Matthew.Bocci@alcatel-lucent.co.uk >>>> Subject: RE: [ANCP] ANCP WG follow-up >>>> >>>> Woj/Matthew >>>> There was some support for multicast use-cases in >>> general amongst >>>> the folks who were in attendence at the last WG meeting. However, >>>> specifally on draft-maglione, while it sets good context for the >>>> multicast use cases, the mechanism (and corresponding >>> message flows) >>>> suggested in the draft only cover a single deployment scenario. It >>>> does not cover the case where the AN does not do or is incapable of >>>> IGMP snooping, and the BNG controls the replication on the AN via >>>> ANCP. >>>> Adding general text on multicast use-cases (conditional >>>> access/CAC/accounting) in the framework draft is fine. >>>> However, choosing a single deployment model, and adding >>> message flows >>>> for it in the framework draft, is not ideal. >>>> Also, there were specific questions raised on the mailing >>> list on some >>>> of the suggestions in the draft (specifically pertaining to >>> flow-group >>>> optimization). We haven't seen any responses. >>>> IMHO, we need to make progress on both these fronts (describing >>>> alternate deployment model, and providing clarity on mechanisms >>>> defined in draft-maglione) before we can make progress on adding >>>> detailed message flows and corresponding protocol machinery to >>>> framework and protocol drafts. >>>> >>>> Regards >>>> -Sanjay >>>> >>>>> -----Original Message----- >>>>> From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] >>>>> Sent: Monday, September 03, 2007 8:39 AM >>>>> To: ancp@ietf.org >>>>> Subject: [ANCP] ANCP WG follow-up >>>>> >>>>> >>>>> Hi All, >>>>> >>>>> At the recent IETF meeting we've heard a fair amount of debate >>>>> regarding the subject of multicast. The debate spanned >>>> multiple camps >>>>> and went over both the whys, the why not's, as well as >>> pros and cons. >>>>> The general >>>>> consensus formed at the meeting was that the framework and >>>> requirements >>>>> document needs to cover all use cases to the same level of >>>> depth, and >>>>> to have sufficient detail to design the protocol. This in >>>> effect means >>>>> the definition of the message primitives for supporting the >>>>> use-case(s). >>>>> We also heard there being significantly more support than not for >>>>> introducing into the protocol the flexibility offered by the >>>>> request-response message set as proposed in draft-maglione, >>>> along with >>>>> the use-cases. Hence, we would like to confirm the following >>>> direction >>>>> with the working group for carrying out the following two points: >>>>> >>>>> 1. Introduce into the latest draft-ietf-ancp-framework >>>> changes and text >>>>> that covers the following: >>>>> - High level message diagram including query/response primitives >>>>> - Description of the following multicast-use cases; >>>>> * Multicast Conditional Access >>>>> * Multicast Admission Control >>>>> * Multicast Accounting >>>>> * Multicast Termination >>>>> >>>>> Some solidification of the final text will be required and >>> ought to >>>>> take place on the alias. For the above however >>>> draft-maglione appears >>>>> to contain a fair base of the material required. >>>>> >>>>> 2. The WG commences work on defining the necessary protocol >>>> extensions >>>>> for inclusion in draft-ietf-ancp-protocol, based on the protocol >>>>> specific text in draft-maglione. >>>>> >>>>> Regards, >>>>> Woj and Matthew. >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Sep 19 03:52:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXuMY-0000mv-Po; Wed, 19 Sep 2007 03:52:46 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IXuMX-0000mp-O2 for ancp-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 03:52:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXuMW-0000kv-TL for ancp@ietf.org; Wed, 19 Sep 2007 03:52:44 -0400 Received: from smail5.alcatel.fr ([62.23.212.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXuMU-0007mb-UK for ancp@ietf.org; Wed, 19 Sep 2007 03:52:44 -0400 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8J7pvDP027694; Wed, 19 Sep 2007 09:51:57 +0200 Received: from [172.31.131.203] ([172.31.131.203]) by FRVELSBHS06.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Wed, 19 Sep 2007 09:52:38 +0200 Message-ID: <46F0D541.9070701@alcatel-lucent.be> Date: Wed, 19 Sep 2007 09:52:33 +0200 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: Francois Le Faucheur IMAP References: <8389FA73-DB6E-405C-85BF-83685E709432@cisco.com> In-Reply-To: <8389FA73-DB6E-405C-85BF-83685E709432@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Sep 2007 07:52:38.0471 (UTC) FILETIME=[0C780570:01C7FA92] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Cc: ancp@ietf.org Subject: [ANCP] Re: ANCP Digest, Vol 16, Issue 6 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 Francois, The DOS attacks that a user might create by sending many IGMP messages, is indeed a security problem totally missing in the draft and has to be added. The DOS attacks mentioned in the draft, and the mechanisms like authentication are not related to it, so this new type of DOS attack has to be discussed seperately. The draft will however not propose any solutions for it, just like the draft does not propose any solutions for authentication, or for the other threats. I can imagine many solutions for it (e.g., AN already can do a lot to protect itself independent from ANCP, and creating extra filters (say ACL lists) in the AN to limit the ANCP messages). see further below... Francois Le Faucheur IMAP wrote: > Hasnaa, > > Thanks for looking into my comments. > I cut out all the points which are closed/agreed. A few more thoughts on > remaining ones below: > >> >> Section 7: >> In addition to discussing attacks against the 4 uses cases, I suspect >> there would be value in discussing attacks during the "Protocol >> establishment phase" (ie ANCP discovery phase, ANCP peering >> establishment, ANCP Capability negotiation ...), Could this be added? >> Does it lead to any additional security requirements specifically for >> the ANCP Discovery phase? or peering phase? >> >> >> In fact, the setup phase is among the protocol details, which will >> change nothing in the requirements. >> The draft could mention something about "initiating the ANCP >> communication". This is already in the draft, but maybe should be made >> more clear. > > > Yes, I think that would help. > >> >> >> section 7.4: >> There is an additional type of DOS attack that, I think, is not >> discussed in the current text. Since, in some mode of operation of >> ANCP for multicast, an IGMP join/leave received on AN validly >> triggers an ANCP message from AN to NAS, a HGW/CPE can effectively >> achieve a NAS DOS by generating heaps of IGMP join/leaves. I believe >> this is worth discussing separately because it cannot be addressed >> solely through security mechanisms inside the ANCP protocol. This >> risk is discussed in section "6. Security Considerations" of draft- >> maglione. Could the corresponding text describing the risk be >> incorporated here in section 7.4(with appropraite editing if needed)? >> >> >> The mentioned risk is not clear for me, I could not understand if the >> risk is DoS or anything else, as the section firstly discusses DoS >> then mentions the risk. > > > I believe the group has agreed to _optionally_ allow an _optional_ > model whereby a join/leave from an enduser will trigger one ANCP > query/response between AN and NAS. > If an end-device decides to issue join/leave at very high rate, this can > translate into very high rates of ANCP query/response. I believe this is > a specific additional risk because this can happen even if the AN and > NAS are fully secured (ie authenticated/authorized to each other). > I believe this risk can translate into a DOS attack, but I leave it up > to you how to best categorize this risk > > I would expect that the ancp-security I-D should describe this sort of > risk (without having to assume details of ANCP protocols), explain that > pure ANCP protocol security mechanisms like authentication, integrity > protection, encryption, that may be operating between AN and NAS, do > NOT protect against this risk and therefore the ANCP protocol spec needs > to think about this and hopefully make some recommendations. > > >> >> >> Section "6. Security Considerations" of draft-maglione also >> recommends specific mitigation approaches for this ("To mitigate this >> risk,..."). Could this recommendation be added in section 8 of ancp- >> security? >> >> >> The cited recommendations go into solutions details, which is not our >> objective in Section 8 in our draft (which only gives requirements). >> Indeed, overload is something that is not handled in the draft, but is >> concerning the scalability of the protocol solution (so not the scope >> of the security draft). In any case, it is a good idea to add >> something about overload/scalability to the draft without specifying >> where it could come from. > > > We need to strike the right balance between being too specific and being > too generic. You may be right that the mechanisms discussed in > ancp-mcast may be a little too solution-specific. At the same time, > saying something like "the ANCP protocol must be scalable and robust" > would not be very helpful. Perhaps the right balance would be to : > (i) explain that ANCP protocol security mechanisms like > authentication/encryption cannot protect against that risk > (ii) specific mechanism for this risk should be discussed in protocol > document > >> >> >> section 7.4: >> One of the functions that ANCP has to enable for multicast is >> accounting. So a specific additional risk associated with the >> multicast use cases is tempering with accounting information (eg >> escaping charging or conversely over-charging another user). >> Could you add a statement to that effect? For example, perhaps, at >> teh very end of section 7.4 we could add: >> " * Messages's modifications to temper with accounting >> information, >> for example in order to avoid service charges or conversely in order >> to artificially increase service charges on other users" >> >> >> In this case, we handle the security of the "information" sent between >> the AN and the NAS without further detailing what this information is, >> which can be accounting information (so in fact, it is covered in the >> draft). But something may be mentioned saying that "since this >> information can be used for accounting, it is possible to have attacks". > > > Yes, I would find it useful then to have "accounting" being mentioned as > a specific example of information and mention the corresponding attacks. > >> >> >> section 8: >> Based on discussions on the list re multicast use case security >> aspects, I'd suggest adding requirements along the line of >> " o The protocol solution SHOULD ensure that, by default, IGMP >> join/leave requests received by AN are only relayed to NAS for those >> multicast flows that have been explicitly identified before by the >> NAS through ANCP" >> >> >> Actually, this is a solution for multicast. There are other solutions >> where this is not relevant. > > > I don't fully get what you're saying here. > Are you saying that: > (i) the above requirements only applies to the multicast use-case , or > (ii) the above requirements is only applicable to one particular > protocol solution to handle multicast? > > If (i), then yes. But it is still a valid concern/requirement for > multicast use-case. > If (ii), then you could try make it a bit more generic (like "the > protocol should ensure that operations in default configuration > guarantees low level of AN/NAS protocol interactions"). > As said above, saying something like "The protocol solution SHOULD ensure that, by default, IGMP join/leave requests received by AN are only relayed to NAS for those multicast flows that have been explicitly identified before by the NAS through ANCP" is one way to achieve it and you second wording above sounds better. In fact the first requirement also has problems in the sense that as soon the AN is allowed to sent IGMP requests to the NAS for 1 multicast stream, an attacker might send many join/leaves for this multicast stream and then no security issue is solved. Even when the AN has been explicitely configured to send requests to the NAS, it still has to limit the protocol exchange in some way. > Saying nothing about this problem is not very helpful. There has been > several messages on the list expressing a security consideration on that > exact issue and we are modifying the ANCP proposal to address it. > ancp-security ought to document such security requirements. > >> >> >> section 8: >> In case of DOS attacks on NAS as a result of IGMP leave/joins >> resulting in ANCP messages from AN to NAS, we would want the NAS to >> be able to stop ANCP messages generated by the AN. I would suggest >> adding a requirement along the lines of: >> " o The protocol solution MUST allow the NAS to instruct the AN >> to stop issuing ANCP messages to the NAS on join/leave (i) from a >> particular AN port , (ii) for a particular multicast flow (or ranges >> of multicast flows) or (iii) combination thereof." >> >> >> There is a requirment in the draft (The protocol solution MUST be >> robust against DoS). Such requirment covers the case that you state. >> However if the case is mentioned as you describe, we believe that it >> will go into solutions description which is not the objective of our >> draft. Indeed, the requirement is that the protocol MUST be robust >> against DoS attacks, how it is done is not the scope of the draft. > > > Again, my view is that requirements like " the protocol must be secure, > scalable, robust and protect against DOS attacks" are of limited value > for developing the ANCP protocol. I think we need to go one level more > specific. > If the requirement proposed above is too specific, perhaps it could > be generalized along the lines of: > "the protocol MUST facilitate pushing of DOS mitigation enforcement from > the NAS into the AN". > Just to be clear, all I am saying is that we want to make sure that in > case there is some attack resulting in a high ANCP load on NAS, we want > to facilitate pushing some rule in AN via ANCP to basically block the > attack at the level of the AN. > >> >> section 7.4: >> s/this allows the NAS to follow subscribers' multicast (source, >> group) membership/this allows the NAS to follow subscribers' >> multicast (source, group) membership and control replication >> performed by the AN./ >> >> >> Actually, this is too specific. There is no agreement on how the >> solution will look like. > > > There is no agreement as to the protocol details. > However I believe there is clear agreement on the fact that ANCP will > _optionally_ allow decision to be taken by the NAS and replication > control in AN controlled via ANCP. For all use cases, the framework document is not listing the exact parameters/information that is exchanged between AN and NAS, and hence also in the security draft we are not further detailing this. If it is agreed to furhter describe details, then the security draft has to follow that. Apparantly specificaly for the multicast use case there is interest to make the high level description more detailed, and that's good for the security draft because then also more specific security issues can be discussed. regards, Stefaan > > Please see the ANCP WG minutes. In particular the final conclusion of > the discussion: > " > Woj: Take flexibility as key thing. Lot of support, individual opposition. > " > >> So, we should not mention things for which the framework does not >> mention anything. >> Since a considerable number of people is against that the NAS controls >> the replication in the AN, > > > This has been extensively discussed in Chicago. > I heard Roberta, Francois, Mike Mc Bride (PIM WG Chair), Hiroshi Ohta > (MBONED chair), Sanjay and Curtis expressing support for NAS control. I > heard only Dong expressing concerns with NAS control. > > >> because the zapping delay becomes too high with such a solution, so >> let's wait with this. > > > In any case, I understand there is WG agreement to allow this optional > flexibility. If you woudl like to revert that decision, please discuss > this specifically on the list, but for now I think we should adhere > to the current decision. > > Cheers > > Francois _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Sep 19 04:07:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXuaA-00007I-Qp; Wed, 19 Sep 2007 04:06:50 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IXua9-00007B-W9 for ancp-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 04:06:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXua9-0008Ta-Co for ancp@ietf.org; Wed, 19 Sep 2007 04:06:49 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXua7-0008Hg-PK for ancp@ietf.org; Wed, 19 Sep 2007 04:06:49 -0400 X-IronPort-AV: E=Sophos;i="4.20,272,1186351200"; d="scan'208";a="153534672" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 Sep 2007 10:06:45 +0200 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 l8J86j3D031273; Wed, 19 Sep 2007 10:06:45 +0200 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 l8J86etX018905; Wed, 19 Sep 2007 08:06:44 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 10:06:40 +0200 Received: from [144.254.53.188] ([144.254.53.188]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 10:06:39 +0200 In-Reply-To: <46F0D541.9070701@alcatel-lucent.be> References: <8389FA73-DB6E-405C-85BF-83685E709432@cisco.com> <46F0D541.9070701@alcatel-lucent.be> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7C183AE1-6571-46E1-A350-B8E2F568E3DA@cisco.com> Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Date: Wed, 19 Sep 2007 10:06:29 +0200 To: Stefaan DE CNODDER X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 19 Sep 2007 08:06:39.0706 (UTC) FILETIME=[01E24BA0:01C7FA94] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12935; t=1190189205; x=1191053205; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20ANCP=20Digest,=20Vol=2016,=20Issue=206 |Sender:=20; bh=5/zQ5fsM8uDvnvJ399p8CyETdAcVheQs1rUz3R9I3vc=; b=bsnCq4FJForuibrP1AoJKMF207gj9m/fUkGe07QzGNCupSORL8pUWKPiRfJQEmqMkCjHOFV0 teC9CoJXZONCfLU7ct5WIlSa4djN1zttDFs1NfmVhV13ol/vL+FwbpSR; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Cc: ancp@ietf.org Subject: [ANCP] Re: ANCP Digest, Vol 16, Issue 6 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 Stefaan, On 19 Sep 2007, at 09:52, Stefaan DE CNODDER wrote: > > Hi Francois, > > The DOS attacks that a user might create by sending many IGMP > messages, is indeed a security problem totally missing in the draft > and has to be added. The DOS attacks mentioned in the draft, and > the mechanisms like authentication are not related to it, so this > new type of DOS attack has to be discussed seperately. The draft > will however not propose any solutions for it, just like the draft > does not propose any solutions for authentication, or for the other > threats. Agreed. I am also in general agreement with your comments below. I think it will be good to have this reflected in the next version. Cheers Francois > I can imagine many solutions for it (e.g., AN already can do a lot > to protect itself independent from ANCP, and creating extra filters > (say ACL lists) in the AN to limit the ANCP messages). > > see further below... > > Francois Le Faucheur IMAP wrote: > >> Hasnaa, >> Thanks for looking into my comments. >> I cut out all the points which are closed/agreed. A few more >> thoughts on remaining ones below: >>> >>> Section 7: >>> In addition to discussing attacks against the 4 uses cases, I >>> suspect >>> there would be value in discussing attacks during the "Protocol >>> establishment phase" (ie ANCP discovery phase, ANCP peering >>> establishment, ANCP Capability negotiation ...), Could this >>> be added? >>> Does it lead to any additional security requirements >>> specifically for >>> the ANCP Discovery phase? or peering phase? >>> In fact, the setup phase is among the protocol details, which >>> will change nothing in the requirements. >>> The draft could mention something about "initiating the ANCP >>> communication". This is already in the draft, but maybe should be >>> made more clear. >> Yes, I think that would help. >>> >>> section 7.4: >>> There is an additional type of DOS attack that, I think, is not >>> discussed in the current text. Since, in some mode of >>> operation of >>> ANCP for multicast, an IGMP join/leave received on AN validly >>> triggers an ANCP message from AN to NAS, a HGW/CPE can >>> effectively >>> achieve a NAS DOS by generating heaps of IGMP join/leaves. I >>> believe >>> this is worth discussing separately because it cannot be >>> addressed >>> solely through security mechanisms inside the ANCP protocol. >>> This >>> risk is discussed in section "6. Security Considerations" of >>> draft- >>> maglione. Could the corresponding text describing the risk be >>> incorporated here in section 7.4(with appropraite editing if >>> needed)? >>> >>> The mentioned risk is not clear for me, I could not understand >>> if the risk is DoS or anything else, as the section firstly >>> discusses DoS then mentions the risk. >> I believe the group has agreed to _optionally_ allow an >> _optional_ model whereby a join/leave from an enduser will >> trigger one ANCP query/response between AN and NAS. If an end- >> device decides to issue join/leave at very high rate, this can >> translate into very high rates of ANCP query/response. I believe >> this is a specific additional risk because this can happen even if >> the AN and NAS are fully secured (ie authenticated/authorized to >> each other). >> I believe this risk can translate into a DOS attack, but I leave >> it up to you how to best categorize this risk >> I would expect that the ancp-security I-D should describe this >> sort of risk (without having to assume details of ANCP protocols), >> explain that pure ANCP protocol security mechanisms like >> authentication, integrity protection, encryption, that may be >> operating between AN and NAS, do NOT protect against this risk >> and therefore the ANCP protocol spec needs to think about this and >> hopefully make some recommendations. >>> >>> Section "6. Security Considerations" of draft-maglione also >>> recommends specific mitigation approaches for this ("To >>> mitigate this >>> risk,..."). Could this recommendation be added in section 8 >>> of ancp- >>> security? >>> >>> The cited recommendations go into solutions details, which is >>> not our objective in Section 8 in our draft (which only gives >>> requirements). >>> Indeed, overload is something that is not handled in the draft, >>> but is concerning the scalability of the protocol solution (so >>> not the scope of the security draft). In any case, it is a good >>> idea to add something about overload/scalability to the draft >>> without specifying where it could come from. >> We need to strike the right balance between being too specific and >> being too generic. You may be right that the mechanisms discussed >> in ancp-mcast may be a little too solution-specific. At the same >> time, saying something like "the ANCP protocol must be scalable >> and robust" would not be very helpful. Perhaps the right balance >> would be to : >> (i) explain that ANCP protocol security mechanisms like >> authentication/encryption cannot protect against that risk >> (ii) specific mechanism for this risk should be discussed in >> protocol document >>> >>> section 7.4: >>> One of the functions that ANCP has to enable for multicast is >>> accounting. So a specific additional risk associated with the >>> multicast use cases is tempering with accounting information (eg >>> escaping charging or conversely over-charging another user). >>> Could you add a statement to that effect? For example, >>> perhaps, at >>> teh very end of section 7.4 we could add: >>> " * Messages's modifications to temper with accounting >>> information, >>> for example in order to avoid service charges or conversely >>> in order >>> to artificially increase service charges on other users" >>> In this case, we handle the security of the "information" sent >>> between the AN and the NAS without further detailing what this >>> information is, which can be accounting information (so in fact, >>> it is covered in the draft). But something may be mentioned >>> saying that "since this information can be used for accounting, >>> it is possible to have attacks". >> Yes, I would find it useful then to have "accounting" being >> mentioned as a specific example of information and mention the >> corresponding attacks. >>> >>> section 8: >>> Based on discussions on the list re multicast use case security >>> aspects, I'd suggest adding requirements along the line of >>> " o The protocol solution SHOULD ensure that, by >>> default, IGMP >>> join/leave requests received by AN are only relayed to NAS >>> for those >>> multicast flows that have been explicitly identified before >>> by the >>> NAS through ANCP" >>> >>> Actually, this is a solution for multicast. There are other >>> solutions where this is not relevant. >> I don't fully get what you're saying here. >> Are you saying that: >> (i) the above requirements only applies to the multicast use- >> case , or >> (ii) the above requirements is only applicable to one particular >> protocol solution to handle multicast? >> If (i), then yes. But it is still a valid concern/requirement for >> multicast use-case. >> If (ii), then you could try make it a bit more generic (like "the >> protocol should ensure that operations in default configuration >> guarantees low level of AN/NAS protocol interactions"). > > As said above, saying something like "The protocol solution SHOULD > ensure that, by default, IGMP join/leave requests received by AN > are only relayed to NAS for those multicast flows that have been > explicitly identified before by the NAS through ANCP" is one way to > achieve it and you second wording above sounds better. In fact the > first requirement also has problems in the sense that as soon the > AN is allowed to sent IGMP requests to the NAS for 1 multicast > stream, an attacker might send many join/leaves for this multicast > stream and then no security issue is solved. Even when the AN has > been explicitely configured to send requests to the NAS, it still > has to limit the protocol exchange in some way. > > >> Saying nothing about this problem is not very helpful. There has >> been several messages on the list expressing a security >> consideration on that exact issue and we are modifying the ANCP >> proposal to address it. ancp-security ought to document such >> security requirements. >>> >>> section 8: >>> In case of DOS attacks on NAS as a result of IGMP leave/joins >>> resulting in ANCP messages from AN to NAS, we would want the >>> NAS to >>> be able to stop ANCP messages generated by the AN. I would >>> suggest >>> adding a requirement along the lines of: >>> " o The protocol solution MUST allow the NAS to instruct >>> the AN >>> to stop issuing ANCP messages to the NAS on join/leave (i) >>> from a >>> particular AN port , (ii) for a particular multicast flow (or >>> ranges >>> of multicast flows) or (iii) combination thereof." >>> >>> There is a requirment in the draft (The protocol solution MUST >>> be robust against DoS). Such requirment covers the case that you >>> state. However if the case is mentioned as you describe, we >>> believe that it will go into solutions description which is not >>> the objective of our draft. Indeed, the requirement is that the >>> protocol MUST be robust against DoS attacks, how it is done is >>> not the scope of the draft. >> Again, my view is that requirements like " the protocol must be >> secure, scalable, robust and protect against DOS attacks" are of >> limited value for developing the ANCP protocol. I think we need to >> go one level more specific. If the requirement proposed above is >> too specific, perhaps it could be generalized along the lines of: >> "the protocol MUST facilitate pushing of DOS mitigation >> enforcement from the NAS into the AN". Just to be clear, all I am >> saying is that we want to make sure that in case there is some >> attack resulting in a high ANCP load on NAS, we want to facilitate >> pushing some rule in AN via ANCP to basically block the attack at >> the level of the AN. >>> >>> section 7.4: >>> s/this allows the NAS to follow subscribers' multicast (source, >>> group) membership/this allows the NAS to follow subscribers' >>> multicast (source, group) membership and control replication >>> performed by the AN./ >>> >>> Actually, this is too specific. There is no agreement on how the >>> solution will look like. >> There is no agreement as to the protocol details. >> However I believe there is clear agreement on the fact that ANCP >> will _optionally_ allow decision to be taken by the NAS and >> replication control in AN controlled via ANCP. > > > For all use cases, the framework document is not listing the exact > parameters/information that is exchanged between AN and NAS, and > hence also in the security draft we are not further detailing > this. If it is agreed to furhter describe details, then the > security draft has to follow that. Apparantly specificaly for the > multicast use case there is interest to make the high level > description more detailed, and that's good for the security draft > because then also more specific security issues can be discussed. > > regards, > Stefaan > > > >> Please see the ANCP WG minutes. In particular the final conclusion >> of the discussion: >> " >> Woj: Take flexibility as key thing. Lot of support, individual >> opposition. >> " >>> So, we should not mention things for which the framework does not >>> mention anything. >>> Since a considerable number of people is against that the NAS >>> controls the replication in the AN, >> This has been extensively discussed in Chicago. >> I heard Roberta, Francois, Mike Mc Bride (PIM WG Chair), Hiroshi >> Ohta (MBONED chair), Sanjay and Curtis expressing support for NAS >> control. I heard only Dong expressing concerns with NAS control. >>> because the zapping delay becomes too high with such a solution, >>> so let's wait with this. >> In any case, I understand there is WG agreement to allow this >> optional flexibility. If you woudl like to revert that decision, >> please discuss this specifically on the list, but for now I think >> we should adhere to the current decision. >> Cheers >> Francois _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Sep 19 09:56:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY02W-0003Jg-Dd; Wed, 19 Sep 2007 09:56:28 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IY02V-0003Hs-71 for ancp-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 09:56:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY02U-0003Fc-Jk for ancp@ietf.org; Wed, 19 Sep 2007 09:56:26 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IY02S-0000fo-I6 for ancp@ietf.org; Wed, 19 Sep 2007 09:56:26 -0400 X-IronPort-AV: E=Sophos;i="4.20,273,1186351200"; d="scan'208";a="153583613" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 Sep 2007 15:56:13 +0200 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 l8JDuDgj021775; Wed, 19 Sep 2007 15:56:13 +0200 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 l8JDuCtV018951; Wed, 19 Sep 2007 13:56:12 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 15:56:12 +0200 Received: from [144.254.53.188] ([144.254.53.188]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 15:56:12 +0200 In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2803B76378@proton.jnpr.net> References: <9BD5D7887235424FA97DFC223CAE3C2803B76378@proton.jnpr.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <54469D09-60CF-4AE8-8BAD-A26B9E256113@cisco.com> Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Subject: Re: [ANCP] ANCP WG follow-up Date: Wed, 19 Sep 2007 15:56:01 +0200 To: Sanjay Wadhwa X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 19 Sep 2007 13:56:12.0074 (UTC) FILETIME=[D663B0A0:01C7FAC4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=17423; t=1190210173; x=1191074173; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[ANCP]=20ANCP=20WG=20follow-up |Sender:=20; bh=rljFW19H1NajXFBjAfauPab8dVxidhLEf5V9i39Coso=; b=qT/2aCK6F8k0m8DiLnFCGsLD9uTnTaTYS1qYHY1iZZHsHH4XpJFAbrvBMeuSEiRnymET6vVM WwyOITMnVDISJXRfw6emsNS7dXiYN5Jfjgx4u3Humijiwn5mWIS1sZQc; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ce306e4307a2c0b518ae453b13efdd0 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 Sanjay and all, On 18 Sep 2007, at 23:36, Sanjay Wadhwa wrote: > Francois > Reviving the thread... Good. I think the gist of the discussion below is : 1) there is agreement that "primitives & parameters" belong to Framework I-D, that "call flows" belong to Protocol I-D, and that draft-maglione proposal is exactly in line with such a break-out 2) you raise a valid point that there are ANCP deployment variations whereby the replication on AN may be controlled by NAS via ANCP, but where the "join/leave" information may not be conveyed to NAS via ANCP. I agree the ANCP solution should allow this. We will work on a revised proposal allowing this. Francois > Please see inline. > >> -----Original Message----- >> From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] >> Sent: Thursday, September 06, 2007 6:25 AM >> To: Sanjay Wadhwa >> Cc: Francois Le Faucheur IMAP; Wojciech Dec (wdec); ancp@ietf.org; >> Matthew.Bocci@alcatel-lucent.co.uk >> Subject: Re: [ANCP] ANCP WG follow-up >> >> >> Hi Sanjay, >> >>> >>> Adding message flows from draft-maglione to the framework draft is >>> solution-creep, which has been avoided until now. Message flows in >>> draft-maglione are tied to the proposed solution. As an example >>> consider >>> the message flow in figure 9 from the draft. >> >> The topic of "what belongs to the framework draft and what belongs to >> the protocol draft" has come up before. I believe the agreed >> conclusion is: >> * the framework document ought to include: >> (1) requirements >> (2) use-cases >> (3) primitives/parameters (REPEAT: primitives >> and parameters) >> * the protocol document ought to include: >> (1) actual message flows. >> This is what has been done for all the existing use cases in the >> current framework. >> I believe this is what we have also re-established during the Chicago >> meeting. >> >> Do you agree with this breakout? > > I don't think we are dis-agreeing. However, I want to clarify the > following (at the risk of repeating). > Draft-maglione defines one possible option/architecture for multicast, > where per-subscriber IGMP terminates on the DSLAM. It is reasonable > for > the framework draft to describe this as *one* of the possible options > for multicast, and for this option, it is also reasonable to define > high-level exchange between AN and BNG to implement each of the > use-cases (e.g. it is reasonable to say and "Admission-Control- > Request" > in ANCP will be sent from AN to BNG on reception of IGMP). > One would assume the same level of detail goes in for other > alternate/viable options/architectures for multicast. > >> draft-maglione explicitly says: >> "This proposal aims at collecting feedback from this community in >> order to work towards consensus. Eventually, text derived from the >> material in section 3. and 4. would be intended to be >> incorporated in "ANCP Framework I-D" [1]. Similarly, text derived >> from the material >> of section 5. would be intended to be incorporated in "ANCP >> Protocol I-D" [2] and to be extended with actual protocol extensions. >> " >> So it is NOT proposing to incorporate message flows (such as the one >> in figure 9) into the framework, but rather into the protocol >> document. > > I was hoping the base description of use-cases that are added into the > framework draft remain generic i.e. not tied to a specific > option/architecture. For example text in section 3 of draft-maglioine > defines the use-cases assuming per-subscriber IGMP is terminated on > the > AN. Ideally, we should have a section that defines the basic use-cases > in a generic manner, and then add anything that is specific to a > paritcular multicast option in a sub-section specific to that option. > Same goes for section 4 of the draft. It assumes a particular > multicast > architecture and goes into the details (including optimizations) for > that architecture. > >> In his message below, while Woj is proposing that primitives/ >> parameters be included into the framework, he is NOT proposing that >> message flows be incorporated into the framework. >> >> Is it clear to you now that neither the draft-maglione co-authors nor >> Woj are trying to push any message flow into the framework? >> >> >>> It is related to the >>> suggested solution as it refers to flow-groups in message exchange. >>> >>> With respect to #1 in your mail below, I am not opposed to any >>> optimizations aimed at reducing message load. However, the >>> optimization >>> as a concept has to gurantee correctness and simplicity, >> both of which >>> are independent of the protocol messages used to implement the >>> concept. >>> A more constructive approach would be for the authors of the >>> draft to >>> consider issues raised thus far to ensure a workable solution, >>> before >>> any push from WG chair for inclusion of content into the framework >>> draft. >> >> Yes, we need to further discuss the comments/suggestions brought up >> on the list on the primitives discussed in draft-maglione before they >> can be incorporated in the framework document. We'll try get onto >> this soon, and see if we can work towards some converged approach. >> >>> >>> With respect to #2, draft-maglione requires/mandates IGMP >> snooping and >>> full IGMP control on the AN, which is a valid option. >> However, we also >>> need to consider the option where the AN does the replication, >>> but is >>> not burdened with all the associated IGMP control. >> >> If the WG decides to incorporate that approach into the framework >> also, a possible approach could be to try make the draft-maglione >> approach more explicitly modular whereby one could either : >> - deploy the full ANCP solution : ie ANCP for relaying >> leave/join >> from AN to BNG + ANCP for controlling replication by BNG, or >> - hybrid solution: ie IGMP for relaying leave/join from >> AN to BNG + >> ANCP for controlling replication by BNG > > The option I alluded to is IGMP from RG to BNG, and replication on the > AN. The replication state on the AN created/controlled via ANCP by > BNG. > An optimization could be optional transparent snooping of IGMP on > the AN > to act on IGMP reports for leave only (to implement "fast leave"). > > Thanks > -Sanjay > >> It would be good to hear other opinions from WG about whether we need >> to do this. >> >> Cheers >> >> Francois >> >>> And again this has >>> nothing to do with ATM or Ethernet in the aggregation network. >>> The concreate proposal is for the "Home Gateway" to send per- >>> subscriber >>> IGMP to the BNG, which triggers per-subscriber conditional-access, >>> admission-control, and accounting on the BNG. If both access and >>> admission control passes, the BNG can use ANCP to set multicast >>> replication state on the AN. >>> A variation here could be that the AN transparently snoops, but >>> autonomously acts on IGMP leaves to implement a "fast >> leave". However, >>> the creation of the replication state on AN is still >> controlled by the >>> BNG via ANCP, subject to access and admission control. >>> >>> Regards >>> -Sanjay >>> >>> >>> >>> -----Original Message----- >>> From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] >>> Sent: Wednesday, September 05, 2007 6:43 AM >>> To: Sanjay Wadhwa; ancp@ietf.org; Matthew.Bocci@alcatel-lucent.co.uk >>> Subject: RE: [ANCP] ANCP WG follow-up >>> >>> Sanjay, >>> >>> The framework document is the place to define the message >>> primitives and >>> use-cases - this is intended not to drive any specific solution but >>> rather the overall fundamental protocol messaging capability. I >>> would >>> also like to point out that this is not *my* suggestion, but rather >>> the >>> conclusion reached by the WG at the meeting. >>> Flow groups or not, the primitives that appear to be required for >>> the >>> multicast case(s) are the Request/Response ones (see Figure 1 of the >>> ancp-framework document for an example of other primitives). So, to >>> re-iterate the direction for the WG is to; >>> * include in the framework document such message primitives and a >>> description of the use-cases. >>> * Work on message specifics for protocol draft. >>> In the above review and comments on the specific text for each of >>> the >>> drafts will take place as usual though discussion on the alias. >>> >>> Now let's delve into the two specific issues you raise and >> open up the >>> discussion to the WG as a whole: >>> >>> 1. The flow-group concept is generally understood to be an >> intended to >>> reduce/optimize the number of ANCP messaging transactions subject to >>> certain conditions related to the multicast-use case(s). >> This seems to >>> be a worthwhile goal, and even though the current flow-group text >>> is not >>> perfect and protocol details are not sufficient, there is no other >>> optimization mechanism on the table. It's clearly up to >> further debate >>> by the WG on how the optimization behaviour should be realized in >>> protocol specifics, eg by using a type-of-Response message, or >>> though a >>> change-of-configuration message. >>> >>> Now, could you, or anyone present an alternative proposal for such >>> optimization? Or are you objecting to the whole concept? >>> >>> 2. Alternative Deployment scenarios. >>> Can you please prepare a *concrete proposal* regarding the scenario >>> you >>> describe, and the modifications to the high-level (primitives) >>> mechanism >>> in draft-maglione required to support it? Before this is presented, >>> saying that there are other "viable deployment scenarios" is not >>> very >>> constructive and doesn't allow the WG to make an assessment >> on what to >>> do with it. >>> >>> Regards, >>> Woj. >>> >>> >>>> -----Original Message----- >>>> From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] >>>> Sent: 04 September 2007 15:18 >>>> To: Wojciech Dec (wdec); ancp@ietf.org; >>>> Matthew.Bocci@alcatel-lucent.co.uk >>>> Subject: RE: [ANCP] ANCP WG follow-up >>>> >>>> Woj >>>> There are questions with the flow-group concept (and other >>>> mechanisms in the draft), that have already been raised in email >>>> threads. Since you are suggesting, the framework document should >>>> contain message flows for a specific solution, it needs to be made >>>> sure that the solution is a workable solution, and does not ignore >>>> viable deployment options, before we do anything with the framework >>>> draft. >>>> Ideally, the framework draft should not contain message flows for a >>>> specific solution/implementation. >>>> >>>> On the second issue, IGMP snooping capability or lack of >> (for both IP >>>> and PPP) on an "AN" or the necessity for a deployment to use it, if >>>> supported, has nothing to do with ATM or Ethernet. By lumping these >>>> together one could conveniently ignore viable deployment scenarios, >>>> which is not justified. >>>> There are tier-1 deployments today, where the replication as >>>> well as >>>> all the necessary multicast control happens on the BNG. It is >>>> desirable to move the replication to the AN. >>>> However, this should not come with the need and complexity to move >>>> all >>> >>>> the necessary multicast control processing to the AN. >>>> >>>> The use-cases for both models are the same (conditional access, >>>> multi-service CAC, accounting etc). The message-flows, *complexity* >>>> and the extent to which ANCP is leveraged in each case is >>>> different. >>>> >>>> Regards >>>> -Sanjay >>>> >>>> -----Original Message----- >>>> From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] >>>> Sent: Tuesday, September 04, 2007 7:03 AM >>>> To: Sanjay Wadhwa; ancp@ietf.org; Matthew.Bocci@alcatel- >>>> lucent.co.uk >>>> Subject: RE: [ANCP] ANCP WG follow-up >>>> >>>> Sanjay, >>>> >>>> The points you raise regarding more specifics around flow groups >>>> are >>>> fine, and should take place on the alias as part of the work on the >>>> protocol draft text. >>>> Also for scenarios where the AN is not capable of for example IGMP >>>> processing (which is precisely the functional model you seem to say >>>> needs to be added), feel free to propose for discussion the use- >>>> case >>>> and a mechanism that fits with the draft-maglione proposal. >>>> >>>> As a side-note: I do remember hearing from several group >> participants >>>> opinions that "legacy ATM" use-cases (and non IGMP capable >>>> access-nodes could likely fall in that category) should be placed >>>> on a >>> >>>> lower footing than the others in relation to new use-cases. The >>>> complexity of any mechanism aimed at supporting these use-cases in >>>> this category vs their benefit needs to be one of the >>>> considerations >>>> for the WG. >>>> >>>> Regards, >>>> Woj. >>>> >>>>> -----Original Message----- >>>>> From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] >>>>> Sent: 04 September 2007 06:50 >>>>> To: Wojciech Dec (wdec); ancp@ietf.org; >>>>> Matthew.Bocci@alcatel-lucent.co.uk >>>>> Subject: RE: [ANCP] ANCP WG follow-up >>>>> >>>>> Woj/Matthew >>>>> There was some support for multicast use-cases in >>>> general amongst >>>>> the folks who were in attendence at the last WG meeting. However, >>>>> specifally on draft-maglione, while it sets good context for the >>>>> multicast use cases, the mechanism (and corresponding >>>> message flows) >>>>> suggested in the draft only cover a single deployment scenario. It >>>>> does not cover the case where the AN does not do or is >>>>> incapable of >>>>> IGMP snooping, and the BNG controls the replication on the AN via >>>>> ANCP. >>>>> Adding general text on multicast use-cases (conditional >>>>> access/CAC/accounting) in the framework draft is fine. >>>>> However, choosing a single deployment model, and adding >>>> message flows >>>>> for it in the framework draft, is not ideal. >>>>> Also, there were specific questions raised on the mailing >>>> list on some >>>>> of the suggestions in the draft (specifically pertaining to >>>> flow-group >>>>> optimization). We haven't seen any responses. >>>>> IMHO, we need to make progress on both these fronts (describing >>>>> alternate deployment model, and providing clarity on mechanisms >>>>> defined in draft-maglione) before we can make progress on adding >>>>> detailed message flows and corresponding protocol machinery to >>>>> framework and protocol drafts. >>>>> >>>>> Regards >>>>> -Sanjay >>>>> >>>>>> -----Original Message----- >>>>>> From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] >>>>>> Sent: Monday, September 03, 2007 8:39 AM >>>>>> To: ancp@ietf.org >>>>>> Subject: [ANCP] ANCP WG follow-up >>>>>> >>>>>> >>>>>> Hi All, >>>>>> >>>>>> At the recent IETF meeting we've heard a fair amount of debate >>>>>> regarding the subject of multicast. The debate spanned >>>>> multiple camps >>>>>> and went over both the whys, the why not's, as well as >>>> pros and cons. >>>>>> The general >>>>>> consensus formed at the meeting was that the framework and >>>>> requirements >>>>>> document needs to cover all use cases to the same level of >>>>> depth, and >>>>>> to have sufficient detail to design the protocol. This in >>>>> effect means >>>>>> the definition of the message primitives for supporting the >>>>>> use-case(s). >>>>>> We also heard there being significantly more support than not for >>>>>> introducing into the protocol the flexibility offered by the >>>>>> request-response message set as proposed in draft-maglione, >>>>> along with >>>>>> the use-cases. Hence, we would like to confirm the following >>>>> direction >>>>>> with the working group for carrying out the following two points: >>>>>> >>>>>> 1. Introduce into the latest draft-ietf-ancp-framework >>>>> changes and text >>>>>> that covers the following: >>>>>> - High level message diagram including query/response primitives >>>>>> - Description of the following multicast-use cases; >>>>>> * Multicast Conditional Access >>>>>> * Multicast Admission Control >>>>>> * Multicast Accounting >>>>>> * Multicast Termination >>>>>> >>>>>> Some solidification of the final text will be required and >>>> ought to >>>>>> take place on the alias. For the above however >>>>> draft-maglione appears >>>>>> to contain a fair base of the material required. >>>>>> >>>>>> 2. The WG commences work on defining the necessary protocol >>>>> extensions >>>>>> for inclusion in draft-ietf-ancp-protocol, based on the protocol >>>>>> specific text in draft-maglione. >>>>>> >>>>>> Regards, >>>>>> Woj and Matthew. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Sep 19 10:47:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY0pV-0005FG-8i; Wed, 19 Sep 2007 10:47:05 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IY0pT-0005F3-Bm for ancp-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 10:47:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY0pT-0005Er-1N for ancp@ietf.org; Wed, 19 Sep 2007 10:47:03 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IY0pR-0003oj-DE for ancp@ietf.org; Wed, 19 Sep 2007 10:47:03 -0400 X-IronPort-AV: E=Sophos;i="4.20,273,1186351200"; d="scan'208,217";a="153590660" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 Sep 2007 16:47:00 +0200 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 l8JEl0ZX006871; Wed, 19 Sep 2007 16:47:00 +0200 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 l8JEl0tV010334; Wed, 19 Sep 2007 14:47:00 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); Wed, 19 Sep 2007 16:47:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Admission Request message Re: [ANCP] Comments on draft-maglione Date: Wed, 19 Sep 2007 16:46:43 +0200 Message-ID: In-Reply-To: <441751AB-C67D-4CF7-BACF-7A0310D37BA4@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Admission Request message Re: [ANCP] Comments on draft-maglione Thread-Index: AcfxRrlXI/dN86WbTsW33z2/7dsPeQJhKHsQ References: <9BD5D7887235424FA97DFC223CAE3C2803B76297@proton.jnpr.net> <441751AB-C67D-4CF7-BACF-7A0310D37BA4@cisco.com> From: "Wojciech Dec (wdec)" To: "Francois Le Faucheur (flefauch)" , "Sanjay Wadhwa" X-OriginalArrivalTime: 19 Sep 2007 14:47:00.0596 (UTC) FILETIME=[EF733B40:01C7FACB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7695; t=1190213220; x=1191077220; 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=20Admission=20Request=20message=20Re=3A=20[ANCP]=20Comm ents=20on=20draft-maglione |Sender:=20; bh=fKXGEbvJieeE/CA+/2X5Pym8HpnZMUZbX2b7u12UPKU=; b=qkSCqp9+4XyTVlzVc+ZMXu4XpcfOF64yhToBFaMYKzAgs4zZ5hSfKH5ikyXHopTsZD2LTOX/ kT7R6wbSVLfptfno2+9VXi92n0v96mRdti9CrmyoVT7B0gM++YdYCZ03; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 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: , Content-Type: multipart/mixed; boundary="===============1163516252==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1163516252== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7FACB.EF294EC8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7FACB.EF294EC8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Francois, =20 inline... ________________________________ From: Francois Le Faucheur (flefauch)=20 Sent: 07 September 2007 13:58 To: Sanjay Wadhwa Cc: ancp@ietf.org Subject: Admission Request message Re: [ANCP] Comments on draft-maglione =09 =09 Sanjay et al,=20 4.2 Conditional access and admission control with NAS decision It is not clear what information is required / envisaged for the Admission Request / Response messages -=20 Multicast Flow and ACI at a minimum seems to be needed. =09 The document lists the parameters for Admission Requests in the "Message Flows" section, but I agree that those need to be listed first in the "Protocol Requirements" sections. The parameters currently identified for Admission Request are: - Flow_Id - Port_Id=20 Flow_Id =3D (S,G) or (*,G) Do you see other parameters that need to be added to Admission Request?=20 =20 Woj> IMO it wouldn't hurt to allow the message to optionally carry of other info that could be derived from the received trigger, eg source MAC, and source IP address. The parameters currently identified for Admission Response are: - Accounting_Flag (which allows the NAS to tell AN if accounting is required for this flow). Do you see other parameters that need to be added to Admission Response?=20 =20 Woj> Additional parameters will be needed, especially to allow the Admission Response to be decoupled from the Request. These would then be: - Flow_Id - Target Port_id =20 Regards, Woj. It will be useful to clarify that the NAS is expected to know the BW information for the multicast flow (flow-group) for which admission control is being requested.=20 =09 Agreed. This could be locally configured on the NAS, could be provided at auth time from radius/policy server, or could be dynamically auto-sensed (measured) on the NAS. Agreed. In the future it could also potentially be explicitely signaled by the source. Francois ------_=_NextPart_001_01C7FACB.EF294EC8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Francois,
 
inline...

From: Francois Le Faucheur = (flefauch)=20
Sent: 07 September 2007 13:58
To: Sanjay=20 Wadhwa
Cc: ancp@ietf.org
Subject: Admission = Request=20 message Re: [ANCP] Comments on draft-maglione

Sanjay et al,

4.2 Conditional access and admission = control with=20 NAS decision
It is not clear what information is required / = envisaged for=20 the Admission Request / Response messages -
Multicast Flow and = ACI at a=20 minimum seems to be needed.

The document lists the parameters for Admission Requests in the = "Message=20 Flows" section, but I agree that those need to be listed first in the=20 "Protocol Requirements" sections.

The parameters currently identified for Admission Request = are:
-=20 Flow_Id
-=20 Port_Id 
Flow_Id =3D (S,G) or (*,G)
Do you see other parameters that need to be added to Admission=20 Request? 
 
Woj> IMO it=20 wouldn't hurt to allow the message to optionally carry of other info = that=20 could be derived from the received trigger, eg source MAC, and source = IP=20 address.

The parameters currently identified for Admission Response = are:
-=20 Accounting_Flag (which allows the NAS to tell AN if accounting is = required for=20 this flow).
Do you see other parameters that need to be added to Admission=20 Response? 
 
Woj> Additional=20 parameters will be needed, especially to allow the Admission Response = to be=20 decoupled from the Request. These would then be:
-=20 Flow_Id
- = Target=20 Port_id
 
Regards,
Woj.

It=20 will be useful to clarify that the NAS is expected to know the BW=20 information for the multicast flow (flow-group) for which admission = control=20 is being requested.

Agreed.

This could be locally configured on the = NAS, could=20 be provided at auth time from radius/policy server, or could be = dynamically=20 auto-sensed (measured) on the = NAS.

Agreed. In the future it could also potentially be = explicitely=20 signaled by the source.

Francois


------_=_NextPart_001_01C7FACB.EF294EC8-- --===============1163516252== 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 --===============1163516252==-- From ancp-bounces@ietf.org Wed Sep 19 13:02:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY2vv-0002JI-Rx; Wed, 19 Sep 2007 13:01:51 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IY2vu-0002J4-8G for ancp-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 13:01:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY2vt-0002Iv-OY for ancp@ietf.org; Wed, 19 Sep 2007 13:01:49 -0400 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IY2vr-0006C8-Cd for ancp@ietf.org; Wed, 19 Sep 2007 13:01:49 -0400 Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8JH15EM016740; Wed, 19 Sep 2007 19:01:05 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS07.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 19 Sep 2007 19:01:44 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [ANCP] Comments on draft-ietf-ancp-framework-02 Date: Wed, 19 Sep 2007 19:01:42 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E38001510EAC@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Comments on draft-ietf-ancp-framework-02 Thread-Index: AcfpU83pE3C2QWNARiyqWPyvXPBW3ARfnURw References: From: "OOGHE Sven" To: , X-OriginalArrivalTime: 19 Sep 2007 17:01:44.0454 (UTC) FILETIME=[C1CE1260:01C7FADE] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1d30a527351d82e25c9159ea5f4b10e8 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="===============0455824838==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0455824838== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7FADE.C18A4DCC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7FADE.C18A4DCC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Kirubaharan, =20 See inline (sorry for the long delay). ________________________________ From: kirubaharan.dorairaj@wipro.com [mailto:kirubaharan.dorairaj@wipro.com]=20 Sent: dinsdag 28 augustus 2007 11:14 To: ancp@ietf.org Subject: [ANCP] Comments on draft-ietf-ancp-framework-02 Hello Sven et al., =20 Please find below my comments on ANCP protocol framework draft. Covers most of the sections of the framework draft and points to specific improvements required. =20 Page 6: =20 >From figure 1, it appears that the controller would reside in NAS generally. Not sure if a one-directional controller-reporter model would be the best possible mechanism. This needs to take into account the possibility of extending this mechanism to US QoS control. With the new evolving access model and architecture, possibility of more user-generated content and highbandwidth streams are foreseen, moving away from a provider-centric model. It would help to have provisions for this, by having the control at either endpoints of ANCP adjacency.=20 =20 I agree that some form of enforcement also happens at the NAS. For the purpose of the framework however, the "enforcement function" refers to a function that is "controlled" via ANCP. So I agree that the NAS will also be involed in some form of QoS policy enforcement, but that won't be configured via ANCP (but rather via e.g. some network management or policy management interface). That is the point we are trying to make with the figure. =20 Page 7: =20 Reporting and/or enforcement function - Here enforcement should probably be a separate function as it can be in AN or NAS. e.g. In NAS traffic shaping based on access loop rate report, the enforcement function is in NAS. Also, enforcement should be based on a policy decision or report. Hence, port testing initiation may not be classified as an example of enforcement. =20 See previous comment: I agree that enforcement also happens on the NAS, but the "enforcement function" in the framework refers to something that is controlled by ANCP specifically. =20 Page 8: =20 2.2.2 - The term NID may be replaced with a term consistent with the figure (HGW). More important than the protocol encapsulations, I think, is the physical layer technologies that may be used in access loop, i.e. different DSL types: ADSL2+, VDSL2, VDSL, SHDSL, etc. (Assuming that this draft considers just DSL as explained in introduction and not WiMAX or PON based access networks) =20 Ok, we can make the necessary changes. =20 2.2.3 - Paragraph 4 - Enforcement need not be in access node alone (e.g. traffic shaping in NAS) =20 See above. =20 Page 12: =20 3.1 - Section title - could be along the lines of "Access node capabilities report", there seems to be no discovery involved. Paragraph 2 - "topology of the access network" can be removed - it seems to me that NAS does not have any knowledge of the network topology. If needed, it can be addressed in a separate section -Access topology discovery. =20 The ANCP WG has discussed the terminology on several occations. In the end the group decided to use the titles as indicated in the current version. I would prefer to keep them this way, rather than reopening this discussion. =20 Paragraph 3 - Reference to "Access port discovery" - needs to be made consistent with section title. =20 Ok, we will make the change. =20 Paragraph 5 - Not sure if NAS hierarchical scheduling based on DSL sync rate would be the best possible thing to do. It may help to some extent. But, ANs typically apply rate limiting per DSL port that may be far too lower than the actual DSL sync rate. In such a case, it would make sense to communicate the lesser of the two (sync rate or rate limit). This again may not take into account the bandwidth consumed by multicast traffic replicated locally at AN. =20 The scenario assumes that no rate limiting is used on the Access Node. Perhaps we should make this clear in the text? =20 Paragraph 6 - Access loop characteristics - Would be a good idea to add DSL port bonding status. If ports are bonded at PHY level or at ATM or ethernet level, it is important that NAS is aware of this to determine the rate for shaping. =20 I'm not sure I got your point. Would it not suffice to announce the bitrate and encapsulation used? That seems to be rather independent of bonding. Of course, in case of bonding you would announce the total bitrate across multiple interfaces. But I don't think that this fundamentally changes the model or description. =20 Page 15: =20 3.2 Access loop configuration - It would be useful to make the result of configuration always communicated back to NAS/controller. This is needed to ensure synchronization between the elements as a configuration may fail or may be denied by an AN. =20 I agree. The framework mentions in the protocol requirements section that there is a need to support request/response transactions with ANCP. The details of how this is done for loop configuration is covered in the protocol specification. So that should cover your comment. =20 Paragraph 4 - QoS profile for an access loop - it would be good to have an example profile and/or an illustration of this as it is an important functionality. =20 The details of the QoS profile are considered beyond the scope of the framework. Perhaps we can add this statement to the text? =20 Page 18: =20 4.1 - A requirement is needed to specify the bandwidth limit for protocol message overhead. (ANCP protocol message overhead must not exceed x% of link capacity or x kbps). =20 I agree that the protocol should not eat up too much bandwidth, but I don't know how we can put a number on it...=20 =20 Page 20: =20 4.4 - ANCP transport requirements - Redundant paths (VLAN/VC) for the control channel can be made a requirement. =20 Some redundancy may indeed be used below the ANCP layer. How this is done is beyond the scope of the framework. I'm not sure we need to spell it out, as it is not impacting the ANCP protocol operation as long as this is invisible to the IP layer...=20 =20 Page 21: =20 4.5.1 - Last requirement - "AN should be able to work with redundant controllers" - Elaborate on requirement for maintaining redundant adjacencies and the failover mechanisms. =20 The requirement as it stands is very high-level. I think more discussion is required on the details of redundancy in ANCP, and how it is achieved. Perhaps we can reword this to: "The AN should be able to establish and maintain ANCP Adjacencies to redundant controllers". =20 Page 22: =20 4.5.2 - ANCP capability negotiation procedure - framework and rationale for this needs to be provided separately.=20 =20 Section 4.2 has the following requirement: "The ANCP MUST provide a means for the AN and the NAS to perform capability negotiation and negotiate a common subset." That covers the need for capability negotiation. Does this cover your comment?=20 =20 Page 23: =20 4.6.1 - Minimum/maximum number of ANCP adjacencies to be supported by NAS needs to be identified. Number of ANCP instances supported at NAS can also be specified. =20 In one of the previous IETF meetings, the ANCP WG has decided to focus on the protocol requirements and not so much on the node requirements. For this reason, you'll notice that the sections with node requirements don't use MUST / SHOULD etc. For this reason, I don't think we need to add specific requirements on the number of adjacencies or instances to be supported. =20 Page 28: =20 6. - Management related requirements - When ANCP adjacency is up in AN, any configuration parameter successfully updated by ANCP should not be allowed to be changed by local EMS. This is required to ensure consistency of data and operation. =20 Good point. I think it should be added, unless someone speaks up. =20 A general comment: =20 On using the AN uplink attributes in ANCP, it might be necessary to consider other bottlenecks in aggregation network. The links between AN and NAS could be a direct-connect in which case, it is straightforwad. However, when there are aggregation elements involved, it would help to provide for extensions in the framework to identify any link bottleneck. The capacity of links between aggregation elements or the links betweek an aggregation node and NAS can be static or dynamic (link aggregation). Identifying bottlenecks in the link capacity here would help do a more accurate traffic scheduling or shaping at NAS as compared to having just the AN uplink attributes. =20 That would broaden the scope to using ANCP between aggregation switches and the NAS. Currently this is not the charter of the WG... =20 Regards, Sven =20 Thanks, Kirubaharan ------_=_NextPart_001_01C7FADE.C18A4DCC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Kirubaharan,
 
See inline (sorry for the long=20 delay).

From: kirubaharan.dorairaj@wipro.com = [mailto:kirubaharan.dorairaj@wipro.com]
Sent: dinsdag 28 = augustus=20 2007 11:14
To: ancp@ietf.org
Subject: [ANCP] = Comments on=20 draft-ietf-ancp-framework-02

Hello = Sven et=20 al.,
 
Please = find below my=20 comments on ANCP protocol framework draft.
Covers = most of the=20 sections of the framework draft and points to specific improvements=20 required.
 
Page=20 6:
 
From = figure 1, it=20 appears that the controller would reside in NAS = generally.
Not sure if a=20 one-directional controller-reporter model would be the best possible=20 mechanism.  This needs to take into account the possibility of = extending this mechanism to US QoS control. With the new evolving access = model=20 and architecture, possibility of more user-generated content and = highbandwidth=20 streams are foreseen, moving away from a provider-centric model. It = would help=20 to have provisions for this, by having the control at either endpoints = of ANCP=20 adjacency. 
 
<Sven> I agree = that some form=20 of enforcement also happens at the NAS. For the purpose of the = framework however, the "enforcement function" refers to a function that = is=20 "controlled" via ANCP. So I agree that the NAS will also be involed in = some form=20 of QoS policy enforcement, but that won't be configured via ANCP = (but=20 rather via e.g. some network management or policy management = interface).=20 That is the point we are trying to make with=20 the figure.
 
Page=20 7:
 
Reporting and/or=20 enforcement function - Here enforcement should probably be a separate = function=20 as it can be in AN or NAS.
e.g. = In NAS traffic=20 shaping based on access loop rate report, the enforcement function is in = NAS.
Also, = enforcement=20 should be based on a policy decision or report. Hence, port testing = initiation=20 may not be classified as an example of enforcement.
 
<Sven> See previous comment: I agree = that=20 enforcement also happens on the NAS, but the "enforcement function" in = the=20 framework refers to something that is controlled by ANCP=20 specifically.
 
Page=20 8:
 
2.2.2 = - The term NID=20 may be replaced with a term consistent with the figure (HGW). More = important=20 than the protocol encapsulations, I think, is the physical=20 layer
technologies that=20 may be used in access loop, i.e. different DSL types: ADSL2+, VDSL2, = VDSL,=20 SHDSL, etc. (Assuming that this draft considers just DSL as explained in = introduction and not WiMAX or PON based access = networks)
 
<Sven> Ok, we can make the necessary=20 changes.
 
2.2.3 = -=20 Paragraph 4 - Enforcement need not be in access node alone = (e.g.=20 traffic shaping in NAS)
 
<Sven> See = above.
 
Page=20 12:
 
3.1 - = Section title=20 - could be along the lines of "Access node capabilities report", there = seems to=20 be no discovery involved.
Paragraph 2 -=20 "topology of the access network" can be removed - it seems to me that = NAS does=20 not have any knowledge of the network topology.
If = needed, it can be=20 addressed in a separate section -Access topology = discovery.
 
<Sven> The ANCP WG has discussed the = terminology=20 on several occations. In the end the group decided to use the titles as=20 indicated in the current version. I would prefer to keep them this way, = rather=20 than reopening this discussion.
 
Paragraph 3 -=20 Reference to "Access port discovery" - needs to be made consistent with = section=20 title.
 
<Sven> Ok, we will make the=20 change.
 
Paragraph 5 - Not=20 sure if NAS hierarchical scheduling based on DSL sync rate would be the = best=20 possible thing to do. It may help to some extent.
But, = ANs typically=20 apply rate limiting per DSL port that may be far too lower than the = actual DSL=20 sync rate. In such a case, it would make sense to communicate the lesser of = the two (sync=20 rate or rate limit). This again may not take into account the bandwidth = consumed=20 by multicast traffic replicated locally at AN.
 
<Sven> The scenario assumes that no = rate limiting=20 is used on the Access Node. Perhaps we should make this clear in the=20 text?
 
Paragraph 6 - Access=20 loop characteristics - Would be a good idea to add DSL port bonding = status. If=20 ports are bonded at PHY level or at ATM or ethernet = level,
it is = important that=20 NAS is aware of this to determine the rate for = shaping.
 
<Sven> I'm not sure I got your point. = Would it=20 not suffice to announce the bitrate and encapsulation used? That seems = to be=20 rather independent of bonding. Of course, in case of bonding you = would=20 announce the total bitrate across multiple interfaces. But I don't think = that=20 this fundamentally changes the model or = description.
 
Page=20 15:
 
3.2 = Access loop=20 configuration - It would be useful to make the result of configuration = always=20 communicated back to NAS/controller. This is needed to ensure = synchronization=20 between the elements as a configuration may fail or may be denied by an=20 AN.
 
<Sven> I agree. The framework mentions = in the=20 protocol requirements section that there is a need to support = request/response=20 transactions with ANCP. The details of how this is done for loop = configuration=20 is covered in the protocol specification. So that should cover your=20 comment.
 
Paragraph 4 - QoS=20 profile for an access loop - it would be good to have an example profile = and/or=20 an illustration of this as it is an important = functionality.
 
<Sven> The details of the QoS profile = are=20 considered beyond the scope of the framework. Perhaps we can add this = statement=20 to the text?
 
Page=20 18:
 
4.1 - = A requirement=20 is needed to specify the bandwidth limit for protocol message=20 overhead.
(ANCP = protocol=20 message overhead must not exceed x% of link capacity or x=20 kbps).
 
<Sven> I agree that the protocol should = not eat=20 up too much bandwidth, but I don't know how we can put a number on it... =
 
Page=20 20:
 
4.4 - = ANCP transport=20 requirements - Redundant paths (VLAN/VC) for the control channel can be = made a=20 requirement.
 
<Sven> Some redundancy may indeed be = used below=20 the ANCP layer. How this is done is beyond the scope of the framework. = I'm not=20 sure we need to spell it out, as it is not impacting the = ANCP protocol=20 operation as long as this is invisible to the IP=20 layer... 
 
Page=20 21:
 
4.5.1 = - Last=20 requirement - "AN should be able to work with redundant controllers" - = Elaborate=20 on requirement for maintaining redundant adjacencies and the failover=20 mechanisms.
 
<Sven> The requirement as it stands is = very=20 high-level. I think more discussion is required on the details of = redundancy in=20 ANCP, and how it is achieved.
Perhaps we can reword this to: "The AN should = be able=20 to establish and maintain ANCP Adjacencies to redundant=20 controllers".
 
Page=20 22:
 
4.5.2 - ANCP=20 capability negotiation procedure - framework and rationale for this = needs to be=20 provided separately. 
 
<Sven> Section = 4.2 has the=20 following requirement:
   "The ANCP = MUST provide=20 a means for the AN and the NAS to = perform
     =20 capability negotiation and negotiate a common = subset."
That covers the=20 need for capability negotiation. Does this cover your=20 comment? 
 
Page=20 23:
 
4.6.1 = -=20 Minimum/maximum number of ANCP adjacencies to be supported by NAS needs = to be=20 identified. Number of ANCP instances supported at NAS can also be=20 specified.
 
<Sven> In one of the previous IETF = meetings,=20 the ANCP WG has decided to focus on the protocol requirements and not so = much on=20 the node requirements. For this reason, you'll notice that the sections = with=20 node requirements don't use MUST / SHOULD etc. For this reason, I don't = think we=20 need to add specific requirements on the number of adjacencies or = instances to=20 be supported.
 
Page=20 28:
 
6. - = Management=20 related requirements - When ANCP adjacency is up in AN, any = configuration=20 parameter successfully updated by ANCP should not be allowed to be = changed by=20 local EMS. This is required to ensure consistency of data and=20 operation.
 
<Sven> Good point. I think it should be = added,=20 unless someone speaks up.
 
A = general=20 comment:
 
On = using the AN=20 uplink attributes in ANCP, it might be necessary to consider other = bottlenecks=20 in aggregation network. The links between AN and NAS could be a = direct-connect=20 in which case, it is straightforwad. However, when there are aggregation = elements involved, it would help to provide for extensions in the = framework to=20 identify any link bottleneck. The capacity of links between aggregation = elements=20 or the links betweek an aggregation node and NAS can be static or = dynamic (link=20 aggregation). Identifying bottlenecks in the link capacity here would = help do a=20 more accurate traffic scheduling or shaping at NAS as compared to having = just=20 the AN uplink attributes.
 
<Sven> That would broaden the scope to = using ANCP=20 between aggregation switches and the NAS. Currently this is not the = charter of=20 the WG...
 
Regards,
Sven
 
Thanks,
Kirubaharan
------_=_NextPart_001_01C7FADE.C18A4DCC-- --===============0455824838== 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 --===============0455824838==-- From ancp-bounces@ietf.org Wed Sep 19 14:55:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY4hi-000429-8I; Wed, 19 Sep 2007 14:55:18 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IY4hg-00040W-5J for ancp-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 14:55:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY4hf-0003v9-PW for ancp@ietf.org; Wed, 19 Sep 2007 14:55:15 -0400 Received: from exprod7og53.obsmtp.com ([64.18.2.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IY4hV-0002bQ-GF for ancp@ietf.org; Wed, 19 Sep 2007 14:55:11 -0400 Received: from source ([66.129.224.36]) by exprod7ob53.obsmtp.com ([64.18.6.12]) with SMTP; Wed, 19 Sep 2007 11:51:20 PDT Received: from beta.jnpr.net ([172.24.18.109]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 11:53:30 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 11:53:29 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Sep 2007 14:53:25 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280AB434C0@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Link bonding Thread-Index: Acf67i11ZVg9/1twSYWI90SdyP9OFA== From: "Sanjay Wadhwa" To: X-OriginalArrivalTime: 19 Sep 2007 18:53:29.0919 (UTC) FILETIME=[5E92D4F0:01C7FAEE] X-Spam-Score: -4.0 (----) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Thomas.Haag@t-systems.com Subject: [ANCP] Link bonding 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 All =20 I would like to get some feedback on requirements for ANCP to support = link bonding e.g.as defined in ITU-T G.998.2 (EFM bonding). At a high = level it seems the AN should report the aggregate rate for the bonded = links to the BNG. If an existing link in the bundle goes down or a new = link in the bundle is added, the AN should report this to the BNG as a = change in the downstream and upstream rate. In case of regular un-bonded = link, the ACI that is used for addressing a local-loop has a default = syntax that carries=20 AN-name/slot/port/vpi.vci or vlan. In case of link bonding, I suppose = the AN should use "logical addressing" for the bonded link when = constructing the ACI (inserted in DHCP opt82/pppoe IA tags, and ANCP). = BNG would transparently correlate the rate received in ANCP messages to = subscriber's interface based on ACI and adjust its traffic-shaping = accordingly. The overhead due to (variable sized) fragmentation on the = bonded link somehow needs to be accounted for on the BNG to calculate = the effective rate of the local-loop. This is dependent on the packet = sizes, and the framgentation scheme used on the AN. A very simplistic = solution could be for the AN to report a fixed overhead to the BNG for = fragmentation. Do we see other implications of bonding on the = topology-discovery/adaptive-rate use case ? Thanks -Sanjay =20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Sep 20 06:47:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYJYu-0001MN-EG; Thu, 20 Sep 2007 06:47:12 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IYJYs-0001GY-Dq for ancp-confirm+ok@megatron.ietf.org; Thu, 20 Sep 2007 06:47:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYJYs-0001GB-0o for ancp@ietf.org; Thu, 20 Sep 2007 06:47:10 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYJYm-00013j-8x for ancp@ietf.org; Thu, 20 Sep 2007 06:47:09 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 20 Sep 2007 12:46:45 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Sep 2007 12:46:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Sep 2007 12:46:06 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C21E202@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280AB434C0@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Link bonding thread-index: Acf67i11ZVg9/1twSYWI90SdyP9OFAAhFvEQ References: <9BD5D7887235424FA97DFC223CAE3C280AB434C0@proton.jnpr.net> From: "Haag, T" To: X-OriginalArrivalTime: 20 Sep 2007 10:46:45.0425 (UTC) FILETIME=[89C07210:01C7FB73] X-Spam-Score: -1.0 (-) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Subject: [ANCP] AW: Link bonding 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 All, considering link bonding (ITU-T G.998.2 (EFM bonding) and ANCP is very = welcome but I would like to recommend not combine DHCP Option 82 or = PPPoE intermediate function issues with that use case.=20 I think these are two separate issues which may be combined but not = necessarily needed to be combined. From an operator's standpoint ANCP = protocol issues should be considered stand alone for link bonding = without PPPoE or DHCP because for products using bonded links PPP or = DHCP is not mandatory.=20 Regards Thomas -----Urspr=FCngliche Nachricht----- Von: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Gesendet: Mittwoch, 19. September 2007 20:53 An: ancp@ietf.org Cc: Haag, Thomas; norbert.voigt@nsn.com Betreff: Link bonding All =20 I would like to get some feedback on requirements for ANCP to support = link bonding e.g.as defined in ITU-T G.998.2 (EFM bonding). At a high = level it seems the AN should report the aggregate rate for the bonded = links to the BNG. If an existing link in the bundle goes down or a new = link in the bundle is added, the AN should report this to the BNG as a = change in the downstream and upstream rate. In case of regular un-bonded = link, the ACI that is used for addressing a local-loop has a default = syntax that carries=20 AN-name/slot/port/vpi.vci or vlan. In case of link bonding, I suppose = the AN should use "logical addressing" for the bonded link when = constructing the ACI (inserted in DHCP opt82/pppoe IA tags, and ANCP). = BNG would transparently correlate the rate received in ANCP messages to = subscriber's interface based on ACI and adjust its traffic-shaping = accordingly. The overhead due to (variable sized) fragmentation on the = bonded link somehow needs to be accounted for on the BNG to calculate = the effective rate of the local-loop. This is dependent on the packet = sizes, and the framgentation scheme used on the AN. A very simplistic = solution could be for the AN to report a fixed overhead to the BNG for = fragmentation. Do we see other implications of bonding on the = topology-discovery/adaptive-rate use case ? Thanks -Sanjay =20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Sep 21 11:38:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYka3-0003Xs-2M; Fri, 21 Sep 2007 11:38:11 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IYka1-0003TQ-Uw for ancp-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 11:38:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYka1-0003O9-4U for ancp@ietf.org; Fri, 21 Sep 2007 11:38:09 -0400 Received: from smail5.alcatel.fr ([64.208.49.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYkZy-00070q-C0 for ancp@ietf.org; Fri, 21 Sep 2007 11:38:06 -0400 Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com [155.132.6.74]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8LFbLmb029724; Fri, 21 Sep 2007 17:37:21 +0200 Received: from [172.31.195.41] ([172.31.195.41]) by FRVELSBHS02.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Fri, 21 Sep 2007 17:38:04 +0200 Message-ID: <46F3E55B.4070006@alcatel-lucent.be> Date: Fri, 21 Sep 2007 17:38:03 +0200 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: OOGHE Sven Subject: Re: [ANCP] Comments on draft-ietf-ancp-framework-02 References: <8144761F31F48D43AD53D09F5350E38001510EAC@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <8144761F31F48D43AD53D09F5350E38001510EAC@FRVELSMBS22.ad2.ad.alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Sep 2007 15:38:04.0391 (UTC) FILETIME=[6670BF70:01C7FC65] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 > Page 28: > > 6. - Management related requirements - When ANCP adjacency is up in AN, > any configuration parameter successfully updated by ANCP should not be > allowed to be changed by local EMS. This is required to ensure > consistency of data and operation. > > Good point. I think it should be added, unless someone speaks up. > This looks to contradict with what is described on page 22, section 4.5.7: "When using ANCP for Access Loop Configuration, the EMS needs to configure on the Access Node which parameters may or may not be modified using the Access Node Control Mechanism. Furthermore, for those parameters that may be modified using ANCP, the EMS needs to specify the default values to be used when an Access Node comes up after recovery." According to section 4.5.7, an EMS can change the by ANCP successfuly updated parameter, my not allowing the parameter anymore to be configured by ANCP and then the EMS can change it. From a conceptual point of view that is the same as an EMS that can change something that is successfuly updated by ANCP. regards, Stefaan _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Sep 24 03:53:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZilD-0003Qs-JY; Mon, 24 Sep 2007 03:53:43 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IZilC-0003NH-9R for ancp-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 03:53:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZil8-0003Ji-1G for ancp@ietf.org; Mon, 24 Sep 2007 03:53:38 -0400 Received: from smail5.alcatel.fr ([64.208.49.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZil6-0000Be-Vm for ancp@ietf.org; Mon, 24 Sep 2007 03:53:37 -0400 Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8O7qQ4C025521; Mon, 24 Sep 2007 09:52:50 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS07.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 24 Sep 2007 09:53:18 +0200 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: [ANCP] Comments on draft-ietf-ancp-framework-02 Date: Mon, 24 Sep 2007 09:53:17 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E38001580172@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <46F3E55B.4070006@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Comments on draft-ietf-ancp-framework-02 Thread-Index: Acf8ZWaCvkPKu+u4Rk+lSs8HWL816gCGW87w References: <8144761F31F48D43AD53D09F5350E38001510EAC@FRVELSMBS22.ad2.ad.alcatel.com> <46F3E55B.4070006@alcatel-lucent.be> From: "OOGHE Sven" To: "DE CNODDER Stefaan" X-OriginalArrivalTime: 24 Sep 2007 07:53:18.0578 (UTC) FILETIME=[F8709D20:01C7FE7F] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Stefaan, I think you're right. This raises an interesting question: it looks like allowing the EMS to "turn on" or "turn off" certain parameters to be changed via ANCP may lead to race conditions, i.e. both the NAS and the EMS wish to perform an action on the same parameter (EMS wishes to "turn off" changes via ANCP / NAS wishes to change the value of the parameter). Perhaps it's simpler to determine beforehand what parameters may or may not be changed via ANCP? Regards, Sven -----Original Message----- From: DE CNODDER Stefaan=20 Sent: vrijdag 21 september 2007 17:38 To: OOGHE Sven Cc: kirubaharan.dorairaj@wipro.com; ancp@ietf.org Subject: Re: [ANCP] Comments on draft-ietf-ancp-framework-02 > Page 28: > =20 > 6. - Management related requirements - When ANCP adjacency is up in=20 > AN, any configuration parameter successfully updated by ANCP should=20 > not be allowed to be changed by local EMS. This is required to ensure=20 > consistency of data and operation. > =20 > Good point. I think it should be added, unless someone speaks up. > =20 This looks to contradict with what is described on page 22, section 4.5.7: "When using ANCP for Access Loop Configuration, the EMS needs to configure on the Access Node which parameters may or may not be modified using the Access Node Control Mechanism. Furthermore, for those parameters that may be modified using ANCP, the EMS needs to specify the default values to be used when an Access Node comes up after recovery." According to section 4.5.7, an EMS can change the by ANCP successfuly updated parameter, my not allowing the parameter anymore to be configured by ANCP and then the EMS can change it. From a conceptual point of view that is the same as an EMS that can change something that is successfuly updated by ANCP. regards, Stefaan _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Sep 24 06:28:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZlAb-0000uZ-Tx; Mon, 24 Sep 2007 06:28:05 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IZlAa-0000uF-Hj for ancp-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 06:28:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZlAa-0000pm-7v for ancp@ietf.org; Mon, 24 Sep 2007 06:28:04 -0400 Received: from smail5.alcatel.fr ([62.23.212.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZlAL-0002hs-5p for ancp@ietf.org; Mon, 24 Sep 2007 06:27:55 -0400 Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8OAQX0V011657; Mon, 24 Sep 2007 12:26:33 +0200 Received: from [172.31.195.41] ([172.31.195.41]) by FRVELSBHS07.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Mon, 24 Sep 2007 12:27:18 +0200 Message-ID: <46F79105.6090400@alcatel-lucent.be> Date: Mon, 24 Sep 2007 12:27:17 +0200 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: OOGHE Sven Subject: Re: [ANCP] Comments on draft-ietf-ancp-framework-02 References: <8144761F31F48D43AD53D09F5350E38001580172@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <8144761F31F48D43AD53D09F5350E38001580172@FRVELSMBS22.ad2.ad.alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Sep 2007 10:27:18.0036 (UTC) FILETIME=[7B960540:01C7FE95] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 Sven, It looks to me that the original text is correct: the EMS has to configure which parameters can be changed by the NAS and which cannot be changed. If the NAS tries to configure another parameter, the request will fail with an appropriate error code. It also implies that the EMS can change whatever the NAS has configured before, without information the NAS about this modification. regards, Stefaan OOGHE Sven wrote: > Stefaan, > > I think you're right. This raises an interesting question: it looks like > allowing the EMS to "turn on" or "turn off" certain parameters to be > changed via ANCP may lead to race conditions, i.e. both the NAS and the > EMS wish to perform an action on the same parameter (EMS wishes to "turn > off" changes via ANCP / NAS wishes to change the value of the > parameter). > > Perhaps it's simpler to determine beforehand what parameters may or may > not be changed via ANCP? > > Regards, > Sven > > -----Original Message----- > From: DE CNODDER Stefaan > Sent: vrijdag 21 september 2007 17:38 > To: OOGHE Sven > Cc: kirubaharan.dorairaj@wipro.com; ancp@ietf.org > Subject: Re: [ANCP] Comments on draft-ietf-ancp-framework-02 > > > >>Page 28: >> >>6. - Management related requirements - When ANCP adjacency is up in >>AN, any configuration parameter successfully updated by ANCP should >>not be allowed to be changed by local EMS. This is required to ensure >>consistency of data and operation. >> >> Good point. I think it should be added, unless someone speaks > > up. > >> > > > This looks to contradict with what is described on page 22, section > 4.5.7: > > "When using ANCP for Access Loop Configuration, the EMS needs to > configure on the Access Node which parameters may or may not be modified > using the Access Node Control Mechanism. Furthermore, for those > parameters that may be modified using ANCP, the EMS needs to specify the > default values to be used when an Access Node comes up after recovery." > > According to section 4.5.7, an EMS can change the by ANCP successfuly > updated parameter, my not allowing the parameter anymore to be > configured by ANCP and then the EMS can change it. From a conceptual > point of view that is the same as an EMS that can change something that > is successfuly updated by ANCP. > > regards, > Stefaan > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Sep 24 08:27:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZn1Y-0006l0-KC; Mon, 24 Sep 2007 08:26:52 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IZn1X-0006kq-Dw for ancp-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 08:26:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZn1X-0006b1-3t for ancp@ietf.org; Mon, 24 Sep 2007 08:26:51 -0400 Received: from wip-cdc-wd.wipro.com ([203.91.201.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZn1K-0005c0-Ei for ancp@ietf.org; Mon, 24 Sep 2007 08:26:49 -0400 Received: from wip-cdc-wd.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2F50418056 for ; Mon, 24 Sep 2007 17:56:54 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-cdc-wd.wipro.com (Postfix) with ESMTP id 1D65918051 for ; Mon, 24 Sep 2007 17:56:54 +0530 (IST) Received: from BLR-EC-MBX03.wipro.com ([10.201.50.164]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Sep 2007 17:57:08 +0530 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: [ANCP] Comments on draft-ietf-ancp-framework-02 Date: Mon, 24 Sep 2007 17:57:36 +0530 Message-ID: In-Reply-To: <46F79105.6090400@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Comments on draft-ietf-ancp-framework-02 Thread-Index: Acf+lb4PJLqdhDd2Rla1kcuLBj0PBgADoYAQ From: To: , X-OriginalArrivalTime: 24 Sep 2007 12:27:08.0203 (UTC) FILETIME=[39426FB0:01C7FEA6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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 Stefaan and Sven, My comment was based on the assumption that any change in permission on parameter configuration by EMS would=20 be immediately communicated to NAS. At any point in time, NAS should be aware of which parameters are allowed to be changed in AN. If that is done, there will be no inconsistencies in ANCP operation=20 and permissions can be changed dynamically by EMS. Thanks, Kirubaharan -----Original Message----- From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: Monday, September 24, 2007 3:57 PM To: OOGHE Sven Cc: Kirubaharan Dorairaj (WT01 - TES-Telecom Engineering Solutions); ancp@ietf.org Subject: Re: [ANCP] Comments on draft-ietf-ancp-framework-02 Sven, It looks to me that the original text is correct: the EMS has to=20 configure which parameters can be changed by the NAS and which cannot be changed. If the NAS tries to configure another parameter, the request=20 will fail with an appropriate error code. It also implies that the EMS=20 can change whatever the NAS has configured before, without information=20 the NAS about this modification. regards, Stefaan OOGHE Sven wrote: > Stefaan, >=20 > I think you're right. This raises an interesting question: it looks=20 > like allowing the EMS to "turn on" or "turn off" certain parameters to > be changed via ANCP may lead to race conditions, i.e. both the NAS and > the EMS wish to perform an action on the same parameter (EMS wishes to > "turn off" changes via ANCP / NAS wishes to change the value of the=20 > parameter). >=20 > Perhaps it's simpler to determine beforehand what parameters may or=20 > may not be changed via ANCP? >=20 > Regards, > Sven >=20 > -----Original Message----- > From: DE CNODDER Stefaan > Sent: vrijdag 21 september 2007 17:38 > To: OOGHE Sven > Cc: kirubaharan.dorairaj@wipro.com; ancp@ietf.org > Subject: Re: [ANCP] Comments on draft-ietf-ancp-framework-02 >=20 >=20 >=20 >>Page 28: >>=20 >>6. - Management related requirements - When ANCP adjacency is up in >>AN, any configuration parameter successfully updated by ANCP should=20 >>not be allowed to be changed by local EMS. This is required to ensure=20 >>consistency of data and operation. >>=20 >> Good point. I think it should be added, unless someone speaks >=20 > up. >=20 >>=20 >=20 >=20 > This looks to contradict with what is described on page 22, section > 4.5.7: >=20 > "When using ANCP for Access Loop Configuration, the EMS needs to=20 > configure on the Access Node which parameters may or may not be=20 > modified using the Access Node Control Mechanism. Furthermore, for=20 > those parameters that may be modified using ANCP, the EMS needs to=20 > specify the default values to be used when an Access Node comes up=20 > after recovery." >=20 > According to section 4.5.7, an EMS can change the by ANCP successfuly=20 > updated parameter, my not allowing the parameter anymore to be=20 > configured by ANCP and then the EMS can change it. From a conceptual=20 > point of view that is the same as an EMS that can change something=20 > that is successfuly updated by ANCP. >=20 > regards, > Stefaan >=20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Sep 24 09:24:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZnvQ-0003aT-CN; Mon, 24 Sep 2007 09:24:36 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IZnvP-0003aG-BD for ancp-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 09:24:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZnvO-0003a5-Rt for ancp@ietf.org; Mon, 24 Sep 2007 09:24:35 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZnvN-0000qc-Ut for ancp@ietf.org; Mon, 24 Sep 2007 09:24:34 -0400 X-IronPort-AV: E=Sophos;i="4.20,291,1186351200"; d="scan'208";a="153976588" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 24 Sep 2007 15:24:32 +0200 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 l8ODOV8g008877; Mon, 24 Sep 2007 15:24:31 +0200 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 l8ODOVtZ018323; Mon, 24 Sep 2007 13:24:31 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, 24 Sep 2007 15:24:10 +0200 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: [ANCP] Comments on draft-ietf-ancp-framework-02 Date: Mon, 24 Sep 2007 15:24:07 +0200 Message-ID: In-Reply-To: <8144761F31F48D43AD53D09F5350E38001580172@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Comments on draft-ietf-ancp-framework-02 Thread-Index: Acf8ZWaCvkPKu+u4Rk+lSs8HWL816gCGW87wAAWY4jA= References: <8144761F31F48D43AD53D09F5350E38001510EAC@FRVELSMBS22.ad2.ad.alcatel.com><46F3E55B.4070006@alcatel-lucent.be> <8144761F31F48D43AD53D09F5350E38001580172@FRVELSMBS22.ad2.ad.alcatel.com> From: "Wojciech Dec (wdec)" To: "OOGHE Sven" , "DE CNODDER Stefaan" X-OriginalArrivalTime: 24 Sep 2007 13:24:10.0793 (UTC) FILETIME=[31483990:01C7FEAE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4289; t=1190640271; x=1191504271; 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=20[ANCP]=20Comments=20on=20draft-ietf-ancp-framework-02 |Sender:=20; bh=MO0Tf2p2aJUAYCKNKhv5EjQ6DRr3o6ZQtyJFI8ZxzJc=; b=J0vJsJFSBcMr4jh2kOmXwGTzIYaLXS2LtC2aBP5X/SOulA0dQWTEcQ/T/vFAVYdohmaoknGw KbX3ZUtqoG+MVAiWvitfYwGs2H5zt61dMLjVq8McVcDzbpWUftc4xDvA; 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: 6d95a152022472c7d6cdf886a0424dc6 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 Well, calling out which parameters may or may not be changed via ANCP seems rather undesirable as it could complicate extensibility or even some details of the existing use-cases, not to mention bringing about quite an extra operational chore.=20 IMO we could have the framework re-aligned so that: i) there may be default configuration values (whether these defaults got there via local or remote EMS is secondary) ii) there should be a local mechanism for handling configuration source info priorities and failures to apply it, with such a mechanism most likely being implementation specific.=20 Taking this view would make ANCP agnostic to the mechanism allowing say vendor A choosing to do a config parameter source based priority scheme vs vendor B choosing a specific parameter lock mechanism vs a vendor C choosing a parameter merge mechanism (although operators may prefer one method vs the other). The only real consequence for ANCP is that there needs to be an error message which indicates that there was/is a problem in applying the configuration desired by ANCP, and that this was/is caused by a denial from the device local mechanism. Iii) Once ANCP is successful in configuring a data object, then it should be assumed that ANCP is the owner and then there must be a means of enforcing a lock on the ANCP configured data object (after all, if one uses ANCP, and allows ANCP to make config changes, then presumably one really wants that). If, through say special intervention such a lock is removed, then there must be a way of signalling this, and this appears to translate to an ANCP message very similar to the error message above.=20 Given the above I'd suggest removing the EMS references all together and structuring the description along the above points. Thoughts or comments? -Woj. > -----Original Message----- > From: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be]=20 > Sent: 24 September 2007 09:53 > To: DE CNODDER Stefaan > Cc: ancp@ietf.org > Subject: RE: [ANCP] Comments on draft-ietf-ancp-framework-02 >=20 > Stefaan, >=20 > I think you're right. This raises an interesting question: it=20 > looks like allowing the EMS to "turn on" or "turn off"=20 > certain parameters to be changed via ANCP may lead to race=20 > conditions, i.e. both the NAS and the EMS wish to perform an=20 > action on the same parameter (EMS wishes to "turn off"=20 > changes via ANCP / NAS wishes to change the value of the parameter). >=20 > Perhaps it's simpler to determine beforehand what parameters=20 > may or may not be changed via ANCP? >=20 > Regards, > Sven >=20 > -----Original Message----- > From: DE CNODDER Stefaan > Sent: vrijdag 21 september 2007 17:38 > To: OOGHE Sven > Cc: kirubaharan.dorairaj@wipro.com; ancp@ietf.org > Subject: Re: [ANCP] Comments on draft-ietf-ancp-framework-02 >=20 >=20 > > Page 28: > > =20 > > 6. - Management related requirements - When ANCP adjacency is up in=20 > > AN, any configuration parameter successfully updated by ANCP should=20 > > not be allowed to be changed by local EMS. This is required=20 > to ensure=20 > > consistency of data and operation. > > =20 > > Good point. I think it should be added, unless someone speaks > up. > > =20 >=20 > This looks to contradict with what is described on page 22, section > 4.5.7: >=20 > "When using ANCP for Access Loop Configuration, the EMS needs to > configure on the Access Node which parameters may or may not=20 > be modified > using the Access Node Control Mechanism. Furthermore, for those > parameters that may be modified using ANCP, the EMS needs to=20 > specify the > default values to be used when an Access Node comes up after=20 > recovery." >=20 > According to section 4.5.7, an EMS can change the by ANCP successfuly > updated parameter, my not allowing the parameter anymore to be > configured by ANCP and then the EMS can change it. From a conceptual > point of view that is the same as an EMS that can change=20 > something that > is successfuly updated by ANCP. >=20 > regards, > Stefaan >=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 Sep 25 06:14:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia7Qg-0001xJ-BJ; Tue, 25 Sep 2007 06:14:10 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Ia7Qd-0001hf-SJ for ancp-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 06:14:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia7Qd-0001c5-AF for ancp@ietf.org; Tue, 25 Sep 2007 06:14:07 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ia7Qc-0002wP-8x for ancp@ietf.org; Tue, 25 Sep 2007 06:14:07 -0400 X-IronPort-AV: E=Sophos;i="4.20,295,1186351200"; d="scan'208,217";a="154057465" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 25 Sep 2007 12:14:03 +0200 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 l8PAE3jW004880; Tue, 25 Sep 2007 12:14:03 +0200 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 l8PAE0tV014165; Tue, 25 Sep 2007 10:14:00 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); Tue, 25 Sep 2007 12:14:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Sep 2007 12:13:57 +0200 Message-ID: In-Reply-To: <8144761F31F48D43AD53D09F5350E38001580124@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated ANCP Framework Thread-Index: Acf8WZEYjvX7uyYDRB6LagdNk4dLPgCIbofAADZalaA= References: <8144761F31F48D43AD53D09F5350E38001510EBB@FRVELSMBS22.ad2.ad.alcatel.com> <855774AB-BEA2-43D8-842B-B457CAC19FCE@cisco.com> <8144761F31F48D43AD53D09F5350E38001580124@FRVELSMBS22.ad2.ad.alcatel.com> From: "Wojciech Dec (wdec)" To: X-OriginalArrivalTime: 25 Sep 2007 10:14:00.0303 (UTC) FILETIME=[CA835FF0:01C7FF5C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9213; t=1190715243; x=1191579243; 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=20Updated=20ANCP=20Framework |Sender:=20; bh=v3qBLYdmG4WyWIYvP9f5dVsKynegxMlwBKWZI6a0iW4=; b=eM0wJZ6yv1FRC4kvjMyqlgFh/VSqF6DDnBbtediq5700szu7ddpeXQjzQvYrApeNMJGMhrFT VeIaznVE6fouuuRkapMgmhZ0w3YPLkAnZuTkynnEuC0bGkTI5aNV0nPJ; 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: bacfc6c7290e34d410f9bc22b825ce96 Cc: OOGHE Sven Subject: [ANCP] RE: Updated ANCP Framework 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="===============1719579094==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1719579094== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7FF5C.CA46DE24" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7FF5C.CA46DE24 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 there seem to be three main changes related to the updated ANCP Framework that we would like to solicit further comments/discussion from the WG. These are summarized below and currently all look likely to be accepted. =20 1. Provisioning via ANCP of maximum number of multicast groups per port. The proposal is to add the following text to the Framework doc (largely in relation to the multicast use-case(s)): * A high level ANCP functional requirement stating, "The ANCP MUST support the configuration of the "maximum number of multicast groups/streams" allowed to be received concurrently per Access Port." * An access-node requirement (section 4.5.6) stating, "The Access Node must be able to control the maximum number of multicast streams that is allowed to be received concurrently per Access Port." * A NAS requirement (section 4.6.6 ) stating, "The NAS must support using ANCP to configure the Access Node with the "maximum number of multicast streams" allowed to be received concurrently per Access Port." 2. Provisioning and updating via ANCP of ACLs. This appears to be related more closely to the access-line configuration use-case, but has an overlap with the multicast use-case too. The proposal is to add: * A set of high level ANCP functional requirements in Sec 4.1 stating " o The ANCP MUST support partial updates of the White lists and Black lists. o The ANCP MUST support providing opening and closing a specific Access Port using the Access Loop Configuration use case. o The ANCP MUST support configuring access control lists using the Port Configuration Mechanism. For example, such a list may include source MAC addresses and destination MAC address in order to allow/deny access to/from specific destinations." * The respective access-node and NAS requirements seem to be currently missing/not proposed. 3. Grey Lists and default behaviour This is primarily related to the multicast use-cases, and was raised at the WG meeting. The proposal is to modify the access-node behaviour ascribed to the access-node in draft-maglione for multicast join events. * The modified behaviour sees the access-node deny-by-default multicast join events unless explicitly allowed to on a list. * Introduce an explicit grey-list to supplement the above deny-by-default and allow the ANCP queries to be generated.=20 * A fuller description of the proposal can be found by looking up the "Grey List & Default Behaviour" thread on the WG mailing list. Regards, Woj. ------_=_NextPart_001_01C7FF5C.CA46DE24 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Updated ANCP Framework

Hi = All,
 
there = seem to be three main = changes related to the updated ANCP Framework that we would like to solicit further comments/discussion from the = WG. These are summarized below and currently all look likely = to be accepted.

 
1. = Provisioning via ANCP of maximum number of multicast groups per = port.

The proposal is to = add the following text to the Framework doc (largely in relation to the = multicast use-case(s)):
* A high level = ANCP functional requirement stating, "The ANCP MUST support the = configuration of the "maximum number of multicast = groups/streams" allowed to be received concurrently per Access = Port."

* An access-node = requirement (section 4.5.6) stating, "The Access Node must be able = to control the maximum number of multicast streams that is allowed to be = received concurrently per Access Port."

* A NAS requirement (section 4.6.6 ) stating, "The NAS must = support using ANCP to configure the Access Node with the "maximum = number of multicast streams" allowed to be received concurrently = per Access Port."

2. Provisioning = and updating via ANCP of ACLs.

This appears to be = related more closely to the access-line configuration use-case, but has = an overlap with the multicast use-case too. The proposal is = to add:

* A set of high = level ANCP functional requirements in Sec 4.1 stating
"   o  The ANCP MUST support partial = updates of the White lists and Black
      lists.
   = o  The ANCP MUST support providing opening and closing a = specific
      Access Port using the = Access Loop Configuration use case.
   = o  The ANCP MUST support configuring access control lists using = the
      Port Configuration = Mechanism.  For example, such a list may
      include source MAC = addresses and destination MAC address in order
      to allow/deny access = to/from specific destinations."
* The respective access-node and = NAS requirements = seem to be currently missing/not = proposed.

3. Grey = Lists and default behaviour

This is primarily = related to the multicast use-cases, and was raised at the WG meeting. = The proposal is to modify the access-node behaviour ascribed to the = access-node in draft-maglione for multicast join events. =

* The modified = behaviour sees the access-node deny-by-default multicast join events = unless explicitly allowed to on a list.

* Introduce an = explicit grey-list to supplement the above deny-by-default and allow the = ANCP queries to be generated.
* A fuller = description of the proposal can be found by looking up the "Grey = List & Default Behaviour" thread on the WG mailing = list.

Regards,
Woj.


------_=_NextPart_001_01C7FF5C.CA46DE24-- --===============1719579094== 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 --===============1719579094==-- From ancp-bounces@ietf.org Wed Sep 26 02:58:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaQqt-0005sU-Bz; Wed, 26 Sep 2007 02:58:31 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IaQqr-0005ft-Mm for ancp-confirm+ok@megatron.ietf.org; Wed, 26 Sep 2007 02:58:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaQqn-0005X5-D2 for ancp@ietf.org; Wed, 26 Sep 2007 02:58:25 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaQqm-00059R-Nb for ancp@ietf.org; Wed, 26 Sep 2007 02:58:25 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 26 Sep 2007 08:58:23 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Sep 2007 08:58:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [ANCP] Comments on draft-ietf-ancp-framework-02 Date: Wed, 26 Sep 2007 08:58:22 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C0E23D3@S4DE8PSAANK.mitte.t-com.de> In-reply-to: <46F79105.6090400@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Comments on draft-ietf-ancp-framework-02 Thread-Index: Acf+lgzf6REqYUxASDOyT4NFJSP71ABdA14g References: <8144761F31F48D43AD53D09F5350E38001580172@FRVELSMBS22.ad2.ad.alcatel.com> <46F79105.6090400@alcatel-lucent.be> From: "Freudenberger, Markus" To: , X-OriginalArrivalTime: 26 Sep 2007 06:58:23.0130 (UTC) FILETIME=[A106A7A0:01C8000A] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: "Haag, T" , "Busser, M" , 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 Stefaan, Sven, We do not agree to the following: "When ANCP adjacency is up in AN, any configuration parameter = successfully updated by ANCP should not be allowed to be changed by = local EMS. This is required to ensure consistency of data and = operation." for the use case line configuration and in addition to the actual = requirements contained in chapter 6, we as an operator, want: - to control via EMS (e. g .via SNMP-If, CLI), which parameters can be = changed and which cannot be changed by ANCP in the acces node. - that the EMS (e. g. via SNMP-If, CLI) can change the parameters in the = acces node which may be set by ANCP at any time. Regards Markus =20 -----Urspr=FCngliche Nachricht----- Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Gesendet: Montag, 24. September 2007 12:27 An: OOGHE Sven Cc: ancp@ietf.org Betreff: Re: [ANCP] Comments on draft-ietf-ancp-framework-02 Sven, It looks to me that the original text is correct: the EMS has to = configure which parameters can be changed by the NAS and which cannot be = changed. If the NAS tries to configure another parameter, the request = will fail with an appropriate error code. It also implies that the EMS = can change whatever the NAS has configured before, without information = the NAS about this modification. regards, Stefaan OOGHE Sven wrote: > Stefaan, >=20 > I think you're right. This raises an interesting question: it looks=20 > like allowing the EMS to "turn on" or "turn off" certain parameters to = > be changed via ANCP may lead to race conditions, i.e. both the NAS and = > the EMS wish to perform an action on the same parameter (EMS wishes to = > "turn off" changes via ANCP / NAS wishes to change the value of the=20 > parameter). >=20 > Perhaps it's simpler to determine beforehand what parameters may or=20 > may not be changed via ANCP? >=20 > Regards, > Sven >=20 > -----Original Message----- > From: DE CNODDER Stefaan > Sent: vrijdag 21 september 2007 17:38 > To: OOGHE Sven > Cc: kirubaharan.dorairaj@wipro.com; ancp@ietf.org > Subject: Re: [ANCP] Comments on draft-ietf-ancp-framework-02 >=20 >=20 >=20 >>Page 28: >>=20 >>6. - Management related requirements - When ANCP adjacency is up in=20 >>AN, any configuration parameter successfully updated by ANCP should=20 >>not be allowed to be changed by local EMS. This is required to ensure=20 >>consistency of data and operation. >>=20 >> Good point. I think it should be added, unless someone speaks >=20 > up. >=20 >>=20 >=20 >=20 > This looks to contradict with what is described on page 22, section > 4.5.7: >=20 > "When using ANCP for Access Loop Configuration, the EMS needs to=20 > configure on the Access Node which parameters may or may not be=20 > modified using the Access Node Control Mechanism. Furthermore, for=20 > those parameters that may be modified using ANCP, the EMS needs to=20 > specify the default values to be used when an Access Node comes up = after recovery." >=20 > According to section 4.5.7, an EMS can change the by ANCP successfuly=20 > updated parameter, my not allowing the parameter anymore to be=20 > configured by ANCP and then the EMS can change it. From a conceptual=20 > point of view that is the same as an EMS that can change something=20 > that is successfuly updated by ANCP. >=20 > regards, > Stefaan >=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 Sep 26 03:35:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaRR5-0007nA-8z; Wed, 26 Sep 2007 03:35:55 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IaRR4-0007n5-JO for ancp-confirm+ok@megatron.ietf.org; Wed, 26 Sep 2007 03:35:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaRR4-0007mx-4D for ancp@ietf.org; Wed, 26 Sep 2007 03:35:54 -0400 Received: from de307622-de-outbound.net.avaya.com ([198.152.71.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaRR3-00062C-B0 for ancp@ietf.org; Wed, 26 Sep 2007 03:35:54 -0400 X-IronPort-AV: E=Sophos;i="4.20,299,1186372800"; d="scan'208";a="61192787" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Sep 2007 03:35:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ANCP] Comments on draft-ietf-ancp-framework-02 Date: Wed, 26 Sep 2007 09:35:10 +0200 Message-ID: In-Reply-To: <1B6169C658325341A3B8066E23919E1C0E23D3@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Comments on draft-ietf-ancp-framework-02 Thread-Index: Acf+lgzf6REqYUxASDOyT4NFJSP71ABdA14gAAFj30A= References: <8144761F31F48D43AD53D09F5350E38001580172@FRVELSMBS22.ad2.ad.alcatel.com><46F79105.6090400@alcatel-lucent.be> <1B6169C658325341A3B8066E23919E1C0E23D3@S4DE8PSAANK.mitte.t-com.de> From: "Romascanu, Dan (Dan)" To: "Freudenberger, Markus" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: "Haag, T" , "Busser, M" , 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 Markus - clarification question just to make sure - what do you mean by = 'SNMP-If'?=20 Thanks and Regards, Dan =20 =20 > -----Original Message----- > From: Freudenberger, Markus=20 > [mailto:Markus.Freudenberger@t-systems.com]=20 > Sent: Wednesday, September 26, 2007 8:58 AM > To: stefaan.de_cnodder@alcatel-lucent.be; Sven.Ooghe@alcatel-lucent.be > Cc: Haag, T; Busser,M; ancp@ietf.org > Subject: AW: [ANCP] Comments on draft-ietf-ancp-framework-02 >=20 > Stefaan, Sven, >=20 > We do not agree to the following: > "When ANCP adjacency is up in AN, any configuration parameter=20 > successfully updated by ANCP should not be allowed to be=20 > changed by local EMS. This is required to ensure consistency=20 > of data and operation." >=20 > for the use case line configuration and in addition to the=20 > actual requirements contained in chapter 6, we as an operator, want: > - to control via EMS (e. g .via SNMP-If, CLI), which=20 > parameters can be changed and which cannot be changed by ANCP=20 > in the acces node. > - that the EMS (e. g. via SNMP-If, CLI) can change the=20 > parameters in the acces node which may be set by ANCP at any time. >=20 > Regards > Markus > =20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] > Gesendet: Montag, 24. September 2007 12:27 > An: OOGHE Sven > Cc: ancp@ietf.org > Betreff: Re: [ANCP] Comments on draft-ietf-ancp-framework-02 >=20 >=20 > Sven, >=20 > It looks to me that the original text is correct: the EMS has=20 > to configure which parameters can be changed by the NAS and=20 > which cannot be changed. If the NAS tries to configure=20 > another parameter, the request will fail with an appropriate=20 > error code. It also implies that the EMS can change whatever=20 > the NAS has configured before, without information the NAS=20 > about this modification. >=20 > regards, > Stefaan >=20 >=20 > OOGHE Sven wrote: >=20 > > Stefaan, > >=20 > > I think you're right. This raises an interesting question: it looks=20 > > like allowing the EMS to "turn on" or "turn off" certain=20 > parameters to=20 > > be changed via ANCP may lead to race conditions, i.e. both=20 > the NAS and=20 > > the EMS wish to perform an action on the same parameter=20 > (EMS wishes to=20 > > "turn off" changes via ANCP / NAS wishes to change the value of the=20 > > parameter). > >=20 > > Perhaps it's simpler to determine beforehand what parameters may or=20 > > may not be changed via ANCP? > >=20 > > Regards, > > Sven > >=20 > > -----Original Message----- > > From: DE CNODDER Stefaan > > Sent: vrijdag 21 september 2007 17:38 > > To: OOGHE Sven > > Cc: kirubaharan.dorairaj@wipro.com; ancp@ietf.org > > Subject: Re: [ANCP] Comments on draft-ietf-ancp-framework-02 > >=20 > >=20 > >=20 > >>Page 28: > >>=20 > >>6. - Management related requirements - When ANCP adjacency is up in=20 > >>AN, any configuration parameter successfully updated by ANCP should=20 > >>not be allowed to be changed by local EMS. This is required=20 > to ensure=20 > >>consistency of data and operation. > >>=20 > >> Good point. I think it should be added, unless someone speaks > >=20 > > up. > >=20 > >>=20 > >=20 > >=20 > > This looks to contradict with what is described on page 22, section > > 4.5.7: > >=20 > > "When using ANCP for Access Loop Configuration, the EMS needs to=20 > > configure on the Access Node which parameters may or may not be=20 > > modified using the Access Node Control Mechanism. Furthermore, for=20 > > those parameters that may be modified using ANCP, the EMS needs to=20 > > specify the default values to be used when an Access Node=20 > comes up after recovery." > >=20 > > According to section 4.5.7, an EMS can change the by ANCP=20 > successfuly=20 > > updated parameter, my not allowing the parameter anymore to be=20 > > configured by ANCP and then the EMS can change it. From a=20 > conceptual=20 > > point of view that is the same as an EMS that can change something=20 > > that is successfuly updated by ANCP. > >=20 > > regards, > > Stefaan > >=20 >=20 >=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 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Sep 26 03:43:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaRYj-0003Ph-JY; Wed, 26 Sep 2007 03:43:49 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IaRYi-0003OV-Op for ancp-confirm+ok@megatron.ietf.org; Wed, 26 Sep 2007 03:43:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaRYi-0003ON-F0 for ancp@ietf.org; Wed, 26 Sep 2007 03:43:48 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaRYb-0001vu-QK for ancp@ietf.org; Wed, 26 Sep 2007 03:43:48 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 26 Sep 2007 09:43:33 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Sep 2007 09:43:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [ANCP] Comments on draft-ietf-ancp-framework-02 Date: Wed, 26 Sep 2007 09:43:32 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C0E23D4@S4DE8PSAANK.mitte.t-com.de> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Comments on draft-ietf-ancp-framework-02 Thread-Index: Acf+lgzf6REqYUxASDOyT4NFJSP71ABdA14gAAFj30AAABOfsA== References: <8144761F31F48D43AD53D09F5350E38001580172@FRVELSMBS22.ad2.ad.alcatel.com><46F79105.6090400@alcatel-lucent.be> <1B6169C658325341A3B8066E23919E1C0E23D3@S4DE8PSAANK.mitte.t-com.de> From: "Freudenberger, Markus" To: , , X-OriginalArrivalTime: 26 Sep 2007 07:43:33.0173 (UTC) FILETIME=[F0566650:01C80010] X-Spam-Score: -1.0 (-) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: "Haag, T" , "Busser, M" , 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 Hi Dan, SNMP-If means SNMP-Interface (which is meant in this context as one = possible kind of management interface, implemented in a network element = to communicate with an EMS).=20 Hope this clarifies your question. Regards Markus=20 -----Urspr=FCngliche Nachricht----- Von: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Gesendet: Mittwoch, 26. September 2007 09:35 An: Freudenberger, Markus; stefaan.de_cnodder@alcatel-lucent.be; = Sven.Ooghe@alcatel-lucent.be Cc: Haag, Thomas; Busser, Michael; ancp@ietf.org Betreff: RE: [ANCP] Comments on draft-ietf-ancp-framework-02 Markus - clarification question just to make sure - what do you mean by = 'SNMP-If'?=20 Thanks and Regards, Dan =20 =20 > -----Original Message----- > From: Freudenberger, Markus > [mailto:Markus.Freudenberger@t-systems.com] > Sent: Wednesday, September 26, 2007 8:58 AM > To: stefaan.de_cnodder@alcatel-lucent.be; Sven.Ooghe@alcatel-lucent.be > Cc: Haag, T; Busser,M; ancp@ietf.org > Subject: AW: [ANCP] Comments on draft-ietf-ancp-framework-02 >=20 > Stefaan, Sven, >=20 > We do not agree to the following: > "When ANCP adjacency is up in AN, any configuration parameter=20 > successfully updated by ANCP should not be allowed to be changed by=20 > local EMS. This is required to ensure consistency of data and=20 > operation." >=20 > for the use case line configuration and in addition to the actual=20 > requirements contained in chapter 6, we as an operator, want: > - to control via EMS (e. g .via SNMP-If, CLI), which parameters can be = > changed and which cannot be changed by ANCP in the acces node. > - that the EMS (e. g. via SNMP-If, CLI) can change the parameters in=20 > the acces node which may be set by ANCP at any time. >=20 > Regards > Markus > =20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] > Gesendet: Montag, 24. September 2007 12:27 > An: OOGHE Sven > Cc: ancp@ietf.org > Betreff: Re: [ANCP] Comments on draft-ietf-ancp-framework-02 >=20 >=20 > Sven, >=20 > It looks to me that the original text is correct: the EMS has to=20 > configure which parameters can be changed by the NAS and which cannot=20 > be changed. If the NAS tries to configure another parameter, the=20 > request will fail with an appropriate error code. It also implies=20 > that the EMS can change whatever the NAS has configured before,=20 > without information the NAS about this modification. >=20 > regards, > Stefaan >=20 >=20 > OOGHE Sven wrote: >=20 > > Stefaan, > >=20 > > I think you're right. This raises an interesting question: it looks=20 > > like allowing the EMS to "turn on" or "turn off" certain > parameters to > > be changed via ANCP may lead to race conditions, i.e. both > the NAS and > > the EMS wish to perform an action on the same parameter > (EMS wishes to > > "turn off" changes via ANCP / NAS wishes to change the value of the=20 > > parameter). > >=20 > > Perhaps it's simpler to determine beforehand what parameters may or=20 > > may not be changed via ANCP? > >=20 > > Regards, > > Sven > >=20 > > -----Original Message----- > > From: DE CNODDER Stefaan > > Sent: vrijdag 21 september 2007 17:38 > > To: OOGHE Sven > > Cc: kirubaharan.dorairaj@wipro.com; ancp@ietf.org > > Subject: Re: [ANCP] Comments on draft-ietf-ancp-framework-02 > >=20 > >=20 > >=20 > >>Page 28: > >>=20 > >>6. - Management related requirements - When ANCP adjacency is up in=20 > >>AN, any configuration parameter successfully updated by ANCP should=20 > >>not be allowed to be changed by local EMS. This is required > to ensure > >>consistency of data and operation. > >>=20 > >> Good point. I think it should be added, unless someone speaks > >=20 > > up. > >=20 > >>=20 > >=20 > >=20 > > This looks to contradict with what is described on page 22, section > > 4.5.7: > >=20 > > "When using ANCP for Access Loop Configuration, the EMS needs to=20 > > configure on the Access Node which parameters may or may not be=20 > > modified using the Access Node Control Mechanism. Furthermore, for=20 > > those parameters that may be modified using ANCP, the EMS needs to=20 > > specify the default values to be used when an Access Node > comes up after recovery." > >=20 > > According to section 4.5.7, an EMS can change the by ANCP > successfuly > > updated parameter, my not allowing the parameter anymore to be=20 > > configured by ANCP and then the EMS can change it. From a > conceptual > > point of view that is the same as an EMS that can change something=20 > > that is successfuly updated by ANCP. > >=20 > > regards, > > Stefaan > >=20 >=20 >=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 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Sep 26 07:37:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaVCo-0004w7-0D; Wed, 26 Sep 2007 07:37:26 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IaVCn-0004tK-1k for ancp-confirm+ok@megatron.ietf.org; Wed, 26 Sep 2007 07:37:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaVCm-0004tC-J8 for ancp@ietf.org; Wed, 26 Sep 2007 07:37:24 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaVCl-00040u-Nf for ancp@ietf.org; Wed, 26 Sep 2007 07:37:24 -0400 X-IronPort-AV: E=Sophos;i="4.20,301,1186351200"; d="scan'208";a="154195336" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 26 Sep 2007 13:37:21 +0200 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 l8QBbL9j014630; Wed, 26 Sep 2007 13:37:21 +0200 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 l8QBbKvb027579; Wed, 26 Sep 2007 11:37:20 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); Wed, 26 Sep 2007 13:37:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ANCP] Comments on draft-ietf-ancp-framework-02 Date: Wed, 26 Sep 2007 13:37:16 +0200 Message-ID: In-Reply-To: <1B6169C658325341A3B8066E23919E1C0E23D3@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Comments on draft-ietf-ancp-framework-02 Thread-Index: Acf+lgzf6REqYUxASDOyT4NFJSP71ABdA14gAAmrOmA= References: <8144761F31F48D43AD53D09F5350E38001580172@FRVELSMBS22.ad2.ad.alcatel.com><46F79105.6090400@alcatel-lucent.be> <1B6169C658325341A3B8066E23919E1C0E23D3@S4DE8PSAANK.mitte.t-com.de> From: "Wojciech Dec (wdec)" To: "Freudenberger, Markus" , , X-OriginalArrivalTime: 26 Sep 2007 11:37:20.0329 (UTC) FILETIME=[992C8B90:01C80031] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4512; t=1190806641; x=1191670641; 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=20[ANCP]=20Comments=20on=20draft-ietf-ancp-framework-02 |Sender:=20; bh=FeB9Kd4wk/6JKP8TmHb8h3Vc9O0spjYUKWC30UTMJ7U=; b=S+AWiisD/PlxV8gV7YvLoFZiCC/umEz5+OQ2Jkuuw9UaCmJqrbzm9G14fOFI1I1XSWrjP15R DJ8nHbn6Ix8Wbyp9AD8qQrjzafzHDWXg/9x5RCkjo/laLldj41AvFOJ3; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: "Haag, T" , "Busser, M" , 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 Markus, Can you clarify what would be your expectation regarding ANCP's = behaviour after an ANCP set parameter is overriden via EMS? -Woj.=20 > -----Original Message----- > From: Freudenberger, Markus=20 > [mailto:Markus.Freudenberger@t-systems.com]=20 > Sent: 26 September 2007 08:58 > To: stefaan.de_cnodder@alcatel-lucent.be; Sven.Ooghe@alcatel-lucent.be > Cc: Haag, T; Busser,M; ancp@ietf.org > Subject: AW: [ANCP] Comments on draft-ietf-ancp-framework-02 >=20 > Stefaan, Sven, >=20 > We do not agree to the following: > "When ANCP adjacency is up in AN, any configuration parameter=20 > successfully updated by ANCP should not be allowed to be=20 > changed by local EMS. This is required to ensure consistency=20 > of data and operation." >=20 > for the use case line configuration and in addition to the=20 > actual requirements contained in chapter 6, we as an operator, want: > - to control via EMS (e. g .via SNMP-If, CLI), which=20 > parameters can be changed and which cannot be changed by ANCP=20 > in the acces node. > - that the EMS (e. g. via SNMP-If, CLI) can change the=20 > parameters in the acces node which may be set by ANCP at any time. >=20 > Regards > Markus > =20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] > Gesendet: Montag, 24. September 2007 12:27 > An: OOGHE Sven > Cc: ancp@ietf.org > Betreff: Re: [ANCP] Comments on draft-ietf-ancp-framework-02 >=20 >=20 > Sven, >=20 > It looks to me that the original text is correct: the EMS has=20 > to configure which parameters can be changed by the NAS and=20 > which cannot be changed. If the NAS tries to configure=20 > another parameter, the request will fail with an appropriate=20 > error code. It also implies that the EMS can change whatever=20 > the NAS has configured before, without information the NAS=20 > about this modification. >=20 > regards, > Stefaan >=20 >=20 > OOGHE Sven wrote: >=20 > > Stefaan, > >=20 > > I think you're right. This raises an interesting question: it looks=20 > > like allowing the EMS to "turn on" or "turn off" certain=20 > parameters to=20 > > be changed via ANCP may lead to race conditions, i.e. both=20 > the NAS and=20 > > the EMS wish to perform an action on the same parameter=20 > (EMS wishes to=20 > > "turn off" changes via ANCP / NAS wishes to change the value of the=20 > > parameter). > >=20 > > Perhaps it's simpler to determine beforehand what parameters may or=20 > > may not be changed via ANCP? > >=20 > > Regards, > > Sven > >=20 > > -----Original Message----- > > From: DE CNODDER Stefaan > > Sent: vrijdag 21 september 2007 17:38 > > To: OOGHE Sven > > Cc: kirubaharan.dorairaj@wipro.com; ancp@ietf.org > > Subject: Re: [ANCP] Comments on draft-ietf-ancp-framework-02 > >=20 > >=20 > >=20 > >>Page 28: > >>=20 > >>6. - Management related requirements - When ANCP adjacency is up in=20 > >>AN, any configuration parameter successfully updated by ANCP should=20 > >>not be allowed to be changed by local EMS. This is required=20 > to ensure=20 > >>consistency of data and operation. > >>=20 > >> Good point. I think it should be added, unless someone speaks > >=20 > > up. > >=20 > >>=20 > >=20 > >=20 > > This looks to contradict with what is described on page 22, section > > 4.5.7: > >=20 > > "When using ANCP for Access Loop Configuration, the EMS needs to=20 > > configure on the Access Node which parameters may or may not be=20 > > modified using the Access Node Control Mechanism. Furthermore, for=20 > > those parameters that may be modified using ANCP, the EMS needs to=20 > > specify the default values to be used when an Access Node=20 > comes up after recovery." > >=20 > > According to section 4.5.7, an EMS can change the by ANCP=20 > successfuly=20 > > updated parameter, my not allowing the parameter anymore to be=20 > > configured by ANCP and then the EMS can change it. From a=20 > conceptual=20 > > point of view that is the same as an EMS that can change something=20 > > that is successfuly updated by ANCP. > >=20 > > regards, > > Stefaan > >=20 >=20 >=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 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Sep 26 07:55:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaVUI-0004H3-Qj; Wed, 26 Sep 2007 07:55:32 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IaVUH-0004Gy-Pz for ancp-confirm+ok@megatron.ietf.org; Wed, 26 Sep 2007 07:55:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaVUH-0004Gq-Ef for ancp@ietf.org; Wed, 26 Sep 2007 07:55:29 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaVU7-00088E-98 for ancp@ietf.org; Wed, 26 Sep 2007 07:55:29 -0400 X-IronPort-AV: E=Sophos;i="4.20,301,1186351200"; d="scan'208,217";a="154197586" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Sep 2007 13:54:54 +0200 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 l8QBsrLn005104; Wed, 26 Sep 2007 13:54:53 +0200 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 l8QBsivh004601; Wed, 26 Sep 2007 11:54:53 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); Wed, 26 Sep 2007 13:54:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] RE: Updated ANCP Framework Date: Wed, 26 Sep 2007 13:54:45 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] RE: Updated ANCP Framework Thread-Index: Acf8WZEYjvX7uyYDRB6LagdNk4dLPgCIbofAADZalaAAN3ZhMA== References: <8144761F31F48D43AD53D09F5350E38001510EBB@FRVELSMBS22.ad2.ad.alcatel.com><855774AB-BEA2-43D8-842B-B457CAC19FCE@cisco.com><8144761F31F48D43AD53D09F5350E38001580124@FRVELSMBS22.ad2.ad.alcatel.com> From: "Wojciech Dec (wdec)" To: "Wojciech Dec (wdec)" , X-OriginalArrivalTime: 26 Sep 2007 11:54:49.0238 (UTC) FILETIME=[0A5F5B60:01C80034] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=13522; t=1190807693; x=1191671693; 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=20[ANCP]=20RE=3A=20Updated=20ANCP=20Framework |Sender:=20; bh=w75W5qp7TPPSF1ZzzP/E+SfrgZSXLYkZlkCSgnlfqO8=; b=uLuasfqg0nDF3C2sjgBqrNUT1AlJrp3oFo69QmT02H8p4CAvNRdrRj/lRU7xPbi81rXDPeID VoqPQZcKykeRnDsOtBKakDfiTrIsbz9dbFqBhJRIn0Blmc/xo+oNJGV3; 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: 913ee11e7c554f7d4da75d500826397e Cc: OOGHE Sven 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="===============0524229312==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0524229312== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80034.0A420A7E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80034.0A420A7E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 my earlier mail below assumed that the latest "working version" of the ANCP framework text has been posted by the editors to the WG, which I now realize has not yet happened. As such, let me provide some more background. =20 The revised ANCP framework will largely see an inclusion of the multicast topics discussed at the last meeting and on the WG alias. Three new items though have cropped up, and are being proposed for inclusion in the merged framework. Our solicitation for inputs from the WG is about these: =20 1. It is proposed that ANCP be also capable of setting the maximum number of multicast flows allowed on a port 2. It is proposed that ANCP be capable of configuring and modifying ACLs (not multicast specific) on a port 3. At the meeting and also on the list it was proposed to modify the default behaviour regarding multicast queries described in draft-maglione.=20 =20 My post below provides additional detail on each. -Woj. ________________________________ From: Wojciech Dec (wdec)=20 Sent: 25 September 2007 12:14 To: ancp@ietf.org Cc: OOGHE Sven Subject: [ANCP] RE: Updated ANCP Framework =09 =09 Hi All,=20 =20 there seem to be three main changes related to the updated ANCP Framework that we would like to solicit further comments/discussion from the WG. These are summarized below and currently all look likely to be accepted. =09 1. Provisioning via ANCP of maximum number of multicast groups per port.=20 The proposal is to add the following text to the Framework doc (largely in relation to the multicast use-case(s)):=20 * A high level ANCP functional requirement stating, "The ANCP MUST support the configuration of the "maximum number of multicast groups/streams" allowed to be received concurrently per Access Port." * An access-node requirement (section 4.5.6) stating, "The Access Node must be able to control the maximum number of multicast streams that is allowed to be received concurrently per Access Port." * A NAS requirement (section 4.6.6 ) stating, "The NAS must support using ANCP to configure the Access Node with the "maximum number of multicast streams" allowed to be received concurrently per Access Port." 2. Provisioning and updating via ANCP of ACLs.=20 This appears to be related more closely to the access-line configuration use-case, but has an overlap with the multicast use-case too. The proposal is to add: * A set of high level ANCP functional requirements in Sec 4.1 stating=20 " o The ANCP MUST support partial updates of the White lists and Black=20 lists.=20 o The ANCP MUST support providing opening and closing a specific=20 Access Port using the Access Loop Configuration use case.=20 o The ANCP MUST support configuring access control lists using the=20 Port Configuration Mechanism. For example, such a list may=20 include source MAC addresses and destination MAC address in order=20 to allow/deny access to/from specific destinations."=20 * The respective access-node and NAS requirements seem to be currently missing/not proposed.=20 3. Grey Lists and default behaviour=20 This is primarily related to the multicast use-cases, and was raised at the WG meeting. The proposal is to modify the access-node behaviour ascribed to the access-node in draft-maglione for multicast join events.=20 * The modified behaviour sees the access-node deny-by-default multicast join events unless explicitly allowed to on a list. * Introduce an explicit grey-list to supplement the above deny-by-default and allow the ANCP queries to be generated.=20 * A fuller description of the proposal can be found by looking up the "Grey List & Default Behaviour" thread on the WG mailing list. Regards,=20 Woj.=20 ------_=_NextPart_001_01C80034.0A420A7E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Updated ANCP Framework
Hi All,
 
my earlier mail below assumed that the latest "working = version" of=20 the ANCP framework text has been posted by the editors to the WG, = which I=20 now realize has not yet happened. As such, let me provide some more=20 background.
 
The revised ANCP framework will largely see an inclusion = of the=20 multicast topics discussed at the last meeting and on the WG alias. = Three new=20 items though have cropped up, and are being proposed for inclusion = in the=20 merged framework. Our solicitation for inputs from the WG is about=20 these:
 
1. It is proposed that ANCP be also capable of setting the = maximum number=20 of multicast flows allowed on a port
2. It is proposed that ANCP be capable of configuring and = modifying ACLs=20 (not multicast specific) on a port
3. At the meeting and also on the list it was proposed=20 to modify the default behaviour regarding multicast queries = described in=20 draft-maglione.
 
My post below provides additional detail on=20 each.
-Woj.
From: Wojciech Dec (wdec) =
Sent: 25=20 September 2007 12:14
To: ancp@ietf.org
Cc: OOGHE=20 Sven
Subject: [ANCP] RE: Updated ANCP = Framework

Hi = All,
  =
there seem=20 to be three main=20 changes related=20 to the updated ANCP Framework that = we would=20 like to solicit further = comments/discussion=20 from the WG.=20 These are summarized below and currently all look likely to be=20 accepted.

=
1. Provisioning via ANCP = of maximum=20 number of multicast groups per port.

The proposal is to = add the=20 following text to the Framework doc (largely in relation to the = multicast=20 use-case(s)):
* A=20 high level ANCP functional requirement stating, "The ANCP MUST support = the=20 configuration of the "maximum number of multicast groups/streams" = allowed to=20 be received concurrently per Access Port."

* An access-node = requirement=20 (section 4.5.6) stating, "The Access Node must be able to control the = maximum=20 number of multicast streams that is allowed to be received = concurrently per=20 Access Port."

* A NAS requirement (section = 4.6.6 ) stating,=20 "The NAS must support using ANCP to configure the Access Node with the = "maximum number of multicast streams" allowed to be received = concurrently per=20 Access Port."

2. Provisioning = and updating=20 via ANCP of ACLs.

This appears to be = related more=20 closely to the access-line configuration use-case, but has an overlap = with the=20 multicast use-case too. = The proposal is to add:

* A set of high = level ANCP=20 functional requirements in Sec 4.1 stating
"   o  The = ANCP MUST support=20 partial updates of the White lists and Black
     =20 lists.
  =20 o  The ANCP MUST support providing opening and closing a=20 specific
      Access Port using the Access = Loop=20 Configuration use case.
   o  The ANCP MUST support configuring access = control=20 lists using the
      Port Configuration = Mechanism.  For=20 example, such a list may
      include source MAC addresses = and=20 destination MAC address in order
      to allow/deny = access to/from=20 specific destinations."
* The respective = access-node and NAS=20 requirements seem to=20 be currently missing/not proposed.

3. Grey Lists and default=20 behaviour

This is primarily = related to the=20 multicast use-cases, and was raised at the WG meeting. The proposal is = to=20 modify the access-node behaviour ascribed to the access-node in = draft-maglione=20 for multicast join events.

* The modified = behaviour sees the=20 access-node deny-by-default multicast join events unless explicitly = allowed to=20 on a list.

* Introduce an = explicit grey-list=20 to supplement the above deny-by-default and allow the ANCP queries to = be=20 generated.
* A=20 fuller description of the proposal can be found by looking up the = "Grey List=20 & Default Behaviour" thread on the WG mailing = list.

Regards,
Woj.=20


------_=_NextPart_001_01C80034.0A420A7E-- --===============0524229312== 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 --===============0524229312==-- From ancp-bounces@ietf.org Wed Sep 26 09:27:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaWuv-0004bG-3D; Wed, 26 Sep 2007 09:27:05 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IaWuu-0004b5-2p for ancp-confirm+ok@megatron.ietf.org; Wed, 26 Sep 2007 09:27:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaWut-0004ax-PT for ancp@ietf.org; Wed, 26 Sep 2007 09:27:03 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaWun-0001uC-EF for ancp@ietf.org; Wed, 26 Sep 2007 09:27:03 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 26 Sep 2007 15:26:44 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Sep 2007 15:26:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [ANCP] Comments on draft-ietf-ancp-framework-02 Date: Wed, 26 Sep 2007 15:26:43 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C0E23D8@S4DE8PSAANK.mitte.t-com.de> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Comments on draft-ietf-ancp-framework-02 Thread-Index: Acf+lgzf6REqYUxASDOyT4NFJSP71ABdA14gAAmrOmAAAx/s0A== References: <8144761F31F48D43AD53D09F5350E38001580172@FRVELSMBS22.ad2.ad.alcatel.com><46F79105.6090400@alcatel-lucent.be><1B6169C658325341A3B8066E23919E1C0E23D3@S4DE8PSAANK.mitte.t-com.de> From: "Freudenberger, Markus" To: X-OriginalArrivalTime: 26 Sep 2007 13:26:43.0974 (UTC) FILETIME=[E1694A60:01C80040] X-Spam-Score: -1.0 (-) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: "Haag, T" , "Busser, M" , 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 Wojciech, I think it depends on the specific parameter.=20 But as the framework is actually focused on the same set of DSL related = paramteters for both use cases "Access Topology Discovery" and "Access = Loop Configuration", I think the behaviour is already described in the = document: After the EMS changs e. g. the minimum data rate for a specific DSL line = in the AN, ANCP reports this change to the NAS. Please correct me if I am wrong.=20 Markus -----Urspr=FCngliche Nachricht----- Von: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Gesendet: Mittwoch, 26. September 2007 13:37 An: Freudenberger, Markus; stefaan.de_cnodder@alcatel-lucent.be; = Sven.Ooghe@alcatel-lucent.be Cc: Haag, Thomas; Busser, Michael; ancp@ietf.org Betreff: RE: [ANCP] Comments on draft-ietf-ancp-framework-02 Markus, Can you clarify what would be your expectation regarding ANCP's = behaviour after an ANCP set parameter is overriden via EMS? -Woj.=20 > -----Original Message----- > From: Freudenberger, Markus > [mailto:Markus.Freudenberger@t-systems.com] > Sent: 26 September 2007 08:58 > To: stefaan.de_cnodder@alcatel-lucent.be; Sven.Ooghe@alcatel-lucent.be > Cc: Haag, T; Busser,M; ancp@ietf.org > Subject: AW: [ANCP] Comments on draft-ietf-ancp-framework-02 >=20 > Stefaan, Sven, >=20 > We do not agree to the following: > "When ANCP adjacency is up in AN, any configuration parameter=20 > successfully updated by ANCP should not be allowed to be changed by=20 > local EMS. This is required to ensure consistency of data and=20 > operation." >=20 > for the use case line configuration and in addition to the actual=20 > requirements contained in chapter 6, we as an operator, want: > - to control via EMS (e. g .via SNMP-If, CLI), which parameters can be = > changed and which cannot be changed by ANCP in the acces node. > - that the EMS (e. g. via SNMP-If, CLI) can change the parameters in=20 > the acces node which may be set by ANCP at any time. >=20 > Regards > Markus > =20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] > Gesendet: Montag, 24. September 2007 12:27 > An: OOGHE Sven > Cc: ancp@ietf.org > Betreff: Re: [ANCP] Comments on draft-ietf-ancp-framework-02 >=20 >=20 > Sven, >=20 > It looks to me that the original text is correct: the EMS has to=20 > configure which parameters can be changed by the NAS and which cannot=20 > be changed. If the NAS tries to configure another parameter, the=20 > request will fail with an appropriate error code. It also implies=20 > that the EMS can change whatever the NAS has configured before,=20 > without information the NAS about this modification. >=20 > regards, > Stefaan >=20 >=20 > OOGHE Sven wrote: >=20 > > Stefaan, > >=20 > > I think you're right. This raises an interesting question: it looks=20 > > like allowing the EMS to "turn on" or "turn off" certain > parameters to > > be changed via ANCP may lead to race conditions, i.e. both > the NAS and > > the EMS wish to perform an action on the same parameter > (EMS wishes to > > "turn off" changes via ANCP / NAS wishes to change the value of the=20 > > parameter). > >=20 > > Perhaps it's simpler to determine beforehand what parameters may or=20 > > may not be changed via ANCP? > >=20 > > Regards, > > Sven > >=20 > > -----Original Message----- > > From: DE CNODDER Stefaan > > Sent: vrijdag 21 september 2007 17:38 > > To: OOGHE Sven > > Cc: kirubaharan.dorairaj@wipro.com; ancp@ietf.org > > Subject: Re: [ANCP] Comments on draft-ietf-ancp-framework-02 > >=20 > >=20 > >=20 > >>Page 28: > >>=20 > >>6. - Management related requirements - When ANCP adjacency is up in=20 > >>AN, any configuration parameter successfully updated by ANCP should=20 > >>not be allowed to be changed by local EMS. This is required > to ensure > >>consistency of data and operation. > >>=20 > >> Good point. I think it should be added, unless someone speaks > >=20 > > up. > >=20 > >>=20 > >=20 > >=20 > > This looks to contradict with what is described on page 22, section > > 4.5.7: > >=20 > > "When using ANCP for Access Loop Configuration, the EMS needs to=20 > > configure on the Access Node which parameters may or may not be=20 > > modified using the Access Node Control Mechanism. Furthermore, for=20 > > those parameters that may be modified using ANCP, the EMS needs to=20 > > specify the default values to be used when an Access Node > comes up after recovery." > >=20 > > According to section 4.5.7, an EMS can change the by ANCP > successfuly > > updated parameter, my not allowing the parameter anymore to be=20 > > configured by ANCP and then the EMS can change it. From a > conceptual > > point of view that is the same as an EMS that can change something=20 > > that is successfuly updated by ANCP. > >=20 > > regards, > > Stefaan > >=20 >=20 >=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 _______________________________________________ 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 Sep 26 09:49:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaXGK-00005m-DA; Wed, 26 Sep 2007 09:49:12 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IaXGI-000058-U8 for ancp-confirm+ok@megatron.ietf.org; Wed, 26 Sep 2007 09:49:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaXGI-000050-Ii for ancp@ietf.org; Wed, 26 Sep 2007 09:49:10 -0400 Received: from smail5.alcatel.fr ([62.23.212.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaXGH-0007ba-Cw for ancp@ietf.org; Wed, 26 Sep 2007 09:49:10 -0400 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8QDmHiW009048; Wed, 26 Sep 2007 15:48:19 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 26 Sep 2007 15:49:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ANCP] Comments on draft-ietf-ancp-framework-02 Date: Wed, 26 Sep 2007 15:49:01 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E38001663B5A@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <1B6169C658325341A3B8066E23919E1C0E23D3@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Comments on draft-ietf-ancp-framework-02 Thread-Index: Acf+lgzf6REqYUxASDOyT4NFJSP71ABdA14gAA4MT+A= References: <8144761F31F48D43AD53D09F5350E38001580172@FRVELSMBS22.ad2.ad.alcatel.com> <46F79105.6090400@alcatel-lucent.be> <1B6169C658325341A3B8066E23919E1C0E23D3@S4DE8PSAANK.mitte.t-com.de> From: "OOGHE Sven" To: "Freudenberger, Markus" , "DE CNODDER Stefaan" X-OriginalArrivalTime: 26 Sep 2007 13:49:03.0702 (UTC) FILETIME=[FFF38F60:01C80043] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: "Haag, T" , "Busser, M" , 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 Markus, I agree that the EMS may overwrite a parameter value that was previously = changed via ANCP. That implies that the 3rd sub-bullet in section 6 = needs to be removed. Correct? The question then is whether a configuration change by the EMS results = in a notification message being sent to the NAS. As you write in another = email, the NAS is made aware of a configuration change to the DSL = parameters, thanks to the Access Topology Discovery procedure. Perhaps we need to describe such a notification mechanism in a more = generic context of configuration changes. What do you think? Regards, Sven -----Original Message----- From: Freudenberger, Markus [mailto:Markus.Freudenberger@t-systems.com]=20 Sent: woensdag 26 september 2007 8:58 To: DE CNODDER Stefaan; OOGHE Sven Cc: ancp@ietf.org; Haag, T; Busser, M Subject: AW: [ANCP] Comments on draft-ietf-ancp-framework-02 Stefaan, Sven, We do not agree to the following: "When ANCP adjacency is up in AN, any configuration parameter = successfully updated by ANCP should not be allowed to be changed by = local EMS. This is required to ensure consistency of data and = operation." for the use case line configuration and in addition to the actual = requirements contained in chapter 6, we as an operator, want: - to control via EMS (e. g .via SNMP-If, CLI), which parameters can be = changed and which cannot be changed by ANCP in the acces node. - that the EMS (e. g. via SNMP-If, CLI) can change the parameters in the = acces node which may be set by ANCP at any time. Regards Markus =20 -----Urspr=FCngliche Nachricht----- Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] Gesendet: Montag, 24. September 2007 12:27 An: OOGHE Sven Cc: ancp@ietf.org Betreff: Re: [ANCP] Comments on draft-ietf-ancp-framework-02 Sven, It looks to me that the original text is correct: the EMS has to = configure which parameters can be changed by the NAS and which cannot be = changed. If the NAS tries to configure another parameter, the request = will fail with an appropriate error code. It also implies that the EMS = can change whatever the NAS has configured before, without information = the NAS about this modification. regards, Stefaan OOGHE Sven wrote: > Stefaan, >=20 > I think you're right. This raises an interesting question: it looks=20 > like allowing the EMS to "turn on" or "turn off" certain parameters to = > be changed via ANCP may lead to race conditions, i.e. both the NAS and = > the EMS wish to perform an action on the same parameter (EMS wishes to = > "turn off" changes via ANCP / NAS wishes to change the value of the=20 > parameter). >=20 > Perhaps it's simpler to determine beforehand what parameters may or=20 > may not be changed via ANCP? >=20 > Regards, > Sven >=20 > -----Original Message----- > From: DE CNODDER Stefaan > Sent: vrijdag 21 september 2007 17:38 > To: OOGHE Sven > Cc: kirubaharan.dorairaj@wipro.com; ancp@ietf.org > Subject: Re: [ANCP] Comments on draft-ietf-ancp-framework-02 >=20 >=20 >=20 >>Page 28: >>=20 >>6. - Management related requirements - When ANCP adjacency is up in=20 >>AN, any configuration parameter successfully updated by ANCP should=20 >>not be allowed to be changed by local EMS. This is required to ensure=20 >>consistency of data and operation. >>=20 >> Good point. I think it should be added, unless someone speaks >=20 > up. >=20 >>=20 >=20 >=20 > This looks to contradict with what is described on page 22, section > 4.5.7: >=20 > "When using ANCP for Access Loop Configuration, the EMS needs to=20 > configure on the Access Node which parameters may or may not be=20 > modified using the Access Node Control Mechanism. Furthermore, for=20 > those parameters that may be modified using ANCP, the EMS needs to=20 > specify the default values to be used when an Access Node comes up = after recovery." >=20 > According to section 4.5.7, an EMS can change the by ANCP successfuly=20 > updated parameter, my not allowing the parameter anymore to be=20 > configured by ANCP and then the EMS can change it. From a conceptual=20 > point of view that is the same as an EMS that can change something=20 > that is successfuly updated by ANCP. >=20 > regards, > Stefaan >=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 Sep 26 10:46:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaY8Q-0000LZ-Da; Wed, 26 Sep 2007 10:45:06 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IaY8O-0000Jh-Hq for ancp-confirm+ok@megatron.ietf.org; Wed, 26 Sep 2007 10:45:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaY8N-0000I2-Tn for ancp@ietf.org; Wed, 26 Sep 2007 10:45:04 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaY8M-0000kD-5L for ancp@ietf.org; Wed, 26 Sep 2007 10:45:03 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 26 Sep 2007 16:45:00 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Sep 2007 16:45:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: AW: [ANCP] Comments on draft-ietf-ancp-framework-02 Date: Wed, 26 Sep 2007 16:44:59 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C0E23DD@S4DE8PSAANK.mitte.t-com.de> In-reply-to: <8144761F31F48D43AD53D09F5350E38001663B5A@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Comments on draft-ietf-ancp-framework-02 Thread-Index: Acf+lgzf6REqYUxASDOyT4NFJSP71ABdA14gAA4MT+AAAQRg8A== References: <8144761F31F48D43AD53D09F5350E38001580172@FRVELSMBS22.ad2.ad.alcatel.com><46F79105.6090400@alcatel-lucent.be><1B6169C658325341A3B8066E23919E1C0E23D3@S4DE8PSAANK.mitte.t-com.de> <8144761F31F48D43AD53D09F5350E38001663B5A@FRVELSMBS22.ad2.ad.alcatel.com> From: "Freudenberger, Markus" To: , X-OriginalArrivalTime: 26 Sep 2007 14:45:00.0419 (UTC) FILETIME=[D0B5ED30:01C8004B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d1100b36d83fed07afbc292d8848e10 Cc: "Haag, T" , "Busser, M" , 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: , Content-Type: multipart/mixed; boundary="===============0559683139==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0559683139== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8004B.D06D8EBD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8004B.D06D8EBD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sven, see my comments inline. Regards, Markus -----Urspr=FCngliche Nachricht----- Von: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be]=20 Gesendet: Mittwoch, 26. September 2007 15:49 An: Freudenberger, Markus; DE CNODDER Stefaan Cc: Haag, Thomas; Busser, Michael; ancp@ietf.org Betreff: RE: [ANCP] Comments on draft-ietf-ancp-framework-02 Markus, I agree that the EMS may overwrite a parameter value that was previously = changed via ANCP. That implies that the 3rd sub-bullet in section 6 = needs to be removed. Correct? [Markus] I don't see anything to be removed, but I may did'nt understand your = point. You mentioned the 3rd sub-bullet in section 6, which says: o The Access Node must provide the possibility using SNMP to associate = individual DSL lines with specific Access Node Control Adjacencies. Can you explain in more detail why this needs to be removed? The question then is whether a configuration change by the EMS results = in a notification message being sent to the NAS. As you write in another = email, the NAS is made aware of a configuration change to the DSL = parameters, thanks to the Access Topology Discovery procedure. Perhaps we need to describe such a notification mechanism in a more = generic context of configuration changes. What do you think? [Markus] I agree. My proposal for addional text to be added to section 6: o The ANCP may provide a notification mechanism to inform the NAS about = configuration changes done by an EMS in a timely manner. This applies = only to changes of parameters which are part of the Use Case Access Loop = Configuration Regards, Sven -----Original Message----- From: Freudenberger, Markus [mailto:Markus.Freudenberger@t-systems.com] Sent: woensdag 26 september 2007 8:58 To: DE CNODDER Stefaan; OOGHE Sven Cc: ancp@ietf.org; Haag, T; Busser, M Subject: AW: [ANCP] Comments on draft-ietf-ancp-framework-02 Stefaan, Sven, We do not agree to the following: "When ANCP adjacency is up in AN, any configuration parameter = successfully updated by ANCP should not be allowed to be changed by = local EMS. This is required to ensure consistency of data and = operation." for the use case line configuration and in addition to the actual = requirements contained in chapter 6, we as an operator, want: - to control via EMS (e. g .via SNMP-If, CLI), which parameters can be = changed and which cannot be changed by ANCP in the acces node. - that the EMS (e. g. via SNMP-If, CLI) can change the parameters in the = acces node which may be set by ANCP at any time. Regards Markus =20 -----Urspr=FCngliche Nachricht----- Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] Gesendet: Montag, 24. September 2007 12:27 An: OOGHE Sven Cc: ancp@ietf.org Betreff: Re: [ANCP] Comments on draft-ietf-ancp-framework-02 Sven, It looks to me that the original text is correct: the EMS has to = configure which parameters can be changed by the NAS and which cannot be = changed. If the NAS tries to configure another parameter, the request = will fail with an appropriate error code. It also implies that the EMS = can change whatever the NAS has configured before, without information = the NAS about this modification. regards, Stefaan OOGHE Sven wrote: > Stefaan, >=20 > I think you're right. This raises an interesting question: it looks=20 > like allowing the EMS to "turn on" or "turn off" certain parameters to = > be changed via ANCP may lead to race conditions, i.e. both the NAS and = > the EMS wish to perform an action on the same parameter (EMS wishes to = > "turn off" changes via ANCP / NAS wishes to change the value of the=20 > parameter). >=20 > Perhaps it's simpler to determine beforehand what parameters may or=20 > may not be changed via ANCP? >=20 > Regards, > Sven >=20 > -----Original Message----- > From: DE CNODDER Stefaan > Sent: vrijdag 21 september 2007 17:38 > To: OOGHE Sven > Cc: kirubaharan.dorairaj@wipro.com; ancp@ietf.org > Subject: Re: [ANCP] Comments on draft-ietf-ancp-framework-02 >=20 >=20 >=20 >>Page 28: >>=20 >>6. - Management related requirements - When ANCP adjacency is up in=20 >>AN, any configuration parameter successfully updated by ANCP should=20 >>not be allowed to be changed by local EMS. This is required to ensure=20 >>consistency of data and operation. >>=20 >> Good point. I think it should be added, unless someone speaks >=20 > up. >=20 >>=20 >=20 >=20 > This looks to contradict with what is described on page 22, section > 4.5.7: >=20 > "When using ANCP for Access Loop Configuration, the EMS needs to=20 > configure on the Access Node which parameters may or may not be=20 > modified using the Access Node Control Mechanism. Furthermore, for=20 > those parameters that may be modified using ANCP, the EMS needs to=20 > specify the default values to be used when an Access Node comes up = after recovery." >=20 > According to section 4.5.7, an EMS can change the by ANCP successfuly=20 > updated parameter, my not allowing the parameter anymore to be=20 > configured by ANCP and then the EMS can change it. From a conceptual=20 > point of view that is the same as an EMS that can change something=20 > that is successfuly updated by ANCP. >=20 > regards, > Stefaan >=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 ------_=_NextPart_001_01C8004B.D06D8EBD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable AW: [ANCP] Comments on draft-ietf-ancp-framework-02

 Sven,

see my comments = inline.

Regards,
Markus

-----Urspr=FCngliche = Nachricht-----
Von: OOGHE Sven = [mailto:Sven.Ooghe@alcatel-lucent.be<= SPAN LANG=3D"de">]
Gesendet: Mittwoch, = 26. September 2007 15:49
An: Freudenberger, = Markus; DE CNODDER Stefaan
Cc: Haag, Thomas; = Busser, Michael; ancp@ietf.org
Betreff: RE: [ANCP] = Comments on draft-ietf-ancp-framework-02

Markus,

I agree that the EMS = may overwrite a parameter value that was previously changed via ANCP. = That implies that the 3rd sub-bullet in section 6 needs to be removed. = Correct?

[Markus]
I = don't see anything to be removed, but I may did'nt understand your = point. You mentioned the 3rd sub-bullet in section 6, which = says:

o = The Access Node must provide the possibility using SNMP to associate = individual DSL lines with specific Access Node Control = Adjacencies.

Can = you explain in more detail why this needs to be removed?

The question then is = whether a configuration change by the EMS results in a notification = message being sent to the NAS. As you write in another email, the NAS is = made aware of a configuration change to the DSL parameters, thanks to = the Access Topology Discovery procedure.

Perhaps we need to = describe such a notification mechanism in a more generic context of = configuration changes. What do you think?

[Markus]
I = agree. My proposal for addional text to be added to section = 6:
o = The ANCP may provide a notification mechanism to inform the NAS about = configuration changes done by an EMS in a timely manner. This applies = only to changes of parameters which are part of the Use Case Access Loop = Configuration



Regards,
Sven

-----Original = Message-----
From: Freudenberger, = Markus [mailto:Markus.Freudenberger@t-systems.com]
Sent: woensdag 26 = september 2007 8:58
To: DE CNODDER = Stefaan; OOGHE Sven
Cc: ancp@ietf.org; = Haag, T; Busser, M
Subject: AW: [ANCP] = Comments on draft-ietf-ancp-framework-02

Stefaan, = Sven,

We do not agree to = the following:
"When ANCP = adjacency is up in AN, any configuration parameter successfully updated = by ANCP should not be allowed to be changed by local EMS. This is = required to ensure consistency of data and = operation."

for the use case line = configuration and in addition to the actual requirements contained in = chapter 6, we as an operator, want:

- to control via EMS = (e. g .via SNMP-If, CLI), which parameters can be changed and which = cannot be changed by ANCP in the acces node.

- that the EMS (e. g. = via SNMP-If, CLI) can change the parameters in the acces node which may = be set by ANCP at any time.

Regards
Markus
 

-----Urspr=FCngliche = Nachricht-----
Von: Stefaan DE = CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be]
Gesendet: Montag, = 24. September 2007 12:27
An: OOGHE = Sven
Cc: = ancp@ietf.org
Betreff: Re: [ANCP] = Comments on draft-ietf-ancp-framework-02


Sven,

It looks to me that = the original text is correct: the EMS has to configure which parameters = can be changed by the NAS and which cannot be changed.  If the NAS = tries to configure another parameter, the request will fail with an = appropriate error code.  It also implies that the EMS can change = whatever the NAS has configured before, without information the NAS = about this modification.

regards,
Stefaan


OOGHE Sven = wrote:

> = Stefaan,
>
> I think you're = right. This raises an interesting question: it looks
> like allowing = the EMS to "turn on" or "turn off" certain = parameters to
> be changed via = ANCP may lead to race conditions, i.e. both the NAS and
> the EMS wish to = perform an action on the same parameter (EMS wishes to
> "turn = off" changes via ANCP / NAS wishes to change the value of the =
> = parameter).
>
> Perhaps it's = simpler to determine beforehand what parameters may or
> may not be = changed via ANCP?
>
> = Regards,
> = Sven
>
> -----Original = Message-----
> From: DE = CNODDER Stefaan
> Sent: vrijdag = 21 september 2007 17:38
> To: OOGHE = Sven
> Cc: = kirubaharan.dorairaj@wipro.com; ancp@ietf.org
> Subject: Re: = [ANCP] Comments on draft-ietf-ancp-framework-02
>
>
>
>>Page = 28:
>> =
>>6. - = Management related requirements - When ANCP adjacency is up in =
>>AN, any = configuration parameter successfully updated by ANCP should =
>>not be = allowed to be changed by local EMS. This is required to ensure =
>>consistency = of data and operation.
>> =
>><Sven> = Good point. I think it should be added, unless someone = speaks
>
> = up.
>
>> =
>
>
> This looks to = contradict with what is described on page 22, section
> = 4.5.7:
>
> "When = using ANCP for Access Loop Configuration, the EMS needs to =
> configure on = the Access Node which parameters may or may not be
> modified using = the Access Node Control Mechanism.  Furthermore, for
> those = parameters that may be modified using ANCP, the EMS needs to =
> specify the = default values to be used when an Access Node comes up after = recovery."
>
> According to = section 4.5.7, an EMS can change the by ANCP successfuly
> updated = parameter, my not allowing the parameter anymore to be
> configured by = ANCP and then the EMS can change it.  From a conceptual =
> point of view = that is the same as an EMS that can change something
> that is = successfuly updated by ANCP.
>
> = regards,
> = Stefaan
>


_______________________________________________
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_01C8004B.D06D8EBD-- --===============0559683139== 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 --===============0559683139==-- From ancp-bounces@ietf.org Thu Sep 27 03:13: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 1IanYU-0003Cu-Vy; Thu, 27 Sep 2007 03:13:02 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IanYT-0003Cb-Oe for ancp-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 03:13:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IanYP-0002r7-7e for ancp@ietf.org; Thu, 27 Sep 2007 03:12:57 -0400 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IanYJ-000534-PX for ancp@ietf.org; Thu, 27 Sep 2007 03:12:53 -0400 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8R7C6Jq012405; Thu, 27 Sep 2007 09:12:06 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 27 Sep 2007 09:12:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] Comments on draft-ietf-ancp-framework-02 Date: Thu, 27 Sep 2007 09:12:49 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E38001663E93@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <1B6169C658325341A3B8066E23919E1C0E23DD@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Comments on draft-ietf-ancp-framework-02 Thread-Index: Acf+lgzf6REqYUxASDOyT4NFJSP71ABdA14gAA4MT+AAAQRg8AAjs6mQ References: <8144761F31F48D43AD53D09F5350E38001580172@FRVELSMBS22.ad2.ad.alcatel.com><46F79105.6090400@alcatel-lucent.be><1B6169C658325341A3B8066E23919E1C0E23D3@S4DE8PSAANK.mitte.t-com.de> <8144761F31F48D43AD53D09F5350E38001663B5A@FRVELSMBS22.ad2.ad.alcatel.com> <1B6169C658325341A3B8066E23919E1C0E23DD@S4DE8PSAANK.mitte.t-com.de> From: "OOGHE Sven" To: "Freudenberger, Markus" , "DE CNODDER Stefaan" X-OriginalArrivalTime: 27 Sep 2007 07:12:50.0380 (UTC) FILETIME=[D05C40C0:01C800D5] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0634ec58aad05a6aa9ac7d4670be9c6c Cc: "Haag, T" , "Busser, M" , 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: , Content-Type: multipart/mixed; boundary="===============1325294202==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1325294202== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C800D5.D007F548" This is a multi-part message in MIME format. ------_=_NextPart_001_01C800D5.D007F548 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Markus, =20 see inline. ________________________________ From: Freudenberger, Markus [mailto:Markus.Freudenberger@t-systems.com]=20 Sent: woensdag 26 september 2007 16:45 To: OOGHE Sven; DE CNODDER Stefaan Cc: Haag, T; Busser, M; ancp@ietf.org Subject: AW: [ANCP] Comments on draft-ietf-ancp-framework-02 Sven,=20 see my comments inline.=20 Regards,=20 Markus=20 -----Urspr=FCngliche Nachricht-----=20 Von: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be = ]=20 Gesendet: Mittwoch, 26. September 2007 15:49=20 An: Freudenberger, Markus; DE CNODDER Stefaan=20 Cc: Haag, Thomas; Busser, Michael; ancp@ietf.org=20 Betreff: RE: [ANCP] Comments on draft-ietf-ancp-framework-02=20 Markus,=20 I agree that the EMS may overwrite a parameter value that was previously = changed via ANCP. That implies that the 3rd sub-bullet in section 6 = needs to be removed. Correct? [Markus]=20 I don't see anything to be removed, but I may did'nt understand your = point. You mentioned the 3rd sub-bullet in section 6, which says: o The Access Node must provide the possibility using SNMP to associate = individual DSL lines with specific Access Node Control Adjacencies. Can you explain in more detail why this needs to be removed? =20 My mistake: I referred to a bullet in one of my own working = document, which actually included some text by Kirubaharan. In draft-02 = this text wasn't there. So forget about this question. =20 The question then is whether a configuration change by the EMS results = in a notification message being sent to the NAS. As you write in another = email, the NAS is made aware of a configuration change to the DSL = parameters, thanks to the Access Topology Discovery procedure. Perhaps we need to describe such a notification mechanism in a more = generic context of configuration changes. What do you think? [Markus]=20 I agree. My proposal for addional text to be added to section 6:=20 o The ANCP may provide a notification mechanism to inform the NAS about = configuration changes done by an EMS in a timely manner. This applies = only to changes of parameters which are part of the Use Case Access Loop = Configuration I think it makese sense to add this bullet to cover the generic = case of Access Loop Configuration. It shows that the AN can notify the = NAS of those parameter changes that the NAS is allowed to perform. The = NAS should of course not be notified of changes to parameters that the = NAS is not allowed to change in the first place.=20 =20 Regards, Sven=20 Regards,=20 Sven=20 -----Original Message-----=20 From: Freudenberger, Markus [mailto:Markus.Freudenberger@t-systems.com = ]=20 Sent: woensdag 26 september 2007 8:58=20 To: DE CNODDER Stefaan; OOGHE Sven=20 Cc: ancp@ietf.org; Haag, T; Busser, M=20 Subject: AW: [ANCP] Comments on draft-ietf-ancp-framework-02=20 Stefaan, Sven,=20 We do not agree to the following:=20 "When ANCP adjacency is up in AN, any configuration parameter = successfully updated by ANCP should not be allowed to be changed by = local EMS. This is required to ensure consistency of data and = operation." for the use case line configuration and in addition to the actual = requirements contained in chapter 6, we as an operator, want: - to control via EMS (e. g .via SNMP-If, CLI), which parameters can be = changed and which cannot be changed by ANCP in the acces node. - that the EMS (e. g. via SNMP-If, CLI) can change the parameters in the = acces node which may be set by ANCP at any time. Regards=20 Markus=20 =20 -----Urspr=FCngliche Nachricht-----=20 Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be = ]=20 Gesendet: Montag, 24. September 2007 12:27=20 An: OOGHE Sven=20 Cc: ancp@ietf.org=20 Betreff: Re: [ANCP] Comments on draft-ietf-ancp-framework-02=20 Sven,=20 It looks to me that the original text is correct: the EMS has to = configure which parameters can be changed by the NAS and which cannot be = changed. If the NAS tries to configure another parameter, the request = will fail with an appropriate error code. It also implies that the EMS = can change whatever the NAS has configured before, without information = the NAS about this modification. regards,=20 Stefaan=20 OOGHE Sven wrote:=20 > Stefaan,=20 >=20 > I think you're right. This raises an interesting question: it looks=20 > like allowing the EMS to "turn on" or "turn off" certain parameters to = > be changed via ANCP may lead to race conditions, i.e. both the NAS and = > the EMS wish to perform an action on the same parameter (EMS wishes to = > "turn off" changes via ANCP / NAS wishes to change the value of the=20 > parameter).=20 >=20 > Perhaps it's simpler to determine beforehand what parameters may or=20 > may not be changed via ANCP?=20 >=20 > Regards,=20 > Sven=20 >=20 > -----Original Message-----=20 > From: DE CNODDER Stefaan=20 > Sent: vrijdag 21 september 2007 17:38=20 > To: OOGHE Sven=20 > Cc: kirubaharan.dorairaj@wipro.com; ancp@ietf.org=20 > Subject: Re: [ANCP] Comments on draft-ietf-ancp-framework-02=20 >=20 >=20 >=20 >>Page 28:=20 >>=20 >>6. - Management related requirements - When ANCP adjacency is up in=20 >>AN, any configuration parameter successfully updated by ANCP should=20 >>not be allowed to be changed by local EMS. This is required to ensure=20 >>consistency of data and operation.=20 >>=20 >> Good point. I think it should be added, unless someone speaks=20 >=20 > up.=20 >=20 >>=20 >=20 >=20 > This looks to contradict with what is described on page 22, section=20 > 4.5.7:=20 >=20 > "When using ANCP for Access Loop Configuration, the EMS needs to=20 > configure on the Access Node which parameters may or may not be=20 > modified using the Access Node Control Mechanism. Furthermore, for=20 > those parameters that may be modified using ANCP, the EMS needs to=20 > specify the default values to be used when an Access Node comes up = after recovery."=20 >=20 > According to section 4.5.7, an EMS can change the by ANCP successfuly=20 > updated parameter, my not allowing the parameter anymore to be=20 > configured by ANCP and then the EMS can change it. From a conceptual=20 > point of view that is the same as an EMS that can change something=20 > that is successfuly updated by ANCP.=20 >=20 > regards,=20 > Stefaan=20 >=20 _______________________________________________=20 ANCP mailing list=20 ANCP@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ancp = =20 _______________________________________________=20 ANCP mailing list=20 ANCP@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ancp = =20 ------_=_NextPart_001_01C800D5.D007F548 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable AW: [ANCP] Comments on = draft-ietf-ancp-framework-02
Markus,
 
see inline.

From: Freudenberger, Markus=20 [mailto:Markus.Freudenberger@t-systems.com]
Sent: woensdag 26 = september 2007 16:45
To: OOGHE Sven; DE CNODDER = Stefaan
Cc:=20 Haag, T; Busser, M; ancp@ietf.org
Subject: AW: [ANCP] Comments = on=20 draft-ietf-ancp-framework-02

 Sven, =

see my comments = inline.=20

Regards, =
Markus

-----Urspr=FCngliche=20 Nachricht-----
Von:=20 OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be]
Gesendet: Mittwoch, 26. September 2007 = 15:49=20
An: Freudenberger, = Markus; DE CNODDER=20 Stefaan
Cc: Haag,=20 Thomas; Busser, Michael; ancp@ietf.org
Betreff: RE: [ANCP] Comments on=20 draft-ietf-ancp-framework-02

Markus, =

I agree that the EMS may = overwrite a=20 parameter value that was previously changed via ANCP. That implies that = the 3rd=20 sub-bullet in section 6 needs to be removed. Correct?

[Markus]=20
I don't = see anything to=20 be removed, but I may did'nt understand your point. You mentioned the = 3rd=20 sub-bullet in section 6, which says:

o The = Access Node must=20 provide the possibility using SNMP to associate individual DSL lines = with=20 specific Access Node Control Adjacencies.

Can you = explain in more=20 detail why this needs to be removed?  

<Sven> My mistake: I referred to a bullet in  one of my own = working document,=20 which actually included some text by Kirubaharan. In draft-02 this text = wasn't=20 there. So forget=20 about this question.  

The question then is = whether a=20 configuration change by the EMS results in a notification message being = sent to=20 the NAS. As you write in another email, the NAS is made aware of a = configuration=20 change to the DSL parameters, thanks to the Access Topology Discovery=20 procedure.

Perhaps we need to = describe such a=20 notification mechanism in a more generic context of configuration = changes. What=20 do you think?

[Markus]=20
I agree. = My proposal for=20 addional text to be added to section 6:
o The ANCP may provide a = notification mechanism=20 to inform the NAS about configuration changes done by an EMS in a timely = manner.=20 This applies only to changes of parameters which are part of the Use = Case Access=20 Loop Configuration

 <Sven> I think it makese sense to add this bullet = to cover=20 the generic case of Access Loop Configuration. It shows that = the AN=20 can notify the NAS of those parameter changes that the NAS is = allowed to=20 perform. The NAS should of course not be notified of changes to = parameters that=20 the NAS is not allowed to change in the first place. =
 
Regards,
Sven 

Regards, =
Sven

-----Original=20 Message-----
From:=20 Freudenberger, Markus [mailto:Markus.Freudenberger@t-systems.com<= SPAN=20 lang=3Dde>]
Sent: woensdag 26 september 2007 = 8:58
To: DE CNODDER Stefaan; OOGHE = Sven=20
Cc: ancp@ietf.org; Haag, = T; Busser,=20 M
Subject: = AW: [ANCP]=20 Comments on draft-ietf-ancp-framework-02

Stefaan, = Sven,

We do not agree to the=20 following:
"When ANCP=20 adjacency is up in AN, any configuration parameter successfully updated = by ANCP=20 should not be allowed to be changed by local EMS. This is required to = ensure=20 consistency of data and operation."

for the use case line = configuration and=20 in addition to the actual requirements contained in chapter 6, we as an=20 operator, want:

- to control via EMS (e. = g .via=20 SNMP-If, CLI), which parameters can be changed and which cannot be = changed by=20 ANCP in the acces node.

- that the EMS (e. g. via = SNMP-If, CLI)=20 can change the parameters in the acces node which may be set by ANCP at = any=20 time.

Regards =
Markus
 

-----Urspr=FCngliche=20 Nachricht-----
Von:=20 Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be]
Gesendet: Montag, 24. September 2007 = 12:27=20
An: OOGHE = Sven
Cc: ancp@ietf.org =
Betreff: Re: [ANCP] Comments on=20 draft-ietf-ancp-framework-02


Sven,

It looks to me that the = original text=20 is correct: the EMS has to configure which parameters can be changed by = the NAS=20 and which cannot be changed.  If the NAS tries to configure another = parameter, the request will fail with an appropriate error code.  = It also=20 implies that the EMS can change whatever the NAS has configured before, = without=20 information the NAS about this modification.

regards, =
Stefaan


OOGHE Sven = wrote:

> = Stefaan,
>
> I think you're right. This raises an = interesting=20 question: it looks
>=20 like allowing the EMS to "turn on" or "turn off" certain parameters to=20
> be = changed via ANCP=20 may lead to race conditions, i.e. both the NAS and =
> the EMS wish to perform an = action on the=20 same parameter (EMS wishes to
> "turn off" changes via ANCP / NAS wishes to change the = value of the=20
>=20 parameter).
>=20
> = Perhaps it's=20 simpler to determine beforehand what parameters may or =
> may not be changed via = ANCP?=20
> =
> Regards, =
> Sven
>
> -----Original Message-----
> From: DE CNODDER Stefaan =
> Sent: vrijdag 21 september = 2007=20 17:38
> = To: OOGHE=20 Sven
> = Cc:=20 kirubaharan.dorairaj@wipro.com; ancp@ietf.org
> Subject: Re: [ANCP] Comments = on=20 draft-ietf-ancp-framework-02
>
>=20
>=20
>>Page=20 28:
>>=20
>>6. = - Management=20 related requirements - When ANCP adjacency is up in =
>>AN, any configuration = parameter=20 successfully updated by ANCP should
>>not be allowed to be changed by local EMS. = This is=20 required to ensure
>>consistency of data and operation. =
>>
>><Sven> Good point. I think it should = be added,=20 unless someone speaks
>
>=20 up.
>=20
>>=20
>=20
>=20
> This = looks to=20 contradict with what is described on page 22, section =
> 4.5.7: =
>
> "When using ANCP for Access Loop = Configuration, the EMS=20 needs to
> configure=20 on the Access Node which parameters may or may not be =
> modified using the Access = Node Control=20 Mechanism.  Furthermore, for
> those parameters that may be modified using = ANCP, the EMS=20 needs to
> specify=20 the default values to be used when an Access Node comes up after=20 recovery."
>=20
> = According to=20 section 4.5.7, an EMS can change the by ANCP successfuly =
> updated parameter, my not = allowing the=20 parameter anymore to be
> configured by ANCP and then the EMS can change it.  = >From a=20 conceptual
> point of=20 view that is the same as an EMS that can change something=20
> that = is successfuly=20 updated by ANCP.
>=20
>=20 regards,
>=20 Stefaan
>=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

------_=_NextPart_001_01C800D5.D007F548-- --===============1325294202== 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 --===============1325294202==--