Network Working Group L. Yong Internet-Draft L. Dunbar Intended status: BCP Huawei T. Herbert Facebook Expires: April 2017 October 31, 2016 Interconnecting Network Sites by IP Tunnels draft-yong-intarea-inter-sites-over-tunnels-00.txt Abstract This document specifies use of a set of IP tunnels to interconnect multiple network sites over IP backbone networks. The interconnected network sites form 'virtual' private network(s). The networks at any of those sites can be Layer 2 domains or/and Layer 3 subnets. The IP backbone networks that the tunnels traverse through can be IPv4 or IPv6. This document describes the special property (or features) that those IP tunnels need to have in order to interconnect multiple sites as if those sites are directly connected by wires. Status of This Document 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 31, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. Yong, et al. [Page 1] Internet-Draft Sites Interconnection by Tunnels October 2016 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 1.1. Motivation of sites interconnection by IP tunnels.........3 2. Terminology....................................................4 2.1. Requirements language.....................................4 2.2. Terms defined in this document............................5 3. Sites interconnection solution architecture....................5 4. Key properties of sites interconnection over IP tunnels........7 4.1. Network sites interconnection properties..................7 4.2. Tunnel transport properties for sites interconnection.....8 5. Site traffic encapsulation.....................................9 6. Tunneling multicast and broadcast traffic......................9 7. Tunnel transport over IP.......................................9 7.1. Tunnel transport mode.....................................9 7.2. MTU and fragmentation....................................10 7.3. Checksum.................................................10 7.4. Congestion management....................................10 7.4.1. Congestion detection................................10 7.4.2. Congestion notification.............................10 7.4.3. Tunnel ingress traffic control......................10 7.5. Tunnel traffic hop count and DSCP value setting..........10 7.6. Middle box considerations................................10 8. Sites interconnection security................................10 9. Tunnel configuration..........................................11 10. Tunnel tools.................................................11 11. Operational considerations...................................11 12. IANA considerations..........................................11 13. Security considerations......................................11 14. References...................................................11 14.1. Normative References....................................11 14.2. Informative Reference...................................11 15. Authors' Addresses...........................................12 Yong, et al. [Page 2] Internet-Draft Sites Interconnection by Tunnels October 2016 1. Introduction This document specifies use of a set of IP tunnels to interconnect multiple network sites over IP backbone networks. The networks at any of those sites can be Layer 2 domains or Layer 3 subnets; IP backbone networks that tunnels traverse can be IPv4 or IPv6. This document describes the properties (or features) that IP tunnels need to have in order to interconnect multiple sites as if those sites are directly connected by wires. An IP tunnel in this document is identified by a pair of IP addresses (IPv4 or IPv6) that IP backbone networks can reach or the IP addresses plus a pair of UDP ports; one address per each tunnel endpoint. Tunnel ingress receives network traffic from its site (or access ports) and will encapsulate the traffic with an outer header whose destination and source address are the tunnel's two end points respectively. Tunnel egress receives IP packets from the backbone network, decapsulates the IP packets, and forwards decapsulated traffic toward its site (or an access port). Section 1.1 describes the motivation of this specification. Section 3 describes the solution architecture for sites interconnection by IP tunnels. Section 4 specifies the sites interconnection requirements for the IP tunnels. The rest of Sections describe Site Interconnection Tunnel (SITE) solution. Section 11 describes operational considerations for sites interconnection over IP tunnels. Note: The site interconnection policy configuration and the prefix routing within a site and across sites are outside the scope of this document. 1.1. Motivation of sites interconnection by IP tunnels Tunneling technology has being widely used in IP networks. For examples: transporting packets in one address family (e.g. IPv6) over a network of different address family (e.g. IPv4) [RFC7059]; establishing a direct logical "link" for traffic engineering; traffic security over the Internet (e.g. IPsec tunnel [RFC5996] [RFC3884]); or Location and Identifier Separation application (LISP) [RFC6830]. Provider based L2VPN and L3VPN solutions [RFC4762] [RFC4364] use MPLS LSP tunnel technology to interconnect provider edge devices, i.e., Provider Edge (PE). In these solutions, PEs are part of provider backbone networks that implement the VPN solutions. For a customer to get a provider based VPN service, each customer site Yong, et al. [Page 3] Internet-Draft Sites Interconnection by Tunnels October 2016 must attach to at least one of the PEs in the provider backbone networks, this attachment is called attachment circuit (AC) [RFC4664] [RFC4364]. Today, a company can use IPSec tunnels [RFC5996][RFC3884] to interconnect its IP subnets at different sites over the Internet if the company has an experienced operator to configure its site networks and the devices that support the IPsec tunnel capability. To achieve this, each site needs to have at least one device attaching to an IP backbone network and have at least one public IP address that the IP backbone networks can reach to. As a result, the interconnected sites form one "virtual" private network among the sites. In this case, an ISP provider (i.e. IP backbone provider) does not provide the sites interconnection service to the company although it carries the IPsec tunnel traffic; in other words, the ISP provider only provides Internet access service to each site. As a result, there is no guaranteed QoS between a pair of sites, which is the difference from provider based VPN solutions. Sites interconnection by IP tunnels is attractive to some companies that operate at multiple locations. Some companies wish to do it but do not have such an experienced operator to construct/configure site networks and tunnels to achieve this. A vendor may make a product to achieve this and sell to these companies. The product includes a site gateway device or component (called S-GW in this document) and software to allow a customer to specify their site interconnection requirements including sites interconnection policies. The software will manage the configuration of the S-GWs at multiple locations; furthermore the software can automate the processes from client specifying the sites interconnection to the sites interconnection completion. Section 3 highlights this solution architecture. A SP provider may use this product and integrate it with its provider based VPN solution [RFC4364][RFC4762][RFC7432] to provide agile VPN services to its customers. [Dunbar] 2. Terminology 2.1. Requirements language 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 [RFC2119]. Yong, et al. [Page 4] Internet-Draft Sites Interconnection by Tunnels October 2016 2.2. Terms defined in this document Site: A place that contains switches, routers, services, appliances and these devices are configured to form L2 domain (s) or L3 domain. For examples, an Enterprise company data center, a college campus network center. SITE: Site Interconnection Tunnel Protocol Solution More coming 3. Sites interconnection solution architecture .-.-.-.-.-,-.-,-.-.-,-. / Site Operator \ { | } . +-----V----+ . ( |Inter-con | ) { | Portal | } . +----------+ . % | * $ +---------+ $ # | Site | # ! |Inter-con| ! % | App | % $ +----+----+ & ! / \ ! ! / \ SIC-Ch ! ,.............., !+------+ +---------+! ,............, . . / \ . . . +-/--+ IP tunnel +--\-+ . . Site A |Site+====================+Site| Site B . . network |GW | |GW | network . . +----+\ IP Backbone +----+ . . . $ \ $ . . ,.............., ! \ ! ,............, ( V Web Traffic ) ' . $,-,-,-,-,-,-,-,-,-,-,-$ Figure 1 : Sites Interconnection Solution Architecture View Figure 1 illustrates the solution architecture of sites interconnection. The architecture contains the following components: Yong, et al. [Page 5] Internet-Draft Sites Interconnection by Tunnels October 2016 o Site Gateway (S-GW): A router and/or switch device/component. It can be configured to perform routing/forwarding function at the site. S-GW attaches to an IP backbone network and support a tunnel capability specified in this document. S-GW can be configured with one IP address to be used as tunnel end point for all tunnels to other sites or be configured with one IP address per a tunnel to a remote site. o Sites Interconnection Controller (SIC): A software component that controls/manages individual S-GWs via a SIC channel. It receives a sites interconnection request from the SIP; processes it, and sends the configuration data to individual S-GWs via SIC channel. o Sites Interconnection Portal: A software with GUI interface to allow site operator to specify its sites interconnection requirement including sites interconnection policy. The same portal can be used for the site operator to specify the site Internet access policies. o SIC Channel: a communication channel between S-GW and SIC over IP network. It could be a TCP application with security capability. The channel is used for SIC to send S-GW configuration data and get the PM data from S-GW. It may be used for dynamic routing purpose among the sites; in this case, SIC gets the prefix information from the S-GW at a site, and send the information to the S-GWs at other sites where the S-GW will distribute the information to the site. o IP tunnel: A tunnel exists between a pair of S-GWs. The tunnel end point as an interface on a S-GW receives network traffic and encapsulate the traffic with an outer header whose Destination and Source address are the tunnel's two end points respectively. Tunnel egress receives IP packets from the IP backbone network, decapsulates the IP packets, and forwards decapsulated packets toward its site (or one access port(s)). IP tunnel is unidirectional, two sites interconnection requires two tunnels, one for each direction. Two tunnels may traverse different paths in backbone network. In this architecture, each site uses its S-GW to attach to IP backbone network, which implies that the site traffic may go to the Internet via the S-GW. For security and performance reason, it is RECOMMENDED to use different public IP addresses for the Internet access and the tunnel end point of sites interconnection. It is possible to use more than one S-GW at a site for sites interconnection. Yong, et al. [Page 6] Internet-Draft Sites Interconnection by Tunnels October 2016 In this architecture, a site may have L2 domains, L3 subnets, or TRILL networks. However, the interconnected site networks MUST have the same type (see Section 3.1). Note: This document will not specify the whole solution for this architecture. It only specifies the tunnel end point functions at a S-GW and tunnel end point configuration at the S-GW. Other functions in this solution architecture will be addressed in other documents. 4. Key properties of sites interconnection over IP tunnels This section only lists the requirements for sites interconnection over IP tunnels. The entire solution architecture requirements are beyond the scope of this document. 4.1. Network sites interconnection properties 1. A site in this context may have a single network or multiple networks. For single network case, the network may be an L2 domain, L3 subnets, or a TRILL network. For the case of multiple networks, each network may be an L2 domain or L3 subnets and individual network traffic is segregated within the site including on the S-GW. Sites interconnection MUST NOT interconnect the networks at two sites that have different type. For example, one is L3 subnet, another is L2 domain. In the case of multiple networks at a site, sites interconnection MUST support individual networks at the site to be connected to the same type of networks that reside in either a remote site or different remote sites. 2. The S-GW MUST support site Internet access. The traffic to the Internet and the traffic to a remote site SHOULD be segregated by different S-GW physical ports or different IP addresses to avoid DDoS attack [RFC4732]. 3. Tunnels for sites interconnection MUST secure site traffic over the IP backbone network. 4. Tunnels for sites interconnection MUST segregate the site traffic from different networks. 5. Sites interconnection topology may be mesh or hub-spoke. Yong, et al. [Page 7] Internet-Draft Sites Interconnection by Tunnels October 2016 6. Tunnel for sites interconnection MUST be able to detect congestion on the path of IP backbone network and MUST stop some site traffic based on the operator specified policy. (stop some traffic on both directions or congestion direction?). Early dropping traffic will help site applications to take an action. S-GW MUST reports the congestion status to site interconnection app (SIA). 7. A site can be configured with two S-GWs for redundant and/or transport capacity. The remote S-GW MUST be able to support load balance tunnel traffic. A S-GW at a site MUST NOT forward incoming traffic from IP backbone to another S-GW at the site, which creates the loop. 8. Site network traffic may be unicast, mcast, or bcast(L2) traffic. Sites interconnection solution MUST be able to carry unicast, mcast, bcast traffic over tunnels. 9. Site network traffic may be control plane packets such as IBGP (ISIS?) or control packets such as ICMP, ARP. Tunnel SHOULD be able to carry control plane or control packets according to operator specified site interconnection policy. In default, a tunnel MUST NOT carry control plane packets over the tunnel. 10.Other? 4.2. Tunnel transport properties for sites interconnection This section lists tunnel transport requirements over IP backbone networks for sites interconnection application. 1. Tunnel type (tunnel mode, or transport mode, or both) 2. IP backbone network can be IPv4 or IPv6 network. A tunnel MUST be able to run over an IPv4 or IPv6 network. 3. Tunnel solution MUST meet IP [RFC791] [RFC2460] and UDP application requirements [RFC5405bis] 4. Tunnel MTU and Fragmentation [JOE]. Tunnel SHOULD avoid tunnel traffic to be fragmented on IP backbone networks. 5. Tunnel solution supports configuration option to turn off traffic encryption function. Yong, et al. [Page 8] Internet-Draft Sites Interconnection by Tunnels October 2016 6. Tunnel solution supports congestion control upon detecting congestion condition on the tunnel path (use circuit breaker, packet drop/report at ingress, notification to source). 7. Tunnel solution MUST map site traffic QoS to proper DSCP value on tunnel IP packets based on operation specified policy. 8. Tunnel solution SHOULD be able to monitor the inter-sites connectivity and report the status. 9. Tunnel solution SHOULD support some tools for sites interconnection operator such as tunnel path trace, ping, tunnel's throughput test, etc. 10.ICMP handling (from Internet or from remote tunnel end-point). 11.Others, Hop count for tunnel traffic, middle box considerations, etc. 5. Site traffic encapsulation GRE-in-UDP w/DTLS [GRE-in-UDP] or GUE [GUE]: the reason is: o It can run over the Internet (Ipv4 and Ipv6) o It runs as UDP application, ECMP advantage, and middle box traversal benefit. o Encapsulate different types of traffic o Ability to support fragmentation o Security/encryption capability o Support traffic segregation Like to hear other's opinions on encapsulation protocol choices. 6. Tunneling multicast and broadcast traffic 7. Tunnel transport over IP 7.1. Tunnel transport mode Tunnel mode or transport mode or both.[RFC3884] Yong, et al. [Page 9] Internet-Draft Sites Interconnection by Tunnels October 2016 7.2. MTU and fragmentation Intarea-tunnels draft or GUE-extension draft 7.3. Checksum Tunnel solution MUST implement the checksum specification for default GRE-in-UDP tunnel in [GRE-in-UDP]. 7.4. Congestion management More than likely, a site operator has no way to control transport path resource in IP backbone networks for sites interconnection. Tunnel packets are treated as regular IP packets and traverse a path in IP backbone networks that other IP application packets traverse as well. Congestion may happen due to "ship-in-night" situation. IP backbone network uses explicitly congestion notification (ECN) [RFC6040] to indicate IP applications about the network congestion. Upon backbone path congestion, a tunnel for the site interconnection MUST stop some traffic based on operator's interconnection policy. This section specifies the tunnel congestion control mechanism. 7.4.1. Congestion detection 7.4.2. Congestion notification 7.4.3. Tunnel ingress traffic control 7.5. Tunnel traffic hop count and DSCP value setting 7.6. Middle box considerations 8. Sites interconnection security For site traffic security, tunnel MUST use DTLS to encrypt site traffic, i.e., use GRE-in-UDP w/ DTLS. This feature MAY be turned off by a site operator if the site network traffic is already encrypted. A site operator SHOULD request a security service from IP backbone provider to prevent DDoS traffic to reach the tunnel end point at a S-GW of the sites. Yong, et al. [Page 10] Internet-Draft Sites Interconnection by Tunnels October 2016 9. Tunnel configuration 10. Tunnel tools 11. Operational considerations 12. IANA considerations 13. Security considerations 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC2119, March 1997. [RFC791] DARPA, "INTERNET PROTOCOL", RFC791, September, 1981. [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC792, September 1981. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC5405bis] Eggert, L., "Unicast UDP Usage Guideline for Application Designers", draft-ietf-tsvwg-rfc5405bis, work in progress. [RFC6040] Briscoe, B., "Tunneling of Explicit Congestion Notification", RFC6040, November 2010. [GRE-in-UDP] Yong, L., et al, "GRE-in-UDP Encapsulation", draft- ietf-tsvwg-gre-in-udp-encap-19, work in progress. [JOE] Touch, J. and Townsley, M., "IP Tunnels in the Internet Architecture", draft-ietf-intarea-tunnels-03, work in progress. 14.2. Informative Reference [RFC3884] Touch, J., Eggert, L., and Wang, Y., "Use of Ipsec Transport Mode for Dynamic Routing", September 2004. Yong, et al. [Page 11] Internet-Draft Sites Interconnection by Tunnels October 2016 [RFC4364] Rosen, E. and Rekhter, Y., "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC4364, February 2006. [RFC4664] Andersson, L. and Rosen, E., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC4664, September 2006. [RFC4732] Handley, M. and Rescorla, E., "Internet Denial-of-Service Considerations" RFC4732, November 2006. [RFC4762] Lasserre, M. and Kompella, V.,"Virtual Private LAN Service (VPLS) using Label Distribution Protocol (LDP) Signaling", RFC4762, January 2007. [RFC5996] Kaufman, C., et al, "Internet Key Exchange Protocol Version 2 (IKEv2)", September 2010. [RFC6830] Farinacci, D., et al, "The Locator/IP Separation Protocol (LISP)", RFC6830, January 2013. [RFC7059] Steffann, S., et al, "A comparison of IPv6-over-IPv4 Tunnel Mechanism", RFC7059, November 2013 [RFC7432] Sajassi, A., et al, "BGP MPLS-Based Ethernet VPN", RFC7432, February 2015. [Dunbar] Dunbar, L., Yong, L., Song, X., "Client Defined Private Networks laid over Thin CEPs", draft-dunbar-interarea- private-networks-over-thinCPE, work in progress. [GUE] Herbert, T., Yong, L., Zia, O, "Generic UPD Encapsulation", draft-ietf-nvo3-gue-05, work in progress. 15. Authors' Addresses Lucy Yong Huawei Technologies Email: lucy.yong@huawei.com Linda Dunbar Huawei Technologies Email: linda.dunbar@huawei.com Tom Herbert Yong, et al. [Page 12] Internet-Draft Sites Interconnection by Tunnels October 2016 Facebook Emails: tom@herbertland.com Yong, et al. [Page 13]