From exim@www1.ietf.org Fri Aug 1 11:21:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAB26279 for ; Fri, 1 Aug 2003 11:21:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ibiL-0007Mo-8Z for l3vpn-archive@odin.ietf.org; Fri, 01 Aug 2003 11:21:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71FL57I028314 for l3vpn-archive@odin.ietf.org; Fri, 1 Aug 2003 11:21:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ibiL-0007Mb-5I for l3vpn-web-archive@optimus.ietf.org; Fri, 01 Aug 2003 11:21:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26249 for ; Fri, 1 Aug 2003 11:21:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ibiK-0003JR-00 for l3vpn-web-archive@ietf.org; Fri, 01 Aug 2003 11:21:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ibiJ-0003JN-00 for l3vpn-web-archive@ietf.org; Fri, 01 Aug 2003 11:21:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ibiH-0007LO-Vw; Fri, 01 Aug 2003 11:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ibhY-0007Kg-Ra for l3vpn@optimus.ietf.org; Fri, 01 Aug 2003 11:20:16 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26186; Fri, 1 Aug 2003 11:20:12 -0400 (EDT) Message-Id: <200308011520.LAA26186@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-00.txt Date: Fri, 01 Aug 2003 11:20:12 -0400 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: , --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 et al. Filename : draft-ietf-l3vpn-mgt-fwk-00.txt Pages : 24 Date : 2003-7-31 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-00.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-00.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-00.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: <2003-7-31120505.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-mgt-fwk-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-mgt-fwk-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-31120505.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Fri Aug 1 16:59:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12041 for ; Fri, 1 Aug 2003 16:59:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19igzQ-0006KU-6S for l3vpn-archive@odin.ietf.org; Fri, 01 Aug 2003 16:59:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71Kx4bk024326 for l3vpn-archive@odin.ietf.org; Fri, 1 Aug 2003 16:59:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19igzQ-0006KH-2n for l3vpn-web-archive@optimus.ietf.org; Fri, 01 Aug 2003 16:59:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12032 for ; Fri, 1 Aug 2003 16:58:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19igzO-0006p2-00 for l3vpn-web-archive@ietf.org; Fri, 01 Aug 2003 16:59:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19igzN-0006ow-00 for l3vpn-web-archive@ietf.org; Fri, 01 Aug 2003 16:59:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19igzN-0006JK-Kf; Fri, 01 Aug 2003 16:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19icAA-0008Mu-WF for l3vpn@optimus.ietf.org; Fri, 01 Aug 2003 11:49:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27139; Fri, 1 Aug 2003 11:49:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19icA9-0003U5-00; Fri, 01 Aug 2003 11:49:49 -0400 Received: from [12.38.212.174] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19icA8-0003U1-00; Fri, 01 Aug 2003 11:49:48 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id h71FndRp013714; Fri, 1 Aug 2003 11:49:42 -0400 Message-Id: <200308011549.h71FndRp013714@mailhost.avici.com> To: raszuk@cisco.com cc: Routing Discussion , L3VPN Reply-To: curtis@fictitious.org Subject: Re: Sequence control of distributed information In-reply-to: Your message of "Thu, 31 Jul 2003 19:11:03 +0200." <3F294DA7.C44114F9@cisco.com> Date: Fri, 01 Aug 2003 11:49:37 -0400 From: Curtis Villamizar 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: , In message <3F294DA7.C44114F9@cisco.com>, Robert Raszuk writes: > > Let me try to probe operators about one element which may become much > harder to achive when moving some data out of BGP umbrella. Under a > numerous conversations I have heard requests asking for allowing > operator to tightly control the order of information being distributed > by BGP for example: vpnv4 routes first then ipv4 routes or ipv4 routes > first followed by mutlicast routes etc ... > > When all AFs are under the same BGP umbrella that request can be very > easy to deliver with a simple knob. When we separate future - non > routing data - I could easily see the case that +100K ipv4 routes is > competing with +100K telefon numbers to be send between routers. There > would be no easy way to allow priority control other then low level CPU > resources allocations to each process. Even that it would be usually > difficult to achive full task serialization on a more granular level > that fully blocking given's process resources. That will in turn result > in explosion of separate processes almost per task and managment of > those will for sure provide very stable platforms :). > > Bottom line - the question is - do we all agree that the only required > mode of operation is fairness in distribution of all kinds of > information between routers ? > > Cheers, > R. Some implementations are smart enough to prioritize packing IGP routes into BGP updates (when redistributed to EBGP) and provide other heuristics for updating "more important" information first. Installing IGP routes in the hardware first is probably universal among successful routers. It would be a simple enough matter to pack BGP updates full of IPv4 routes before other information or to provide internal scheduling whether that other information was within BGP or in another protocol. Fairness in distribution of all kinds of information does not currently exist. It is not a goal. Control over the allocation of resources by protocol and/or data type might be a goal in the future, but being fair might not be the outcome. Curtis From exim@www1.ietf.org Fri Aug 1 16:59:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12055 for ; Fri, 1 Aug 2003 16:59:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19igzQ-0006M4-In for l3vpn-archive@odin.ietf.org; Fri, 01 Aug 2003 16:59:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71Kx4Sb024422 for l3vpn-archive@odin.ietf.org; Fri, 1 Aug 2003 16:59:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19igzP-0006KF-U8 for l3vpn-web-archive@optimus.ietf.org; Fri, 01 Aug 2003 16:59:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12029 for ; Fri, 1 Aug 2003 16:58:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19igzN-0006oz-00 for l3vpn-web-archive@ietf.org; Fri, 01 Aug 2003 16:59:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19igzN-0006ov-00 for l3vpn-web-archive@ietf.org; Fri, 01 Aug 2003 16:59:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19igzN-0006J7-BP; Fri, 01 Aug 2003 16:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iaau-0005Di-Po for l3vpn@optimus.ietf.org; Fri, 01 Aug 2003 10:09:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22796; Fri, 1 Aug 2003 10:09:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iaas-0002i2-00; Fri, 01 Aug 2003 10:09:18 -0400 Received: from zlpmail.furukawa.co.jp ([158.202.43.12] helo=datacoa.net) by ietf-mx with esmtp (Exim 4.12) id 19iaaq-0002hw-00; Fri, 01 Aug 2003 10:09:16 -0400 X-ZLAuthOn: Received: from kireeti@datacoa.net (EHLO inf-gw.inf.furukawa.co.jp 158.202.50.19 [158.202.50.19] (may be forged)) by zlpWeb.furukawa.co.jp with ESMTP id AHKDEPKENVIAMHMBKIH1P0NTHYDSF1APEBAINUOO for <>; 01 Aug 2003 23:05:46 +0900 (JST) Received: from k_morita (hirame.inf.furukawa.co.jp [158.202.232.116]) by inf-gw.inf.furukawa.co.jp (8.9.3/3.7W-SYSTEM CENTER MAIL SERVER 1.0) with SMTP id XAA16098; Fri, 1 Aug 2003 23:05:30 +0900 (JST) Date: Fri, 1 Aug 2003 23:05:30 +0900 (JST) Message-Id: <200308011405.XAA16098@inf-gw.inf.furukawa.co.jp> From: Kireeti Kompella Subject: Re: draft-rosen-mpls-in-ip-or-gre-00.txt MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------16FOISFCLUW83K" 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: , ------------16FOISFCLUW83K Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Loa, On Mon, 16 Dec 2002, Loa Andersson wrote: > it is > the wg chairs intention to make this draft a wg document. Works for me. Kireeti. From exim@www1.ietf.org Fri Aug 1 18:00:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13994 for ; Fri, 1 Aug 2003 18:00:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ihwT-0001bo-T7 for l3vpn-archive@odin.ietf.org; Fri, 01 Aug 2003 18:00:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71M05Mu006183 for l3vpn-archive@odin.ietf.org; Fri, 1 Aug 2003 18:00:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ihwT-0001ba-Mb for l3vpn-web-archive@optimus.ietf.org; Fri, 01 Aug 2003 18:00:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13940 for ; Fri, 1 Aug 2003 18:00:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ihwQ-0007GN-00 for l3vpn-web-archive@ietf.org; Fri, 01 Aug 2003 18:00:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ihwQ-0007GK-00 for l3vpn-web-archive@ietf.org; Fri, 01 Aug 2003 18:00:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ihwP-0001YW-IZ; Fri, 01 Aug 2003 18:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ihvW-0001XE-IA for l3vpn@optimus.ietf.org; Fri, 01 Aug 2003 17:59:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13924 for ; Fri, 1 Aug 2003 17:59:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ihvT-0007Fz-00 for l3vpn@ietf.org; Fri, 01 Aug 2003 17:59:03 -0400 Received: from vmmrnat.verisignmail.com ([216.168.230.187] helo=vmmr7.verisignmail.com) by ietf-mx with esmtp (Exim 4.12) id 19ihvT-0007Fw-00 for l3vpn@ietf.org; Fri, 01 Aug 2003 17:59:03 -0400 Received: from ms7.verisignmail.com (ms7.verisignmail.com [216.168.230.174] (may be forged)) by vmmr7.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id OZA45938; Fri, 1 Aug 2003 17:59:02 -0400 (EDT) Received: from khumbu ([65.211.67.100]) by ms7.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ALM39796; Fri, 1 Aug 2003 17:59:02 -0400 (EDT) From: "Eric W Gray" To: Subject: RE: WG Focus Item - draft-fang-ppvpn-security-framework-01.txt Date: Fri, 1 Aug 2003 17:59:54 -0400 Message-ID: <013b01c35878$3d954b60$6901a8c0@khumbu> 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, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Draft Authors, Overall, the draft provides lots of useful information, is well written and easy to read. I have some specific comments and questions. Introduction, second paragraph: in the statement "We consider security issues deriving both from malicious behavior of users and other parties and from negligent or incorrect behavior of the providers", I assume it is not the intent to exclude from consideration any security issues that derive from negligent or incorrect behavior on the part of users and other parties - is that correct? Or is it implied that such user behavior either falls into the category of "negligent or incorrect behavior of the providers" (if it is allowed to introduce a security issue) or out of scope (because it's what the user does to themselves)? Introduction, third paragraph, last sentence: there is a part of this that is redundant over the previous sentence - i.e. "make it secure so it can provide the PPVPN services." I think a separate provider requirement to protect their network such that they can provide services in addition to PPVPN. Security Reference Model, second paragraph: a PPVPN service over the Internet seems a non-sequitur except to the extent that a provider is able to provision the Internet (the PP part of PPVPN). It seems to me that what is addressed here is a set of zero or more PPVPN services connected by a VPN service and I assume that VPN security in general is out of scope in this document. Security Reference Model, fifth paragraph: the discussion of extranets seems to imply the need for tiered trust models instead of a simplistic trusted or not trusted model. At the very least it is clear that different definitions may apply to what it means to be "trusted". Security Reference Model, last paragraph: we may want to at least include the analysis for attacks from the Internet to a server of a given PPVPN user that we use to conclude that provisioning methods cannot affect exposure. Middle of page 6, second set of bullets (especially the 4th and 5th bullets) and following paragraph: these seem to imply a distinct separation of VPNs and the Internet. Most VPNs would be connected to the Internet (either as part of the PPVPN service, or via another means) and a compromise of any VPN could make possible any compromise from the Internet that would be possible from that VPN. In the case where Internet access is not via the same PPVPN provider, avoidance of compromise from the Internet via the VPN itself is not within the purview of the PPVPN provider and - therefore - may not be a separable threat. This may be a problem in the first paragraph in section 4.5 on page 18 as well ("even if VPN services make use of a separate network from Internet services"). A seeming separation of VPN and Internet services from the service provider's perspective may not actually exist. Last few paragraphs on page 6: it would be clearer to use "attacks" rather than "threats" with respect to occurrence and ease of mounting. Attacks on the Data Plane, several points: The specific classifications used lead to ambiguities which may complicate the process of picking a solution. For example, replay should involve both unauthorized observation and insertion of illegitimate data traffic (replay may actually involve authentic data - in so far as authenticity can be determined using some forms of authentication - even if replay traffic is illegitimate). Unauthorized observation, modification and deletion are fundamentally different forms of attack, possibly making the grouping of them ambiguous. We probably want to recognize that several of these attacks stem from unauthorized observation (modification does, but deletion may not, traffic pattern analysis is an attack only if it derives from unauthorized observation, replay can only occur if observation - presumably unauthorized - can occur, etc.). Impersonation is not necessarily an attack against the data plane. Attacks on the Control Plane: cross-connection of traffic between PPVPNs is not an attack against the control plane as much as it is a failure of the control plane (if you extend the concept to potentially include the operator) and an attack against the data plane (a combination of unauthorized observation and insertion of illegitimate traffic). A possible exception might be for any network element whose control plane may be tied up in attempting to correct the cross-connection - which seems unlikely to be a common case. Attacks on Address Space Separation: it is not clear what is meant here. Clearly addresses may exist independently in more than one VPN (this is what is referred to as Address Separation in section 6.1.1), so what is address space in this context? Defensive Techniques: in addition to discussion of inherent limitations of defense in general, it would help if this section also included at least a list of the techniques that would be discussed in its subsections - possibly including a brief description of each technique. This would be helpful, for example, when "other defensive techniques" are mentioned in "Cryptographic Techniques". Cryptographic techniques - several points: What cryptographic techniques are referred to in this section other than encryption (and - by implication - decryption)? Is traffic separation considered a cryptographic technique? Is authentication? Perhaps the section should be called "Encryption"? Yes, privacy is important in a VPN, but the very term VPN over-loads the meaning of privacy to include more than avoidance of unauthorized observation and noise. Private, in the VPN sense also implies a perception of some amount of being "alone" (in terms of availability of service). This is implied in the list of threats that apply to a PPVPN service (which includes DoS as distinct from DoS applied to non-VPN services). Hence, traffic separation and encryption are insufficient to ensure privacy. Authentication may help but appears to be excluded as a cryptographic technique that might be used to secure privacy. I disagree with the conclusion of the paragraph at the top of page 11 - largely because of the first sentence in the very next paragraph. For trust reasons mentioned in the next paragraph, a user wishing to use encryption to avoid unauthorized observation of their traffic is unlikely to want it to be done by someone else, at that someone else's discretion and subject to that someone else's policies and regulatory restrictions. This will be true irrespective of some intrinsic value of the encryption service or any perceived ease with which a service may be able to provide encryption as a feature. Hence the ability of encryption to reduce exposure to certain threats is unlikely to directly motivate making encryption a common service offering in PPVPN. It seems more likely that a user who wants to employ encryption will do so themselves (using mechanisms under their own administrative control) and a user who does not will not necessarily be willing to pay for it even if it is done by someone else, for relatively low cost. Authentication: in this section (4.2), authentication is listed as a cryptographic technique yet authentication receives minimal attention in the section addressing cryptographic techniques (4.1). Perhaps a forward reference might be made in section 4.1? Cryptographic techniques for authenticating identity: the statement "Digital certificates using a hierarchical Certificate Authority system are among the most useful systems, but they require significant investment in infrastructure, and have not been universally deployed" seems to contain at least one subjective valuation that does not add much to the document. Perhaps it should be replaced by a statement similar to the following - "Another approach is to use a hierarchical Certificate Authority system to provide digital certificates." Integrity (section 6.5): the user requirement here is - "Data in transit must be secured such that it cannot be altered." Cryptography may be one approach for meeting this requirement. Anti-Replay (section 6.6): the user requirement here is - "Data in transit must be secured such that it cannot be recorded and replayed later." Cryptography may be one approach for meeting this requirement. Evaluating the Template (section 8.1): I do not understand the statement "In the VPN approach, the requirement is addressed in a way that is beyond the scope of the VPN approach." It seems to me that "addressed" and "out of scope" are mutually exclusive concepts. Template (section 8.2): 1 and 2 might be clearer if they were worded as - " 1. The approach provides complete IP address separation for each L3 VPN. " 2. The approach provides complete L2 address separation for each L2 VPN. " 3. The approach provides complete VLAN ID separation for each VPN. " 4. The approach provides complete IP route separation for each VPN. " 5. The approach provides complete L2 forwarding separation for each VPN." In particular, 4 and 5 should address what is separated for each VPN (forwarding) as opposed to how it is separated (separate tables as opposed to other approaches). Template (section 9, a and b): should require precise values (or state that it is operator definable) for "excessive". Template (section 15): should read something like - " 15. The approach provides protection against unauthorized traffic pattern analysis for PPVPN user data." From exim@www1.ietf.org Wed Aug 6 10:41:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18996 for ; Wed, 6 Aug 2003 10:41:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPTL-0008VX-Nu for l3vpn-archive@odin.ietf.org; Wed, 06 Aug 2003 10:41:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Ef3pS032699 for l3vpn-archive@odin.ietf.org; Wed, 6 Aug 2003 10:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPTL-0008VK-Ko for l3vpn-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 10:41:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18966 for ; Wed, 6 Aug 2003 10:40:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kPTJ-0003J0-00 for l3vpn-web-archive@ietf.org; Wed, 06 Aug 2003 10:41:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kPTI-0003Iw-00 for l3vpn-web-archive@ietf.org; Wed, 06 Aug 2003 10:41:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPTJ-0008Um-6Y; Wed, 06 Aug 2003 10:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPTI-0008UV-0s for l3vpn@optimus.ietf.org; Wed, 06 Aug 2003 10:41:00 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18952; Wed, 6 Aug 2003 10:40:54 -0400 (EDT) Message-Id: <200308061440.KAA18952@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-01.txt Date: Wed, 06 Aug 2003 10:40:54 -0400 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: , --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 VPN Author(s) : A. Nagarajan Filename : draft-ietf-l3vpn-generic-reqts-01.txt Pages : 23 Date : 2003-8-6 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-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-generic-reqts-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-generic-reqts-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: <2003-8-6095954.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-generic-reqts-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-generic-reqts-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-6095954.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Wed Aug 6 11:16:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20983 for ; Wed, 6 Aug 2003 11:16:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQ1S-0001ng-4M for l3vpn-archive@odin.ietf.org; Wed, 06 Aug 2003 11:16:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76FGIqT006914 for l3vpn-archive@odin.ietf.org; Wed, 6 Aug 2003 11:16:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQ1R-0001nR-WA for l3vpn-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 11:16:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20951 for ; Wed, 6 Aug 2003 11:16:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kQ1F-0003o9-00 for l3vpn-web-archive@ietf.org; Wed, 06 Aug 2003 11:16:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kQ1E-0003o6-00 for l3vpn-web-archive@ietf.org; Wed, 06 Aug 2003 11:16:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQ1B-0001jl-2n; Wed, 06 Aug 2003 11:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQ0E-0001Xu-Si for l3vpn@optimus.ietf.org; Wed, 06 Aug 2003 11:15:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20794 for ; Wed, 6 Aug 2003 11:14:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kQ0E-0003mF-00 for l3vpn@ietf.org; Wed, 06 Aug 2003 11:15:02 -0400 Received: from mx03.forces.gc.ca ([131.137.245.203]) by ietf-mx with esmtp (Exim 4.12) id 19kQ0D-0003m9-00 for l3vpn@ietf.org; Wed, 06 Aug 2003 11:15:01 -0400 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 2EB3920660A for ; Wed, 6 Aug 2003 11:13:25 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19kPWq-0004qi-Pf for ietf-announce-list@asgard.ietf.org; Wed, 06 Aug 2003 10:44:40 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19kPTG-0004oy-9k for all-ietf@asgard.ietf.org; Wed, 06 Aug 2003 10:40:58 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18952; Wed, 6 Aug 2003 10:40:54 -0400 (EDT) Message-Id: <200308061440.KAA18952@ietf.org> 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-01.txt Date: Wed, 06 Aug 2003 10:40:54 -0400 Precedence: bulk MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+280369_941926645910_719743730471" Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --MIMEStream=_0+280369_941926645910_719743730471 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 VPN Author(s) : A. Nagarajan Filename : draft-ietf-l3vpn-generic-reqts-01.txt Pages : 23 Date : 2003-8-6 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-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-generic-reqts-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-generic-reqts-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. --MIMEStream=_0+280369_941926645910_719743730471 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+86113_96667165575052_20567626955" --MIMEStream=_1+86113_96667165575052_20567626955 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-6095954.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-generic-reqts-01.txt --MIMEStream=_1+86113_96667165575052_20567626955 Content-Type: Message/External-body; name="draft-ietf-l3vpn-generic-reqts-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-6095954.I-D@ietf.org> --MIMEStream=_1+86113_96667165575052_20567626955-- --MIMEStream=_0+280369_941926645910_719743730471-- From exim@www1.ietf.org Fri Aug 8 15:13:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22625 for ; Fri, 8 Aug 2003 15:13:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lCfC-0003H4-NH for l3vpn-archive@odin.ietf.org; Fri, 08 Aug 2003 15:12:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78JCYBT012580 for l3vpn-archive@odin.ietf.org; Fri, 8 Aug 2003 15:12:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lCfC-0003Gp-Iz for l3vpn-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 15:12:34 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22577 for ; Fri, 8 Aug 2003 15:12:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lCee-0003Df-Iq; Fri, 08 Aug 2003 15:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lCdw-0003DA-95 for l3vpn@optimus.ietf.org; Fri, 08 Aug 2003 15:11:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22443; Fri, 8 Aug 2003 15:11:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lCdt-00038L-00; Fri, 08 Aug 2003 15:11:13 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19lCds-00037i-00; Fri, 08 Aug 2003 15:11:12 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Aug 2003 21:10:19 +0200 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h78J8W36026252; Fri, 8 Aug 2003 21:08:33 +0200 (MET DST) Received: from MBEHRING-W2K1.cisco.com (ams-mbehring-stealth-5.cisco.com [10.61.96.37]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id VAA28670; Fri, 8 Aug 2003 21:10:44 +0200 (MET DST) Message-Id: <4.3.2.7.2.20030808205033.0238b9e8@madrid.cisco.com> X-Sender: mbehring@madrid.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Aug 2003 21:10:28 +0200 To: stbryant@cisco.com, Ron Bonica , luyuanfang@att.com From: "Michael H. Behringer" Subject: Re: draft-fang-ppvpn-security-framework-01.txt Cc: l3vpn@ietf.org, "pwe3@ietf.org" In-Reply-To: <3F27F99D.90007@cisco.com> References: 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: , At 19:00 30/07/2003, Stewart Bryant wrote: >[...] >2. Security Reference Model > > Also outside the scope are all aspects of network security which are > independent of whether a network is a PPVPN network or a > conventional network (for example, attacks from the Internet to a > server of a given PPVPN user will not be considered here, unless the > way to provision the PPVPN network could make a difference to the > security of this server). > >SB> This is the first time you use the term server, and I not sure I >SB> understand what you mean. Presumably you refer to the equipment >SB> that interfaces the VPN to the VPN core (and hence Internet). In >SB> which case it is not just the provisioning mechanism that needs >SB> to be considered. No, I mean literally a "server", like a web server for example. What I'm trying to say is: - A server can be attacked from the Internet. This is independent of whether this enterprise... -- has a private network with an Internet gateway, or -- has a PPVPN service. For attack forms where this statement is NOT true, it's the job of the draft to highlight this. Where this IS true it's outside the scope. I'll change the above sentence, I hope that makes it clearer. >[...] >6.4. CE Authentication > > It is not possible for an outsider to install a CE and pretend to > belong to a specific PPVPN, to which this CE does not belong in > reality. > >SB> I think that you need to restate this, to state that authentication >SB> makes this impossible (well actually just difficult). Not clear what you mean. The requirement is "authentication", and if this is present, the consequence is that "it is not possible ...". Same structure as in all other sections?!?? Please clarify... >6.5. Integrity > > Data in transit must be cryptographically secured such that it > cannot be altered. > >6.6. Anti-Replay > > Data in transit must be cryptographically secured such that it > cannot be recorded and replayed later. > >SB> You may wish to expand the last two sections a little so that the >SB> title is not integral to reading the sentence. Hmmm, I like it short and crisp ;-) But I'll reword it :-) Thanks for your comments! Michael [rest deleted here] From exim@www1.ietf.org Fri Aug 8 16:24:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24579 for ; Fri, 8 Aug 2003 16:24:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDmU-0005dJ-Gu for l3vpn-archive@odin.ietf.org; Fri, 08 Aug 2003 16:24:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78KOACG021649 for l3vpn-archive@odin.ietf.org; Fri, 8 Aug 2003 16:24:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDmT-0005cw-Tw for l3vpn-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 16:24:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24389 for ; Fri, 8 Aug 2003 16:24:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lDmS-0003jE-00 for l3vpn-web-archive@ietf.org; Fri, 08 Aug 2003 16:24:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lDmR-0003jA-00 for l3vpn-web-archive@ietf.org; Fri, 08 Aug 2003 16:24:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDmO-0005X8-Sg; Fri, 08 Aug 2003 16:24:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lCwP-0003fk-Ol for l3vpn@optimus.ietf.org; Fri, 08 Aug 2003 15:30:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23336 for ; Fri, 8 Aug 2003 15:30:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lCwO-0003F6-00 for l3vpn@ietf.org; Fri, 08 Aug 2003 15:30:20 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19lCwN-0003Ev-00 for l3vpn@ietf.org; Fri, 08 Aug 2003 15:30:19 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Aug 2003 21:29:21 +0200 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h78JRZlk028280; Fri, 8 Aug 2003 21:27:36 +0200 (MET DST) Received: from MBEHRING-W2K1.cisco.com (ams-mbehring-stealth-5.cisco.com [10.61.96.37]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id VAA00423; Fri, 8 Aug 2003 21:29:46 +0200 (MET DST) Message-Id: <4.3.2.7.2.20030808211631.024538b0@madrid.cisco.com> X-Sender: mbehring@madrid.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Aug 2003 21:29:01 +0200 To: Ron Bonica , Paul Hoffman / VPNC , l3vpn@ietf.org From: "Michael H. Behringer" Subject: RE: draft-fang-ppvpn-security-framework-01 In-Reply-To: References: 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: , Ron, Paul, Well, "the central network infrastructure over which PPVPN services are delivered" includes PE routers in my reading. You deliver a PPVPN service specifically from a PE router, right? What if I change it to "A PPVPN core network is defined here as the central network infrastructure (P and PE routers) over which PPVPN services are delivered."? I don't like to talk about a SP network, because a PPVPN core may consist of more than one SP network, right? I guess I could write after the above sentence: "A PPVPN core network consists of one or more SP networks." Hmmm... After various comments on that paragraph I have done so much wordsmithing on it, that I think it is best to copy it here, so that you can see yourself: --- A PPVPN core network is defined here as the central network infrastructure (P and PE routers) over which PPVPN services are delivered. A PPVPN core network consists of one or more SP networks. All network elements in the core are under the operational control of one or more PPVPN service providers. Even if the PPVPN core is provided by several service providers, towards the PPVPN users it appears as a single zone of trust. However, several service providers providing together a PPVPN core still need to secure themselves against the other providers. PPVPN services can also be delivered over the Internet, in which case the Internet forms a logical part of the PPVPN core. --- The ASCII art BTW is meant to show zones of trust nothing more. What do you think? Thanks, Michael At 14:53 30/07/2003, Ron Bonica wrote: >Paul, > >You may be right. However, I would not have infered that meaning from the >following definition >which was lifted from draft-fang-ppvpn-security-framework > > "A PPVPN core network is defined here as the central network > infrastructure over which PPVPN services are delivered. All network > elements in the core are under the operational control of one or > more PPVPN service providers. PPVPN services can also be delivered > over the Internet, in which case the Internet forms a logical part > of the PPVPN core." > >If that was the meaning of this paragraph, it should include some specific >verbage excluding PE routers. Then the term becomes significantly different >from the term "SP network". > > Ron > /individual contributor > > > -----Original Message----- > > From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org]On Behalf Of > > Paul Hoffman / VPNC > > Sent: Tuesday, July 29, 2003 11:45 PM > > To: Ron Bonica; l3vpn@ietf.org > > Subject: RE: draft-fang-ppvpn-security-framework-01 > > > > > > At 9:00 PM -0400 7/29/03, Ron Bonica wrote: > > >Paul > > > > > >Doesn't draft-ietf-l3vpn-framework use the term "SP Network"? > > Isn't that the > > >same as the "core network"? > > > > It doesn't appear to be. In the l3vpn-framework document, it appears > > that the "SP Network" include the PE boxes, but in the > > security-framework document, the "core network" does not. That's a > > pretty significant difference when you are trying to delineate where > > various security services happen. > > > > Of course, I could be reading one or both of the documents wrong, > > particularly because the l3vpn-framework document doesn't directly > > define "SP network": you have to infer it from the ASCII art. > > > > --Paul Hoffman, Director > > --VPN Consortium > > From exim@www1.ietf.org Sun Aug 10 16:46:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15753 for ; Sun, 10 Aug 2003 16:46:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lx4p-0006J6-ES for l3vpn-archive@odin.ietf.org; Sun, 10 Aug 2003 16:46:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7AKk7T6024241 for l3vpn-archive@odin.ietf.org; Sun, 10 Aug 2003 16:46:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lx4p-0006Iu-9h for l3vpn-web-archive@optimus.ietf.org; Sun, 10 Aug 2003 16:46:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15741 for ; Sun, 10 Aug 2003 16:46:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lx4n-0001Fq-00 for l3vpn-web-archive@ietf.org; Sun, 10 Aug 2003 16:46:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lx4m-0001Fm-00 for l3vpn-web-archive@ietf.org; Sun, 10 Aug 2003 16:46:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lx4k-0006IN-5a; Sun, 10 Aug 2003 16:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lx4T-0006I4-BD for l3vpn@optimus.ietf.org; Sun, 10 Aug 2003 16:45:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15733 for ; Sun, 10 Aug 2003 16:45:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lx4R-0001FZ-00 for l3vpn@ietf.org; Sun, 10 Aug 2003 16:45:43 -0400 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 19lx4Q-0001FV-00 for l3vpn@ietf.org; Sun, 10 Aug 2003 16:45:42 -0400 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HJF002CI81MQT@firewall.wcom.com> for l3vpn@ietf.org; Sun, 10 Aug 2003 20:39:22 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HJF00F0181M77@pmismtp01.wcomnet.com>; Sun, 10 Aug 2003 20:39:22 +0000 (GMT) Received: from rbonica ([166.50.152.64]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HJF00BCN81K71@pmismtp01.wcomnet.com>; Sun, 10 Aug 2003 20:39:21 +0000 (GMT) Date: Sun, 10 Aug 2003 16:40:04 -0400 From: Ron Bonica Subject: RE: draft-fang-ppvpn-security-framework-01 In-reply-to: <4.3.2.7.2.20030808211631.024538b0@madrid.cisco.com> To: "Michael H. Behringer" , Paul Hoffman / VPNC , l3vpn@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit much better! Thanks for the clarification. -r > -----Original Message----- > From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org]On Behalf Of > Michael H. Behringer > Sent: Friday, August 08, 2003 3:29 PM > To: Ron Bonica; Paul Hoffman / VPNC; l3vpn@ietf.org > Subject: RE: draft-fang-ppvpn-security-framework-01 > > > Ron, Paul, > > Well, "the central network infrastructure over which PPVPN services are > delivered" includes PE routers in my reading. You deliver a PPVPN service > specifically from a PE router, right? > > What if I change it to "A PPVPN core network is defined here as > the central > network infrastructure (P and PE routers) over which PPVPN services are > delivered."? > > I don't like to talk about a SP network, because a PPVPN core may consist > of more than one SP network, right? I guess I could write after the above > sentence: "A PPVPN core network consists of one or more SP networks." > > Hmmm... After various comments on that paragraph I have done so much > wordsmithing on it, that I think it is best to copy it here, so that you > can see yourself: > > --- > A PPVPN core network is defined here as the central network > infrastructure > (P and PE routers) over which PPVPN services are delivered. A PPVPN core > network consists of one or more SP networks. All network elements in the > core are under the operational control of one or more PPVPN service > providers. Even if the PPVPN core is provided by several service > providers, > towards the PPVPN users it appears as a single zone of trust. However, > several service providers providing together a PPVPN core still need to > secure themselves against the other providers. PPVPN services can also be > delivered over the Internet, in which case the Internet forms a logical > part of the PPVPN core. > --- > > The ASCII art BTW is meant to show zones of trust nothing more. > > What do you think? > > Thanks, > Michael > > At 14:53 30/07/2003, Ron Bonica wrote: > >Paul, > > > >You may be right. However, I would not have infered that meaning from the > >following definition > >which was lifted from draft-fang-ppvpn-security-framework > > > > "A PPVPN core network is defined here as the central network > > infrastructure over which PPVPN services are delivered. All network > > elements in the core are under the operational control of one or > > more PPVPN service providers. PPVPN services can also be delivered > > over the Internet, in which case the Internet forms a logical part > > of the PPVPN core." > > > >If that was the meaning of this paragraph, it should include > some specific > >verbage excluding PE routers. Then the term becomes > significantly different > >from the term "SP network". > > > > Ron > > /individual contributor > > > > > -----Original Message----- > > > From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org]On Behalf Of > > > Paul Hoffman / VPNC > > > Sent: Tuesday, July 29, 2003 11:45 PM > > > To: Ron Bonica; l3vpn@ietf.org > > > Subject: RE: draft-fang-ppvpn-security-framework-01 > > > > > > > > > At 9:00 PM -0400 7/29/03, Ron Bonica wrote: > > > >Paul > > > > > > > >Doesn't draft-ietf-l3vpn-framework use the term "SP Network"? > > > Isn't that the > > > >same as the "core network"? > > > > > > It doesn't appear to be. In the l3vpn-framework document, it appears > > > that the "SP Network" include the PE boxes, but in the > > > security-framework document, the "core network" does not. That's a > > > pretty significant difference when you are trying to delineate where > > > various security services happen. > > > > > > Of course, I could be reading one or both of the documents wrong, > > > particularly because the l3vpn-framework document doesn't directly > > > define "SP network": you have to infer it from the ASCII art. > > > > > > --Paul Hoffman, Director > > > --VPN Consortium > > > > > From exim@www1.ietf.org Tue Aug 12 13:32:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22236 for ; Tue, 12 Aug 2003 13:32:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19md08-0003nn-NR for l3vpn-archive@odin.ietf.org; Tue, 12 Aug 2003 13:32:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CHW4Kt014613 for l3vpn-archive@odin.ietf.org; Tue, 12 Aug 2003 13:32:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19md08-0003nb-IY for l3vpn-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 13:32:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22200 for ; Tue, 12 Aug 2003 13:31:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19md06-0002Vj-00 for l3vpn-web-archive@ietf.org; Tue, 12 Aug 2003 13:32:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19md05-0002Vd-00 for l3vpn-web-archive@ietf.org; Tue, 12 Aug 2003 13:32:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19md05-0003mV-P6; Tue, 12 Aug 2003 13:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mczx-0003mF-Ot for l3vpn@optimus.ietf.org; Tue, 12 Aug 2003 13:31:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22188 for ; Tue, 12 Aug 2003 13:31:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mczv-0002VQ-00 for l3vpn@ietf.org; Tue, 12 Aug 2003 13:31:51 -0400 Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx with esmtp (Exim 4.12) id 19mczu-0002VD-00 for l3vpn@ietf.org; Tue, 12 Aug 2003 13:31:51 -0400 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.166]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q3Z2RPCD; Tue, 12 Aug 2003 13:31:20 -0400 Message-Id: <5.2.0.9.0.20030812120345.01f80e40@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 12 Aug 2003 13:01:26 -0400 To: "Eric W Gray" , From: Mark Duffy Subject: RE: WG Focus Item - draft-fang-ppvpn-security-framework-01.txt In-Reply-To: <013b01c35878$3d954b60$6901a8c0@khumbu> References: 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: , Hi Eric, and think you for your review and comments. I'm responding here only to a few of them. --Mark At 05:59 PM 8/1/2003 -0400, Eric W Gray wrote: >Evaluating the Template (section 8.1): I do not understand > the statement "In the VPN approach, the requirement is > addressed in a way that is beyond the scope of the VPN > approach." It seems to me that "addressed" and "out of > scope" are mutually exclusive concepts. At the time I wrote this I had something specific in mind, and I believe it was along the lines of "In the VPN approach, the requirement is addressed by some other mechanism that is always used together with the VPN approach." That said, unless I remember the specific issue, I'll remove the text. >Template (section 8.2): 1 and 2 might be clearer if they > were worded as - > >" 1. The approach provides complete IP address separation > for each L3 VPN. > >" 2. The approach provides complete L2 address separation > for each L2 VPN. > >" 3. The approach provides complete VLAN ID separation > for each VPN. > >" 4. The approach provides complete IP route separation > for each VPN. > >" 5. The approach provides complete L2 forwarding > separation for each VPN." agreed >In particular, 4 and 5 should address what is separated >for each VPN (forwarding) as opposed to how it is separated >(separate tables as opposed to other approaches). > >Template (section 9, a and b): should require precise values >(or state that it is operator definable) for "excessive". The point here was that the approach should provide protection against "too much" routing or management traffic, for any value of too much from "just a wee bit too much" to "arbitrarily much". I will try to make the wording more clear. >Template (section 15): should read something like - > >" 15. The approach provides protection against unauthorized > traffic pattern analysis for PPVPN user data." ok, I'll add the word "unauthorized". From exim@www1.ietf.org Tue Aug 12 13:32:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22241 for ; Tue, 12 Aug 2003 13:32:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19md08-0003pM-RI for l3vpn-archive@odin.ietf.org; Tue, 12 Aug 2003 13:32:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CHW46f014646 for l3vpn-archive@odin.ietf.org; Tue, 12 Aug 2003 13:32:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19md08-0003nc-JU for l3vpn-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 13:32:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22199 for ; Tue, 12 Aug 2003 13:31:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19md06-0002Vm-00 for l3vpn-web-archive@ietf.org; Tue, 12 Aug 2003 13:32:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19md05-0002Ve-00 for l3vpn-web-archive@ietf.org; Tue, 12 Aug 2003 13:32:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19md06-0003mi-6I; Tue, 12 Aug 2003 13:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mczy-0003mK-5q for l3vpn@optimus.ietf.org; Tue, 12 Aug 2003 13:31:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22191 for ; Tue, 12 Aug 2003 13:31:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mczw-0002VT-00 for l3vpn@ietf.org; Tue, 12 Aug 2003 13:31:52 -0400 Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx with esmtp (Exim 4.12) id 19mczv-0002VE-00 for l3vpn@ietf.org; Tue, 12 Aug 2003 13:31:51 -0400 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.166]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q3Z2RPCF; Tue, 12 Aug 2003 13:31:20 -0400 Message-Id: <5.2.0.9.0.20030812122305.01fdc3c0@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 12 Aug 2003 13:04:37 -0400 To: Paul Hoffman / VPNC , l3vpn@ietf.org From: Mark Duffy Subject: Re: Comments on draft-fang-ppvpn-security-framework-01 In-Reply-To: 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: , Hi Paul and thank you for all your comments. I am responding here only to the comments on sect. 8. Thanks, Mark At 10:53 AM 7/30/2003 -0700, Paul Hoffman / VPNC wrote: >Section 8.2, step 8. Remove the "[Editor's note..."; otherwise, everyone >will just repeat it in their document. You have made it clear that non-VPN >DoS attacks are out of scope. done >Section 8.2, step 11. It is not clear what kind of confidentiality you are >referring to. I suggest changing this to "The approach provides >cryptographic confidentiality protection...". The reference here is to confidentiality protection in the sense of keeping the data secret. Although I find it hard to conceive of anyone providing this in a PPVPN through a means other than cryptography, I think it is improper to dictate the means here. I will clarify the service this is calling for. This item is implicitly linked to the confidentiality requirement stated in sect. 6.3 (which currently calls for cryptographic means, but we have been asked to change that because, likewise, the means to the end should not be part of the requirement). From exim@www1.ietf.org Tue Aug 12 15:39:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27323 for ; Tue, 12 Aug 2003 15:39:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mez5-0007jt-UO for l3vpn-archive@odin.ietf.org; Tue, 12 Aug 2003 15:39:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CJd707029743 for l3vpn-archive@odin.ietf.org; Tue, 12 Aug 2003 15:39:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mez5-0007je-Nl for l3vpn-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 15:39:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27319 for ; Tue, 12 Aug 2003 15:39:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mez4-0003Zm-00 for l3vpn-web-archive@ietf.org; Tue, 12 Aug 2003 15:39:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mez3-0003Zj-00 for l3vpn-web-archive@ietf.org; Tue, 12 Aug 2003 15:39:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19meyz-0007iV-4T; Tue, 12 Aug 2003 15:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19meyG-0007ho-RB for l3vpn@optimus.ietf.org; Tue, 12 Aug 2003 15:38:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27305 for ; Tue, 12 Aug 2003 15:38:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19meyF-0003Zg-00 for l3vpn@ietf.org; Tue, 12 Aug 2003 15:38:15 -0400 Received: from vmmrnat.verisignmail.com ([216.168.230.187] helo=vmmr9.verisignmail.com) by ietf-mx with esmtp (Exim 4.12) id 19meyE-0003Zd-00 for l3vpn@ietf.org; Tue, 12 Aug 2003 15:38:14 -0400 Received: from ms7.verisignmail.com (ms7.verisignmail.com [216.168.230.174] (may be forged)) by vmmr9.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id PJC21960; Tue, 12 Aug 2003 15:38:12 -0400 (EDT) Received: from khumbu ([65.211.67.100]) by ms7.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id AMD82561; Tue, 12 Aug 2003 15:38:10 -0400 (EDT) From: "Eric W Gray" To: "'Mark Duffy'" , Subject: RE: WG Focus Item - draft-fang-ppvpn-security-framework-01.txt Date: Tue, 12 Aug 2003 15:38:12 -0400 Message-ID: <001301c36109$475ccd50$6901a8c0@khumbu> 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, Build 10.0.2627 In-Reply-To: <5.2.0.9.0.20030812120345.01f80e40@email.quarrytech.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mark, As long as "more clear" means more something that can be determined (or measured) in some meaningful way, that's fine. Otherwise, I have to wonder what it means to assign a rating (as defined in section 8.1) to these two items. -- Eric > ... > > > >Template (section 9, a and b): should require precise values > >(or state that it is operator definable) for "excessive". > > The point here was that the approach should provide protection against "too > much" routing or management traffic, for any value of too much from "just a > wee bit too much" to "arbitrarily much". I will try to make the wording > more clear. > > > ... From exim@www1.ietf.org Wed Aug 13 09:50:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19141 for ; Wed, 13 Aug 2003 09:50:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mw0s-0007id-Hc for l3vpn-archive@odin.ietf.org; Wed, 13 Aug 2003 09:50:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DDo6m1029665 for l3vpn-archive@odin.ietf.org; Wed, 13 Aug 2003 09:50:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mw0s-0007iN-Bc for l3vpn-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 09:50:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19130 for ; Wed, 13 Aug 2003 09:50:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mw0q-0001Zn-00 for l3vpn-web-archive@ietf.org; Wed, 13 Aug 2003 09:50:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mw0p-0001Zj-00 for l3vpn-web-archive@ietf.org; Wed, 13 Aug 2003 09:50:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mw0n-0007hE-0n; Wed, 13 Aug 2003 09:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mvzr-0007gb-Vb for l3vpn@optimus.ietf.org; Wed, 13 Aug 2003 09:49:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19108 for ; Wed, 13 Aug 2003 09:48:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mvzp-0001ZN-00 for l3vpn@ietf.org; Wed, 13 Aug 2003 09:49:01 -0400 Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx with esmtp (Exim 4.12) id 19mvzp-0001ZF-00 for l3vpn@ietf.org; Wed, 13 Aug 2003 09:49:01 -0400 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.166]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q3Z2RQL7; Wed, 13 Aug 2003 09:48:29 -0400 Message-Id: <5.2.0.9.0.20030812173647.01f7ac50@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 12 Aug 2003 23:22:45 -0400 To: Ron Bonica , l3vpn@ietf.org From: Mark Duffy Subject: Re: draft-fang-ppvpn-security-framework-01 In-Reply-To: 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: , Hi Ron, thanks for the comments! Responses below... --Mark At 09:52 PM 7/26/2003 -0400, Ron Bonica wrote: >Authors, > >Two more comments on the draft follow: > >1) In Section 3, as you enumerate threat classes, you include "traffic >pattern analysis". You expand upon the concept of traffic pattern analysis >in section 3.1.4. I wonder if this shouldn't be identified as a second order >threat, as its consequences are not so severe as the other threats. Also, it >is very difficult to protect against. done. >2) In Section 3, you identify the following threat source: > >- Persons within the organization which is the PPVPN user with respect to a >particular PPVPN > >Does the SP need to protect against threats from this source, as the source >and target are contained by the same trusted zone? Good point. Section 2 of the document places these out of scope. I'd like to leave that line in for completeness but add a note that such threats are out of scope here. > Ron > /individual contributor From exim@www1.ietf.org Wed Aug 13 09:50:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19156 for ; Wed, 13 Aug 2003 09:50:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mw0t-0007kA-Vy for l3vpn-archive@odin.ietf.org; Wed, 13 Aug 2003 09:50:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DDo7XG029760 for l3vpn-archive@odin.ietf.org; Wed, 13 Aug 2003 09:50:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mw0s-0007iO-DV for l3vpn-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 09:50:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19129 for ; Wed, 13 Aug 2003 09:50:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mw0q-0001Zq-00 for l3vpn-web-archive@ietf.org; Wed, 13 Aug 2003 09:50:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mw0p-0001Zk-00 for l3vpn-web-archive@ietf.org; Wed, 13 Aug 2003 09:50:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mw0n-0007hV-EQ; Wed, 13 Aug 2003 09:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mvzs-0007gg-2E for l3vpn@optimus.ietf.org; Wed, 13 Aug 2003 09:49:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19109 for ; Wed, 13 Aug 2003 09:48:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mvzq-0001ZQ-00 for l3vpn@ietf.org; Wed, 13 Aug 2003 09:49:02 -0400 Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx with esmtp (Exim 4.12) id 19mvzp-0001ZG-00 for l3vpn@ietf.org; Wed, 13 Aug 2003 09:49:01 -0400 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.166]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q3Z2RQL9; Wed, 13 Aug 2003 09:48:29 -0400 Message-Id: <5.2.0.9.0.20030812174249.01fa1db0@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 12 Aug 2003 23:37:39 -0400 To: Paul Hoffman / VPNC , l3vpn@ietf.org From: Mark Duffy Subject: Re: Comments on draft-fang-ppvpn-security-framework-01 In-Reply-To: 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: , Hi Paul, and thanks. Here are responses to your comments on sect. 3. --Mark At 10:53 AM 7/30/2003 -0700, Paul Hoffman / VPNC wrote: >Section 3, second list. "Persons within an organization that is a separate >PPVPN of the same service provider" is unclear. I suggest changing it to >"Users of a different PPVPN that is managed by the same PPVPN service >provider". ok >Also, I think that this is what most users consider to be the most likely >source of attack; you might consider moving this item to the top of the list. ok. although i still make no claim that the list is ordered by likelihood. >Section 3.1.1. The phrase "with the objective of having them accepted as >legitimate" is a bit misleading here. In a PPVPN, all packets are always >considered to be legitimate. I would remove it to make the first sentence >shorter and more to the point. I reworded this slightly but I stick by the original point. I think it is one thing (actually, a DOS attack) to inject packets that will be forwarded to their destination and then dropped, and another to inject packets containing bogus data and having them be taken for legitimate by the receiver. I'm not sure what you mean by "In a PPVPN, all packets are always considered to be legitimate." unless you are referring to any system without data origin authentication or data integrity protection, that just accepts all data received. >Section 3.1.3. Modification and deletion of traffic is quite different >that observation. I suggest grouping insertion, modification, and deletion >in one section, and cover observation in a different section. Also, I >think you should remove the second sentence; there is very little good >evidence about where observation happens. I split apart observation, modification, deletion, etc, and also removed the statement about where they might occur. (Several other people made similar comments.) >Section 3.1.5. This section should be removed; it is no different than the >combination of insertion and observation (and sometimes observation isn't >even needed). removed. From exim@www1.ietf.org Wed Aug 13 12:05:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24413 for ; Wed, 13 Aug 2003 12:05:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19my7c-00064j-Ci for l3vpn-archive@odin.ietf.org; Wed, 13 Aug 2003 12:05:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DG5CFD023347 for l3vpn-archive@odin.ietf.org; Wed, 13 Aug 2003 12:05:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19my7c-00064U-7d for l3vpn-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 12:05:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24406 for ; Wed, 13 Aug 2003 12:05:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19my7b-0002oE-00 for l3vpn-web-archive@ietf.org; Wed, 13 Aug 2003 12:05:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19my7a-0002oB-00 for l3vpn-web-archive@ietf.org; Wed, 13 Aug 2003 12:05:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19my7Q-00063g-TA; Wed, 13 Aug 2003 12:05:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19my6X-00061C-Nx for l3vpn@optimus.ietf.org; Wed, 13 Aug 2003 12:04:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24365 for ; Wed, 13 Aug 2003 12:04:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19my6W-0002nM-00 for l3vpn@ietf.org; Wed, 13 Aug 2003 12:04:04 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19my6V-0002nD-00 for l3vpn@ietf.org; Wed, 13 Aug 2003 12:04:03 -0400 Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DG3vqu093238; Wed, 13 Aug 2003 09:03:58 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <5.2.0.9.0.20030812174249.01fa1db0@email.quarrytech.com> References: <5.2.0.9.0.20030812174249.01fa1db0@email.quarrytech.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Wed, 13 Aug 2003 08:49:25 -0700 To: Mark Duffy , l3vpn@ietf.org From: Paul Hoffman / VPNC Subject: Re: Comments on draft-fang-ppvpn-security-framework-01 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: , At 11:37 PM -0400 8/12/03, Mark Duffy wrote: >>Section 3.1.1. The phrase "with the objective of having them >>accepted as legitimate" is a bit misleading here. In a PPVPN, all >>packets are always considered to be legitimate. I would remove it >>to make the first sentence shorter and more to the point. > >I reworded this slightly but I stick by the original point. I think >it is one thing (actually, a DOS attack) to inject packets that will >be forwarded to their destination and then dropped, and another to >inject packets containing bogus data and having them be taken for >legitimate by the receiver. I'm not sure what you mean by "In a >PPVPN, all packets are always considered to be legitimate." unless >you are referring to any system without data origin authentication >or data integrity protection, that just accepts all data received. That's *exactly* what I am referring to, and it is an important property of any VPN. If a VPN customer wasn't using internal firewalls (as compared to a firewall at the border to the Internet), using a VPN should not make them think that they might need them now. It is the responsibility of the VPN to only pass traffic that would have been passed if this had been a real local network. --Paul Hoffman, Director --VPN Consortium From exim@www1.ietf.org Wed Aug 13 13:55:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27842 for ; Wed, 13 Aug 2003 13:55:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mzpx-0003kN-4T for l3vpn-archive@odin.ietf.org; Wed, 13 Aug 2003 13:55:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DHt5uR014396 for l3vpn-archive@odin.ietf.org; Wed, 13 Aug 2003 13:55:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mzpw-0003k6-Vw for l3vpn-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 13:55:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27830 for ; Wed, 13 Aug 2003 13:55:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mzpu-0003Ze-00 for l3vpn-web-archive@ietf.org; Wed, 13 Aug 2003 13:55:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mzpt-0003ZW-00 for l3vpn-web-archive@ietf.org; Wed, 13 Aug 2003 13:55:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mzpt-0003j0-Ex; Wed, 13 Aug 2003 13:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mzpZ-0003iI-2P for l3vpn@optimus.ietf.org; Wed, 13 Aug 2003 13:54:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27784 for ; Wed, 13 Aug 2003 13:54:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mzpK-0003Yf-00 for l3vpn@ietf.org; Wed, 13 Aug 2003 13:54:26 -0400 Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx with esmtp (Exim 4.12) id 19mzpJ-0003YE-00 for l3vpn@ietf.org; Wed, 13 Aug 2003 13:54:25 -0400 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.166]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q3Z2RQ7V; Wed, 13 Aug 2003 13:53:50 -0400 Message-Id: <5.2.0.9.0.20030812175456.01f96a38@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 13 Aug 2003 13:29:40 -0400 To: "Eric W Gray" , From: Mark Duffy Subject: RE: WG Focus Item - draft-fang-ppvpn-security-framework-01.txt In-Reply-To: <013b01c35878$3d954b60$6901a8c0@khumbu> References: 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: , Thanks Eric, I've responded below to the comments re section 3, Security Threats. --Mark At 05:59 PM 8/1/2003 -0400, Eric W Gray wrote: >Middle of page 6, second set of bullets (especially the 4th > and 5th bullets) and following paragraph: these seem to > imply a distinct separation of VPNs and the Internet. > Most VPNs would be connected to the Internet (either as > part of the PPVPN service, or via another means) and a > compromise of any VPN could make possible any compromise > from the Internet that would be possible from that VPN. > In the case where Internet access is not via the same > PPVPN provider, avoidance of compromise from the Internet > via the VPN itself is not within the purview of the PPVPN > provider and - therefore - may not be a separable threat. > This may be a problem in the first paragraph in section > 4.5 on page 18 as well ("even if VPN services make use > of a separate network from Internet services"). A seeming > separation of VPN and Internet services from the service > provider's perspective may not actually exist. Agreed that there may be connectivity between a PPVPN and the Internet. However, to the extent that attacks mounted from the Internet would be the same for a PPVPN as for an actual private network, they are out of scope for this doc. We are addressing only the threats that arise because of the "PPVP" part -- provider provisioned and virtually private. Also, whether a PPVPN is connected to the Internet or not, the avenues open to attacking it by another PPVPN user of the same SP will be a superset of the avenues open to persons on the Internet at large, so I think it is still a useful distinction to make. As for an attacker from the Internet compromising one VPN and therefore gaining an advantaged position to attack the other PPVPNs of the same SP, well that might or might not be the case. "Compromising" a network is not necessarily equal to "having all the privileges of a legitimate user" of the network. And in the case where they do compromise one PPVPN via another, they would have had to first surmount the hurdle of greater or equal height, that of compromising the first PPVPN from the Internet. So I'm not sure if that addresses your comment or not. Were you suggesting a change in the text? Given the explanation above, are you still? >Last few paragraphs on page 6: it would be clearer to use > "attacks" rather than "threats" with respect to occurrence > and ease of mounting. done. (FWIW, I would consider the possibility of an "attack" occurring to be a "threat".) >Attacks on the Data Plane, several points: > > The specific classifications used lead to ambiguities > which may complicate the process of picking a solution. > For example, replay should involve both unauthorized > observation and insertion of illegitimate data traffic > (replay may actually involve authentic data - in so far > as authenticity can be determined using some forms of > authentication - even if replay traffic is illegitimate). > > Unauthorized observation, modification and deletion are > fundamentally different forms of attack, possibly making > the grouping of them ambiguous. > > We probably want to recognize that several of these attacks > stem from unauthorized observation (modification does, but > deletion may not, traffic pattern analysis is an attack > only if it derives from unauthorized observation, replay > can only occur if observation - presumably unauthorized - > can occur, etc.). I have split the observation, modification, deletion, insertion from each other, and indicated some relationships between them. > Impersonation is not necessarily an attack against the > data plane. The impersonation section has been removed, "by popular demand" :-) >Attacks on the Control Plane: cross-connection of traffic > between PPVPNs is not an attack against the control plane > as much as it is a failure of the control plane (if you > extend the concept to potentially include the operator) > and an attack against the data plane (a combination of > unauthorized observation and insertion of illegitimate > traffic). A possible exception might be for any network > element whose control plane may be tied up in attempting > to correct the cross-connection - which seems unlikely > to be a common case. I have clarified that cross-connection may be caused by malice or by error (i.e. by the operator). I agree that this *affects* the data plane (many control plane attacks will) but with the document being organized as it is I need to categorize this as an attack on the control plane or an attack on the data plane. I believe it is more correct to place this in the first category. >Attacks on Address Space Separation: it is not clear what > is meant here. Clearly addresses may exist independently > in more than one VPN (this is what is referred to as > Address Separation in section 6.1.1), so what is address > space in this context? This is talking about the same concept of address space separation. 6.1.1 presents the requirement for that separation. Here, it is pointing out that there is a threat of that separation being breached. I will clarify the wording. Thanks, Mark From exim@www1.ietf.org Wed Aug 13 14:42:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27841 for ; Wed, 13 Aug 2003 13:55:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mzpx-0003kb-88 for l3vpn-archive@odin.ietf.org; Wed, 13 Aug 2003 13:55:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DHt5Jc014411 for l3vpn-archive@odin.ietf.org; Wed, 13 Aug 2003 13:55:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mzpx-0003k7-0d for l3vpn-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 13:55:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27829 for ; Wed, 13 Aug 2003 13:55:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mzpu-0003Zb-00 for l3vpn-web-archive@ietf.org; Wed, 13 Aug 2003 13:55:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mzpt-0003ZV-00 for l3vpn-web-archive@ietf.org; Wed, 13 Aug 2003 13:55:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mzps-0003ih-W8; Wed, 13 Aug 2003 13:55:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mzpN-0003eP-1D for l3vpn@optimus.ietf.org; Wed, 13 Aug 2003 13:54:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27773 for ; Wed, 13 Aug 2003 13:54:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mzpK-0003Yi-00 for l3vpn@ietf.org; Wed, 13 Aug 2003 13:54:26 -0400 Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx with esmtp (Exim 4.12) id 19mzpJ-0003YF-00 for l3vpn@ietf.org; Wed, 13 Aug 2003 13:54:25 -0400 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.166]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q3Z2RQ7X; Wed, 13 Aug 2003 13:53:51 -0400 Message-Id: <5.2.0.9.0.20030812172546.01fa9e30@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 13 Aug 2003 13:35:48 -0400 To: stbryant@cisco.com From: Mark Duffy Subject: Re: draft-fang-ppvpn-security-framework-01.txt Cc: l3vpn@ietf.org In-Reply-To: <3F27F99D.90007@cisco.com> References: 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: , Hi Stewart, thanks for your comments! (I am addressing only a subset of them here.) --Mark At 06:00 PM 7/30/2003 +0100, Stewart Bryant wrote: >3. Security Threats > > > A successful attack on a particular PPVPN or on a service provider's > PPVPN infrastructure would be expected to have effects of the > following unhappy sorts: > SB> unhappy :( ? I think that the sentence needs rewording? they wouldn't make you unhappy? ;-) ok, i'll reword. > In the case of PPVPNs, some parties may be in more advantaged > positions that enable them to launch types of attacks not available > to others. For example other PPVPN users of the same service >SB> s/other PPVPN/PPVPN/ I will reword that to be more clear. >SB> Also shouldn't it now be l3vpn? Although there is some overlap >SB> with l2vpn, there are important differences in the vulnerabilities. Hmm. I'm not sure. I'll discuss with my co-authors. There is some L2VPN content in this doc. Before the wg split it was intended to gover l2 and l3. > It is also useful to consider the likelihood of different sorts of > threats occurring. There is at least a perceived difference in the > likelihood of most types of attacks being successfully mounted in > different environments, such as: > > - In a TDM or ATM access network between a PPVPN user and the > service provider > - In an Ethernet access network >SB> I am not sure that there issues are VPN specific, but we will see >SB> what gets said later. I agree. I'll remove these. > - In a PPVPN contained within one service provider's network > - In a PPVPN transiting the public Internet >SB> It may be dangerous to differentiate from because this may change >SB> within the lifetime of a service - assuming PPVPN is succesfull To the extent that these present different security situations, I think it is important that we recognize that and address it. >3.1.3. Unauthorized Observation/Modification/Deletion of Data Traffic > > This refers to "sniffing" VPN packets and examining their contents. > It also includes modifying the contents of packets in flight, or > causing packets in flight to be discarded. Such attacks would > typically occur on links in the network but might also occur in a > compromised node of the network. >SB> I would have thought that modification or deletion was more likely >SB> in a node. Several people raised this point. I will remove that statement. >SB> Under dataplane you also need to consider DOS on the PE (from either >SB> inside or outside the VPN) which I do dnot think that you cover. The DOS sections have been reorganized somewhat. Yes, this section includes attacks on the PE, but the PE is not called out specifically (but nor are any other components). >3.2. Attacks on the Control Plane > > This category encompasses attacks on the control structures operated > by the PPVPN service provider. > >3.2.1. Denial of Service Attacks on the Network Infrastructure > > DOS attacks could be mounted specifically against the mechanisms the > service provider uses to provide PPVPNs e.g. IPsec, MPLS, etc., or > against the general infrastructure of the service provider e.g. core > routers. (The latter case is within the scope of this document only > if the attack happens in relation with the VPN service, otherwise is > not a PPVPN-specific issue.) > > Of special concern for PPVPNs is denial of service to one PPVPN user > caused by the otherwise-legitimate activities of another PPVPN user. > This can occur for example if one PPVPN user's activities are > allowed to consume excessive network resources of any sort that are > also needed to serve other PPVPN users. > >SB> This is a legitimate attack, but I don't think that it belongs under >SB> control plane sub-heading. It is a dataplane attack. I would contend that over-consumption of PPVPN resources can be a data plane or a control plane threat, depending on the type of resource being consumed. Therefore, there is similar text in both sections. >3.2.3. Cross-connection of Traffic Between PPVPNs > > This refers to the event where expected isolation between separate > PPVPNs is breached. This includes cases such as: > > - A site being connected into the "wrong" VPN > - Two or more VPNs being improperly merged together > - A point-to-point VPN connecting the wrong two points > - Any packet or frame being improperly delivered outside the VPN it > is sent in. > > Mis-connection or cross-connection of VPNs has a high likelihood of > being the result of service provider or equipment vendor error > rather than malicious action. > >SB> A compomised router could do this. I have clarified that cross-connection may be caused by malice or by error (i.e. by the operator). >3.2.4. Attacks Against PPVPN Routing Protocols > > This encompasses attacks against routing protocols that are run by > the service provider. > >SB> This sentence needs a scope limiting rider. done > In layer 3 VPNs with dynamic routing this > would typically relate to the distribution of per-VPN routes as well > as backbone routes. In layer 2 VPNs this would typically relate > only to the distribution of backbone routes. Specific attacks > against popular routing protocols have been widely studied and > described in [Beard]. > >SB> Again I am worried about the scoping here. >SB> Surely in L2 it is the distribution of VPN endpoints (or authentication >SB> info that is the PPVPN specific concern, general route distribution is >SB> surely out of scope. agreed. text corrected. >3.2.7. Other Attacks on PPVPN Control Traffic > > Besides routing and management protocols (covered separately in the > previous sections) a number of other control protocols are used for > membership discovery and tunnel establishment in various PPVPN > approaches. These include but may not be limited to: > > - MPLS signaling (LDP, RSVP-TE) > - IPsec signaling (IKE) > - L2TP > - BGP-based membership discovery > - Database-based membership discovery (e.g. RADIUS-based) > > Attacks might subvert or disrupt the activities of these protocols, > for example via impersonation or DOS attacks. > >SB> A network that has these vulnerabilities does not just have PPVPN >SB> issues. Agreed. However, in this section we are only talking about the use of these protocols to deliver the PPVPN service. I have made that more clear. Thanks, Mark From exim@www1.ietf.org Fri Aug 15 09:54:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27350 for ; Fri, 15 Aug 2003 09:54:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nf1q-0003kd-5N for l3vpn-archive@odin.ietf.org; Fri, 15 Aug 2003 09:54:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FDs6GT014417 for l3vpn-archive@odin.ietf.org; Fri, 15 Aug 2003 09:54:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nf1q-0003kS-0d for l3vpn-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 09:54:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27317 for ; Fri, 15 Aug 2003 09:54:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nf1o-0002gy-00 for l3vpn-web-archive@ietf.org; Fri, 15 Aug 2003 09:54:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nf1n-0002gu-00 for l3vpn-web-archive@ietf.org; Fri, 15 Aug 2003 09:54:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nf1l-0003jf-38; Fri, 15 Aug 2003 09:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nf1L-0003Yp-To for l3vpn@optimus.ietf.org; Fri, 15 Aug 2003 09:53:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27300 for ; Fri, 15 Aug 2003 09:53:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nf1K-0002gO-00 for l3vpn@ietf.org; Fri, 15 Aug 2003 09:53:34 -0400 Received: from vmmrnat.verisignmail.com ([216.168.230.187] helo=mr10.verisignmail.com) by ietf-mx with esmtp (Exim 4.12) id 19nf1J-0002gK-00 for l3vpn@ietf.org; Fri, 15 Aug 2003 09:53:33 -0400 Received: from ms7.verisignmail.com (ms7.verisignmail.com [216.168.230.174] (may be forged)) by mr10.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id AEC38380; Fri, 15 Aug 2003 09:53:15 -0400 (EDT) Received: from khumbu ([65.211.67.100]) by ms7.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id AMI45386; Fri, 15 Aug 2003 09:53:14 -0400 (EDT) From: "Eric W Gray" To: "'Mark Duffy'" , Subject: RE: WG Focus Item - draft-fang-ppvpn-security-framework-01.txt Date: Fri, 15 Aug 2003 09:53:00 -0400 Message-ID: <004401c36334$8d8070c0$6901a8c0@khumbu> 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, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <5.2.0.9.0.20030812175456.01f96a38@email.quarrytech.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mark, See below... -- Eric > -----Original Message----- > From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org] On Behalf Of Mark > Duffy > Sent: Wednesday, August 13, 2003 1:30 PM > To: Eric W Gray; l3vpn@ietf.org > Subject: RE: WG Focus Item - draft-fang-ppvpn-security-framework-01.txt > > Thanks Eric, > I've responded below to the comments re section 3, Security Threats. > --Mark > > At 05:59 PM 8/1/2003 -0400, Eric W Gray wrote: > >Middle of page 6, second set of bullets (especially the 4th > > and 5th bullets) and following paragraph: these seem to > > imply a distinct separation of VPNs and the Internet. > > Most VPNs would be connected to the Internet (either as > > part of the PPVPN service, or via another means) and a > > compromise of any VPN could make possible any compromise > > from the Internet that would be possible from that VPN. > > In the case where Internet access is not via the same > > PPVPN provider, avoidance of compromise from the Internet > > via the VPN itself is not within the purview of the PPVPN > > provider and - therefore - may not be a separable threat. > > This may be a problem in the first paragraph in section > > 4.5 on page 18 as well ("even if VPN services make use > > of a separate network from Internet services"). A seeming > > separation of VPN and Internet services from the service > > provider's perspective may not actually exist. > > Agreed that there may be connectivity between a PPVPN and the > Internet. However, to the extent that attacks mounted from the Internet > would be the same for a PPVPN as for an actual private network, they are > out of scope for this doc. We are addressing only the threats that arise > because of the "PPVP" part -- provider provisioned and virtually private. > > Also, whether a PPVPN is connected to the Internet or not, the avenues open > to attacking it by another PPVPN user of the same SP will be a superset of > the avenues open to persons on the Internet at large, so I think it is > still a useful distinction to make. As for an attacker from the Internet > compromising one VPN and therefore gaining an advantaged position to > attack the other PPVPNs of the same SP, well that might or might not be the > case. "Compromising" a network is not necessarily equal to "having all the > privileges of a legitimate user" of the network. And in the case where > they do compromise one PPVPN via another, they would have had to first > surmount the hurdle of greater or equal height, that of compromising the > first PPVPN from the Internet. > > So I'm not sure if that addresses your comment or not. Were you suggesting > a change in the text? Given the explanation above, are you still? With these clarifications, I understand your meaning well enough from the existing text. Yes, this does address my comment. > > > ... > > > >Attacks on the Control Plane: cross-connection of traffic > > between PPVPNs is not an attack against the control plane > > as much as it is a failure of the control plane (if you > > extend the concept to potentially include the operator) > > and an attack against the data plane (a combination of > > unauthorized observation and insertion of illegitimate > > traffic). A possible exception might be for any network > > element whose control plane may be tied up in attempting > > to correct the cross-connection - which seems unlikely > > to be a common case. > > I have clarified that cross-connection may be caused by malice or by error > (i.e. by the operator). I agree that this *affects* the data plane (many > control plane attacks will) but with the document being organized as it is > I need to categorize this as an attack on the control plane or an attack on > the data plane. I believe it is more correct to place this in the first > category. I understand that the "possibility of" cross connection of traffic between PPVPNs is a threat that exists within the control plane, and if such an attack is carried out it will subsequently affect the data plane. However, a literal cross-connect between PPVPNs may exist outside of the influence of the control plane and such a cross-connect - once extant - is an attack against the data plane. I now understand that this is not the threat that you're trying to identify (largely because you've separately identified the constituents of such a threat to the data plane), but this is not clear in your current text - even knowing what you most likely meant to say. Your modified text may make this much clearer. > > ... > > Thanks, Mark From exim@www1.ietf.org Fri Aug 15 12:52:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03328 for ; Fri, 15 Aug 2003 12:52:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nho3-0004ju-D6 for l3vpn-archive@odin.ietf.org; Fri, 15 Aug 2003 12:52:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FGq3Dk018215 for l3vpn-archive@odin.ietf.org; Fri, 15 Aug 2003 12:52:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nho3-0004ji-8b for l3vpn-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 12:52:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03306 for ; Fri, 15 Aug 2003 12:51:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nho1-0003qC-00 for l3vpn-web-archive@ietf.org; Fri, 15 Aug 2003 12:52:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nho1-0003q9-00 for l3vpn-web-archive@ietf.org; Fri, 15 Aug 2003 12:52:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nho0-0004j1-U4; Fri, 15 Aug 2003 12:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nhn3-0004iV-8k for l3vpn@optimus.ietf.org; Fri, 15 Aug 2003 12:51:01 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03188; Fri, 15 Aug 2003 12:50:55 -0400 (EDT) Message-Id: <200308151650.MAA03188@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-ipsec-2547-01.txt Date: Fri, 15 Aug 2003 12:50:54 -0400 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: , --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 : Use of PE-PE IPsec in RFC2547 VPNs Author(s) : E. Rosen et al. Filename : draft-ietf-l3vpn-ipsec-2547-01.txt Pages : 16 Date : 2003-8-15 [RFC2547bis] specifies a particular way of implementing Layer 3 VPNs. It presupposes the use of MPLS Label Switched Paths (LSPs) for carrying VPN traffic between Provider Edge (PE) routers, and specifies the use of two labels in the MPLS label stack. In some circumstances, it is desirable to support the same type of VPN architecture, using an IPsec Security Association in place of an MPLS LSP, thus replacing the topmost of the two MPLS labels with an IP/IPsec header. This enables the VPN packets to be carried securely over non-MPLS networks, using standard IPsec authentication and/or encryption functions to protect them. This draft specifies the procedures which are specific to support of RFC2547bis VPNs using the IPsec encapsulation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-ipsec-2547-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-ipsec-2547-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-ipsec-2547-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: <2003-8-15124000.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-ipsec-2547-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-ipsec-2547-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-15124000.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Fri Aug 15 13:20:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05648 for ; Fri, 15 Aug 2003 13:20:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19niF8-0006NM-Tt for l3vpn-archive@odin.ietf.org; Fri, 15 Aug 2003 13:20:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FHK22t024502 for l3vpn-archive@odin.ietf.org; Fri, 15 Aug 2003 13:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19niF8-0006N7-NS for l3vpn-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 13:20:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05635 for ; Fri, 15 Aug 2003 13:19:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19niF6-0004Sm-00 for l3vpn-web-archive@ietf.org; Fri, 15 Aug 2003 13:20:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19niF6-0004Sj-00 for l3vpn-web-archive@ietf.org; Fri, 15 Aug 2003 13:20:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19niF7-0006MY-E4; Fri, 15 Aug 2003 13:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19niEl-0006Lf-M1 for l3vpn@optimus.ietf.org; Fri, 15 Aug 2003 13:19:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05618 for ; Fri, 15 Aug 2003 13:19:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19niEj-0004Se-00 for l3vpn@ietf.org; Fri, 15 Aug 2003 13:19:37 -0400 Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx with esmtp (Exim 4.12) id 19niEj-0004S5-00 for l3vpn@ietf.org; Fri, 15 Aug 2003 13:19:37 -0400 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.166]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q3Z2R4A4; Fri, 15 Aug 2003 13:19:05 -0400 Message-Id: <5.2.0.9.0.20030815125955.0203aa40@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 15 Aug 2003 13:05:40 -0400 To: "Eric W Gray" , From: Mark Duffy Subject: RE: WG Focus Item - draft-fang-ppvpn-security-framework-01.txt In-Reply-To: <001301c36109$475ccd50$6901a8c0@khumbu> References: <5.2.0.9.0.20030812120345.01f80e40@email.quarrytech.com> 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: , Eric, I agree that it does not make sense to respond to that item (or the preceding one) in the template using the specified yes/no/partial/etc. ratings. I think a good solution is to pose those items as questions that require a narrative answer rather than the yes/no/partial/etc. Mark At 03:38 PM 8/12/2003 -0400, Eric W Gray wrote: >Mark, > > As long as "more clear" means more something that >can be determined (or measured) in some meaningful way, >that's fine. Otherwise, I have to wonder what it means >to assign a rating (as defined in section 8.1) to these >two items. > >-- >Eric > > > ... > > > > > >Template (section 9, a and b): should require precise values > > >(or state that it is operator definable) for "excessive". > > > > The point here was that the approach should provide protection against >"too > > much" routing or management traffic, for any value of too much from >"just a > > wee bit too much" to "arbitrarily much". I will try to make the >wording > > more clear. > > > > > > ... From exim@www1.ietf.org Fri Aug 15 13:37:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06079 for ; Fri, 15 Aug 2003 13:37:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19niVa-0007FR-Uu for l3vpn-archive@odin.ietf.org; Fri, 15 Aug 2003 13:37:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FHb2uq027861 for l3vpn-archive@odin.ietf.org; Fri, 15 Aug 2003 13:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19niVa-0007FA-RA for l3vpn-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 13:37:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06066 for ; Fri, 15 Aug 2003 13:36:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19niVY-0004ZY-00 for l3vpn-web-archive@ietf.org; Fri, 15 Aug 2003 13:37:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19niVY-0004ZV-00 for l3vpn-web-archive@ietf.org; Fri, 15 Aug 2003 13:37:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19niVZ-0007E0-Bc; Fri, 15 Aug 2003 13:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19niUh-0007DH-El for l3vpn@optimus.ietf.org; Fri, 15 Aug 2003 13:36:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06054 for ; Fri, 15 Aug 2003 13:36:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19niUf-0004Z5-00 for l3vpn@ietf.org; Fri, 15 Aug 2003 13:36:05 -0400 Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx with esmtp (Exim 4.12) id 19niUe-0004Z1-00 for l3vpn@ietf.org; Fri, 15 Aug 2003 13:36:04 -0400 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.166]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q3Z2R4BK; Fri, 15 Aug 2003 13:35:34 -0400 Message-Id: <5.2.0.9.0.20030815132226.0203c140@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 15 Aug 2003 13:32:14 -0400 To: Paul Hoffman / VPNC , l3vpn@ietf.org From: Mark Duffy Subject: Re: Comments on draft-fang-ppvpn-security-framework-01 In-Reply-To: References: <5.2.0.9.0.20030812174249.01fa1db0@email.quarrytech.com> <5.2.0.9.0.20030812174249.01fa1db0@email.quarrytech.com> 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: , At 08:49 AM 8/13/2003 -0700, Paul Hoffman / VPNC wrote: >At 11:37 PM -0400 8/12/03, Mark Duffy wrote: >>>Section 3.1.1. The phrase "with the objective of having them accepted as >>>legitimate" is a bit misleading here. In a PPVPN, all packets are always >>>considered to be legitimate. I would remove it to make the first >>>sentence shorter and more to the point. >> >>I reworded this slightly but I stick by the original point. I think it >>is one thing (actually, a DOS attack) to inject packets that will be >>forwarded to their destination and then dropped, and another to inject >>packets containing bogus data and having them be taken for legitimate by >>the receiver. I'm not sure what you mean by "In a PPVPN, all packets are >>always considered to be legitimate." unless you are referring to any >>system without data origin authentication or data integrity protection, >>that just accepts all data received. > >That's *exactly* what I am referring to, and it is an important property >of any VPN. If a VPN customer wasn't using internal firewalls (as compared >to a firewall at the border to the Internet), using a VPN should not make >them think that they might need them now. It is the responsibility of the >VPN to only pass traffic that would have been passed if this had been a >real local network. > >--Paul Hoffman, Director >--VPN Consortium OK, I believe I understand your point -- that the PPVPN service should protect against this spoofing. And I agree. Bear in mind though that this is *not* the section of the document that says what PPVPNs should do/offer. This *is* the section that explains potential threats. From that perspective, do you feel the following text is inappropriate? Insertion of Non-Authentic Data Traffic ... This refers to the insertion (or "spoofing") into the VPN of packets that do not belong there, with the objective of having them accepted by the recipient as legitimate. Thanks, Mark From exim@www1.ietf.org Fri Aug 15 13:56:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06768 for ; Fri, 15 Aug 2003 13:56:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ninz-0000Jt-Fg for l3vpn-archive@odin.ietf.org; Fri, 15 Aug 2003 13:56:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FHu3CV001223 for l3vpn-archive@odin.ietf.org; Fri, 15 Aug 2003 13:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ninz-0000Je-Bu for l3vpn-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 13:56:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06758 for ; Fri, 15 Aug 2003 13:55:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ninx-0004kc-00 for l3vpn-web-archive@ietf.org; Fri, 15 Aug 2003 13:56:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ninw-0004kZ-00 for l3vpn-web-archive@ietf.org; Fri, 15 Aug 2003 13:56:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ninx-0000J3-Fp; Fri, 15 Aug 2003 13:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ninB-0000IB-7y for l3vpn@optimus.ietf.org; Fri, 15 Aug 2003 13:55:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06741 for ; Fri, 15 Aug 2003 13:55:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nin8-0004kV-00 for l3vpn@ietf.org; Fri, 15 Aug 2003 13:55:11 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19nin8-0004kQ-00 for l3vpn@ietf.org; Fri, 15 Aug 2003 13:55:10 -0400 Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FHt6qw012970; Fri, 15 Aug 2003 10:55:08 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <5.2.0.9.0.20030815132226.0203c140@email> References: <5.2.0.9.0.20030812174249.01fa1db0@email.quarrytech.com> <5.2.0.9.0.20030812174249.01fa1db0@email.quarrytech.com> <5.2.0.9.0.20030815132226.0203c140@email> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Fri, 15 Aug 2003 10:56:09 -0700 To: Mark Duffy , l3vpn@ietf.org From: Paul Hoffman / VPNC Subject: Re: Comments on draft-fang-ppvpn-security-framework-01 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: , At 1:32 PM -0400 8/15/03, Mark Duffy wrote: >At 08:49 AM 8/13/2003 -0700, Paul Hoffman / VPNC wrote: >>At 11:37 PM -0400 8/12/03, Mark Duffy wrote: >>>>Section 3.1.1. The phrase "with the objective of having them >>>>accepted as legitimate" is a bit misleading here. In a PPVPN, all >>>>packets are always considered to be legitimate. I would remove it >>>>to make the first sentence shorter and more to the point. >>> >>>I reworded this slightly but I stick by the original point. I >>>think it is one thing (actually, a DOS attack) to inject packets >>>that will be forwarded to their destination and then dropped, and >>>another to inject packets containing bogus data and having them be >>>taken for legitimate by the receiver. I'm not sure what you mean >>>by "In a PPVPN, all packets are always considered to be >>>legitimate." unless you are referring to any system without data >>>origin authentication or data integrity protection, that just >>>accepts all data received. >> >>That's *exactly* what I am referring to, and it is an important >>property of any VPN. If a VPN customer wasn't using internal >>firewalls (as compared to a firewall at the border to the >>Internet), using a VPN should not make them think that they might >>need them now. It is the responsibility of the VPN to only pass >>traffic that would have been passed if this had been a real local >>network. >> >>--Paul Hoffman, Director >>--VPN Consortium > >OK, I believe I understand your point -- that the PPVPN service >should protect against this spoofing. And I agree. Bear in mind >though that this is *not* the section of the document that says what >PPVPNs should do/offer. This *is* the section that explains >potential threats. From that perspective, do you feel the following >text is inappropriate? > >Insertion of Non-Authentic Data Traffic ... This refers to the >insertion (or "spoofing") into the VPN of packets that do not belong >there, with the objective of having them accepted by the recipient >as legitimate. Ah, I see the disconnect. Yup, that is fine. --Paul Hoffman, Director --VPN Consortium From exim@www1.ietf.org Fri Aug 15 14:09:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07252 for ; Fri, 15 Aug 2003 14:09:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nj0Z-0000qz-EE for l3vpn-archive@odin.ietf.org; Fri, 15 Aug 2003 14:09:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FI93hG003250 for l3vpn-archive@odin.ietf.org; Fri, 15 Aug 2003 14:09:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nj0Y-0000qL-HL for l3vpn-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 14:09:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07242 for ; Fri, 15 Aug 2003 14:08:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nj0W-0004qd-00 for l3vpn-web-archive@ietf.org; Fri, 15 Aug 2003 14:09:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nj0V-0004qa-00 for l3vpn-web-archive@ietf.org; Fri, 15 Aug 2003 14:08:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nj0X-0000pp-2G; Fri, 15 Aug 2003 14:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nj0D-0000pc-EN for l3vpn@optimus.ietf.org; Fri, 15 Aug 2003 14:08:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07239 for ; Fri, 15 Aug 2003 14:08:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nj0B-0004qX-00 for l3vpn@ietf.org; Fri, 15 Aug 2003 14:08:39 -0400 Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx with esmtp (Exim 4.12) id 19nj0A-0004qU-00 for l3vpn@ietf.org; Fri, 15 Aug 2003 14:08:38 -0400 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.166]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q3Z2R4CV; Fri, 15 Aug 2003 14:08:07 -0400 Message-Id: <5.2.0.9.0.20030815134221.0203af50@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 15 Aug 2003 14:07:08 -0400 To: "Eric W Gray" , From: Mark Duffy Subject: RE: WG Focus Item - draft-fang-ppvpn-security-framework-01.txt In-Reply-To: <004401c36334$8d8070c0$6901a8c0@khumbu> References: <5.2.0.9.0.20030812175456.01f96a38@email.quarrytech.com> 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: , At 09:53 AM 8/15/2003 -0400, Eric W Gray wrote: ... > > >Attacks on the Control Plane: cross-connection of traffic > > > between PPVPNs is not an attack against the control plane > > > as much as it is a failure of the control plane (if you > > > extend the concept to potentially include the operator) > > > and an attack against the data plane (a combination of > > > unauthorized observation and insertion of illegitimate > > > traffic). A possible exception might be for any network > > > element whose control plane may be tied up in attempting > > > to correct the cross-connection - which seems unlikely > > > to be a common case. > > > > I have clarified that cross-connection may be caused by malice or by >error > > (i.e. by the operator). I agree that this *affects* the data plane >(many > > control plane attacks will) but with the document being organized as >it is > > I need to categorize this as an attack on the control plane or an >attack on > > the data plane. I believe it is more correct to place this in the >first > > category. > >I understand that the "possibility of" cross connection of >traffic between PPVPNs is a threat that exists within the >control plane, and if such an attack is carried out it will >subsequently affect the data plane. > >However, a literal cross-connect between PPVPNs may exist >outside of the influence of the control plane and such a >cross-connect - once extant - is an attack against the >data plane. I now understand that this is not the threat >that you're trying to identify (largely because you've >separately identified the constituents of such a threat >to the data plane), but this is not clear in your current >text - even knowing what you most likely meant to say. > >Your modified text may make this much clearer. Actually, I don't think it does. Are you talking about a cross-connection that happens in the data plane *without* the control plane causing it? I imagine that could happen e.g. by someone modifying mpls labels or GRE tunnel headers or the like on packets in flight. Is that what you have in mind? But even that I would argue is an attack on the control plane (viewing tunnels implementing the PPVPN as control plane constructs). Even if you view that as a data plane attack I think that would be considered a case of "modification of data traffic" which we already cover as a data plane attack. (Perhaps that's what you mean by saying I've identified the constituents of such a threat...) Mark From exim@www1.ietf.org Mon Aug 18 10:29:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20860 for ; Mon, 18 Aug 2003 10:29:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ol0U-0007JE-7E for l3vpn-archive@odin.ietf.org; Mon, 18 Aug 2003 10:29:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IETEET028095 for l3vpn-archive@odin.ietf.org; Mon, 18 Aug 2003 10:29:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ol0T-0007J4-LA for l3vpn-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 10:29:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20824 for ; Mon, 18 Aug 2003 10:29:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ol0R-0007Oo-00 for l3vpn-web-archive@ietf.org; Mon, 18 Aug 2003 10:29:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ol0Q-0007Ok-00 for l3vpn-web-archive@ietf.org; Mon, 18 Aug 2003 10:29:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ol0H-0007IN-5d; Mon, 18 Aug 2003 10:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19okzJ-0007Hs-L9 for l3vpn@optimus.ietf.org; Mon, 18 Aug 2003 10:28:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20799 for ; Mon, 18 Aug 2003 10:27:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19okzH-0007OU-00 for l3vpn@ietf.org; Mon, 18 Aug 2003 10:27:59 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19okzG-0007OJ-00 for l3vpn@ietf.org; Mon, 18 Aug 2003 10:27:58 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23831 for ; Mon, 18 Aug 2003 10:27:25 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA02672 for ; Mon, 18 Aug 2003 10:27:27 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Aug 2003 10:27:26 -0400 Message-ID: <0725120622E7D411AEF70020485A6B0C01FC6734@dl-msgusr-01.eu.fore.com> From: "Morris, Stephen" To: l3vpn@ietf.org Subject: RE: draft-ietf-l3vpn-generic-reqts-01.txt Date: Mon, 18 Aug 2003 10:25:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , Hello I've just finished reading the above draft. I wanted to ask about one matter mentioned in section 6.4. Specifically, I'm interested in the idea of manipulating aggregate managed objects. These are objects that span a managed network or networks, and provide some higher level service, e.g., VLANs, IP VPNs, LSPs, etc. My thinking is that for effective network management, a network management system needs to be able to create/delete, view the status/performance/security, etc. of these aggregate managed objects. However, some existing technologies (e.g. RFC 2547) arguably make this end-to-end view a bit difficult, i.e., the NMS might have a lot of work to do in order to build an end-to-end picture of a 2547 VPN service. Clearly, moving support for aggregate managed objects (e.g., create a 2547 VPN between x sites with a specified core QoS) into network elements might represent a scalability challenge. Also, there are possible issues where multiple providers orchestrate the overall service... Is there any interest in possibly pursuing this topic? Best wishes Stephen Morris From exim@www1.ietf.org Mon Aug 18 11:59:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24819 for ; Mon, 18 Aug 2003 11:59:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19omPP-0002Zp-Oe for l3vpn-archive@odin.ietf.org; Mon, 18 Aug 2003 11:59:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IFx3li009899 for l3vpn-archive@odin.ietf.org; Mon, 18 Aug 2003 11:59:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19omPP-0002Za-Iz for l3vpn-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 11:59:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24805 for ; Mon, 18 Aug 2003 11:58:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19omPO-0000el-00 for l3vpn-web-archive@ietf.org; Mon, 18 Aug 2003 11:59:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19omPN-0000ei-00 for l3vpn-web-archive@ietf.org; Mon, 18 Aug 2003 11:59:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19omPN-0002Z5-7o; Mon, 18 Aug 2003 11:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19omOs-0002Ye-O0 for l3vpn@optimus.ietf.org; Mon, 18 Aug 2003 11:58:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24777; Mon, 18 Aug 2003 11:58:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19omOr-0000eH-00; Mon, 18 Aug 2003 11:58:29 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19omOq-0000e5-00; Mon, 18 Aug 2003 11:58:28 -0400 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 h7IFvma10675; Mon, 18 Aug 2003 11:57:48 -0400 (EDT) Received: by zbl6c012.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Aug 2003 11:57:47 -0400 Message-ID: <6204FDDE129D364D8040A98BCCB290EF079CACE8@zbl6c004.corpeast.baynetworks.com> From: "Paul Knight" To: stbryant@cisco.com Cc: l3vpn@ietf.org, pwe3@ietf.org Subject: RE: draft-fang-ppvpn-security-framework-01.txt Date: Mon, 18 Aug 2003 11:57:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C365A1.73614380" 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: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C365A1.73614380 Content-Type: text/plain Hi Stewart, Thanks for your comments. Responses to some parts of your questions, regarding section 4: > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Wednesday, July 30, 2003 1:00 PM > To: Ron Bonita; luyuanfang@att.com > Cc: l3vpn@ietf.org; pwe3@ietf.org > Subject: draft-fang-ppvpn-security-framework-01.txt > [...] > > > 4.1. Cryptographic techniques > > Packet lengths are typically increased when the packets are > encrypted, increasing the network traffic load and adding to the > likelihood of packet fragmentation with its increased overhead. > > SB> Do you want to talk about MTU here? It's difficult to do justice to the MTU issues without bloating the document, but I'm thinking of expanding the existing parenthetical mention of compression to include it: (This packet length increase can often be mitigated to some extent by data compression techniques, but at the expense of additional computational burden. It could also be mitigated by decreasing the path MTU perceived by the user VPN sites, so that encrypted packets will not require fragmentation. However, MTU discovery is not reliably active in end systems in current IPv4 networks, so this may be of little benefit in avoiding packet fragmentation. Also, causing a reduction of the MTU within the user's sites violates a common PPVPN goal of minimizing changes to the user's network.) > > > 4.1.3. Cryptographic techniques in Layer 2 PPVPNs > > Layer 2 PPVPNs will generally not be able to use IPsec to provide > encryption throughout the entire network. They may be able to use > IPsec for PE-PE traffic where it is encapsulated in IP packets, > > SB> Does this mean that we need an MPLSsec work item? We've essentially got it in draft-ietf-l3vpn-ipsec-2547-01.txt, which is the approach which this refers to. I don't plan to include the reference in the draft, however. > > > 4.3. Access Control techniques > > SB> Should you you call out the use of internal only addresses for > SB> the VPN infrastructure? This is called up later - perhaps a > SB> forward reference? - I'll include a reference, and expand the description of internal-only addresses in 4.4. It's definitely a frequently-used part of isolated infrastructure which we hadn't mentioned. Reference reads: Enforcement of access control by isolated infrastructure addresses is discussed in another section of this document. > > > 4.4. Use of Isolated Infrastructure > > One way to protect the infrastructure used for support of > VPNs is to > separate the resources for support of VPNs from the resources used > for other purposes (such as support of Internet services). In some > cases this may make use of a physically separate equipment for VPN > services, or even a physically separate network. > > For example, PE-based L3 VPNs may be run on a separate > backbone not > connected to the Internet, or may make use of separate > edge routers > from those used to support Internet service. > > SB> This is where local (to the provider) addresses help. Added: Private IP addresses (local to the provider and non-routable over the Internet) may be used to provide additional separation. [...] Regards, Paul ------_=_NextPart_001_01C365A1.73614380 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: draft-fang-ppvpn-security-framework-01.txt

