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