Internet Engineering Task Force J. Sumimoto INTERNET-DRAFT M. Suzuki NTT Expires May 20, 2002 M. Carugi France Telecom J. De Clercq Alcatel C. Y. Lee Paragon Networks November 21, 2001 Guidelines of Applicability Statements for PPVPNs Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document provides guidelines of applicability statements for Provider Provisioned Virtual Private Networks (PPVPNs). The document is intended as guidelines to assist in the development of applicability statements for each specific PPVPN solution. # Current version focuses on layer 3 PPVPNs. Other stuff should be Sumimoto Expires May 2002 [Page 1] INTERNET-DRAFT November 21, 2001 filled out in future. 1. Summary for Sub-IP Area 1.1 Summary This document provides guidelines of applicability statements for Provider Provisioned Virtual Private Networks (PPVPNs). The document is intended as guidelines to assist in the development of applicability statements for each specific PPVPN approach. 1.2 Where does it fit in the Picture of the Sub-IP Work This document fits in ppvpn WG. 1.3 Why is it Targeted at this WG As this document describes the contents for the following work item from the ppvpn WG charter: "An applicability statement will be developed for each approach that describes the environments in which the approaches are suitable for deployment, including analysis of scaling impact of the approach on SPs and threat analysis. " This document is intended as guidelines to assist in the development of applicability statement documents for each specific PPVPN approach. (*)We do not need justification as this document directly fits in ppvpn WG. 2. Introduction (*** Objective and Scope ***) *** What is this document? *** This document is intended as guidelines to assist in the development of applicability statement documents for each specific PPVPN approach. Towards this end, it provides a high level discussion of the applicability and limitations of PPVPNs and identifies a list of PPVPN requirements. Individual applicability statements may associate the applicability and limitations of the specific approach with this list of requirements. In this respect, this document may also help providers and users to define the applicability scenarios of each PPVPN approach and to position it against a set of requirements. *** Terminology (PPVPN, Layer 3/Layer2 VPNs, CE-based VPNs)*** Sumimoto Expires May 2002 [Page 2] INTERNET-DRAFT November 21, 2001 The term "PPVPNs" refers to Virtual Private Networks (VPNs) for which the service provider participates in management and provisioning of the VPN, and there are multiple different types of PPVPNs. One distinction between the various types of VPNs considered in this document, is the distinction between PE-based VPNs and CE-based VPNs. Furthermore, from the customer's layer viewpoint, PE-based VPNs are classified into two categories, layer 3 and 2 PE-based VPNs. Multiple technical approaches are possible in these categories (e.g., BGP MPLS VPNs as defined in [2547bis], VR VPNs as defined in [VPN-VR] or [2917bis] are approaches included in layer 3 VPNs). This document provides a description of these individual approaches in Section 3. For more detail on definitions of all technical terms mentioned in this paragraph, see [VPN-FR]. *** Scope and organization of this draft, and scope expected in each individual AS draft *** Section 3 provides technical overview of each PPVPN approach to facilitate understanding of applicability and limitations content. Section 4 outlines requirements for PPVPNs as a basic list for discussing applicability and limitations. The same list may be used for individual AS documents to be developed in future. Section 5 presents applicability of PPVPNs and Section 6 presents limitations of PPVPNs. Section 7 is for security considerations, section 8 for references. This document focuses on discussion common to all approaches, however, it may play an introductory role toward individual AS documents to be developed in future. Detailed applicability and limitations sections are expected to be developed in these individual AS documents. 3. PPVPN technical overview *** Brief overview of PPVPN types *** This section provides a brief overview on the various types of PPVPNs as an introductory guidance toward discussions in the rest of this document and in developing individual AS documents. Individual approach-specific AS documents are expected to include more detailed technical overview of the respective approach. Note that as some of the engineering tradeoffs between different types of PPVPNs are important, this document will discuss them in a further version. PE-based VPNs means VPNs whose VPN-specific functions are deployed by the SP in the provider edge devices, while the customer equipment has no VPN awareness. PE-based VPNs may be distinguished by the service layer offered. Sumimoto Expires May 2002 [Page 3] INTERNET-DRAFT November 21, 2001 - Layer 3 PE-based VPNs In a layer 3 PE-based VPN service, a customer site receives IP layer (i.e., layer 3) service from the SP. The CE and PE are adjacent to each other at the data link layer and the IP layer across the access network. The PE performs forwarding of user data packets based on information in the IP layer header, such as an IPv4 or IPv6 destination address. The CE sees the PE as a layer 3 device such as an IPv4 or IPv6 router. - Layer 2 PE-based VPNs In a layer 2 PE-based VPN service, a CE receives data link layer (i.e., layer 2) service from the SP. The CE and PE are adjacent to each other at the data link layer and not at the IP layer across the access network. A PE performs forwarding of user data packets based on information in the packets' data link layer headers, such as a frame relay DLCI or 802.1q VLAN tag. That is, the CE sees the PE as a layer 2 device such as a FR switch or an Ethernet VLAN switch. Both layer 3 and 2 PE-based VPNs include various technical approaches. Specific approaches of layer 3 PE-based VPNs include BGP MPLS VPNs as defined in [2547bis], virtual routers (VRs) as defined in [VPN-VR] or [2917bis]. Specific approaches of layer 2 PE-based VPNs include port-based VPNs (i.e., where the SP provides a layer 2 interface, such as Frame Relay or ATM, to the VPN customer, while using IP-based mechanisms in the provider infrastructure to improve scalability and configurability over traditional L2 networks). All types of PPVPNs adopt some tunneling mechanisms in SP networks based on IP (for example, MPLS, L2TP, GRE and IPsec) and service providers participate in management and provisioning of the PPVPNs. The tunneling mechanisms considered for layer 2 PPVPNs are those specified in the charter of the pwe3 working group i.e., MPLS, GRE and L2TP. This is part of the requirements mentioned in the following section. This document also provides brief overview of CE-based VPNs here, for mentioning requirements specific to CE-based VPNs below. - CE-based VPNs In CE-based VPNs, the VPN-specific functions (e.g. tunneling) are deployed in the customer edge devices, while the provider network has no VPN awareness on the data-plane level. For provider provisioned CE-based VPNs, the VPN functions on the CE device are managed by the service provider [VPN-FR]. Sumimoto Expires May 2002 [Page 4] INTERNET-DRAFT November 21, 2001 With CE-based VPNs, the VPN tunnels are IP tunnels (IPsec, L2TP, GRE, etc.) originated at the CE devices. The PE device will forward the customer's IP packets based on the encapsulating (outer) IP header. As such, the PE device and the CE device have a peering relationship at the IP level, but the PE device has no VPN knowledge. 4. Outline of requirements for PPVPNs *** Why and how does this document outline requirements? *** This section briefly outlines main requirements for PPVPNs provided in [VPN-REQ] as a basic list for discussing applicability and limitations in the following sections. Detailed requirements are out of the scope of this document, because these are fully presented in [VPN-REQ]. This section classifies the requirements into 3 categories, general requirements (for both layer 3/layer 2 PE-based VPNs and CE-based VPNs), requirements specifically for PE-based layer 3 VPNs, and requirements specifically for layer 2 PE-based VPNs and requirements specifically for CE-based VPNs. Above distinction is just a suggestion to be discussed. The point we want to raise here is that we should classify requirements according to the most appropriate way to develop individual AS documents. Apart from customer/service provider requirement distinction, a more extended classification could be : - general requirements, - service-specific requirements (L3 PE-based, L2 PE-based, CE-based, etc.), basically following current framework/req ID taxonomy - solution-specific requirements, or approach-specific requirements (we may have in theory more than one solution per each approach) *** Concrete list of the requirements: 4.1 - 4.4 *** 4.1 General requirements 4.1.1 Security (including threat analysis as mentioned in charter) Each PPVPN solution should support a range of security related features. Basic levels of security service, like traffic isolation, should be supported. Enhanced levels of security services, like edge-to-edge encryption, authentication, or replay attack prevention should be supported if some customers require them. Furthermore, firewall functionality may be desired when Internet access is provided. 4.1.2 QoS and SLA support Sumimoto Expires May 2002 [Page 5] INTERNET-DRAFT November 21, 2001 With regards to QoS support, a PPVPN shall be able to support QoS in one or more of the following standard modes: - Best Effort (support mandatory for all PPVPN types) - QoS support (e.g., Intserv) by RSVP, TE by RSVP extension or CR-LDP - Diffserv marked - Across packet-switched access networks 4.1.3 Manageability (including ease of monitoring/accounting) An SP and its customers must be able to manage the capabilities and characteristics of their VPN services. To the greatest possible extent, automated operations and interoperability with standard management platforms should be supported. 4.1.4 Interoperability Each technical solution should support the Internet standards (in terms of compatibility and modularity). Multi-vendor interoperability at network element, network and service levels among different implementations of the same technical solution should be guaranteed (that will likely rely on the completeness of the corresponding standard). This is a central requirement for SPs and customers. The technical solution must be multi-vendor interoperable not only within the SP network infrastructure, but also with the customer's network equipment and services making usage of the PPVPN service. 4.1.5 Scalability (convergence time, routing tables, VPN size, routing instances, etc) Routing updates in VPNs shall not affect the stability of the SP network. Applicability and limitations in relation with parameters provided in 5.1.1 [PPVPN-REQ] should be provided. (See 5.1.2 [PPVPN-REQ] for solution-specific metrics) 4.1.6 Migration impact A range of scenarios of customer migration must be supported. Full migration of all sites must be supported. Support for cases of partial migration is highly desirable [Y.1311.1], that is, legacy private network sites that belong to the PPVPN service should still have L2 connectivity or L3 reachability to the sites that migrate to the PPVPN service. 4.1.7 Learning VPN Related Information Configuration of CE and PE devices is a significant task for a Sumimoto Expires May 2002 [Page 6] INTERNET-DRAFT November 21, 2001 service provider. Solutions should strive to contain methods that dynamically allow VPN information to be learned by relevant PEs and/or CEs to reduce configuration complexity. 4.1.8 Reliability (Including Protection/Restoration) The Service provider should be able to deploy protection and restoration mechanisms within the service provider's backbone infrastructure to increase reliability and fault tolerance of the VPN service offering. These techniques should be scalable. Therefore, implementation of such function in the backbone on a per-VPN basis may be prohibited. 4.1.9 Network environment Functions required to PEs: Some PPVPN types or approaches require special functions to PEs. The less such special functions are, the easier to deploy. (To be completed.) 4.1.10 Support of various service scenarios (inter-AS, wholesale, Internet access, extranet, etc.) (To be filled out.) 4.1.11 Support of various connectivity scenarios (access network connectivity, etc.) (To be filled out.) 4.1.12 Topology A PPVPN should support arbitrary, customer agent defined inter-site connectivity, ranging, for example, from hub-and-spoke, partial mesh to full mesh topology. 4.1.13 Operation/Deployment considerations (including adding/moving sites) Ease of Operation/Deployment is highly desired. Special skill for operation/deployment may be an obstacle. (To be completed.) 4.1.14 Routing protocol and policy routing support There should be no restriction on the routing protocols used between CE and PE devices or between CE devices. At least the following protocols must be supported: static routing, IGP, such as Sumimoto Expires May 2002 [Page 7] INTERNET-DRAFT November 21, 2001 RIP, OSPF, IS-IS, or BGP. (To be completed.) 4.1.15 Cost considerations (To be filled out.) 4.2 Requirements specifically for Layer 3 PE-based VPNs 4.2.1 Addressing The following supports from PPVPN solutions are required: o globally unique/private IP addresses, IPv4/IPv6, for both unicast and multicast o obtained by the customer from IANA / statically assigned by the PPVPN service provider o on-demand, dynamically assigned IP addresses (e.g., DHCP), irrespective of whether the access is temporary (e.g., remote) or permanent (i.e., dedicated) Customer VPN address overlapping shall be supported - IP addresses have to be unique only within a given VPN, but not across VPNs. In the case where private IP addresses are used, a PPVPN solution must provide a means for an SP to translate such addresses to public IP addresses for communication with other VPNs using overlapping addresses, or the Internet. 4.2.2 Interworking with other solutions Service interworking among different solutions providing PPVPN services is highly desirable and should be supported in a scalable manner as much as possible. 4.2.3 Provisioning Value-Added Service Access (To be filled out.) 4.3 Requirements specifically for Layer 2 PE-based VPNs (Requirements from the following references are to be outlined here; draft-ietf-ppvpn-l2vpn-00.txt draft-tsenevir-l2-req-01.txt, draft-ouldbrahim-ethernet-l2vpn-requirements-00.txt, draft-ouldbrahim-l2vpn-lpe-00.txt, draft-heron-ppvpn-vpsn-reqmts-00.txt, draft-kb-ppvpn-l2vpn-motiv-00.txt, Sumimoto Expires May 2002 [Page 8] INTERNET-DRAFT November 21, 2001 draft-kompella-ppvpn-l2vpn-00.txt, draft-rosen-ppvpn-l2-signaling-00.txt, draft-heinanen-dirldp-eth-vpns-01.txt.) 4.4 Requirements specifically for CE-based VPNs 4.4.1 Addressing Same requirements as in section in 4.2.1. 4.4.2 Support for dynamic routing Independently of the used tunneling mechanism and the way the VPN tunnels are established, a CE-based VPN solution should support for the dynamic distribution of routing information between different sites of the same VPN. The relationship between routing information, VPN membership and VPN tunnel status should always be consistent. 4.4.3 SP's management system requirements As the SP will configure the VPN functions on the customer's CE devices, the 'provisioning mechanism' that is used plays an important role. Different options are available for this provisioning: manual configuration, the use of a management protocol (e.g. SNMP, COPS, etc.), of a directory access protocol (e.g. LDAP), etc. Important requirements with regards to this provisioning scheme are: - the scalability (as a single SP may need to provision a large amount of CE devices from a large number of VPNs) - the security aspects with regards to authentication, privacy etc. (as the security of the VPN management affects the complete security of the VPN itself). 5. Applicability *** Applicability description of identified solutions *** 5.1 Security All of PPVPN approaches (BGP-VPNs, VR, port-based VPNs) achieve logical traffic isolation by adopting VPN tunnels operated by service providers. All of PE-based VPN solutions prohibit an end user from IP masquerade or mis-delivering toward unauthorized VPNs, as a PE identifies correspondence between L2 interfaces toward CEs Sumimoto Expires May 2002 [Page 9] INTERNET-DRAFT November 21, 2001 and VPNs. All of CE-based VPN solutions achieve logical traffic isolation by adoption direct VPN tunnels between CE devices. It follows that all of PPVPN solutions achieve the same security level as VPNs implemented by TDM or packet network. For more discussion regarding stronger security, see the limitation section. 5.2 QoS support/SLA support - Best effort Any IP packet delivery of both BGP MPLS and VR approach by using any tunneling technology (MPLS, IPsec, or GRE) without optional QoS support mechanisms is best effort. - QoS support (e.g., Intserv by RSVP, TE by RSVP extension or CR- LDP) Any [current] individual approach documents do not specify how they support QoS by RSVP [extension] or CR-LDP. If an individual approach can support it, the corresponding approach-specific AS document should clarify its applicability and limitations from the viewpoint of interval, kind of services, and how to operate. - Diffserv If an individual approach can support it, the corresponding approach-specific AS document should clarify its applicability and limitations from the viewpoint of interval, kind of services, and how to operate. ('A Core MPLS IP VPN Architecture' [2917bis] refers to a method to support diffserv by using private LSPs per VPN. Other [current] individual approach documents do not specify how they support diffserv.) Furthermore, method for tunnels to carry DSCP information must be clarified, since it depends on which tunneling technology is used and this document should make sure of them. Current situation of such clarification is as follows; MPLS -- Work in progress [MPLS-DIFF]. IPsec, IP in IP -- [RFC2983] gives two conceptual models for the interaction of diffserv with IP tunnels and relevant considerations. GRE -- There is no field to carry DSCP information in GRE header. Moreover, there is no specification of how to treat fields for DSCP between an outer IP header and an inner IP header in case that GRE is applied for IP encapsulation within IP. Sumimoto Expires May 2002 [Page 10] INTERNET-DRAFT November 21, 2001 5.3 Manageability Defining MIBs for BGP MPLS VPNs approach are on progress. VR approach- specific MIBs are on progress. MIBs for the port-based VPN approaches are not currently defined (some work in pwe3 WG may be used for that). A MIB for the PP CE-based approach is not currently defined. Detailed descriptions are expected to be included in each AS document per technical solution. 5.4 Interoperability Each approach-specific AS document must clarify applicability and limitation in terms of interoperability within each technical solution belonging the approach. 5.5 Scalability See the limitations Section. 5.6 Migration impact Most important point here is whether any CE can access a PE in the same manner as it accesses VPNs based on leased lines. As VR approach makes use of standard routing protocols without any extensions, any CE of VR approach can access a PE in the same manner as it accesses VPNs based on leased lines. With regard to BGP MPLS approach, any CE can access a PE in the same manner as it accesses VPNs based on leased lines if the CE does not directly participate in BGP MPLS control. However, as is well known , any CE is required extended BGP capability if the CE directly participates in BGP MPLS control. See the limitation section. 5.7 Learning VPN Related Information This item specifically provides whether each approach can supports auto-discovery mechanisms. Detail should be described in each approach-specific AS document. If some constraints exist, they should be clarified in the limitations section. Both VR and BGP MPLS approach can support membership discovery mechanism. See the same item in the limitations Section. 5.8 Reliability If some restoration/recovery mechanisms are built in tunneling technologies, they are useful to enhance reliability of PPVPNs. If such built-in mechanism is not available, route duplication may be used for enhancing reliability of PPVPNs. Sumimoto Expires May 2002 [Page 11] INTERNET-DRAFT November 21, 2001 5.9 Network environment Each approach-specific AS document must clarify special requirements on network environment for using the approach. Some examples are given here. Though VR approach requires that PE devices implement VR functions, it does not always require implementation of any extension of standard routing protocols. BGP MPLS approach requires that PE devices implement not only VRF functions but also extended BGP and semantics specified in [2547bis]. Note that PE devices of BGP MPLS approach are required MPLS functions even in case that VPN tunnels are supported by IPsec or GRE (i.e., other than MPLS) within SP networks. 5.10 Support of various service scenarios (inter-AS, wholesale, Internet access, extranet, etc.) (To be filled out.) 5.11 Support of various connectivity scenarios (access network connectivity, etc.) (To be filled out.) 5.12 Topology As applicability of topology depends on each technical solution, each AS document for specific technical solution is expected to describe this issue for the solution. 5.13 Operation/Deployment considerations (Includes adding/moving sites) (To be filled out.) 5.14 Routing protocol and policy routing support (To be filled out.) 5.15 Cost considerations (To be filled out.) 5.16 Addressing (To be filled out.) 5.17 Interworking with other solutions Sumimoto Expires May 2002 [Page 12] INTERNET-DRAFT November 21, 2001 Applicability of layer 3 PPVPN interworking is described here, based on the interworking interface section of [PPVPN-FR]. Static interworking on data plane without auto-discovery nor management has been made available between VR approach and BGP MPLS approach. See limitations Section for a limitation related auto-discovery and management. 5.18 Provisioning Value-Added Service Access (To be filled out.) 6. Limitations *** Description of general limitations of identified solutions *** 6.1 Security Not all PPVPN solutions support confidentiality, integrity, authentication, and replay attack prevention. To achieve them, IPsec (or other encryption mechanism) must be used as tunneling mechanism or used over VPN tunnels. Even with the use of IPsec, the security level offered is dependent on the scope of the IPsec security: encrypting on a CE-to-CE basis (as in CE-based VPNs) will offer a higher level of protection than encrypting on a PE-to-PE basis (as in PE-based VPNs). Note that some configuration error can cause traffic isolation to be broken. 6.2 Scalability (To be filled out.) 6.3 Learning VPN Related Information BGP MPLS approach is bound to specific membership discovery mechanism using extended BGP and semantics specified in [2547bis]. 6.4 Operation/Deployment considerations (including adding/moving sites) (To be filled out.) 6.5 Addressing In case that a site belongs to multiple PPVPNs, they cannot have duplicated IP addresses. (To be completed.) Sumimoto Expires May 2002 [Page 13] INTERNET-DRAFT November 21, 2001 6.6 Interoperability Each approach-specific AS document must clarify limitations in terms of interoperability within each technical solution belonging the approach. 6.7 Interworking with other solutions Auto-discovery and management scheme beyond interworking interface is not clear at present. (*)Other items have to be added. 7. Security considerations (To be written.) 8. References [PPVPN-FR] Callon, R. et al., "A Framework for Provider Provisioned Virtual Private Networks," work in progress. [PPVPN-REQ] Carugi, M. et al., "Service Requirements for Provider Provisioned Virtual Private Networks," work in progress. [2547bis] Rosen E. et al., "BGP/MPLS VPNs," work in progress. [VPN-VR] Ould-Brahim, H. et al., "Network based IP VPN Architecture using Virtual Routers, " work in progress. [2917bis] Muthukrishnan, K. et al., "A Core MPLS IP VPN Architecture, " work in progress. [MPLS-DIFF] Le Faucheur, F. et al., "MPLS Support of Differentiated Services, " work in progress. [RFC2983] Black, D., "Differentiated Services and Tunnels," RFC2983, October 2000. (*) Additional references to be provided here. Sumimoto Expires May 2002 [Page 14] INTERNET-DRAFT November 21, 2001 9. Authors' address Junichi Sumimoto NTT Information Sharing Platform Labs. 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Email: sumimoto.junichi@lab.ntt.co.jp Muneyoshi Suzuki NTT Information Sharing Platform Labs. 3-9-11, Midori-cho, Musashino-shi, Tokyo 180-8585, Japan Email: suzuki.muneyoshi@lab.ntt.co.jp Marco Carugi France Telecom Research and Development Technopole Anticipa -- 2, av. Pierre Marzin 22307 Lannion cedex, France Phone : + 33 2 96 05 36 17 Email : marco.carugi@francetelecom.com Jeremy De Clercq Alcatel Fr. Wellesplein 1, 2018 Antwerpen, Belgium E-mail: jeremy.de_clercq@alcatel.be Cheng-Yin Lee Paragon Networks leecy@paragon-networks.com Sumimoto Expires May 2002 [Page 15]