Hi Stewart,

Thanks for your comments.

Responses to some parts of your questions, regarding = section 4:

> -----Original Message-----
> From: Stewart Bryant [mailto:stbryant@cisco.com] =
> Sent: Wednesday, July 30, 2003 1:00 PM
> To: Ron Bonita; luyuanfang@att.com
> Cc: l3vpn@ietf.org; pwe3@ietf.org
> Subject: = draft-fang-ppvpn-security-framework-01.txt
>
[...]
>
>
> 4.1.    Cryptographic = techniques
>
>     Packet lengths are = typically increased when the packets are
>     encrypted, increasing = the network traffic load and adding to the
>     likelihood of packet = fragmentation with its increased overhead.
>
> SB> Do you want to talk about MTU = here?
It's difficult to do justice to the MTU issues = without bloating the document, but I'm thinking of expanding the = existing parenthetical mention of compression to include it:

(This packet length increase can often be mitigated = to some extent by data compression techniques, but at the expense of = additional computational burden. It could also be mitigated by = decreasing the path MTU perceived by the user VPN sites, so that = encrypted packets will not require fragmentation. However, MTU = discovery is not reliably active in end systems in current IPv4 = networks, so this may be of little benefit in avoiding packet = fragmentation. Also, causing a reduction of the MTU within the user's = sites violates a common PPVPN goal of minimizing changes to the user's = network.)

