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