From exim@www1.ietf.org Sun Jan 4 13:28:11 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03348 for ; Sun, 4 Jan 2004 13:28:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdCyX-0003OE-84 for l3vpn-archive@odin.ietf.org; Sun, 04 Jan 2004 13:27:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i04IRj0F013024 for l3vpn-archive@odin.ietf.org; Sun, 4 Jan 2004 13:27:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdCyX-0003Nz-2t for l3vpn-web-archive@optimus.ietf.org; Sun, 04 Jan 2004 13:27:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03294 for ; Sun, 4 Jan 2004 13:27:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdCyU-00056a-00 for l3vpn-web-archive@ietf.org; Sun, 04 Jan 2004 13:27:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdCtz-0004wn-00 for l3vpn-web-archive@ietf.org; Sun, 04 Jan 2004 13:23:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdCqR-0004pW-00 for l3vpn-web-archive@ietf.org; Sun, 04 Jan 2004 13:19:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdCq4-0003Ei-MH; Sun, 04 Jan 2004 13:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdCpo-0003ET-EV for l3vpn@optimus.ietf.org; Sun, 04 Jan 2004 13:18:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03114 for ; Sun, 4 Jan 2004 13:18:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdCpc-0004o5-00 for l3vpn@ietf.org; Sun, 04 Jan 2004 13:18:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdClk-0004gA-00 for l3vpn@ietf.org; Sun, 04 Jan 2004 13:14:32 -0500 Received: from bay8-f114.bay8.hotmail.com ([64.4.27.114] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AdCgx-0004Uk-00 for l3vpn@ietf.org; Sun, 04 Jan 2004 13:09:35 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 4 Jan 2004 10:08:39 -0800 Received: from 57.250.229.136 by by8fd.bay8.hotmail.msn.com with HTTP; Sun, 04 Jan 2004 18:08:39 GMT X-Originating-IP: [57.250.229.136] X-Originating-Email: [elkou141061@hotmail.com] X-Sender: elkou141061@hotmail.com From: "M. ELK" To: l3vpn@ietf.org Subject: Enquiry about "draft-libin-hierarchy-pe-bgp-mpls-vpn-02.txt " Date: Sun, 04 Jan 2004 18:08:39 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Jan 2004 18:08:39.0529 (UTC) FILETIME=[C7A86590:01C3D2ED] Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.4 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, FROM_WEBMAIL_END_NUMS6 autolearn=no version=2.60 Hi just before posting my questions , is the above draft still alive (the latest version indicated expiry date as Nov 2003) ? Brgds _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From exim@www1.ietf.org Thu Jan 8 14:47:07 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07945 for ; Thu, 8 Jan 2004 14:47:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeg76-0002fR-DC for l3vpn-archive@odin.ietf.org; Thu, 08 Jan 2004 14:46:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08Jkeig010249 for l3vpn-archive@odin.ietf.org; Thu, 8 Jan 2004 14:46:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeg76-0002fE-9L for l3vpn-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 14:46:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07889 for ; Thu, 8 Jan 2004 14:46:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aeg73-0001zr-00 for l3vpn-web-archive@ietf.org; Thu, 08 Jan 2004 14:46:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeg5K-0001tW-00 for l3vpn-web-archive@ietf.org; Thu, 08 Jan 2004 14:44:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aeg3a-0001n4-00 for l3vpn-web-archive@ietf.org; Thu, 08 Jan 2004 14:43:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeg3Z-0002Q5-1E; Thu, 08 Jan 2004 14:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeg3B-0002Ob-ES for l3vpn@optimus.ietf.org; Thu, 08 Jan 2004 14:42:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07691 for ; Thu, 8 Jan 2004 14:42:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aeg38-0001j9-00 for l3vpn@ietf.org; Thu, 08 Jan 2004 14:42:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeg1I-0001d5-00 for l3vpn@ietf.org; Thu, 08 Jan 2004 14:40:40 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1Aefzr-0001WE-00 for l3vpn@ietf.org; Thu, 08 Jan 2004 14:39:11 -0500 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i08JcaLE013859; Thu, 8 Jan 2004 14:38:37 -0500 (EST) Message-Id: <200401081938.i08JcaLE013859@rtp-core-1.cisco.com> To: "Vishal Sharma" cc: "L3PPVPN" Subject: Re: Clarification on the L3 framework draft In-reply-to: Your message of Tue, 30 Dec 2003 17:15:55 -0800. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 08 Jan 2004 14:38:36 -0500 From: Eric Rosen Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Vishal> On pp. 54, Sec. 4.4.4, the document states that using Vishal> BGP's route reflectors, PE-PE adjacencies can be completely Vishal> eliminated, and furthermore that the no. of backbone adjacencies Vishal> can be made a small constant _independent_ of the number of Vishal> PEs involved. I think the paragraph you're looking at is: This approach greatly reduces the number of routing adjacencies which the PEs must maintain, since there is no longer any need to maintain more than one such adjacency between a given pair of PEs. If the single routing protocol supports a hierarchical route distribution mechanism (such as BGP's "route reflectors"), the PE-PE adjacencies can be completely eliminated, and the number of backbone adjacencies can be made into a small constant which is independent of the number of PE devices. This improves the scaling properties. The term "the number of backbone adjacencies" is intended to mean "the number of adjacencies which a given PE must maintain over the backbone". From exim@www1.ietf.org Thu Jan 8 14:49:06 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08020 for ; Thu, 8 Jan 2004 14:49:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeg91-0002o0-8L for l3vpn-archive@odin.ietf.org; Thu, 08 Jan 2004 14:48:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08JmdeF010778 for l3vpn-archive@odin.ietf.org; Thu, 8 Jan 2004 14:48:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeg91-0002nl-4H for l3vpn-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 14:48:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07993 for ; Thu, 8 Jan 2004 14:48:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aeg8y-00026M-00 for l3vpn-web-archive@ietf.org; Thu, 08 Jan 2004 14:48:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeg79-000212-00 for l3vpn-web-archive@ietf.org; Thu, 08 Jan 2004 14:46:43 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aeg5W-0001uy-00 for l3vpn-web-archive@ietf.org; Thu, 08 Jan 2004 14:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeg5X-0002Zp-3m; Thu, 08 Jan 2004 14:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeg5L-0002YH-Qd for l3vpn@optimus.ietf.org; Thu, 08 Jan 2004 14:44:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07795 for ; Thu, 8 Jan 2004 14:44:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aeg5J-0001tE-00 for l3vpn@ietf.org; Thu, 08 Jan 2004 14:44:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeg3R-0001mV-00 for l3vpn@ietf.org; Thu, 08 Jan 2004 14:42:53 -0500 Received: from smtp102.mail.sc5.yahoo.com ([216.136.174.140]) by ietf-mx with smtp (Exim 4.12) id 1Aeg2q-0001gG-00 for l3vpn@ietf.org; Thu, 08 Jan 2004 14:42:16 -0500 Received: from unknown (HELO RAKHILAPTOP) (vsharma87@67.117.148.217 with login) by smtp102.mail.sc5.yahoo.com with SMTP; 8 Jan 2004 19:42:14 -0000 From: "Vishal Sharma" To: Cc: "L3PPVPN" Subject: RE: Clarification on the L3 framework draft Date: Thu, 8 Jan 2004 11:41:49 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <200401081938.i08JcaLE013859@rtp-core-1.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric, Great, thanks very much. This answers my question! -Vishal > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Thursday, January 08, 2004 11:39 AM > To: Vishal Sharma > Cc: L3PPVPN > Subject: Re: Clarification on the L3 framework draft > > > > Vishal> On pp. 54, Sec. 4.4.4, the document states that using > Vishal> BGP's route reflectors, PE-PE adjacencies can be completely > Vishal> eliminated, and furthermore that the no. of backbone adjacencies > Vishal> can be made a small constant _independent_ of the number of > Vishal> PEs involved. > > > I think the paragraph you're looking at is: > > This approach greatly reduces the number of routing adjacencies which > the PEs must maintain, since there is no longer any need to maintain > more than one such adjacency between a given pair of PEs. If the > single routing protocol supports a hierarchical route distribution > mechanism (such as BGP's "route reflectors"), the PE-PE adjacencies > can be completely eliminated, and the number of backbone adjacencies > can be made into a small constant which is independent of the number > of PE devices. This improves the scaling properties. > > The term "the number of backbone adjacencies" is intended to > mean "the > number of adjacencies which a given PE must maintain over the backbone". From exim@www1.ietf.org Fri Jan 9 15:38:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12907 for ; Fri, 9 Jan 2004 15:38:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3OU-0005rj-33 for l3vpn-archive@odin.ietf.org; Fri, 09 Jan 2004 15:38:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i09Kc9i7022531 for l3vpn-archive@odin.ietf.org; Fri, 9 Jan 2004 15:38:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3OT-0005rK-6G for l3vpn-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 15:38:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12844 for ; Fri, 9 Jan 2004 15:38:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af3OR-0003Jn-00 for l3vpn-web-archive@ietf.org; Fri, 09 Jan 2004 15:38:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af3Ko-0002Ke-00 for l3vpn-web-archive@ietf.org; Fri, 09 Jan 2004 15:34:24 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Af3Em-0000vv-00 for l3vpn-web-archive@ietf.org; Fri, 09 Jan 2004 15:28:09 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Af3Eo-0003o5-6p for l3vpn-web-archive@ietf.org; Fri, 09 Jan 2004 15:28:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3Ef-0004te-N6; Fri, 09 Jan 2004 15:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3EQ-0004t5-Dj for l3vpn@optimus.ietf.org; Fri, 09 Jan 2004 15:27:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09894 for ; Fri, 9 Jan 2004 15:27:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af3EO-0000q6-00 for l3vpn@ietf.org; Fri, 09 Jan 2004 15:27:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af2pU-0005PM-00 for l3vpn@ietf.org; Fri, 09 Jan 2004 15:02:01 -0500 Received: from web60709.mail.yahoo.com ([216.109.117.232]) by ietf-mx with smtp (Exim 4.12) id 1Af2O8-0004VD-00 for l3vpn@ietf.org; Fri, 09 Jan 2004 14:33:44 -0500 Message-ID: <20040109193312.78707.qmail@web60709.mail.yahoo.com> Received: from [64.221.212.137] by web60709.mail.yahoo.com via HTTP; Fri, 09 Jan 2004 11:33:11 PST Date: Fri, 9 Jan 2004 11:33:11 -0800 (PST) From: Jim T Subject: Question regarding InterAS and Carriers' Carrier VPNs To: l3vpn@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1333595018-1073676791=:78213" Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 --0-1333595018-1073676791=:78213 Content-Type: text/plain; charset=us-ascii In section 10(b) of rfc2547bis, it is stated that when the ASBR receives a labeled packet from the adjacent ASBR, it has to ensure that the top label in the labeled packet was one that it distributed to the adjacent ASBR. I am not clear how this is enforced. Would the ASBR have a per-interface label-forwarding entry or would it have a label-forwarding entry per adjacent ASBR? If so, if the ASBR distributes a particular VPN-IPv4 route to many other ASBRs, it would have to create many label-forwarding entries, correct? Is this how vendors do it? The same question applies to section 9 too. I don't know if this is an implementation issue but it would help me if someone can shed some light upon it. Thanks, Jim --------------------------------- Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes --0-1333595018-1073676791=:78213 Content-Type: text/html; charset=us-ascii
In section 10(b) of rfc2547bis, it is stated that when the ASBR receives a labeled packet from the adjacent ASBR, it has to ensure that the top label in the labeled packet was one that it distributed to the adjacent ASBR. I am not clear how this is enforced. Would the ASBR have a per-interface label-forwarding entry or would it have a label-forwarding entry per adjacent ASBR? If so, if the ASBR distributes a particular VPN-IPv4 route to many other ASBRs, it would have to create many label-forwarding entries, correct? Is this how vendors do it?
 
The same question applies to section 9 too. I don't know if this is an implementation issue but it would help me if someone can shed some light upon it.
 
Thanks,
Jim
 

Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes --0-1333595018-1073676791=:78213-- From exim@www1.ietf.org Mon Jan 12 02:53:46 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16998 for ; Mon, 12 Jan 2004 02:53:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Afwsw-00080i-DG for l3vpn-archive@odin.ietf.org; Mon, 12 Jan 2004 02:53:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0C7rIDf030793 for l3vpn-archive@odin.ietf.org; Mon, 12 Jan 2004 02:53:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Afwsv-00080a-UJ for l3vpn-web-archive@optimus.ietf.org; Mon, 12 Jan 2004 02:53:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16994 for ; Mon, 12 Jan 2004 02:53:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Afwss-0004PB-00 for l3vpn-web-archive@ietf.org; Mon, 12 Jan 2004 02:53:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AfwsC-0004K3-00 for l3vpn-web-archive@ietf.org; Mon, 12 Jan 2004 02:52:33 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Afwq8-0004DZ-00 for l3vpn-web-archive@ietf.org; Mon, 12 Jan 2004 02:50:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Afwpl-0007ph-7e; Mon, 12 Jan 2004 02:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfwpE-0007oz-Cj for l3vpn@optimus.ietf.org; Mon, 12 Jan 2004 02:49:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16858 for ; Mon, 12 Jan 2004 02:49:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Afwp0-0004AI-00 for l3vpn@ietf.org; Mon, 12 Jan 2004 02:49:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AfwkI-00042z-00 for l3vpn@ietf.org; Mon, 12 Jan 2004 02:44:22 -0500 Received: from [203.197.140.35] (helo=fsnt.future.futsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Afwh3-0003vg-00 for l3vpn@ietf.org; Mon, 12 Jan 2004 02:41:02 -0500 Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by fsnt.future.futsoft.com (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Mon, 12 Jan 2004 13:16:01 +0530 Received: from sakthivss (sakthivss.future.futsoft.com [10.6.4.130]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id i0C7abU02857; Mon , 12 Jan 2004 13:06:38 +0530 Reply-To: From: "Sakthivadivu.S.S" To: , Subject: RE: Route Reflector In VPN Date: Mon, 12 Jan 2004 13:09:51 +0530 Message-ID: <000001c3d8df$43f8eec0$8204060a@future.futsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <37642.61.16.170.200.1073577182.squirrel@mail.apara.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,EXCUSE_16 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Carrying Label RFC says in Capability Advrtisement Paragraph that Carrying Label capability should be advertised only if there is an LSP between the peers. Do we need to follow this for VPNv4 capability also?. If it so, then i have problem in Route Reflector case. If Route Reflector is not in forwarding path, then this will not work sincee the Vpn4 connection should be established between PE and RR. Can you pls clarify my doubt?. Regards, sakthi -----Original Message----- From: Alok Dube [mailto:alok.dube@apara.com] Sent: Thursday, 8 January 2004 9:23 PM To: sakthivss@future.futsoft.com Subject: Re: Route Reflector In VPN dont know where you are coming from, but an RR should put Label mappings and not routes/prefixes in the forwarding table. else there may not be any purpose to use an RR...if one needs to do an L3 lookup there that is... > > Hi, > > When the route reflector receives route the VPN-Ipv4 routes from PE > peers, > will it install the routes in IP forwarding table ?. > > > If CE is associated with Route Reflector (VRF_A), the routes only > belongs to the VPN corresponding to CE > will be installed in this VRF_A. Will RR install other routes which > it > reflects in default forwarding table. > > Can you please clarify my doubt > > Regards, > Sakthi > > > > > > > > > > *************************************************************************** > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, > you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > *************************************************************************** *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From exim@www1.ietf.org Fri Jan 16 18:24:06 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04552 for ; Fri, 16 Jan 2004 18:24:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhdJU-0002EG-7Z for l3vpn-archive@odin.ietf.org; Fri, 16 Jan 2004 18:23:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GNNeVC008562 for l3vpn-archive@odin.ietf.org; Fri, 16 Jan 2004 18:23:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhdJU-0002E1-2r for l3vpn-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 18:23:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04496 for ; Fri, 16 Jan 2004 18:23:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhdJR-0003h1-00 for l3vpn-web-archive@ietf.org; Fri, 16 Jan 2004 18:23:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhdHA-0003Zl-00 for l3vpn-web-archive@ietf.org; Fri, 16 Jan 2004 18:21:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhdEN-0003Se-00 for l3vpn-web-archive@ietf.org; Fri, 16 Jan 2004 18:18:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhdE0-00013r-Gw; Fri, 16 Jan 2004 18:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhdDM-0000uo-0u for l3vpn@optimus.ietf.org; Fri, 16 Jan 2004 18:17:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04185 for ; Fri, 16 Jan 2004 18:17:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhdDE-0003PC-00 for l3vpn@ietf.org; Fri, 16 Jan 2004 18:17:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ahd9v-0003Ht-00 for l3vpn@ietf.org; Fri, 16 Jan 2004 18:13:47 -0500 Received: from web60703.mail.yahoo.com ([216.109.117.226]) by ietf-mx with smtp (Exim 4.12) id 1Ahd8B-000395-00 for l3vpn@ietf.org; Fri, 16 Jan 2004 18:11:59 -0500 Message-ID: <20040116231100.31280.qmail@web60703.mail.yahoo.com> Received: from [64.221.212.137] by web60703.mail.yahoo.com via HTTP; Fri, 16 Jan 2004 15:11:00 PST Date: Fri, 16 Jan 2004 15:11:00 -0800 (PST) From: Jim T Subject: Fwd: Question regarding InterAS and Carriers' Carrier VPNs To: l3vpn@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1603124337-1074294660=:30545" Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 --0-1603124337-1074294660=:30545 Content-Type: text/plain; charset=us-ascii I did a test regarding the point mentioned below on a Juniper Networks' router. I found that it accepted a labeled packet from a device to which it had not distributed the label. The ASBR forwarded the packet to the PE router in its AS (or to the neighboring ASBR) after label swapping. The result was that a packet (echo request) from an unintended source reached the destination in a VRF though the response was dropped by the PE router. The draft seems to state that this should not be done. Is this just a recommendation that is left to the implementation or is it something that ought to be supported by a router implementing section 9 and 10 of the draft? Comments appreciated. Thanks, Jim Jim T wrote: Date: Fri, 9 Jan 2004 11:33:11 -0800 (PST) From: Jim T Subject: Question regarding InterAS and Carriers' Carrier VPNs To: l3vpn@ietf.org In section 10(b) of rfc2547bis, it is stated that when the ASBR receives a labeled packet from the adjacent ASBR, it has to ensure that the top label in the labeled packet was one that it distributed to the adjacent ASBR. I am not clear how this is enforced. Would the ASBR have a per-interface label-forwarding entry or would it have a label-forwarding entry per adjacent ASBR? If so, if the ASBR distributes a particular VPN-IPv4 route to many other ASBRs, it would have to create many label-forwarding entries, correct? Is this how vendors do it? The same question applies to section 9 too. I don't know if this is an implementation issue but it would help me if someone can shed some light upon it. Thanks, Jim --------------------------------- Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes --------------------------------- Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes --0-1603124337-1074294660=:30545 Content-Type: text/html; charset=us-ascii
I did a test regarding the point mentioned below on a Juniper Networks' router. I found that it accepted a labeled packet from a device to which it had not distributed the label. The ASBR forwarded the packet to the PE router in its AS (or to the neighboring ASBR) after label swapping. The result was that a packet (echo request) from an unintended source reached the destination in a VRF though the response was dropped by the PE router.
 
The draft seems to state that this should not be done. Is this just a recommendation that is left to the implementation or is it something that ought to be supported by a router implementing section 9 and 10 of the draft? Comments appreciated.
 
Thanks,
Jim

Jim T <jim_technical@yahoo.com> wrote:
Date: Fri, 9 Jan 2004 11:33:11 -0800 (PST)
From: Jim T
Subject: Question regarding InterAS and Carriers' Carrier VPNs
To: l3vpn@ietf.org

In section 10(b) of rfc2547bis, it is stated that when the ASBR receives a labeled packet from the adjacent ASBR, it has to ensure that the top label in the labeled packet was one that it distributed to the adjacent ASBR. I am not clear how this is enforced. Would the ASBR have a per-interface label-forwarding entry or would it have a label-forwarding entry per adjacent ASBR? If so, if the ASBR distributes a particular VPN-IPv4 route to many other ASBRs, it would have to create many label-forwarding entries, correct? Is this how vendors do it?
 
The same question applies to section 9 too. I don't know if this is an implementation issue but it would help me if someone can shed some light upon it.
 
Thanks,
Jim
 

Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes

Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes --0-1603124337-1074294660=:30545-- From exim@www1.ietf.org Fri Jan 16 22:53:14 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11923 for ; Fri, 16 Jan 2004 22:53:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhhVv-0000NY-TQ for l3vpn-archive@odin.ietf.org; Fri, 16 Jan 2004 22:52:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0H3qlNJ001450 for l3vpn-archive@odin.ietf.org; Fri, 16 Jan 2004 22:52:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhhVv-0000NJ-NK for l3vpn-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 22:52:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11913 for ; Fri, 16 Jan 2004 22:52:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhhVn-00018O-00 for l3vpn-web-archive@ietf.org; Fri, 16 Jan 2004 22:52:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhhTt-00014r-00 for l3vpn-web-archive@ietf.org; Fri, 16 Jan 2004 22:50:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhhTH-0000zd-00 for l3vpn-web-archive@ietf.org; Fri, 16 Jan 2004 22:50:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhhTH-0000CJ-Cn; Fri, 16 Jan 2004 22:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhhT9-0000As-MR for l3vpn@optimus.ietf.org; Fri, 16 Jan 2004 22:49:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11869 for ; Fri, 16 Jan 2004 22:49:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhhT6-0000yN-00 for l3vpn@ietf.org; Fri, 16 Jan 2004 22:49:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhhRy-0000mA-00 for l3vpn@ietf.org; Fri, 16 Jan 2004 22:48:43 -0500 Received: from ns.ft.solteria.net ([210.142.173.164]) by ietf-mx with esmtp (Exim 4.12) id 1AhhQZ-0000RW-00 for l3vpn@ietf.org; Fri, 16 Jan 2004 22:47:15 -0500 Received: from Satoru_T40p.ft.solteria.net (localhost [127.0.0.1]) by ns.ft.solteria.net (Postfix) with ESMTP id E0F2938712; Sat, 17 Jan 2004 12:46:43 +0900 (JST) Message-Id: <5.1.1.9.2.20040117123802.05f31bc8@localhost> X-Sender: satoru@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr4 Date: Sat, 17 Jan 2004 12:46:43 +0900 To: Jim T , l3vpn@ietf.org From: "S.Matsushima" Subject: Re: Fwd: Question regarding InterAS and Carriers' Carrier VPNs In-Reply-To: <20040116231100.31280.qmail@web60703.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit At 15:11 04/01/16 -0800, Jim T wrote: >I did a test regarding the point mentioned below on a Juniper Networks' >router. I found that it accepted a labeled packet from a device to which >it had not distributed the label. The ASBR forwarded the packet to the PE >router in its AS (or to the neighboring ASBR) after label swapping. The >result was that a packet (echo request) from an unintended source reached >the destination in a VRF though the response was dropped by the PE router. > >The draft seems to state that this should not be done. Is this just a >recommendation that is left to the implementation or is it something that >ought to be supported by a router implementing section 9 and 10 of the >draft? Comments appreciated. Carriers' Carrier SP must have that feature (I call it "label spoofing avoid" personally.) There are some vendors which already have it. -- Satoru Matsushima From exim@www1.ietf.org Tue Jan 20 02:03:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07829 for ; Tue, 20 Jan 2004 02:03:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aipuk-0000EY-Iw for l3vpn-archive@odin.ietf.org; Tue, 20 Jan 2004 02:03:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0K736wW000894 for l3vpn-archive@odin.ietf.org; Tue, 20 Jan 2004 02:03:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aipuj-0000EE-SU for l3vpn-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 02:03:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07226 for ; Tue, 20 Jan 2004 02:03:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aipug-0002y8-00 for l3vpn-web-archive@ietf.org; Tue, 20 Jan 2004 02:03:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aipth-0002vq-00 for l3vpn-web-archive@ietf.org; Tue, 20 Jan 2004 02:02:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aipsl-0002uE-00 for l3vpn-web-archive@ietf.org; Tue, 20 Jan 2004 02:01:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aipsk-0007xO-AQ; Tue, 20 Jan 2004 02:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiprr-0007ja-4t for l3vpn@optimus.ietf.org; Tue, 20 Jan 2004 02:00:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03681 for ; Tue, 20 Jan 2004 02:00:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aiprn-0002r5-00 for l3vpn@ietf.org; Tue, 20 Jan 2004 02:00:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aipqq-0002pH-00 for l3vpn@ietf.org; Tue, 20 Jan 2004 01:59:05 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1Aipq0-0002mA-00 for l3vpn@ietf.org; Tue, 20 Jan 2004 01:58:12 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i0K6vh1K040611; Mon, 19 Jan 2004 22:57:43 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i0K6vhlW040608; Mon, 19 Jan 2004 22:57:43 -0800 (PST) Date: Mon, 19 Jan 2004 22:57:43 -0800 (PST) Message-Id: <200401200657.i0K6vhlW040608@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jim T Cc: l3vpn@ietf.org Subject: Fwd: Question regarding InterAS and Carriers' Carrier VPNs In-Reply-To: <20040116231100.31280.qmail@web60703.mail.yahoo.com> References: <20040116231100.31280.qmail@web60703.mail.yahoo.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jim T writes: > The draft seems to state > that this should not be done. Is this just a recommendation that is > left to the implementation or is it something that ought to be > supported by a router implementing section 9 and 10 of the draft? > Comments appreciated. In the context of carrier-of-carriers the implementation you refer to can be configured such that labels are specific to a particular carrier VPN... that is the behaviour you will get w/ the recomended CoC config, AFAIK. But that is probably a discussion for another mailing list. Pedro. From exim@www1.ietf.org Tue Jan 20 15:47:23 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21182 for ; Tue, 20 Jan 2004 15:47:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj2ly-0000MT-Jv for l3vpn-archive@odin.ietf.org; Tue, 20 Jan 2004 15:46:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KKksEU001383 for l3vpn-archive@odin.ietf.org; Tue, 20 Jan 2004 15:46:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj2ly-0000ME-GP for l3vpn-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 15:46:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21138 for ; Tue, 20 Jan 2004 15:46:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj2lx-0000hv-00 for l3vpn-web-archive@ietf.org; Tue, 20 Jan 2004 15:46:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj2kz-0000cN-00 for l3vpn-web-archive@ietf.org; Tue, 20 Jan 2004 15:45:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aj2kL-0000X8-00 for l3vpn-web-archive@ietf.org; Tue, 20 Jan 2004 15:45:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj2kD-0008DB-Pb; Tue, 20 Jan 2004 15:45:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj2jj-00087f-8E for l3vpn@optimus.ietf.org; Tue, 20 Jan 2004 15:44:35 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20695; Tue, 20 Jan 2004 15:44:32 -0500 (EST) Message-Id: <200401202044.PAA20695@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: l3vpn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-mgt-fwk-01.txt Date: Tue, 20 Jan 2004 15:44:32 -0500 Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. Title : Framework for PPVPN Operations and Management Author(s) : Y. Mghazli Filename : draft-ietf-l3vpn-mgt-fwk-01.txt Pages : 25 Date : 2004-1-20 This document provides a framework for Provider Provisioned Virtual Private Networks (PPVPNs) operation and management. This framework intends to produce a coherent description of the significant technical issues which are important in the design of PPVPN management solution. Selection of specific approaches, making choices among information models and protocols are outside of the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-mgt-fwk-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l3vpn-mgt-fwk-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l3vpn-mgt-fwk-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-20142808.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-mgt-fwk-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-mgt-fwk-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-20142808.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Tue Jan 20 17:21:09 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28421 for ; Tue, 20 Jan 2004 17:21:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj4Ek-0006P1-LO for l3vpn-archive@odin.ietf.org; Tue, 20 Jan 2004 17:20:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KMKg6d024605 for l3vpn-archive@odin.ietf.org; Tue, 20 Jan 2004 17:20:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj4Ek-0006Om-Gg for l3vpn-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 17:20:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28396 for ; Tue, 20 Jan 2004 17:20:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj4Ei-0001qE-00 for l3vpn-web-archive@ietf.org; Tue, 20 Jan 2004 17:20:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj4Dm-0001n7-00 for l3vpn-web-archive@ietf.org; Tue, 20 Jan 2004 17:19:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aj4DA-0001k7-00 for l3vpn-web-archive@ietf.org; Tue, 20 Jan 2004 17:19:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj4D7-00067p-Mw; Tue, 20 Jan 2004 17:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj4D3-00066k-Jl for l3vpn@optimus.ietf.org; Tue, 20 Jan 2004 17:18:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28268 for ; Tue, 20 Jan 2004 17:18:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj4D1-0001jZ-00 for l3vpn@ietf.org; Tue, 20 Jan 2004 17:18:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj4CT-0001eq-00 for l3vpn@ietf.org; Tue, 20 Jan 2004 17:18:21 -0500 Received: from web109.biz.mail.yahoo.com ([216.136.174.219]) by ietf-mx with smtp (Exim 4.12) id 1Aj4BM-0001Wo-00 for l3vpn@ietf.org; Tue, 20 Jan 2004 17:17:12 -0500 Message-ID: <20040120215626.64812.qmail@web109.biz.mail.yahoo.com> Received: from [128.251.97.179] by web109.biz.mail.yahoo.com via HTTP; Tue, 20 Jan 2004 13:56:26 PST Date: Tue, 20 Jan 2004 13:56:26 -0800 (PST) From: Rick Wilder Subject: last call on terminology draft To: l3vpn@ietf.org Cc: l2vpn@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This begins a 2-week last-call period for . Please let the list hear any remaining comments on this document. Rick From exim@www1.ietf.org Wed Jan 21 11:04:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27425 for ; Wed, 21 Jan 2004 11:04:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKpt-0000qb-NK for l3vpn-archive@odin.ietf.org; Wed, 21 Jan 2004 11:04:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LG49ok003251 for l3vpn-archive@odin.ietf.org; Wed, 21 Jan 2004 11:04:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKpt-0000qM-HJ for l3vpn-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 11:04:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27402 for ; Wed, 21 Jan 2004 11:04:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjKpr-0004tO-00 for l3vpn-web-archive@ietf.org; Wed, 21 Jan 2004 11:04:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjKot-0004qd-00 for l3vpn-web-archive@ietf.org; Wed, 21 Jan 2004 11:03:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjKnv-0004o6-00 for l3vpn-web-archive@ietf.org; Wed, 21 Jan 2004 11:02:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKnp-0000cW-Od; Wed, 21 Jan 2004 11:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKn1-0000ba-BP for l3vpn@optimus.ietf.org; Wed, 21 Jan 2004 11:01:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27287 for ; Wed, 21 Jan 2004 11:01:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjKmy-0004lQ-00 for l3vpn@ietf.org; Wed, 21 Jan 2004 11:01:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjKm1-0004j2-00 for l3vpn@ietf.org; Wed, 21 Jan 2004 11:00:09 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1AjKl8-0004gH-00 for l3vpn@ietf.org; Wed, 21 Jan 2004 10:59:14 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i0LFwgl72561; Wed, 21 Jan 2004 07:58:42 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt.juniper.net (rcallon-lt.jnpr.net [10.10.132.99] (may be forged)) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i0LFwZh85400; Wed, 21 Jan 2004 07:58:35 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20040121105025.02ea11d8@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 21 Jan 2004 10:58:28 -0500 To: l3vpn@ietf.org From: Ross Callon Subject: Call for Agenda Items for Seoul IETF Cc: ronald.p.bonica@mci.com, rick@rhwilder.net, rcallon@juniper.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 This is a call for agenda items for Seoul. If you want to present, please send email to all three chairs with: a) author / proposed speaker b) draft name (title and identifier) c) time required Please get your drafts in by the cut-off date. Priority will be given to working group drafts which get in by the cut-off date (personally I always try to get things in a day early -- since the secretariat gets a large number of last minute drafts). There is a good chance that we may have time for other drafts. Thanks, Ross (and Rick and Ron) From exim@www1.ietf.org Wed Jan 21 16:00:50 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08301 for ; Wed, 21 Jan 2004 16:00:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPSX-0003fP-PF for l3vpn-archive@odin.ietf.org; Wed, 21 Jan 2004 16:00:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LL0LcI014089 for l3vpn-archive@odin.ietf.org; Wed, 21 Jan 2004 16:00:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPSX-0003fA-K1 for l3vpn-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 16:00:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08271 for ; Wed, 21 Jan 2004 16:00:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjPSW-0001OC-00 for l3vpn-web-archive@ietf.org; Wed, 21 Jan 2004 16:00:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjPRc-0001Mb-00 for l3vpn-web-archive@ietf.org; Wed, 21 Jan 2004 15:59:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjPRJ-0001KQ-00 for l3vpn-web-archive@ietf.org; Wed, 21 Jan 2004 15:59:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPRF-0003SU-DN; Wed, 21 Jan 2004 15:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPQe-0003KE-1M for l3vpn@optimus.ietf.org; Wed, 21 Jan 2004 15:58:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08208 for ; Wed, 21 Jan 2004 15:58:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjPQc-0001J5-00 for l3vpn@ietf.org; Wed, 21 Jan 2004 15:58:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjPPj-0001H5-00 for l3vpn@ietf.org; Wed, 21 Jan 2004 15:57:28 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1AjPPS-0001EA-00 for l3vpn@ietf.org; Wed, 21 Jan 2004 15:57:10 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i0LKueBm038514; Wed, 21 Jan 2004 12:56:40 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt.juniper.net (rcallon-lt.jnpr.net [10.10.132.99]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i0LKueh17139; Wed, 21 Jan 2004 12:56:40 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20040121153926.030be0a0@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 21 Jan 2004 15:53:02 -0500 To: l3vpn@ietf.org From: Ross Callon Subject: draft-touch-ipsec-vpn-06.txt Cc: Thomas Narten Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 We have been notified that the IESG is considering publication of an individual contribution entitled: Use of IPsec Transport Mode for Dynamic Routing draft-touch-ipsec-vpn-06.txt http://www.ietf.org/internet-drafts/draft-touch-ipsec-vpn-06.txt This document is related to use of IPsec for support of VPNs. From the abstract of the document, it states in part: This document addresses the use of IPsec to secure the links of a virtual (private) network (VN/VPN)... Given that the document overlaps with our work, the issue has come up regarding whether the document should be published without any working group consideration, or whether the author should be requested to bring the work to the l3vpn working group for consideration. This leads to two questions: - Does the l3vpn working group feel that this document should be reviewed by a public working group, such as the l3vpn working group, prior to publication? - Do we have any technical comments on the document? Comments to the list, please. Thanks, Ross From exim@www1.ietf.org Wed Jan 21 16:33:56 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10133 for ; Wed, 21 Jan 2004 16:33:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPya-0006Fe-NS for l3vpn-archive@odin.ietf.org; Wed, 21 Jan 2004 16:33:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LLXSS6024024 for l3vpn-archive@odin.ietf.org; Wed, 21 Jan 2004 16:33:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPya-0006FP-J1 for l3vpn-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 16:33:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10106 for ; Wed, 21 Jan 2004 16:33:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjPyY-0002f3-00 for l3vpn-web-archive@ietf.org; Wed, 21 Jan 2004 16:33:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjPxa-0002dN-00 for l3vpn-web-archive@ietf.org; Wed, 21 Jan 2004 16:32:26 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjPxA-0002b9-00 for l3vpn-web-archive@ietf.org; Wed, 21 Jan 2004 16:32:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPxA-00068X-6p; Wed, 21 Jan 2004 16:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPwX-00067q-6E for l3vpn@optimus.ietf.org; Wed, 21 Jan 2004 16:31:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09951 for ; Wed, 21 Jan 2004 16:31:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjPwV-0002a1-00 for l3vpn@ietf.org; Wed, 21 Jan 2004 16:31:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjPvf-0002YG-00 for l3vpn@ietf.org; Wed, 21 Jan 2004 16:30:28 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1AjPuw-0002W1-00 for l3vpn@ietf.org; Wed, 21 Jan 2004 16:29:42 -0500 Received: from isi.edu (host253.tollo.net [206.117.6.253]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i0LLTfD11430; Wed, 21 Jan 2004 13:29:41 -0800 (PST) Message-ID: <400EEF38.7000302@isi.edu> Date: Wed, 21 Jan 2004 13:29:28 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ross Callon CC: l3vpn@ietf.org, Thomas Narten Subject: Re: draft-touch-ipsec-vpn-06.txt References: <4.3.2.20040121153926.030be0a0@zircon.juniper.net> In-Reply-To: <4.3.2.20040121153926.030be0a0@zircon.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ross Callon wrote: > We have been notified that the IESG is considering publication > of an individual contribution entitled: > Use of IPsec Transport Mode for Dynamic Routing > draft-touch-ipsec-vpn-06.txt > http://www.ietf.org/internet-drafts/draft-touch-ipsec-vpn-06.txt > > This document is related to use of IPsec for support of VPNs. From > the abstract of the document, it states in part: > > This document addresses the use of IPsec to secure the links > of a virtual (private) network (VN/VPN)... > > Given that the document overlaps with our work, the issue has come > up regarding whether the document should be published without any > working group consideration, This document has been in development since 2000, and has been brought several times (with presentations) to both the IPsec and PPVPN WGs for comment and feedback, which has already been incorporated. Please check the list archives (notably ppvpn, since versions were posted there in 2002). > or whether the author should be requested > to bring the work to the l3vpn working group for consideration. > > This leads to two questions: > > - Does the l3vpn working group feel that this document should be > reviewed by a public working group, such as the l3vpn working group, > prior to publication? It has been, multiple times. Please review the archives for comments that have already been made on the precursor to this list. Joe > - Do we have any technical comments on the document? > > Comments to the list, please. > > Thanks, Ross > From exim@www1.ietf.org Wed Jan 21 18:28:55 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17642 for ; Wed, 21 Jan 2004 18:28:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjRls-0000KJ-WC for l3vpn-archive@odin.ietf.org; Wed, 21 Jan 2004 18:28:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LNSS78001249 for l3vpn-archive@odin.ietf.org; Wed, 21 Jan 2004 18:28:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjRls-0000K4-Qj for l3vpn-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 18:28:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17625 for ; Wed, 21 Jan 2004 18:28:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjRlp-0002cl-00 for l3vpn-web-archive@ietf.org; Wed, 21 Jan 2004 18:28:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjRks-0002aj-00 for l3vpn-web-archive@ietf.org; Wed, 21 Jan 2004 18:27:27 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjRkT-0002Yn-00 for l3vpn-web-archive@ietf.org; Wed, 21 Jan 2004 18:27:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjRkT-0008Ja-60; Wed, 21 Jan 2004 18:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjRjs-0008B0-EQ for l3vpn@optimus.ietf.org; Wed, 21 Jan 2004 18:26:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17452 for ; Wed, 21 Jan 2004 18:26:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjRjp-0002Xw-00 for l3vpn@ietf.org; Wed, 21 Jan 2004 18:26:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjRit-0002Wl-00 for l3vpn@ietf.org; Wed, 21 Jan 2004 18:25:24 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AjRiP-0002Uj-00 for l3vpn@ietf.org; Wed, 21 Jan 2004 18:24:54 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0LNOM111066 for ; Wed, 21 Jan 2004 18:24:23 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Jan 2004 18:24:23 -0500 Message-ID: From: "Hamid Ould-Brahim" To: Joe Touch , Ross Callon Cc: l3vpn@ietf.org, Thomas Narten Subject: RE: draft-touch-ipsec-vpn-06.txt Date: Wed, 21 Jan 2004 18:24:21 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Speaking of ppvpn archive, I think a web link should be added to l3vpn and l2vpn wg web pages or the previous ppvpn archive should be moved to the new archives. Here is the link of previous ppvpn archive: http://ppvpn.francetelecom.com/ Hamid. > > > > > Ross Callon wrote: > > > We have been notified that the IESG is considering publication > > of an individual contribution entitled: > > Use of IPsec Transport Mode for Dynamic Routing > > draft-touch-ipsec-vpn-06.txt > > http://www.ietf.org/internet-drafts/draft-touch-ipsec-vpn-06.txt > > > > This document is related to use of IPsec for support of VPNs. From > > the abstract of the document, it states in part: > > > > This document addresses the use of IPsec to secure the links > > of a virtual (private) network (VN/VPN)... > > > > Given that the document overlaps with our work, the issue > has come up > > regarding whether the document should be published without > any working > > group consideration, > > This document has been in development since 2000, and has > been brought > several times (with presentations) to both the IPsec and > PPVPN WGs for > comment and feedback, which has already been incorporated. > Please check > the list archives (notably ppvpn, since versions were posted > there in 2002). > > > or whether the author should be requested > > to bring the work to the l3vpn working group for consideration. > > > > This leads to two questions: > > > > - Does the l3vpn working group feel that this document should be > > reviewed by a public working group, such as the l3vpn > working group, > > prior to publication? > > It has been, multiple times. Please review the archives for comments > that have already been made on the precursor to this list. > > Joe > > > - Do we have any technical comments on the document? > > > > Comments to the list, please. > > > > Thanks, Ross > > > > From exim@www1.ietf.org Wed Jan 21 19:37:53 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19504 for ; Wed, 21 Jan 2004 19:37:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjSqb-0004TM-VA for l3vpn-archive@odin.ietf.org; Wed, 21 Jan 2004 19:37:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0M0bPd3017178 for l3vpn-archive@odin.ietf.org; Wed, 21 Jan 2004 19:37:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjSqb-0004Sz-4m for l3vpn-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 19:37:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19501 for ; Wed, 21 Jan 2004 19:37:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjSqZ-0005Lo-00 for l3vpn-web-archive@ietf.org; Wed, 21 Jan 2004 19:37:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjSpe-0005Kd-00 for l3vpn-web-archive@ietf.org; Wed, 21 Jan 2004 19:36:26 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjSpI-0005JL-00 for l3vpn-web-archive@ietf.org; Wed, 21 Jan 2004 19:36:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjSpF-0004FI-12; Wed, 21 Jan 2004 19:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjSof-0004DN-9p for l3vpn@optimus.ietf.org; Wed, 21 Jan 2004 19:35:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19486 for ; Wed, 21 Jan 2004 19:35:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjSod-0005Ig-00 for l3vpn@ietf.org; Wed, 21 Jan 2004 19:35:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjSng-0005HZ-00 for l3vpn@ietf.org; Wed, 21 Jan 2004 19:34:25 -0500 Received: from [142.46.197.162] (helo=pion-smtp.jnpr.net) by ietf-mx with esmtp (Exim 4.12) id 1AjSnO-0005GS-00 for l3vpn@ietf.org; Wed, 21 Jan 2004 19:34:06 -0500 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: draft-touch-ipsec-vpn-06.txt X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Wed, 21 Jan 2004 19:33:35 -0500 Message-ID: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DAD3@pion.jnpr.net> Thread-Topic: draft-touch-ipsec-vpn-06.txt Thread-Index: AcPgY2NC6gkLYqaNSWeqtUW7Aabt4wABD/YQ From: "Claudio Lordello" To: Cc: "Ross Callon" , "Claudio Lordello" Content-Transfer-Encoding: quoted-printable Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable My 2 cents: 1) Using ipsec tunnels for provisioning private networks running dynamic = protocols over a public infrastructure works just fine and existing = equipment, my company's included, has had that functionality for years, = without any of the issues mentioned in the draft. While it is true that = some other implementations may have limitations with running dynamic = routing over IPsec tunnels, that's more an implementation issue than one = intrinsic to the IPsec protocol. 2) Some versions of this draft have been submitted to the ipsec WG in = the past, and it did not progress in that WG. I am not sure I understand = the motivation for publishing this document. Perhaps someone could = clarify. Claudio. >Date: Wed, 21 Jan 2004 15:53:02 -0500 >To: l3vpn@ietf.org >From: Ross Callon >Subject: draft-touch-ipsec-vpn-06.txt >Cc: Thomas Narten > >We have been notified that the IESG is considering publication=20 >of an individual contribution entitled:=20 > Use of IPsec Transport Mode for Dynamic Routing > draft-touch-ipsec-vpn-06.txt > = http://www.ietf.org/internet-drafts/draft-touch-ipsec-vpn-06.txt > >This document is related to use of IPsec for support of VPNs. From=20 >the abstract of the document, it states in part: > > This document addresses the use of IPsec to secure the links=20 > of a virtual (private) network (VN/VPN)... > >Given that the document overlaps with our work, the issue has come >up regarding whether the document should be published without any >working group consideration, or whether the author should be requested >to bring the work to the l3vpn working group for consideration.=20 > >This leads to two questions: > > - Does the l3vpn working group feel that this document should be=20 >reviewed by a public working group, such as the l3vpn working group,=20 >prior to publication? > > - Do we have any technical comments on the document? > >Comments to the list, please. > >Thanks, Ross=20 From exim@www1.ietf.org Wed Jan 21 19:54:01 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19855 for ; Wed, 21 Jan 2004 19:54:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjT6C-0005Bm-Gq for l3vpn-archive@odin.ietf.org; Wed, 21 Jan 2004 19:53:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0M0rWn1019940 for l3vpn-archive@odin.ietf.org; Wed, 21 Jan 2004 19:53:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjT6C-0005BX-Cu for l3vpn-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 19:53:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19841 for ; Wed, 21 Jan 2004 19:53:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjT6A-0005zQ-00 for l3vpn-web-archive@ietf.org; Wed, 21 Jan 2004 19:53:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjT5E-0005wz-00 for l3vpn-web-archive@ietf.org; Wed, 21 Jan 2004 19:52:33 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjT4i-0005ul-00 for l3vpn-web-archive@ietf.org; Wed, 21 Jan 2004 19:52:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjT4i-00053Q-LK; Wed, 21 Jan 2004 19:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjT49-000537-8V for l3vpn@optimus.ietf.org; Wed, 21 Jan 2004 19:51:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19802 for ; Wed, 21 Jan 2004 19:51:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjT47-0005tQ-00 for l3vpn@ietf.org; Wed, 21 Jan 2004 19:51:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjT39-0005rz-00 for l3vpn@ietf.org; Wed, 21 Jan 2004 19:50:23 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1AjT2V-0005r7-00 for l3vpn@ietf.org; Wed, 21 Jan 2004 19:49:43 -0500 Received: from isi.edu (host253.tollo.net [206.117.6.253]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i0M0neD10571; Wed, 21 Jan 2004 16:49:40 -0800 (PST) Message-ID: <400F1E17.2020707@isi.edu> Date: Wed, 21 Jan 2004 16:49:27 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Claudio Lordello CC: l3vpn@ietf.org, Ross Callon Subject: Re: draft-touch-ipsec-vpn-06.txt References: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DAD3@pion.jnpr.net> In-Reply-To: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DAD3@pion.jnpr.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Claudio Lordello wrote: > My 2 cents: > > 1) Using ipsec tunnels for provisioning private networks running > dynamic protocols over a public infrastructure works just fine and > existing equipment, my company's included, has had that functionality > for years, without any of the issues mentioned in the draft. While it is > true that some other implementations may have limitations with running > dynamic routing over IPsec tunnels, that's more an implementation issue > than one intrinsic to the IPsec protocol. The issue is exactly that the result is implementation specific, and should not be. > 2) Some versions of this draft have been submitted to the ipsec WG in > the past, and it did not progress in that WG. I am not sure I > understand the motivation for publishing this document. Perhaps > someone could clarify. The IPsec WG recommended that we proceed with publishing it as an individual informational submission (which is where we are in the process), since any changes to RFC2401 would be better rolled into the (then pending, now emerging) update to 2401 rather than endorsed in a separate WG document (such changes have already been incorporated in the current 2401bis draft). Our draft adds to that primarily in discussing the issues - which is why we are proceeding with publication as informational. All these issues have been discussed in the IPsec and PPVPN WGs many times before. Joe > Claudio. > > > >>Date: Wed, 21 Jan 2004 15:53:02 -0500 >>To: l3vpn@ietf.org >>From: Ross Callon >>Subject: draft-touch-ipsec-vpn-06.txt >>Cc: Thomas Narten >> >>We have been notified that the IESG is considering publication >>of an individual contribution entitled: >> Use of IPsec Transport Mode for Dynamic Routing >> draft-touch-ipsec-vpn-06.txt >> http://www.ietf.org/internet-drafts/draft-touch-ipsec-vpn-06.txt >> >>This document is related to use of IPsec for support of VPNs. From >>the abstract of the document, it states in part: >> >> This document addresses the use of IPsec to secure the links >> of a virtual (private) network (VN/VPN)... >> >>Given that the document overlaps with our work, the issue has come >>up regarding whether the document should be published without any >>working group consideration, or whether the author should be requested >>to bring the work to the l3vpn working group for consideration. >> >>This leads to two questions: >> >> - Does the l3vpn working group feel that this document should be >>reviewed by a public working group, such as the l3vpn working group, >>prior to publication? >> >> - Do we have any technical comments on the document? >> >>Comments to the list, please. >> >>Thanks, Ross > > From exim@www1.ietf.org Wed Jan 21 21:30:22 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22859 for ; Wed, 21 Jan 2004 21:30:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjUbS-0002CP-Lm for l3vpn-archive@odin.ietf.org; Wed, 21 Jan 2004 21:29:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0M2Tsj9008447 for l3vpn-archive@odin.ietf.org; Wed, 21 Jan 2004 21:29:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjUbS-0002CA-Gz for l3vpn-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 21:29:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22815 for ; Wed, 21 Jan 2004 21:29:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjUbP-0002CD-00 for l3vpn-web-archive@ietf.org; Wed, 21 Jan 2004 21:29:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjUaY-00025K-00 for l3vpn-web-archive@ietf.org; Wed, 21 Jan 2004 21:28:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjUZe-0001y3-00 for l3vpn-web-archive@ietf.org; Wed, 21 Jan 2004 21:28:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjUZe-0001yw-OA; Wed, 21 Jan 2004 21:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjUZc-0001xP-81 for l3vpn@optimus.ietf.org; Wed, 21 Jan 2004 21:28:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22636 for ; Wed, 21 Jan 2004 21:27:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjUZZ-0001x5-00 for l3vpn@ietf.org; Wed, 21 Jan 2004 21:27:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjUYh-0001qJ-00 for l3vpn@ietf.org; Wed, 21 Jan 2004 21:27:04 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AjUXy-0001d1-00; Wed, 21 Jan 2004 21:26:18 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0M2Pl819223; Wed, 21 Jan 2004 21:25:47 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Jan 2004 21:25:48 -0500 Message-ID: From: "Hamid Ould-Brahim" To: l3vpn@ietf.org, l2vpn@ietf.org Subject: ppvpn archives for l2/3 vpns wgs... Date: Wed, 21 Jan 2004 21:25:47 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Checking the current l2/3 vpn archives, I noticed they do not include all previous discussions from year 2000-2003. I think we need to refer/move the former two ppvpn archives to l2&3 vpn wg archives. There are in fact two archives for former ppvpn wg: 1) From July 2000 to September 2002 which can be found at http://ppvpn.francetelecom.com/ 2) and from October 2002 to August 2003 can be found at: http://standards.nortelnetworks.com/archives/ppvpn.html The current l3vpn and l2vpn wg archives are only from May 2003-today Jan 04 (and I think they overlap with ppvpn from May 2003-August 2003). Hamid. From exim@www1.ietf.org Wed Jan 21 23:08:25 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25159 for ; Wed, 21 Jan 2004 23:08:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjW8M-0001Dn-VX for l3vpn-archive@odin.ietf.org; Wed, 21 Jan 2004 23:07:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0M47wuK004666 for l3vpn-archive@odin.ietf.org; Wed, 21 Jan 2004 23:07:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjW8L-0001D8-Ph for l3vpn-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 23:07:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25141 for ; Wed, 21 Jan 2004 23:07:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjW8G-0005yZ-00 for l3vpn-web-archive@ietf.org; Wed, 21 Jan 2004 23:07:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjW72-0005vc-00 for l3vpn-web-archive@ietf.org; Wed, 21 Jan 2004 23:06:37 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjW5Y-0005rn-00 for l3vpn-web-archive@ietf.org; Wed, 21 Jan 2004 23:05:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjW5W-0000lG-0I; Wed, 21 Jan 2004 23:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjW54-0000ju-B3 for l3vpn@optimus.ietf.org; Wed, 21 Jan 2004 23:04:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25068 for ; Wed, 21 Jan 2004 23:04:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjW50-0005qe-00 for l3vpn@ietf.org; Wed, 21 Jan 2004 23:04:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjW48-0005oo-00 for l3vpn@ietf.org; Wed, 21 Jan 2004 23:03:36 -0500 Received: from [142.46.197.162] (helo=pion-smtp.jnpr.net) by ietf-mx with esmtp (Exim 4.12) id 1AjW3I-0005ko-00 for l3vpn@ietf.org; Wed, 21 Jan 2004 23:02:44 -0500 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: draft-touch-ipsec-vpn-06.txt X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Wed, 21 Jan 2004 23:02:15 -0500 Message-ID: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DAD4@pion.jnpr.net> Thread-Topic: draft-touch-ipsec-vpn-06.txt Thread-Index: AcPggg9BNz/nONT/Sj6J3qkA/MPyUQAFkHDA From: "Claudio Lordello" To: "Joe Touch" Cc: , "Ross Callon" , "Claudio Lordello" Content-Transfer-Encoding: quoted-printable Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Joe Touch wrote: >=20 > The issue is exactly that the result is implementation specific, and=20 > should not be. >=20 Well, if this should not be implementation specific, then perhaps it = should be on standards track. >=20 > The IPsec WG recommended that we proceed with publishing it as an=20 > individual informational submission (which is where we are in the=20 > process), since any changes to RFC2401 would be better rolled=20 > into the=20 > (then pending, now emerging) update to 2401 rather than endorsed in a=20 > separate WG document (such changes have already been=20 > incorporated in the=20 > current 2401bis draft). Our draft adds to that primarily in=20 > discussing=20 > the issues - which is why we are proceeding with publication as=20 > informational. >=20 As far as I understood, all RFC2401bis is doing is lifting the = restriction that IPsec SG's MUST only use tunnel mode, a restriction = which currently exists in RFC2401. That does not mean that RFC2401bis = will favor tunnel or transport modes for this application. It does not = care. Anyway, the point I would like to make is that implementations should be = allowed to implement it either way, or perhaps both ways and let the = user pick which way to use it via configuration. If however, it is felt = by this WG that a single way should be picked, than I would ague that = tunnel mode is superior because it allows the tunnel selectors to act on = the tunneled traffic. Claudio. From exim@www1.ietf.org Thu Jan 22 01:09:07 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27584 for ; Thu, 22 Jan 2004 01:09:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjY18-0001dM-Qe for l3vpn-archive@odin.ietf.org; Thu, 22 Jan 2004 01:08:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0M68cfL006279 for l3vpn-archive@odin.ietf.org; Thu, 22 Jan 2004 01:08:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjY18-0001dC-Lm for l3vpn-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 01:08:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27580 for ; Thu, 22 Jan 2004 01:08:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjY15-0001sZ-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 01:08:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjY0A-0001rM-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 01:07:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjXzZ-0001pf-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 01:07:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjXzZ-0001FZ-TN; Thu, 22 Jan 2004 01:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjXzH-0001El-U0 for l3vpn@optimus.ietf.org; Thu, 22 Jan 2004 01:06:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27559 for ; Thu, 22 Jan 2004 01:06:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjXzF-0001pI-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 01:06:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjXyP-0001nK-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 01:05:49 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1AjXy0-0001k4-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 01:05:24 -0500 Received: from isi.edu (218.sub-69-83-69.myvzw.com [69.83.69.218]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i0M65HD01884; Wed, 21 Jan 2004 22:05:18 -0800 (PST) Message-ID: <400F6818.7090009@isi.edu> Date: Wed, 21 Jan 2004 22:05:12 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Claudio Lordello CC: l3vpn@ietf.org, Ross Callon Subject: Re: draft-touch-ipsec-vpn-06.txt References: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DAD4@pion.jnpr.net> In-Reply-To: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DAD4@pion.jnpr.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Claudio Lordello wrote: > > Joe Touch wrote: > >>The issue is exactly that the result is implementation specific, and >>should not be. >> > > Well, if this should not be implementation specific, > then perhaps it should be on standards track. It is a clarification of the standard, which, as below, is already being incorporated in 2401bis. The specific reasons are in this draft, though. >>The IPsec WG recommended that we proceed with publishing it as an >>individual informational submission (which is where we are in the >>process), since any changes to RFC2401 would be better rolled >>into the >>(then pending, now emerging) update to 2401 rather than endorsed in a >>separate WG document (such changes have already been >>incorporated in the >>current 2401bis draft). Our draft adds to that primarily in >>discussing >>the issues - which is why we are proceeding with publication as >>informational. >> > > > As far as I understood, all RFC2401bis is doing is lifting > the restriction that IPsec SG's MUST only use tunnel mode, > a restriction which currently exists in RFC2401. That does > not mean that RFC2401bis will favor tunnel or transport modes > for this application. It does not care. Yes. But it also has a more explicit processing model which has implications, notably on integrating dynamic routing with SPD lookup. The alternate solutions involve multiple SPDs; the new architecture doesn't. All these have implications on whether you can use tunnel-mode IPsec for dynamic routing, vs. transport mode on a non-IPsec tunnel. > Anyway, the point I would like to make is that implementations should > be allowed to implement it either way, or perhaps both ways and let > the user pick which way to use it via configuration. If however, > it is felt by this WG that a single way should be picked, than > I would ague that tunnel mode is superior because it allows the tunnel > selectors to act on the tunneled traffic. > > Claudio. The implementation difference is as per above, not whether you want to use tunnel mode vs. transport with non-IPsec tunnel. That is the need for the clarofications to 2401 which are already underway. As to which is better and under what circumstances, that's what the draft is about. Since it's not a standard - and doesn't itself modify a spec - it doesn't force a particular solution. What it does do is explain why transport + non-IPsec tunnel should be allowed, which it now is (or will be). Joe From exim@www1.ietf.org Thu Jan 22 10:38:43 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25284 for ; Thu, 22 Jan 2004 10:38:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjguO-0005yE-Mh for l3vpn-archive@odin.ietf.org; Thu, 22 Jan 2004 10:38:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MFcGOp022917 for l3vpn-archive@odin.ietf.org; Thu, 22 Jan 2004 10:38:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjguN-0005xB-Bq for l3vpn-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 10:38:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25214 for ; Thu, 22 Jan 2004 10:38:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjguL-0007MJ-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 10:38:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajgtl-0007HH-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 10:37:38 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjgsR-0007CF-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 10:36:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjgsD-00053n-4m; Thu, 22 Jan 2004 10:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjgrP-0004td-Q3 for l3vpn@optimus.ietf.org; Thu, 22 Jan 2004 10:35:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24981 for ; Thu, 22 Jan 2004 10:35:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjgrD-00076X-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 10:34:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjgnN-0006zb-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 10:31:02 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Ajgl3-0006p8-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 10:28:37 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 22 Jan 2004 07:28:55 -0800 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i0MFRb5g013225; Thu, 22 Jan 2004 10:27:38 -0500 (EST) Message-Id: <200401221527.i0MFRb5g013225@rtp-core-2.cisco.com> To: Ross Callon cc: l3vpn@ietf.org, Thomas Narten Subject: Re: draft-touch-ipsec-vpn-06.txt In-reply-to: Your message of Wed, 21 Jan 2004 15:53:02 -0500. <4.3.2.20040121153926.030be0a0@zircon.juniper.net> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 22 Jan 2004 10:27:37 -0500 From: Eric Rosen Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I think it would be useful to have an RFC which discusses the issues that arise when you want to use an IPsec Security Association as a routing adjacency. In fact, it might even be useful to have a standard way of doing this that would ensure multi-vendor interoperability. As Claudio points out, implementors do know how to do this, and there have been many products on the market for years that do this. Whether they do it in an interoperable manner is another question. Whether this is in violation of the IPsec standard is a further question. I'd have thought that a draft on this topic, even an informational draft, would need the approval of the IPsec WG. I am concerned about the fact that the IPsec WG has failed to progress this draft. Given that there are many deployed products that do routing over IPsec, I'd think an informational draft on the topic would benefit from making it clearer what the existing practices and what the interoperability issues are. With regard to the draft's relation to L3VPN, the L3VPN charter does unfortunately include "CE-based VPNs using IPsec". Unless this is removed from the charter (which would be a good thing imho), I think it would be odd for an individual draft on the topic to be published. From exim@www1.ietf.org Thu Jan 22 12:58:26 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01831 for ; Thu, 22 Jan 2004 12:58:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajj5c-00035f-5r for l3vpn-archive@odin.ietf.org; Thu, 22 Jan 2004 12:58:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MHw0Tc011875 for l3vpn-archive@odin.ietf.org; Thu, 22 Jan 2004 12:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajj5b-00035S-Ok for l3vpn-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 12:58:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01786 for ; Thu, 22 Jan 2004 12:57:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajj5a-00018M-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 12:57:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajj4f-00015S-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 12:57:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajj3q-00013N-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 12:56:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajj3i-0002x3-FN; Thu, 22 Jan 2004 12:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajj2n-0002vH-I0 for l3vpn@optimus.ietf.org; Thu, 22 Jan 2004 12:55:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01709 for ; Thu, 22 Jan 2004 12:55:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajj2l-00010t-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 12:55:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajj1q-0000ya-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 12:54:06 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1Ajj15-0000w0-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 12:53:20 -0500 Received: from isi.edu (host241.tethered.net [206.117.27.241]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i0MHr7D28802; Thu, 22 Jan 2004 09:53:07 -0800 (PST) Message-ID: <40100E03.4040601@isi.edu> Date: Thu, 22 Jan 2004 09:53:07 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: erosen@cisco.com CC: Ross Callon , l3vpn@ietf.org, Thomas Narten Subject: Re: draft-touch-ipsec-vpn-06.txt References: <200401221527.i0MFRb5g013225@rtp-core-2.cisco.com> In-Reply-To: <200401221527.i0MFRb5g013225@rtp-core-2.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric Rosen wrote: > I think it would be useful to have an RFC which discusses the issues that > arise when you want to use an IPsec Security Association as a routing > adjacency. In fact, it might even be useful to have a standard way of doing > this that would ensure multi-vendor interoperability. > > As Claudio points out, implementors do know how to do this, and there have > been many products on the market for years that do this. Whether they do it > in an interoperable manner is another question. Whether this is in > violation of the IPsec standard is a further question. > > I'd have thought that a draft on this topic, even an informational draft, > would need the approval of the IPsec WG. The IPsec WG already decided on this issue and suggested how to proceed - in the manner we are already doing. > I am concerned about the fact that > the IPsec WG has failed to progress this draft. It was never an IPsec WG document. The time delay is largely due to input from other WGs who 'discover' it and want to revisit issues that have already been covered ;-) > Given that there are many deployed products that do routing over IPsec, I'd > think an informational draft on the topic would benefit from making it > clearer what the existing practices and what the interoperability issues > are. The doc already discusses interoperability (i.e., that transport mode/IP tunnel and tunnel mode interoperate on the wire), and lists the various approaches in detail. > With regard to the draft's relation to L3VPN, the L3VPN charter does > unfortunately include "CE-based VPNs using IPsec". Unless this is removed > from the charter (which would be a good thing imho), I think it would be odd > for an individual draft on the topic to be published. The current CE-based L3VPN docs already cite this draft, directly or indirectly. CE-based L3VPNs are only one way our draft might be used; there are places where dynamic routing is used independent of a CE-based solution. Our draft - and our work for several years - is more closely associated with the IPsec WG due to the more direct impact on 2401bis. Paul Knight had an earlier summary of the various techniques for doing tunnels and their interaction with routing - which includes refs to our draft - and is more closely the summary and L3VPN-focused draft that you're proposing. You might want to solicit that document to focus on L3VPN issues. Joe From exim@www1.ietf.org Thu Jan 22 13:41:28 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03357 for ; Thu, 22 Jan 2004 13:41:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjjlE-000776-Kp for l3vpn-archive@odin.ietf.org; Thu, 22 Jan 2004 13:41:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MIf0hI027338 for l3vpn-archive@odin.ietf.org; Thu, 22 Jan 2004 13:41:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjjlE-00076r-DY for l3vpn-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 13:41:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03335 for ; Thu, 22 Jan 2004 13:40:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjjlC-0003GL-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 13:40:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjjkF-0003Ds-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 13:40:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjjjJ-0003BU-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 13:39:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjjjJ-00070C-20; Thu, 22 Jan 2004 13:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjjiK-0006jE-KK for l3vpn@optimus.ietf.org; Thu, 22 Jan 2004 13:38:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03161 for ; Thu, 22 Jan 2004 13:37:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjjiI-00038H-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 13:37:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjjhL-00035F-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 13:37:00 -0500 Received: from smtp807.mail.sc5.yahoo.com ([66.163.168.186]) by ietf-mx with smtp (Exim 4.12) id 1AjjgN-00031o-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 13:35:59 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp807.mail.sc5.yahoo.com with SMTP; 22 Jan 2004 18:35:58 -0000 Message-ID: <006301c3e116$959c6290$681067c0@adithya> From: "Mohan Parthasarathy" To: , "Ross Callon" Cc: "Thomas Narten" References: <4.3.2.20040121153926.030be0a0@zircon.juniper.net> Subject: Re: draft-touch-ipsec-vpn-06.txt Date: Thu, 22 Jan 2004 10:36:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Joe, I always liked the idea of using a IP-IP tunnel interface and securing with IPsec transport mode SA, but i am not sure i understand/agree with the issues regarding the alternative proposal mentioned in section 4.1.1. I am trying to understand why alternative 1 is a bad idea. There are some implementations which do this today. 4.1.1 Alternative 1: IPsec with Interface SAs In the first alternative, each IPsec tunnel mode SA is required to act as a full-fledged network interface. This SA interface acts as the outbound interface of the virtual destination's forwarding table entry. IPsec dynamically updates the SA interface configuration in response to SAD changes, e.g. caused by IKE negotiation. Could you elaborate on what this dynamic update is ? This approach supports dynamic routing and existing source address selection rules, but requires extensions to the IPsec architecture that define tunnel mode SA interfaces and their associated management procedures. What did you mean by "associated management procedures ? It would necessitate recapitulating the definition of the entirety of RFC 2003 IPIP encapsulation, including the association of tunnels with interfaces, inside IPsec. This defeats the modular architecture of the Internet, and violates the specification of type 4 IP in IP packets as being uniquely defined by a single Internet standard (it is already standardized by [N4]). For all practical purposes, it is an IP-IP interface. I see it as IPsec using the encapsulation scheme of RFC2003 which is what tunnel mode SA does anyway. There is also another difference. If you use IIPtran, you have to use the destination address to infer the VPN the packet belongs to. This means, you have to have one address per VPN for the box. If you support multiple VPNs, then this is a disadvantage. In the case of modelling ipsec tunnel mode SA as an interface, you can just use the SPI alone (which is allocated unique for the box) for finding out the VPN. You just need one address for the whole box which really is a big advantage. Is that right ? -mohan > We have been notified that the IESG is considering publication > of an individual contribution entitled: > Use of IPsec Transport Mode for Dynamic Routing > draft-touch-ipsec-vpn-06.txt > http://www.ietf.org/internet-drafts/draft-touch-ipsec-vpn-06.txt > > This document is related to use of IPsec for support of VPNs. From > the abstract of the document, it states in part: > > This document addresses the use of IPsec to secure the links > of a virtual (private) network (VN/VPN)... > > Given that the document overlaps with our work, the issue has come > up regarding whether the document should be published without any > working group consideration, or whether the author should be requested > to bring the work to the l3vpn working group for consideration. > > This leads to two questions: > > - Does the l3vpn working group feel that this document should be > reviewed by a public working group, such as the l3vpn working group, > prior to publication? > > - Do we have any technical comments on the document? > > Comments to the list, please. > > Thanks, Ross > From exim@www1.ietf.org Thu Jan 22 14:00:53 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04973 for ; Thu, 22 Jan 2004 14:00:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajk41-0000JD-A8 for l3vpn-archive@odin.ietf.org; Thu, 22 Jan 2004 14:00:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MJ0POB001187 for l3vpn-archive@odin.ietf.org; Thu, 22 Jan 2004 14:00:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajk41-0000J4-49 for l3vpn-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 14:00:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04964 for ; Thu, 22 Jan 2004 14:00:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajk3t-0005Jp-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 14:00:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajk2b-0005Ij-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 13:58:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajk1i-0005Hm-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 13:58:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajk1h-0000Cr-LM; Thu, 22 Jan 2004 13:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajk0n-0008UO-Fo for l3vpn@optimus.ietf.org; Thu, 22 Jan 2004 13:57:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04906 for ; Thu, 22 Jan 2004 13:57:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajk0l-0005Fc-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 13:57:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajjzy-0005E1-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 13:56:15 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1Ajjzg-0005Bc-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 13:55:56 -0500 Received: from isi.edu (224.sub-69-83-6.myvzw.com [69.83.6.224]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i0MItnD11752; Thu, 22 Jan 2004 10:55:49 -0800 (PST) Message-ID: <40101CA9.3040701@isi.edu> Date: Thu, 22 Jan 2004 10:55:37 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy CC: l3vpn@ietf.org, Ross Callon , Thomas Narten Subject: Re: draft-touch-ipsec-vpn-06.txt References: <4.3.2.20040121153926.030be0a0@zircon.juniper.net> <006301c3e116$959c6290$681067c0@adithya> In-Reply-To: <006301c3e116$959c6290$681067c0@adithya> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mohan Parthasarathy wrote: > Joe, > > I always liked the idea of using a IP-IP tunnel interface and securing with IPsec transport mode SA, but > i am not sure i understand/agree with the issues regarding the alternative proposal mentioned in > section 4.1.1. I am trying to understand why alternative 1 is a bad idea. There are some implementations > which do this today. First, because 2401bis makes it hard if not impossible, given a centralized SAD. > 4.1.1 Alternative 1: IPsec with Interface SAs > > In the first alternative, each IPsec tunnel mode SA is required to > act as a full-fledged network interface. This SA interface acts as > the outbound interface of the virtual destination's forwarding table > entry. IPsec dynamically updates the SA interface configuration in > response to SAD changes, e.g. caused by IKE negotiation. > > Could you elaborate on what this dynamic update is ? IKE negotiation updates the SAD - when a new SA is negotiated, it is entered into the SAD and takes effect > This approach supports dynamic routing and existing source address > selection rules, but requires extensions to the IPsec architecture > that define tunnel mode SA interfaces and their associated management > procedures. > > What did you mean by "associated management procedures ? See RFC2401 and the IKE RFCs. > It would necessitate recapitulating the definition of the entirety of > RFC 2003 IPIP encapsulation, including the association of tunnels > with interfaces, inside IPsec. This defeats the modular architecture > of the Internet, and violates the specification of type 4 IP in IP > packets as being uniquely defined by a single Internet standard (it > is already standardized by [N4]). > > For all practical purposes, it is an IP-IP interface. Except that IP-IP interfaces are routable, whereas IPsec tunnels need not be implemented as routable interfaces. > I see it as IPsec using > the encapsulation scheme of RFC2003 which is what tunnel mode SA > does anyway. Tunnel-mode SAs aren't routable interfaces necessarily. > There is also another difference. If you use IIPtran, you have > to use the destination address to infer the VPN the packet belongs to. > This means, you have to have one address per VPN for the box. If you > support multiple VPNs, then this is a disadvantage. In the > case of modelling ipsec tunnel mode SA as an interface, you can just use > the SPI alone (which is allocated unique for the box) for finding out the > VPN. You just need one address for the whole box which really is > a big advantage. Is that right ? > > -mohan IIPtran uses the address to demux, not the SPI. This means that the virtual network is _independent_ of whether IPsec is used or not. Dynamic routing is based on addresses; there are emerging standards for how to augment those addresses with IDs outside the SPI space (e.g., VPN IDs) which would allow reuse of addresses that touchdown at the same node - regardless of whether IPsec is used or not. A L3VPN doc (such as Knight's?) would address these issues in specific, but our draft is intended to be more general. Joe >>We have been notified that the IESG is considering publication >>of an individual contribution entitled: >>Use of IPsec Transport Mode for Dynamic Routing >>draft-touch-ipsec-vpn-06.txt >>http://www.ietf.org/internet-drafts/draft-touch-ipsec-vpn-06.txt >> >>This document is related to use of IPsec for support of VPNs. From >>the abstract of the document, it states in part: >> >>This document addresses the use of IPsec to secure the links >>of a virtual (private) network (VN/VPN)... >> >>Given that the document overlaps with our work, the issue has come >>up regarding whether the document should be published without any >>working group consideration, or whether the author should be requested >>to bring the work to the l3vpn working group for consideration. >> >>This leads to two questions: >> >> - Does the l3vpn working group feel that this document should be >>reviewed by a public working group, such as the l3vpn working group, >>prior to publication? >> >> - Do we have any technical comments on the document? >> >>Comments to the list, please. >> >>Thanks, Ross >> From exim@www1.ietf.org Thu Jan 22 14:22:18 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05499 for ; Thu, 22 Jan 2004 14:22:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjkOl-0002QH-Bk for l3vpn-archive@odin.ietf.org; Thu, 22 Jan 2004 14:21:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MJLpHe009307 for l3vpn-archive@odin.ietf.org; Thu, 22 Jan 2004 14:21:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjkOj-0002Q2-PR for l3vpn-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 14:21:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05483 for ; Thu, 22 Jan 2004 14:21:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjkOc-00068R-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 14:21:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjkLg-00062p-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 14:18:43 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjkJQ-0005wR-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 14:16:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjkJ8-00027Y-TD; Thu, 22 Jan 2004 14:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjkJ6-00026x-Ct for l3vpn@optimus.ietf.org; Thu, 22 Jan 2004 14:16:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05333 for ; Thu, 22 Jan 2004 14:15:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjkIy-0005vI-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 14:15:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjkFR-0005lx-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 14:12:14 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1AjkDU-0005cG-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 14:10:12 -0500 Received: from isi.edu (224.sub-69-83-6.myvzw.com [69.83.6.224]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i0MJ9tD27614; Thu, 22 Jan 2004 11:09:56 -0800 (PST) Message-ID: <40101FFA.4070303@isi.edu> Date: Thu, 22 Jan 2004 11:09:46 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Claudio Lordello CC: l3vpn@ietf.org, Ross Callon Subject: Re: draft-touch-ipsec-vpn-06.txt References: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DAD4@pion.jnpr.net> In-Reply-To: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DAD4@pion.jnpr.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Claudio Lordello wrote: > > Joe Touch wrote: > >>The issue is exactly that the result is implementation specific, and >>should not be. > > Well, if this should not be implementation specific, then perhaps it > hould be on standards track. It is - the specific recommendations are made as standards-track in 2401bis. >>The IPsec WG recommended that we proceed with publishing it as an >>individual informational submission (which is where we are in the >>process), since any changes to RFC2401 would be better rolled >>into the >>(then pending, now emerging) update to 2401 rather than endorsed in a >>separate WG document (such changes have already been >>incorporated in the >>current 2401bis draft). Our draft adds to that primarily in >>discussing >>the issues - which is why we are proceeding with publication as >>informational. >> > > > As far as I understood, all RFC2401bis is doing is lifting the > restriction that IPsec SG's MUST only use tunnel mode, a restriction > which currently exists in RFC2401. That does not mean that RFC2401bis > will favor tunnel or transport modes for this application. It does not care. See also the revised description of the processing model, notably the use of a single SPD, as well as the many threads of this discussion on the IPsec and PPVPN mailing lists. > Anyway, the point I would like to make is that implementations should > be allowed to implement it either way, or perhaps both ways and let the > user pick which way to use it via configuration. One of the ways isn't consistent with the use of a single SPD. > If however, it is felt > by this WG that a single way should be picked, than I would ague that > tunnel mode is superior because it allows the tunnel selectors to act on > the tunneled traffic. > > Claudio. First, that's an artifact of a deficiency in transport mode, which we raised a while back in the IPsec WG, notably that transport mode doesn't have provisions for looking at IP as a transport payload (even though it's well-defined as such - protocol type 4). That would require revising the SPD specs in 2401 substantially, which isn't really needed, due to the second point.... Second, it was perceived by the IPsec WG that tunnel selectors aren't needed in the IP-over-IP case (a special case of L3VPNs). That issue was also discussed in the IPsec WG a while ago. Our doc (and the many previous WG discussions) addresses these issues, as well as others that have been raised in detail already. Joe From exim@www1.ietf.org Thu Jan 22 14:32:52 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05848 for ; Thu, 22 Jan 2004 14:32:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjkYy-0003Ve-Sj for l3vpn-archive@odin.ietf.org; Thu, 22 Jan 2004 14:32:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MJWOnZ013484 for l3vpn-archive@odin.ietf.org; Thu, 22 Jan 2004 14:32:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjkYy-0003VP-NS for l3vpn-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 14:32:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05817 for ; Thu, 22 Jan 2004 14:32:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjkYw-0002YQ-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 14:32:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjkY6-0002Pr-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 14:31:32 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjkW1-0007IB-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 14:29:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjkVh-00031P-8q; Thu, 22 Jan 2004 14:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjkUW-0002vs-8W for l3vpn@optimus.ietf.org; Thu, 22 Jan 2004 14:28:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05622 for ; Thu, 22 Jan 2004 14:27:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjkUO-0006Ji-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 14:27:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjkR8-0006DP-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 14:24:18 -0500 Received: from smtp810.mail.sc5.yahoo.com ([66.163.170.80]) by ietf-mx with smtp (Exim 4.12) id 1AjkOd-00066D-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 14:21:43 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp810.mail.sc5.yahoo.com with SMTP; 22 Jan 2004 19:20:29 -0000 Message-ID: <008901c3e11c$cd650730$681067c0@adithya> From: "Mohan Parthasarathy" To: "Joe Touch" Cc: , "Ross Callon" , "Thomas Narten" References: <4.3.2.20040121153926.030be0a0@zircon.juniper.net> <006301c3e116$959c6290$681067c0@adithya> <40101CA9.3040701@isi.edu> Subject: Re: draft-touch-ipsec-vpn-06.txt Date: Thu, 22 Jan 2004 11:20:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > It would necessitate recapitulating the definition of the entirety of > > RFC 2003 IPIP encapsulation, including the association of tunnels > > with interfaces, inside IPsec. This defeats the modular architecture > > of the Internet, and violates the specification of type 4 IP in IP > > packets as being uniquely defined by a single Internet standard (it > > is already standardized by [N4]). > > > > For all practical purposes, it is an IP-IP interface. > > Except that IP-IP interfaces are routable, whereas IPsec tunnels need > not be implemented as routable interfaces. > We are discussing about the alternative 1, where the IPsec tunnel is an interface. > > I see it as IPsec using > > the encapsulation scheme of RFC2003 which is what tunnel mode SA > > does anyway. > > Tunnel-mode SAs aren't routable interfaces necessarily. Again, i thought we are discussing about alternative 1. > > > There is also another difference. If you use IIPtran, you have > > to use the destination address to infer the VPN the packet belongs to. > > This means, you have to have one address per VPN for the box. If you > > support multiple VPNs, then this is a disadvantage. In the > > case of modelling ipsec tunnel mode SA as an interface, you can just use > > the SPI alone (which is allocated unique for the box) for finding out the > > VPN. You just need one address for the whole box which really is > > a big advantage. Is that right ? > > > > -mohan > > IIPtran uses the address to demux, not the SPI. This means that the > virtual network is _independent_ of whether IPsec is used or not. > > Dynamic routing is based on addresses; there are emerging standards for > how to augment those addresses with IDs outside the SPI space (e.g., VPN > IDs) which would allow reuse of addresses that touchdown at the same > node - regardless of whether IPsec is used or not. > In the forwarding plane, when a packet enters IP, you still need something in the IP header or following it, to differentiate the multiple VPNs. Are you saying that there might be a different header with the packet that would allow you to differentiate the multiple VPNs ? > A L3VPN doc (such as Knight's?) would address these issues in specific, > but our draft is intended to be more general. > I could not locate this document anywhere. Do you have a copy of it ? thanks mohan > Joe > > >>We have been notified that the IESG is considering publication > >>of an individual contribution entitled: > >>Use of IPsec Transport Mode for Dynamic Routing > >>draft-touch-ipsec-vpn-06.txt > >>http://www.ietf.org/internet-drafts/draft-touch-ipsec-vpn-06.txt > >> > >>This document is related to use of IPsec for support of VPNs. From > >>the abstract of the document, it states in part: > >> > >>This document addresses the use of IPsec to secure the links > >>of a virtual (private) network (VN/VPN)... > >> > >>Given that the document overlaps with our work, the issue has come > >>up regarding whether the document should be published without any > >>working group consideration, or whether the author should be requested > >>to bring the work to the l3vpn working group for consideration. > >> > >>This leads to two questions: > >> > >> - Does the l3vpn working group feel that this document should be > >>reviewed by a public working group, such as the l3vpn working group, > >>prior to publication? > >> > >> - Do we have any technical comments on the document? > >> > >>Comments to the list, please. > >> > >>Thanks, Ross > >> From exim@www1.ietf.org Thu Jan 22 14:37:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06274 for ; Thu, 22 Jan 2004 14:37:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjkdS-0003rC-KW for l3vpn-archive@odin.ietf.org; Thu, 22 Jan 2004 14:37:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MJb2lX014812 for l3vpn-archive@odin.ietf.org; Thu, 22 Jan 2004 14:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjkdR-0003qZ-QX for l3vpn-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 14:37:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06267 for ; Thu, 22 Jan 2004 14:36:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjkdP-0005d1-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 14:36:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajkcp-0004n9-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 14:36:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjkcV-0004Ny-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 14:36:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjkcT-0003kj-7q; Thu, 22 Jan 2004 14:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjkbV-0003fz-Gh for l3vpn@optimus.ietf.org; Thu, 22 Jan 2004 14:35:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06058 for ; Thu, 22 Jan 2004 14:34:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjkbS-0003uT-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 14:34:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjkaU-0003CO-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 14:33:59 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1AjkZX-0002b7-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 14:32:59 -0500 Received: from isi.edu (224.sub-69-83-6.myvzw.com [69.83.6.224]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i0MJWbD24947; Thu, 22 Jan 2004 11:32:38 -0800 (PST) Message-ID: <40102551.8050405@isi.edu> Date: Thu, 22 Jan 2004 11:32:33 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy CC: l3vpn@ietf.org, Ross Callon , Thomas Narten Subject: Re: draft-touch-ipsec-vpn-06.txt References: <4.3.2.20040121153926.030be0a0@zircon.juniper.net> <006301c3e116$959c6290$681067c0@adithya> <40101CA9.3040701@isi.edu> <008901c3e11c$cd650730$681067c0@adithya> In-Reply-To: <008901c3e11c$cd650730$681067c0@adithya> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mohan Parthasarathy wrote: > > > >>> It would necessitate recapitulating the definition of the entirety of >>> RFC 2003 IPIP encapsulation, including the association of tunnels >>> with interfaces, inside IPsec. This defeats the modular architecture >>> of the Internet, and violates the specification of type 4 IP in IP >>> packets as being uniquely defined by a single Internet standard (it >>> is already standardized by [N4]). >>> >>>For all practical purposes, it is an IP-IP interface. >> >>Except that IP-IP interfaces are routable, whereas IPsec tunnels need >>not be implemented as routable interfaces. > > We are discussing about the alternative 1, where the IPsec tunnel is an interface. Except where they are not (the "need not" part). >>>I see it as IPsec using >>>the encapsulation scheme of RFC2003 which is what tunnel mode SA >>>does anyway. >> >>Tunnel-mode SAs aren't routable interfaces necessarily. > > > Again, i thought we are discussing about alternative 1. Again, the "necessarily" part is important. The issue is that 2401bis would have to force an implementation, which neither 2401 nor 2401bis do (or should, IMO). >>>There is also another difference. If you use IIPtran, you have >>>to use the destination address to infer the VPN the packet belongs to. >>>This means, you have to have one address per VPN for the box. If you >>>support multiple VPNs, then this is a disadvantage. In the >>>case of modelling ipsec tunnel mode SA as an interface, you can just use >>>the SPI alone (which is allocated unique for the box) for finding out the >>>VPN. You just need one address for the whole box which really is >>>a big advantage. Is that right ? >>> >>>-mohan >> >>IIPtran uses the address to demux, not the SPI. This means that the >>virtual network is _independent_ of whether IPsec is used or not. >> >>Dynamic routing is based on addresses; there are emerging standards for >>how to augment those addresses with IDs outside the SPI space (e.g., VPN >>IDs) which would allow reuse of addresses that touchdown at the same >>node - regardless of whether IPsec is used or not. > > In the forwarding plane, when a packet enters IP, you still need something in > the IP header or following it, to differentiate the multiple VPNs. Are you > saying that there might be a different header with the packet that would > allow you to differentiate the multiple VPNs ? Either the IP address (which is what we do) or a VPN-ID in an inner header or option allows that. Overloading the SPI for that has numerous complications. >>A L3VPN doc (such as Knight's?) would address these issues in specific, >>but our draft is intended to be more general. > > I could not locate this document anywhere. Do you have a copy of it ? http://www.ietf.org/internet-drafts/draft-knight-ppvpn-vr-protocol-00.txt is related. Look for other drafts by that author. Joe > > thanks > mohan > > >>Joe >> >> >>>>We have been notified that the IESG is considering publication >>>>of an individual contribution entitled: >>>>Use of IPsec Transport Mode for Dynamic Routing >>>>draft-touch-ipsec-vpn-06.txt >>>>http://www.ietf.org/internet-drafts/draft-touch-ipsec-vpn-06.txt >>>> >>>>This document is related to use of IPsec for support of VPNs. From >>>>the abstract of the document, it states in part: >>>> >>>>This document addresses the use of IPsec to secure the links >>>>of a virtual (private) network (VN/VPN)... >>>> >>>>Given that the document overlaps with our work, the issue has come >>>>up regarding whether the document should be published without any >>>>working group consideration, or whether the author should be requested >>>>to bring the work to the l3vpn working group for consideration. >>>> >>>>This leads to two questions: >>>> >>>> - Does the l3vpn working group feel that this document should be >>>>reviewed by a public working group, such as the l3vpn working group, >>>>prior to publication? >>>> >>>> - Do we have any technical comments on the document? >>>> >>>>Comments to the list, please. >>>> >>>>Thanks, Ross >>>> From exim@www1.ietf.org Thu Jan 22 15:35:52 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09352 for ; Thu, 22 Jan 2004 15:35:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjlXw-00081g-AB for l3vpn-archive@odin.ietf.org; Thu, 22 Jan 2004 15:35:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MKZOrc030846 for l3vpn-archive@odin.ietf.org; Thu, 22 Jan 2004 15:35:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjlXw-00081R-4o for l3vpn-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 15:35:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09277 for ; Thu, 22 Jan 2004 15:35:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjlXu-0006p5-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 15:35:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjlWt-0006hB-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 15:34:20 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjlVx-0006Y5-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 15:33:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjlVe-0007KK-Td; Thu, 22 Jan 2004 15:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjlVO-0007Fw-Rl for l3vpn@optimus.ietf.org; Thu, 22 Jan 2004 15:32:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08845 for ; Thu, 22 Jan 2004 15:32:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjlVN-0006RZ-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 15:32:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjlTu-00068o-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 15:31:15 -0500 Received: from smtp803.mail.sc5.yahoo.com ([66.163.168.182]) by ietf-mx with smtp (Exim 4.12) id 1AjlMi-0005b3-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 15:23:48 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp803.mail.sc5.yahoo.com with SMTP; 22 Jan 2004 20:22:44 -0000 Message-ID: <009301c3e125$7f5da930$681067c0@adithya> From: "Mohan Parthasarathy" To: "Joe Touch" Cc: , "Ross Callon" , "Thomas Narten" References: <4.3.2.20040121153926.030be0a0@zircon.juniper.net> <006301c3e116$959c6290$681067c0@adithya> <40101CA9.3040701@isi.edu> <008901c3e11c$cd650730$681067c0@adithya> <40102551.8050405@isi.edu> Subject: Re: draft-touch-ipsec-vpn-06.txt Date: Thu, 22 Jan 2004 12:22:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > >>> It would necessitate recapitulating the definition of the entirety of > >>> RFC 2003 IPIP encapsulation, including the association of tunnels > >>> with interfaces, inside IPsec. This defeats the modular architecture > >>> of the Internet, and violates the specification of type 4 IP in IP > >>> packets as being uniquely defined by a single Internet standard (it > >>> is already standardized by [N4]). > >>> > >>>For all practical purposes, it is an IP-IP interface. > >> > >>Except that IP-IP interfaces are routable, whereas IPsec tunnels need > >>not be implemented as routable interfaces. > > > > We are discussing about the alternative 1, where the IPsec tunnel is an interface. > > Except where they are not (the "need not" part). > > >>>I see it as IPsec using > >>>the encapsulation scheme of RFC2003 which is what tunnel mode SA > >>>does anyway. > >> > >>Tunnel-mode SAs aren't routable interfaces necessarily. > > > > > > Again, i thought we are discussing about alternative 1. > > Again, the "necessarily" part is important. > > The issue is that 2401bis would have to force an implementation, which > neither 2401 nor 2401bis do (or should, IMO). > I am a bit confused. We are comparing IIPtran with Alternative 1. Alternative 1 needs some clarifications in rfc2401 about tunnel mode SAs and so does IIPtran. > >>>There is also another difference. If you use IIPtran, you have > >>>to use the destination address to infer the VPN the packet belongs to. > >>>This means, you have to have one address per VPN for the box. If you > >>>support multiple VPNs, then this is a disadvantage. In the > >>>case of modelling ipsec tunnel mode SA as an interface, you can just use > >>>the SPI alone (which is allocated unique for the box) for finding out the > >>>VPN. You just need one address for the whole box which really is > >>>a big advantage. Is that right ? > >>> > >>>-mohan > >> > >>IIPtran uses the address to demux, not the SPI. This means that the > >>virtual network is _independent_ of whether IPsec is used or not. > >> > >>Dynamic routing is based on addresses; there are emerging standards for > >>how to augment those addresses with IDs outside the SPI space (e.g., VPN > >>IDs) which would allow reuse of addresses that touchdown at the same > >>node - regardless of whether IPsec is used or not. > > > > In the forwarding plane, when a packet enters IP, you still need something in > > the IP header or following it, to differentiate the multiple VPNs. Are you > > saying that there might be a different header with the packet that would > > allow you to differentiate the multiple VPNs ? > > Either the IP address (which is what we do) or a VPN-ID in an inner > header or option allows that. Overloading the SPI for that has numerous > complications. > I don't know what complications you refer to. Using IIPtran in this scenario is not easy. You have to pre-setup all the IP-IP interfaces, one for each VPN. In Alternative 1, IKE can be used to dynamically plumb these interfaces. > >>A L3VPN doc (such as Knight's?) would address these issues in specific, > >>but our draft is intended to be more general. > > > > I could not locate this document anywhere. Do you have a copy of it ? > > http://www.ietf.org/internet-drafts/draft-knight-ppvpn-vr-protocol-00.txt > > is related. Look for other drafts by that author. > thanks mohan > Joe > > > > > thanks > > mohan > > > > > >>Joe > >> > >> > >>>>We have been notified that the IESG is considering publication > >>>>of an individual contribution entitled: > >>>>Use of IPsec Transport Mode for Dynamic Routing > >>>>draft-touch-ipsec-vpn-06.txt > >>>>http://www.ietf.org/internet-drafts/draft-touch-ipsec-vpn-06.txt > >>>> > >>>>This document is related to use of IPsec for support of VPNs. From > >>>>the abstract of the document, it states in part: > >>>> > >>>>This document addresses the use of IPsec to secure the links > >>>>of a virtual (private) network (VN/VPN)... > >>>> > >>>>Given that the document overlaps with our work, the issue has come > >>>>up regarding whether the document should be published without any > >>>>working group consideration, or whether the author should be requested > >>>>to bring the work to the l3vpn working group for consideration. > >>>> > >>>>This leads to two questions: > >>>> > >>>> - Does the l3vpn working group feel that this document should be > >>>>reviewed by a public working group, such as the l3vpn working group, > >>>>prior to publication? > >>>> > >>>> - Do we have any technical comments on the document? > >>>> > >>>>Comments to the list, please. > >>>> > >>>>Thanks, Ross > >>>> From exim@www1.ietf.org Thu Jan 22 15:36:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09491 for ; Thu, 22 Jan 2004 15:36:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjlYh-0008Em-FT for l3vpn-archive@odin.ietf.org; Thu, 22 Jan 2004 15:36:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MKaBwj031658 for l3vpn-archive@odin.ietf.org; Thu, 22 Jan 2004 15:36:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjlYh-0008EW-2Q for l3vpn-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 15:36:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09405 for ; Thu, 22 Jan 2004 15:36:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjlYf-0006vu-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 15:36:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjlXj-0006nd-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 15:35:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjlWh-0006fJ-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 15:34:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjlWb-0007gi-Hs; Thu, 22 Jan 2004 15:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjlW4-0007Rk-Ok for l3vpn@optimus.ietf.org; Thu, 22 Jan 2004 15:33:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08987 for ; Thu, 22 Jan 2004 15:33:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjlW3-0006Z1-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 15:33:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjlUl-0006KX-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 15:32:10 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1AjlQO-0005wK-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 15:27:36 -0500 Received: from isi.edu (224.sub-69-83-6.myvzw.com [69.83.6.224]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i0MKR1D29501; Thu, 22 Jan 2004 12:27:01 -0800 (PST) Message-ID: <40103211.90005@isi.edu> Date: Thu, 22 Jan 2004 12:26:57 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy CC: l3vpn@ietf.org, Ross Callon , Thomas Narten Subject: Re: draft-touch-ipsec-vpn-06.txt References: <4.3.2.20040121153926.030be0a0@zircon.juniper.net> <006301c3e116$959c6290$681067c0@adithya> <40101CA9.3040701@isi.edu> <008901c3e11c$cd650730$681067c0@adithya> <40102551.8050405@isi.edu> <009301c3e125$7f5da930$681067c0@adithya> In-Reply-To: <009301c3e125$7f5da930$681067c0@adithya> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mohan Parthasarathy wrote: >>>>>I see it as IPsec using >>>>>the encapsulation scheme of RFC2003 which is what tunnel mode SA >>>>>does anyway. >>>> >>>>Tunnel-mode SAs aren't routable interfaces necessarily. >>> >>> >>>Again, i thought we are discussing about alternative 1. >> >>Again, the "necessarily" part is important. >> >>The issue is that 2401bis would have to force an implementation, which >>neither 2401 nor 2401bis do (or should, IMO). > > I am a bit confused. We are comparing IIPtran with Alternative 1. > Alternative 1 needs some clarifications in rfc2401 about tunnel mode SAs > and so does IIPtran. Alternative 1 requires 2401bis specify an implementation, which it is not likely to do (and largely inappropriate as well). IIPtran requres 2401bis permit transport mode between gateways - which it already does, and is a protocol specification issue. >>>>>There is also another difference. If you use IIPtran, you have >>>>>to use the destination address to infer the VPN the packet belongs to. >>>>>This means, you have to have one address per VPN for the box. If you >>>>>support multiple VPNs, then this is a disadvantage. In the >>>>>case of modelling ipsec tunnel mode SA as an interface, you can just use >>>>>the SPI alone (which is allocated unique for the box) for finding out the >>>>>VPN. You just need one address for the whole box which really is >>>>>a big advantage. Is that right ? >>>>> >>>>>-mohan >>>> >>>>IIPtran uses the address to demux, not the SPI. This means that the >>>>virtual network is _independent_ of whether IPsec is used or not. >>>> >>>>Dynamic routing is based on addresses; there are emerging standards for >>>>how to augment those addresses with IDs outside the SPI space (e.g., VPN >>>>IDs) which would allow reuse of addresses that touchdown at the same >>>>node - regardless of whether IPsec is used or not. >>> >>>In the forwarding plane, when a packet enters IP, you still need something in >>>the IP header or following it, to differentiate the multiple VPNs. Are you >>>saying that there might be a different header with the packet that would >>>allow you to differentiate the multiple VPNs ? >> >>Either the IP address (which is what we do) or a VPN-ID in an inner >>header or option allows that. Overloading the SPI for that has numerous >>complications. > > I don't know what complications you refer to. Using IIPtran in this scenario > is not easy. You have to pre-setup all the IP-IP interfaces, one for each > VPN. In Alternative 1, IKE can be used to dynamically plumb these > interfaces. That's all static. The dynamic routing protocols need to be modified to exchange SPIs now, to resolve different VPNs that reuse addresses. The alternative is to use routing-specific information - IP addresses or VPN IDs - instead. Joe From exim@www1.ietf.org Thu Jan 22 16:48:49 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14039 for ; Thu, 22 Jan 2004 16:48:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjmgY-0005zf-20 for l3vpn-archive@odin.ietf.org; Thu, 22 Jan 2004 16:48:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MLmM1o023035 for l3vpn-archive@odin.ietf.org; Thu, 22 Jan 2004 16:48:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjmgX-0005zO-J6 for l3vpn-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 16:48:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13986 for ; Thu, 22 Jan 2004 16:48:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjmgV-0005xE-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 16:48:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjmeB-0005QQ-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 16:45:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjmZX-0004Ou-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 16:41:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjmZR-0005En-W9; Thu, 22 Jan 2004 16:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjmYs-0005Bf-6h for l3vpn@optimus.ietf.org; Thu, 22 Jan 2004 16:40:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12447 for ; Thu, 22 Jan 2004 16:40:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjmYp-0004GT-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 16:40:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjmQK-00038B-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 16:31:39 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AjmBq-0002HA-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 16:16:38 -0500 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0MLFvW09036 for ; Thu, 22 Jan 2004 16:15:57 -0500 (EST) Received: by zbl6c012.corpeast.baynetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Jan 2004 16:15:56 -0500 Message-ID: <6204FDDE129D364D8040A98BCCB290EF0ADFEC09@zbl6c004.corpeast.baynetworks.com> From: "Paul Knight" To: Joe Touch , erosen@cisco.com Cc: Ross Callon , l3vpn@ietf.org, Thomas Narten Subject: RE: draft-touch-ipsec-vpn-06.txt Date: Thu, 22 Jan 2004 16:15:51 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi all, In response to Ross's original question, I would like to support the Touch draft progressing as an Informational RFC, since in my opinion it does a very good job of describing the basic transport/tunnel dilemmas for dynamic routing. The Touch draft is largely a theoretical approach, although it is based on experience with the X-bone project. As Joe says, it has been discussed in the past in both IPSEC and PPVPN, and definitely provided the impetus to the modifications to RFC2401 regarding transport mode. The IPSEC group had no objections to the draft, and as Joe says, suggested that it be published as Informational. I think it is a very useful reference point for further work, and it would be a mistake to try to expand its scope to deal with the whole range of transport-vs.-tunnel issues. I also agree with Eric that it will be valuable to develop a separate L3VPN WG draft which focuses on the issues of using an IPsec SA as a routing adjacency, and related issues of specifying the next-hop, ordering the processing of routing and SA lookup, etc. This should be an implementation-focused RFC. IMHO, I agree with Joe that my draft (http://www.ietf.org/internet-drafts/draft-knight-ppvpn-ipsec-dynroute-03.tx t) may be a reasonable starting point (or at least a source of some text) for this effort, although it is currently focusing mostly on the transport mode approach. It describes an implementation which is very widely deployed. For a WG draft, it would probably be useful to add balancing text describing the tunnel mode approach. In addition, I think it should start by developing a good analysis of how to treat tunnel endpoints as interfaces - or not. It also needs to clearly describe the issues of ordering of SA and route selection, and how to separate the two. This is really a key point - how to prevent the routing from compromising the security. There must be a clear delineation of the two. The WG draft may also need to address such issues as how to handle the loss of routes within the overlay network - how to prevent the traffic from ending up on a default route, potentially with unintended security characteristics. The goal is clearly interoperability. As my draft points out, interoperability of dynamic routing (RIP and OSPF) using transport mode (IIPtran, in the Touch terminology) has been demonstrated between multiple vendors. However, this whole area can benefit from some more work. Regards, Paul Knight > -----Original Message----- > From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org] On > Behalf Of Joe Touch > Sent: Thursday, January 22, 2004 12:53 PM > To: erosen@cisco.com > Cc: Ross Callon; l3vpn@ietf.org; Thomas Narten > Subject: Re: draft-touch-ipsec-vpn-06.txt > > > > > Eric Rosen wrote: > > > I think it would be useful to have an RFC which discusses the > > issues that arise when you want to use an IPsec Security > > Association as a routing adjacency. In fact, it might even be > > useful to have a standard way of doing this that would > ensure multi-vendor interoperability. > > > > As Claudio points out, implementors do know how to do this, and > > there have been many products on the market for years that > do this. Whether they do it > > in an interoperable manner is another question. > Whether this is in > > violation of the IPsec standard is a further question. > > > > I'd have thought that a draft on this topic, even an > informational > > draft, would need the approval of the IPsec WG. > > The IPsec WG already decided on this issue and suggested how > to proceed > - in the manner we are already doing. > > > I am concerned about the fact that > > the IPsec WG has failed to progress this draft. > > It was never an IPsec WG document. The time delay is largely > due to input from other WGs who 'discover' it and want to > revisit issues that have already been covered ;-) > > > Given that there are many deployed products that do routing over > > IPsec, I'd think an informational draft on the topic > would benefit > > from making it clearer what the existing practices and > what the > > interoperability issues are. > > The doc already discusses interoperability (i.e., that > transport mode/IP tunnel and tunnel mode interoperate on the > wire), and lists the various approaches in detail. > > > With regard to the draft's relation to L3VPN, the > L3VPN charter > > does unfortunately include "CE-based VPNs using IPsec". > Unless this > > is removed from the charter (which would be a good thing imho), I > > think it would be odd for an individual draft on the topic to be > > published. > > The current CE-based L3VPN docs already cite this draft, > directly or indirectly. CE-based L3VPNs are only one way our > draft might be used; there are places where dynamic routing > is used independent of a CE-based solution. > > Our draft - and our work for several years - is more closely > associated with the IPsec WG due to the more direct impact on 2401bis. > > Paul Knight had an earlier summary of the various techniques > for doing > tunnels and their interaction with routing - which includes > refs to our > draft - and is more closely the summary and L3VPN-focused draft that > you're proposing. You might want to solicit that document to focus on > L3VPN issues. > > Joe > > > > From exim@www1.ietf.org Thu Jan 22 19:16:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21130 for ; Thu, 22 Jan 2004 19:16:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjozV-000601-Iq for l3vpn-archive@odin.ietf.org; Thu, 22 Jan 2004 19:16:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0N0G5gF023058 for l3vpn-archive@odin.ietf.org; Thu, 22 Jan 2004 19:16:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjozL-0005zJ-8c for l3vpn-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 19:16:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21110 for ; Thu, 22 Jan 2004 19:15:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjozE-0007nL-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 19:15:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajowj-0007i6-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 19:13:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajotv-0007d3-00 for l3vpn-web-archive@ietf.org; Thu, 22 Jan 2004 19:10:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajote-0005D9-Iz; Thu, 22 Jan 2004 19:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajot2-00058s-Dd for l3vpn@optimus.ietf.org; Thu, 22 Jan 2004 19:09:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21036 for ; Thu, 22 Jan 2004 19:09:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajosp-0007Yo-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 19:09:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjopM-0007WQ-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 19:05:37 -0500 Received: from smtp807.mail.sc5.yahoo.com ([66.163.168.186]) by ietf-mx with smtp (Exim 4.12) id 1Ajonz-0007SD-00 for l3vpn@ietf.org; Thu, 22 Jan 2004 19:04:11 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp807.mail.sc5.yahoo.com with SMTP; 23 Jan 2004 00:03:10 -0000 Message-ID: <00dc01c3e144$4a04a530$681067c0@adithya> From: "Mohan Parthasarathy" To: "Joe Touch" Cc: , "Ross Callon" , "Thomas Narten" References: <4.3.2.20040121153926.030be0a0@zircon.juniper.net> <006301c3e116$959c6290$681067c0@adithya> <40101CA9.3040701@isi.edu> <008901c3e11c$cd650730$681067c0@adithya> <40102551.8050405@isi.edu> <009301c3e125$7f5da930$681067c0@adithya> <40103211.90005@isi.edu> Subject: Re: draft-touch-ipsec-vpn-06.txt Date: Thu, 22 Jan 2004 16:03:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Joe, > >>>>>I see it as IPsec using > >>>>>the encapsulation scheme of RFC2003 which is what tunnel mode SA > >>>>>does anyway. > >>>> > >>>>Tunnel-mode SAs aren't routable interfaces necessarily. > >>> > >>> > >>>Again, i thought we are discussing about alternative 1. > >> > >>Again, the "necessarily" part is important. > >> > >>The issue is that 2401bis would have to force an implementation, which > >>neither 2401 nor 2401bis do (or should, IMO). > > > > I am a bit confused. We are comparing IIPtran with Alternative 1. > > Alternative 1 needs some clarifications in rfc2401 about tunnel mode SAs > > and so does IIPtran. > > Alternative 1 requires 2401bis specify an implementation, which it is > not likely to do (and largely inappropriate as well). > > IIPtran requres 2401bis permit transport mode between gateways - which > it already does, and is a protocol specification issue. > But section 4.2.4 points out the inter-op problem also with IIPtran which alternative 1 does not have. My point is alternative 1 is not inferior on technical grounds. It is as good as IIPtran. The only problem i can see is its dependency on rfc2401. IIPtran may not have this dependency but you can have problems negotiating a transport mode SA if the other end thinks that it is tunnel mode. > >>>>>There is also another difference. If you use IIPtran, you have > >>>>>to use the destination address to infer the VPN the packet belongs to. > >>>>>This means, you have to have one address per VPN for the box. If you > >>>>>support multiple VPNs, then this is a disadvantage. In the > >>>>>case of modelling ipsec tunnel mode SA as an interface, you can just use > >>>>>the SPI alone (which is allocated unique for the box) for finding out the > >>>>>VPN. You just need one address for the whole box which really is > >>>>>a big advantage. Is that right ? > >>>>> > >>>>>-mohan > >>>> > >>>>IIPtran uses the address to demux, not the SPI. This means that the > >>>>virtual network is _independent_ of whether IPsec is used or not. > >>>> > >>>>Dynamic routing is based on addresses; there are emerging standards for > >>>>how to augment those addresses with IDs outside the SPI space (e.g., VPN > >>>>IDs) which would allow reuse of addresses that touchdown at the same > >>>>node - regardless of whether IPsec is used or not. > >>> > >>>In the forwarding plane, when a packet enters IP, you still need something in > >>>the IP header or following it, to differentiate the multiple VPNs. Are you > >>>saying that there might be a different header with the packet that would > >>>allow you to differentiate the multiple VPNs ? > >> > >>Either the IP address (which is what we do) or a VPN-ID in an inner > >>header or option allows that. Overloading the SPI for that has numerous > >>complications. > > > > I don't know what complications you refer to. Using IIPtran in this scenario > > is not easy. You have to pre-setup all the IP-IP interfaces, one for each > > VPN. In Alternative 1, IKE can be used to dynamically plumb these > > interfaces. > > That's all static. The dynamic routing protocols need to be modified to > exchange SPIs now, to resolve different VPNs that reuse addresses. The > alternative is to use routing-specific information - IP addresses or VPN > IDs - instead. > Why do you have to exchange SPIs ? IKE would exchange SPIs and the ID payload would carry VPN-IDs, one per VPN. Dynamic routing protocols when receiving packets know exactly which VR the packet belongs to (ip stack would initialize the VR and an extra socket option to retrieve it) and hence which FIB to associate the routes to. -mohan > Joe From exim@www1.ietf.org Fri Jan 23 00:24:12 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29511 for ; Fri, 23 Jan 2004 00:24:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajtn9-00086F-MN for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 00:23:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0N5NdqW031129 for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 00:23:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajtn9-000860-HM for l3vpn-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 00:23:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29482 for ; Fri, 23 Jan 2004 00:23:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajtn2-0003e3-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 00:23:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajtjt-0003YS-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 00:20:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajti2-0003TA-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 00:18:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajthh-0007oY-EZ; Fri, 23 Jan 2004 00:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjthY-0007oA-KL for l3vpn@optimus.ietf.org; Fri, 23 Jan 2004 00:17:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29383 for ; Fri, 23 Jan 2004 00:17:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjthR-0003Se-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 00:17:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjteU-0003OW-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 00:14:43 -0500 Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx with esmtp (Exim 4.12) id 1Ajtcb-0003IX-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 00:12:45 -0500 Received: from MDUFFY1.quarrytech.com (rocket.quarrytech.com [10.1.1.127]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XT41A53Z; Fri, 23 Jan 2004 00:11:50 -0500 Message-Id: <5.2.0.9.0.20040122200853.021a90e0@email> X-Sender: mduffy@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 23 Jan 2004 00:10:19 -0500 To: Ross Callon , l3vpn@ietf.org From: Mark Duffy Subject: Re: draft-touch-ipsec-vpn-06.txt Cc: Thomas Narten In-Reply-To: <4.3.2.20040121153926.030be0a0@zircon.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > - Does the l3vpn working group feel that this document should be >reviewed by a public working group, such as the l3vpn working group, >prior to publication? I would think that should be more a matter of ietf policy regarding personal submission RFCs than what any wg thinks. Unless the policy is to ask relevant wg's :-) > - Do we have any technical comments on the document? The basic concept of forming virtual links by first applying IP-in-IP tunnelling, then securing them by applying transport mode IPsec to the resulting packets seems a good one to me. (And it is already embodied in at least one document that is a product of this wg.) As an aside, I would be quite interested for the working group to take on the effort to progress a *standard* for virtual links. It should go a step further and provide a way to convey to the far end what vpn context a given tunnel is for. Those deeply interested in this subject might want to look at which provides a survey of issues in this space and of potential solutions. Anyway, back to draft-touch. I think the basic approach presented is sound and appropriate. I do think the message gets a little lost in all the description of other possible approaches and why they don't work. I found those descriptions difficult to follow. The draft expresses an interpretation of RFC 2401 that I believe is excessively rigid and literal. E.g. in concluding that transport mode may not be used between two gateways, and that protocol #4 encapsulations must be skipped past in evaluating SPD policy to look for a transport header deeper in the packet. The draft on page 7 states: There are two common implementation scenarios for tunnel mode SAs: One is based on firewall-like packet matching operations where tunnel mode SAs are not virtual interfaces, another is tunnel-based, and treats a tunnel mode SA as a virtual interface. The current IPsec architecture does not mandate one or the other. This is completely outside my understanding of RFC 2401. 2401 is completely oriented towards the policy based approach. I am unaware that it provides in any way for treating a tunnel mode SA as a virtual interface. In fact it does much to obstruct that viz. SPD policy and packet selectors. Nit: the link numbers on figure 3 do not seem to match some references to them in the preceding paragraphs. Previous revisions of this document contained the concept that if one sends an IKE proposal for transport mode protection for protocol #4, then one is signalling the intent that the tunnel is to be considered a virtual link. Perhaps that has been removed because offhand I cannot find it. I thought that was undesirable because it imposes a new meaning onto a possibly pre-existing behavior, and it is implicit rather than explicit. Regards, Mark From exim@www1.ietf.org Fri Jan 23 03:34:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18610 for ; Fri, 23 Jan 2004 03:34:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjwlQ-0002lp-Jt for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 03:34:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0N8Y46J010640 for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 03:34:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjwlP-0002lV-Du for l3vpn-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 03:34:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18550 for ; Fri, 23 Jan 2004 03:34:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjwlN-0004eb-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 03:34:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjwkR-0004Vt-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 03:33:03 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AjwjQ-00049D-03 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 03:32:00 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AjwSh-0008Rg-0f for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 03:14:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjwS1-0001IL-52; Fri, 23 Jan 2004 03:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjwRH-0001G0-F0 for l3vpn@optimus.ietf.org; Fri, 23 Jan 2004 03:13:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17992 for ; Fri, 23 Jan 2004 03:13:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjwR0-0003tA-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 03:12:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjwP9-0003pL-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 03:11:04 -0500 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AjwMs-0003kL-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 03:08:42 -0500 Received: from netlab.nec.de (tokyo.netlab.nec.de [195.37.70.2]) by ftp.ccrle.nec.de (Postfix) with ESMTP id 5F0F1F5A9; Fri, 23 Jan 2004 09:12:57 +0100 (CET) Message-ID: <4010D66D.20300@netlab.nec.de> Date: Fri, 23 Jan 2004 09:08:13 +0100 From: Lars Eggert Organization: NEC Network Laboratories User-Agent: Mozilla Thunderbird 0.5a (Macintosh/20040120) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy Cc: Joe Touch , l3vpn@ietf.org, Ross Callon , Thomas Narten Subject: Re: draft-touch-ipsec-vpn-06.txt References: <4.3.2.20040121153926.030be0a0@zircon.juniper.net> <006301c3e116$959c6290$681067c0@adithya> <40101CA9.3040701@isi.edu> <008901c3e11c$cd650730$681067c0@adithya> <40102551.8050405@isi.edu> <009301c3e125$7f5da930$681067c0@adithya> <40103211.90005@isi.edu> <00dc01c3e144$4a04a530$681067c0@adithya> In-Reply-To: <00dc01c3e144$4a04a530$681067c0@adithya> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070008060908050601040001" Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms070008060908050601040001 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mohan, sorry for jumping in so late - time zones. Mohan Parthasarathy wrote: > My point is alternative 1 is not inferior on technical grounds. It is > as good as IIPtran. The only problem i can see is its dependency on > rfc2401. IIPtran may not have this dependency but you can have > problems negotiating a transport mode SA if the other end thinks that > it is tunnel mode. The issue with alternative 1 is that nothing in 2401 (or 2401bis, for that matter) mandates it. As others have pointed out, implementations are free to provide the neccessary IP encapsulation for tunnel mode SAs without representing this imiplicit tunnel in the forwarding tables. (See section 4.2.1) Now consider a virtual multi-hop topology, where some nodes implement alternative 1 and others do not. A dynamic routing protocol running over such a virtual topology will fail to exchange routes with the peers that do not implement alternative 1, as there are no interfaces to broadcast or multicast routing information over. (Unless these nodes implement alternative 3, where routing protocol implementation have to explicitly become IPsec-aware.) Lars -- Lars Eggert NEC Network Laboratories --------------ms070008060908050601040001 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNaMIICw6ADAgECAgMLU6IwDQYJKoZIhvcNAQEE BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTAz MTIxNTEyMzEyOFoXDTA0MTIxNDEyMzEyOFowgYQxDzANBgNVBAQTBkVnZ2VydDENMAsGA1UE KhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdn ZXJ0QG5ldGxhYi5uZWMuZGUxIjAgBgkqhkiG9w0BCQEWE2xhcnMuZWdnZXJ0QGdteC5uZXQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWps58Zq8Buu2DKDl9crbvzSo6zWsZ TkQLr5zOTqUMs/eU7Mcohv64O4IxWWYGLfYsjDRxUlmdHdJUbyTtUh2lH452DUDJByXidlLm RDgohG0AVwztedqy1+hE3VnCdpMhUGks+6ntrr3dKSxMgLM0AM1kPWsH9lWX6IOPdxOC30gM PiQ65zH9PR70befQLgFPKcAv0wP8210l05n8ekwYAcq2cm3/j+nuDu0HEh5pgsnY7cVELeNJ ODvr4IiE1t3c2w4+0Nc/WJrqGCMl+gZ8c+7FtzjoyDeEsCjNFDeA2ymNd+10O6kjwvPHlzPr 3rW73RDRPAjMJ49HXlueiuoNAgMBAAGjdzB1MCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5k ZYETbGFycy5lZ2dlcnRAZ214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AHgrv3SQFD4AS4lY4oKcI3iTHcclEHbYfg3UUb8zzCUsl+OJoz0nmebGmOL+tvNj5GvCrWnN H4LvVLh8ZBhFXms7eKJ1YiHgbKwTRK23P8Y5NDit5ico0ZjpFWeenUWj3ajEbN6n4K8dNp+C 0b2apnSrlFVWY6BucZFIYqQ1Lf91MIIDWjCCAsOgAwIBAgIDC1OiMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wMzEy MTUxMjMxMjhaFw0wNDEyMTQxMjMxMjhaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoT BExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2Vy dEBuZXRsYWIubmVjLmRlMSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1qbOfGavAbrtgyg5fXK2780qOs1rGU5E C6+czk6lDLP3lOzHKIb+uDuCMVlmBi32LIw0cVJZnR3SVG8k7VIdpR+Odg1AyQcl4nZS5kQ4 KIRtAFcM7XnastfoRN1ZwnaTIVBpLPup7a693SksTICzNADNZD1rB/ZVl+iDj3cTgt9IDD4k Oucx/T0e9G3n0C4BTynAL9MD/NtdJdOZ/HpMGAHKtnJt/4/p7g7tBxIeaYLJ2O3FRC3jSTg7 6+CIhNbd3NsOPtDXP1ia6hgjJfoGfHPuxbc46Mg3hLAozRQ3gNspjXftdDupI8Lzx5cz6961 u90Q0TwIzCePR15bnorqDQIDAQABo3cwdTAqBgUrZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVN eWZmQk5VYk5KSmNkWjJzMDkGA1UdEQQyMDCBGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGWB E2xhcnMuZWdnZXJ0QGdteC5uZXQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB4 K790kBQ+AEuJWOKCnCN4kx3HJRB22H4N1FG/M8wlLJfjiaM9J5nmxpji/rbzY+Rrwq1pzR+C 71S4fGQYRV5rO3iidWIh4GysE0Sttz/GOTQ4reYnKNGY6RVnnp1Fo92oxGzep+CvHTafgtG9 mqZ0q5RVVmOgbnGRSGKkNS3/dTGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwMTIzMDgwODEzWjAjBgkqhkiG 9w0BCQQxFgQU5XoA+5OZ0X/Ux+1K5Sp2tMh1LmQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwtTojB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwDQYJKoZIhvcNAQEBBQAEggEA n0cozt5BdgqYPHDPvkd/UQVxZ5TakpA3XgzexTQst22UMLa1bW1oGaAMVXRJQswBUgVGDyz6 N2gDev9oVTPsjZAn7cZXVRcCx9aFtzFP8XTYp7rK9eKA4NrHnlHONg+PZqt+L8PSs8bgoQpr XI9iRLpfOzIMz4cFTMT2g58wg3lrxuFsQdobuhW8LrAx0IZ1rR12nyGKXCkA8NWV4g1X3d4l PIahoWPVmHjxvMgAZ4jRnriCSlBfFh5VVq+MUH5t8fe/Ppg6ht8W6nCMhjDf3O7TvvHs0uS6 vAk/Wla398VhDxNGUc/vbiv1A5I4I1vRtdMjOQxKnZt3zxorjGQzXAAAAAAAAA== --------------ms070008060908050601040001-- From exim@www1.ietf.org Fri Jan 23 08:26:27 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29576 for ; Fri, 23 Jan 2004 08:26:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak1Jv-00039e-18 for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 08:25:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NDPwxV012122 for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 08:25:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak1Jp-00039P-TV for l3vpn-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 08:25:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29555 for ; Fri, 23 Jan 2004 08:25:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak1Jj-0005EP-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 08:25:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak1HH-00055T-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 08:23:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak1DO-0004wy-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 08:19:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak1DB-0002fp-91; Fri, 23 Jan 2004 08:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak1Ce-0002cU-Dx for l3vpn@optimus.ietf.org; Fri, 23 Jan 2004 08:18:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29454 for ; Fri, 23 Jan 2004 08:18:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak1CY-0004sq-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 08:18:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak17u-0004kR-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 08:13:35 -0500 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 1Ak15J-0004Ym-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 08:10:53 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0ND9RSE171104 for ; Fri, 23 Jan 2004 08:09:37 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-229-188.mts.ibm.com [9.65.229.188]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0ND9FC1153136 for ; Fri, 23 Jan 2004 06:09:16 -0700 Received: from cichlid.raleigh.ibm.com (narten@localhost) by cichlid.raleigh.ibm.com (8.11.6/8.9.3) with ESMTP id i0ND8wG10482 for ; Fri, 23 Jan 2004 08:08:58 -0500 Message-Id: <200401231308.i0ND8wG10482@cichlid.raleigh.ibm.com> To: l3vpn@ietf.org Subject: Re: draft-touch-ipsec-vpn-06.txt In-Reply-To: Message from rcallon@juniper.net of "Wed, 21 Jan 2004 15:53:02 EST." <4.3.2.20040121153926.030be0a0@zircon.juniper.net> Date: Fri, 23 Jan 2004 08:08:58 -0500 From: Thomas Narten Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 A few misc points on this discussion. 1) My understanding is that this document has been reviewed by the IPsec WG, and they are OK with it being published as an Informational (non-WG) document. The main question is whether the l3vpn WG feels similarly. 2) This document does relate to the l3vpn WG, hence it is appropriate for this WG to review the document and raise any issues it feels it has. However, the WG has a number of things it can say, including: - basically OK, no need to bring it into the WG formally, i.e., just go ahead and publish it as Joe has requested - OK, but here are some things that should be clarified/fixed (and then indicate what they are) - really conflicts with what we are doing and shouldn't be published until some of our other documents are completed (but so far, I don't sense that folk are saying that) - technically flawed, should not be published at all. (Again, I don't sense that folk are saying that) From a process perpsective, the RFC editor always asks the IESG if it is OK to publish an independent submission. This check is to ensure that the document isn't an end-run around an IETF effort (and in this case, I don't sense that it is, as the document's existance is hardly a secret to this or the ipsec WG). 3) Although the document may have been discussed in this WG before, what is at issue now is whether _this_ version of the document is OK to publish as an informational RFC at this time. Thomas From exim@www1.ietf.org Fri Jan 23 08:28:05 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29644 for ; Fri, 23 Jan 2004 08:28:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak1LV-0003FN-IZ for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 08:27:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NDRbMn012475 for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 08:27:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak1LV-0003F8-DS for l3vpn-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 08:27:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29632 for ; Fri, 23 Jan 2004 08:27:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak1LP-0005Gk-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 08:27:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak1Hk-00058A-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 08:23:46 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak1EV-0004zh-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 08:20:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak1EB-0002xk-Fr; Fri, 23 Jan 2004 08:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak1Dn-0002ud-TC for l3vpn@optimus.ietf.org; Fri, 23 Jan 2004 08:19:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29475 for ; Fri, 23 Jan 2004 08:19:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak1Dc-0004yH-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 08:19:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak1AV-0004oz-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 08:16:16 -0500 Received: from omrnat4.verisignmail.com ([216.168.230.163] helo=omr2.verisignmail.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak175-0004fT-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 08:12:43 -0500 Received: from ms7.verisignmail.com (IDENT:mirapoint@[216.168.230.174]) by omr2.verisignmail.com (8.12.10/8.12.10) with ESMTP id i0ND8UXR021699; Fri, 23 Jan 2004 08:08:30 -0500 (EST) Received: from aldebaran (h00a0ccd1a9ec.ne.client2.attbi.com [24.61.193.83]) by ms7.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with SMTP id BAS44000; Fri, 23 Jan 2004 08:12:12 -0500 (EST) From: "Eric Gray" To: , "Ross Callon" Cc: , "Thomas Narten" Subject: RE: draft-touch-ipsec-vpn-06.txt Date: Fri, 23 Jan 2004 08:05:39 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <200401221527.i0MFRb5g013225@rtp-core-2.cisco.com> Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit What he said. -----Original Message----- From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org]On Behalf Of Eric Rosen Sent: Thursday, January 22, 2004 10:28 AM To: Ross Callon Cc: l3vpn@ietf.org; Thomas Narten Subject: Re: draft-touch-ipsec-vpn-06.txt I think it would be useful to have an RFC which discusses the issues that arise when you want to use an IPsec Security Association as a routing adjacency. In fact, it might even be useful to have a standard way of doing this that would ensure multi-vendor interoperability. As Claudio points out, implementors do know how to do this, and there have been many products on the market for years that do this. Whether they do it in an interoperable manner is another question. Whether this is in violation of the IPsec standard is a further question. I'd have thought that a draft on this topic, even an informational draft, would need the approval of the IPsec WG. I am concerned about the fact that the IPsec WG has failed to progress this draft. Given that there are many deployed products that do routing over IPsec, I'd think an informational draft on the topic would benefit from making it clearer what the existing practices and what the interoperability issues are. With regard to the draft's relation to L3VPN, the L3VPN charter does unfortunately include "CE-based VPNs using IPsec". Unless this is removed from the charter (which would be a good thing imho), I think it would be odd for an individual draft on the topic to be published. From exim@www1.ietf.org Fri Jan 23 08:38:10 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00185 for ; Fri, 23 Jan 2004 08:38:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak1VF-0004dj-OM for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 08:37:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NDbfsx017827 for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 08:37:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak1VE-0004cf-RF for l3vpn-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 08:37:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00164 for ; Fri, 23 Jan 2004 08:37:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak1VD-0005pk-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 08:37:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak1UR-0005oP-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 08:36:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak1Te-0005lf-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 08:36:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak1Td-0004CH-8m; Fri, 23 Jan 2004 08:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak1Sh-0003lC-Sc for l3vpn@optimus.ietf.org; Fri, 23 Jan 2004 08:35:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29960 for ; Fri, 23 Jan 2004 08:35:01 -0500 (EST) From: jeremy.de_clercq@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak1Sg-0005fq-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 08:35:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak1S0-0005bW-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 08:34:21 -0500 Received: from colt-na165.alcatel.fr ([62.23.212.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1Ak1Qi-0005Ux-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 08:33:00 -0500 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i0NDWUgk003481; Fri, 23 Jan 2004 14:32:32 +0100 Received: from alcatel.be ([138.203.67.106]) by bemail04.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004012314322916:4942 ; Fri, 23 Jan 2004 14:32:29 +0100 Message-ID: <4011226C.80006@alcatel.be> Date: Fri, 23 Jan 2004 14:32:28 +0100 Organization: Alcatel User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Narten CC: l3vpn@ietf.org Subject: Re: draft-touch-ipsec-vpn-06.txt References: <200401231308.i0ND8wG10482@cichlid.raleigh.ibm.com> In-Reply-To: <200401231308.i0ND8wG10482@cichlid.raleigh.ibm.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 01/23/2004 14:32:29, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 01/23/2004 14:32:31, Serialize complete at 01/23/2004 14:32:31 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit the following is my opinion: > - basically OK, no need to bring it into the WG formally, i.e., > just go ahead and publish it as Joe has requested Jeremy. From exim@www1.ietf.org Fri Jan 23 09:25:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02046 for ; Fri, 23 Jan 2004 09:25:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak2F7-0007pt-2g for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 09:25:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NEP5EA030110 for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 09:25:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak2F6-0007pM-NQ for l3vpn-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 09:25:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02035 for ; Fri, 23 Jan 2004 09:25:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak2F4-0000Hy-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 09:25:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak2E1-00005Y-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 09:23:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak2CB-0007aF-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 09:22:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak2C9-0007YB-4N; Fri, 23 Jan 2004 09:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak2Bn-0007Xf-VP for l3vpn@optimus.ietf.org; Fri, 23 Jan 2004 09:21:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01604 for ; Fri, 23 Jan 2004 09:21:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak2Bm-0007W5-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 09:21:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak2Av-0007UT-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 09:20:45 -0500 Received: from [142.46.197.162] (helo=pion-smtp.jnpr.net) by ietf-mx with esmtp (Exim 4.12) id 1Ak2A1-0007RQ-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 09:19:49 -0500 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: draft-touch-ipsec-vpn-06.txt X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Fri, 23 Jan 2004 09:19:16 -0500 Message-ID: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DADA@pion.jnpr.net> Thread-Topic: draft-touch-ipsec-vpn-06.txt Thread-Index: AcPhs8UmDxNkQVYiRvGQKFci1rfayAAA5O9g From: "Claudio Lordello" To: "Thomas Narten" , Cc: "Claudio Lordello" Content-Transfer-Encoding: quoted-printable Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > 2) This document does relate to the l3vpn WG, hence it is appropriate > for this WG to review the document and raise any issues it feels it > has. However, the WG has a number of things it can say, including: >=20 > - basically OK, no need to bring it into the WG formally, i.e., > just go ahead and publish it as Joe has requested > - OK, but here are some things that should be clarified/fixed (and > then indicate what they are) > - really conflicts with what we are doing and shouldn't be > published until some of our other documents are completed (but > so far, I don't sense that folk are saying that)=20 > - technically flawed, should not be published at all. (Again, I > don't sense that folk are saying that) My comments to this draft fall under the second bullet above. The issues = that I believe need to be fixed are related to the stated "problems" = with routing over IPsec tunnels. I believe the stated problems are the = result of a given implementation and are not shared by all = implementations of IPsec tunnels. As an example, I quote the first = paragraph on the Abstract section: "It describes how virtual links established by IPsec tunnel mode conflict with routing and forwarding inside the VN, due to the IP routing dependence on references to interfaces and next-hop IP addresses." As an implementor who has developed an IPsec implementation which allows = routing over IPsec tunnels without the issues described on the draft, I = have to disagree with such an statement. For the record, I have no problem with the draft's proposed "IP tunnel + = IPsec-transport" approach. It is a viable approach to the problem, as it = is a pure "IPsec tunnel", or yet, a "GRE tunnel + IPsec-transport" which = does not get mentioned in the draft but has been available for a while = from some vendors. Claudio. From exim@www1.ietf.org Fri Jan 23 09:42:11 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02699 for ; Fri, 23 Jan 2004 09:42:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak2VE-0000eM-3Q for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 09:41:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NEfiE4002492 for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 09:41:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak2VD-0000e7-TX for l3vpn-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 09:41:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02693 for ; Fri, 23 Jan 2004 09:41:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak2VC-00016e-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 09:41:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak2UI-000153-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 09:40:46 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak2Te-00013Z-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 09:40:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak2Td-0000Xd-Av; Fri, 23 Jan 2004 09:40:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak2TS-0000Wg-56 for l3vpn@optimus.ietf.org; Fri, 23 Jan 2004 09:39:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02654 for ; Fri, 23 Jan 2004 09:39:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak2TQ-00012y-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 09:39:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak2SV-00010T-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 09:38:56 -0500 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1Ak2Ri-0000xa-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 09:38:06 -0500 Received: from netlab.nec.de (tokyo.netlab.nec.de [195.37.70.2]) by ftp.ccrle.nec.de (Postfix) with ESMTP id 9B8FAF5A9; Fri, 23 Jan 2004 15:42:44 +0100 (CET) Message-ID: <401131C8.8070308@netlab.nec.de> Date: Fri, 23 Jan 2004 15:38:00 +0100 From: Lars Eggert Organization: NEC Network Laboratories User-Agent: Mozilla Thunderbird 0.5a (Macintosh/20040120) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Claudio Lordello Cc: Thomas Narten , l3vpn@ietf.org Subject: Re: draft-touch-ipsec-vpn-06.txt References: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DADA@pion.jnpr.net> In-Reply-To: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DADA@pion.jnpr.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010909000000070302080305" Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms010909000000070302080305 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Claudio, Claudio Lordello wrote: > My comments to this draft fall under the second bullet above. The > issues that I believe need to be fixed are related to the stated > "problems" with routing over IPsec tunnels. I believe the stated > problems are the result of a given implementation and are not shared > by all implementations of IPsec tunnels. As an example, I quote the > first paragraph on the Abstract section: > > "It describes how virtual links established by IPsec tunnel mode > conflict with routing and forwarding inside the VN, due to the IP > routing dependence on references to interfaces and next-hop IP > addresses." > > As an implementor who has developed an IPsec implementation which > allows routing over IPsec tunnels without the issues described on the > draft, I have to disagree with such an statement. I agree that routing can work over a topology built from IPsec tunnel mode SAs, and we list several alternative approaches in the ID. Our point is that 2401 (and 2401bis, if I read it correctly) is underspecified in this regard - a compliant implementation will not neccessarily support dynamic routing over tunnel mode SAs. What our draft proposes is another method for constructing a secure virtual topology out of IPIP tunnels and IPsec transport mode. Our alternative neccessarily supports dynamic routing due this composition. (And has the nice side effect of being much simpler, at least in my opinion, but that is beside the point here.) We suggest using this alternative approach, instead of complicating IPsec with further constraints that will establish dynamic routing functionality for tunnel mode on all implementations. As for the sentence you quoted, I agree that re-stating it may be useful. What do you think about this instead: "It describes how virtual links established by IPsec tunnel mode can conflict with routing and forwarding inside the VN, due to the IP routing dependence on references to interfaces and next-hop IP addresses." Lars -- Lars Eggert NEC Network Laboratories --------------ms010909000000070302080305 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNaMIICw6ADAgECAgMLU6IwDQYJKoZIhvcNAQEE BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTAz MTIxNTEyMzEyOFoXDTA0MTIxNDEyMzEyOFowgYQxDzANBgNVBAQTBkVnZ2VydDENMAsGA1UE KhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdn ZXJ0QG5ldGxhYi5uZWMuZGUxIjAgBgkqhkiG9w0BCQEWE2xhcnMuZWdnZXJ0QGdteC5uZXQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWps58Zq8Buu2DKDl9crbvzSo6zWsZ TkQLr5zOTqUMs/eU7Mcohv64O4IxWWYGLfYsjDRxUlmdHdJUbyTtUh2lH452DUDJByXidlLm RDgohG0AVwztedqy1+hE3VnCdpMhUGks+6ntrr3dKSxMgLM0AM1kPWsH9lWX6IOPdxOC30gM PiQ65zH9PR70befQLgFPKcAv0wP8210l05n8ekwYAcq2cm3/j+nuDu0HEh5pgsnY7cVELeNJ ODvr4IiE1t3c2w4+0Nc/WJrqGCMl+gZ8c+7FtzjoyDeEsCjNFDeA2ymNd+10O6kjwvPHlzPr 3rW73RDRPAjMJ49HXlueiuoNAgMBAAGjdzB1MCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5k ZYETbGFycy5lZ2dlcnRAZ214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AHgrv3SQFD4AS4lY4oKcI3iTHcclEHbYfg3UUb8zzCUsl+OJoz0nmebGmOL+tvNj5GvCrWnN H4LvVLh8ZBhFXms7eKJ1YiHgbKwTRK23P8Y5NDit5ico0ZjpFWeenUWj3ajEbN6n4K8dNp+C 0b2apnSrlFVWY6BucZFIYqQ1Lf91MIIDWjCCAsOgAwIBAgIDC1OiMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wMzEy MTUxMjMxMjhaFw0wNDEyMTQxMjMxMjhaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoT BExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2Vy dEBuZXRsYWIubmVjLmRlMSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1qbOfGavAbrtgyg5fXK2780qOs1rGU5E C6+czk6lDLP3lOzHKIb+uDuCMVlmBi32LIw0cVJZnR3SVG8k7VIdpR+Odg1AyQcl4nZS5kQ4 KIRtAFcM7XnastfoRN1ZwnaTIVBpLPup7a693SksTICzNADNZD1rB/ZVl+iDj3cTgt9IDD4k Oucx/T0e9G3n0C4BTynAL9MD/NtdJdOZ/HpMGAHKtnJt/4/p7g7tBxIeaYLJ2O3FRC3jSTg7 6+CIhNbd3NsOPtDXP1ia6hgjJfoGfHPuxbc46Mg3hLAozRQ3gNspjXftdDupI8Lzx5cz6961 u90Q0TwIzCePR15bnorqDQIDAQABo3cwdTAqBgUrZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVN eWZmQk5VYk5KSmNkWjJzMDkGA1UdEQQyMDCBGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGWB E2xhcnMuZWdnZXJ0QGdteC5uZXQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB4 K790kBQ+AEuJWOKCnCN4kx3HJRB22H4N1FG/M8wlLJfjiaM9J5nmxpji/rbzY+Rrwq1pzR+C 71S4fGQYRV5rO3iidWIh4GysE0Sttz/GOTQ4reYnKNGY6RVnnp1Fo92oxGzep+CvHTafgtG9 mqZ0q5RVVmOgbnGRSGKkNS3/dTGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwMTIzMTQzODAwWjAjBgkqhkiG 9w0BCQQxFgQUtNWMzaGAqFCnAV7XeBlvjChGPigwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwtTojB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwDQYJKoZIhvcNAQEBBQAEggEA dgyShtbqB5E9zWJcyu4F7NPcAigPECX8KrnNZQEpZn0qKoEOookhNyhr/8hWPO1O/iZC1jHx hkQzdnbfDSqENK2LQ0tHyxpBvT2x9J2B5NbCH509w4ZNY6SigHarfvUlMEsUt7tzLqiHl8bg 0AhupwO0V6yUFjNVaZtb+tzYSGJHaxdVVm1cH8AkgSNZyTpYbvzIC5vYnLSKs326d1DynSyu 21O1Z1hLdajxSKZMKbm15vt9yCK4JXeUwfNcmG5KXRngCVrND6jXrUaUsbn3qIluvErLzsYz h84w37Hbb8xUmwqUTo+tEUHj16jwlbEpnoT9y37SzkOC0mcow7tPxQAAAAAAAA== --------------ms010909000000070302080305-- From exim@www1.ietf.org Fri Jan 23 10:56:01 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06648 for ; Fri, 23 Jan 2004 10:56:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3eh-00035S-5T for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 10:55:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NFtZdZ011866 for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 10:55:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3eg-00035J-TF for l3vpn-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 10:55:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06584 for ; Fri, 23 Jan 2004 10:55:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3ee-00044g-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 10:55:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak3dE-0003tR-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 10:54:05 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak3cT-0003ow-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 10:53:18 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ak3WZ-0007Nd-LX for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 10:47:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3WP-0002WA-5S; Fri, 23 Jan 2004 10:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3WB-0002TG-Qg for l3vpn@optimus.ietf.org; Fri, 23 Jan 2004 10:46:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06227 for ; Fri, 23 Jan 2004 10:46:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3W9-0003bf-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 10:46:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak3VJ-0003aQ-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 10:45:53 -0500 Received: from [142.46.197.162] (helo=pion-smtp.jnpr.net) by ietf-mx with esmtp (Exim 4.12) id 1Ak3Uu-0003Xh-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 10:45:28 -0500 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: draft-touch-ipsec-vpn-06.txt X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Fri, 23 Jan 2004 10:44:51 -0500 Message-ID: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DADB@pion.jnpr.net> Thread-Topic: draft-touch-ipsec-vpn-06.txt Thread-Index: AcPhv5uEi8qDCDUgQW+IMRx2iMPNOQAAsFfg From: "Claudio Lordello" To: "Lars Eggert" Cc: "Thomas Narten" , Content-Transfer-Encoding: quoted-printable Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Lars Eggert wrote: > As for the sentence you quoted, I agree that re-stating it may be=20 > useful. What do you think about this instead: >=20 > "It describes how virtual links established by IPsec tunnel mode > can conflict with routing and forwarding inside the VN, due to the IP > routing dependence on references to interfaces and next-hop IP > addresses." >=20 The "can" does soften the statement a bit, but still leaves it unclear = as to when exactly tunnel mode does or does not conflict with routing. = If I understood correctly what you [the authors] are saying, would you = agree that the following correctly states your position: "While some = existing IPsec tunnel implementations have no problems with routing, its = specification does not mandate all implementations to behave that way. = As a consequence, other implementations will conflict with routing". If = it does, would you and give it some consideration. However, the text I quoted was just an example. The draft repeats = similar statements in other places, and those could also be reworded (or = perhaps even removed given that they have already been stated earlier, = but that's a different issue). Another example would be the second = paragraph on the "Introduction" section. There may be others too. Claudio. From exim@www1.ietf.org Fri Jan 23 12:04:20 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11486 for ; Fri, 23 Jan 2004 12:04:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4im-00029q-9o for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 12:03:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NH3q0r008293 for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 12:03:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4il-00029g-R1 for l3vpn-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 12:03:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11463 for ; Fri, 23 Jan 2004 12:03:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak4ik-0001y8-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 12:03:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak4hy-0001wE-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 12:03:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak4h2-0001td-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 12:02:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4gE-0001bW-Hn; Fri, 23 Jan 2004 12:01:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4fs-0001Po-KO for l3vpn@optimus.ietf.org; Fri, 23 Jan 2004 12:00:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11337 for ; Fri, 23 Jan 2004 12:00:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak4fr-0001p1-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 12:00:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak4ev-0001nC-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 11:59:53 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1Ak4eb-0001lA-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 11:59:33 -0500 Received: from isi.edu (143.sub-69-83-187.myvzw.com [69.83.187.143]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i0NGxHD28915; Fri, 23 Jan 2004 08:59:18 -0800 (PST) Message-ID: <401152E1.4080409@isi.edu> Date: Fri, 23 Jan 2004 08:59:13 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Narten CC: l3vpn@ietf.org Subject: Re: draft-touch-ipsec-vpn-06.txt References: <200401231308.i0ND8wG10482@cichlid.raleigh.ibm.com> In-Reply-To: <200401231308.i0ND8wG10482@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thomas Narten wrote: > A few misc points on this discussion. > > 1) My understanding is that this document has been reviewed by the > IPsec WG, and they are OK with it being published as an > Informational (non-WG) document. The main question is whether the > l3vpn WG feels similarly. > > 2) This document does relate to the l3vpn WG, hence it is appropriate > for this WG to review the document and raise any issues it feels it > has. However, the WG has a number of things it can say, including: > > - basically OK, no need to bring it into the WG formally, i.e., > just go ahead and publish it as Joe has requested > - OK, but here are some things that should be clarified/fixed (and > then indicate what they are) To date, the suggestions and clarifications requested focus on IPsec WG issues, which have already been thoroughly vetted in that WG. Since that WG has disbanded, and since this document has already been approved to proceed as per (1), modifications suggested should be limited to issues directly relating to this WG. Joe From exim@www1.ietf.org Fri Jan 23 12:19:13 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12236 for ; Fri, 23 Jan 2004 12:19:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4xC-0003pv-7T for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 12:18:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NHIkEM014741 for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 12:18:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4xC-0003pg-2k for l3vpn-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 12:18:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12189 for ; Fri, 23 Jan 2004 12:18:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak4xA-0002kd-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 12:18:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak4wE-0002iL-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 12:17:47 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak4vU-0002gx-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 12:17:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4vU-0003g3-Cp; Fri, 23 Jan 2004 12:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4vJ-0003fe-BO for l3vpn@optimus.ietf.org; Fri, 23 Jan 2004 12:16:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12091 for ; Fri, 23 Jan 2004 12:16:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak4vH-0002g4-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 12:16:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak4uS-0002eg-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 12:15:57 -0500 Received: from [142.46.197.162] (helo=pion-smtp.jnpr.net) by ietf-mx with esmtp (Exim 4.12) id 1Ak4tu-0002ap-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 12:15:22 -0500 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: draft-touch-ipsec-vpn-06.txt X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Fri, 23 Jan 2004 12:14:51 -0500 Message-ID: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DADD@pion.jnpr.net> Thread-Topic: draft-touch-ipsec-vpn-06.txt Thread-Index: AcPhHYwbmuWJHpX5Q3mawTQqRTFGCQArBECQ From: "Claudio Lordello" To: "Joe Touch" Cc: , "Ross Callon" Content-Transfer-Encoding: quoted-printable Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Joe Touch wrote: > It is - the specific recommendations are made as=20 > standards-track in 2401bis. >=20 Are you saying that 2401bis will "disallow" SG's from using tunnel mode = when routing is required?=20 > One of the ways isn't consistent with the use of a single SPD. >=20 Sorry but I do not understand how routing over an IPsec tunnel mode is = inconsistent with a single SPD, assuming that's what you are saying... > Second, it was perceived by the IPsec WG that tunnel selectors aren't > needed in the IP-over-IP case (a special case of L3VPNs).=20 > That issue was > also discussed in the IPsec WG a while ago. I certainly did miss the IPsec WG thread where tunnel selectors are = perceived as not needed. >=20 > Our doc (and the many previous WG discussions) addresses=20 > these issues,=20 > as well as others that have been raised in detail already. I am not concerned with "other" issues. I am concerned with statements = about IPsec tunnel mode being incompatible with routing. Your doc states = that as if it was a general IPsec problem, when I do not believe it is = the case. Claudio. From exim@www1.ietf.org Fri Jan 23 13:16:23 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14338 for ; Fri, 23 Jan 2004 13:16:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak5qX-0007lU-Gx for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 13:15:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NIFvm4029842 for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 13:15:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak5qX-0007lF-Cv for l3vpn-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 13:15:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14299 for ; Fri, 23 Jan 2004 13:15:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak5qV-0004wh-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 13:15:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak5pY-0004tC-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 13:14:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak5oi-0004py-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 13:14:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak5of-0007di-1K; Fri, 23 Jan 2004 13:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak5oQ-0007dG-OU for l3vpn@optimus.ietf.org; Fri, 23 Jan 2004 13:13:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14200 for ; Fri, 23 Jan 2004 13:13:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak5oO-0004nm-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 13:13:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak5nU-0004lZ-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 13:12:48 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1Ak5mb-0004jR-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 13:11:54 -0500 Received: from isi.edu (23.sub-69-83-170.myvzw.com [69.83.170.23]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i0NIBhD23125; Fri, 23 Jan 2004 10:11:44 -0800 (PST) Message-ID: <401163D5.5060802@isi.edu> Date: Fri, 23 Jan 2004 10:11:33 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Claudio Lordello CC: l3vpn@ietf.org, Ross Callon Subject: Re: draft-touch-ipsec-vpn-06.txt References: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DADD@pion.jnpr.net> In-Reply-To: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DADD@pion.jnpr.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Claudio Lordello wrote: > Joe Touch wrote: > >>It is - the specific recommendations are made as >>standards-track in 2401bis. > > Are you saying that 2401bis will "disallow" SG's from using tunnel mode when routing is required? Not explicitly - it specificially allows transport mode for otherwise tunneled traffic. >>One of the ways isn't consistent with the use of a single SPD. > > Sorry but I do not understand how routing over an IPsec tunnel mode > is inconsistent with a single SPD, assuming that's what you are saying... Please see the processing model diagram in 2401bis. The SPD processing happens before the forwarding step, very explicitly in this newer model. That means a tunnel-mode SA must be picked before dynamic routing comes into play. While there are ways to have (as with 2401) an implementation that is IPsec-2401bis compliant that handles dynamic routing using tunnel-mode SAs, it's not ensured. It is ensured that transport mode with non-IPsec tunnels will always accommodate dynamic routing. >>Second, it was perceived by the IPsec WG that tunnel selectors aren't >>needed in the IP-over-IP case (a special case of L3VPNs). >>That issue was >>also discussed in the IPsec WG a while ago. > > I certainly did miss the IPsec WG thread where tunnel selectors are perceived as not needed. > >>Our doc (and the many previous WG discussions) addresses >>these issues, >>as well as others that have been raised in detail already. > > > I am not concerned with "other" issues. I am concerned with > statements about IPsec tunnel mode being incompatible with routing. > Your doc states that as if it was a general IPsec problem, when I > do not believe it is the case. > > Claudio. The IPsec WG did, which is why this work was presented there several times. Joe From exim@www1.ietf.org Fri Jan 23 13:20:22 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14718 for ; Fri, 23 Jan 2004 13:20:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak5uO-00086e-N3 for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 13:19:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NIJuJh031154 for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 13:19:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak5uO-00086P-I3 for l3vpn-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 13:19:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14671 for ; Fri, 23 Jan 2004 13:19:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak5uM-0005Fu-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 13:19:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak5tQ-0005BV-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 13:18:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak5sX-00056w-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 13:18:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak5sX-0007uK-QS; Fri, 23 Jan 2004 13:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak5re-0007qz-4X for l3vpn@optimus.ietf.org; Fri, 23 Jan 2004 13:17:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14440 for ; Fri, 23 Jan 2004 13:17:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak5rc-00052g-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 13:17:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak5qk-0004z0-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 13:16:11 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1Ak5py-0004us-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 13:15:22 -0500 Received: from isi.edu (23.sub-69-83-170.myvzw.com [69.83.170.23]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i0NIF5D26030; Fri, 23 Jan 2004 10:15:05 -0800 (PST) Message-ID: <401164A7.8000107@isi.edu> Date: Fri, 23 Jan 2004 10:15:03 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Duffy CC: Ross Callon , l3vpn@ietf.org, Thomas Narten Subject: Re: draft-touch-ipsec-vpn-06.txt References: <5.2.0.9.0.20040122200853.021a90e0@email> In-Reply-To: <5.2.0.9.0.20040122200853.021a90e0@email> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mark Duffy wrote: > >> - Does the l3vpn working group feel that this document should be >> reviewed by a public working group, such as the l3vpn working group, >> prior to publication? > > > I would think that should be more a matter of ietf policy regarding > personal submission RFCs than what any wg thinks. Unless the policy is > to ask relevant wg's :-) 1) that's the policy 2) as I've stated, and as is available in the archives, we did as several WGs even before the IESG did. >> - Do we have any technical comments on the document? > > > The basic concept of forming virtual links by first applying IP-in-IP > tunnelling, then securing them by applying transport mode IPsec to the > resulting packets seems a good one to me. (And it is already embodied > in at least one document that is a product of this wg.) It was embodied in this draft in 3/2000, and described in normative publications of our project since 2000 as well. > As an aside, I would be quite interested for the working group to take > on the effort to progress a *standard* for virtual links. It should go > a step further and provide a way to convey to the far end what vpn > context a given tunnel is for. Those deeply interested in this subject > might want to look at > > which provides a survey of issues in this space and of potential solutions. > > Anyway, back to draft-touch. > > I think the basic approach presented is sound and appropriate. I do > think the message gets a little lost in all the description of other > possible approaches and why they don't work. I found those > descriptions difficult to follow. > > The draft expresses an interpretation of RFC 2401 that I believe is > excessively rigid and literal. E.g. in concluding that transport mode > may not be used between two gateways, and that protocol #4 > encapsulations must be skipped past in evaluating SPD policy to look for > a transport header deeper in the packet. Please review the IPsec WG mailing list archives on this issue. Rigidity is the defining characteristic of security specs (if not all specs, hopefully). > The draft on page 7 states: > There are two common implementation scenarios for tunnel mode SAs: > One is based on firewall-like packet matching operations where tunnel > mode SAs are not virtual interfaces, another is tunnel-based, and > treats a tunnel mode SA as a virtual interface. The current IPsec > architecture does not mandate one or the other. > This is completely outside my understanding of RFC 2401. 2401 is > completely oriented towards the policy based approach. I am unaware > that it provides in any way for treating a tunnel mode SA as a virtual > interface. In fact it does much to obstruct that viz. SPD policy and > packet selectors. 2401 cannot mandate only firewall-like (policy-based) approach; that would defeat BITW architectures, which are specifically supported. > Nit: the link numbers on figure 3 do not seem to match some references > to them in the preceding paragraphs. That has already been corrected in an update that is pending this final IESG review. > Previous revisions of this document contained the concept that if one > sends an IKE proposal for transport mode protection for protocol #4, > then one is signalling the intent that the tunnel is to be considered a > virtual link. Perhaps that has been removed because offhand I cannot > find it. I thought that was undesirable because it imposes a new > meaning onto a possibly pre-existing behavior, and it is implicit rather > than explicit. > > Regards, Mark That's in section 4.2.4 (IKE impact), and has been reviewed by the IPsec WG. Joe From exim@www1.ietf.org Fri Jan 23 13:20:24 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14735 for ; Fri, 23 Jan 2004 13:20:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak5uQ-00086w-2S for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 13:19:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NIJw17031172 for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 13:19:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak5uP-00086h-SB for l3vpn-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 13:19:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14675 for ; Fri, 23 Jan 2004 13:19:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak5uO-0005G7-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 13:19:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak5tR-0005Bf-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 13:18:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak5sX-00056x-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 13:18:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak5sY-0007uZ-Bu; Fri, 23 Jan 2004 13:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak5sI-0007tb-05 for l3vpn@optimus.ietf.org; Fri, 23 Jan 2004 13:17:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14484 for ; Fri, 23 Jan 2004 13:17:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak5sG-00054N-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 13:17:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak5rI-0004zd-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 13:16:44 -0500 Received: from smtp805.mail.sc5.yahoo.com ([66.163.168.184]) by ietf-mx with smtp (Exim 4.12) id 1Ak5qK-0004uu-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 13:15:44 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp805.mail.sc5.yahoo.com with SMTP; 23 Jan 2004 18:15:43 -0000 Message-ID: <004601c3e1dc$ec9135a0$681067c0@adithya> From: "Mohan Parthasarathy" To: "Lars Eggert" Cc: "Joe Touch" , , "Ross Callon" , "Thomas Narten" References: <4.3.2.20040121153926.030be0a0@zircon.juniper.net> <006301c3e116$959c6290$681067c0@adithya> <40101CA9.3040701@isi.edu> <008901c3e11c$cd650730$681067c0@adithya> <40102551.8050405@isi.edu> <009301c3e125$7f5da930$681067c0@adithya> <40103211.90005@isi.edu> <00dc01c3e144$4a04a530$681067c0@adithya> <4010D66D.20300@netlab.nec.de> Subject: Re: draft-touch-ipsec-vpn-06.txt Date: Fri, 23 Jan 2004 10:15:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Mohan, > > sorry for jumping in so late - time zones. > > Mohan Parthasarathy wrote: > > My point is alternative 1 is not inferior on technical grounds. It is > > as good as IIPtran. The only problem i can see is its dependency on > > rfc2401. IIPtran may not have this dependency but you can have > > problems negotiating a transport mode SA if the other end thinks that > > it is tunnel mode. > > The issue with alternative 1 is that nothing in 2401 (or 2401bis, for > that matter) mandates it. As others have pointed out, implementations > are free to provide the neccessary IP encapsulation for tunnel mode SAs > without representing this imiplicit tunnel in the forwarding tables. > (See section 4.2.1) > Agreed. Is this a good enough reason for going with IIPtran ? I see that this working group is already using IIPtran in one of the drafts. Would it be a good fit in other scenarios that this group is considering ? e.g., CE-based VPNs discusses both transport mode and tunnel mode and does not recommend one over the other. > Now consider a virtual multi-hop topology, where some nodes implement > alternative 1 and others do not. A dynamic routing protocol running over > such a virtual topology will fail to exchange routes with the peers that > do not implement alternative 1, as there are no interfaces to broadcast > or multicast routing information over. (Unless these nodes implement > alternative 3, where routing protocol implementation have to explicitly > become IPsec-aware.) > I just did a quick read of the Mark Duffy's document that he posted in the other mail. It does seem to point out the pros and cons of the various alternatives very well.Though i do not disagree with the IIPtran approach (which i have implemented in the past), the pros and cons are not evaluated against a standard set of requirements in this draft. -mohan > Lars > -- > Lars Eggert NEC Network Laboratories > From exim@www1.ietf.org Fri Jan 23 13:25:20 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14937 for ; Fri, 23 Jan 2004 13:25:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak5zB-0008Tk-V6 for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 13:24:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NIOr9S032586 for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 13:24:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak5zB-0008TV-Or for l3vpn-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 13:24:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14930 for ; Fri, 23 Jan 2004 13:24:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak5z9-0005bR-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 13:24:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak5yC-0005Yc-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 13:23:53 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak5xO-0005V5-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 13:23:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak5xN-0008Ge-Jf; Fri, 23 Jan 2004 13:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak5wY-0008DJ-J2 for l3vpn@optimus.ietf.org; Fri, 23 Jan 2004 13:22:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14828 for ; Fri, 23 Jan 2004 13:22:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak5wW-0005RW-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 13:22:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak5vY-0005N2-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 13:21:09 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1Ak5us-0005It-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 13:20:26 -0500 Received: from isi.edu (23.sub-69-83-170.myvzw.com [69.83.170.23]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i0NIKHD00213; Fri, 23 Jan 2004 10:20:18 -0800 (PST) Message-ID: <401165DB.5060900@isi.edu> Date: Fri, 23 Jan 2004 10:20:11 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy CC: Lars Eggert , l3vpn@ietf.org, Ross Callon , Thomas Narten Subject: Re: draft-touch-ipsec-vpn-06.txt References: <4.3.2.20040121153926.030be0a0@zircon.juniper.net> <006301c3e116$959c6290$681067c0@adithya> <40101CA9.3040701@isi.edu> <008901c3e11c$cd650730$681067c0@adithya> <40102551.8050405@isi.edu> <009301c3e125$7f5da930$681067c0@adithya> <40103211.90005@isi.edu> <00dc01c3e144$4a04a530$681067c0@adithya> <4010D66D.20300@netlab.nec.de> <004601c3e1dc$ec9135a0$681067c0@adithya> In-Reply-To: <004601c3e1dc$ec9135a0$681067c0@adithya> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mohan Parthasarathy wrote: > > > >>Mohan, >> >>sorry for jumping in so late - time zones. >> >>Mohan Parthasarathy wrote: >> >>>My point is alternative 1 is not inferior on technical grounds. It is >>>as good as IIPtran. The only problem i can see is its dependency on >>>rfc2401. IIPtran may not have this dependency but you can have >>>problems negotiating a transport mode SA if the other end thinks that >>>it is tunnel mode. >> >>The issue with alternative 1 is that nothing in 2401 (or 2401bis, for >>that matter) mandates it. As others have pointed out, implementations >>are free to provide the neccessary IP encapsulation for tunnel mode SAs >>without representing this imiplicit tunnel in the forwarding tables. >>(See section 4.2.1) >> > > Agreed. Is this a good enough reason for going with IIPtran ? I see that > this working group is already using IIPtran in one of the drafts. Would it > be a good fit in other scenarios that this group is considering ? e.g., CE-based > VPNs discusses both transport mode and tunnel mode and does not > recommend one over the other. That might be an interesting issue to discuss in Knight's draft (or a derivative thereof, as he mentioned). >>Now consider a virtual multi-hop topology, where some nodes implement >>alternative 1 and others do not. A dynamic routing protocol running over >>such a virtual topology will fail to exchange routes with the peers that >>do not implement alternative 1, as there are no interfaces to broadcast >>or multicast routing information over. (Unless these nodes implement >>alternative 3, where routing protocol implementation have to explicitly >>become IPsec-aware.) > > I just did a quick read of the Mark Duffy's document that he posted in the > other mail. It does seem to point out the pros and cons of the various > alternatives very well. Though i do not disagree with the IIPtran approach > (which i have implemented in the past), the pros and cons are not > evaluated against a standard set of requirements in this draft. > > -mohan The requirements are implicit - compliance with 2401 or interpretation thereof (e.g., that transport mode is OK between gateways because non-IPsec traffic is sourced/sunk at the gateways themselves - as clarified as allowable in 2401bis), and supporting dynamic routing. Joe From exim@www1.ietf.org Fri Jan 23 13:29:19 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15099 for ; Fri, 23 Jan 2004 13:29:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak633-0000Cq-DR for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 13:28:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NISrsq000782 for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 13:28:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak633-0000CX-2p for l3vpn-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 13:28:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15084 for ; Fri, 23 Jan 2004 13:28:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak631-0005ll-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 13:28:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak624-0005k0-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 13:27:53 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak61F-0005i2-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 13:27:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak61F-00005w-JL; Fri, 23 Jan 2004 13:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak615-00005C-V2 for l3vpn@optimus.ietf.org; Fri, 23 Jan 2004 13:26:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15028 for ; Fri, 23 Jan 2004 13:26:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak613-0005h3-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 13:26:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak60C-0005ex-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 13:25:57 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1Ak5zV-0005co-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 13:25:13 -0500 Received: from isi.edu (23.sub-69-83-170.myvzw.com [69.83.170.23]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i0NIP3D06797; Fri, 23 Jan 2004 10:25:04 -0800 (PST) Message-ID: <401166FA.1030807@isi.edu> Date: Fri, 23 Jan 2004 10:24:58 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy CC: l3vpn@ietf.org, Ross Callon , Thomas Narten Subject: Re: draft-touch-ipsec-vpn-06.txt References: <4.3.2.20040121153926.030be0a0@zircon.juniper.net> <006301c3e116$959c6290$681067c0@adithya> <40101CA9.3040701@isi.edu> <008901c3e11c$cd650730$681067c0@adithya> <40102551.8050405@isi.edu> <009301c3e125$7f5da930$681067c0@adithya> <40103211.90005@isi.edu> <00dc01c3e144$4a04a530$681067c0@adithya> In-Reply-To: <00dc01c3e144$4a04a530$681067c0@adithya> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mohan Parthasarathy wrote: > Joe, > > >>>>>>>I see it as IPsec using >>>>>>>the encapsulation scheme of RFC2003 which is what tunnel mode SA >>>>>>>does anyway. >>>>>> >>>>>>Tunnel-mode SAs aren't routable interfaces necessarily. >>>>> >>>>> >>>>>Again, i thought we are discussing about alternative 1. >>>> >>>>Again, the "necessarily" part is important. >>>> >>>>The issue is that 2401bis would have to force an implementation, which >>>>neither 2401 nor 2401bis do (or should, IMO). >>> >>>I am a bit confused. We are comparing IIPtran with Alternative 1. >>>Alternative 1 needs some clarifications in rfc2401 about tunnel mode SAs >>>and so does IIPtran. >> >>Alternative 1 requires 2401bis specify an implementation, which it is >>not likely to do (and largely inappropriate as well). >> >>IIPtran requres 2401bis permit transport mode between gateways - which >>it already does, and is a protocol specification issue. > > But section 4.2.4 points out the inter-op problem also with IIPtran which > alternative 1 does not have. With the caveat that this part of the thread is focusing on issues that focus on IPsec issues that the IPsec WG has already reviewed...(the thread below on VPN-IDs is more L3VPN-specific). IIPtran works with IKE fine (IKE to setup transport associations). The interop problem is that IKE is setting up the tunnel too - and it's not designed to setup IIPtran tunnels. It could easily be extended to do that. The tricks are for mixed-mode IKE negotiation - i.e., using modified IKE on an IIPtran node to trick a non-modified IKE to setup the receive side of the tunnel correctly. That's not at all required - it's discussed for completeness. > My point is alternative 1 is not inferior on technical grounds. That depends on 'technical grounds'. Needing a protocol spec to indicate the implementation details is (IMO) a technical flaw. > It is as good as IIPtran. > The only problem i can see is its dependency on rfc2401. Actually, that it depends on modifying 2401 to include implementation details; 2401 alone (as-is) is insufficient - exactly because it is ambiguous in this regard. > IIPtran may not have this > dependency but you can have problems negotiating a transport mode SA if the > other end thinks that it is tunnel mode. There is no trouble negotiating a transport mode SA over a tunnel configured using a separate (e.g., tunnel configuration) protocol. The issues raised in 4.2.4 are tricks to enable tunnel-mode receivers to accept IIPtran packets - mixed mode, which (although it works, albeit with IKE trickery) is not required. >>>>>>>There is also another difference. If you use IIPtran, you have >>>>>>>to use the destination address to infer the VPN the packet belongs to. >>>>>>>This means, you have to have one address per VPN for the box. If you >>>>>>>support multiple VPNs, then this is a disadvantage. In the >>>>>>>case of modelling ipsec tunnel mode SA as an interface, you can just use >>>>>>>the SPI alone (which is allocated unique for the box) for finding out the >>>>>>>VPN. You just need one address for the whole box which really is >>>>>>>a big advantage. Is that right ? >>>>>>> >>>>>>>-mohan >>>>>> >>>>>>IIPtran uses the address to demux, not the SPI. This means that the >>>>>>virtual network is _independent_ of whether IPsec is used or not. >>>>>> >>>>>>Dynamic routing is based on addresses; there are emerging standards for >>>>>>how to augment those addresses with IDs outside the SPI space (e.g., VPN >>>>>>IDs) which would allow reuse of addresses that touchdown at the same >>>>>>node - regardless of whether IPsec is used or not. >>>>> >>>>>In the forwarding plane, when a packet enters IP, you still need something in >>>>>the IP header or following it, to differentiate the multiple VPNs. Are you >>>>>saying that there might be a different header with the packet that would >>>>>allow you to differentiate the multiple VPNs ? >>>> >>>>Either the IP address (which is what we do) or a VPN-ID in an inner >>>>header or option allows that. Overloading the SPI for that has numerous >>>>complications. >>> >>>I don't know what complications you refer to. Using IIPtran in this scenario >>>is not easy. You have to pre-setup all the IP-IP interfaces, one for each >>>VPN. In Alternative 1, IKE can be used to dynamically plumb these >>>interfaces. >> >>That's all static. The dynamic routing protocols need to be modified to >>exchange SPIs now, to resolve different VPNs that reuse addresses. The >>alternative is to use routing-specific information - IP addresses or VPN >>IDs - instead. > > Why do you have to exchange SPIs ? For some routing protocols - to advertise 10.0.0.1/spi#3 as having a different routing metric than 10.0.0.1/spi#4. If a VPN-ID were available (e.g., in the tunneling protocol), and used by the forwarding table, it might be exchanged by the routing protocol (e.g., in a VR) as well. In that case, the SPIs need not be exchanged, and are a moot point. VPN-IDs help, or you can backoff and use IP addresses that are (like the VPN-IDs) unique per-node. Discussions of the impact of VPN-IDs would be relevant to Knight's draft; our draft does not address L3VPNs directly. > IKE would exchange SPIs and the > ID payload would carry VPN-IDs, one per VPN. Dynamic routing protocols when > receiving packets know exactly which VR the packet belongs to (ip stack would > initialize the VR and an extra socket option to retrieve it) and hence > which FIB to associate the routes to. > > -mohan Given VPN-IDs and the proper forwarding implementation (VRs), I don't need the SPIs anymore. The VPN-ID tells me which VPN a packet belongs to. Using an IP address alone would be useful where VPN-IDs had not yet been implemented or supported in the forwarding tables. I.e., it's a back-off solution compatible with existing protocols. Again, these issues should be relevant to Knight's draft. Joe From exim@www1.ietf.org Fri Jan 23 13:38:27 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15490 for ; Fri, 23 Jan 2004 13:38:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak6Br-00010U-Kg for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 13:37:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NIbxVF003864 for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 13:37:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak6Br-00010F-FB for l3vpn-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 13:37:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15483 for ; Fri, 23 Jan 2004 13:37:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak6Bn-00066E-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 13:37:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak6Aq-000644-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 13:36:56 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak6A2-00061h-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 13:36:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak69x-0000Xo-NU; Fri, 23 Jan 2004 13:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak69r-0000W2-BX for l3vpn@optimus.ietf.org; Fri, 23 Jan 2004 13:35:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15405 for ; Fri, 23 Jan 2004 13:35:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak69m-00060M-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 13:35:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak68u-0005yY-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 13:34:56 -0500 Received: from [142.46.197.162] (helo=pion-smtp.jnpr.net) by ietf-mx with esmtp (Exim 4.12) id 1Ak67z-0005ub-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 13:34:00 -0500 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: draft-touch-ipsec-vpn-06.txt X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Fri, 23 Jan 2004 13:33:28 -0500 Message-ID: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DADF@pion.jnpr.net> Thread-Topic: draft-touch-ipsec-vpn-06.txt Thread-Index: AcPh3OOssvrAXJ1iQQ+s82LWVWGGQAAAeLFg From: "Claudio Lordello" To: "Joe Touch" Cc: , "Ross Callon" Content-Transfer-Encoding: quoted-printable Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Joe Touch wrote: > While there are ways to have (as with 2401) an implementation that is=20 > IPsec-2401bis compliant that handles dynamic routing using=20 > tunnel-mode=20 > SAs, it's not ensured. It is ensured that transport mode with=20 > non-IPsec=20 > tunnels will always accommodate dynamic routing. >=20 That's my point. So you agree that tunnel mode and routing are not = necessarily mutually exclusive, and yet your drafts states that in = several occasions. Claudio. From exim@www1.ietf.org Fri Jan 23 13:46:22 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15860 for ; Fri, 23 Jan 2004 13:46:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak6JW-0001zf-DP for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 13:45:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NIjsCv007662 for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 13:45:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak6JW-0001zV-8v for l3vpn-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 13:45:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15789 for ; Fri, 23 Jan 2004 13:45:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak6JU-0006Uz-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 13:45:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak6Ib-0006QF-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 13:44:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak6Hh-0006MB-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 13:44:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak6Hh-0001r1-Be; Fri, 23 Jan 2004 13:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak6Hf-0001qG-2Y for l3vpn@optimus.ietf.org; Fri, 23 Jan 2004 13:43:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15689 for ; Fri, 23 Jan 2004 13:43:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak6Hc-0006LJ-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 13:43:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak6Gj-0006Hn-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 13:43:02 -0500 Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak6G6-0006E2-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 13:42:22 -0500 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.169]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XT41A7C5; Fri, 23 Jan 2004 13:41:52 -0500 Message-Id: <5.2.0.9.0.20040123133222.02077408@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 23 Jan 2004 13:40:20 -0500 To: Joe Touch From: Mark Duffy Subject: Re: draft-touch-ipsec-vpn-06.txt Cc: l3vpn@ietf.org In-Reply-To: <401164A7.8000107@isi.edu> References: <5.2.0.9.0.20040122200853.021a90e0@email> <5.2.0.9.0.20040122200853.021a90e0@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 10:15 AM 1/23/2004 -0800, Joe Touch wrote: >>The draft on page 7 states: >> There are two common implementation scenarios for tunnel mode SAs: >> One is based on firewall-like packet matching operations where tunnel >> mode SAs are not virtual interfaces, another is tunnel-based, and >> treats a tunnel mode SA as a virtual interface. The current IPsec >> architecture does not mandate one or the other. >>This is completely outside my understanding of RFC 2401. 2401 is >>completely oriented towards the policy based approach. I am unaware that >>it provides in any way for treating a tunnel mode SA as a virtual >>interface. In fact it does much to obstruct that viz. SPD policy and >>packet selectors. > >2401 cannot mandate only firewall-like (policy-based) approach; that >would defeat BITW architectures, which are specifically supported. Huh? What does BITW change? All implementation types (BITW, BITS, host, security gateway, etc.) of IPsec are required to implement the access controls aka policy orientation. --Mark From exim@www1.ietf.org Fri Jan 23 13:55:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16166 for ; Fri, 23 Jan 2004 13:55:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak6SM-0002SV-Oz for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 13:55:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NIt2aB009445 for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 13:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak6SM-0002S8-Ks for l3vpn-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 13:55:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16160 for ; Fri, 23 Jan 2004 13:54:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak6S8-0006oN-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 13:54:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak6RG-0006n5-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 13:53:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak6QQ-0006lU-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 13:53:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak6QP-0002K9-Sf; Fri, 23 Jan 2004 13:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak6QC-0002JL-Tq for l3vpn@optimus.ietf.org; Fri, 23 Jan 2004 13:52:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16082 for ; Fri, 23 Jan 2004 13:52:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak6QA-0006jq-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 13:52:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak6PG-0006ie-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 13:51:50 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1Ak6OP-0006hL-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 13:50:57 -0500 Received: from isi.edu (157.sub-69-83-94.myvzw.com [69.83.94.157]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i0NIobD03572; Fri, 23 Jan 2004 10:50:37 -0800 (PST) Message-ID: <40116CF8.8030905@isi.edu> Date: Fri, 23 Jan 2004 10:50:32 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Duffy CC: l3vpn@ietf.org Subject: Re: draft-touch-ipsec-vpn-06.txt References: <5.2.0.9.0.20040122200853.021a90e0@email> <5.2.0.9.0.20040122200853.021a90e0@email> <5.2.0.9.0.20040123133222.02077408@email> In-Reply-To: <5.2.0.9.0.20040123133222.02077408@email> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mark Duffy wrote: > At 10:15 AM 1/23/2004 -0800, Joe Touch wrote: > >>> The draft on page 7 states: >>> There are two common implementation scenarios for tunnel mode SAs: >>> One is based on firewall-like packet matching operations where tunnel >>> mode SAs are not virtual interfaces, another is tunnel-based, and >>> treats a tunnel mode SA as a virtual interface. The current IPsec >>> architecture does not mandate one or the other. >>> This is completely outside my understanding of RFC 2401. 2401 is >>> completely oriented towards the policy based approach. I am unaware >>> that it provides in any way for treating a tunnel mode SA as a >>> virtual interface. In fact it does much to obstruct that viz. SPD >>> policy and packet selectors. >> >> 2401 cannot mandate only firewall-like (policy-based) approach; that >> would defeat BITW architectures, which are specifically supported. > > Huh? What does BITW change? All implementation types (BITW, BITS, > host, security gateway, etc.) of IPsec are required to implement the > access controls aka policy orientation. > > --Mark BITW is my interpretation of how tunnel-mode-as-virtual-interface is perceived. That may not be correct; I won't defend that interpretation, since there are other problems. Others have defended it in the IPsec WG, which is why they are discussed as alternatives in our draft. Joe From exim@www1.ietf.org Fri Jan 23 14:01:18 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16371 for ; Fri, 23 Jan 2004 14:01:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak6Xy-0002nK-NZ for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 14:00:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NJ0o0S010736 for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 14:00:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak6Xy-0002n5-Ii for l3vpn-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 14:00:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16365 for ; Fri, 23 Jan 2004 14:00:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak6Xw-00070I-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 14:00:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak6Wz-0006zV-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 13:59:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak6WD-0006yY-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 13:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak6WD-0002c8-CW; Fri, 23 Jan 2004 13:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak6W2-0002Zk-Ek for l3vpn@optimus.ietf.org; Fri, 23 Jan 2004 13:58:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16284 for ; Fri, 23 Jan 2004 13:58:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak6Vz-0006xj-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 13:58:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak6V3-0006w0-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 13:57:50 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1Ak6UA-0006uS-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 13:56:54 -0500 Received: from isi.edu (157.sub-69-83-94.myvzw.com [69.83.94.157]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i0NIunD09943; Fri, 23 Jan 2004 10:56:49 -0800 (PST) Message-ID: <40116E6C.7060800@isi.edu> Date: Fri, 23 Jan 2004 10:56:44 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Claudio Lordello CC: l3vpn@ietf.org, Ross Callon Subject: Re: draft-touch-ipsec-vpn-06.txt References: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DADF@pion.jnpr.net> In-Reply-To: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DADF@pion.jnpr.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Claudio Lordello wrote: > Joe Touch wrote: > >>While there are ways to have (as with 2401) an implementation that is >>IPsec-2401bis compliant that handles dynamic routing using >>tunnel-mode >>SAs, it's not ensured. It is ensured that transport mode with >>non-IPsec >>tunnels will always accommodate dynamic routing. > > That's my point. So you agree that tunnel mode and routing are > not necessarily mutually exclusive, and yet your drafts states > that in several occasions. > > Claudio. Reliable transport and UDP are not mutually exclusive either. IF all the packets get there. You cannot rely on an implementation conformant to the spec to support dynamic routing - on that information alone. Our assertion - and the whole document - focuses on the spec. As I've already stated, implementation variations outside the spec that cannot be relied upon are important as possible mods to the spec only. And that's how we discuss them. This issue, however, is core to the discussions that have already occurred within the IPsec WG, as they relate directly to the interaction between dynamic routing and IPsec. These are not specific to L3VPNs. Joe From exim@www1.ietf.org Fri Jan 23 14:47:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18393 for ; Fri, 23 Jan 2004 14:47:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak7GU-00060q-44 for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 14:46:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NJkoGQ023111 for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 14:46:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak7GU-00060g-08 for l3vpn-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 14:46:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18388 for ; Fri, 23 Jan 2004 14:46:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak7GR-00019g-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 14:46:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak7FU-000196-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 14:45:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak7En-00018Z-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 14:45:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak7Ej-0005tn-PD; Fri, 23 Jan 2004 14:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak7EX-0005tN-Py for l3vpn@optimus.ietf.org; Fri, 23 Jan 2004 14:44:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18362 for ; Fri, 23 Jan 2004 14:44:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak7EV-00017g-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 14:44:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak7DZ-000158-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 14:43:50 -0500 Received: from [142.46.197.162] (helo=pion-smtp.jnpr.net) by ietf-mx with esmtp (Exim 4.12) id 1Ak7Cf-00010i-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 14:42:54 -0500 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: draft-touch-ipsec-vpn-06.txt X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Fri, 23 Jan 2004 14:42:23 -0500 Message-ID: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DAE1@pion.jnpr.net> Thread-Topic: draft-touch-ipsec-vpn-06.txt Thread-Index: AcPh5U8osHQDDw7NT3WSFeR2D95JPwAAG4Xg From: "Claudio Lordello" To: "Joe Touch" Cc: , "Ross Callon" Content-Transfer-Encoding: quoted-printable Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Joe Touch wrote: > >=20 > >>While there are ways to have (as with 2401) an=20 > implementation that is=20 > >>IPsec-2401bis compliant that handles dynamic routing using=20 > >>tunnel-mode=20 > >>SAs, it's not ensured. It is ensured that transport mode with=20 > >>non-IPsec=20 > >>tunnels will always accommodate dynamic routing. > >=20 > > That's my point. So you agree that tunnel mode and routing are > > not necessarily mutually exclusive, and yet your drafts states > > that in several occasions. > >=20 > > Claudio. >=20 > Reliable transport and UDP are not mutually exclusive either.=20 > IF all the=20 > packets get there. You cannot rely on an implementation conformant to=20 > the spec to support dynamic routing - on that information alone. >=20 Yes, the same way you cannot say that another implementation, also = conformant to the spec, cannot support dynamic routing. Yet you do. Regarding you example, the difference is that UDP is clearly stated as = an unreliable. Assuming otherwise is a mistake. On the other hand, 2401 = does not state that tunnel mode cannot be used in dynamic routing = environments. > Our assertion - and the whole document - focuses on the spec. As I've=20 > already stated, implementation variations outside the spec=20 > that cannot=20 > be relied upon are important as possible mods to the spec only. And=20 > that's how we discuss them. >=20 Why "outside the spec"? How can you say that when also you agreed that = "there are ways to have an implementation that is IPsec-2401bis = compliant that handles dynamic routing using tunnel-mode SAs"?=20 Claudio.=20 From exim@www1.ietf.org Fri Jan 23 16:30:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25675 for ; Fri, 23 Jan 2004 16:30:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak8sM-0004CM-NE for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 16:30:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NLU2EX016131 for l3vpn-archive@odin.ietf.org; Fri, 23 Jan 2004 16:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak8sL-0004Bt-DU for l3vpn-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 16:30:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25596 for ; Fri, 23 Jan 2004 16:29:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak8sJ-0006iZ-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 16:29:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak8rO-0006ek-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 16:29:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak8qV-0006ad-00 for l3vpn-web-archive@ietf.org; Fri, 23 Jan 2004 16:28:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak8qO-00043F-IL; Fri, 23 Jan 2004 16:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak8pb-00041h-GB for l3vpn@optimus.ietf.org; Fri, 23 Jan 2004 16:27:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25333 for ; Fri, 23 Jan 2004 16:27:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak8pZ-0006Ur-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 16:27:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak8oj-0006PQ-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 16:26:18 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1Ak8nr-0006H0-00 for l3vpn@ietf.org; Fri, 23 Jan 2004 16:25:23 -0500 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i0NLPMD24879; Fri, 23 Jan 2004 13:25:22 -0800 (PST) Message-ID: <401190CB.7020307@isi.edu> Date: Fri, 23 Jan 2004 13:23:23 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Claudio Lordello CC: l3vpn@ietf.org, Ross Callon Subject: Re: draft-touch-ipsec-vpn-06.txt References: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DAE1@pion.jnpr.net> In-Reply-To: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DAE1@pion.jnpr.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Claudio Lordello wrote: > Joe Touch wrote: > >>>>While there are ways to have (as with 2401) an >> >>implementation that is >> >>>>IPsec-2401bis compliant that handles dynamic routing using >>>>tunnel-mode >>>>SAs, it's not ensured. It is ensured that transport mode with >>>>non-IPsec >>>>tunnels will always accommodate dynamic routing. >>> >>>That's my point. So you agree that tunnel mode and routing are >> >> > not necessarily mutually exclusive, and yet your drafts states >> > that in several occasions. >> >>>Claudio. >> >>Reliable transport and UDP are not mutually exclusive either. >>IF all the >>packets get there. You cannot rely on an implementation conformant to >>the spec to support dynamic routing - on that information alone. >> > > > Yes, the same way you cannot say that another implementation, also conformant to the spec, cannot support dynamic routing. Yet you do. The doc doesn't talk about implementations - it talks about specs, and should. > Regarding you example, the difference is that UDP is clearly stated as an unreliable. > Assuming otherwise is a mistake. Assuming that a compliant 2401 implementation can support dynamic routing is equally erroneous. ... >>Our assertion - and the whole document - focuses on the spec. As I've >>already stated, implementation variations outside the spec >>that cannot >>be relied upon are important as possible mods to the spec only. And >>that's how we discuss them. > > Why "outside the spec"? How can you say that when also you agreed that > "there are ways to have an implementation that is IPsec-2401bis compliant > that handles dynamic routing using tunnel-mode SAs"? > > Claudio. MUST vs. MAY, in a sense. We're talking about what needs (MUST) be done so that the user can rely on dynamic routing working. Joe From exim@www1.ietf.org Tue Jan 27 01:14:57 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08445 for ; Tue, 27 Jan 2004 01:14:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlMUW-0001pZ-Ee for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 01:14:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0R6ESgK007033 for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 01:14:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlMUW-0001pM-85 for l3vpn-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 01:14:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08439 for ; Tue, 27 Jan 2004 01:14:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlMUT-0001dn-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 01:14:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlMTa-0001cX-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 01:13:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlMTA-0001ai-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 01:13:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlMT7-0001l6-Et; Tue, 27 Jan 2004 01:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlMSf-0001ka-H8 for l3vpn@optimus.ietf.org; Tue, 27 Jan 2004 01:12:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08382 for ; Tue, 27 Jan 2004 01:12:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlMSc-0001Zy-00 for l3vpn@ietf.org; Tue, 27 Jan 2004 01:12:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlMRh-0001XU-00 for l3vpn@ietf.org; Tue, 27 Jan 2004 01:11:33 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1AlMRK-0001VB-00 for l3vpn@ietf.org; Tue, 27 Jan 2004 01:11:10 -0500 Received: from isi.edu (ras45.isi.edu [128.9.176.145]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i0R6B7v03742; Mon, 26 Jan 2004 22:11:07 -0800 (PST) Message-ID: <401600F8.6000907@isi.edu> Date: Mon, 26 Jan 2004 22:11:04 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Claudio Lordello CC: l3vpn@ietf.org, Ross Callon Subject: Re: draft-touch-ipsec-vpn-06.txt References: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DAF0@pion.jnpr.net> In-Reply-To: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DAF0@pion.jnpr.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Claudio Lordello wrote: >>... >> >>>OK. In summary: this WG is asking comments as to whether or not it >>>should approve this draft, >> >>Actually, since it's not a WG doc, the 'approval' isn't the option. >> >>What's being asked is whether the WG has issues with the doc in its >>current for, notably issues central to L3VPN. >> > Well, hopefully is very clear by now that I do have an issue > with this draft on its current format, and I have clearly stated > what exactly my issue is on previous emails. > >>>a draft which states that "IPsec tunnel mode >>>conflict with routing and forwarding inside a VN", when in fact, the >>>only mode that MUST be supported by SG's (i.e., routers), >> >>as established >> >>>by the IPsec WG, is actually tunnel mode. >> >>That is an excellent point that has already been taken up >>with the IPsec >>WG. Your participation in that WG - notably on the update to RFC2401, >>would have been useful. >> >>Joe > > Not at all! I am NOT the one saying that there are issues > with running routing protocols over an IPsec tunnel. You are > saying that. I am perfectly happy with the MUST's and > MAY's currently specified in 2401bis regarding tunnel/transport > mode. Actually, I have clearly stated that the implementation > I work with does support dynamic routing over an IPsec tunnel, > without any of the issues you describe in your draft. > > Claudio. Claudio, This thread is repeating itself. The IPsec WG has already decided on our draft on this specific issue. See especially the IPsec WG archives around the Salt Lake City IETF meeting in Dec. 2001. Joe From exim@www1.ietf.org Tue Jan 27 08:52:14 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04883 for ; Tue, 27 Jan 2004 08:52:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlTd4-0000BE-Ey for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 08:51:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RDpkTm000688 for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 08:51:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlTd4-0000B1-8U for l3vpn-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 08:51:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04877 for ; Tue, 27 Jan 2004 08:51:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlTd2-0002jw-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 08:51:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlTc5-0002hp-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 08:50:45 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlTbQ-0002fc-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 08:50:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlTbN-0008QG-JX; Tue, 27 Jan 2004 08:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlTb8-0008PZ-0K for l3vpn@optimus.ietf.org; Tue, 27 Jan 2004 08:49:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04862 for ; Tue, 27 Jan 2004 08:49:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlTb6-0002fG-00 for l3vpn@ietf.org; Tue, 27 Jan 2004 08:49:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlTa9-0002cl-00 for l3vpn@ietf.org; Tue, 27 Jan 2004 08:48:46 -0500 Received: from [142.46.197.162] (helo=pion-smtp.jnpr.net) by ietf-mx with esmtp (Exim 4.12) id 1AlTZP-0002Y8-00 for l3vpn@ietf.org; Tue, 27 Jan 2004 08:47:59 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: draft-touch-ipsec-vpn-06.txt X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Tue, 27 Jan 2004 08:47:28 -0500 Message-ID: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DAF2@pion.jnpr.net> Thread-Topic: draft-touch-ipsec-vpn-06.txt Thread-Index: AcPkUJWCWpcmMd60SkWzwXxhzkMnaQAAbHaQACJjSQA= From: "Claudio Lordello" To: Content-Transfer-Encoding: quoted-printable Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable reposting... >=20 > ... > > OK. In summary: this WG is asking comments as to whether or not it > > should approve this draft, >=20 > Actually, since it's not a WG doc, the 'approval' isn't the option. >=20 > What's being asked is whether the WG has issues with the doc in its=20 > current for, notably issues central to L3VPN. >=20 Well, hopefully is very clear by now that I do have an issue with this = draft on its current format, and I have clearly stated what exactly my = issue is on previous emails. > > a draft which states that "IPsec tunnel mode > > conflict with routing and forwarding inside a VN", when in fact, the > > only mode that MUST be supported by SG's (i.e., routers),=20 > as established > > by the IPsec WG, is actually tunnel mode. >=20 > That is an excellent point that has already been taken up=20 > with the IPsec=20 > WG. Your participation in that WG - notably on the update to RFC2401,=20 > would have been useful. >=20 > Joe >=20 Not at all! I am NOT the one saying that there are issues with running = routing protocols over an IPsec tunnel. You are saying that. I am = perfectly happy with the MUST's and MAY's currently specified in 2401bis = regarding tunnel/transport mode. Actually, I have clearly stated that = the implementation I work with does support dynamic routing over an = IPsec tunnel, without any of the issues you describe in your draft.=20 Claudio. From exim@www1.ietf.org Tue Jan 27 09:16:16 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05723 for ; Tue, 27 Jan 2004 09:16:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlU0J-0001vq-LD for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 09:15:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0REFlMH007420 for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 09:15:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlU0J-0001vb-7F for l3vpn-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 09:15:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05715 for ; Tue, 27 Jan 2004 09:15:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlU0H-0003zs-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 09:15:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlTzH-0003ws-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 09:14:44 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlTye-0003um-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 09:14:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlTyb-0001qU-By; Tue, 27 Jan 2004 09:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlTyM-0001n7-Bn for l3vpn@optimus.ietf.org; Tue, 27 Jan 2004 09:13:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05697 for ; Tue, 27 Jan 2004 09:13:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlTyK-0003ue-00 for l3vpn@ietf.org; Tue, 27 Jan 2004 09:13:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlTxQ-0003sc-00 for l3vpn@ietf.org; Tue, 27 Jan 2004 09:12:49 -0500 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AlTwn-0003q5-00 for l3vpn@ietf.org; Tue, 27 Jan 2004 09:12:09 -0500 Received: from netlab.nec.de (tokyo.netlab.nec.de [195.37.70.2]) by ftp.ccrle.nec.de (Postfix) with ESMTP id BF4BFF5A9; Tue, 27 Jan 2004 15:16:48 +0100 (CET) Message-ID: <401671B3.6020301@netlab.nec.de> Date: Tue, 27 Jan 2004 15:12:03 +0100 From: Lars Eggert Organization: NEC Network Laboratories User-Agent: Mozilla Thunderbird 0.5a (Macintosh/20040126) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Claudio Lordello Cc: l3vpn@ietf.org Subject: Re: FW: draft-touch-ipsec-vpn-06.txt References: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DAF2@pion.jnpr.net> In-Reply-To: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DAF2@pion.jnpr.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020106070401030403080602" Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms020106070401030403080602 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Claudio Lordello wrote: > > Not at all! I am NOT the one saying that there are issues with > running routing protocols over an IPsec tunnel. You are saying that. > I am perfectly happy with the MUST's and MAY's currently specified in > 2401bis regarding tunnel/transport mode. Actually, I have clearly > stated that the implementation I work with does support dynamic > routing over an IPsec tunnel, without any of the issues you describe > in your draft. Some 2401-compliant implementations *CAN* run dynamic routing over IPsec tunnels. Some 2401-compliant implementations *CANNOT*. I'd call that an issue in the spec with regard to supporting dynamic routing. (I don't know how else to explain this any simpler.) Lars -- Lars Eggert NEC Network Laboratories --------------ms020106070401030403080602 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNaMIICw6ADAgECAgMLU6IwDQYJKoZIhvcNAQEE BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTAz MTIxNTEyMzEyOFoXDTA0MTIxNDEyMzEyOFowgYQxDzANBgNVBAQTBkVnZ2VydDENMAsGA1UE KhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdn ZXJ0QG5ldGxhYi5uZWMuZGUxIjAgBgkqhkiG9w0BCQEWE2xhcnMuZWdnZXJ0QGdteC5uZXQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWps58Zq8Buu2DKDl9crbvzSo6zWsZ TkQLr5zOTqUMs/eU7Mcohv64O4IxWWYGLfYsjDRxUlmdHdJUbyTtUh2lH452DUDJByXidlLm RDgohG0AVwztedqy1+hE3VnCdpMhUGks+6ntrr3dKSxMgLM0AM1kPWsH9lWX6IOPdxOC30gM PiQ65zH9PR70befQLgFPKcAv0wP8210l05n8ekwYAcq2cm3/j+nuDu0HEh5pgsnY7cVELeNJ ODvr4IiE1t3c2w4+0Nc/WJrqGCMl+gZ8c+7FtzjoyDeEsCjNFDeA2ymNd+10O6kjwvPHlzPr 3rW73RDRPAjMJ49HXlueiuoNAgMBAAGjdzB1MCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5k ZYETbGFycy5lZ2dlcnRAZ214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AHgrv3SQFD4AS4lY4oKcI3iTHcclEHbYfg3UUb8zzCUsl+OJoz0nmebGmOL+tvNj5GvCrWnN H4LvVLh8ZBhFXms7eKJ1YiHgbKwTRK23P8Y5NDit5ico0ZjpFWeenUWj3ajEbN6n4K8dNp+C 0b2apnSrlFVWY6BucZFIYqQ1Lf91MIIDWjCCAsOgAwIBAgIDC1OiMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wMzEy MTUxMjMxMjhaFw0wNDEyMTQxMjMxMjhaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoT BExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2Vy dEBuZXRsYWIubmVjLmRlMSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1qbOfGavAbrtgyg5fXK2780qOs1rGU5E C6+czk6lDLP3lOzHKIb+uDuCMVlmBi32LIw0cVJZnR3SVG8k7VIdpR+Odg1AyQcl4nZS5kQ4 KIRtAFcM7XnastfoRN1ZwnaTIVBpLPup7a693SksTICzNADNZD1rB/ZVl+iDj3cTgt9IDD4k Oucx/T0e9G3n0C4BTynAL9MD/NtdJdOZ/HpMGAHKtnJt/4/p7g7tBxIeaYLJ2O3FRC3jSTg7 6+CIhNbd3NsOPtDXP1ia6hgjJfoGfHPuxbc46Mg3hLAozRQ3gNspjXftdDupI8Lzx5cz6961 u90Q0TwIzCePR15bnorqDQIDAQABo3cwdTAqBgUrZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVN eWZmQk5VYk5KSmNkWjJzMDkGA1UdEQQyMDCBGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGWB E2xhcnMuZWdnZXJ0QGdteC5uZXQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB4 K790kBQ+AEuJWOKCnCN4kx3HJRB22H4N1FG/M8wlLJfjiaM9J5nmxpji/rbzY+Rrwq1pzR+C 71S4fGQYRV5rO3iidWIh4GysE0Sttz/GOTQ4reYnKNGY6RVnnp1Fo92oxGzep+CvHTafgtG9 mqZ0q5RVVmOgbnGRSGKkNS3/dTGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwMTI3MTQxMjAzWjAjBgkqhkiG 9w0BCQQxFgQUKeZFKtaeEmBjhHBRiG51k8+bfAkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwtTojB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwDQYJKoZIhvcNAQEBBQAEggEA CFr1DkLW4lwvAQJogJZjuf/tmkoy6YrMI8OqiU0MhQ+2rb0QW23fey1sRfx4jbhQ5JZ/C3Tf xyoqA+FkRBK40WXOMN93eHQEmTn3WQCnZkOiulScsA9gewEwD4YGAbzIso/Kpt1aUakaApCC RNl8qEJLUuir0wCyOVH56vSZA3kmGpwDx93Dltec1kaO0Hgi2ol7fEiZsr+uC9DfPwUwldBI 2WOElip8HwFx/UEdgSbv17q3dpJEETjxaMEF1MGtjpSTxA4c5c5dkYGvqF5DX8o/pw+gC4H1 kvzm4KuHSqGltVZ46c3v/zy/9UraRYUQS78FQla1TmUpZTUfOGRzEwAAAAAAAA== --------------ms020106070401030403080602-- From exim@www1.ietf.org Tue Jan 27 10:44:20 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10106 for ; Tue, 27 Jan 2004 10:44:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlVNY-0005cL-Q0 for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 10:43:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RFhqdE021587 for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 10:43:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlVNY-0005c6-Kk for l3vpn-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 10:43:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10031 for ; Tue, 27 Jan 2004 10:43:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlVNW-0001ou-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 10:43:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlVMi-0001mG-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 10:43:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlVM3-0001ii-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 10:42:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlVLl-0005Qw-Bo; Tue, 27 Jan 2004 10:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlVLZ-0005Qf-2f for l3vpn@optimus.ietf.org; Tue, 27 Jan 2004 10:41:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09953 for ; Tue, 27 Jan 2004 10:41:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlVLW-0001h0-00 for l3vpn@ietf.org; Tue, 27 Jan 2004 10:41:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlVKc-0001ea-00 for l3vpn@ietf.org; Tue, 27 Jan 2004 10:40:50 -0500 Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx with esmtp (Exim 4.12) id 1AlVKT-0001c7-00 for l3vpn@ietf.org; Tue, 27 Jan 2004 10:40:41 -0500 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.169]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XT41BG1N; Tue, 27 Jan 2004 10:40:09 -0500 Message-Id: <5.2.0.9.0.20040127103500.020786e8@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 27 Jan 2004 10:38:35 -0500 To: Lars Eggert From: Mark Duffy Subject: Re: FW: draft-touch-ipsec-vpn-06.txt Cc: l3vpn@ietf.org In-Reply-To: <401671B3.6020301@netlab.nec.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 09:12 AM 1/27/2004 -0500, Lars Eggert wrote: >Some 2401-compliant implementations *CAN* run dynamic routing over IPsec >tunnels. Some 2401-compliant implementations *CANNOT*. > >I'd call that an issue in the spec with regard to supporting dynamic >routing. (I don't know how else to explain this any simpler.) The authors of this draft have been making this sort of argument all along and to me it makes no sense. Some ethernet-compliant devices *CAN* support IP and some *CANNOT*. Does anyone think this is a problem with the ethernet spec? -Mark From exim@www1.ietf.org Tue Jan 27 11:02:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10874 for ; Tue, 27 Jan 2004 11:02:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlVew-0006N3-Qq for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 11:01:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RG1oRI024483 for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 11:01:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlVew-0006Mo-KN for l3vpn-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 11:01:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10870 for ; Tue, 27 Jan 2004 11:01:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlVeu-0002sJ-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 11:01:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlVdw-0002q6-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 11:00:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlVdI-0002ni-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 11:00:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlVdC-0006G6-Ap; Tue, 27 Jan 2004 11:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlVcy-0006FQ-Vg for l3vpn@optimus.ietf.org; Tue, 27 Jan 2004 10:59:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10804 for ; Tue, 27 Jan 2004 10:59:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlVcw-0002mr-00 for l3vpn@ietf.org; Tue, 27 Jan 2004 10:59:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlVc1-0002kG-00 for l3vpn@ietf.org; Tue, 27 Jan 2004 10:58:49 -0500 Received: from [142.46.197.162] (helo=pion-smtp.jnpr.net) by ietf-mx with esmtp (Exim 4.12) id 1AlVbD-0002er-00 for l3vpn@ietf.org; Tue, 27 Jan 2004 10:57:59 -0500 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: FW: draft-touch-ipsec-vpn-06.txt X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Tue, 27 Jan 2004 10:57:29 -0500 Message-ID: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DAF6@pion.jnpr.net> Thread-Topic: FW: draft-touch-ipsec-vpn-06.txt Thread-Index: AcPk7Dt6F7YywfNqT1ytyne5pKj8WAAAJUfA From: "Claudio Lordello" To: "Mark Duffy" , "Lars Eggert" Cc: Content-Transfer-Encoding: quoted-printable Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Mark Duffy wrote: >=20 > At 09:12 AM 1/27/2004 -0500, Lars Eggert wrote: >=20 > >Some 2401-compliant implementations *CAN* run dynamic=20 > routing over IPsec > >tunnels. Some 2401-compliant implementations *CANNOT*. > > > >I'd call that an issue in the spec with regard to supporting dynamic > >routing. (I don't know how else to explain this any simpler.) >=20 > The authors of this draft have been making this sort of=20 > argument all along=20 > and to me it makes no sense. Some ethernet-compliant devices=20 > *CAN* support=20 > IP and some *CANNOT*. Does anyone think this is a problem with the=20 > ethernet spec? >=20 > -Mark You hit the nail on the head. The fact is that IPsec is orthogonal to dynamic routing. It does not = mandate nor restrict it, as it should. Claudio. From exim@www1.ietf.org Tue Jan 27 11:16:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11544 for ; Tue, 27 Jan 2004 11:16:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlVsf-00084M-5G for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 11:16:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RGG1Re031017 for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 11:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlVse-00083z-ST for l3vpn-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 11:16:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11528 for ; Tue, 27 Jan 2004 11:15:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlVse-0003pG-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 11:16:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlVrv-0003kY-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 11:15:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlVqo-0003fa-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 11:14:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlVqk-0007fq-AG; Tue, 27 Jan 2004 11:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlVpn-0007bo-Lk for l3vpn@optimus.ietf.org; Tue, 27 Jan 2004 11:13:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11371 for ; Tue, 27 Jan 2004 11:13:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlVpm-0003Zv-00 for l3vpn@ietf.org; Tue, 27 Jan 2004 11:13:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlVov-0003V6-00 for l3vpn@ietf.org; Tue, 27 Jan 2004 11:12:10 -0500 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AlVoK-0003Pn-00 for l3vpn@ietf.org; Tue, 27 Jan 2004 11:11:32 -0500 Received: from netlab.nec.de (tokyo.netlab.nec.de [195.37.70.2]) by ftp.ccrle.nec.de (Postfix) with ESMTP id CE800F5A9; Tue, 27 Jan 2004 17:16:08 +0100 (CET) Message-ID: <40168DA4.9050804@netlab.nec.de> Date: Tue, 27 Jan 2004 17:11:16 +0100 From: Lars Eggert Organization: NEC Network Laboratories User-Agent: Mozilla Thunderbird 0.5a (Macintosh/20040126) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Duffy Cc: l3vpn@ietf.org Subject: Re: FW: draft-touch-ipsec-vpn-06.txt References: <5.2.0.9.0.20040127103500.020786e8@email> In-Reply-To: <5.2.0.9.0.20040127103500.020786e8@email> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060607050004050307070600" Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms060607050004050307070600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mark Duffy wrote: > At 09:12 AM 1/27/2004 -0500, Lars Eggert wrote: > >> Some 2401-compliant implementations *CAN* run dynamic routing over IPsec >> tunnels. Some 2401-compliant implementations *CANNOT*. > > The authors of this draft have been making this sort of argument all > along and to me it makes no sense. Some ethernet-compliant devices > *CAN* support IP and some *CANNOT*. Does anyone think this is a problem > with the ethernet spec? To stick with your analogy: The Ethernet spec is underspecified when it comes to carrying IP traffic, similar to how 2401 is underspecified when it comes to dynamic routing. Hence, we have a spec that says "here's how you can carry IP over Ethernet and interoperate", similar to how our draft does for dynamic routing and IPsec. (Note that the Ethernet specification did the right thing, and not discuss this. IPsec would be cleaner if it did not include its own underspecified tunneling mechanism.) Lars -- Lars Eggert NEC Network Laboratories --------------ms060607050004050307070600 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNaMIICw6ADAgECAgMLU6IwDQYJKoZIhvcNAQEE BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTAz MTIxNTEyMzEyOFoXDTA0MTIxNDEyMzEyOFowgYQxDzANBgNVBAQTBkVnZ2VydDENMAsGA1UE KhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdn ZXJ0QG5ldGxhYi5uZWMuZGUxIjAgBgkqhkiG9w0BCQEWE2xhcnMuZWdnZXJ0QGdteC5uZXQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWps58Zq8Buu2DKDl9crbvzSo6zWsZ TkQLr5zOTqUMs/eU7Mcohv64O4IxWWYGLfYsjDRxUlmdHdJUbyTtUh2lH452DUDJByXidlLm RDgohG0AVwztedqy1+hE3VnCdpMhUGks+6ntrr3dKSxMgLM0AM1kPWsH9lWX6IOPdxOC30gM PiQ65zH9PR70befQLgFPKcAv0wP8210l05n8ekwYAcq2cm3/j+nuDu0HEh5pgsnY7cVELeNJ ODvr4IiE1t3c2w4+0Nc/WJrqGCMl+gZ8c+7FtzjoyDeEsCjNFDeA2ymNd+10O6kjwvPHlzPr 3rW73RDRPAjMJ49HXlueiuoNAgMBAAGjdzB1MCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5k ZYETbGFycy5lZ2dlcnRAZ214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AHgrv3SQFD4AS4lY4oKcI3iTHcclEHbYfg3UUb8zzCUsl+OJoz0nmebGmOL+tvNj5GvCrWnN H4LvVLh8ZBhFXms7eKJ1YiHgbKwTRK23P8Y5NDit5ico0ZjpFWeenUWj3ajEbN6n4K8dNp+C 0b2apnSrlFVWY6BucZFIYqQ1Lf91MIIDWjCCAsOgAwIBAgIDC1OiMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wMzEy MTUxMjMxMjhaFw0wNDEyMTQxMjMxMjhaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoT BExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2Vy dEBuZXRsYWIubmVjLmRlMSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1qbOfGavAbrtgyg5fXK2780qOs1rGU5E C6+czk6lDLP3lOzHKIb+uDuCMVlmBi32LIw0cVJZnR3SVG8k7VIdpR+Odg1AyQcl4nZS5kQ4 KIRtAFcM7XnastfoRN1ZwnaTIVBpLPup7a693SksTICzNADNZD1rB/ZVl+iDj3cTgt9IDD4k Oucx/T0e9G3n0C4BTynAL9MD/NtdJdOZ/HpMGAHKtnJt/4/p7g7tBxIeaYLJ2O3FRC3jSTg7 6+CIhNbd3NsOPtDXP1ia6hgjJfoGfHPuxbc46Mg3hLAozRQ3gNspjXftdDupI8Lzx5cz6961 u90Q0TwIzCePR15bnorqDQIDAQABo3cwdTAqBgUrZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVN eWZmQk5VYk5KSmNkWjJzMDkGA1UdEQQyMDCBGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGWB E2xhcnMuZWdnZXJ0QGdteC5uZXQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB4 K790kBQ+AEuJWOKCnCN4kx3HJRB22H4N1FG/M8wlLJfjiaM9J5nmxpji/rbzY+Rrwq1pzR+C 71S4fGQYRV5rO3iidWIh4GysE0Sttz/GOTQ4reYnKNGY6RVnnp1Fo92oxGzep+CvHTafgtG9 mqZ0q5RVVmOgbnGRSGKkNS3/dTGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwMTI3MTYxMTE2WjAjBgkqhkiG 9w0BCQQxFgQUG3i3k+vdanyErmu8utJUhGVWs/8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwtTojB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwDQYJKoZIhvcNAQEBBQAEggEA vh24ETzp62e2m7iGe90Gk9fU5L3v1yWecppI3zOyt3jlDgspcnciAOPPXSNOANb+cIySFuFT xb8s6iPor65LGrcT6ntrp+IG+kJnFgJCswFm2PM9HfyD1V5/VsiJEJ0krBIpTm+oyxBX5TZ1 m7pSD74eWvb2ep/sQOFIwlF4eDZeczUIZVoX6f8VmeLag/JfREfWgopAd+cDCm8NgZz+Dn5w Ad7CeMywSxJKH/VLZJR+4WOd9sjmYuX6qoS68Derlc/Fup6enTqypk2uM1cY21la27cSnsqh EysLj0H6tOtv/nGA5xQHTtSAA2EKR4j8B3zW7rBHZ6pubKzK/jUrrAAAAAAAAA== --------------ms060607050004050307070600-- From exim@www1.ietf.org Tue Jan 27 11:25:16 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11843 for ; Tue, 27 Jan 2004 11:25:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlW1A-0008V0-Gf for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 11:24:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RGOmx5032664 for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 11:24:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlW1A-0008Ul-B8 for l3vpn-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 11:24:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11803 for ; Tue, 27 Jan 2004 11:24:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlW19-0004LM-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 11:24:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlW0E-0004IZ-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 11:23:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlVzS-0004G8-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 11:23:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlVzQ-0008Jy-Es; Tue, 27 Jan 2004 11:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlVzD-0008Jc-MP for l3vpn@optimus.ietf.org; Tue, 27 Jan 2004 11:22:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11770 for ; Tue, 27 Jan 2004 11:22:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlVzC-0004F7-00 for l3vpn@ietf.org; Tue, 27 Jan 2004 11:22:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlVyH-0004CA-00 for l3vpn@ietf.org; Tue, 27 Jan 2004 11:21:50 -0500 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AlVxN-00049k-00 for l3vpn@ietf.org; Tue, 27 Jan 2004 11:20:53 -0500 Received: from netlab.nec.de (tokyo.netlab.nec.de [195.37.70.2]) by ftp.ccrle.nec.de (Postfix) with ESMTP id C7488F5A9; Tue, 27 Jan 2004 17:25:33 +0100 (CET) Message-ID: <40168FE0.5050701@netlab.nec.de> Date: Tue, 27 Jan 2004 17:20:48 +0100 From: Lars Eggert Organization: NEC Network Laboratories User-Agent: Mozilla Thunderbird 0.5a (Macintosh/20040126) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Claudio Lordello Cc: Mark Duffy , l3vpn@ietf.org Subject: Re: FW: draft-touch-ipsec-vpn-06.txt References: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DAF6@pion.jnpr.net> In-Reply-To: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DAF6@pion.jnpr.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090407030900030801010306" Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms090407030900030801010306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Claudio Lordello wrote: > > The fact is that IPsec is orthogonal to dynamic routing. It does not > mandate nor restrict it, as it should. It does include a tunneling mechanism that provides some of the functionality of a virtual link. It leaves it up to implementors to decide how fully to implement related link characteristics. Hence the ambiguity. The ID does NOT propose to change 2401 such that all IPsec implementations must support dynamic routing. It describes one approach that carefully combines existing mechanisms such that dynamic routing works by default. We're running in circles, and I'll stop now. Lars -- Lars Eggert NEC Network Laboratories --------------ms090407030900030801010306 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNaMIICw6ADAgECAgMLU6IwDQYJKoZIhvcNAQEE BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTAz MTIxNTEyMzEyOFoXDTA0MTIxNDEyMzEyOFowgYQxDzANBgNVBAQTBkVnZ2VydDENMAsGA1UE KhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdn ZXJ0QG5ldGxhYi5uZWMuZGUxIjAgBgkqhkiG9w0BCQEWE2xhcnMuZWdnZXJ0QGdteC5uZXQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWps58Zq8Buu2DKDl9crbvzSo6zWsZ TkQLr5zOTqUMs/eU7Mcohv64O4IxWWYGLfYsjDRxUlmdHdJUbyTtUh2lH452DUDJByXidlLm RDgohG0AVwztedqy1+hE3VnCdpMhUGks+6ntrr3dKSxMgLM0AM1kPWsH9lWX6IOPdxOC30gM PiQ65zH9PR70befQLgFPKcAv0wP8210l05n8ekwYAcq2cm3/j+nuDu0HEh5pgsnY7cVELeNJ ODvr4IiE1t3c2w4+0Nc/WJrqGCMl+gZ8c+7FtzjoyDeEsCjNFDeA2ymNd+10O6kjwvPHlzPr 3rW73RDRPAjMJ49HXlueiuoNAgMBAAGjdzB1MCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5k ZYETbGFycy5lZ2dlcnRAZ214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AHgrv3SQFD4AS4lY4oKcI3iTHcclEHbYfg3UUb8zzCUsl+OJoz0nmebGmOL+tvNj5GvCrWnN H4LvVLh8ZBhFXms7eKJ1YiHgbKwTRK23P8Y5NDit5ico0ZjpFWeenUWj3ajEbN6n4K8dNp+C 0b2apnSrlFVWY6BucZFIYqQ1Lf91MIIDWjCCAsOgAwIBAgIDC1OiMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wMzEy MTUxMjMxMjhaFw0wNDEyMTQxMjMxMjhaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoT BExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2Vy dEBuZXRsYWIubmVjLmRlMSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1qbOfGavAbrtgyg5fXK2780qOs1rGU5E C6+czk6lDLP3lOzHKIb+uDuCMVlmBi32LIw0cVJZnR3SVG8k7VIdpR+Odg1AyQcl4nZS5kQ4 KIRtAFcM7XnastfoRN1ZwnaTIVBpLPup7a693SksTICzNADNZD1rB/ZVl+iDj3cTgt9IDD4k Oucx/T0e9G3n0C4BTynAL9MD/NtdJdOZ/HpMGAHKtnJt/4/p7g7tBxIeaYLJ2O3FRC3jSTg7 6+CIhNbd3NsOPtDXP1ia6hgjJfoGfHPuxbc46Mg3hLAozRQ3gNspjXftdDupI8Lzx5cz6961 u90Q0TwIzCePR15bnorqDQIDAQABo3cwdTAqBgUrZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVN eWZmQk5VYk5KSmNkWjJzMDkGA1UdEQQyMDCBGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGWB E2xhcnMuZWdnZXJ0QGdteC5uZXQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB4 K790kBQ+AEuJWOKCnCN4kx3HJRB22H4N1FG/M8wlLJfjiaM9J5nmxpji/rbzY+Rrwq1pzR+C 71S4fGQYRV5rO3iidWIh4GysE0Sttz/GOTQ4reYnKNGY6RVnnp1Fo92oxGzep+CvHTafgtG9 mqZ0q5RVVmOgbnGRSGKkNS3/dTGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwMTI3MTYyMDQ4WjAjBgkqhkiG 9w0BCQQxFgQU5mtYur8pY3fACxRHOZStHBC4qKEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwtTojB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwDQYJKoZIhvcNAQEBBQAEggEA LE5rVZY2U8eA7ArOsB1U+nuwnZ1z+1+d0u++GlVBq6cFAYmae0PaKRhtCKAS4HR6Jy9tG1b3 hBIcGV3kNYkr04b31F9vPAGiEJPSuA/uPJ/K3yI+bRcyJkfnDO6BIIyFMlfIqh4JxUnvEdzc 6D2rJBqYtBCZ6qGCQoj+mslWod5r8eS8eJmV2DuosJsWdQjy/aJNSHRNP1xWV5lDaupBGL7M 9i4uby//Y88r3qXJJDIS4ZEfl5URg+W/ietyxUNezBhTRrCrvaA2xFJqw8Btcir+N9Yif0W2 2qvw/Lt5++UuQFGJLEvmanLrMxWTeXa1wTrqBb8wvPoCGr/6apIadgAAAAAAAA== --------------ms090407030900030801010306-- From exim@www1.ietf.org Tue Jan 27 13:57:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18230 for ; Tue, 27 Jan 2004 13:57:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYOU-0003Te-Ft for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 13:57:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RIv2lW013365 for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 13:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYOU-0003TU-AW for l3vpn-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 13:57:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18206 for ; Tue, 27 Jan 2004 13:56:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlYOS-00071O-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 13:57:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlYNR-0006xU-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 13:55:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlYMd-0006uF-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 13:55:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYMa-00038C-5m; Tue, 27 Jan 2004 13:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYMU-00037P-MC for l3vpn@optimus.ietf.org; Tue, 27 Jan 2004 13:54:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18175 for ; Tue, 27 Jan 2004 13:54:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlYMS-0006ta-00 for l3vpn@ietf.org; Tue, 27 Jan 2004 13:54:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlYLX-0006qW-00 for l3vpn@ietf.org; Tue, 27 Jan 2004 13:53:59 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1AlYKx-0006mR-00 for l3vpn@ietf.org; Tue, 27 Jan 2004 13:53:23 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i0RIqbBm071937; Tue, 27 Jan 2004 10:52:37 -0800 (PST) (envelope-from rahul@juniper.net) Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i0RIqbh55385; Tue, 27 Jan 2004 10:52:37 -0800 (PST) (envelope-from rahul@juniper.net) Received: from localhost (rahul@localhost) by sapphire.juniper.net (8.11.6/8.11.3) with ESMTP id i0RIqa587027; Tue, 27 Jan 2004 10:52:37 -0800 (PST) (envelope-from rahul@juniper.net) X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs Date: Tue, 27 Jan 2004 10:52:36 -0800 (PST) From: Rahul Aggarwal To: Eric Rosen cc: Ross Callon , "" , Thomas Narten Subject: Re: draft-touch-ipsec-vpn-06.txt In-Reply-To: <200401221527.i0MFRb5g013225@rtp-core-2.cisco.com> Message-ID: <20040127104328.O69210@sapphire.juniper.net> References: <200401221527.i0MFRb5g013225@rtp-core-2.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Eric and WG, Comments inline: On Thu, 22 Jan 2004, Eric Rosen wrote: > > I think it would be useful to have an RFC which discusses the issues that > arise when you want to use an IPsec Security Association as a routing > adjacency. In fact, it might even be useful to have a standard way of doing > this that would ensure multi-vendor interoperability. > > As Claudio points out, implementors do know how to do this, and there have > been many products on the market for years that do this. Whether they do it > in an interoperable manner is another question. Whether this is in > violation of the IPsec standard is a further question. > I would second the above. > I'd have thought that a draft on this topic, even an informational draft, > would need the approval of the IPsec WG. I am concerned about the fact that > the IPsec WG has failed to progress this draft. > Ditto. > Given that there are many deployed products that do routing over IPsec, I'd > think an informational draft on the topic would benefit from making it > clearer what the existing practices and what the interoperability issues > are. > Agreed. And this draft doesn't seem to help in that regard. > With regard to the draft's relation to L3VPN, the L3VPN charter does > unfortunately include "CE-based VPNs using IPsec". Unless this is removed > from the charter (which would be a good thing imho), I think it would be odd > for an individual draft on the topic to be published. > I agree that progressing this as an individual draft is odd as it directly relates to CE-based VPNs. Furthermore it is not very clear whether this draft also applies to the use of IPsec tunnel mode in PE based VPNs i.e. PE-PE IPsec tunnel mode. If it does, it is very much related to the L3VPN WG. rahul > > > > > > > From exim@www1.ietf.org Tue Jan 27 14:13:22 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18781 for ; Tue, 27 Jan 2004 14:13:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYdq-0004cn-GU for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 14:12:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RJCsOe017771 for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 14:12:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYdq-0004cY-9X for l3vpn-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 14:12:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18715 for ; Tue, 27 Jan 2004 14:12:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlYdo-00009G-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 14:12:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlYcr-00004i-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 14:11:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlYc1-000028-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 14:11:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYc2-0004Nx-3B; Tue, 27 Jan 2004 14:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYbt-0004Ld-Mt for l3vpn@optimus.ietf.org; Tue, 27 Jan 2004 14:10:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18681 for ; Tue, 27 Jan 2004 14:10:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlYbr-00001L-00 for l3vpn@ietf.org; Tue, 27 Jan 2004 14:10:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlYat-0007m5-00 for l3vpn@ietf.org; Tue, 27 Jan 2004 14:09:52 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1AlYZw-0007ga-00 for l3vpn@ietf.org; Tue, 27 Jan 2004 14:08:52 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i0RJ8Ll15942; Tue, 27 Jan 2004 11:08:21 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i0RJ8Fh57981; Tue, 27 Jan 2004 11:08:15 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200401271908.i0RJ8Fh57981@merlot.juniper.net> To: Rahul Aggarwal cc: Eric Rosen , Ross Callon , "" , Thomas Narten Subject: Re: draft-touch-ipsec-vpn-06.txt In-Reply-To: Your message of "Tue, 27 Jan 2004 10:52:36 PST." <20040127104328.O69210@sapphire.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <39125.1075230495.1@juniper.net> Date: Tue, 27 Jan 2004 11:08:15 -0800 From: Yakov Rekhter Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > > Hi Eric and WG, agreed with the points made by Eric and Rahul. Yakov. > > Comments inline: > > On Thu, 22 Jan 2004, Eric Rosen wrote: > > > > > I think it would be useful to have an RFC which discusses the issues tha t > > arise when you want to use an IPsec Security Association as a routin g > > adjacency. In fact, it might even be useful to have a standard way of doin g > > this that would ensure multi-vendor interoperability. > > > > As Claudio points out, implementors do know how to do this, and there hav e > > been many products on the market for years that do this. Whether they do i t > > in an interoperable manner is another question. Whether this is i n > > violation of the IPsec standard is a further question. > > > > I would second the above. > > > I'd have thought that a draft on this topic, even an informational draft , > > would need the approval of the IPsec WG. I am concerned about the fact tha t > > the IPsec WG has failed to progress this draft. > > > > Ditto. > > > Given that there are many deployed products that do routing over IPsec, I' d > > think an informational draft on the topic would benefit from making i t > > clearer what the existing practices and what the interoperability issue s > > are. > > > > Agreed. And this draft doesn't seem to help in that regard. > > > With regard to the draft's relation to L3VPN, the L3VPN charter doe s > > unfortunately include "CE-based VPNs using IPsec". Unless this is remove d > > from the charter (which would be a good thing imho), I think it would be od d > > for an individual draft on the topic to be published. > > > > I agree that progressing this as an individual draft is odd as it > directly relates to CE-based VPNs. Furthermore it is not very clear whether t his draft > also applies to the use of IPsec tunnel mode in PE based VPNs i.e. PE-PE IPse c tunnel mode. > If it does, it is very much related to the L3VPN WG. > > rahul > > > > > > > > > > > > > > > > From exim@www1.ietf.org Tue Jan 27 19:24:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04414 for ; Tue, 27 Jan 2004 19:24:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldV1-0005vF-7F for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 19:24:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S0O7Ff022758 for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 19:24:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldV0-0005uz-VT for l3vpn-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 19:24:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04298 for ; Tue, 27 Jan 2004 19:24:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AldUz-0000N4-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 19:24:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AldTs-00008f-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 19:22:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AldSg-0007iL-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 19:21:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldIh-000250-CA; Tue, 27 Jan 2004 19:11:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlEQv-0001zl-Ha for l3vpn@optimus.ietf.org; Mon, 26 Jan 2004 16:38:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21049 for ; Mon, 26 Jan 2004 16:38:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlEQt-0005Y5-00 for l3vpn@ietf.org; Mon, 26 Jan 2004 16:38:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlEQ1-0005Vx-00 for l3vpn@ietf.org; Mon, 26 Jan 2004 16:37:18 -0500 Received: from [142.46.197.162] (helo=pion-smtp.jnpr.net) by ietf-mx with esmtp (Exim 4.12) id 1AlEPU-0005RB-00 for l3vpn@ietf.org; Mon, 26 Jan 2004 16:36:44 -0500 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: draft-touch-ipsec-vpn-06.txt X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Mon, 26 Jan 2004 16:36:13 -0500 Message-ID: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DAF0@pion.jnpr.net> Thread-Topic: draft-touch-ipsec-vpn-06.txt Thread-Index: AcPkUJWCWpcmMd60SkWzwXxhzkMnaQAAbHaQ From: "Claudio Lordello" To: "Joe Touch" Cc: , "Ross Callon" , "Claudio Lordello" Content-Transfer-Encoding: quoted-printable Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >=20 > ... > > OK. In summary: this WG is asking comments as to whether or not it > > should approve this draft, >=20 > Actually, since it's not a WG doc, the 'approval' isn't the option. >=20 > What's being asked is whether the WG has issues with the doc in its=20 > current for, notably issues central to L3VPN. >=20 Well, hopefully is very clear by now that I do have an issue with this = draft on its current format, and I have clearly stated what exactly my = issue is on previous emails. > > a draft which states that "IPsec tunnel mode > > conflict with routing and forwarding inside a VN", when in fact, the > > only mode that MUST be supported by SG's (i.e., routers),=20 > as established > > by the IPsec WG, is actually tunnel mode. >=20 > That is an excellent point that has already been taken up=20 > with the IPsec=20 > WG. Your participation in that WG - notably on the update to RFC2401,=20 > would have been useful. >=20 > Joe >=20 Not at all! I am NOT the one saying that there are issues with running = routing protocols over an IPsec tunnel. You are saying that. I am = perfectly happy with the MUST's and MAY's currently specified in 2401bis = regarding tunnel/transport mode. Actually, I have clearly stated that = the implementation I work with does support dynamic routing over an = IPsec tunnel, without any of the issues you describe in your draft.=20 Claudio. From exim@www1.ietf.org Tue Jan 27 19:35:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05149 for ; Tue, 27 Jan 2004 19:35:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aldfi-0006id-9B for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 19:35:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S0ZArc025821 for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 19:35:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aldfi-0006iO-54 for l3vpn-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 19:35:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05055 for ; Tue, 27 Jan 2004 19:35:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aldfg-0001nc-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 19:35:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlddT-0001G3-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 19:32:51 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Aldca-00012Q-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 19:31:56 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AldRY-00065H-Nh for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 19:20:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldGt-0001GA-QS; Tue, 27 Jan 2004 19:09:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlCcZ-0003n8-L5 for l3vpn@optimus.ietf.org; Mon, 26 Jan 2004 14:42:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17235 for ; Mon, 26 Jan 2004 14:42:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlCcW-0000Gj-00 for l3vpn@ietf.org; Mon, 26 Jan 2004 14:42:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlCbY-0000Dx-00 for l3vpn@ietf.org; Mon, 26 Jan 2004 14:41:05 -0500 Received: from [142.46.197.162] (helo=pion-smtp.jnpr.net) by ietf-mx with esmtp (Exim 4.12) id 1AlCaa-00009w-00 for l3vpn@ietf.org; Mon, 26 Jan 2004 14:40:04 -0500 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: draft-touch-ipsec-vpn-06.txt X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Mon, 26 Jan 2004 14:39:33 -0500 Message-ID: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DAED@pion.jnpr.net> Thread-Topic: draft-touch-ipsec-vpn-06.txt Thread-Index: AcPkMr0ALIJaiRnBQZSjRRsHuVA9cAAC1Hfg From: "Claudio Lordello" To: "Joe Touch" Cc: , "Ross Callon" , "Claudio Lordello" Content-Transfer-Encoding: quoted-printable Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > Joe Touch wrote: >=20 > Claudio Lordello wrote: >=20 > > Joe Touch wrote: > >=20 > >>MUST vs. MAY, in a sense. We're talking about what needs=20 > >>(MUST) be done=20 > >>so that the user can rely on dynamic routing working. > >> > >>Joe > >=20 > > You seem to be exchanging "MUST"'s and "MAY"'s.=20 > > The current version of RFC2401bis clearly states that > > IPsec SG's MUST implement tunnel mode and only MAY implement=20 > transport mode. > >=20 > > Claudio. >=20 > Yes. And where it does not, dynamic routing won't be=20 > supported. By since=20 > dynamic routing isn't a MUST, neither is transport mode at gateways. >=20 > Joe >=20 OK. In summary: this WG is asking comments as to whether or not it = should approve this draft, a draft which states that "IPsec tunnel mode = conflict with routing and forwarding inside a VN", when in fact, the = only mode that MUST be supported by SG's (i.e., routers), as established = by the IPsec WG, is actually tunnel mode. Claudio. From exim@www1.ietf.org Tue Jan 27 19:37:56 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05434 for ; Tue, 27 Jan 2004 19:37:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aldhx-00071x-4k for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 19:37:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S0bTiu027016 for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 19:37:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aldhw-00071f-Oi for l3vpn-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 19:37:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05405 for ; Tue, 27 Jan 2004 19:37:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aldhv-0002Le-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 19:37:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aldee-0001YI-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 19:34:05 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Aldd0-00019s-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 19:32:22 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AldQp-00062U-Uj for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 19:19:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ald9s-0007Pv-MI; Tue, 27 Jan 2004 19:02:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlAV0-0004BI-RR for l3vpn@optimus.ietf.org; Mon, 26 Jan 2004 12:26:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13642 for ; Mon, 26 Jan 2004 12:26:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlAUz-0001wm-00 for l3vpn@ietf.org; Mon, 26 Jan 2004 12:26:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlAU6-0001re-00 for l3vpn@ietf.org; Mon, 26 Jan 2004 12:25:14 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1AlAT4-0001me-00 for l3vpn@ietf.org; Mon, 26 Jan 2004 12:24:10 -0500 Received: from isi.edu (purple.cs.ucl.ac.uk [128.16.64.86]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i0QHO6v03014; Mon, 26 Jan 2004 09:24:06 -0800 (PST) Message-ID: <40154D37.9060807@isi.edu> Date: Mon, 26 Jan 2004 09:24:07 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Claudio Lordello CC: l3vpn@ietf.org, Ross Callon Subject: Re: draft-touch-ipsec-vpn-06.txt References: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DAE9@pion.jnpr.net> In-Reply-To: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DAE9@pion.jnpr.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Claudio Lordello wrote: > Joe Touch wrote: > >>MUST vs. MAY, in a sense. We're talking about what needs >>(MUST) be done >>so that the user can rely on dynamic routing working. >> >>Joe > > You seem to be exchanging "MUST"'s and "MAY"'s. > The current version of RFC2401bis clearly states that > IPsec SG's MUST implement tunnel mode and only MAY implement transport mode. > > Claudio. Yes. And where it does not, dynamic routing won't be supported. By since dynamic routing isn't a MUST, neither is transport mode at gateways. Joe From exim@www1.ietf.org Tue Jan 27 19:39:18 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05908 for ; Tue, 27 Jan 2004 19:39:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldjH-0007Kw-2T for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 19:38:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S0cotU028179 for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 19:38:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldjG-0007K6-0L for l3vpn-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 19:38:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05719 for ; Tue, 27 Jan 2004 19:38:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AldjE-0002g9-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 19:38:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aldg9-0001v9-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 19:35:38 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Alddh-0001LA-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 19:33:05 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AldRP-00062U-U6 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 19:20:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldHr-0001fy-WF; Tue, 27 Jan 2004 19:10:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlDp7-0008Kz-Us for l3vpn@optimus.ietf.org; Mon, 26 Jan 2004 15:59:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20148 for ; Mon, 26 Jan 2004 15:59:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlDp6-0003p6-00 for l3vpn@ietf.org; Mon, 26 Jan 2004 15:59:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlDoB-0003ni-00 for l3vpn@ietf.org; Mon, 26 Jan 2004 15:58:11 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1AlDnj-0003m7-00 for l3vpn@ietf.org; Mon, 26 Jan 2004 15:57:43 -0500 Received: from isi.edu (ras39.isi.edu [128.9.176.139]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i0QKvdv14016; Mon, 26 Jan 2004 12:57:39 -0800 (PST) Message-ID: <40157F4A.8020900@isi.edu> Date: Mon, 26 Jan 2004 12:57:46 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Claudio Lordello CC: l3vpn@ietf.org, Ross Callon Subject: Re: draft-touch-ipsec-vpn-06.txt References: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DAED@pion.jnpr.net> In-Reply-To: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DAED@pion.jnpr.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Claudio Lordello wrote: ... > OK. In summary: this WG is asking comments as to whether or not it > should approve this draft, Actually, since it's not a WG doc, the 'approval' isn't the option. What's being asked is whether the WG has issues with the doc in its current for, notably issues central to L3VPN. > a draft which states that "IPsec tunnel mode > conflict with routing and forwarding inside a VN", when in fact, the > only mode that MUST be supported by SG's (i.e., routers), as established > by the IPsec WG, is actually tunnel mode. That is an excellent point that has already been taken up with the IPsec WG. Your participation in that WG - notably on the update to RFC2401, would have been useful. Joe From exim@www1.ietf.org Tue Jan 27 19:40:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06340 for ; Tue, 27 Jan 2004 19:40:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldkV-0007cK-Jm for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 19:40:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S0e7Pb029242 for l3vpn-archive@odin.ietf.org; Tue, 27 Jan 2004 19:40:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldkP-0007aZ-RL for l3vpn-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 19:40:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06231 for ; Tue, 27 Jan 2004 19:39:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AldkN-0002xW-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 19:40:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AldiE-0002Pd-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 19:37:47 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Aldep-0001bW-00 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 19:34:15 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AldRs-00062U-19 for l3vpn-web-archive@ietf.org; Tue, 27 Jan 2004 19:20:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ald5M-0005Vv-A7; Tue, 27 Jan 2004 18:57:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al9MC-0000IU-K1 for l3vpn@optimus.ietf.org; Mon, 26 Jan 2004 11:13:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10859 for ; Mon, 26 Jan 2004 11:12:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al9MB-00058S-00 for l3vpn@ietf.org; Mon, 26 Jan 2004 11:12:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al9LE-000563-00 for l3vpn@ietf.org; Mon, 26 Jan 2004 11:12:01 -0500 Received: from [142.46.197.162] (helo=pion-smtp.jnpr.net) by ietf-mx with esmtp (Exim 4.12) id 1Al9KN-00051i-00 for l3vpn@ietf.org; Mon, 26 Jan 2004 11:11:07 -0500 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: draft-touch-ipsec-vpn-06.txt X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Mon, 26 Jan 2004 11:10:30 -0500 Message-ID: <6157E7BE4F8B9548AAE5EB84DBF5D46A36DAE9@pion.jnpr.net> Thread-Topic: draft-touch-ipsec-vpn-06.txt Thread-Index: AcPh+UvBcUqv7UTBRtG9lOSrwpmEkACLFiAw From: "Claudio Lordello" To: "Joe Touch" Cc: , "Ross Callon" , "Claudio Lordello" Content-Transfer-Encoding: quoted-printable Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Joe Touch wrote: > MUST vs. MAY, in a sense. We're talking about what needs=20 > (MUST) be done=20 > so that the user can rely on dynamic routing working. >=20 > Joe >=20 >=20 You seem to be exchanging "MUST"'s and "MAY"'s. The current version of = RFC2401bis clearly states that IPsec SG's MUST implement tunnel mode and = only MAY implement transport mode. Claudio. From exim@www1.ietf.org Wed Jan 28 12:27:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15517 for ; Wed, 28 Jan 2004 12:27:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AltSx-000779-8m for l3vpn-archive@odin.ietf.org; Wed, 28 Jan 2004 12:27:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SHR32N027346 for l3vpn-archive@odin.ietf.org; Wed, 28 Jan 2004 12:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AltSx-00076z-3T for l3vpn-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 12:27:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15502 for ; Wed, 28 Jan 2004 12:26:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AltSv-00037V-00 for l3vpn-web-archive@ietf.org; Wed, 28 Jan 2004 12:27:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AltS9-0002zD-00 for l3vpn-web-archive@ietf.org; Wed, 28 Jan 2004 12:26:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AltRG-0002nM-00 for l3vpn-web-archive@ietf.org; Wed, 28 Jan 2004 12:25:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AltR3-0006cY-5W; Wed, 28 Jan 2004 12:25:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AltQw-0006ah-3c for l3vpn@optimus.ietf.org; Wed, 28 Jan 2004 12:24:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15145 for ; Wed, 28 Jan 2004 12:24:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AltQu-0002jl-00 for l3vpn@ietf.org; Wed, 28 Jan 2004 12:24:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AltPO-0002Mi-00 for l3vpn@ietf.org; Wed, 28 Jan 2004 12:23:22 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1AltNf-0001xe-00 for l3vpn@ietf.org; Wed, 28 Jan 2004 12:21:35 -0500 Received: from isi.edu (purple.cs.ucl.ac.uk [128.16.64.86]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i0SHLUv12593; Wed, 28 Jan 2004 09:21:30 -0800 (PST) Message-ID: <4017EF9B.9060206@isi.edu> Date: Wed, 28 Jan 2004 09:21:31 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rahul Aggarwal CC: Eric Rosen , Ross Callon , l3vpn@ietf.org, Thomas Narten Subject: Re: draft-touch-ipsec-vpn-06.txt References: <200401221527.i0MFRb5g013225@rtp-core-2.cisco.com> <20040127104328.O69210@sapphire.juniper.net> In-Reply-To: <20040127104328.O69210@sapphire.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rahul Aggarwal wrote: > Hi Eric and WG, > > Comments inline: > > On Thu, 22 Jan 2004, Eric Rosen wrote: > > >>I think it would be useful to have an RFC which discusses the issues that >>arise when you want to use an IPsec Security Association as a routing >>adjacency. In fact, it might even be useful to have a standard way of doing >>this that would ensure multi-vendor interoperability. >> >>As Claudio points out, implementors do know how to do this, and there have >>been many products on the market for years that do this. Whether they do it >>in an interoperable manner is another question. Whether this is in >>violation of the IPsec standard is a further question. > > I would second the above. It is a question that has already been discussed in the IPsec WG, and they have suggested that we move forward with our draft. >>I'd have thought that a draft on this topic, even an informational draft, >>would need the approval of the IPsec WG. I am concerned about the fact that >>the IPsec WG has failed to progress this draft. This has been addressed already. ... >>With regard to the draft's relation to L3VPN, the L3VPN charter does >>unfortunately include "CE-based VPNs using IPsec". This has been addressed already - this doc is more general than CE-based VPNs. Whether it applies to L3VPNs at all should be an issue for a draft such as Knight's - which we've already suggested. That draft should have a normative reference on this issue in the more general case, which would be ours. Joe From exim@www1.ietf.org Wed Jan 28 13:17:19 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18110 for ; Wed, 28 Jan 2004 13:17:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AluFA-0004nD-Sq for l3vpn-archive@odin.ietf.org; Wed, 28 Jan 2004 13:16:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SIGqSw018417 for l3vpn-archive@odin.ietf.org; Wed, 28 Jan 2004 13:16:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AluFA-0004my-Mc for l3vpn-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 13:16:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18099 for ; Wed, 28 Jan 2004 13:16:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AluEy-0000VP-00 for l3vpn-web-archive@ietf.org; Wed, 28 Jan 2004 13:16:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AluD9-0000QH-00 for l3vpn-web-archive@ietf.org; Wed, 28 Jan 2004 13:14:48 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AluCP-0000LI-00 for l3vpn-web-archive@ietf.org; Wed, 28 Jan 2004 13:14:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AluCO-0004Zw-Ss; Wed, 28 Jan 2004 13:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AluC3-0004Xa-7S for l3vpn@optimus.ietf.org; Wed, 28 Jan 2004 13:13:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17997 for ; Wed, 28 Jan 2004 13:13:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AluC1-0000Ij-00 for l3vpn@ietf.org; Wed, 28 Jan 2004 13:13:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AluB2-0000Bw-00 for l3vpn@ietf.org; Wed, 28 Jan 2004 13:12:37 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AluA4-00000s-00 for l3vpn@ietf.org; Wed, 28 Jan 2004 13:11:36 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 28 Jan 2004 10:11:07 -0800 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i0SIB3nG027861; Wed, 28 Jan 2004 10:11:03 -0800 (PST) Message-Id: <200401281811.i0SIB3nG027861@sj-core-4.cisco.com> To: Joe Touch cc: Rahul Aggarwal , Ross Callon , l3vpn@ietf.org, Thomas Narten Subject: Re: draft-touch-ipsec-vpn-06.txt In-reply-to: Your message of Wed, 28 Jan 2004 09:21:31 -0800. <4017EF9B.9060206@isi.edu> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Wed, 28 Jan 2004 13:11:03 -0500 From: Eric Rosen Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Joe> That draft should have a normative reference on this issue in the more Joe> general case, which would be ours. This is the sort of statement that concerns me; it seems to me that if you are requesting publication of an individual draft as an informational RFC, you cannot then demand (or even expect) that any standards document will ever have a normative reference to it. People should feel free to ignore it or not, as they see fit. From exim@www1.ietf.org Wed Jan 28 13:19:19 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18164 for ; Wed, 28 Jan 2004 13:19:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AluH7-00051Y-Q4 for l3vpn-archive@odin.ietf.org; Wed, 28 Jan 2004 13:18:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SIIrC1019306 for l3vpn-archive@odin.ietf.org; Wed, 28 Jan 2004 13:18:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AluH7-00051J-Kf for l3vpn-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 13:18:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18151 for ; Wed, 28 Jan 2004 13:18:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AluH0-0000hN-00 for l3vpn-web-archive@ietf.org; Wed, 28 Jan 2004 13:18:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AluFl-0000Zo-00 for l3vpn-web-archive@ietf.org; Wed, 28 Jan 2004 13:17:30 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AluDN-0000R3-00 for l3vpn-web-archive@ietf.org; Wed, 28 Jan 2004 13:15:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AluDO-0004fq-Nv; Wed, 28 Jan 2004 13:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AluD9-0004es-U3 for l3vpn@optimus.ietf.org; Wed, 28 Jan 2004 13:14:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18080 for ; Wed, 28 Jan 2004 13:14:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AluD7-0000Q4-00 for l3vpn@ietf.org; Wed, 28 Jan 2004 13:14:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AluCG-0000LA-00 for l3vpn@ietf.org; Wed, 28 Jan 2004 13:13:52 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1AluBq-0000FD-00 for l3vpn@ietf.org; Wed, 28 Jan 2004 13:13:26 -0500 Received: from isi.edu (purple.cs.ucl.ac.uk [128.16.64.86]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i0SIDNv11172; Wed, 28 Jan 2004 10:13:23 -0800 (PST) Message-ID: <4017FBC4.9010701@isi.edu> Date: Wed, 28 Jan 2004 10:13:24 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Rosen CC: Rahul Aggarwal , Ross Callon , l3vpn@ietf.org, Thomas Narten Subject: Re: draft-touch-ipsec-vpn-06.txt References: <200401281811.i0SIB3nG027861@sj-core-4.cisco.com> In-Reply-To: <200401281811.i0SIB3nG027861@sj-core-4.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric Rosen wrote: > Joe> That draft should have a normative reference on this issue in the more > Joe> general case, which would be ours. > > This is the sort of statement that concerns me; it seems to me that if you > are requesting publication of an individual draft as an informational RFC, > you cannot then demand (or even expect) that any standards document will > ever have a normative reference to it. People should feel free to ignore it > or not, as they see fit. Normative refs aren't just for standards. FWIW, I wasn't requiring a normative ref (SHOULD, not MUST - perhaps I should have used caps?). I was suggesting it. The utility of a ref would be that the Knight doc could focus on the L3VPN-specific issues, rather than recapitulating them. In that case, the ref would be normative in citing the explainations - not necessarily agreeing with them. Joe From exim@www1.ietf.org Wed Jan 28 13:24:08 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18423 for ; Wed, 28 Jan 2004 13:24:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AluLm-0005O6-Ly for l3vpn-archive@odin.ietf.org; Wed, 28 Jan 2004 13:23:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SINgIC020704 for l3vpn-archive@odin.ietf.org; Wed, 28 Jan 2004 13:23:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AluLl-0005Nr-Up for l3vpn-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 13:23:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18356 for ; Wed, 28 Jan 2004 13:23:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AluLk-0001DH-00 for l3vpn-web-archive@ietf.org; Wed, 28 Jan 2004 13:23:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AluKx-000177-00 for l3vpn-web-archive@ietf.org; Wed, 28 Jan 2004 13:22:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AluKC-00011c-00 for l3vpn-web-archive@ietf.org; Wed, 28 Jan 2004 13:22:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AluK8-0005AB-W1; Wed, 28 Jan 2004 13:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AluJW-00058m-Pu for l3vpn@optimus.ietf.org; Wed, 28 Jan 2004 13:21:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18210 for ; Wed, 28 Jan 2004 13:21:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AluJP-0000tr-00 for l3vpn@ietf.org; Wed, 28 Jan 2004 13:21:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AluGr-0000jP-00 for l3vpn@ietf.org; Wed, 28 Jan 2004 13:18:38 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1AluG3-0000dU-00 for l3vpn@ietf.org; Wed, 28 Jan 2004 13:17:47 -0500 Received: from isi.edu (purple.cs.ucl.ac.uk [128.16.64.86]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i0SIHPv15799; Wed, 28 Jan 2004 10:17:25 -0800 (PST) Message-ID: <4017FCB5.4070909@isi.edu> Date: Wed, 28 Jan 2004 10:17:25 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Touch CC: Eric Rosen , Rahul Aggarwal , Ross Callon , l3vpn@ietf.org, Thomas Narten Subject: Re: draft-touch-ipsec-vpn-06.txt References: <200401281811.i0SIB3nG027861@sj-core-4.cisco.com> <4017FBC4.9010701@isi.edu> In-Reply-To: <4017FBC4.9010701@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Joe Touch wrote: > Eric Rosen wrote: > >> Joe> That draft should have a normative reference on this issue in >> the more >> Joe> general case, which would be ours. >> This is the sort of statement that concerns me; it seems to me that >> if you >> are requesting publication of an individual draft as an >> informational RFC, >> you cannot then demand (or even expect) that any standards >> document will >> ever have a normative reference to it. People should feel free to >> ignore it >> or not, as they see fit. > > > Normative refs aren't just for standards. To be more specific, see: http://www.rfc-editor.org/policy.html#policy.refs "Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work." From exim@www1.ietf.org Wed Jan 28 13:39:10 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19161 for ; Wed, 28 Jan 2004 13:39:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AluaI-0006iU-Dk for l3vpn-archive@odin.ietf.org; Wed, 28 Jan 2004 13:38:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SIcgHA025812 for l3vpn-archive@odin.ietf.org; Wed, 28 Jan 2004 13:38:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AluaI-0006iF-6Q for l3vpn-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 13:38:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19147 for ; Wed, 28 Jan 2004 13:38:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AluaG-0002gB-00 for l3vpn-web-archive@ietf.org; Wed, 28 Jan 2004 13:38:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AluZK-0002bk-00 for l3vpn-web-archive@ietf.org; Wed, 28 Jan 2004 13:37:43 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AluYh-0002XE-00 for l3vpn-web-archive@ietf.org; Wed, 28 Jan 2004 13:37:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AluYe-0006K3-Hy; Wed, 28 Jan 2004 13:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AluYP-0006J6-0s for l3vpn@optimus.ietf.org; Wed, 28 Jan 2004 13:36:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19097 for ; Wed, 28 Jan 2004 13:36:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AluYM-0002WP-00 for l3vpn@ietf.org; Wed, 28 Jan 2004 13:36:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AluXS-0002Ro-00 for l3vpn@ietf.org; Wed, 28 Jan 2004 13:35:46 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AluX1-0002MU-00 for l3vpn@ietf.org; Wed, 28 Jan 2004 13:35:19 -0500 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i0SIYknG027800; Wed, 28 Jan 2004 10:34:46 -0800 (PST) Message-Id: <200401281834.i0SIYknG027800@sj-core-4.cisco.com> To: Joe Touch cc: Rahul Aggarwal , Ross Callon , l3vpn@ietf.org, Thomas Narten Subject: Re: draft-touch-ipsec-vpn-06.txt In-reply-to: Your message of Wed, 28 Jan 2004 10:17:25 -0800. <4017FCB5.4070909@isi.edu> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Wed, 28 Jan 2004 13:34:46 -0500 From: Eric Rosen Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 > "Normative references specify documents that must be read to understand > or implement the technology in the new RFC, or whose technology must be > present for the technology in the new RFC to work." I have a hard time seeing how your document would fall into this category. I just want to be sure we are not setting the stage for a continuing series of future conflicts regarding this document. From exim@www1.ietf.org Wed Jan 28 13:57:23 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20005 for ; Wed, 28 Jan 2004 13:57:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alurv-0007ND-Th for l3vpn-archive@odin.ietf.org; Wed, 28 Jan 2004 13:56:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SIutL0028337 for l3vpn-archive@odin.ietf.org; Wed, 28 Jan 2004 13:56:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alurv-0007My-NM for l3vpn-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 13:56:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19961 for ; Wed, 28 Jan 2004 13:56:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alurt-0004ON-00 for l3vpn-web-archive@ietf.org; Wed, 28 Jan 2004 13:56:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aluqz-0004Gp-00 for l3vpn-web-archive@ietf.org; Wed, 28 Jan 2004 13:55:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aluq9-0004A8-00 for l3vpn-web-archive@ietf.org; Wed, 28 Jan 2004 13:55:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aluq8-0007Ei-A5; Wed, 28 Jan 2004 13:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alupt-0007CN-OV for l3vpn@optimus.ietf.org; Wed, 28 Jan 2004 13:54:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19815 for ; Wed, 28 Jan 2004 13:54:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alupr-00048E-00 for l3vpn@ietf.org; Wed, 28 Jan 2004 13:54:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aluou-00041Q-00 for l3vpn@ietf.org; Wed, 28 Jan 2004 13:53:48 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1Alunr-0003ug-00 for l3vpn@ietf.org; Wed, 28 Jan 2004 13:52:43 -0500 Received: from isi.edu (purple.cs.ucl.ac.uk [128.16.64.86]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i0SIqdv28985; Wed, 28 Jan 2004 10:52:39 -0800 (PST) Message-ID: <401804F6.1010408@isi.edu> Date: Wed, 28 Jan 2004 10:52:38 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: erosen@cisco.com CC: Rahul Aggarwal , Ross Callon , l3vpn@ietf.org, Thomas Narten Subject: Re: draft-touch-ipsec-vpn-06.txt References: <200401281834.i0SIYknG027800@sj-core-4.cisco.com> In-Reply-To: <200401281834.i0SIYknG027800@sj-core-4.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric Rosen wrote: >>"Normative references specify documents that must be read to understand >>or implement the technology in the new RFC, or whose technology must be >>present for the technology in the new RFC to work." > > > I have a hard time seeing how your document would fall into this category. "read to understand" - even if it's a differing viewpoint, it is one that was vetted through IPsec. If you don't feel it should be cited, then don't. > I just want to be sure we are not setting the stage for a continuing series > of future conflicts regarding this document. Agreed. But as an individual informational submission, there should be no conflict in that regard. You are always welcome to disagree. Joe From exim@www1.ietf.org Fri Jan 30 11:53:41 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27332 for ; Fri, 30 Jan 2004 11:53:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmbtK-0001KJ-7Y for l3vpn-archive@odin.ietf.org; Fri, 30 Jan 2004 11:53:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UGrEeo005093 for l3vpn-archive@odin.ietf.org; Fri, 30 Jan 2004 11:53:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmbtK-0001K1-4D for l3vpn-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 11:53:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27207 for ; Fri, 30 Jan 2004 11:53:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmbtJ-0006US-00 for l3vpn-web-archive@ietf.org; Fri, 30 Jan 2004 11:53:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmbsK-0006JS-00 for l3vpn-web-archive@ietf.org; Fri, 30 Jan 2004 11:52:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmbrL-00066v-00 for l3vpn-web-archive@ietf.org; Fri, 30 Jan 2004 11:51:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmbrE-0000YN-9n; Fri, 30 Jan 2004 11:51:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ambqb-0000VL-6W for l3vpn@optimus.ietf.org; Fri, 30 Jan 2004 11:50:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26912; Fri, 30 Jan 2004 11:50:21 -0500 (EST) Message-Id: <200401301650.LAA26912@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: l3vpn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-generic-reqts-02.txt Date: Fri, 30 Jan 2004 11:50:21 -0500 Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. Title : Generic Requirements for Provider Provisioned Virtual Private Networks Author(s) : A. Nagarajan Filename : draft-ietf-l3vpn-generic-reqts-02.txt Pages : 26 Date : 2004-1-29 This document describes generic requirements for Provider Provisioned Virtual Private Networks (PPVPN). The requirements are categorized into service requirements, provider requirements and engineering requirements. These requirements are not specific to any particular type of PPVPN technology, but rather apply to all PPVPN technologies. All PPVPN technologies are expected to meet the umbrella set of requirements described in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-generic-reqts-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l3vpn-generic-reqts-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l3vpn-generic-reqts-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-30121107.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-generic-reqts-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-generic-reqts-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-30121107.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Fri Jan 30 11:53:43 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27349 for ; Fri, 30 Jan 2004 11:53:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmbtL-0001Kb-Tv for l3vpn-archive@odin.ietf.org; Fri, 30 Jan 2004 11:53:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UGrFVX005111 for l3vpn-archive@odin.ietf.org; Fri, 30 Jan 2004 11:53:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmbtL-0001KM-QW for l3vpn-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 11:53:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27211 for ; Fri, 30 Jan 2004 11:53:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmbtK-0006Ug-00 for l3vpn-web-archive@ietf.org; Fri, 30 Jan 2004 11:53:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmbsL-0006Ja-00 for l3vpn-web-archive@ietf.org; Fri, 30 Jan 2004 11:52:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmbrL-000670-00 for l3vpn-web-archive@ietf.org; Fri, 30 Jan 2004 11:51:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmbrE-0000YV-R7; Fri, 30 Jan 2004 11:51:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ambqg-0000Vi-FK for l3vpn@optimus.ietf.org; Fri, 30 Jan 2004 11:50:30 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26928; Fri, 30 Jan 2004 11:50:27 -0500 (EST) Message-Id: <200401301650.LAA26928@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: l3vpn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-mpls-vpn-mib-01.txt Date: Fri, 30 Jan 2004 11:50:26 -0500 Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. Title : MPLS/BGP Layer 3 Virtual Private Network Management Information Base Using Author(s) : T. Nadeau Filename : draft-ietf-l3vpn-mpls-vpn-mib-01.txt Pages : 35 Date : 2004-1-29 This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor Multi-protocol Label Switching Layer-3 Virtual Private Networks on a Multi-Protocol Label Switching (MPLS) Label Switching Router (LSR) supporting this feature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-mpls-vpn-mib-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l3vpn-mpls-vpn-mib-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l3vpn-mpls-vpn-mib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-30121115.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-mpls-vpn-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-mpls-vpn-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-30121115.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Fri Jan 30 13:55:08 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08395 for ; Fri, 30 Jan 2004 13:55:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amdmq-0003z7-2S for l3vpn-archive@odin.ietf.org; Fri, 30 Jan 2004 13:54:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UIseqs015282 for l3vpn-archive@odin.ietf.org; Fri, 30 Jan 2004 13:54:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amdmp-0003yD-Po for l3vpn-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 13:54:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08387 for ; Fri, 30 Jan 2004 13:54:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amdmn-0003uY-00 for l3vpn-web-archive@ietf.org; Fri, 30 Jan 2004 13:54:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amdlm-0003lU-00 for l3vpn-web-archive@ietf.org; Fri, 30 Jan 2004 13:53:35 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmdlH-0003dW-00 for l3vpn-web-archive@ietf.org; Fri, 30 Jan 2004 13:53:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmdlF-0008S2-Rx; Fri, 30 Jan 2004 13:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amdke-00070X-07 for l3vpn@optimus.ietf.org; Fri, 30 Jan 2004 13:52:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08223 for ; Fri, 30 Jan 2004 13:52:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amdkb-0003Zp-00 for l3vpn@ietf.org; Fri, 30 Jan 2004 13:52:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amdjb-0003QB-00 for l3vpn@ietf.org; Fri, 30 Jan 2004 13:51:19 -0500 Received: from omzesmtp03.mci.com ([199.249.17.11]) by ietf-mx with esmtp (Exim 4.12) id 1Amdid-00039k-00 for l3vpn@ietf.org; Fri, 30 Jan 2004 13:50:19 -0500 Received: from dgismtp06.wcomnet.com ([166.38.58.89]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HSB00G03FYXXO@firewall.mci.com> for l3vpn@ietf.org; Fri, 30 Jan 2004 18:42:36 +0000 (GMT) Received: from dgismtp06.wcomnet.com by dgismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HSB00G01FY58X@dgismtp06.mcilink.com> for l3vpn@ietf.org; Fri, 30 Jan 2004 18:42:34 +0000 (GMT) Received: from ws344v1681 ([166.32.199.163]) by dgismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HSB00G32FYT4J@dgismtp06.mcilink.com> for l3vpn@ietf.org; Fri, 30 Jan 2004 18:42:30 +0000 (GMT) Date: Fri, 30 Jan 2004 13:42:30 -0500 From: Ronald Bonica Subject: WG Last Call: draft-ietf-l3vpn-mpls-vpn-mib-01 To: l3vpn@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, This message initiates a WG last call on draft-ietf-l3vpn-mpls-vpn-mib-01. The last call will end on February 13. Ron -----Original Message----- From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: Friday, January 30, 2004 11:50 AM To: IETF-Announce: Cc: l3vpn@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-mpls-vpn-mib-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. Title : MPLS/BGP Layer 3 Virtual Private Network Management Information Base Using Author(s) : T. Nadeau Filename : draft-ietf-l3vpn-mpls-vpn-mib-01.txt Pages : 35 Date : 2004-1-29