>
>
> 4.1.3.  Cryptographic techniques in Layer = 2 PPVPNs
>
>     Layer 2 PPVPNs will = generally not be able to use IPsec to provide
>     encryption throughout = the entire network.  They may be able to use
>     IPsec for PE-PE traffic = where it is encapsulated in IP packets,
>
> SB> Does this mean that we need an MPLSsec = work item?

We've essentially got it in = draft-ietf-l3vpn-ipsec-2547-01.txt, which is the approach which this = refers to. I don't plan to include the reference in the draft, = however.

>
>
> 4.3.    Access Control = techniques
>
> SB> Should you you call out the use of = internal only addresses for
> SB> the VPN infrastructure? This is called = up later - perhaps a
> SB> forward reference?

- I'll include a reference, and expand the = description of internal-only addresses in 4.4.  It's definitely a = frequently-used part of isolated infrastructure which we hadn't = mentioned.

Reference reads:
 Enforcement of access control by isolated = infrastructure addresses is discussed in another section of this = document.
>
>
> 4.4.    Use of Isolated = Infrastructure
>
>     One way to protect the = infrastructure used for support of
> VPNs is to
>     separate the resources = for support of VPNs from the resources used
>     for other purposes = (such as support of Internet services). In some
>     cases this may make use = of a physically separate equipment for VPN
>     services, or even a = physically separate network.
>
>     For example, PE-based = L3 VPNs may be run on a separate
> backbone not
>     connected to the = Internet, or may make use of separate
> edge routers
>     from those used to = support Internet service.
>
> SB> This is where local (to the provider) = addresses help.

