Network Working Group Z. Li Internet-Draft Y. Yin Intended status: Informational L. Zhang Expires: April 30, 2015 Huawei Technologies October 27, 2014 An Architecture of Instant VPN draft-li-bess-instant-vpn-arch-00 Abstract With the wide application of cloud computing technology, more and more enterprises will hire public cloud data center resources, reduce their own costs. Providers need to enterprise data center rental network and enterprise own network connected together, provide enterprise lease line services. L3VPN is most providers provide this service selection. New VPN line business needs to rapidly deploy, but the current technology cannot meet this requirement. This document introduces the architecture to deploy L3VPN rapidly which can satisfy the requirement for service provision. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RE COMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 30, 2015. Li, et al. Expires April 30, 2015 [Page 1] Internet-Draft An Architecture of Instant VPN October 2014 Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirement . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. VPN Controller . . . . . . . . . . . . . . . . . . . . . 5 4.1.1. VPN User Interface . . . . . . . . . . . . . . . . . 6 4.1.2. VPN Authentication . . . . . . . . . . . . . . . . . 6 4.1.3. VPN User Management . . . . . . . . . . . . . . . . . 6 4.1.4. VPN Route Management . . . . . . . . . . . . . . . . 7 4.2. PE . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.1. VPN User Management . . . . . . . . . . . . . . . . . 7 4.2.2. VRF Instance Automatically Create . . . . . . . . . . 7 4.2.3. Access Side Configure Automatically . . . . . . . . . 8 4.2.4. VPN Tunnel Automatically Setup . . . . . . . . . . . 8 4.3. CE . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. VPN User Information Input . . . . . . . . . . . . . . . 8 5.2. VPN User Authentication Process . . . . . . . . . . . . . 9 5.3. VRF Instance Configuration . . . . . . . . . . . . . . . 9 5.4. Route Protocol Configuration Between PE and CE . . . . . 10 5.5. VRF Route Distribution . . . . . . . . . . . . . . . . . 10 5.6. VPN Tunnel Establishment . . . . . . . . . . . . . . . . 10 6. Protocol Extension Requirements . . . . . . . . . . . . . . . 11 6.1. Authentication Between CE and PE . . . . . . . . . . . . 11 6.2. Authentication Between PE and VPN Controller . . . . . . 11 6.3. Configuration Distributed from VPN Controller to PE . . . 11 6.4. Tunnel Information Distributed from VPN Controller to PE 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Normative References . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Li, et al. Expires April 30, 2015 [Page 2] Internet-Draft An Architecture of Instant VPN October 2014 1. Introduction Enterprise leased line is one of the provider's principal business. Many providers are currently using L3VPN technology to provide this type of service, and with the development of cloud computing, the public cloud data centers will provide network service for a large number of enterprises and the provider's network need deploy massive L3VPNs in a short time. But the current L3VPN deployment has following problems to be unable to meet fast deployment requirements. 1. The deployment of an L3VPN need to configure the VPN instance and tunnel on PE nodes. If an L3VPN has a lot of access points, many PE nodes need to be configured and creation of tunnels will become complicated. For data centers to support massive tenants, the PE nodes need to configure massive VPNs. The configuration work will be huge and error-prone. 2. The L3VPN deployment need to configure RD, RT, etc. which need complex unified planning and design. 3. For enterprise lease line services , providers and enterprises need to plan ahead between CE and PE IP address and routing protocols, and enterprise CE position changes, need to reconfigure the corresponding PE. This document defines an architecture of instant L3VPN to deploy L3VPN fast which is achieved by central control. 2. Terminology VPN: Virtual Private Network CE: Customer Edge Router PE: Provider Edge Router MP-BGP: Multiprotocol BGP RT: Route Target RD: Route Distinguisher EAP: Extensible Authentication Protocol RADIUS: Remote Authentication Dial In User Service I2RS: Interface to The Internet Routing System Li, et al. Expires April 30, 2015 [Page 3] Internet-Draft An Architecture of Instant VPN October 2014 3. Requirement This chapter describe requirements of rapid deployment of L3VPN for cloud computing scenarios from the point of view of the enterprise and the provider: For enterprises: Requirement 1: Enterprise users can apply for VPN services from providers through web pages. Requirement 2: Enterprise users can have access to the VPN network at any position. Requirement 3: When the position of the enterprise's CE can be changed, configuration after migration need not to be changed and CE can still access L3VPN network real time. Requirement 4: Enterprises can define access strategy between any two CEs. Requirement 5: Enterprises can define the bandwidth and other constraints between any two CEs. Requirement 6: Enterprises can apply for virtual machine resources from provider data center, and the virtual machine can quickly access the enterprise L3VPN networks. For providers: Requirement 1: Providers can deploy VPN service rapidly according to business requirements of the enterprise. Requirement 2: Providers can do for enterprise user authentication, authorization, and accounting functions. Requirement 3: Providers can manage all VPN, including viewing each VPN's CE ID, PE address which CE access to, the tunnel state information between PEs, etc., and can provide enterprises with a VPN SLA reports. 4. Architecture The architecture of Instant VPN is shown in the following figure. There is a VPN controller in the network to directly control all PE devices. This document focuses on the VPN deployment in one AS. The central control architecture for the inter-AS VPN will be described in the future version. Li, et al. Expires April 30, 2015 [Page 4] Internet-Draft An Architecture of Instant VPN October 2014 +---------------------------------------------+ | | | +----------------+ +----------------+ | | | VPN | | VPN USER | | | | AUTHENTICATION | | INTERFACE | | | +----------------+ +----------------+ | | VPN Controller | | +----------------+ +----------------+ | | | VPN USER | | VPN ROUTE | | | | MANAGEMENT | | MANAGEMENT | | | +----------------+ +----------------+ | | | +---------------------------------------------+ | | | | | | +-----|-----------------|----------------|------+ | | | | | | | +---------+ | | | | | PE | | | | | | NODE 1 | | | | | /| BGP |\ | | | | / | CLIENT | \ | | | | / +---------+ \ | | | | / \ | | +----+ | +--------+ / \ +--------+ | +----+ | | | | PE | / \ | PE | | | | | CE |----| NODE 2 |/ \| NODE n |----| CE | | | | | BGP | ...... | BGP | | | | +----+ | | CLIENT | | CLIENT | | +----+ | +--------+ +--------+ | | | +-----------------------------------------------+ Figure 1 An Architecture of Instant VPN 4.1. VPN Controller There are four main function modules in the VPN Controller which controls all PE devices: -- VPN User Interface -- VPN Authentication -- VPN User Management -- VPN Route Management Li, et al. Expires April 30, 2015 [Page 5] Internet-Draft An Architecture of Instant VPN October 2014 4.1.1. VPN User Interface 1. Provides the interface for the enterprise VPN user to input VPN information which will be saved to the VPN User Management module. 2. Provide VPN information query interface to view the VPN information through the interface, such as the current on-line of CE ID, PE address which CE accessed to, VPN tunnel information, VPN SLA etc. 4.1.2. VPN Authentication 1. Receive the authentication request message of CE from PE. 2. Being responsible for the authentication of VPN users on-line by examining the VPN ID+CE ID and CE password. 3. Reply message with VPN information for the users that pass the authentication successfully . 4.1.3. VPN User Management 1. Being responsible for the management of all providers of VPN user information, including: VPN ID: unique ID of enterprise VPN users. CE ID: unique ID of CE, which should be guaranteed to be unique within an enterprise VPN user. CE password: CE access authentication password. Access strategy between CEs: definition of strategy which defines how two different CEs in the same VPN access to each other. Routing protocol between CE and PE: choice of routing protocol which runs between CE and PE. If BGP is chosen, the private network AS number should be provided. PE identifier and access interface: supply the actual physical access information, which will be taken into account for the VPN RD and RT allocation algorithm and will get the VPN configuration finally. IP address and mask connected between CE and PE: IP address and subnet mask of the PE's interface which accessed to CE, the IP address and subnet mask of the CE's interface which accessed to PE. Li, et al. Expires April 30, 2015 [Page 6] Internet-Draft An Architecture of Instant VPN October 2014 All above Information should be provided by the enterprises when they apply for VPN service. 2. Automatic generating of configuration for each access CE, including VRF name, RD, RT information. 3. Management of all on-line VPN users, including all CE IDs, PE addresses which CE accessed to, etc. 4.1.4. VPN Route Management 1. Receives all VPN routes from all PEs. Calculate routes for each VRF based on each VRF's IRT and ERT. 2. Send the VRF routes to PE based on the strategy of center control. 3. Apply the route policy centrally to control the route distribution. 4.2. PE There are four main function modules in PE devices: VPN user management function, VRF instance automatically create function, Access side configuration automatically function, VPN tunnel automatically set up function. 4.2.1. VPN User Management 1. Receive authentication request message from CE, including CE ID, CE password, and relay the authentication request to VPN controller after appending the physical PE ID and interface information. 2. Receive authentication response message from VPN controller, including authentication result, VPN ID, CE ID, the routing protocol running with CE, the CE interface IP address and mask which access to PE, the PE interface IP address and mask which access to CE, the CE AS number and PE AS number if route protocol is BGP, and relay the authentication response message to CE. 3. Manage all CE users, recording VPN ID, CE ID, the CE access interface, accounting for VPN user. 4.2.2. VRF Instance Automatically Create 1. Create VRF instance based on the configuration which VPN controller sent, configure the RD and RT automatically Li, et al. Expires April 30, 2015 [Page 7] Internet-Draft An Architecture of Instant VPN October 2014 2. Bind the CE access interface with VRF automatically. 4.2.3. Access Side Configure Automatically 1. Configure the IP address and subnet mask of the interface which access to CE based on the authentication response message. 2. Configure the route protocol based on the message which VPN controller sent. 4.2.4. VPN Tunnel Automatically Setup 1. For each VRF, receive the following information which VPN controller sent: ---The PE IP address list which can access to the VPN. ---The tunnel information including tunnel type, tunnel bandwidth and other constraints if MPLS TE tunnel is used. 2. Set up the tunnel automatically with each PE. 4.3. CE 1. Automatically initiate VPN user authentication request to PE. 2. Receive VPN user authentication response message including the CE IP address and mask, the route protocol between CE and PE, the PE IP address and AS number if protocol is BGP. 3. Configure the interface IP address, mask and route protocol automatically. 5. Procedures 5.1. VPN User Information Input Step 1: Enterprise users input following information based on the VPN User interface which VPN controller provided: -- CE ID -- CE password -- access strategy between CEs -- routing protocol between CE and PE Li, et al. Expires April 30, 2015 [Page 8] Internet-Draft An Architecture of Instant VPN October 2014 -- IP address and mask connected between the CE and the PE. Step 2: VPN Controller saves the VPN information to the VPN User Management. 5.2. VPN User Authentication Process Step 1: CE initiates VPN service request to PE automatically , carrying the CE ID, CE password. Step 2: PE receives the authentication request and appends the physical PE ID and access interface information, then sends the authentication request to VPN Controller. Step 3: VPN Controller receives and processes the authentication request through the VPN Authentication module based on the information input by the enterprise users. Step 4: If the authentication passes, VPN Controller sends authentication success message to PE, carrying information: VPN ID, CE ID, the routing protocol between CE and PE, the CE IP address and mask, the PE IP address and mask, the CE AS number and PE AS number if routing protocol is BGP. Step 5: PE decapsulates authentication success message. If the routing protocol between CE and PE is BGP, PE's own AS number and IP address will be encapsulated in an authentication success message and sent to CE. 5.3. VRF Instance Configuration Step 1: After the CE authentication passes, VPN Authentication module informs VPN User Management module. Step 2: VPN User Management module creates an VRF instance for the CE user, automatically generating VRF RD, and computing import RT and export RT information based on the physical access PE and interface information and the access strategy between CEs Step 3: VPN User Management module sends VRF configuration information to the corresponding PE. Step 4: PE receive the VRF configuration from VPN controller, and create VRF automatically, binding VRF with the interface which CE access to. Li, et al. Expires April 30, 2015 [Page 9] Internet-Draft An Architecture of Instant VPN October 2014 5.4. Route Protocol Configuration Between PE and CE Step 1: After the CE user authentication passes, VPN User Management gets the routing protocol information between CE and PE and automatically generates the routing protocol configuration of the PE. If the BGP protocol runs between the CE and the PE, the CE's IP address and AS number are also required. If the enterprise define the access strategy, also generates the route policy configuration. Step 2: VPN User Management sends the configuration to PE to compete the configuration automatically. Step 3: After the CE receives the authentication success message from PE, it can get the route protocol type between CE and PE. If the protocol is BGP, it can also get the PE's IP address and AS number from the message. Then the CE can complete the routing configuration automatically. 5.5. VRF Route Distribution Step 1: BGP peers establish automatically between the PE and the VPN Controller. Step 2: CE advertises its routes to PE. Step 3: PE advertises the routes which are received from CE to the VPN controller. VPN controller processes the routes through VPN Route Management module. Step 4: VPN Route Management module receives VRN routes of all on- line CE and calculate routes for each VRF according to the VRF RT value. Step 5: In the controller the enterprise users can configure specific policy for each CE or PE to control the route distribution, such as the removal of specific routing prefixes. Step 6: VPN Controller advertises the VRF routes to the corresponding PE. Step 7: PE receives and installs the VRF routes. Then the PE sends routes to CE. 5.6. VPN Tunnel Establishment If the enterprise user does not define the bandwidth and other constraints between CEs, the tunnel for the VPN can use LDP or GRE, VXLAN and other types of tunnels. If the enterprise users define the Li, et al. Expires April 30, 2015 [Page 10] Internet-Draft An Architecture of Instant VPN October 2014 bandwidth or other constraints between CEs, MPLS TE tunnel can be used. Based on VRF RT information of PEs, VPN controller determine the tunnels which should be set up among these PEs of the VPN. When a new CE is online, VPN Controller will send the PE lists to a specific PE. The PE lists determines the tunnels which the specific PE need to set up to these PEs. In addition, the tunnel type can also be advertised to the PE. If MPLS TE tunnel is used, the MPLS TE constraint for the tunnel can also be advertised. When the PE received the PE list, it should establish the tunnel with the other PE members specified by the PE list. 6. Protocol Extension Requirements 6.1. Authentication Between CE and PE Needs to be extended as follows: 1. The authentication request message need carry CE ID, CE password information. 2. The authentication response message need carry the route protocol between CE and PE, the IP address and mask of CE, if route protocol is BGP, also need carry the IP address PE, the CE AS number and the PE AS number. 6.2. Authentication Between PE and VPN Controller Needs to be extended as follows: 1. The authentication request message need carry CE ID, CE password information and physical PE ID and access interface information. 2. The authentication response message need carry the route protocol between CE and PE, the IP address and mask of CE, the IP address and mask of PE, if route protocol is BGP, also need carry the CE AS number and the PE AS number. 6.3. Configuration Distributed from VPN Controller to PE Needs to be extended as follows: 1. VRF configuration, including VRF name, VRF RD, VRF RT. 2. The route protocol configuration, including protocol process number, route policy etc. Li, et al. Expires April 30, 2015 [Page 11] Internet-Draft An Architecture of Instant VPN October 2014 6.4. Tunnel Information Distributed from VPN Controller to PE Needs to be extended as follows: 1. PE members list information which VRF accessed to. 2. The tunnel type, tunnel constraint information if MPLS TE is used. 7. IANA Considerations This document makes no request of IANA. 8. Security Considerations In this solution, the main need to consider the security between CE and PE communication, PE and VPN Controller, in the existing protocol already has good mechanism, this paper does not introduce in detail. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007. Li, et al. Expires April 30, 2015 [Page 12] Internet-Draft An Architecture of Instant VPN October 2014 Authors' Addresses Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Yuanbin Yin Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: yinyuanbin@huawei.com Li Zhang Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: monica.zhangli@huawei.com Li, et al. Expires April 30, 2015 [Page 13]