From l3vpn-bounces@ietf.org Tue Jun 05 05:06: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 1HvUzk-0006Te-9w; Tue, 05 Jun 2007 05:06:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvUzi-0006R2-TO for l3vpn@ietf.org; Tue, 05 Jun 2007 05:06:26 -0400 Received: from web314.biz.mail.mud.yahoo.com ([68.142.199.14]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvUzf-0005cV-GU for l3vpn@ietf.org; Tue, 05 Jun 2007 05:06:26 -0400 Received: (qmail 60945 invoked by uid 60001); 5 Jun 2007 09:06:23 -0000 X-YMail-OSG: eSLshtoVM1kudJlqBZ7rG_6UcE4nx2Fr103Do.7C6iE0IvcO45HcXikhV5MkFUkbk7Sl0Z45I1etd6wzKOXQk.JuNPazUh8311KaVpPWflmWbHw- Received: from [68.106.115.70] by web314.biz.mail.mud.yahoo.com via HTTP; Tue, 05 Jun 2007 02:06:23 PDT Date: Tue, 5 Jun 2007 02:06:23 -0700 (PDT) From: Rick Wilder To: l3vpn@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <41934.36278.qm@web314.biz.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Shane Amante Subject: VPN authentication/verification and WG re-chartering X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org L3VPN participants, As was mentioned at the Prague meeting and on this email list, Ron, Mark, and I are currently updating the charter for the L3VPN WG. When Ron called for work items that need to be undertaken by the WG, Shane Amante recommended reviving the VPN authentication/verification work that was started some time back, but not completed. (his email copied below) In order for this to be included in the WG charter, we need to hear some more support for this work item within the next 10 days. If VPN authentication/verification is of importance to you, please weigh in before re-chartering is completed. Rick ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Ron Bonica wrote: > Folks, > > We are considering an update to the L3VPN WG charter. In the new > charter, VPN Multicast will remain high on our list of work items. So > far, the only request for a new work item has been "MPLS services > delivered over L3VPN infrastructure". (See > draft-kumaki-l3vpn-e2e-rsvp-te-reqs). > > Would anyone else like to recommend work items for inclusion in the charter? I agree VPN multicast should be a high priority for the WG. In addition, I would also recommend that the WG look at solving for two additional things: 1) iBGP PE-CE http://www.watersprings.org/pub/id/draft-marques-l3vpn-ibgp-01.txt At a minimum, we should look at publishing this as an Informational Draft -- since, to my knowledge, there is at least 1 major implementation that does this today. Note, I don't think we need to put this in the charter if it's just going as Informational, unless it has a significant affect on many other drafts & RFC's ... so, perhaps this is just a small "todo" item. 2) "Layer-3 Import/Export Verification". According to the archives, there appears to be at least 3 different WG drafts: http://tools.ietf.org/html/draft-ietf-l3vpn-auth-00 http://tools.ietf.org/html/draft-ietf-l3vpn-l3vpn-auth-01 http://tools.ietf.org/html/draft-ietf-l3vpn-vpn-verification-00 ... although, it appears as if the first two are the same draft, just with a title change. Regardless, all three drafts have expired over the course of the last 2-4 years. I realize there is also work occurring in tcpm, sidr, and, perhaps, others to secure various elements of BGP (key rollover, securing path update messages, etc.). However, its not clear what is the time horizon to complete that work, and more importantly whether they have adequate reqmt's to: a) deliver 'lightweight' solutions for IPVPN's; and, b) will be able to adequately accomodate some properties unique to IPVPN's that aren't applicable to the general Internet, (e.g.: AS_OVERRIDE). In summary, I would propose we do two things for this one: 1) Complete the work on at least one of the outstanding l3vpn vpn verification drafts; and, 2) Look at specifying reqmt's for sidr, or other relevant WG's, to accomodate reqmt's unique to L3VPN's to secure the control plane. -shane From l3vpn-bounces@ietf.org Tue Jun 05 09:13:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvYqj-0001Wc-4u; Tue, 05 Jun 2007 09:13:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvYqi-0001WR-JS for l3vpn@ietf.org; Tue, 05 Jun 2007 09:13:24 -0400 Received: from out002.apptix.savvis.net ([216.91.32.45] helo=out002a.email.savvis.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvYqf-00026e-7b for l3vpn@ietf.org; Tue, 05 Jun 2007 09:13:24 -0400 Received: from S228130HZ1EW24.apptix-01.savvis.net ([10.146.4.22]) by out002a.email.savvis.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 08:13:20 -0500 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: Tue, 5 Jun 2007 08:13:19 -0500 Message-ID: <2DC6358FAE5D5F44A12DC5ABFDA8AC4DD440B6@s228130hz1ew24.apptix-01.savvis.net> In-Reply-To: <41934.36278.qm@web314.biz.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VPN authentication/verification and WG re-chartering Thread-Index: AcenUNnnSg0rp+3ORSekLdxQWCWWVgAFlQ1A From: "Schliesser, Benson" To: "Rick Wilder" , X-OriginalArrivalTime: 05 Jun 2007 13:13:20.0850 (UTC) FILETIME=[4A088B20:01C7A773] X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: Shane Amante Subject: RE: VPN authentication/verification and WG re-chartering X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org I agree that a) VPN authentication should be included in the new charter. In my experience as a SP, concern over "security" is one of the most common reasons that users choose against L3VPN services. ("Control" being the other common reason.) To whatever extent authentication mechanisms can provide validation of the VPN membership and routes, I think it will be a valuable component of a L3VPN service. I would like to see discussion of the requirements first, so that candidate solutions have a point of reference. I also agree with Shane's message that b) multicast in L3VPN and c) iBGP as PE-CE protocol should also be driven to completion, possibly in the charter. And finally, I also think that more discussion is needed around d) inter-provider L3VPN interconnection. I understand that discussion around this topic is happening in other forums, and I believe it would be useful if some of that discussion "came home" to influence this WG. Specifically, most providers with whom I speak are confounded by their desire to run "option B" for scale and management reasons versus their need to run "option A" due to implementation issues and complexity, feature constraints, etc. Perhaps the charter should reflect this topic, or perhaps this should be relocated to another WG? Cheers, -Benson > -----Original Message----- > From: Rick Wilder [mailto:rick@rhwilder.net]=20 > Sent: Tuesday, June 05, 2007 10:06 AM > To: l3vpn@ietf.org > Cc: Shane Amante > Subject: VPN authentication/verification and WG re-chartering >=20 > =20 > L3VPN participants, > =20 > =20 > As was mentioned at the Prague meeting and on this email=20 > list, Ron, Mark, and I are > currently updating the charter for the L3VPN WG.=20 > =20 > When Ron called for work items that need to be undertaken by=20 > the WG, Shane Amante > recommended reviving the VPN authentication/verification > work that was started some time back, but not completed. (his=20 > email copied below) > =20 > In order for this to be included in the WG charter, we need=20 > to hear some more support for > this work item within the next 10 days.=20 > If VPN authentication/verification is of importance to you,=20 > please weigh in before > re-chartering is completed. > =20 > Rick > =20 > =20 > -------------------------------------------------------------- > -------------------------------------------------------------- > -------------------------------------------------------------- > ------------------- >=20 >=20 > Ron Bonica wrote: > > Folks, > >=20 > > We are considering an update to the L3VPN WG charter. In the new > > charter, VPN Multicast will remain high on our list of work=20 > items. So > > far, the only request for a new work item has been "MPLS services > > delivered over L3VPN infrastructure". (See > > draft-kumaki-l3vpn-e2e-rsvp-te-reqs). > >=20 > > Would anyone else like to recommend work items for=20 > inclusion in the charter? >=20 > I agree VPN multicast should be a high priority for the WG. >=20 > In addition, I would also recommend that the WG look at=20 > solving for two=20 > additional things: > 1) iBGP PE-CE > http://www.watersprings.org/pub/id/draft-marques-l3vpn-ibgp-01.txt > At a minimum, we should look at publishing this as an Informational=20 > Draft -- since, to my knowledge, there is at least 1 major=20 > implementation that does this today. Note, I don't think we=20 > need to put=20 > this in the charter if it's just going as Informational,=20 > unless it has a=20 > significant affect on many other drafts & RFC's ... so,=20 > perhaps this is=20 > just a small "todo" item. >=20 > 2) "Layer-3 Import/Export Verification". According to the archives,=20 > there appears to be at least 3 different WG drafts: > http://tools.ietf.org/html/draft-ietf-l3vpn-auth-00 > http://tools.ietf.org/html/draft-ietf-l3vpn-l3vpn-auth-01 > http://tools.ietf.org/html/draft-ietf-l3vpn-vpn-verification-00 > ... although, it appears as if the first two are the same draft, just=20 > with a title change. Regardless, all three drafts have=20 > expired over the=20 > course of the last 2-4 years. >=20 > I realize there is also work occurring in tcpm, sidr, and, perhaps,=20 > others to secure various elements of BGP (key rollover, securing path=20 > update messages, etc.). However, its not clear what is the=20 > time horizon=20 > to complete that work, and more importantly whether they have=20 > adequate=20 > reqmt's to: a) deliver 'lightweight' solutions for IPVPN's;=20 > and, b) will=20 > be able to adequately accomodate some properties unique to=20 > IPVPN's that=20 > aren't applicable to the general Internet, (e.g.: AS_OVERRIDE). >=20 > In summary, I would propose we do two things for this one: > 1) Complete the work on at least one of the outstanding l3vpn vpn=20 > verification drafts; and, > 2) Look at specifying reqmt's for sidr, or other relevant WG's, to=20 > accomodate reqmt's unique to L3VPN's to secure the control plane. >=20 > -shane >=20 >=20 >=20 From l3vpn-bounces@ietf.org Tue Jun 05 09:21:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvYyj-0006VP-P4; Tue, 05 Jun 2007 09:21:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvYyi-0006VJ-HP for l3vpn@ietf.org; Tue, 05 Jun 2007 09:21:40 -0400 Received: from out002.apptix.savvis.net ([216.91.32.45] helo=out002a.email.savvis.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvYyh-0003GX-At for l3vpn@ietf.org; Tue, 05 Jun 2007 09:21:40 -0400 Received: from S228130HZ1EW24.apptix-01.savvis.net ([10.146.4.22]) by out002a.email.savvis.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 08:21:39 -0500 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: Tue, 5 Jun 2007 08:21:39 -0500 Message-ID: <2DC6358FAE5D5F44A12DC5ABFDA8AC4DD440CA@s228130hz1ew24.apptix-01.savvis.net> In-Reply-To: <2DC6358FAE5D5F44A12DC5ABFDA8AC4DD440B6@s228130hz1ew24.apptix-01.savvis.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VPN Auth (was VPN authentication/verification and WG re-chartering) Thread-Index: AcenUNnnSg0rp+3ORSekLdxQWCWWVgAFlQ1AAAMYSzA= From: "Schliesser, Benson" To: X-OriginalArrivalTime: 05 Jun 2007 13:21:39.0038 (UTC) FILETIME=[72F9FFE0:01C7A774] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: VPN Auth (was VPN authentication/verification and WG re-chartering) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Sorry for replying to my own message, but I would like to encourage discussion around VPN Auth requirements. > I would like to see discussion of the requirements first, so that=20 > candidate solutions have a point of reference. For instance, I would argue that there are several roles/modes of authentication that must be considered: SP-managed, user-managed, and co-managed. Each of these modes have slightly different requirements, of course, and different alerting and/or response mechanisms. Across all of these modes the primary goal is to be assured that all sites attached to the VPN are intended and allowed to be members. Secondary goals *might* include verification that the CE was configured by the correct authority (i.e. is not a hacked or replaced device), that routes originating from the CE (or PE) are legitimate, etc. Maybe a solution for one of the secondary goals might actually solve the primary goal, too. Any thoughts on these goals, and/or how they translate into technical requirements? Cheers, -Benson From l3vpn-bounces@ietf.org Tue Jun 05 10:27:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZzu-0003kS-9Z; Tue, 05 Jun 2007 10:26:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZzt-0003ju-6H for l3vpn@ietf.org; Tue, 05 Jun 2007 10:26:57 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvZzs-0006uw-UT for l3vpn@ietf.org; Tue, 05 Jun 2007 10:26:57 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 05 Jun 2007 10:26:56 -0400 X-IronPort-AV: i="4.16,386,1175486400"; d="scan'208"; a="61971320:sNHT46088260" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l55EQuuF006325; Tue, 5 Jun 2007 10:26:56 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l55EQpBs021297; Tue, 5 Jun 2007 14:26:56 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 10:26:46 -0400 Received: from [10.83.15.60] ([10.83.15.60]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 10:26:46 -0400 In-Reply-To: <2DC6358FAE5D5F44A12DC5ABFDA8AC4DD440CA@s228130hz1ew24.apptix-01.savvis.net> References: <2DC6358FAE5D5F44A12DC5ABFDA8AC4DD440CA@s228130hz1ew24.apptix-01.savvis.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1908BCC0-EDCB-4B24-940C-F0F8A6B9F82E@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Date: Tue, 5 Jun 2007 10:26:45 -0400 To: "Schliesser, Benson" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 05 Jun 2007 14:26:46.0702 (UTC) FILETIME=[8C2034E0:01C7A77D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1327; t=1181053616; x=1181917616; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=20=22Thomas=20D.=20Nadeau=22=20 |Subject:=20Re=3A=20VPN=20Auth=20(was=20VPN=20authentication/verification =20and=20WG=20re-chartering) |Sender:=20 |To:=20=22Schliesser,=20Benson=22=20; bh=7lxgcai1xE+Onf0ibYx0S6yEiGhs7t+9DRYof4BNaHc=; b=sAdMzc3XZcGqsYqd1fDuF9xmn33uUFS1D7XSoKtNcecWyC8bMGszD9u4J2quh+V6985quyVo J2M8t8sNYMVbRxD0CNcaFTR1rUz6Wcf4PuHNUrZXrY02LfPHXM8VgLhk; Authentication-Results: rtp-dkim-2; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: l3vpn@ietf.org Subject: Re: VPN Auth (was VPN authentication/verification and WG re-chartering) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org > Sorry for replying to my own message, but I would like to encourage > discussion around VPN Auth requirements. > >> I would like to see discussion of the requirements first, so that >> candidate solutions have a point of reference. > > For instance, I would argue that there are several roles/modes of > authentication that must be considered: SP-managed, user-managed, and > co-managed. Each of these modes have slightly different > requirements, of > course, and different alerting and/or response mechanisms. And one other thing related to an important point you raised earlier related would be two other cases: multiple SP-managed, co- managed with multiple SPs where there are multiple providers. --Tom > Across all of these modes the primary goal is to be assured that all > sites attached to the VPN are intended and allowed to be members. > Secondary goals *might* include verification that the CE was > configured > by the correct authority (i.e. is not a hacked or replaced device), > that > routes originating from the CE (or PE) are legitimate, etc. Maybe a > solution for one of the secondary goals might actually solve the > primary > goal, too. > > Any thoughts on these goals, and/or how they translate into technical > requirements? > > Cheers, > -Benson From l3vpn-bounces@ietf.org Tue Jun 05 12:03:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvbV5-000131-29; Tue, 05 Jun 2007 12:03:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvbV3-0000wW-4x for l3vpn@ietf.org; Tue, 05 Jun 2007 12:03:13 -0400 Received: from out001.apptix.savvis.net ([216.91.32.44] helo=out001a.email.savvis.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvbV1-0003BZ-Ty for l3vpn@ietf.org; Tue, 05 Jun 2007 12:03:13 -0400 Received: from S228130HZ1EW24.apptix-01.savvis.net ([10.146.4.22]) by out001a.email.savvis.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 11:03:11 -0500 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: Tue, 5 Jun 2007 11:03:08 -0500 Message-ID: <2DC6358FAE5D5F44A12DC5ABFDA8AC4DD442DF@s228130hz1ew24.apptix-01.savvis.net> In-Reply-To: <1908BCC0-EDCB-4B24-940C-F0F8A6B9F82E@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VPN Auth (was VPN authentication/verification and WG re-chartering) Thread-Index: AcenfZKqvcWh8Zl+QDuDvb72LGh26AADDKdA From: "Schliesser, Benson" To: "Thomas D. Nadeau" X-OriginalArrivalTime: 05 Jun 2007 16:03:11.0971 (UTC) FILETIME=[046A3330:01C7A78B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: l3vpn@ietf.org Subject: RE: VPN Auth (was VPN authentication/verification and WG re-chartering) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Tom- That's a good point. It can (easily) be argued that these multi-SP cases are actually the most important for VPN authentication to address... Certainly, the trust models are complicated. I.e. who owns the customer relationship, who is managing the service(s), etc. But in any case, there are too many contributors in the VPN for things to just work without occasional error. VPN authentication is very valuable in this environment. Cheers, -Benson > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]=20 > Sent: Tuesday, June 05, 2007 3:27 PM > To: Schliesser, Benson > Cc: l3vpn@ietf.org > Subject: Re: VPN Auth (was VPN authentication/verification=20 > and WG re-chartering) >=20 >=20 > > Sorry for replying to my own message, but I would like to encourage > > discussion around VPN Auth requirements. > > > >> I would like to see discussion of the requirements first, so that > >> candidate solutions have a point of reference. > > > > For instance, I would argue that there are several roles/modes of > > authentication that must be considered: SP-managed,=20 > user-managed, and > > co-managed. Each of these modes have slightly different =20 > > requirements, of > > course, and different alerting and/or response mechanisms. >=20 > And one other thing related to an important point you raised > earlier related would be two other cases: multiple SP-managed, co-=20 > managed > with multiple SPs where there are multiple providers. >=20 > --Tom >=20 >=20 > > Across all of these modes the primary goal is to be assured that all > > sites attached to the VPN are intended and allowed to be members. > > Secondary goals *might* include verification that the CE was =20 > > configured > > by the correct authority (i.e. is not a hacked or replaced=20 > device), =20 > > that > > routes originating from the CE (or PE) are legitimate, etc. Maybe a > > solution for one of the secondary goals might actually solve the =20 > > primary > > goal, too. > > > > Any thoughts on these goals, and/or how they translate into=20 > technical > > requirements? > > > > Cheers, > > -Benson >=20 From l3vpn-bounces@ietf.org Tue Jun 05 17:11: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 1HvgJL-0005NE-Vj; Tue, 05 Jun 2007 17:11:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvgJJ-0005N8-Sg for l3vpn@ietf.org; Tue, 05 Jun 2007 17:11:25 -0400 Received: from borg.juniper.net ([207.17.137.119] helo=smtpb.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvgJI-0005ZW-KP for l3vpn@ietf.org; Tue, 05 Jun 2007 17:11:25 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpb.juniper.net with ESMTP; 05 Jun 2007 14:11:23 -0700 Received: from [172.23.1.63] ([172.23.1.63] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 17:11:14 -0400 Message-ID: <4665D16E.7030303@juniper.net> Date: Tue, 05 Jun 2007 17:11:10 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Schliesser, Benson" References: <2DC6358FAE5D5F44A12DC5ABFDA8AC4DD440CA@s228130hz1ew24.apptix-01.savvis.net> In-Reply-To: <2DC6358FAE5D5F44A12DC5ABFDA8AC4DD440CA@s228130hz1ew24.apptix-01.savvis.net> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jun 2007 21:11:14.0256 (UTC) FILETIME=[0CB71500:01C7A7B6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: l3vpn@ietf.org Subject: Re: VPN Auth (was VPN authentication/verification and WG re-chartering) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Schliesser, Benson wrote: > Sorry for replying to my own message, but I would like to encourage > discussion around VPN Auth requirements. > > >>I would like to see discussion of the requirements first, so that >>candidate solutions have a point of reference. > > > For instance, I would argue that there are several roles/modes of > authentication that must be considered: SP-managed, user-managed, and > co-managed. Each of these modes have slightly different requirements, of > course, and different alerting and/or response mechanisms. Could you say a few words about what each of these terms means? > > Across all of these modes the primary goal is to be assured that all > sites attached to the VPN are intended and allowed to be members. > Secondary goals *might* include verification that the CE was configured > by the correct authority (i.e. is not a hacked or replaced device), that > routes originating from the CE (or PE) are legitimate, etc. Maybe a > solution for one of the secondary goals might actually solve the primary > goal, too. Could you say a few words about the secondary goals? Ron > > Any thoughts on these goals, and/or how they translate into technical > requirements? > > Cheers, > -Benson > From l3vpn-bounces@ietf.org Thu Jun 07 19:08:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwR5T-0002up-Qk; Thu, 07 Jun 2007 19:08:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwR5S-0002uk-Nc for l3vpn@ietf.org; Thu, 07 Jun 2007 19:08:14 -0400 Received: from out001.apptix.savvis.net ([216.91.32.44] helo=out001a.email.savvis.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwR5S-0003wD-Eo for l3vpn@ietf.org; Thu, 07 Jun 2007 19:08:14 -0400 Received: from S228130HZ1EW24.apptix-01.savvis.net ([10.146.4.22]) by out001a.email.savvis.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 18:08:14 -0500 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: Thu, 7 Jun 2007 18:08:13 -0500 Message-ID: <2DC6358FAE5D5F44A12DC5ABFDA8AC4DE68821@s228130hz1ew24.apptix-01.savvis.net> In-Reply-To: <4665D16E.7030303@juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VPN Auth (was VPN authentication/verification and WG re-chartering) Thread-Index: AcenthMni6LGx0R5RVuED9cqeUKMZwBmlqAA From: "Schliesser, Benson" To: "Ron Bonica" , X-OriginalArrivalTime: 07 Jun 2007 23:08:14.0146 (UTC) FILETIME=[B9B8CA20:01C7A958] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Subject: RE: VPN Auth (was VPN authentication/verification and WG re-chartering) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Hi, Ron. Ron Bonica wrote: > Schliesser, Benson wrote: > > For instance, I would argue that there are several roles/modes of > > authentication that must be considered: SP-managed,=20 > user-managed, and > > co-managed. Each of these modes have slightly different=20 > requirements, of > > course, and different alerting and/or response mechanisms. >=20 > Could you say a few words about what each of these terms means? Sure. The essence of what I'm referring to by each of these "modes" is the answer to the question, "who cares?". For whatever reason ("managed" product offering, associated SLA, etc) the SP may care about whether invalid sites are attached to the VPN. In the simplest case this may just provide a point of measurement for the SP to know if there has been a provisioning mistake. In other cases this may trigger a response process by the SP, SLA credits/payments, etc. This is what I mean by "SP-managed". Similarly, the customer/user may also care. Clearly the customer may have security concerns. There may also be vendor-management issues, such as SLA-credit requests. This is what I mean by "user-managed". The hybrid "co-managed" case is where the SP and the user both care. I imagine that for each of these modes, the notable difference is who has access to which authentication keys. I don't want to presume to know what form the keys take, whether there are one or more, etc. But I do assume that the verification process will require some knowledge of key data, which may need to exist independently for the SP and user, or in a mode which can be shared, etc. When I refer to "alerting" mechanisms, I mean for instance that the PE or CE may issue alarms (SNMP traps, CLI messages, etc). By the term "response" I mean something automated, such as I.e. a PE-based mechanism to automatically shutdown interfaces that fail authentication. As Tom pointed out in his message, the multi-provider case just exacerbates this issue. For instance, does the user have a direct relationship with each provider or is there a single provider that is responsible for the customer relationship and acts as a management proxy for the other providers? This may impact who has access to which keys... Etc. Another scenario, which occurred to me after my previous post, is the extranet case where there are multiple (untrusting) users connecting to the same L3VPN. > > Across all of these modes the primary goal is to be assured that all > > sites attached to the VPN are intended and allowed to be members. > > Secondary goals *might* include verification that the CE=20 > was configured > > by the correct authority (i.e. is not a hacked or replaced=20 > device), that > > routes originating from the CE (or PE) are legitimate, etc. Maybe a > > solution for one of the secondary goals might actually=20 > solve the primary > > goal, too. >=20 > Could you say a few words about the secondary goals? There may be other secondary goals, in addition to the ones I mentioned here. But I'll be glad to explain the ones I brought up. The "verification" goal is possibly a tough one... What I mean is that the authentication mechanism can indicate whether the CE was modified or replaced. For instance if a SP is offering a fully-managed service, where they are responsible for the CE device and configuration, can they know if the user unplugs the SP-managed CE and replaces it with their own? (Or an untrusted third party does it?) If the authentication mechanism is based only on key information which may in fact be shared between the SP and user then this might be hard to detect. Conversely if there was some information (CE secret identity, configuration serial number, etc) that worked in conjunction with the authentication key, then perhaps this activity could be detected. The "route legitimacy" goal is more straight-forward, I think. The authentication mechanism might provide the ability for a network element to verify that routes are in fact allowed to originate from their source PE or CE. There are variations on how this could be done. Some of the SIDR work, for example, might apply. Do these comments make sense? If it would be useful, I'll be glad to say even more words. ;) But I'd like to get some feedback and invite others to challenge or contribute to the discussion. Cheers, -Benson From l3vpn-bounces@ietf.org Mon Jun 11 12:54:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxnA9-0002ff-8e; Mon, 11 Jun 2007 12:54:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxnA7-0002fX-OD for l3vpn@ietf.org; Mon, 11 Jun 2007 12:54:39 -0400 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxnA6-0007go-AX for l3vpn@ietf.org; Mon, 11 Jun 2007 12:54:39 -0400 Received: from E03MVY1-UKDY.domain1.systemhost.net ([193.113.30.56]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 17:54:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Jun 2007 17:54:36 +0100 Message-ID: In-Reply-To: <41934.36278.qm@web314.biz.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VPN authentication/verification and WG re-chartering Thread-Index: AcenUPmvORR4PxwDTI6H3iE+sm7M1gE9xrnQ From: To: , X-OriginalArrivalTime: 11 Jun 2007 16:54:37.0393 (UTC) FILETIME=[31F2BC10:01C7AC49] X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: shane@castlepoint.net Subject: RE: VPN authentication/verification and WG re-chartering X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Rick, Rick Wilder wrote: > As was mentioned at the Prague meeting and on this email > list, Ron, Mark, and I are currently updating the charter for > the L3VPN WG. >=20 > When Ron called for work items that need to be undertaken by > the WG, Shane Amante recommended reviving the VPN > authentication/verification work that was started some time > back, but not completed. (his email copied below) >=20 > If VPN authentication/verification is of importance to you, > please weigh in before re-chartering is completed. I support VPN authentication/verification being added to the charter as it is a useful tool to ensure that the actual state stored by the routers matches what the OSS systems have configured the network to look like thereby enabling the detection of misconfigured routers. I also support the continued inclusion of VPN multicast as a high priority work item and agree with Shane that it would be useful to publish the iBGP PE-CE draft in some form. Ben --=20 Ben Niven-Jenkins Network Architect, BT =20 E-mail: benjamin.niven-jenkins@bt.com=20 Office: +44 (0)1473 648225 Mobile: +44 (0)7918 077205 Fax: +44 (0)1332 578827 From l3vpn-bounces@ietf.org Fri Jun 15 09:48: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 1HzCAC-0005Cu-TK; Fri, 15 Jun 2007 09:48:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzCAA-0005A9-NB for l3vpn@ietf.org; Fri, 15 Jun 2007 09:48:30 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzCAA-0008Kq-93 for l3vpn@ietf.org; Fri, 15 Jun 2007 09:48:30 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 15 Jun 2007 09:48:30 -0400 X-IronPort-AV: i="4.16,425,1175486400"; d="scan'208"; a="123714480:sNHT64768652" 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 l5FDmTsT012173 for ; Fri, 15 Jun 2007 09:48:29 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5FDmT5f004355 for ; Fri, 15 Jun 2007 13:48:29 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 09:48:29 -0400 Received: from [10.83.15.50] ([10.83.15.50]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 09:48:29 -0400 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: quoted-printable Message-Id: <4C33252B-3513-4C0F-9754-1DC220F77830@cisco.com> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed To: l3vpn@ietf.org From: "Thomas D. Nadeau" Date: Fri, 15 Jun 2007 09:48:28 -0400 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 15 Jun 2007 13:48:29.0401 (UTC) FILETIME=[DAF56490:01C7AF53] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7430; t=1181915309; x=1182779309; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=20=22Thomas=20D.=20Nadeau=22=20 |Subject:=20=3D?WINDOWS-1252?Q?IEEE_ComMag_Feature_Topic_on_=22Next-Gener ation_C?=3D=0A=20=3D?WINDOWS-1252?Q?arrier_Ethernet_Transport_Technologies =3D94?=3D |Sender:=20 |To:=20l3vpn@ietf.org; bh=PfocYZjhsK2e+1+hsu8ND/Sf76J4a5Gxbyw2DG6tTMo=; b=GbxLdmBTGrEINaIPsKg7KM3rJn7p6r9L2N1L6fUj6OzXpk+Xm8LL5u3HrUmorepoL5lOKAou yh7d1DivA8TNo3svPOlKOwBWshmt/AM/OmlejpnIXUGlHwiqPlWcEb2x; Authentication-Results: rtp-dkim-2; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Subject: =?windows-1252?q?IEEE_ComMag_Feature_Topic_on_=22Next-Generation?= =?windows-1252?q?_Carrier_Ethernet_Transport_Technologies=94?= X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org CALL FOR PAPERS ------------------------------ IEEE Communications Magazine Feature Topic on "Next-Generation Carrier Ethernet Transport Technologies=94 Over the last few years, the share of packet-dominated traffic has =20 grown exponentially in networks worldwide. As a result packet-based =20 transport technologies such as MPLS are increasingly deemed to be =20 more efficient for carrying this traffic compared to legacy SDH/SONET =20= technology (and its next-generation incarnations) or the more =20 familiar ATM/FR technology. A majority of this traffic is now either =20 Ethernet or Internet Protocol (IP), so enterprises (and even =20 residential customers) familiar with Ethernet technology have begun =20 demanding a simple, inexpensive and high-speed universal Ethernet =20 service. With the availability of low-cost, high-bandwidth Ethernet =20 beyond the Local Area Network, the Metro Ethernet Forum (MEF) has =20 defined such a service as Carrier Ethernet, and defined it as a =20 ubiquitous, standardized, carrier-class service/application =20 characterized by some key attributes: reliability, hard Quality-of-=20 Service (QoS), service management, and scalability. These features set it apart from the ubiquitously deployed LAN-based =20 Ethernet and serve as an add-on to switched Ethernet (GigE, and =20 10GigE variants). There are, however, several options for building =20 the underlying transport infrastructure to deliver such a carrier =20 Ethernet service. These include, for example, using: IP/MPLS =20 technology to deliver point-to-point Ethernet circuits joined =20 together with physical Ethernet bridges/switches; IP/MPLS with =20 Virtual-Private LAN Service (VPLS) or Hierarchical Virtual Private =20 LAN Service (H-VPLS) (developed at the IETF); Transport-MPLS (T-MPLS) =20= being proposed at the ITU-T, using modified Ethernet technology with =20 Provider Backbone Bridging (PBB) and Provider-Backbone Transport =20 (PBT) being proposed at the IEEE; using a combination of a modified =20 Ethernet data-plane and a GMPLS-based control-plane with VLAN cross-=20 connect (being proposed by several vendors and under consideration at =20= the IETF) and Circuit Emulation Services (CES) over an Ethernet =20 fabric to provision Pseudo Wires (PWs). The quest, therefore, is for the most feature rich, and CAPEX/OPEX =20 efficient, packet-based transport infrastructure for next-generation =20 Carrier Ethernet services. Debate and discussion is rife in the =20 industry and the academic/research communities about which technology =20= will provide the best combination of cost, ease of use, OAM features, =20= performance and service management, ability to offer Quality-of-=20 Service (QoS) guarantees, traffic engineering, and resilience, and =20 capability to manage and bill for services running atop the transport =20= infrastructure. This special issue aims to consolidate and disseminate the latest =20 developments and advances in transport technology options for Carrier =20= Ethernet service. With this objective, the list of topics includes =20 (but will not be limited to) the following: =95 Metro Ethernet and Carrier Ethernet evolutions =96 =20 requirements, services specifications, carrier drivers, customer drivers =95 Requirements on QoS, traffic engineering, resilience, =20 manageability, OAM, and service scalability for carrier Ethernet =20 transport technologies =95 IP/MPLS (VPLS, H-VPLS) for carrier Ethernet services =96 =20= choices, pros, cons, costs/benefits =95 Provider Backbone Bridging (PBB) and Provider Backbone =20 Transport-Traffic Engineered (PBT-TE) as alternatives to IP/MPLS for =20 Ethernet transport =96 pros, cons, costs/benefits =95 Transport-MPLS for carrier Ethernet =96 pros, cons, costs/=20= benefits =95 GMPLS-based control of Ethernet networks =96 changes in = the =20 data and control planes =95 Assessment of the proposed transport solutions in terms =20= of their ability to provide QoS, traffic engineering, resilience, =20 manageability, and so on. =95 OAM, network management, service management =96 options, =20= choices, pitfalls, needs, and cost analysis and comparison of solutions. =95 Solutions that meet the perceived requirements of the =20 community that are alternatives to the ones being proposed in the =20 various standards bodies. =95 Traffic engineering and dimensioning of carrier Ethernet =20= transport networks =95 Techniques to ensure QoS, especially with a mix of =20 transport technologies in use =95 Analysis and studies of resilience and protection =20 approaches utilized by different transport architectures and =20 associated technologies =95 Studies comparing the different transport technologies =20 along multiple dimensions =96 deployment cost, day-to-day running cost, =20= features provided, ease of deployment/management, and so on =95 Comparisons and case-studies from the provider community =20= to highlight why existing technologies do not meet current and =20 evolving provider requirements. =95 Commentaries from providers who feel existing techniques/=20= choices meet their requirements or can be easily modified to meet =20 their requirements. =95 Network operators, vendors, and standards bodies=92 =20 perspectives on any of the above. =95 Implementations, test-beds and field trials related to =20 carrier Ethernet transport technologies =95 State of current standards Submission Articles should be tutorial in nature and should be written in a =20 style comprehensible to readers outside the specialty of the article. =20= Articles may be edited for clarity and grammatical accuracy, and will =20= be copyedited according to the Magazine's style. Mathematical =20 equations should not be used (in justified cases up to three simple =20 equations could be allowed, provided there is consent of the Guest =20 Editor; more than three equations require permission from the Editor-=20 in-Chief). Articles should have no more than 4,500 words, no more =20 than 6 tables/figures, and no more than 15 references. Guidelines for =20= prospective authors can be found on-line at http://www.comsoc.org/=20 pubs/commag/sub_guidelines.html. Please submit no later than 31 July =20 2007. All articles to be considered for publication must be submitted =20= through IEEE Manuscript Central (http://commag-=20 ieee.manuscriptcentral.com). Please select "March 2008/Next-=20 Generation Carrier Ethernet Transport Technologies" in the drop down =20 menu. Accepted papers will also be included in Communications =20 Interactive (CI), the online version of Communications Magazine. Manuscript Due: 1 August 2007 Acceptance Notification: 1 November 2007 Final Manuscript Due: 1 December 2007 Publication Date: March 2008 Guest Editors: Thomas D. Nadeau, Cisco Systems, Inc., (tnadeau@cisco.com) Vishal Sharma, Metanoia, Inc. (v.sharma@ieee.org) Ashwin Gumaste, Indian Institute of Technology Bombay (ashwing@ieee.org) From l3vpn-bounces@ietf.org Tue Jun 19 15:03: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 1I0iyf-0008H6-7E; Tue, 19 Jun 2007 15:02:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0iye-0008Fr-Jw for l3vpn@ietf.org; Tue, 19 Jun 2007 15:02:56 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0iyb-0006m8-C9 for l3vpn@ietf.org; Tue, 19 Jun 2007 15:02:56 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpa.juniper.net with ESMTP; 19 Jun 2007 12:02:52 -0700 X-IronPort-AV: i="4.16,439,1175497200"; d="scan'208"; a="21655742:sNHT47717866" Received: from [172.23.1.54] ([172.23.1.54] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 15:02:51 -0400 Message-ID: <46782853.80100@juniper.net> Date: Tue, 19 Jun 2007 15:02:43 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l3vpn@ietf.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jun 2007 19:02:51.0622 (UTC) FILETIME=[6F5EE860:01C7B2A4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: IETF 69 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Folks, So far, the following individuals have requested agenda time at IETF 69: - the chairs - Rahul Aggarwal - Maria Napierala - Kenji Kumaki - Bruce Davie Are there any other requests? Ron