Added:
 Private IP addresses (local to the provider = and non-routable over the Internet) may be used to provide additional = separation.

[...]

Regards,
Paul

------_=_NextPart_001_01C365A1.73614380-- From exim@www1.ietf.org Mon Aug 18 16:46:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03987 for ; Mon, 18 Aug 2003 16:46:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oqtB-0004hF-V2 for l3vpn-archive@odin.ietf.org; Mon, 18 Aug 2003 16:46:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IKk5SR018049 for l3vpn-archive@odin.ietf.org; Mon, 18 Aug 2003 16:46:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oqtB-0004h2-R5 for l3vpn-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 16:46:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03945 for ; Mon, 18 Aug 2003 16:45:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oqt8-0002SO-00 for l3vpn-web-archive@ietf.org; Mon, 18 Aug 2003 16:46:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19oqt7-0002SL-00 for l3vpn-web-archive@ietf.org; Mon, 18 Aug 2003 16:46:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oqt8-0004gS-1E; Mon, 18 Aug 2003 16:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oqsO-0004fj-66 for l3vpn@optimus.ietf.org; Mon, 18 Aug 2003 16:45:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03935 for ; Mon, 18 Aug 2003 16:45:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oqsM-0002S6-00 for l3vpn@ietf.org; Mon, 18 Aug 2003 16:45:14 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19oqsL-0002Rp-00 for l3vpn@ietf.org; Mon, 18 Aug 2003 16:45:13 -0400 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 h7IKiZa09494; Mon, 18 Aug 2003 16:44:35 -0400 (EDT) Received: by zbl6c012.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Aug 2003 16:44:34 -0400 Message-ID: <6204FDDE129D364D8040A98BCCB290EF07A5A700@zbl6c004.corpeast.baynetworks.com> From: "Paul Knight" To: Paul Hoffman / VPNC , l3vpn@ietf.org Subject: RE: Comments on draft-fang-ppvpn-security-framework-01 Date: Mon, 18 Aug 2003 16:44:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C365C9.84D158D0" 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: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C365C9.84D158D0 Content-Type: text/plain Hi Paul, Thanks for your suggestions. (Also thanks to private comments on your comments, from Michael Behringer.) Below are responses related mostly to section 4: > -----Original Message----- > From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] > Sent: Wednesday, July 30, 2003 1:53 PM > To: l3vpn@ietf.org > Subject: Comments on draft-fang-ppvpn-security-framework-01 > > > [[ l3vpn: These are the comments that I sent to the draft's editor > last week. Comments on my comments from this list are of course > welcome. --Paul Hoffman ]] > > > Section 4. Maybe change the section title to "Defensive Techniques > for Service Providers". This makes it clearer that the users are not > expected to use any of these techniques in order to make the VPN > secure. Yes, I think that fits. > > Section 4.1, last paragraph. I believe that this paragraph should be > removed because if the end user has any control over the keys, it is > no longer provider-provisioned: the VPN has mixed provisioning and > the security of the VPN becomes much less clear. This might be > controversial, so you might even want to take it to the mailing > lists. To me, an IPsec VPN where the ISP controls the IPsec devices > but the user can mess things up by using weak keys is just a bad idea. It might simplify things to take the paragraph out, but the intersection of the provider and user security domains is a key point of the framework, and I think it needs to be addressed. The concern is not really about weak keys or weak encryption with IPsec now. With most implementations, it's pretty straightforward to correctly configure the type of encryption, and the keys are essentially known only to the IPsec devices unless someone with management access extracts them. The issue being considered is not keying or encryption themselves, but access to the keys and/or ultimately to the unencrypted data. Why even bother with keys when a rogue provider can configure the device to send data in the clear? Is there a model for managing the CE which can give the user some confidence that the data is secure from the provider (and others), while leaving most of the CE device provisioning in the hands of the provider? I think there is. An imperfect analogy is a real-estate agent's lock-box, which holds a key to the door of a home being offered for sale. The homeowner can see when the key is out of the lock-box and being used to open the house, and when the key is itself locked up. I'll definitely revise the existing text, however. It's obviously not clear enough. At this point, I am rewriting (and expanding) the last paragraph of 4.1. The current version: ***** The trust model among the PPVPN user, the PPVPN provider, and other parts of the network is a key element in determining the applicability of encryption for any specific PPVPN implementation. In particular, it determines where encryption should be applied: - If the data path between the user's site and the provider's PE is not trusted, then encryption may be used on the PE-CE link. - If the backbone network is not trusted, particularly in implementations where traffic may travel across the Internet or multiple provider networks, then the PE-PE traffic may encrypted. - If the PPVPN user does not trust any zone outside of its premises, it may require end-to-end or CE-CE encryption service. This service fits within the scope of this PPVPN security framework when the CE is provisioned by the PPVPN provider. Although CE-CE encryption provides privacy against third-party interception, if the PPVPN provider has complete management control over the CE (encryption) devices, then it may be possible for the provider to gain access to the user's VPN traffic or internal network. Encryption devices can potentially be configured to use null encryption, bypass encryption processing altogether, or provide some means of sniffing or diverting unencrypted traffic. Thus a PPVPN implementation using CE-CE encryption needs to consider the trust relationship between the PPVPN user and provider. PPVPN users and providers may wish to negotiate a service level agreement (SLA) for CE-CE encryption which will provide an acceptable demarcation of responsibilities for management of encryption on the CE devices. The demarcation may also be affected by the capabilities of the CE devices. For example, the CE might support some partitioning of management, a configuration lock-down ability, or allow both parties to verify the configuration. > > Section 4.1.2, first paragraph. I think IPsec for management of the > devices is incredibly rare. Maybe remove the second sentence, and add > a bullet at the bottom of the list that says "- IPsec is sometimes > used, but much less often than TLS." > Yes, IPsec is mostly used just for in-band management of IPsec devices. It will be just one of the options listed. [...] > I hope this helps! Yes, thanks! > > --Paul Hoffman, Director > --VPN Consortium > Regards, Paul Knight IP-VPN Standards Advisor, Nortel Networks Advanced Technology - Strategic Protocols & Standards +1 978-288-6414 ESN 248-6414 "With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea." - RFC 1925 ------_=_NextPart_001_01C365C9.84D158D0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Comments on draft-fang-ppvpn-security-framework-01

