idnits 2.17.1 draft-ietf-lisp-vpn-08.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 (January 18, 2022) is 800 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC 6830' is mentioned on line 653, but not defined ** Obsolete undefined reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Unused Reference: 'RFC3618' is defined on line 707, but no explicit reference was found in the text == Unused Reference: 'RFC4601' is defined on line 712, but no explicit reference was found in the text == Unused Reference: 'RFC4607' is defined on line 718, 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-09 -- 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. Moreno 3 Internet-Draft Google LLC 4 Intended status: Experimental D. Farinacci 5 Expires: July 22, 2022 lispers.net 6 January 18, 2022 8 LISP Virtual Private Networks (VPNs) 9 draft-ietf-lisp-vpn-08 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 July 22, 2022. 46 Copyright Notice 48 Copyright (c) 2022 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 . . . . . . . . . . . . . 7 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 Publish/Subscribe Procedures . . . . . 11 75 4.1.4. LISP Extranet VPN Home-IID encoding . . . . . . . . . 11 76 4.2. LISP Extranet VPN Data Plane . . . . . . . . . . . . . . 12 77 4.3. LISP Extranet VPN Multicast Considerations . . . . . . . 12 78 4.3.1. LISP Extranet VPN Multicast Control Plane . . . . . . 12 79 4.3.2. LISP Extranet VPN Multicast Data Plane . . . . . . . 13 80 4.4. LISP Extranet SMR Considerations . . . . . . . . . . . . 13 81 4.4.1. Home-IID inclusion in SMR messages . . . . . . . . . 14 82 4.5. LISP Extranet RLOC Probing Considerations . . . . . . . . 14 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 84 5.1. LISP VPNs and LISP Crypto . . . . . . . . . . . . . . . . 15 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 86 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 89 8.2. Informative References . . . . . . . . . . . . . . . . . 16 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 92 1. Introduction 94 Network virtualization creates multiple, logically separated 95 topologies across one common physical infrastructure. These 96 logically separated topologies are known as Virtual Private Networks 97 (VPNs) and are generally used to create closed groups of end-points. 98 Network reachability within a VPN is restricted to the addresses of 99 the end-points that are members of the VPN. This level of 100 segmentation is useful in providing fault isolation, enforcing 101 access-control restrictions, enabling the use of a single network by 102 multiple tenants and scoping network policy per VPN. 104 LISP creates two namespaces: The End-point Identifier (EID) namespace 105 and the Routing Locator (RLOC) namespace. The LISP Mapping System 106 maps EIDs to RLOCs. Either the EID space, the RLOC space or both may 107 be segmented. The LISP Mapping System can be used to map a segmented 108 EID address space to the RLOC space. When the EID namespace is 109 segmented, a LISP Instance-ID (IID) is encoded in both the data plane 110 and the control plane to provide segmentation and to disambiguate 111 overlapping EID Prefixes. This allows multiple VRFs to 'share' a 112 common Routing Locator network while maintaining EID prefix 113 segmentation. 115 LISP VPNs must support Multicast traffic in the EID space and must 116 also support the ability to provide controlled reachability across 117 VPNs which is commonly known as extranet functionality. When data 118 path security is needed, LISP virtualization can be combined with 119 LISP Crypto to provide data path confidentiality, integrity, origin 120 authentication and anti-replay protection. 122 2. Definition of Terms 124 LISP related terms, notably Map-Request, Map-Reply, Ingress Tunnel 125 Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS) and Map- 126 Resolver (MR) are defined in the LISP specification [RFC6830]. 128 Terms defining interactions with the LISP Mapping System are defined 129 in [RFC6833]. 131 Terms related to the procedures for signal free multicast are defined 132 in [RFC8378]. 134 The following terms are here defined to facilitate the descriptions 135 and discussions within this particular document. 137 Forwarding Context - Logical segment of a device's forwarding table 138 and its associated interfaces. This is usually in the form of a VRF 139 for IP forwarding, may also be in the form of a Bridge Domain or VLAN 140 for MAC forwarding. 142 Home-IID - In the context of cross VPN connectivity, a particular EID 143 will be registered with multiple Instance-IDs, the Home-IID 144 identifies the Instance-ID associated to the Forwarding Context (VRF) 145 to which an EID is actually connected. 147 Extranet-VPN - In the context of cross VPN connectivity, a VPN that 148 is reachable by all Extranet-Subscriber-VPNs and can reach all 149 Extranet-Subscriber-VPNs. 151 Extranet-Subscriber-VPN - The VPNs that can reach the Extranet-VPN, 152 but cannot reach each other. 154 Extranet Policy - The definition of which VPNs share reachability 155 information with each other in the context of cross VPN connectivity. 156 May be structured as a group of Extranet-Subscriber-VPNs that 157 subscribe to an Extranet-VPN. 159 3. LISP Virtual Private Networks (VPNs) 161 A LISP VPN is a collection of LISP Sites building an Overlay Network. 162 These sites share a common control plane, the LISP Mapping System. 163 The members of this VPN also share common RLOC connectivity, whether 164 it be the Internet or a private IP network. 166 Multiple LISP VPNs may run over a common RLOC space and many LISP 167 VPNs may share one or more locations, requiring XTRs to service 168 multiple VPNs simultaneously. 170 VPNs must be allowed to have overlapping address space. It is 171 necessary to disambiguate the EID namespace in both the control and 172 data plane as well as maintain forwarding segmentation within the 173 XTRs. The LISP Instance ID (IID) is used to provide a VPN wide 174 unique identifier that can be used both in the control and data 175 planes. 177 The LISP Instance ID is a 32 bit unstructured namespace that 178 identifies a LISP VPN. The tuple of EID Prefix and IID is referred 179 to as an Extended EID (XEID) [RFC8111]. The LISP IID is used in the 180 data plane of the LISP header [RFC6830], as well as in the LISP 181 control plane [RFC8060]. 183 An implementation should default to an Instance ID value equal to 184 zero when LISP VPNs are not in use. 186 The operation of a LISP VPN is consistent with the operation of LISP 187 in a non-VPN environment as defined in [RFC6830]. The operation of a 188 LISP VPN is here described at a high level in terms of EID 189 registrations, EID lookups and traffic forwarding: 191 EID registration: In a LISP VPN, XTRs that are members of the VPN 192 should be configured with a forwarding context (e.g. VRF) and the 193 associated IID for the VPN. Based on this configuration, the ETRs 194 must register the EIDs within the forwarding context as Extended EIDs 195 (IID+EID). The LISP mapping system consolidates the registrations 196 from all the ETRs in the VPN and builds a mapping database for the 197 VPN. 199 EID Lookup: ITRs that are members of the VPN will do forwarding 200 lookups in the forwarding context where traffic was received. Upon a 201 cache miss within the forwarding context, the ITR must issue a Map- 202 Request for the destination EID and include the VPN's IID. This 203 information must be encoded as an Extended EID (IID+EID) in the Map- 204 Request issued. The IID to associate with the EID in this Map- 205 request is derived from the configuration of the VPN's forwarding 206 context (in which the traffic was received). The Mapping System 207 should reply to the Map Request with a Mapping for the Extended EID 208 (IID+EID), the IID of the Extended EID should be used to identify the 209 forwarding context in which the Mapping received should be cached. 211 Traffic Forwarding: Once a Mapping has been cached in the VPN's 212 forwarding context, the ITR will encapsulate the traffic towards the 213 RLOC in the mapping. The IID corresponding to the VPN's forwarding 214 context must be included in the Instance-ID field of the data plane 215 header. When the encapsulated traffic is received at the ETR the 216 encapsulation header is removed and the IID received in the header is 217 used to identify the forwarding context to use to do a forwarding 218 lookup for the decapsulated traffic. 220 A more formal description of the Control and Data Plane procedures 221 for a LISP VPN is documented in the following sections. 223 In order to create VPNs, the following segmentation functions must be 224 provided: 226 o Device Segmentation. The forwarding tables of the devices must be 227 segmented so that independent forwarding decisions can be made for 228 each virtual network. Virtual Routing and Forwarding (VRF) 229 contexts may be used to create multiple instances of Layer 3 230 routing tables virtualization (segmentation) at the device level. 231 If the EID space is in a Layer 2 address family (e.g. MAC 232 addresses), then Layer 2 contexts such as VLANs or bridge domains 233 may be used to segment the device. We generalize the concept of 234 separate forwarding tables as forwarding contexts. 236 o Data Plane Segmentation. Data Plane Forwarding separation is 237 necessary for the devices to maintain virtual network semantics at 238 forwarding time. Data plane separation can be maintained across 239 network paths using either single-hop path segmentation (hop-by- 240 hop) or multi-hop path segmentation. Single-hop path segmentation 241 mechanisms include constructs such as 802.1q VLAN trunks, multi- 242 hop mechanisms include MPLS, LISP, VXLAN and GRE tunnels. 244 o Control Plane Segmentation. In order to correctly populate the 245 multiple forwarding tables in the segmented network devices, the 246 control plane needs to be segmented so that the different updates 247 that are conveyed by the control plane contain the necessary 248 virtual network semantics to discriminate between information 249 relevant to one segment vs another. Control plane segmentation is 250 key to allowing sites to use overlapping network prefixes in these 251 logically separate topologies. BGP/MPLS VPNs (ref RFC 4364) are 252 an example of this control plane segmentation. 254 3.1. The LISP IID in the Control Plane 256 In a LISP Mapping System supporting VPNs, EID Prefixes should be 257 registered as Extended EID tuples of information that include the EID 258 prefix as well as its corresponding Instance ID (IID) information. 260 In a segmented LISP network, whenever an EID is present in a LISP 261 message, the EID must be encoded as an extended EID using the 262 Instance ID LCAF type defined in [RFC8060]. This includes all LISP 263 messages pertinent to the EIDs in the segmented space, including, but 264 not limited to, Map-Register, Map-Request, Map-Reply, Map-Notify, 265 SMRs, etc. 267 On EID registration by an ETR, the Map-Register message sent by the 268 ETR must contain the corresponding IID encoded as part of the EID 269 using the Instance ID LCAF type. 271 On EID lookup, when an ITR issues a Map-Request, both the Map-Request 272 message and the resulting Map-Reply must contain the IID for the EID 273 encoded using the IID LCAF type. The IID to use for a Map-Request 274 may be derived from the configuration of the ITR Ingress VRF. The 275 mappings received by an ITR in a Map-Reply should be cached in the 276 VRF corresponding (by configuration) to the IID included in the Map- 277 Reply message. 279 The Mapping System must maintain the IID information that corresponds 280 to any EIDs actively registered with the Mapping System. 282 3.2. The LISP IID in the Data Plane 284 A LISP xTR will map, by configuration, a LISP Instance ID to a given 285 forwarding context in its EID namespace. The Instance-ID must be 286 included in the data plane header to allow an xTR to identify which 287 VPN the packet belongs to when encapsulating or decapsulating LISP 288 packets. The LISP header [RFC6830] as well as the VXLAN header 289 [RFC7348] reserve a 24 bit field for the purposes of encoding the 290 Instance-ID (referred to as VNID in the VXLAN specification). 292 LISP ITRs may receive non-encapsulated traffic on an interface that 293 is associated with the forwarding context for a VPN (e.g. VRF). A 294 LISP ITR should do Map-cache lookups for the destination EID within 295 the forwarding context in which it received the traffic. The LISP 296 ITR must encapsulate the traffic to the destination RLOC found in the 297 map-cache and must include, in the header of the encapsulated packet, 298 the IID associated with the forwarding context for the VPN. In the 299 event of a map-cache miss, the LISP ITR must issue a Map-request with 300 the IID associated with the ITR Ingress VRF as described in 301 Section 3.1. 303 On receipt of an encapsulated LISP packet, a LISP ETR will deliver 304 the decapsulated packets to the VRF associated with the IID received 305 in the LISP header. Standard routing lookups will then take place 306 within the context of the VRF for the forwarding of the decapsulated 307 packet towards its destination. 309 The use of multiple IIDs on a single site xTR, each mapped to a 310 different EID VRF allows for multiplexing of VPNs over a Locator 311 network. 313 3.3. Locator Network Segmentation 315 This document has so far discussed virtualizing the LISP EID 316 namespace, and communication between xTRs and the LISP Mapping 317 System. Implicit in this communication requirement is a network 318 between these devices. LISP VPNs do not require this underlay 319 network connectivity to be in the "default" VRF, just that a a given 320 LISP Site and its Mapping System be interconnected via a common VRF. 322 LISP xTRs may have connectivity to each other via multiple distinct 323 VRFs, as in the case where the LISP VPN is being used to create an 324 Overlay with multiple MPLS-VPN Service Providers being used as the 325 transport. In other words, the RLOC space may also be segmented, the 326 segmentation of the RLOC space is not done by LISP, but the 327 segmentation of the RLOC space is delivered by the routing protocols 328 and data plane used by the RLOC space. When the RLOC space is 329 segmented, different EID segments may use different RLOC segments. 331 An RLOC segment may service one or many EID segments, allowing a VPN 332 in the RLOC space to service a subset of the VPNs created in the EID 333 space. 335 3.4. Multicast in LISP VPN environments 337 Both Signaled and Signal Free Multicast within a VPN will operate 338 without modification in VPN environments provided that all LISP 339 control plane messages include the Instance ID for their VPN as 340 specified in Section 3. Multicast Source (S) state as well as 341 multicast Group (G) state are both scoped within a VPN and therefore 342 the values for S and G may be reused in other VPNs. 344 4. LISP VPN Extranet 346 In a multi-tenant network the communication between a shared VPN and 347 a multitude of otherwise isolated VPNs is generally known as extranet 348 communication. Reachability is established between an shared 349 Extranet-VPN and a multitude of Extranet-Subscriber-VPNs without 350 enabling reachability between the different Extranet-Subscriber-VPNs. 351 This section specifies the procedures and protocol encodings 352 necessary to provide extranet functionality in a multi-instance LISP 353 network. The mechanisms described require cross VPN lookups and 354 therefore assume that the EID space across all VPNs involved does not 355 overlap or has been translated to a normalized space that resolves 356 any overlaps. 358 The operation of a LISP VPN Extranet is consistent with the operation 359 of LISP VPNs as defined in Section 3. The operation of a LISP VPN 360 Extranet is here described at a high level in terms of EID 361 registrations, EID lookups and traffic forwarding: 363 EID Registration: EIDs in the Extranet-VPN should be registered in 364 their Home-IID as well as in all other IIDs that are part of the 365 Extranet scope. EIDs in the Extranet-Subscriber-VPNs should be 366 registered in their Home-IID and the Extranet-VPN's IID. This makes 367 the EIDs available for lookups in VPNs other than their Home-VPN. 368 When an EID is registered in an IID that it does not belong to, the 369 mapping should include a parameter containing the Home-IID for the 370 EID. As a result any EID that should be reachable based on the 371 Extranet configuration will be registered in every relevant VPN, if 372 the EID is not native to that VPN, the mapping will have a parameter 373 with the Home-IID for the EID. 375 EID Lookup: Map-requests will be issued within the IID of the 376 requesting VPN as specified in Section 3. If the destination is 377 across VPNs, the mapping for the destination EID should contain the 378 EID's Home-IID as a parameter. The mapping, including the Home-IID 379 parameter is returned in a Map-Reply and cached by the ITR in the 380 Forwarding Context of the requesting VPN. The cache will include the 381 destination's Home-IID as a parameter of the mapping. 383 Traffic Forwarding: An ITR will encapsulate traffic to a cross VPN 384 destination using the destination's Home-IID in the data plane 385 header. Upon decapsulation at the ETR, traffic is handed directly to 386 the destination VPN's forwarding context based on the IID used in the 387 header. 389 A more formal description of the Control and Data Plane procedures 390 for a LISP VPN Extranet is documented in the following sections. 392 4.1. LISP Extranet VPN Control Plane 394 In order to achieve reachability across VPNs, EID mapping entries in 395 the Extranet-VPN must be accessible for lookups initiated from an 396 Extranet-Subscriber-VPN and vice-versa. 398 The definition of which VPNs share reachability information is 399 governed by configurable Extranet Policy. The Extranet Policy will 400 simply state which VPNs are extranet-subscribers to a particular 401 extranet-VPN. There may be multiple Extranet-VPNs in a LISP network 402 and a VPN may subscribe to multiple Extranet-VPNs. An Extranet- 403 subscriber-VPN may act as an Extranet-VPN to provide reachability 404 across Extranet-subscriber-VPNs, this effectively merges the 405 Extranet-subscriber-VPNs together, a scenario that is usually better 406 achieved by creating a single Extranet-subscriber-VPN. 408 The Instance-ID (IID) for the VPN to which an EID is connected is 409 referred to as the Home-IID of the EID. As cross VPN registrations 410 and lookups take place, the Home-IID for an EID must be preserved and 411 communicated in any pertinent LISP messages. 413 4.1.1. LISP Extranet VPN Map Register Procedures 415 An ETR may register EIDs in their Home-IID as well as in the other 416 IIDs within the scope of the Extranet Policy. For example, an EID 417 connected to the Extranet-VPN may be registered by its ETR in its 418 Home-IID and also in all the IIDs corresponding to the Extranet- 419 Subscriber-VPNs defined in the Extranet Policy. When Map-Register 420 messages for an EID are issued in IIDs other than the EID's Home-IID, 421 the Home-IID for the EID must be included in the Map-Register. The 422 Home-IID must be encoded as described in Section 4.1.4. 424 When registering an EID in multiple IIDs, it is advisable to pack the 425 multiple registrations in a single Map-Register message containing 426 the multiple XEID records. 428 A Map-Server may be configured with the Extranet Policy. This may 429 suffice for the Map-Server to be able to satisfy cross VPN lookups. 430 In such implementations, ETRs may not be required to register an EID 431 across the entire scope of IIDs defined in the Extranet Policy, but 432 may only require the registration of the EID in its Home-IID. 434 Which method of cross VPN mapping registration is used (initiated by 435 the ETR or initiated by the Map-Server) should be a configurable 436 option on the XTRs and Map-Server. 438 4.1.2. LISP Extranet VPN Map Lookup Procedures 440 Map-Request messages issued by an ITR, their structure and use do not 441 change when a destination EID is outside of the Home-IID for the 442 source EID. 444 When a Map-Request message is forwarded from the Map-Resolver to an 445 authoritative Map-Server (either directly or by DDT delegation), the 446 IID of the requesting EID must be preserved so that the Map-Reply is 447 sent in the correct context. 449 Map-Reply messages must use the IID of the requesting EID and must 450 also include the Home-IID of the destination EID. The Home-IID is a 451 parameter of the destination EID, part of the mapping and must be 452 encoded as described in Section 4.1.4. The mapping obtained in the 453 Map-Reply must be cached in the forwarding context of the requesting 454 EID, which is identified by the IID for the requesting EID. The 455 mappings cached will contain the Home-IID of the destination EID 456 whenever this destination EID is cached outside of its Home-IID. 458 Since each IID at the Map Server has a complete set of EIDs in the 459 scope of the extranet policy, the deterination of a covering prefix 460 in the case of a non-LISP or external destination is straightforward 461 and follows the proceedures delineated in the procedures for a 462 negative map reply in [RFC6833].When the Map Server determines that 463 the requested destination EID is either not an EID or not registered 464 it must calculate the covering prefix for the requested EID and reply 465 in one of two ways: 467 - With a Negative Map Reply per the procedures outlined in [RFC6833]. 468 If using a PeTR, the Home-IID for the PeTR must be configured at the 469 requesting ITR. 471 - WIth a Map Reply mapping the calculated EID covering prefix to the 472 RLOCs of a configured or registered PeTR. The Map Reply must contain 473 the Home-IID of the registered PeTR. 475 4.1.3. LISP Extranet Publish/Subscribe Procedures 477 When LISP Extranet VPNs are implemented together with LISP Publish/ 478 Subscribe functionality [I-D.ietf-lisp-pubsub], the following 479 considerations apply. 481 Subscriptions initiated across VPNs MUST maintain a record of the IID 482 from which the subscription was requested. An ITR that issues a Map- 483 Request with the N-bit set from an Extranet-Subscriber-VPN will use 484 the IID of the Extranet-Subscriber-VPN as the IID for the XEID it 485 subscribes to. The Map-Request is routed to the Extranet-VPN (Home- 486 VPN) where the EID is registered, as defined in Section 4.1.2. The 487 subscription is maintained in the Home-VPN and will include a record 488 of the IID of the Extranet-Subscriber-VPN from which the subscription 489 was initiated. 491 Any changes in the RLOC set for the EID will be published using a 492 Map-Notify message. The Map-Notify message will include the 493 Extranet-Subscriber-VPN IID in the XEID and it will also include the 494 IID of the Home-VPN (Home-IID) encoded as specified in Section 4.1.4. 496 4.1.4. LISP Extranet VPN Home-IID encoding 498 The Home-IID is an attribute of the EID-RLOC mapping. The Home-IID 499 must be encoded as an additional RLOC within the record carried in 500 Map-Reply messages as defined in [RFC6830]. The Home-IID should also 501 be included in Map-Notify messages when LISP Extranet VPNs are 502 implemented together with LISP Publish/Subscribe functionality 503 [I-D.ietf-lisp-pubsub]. 505 The additional RLOC containing the Home-IID should use AFI = 16387 506 (LCAF) with a List type as described in Section 4.1.4.1. 508 4.1.4.1. Home-IID encoded in LCAF List type 510 The Home-IID may be encoded as LCAF AFI of type Instance ID (Type 2). 511 The IID LCAF AFI entry should be nested within a List Type LCAF (Type 512 1). The list type is used to include a distinguished name type that 513 would provide the semantical information that identifies this field 514 as a Home-IID to be used for the purposes of Extranet VPNs. Map- 515 Servers and XTRs receiving the encoded messages would leverage the 516 semantical information to parse the control plane message properly. 517 The different LCAF types are documented in [RFC8060]. The logical 518 structure of the nested LCAF structure is depicted below: 520 AFI = LCAF(16387) 521 Type = LIST(1) 522 ITEM1 523 AFI = Distinguished Name 524 Value = "Home-IID" 525 ITEM2 526 AFI = LCAF(16387) 527 Type = IID(2) 528 Value = 530 4.1.4.2. Home-IID encoded in dedicated LCAF Type 532 Alternatively, a new dedicated LCAF type could be used in order to 533 include application semantics to the encoding of the IID in a 534 purposely structured type. In the future, this document may be 535 updated to provide details of the definition of structure and 536 semantics for a dedicated LCAF type to be used in this application. 538 4.2. LISP Extranet VPN Data Plane 540 Traffic will be forwarded according to the procedures outlined in 541 [RFC6830]. The map-cache will include the Home-IID for the 542 destination EID as part of the mapping for the destination EID. In 543 an ITR, unicast traffic will be encapsulated using the Home-IID for 544 the destination EID as the Instance-ID in the encapsulation header. 545 On de-capsulation, the Instance-ID in the header points to the 546 destination VPN already so no further procedures are required. 548 4.3. LISP Extranet VPN Multicast Considerations 550 When Multicast traffic needs to be forwarded across VPNs, there are 551 special considerations that are closely tied to the definition of the 552 Extranet functionality. This specification will focus on the use of 553 Signal Free Multicast [RFC8378] for the delivery of a cross VPN 554 multicast service. 556 4.3.1. LISP Extranet VPN Multicast Control Plane 558 The Receiver-site Registration procedures described in [RFC8378] are 559 expanded to allow the formation of a replication-list inclusive of 560 Receivers detected in the different VPNs within the scope of the 561 Extranet Policy. 563 Once the Receiver-ETRs detect the presence of Receivers at the 564 Receiver-site, the Receiver-ETRs will issue Map-Register messages to 565 include the Receiver-ETR RLOCs in the replication-list for the 566 multicast-entry the Receivers joined. 568 The encodings for Map-Register messages and the EIDs and RLOCs within 569 follow the guidelines defined in [RFC8378]. 571 For VPNs within the scope of the Extranet Policy the multicast 572 receiver registrations will be used to build a common replication 573 list across all VPNs in the Extranet Policy scope. This replication 574 list is maintained within the scope of the VPN where the multicast 575 source resides. When Receivers are in the Extranet-Subscriber-VPN, 576 Multicast sources are assumed to be in the Extranet-VPN and 577 viceversa. 579 The Instance-ID used to Register the Receiver-ETR RLOCs in the 580 replication-list is the Instance-ID of the Extranet-VPN, i.e. the VPN 581 where the Multicast Source resides. When listeners are detected in 582 the Extranet-VPN, then multiple Registrations must be sent with the 583 Instance-IDs of the Extranet-Subscriber-VPNs under the assumption 584 that the Multicast sources could be in one or more of the Extranet- 585 Subscriber-VPNs. 587 Source-ITRs will complete lookups for the replication-list of a 588 particular multicast group destination as well as the forwarding of 589 traffic to this multicast group following the procedures defined in 590 [RFC8378] without any change. 592 4.3.2. LISP Extranet VPN Multicast Data Plane 594 It is desirable to send a single copy of the Multicast traffic over 595 the transit network and have the Receiver-ETRs locally replicate the 596 traffic to all Receiver-VPNs necessary. This replication is governed 597 by the Extranet Policy configured at the ETR. Thus, ITRs will 598 encapsulate the traffic with the Instance-ID for the VPN where the 599 Multicast Source resides. ETRs will receive traffic in the source 600 IID and replicate it to the Receiver VPNs per the Extranet Policy. 602 4.4. LISP Extranet SMR Considerations 604 Data driven SMRs MUST carry the IID for the VPNs of the receivers of 605 traffic. Data driven SMRs MAY carry the IID for the VPNs of senders 606 of traffic if the sender VPN IIDs are known by the ETR generating the 607 SMR. If the sender VPN's Instance-ID is not known, the ETR SHOULD 608 send the SMR to the RLOC of the sending ITR without the sender VPN's 609 IID. 611 The SMR MUST be replicated to all extranet VPNs that are defined in 612 the Extranet Policy and instantiated at the sending ITR. 614 When the IID of the sender VPN is known at the ETR, the ETR MAY 615 include the sender VPN's IID in the SMR and issue a separate SMR for 616 each sender VPN IID known to the ETR. Multicast optimizations could 617 be used to minimize the amount of traffic replicated when sending 618 these SMRs and potentially replicate only at the ITR. 620 When the IID of the sender VPN is not known at the ETR, the ETR 621 SHOULD issue a single SMR to each of the sending ITRs. The SMR will 622 then be replicated at the ITR to all extranet VPNs that are defined 623 in the Extranet Policy and instantiated at the sending ITR. 625 4.4.1. Home-IID inclusion in SMR messages 627 The Instance IDs relevant to the SMR signaling will be encoded in the 628 SMR Map-request message fields as follows: 630 Source-EID field: If known by the ETR, this field SHOULD carry the 631 instance-ID of the traffic source VPN at the ITR with the obsolete 632 map-cache. This is the IID of the senders of the traffic. 633 Otherwise, the Instance-ID in this field MUST be the same as the 634 Instance-ID of the destination VPN at the ETR generating the SMR. 636 EID-Prefix field: This field carries the Instance-ID of the 637 destination VPN at the ETR sending the SMR. This is the IID of the 638 receivers of the traffic. This field must always be set with the IID 639 of the receivers. 641 4.5. LISP Extranet RLOC Probing Considerations 643 RLOC Probes must be sent with the IID of the VPN originating the 644 probe. The XTR receiving the probe must identify the VPN for the 645 target EID. The XTR receiving the probe should run all verifications 646 as specified in [RFC6830] within the forwarding context corresponding 647 to the VPN where the target EID is connected. Once verifications are 648 completed, the reply to the probe should be sent in the IID of the 649 VPN that originated the probe. 651 5. Security Considerations 653 LISP [RFC 6830] incorporates many security mechanisms as part of the 654 mapping database service when using control-plane procedures for 655 obtaining EID-to-RLOC mappings. In general, data plane mechanisms 656 are not of primary concern for general Internet use-case. However, 657 when LISP VPNs are deployed, several additional security mechanisms 658 and considerations must be addressed. 660 Data plane traffic uses the LISP instance-id (IID) header field for 661 segmentation. in-flight modifications of this IID value could result 662 in violations to the tenant segmentation provided by the IID. 663 Protection against this attack can be achieved by using the integrity 664 protection mechanisms afforded by LISP Crypto, with or without 665 encryption depending on users' confidentiality requirements (see 666 below). 668 5.1. LISP VPNs and LISP Crypto 670 The procedures for data plane confidentiality in LISP are documented 671 in [RFC8061] and are primarily aimed at negotiating secret shared 672 keys between ITR and ETR in map-request and map-reply messages. 673 These secret shared keys are negotiated on a per RLOC basis and 674 without regard for any VPN segmentation done in the EID space. Thus, 675 multiple VPNs using a shared RLOC may also share a common secret key 676 to encrypt communications of the multiple VPNs. 678 It is possible to negotiate secret shared keys on a per EID basis by 679 applying the procedures described in [RFC8061] to RLOC probes. In a 680 VPN environment, RLOC probes would be aimed at Extended EIDs that 681 contain Instance-ID semantics, therefore resulting in the calculation 682 of different secret shared keys for different XEID. Since the keys 683 are calculated per XEID prefix rather than per VPN, there are scale 684 considerations when implementing this level of key negotiation 685 granularity. 687 6. IANA Considerations 689 This document has no IANA implications 691 7. Acknowledgements 693 The authors want to thank Marc Portoles, Vrushali Ashtaputre, Johnson 694 Leong, Jesus Arango, Prakash Jain, Sanjay Hooda, Alberto Rodriguez- 695 Natal, Darrel Lewis and Greg Schudel for their insightful 696 contribution to shaping the ideas in this document. 698 8. References 700 8.1. Normative References 702 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 703 Requirement Levels", BCP 14, RFC 2119, 704 DOI 10.17487/RFC2119, March 1997, 705 . 707 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 708 Discovery Protocol (MSDP)", RFC 3618, 709 DOI 10.17487/RFC3618, October 2003, 710 . 712 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 713 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 714 Protocol Specification (Revised)", RFC 4601, 715 DOI 10.17487/RFC4601, August 2006, 716 . 718 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 719 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 720 . 722 8.2. Informative References 724 [I-D.ietf-lisp-pubsub] 725 Rodriguez-Natal, A., Ermagan, V., Cabellos, A., Barkai, 726 S., and M. Boucadair, "Publish/Subscribe Functionality for 727 LISP", draft-ietf-lisp-pubsub-09 (work in progress), June 728 2021. 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 Google LLC 779 1600 Amphitheater Parkway 780 Mountain View, CA 94043 781 USA 783 Email: vimoreno@googleo.com 785 Dino Farinacci 786 lispers.net 787 San Jose, CA 95120 788 USA 790 Email: farinacci@gmail.com