idnits 2.17.1 draft-ietf-lisp-vpn-02.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 15, 2018) is 2166 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC 6830' is mentioned on line 580, but not defined ** Obsolete undefined reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Unused Reference: 'RFC3618' is defined on line 634, but no explicit reference was found in the text == Unused Reference: 'RFC4601' is defined on line 639, but no explicit reference was found in the text == Unused Reference: 'RFC4607' is defined on line 645, but no explicit reference was found in the text == Unused Reference: 'I-D.farinacci-lisp-crypto' is defined on line 651, but no explicit reference was found in the text == Unused Reference: 'I-D.farinacci-lisp-mr-signaling' is defined on line 655, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-lisp-crypto' is defined on line 660, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-lisp-ddt' is defined on line 665, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-lisp-lcaf' is defined on line 670, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-lisp-sec' is defined on line 675, but no explicit reference was found in the text == Unused Reference: 'RFC6407' is defined on line 680, but no explicit reference was found in the text == Unused Reference: 'RFC6831' is defined on line 689, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-15 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) -- Obsolete informational reference (is this intentional?): RFC 6833 (Obsoleted by RFC 9301) Summary: 2 errors (**), 0 flaws (~~), 15 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Moreno 3 Internet-Draft Cisco Systems 4 Intended status: Experimental D. Farinacci 5 Expires: November 16, 2018 lispers.net 6 May 15, 2018 8 LISP Virtual Private Networks (VPNs) 9 draft-ietf-lisp-vpn-02 11 Abstract 13 This document describes the use of the Locator/ID Separation Protocol 14 (LISP) to create Virtual Private Networks (VPNs). LISP is used to 15 provide segmentation in both the LISP data plane and control plane. 16 These VPNs can be created over the top of the Internet or over 17 private transport networks, and can be implemented by Enterprises or 18 Service Providers. The goal of these VPNs is to leverage the 19 characteristics of LISP - routing scalability, simply expressed 20 Ingress site TE Policy, IP Address Family traversal, and mobility, in 21 ways that provide value to network operators. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on November 16, 2018. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 65 3. LISP Virtual Private Networks (VPNs) . . . . . . . . . . . . 4 66 3.1. The LISP IID in the Control Plane . . . . . . . . . . . . 6 67 3.2. The LISP IID in the Data Plane . . . . . . . . . . . . . 6 68 3.3. Locator Network Segmentation . . . . . . . . . . . . . . 7 69 3.4. Multicast in LISP VPN environments . . . . . . . . . . . 8 70 4. LISP VPN Extranet . . . . . . . . . . . . . . . . . . . . . . 8 71 4.1. LISP Extranet VPN Control Plane . . . . . . . . . . . . . 9 72 4.1.1. LISP Extranet VPN Map Register Procedures . . . . . . 9 73 4.1.2. LISP Extranet VPN Map Lookup Procedures . . . . . . . 10 74 4.1.3. LISP Extranet VPN Home-IID encoding . . . . . . . . . 10 75 4.2. LISP Extranet VPN Data Plane . . . . . . . . . . . . . . 11 76 4.3. LISP Extranet VPN Multicast Considerations . . . . . . . 11 77 4.3.1. LISP Extranet VPN Multicast Control Plane . . . . . . 11 78 4.3.2. LISP Extranet VPN Multicast Data Plane . . . . . . . 12 79 4.4. LISP Extranet SMR Considerations . . . . . . . . . . . . 12 80 4.5. LISP Extranet RLOC Probing Considerations . . . . . . . . 13 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 5.1. LISP VPNs and LISP Crypto . . . . . . . . . . . . . . . . 13 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 84 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 87 8.2. Informative References . . . . . . . . . . . . . . . . . 14 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 90 1. Introduction 92 Network virtualization creates multiple, logically separated 93 topologies across one common physical infrastructure. These 94 logically separated topologies are known as Virtual Private Networks 95 (VPNs) and are generally used to create closed groups of end-points. 96 Network reachability within a VPN is restricted to the addresses of 97 the end-points that are members of the VPN. This level of 98 segmentation is useful in providing fault isolation, enforcing 99 access-control restrictions, enabling the use of a single network by 100 multiple tenants and scoping network policy per VPN. 102 LISP creates two namespaces: The End-point Identifier (EID) namespace 103 and the Routing Locator (RLOC) namespace. The LISP Mapping System 104 maps EIDs to RLOCs. Either the EID space, the RLOC space or both may 105 be segmented. The LISP Mapping System can be used to map a segmented 106 EID address space to the RLOC space. When the EID namespace is 107 segmented, a LISP Instance-ID (IID) is encoded in both the data plane 108 and the control plane to provide segmentation and to disambiguate 109 overlapping EID Prefixes. This allows multiple VRFs to 'share' a 110 common Routing Locator network while maintaining EID prefix 111 segmentation. 113 LISP VPNs must support Multicast traffic in the EID space and must 114 also support the ability to provide controlled reachability across 115 VPNs which is commonly known as extranet functionality. When data 116 path security is needed, LISP virtualization can be combined with 117 LISP Crypto to provide data path confidentiality, integrity, origin 118 authentication and anti-replay protection. 120 2. Definition of Terms 122 LISP related terms, notably Map-Request, Map-Reply, Ingress Tunnel 123 Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS) and Map- 124 Resolver (MR) are defined in the LISP specification [RFC6830]. 126 Terms defining interactions with the LISP Mapping System are defined 127 in [RFC6833]. 129 Terms related to the procedures for signal free multicast are defined 130 in [RFC8378]. 132 The following terms are here defined to facilitate the descriptions 133 and discussions within this particular document. 135 Forwarding Context - Logical segment of a device's forwarding table 136 and its associated interfaces. This is usually in the form of a VRF 137 for IP forwarding, may also be in the form of a Bridge Domain or VLAN 138 for MAC forwarding. 140 Home-IID - In the context of cross VPN connectivity, a particular EID 141 will be registered with multiple Instance-IDs, the Home-IID 142 identifies the Instance-ID associated to the Forwarding Context (VRF) 143 to which an EID is actually connected. 145 Extranet-VPN - In the context of cross VPN connectivity, a VPN that 146 is reachable by all Extranet-Subscriber-VPNs and can reach all 147 Extranet-Subscriber-VPNs. 149 Extranet-Subscriber-VPN - The VPNs that can reach the Extranet- 150 Provider-VPN, but cannot reach each other. 152 Extranet Policy - The definition of which VPNs share reachability 153 information with each other in the context of cross VPN connectivity. 154 May be structured as a group of Extranet-Subscriber-VPNs that 155 subscribe to an Extranet-VPN. 157 3. LISP Virtual Private Networks (VPNs) 159 A LISP VPN is a collection of LISP Sites building an Overlay Network. 160 These sites share a common control plane, the LISP Mapping System. 161 The members of this VPN also share common RLOC connectivity, whether 162 it be the Internet or a private IP network. 164 Multiple LISP VPNs may run over a common RLOC space and many LISP 165 VPNs may share one or more locations, requiring XTRs to service 166 multiple VPNs simultaneously. 168 VPNs must be allowed to have overlapping address space. It is 169 necessary to disambiguate the EID namespace in both the control and 170 data plane as well as maintain forwarding segmentation within the 171 XTRs. The LISP Instance ID (IID) is used to provide a VPN wide 172 unique identifier that can be used both in the control and data 173 planes. 175 The LISP Instance ID is a 32 bit unstructured namespace that 176 identifies a LISP VPN. The tuple of EID Prefix and IID is referred 177 to as an Extended EID (XEID) [RFC8111]. The LISP IID is used in the 178 data plane of the LISP header [RFC6830], as well as in the LISP 179 control plane [RFC8060]. 181 The operation of a LISP VPN is consistent with the operation of LISP 182 in a non-VPN environment as defined in [RFC6830]. The operation of a 183 LISP VPN is here described at a high level in terms of EID 184 registrations, EID lookups and traffic forwarding: 186 EID registration: In a LISP VPN, XTRs that are members of the VPN 187 should be configured with a forwarding context (e.g. VRF) and the 188 associated IID for the VPN. Based on this configuration, the ETRs 189 must register the EIDs within the forwarding context as Extended EIDs 190 (IID+EID). The LISP mapping system consolidates the registrations 191 from all the ETRs in the VPN and builds a mapping database for the 192 VPN. 194 EID Lookup: ITRs that are members of the VPN will do forwarding 195 lookups in the forwarding context where traffic was received. Upon a 196 cache miss within the forwarding context, the ITR must issue a Map- 197 Request for the destination EID and include the VPN's IID. This 198 information must be encoded as an Extended EID (IID+EID) in the Map- 199 Request issued. The IID to associate with the EID in this Map- 200 request is derived from the configuration of the VPN's forwarding 201 context (in which the traffic was received). The Mapping System 202 should reply to the Map Request with a Mapping for the Extended EID 203 (IID+EID), the IID of the Extended EID should be used to identify the 204 forwarding context in which the Mapping received should be cached. 206 Traffic Forwarding: Once a Mapping has been cached in the VPN's 207 forwarding context, the ITR will encapsulate the traffic towards the 208 RLOC in the mapping. The IID corresponding to the VPN's forwarding 209 context must be included in the Instance-ID field of the data plane 210 header. When the encapsulated traffic is received at the ETR the 211 encapsulation header is removed and the IID received in the header is 212 used to identify the forwarding context to use to do a forwarding 213 lookup for the decapsulated traffic. 215 A more formal description of the Control and Data Plane procedures 216 for a LISP VPN is documented in the following sections. 218 In order to create VPNs, the following segmentation functions must be 219 provided: 221 o Device Segmentation. The forwarding tables of the devices must be 222 segmented so that independent forwarding decisions can be made for 223 each virtual network. Virtual Routing and Forwarding (VRF) 224 contexts may be used to create multiple instances of Layer 3 225 routing tables virtualization (segmentation) at the device level. 226 If the EID space is in a Layer 2 address family (e.g. MAC 227 addresses), then Layer 2 contexts such as VLANs or bridge domains 228 may be used to segment the device. We generalize the concept of 229 separate forwarding tables as forwarding contexts. 231 o Data Plane Segmentation. Data Plane Forwarding separation is 232 necessary for the devices to maintain virtual network semantics at 233 forwarding time. Data plane separation can be maintained across 234 network paths using either single-hop path segmentation (hop-by- 235 hop) or multi-hop path segmentation. Single-hop path segmentation 236 mechanisms include constructs such as 802.1q VLAN trunks, multi- 237 hop mechanisms include MPLS, LISP, VXLAN and GRE tunnels. 239 o Control Plane Segmentation. In order to correctly populate the 240 multiple forwarding tables in the segmented network devices, the 241 control plane needs to be segmented so that the different updates 242 that are conveyed by the control plane contain the necessary 243 virtual network semantics to discriminate between information 244 relevant to one segment vs another. Control plane segmentation is 245 key to allowing sites to use overlapping network prefixes in these 246 logically separate topologies. BGP/MPLS VPNs (ref RFC 4364) are 247 an example of this control plane segmentation. 249 3.1. The LISP IID in the Control Plane 251 In a LISP Mapping System supporting VPNs, EID Prefixes should be 252 registered as Extended EID tuples of information that include the EID 253 prefix as well as its corresponding Instance ID (IID) information. 255 In a segmented LISP network, whenever an EID is present in a LISP 256 message, the EID must be encoded as an extended EID using the 257 Instance ID LCAF type defined in [RFC8060]. This includes all LISP 258 messages pertinent to the EIDs in the segmented space, including, but 259 not limited to, Map-Register, Map-Request, Map-Reply, Map-Notify, 260 SMRs, etc. 262 On EID registration by an ETR, the Map-Register message sent by the 263 ETR must contain the corresponding IID encoded as part of the EID 264 using the Instance ID LCAF type. 266 On EID lookup, when an ITR issues a Map-Request, both the Map-Request 267 message and the resulting Map-Reply must contain the IID for the EID 268 encoded using the IID LCAF type. The IID to use for a Map-Request 269 may be derived from the configuration of the ITR Ingress VRF. The 270 mappings received by an ITR in a Map-Reply should be cached in the 271 VRF corresponding (by configuration) to the IID included in the Map- 272 Reply message. 274 The Mapping System must maintain the IID information that corresponds 275 to any EIDs actively registered with the Mapping System. 277 3.2. The LISP IID in the Data Plane 279 A LISP xTR will map, by configuration, a LISP Instance ID to a given 280 forwarding context in its EID namespace. The Instance-ID must be 281 included in the data plane header to allow an xTR to identify which 282 VPN the packet belongs to when encapsulating or decapsulating LISP 283 packets. The LISP header [RFC6830] as well as the VXLAN header 284 [RFC7348] reserve a 24 bit field for the purposes of encoding the 285 Instance-ID (referred to as VNID in the VXLAN specification). 287 LISP ITRs may receive non-encapsulated traffic on an interface that 288 is associated with the forwarding context for a VPN (e.g. VRF). A 289 LISP ITR should do Map-cache lookups for the destination EID within 290 the forwarding context in which it received the traffic. The LISP 291 ITR must encapsulate the traffic to the destination RLOC found in the 292 map-cache and must include, in the header of the encapsulated packet, 293 the IID associated with the forwarding context for the VPN. In the 294 event of a map-cache miss, the LISP ITR must issue a Map-request with 295 the IID associated with the ITR Ingress VRF as described in 296 Section 3.1. 298 On receipt of an encapsulated LISP packet, a LISP ETR will deliver 299 the decapsulated packets to the VRF associated with the IID received 300 in the LISP header. Standard routing lookups will then take place 301 within the context of the VRF for the forwarding of the decapsulated 302 packet towards its destination. 304 The use of multiple IIDs on a single site xTR, each mapped to a 305 different EID VRF allows for multiplexing of VPNs over a Locator 306 network. 308 3.3. Locator Network Segmentation 310 This document has so far discussed virtualizing the LISP EID 311 namespace, and communication between xTRs and the LISP Mapping 312 System. Implicit in this communication requirement is a network 313 between these devices. LISP VPNs do not require this underlay 314 network connectivity to be in the "default" VRF, just that a a given 315 LISP Site and its Mapping System be interconnected via a common VRF. 317 LISP xTRs may have connectivity to each other via multiple distinct 318 VRFs, as in the case where the LISP VPN is being used to create an 319 Overlay with multiple MPLS-VPN Service Providers being used as the 320 transport. In other words, the RLOC space may also be segmented, the 321 segmentation of the RLOC space is not done by LISP, but the 322 segmentation of the RLOC space is delivered by the routing protocols 323 and data plane used by the RLOC space. When the RLOC space is 324 segmented, different EID segments may use different RLOC segments. 325 An RLOC segment may service one or many EID segments, allowing a VPN 326 in the RLOC space to service a subset of the VPNs created in the EID 327 space. 329 3.4. Multicast in LISP VPN environments 331 Both Signaled and Signal Free Multicast within a VPN will operate 332 without modification in VPN environments provided that all LISP 333 control plane messages include the Instance ID for their VPN as 334 specified in Section 3. Multicast Source (S) state as well as 335 multicast Group (G) state are both scoped within a VPN and therefore 336 the values for S and G may be reused in other VPNs. 338 4. LISP VPN Extranet 340 In a multi-tenant network the communication between a shared VPN and 341 a multitude of otherwise isolated VPNs is generally known as extranet 342 communication. Reachability is established between an shared 343 Extranet-VPN and a multitude of Extranet-Subscriber-VPNs without 344 enabling reachability between the different Extranet-Subscriber-VPNs. 345 This section specifies the procedures and protocol encodings 346 necessary to provide extranet functionality in a multi-instance LISP 347 network. The mechanisms described require cross VPN lookups and 348 therefore assume that the EID space across all VPNs involved does not 349 overlap or has been translated to a normalized space that resolves 350 any overlaps. 352 The operation of a LISP VPN Extranet is consistent with the operation 353 of LISP VPNs as defined in Section 3. The operation of a LISP VPN 354 Extranet is here described at a high level in terms of EID 355 registrations, EID lookups and traffic forwarding: 357 EID Registration: EIDs in the Extranet-VPN should be registered in 358 their Home-IID as well as in all other IIDs that are part of the 359 Extranet scope. EIDs in the Extranet-Subscriber-VPNs should be 360 registered in their Home-IID and the Extranet-VPN's IID. This makes 361 the EIDs available for lookups in VPNs other than their Home-VPN. 362 When an EID is registered in an IID that it does not belong to, the 363 mapping should include a parameter containing the Home-IID for the 364 EID. As a result any EID that should be reachable based on the 365 Extranet configuration will be registered in every relevant VPN, if 366 the EID is not native to that VPN, the mapping will have a parameter 367 with the Home-IID for the EID. 369 EID Lookup: Map-requests will be issued within the IID of the 370 requesting VPN as specified in Section 3. If the destination is 371 across VPNs, the mapping for the destination EID should contain the 372 EID's Home-IID as a parameter. The mapping, including the Home-IID 373 parameter is returned in a Map-Reply and cached by the ITR in the 374 Forwarding Context of the requesting VPN. The cache will include the 375 destination's Home-IID as a parameter of the mapping. 377 Traffic Forwarding: An ITR will encapsulate traffic to a cross VPN 378 destination using the destination's Home-IID in the data plane 379 header. Upon decapsulation at the ETR, traffic is handed directly to 380 the destination VPN's forwarding context based on the IID used in the 381 header. 383 A more formal description of the Control and Data Plane procedures 384 for a LISP VPN Extranet is documented in the following sections. 386 4.1. LISP Extranet VPN Control Plane 388 In order to achieve reachability across VPNs, EID mapping entries in 389 the Extranet Provider VPN must be accessible for lookups initiated 390 from an Extranet Subscriber VPN and vice-versa. 392 The definition of which VPNs share reachability information is 393 governed by configurable Extranet Policy. The Extranet Policy will 394 simply state which VPNs are extranet subscribers to a particular 395 extranet provider VPN. There may be multiple provider VPNs in a LISP 396 network and a VPN may subscribe to multiple provider VPNs. A 397 subscriber VPN may act as a provider VPN to provide reachability 398 across subscriber VPNs, this effectively merges the subscriber VPNs 399 together, a scenario that is usually better achieved by creating a 400 single subscriber VPN. 402 The Instance-ID (IID) for the VPN to which an EID is connected is 403 referred to as the Home-IID of the EID. As cross VPN registrations 404 and lookups take place, the Home-IID for an EID must be preserved and 405 communicated in any pertinent LISP messages. 407 4.1.1. LISP Extranet VPN Map Register Procedures 409 An ETR may register EIDs in their Home-IID as well as in the other 410 IIDs within the scope of the Extranet Policy. For example, an EID 411 connected to the Extranet-VPN may be registered by its ETR in its 412 Home-IID and also in all the IIDs corresponding to the Extranet- 413 Subscriber-VPNs defined in the Extranet Policy. When Map-Register 414 messages for an EID are issued in IIDs other than the EID's Home-IID, 415 the Home-IID for the EID must be included in the Map-Register. The 416 Home-IID must be encoded as described in Section 4.1.3. 418 When registering an EID in multiple IIDs, it is advisable to pack the 419 multiple registrations in a single Map-Register message containing 420 the multiple XEID records. 422 A Map-Server may be configured with the Extranet Policy. This may 423 suffice for the Map-Server to be able to satisfy cross VPN lookups. 424 In such implementations, ETRs may not be required to register an EID 425 across the entire scope of IIDs defined in the Extranet Policy, but 426 may only require the registration of the EID in its Home-IID. 428 Which method of cross VPN mapping registration is used (initiated by 429 the ETR or initiated by the Map-Server) should be a configurable 430 option on the XTRs and Map-Server. 432 4.1.2. LISP Extranet VPN Map Lookup Procedures 434 Map-Request messages issued by an ITR, their structure and use do not 435 change when a destination EID is outside of the Home-IID for the 436 source EID. 438 When a Map-Request message is forwarded from the Map-Resolver to an 439 authoritative Map-Server (either directly or by DDT delegation), the 440 IID of the requesting EID must be preserved so that the Map-Reply is 441 sent in the correct context. 443 Map-Reply messages must use the IID of the requesting EID and must 444 also include the Home-IID of the destination EID. The Home-IID is a 445 parameter of the destination EID, part of the mapping and must be 446 encoded as described in Section 4.1.3. The mapping obtained in the 447 Map-Reply must be cached in the forwarding context of the requesting 448 EID, which is identified by the IID for the requesting EID. The 449 mappings cached will contain the Home-IID of the destination EID 450 whenever this destination EID is cached outside of its Home-IID. 452 4.1.3. LISP Extranet VPN Home-IID encoding 454 The Home-IID is an attribute of the EID-RLOC mapping. The Home-IID 455 must be encoded as an additional RLOC within the record carried in 456 Map-Register, Map-Reply or Map-Notify messages as defined in 457 [RFC6830]. 459 The additional RLOC containing the Home-IID should use AFI = 16387 460 (LCAF) with a List type as described in Section 4.1.3.1. 462 4.1.3.1. Home-IID encoded in LCAF List type 464 The Home-IID may be encoded as LCAF AFI of type Instance ID (Type 2). 465 The IID LCAF AFI entry should be nested within a List Type LCAF (Type 466 1). The list type is used to include a distinguished name type that 467 would provide the semantical information that identifies this field 468 as a Home-IID to be used for the purposes of Extranet VPNs. Map- 469 Servers and XTRs receiving the encoded messages would leverage the 470 semantical information to parse the control plane message properly. 471 The different LCAF types are documented in [RFC8060]. The logical 472 structure of the nested LCAF structure is depicted below: 474 AFI = LCAF(16387) 475 Type = LIST(1) 476 ITEM1 477 AFI = Distinguished Name 478 Value = "Home-IID" 479 ITEM2 480 AFI = LCAF(16387) 481 Type = IID(2) 482 Value = 484 4.1.3.2. Home-IID encoded in dedicated LCAF Type 486 Alternatively, a new dedicated LCAF type could be used in order to 487 include application semantics to the encoding of the IID in a 488 purposely structured type. In the future, this document may be 489 updated to provide details of the definition of structure and 490 semantics for a dedicated LCAF type to be used in this application. 492 4.2. LISP Extranet VPN Data Plane 494 Traffic will be forwarded according to the procedures outlined in 495 [RFC6830]. The map-cache will include the Home-IID for the 496 destination EID as part of the mapping for the destination EID. In 497 an ITR, unicast traffic will be encapsulated using the Home-IID for 498 the destination EID as the Instance-ID in the encapsulation header. 499 On de-capsulation, the Instance-ID in the header points to the 500 destination VPN already so no further procedures are required. 502 4.3. LISP Extranet VPN Multicast Considerations 504 When Multicast traffic needs to be forwarded across VPNs, there are 505 special considerations that are closely tied to the definition of the 506 Extranet functionality. This specification will focus on the use of 507 Signal Free Multicast [RFC8378] for the delivery of a cross VPN 508 multicast service. 510 4.3.1. LISP Extranet VPN Multicast Control Plane 512 The Receiver-site Registration procedures described in [RFC8378] are 513 expanded to allow the formation of a replication-list inclusive of 514 Receivers detected in the different VPNs within the scope of the 515 Extranet Policy. 517 Once the Receiver-ETRs detect the presence of Receivers at the 518 Receiver-site, the Receiver-ETRs will issue Map-Register messages to 519 include the Receiver-ETR RLOCs in the replication-list for the 520 multicast-entry the Receivers joined. 522 The encodings for Map-Register messages and the EIDs and RLOCs within 523 follow the guidelines defined in [RFC8378]. 525 For VPNs within the scope of the Extranet Policy the multicast 526 receiver registrations will be used to build a common replication 527 list across all VPNs in the Extranet Policy scope. This replication 528 list is maintained within the scope of the VPN where the multicast 529 source resides. When Receivers are in the Extranet-Subscriber-VPN, 530 Multicast sources are assumed to be in the Extranet-VPN and 531 viceversa. 533 The Instance-ID used to Register the Receiver-ETR RLOCs in the 534 replication-list is the Instance-ID of the Extranet-VPN, i.e. the VPN 535 where the Multicast Source resides. When listeners are detected in 536 the Extranet-VPN, then multiple Registrations must be sent with the 537 Instance-IDs of the Extranet-Subscriber-VPNs under the assumption 538 that the Multicast sources could be in one or more of the Extranet- 539 Subscriber-VPNs. 541 Source-ITRs will complete lookups for the replication-list of a 542 particular multicast group destination as well as the forwarding of 543 traffic to this multicast group following the procedures defined in 544 [RFC8378] without any change. 546 4.3.2. LISP Extranet VPN Multicast Data Plane 548 It is desirable to send a single copy of the Multicast traffic over 549 the transit network and have the Receiver-ETRs locally replicate the 550 traffic to all Receiver-VPNs necessary. This replication is governed 551 by the Extranet Policy configured at the ETR. Thus, ITRs will 552 encapsulate the traffic with the Instance-ID for the VPN where the 553 Multicast Source resides. ETRs will receive traffic in the source 554 IID and replicate it to the Receiver VPNs per the Extranet Policy. 556 4.4. LISP Extranet SMR Considerations 558 Data driven SMRs need to carry the IID for the VPNs of senders. 559 Since the sender's VPN is not known, the ETR must send the SMR to the 560 sending RLOC but replicated to all VPNs defined in the Extranet 561 Policy. Multicast optimizations could be used to minimize the amount 562 of traffic replicated when sending these SMRs and potentially 563 replicate only at the ITR. An SMR traveling from an Extranet 564 Subscriber VPN to an Extranet VPN will usually be less susceptible to 565 being replicated many times than an SMR traveling in the opposite 566 direction (provider to subscriber). 568 4.5. LISP Extranet RLOC Probing Considerations 570 RLOC Probes must be sent with the IID of the VPN originating the 571 probe. The XTR receiving the probe must identify the VPN for the 572 target EID. The XTR receiving the probe should run all verifications 573 as specified in [RFC6830] within the forwarding context corresponding 574 to the VPN where the target EID is connected. Once verifications are 575 completed, the reply to the probe should be sent in the IID of the 576 VPN that originated the probe. 578 5. Security Considerations 580 LISP [RFC 6830] incorporates many security mechanisms as part of the 581 mapping database service when using control-plane procedures for 582 obtaining EID-to-RLOC mappings. In general, data plane mechanisms 583 are not of primary concern for general Internet use-case. However, 584 when LISP VPNs are deployed, several additional security mechanisms 585 and considerations must be addressed. 587 Data plane traffic uses the LISP instance-id (IID) header field for 588 segmentation. in-flight modifications of this IID value could result 589 in violations to the tenant segmentation provided by the IID. 590 Protection against this attack can be achieved by using the integrity 591 protection mechanisms afforded by LISP Crypto, with or without 592 encryption depending on users' confidentiality requirements (see 593 below). 595 5.1. LISP VPNs and LISP Crypto 597 The procedures for data plane confidentiality in LISP are documented 598 in [RFC8061] and are primarily aimed at negotiating secret shared 599 keys between ITR and ETR in map-request and map-reply messages. 600 These secret shared keys are negotiated on a per RLOC basis and 601 without regard for any VPN segmentation done in the EID space. Thus, 602 multiple VPNs using a shared RLOC may also share a common secret key 603 to encrypt communications of the multiple VPNs. 605 It is possible to negotiate secret shared keys on a per EID basis by 606 applying the procedures described in [RFC8061] to RLOC probes. In a 607 VPN environment, RLOC probes would be aimed at Extended EIDs that 608 contain Instance-ID semantics, therefore resulting in the calculation 609 of different secret shared keys for different XEID. Since the keys 610 are calculated per XEID prefix rather than per VPN, there are scale 611 considerations when implementing this level of key negotiation 612 granularity. 614 6. IANA Considerations 616 This document has no IANA implications 618 7. Acknowledgements 620 The authors want to thank Marc Portoles, Vrushali Ashtaputre, Johnson 621 Leong, Jesus Arango, Prakash Jain, Sanjay Hooda, Darrel Lewis and 622 Greg Schudel for their insightful contribution to shaping the ideas 623 in this document. 625 8. References 627 8.1. Normative References 629 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 630 Requirement Levels", BCP 14, RFC 2119, 631 DOI 10.17487/RFC2119, March 1997, 632 . 634 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 635 Discovery Protocol (MSDP)", RFC 3618, 636 DOI 10.17487/RFC3618, October 2003, 637 . 639 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 640 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 641 Protocol Specification (Revised)", RFC 4601, 642 DOI 10.17487/RFC4601, August 2006, 643 . 645 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 646 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 647 . 649 8.2. Informative References 651 [I-D.farinacci-lisp-crypto] 652 Farinacci, D., "LISP Data-Plane Confidentiality", draft- 653 farinacci-lisp-crypto-01 (work in progress), July 2014. 655 [I-D.farinacci-lisp-mr-signaling] 656 Farinacci, D. and M. Napierala, "LISP Control-Plane 657 Multicast Signaling", draft-farinacci-lisp-mr-signaling-06 658 (work in progress), February 2015. 660 [I-D.ietf-lisp-crypto] 661 Farinacci, D. and B. Weis, "LISP Data-Plane 662 Confidentiality", draft-ietf-lisp-crypto-10 (work in 663 progress), October 2016. 665 [I-D.ietf-lisp-ddt] 666 Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 667 Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- 668 ddt-09 (work in progress), January 2017. 670 [I-D.ietf-lisp-lcaf] 671 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 672 Address Format (LCAF)", draft-ietf-lisp-lcaf-22 (work in 673 progress), November 2016. 675 [I-D.ietf-lisp-sec] 676 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 677 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-15 678 (work in progress), April 2018. 680 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 681 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 682 October 2011, . 684 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 685 Locator/ID Separation Protocol (LISP)", RFC 6830, 686 DOI 10.17487/RFC6830, January 2013, 687 . 689 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 690 Locator/ID Separation Protocol (LISP) for Multicast 691 Environments", RFC 6831, DOI 10.17487/RFC6831, January 692 2013, . 694 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 695 Protocol (LISP) Map-Server Interface", RFC 6833, 696 DOI 10.17487/RFC6833, January 2013, 697 . 699 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 700 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 701 eXtensible Local Area Network (VXLAN): A Framework for 702 Overlaying Virtualized Layer 2 Networks over Layer 3 703 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 704 . 706 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 707 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 708 February 2017, . 710 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 711 (LISP) Data-Plane Confidentiality", RFC 8061, 712 DOI 10.17487/RFC8061, February 2017, 713 . 715 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 716 Smirnov, "Locator/ID Separation Protocol Delegated 717 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 718 May 2017, . 720 [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID 721 Separation Protocol (LISP) Multicast", RFC 8378, 722 DOI 10.17487/RFC8378, May 2018, 723 . 725 Authors' Addresses 727 Victor Moreno 728 Cisco Systems 729 170 Tasman Drive 730 San Jose, California 95134 731 USA 733 Email: vimoreno@cisco.com 735 Dino Farinacci 736 lispers.net 737 San Jose, CA 95120 738 USA 740 Email: farinacci@gmail.com