Hi Paul,

Thanks for your suggestions.  (Also thanks to = private comments on your comments, from Michael Behringer.) Below are = responses related mostly to section 4:

> -----Original Message-----
> From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] =
> Sent: Wednesday, July 30, 2003 1:53 PM
> To: l3vpn@ietf.org
> Subject: Comments on = draft-fang-ppvpn-security-framework-01
>
>
> [[ l3vpn: These are the comments that I sent to = the draft's editor
> last week. Comments on my comments from this = list are of course
> welcome. --Paul Hoffman ]]
>
>
> Section 4. Maybe change the section title to = "Defensive Techniques
> for Service Providers". This makes it = clearer that the users are not
> expected to use any of these techniques in = order to make the VPN
> secure.

Yes, I think that fits.
>
> Section 4.1, last paragraph. I believe that = this paragraph should be
> removed because if the end user has any control = over the keys, it is
> no longer provider-provisioned: the VPN has = mixed provisioning and
> the security of the VPN becomes much less = clear. This might be
> controversial, so you might even want to take = it to the mailing
> lists. To me, an IPsec VPN where the ISP = controls the IPsec devices
> but the user can mess things up by using weak = keys is just a bad idea.

It might simplify things to take the paragraph out, = but the intersection of the provider and user security domains is a key = point of the framework, and I think it needs to be = addressed.

