Network Working Group T. Henderson Internet-Draft University of Washington Intended status: Experimental S. Venema Expires: August 3, 2016 Polyverse Security D. Mattes Tempered Networks January 31, 2016 HIP-based Virtual Private LAN Service (HIPLS) draft-henderson-hip-vpls-10 Abstract The Host Identity Protocol (HIP) and architecture adds a cryptographic name space to name Internet hosts. This draft describes a use case of the HIP architecture, which is to provide a HIP-enabled virtual private LAN service (VPLS) over an untrusted network. In this case, HIP is used to secure tunnels between the provider edge (PE) equipment. 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 August 3, 2016. Copyright Notice Copyright (c) 2016 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 Henderson, et al. Expires August 3, 2016 [Page 1] Internet-Draft HIPLS January 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Reference model . . . . . . . . . . . . . . . . . . . . . . . 3 4. Service description . . . . . . . . . . . . . . . . . . . . . 6 5. System description . . . . . . . . . . . . . . . . . . . . . 7 5.1. Provisioning the PEs . . . . . . . . . . . . . . . . . . 7 5.2. Walkthrough of unicast protocol operation . . . . . . . . 7 5.3. Names and access control lists . . . . . . . . . . . . . 8 5.4. Walkthrough of multicast operation . . . . . . . . . . . 9 5.5. Mobility, multihoming, and address families . . . . . . . 9 6. Proposed extensions to HIP . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Virtual private networks (VPNs) are popular in the wide-area Internet and also among enterprises that wish to separate multiple LAN broadcast domains across shared network infrastructure. Several techniques have been defined to provide VPNs at different layers in the stack, including layer-1 [RFC4847], layer-2 (virtual LAN, virtual private LAN service (VPLS), and pseudo-wire (PW)) [RFC4664], and layer-3 (virtual router and BGP/MPLS provider-provisioned VPNs) [RFC4176]. The Host Identity Protocol (HIP) [RFC7401] and architecture [RFC4423] adds a new public-key-based name space for use as host identifiers in Internet protocols. HIP specifies a means for hosts to use public keys to authenticate one another over Internet protocols and to set up secure data channels using Encapsulating Security Payload [RFC7402] and possibly other transports in the future. This document describes how HIP can be used to create a customer Virtual Private LAN Service (VPLS) overlaid on top of a standard IPv4 and/or IPv6 provider network. Using the nomenclature in RFC 4664 [RFC4664], a VPLS connects several physically separate LAN segments Henderson, et al. Expires August 3, 2016 [Page 2] Internet-Draft HIPLS January 2016 into a single logical LAN segment. The Provider Edge (PE) devices that connect the Customer Edge (CE) devices behave like a learning bridge, and the CE devices may be any layer-2 or layer-3 device, including hosts, routers, bridges, or switches. In the specific use case described, the tunnels between PEs are realized by Encapsulating Security Payload (ESP) tunnels, whose management is controlled by the Host Identity Protocol (HIP) signaling protocol. Each PE device is assigned a cryptographic host identifier, which may be bound to other identifiers in the system via certificates or other means. The HIP signaling protocol is used to allow PE devices to authenticate one another and to build secure tunnels over untrusted provider network infrastructure. Extensions to HIP are described to allow the PE devices to integrate with a public-key infrastructure, in order to ease deployment. Readers may note that this application of HIP differs from the traditional implementation of HIP within end hosts. The key differences are that HIP is here implemented within a middlebox (using the terminology of RFC 4301 [RFC4301], a "bump-in-the-wire" implementation) and that the payloads of the ESP-encrypted datagrams are not transport protocol data units (PDUs) but instead are layer-2 frames. 2. Terminology Terminology is reused from [RFC4664] and and [RFC7401]. 3. Reference model Section 2.2 of RFC 4664 [RFC4664] specifies the VPLS reference model where PE devices that are VPLS-capable provide a logical interconnect such that CE devices belonging to a specific VPLS appear to be on a single bridged Ethernet. A VPLS can contain a single VLAN or multiple tagged VLANs. Henderson, et al. Expires August 3, 2016 [Page 3] Internet-Draft HIPLS January 2016 +-----+ +-----+ + CE1 +--+ +---| CE2 | +-----+ | ................... | +-----+ VPLS A | +----+ +----+ | VPLS A | |VPLS| |VPLS| | +--| PE |--Routed---| PE |-+ +----+ Backbone +----+ / . | . \ _ /\_ +-----+ / . | . \ / \ / \ +-----+ + CE +--+ . | . +--\ Access \----| CE | +-----+ . +----+ . | Network | +-----+ VPLS B .....|VPLS|........ \ / VPLS B | PE | ^ ------- +----+ | | | | | +-----+ | | CE3 | +-- Emulated LAN +-----+ VPLS A Figure 1: Reference model Figure 1, copied from Figure 2 of [RFC4664], depicts the reference model for this use case. A number of CE devices are connected to PE devices over layer-2 networks. Although not shown in the figure, each CE device may be reachable by one or more PE device (for example, CE1 and CE3 may also be able to reach each other directly without using the VPLS). Moreover, the connectivity of the L2 networks (and correspondingly, between a given PE and CE) may change over time. No assumptions are made about the capabilities of the CE devices. From the perspective of the CE devices, each other CE device is reachable, using broadcast, multicast, or unicast, as if it were on the same LAN segment. Therefore, the service provided by the PE devices is that of a L2VPN. Since this is a L2VPN, CE devices are free to use higher layer protocols such as IPv4 and IPv6 and domain specific protocols such as those found in industrial control systems. Henderson, et al. Expires August 3, 2016 [Page 4] Internet-Draft HIPLS January 2016 |-----Routed Backbone-----| | (P Routers) |PSN Tunnels, Emulated LAN | |Pseudowires ....................................................................... . | | . . |---------------------|----| |--------|-----------------| . . | --------------------|--- | | -------|---------------- | . . | VPLS Forwarder | | VPLS Forwarder | . . | ----------|------------- | | ----------|------------- | . ..|.................................................................|.. | | Emulated LAN | | | Emulated LAN | | | Interface | VPLS-PEs | | Interface | | | | <----> | | | | ----------|------------ | | ----------|------------ | | | Bridge | | | | Bridge | | | -|--------|---------|-- | | ---|-------|---------|- | |--|--------|---------|----| |----|-------|---------|---| | | | | | | | | Access | | | Access | | | Networks| | | Networks| | | | | | | | | | | | | CE devices CE devices Figure 2: PE Reference model Figure 2, copied from Figure 3 of RFC4664, depicts the design model for the PE. In this model, a CE device attaches, possibly through an access network, to a "bridge" module of a VPLS-PE. Within the VPLS- PE, the bridge module attaches, through an "Emulated LAN Interface", to an Emulated LAN. For each VPLS, there is an Emulated LAN instance. Figure 3 shows some internal structure to the Emulated LAN: it consists of "VPLS Forwarder" modules connected by pseudowires, where the pseudowires may be traveling through PSN tunnels over a routed backbone. A "VPLS instance" consists of a set of VPLS Forwarders (no more than one per PE) connected by pseudowires. In our application, it is the HIP-enabled ESP tunnels that constitute the pseudowires. The PE devices are interconnected by an IP-based network. This network may be IPv4-based or IPv6-based, or a hybrid. The PEs are responsible for providing a secure (encrypted, authenticated) tunnel over which Layer-2 frames may flow betweeen CEs that are interconnected by the VPN. The PE devices are also responsible for authenticating the peer PE devices as belonging to the same overlay Henderson, et al. Expires August 3, 2016 [Page 5] Internet-Draft HIPLS January 2016 (L2VPN). Furthermore, PE devices may be responsible for maintaining access control lists (ACLs) that govern which CEs are permitted to talk to which other CEs. In addition to IP and MAC addresses found in ACLs, the ACLs may also use the cryptographic identities already bound to the PE devices for use by the HIP protocol. To build tunnels, the PEs must use pre-provisioned configuration information or must consult, on-demand, a mapping database (such as DNS or an LDAP server) to find the bindings between PE and CE device. These bindings may be secured by a public key infrastructure (PKI). PEs may change their point of attachment (and also, their IP address) to the IP-based network, and may be multihomed to the IP-based network (see PE3 in the above figure), and the PE devices must accommodate such changes such that they are transparent to the L2VPN overlay and the CEs. In this model, the PE devices use HIP as follows. Each PE device is assigned (provisioned with) a unique name, such as a serial number or asset tag, and with a public/private key pair. This unique name may be bound to the public key using an X.509 certificate. The L2VPN is also given a name. Each PE device knows which of its interfaces belong to a particular named overlay, and which of its interfaces belong to the underlay (the "routed backbone" in Figure 2). Each PE device knows or learns which CE devices it is fronting for, and how to obtain mapping information that maps a remote CE to a remote PE device. The tunnels established between PE devices are HIP-enabled ESP tunnels. HIP signaling between PE devices is used to establish and maintain the tunnels. A certificate, signed by a trust anchor in the system, binds the PE name to the PE's public key; this public key is used as the host identity in the HIP exchanges. The HIP exchanges carry a PE's certificate, thereby allowing a remote PE to authenticate the PE as a member of the overlay. HIP signaling may also be used between the PE devices and the mapping database, or this communications channel may be secured by other means. 4. Service description RFC 4665 [RFC4665] describes service requirements for L2VPNs, and outlines a number of options for variations on the L2VPN design. In this section, we describe the HIPLS service in terms of the RFC 4665 taxonomy. With respect to Section 5 of RFC 4665, we are describing a full VPLS solution; any variations or caveats should be documented according to Section 5.1 of RFC 4665. For example, a VPLS must support unicast, Henderson, et al. Expires August 3, 2016 [Page 6] Internet-Draft HIPLS January 2016 multicast, and broadcast traffic, even if realized with ESP unicast- based tunnels. 5. System description In this section, we walk through how the HIP-enabled VPLS can be provisioned and how it operates in a few use case scenarios. In the following, we refer to each L2VPN as an overlay network, and to the routed backbone as the underlay. 5.1. Provisioning the PEs At a minimum, a network operator must define a unique overlay name, and must authorize (or list) the PEs that belong to that overlay. In particular, the interfaces (overlay and underlay) that belong to the system must be identified for each PE. Additionally, each PE must possess a public/private key pair, which must be accessible to a host via a smart card, Trusted Platform Module (TPM) hardware, or a local file. The PEs must be able to authenticate the other PEs in the underlay as belonging to a given overlay. One way to do this is to pre-provision a list of PEs (and their HITs) that belong to the overlay, and deploy this list on each PE in a static configuration file. A drawback to this approach is that whenever the set of PEs on the overlay changes, each PE's master list must be edited. An alternative is to deploy an authorization system in which a PE's key is authorized by a server as belonging to that overlay. In addition, there are a number of other configuration items that may either be pre-provisioned or dynamically learned. These include access control lists, associations between PE devices and local CEs, and associations between remote PE devices and remote CEs. All of this type of information may either be pre-provisioned in static configuration files, or stored in a database accessible on the underlay. 5.2. Walkthrough of unicast protocol operation Referring again to Figure 1, consider the case in which CE1 wishes to send an IPv4 unicast datagram to CE3, and no corresponding session state exists between the respective PEs. We assume that CE1 and CE3 both share a network prefix, and that CE1 first sends an ARP request or Neighbor Discovery on its local LAN segment. This request is picked up by PE1 which listens promiscuously on its LAN segment. No other devices respond to this request. Henderson, et al. Expires August 3, 2016 [Page 7] Internet-Draft HIPLS January 2016 PE1 learns that it is the responsible PE device for the source MAC address of the ARP request, and stores this forwarding entry in its forwarding database (address learning). Note that some implementations may populate the forwarding database manually. Manual configuration is required for CE devices that never send an L2 frame ("listen only" devices) or that only send L2 frames when they have received instructions to do so. Since the ARP message is a broadcast layer-2 frame, the PE device must either perform a proxy- ARP function or must send the ARP request to all other PEs on the overlay. Therefore, a means whereby each PE knows all of the other PEs in the overlay is required, either by static configuration or by dynamic discovery. Next, the PE device must forward the ARP request to all peer PEs servicing a particular overlay, or to a specific peer PE if the MAC- to-PE mapping is already known (either by static configuration or earlier dynamic discovery). Since the PEs communicate with each other via HIP, the PE forwarding the ARP must build a HIP tunnel to each target PE if it does not already exist. The source PE wraps the L2 frame within the ESP payload, fragments it if necessary, and sends to the remote PEs where it is detunneled and placed on the remote access network segment again as a L2 broadcast frame. From this point, the intended host will ARP reply with a unicast frame. This frame should be mapped to the ESP association back to the originating PE. Note that flooding of broadcast datagrams in an L2 network is prone to loops. There may be other transparent bridges present in the access network. Therefore, the PE devices must implement and participate in an 802.1d spanning tree algorithm. Note that the nature of 802.1d and the number of broadcast frames typical in most networks will require the setup and maintenance of a full mesh of ESP associations between PEs on an overlay, in general. 5.3. Names and access control lists The name by which the PE devices know one another, at the protocol level, is the HIT, which is a hash of the host identity public key. This key can be used to authenticate messages from PE devices purporting to be a named PE device. However, from a management perspective, the names that operators will want to use in configuration files and in access control lists should be more operationally relevant, such as human- friendly strings and asset tags. Certificates are used to bind a PE device's operational name to its HIT. The HIT is obtained as usual, as a hash of the PE device's public key. All PE devices in the overlay must share a common set of CAs. Henderson, et al. Expires August 3, 2016 [Page 8] Internet-Draft HIPLS January 2016 Certificates should be presented as parameters in the base exchange, to allow peer PE devices to validate them. 5.4. Walkthrough of multicast operation Multicast operation is similer to that described in the section on handling of broadcast ARP requests. 5.5. Mobility, multihoming, and address families The PE devices may be mobile or multihomed on the underlay. The HIP mobility mechanisms [RFC5206] may be used in this case to preserve existing security associations and to update database records upon such changes to the underlying IP addresses. The underlay may itself be a combination of IPv4 and IPv6 network segments. A given overlay may be supported by either or both IPv4 and IPv6-based ESP security associations. The CE devices may be multihomed to PE devices. In this case, the PEs must coordinate to ensure that only one PE sources ingress frames destined from CE4 to another CE. The PE devices may have "backdoor" connections with one another. The 802.1d spanning tree protocol should alleviate problems of this sort. 6. Proposed extensions to HIP The system described above relies on the ability of the PE devices to exchange certificates in the R1, I2, and UPDATE messages, based on local policy. Note that passing of certificates in the HIP exchanges is not strictly necessary, but it will reduce latency if the host proactively provides its certificate as part of the signaling exchange. Work is already underway in the HIP working group to define such a certificate (CERT) parameter [RFC6253]. The system described above can be thought of as a "bump-in-the-wire" type of HIP deployment. Conceptually, what is being encapsulated is not a transport PDU but instead a layer-2 frame. Therefore, HIP implementations in the PE devices need to be able to successfully encapsulate and decapsulate such frames; i.e., this system alters the protocol processing in the stack compared to a host-based HIP implementation. An additional change is that layer-2 (and, by extension, layer-3) multicast and broadcast frames, as well as layer-2 control frames such as bridge PDUs, must be passed as needed. This requires a capability for the PEs to send a copy of each such frame to all other PEs in the overlay. One technique to do this is to replicate each Henderson, et al. Expires August 3, 2016 [Page 9] Internet-Draft HIPLS January 2016 frame and send to each other PE in the system. To support such a transmission framework, N*(N-1) tunnels must be maintained collectively between the PE devices. Alternatively, a constrained system may be deployed that does not support multicast or broadcast, nor bridge PDUs; this would be more like a unicast-only IPLS VPN. If temporary certificates are used, it has not yet been defined in HIP how a host identity may change for active security associations. 7. Security Considerations The model considered above assumes that PE devices that hold trusted credentials (certificates and private keys) are trustworthy; a malicious or misconfigured PE device could subvert packet delivery across the overlay. The model also assumes that the information that PE devices need to obtain to bind the PE name to the overlay and to its respective public key is not compromised, and that the keys of the PE devices are themselves not compromised. A PKI revocation system may aid in dealing with compromised keys. Otherwise, the system described above inherits the security properties found in HIP, including strong authentication of the binding between host identity and (underlay) IP address, and some level of robustness from denial-of-service attacks on the underlay network, based on the properties of the HIP base exchange. Section 5.5 of RFC 4665 describes security features from the perspective of the L2VPN solution, while Section 6.5 of RFC 4665 describes the security from a user perspective. The HIPLS solution must protect against the attacks listed in Section 5.5 of RFC 4665. 8. IANA Considerations There are no IANA considerations. 9. Acknowledgments Jeff Ahrenholz, Orlie Brewer, Eric Byres, Jin Fang, Darren Lissimore and Jeff Meegan have provided invaluable support in the design and prototype implementation of this HIPLS functionality. Richard Paine and Craig Dupler were instrumental in guiding early work along these lines. Members of other Standards organizations such as The Open Group, the Trusted Computing Group (TCG), and the International Society of Automation (ISA) have been involved in standards development activities that leverage HIP and this HIPLS functionality. Henderson, et al. Expires August 3, 2016 [Page 10] Internet-Draft HIPLS January 2016 10. References 10.1. Normative References [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006. [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008. [RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol Certificates", RFC 6253, May 2011. [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, . [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 7402, DOI 10.17487/RFC7402, April 2015, . 10.2. Informative References [RFC4176] El Mghazli, Y., Nadeau, T., Boucadair, M., Chan, K., and A. Gonguet, "Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management", RFC 4176, October 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks", RFC 4665, September 2006. [RFC4847] Takeda, T., "Framework and Requirements for Layer 1 Virtual Private Networks", RFC 4847, April 2007. Henderson, et al. Expires August 3, 2016 [Page 11] Internet-Draft HIPLS January 2016 Authors' Addresses Thomas R. Henderson University of Washington Campus Box 352500 Seattle, WA USA Email: tomhend@u.washington.edu Steven C. Venema Polyverse Security 550 NW Kirkland Way Suite 210 Kirkland, WA USA Email: steve@polyverse.io David Mattes Tempered Networks 3101 Western Avenue Suite 550 Seattle, WA USA Email: d.mattes@temperednetworks.com Henderson, et al. Expires August 3, 2016 [Page 12]