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