The concern is not really about weak keys or weak = encryption with IPsec now. With most implementations, it's pretty = straightforward to correctly configure the type of encryption, and the = keys are essentially known only to the IPsec devices unless someone = with management access extracts them. The issue being considered is not = keying or encryption themselves, but access to the keys and/or = ultimately to the unencrypted data. Why even bother with keys when a = rogue provider can configure the device to send data in the = clear?

Is there a model for managing the CE which can give = the user some confidence that the data is secure from the provider (and = others), while leaving most of the CE device provisioning in the hands = of the provider?

I think there is.  An imperfect analogy is a = real-estate agent's lock-box, which holds a key to the door of a home = being offered for sale. The homeowner can see when the key is out of = the lock-box and being used to open the house, and when the key is = itself locked up.

I'll definitely revise the existing text, however. = It's obviously not clear enough.

At this point, I am rewriting (and expanding) the = last paragraph of 4.1. The current version:
*****
The trust model among the PPVPN user, the PPVPN = provider, and other parts of the network is a key element in = determining the applicability of encryption for any specific PPVPN = implementation. In particular, it determines where encryption should be = applied:

- If the data path between the user's site and the = provider's PE is not trusted, then encryption may be used on the PE-CE = link.

- If the backbone network is not trusted, = particularly in implementations where traffic may travel across the = Internet or multiple provider networks, then the PE-PE traffic may = encrypted.

