idnits 2.17.1 draft-ietf-lisp-vpn-07.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 (26 July 2021) is 1005 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC 6830' is mentioned on line 651, but not defined ** Obsolete undefined reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Unused Reference: 'RFC3618' is defined on line 704, but no explicit reference was found in the text == Unused Reference: 'RFC4601' is defined on line 709, but no explicit reference was found in the text == Unused Reference: 'RFC4607' is defined on line 715, but no explicit reference was found in the text == Unused Reference: 'RFC6407' is defined on line 730, but no explicit reference was found in the text == Unused Reference: 'RFC6831' is defined on line 739, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-15) exists of draft-ietf-lisp-pubsub-02 -- 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 (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V.M. Moreno 3 Internet-Draft Cisco Systems 4 Intended status: Experimental D.F. Farinacci 5 Expires: 27 January 2022 lispers.net 6 26 July 2021 8 LISP Virtual Private Networks (VPNs) 9 draft-ietf-lisp-vpn-07 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 27 January 2022. 46 Copyright Notice 48 Copyright (c) 2021 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 (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Simplified BSD License text 57 as described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 64 3. LISP Virtual Private Networks (VPNs) . . . . . . . . . . . . 4 65 3.1. The LISP IID in the Control Plane . . . . . . . . . . . . 6 66 3.2. The LISP IID in the Data Plane . . . . . . . . . . . . . 7 67 3.3. Locator Network Segmentation . . . . . . . . . . . . . . 7 68 3.4. Multicast in LISP VPN environments . . . . . . . . . . . 8 69 4. LISP VPN Extranet . . . . . . . . . . . . . . . . . . . . . . 8 70 4.1. LISP Extranet VPN Control Plane . . . . . . . . . . . . . 9 71 4.1.1. LISP Extranet VPN Map Register Procedures . . . . . . 10 72 4.1.2. LISP Extranet VPN Map Lookup Procedures . . . . . . . 10 73 4.1.3. LISP Extranet Publish/Subscribe Procedures . . . . . 11 74 4.1.4. LISP Extranet VPN Home-IID encoding . . . . . . . . . 11 75 4.2. LISP Extranet VPN Data Plane . . . . . . . . . . . . . . 12 76 4.3. LISP Extranet VPN Multicast Considerations . . . . . . . 12 77 4.3.1. LISP Extranet VPN Multicast Control Plane . . . . . . 13 78 4.3.2. LISP Extranet VPN Multicast Data Plane . . . . . . . 13 79 4.4. LISP Extranet SMR Considerations . . . . . . . . . . . . 14 80 4.4.1. Home-IID inclusion in SMR messages . . . . . . . . . 14 81 4.5. LISP Extranet RLOC Probing Considerations . . . . . . . . 14 82 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 83 5.1. LISP VPNs and LISP Crypto . . . . . . . . . . . . . . . . 15 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 88 8.2. Informative References . . . . . . . . . . . . . . . . . 16 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 91 1. Introduction 93 Network virtualization creates multiple, logically separated 94 topologies across one common physical infrastructure. These 95 logically separated topologies are known as Virtual Private Networks 96 (VPNs) and are generally used to create closed groups of end-points. 97 Network reachability within a VPN is restricted to the addresses of 98 the end-points that are members of the VPN. This level of 99 segmentation is useful in providing fault isolation, enforcing 100 access-control restrictions, enabling the use of a single network by 101 multiple tenants and scoping network policy per VPN. 103 LISP creates two namespaces: The End-point Identifier (EID) namespace 104 and the Routing Locator (RLOC) namespace. The LISP Mapping System 105 maps EIDs to RLOCs. Either the EID space, the RLOC space or both may 106 be segmented. The LISP Mapping System can be used to map a segmented 107 EID address space to the RLOC space. When the EID namespace is 108 segmented, a LISP Instance-ID (IID) is encoded in both the data plane 109 and the control plane to provide segmentation and to disambiguate 110 overlapping EID Prefixes. This allows multiple VRFs to 'share' a 111 common Routing Locator network while maintaining EID prefix 112 segmentation. 114 LISP VPNs must support Multicast traffic in the EID space and must 115 also support the ability to provide controlled reachability across 116 VPNs which is commonly known as extranet functionality. When data 117 path security is needed, LISP virtualization can be combined with 118 LISP Crypto to provide data path confidentiality, integrity, origin 119 authentication and anti-replay protection. 121 2. Definition of Terms 123 LISP related terms, notably Map-Request, Map-Reply, Ingress Tunnel 124 Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS) and Map- 125 Resolver (MR) are defined in the LISP specification [RFC6830]. 127 Terms defining interactions with the LISP Mapping System are defined 128 in [RFC6833]. 130 Terms related to the procedures for signal free multicast are defined 131 in [RFC8378]. 133 The following terms are here defined to facilitate the descriptions 134 and discussions within this particular document. 136 Forwarding Context - Logical segment of a device's forwarding table 137 and its associated interfaces. This is usually in the form of a VRF 138 for IP forwarding, may also be in the form of a Bridge Domain or VLAN 139 for MAC forwarding. 141 Home-IID - In the context of cross VPN connectivity, a particular EID 142 will be registered with multiple Instance-IDs, the Home-IID 143 identifies the Instance-ID associated to the Forwarding Context (VRF) 144 to which an EID is actually connected. 146 Extranet-VPN - In the context of cross VPN connectivity, a VPN that 147 is reachable by all Extranet-Subscriber-VPNs and can reach all 148 Extranet-Subscriber-VPNs. 150 Extranet-Subscriber-VPN - The VPNs that can reach the Extranet-VPN, 151 but cannot reach each other. 153 Extranet Policy - The definition of which VPNs share reachability 154 information with each other in the context of cross VPN connectivity. 155 May be structured as a group of Extranet-Subscriber-VPNs that 156 subscribe to an Extranet-VPN. 158 3. LISP Virtual Private Networks (VPNs) 160 A LISP VPN is a collection of LISP Sites building an Overlay Network. 161 These sites share a common control plane, the LISP Mapping System. 162 The members of this VPN also share common RLOC connectivity, whether 163 it be the Internet or a private IP network. 165 Multiple LISP VPNs may run over a common RLOC space and many LISP 166 VPNs may share one or more locations, requiring XTRs to service 167 multiple VPNs simultaneously. 169 VPNs must be allowed to have overlapping address space. It is 170 necessary to disambiguate the EID namespace in both the control and 171 data plane as well as maintain forwarding segmentation within the 172 XTRs. The LISP Instance ID (IID) is used to provide a VPN wide 173 unique identifier that can be used both in the control and data 174 planes. 176 The LISP Instance ID is a 32 bit unstructured namespace that 177 identifies a LISP VPN. The tuple of EID Prefix and IID is referred 178 to as an Extended EID (XEID) [RFC8111]. The LISP IID is used in the 179 data plane of the LISP header [RFC6830], as well as in the LISP 180 control plane [RFC8060]. 182 An implementation should default to an Instance ID value equal to 183 zero when LISP VPNs are not in use. 185 The operation of a LISP VPN is consistent with the operation of LISP 186 in a non-VPN environment as defined in [RFC6830]. The operation of a 187 LISP VPN is here described at a high level in terms of EID 188 registrations, EID lookups and traffic forwarding: 190 EID registration: In a LISP VPN, XTRs that are members of the VPN 191 should be configured with a forwarding context (e.g. VRF) and the 192 associated IID for the VPN. Based on this configuration, the ETRs 193 must register the EIDs within the forwarding context as Extended EIDs 194 (IID+EID). The LISP mapping system consolidates the registrations 195 from all the ETRs in the VPN and builds a mapping database for the 196 VPN. 198 EID Lookup: ITRs that are members of the VPN will do forwarding 199 lookups in the forwarding context where traffic was received. Upon a 200 cache miss within the forwarding context, the ITR must issue a Map- 201 Request for the destination EID and include the VPN's IID. This 202 information must be encoded as an Extended EID (IID+EID) in the Map- 203 Request issued. The IID to associate with the EID in this Map- 204 request is derived from the configuration of the VPN's forwarding 205 context (in which the traffic was received). The Mapping System 206 should reply to the Map Request with a Mapping for the Extended EID 207 (IID+EID), the IID of the Extended EID should be used to identify the 208 forwarding context in which the Mapping received should be cached. 210 Traffic Forwarding: Once a Mapping has been cached in the VPN's 211 forwarding context, the ITR will encapsulate the traffic towards the 212 RLOC in the mapping. The IID corresponding to the VPN's forwarding 213 context must be included in the Instance-ID field of the data plane 214 header. When the encapsulated traffic is received at the ETR the 215 encapsulation header is removed and the IID received in the header is 216 used to identify the forwarding context to use to do a forwarding 217 lookup for the decapsulated traffic. 219 A more formal description of the Control and Data Plane procedures 220 for a LISP VPN is documented in the following sections. 222 In order to create VPNs, the following segmentation functions must be 223 provided: 225 * Device Segmentation. The forwarding tables of the devices must be 226 segmented so that independent forwarding decisions can be made for 227 each virtual network. Virtual Routing and Forwarding (VRF) 228 contexts may be used to create multiple instances of Layer 3 229 routing tables virtualization (segmentation) at the device level. 230 If the EID space is in a Layer 2 address family (e.g. MAC 231 addresses), then Layer 2 contexts such as VLANs or bridge domains 232 may be used to segment the device. We generalize the concept of 233 separate forwarding tables as forwarding contexts. 235 * Data Plane Segmentation. Data Plane Forwarding separation is 236 necessary for the devices to maintain virtual network semantics at 237 forwarding time. Data plane separation can be maintained across 238 network paths using either single-hop path segmentation (hop-by- 239 hop) or multi-hop path segmentation. Single-hop path segmentation 240 mechanisms include constructs such as 802.1q VLAN trunks, multi- 241 hop mechanisms include MPLS, LISP, VXLAN and GRE tunnels. 243 * Control Plane Segmentation. In order to correctly populate the 244 multiple forwarding tables in the segmented network devices, the 245 control plane needs to be segmented so that the different updates 246 that are conveyed by the control plane contain the necessary 247 virtual network semantics to discriminate between information 248 relevant to one segment vs another. Control plane segmentation is 249 key to allowing sites to use overlapping network prefixes in these 250 logically separate topologies. BGP/MPLS VPNs (ref RFC 4364) are 251 an example of this control plane segmentation. 253 3.1. The LISP IID in the Control Plane 255 In a LISP Mapping System supporting VPNs, EID Prefixes should be 256 registered as Extended EID tuples of information that include the EID 257 prefix as well as its corresponding Instance ID (IID) information. 259 In a segmented LISP network, whenever an EID is present in a LISP 260 message, the EID must be encoded as an extended EID using the 261 Instance ID LCAF type defined in [RFC8060]. This includes all LISP 262 messages pertinent to the EIDs in the segmented space, including, but 263 not limited to, Map-Register, Map-Request, Map-Reply, Map-Notify, 264 SMRs, etc. 266 On EID registration by an ETR, the Map-Register message sent by the 267 ETR must contain the corresponding IID encoded as part of the EID 268 using the Instance ID LCAF type. 270 On EID lookup, when an ITR issues a Map-Request, both the Map-Request 271 message and the resulting Map-Reply must contain the IID for the EID 272 encoded using the IID LCAF type. The IID to use for a Map-Request 273 may be derived from the configuration of the ITR Ingress VRF. The 274 mappings received by an ITR in a Map-Reply should be cached in the 275 VRF corresponding (by configuration) to the IID included in the Map- 276 Reply message. 278 The Mapping System must maintain the IID information that corresponds 279 to any EIDs actively registered with the Mapping System. 281 3.2. The LISP IID in the Data Plane 283 A LISP xTR will map, by configuration, a LISP Instance ID to a given 284 forwarding context in its EID namespace. The Instance-ID must be 285 included in the data plane header to allow an xTR to identify which 286 VPN the packet belongs to when encapsulating or decapsulating LISP 287 packets. The LISP header [RFC6830] as well as the VXLAN header 288 [RFC7348] reserve a 24 bit field for the purposes of encoding the 289 Instance-ID (referred to as VNID in the VXLAN specification). 291 LISP ITRs may receive non-encapsulated traffic on an interface that 292 is associated with the forwarding context for a VPN (e.g. VRF). A 293 LISP ITR should do Map-cache lookups for the destination EID within 294 the forwarding context in which it received the traffic. The LISP 295 ITR must encapsulate the traffic to the destination RLOC found in the 296 map-cache and must include, in the header of the encapsulated packet, 297 the IID associated with the forwarding context for the VPN. In the 298 event of a map-cache miss, the LISP ITR must issue a Map-request with 299 the IID associated with the ITR Ingress VRF as described in 300 Section 3.1. 302 On receipt of an encapsulated LISP packet, a LISP ETR will deliver 303 the decapsulated packets to the VRF associated with the IID received 304 in the LISP header. Standard routing lookups will then take place 305 within the context of the VRF for the forwarding of the decapsulated 306 packet towards its destination. 308 The use of multiple IIDs on a single site xTR, each mapped to a 309 different EID VRF allows for multiplexing of VPNs over a Locator 310 network. 312 3.3. Locator Network Segmentation 314 This document has so far discussed virtualizing the LISP EID 315 namespace, and communication between xTRs and the LISP Mapping 316 System. Implicit in this communication requirement is a network 317 between these devices. LISP VPNs do not require this underlay 318 network connectivity to be in the "default" VRF, just that a a given 319 LISP Site and its Mapping System be interconnected via a common VRF. 321 LISP xTRs may have connectivity to each other via multiple distinct 322 VRFs, as in the case where the LISP VPN is being used to create an 323 Overlay with multiple MPLS-VPN Service Providers being used as the 324 transport. In other words, the RLOC space may also be segmented, the 325 segmentation of the RLOC space is not done by LISP, but the 326 segmentation of the RLOC space is delivered by the routing protocols 327 and data plane used by the RLOC space. When the RLOC space is 328 segmented, different EID segments may use different RLOC segments. 329 An RLOC segment may service one or many EID segments, allowing a VPN 330 in the RLOC space to service a subset of the VPNs created in the EID 331 space. 333 3.4. Multicast in LISP VPN environments 335 Both Signaled and Signal Free Multicast within a VPN will operate 336 without modification in VPN environments provided that all LISP 337 control plane messages include the Instance ID for their VPN as 338 specified in Section 3. Multicast Source (S) state as well as 339 multicast Group (G) state are both scoped within a VPN and therefore 340 the values for S and G may be reused in other VPNs. 342 4. LISP VPN Extranet 344 In a multi-tenant network the communication between a shared VPN and 345 a multitude of otherwise isolated VPNs is generally known as extranet 346 communication. Reachability is established between an shared 347 Extranet-VPN and a multitude of Extranet-Subscriber-VPNs without 348 enabling reachability between the different Extranet-Subscriber-VPNs. 349 This section specifies the procedures and protocol encodings 350 necessary to provide extranet functionality in a multi-instance LISP 351 network. The mechanisms described require cross VPN lookups and 352 therefore assume that the EID space across all VPNs involved does not 353 overlap or has been translated to a normalized space that resolves 354 any overlaps. 356 The operation of a LISP VPN Extranet is consistent with the operation 357 of LISP VPNs as defined in Section 3. The operation of a LISP VPN 358 Extranet is here described at a high level in terms of EID 359 registrations, EID lookups and traffic forwarding: 361 EID Registration: EIDs in the Extranet-VPN should be registered in 362 their Home-IID as well as in all other IIDs that are part of the 363 Extranet scope. EIDs in the Extranet-Subscriber-VPNs should be 364 registered in their Home-IID and the Extranet-VPN's IID. This makes 365 the EIDs available for lookups in VPNs other than their Home-VPN. 366 When an EID is registered in an IID that it does not belong to, the 367 mapping should include a parameter containing the Home-IID for the 368 EID. As a result any EID that should be reachable based on the 369 Extranet configuration will be registered in every relevant VPN, if 370 the EID is not native to that VPN, the mapping will have a parameter 371 with the Home-IID for the EID. 373 EID Lookup: Map-requests will be issued within the IID of the 374 requesting VPN as specified in Section 3. If the destination is 375 across VPNs, the mapping for the destination EID should contain the 376 EID's Home-IID as a parameter. The mapping, including the Home-IID 377 parameter is returned in a Map-Reply and cached by the ITR in the 378 Forwarding Context of the requesting VPN. The cache will include the 379 destination's Home-IID as a parameter of the mapping. 381 Traffic Forwarding: An ITR will encapsulate traffic to a cross VPN 382 destination using the destination's Home-IID in the data plane 383 header. Upon decapsulation at the ETR, traffic is handed directly to 384 the destination VPN's forwarding context based on the IID used in the 385 header. 387 A more formal description of the Control and Data Plane procedures 388 for a LISP VPN Extranet is documented in the following sections. 390 4.1. LISP Extranet VPN Control Plane 392 In order to achieve reachability across VPNs, EID mapping entries in 393 the Extranet-VPN must be accessible for lookups initiated from an 394 Extranet-Subscriber-VPN and vice-versa. 396 The definition of which VPNs share reachability information is 397 governed by configurable Extranet Policy. The Extranet Policy will 398 simply state which VPNs are extranet-subscribers to a particular 399 extranet-VPN. There may be multiple Extranet-VPNs in a LISP network 400 and a VPN may subscribe to multiple Extranet-VPNs. An Extranet- 401 subscriber-VPN may act as an Extranet-VPN to provide reachability 402 across Extranet-subscriber-VPNs, this effectively merges the 403 Extranet-subscriber-VPNs together, a scenario that is usually better 404 achieved by creating a single Extranet-subscriber-VPN. 406 The Instance-ID (IID) for the VPN to which an EID is connected is 407 referred to as the Home-IID of the EID. As cross VPN registrations 408 and lookups take place, the Home-IID for an EID must be preserved and 409 communicated in any pertinent LISP messages. 411 4.1.1. LISP Extranet VPN Map Register Procedures 413 An ETR may register EIDs in their Home-IID as well as in the other 414 IIDs within the scope of the Extranet Policy. For example, an EID 415 connected to the Extranet-VPN may be registered by its ETR in its 416 Home-IID and also in all the IIDs corresponding to the Extranet- 417 Subscriber-VPNs defined in the Extranet Policy. When Map-Register 418 messages for an EID are issued in IIDs other than the EID's Home-IID, 419 the Home-IID for the EID must be included in the Map-Register. The 420 Home-IID must be encoded as described in Section 4.1.4. 422 When registering an EID in multiple IIDs, it is advisable to pack the 423 multiple registrations in a single Map-Register message containing 424 the multiple XEID records. 426 A Map-Server may be configured with the Extranet Policy. This may 427 suffice for the Map-Server to be able to satisfy cross VPN lookups. 428 In such implementations, ETRs may not be required to register an EID 429 across the entire scope of IIDs defined in the Extranet Policy, but 430 may only require the registration of the EID in its Home-IID. 432 Which method of cross VPN mapping registration is used (initiated by 433 the ETR or initiated by the Map-Server) should be a configurable 434 option on the XTRs and Map-Server. 436 4.1.2. LISP Extranet VPN Map Lookup Procedures 438 Map-Request messages issued by an ITR, their structure and use do not 439 change when a destination EID is outside of the Home-IID for the 440 source EID. 442 When a Map-Request message is forwarded from the Map-Resolver to an 443 authoritative Map-Server (either directly or by DDT delegation), the 444 IID of the requesting EID must be preserved so that the Map-Reply is 445 sent in the correct context. 447 Map-Reply messages must use the IID of the requesting EID and must 448 also include the Home-IID of the destination EID. The Home-IID is a 449 parameter of the destination EID, part of the mapping and must be 450 encoded as described in Section 4.1.4. The mapping obtained in the 451 Map-Reply must be cached in the forwarding context of the requesting 452 EID, which is identified by the IID for the requesting EID. The 453 mappings cached will contain the Home-IID of the destination EID 454 whenever this destination EID is cached outside of its Home-IID. 456 Since each IID at the Map Server has a complete set of EIDs in the 457 scope of the extranet policy, the deterination of a covering prefix 458 in the case of a non-LISP or external destination is straightforward 459 and follows the proceedures delineated in the procedures for a 460 negative map reply in [RFC6833].When the Map Server determines that 461 the requested destination EID is either not an EID or not registered 462 it must calculate the covering prefix for the requested EID and reply 463 in one of two ways: 465 - With a Negative Map Reply per the procedures outlined in [RFC6833]. 466 If using a PeTR, the Home-IID for the PeTR must be configured at the 467 requesting ITR. 469 - WIth a Map Reply mapping the calculated EID covering prefix to the 470 RLOCs of a configured or registered PeTR. The Map Reply must contain 471 the Home-IID of the registered PeTR. 473 4.1.3. LISP Extranet Publish/Subscribe Procedures 475 When LISP Extranet VPNs are implemented together with LISP Publish/ 476 Subscribe functionality [I-D.ietf-lisp-pubsub], the following 477 considerations apply. 479 Subscriptions initiated across VPNs MUST maintain a record of the IID 480 from which the subscription was requested. An ITR that issues a Map- 481 Request with the N-bit set from an Extranet-Subscriber-VPN will use 482 the IID of the Extranet-Subscriber-VPN as the IID for the XEID it 483 subscribes to. The Map-Request is routed to the Extranet-VPN (Home- 484 VPN) where the EID is registered, as defined in Section 4.1.2. The 485 subscription is maintained in the Home-VPN and will include a record 486 of the IID of the Extranet-Subscriber-VPN from which the subscription 487 was initiated. 489 Any changes in the RLOC set for the EID will be published using a 490 Map-Notify message. The Map-Notify message will include the 491 Extranet-Subscriber-VPN IID in the XEID and it will also include the 492 IID of the Home-VPN (Home-IID) encoded as specified in Section 4.1.4. 494 4.1.4. LISP Extranet VPN Home-IID encoding 496 The Home-IID is an attribute of the EID-RLOC mapping. The Home-IID 497 must be encoded as an additional RLOC within the record carried in 498 Map-Reply messages as defined in [RFC6830]. The Home-IID should also 499 be included in Map-Notify messages when LISP Extranet VPNs are 500 implemented together with LISP Publish/Subscribe functionality 501 [I-D.ietf-lisp-pubsub]. 503 The additional RLOC containing the Home-IID should use AFI = 16387 504 (LCAF) with a List type as described in Section 4.1.4.1. 506 4.1.4.1. Home-IID encoded in LCAF List type 508 The Home-IID may be encoded as LCAF AFI of type Instance ID (Type 2). 509 The IID LCAF AFI entry should be nested within a List Type LCAF (Type 510 1). The list type is used to include a distinguished name type that 511 would provide the semantical information that identifies this field 512 as a Home-IID to be used for the purposes of Extranet VPNs. Map- 513 Servers and XTRs receiving the encoded messages would leverage the 514 semantical information to parse the control plane message properly. 515 The different LCAF types are documented in [RFC8060]. The logical 516 structure of the nested LCAF structure is depicted below: 518 AFI = LCAF(16387) 519 Type = LIST(1) 520 ITEM1 521 AFI = Distinguished Name 522 Value = "Home-IID" 523 ITEM2 524 AFI = LCAF(16387) 525 Type = IID(2) 526 Value = 528 4.1.4.2. Home-IID encoded in dedicated LCAF Type 530 Alternatively, a new dedicated LCAF type could be used in order to 531 include application semantics to the encoding of the IID in a 532 purposely structured type. In the future, this document may be 533 updated to provide details of the definition of structure and 534 semantics for a dedicated LCAF type to be used in this application. 536 4.2. LISP Extranet VPN Data Plane 538 Traffic will be forwarded according to the procedures outlined in 539 [RFC6830]. The map-cache will include the Home-IID for the 540 destination EID as part of the mapping for the destination EID. In 541 an ITR, unicast traffic will be encapsulated using the Home-IID for 542 the destination EID as the Instance-ID in the encapsulation header. 543 On de-capsulation, the Instance-ID in the header points to the 544 destination VPN already so no further procedures are required. 546 4.3. LISP Extranet VPN Multicast Considerations 548 When Multicast traffic needs to be forwarded across VPNs, there are 549 special considerations that are closely tied to the definition of the 550 Extranet functionality. This specification will focus on the use of 551 Signal Free Multicast [RFC8378] for the delivery of a cross VPN 552 multicast service. 554 4.3.1. LISP Extranet VPN Multicast Control Plane 556 The Receiver-site Registration procedures described in [RFC8378] are 557 expanded to allow the formation of a replication-list inclusive of 558 Receivers detected in the different VPNs within the scope of the 559 Extranet Policy. 561 Once the Receiver-ETRs detect the presence of Receivers at the 562 Receiver-site, the Receiver-ETRs will issue Map-Register messages to 563 include the Receiver-ETR RLOCs in the replication-list for the 564 multicast-entry the Receivers joined. 566 The encodings for Map-Register messages and the EIDs and RLOCs within 567 follow the guidelines defined in [RFC8378]. 569 For VPNs within the scope of the Extranet Policy the multicast 570 receiver registrations will be used to build a common replication 571 list across all VPNs in the Extranet Policy scope. This replication 572 list is maintained within the scope of the VPN where the multicast 573 source resides. When Receivers are in the Extranet-Subscriber-VPN, 574 Multicast sources are assumed to be in the Extranet-VPN and 575 viceversa. 577 The Instance-ID used to Register the Receiver-ETR RLOCs in the 578 replication-list is the Instance-ID of the Extranet-VPN, i.e. the VPN 579 where the Multicast Source resides. When listeners are detected in 580 the Extranet-VPN, then multiple Registrations must be sent with the 581 Instance-IDs of the Extranet-Subscriber-VPNs under the assumption 582 that the Multicast sources could be in one or more of the Extranet- 583 Subscriber-VPNs. 585 Source-ITRs will complete lookups for the replication-list of a 586 particular multicast group destination as well as the forwarding of 587 traffic to this multicast group following the procedures defined in 588 [RFC8378] without any change. 590 4.3.2. LISP Extranet VPN Multicast Data Plane 592 It is desirable to send a single copy of the Multicast traffic over 593 the transit network and have the Receiver-ETRs locally replicate the 594 traffic to all Receiver-VPNs necessary. This replication is governed 595 by the Extranet Policy configured at the ETR. Thus, ITRs will 596 encapsulate the traffic with the Instance-ID for the VPN where the 597 Multicast Source resides. ETRs will receive traffic in the source 598 IID and replicate it to the Receiver VPNs per the Extranet Policy. 600 4.4. LISP Extranet SMR Considerations 602 Data driven SMRs MUST carry the IID for the VPNs of the receivers of 603 traffic. Data driven SMRs MAY carry the IID for the VPNs of senders 604 of traffic if the sender VPN IIDs are known by the ETR generating the 605 SMR. If the sender VPN's Instance-ID is not known, the ETR SHOULD 606 send the SMR to the RLOC of the sending ITR without the sender VPN's 607 IID. 609 The SMR MUST be replicated to all extranet VPNs that are defined in 610 the Extranet Policy and instantiated at the sending ITR. 612 When the IID of the sender VPN is known at the ETR, the ETR MAY 613 include the sender VPN's IID in the SMR and issue a separate SMR for 614 each sender VPN IID known to the ETR. Multicast optimizations could 615 be used to minimize the amount of traffic replicated when sending 616 these SMRs and potentially replicate only at the ITR. 618 When the IID of the sender VPN is not known at the ETR, the ETR 619 SHOULD issue a single SMR to each of the sending ITRs. The SMR will 620 then be replicated at the ITR to all extranet VPNs that are defined 621 in the Extranet Policy and instantiated at the sending ITR. 623 4.4.1. Home-IID inclusion in SMR messages 625 The Instance IDs relevant to the SMR signaling will be encoded in the 626 SMR Map-request message fields as follows: 628 Source-EID field: If known by the ETR, this field SHOULD carry the 629 instance-ID of the traffic source VPN at the ITR with the obsolete 630 map-cache. This is the IID of the senders of the traffic. 631 Otherwise, the Instance-ID in this field MUST be the same as the 632 Instance-ID of the destination VPN at the ETR generating the SMR. 634 EID-Prefix field: This field carries the Instance-ID of the 635 destination VPN at the ETR sending the SMR. This is the IID of the 636 receivers of the traffic. This field must always be set with the IID 637 of the receivers. 639 4.5. LISP Extranet RLOC Probing Considerations 641 RLOC Probes must be sent with the IID of the VPN originating the 642 probe. The XTR receiving the probe must identify the VPN for the 643 target EID. The XTR receiving the probe should run all verifications 644 as specified in [RFC6830] within the forwarding context corresponding 645 to the VPN where the target EID is connected. Once verifications are 646 completed, the reply to the probe should be sent in the IID of the 647 VPN that originated the probe. 649 5. Security Considerations 651 LISP [RFC 6830] incorporates many security mechanisms as part of the 652 mapping database service when using control-plane procedures for 653 obtaining EID-to-RLOC mappings. In general, data plane mechanisms 654 are not of primary concern for general Internet use-case. However, 655 when LISP VPNs are deployed, several additional security mechanisms 656 and considerations must be addressed. 658 Data plane traffic uses the LISP instance-id (IID) header field for 659 segmentation. in-flight modifications of this IID value could result 660 in violations to the tenant segmentation provided by the IID. 661 Protection against this attack can be achieved by using the integrity 662 protection mechanisms afforded by LISP Crypto, with or without 663 encryption depending on users' confidentiality requirements (see 664 below). 666 5.1. LISP VPNs and LISP Crypto 668 The procedures for data plane confidentiality in LISP are documented 669 in [RFC8061] and are primarily aimed at negotiating secret shared 670 keys between ITR and ETR in map-request and map-reply messages. 671 These secret shared keys are negotiated on a per RLOC basis and 672 without regard for any VPN segmentation done in the EID space. Thus, 673 multiple VPNs using a shared RLOC may also share a common secret key 674 to encrypt communications of the multiple VPNs. 676 It is possible to negotiate secret shared keys on a per EID basis by 677 applying the procedures described in [RFC8061] to RLOC probes. In a 678 VPN environment, RLOC probes would be aimed at Extended EIDs that 679 contain Instance-ID semantics, therefore resulting in the calculation 680 of different secret shared keys for different XEID. Since the keys 681 are calculated per XEID prefix rather than per VPN, there are scale 682 considerations when implementing this level of key negotiation 683 granularity. 685 6. IANA Considerations 687 This document has no IANA implications 689 7. Acknowledgements 691 The authors want to thank Marc Portoles, Vrushali Ashtaputre, Johnson 692 Leong, Jesus Arango, Prakash Jain, Sanjay Hooda, Alberto Rodriguez- 693 Natal, Darrel Lewis and Greg Schudel for their insightful 694 contribution to shaping the ideas in this document. 696 8. References 697 8.1. Normative References 699 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 700 Requirement Levels", BCP 14, RFC 2119, 701 DOI 10.17487/RFC2119, March 1997, 702 . 704 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 705 Discovery Protocol (MSDP)", RFC 3618, 706 DOI 10.17487/RFC3618, October 2003, 707 . 709 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 710 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 711 Protocol Specification (Revised)", RFC 4601, 712 DOI 10.17487/RFC4601, August 2006, 713 . 715 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 716 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 717 . 719 8.2. Informative References 721 [I-D.ietf-lisp-pubsub] 722 Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., 723 Cabellos-Aparicio, A., Barkai, S., Farinacci, D., 724 Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ 725 Subscribe Functionality for LISP", Work in Progress, 726 Internet-Draft, draft-ietf-lisp-pubsub-02, 3 November 727 2018, . 730 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 731 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 732 October 2011, . 734 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 735 Locator/ID Separation Protocol (LISP)", RFC 6830, 736 DOI 10.17487/RFC6830, January 2013, 737 . 739 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 740 Locator/ID Separation Protocol (LISP) for Multicast 741 Environments", RFC 6831, DOI 10.17487/RFC6831, January 742 2013, . 744 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 745 Protocol (LISP) Map-Server Interface", RFC 6833, 746 DOI 10.17487/RFC6833, January 2013, 747 . 749 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 750 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 751 eXtensible Local Area Network (VXLAN): A Framework for 752 Overlaying Virtualized Layer 2 Networks over Layer 3 753 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 754 . 756 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 757 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 758 February 2017, . 760 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 761 (LISP) Data-Plane Confidentiality", RFC 8061, 762 DOI 10.17487/RFC8061, February 2017, 763 . 765 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 766 Smirnov, "Locator/ID Separation Protocol Delegated 767 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 768 May 2017, . 770 [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID 771 Separation Protocol (LISP) Multicast", RFC 8378, 772 DOI 10.17487/RFC8378, May 2018, 773 . 775 Authors' Addresses 777 Victor Moreno 778 Cisco Systems 779 170 Tasman Drive 780 San Jose, California 95134 781 United States of America 783 Email: vimoreno@cisco.com 785 Dino Farinacci 786 lispers.net 787 San Jose, CA 95120 788 United States of America 790 Email: farinacci@gmail.com