idnits 2.17.1 draft-henderson-hip-vpls-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 12, 2014) is 3424 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) ** Obsolete normative reference: RFC 5202 (Obsoleted by RFC 7402) ** Obsolete normative reference: RFC 5206 (Obsoleted by RFC 8046) ** Obsolete normative reference: RFC 6253 (Obsoleted by RFC 8002) -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Henderson 3 Internet-Draft University of Washington 4 Intended status: Experimental S. Venema 5 Expires: May 16, 2015 The Boeing Company 6 D. Mattes 7 Tempered Networks 8 November 12, 2014 10 HIP-based Virtual Private LAN Service (HIPLS) 11 draft-henderson-hip-vpls-08 13 Abstract 15 The Host Identity Protocol (HIP) and architecture adds a 16 cryptographic name space to name Internet hosts. This draft 17 describes a use case of the HIP architecture, which is to provide a 18 HIP-enabled virtual private LAN service (VPLS) over an untrusted 19 network. In this case, HIP is used to secure tunnels between the 20 provider edge (PE) equipment. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 16, 2015. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Reference model . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Service description . . . . . . . . . . . . . . . . . . . . . 6 60 5. System description . . . . . . . . . . . . . . . . . . . . . 7 61 5.1. Provisioning the PEs . . . . . . . . . . . . . . . . . . 7 62 5.2. Walkthrough of unicast protocol operation . . . . . . . . 7 63 5.3. Names and access control lists . . . . . . . . . . . . . 8 64 5.4. Walkthrough of multicast operation . . . . . . . . . . . 9 65 5.5. Mobility, multihoming, and address families . . . . . . . 9 66 6. Proposed extensions to HIP . . . . . . . . . . . . . . . . . 9 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 72 10.2. Informative References . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 Virtual private networks (VPNs) are popular in the wide-area Internet 78 and also among enterprises that wish to separate multiple LAN 79 broadcast domains across shared network infrastructure. Several 80 techniques have been defined to provide VPNs at different layers in 81 the stack, including layer-1 [RFC4847], layer-2 (virtual LAN, virtual 82 private LAN service (VPLS), and pseudo-wire (PW)) [RFC4664], and 83 layer-3 (virtual router and BGP/MPLS provider-provisioned VPNs) 84 [RFC4176]. 86 The Host Identity Protocol (HIP) [RFC5201] and architecture [RFC4423] 87 adds a new public-key-based name space for use as host identifiers in 88 Internet protocols. HIP specifies a means for hosts to use public 89 keys to authenticate one another over Internet protocols and to set 90 up secure data channels using Encapsulating Security Payload 91 [RFC5202] and possibly other transports in the future. 93 This document describes how HIP can be used to create a customer 94 Virtual Private LAN Service (VPLS) overlaid on top of a standard IPv4 95 and/or IPv6 provider network. Using the nomenclature in RFC 4664 96 [RFC4664], a VPLS connects several physically separate LAN segments 97 into a single logical LAN segment. The Provider Edge (PE) devices 98 that connect the Customer Edge (CE) devices behave like a learning 99 bridge, and the CE devices may be any layer-2 or layer-3 device, 100 including hosts, routers, bridges, or switches. 102 In the specific use case described, the tunnels between PEs are 103 realized by Encapsulating Security Payload (ESP) tunnels, whose 104 management is controlled by the Host Identity Protocol (HIP) 105 signaling protocol. Each PE device is assigned a cryptographic host 106 identifier, which may be bound to other identifiers in the system via 107 certificates or other means. The HIP signaling protocol is used to 108 allow PE devices to authenticate one another and to build secure 109 tunnels over untrusted provider network infrastructure. Extensions 110 to HIP are described to allow the PE devices to integrate with a 111 public-key infrastructure, in order to ease deployment. 113 Readers may note that this application of HIP differs from the 114 traditional implementation of HIP within end hosts. The key 115 differences are that HIP is here implemented within a middlebox 116 (using the terminology of RFC 4301 [RFC4301], a "bump-in-the-wire" 117 implementation) and that the payloads of the ESP-encrypted datagrams 118 are not transport protocol data units (PDUs) but instead are layer-2 119 frames. 121 2. Terminology 123 Terminology is reused from [RFC4664] and and [RFC5201]. 125 3. Reference model 127 Section 2.2 of RFC 4664 [RFC4664] specifies the VPLS reference model 128 where PE devices that are VPLS-capable provide a logical interconnect 129 such that CE devices belonging to a specific VPLS appear to be on a 130 single bridged Ethernet. A VPLS can contain a single VLAN or 131 multiple tagged VLANs. 133 +-----+ +-----+ 134 + CE1 +--+ +---| CE2 | 135 +-----+ | ................... | +-----+ 136 VPLS A | +----+ +----+ | VPLS A 137 | |VPLS| |VPLS| | 138 +--| PE |--Routed---| PE |-+ 139 +----+ Backbone +----+ 140 / . | . \ _ /\_ 141 +-----+ / . | . \ / \ / \ +-----+ 142 + CE +--+ . | . +--\ Access \----| CE | 143 +-----+ . +----+ . | Network | +-----+ 144 VPLS B .....|VPLS|........ \ / VPLS B 145 | PE | ^ ------- 146 +----+ | 147 | | 148 | | 149 +-----+ | 150 | CE3 | +-- Emulated LAN 151 +-----+ 152 VPLS A 154 Figure 1: Reference model 156 Figure 1, copied from Figure 2 of [RFC4664], depicts the reference 157 model for this use case. A number of CE devices are connected to PE 158 devices over layer-2 networks. Although not shown in the figure, 159 each CE device may be reachable by one or more PE device (for 160 example, CE1 and CE3 may also be able to reach each other directly 161 without using the VPLS). Moreover, the connectivity of the L2 162 networks (and correspondingly, between a given PE and CE) may change 163 over time. No assumptions are made about the capabilities of the CE 164 devices. From the perspective of the CE devices, each other CE 165 device is reachable, using broadcast, multicast, or unicast, as if it 166 were on the same LAN segment. Therefore, the service provided by the 167 PE devices is that of a L2VPN. Since this is a L2VPN, CE devices are 168 free to use higher layer protocols such as IPv4 and IPv6 and domain 169 specific protocols such as those found in industrial control systems. 171 |-----Routed Backbone-----| 172 | (P Routers) |PSN Tunnels, 173 Emulated LAN | |Pseudowires 174 ....................................................................... 175 . | | . 176 . |---------------------|----| |--------|-----------------| . 177 . | --------------------|--- | | -------|---------------- | . 178 . | VPLS Forwarder | | VPLS Forwarder | . 179 . | ----------|------------- | | ----------|------------- | . 180 ..|.................................................................|.. 181 | | Emulated LAN | | | Emulated LAN | 182 | | Interface | VPLS-PEs | | Interface | 183 | | | <----> | | | 184 | ----------|------------ | | ----------|------------ | 185 | | Bridge | | | | Bridge | | 186 | -|--------|---------|-- | | ---|-------|---------|- | 187 |--|--------|---------|----| |----|-------|---------|---| 188 | | | | | | 189 | | Access | | | Access | 190 | | Networks| | | Networks| 191 | | | | | | 192 | | | | | | 193 CE devices CE devices 195 Figure 2: PE Reference model 197 Figure 2, copied from Figure 3 of RFC4664, depicts the design model 198 for the PE. In this model, a CE device attaches, possibly through an 199 access network, to a "bridge" module of a VPLS-PE. Within the VPLS- 200 PE, the bridge module attaches, through an "Emulated LAN Interface", 201 to an Emulated LAN. For each VPLS, there is an Emulated LAN 202 instance. Figure 3 shows some internal structure to the Emulated 203 LAN: it consists of "VPLS Forwarder" modules connected by 204 pseudowires, where the pseudowires may be traveling through PSN 205 tunnels over a routed backbone. 207 A "VPLS instance" consists of a set of VPLS Forwarders (no more than 208 one per PE) connected by pseudowires. In our application, it is the 209 HIP-enabled ESP tunnels that constitute the pseudowires. 211 The PE devices are interconnected by an IP-based network. This 212 network may be IPv4-based or IPv6-based, or a hybrid. The PEs are 213 responsible for providing a secure (encrypted, authenticated) tunnel 214 over which Layer-2 frames may flow betweeen CEs that are 215 interconnected by the VPN. The PE devices are also responsible for 216 authenticating the peer PE devices as belonging to the same overlay 217 (L2VPN). Furthermore, PE devices may be responsible for maintaining 218 access control lists (ACLs) that govern which CEs are permitted to 219 talk to which other CEs. In addition to IP and MAC addresses found 220 in ACLs, the ACLs may also use the cryptographic identities already 221 bound to the PE devices for use by the HIP protocol. 223 To build tunnels, the PEs must use pre-provisioned configuration 224 information or must consult, on-demand, a mapping database (such as 225 DNS or an LDAP server) to find the bindings between PE and CE device. 226 These bindings may be secured by a public key infrastructure (PKI). 227 PEs may change their point of attachment (and also, their IP address) 228 to the IP-based network, and may be multihomed to the IP-based 229 network (see PE3 in the above figure), and the PE devices must 230 accommodate such changes such that they are transparent to the L2VPN 231 overlay and the CEs. 233 In this model, the PE devices use HIP as follows. Each PE device is 234 assigned (provisioned with) a unique name, such as a serial number or 235 asset tag, and with a public/private key pair. This unique name may 236 be bound to the public key using an X.509 certificate. The L2VPN is 237 also given a name. Each PE device knows which of its interfaces 238 belong to a particular named overlay, and which of its interfaces 239 belong to the underlay (the "routed backbone" in Figure 2). Each PE 240 device knows or learns which CE devices it is fronting for, and how 241 to obtain mapping information that maps a remote CE to a remote PE 242 device. 244 The tunnels established between PE devices are HIP-enabled ESP 245 tunnels. HIP signaling between PE devices is used to establish and 246 maintain the tunnels. A certificate, signed by a trust anchor in the 247 system, binds the PE name to the PE's public key; this public key is 248 used as the host identity in the HIP exchanges. The HIP exchanges 249 carry a PE's certificate, thereby allowing a remote PE to 250 authenticate the PE as a member of the overlay. HIP signaling may 251 also be used between the PE devices and the mapping database, or this 252 communications channel may be secured by other means. 254 4. Service description 256 RFC 4665 [RFC4665] describes service requirements for L2VPNs, and 257 outlines a number of options for variations on the L2VPN design. In 258 this section, we describe the HIPLS service in terms of the RFC 4665 259 taxonomy. 261 With respect to Section 5 of RFC 4665, we are describing a full VPLS 262 solution; any variations or caveats should be documented according to 263 Section 5.1 of RFC 4665. For example, a VPLS must support unicast, 264 multicast, and broadcast traffic, even if realized with ESP unicast- 265 based tunnels. 267 5. System description 269 In this section, we walk through how the HIP-enabled VPLS can be 270 provisioned and how it operates in a few use case scenarios. 272 In the following, we refer to each L2VPN as an overlay network, and 273 to the routed backbone as the underlay. 275 5.1. Provisioning the PEs 277 At a minimum, a network operator must define a unique overlay name, 278 and must authorize (or list) the PEs that belong to that overlay. In 279 particular, the interfaces (overlay and underlay) that belong to the 280 system must be identified for each PE. Additionally, each PE must 281 possess a public/private key pair, which must be accessible to a host 282 via a smart card, Trusted Platform Module (TPM) hardware, or a local 283 file. 285 The PEs must be able to authenticate the other PEs in the underlay as 286 belonging to a given overlay. One way to do this is to pre-provision 287 a list of PEs (and their HITs) that belong to the overlay, and deploy 288 this list on each PE in a static configuration file. A drawback to 289 this approach is that whenever the set of PEs on the overlay changes, 290 each PE's master list must be edited. An alternative is to deploy an 291 authorization system in which a PE's key is authorized by a server as 292 belonging to that overlay. 294 In addition, there are a number of other configuration items that may 295 either be pre-provisioned or dynamically learned. These include 296 access control lists, associations between PE devices and local CEs, 297 and associations between remote PE devices and remote CEs. All of 298 this type of information may either be pre-provisioned in static 299 configuration files, or stored in a database accessible on the 300 underlay. 302 5.2. Walkthrough of unicast protocol operation 304 Referring again to Figure 1, consider the case in which CE1 wishes to 305 send an IPv4 unicast datagram to CE3, and no corresponding session 306 state exists between the respective PEs. We assume that CE1 and CE3 307 both share a network prefix, and that CE1 first sends an ARP request 308 or Neighbor Discovery on its local LAN segment. This request is 309 picked up by PE1 which listens promiscuously on its LAN segment. No 310 other devices respond to this request. 312 PE1 learns that it is the responsible PE device for the source MAC 313 address of the ARP request, and stores this forwarding entry in its 314 forwarding database (address learning). Note that some 315 implementations may populate the forwarding database manually. 316 Manual configuration is required for CE devices that never send an L2 317 frame ("listen only" devices) or that only send L2 frames when they 318 have received instructions to do so. Since the ARP message is a 319 broadcast layer-2 frame, the PE device must either perform a proxy- 320 ARP function or must send the ARP request to all other PEs on the 321 overlay. Therefore, a means whereby each PE knows all of the other 322 PEs in the overlay is required, either by static configuration or by 323 dynamic discovery. 325 Next, the PE device must forward the ARP request to all peer PEs 326 servicing a particular overlay, or to a specific peer PE if the MAC- 327 to-PE mapping is already known (either by static configuration or 328 earlier dynamic discovery). Since the PEs communicate with each 329 other via HIP, the PE forwarding the ARP must build a HIP tunnel to 330 each target PE if it does not already exist. The source PE wraps the 331 L2 frame within the ESP payload, fragments it if necessary, and sends 332 to the remote PEs where it is detunneled and placed on the remote 333 access network segment again as a L2 broadcast frame. From this 334 point, the intended host will ARP reply with a unicast frame. This 335 frame should be mapped to the ESP association back to the originating 336 PE. 338 Note that flooding of broadcast datagrams in an L2 network is prone 339 to loops. There may be other transparent bridges present in the 340 access network. Therefore, the PE devices must implement and 341 participate in an 802.1d spanning tree algorithm. Note that the 342 nature of 802.1d and the number of broadcast frames typical in most 343 networks will require the setup and maintenance of a full mesh of ESP 344 associations between PEs on an overlay, in general. 346 5.3. Names and access control lists 348 The name by which the PE devices know one another, at the protocol 349 level, is the HIT, which is a hash of the host identity public key. 350 This key can be used to authenticate messages from PE devices 351 purporting to be a named PE device. 353 However, from a management perspective, the names that operators will 354 want to use in configuration files and in access control lists should 355 be more operationally relevant, such as human- friendly strings and 356 asset tags. Certificates are used to bind a PE device's operational 357 name to its HIT. The HIT is obtained as usual, as a hash of the PE 358 device's public key. All PE devices in the overlay must share a 359 common set of CAs. 361 Certificates should be presented as parameters in the base exchange, 362 to allow peer PE devices to validate them. 364 5.4. Walkthrough of multicast operation 366 Multicast operation is similer to that described in the section on 367 handling of broadcast ARP requests. 369 5.5. Mobility, multihoming, and address families 371 The PE devices may be mobile or multihomed on the underlay. The HIP 372 mobility mechanisms [RFC5206] may be used in this case to preserve 373 existing security associations and to update database records upon 374 such changes to the underlying IP addresses. 376 The underlay may itself be a combination of IPv4 and IPv6 network 377 segments. A given overlay may be supported by either or both IPv4 378 and IPv6-based ESP security associations. 380 The CE devices may be multihomed to PE devices. In this case, the 381 PEs must coordinate to ensure that only one PE sources ingress frames 382 destined from CE4 to another CE. The PE devices may have "backdoor" 383 connections with one another. The 802.1d spanning tree protocol 384 should alleviate problems of this sort. 386 6. Proposed extensions to HIP 388 The system described above relies on the ability of the PE devices to 389 exchange certificates in the R1, I2, and UPDATE messages, based on 390 local policy. Note that passing of certificates in the HIP exchanges 391 is not strictly necessary, but it will reduce latency if the host 392 proactively provides its certificate as part of the signaling 393 exchange. Work is already underway in the HIP working group to 394 define such a certificate (CERT) parameter [RFC6253]. 396 The system described above can be thought of as a "bump-in-the-wire" 397 type of HIP deployment. Conceptually, what is being encapsulated is 398 not a transport PDU but instead a layer-2 frame. Therefore, HIP 399 implementations in the PE devices need to be able to successfully 400 encapsulate and decapsulate such frames; i.e., this system alters the 401 protocol processing in the stack compared to a host-based HIP 402 implementation. 404 An additional change is that layer-2 (and, by extension, layer-3) 405 multicast and broadcast frames, as well as layer-2 control frames 406 such as bridge PDUs, must be passed as needed. This requires a 407 capability for the PEs to send a copy of each such frame to all other 408 PEs in the overlay. One technique to do this is to replicate each 409 frame and send to each other PE in the system. To support such a 410 transmission framework, N*(N-1) tunnels must be maintained 411 collectively between the PE devices. Alternatively, a constrained 412 system may be deployed that does not support multicast or broadcast, 413 nor bridge PDUs; this would be more like a unicast-only IPLS VPN. 415 If temporary certificates are used, it has not yet been defined in 416 HIP how a host identity may change for active security associations. 418 7. Security Considerations 420 The model considered above assumes that PE devices that hold trusted 421 credentials (certificates and private keys) are trustworthy; a 422 malicious or misconfigured PE device could subvert packet delivery 423 across the overlay. 425 The model also assumes that the information that PE devices need to 426 obtain to bind the PE name to the overlay and to its respective 427 public key is not compromised, and that the keys of the PE devices 428 are themselves not compromised. A PKI revocation system may aid in 429 dealing with compromised keys. 431 Otherwise, the system described above inherits the security 432 properties found in HIP, including strong authentication of the 433 binding between host identity and (underlay) IP address, and some 434 level of robustness from denial-of-service attacks on the underlay 435 network, based on the properties of the HIP base exchange. 437 Section 5.5 of RFC 4665 describes security features from the 438 perspective of the L2VPN solution, while Section 6.5 of RFC 4665 439 describes the security from a user perspective. The HIPLS solution 440 must protect against the attacks listed in Section 5.5 of RFC 4665. 442 8. IANA Considerations 444 There are no IANA considerations. 446 9. Acknowledgments 448 Jeff Ahrenholz, Orlie Brewer, Eric Byres, Jin Fang, Darren Lissimore 449 and Jeff Meegan have provided invaluable support in the design and 450 prototype implementation of this HIPLS functionality. Richard Paine 451 and Craig Dupler were instrumental in guiding early work along these 452 lines. Members of other Standards organizations such as The Open 453 Group, the Trusted Computing Group (TCG), and the International 454 Society of Automation (ISA) have been involved in standards 455 development activities that leverage HIP and this HIPLS 456 functionality. 458 10. References 460 10.1. Normative References 462 [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 463 Private Networks (L2VPNs)", RFC 4664, September 2006. 465 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 466 "Host Identity Protocol", RFC 5201, April 2008. 468 [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the 469 Encapsulating Security Payload (ESP) Transport Format with 470 the Host Identity Protocol (HIP)", RFC 5202, April 2008. 472 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 473 Host Mobility and Multihoming with the Host Identity 474 Protocol", RFC 5206, April 2008. 476 [RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol 477 Certificates", RFC 6253, May 2011. 479 10.2. Informative References 481 [RFC4176] El Mghazli, Y., Nadeau, T., Boucadair, M., Chan, K., and 482 A. Gonguet, "Framework for Layer 3 Virtual Private 483 Networks (L3VPN) Operations and Management", RFC 4176, 484 October 2005. 486 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 487 Internet Protocol", RFC 4301, December 2005. 489 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 490 (HIP) Architecture", RFC 4423, May 2006. 492 [RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for 493 Layer 2 Provider-Provisioned Virtual Private Networks", 494 RFC 4665, September 2006. 496 [RFC4847] Takeda, T., "Framework and Requirements for Layer 1 497 Virtual Private Networks", RFC 4847, April 2007. 499 Authors' Addresses 500 Thomas R. Henderson 501 University of Washington 502 Campus Box 352500 503 Seattle, WA 504 USA 506 Email: tomhend@u.washington.edu 508 Steven C. Venema 509 The Boeing Company 510 P.O. Box 3707 511 Seattle, WA 512 USA 514 Email: steven.c.venema@boeing.com 516 David Mattes 517 Tempered Networks 518 100 West Harrison Street 519 South Tower, Suite 370 520 Seattle, WA 521 USA 523 Email: d.mattes@temperednetworks.com