- If the PPVPN user does not trust any zone outside = of its premises, it may require end-to-end or CE-CE encryption service. = This service fits within the scope of this PPVPN security framework = when the CE is provisioned by the PPVPN provider.

Although CE-CE encryption provides privacy against = third-party interception, if the PPVPN provider has complete management = control over the CE (encryption) devices, then it may be possible for = the provider to gain access to the user's VPN traffic or internal = network. Encryption devices can potentially be configured to use null = encryption, bypass encryption processing altogether, or provide some = means of sniffing or diverting unencrypted traffic. Thus a PPVPN = implementation using CE-CE encryption needs to consider the trust = relationship between the PPVPN user and provider. PPVPN users and = providers may wish to negotiate a service level agreement (SLA) for = CE-CE encryption which will provide an acceptable demarcation of = responsibilities for management of encryption on the CE devices. The = demarcation may also be affected by the capabilities of the CE devices. = For example, the CE might support some partitioning of management, a = configuration lock-down ability, or allow both parties to verify the = configuration.

>
> Section 4.1.2, first paragraph. I think IPsec = for management of the
> devices is incredibly rare. Maybe remove the = second sentence, and add
> a bullet at the bottom of the list that says = "- IPsec is sometimes
> used, but much less often than = TLS."
>
Yes, IPsec is mostly used just for in-band = management of IPsec devices.  It will be just one of the options = listed.
[...]
> I hope this helps!

Yes, thanks!
>
> --Paul Hoffman, Director
> --VPN Consortium
>
Regards,
Paul Knight
 
IP-VPN Standards Advisor, Nortel Networks
Advanced Technology - Strategic Protocols & = Standards
+1 978-288-6414       = ESN 248-6414

"With sufficient thrust, pigs fly just fine. = However, this is not necessarily a good idea."  - RFC = 1925

