PPVPN Working Group Tissa Senevirathne Internet Draft (Force10) Document: draft-tsenevir-vpn-discovery-00.txt Category: Informational September 2001 VPN Auto discovery - Problem Space (scope), Requirements and Architecture Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt 1. Abstract This document identifies the scope of VPN discovery and defines the requirements that need to be satisfied by VPN auto discovery solutions. A possible 3-Layered VPN auto discovery architecture is presented. Senevirathne, et.al Informational - April 2002 1 draft-tsenevir-vpn-discovery-00.txt September 2001 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 3. Introduction VPN deployments and usage is becoming popular. As VPN usage increases, number of VPN serviced by a given PE devices are on the rise. In the same time VPN are evolving from simple point-point VPN to multi-point VPN. As such automatic discovery of VPN membership and configuration information is becoming important. When attempting to provide a solution for automatic VPN discovery it is important to, first, define the scope or the problem space of VPN discovery. Secondly, based on the scope, set of requirements need to be defined. Based on scope and requirements, VPN auto discovery architecture needed to be defined. In this document, we attempt to outline the scope and requirements for Auto discovery of VPN membership and configuration information. In addition a possible VPN discovery architecture is presented. 4. Scope of VPN auto discovery In this section we attempt to cover the problem space of VPN auto discovery. Proper identification of the problem space or the scope of VPN auto discovery is important for subsequent solutions. 4.1 Discovery of member PE devices Discovery of end-points of VPN is the first problem. Different VPN may have corresponding end-points in different PE devices. Member PE devices MUST have capabilities to fully identify, either by configuration or some other method, all other member PE devices (end-points) for a given VPN. 4.2 Control (signaling) channel between PE devices Member PE devices MUST have some means of communication between each other. This communication channel is used to exchange subsequent configuration information. 4.3 Distribution of configuration information Distribution of configuration information is defined as distribution of configuration information related to each VPN of a given end- point (PE). All other participating PE of the VPN is required to know this information to successfully establish and maintain the VPN membership. Senevirathne, et.al Informational - April 2002 2 draft-tsenevir-vpn-discovery-00.txt September 2001 4.4 VPN data plane creation, maintenance and termination This is the scope of VPN tunnels 5. Requirements for VPN auto- discovery 5.1 Discovery of member PE devices MUST support intra AS SHOULD support inter AS SHOULD not impact the existing routing infrastructure. MUST comply with following security consideration - MUST have capabilities to limit the scope of distribution - SHOULD have methods to authenticate and verify the identity of other members - SHOULD have capabilities to securely distribute information 5.2 Control (signaling) channel between PE devices MUST be based on IP or IETF ratified protocol MUST support intra AS SHOULD support inter AS SHOULD have capabilities to scale to the required degree. MUST comply with following security consideration - SHOULD have methods to authenticate and verify the identity of other members - SHOULD have capability to securely distribute information 5.3 Distribution of configuration information MUST use the signaling channel setup in above 4.2 in the event of automatic distribution of configuration information. Configuration information MAY be either manually (by configuration) or automatically distributed. MUST support intra AS SHOULD support inter AS SHOULD have capabilities to scale to the required degree. Senevirathne, et.al Informational - April 2002 3 draft-tsenevir-vpn-discovery-00.txt September 2001 SHOULD not impact the existing routing infrastructure. MUST be capable of notifying any configuration or membership changes in "event driven" manner. MUST comply with following security consideration - SHOULD have methods to authenticate data - SHOULD have capability to securely distribute information 5.4 VPN data plane creation, maintenance and termination SHPULD have capabilities to support different tunneling methods within a given VPN. (As an example, one end-point may wish to use IPsec while other GRE and etc..) MUST support intra AS SHOULD support inter AS SHOULD have capabilities to scale to the required degree. MUST comply with Requirements specified in [VPNREQ] 6.0 Architecture Here we propose a 3-layered VPN auto discovery architecture. The proposed architecture allows scoping of information distribution. Also, it is presumed that layered architecture presented here facilitates scaling. ----------------------------------------------------- Peering -x-x-x- Layer | P1 | ---------- -x-x-x- --------------------/----\----------------------------- / \ / \ / \ ----------------/------------\-------------------------- -:-:- -:-:- Broker | A1 |------| A2 |--...... Layer -:-:- -:-:- / \ ------------| ----- |-------------------------------------- | | | | | | ------------|-------|------------------------------------- | | Senevirathne, et.al Informational - April 2002 4 draft-tsenevir-vpn-discovery-00.txt September 2001 PE Layer PE1 ... PEx ------------------------------------------------------------ Fig: 3-layred VPN auto-discovery architecture 6.1 Peering Layer Peering Layer is at the top of the 3 Layer architecture. Devices in this layer are called Peering Agents (PA). There are two or more PA in peering Layer. Peering Agent (PA+ may be within the AS or in different AS. Peering Agent can be either PE device, separate device or NMS station. The objective of Peering Layer is to summarize and advertise local VPN information, much in the same way like a BGP router or MSDP peering router. 6.2 Broker Layer Broker Layer is the abstraction layer between the Peering Layer and PE layer. Broker Agent (BA) maintains session with PE device and learns local VPN membership and configuration information. BA maintains sessions with other BA to learn VPN information maintained by them. In addition BA maintain sessions with one or more peering agents (PA) to advertise and learn VPN information. 6.3 PE Layer PE Layer contains the PE devices that participate in VPN services. A PE device maintains session with a BA (sometimes, for redundancy purposes more than one). PE device advertises local VPN information to the BA. PE learns VPN information of other VPNs from BA. BA MAY advertise, based on local policies, learnt information to other BA and PA devices. It is important to note that solutions based on this architecture MUST have methods to suppress reflection of VPN information. Such suppression is required to avoid looping of advertisements. 6.4 Advantages Above architecture allows to use both PUSH and PULL modes. Both the modes are needed: 1. Information needed by new clients to join the VPN is distributed using PULL mode. 2. Configuration changes are distributed to existing client using PUSH mode. Allows applying required distribution and discovery policies in a controlled fashion. Manual configuration and/or Network Management based discovery methods can be easily superimposed on the provided model. Independent of the Data plane. Senevirathne, et.al Informational - April 2002 5 draft-tsenevir-vpn-discovery-00.txt September 2001 Allows defining policies such that VPN information distribution can be restricted to the required scope. Can work both inter and intra AS deployments 7. Solution In this section we present an overview of a possible solution that is based on MSDP (Multicast Source Discovery Protocol). In this proposed solution we suggest to treat VPN identifier that is Route Distinguisher (RD) as equivalent to Group address in MSDP. The source address (SA) is treated as the address of the PE that announces this VPN. It is suggested to define new set of TLV to encode required information for VPN discovery. A new TLV to accommodate VPN membership withdrawal or revocation. This TLV is propagated to all peer agents, broker agents and registered PE devices for that VPN. 8. Security Considerations Section 5, specifies related security considerations. Refer to [VMI] and [PPVPNreq] document for detail security analysis of VPN services. Solutions based on the architecture provided in this document, MUST provide related security analysis of the solution, specifically, in relation to the points highlighted in section 5 in this document. 9. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 10. Acknowledgments Various people who reviewed this draft provided valuable comments and feedback. 11. Author's Addresses Tissa Seneviratnne Senevirathne, et.al Informational - April 2002 6 draft-tsenevir-vpn-discovery-00.txt September 2001 Force10 Networks 1440 McCarthy Blvd Milpitas, CA 95035 Phone: 408-965-5103 Email: tissa@force10networks.com Senevirathne, et.al Informational - April 2002 7 draft-tsenevir-vpn-discovery-00.txt September 2001 Full Copyright Statement "Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Senevirathne, et.al Informational - April 2002 8