------_=_NextPart_001_01C365C9.84D158D0-- From exim@www1.ietf.org Wed Aug 20 10:33:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11525 for ; Wed, 20 Aug 2003 10:33:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pU1H-00071m-Gu for l3vpn-archive@odin.ietf.org; Wed, 20 Aug 2003 10:33:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KEX3hs027011 for l3vpn-archive@odin.ietf.org; Wed, 20 Aug 2003 10:33:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pU1H-00071a-55 for l3vpn-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 10:33:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11462 for ; Wed, 20 Aug 2003 10:32:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pU1E-0001Lt-00 for l3vpn-web-archive@ietf.org; Wed, 20 Aug 2003 10:33:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pU1E-0001Lp-00 for l3vpn-web-archive@ietf.org; Wed, 20 Aug 2003 10:33:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pU1F-000714-DI; Wed, 20 Aug 2003 10:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pRdq-0000eZ-SE for l3vpn@optimus.ietf.org; Wed, 20 Aug 2003 08:00:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05439 for ; Wed, 20 Aug 2003 08:00:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pRdp-0007mI-00 for l3vpn@ietf.org; Wed, 20 Aug 2003 08:00:42 -0400 Received: from ckmso2.att.com ([209.219.209.75] helo=ckmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 19pRdo-0007mE-00 for l3vpn@ietf.org; Wed, 20 Aug 2003 08:00:41 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h7KBvZBd022573 for ; Wed, 20 Aug 2003 08:00:05 -0400 Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (6.5.032) id 3F307C6C003CDDD7; Wed, 20 Aug 2003 07:59:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-lai-mpls-mib-rqmts-00.txt Date: Wed, 20 Aug 2003 07:00:00 -0500 Message-ID: <7AFE40EF30EE754DA967D1B5968457CA02165D46@KCCLUST06EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-lai-mpls-mib-rqmts-00.txt Thread-Index: AcMP2C62Vf/xmb2vROSwc7V+gBejzgACZAHAFXh+EKA= From: "Lai, Wai S (Waisum), ALABS" To: Cc: "Ross Callon" , "Loa Andersson" , "Ron Bonica" , , "Ash, Gerald R (Jerry), ALABS" , "Chung, Li-Jin W, ALABS" 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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable At the initiation of Ross Callon, a meeting was held during the IETF'57 in Vienna to discuss the VPN-MIB requirements described in the following draft http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.txt=20 Participants were Ross Callon, Ron Bonica, Loa Andersson, Tom Nadeau, Jerry Ash, Li-Jin Chung, and Wai Sum Lai. As a result, it was agreed that a new counter is to be added to the VPN-MIB to provide a rough estimate of the number of dropped routes when the operator-defined VRF maximum route threshold is exceeded. (see Section 3.1 of the draft). Such count is needed for capacity planning and threshold tuning purposes. It was also agreed that the RT/RD linkage in VPN-MIB (Section 3.2) is to be handled by the NMS. Comments on this are welcome. Thanks, Wai Sum -----Original Message----- From: Lai, Wai S (Waisum), ALABS=20 Sent: Thursday, May 01, 2003 9:02 AM To: ppvpn@nortelnetworks.com Subject: RE: I-D ACTION:draft-lai-mpls-mib-rqmts-00.txt Based on our testing of the VPN MIB, we have identified some requirements as described in the following draft. Your comments are welcome. Thanks, Wai Sum -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, May 01, 2003 7:48 AM Cc: mpls@uu.net; ppvpn@nortelnetworks.com Subject: I-D ACTION:draft-lai-mpls-mib-rqmts-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Network Management Requirements for MPLS MIBs Author(s) : W. Lai, L. Chung Filename : draft-lai-mpls-mib-rqmts-00.txt Pages : 6 Date : 2003-4-30 =09 In this document, requirements for three MPLS-related MIBs (LDP-MIB,=20 VPN-MIB, and BGP4-MIB) are presented for the support of specific=20 network management needs for fault and performance management. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.txt From exim@www1.ietf.org Wed Aug 27 02:35:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26424 for ; Wed, 27 Aug 2003 02:35:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rsB4-0004bO-4X for l3vpn-archive@odin.ietf.org; Wed, 27 Aug 2003 00:45:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R4j0Lb017663 for l3vpn-archive@odin.ietf.org; Wed, 27 Aug 2003 00:45:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rorr-000369-0o for l3vpn-web-archive@optimus.ietf.org; Tue, 26 Aug 2003 21:12:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00065 for ; Tue, 26 Aug 2003 21:12:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19roro-00072C-00 for l3vpn-web-archive@ietf.org; Tue, 26 Aug 2003 21:12:56 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19rorn-000728-00 for l3vpn-web-archive@ietf.org; Tue, 26 Aug 2003 21:12:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmP3-0003Ys-Mh; Tue, 26 Aug 2003 18:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rlQN-0000wI-54 for l3vpn@optimus.ietf.org; Tue, 26 Aug 2003 17:32:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11643 for ; Tue, 26 Aug 2003 17:32:16 -0400 (EDT) From: lwnieman@bellsouth.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rlQK-0002V0-00 for l3vpn@ietf.org; Tue, 26 Aug 2003 17:32:20 -0400 Received: from imf16aec.mail.bellsouth.net ([205.152.59.64]) by ietf-mx with esmtp (Exim 4.12) id 19rlQJ-0002UV-00 for l3vpn@ietf.org; Tue, 26 Aug 2003 17:32:19 -0400 Received: from mail.bellsouth.net ([205.152.59.160]) by imf16aec.mail.bellsouth.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with SMTP id <20030826213142.WSUR21511.imf16aec.mail.bellsouth.net@mail.bellsouth.net> for ; Tue, 26 Aug 2003 17:31:42 -0400 X-Mailer: Openwave WebEngine, version 2.8.11 (webedge20-101-194-20030622) To: Subject: draft-ietf-l3vpn-mpls-vpn-mib-05 Syntax Error? Date: Tue, 26 Aug 2003 17:31:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20030826213142.WSUR21511.imf16aec.mail.bellsouth.net@mail.bellsouth.net> 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I was playing around with the MIB module in draft-ietf-l3vpn-mpls-vpn-mib-05 and got the following error when I tried to compile it: "Item 'mplsVpnVrfBgpPAtrCalcLocalPref' in sequence 'MplsVpnVrfBgpNbrPrefixEntry' has conflicting syntax specified." In the sequence list 'mplsVpnVrfBgpPAtrCalcLocalPref' is shown as an INTEGER: "MplsVpnVrfBgpNbrPrefixEntry ::= SEQUENCE { mplsVpnVrfBgpPAtrCalcLocalPref INTEGER, }" But farther down in the module the sytax for this object is shown as 'Interger32': "mplsVpnVrfBgpPAtrCalcLocalPref OBJECT-TYPE SYNTAX Integer32 (-1..2147483647)" I'd appreciate it if someone could let me know which it's actually supposed to be, INTEGER or Integer32. Thanks, Len Nieman From exim@www1.ietf.org Wed Aug 27 02:39:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26875 for ; Wed, 27 Aug 2003 02:39:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rsvU-0007B4-Gf for l3vpn-archive@odin.ietf.org; Wed, 27 Aug 2003 01:33:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R5Wxpo027578 for l3vpn-archive@odin.ietf.org; Wed, 27 Aug 2003 01:32:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rpBs-0003hw-TT for l3vpn-web-archive@optimus.ietf.org; Tue, 26 Aug 2003 21:33:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01670 for ; Tue, 26 Aug 2003 21:33:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rpBq-0007Q3-00 for l3vpn-web-archive@ietf.org; Tue, 26 Aug 2003 21:33:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19rpBp-0007Q0-00 for l3vpn-web-archive@ietf.org; Tue, 26 Aug 2003 21:33:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rnIS-0006yz-Sy; Tue, 26 Aug 2003 19:32:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19riKh-0001rj-79 for l3vpn@optimus.ietf.org; Tue, 26 Aug 2003 14:14:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17925 for ; Tue, 26 Aug 2003 14:14:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19riKa-0004JX-00 for l3vpn@ietf.org; Tue, 26 Aug 2003 14:14:12 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19riKZ-0004J3-00 for l3vpn@ietf.org; Tue, 26 Aug 2003 14:14:11 -0400 Received: from rcallon-lt.juniper.net (securepptp031.static.jnpr.net [172.24.253.31]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h7QICBY91468; Tue, 26 Aug 2003 11:12:11 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20030826130718.02edc300@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 26 Aug 2003 13:15:06 -0400 To: "Lai, Wai S (Waisum), ALABS" , l3vpn@ietf.org From: Ross Callon Subject: RE: I-D ACTION:draft-lai-mpls-mib-rqmts-00.txt Cc: loa@pi.se, Ronald.P.Bonica@mci.com, tnadeau@cisco.com, gash@att.com, lic@att.com In-Reply-To: <7AFE40EF30EE754DA967D1B5968457CA02165D46@KCCLUST06EVS1.ugd .att.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: , We should emphasize that the decision regarding any changes to the MIB and other working group documents are up to the working group and document authors. Thus the meeting which Wai Lai referred to in his message should be thought of as an informal meeting to discuss possible ways to resolve some issues. Such informal meetings on the side are quite common during IETF meetings. The working group chairs would like to solicit input regarding whether the additional counter that Wai Lai is proposing to add to the VPN-MIB is agreeable to the working group. It might also be noted that the solutions suggested by Wai Lai in his message below would resolve those comments from draft-lai-mpls-mib-rqmts-00.txt which apply to the l3vpn WG. thanks, Ross (and Ron and Rick) At 07:00 AM 8/20/2003 -0500, Lai, Wai S (Waisum), ALABS wrote: >At the initiation of Ross Callon, a meeting was held during the >IETF'57 in Vienna to discuss the VPN-MIB requirements described >in the following draft >http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.txt >Participants were Ross Callon, Ron Bonica, Loa Andersson, Tom >Nadeau, Jerry Ash, Li-Jin Chung, and Wai Sum Lai. > >As a result, it was agreed that a new counter is to be added to the >VPN-MIB to provide a rough estimate of the number of dropped routes >when the operator-defined VRF maximum route threshold is exceeded. >(see Section 3.1 of the draft). Such count is needed for capacity >planning and threshold tuning purposes. > >It was also agreed that the RT/RD linkage in VPN-MIB (Section 3.2) >is to be handled by the NMS. > >Comments on this are welcome. >Thanks, Wai Sum > >-----Original Message----- >From: Lai, Wai S (Waisum), ALABS >Sent: Thursday, May 01, 2003 9:02 AM >To: ppvpn@nortelnetworks.com >Subject: RE: I-D ACTION:draft-lai-mpls-mib-rqmts-00.txt > > >Based on our testing of the VPN MIB, we have identified some >requirements >as described in the following draft. Your comments are welcome. >Thanks, Wai Sum > >-----Original Message----- >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >Sent: Thursday, May 01, 2003 7:48 AM >Cc: mpls@uu.net; ppvpn@nortelnetworks.com >Subject: I-D ACTION:draft-lai-mpls-mib-rqmts-00.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Network Management Requirements for MPLS MIBs > Author(s) : W. Lai, L. Chung > Filename : draft-lai-mpls-mib-rqmts-00.txt > Pages : 6 > Date : 2003-4-30 > >In this document, requirements for three MPLS-related MIBs (LDP-MIB, >VPN-MIB, and BGP4-MIB) are presented for the support of specific >network management needs for fault and performance management. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.txt From exim@www1.ietf.org Wed Aug 27 22:25:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02805 for ; Wed, 27 Aug 2003 22:25:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sBFH-00041O-Or for l3vpn-archive@odin.ietf.org; Wed, 27 Aug 2003 21:06:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S16dEA015451 for l3vpn-archive@odin.ietf.org; Wed, 27 Aug 2003 21:06:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s5Db-00023I-Cp for l3vpn-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 14:40:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25304 for ; Wed, 27 Aug 2003 14:40:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s5DY-0005JT-00 for l3vpn-web-archive@ietf.org; Wed, 27 Aug 2003 14:40:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19s5DY-0005JQ-00 for l3vpn-web-archive@ietf.org; Wed, 27 Aug 2003 14:40:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s49J-0005vH-Gg; Wed, 27 Aug 2003 13:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rvRT-0000dc-3Q for l3vpn@optimus.ietf.org; Wed, 27 Aug 2003 04:14:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04859 for ; Wed, 27 Aug 2003 04:14:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rvRQ-0000ov-00 for l3vpn@ietf.org; Wed, 27 Aug 2003 04:14:08 -0400 Received: from web20511.mail.yahoo.com ([216.136.175.150]) by ietf-mx with smtp (Exim 4.12) id 19rvRP-0000os-00 for l3vpn@ietf.org; Wed, 27 Aug 2003 04:14:07 -0400 Message-ID: <20030827081408.63784.qmail@web20511.mail.yahoo.com> Received: from [57.250.229.136] by web20511.mail.yahoo.com via HTTP; Wed, 27 Aug 2003 01:14:08 PDT Date: Wed, 27 Aug 2003 01:14:08 -0700 (PDT) From: Vincent Parfait Subject: Address Allocation for PE-CE links To: l3vpn@ietf.org, rick@rhwilder.net, rcallon@juniper.net, ronald.p.bonica@mci.com Cc: jguichar@cisco.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1152311447-1061972048=:60801" 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: , --0-1152311447-1061972048=:60801 Content-Type: text/plain; charset=us-ascii Ross, Rick and Ron, The comments received last april on the PPVPN mailing list regarding the PE-CE addressing draft have been consolidated and integrated into a new version : http://www.ietf.org/internet-drafts/draft-guichard-pe-ce-addr-03.txt Compared to version 2, the changes are : - the title was changed to show that the scope of this draft is not restricted to 2547 networks but covers Provider Provisioned VPN neworks in general - the size of the address block requested is changed from [TBD] to /12 with some explanations on this choice To move forward, I suggest that the draft now becomes a L3VPN WG document. Thanks to advise, Vincent ---------------------------------------------------------------------- 22/04/2003 17:38 To: ppvpn@nortelnetworks.com, "Marco Carugi" , rwilder@masergy.com Subject: PE-CE addressing draft This is to inform you that the draft-guichard-pe-ce-addr has been updated : http://www.ietf.org/internet-drafts/draft-guichard-pe-ce-addr-02.txt I invite you to read through this new version and give your feedback to the list. The main motivation for this proposal is to simplify the Service Providers operations in the scenario where they monitor CE-PE links, and/or CE routers, while at the same time conserving IPV4 address space. Large Service Providers such as Equant, ATT and Arcor are supporting this draft and are requesting that it becomes a working group document. Vincent Parfait Equant --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software --0-1152311447-1061972048=:60801 Content-Type: text/html; charset=us-ascii

Ross, Rick and Ron,

The comments received last april on the PPVPN mailing list regarding the PE-CE addressing draft have been consolidated and integrated into a new version : http://www.ietf.org/internet-drafts/draft-guichard-pe-ce-addr-03.txt

Compared to version 2, the changes are :

- the title was changed to show that the scope of this draft is not restricted to 2547 networks but covers Provider Provisioned VPN neworks in general

- the size of the address block requested is changed from [TBD] to /12 with some explanations on this choice

To move forward, I suggest that the draft now becomes a L3VPN WG document.

Thanks to advise,

Vincent

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

 

22/04/2003 17:38

To: ppvpn@nortelnetworks.com, "Marco Carugi" <marco.carugi@nortelnetworks.com>, rwilder@masergy.com

Subject: PE-CE addressing draft

 

This is to inform you that the draft-guichard-pe-ce-addr has been updated : http://www.ietf.org/internet-drafts/draft-guichard-pe-ce-addr-02.txt

I invite you to read through this new version and give your feedback to the list.

The main motivation for this proposal is to simplify the Service Providers operations in the scenario where they monitor CE-PE links, and/or CE routers, while at the same time conserving IPV4 address space.

Large Service Providers such as Equant, ATT and Arcor are supporting this draft and are requesting that it becomes a working group document.

Vincent Parfait
Equant

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software --0-1152311447-1061972048=:60801-- From exim@www1.ietf.org Thu Aug 28 02:51:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08628 for ; Thu, 28 Aug 2003 02:51:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sCPg-0000sh-Ry for l3vpn-archive@odin.ietf.org; Wed, 27 Aug 2003 22:21:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S2LSXd003377 for l3vpn-archive@odin.ietf.org; Wed, 27 Aug 2003 22:21:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sATn-0000wh-O7 for l3vpn-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 20:17:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21758 for ; Wed, 27 Aug 2003 20:17:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sATl-0003pN-00 for l3vpn-web-archive@ietf.org; Wed, 27 Aug 2003 20:17:33 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sATl-0003pK-00 for l3vpn-web-archive@ietf.org; Wed, 27 Aug 2003 20:17:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4t7-0000de-73; Wed, 27 Aug 2003 14:19:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rwdn-0003kK-2e for l3vpn@optimus.ietf.org; Wed, 27 Aug 2003 05:30:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10163 for ; Wed, 27 Aug 2003 05:30:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rwdj-00021B-00 for l3vpn@ietf.org; Wed, 27 Aug 2003 05:30:55 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19rwdj-00020D-00 for l3vpn@ietf.org; Wed, 27 Aug 2003 05:30:55 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h7R9UND04127 for ; Wed, 27 Aug 2003 04:30:24 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Aug 2003 11:30:22 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550245BF8E@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: lwnieman@bellsouth.net, l3vpn@ietf.org Subject: RE: draft-ietf-l3vpn-mpls-vpn-mib-05 Syntax Error? Date: Wed, 27 Aug 2003 11:30:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , According to our mib review guidelines draft-ietf-ops-mib-review-guidelines-02.txt it should be an Integer32. So the fix is to update the SEQUENCE statement Thanks, Bert > -----Original Message----- > From: lwnieman@bellsouth.net [mailto:lwnieman@bellsouth.net] > Sent: dinsdag 26 augustus 2003 23:32 > To: l3vpn@ietf.org > Subject: draft-ietf-l3vpn-mpls-vpn-mib-05 Syntax Error? > > > I was playing around with the MIB module in > draft-ietf-l3vpn-mpls-vpn-mib-05 and got the following error > when I tried to compile it: > > "Item 'mplsVpnVrfBgpPAtrCalcLocalPref' in sequence > 'MplsVpnVrfBgpNbrPrefixEntry' has conflicting syntax specified." > > In the sequence list 'mplsVpnVrfBgpPAtrCalcLocalPref' is > shown as an INTEGER: > > "MplsVpnVrfBgpNbrPrefixEntry ::= SEQUENCE { > > mplsVpnVrfBgpPAtrCalcLocalPref INTEGER, > > }" > > > But farther down in the module the sytax for this object is > shown as 'Interger32': > > "mplsVpnVrfBgpPAtrCalcLocalPref OBJECT-TYPE > SYNTAX Integer32 (-1..2147483647)" > > I'd appreciate it if someone could let me know which it's > actually supposed to be, INTEGER or Integer32. > > Thanks, > Len Nieman > > > From exim@www1.ietf.org Thu Aug 28 02:56:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09025 for ; Thu, 28 Aug 2003 02:56:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sDZr-00073x-4s for l3vpn-archive@odin.ietf.org; Wed, 27 Aug 2003 23:36:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S3a30D027137 for l3vpn-archive@odin.ietf.org; Wed, 27 Aug 2003 23:36:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sBBO-0003gP-2U for l3vpn-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 21:02:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25635 for ; Wed, 27 Aug 2003 21:02:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sBBL-0004sQ-00 for l3vpn-web-archive@ietf.org; Wed, 27 Aug 2003 21:02:35 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sBBL-0004sN-00 for l3vpn-web-archive@ietf.org; Wed, 27 Aug 2003 21:02:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s52D-0001Rp-K1; Wed, 27 Aug 2003 14:28:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s2CM-0007RM-Eo for l3vpn@optimus.ietf.org; Wed, 27 Aug 2003 11:27:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08845 for ; Wed, 27 Aug 2003 11:26:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s2CL-00010x-00 for l3vpn@ietf.org; Wed, 27 Aug 2003 11:27:01 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19s2CK-000109-00 for l3vpn@ietf.org; Wed, 27 Aug 2003 11:27:00 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h7RFQTtH029189; Wed, 27 Aug 2003 08:26:30 -0700 (PDT) Received: from tnadeauw2k02 (che-vpn-cluster-2-96.cisco.com [10.86.242.96]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ABW46863; Wed, 27 Aug 2003 11:26:29 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: , Subject: RE: draft-ietf-l3vpn-mpls-vpn-mib-05 Syntax Error? Date: Wed, 27 Aug 2003 11:26:29 -0400 Organization: Cisco Systems, inc. Message-ID: <038201c36caf$96405160$6501a8c0@amer.cisco.com> 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, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: <20030826213142.WSUR21511.imf16aec.mail.bellsouth.net@mail.bellsouth.net> 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The INTEGER is wrong; this should only be used for enumerations. Will fix in the next version. Will also check compilation using SmicNGPro in ultra-pedantic mode. :P --Tom > I was playing around with the MIB module in > draft-ietf-l3vpn-mpls-vpn-mib-05 and got the following error > when I tried to compile it: > > "Item 'mplsVpnVrfBgpPAtrCalcLocalPref' in sequence > 'MplsVpnVrfBgpNbrPrefixEntry' has conflicting syntax specified." > > In the sequence list 'mplsVpnVrfBgpPAtrCalcLocalPref' is > shown as an INTEGER: > > "MplsVpnVrfBgpNbrPrefixEntry ::= SEQUENCE { > > mplsVpnVrfBgpPAtrCalcLocalPref INTEGER, > > }" > > > But farther down in the module the sytax for this object is > shown as 'Interger32': > > "mplsVpnVrfBgpPAtrCalcLocalPref OBJECT-TYPE > SYNTAX Integer32 (-1..2147483647)" > > I'd appreciate it if someone could let me know which it's > actually supposed to be, INTEGER or Integer32. > > Thanks, > Len Nieman > > > From exim@www1.ietf.org Thu Aug 28 21:08:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07789 for ; Thu, 28 Aug 2003 21:08:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sVCd-0000BR-2q for l3vpn-archive@odin.ietf.org; Thu, 28 Aug 2003 18:25:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SMPFWq000700 for l3vpn-archive@odin.ietf.org; Thu, 28 Aug 2003 18:25:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sSnK-0001Ka-AX for l3vpn-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 15:50:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12875 for ; Thu, 28 Aug 2003 15:50:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sSnI-0005Vk-00 for l3vpn-web-archive@ietf.org; Thu, 28 Aug 2003 15:50:56 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sSnI-0005Vg-00 for l3vpn-web-archive@ietf.org; Thu, 28 Aug 2003 15:50:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sQ8t-0001LN-Q4; Thu, 28 Aug 2003 13:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sOYk-0005T4-6Y for l3vpn@optimus.ietf.org; Thu, 28 Aug 2003 11:19:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23475 for ; Thu, 28 Aug 2003 11:19:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sOYj-0001An-00 for l3vpn@ietf.org; Thu, 28 Aug 2003 11:19:37 -0400 Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx with esmtp (Exim 4.12) id 19sOYi-0001A0-00 for l3vpn@ietf.org; Thu, 28 Aug 2003 11:19:36 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h7SFJ2hu334092; Thu, 28 Aug 2003 11:19:02 -0400 Received: from rotala.raleigh.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h7SFIwpv248690; Thu, 28 Aug 2003 09:18:58 -0600 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id h7SFEn6l021532; Thu, 28 Aug 2003 11:14:49 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.5/Submit) with ESMTP id h7SFEnT3021527; Thu, 28 Aug 2003 11:14:49 -0400 Message-Id: <200308281514.h7SFEnT3021527@rotala.raleigh.ibm.com> To: Vincent Parfait cc: l3vpn@ietf.org, rick@rhwilder.net, rcallon@juniper.net, ronald.p.bonica@mci.com, jguichar@cisco.com Subject: Re: Address Allocation for PE-CE links In-Reply-To: Message from vinceparfait@yahoo.com of "Wed, 27 Aug 2003 01:14:08 PDT." <20030827081408.63784.qmail@web20511.mail.yahoo.com> Date: Thu, 28 Aug 2003 11:14:49 -0400 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: , This document has come up within some informal IESG discussions. There may well be some serious difficulty in convincing the IESG, IANA, etc. that this is a good idea. Note also the comment from the Yokohama meeting: > Scott - The likelihood of setting aside a /8 for VPN providers is > close to zero. Bottom line: this document will not be an easy sell, and needs careful and rigorous justification, as well as strong community consensus. I think I understand the problem this document is trying to solve. Namely, rather than use global/public address space to number certain links, they can all be numbered out of a single SP-reserved prefix. Main Benefits: conserve global address space, don't need to get it from RIRs. Having said that, I'll note: 1) There are very few address blocks that are reserved for a particular purpose (e.g., net 10, etc.). Thus, _any_ proposal to reserve a chunk of space for some special purpose (other than normal global numbering) will be viewed skeptically. The bar for such allocations is high. So even if this WG thinks this makes sense, the larger IETF community may not. 2) The document makes no serious attempt to quantify why /12 is the right amount. Can't it be made smaller? (and note, the smaller the size, the easier it will be to justify I suspect). On the other hand, how do we know whether the size is large enough? If it isn't, then what happens? Does the allocation in fact then not really solve the problem and/or are we back where we started? 3) I don't see right off why these can't just be numbered out of global space. Sure, conserving addresses is goodness, but the real question is whether the cost of the proposal justifies the benefits. If no allocation were given for this purpose, just how much global space would be "wasted"? Is this amount worth trying to conserve when looking at the big picture? (In my mind, this is the critical question.) 4) Finally, what happens with SPs merge through acquisitions and such? Using this scheme, one immediately has collisions among the addresses used by the merged orgnizations, which is presumably not a feature. Indeed, this may make the end result rather painful when compared with just using global space. So, this scheme _does_ have potentially serious drawbacks compared with just using public addresses. Thomas From exim@www1.ietf.org Fri Aug 29 19:46:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19188 for ; Fri, 29 Aug 2003 19:46:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ssII-0000G8-NC for l3vpn-archive@odin.ietf.org; Fri, 29 Aug 2003 19:04:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TN4b5W000986 for l3vpn-archive@odin.ietf.org; Fri, 29 Aug 2003 19:04:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19spXU-0001XP-MB for l3vpn-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 16:08:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00672 for ; Fri, 29 Aug 2003 16:08:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19spXS-0005oD-00 for l3vpn-web-archive@ietf.org; Fri, 29 Aug 2003 16:08:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19spXS-0005o9-00 for l3vpn-web-archive@ietf.org; Fri, 29 Aug 2003 16:08:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19snxD-0005co-Fw; Fri, 29 Aug 2003 14:26:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19smZr-0001LN-5X for l3vpn@optimus.ietf.org; Fri, 29 Aug 2003 12:58:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10911 for ; Fri, 29 Aug 2003 12:33:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19smBt-0007mt-00 for l3vpn@ietf.org; Fri, 29 Aug 2003 12:33:38 -0400 Received: from mx03.forces.gc.ca ([131.137.245.203]) by ietf-mx with esmtp (Exim 4.12) id 19smBr-0007mF-00 for l3vpn@ietf.org; Fri, 29 Aug 2003 12:33:35 -0400 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 82CC520660B for ; Fri, 29 Aug 2003 12:31:55 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19slRq-0007aL-V2 for ietf-announce-list@asgard.ietf.org; Fri, 29 Aug 2003 11:46:02 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19slFA-0006jH-Nw for all-ietf@asgard.ietf.org; Fri, 29 Aug 2003 11:32:56 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03461; Fri, 29 Aug 2003 11:32:49 -0400 (EDT) Message-Id: <200308291532.LAA03461@ietf.org> 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-bgp-ipv6-01.txt Date: Fri, 29 Aug 2003 11:32:49 -0400 Precedence: bulk MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+25615_302320753524091_8298297389" Sender: l3vpn-admin@ietf.org Errors-To: l3vpn-admin@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --MIMEStream=_0+25615_302320753524091_8298297389 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 : BGP-MPLS VPN extension for IPv6 VPN Author(s) : J. De Clercq et al. Filename : draft-ietf-l3vpn-bgp-ipv6-01.txt Pages : 12 Date : 2003-8-29 This document describes a method by which a Service Provider may use its packet switched backbone to provide Virtual Private Network services for its IPv6 customers. This method extends the 'BGP/MPLS VPN' method [2547bis] for support of IPv6. In BGP/MPLS VPN, 'Multiprotocol BGP' is used for distributing IPv4 VPN routes over the service provider backbone and MPLS is used to forward IPv4 VPN packets over the backbone. This document defines an IPv6 VPN address family and describes the corresponding route distribution in 'Multiprotocol BGP'. This document defines support of the IPv6 VPN service over both an IPv4 and an IPv6 backbone, and using various tunnelling techniques over the core including MPLS, IPsec, IP-in-IP and GRE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-bgp-ipv6-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-bgp-ipv6-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-bgp-ipv6-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. --MIMEStream=_0+25615_302320753524091_8298297389 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+277434_3900435992484_84911478904" --MIMEStream=_1+277434_3900435992484_84911478904 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-29113719.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-bgp-ipv6-01.txt --MIMEStream=_1+277434_3900435992484_84911478904 Content-Type: Message/External-body; name="draft-ietf-l3vpn-bgp-ipv6-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-29113719.I-D@ietf.org> --MIMEStream=_1+277434_3900435992484_84911478904-- --MIMEStream=_0+25615_302320753524091_8298297389-- From exim@www1.ietf.org Fri Aug 29 19:56:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19898 for ; Fri, 29 Aug 2003 19:56:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ssSA-0000wU-R8 for l3vpn-archive@odin.ietf.org; Fri, 29 Aug 2003 19:14:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TNEnRD003603 for l3vpn-archive@odin.ietf.org; Fri, 29 Aug 2003 19:14:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19spsC-0002US-70 for l3vpn-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 16:29:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02288 for ; Fri, 29 Aug 2003 16:29:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sps9-0006L3-00 for l3vpn-web-archive@ietf.org; Fri, 29 Aug 2003 16:29:29 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sps9-0006L0-00 for l3vpn-web-archive@ietf.org; Fri, 29 Aug 2003 16:29:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19snvr-0005Rw-TN; Fri, 29 Aug 2003 14:25:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19slFA-0006N2-WB for l3vpn@optimus.ietf.org; Fri, 29 Aug 2003 11:32:57 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03461; Fri, 29 Aug 2003 11:32:49 -0400 (EDT) Message-Id: <200308291532.LAA03461@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-bgp-ipv6-01.txt Date: Fri, 29 Aug 2003 11:32:49 -0400 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: , --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 : BGP-MPLS VPN extension for IPv6 VPN Author(s) : J. De Clercq et al. Filename : draft-ietf-l3vpn-bgp-ipv6-01.txt Pages : 12 Date : 2003-8-29 This document describes a method by which a Service Provider may use its packet switched backbone to provide Virtual Private Network services for its IPv6 customers. This method extends the 'BGP/MPLS VPN' method [2547bis] for support of IPv6. In BGP/MPLS VPN, 'Multiprotocol BGP' is used for distributing IPv4 VPN routes over the service provider backbone and MPLS is used to forward IPv4 VPN packets over the backbone. This document defines an IPv6 VPN address family and describes the corresponding route distribution in 'Multiprotocol BGP'. This document defines support of the IPv6 VPN service over both an IPv4 and an IPv6 backbone, and using various tunnelling techniques over the core including MPLS, IPsec, IP-in-IP and GRE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-bgp-ipv6-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-bgp-ipv6-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-bgp-ipv6-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: <2003-8-29113719.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-bgp-ipv6-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-bgp-ipv6-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-29113719.I-D@ietf.org> --OtherAccess-- --NextPart--