idnits 2.17.1 draft-ietf-lisp-vpn-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 16, 2019) is 1778 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC 6830' is mentioned on line 636, but not defined ** Obsolete undefined reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Unused Reference: 'RFC3618' is defined on line 690, but no explicit reference was found in the text == Unused Reference: 'RFC4601' is defined on line 695, but no explicit reference was found in the text == Unused Reference: 'RFC4607' is defined on line 701, but no explicit reference was found in the text == Unused Reference: 'RFC6407' is defined on line 714, but no explicit reference was found in the text == Unused Reference: 'RFC6831' is defined on line 723, 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. Moreno 3 Internet-Draft Cisco Systems 4 Intended status: Experimental D. Farinacci 5 Expires: November 17, 2019 lispers.net 6 May 16, 2019 8 LISP Virtual Private Networks (VPNs) 9 draft-ietf-lisp-vpn-04 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 17, 2019. 46 Copyright Notice 48 Copyright (c) 2019 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 . . . . . 10 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 . . . . . . . . . 13 82 4.5. LISP Extranet RLOC Probing Considerations . . . . . . . . 14 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 84 5.1. LISP VPNs and LISP Crypto . . . . . . . . . . . . . . . . 14 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 86 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 89 8.2. Informative References . . . . . . . . . . . . . . . . . 15 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- 152 Provider-VPN, 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 Provider VPN must be accessible for lookups initiated 396 from an 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 provider VPN. There may be multiple provider VPNs in a LISP 402 network and a VPN may subscribe to multiple provider VPNs. A 403 subscriber VPN may act as a provider VPN to provide reachability 404 across subscriber VPNs, this effectively merges the subscriber VPNs 405 together, a scenario that is usually better achieved by creating a 406 single 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 4.1.3. LISP Extranet Publish/Subscribe Procedures 460 When LISP Extranet VPNs are implemented together with LISP Publish/ 461 Subscribe functionality [I-D.ietf-lisp-pubsub], the following 462 considerations apply. 464 Subscriptions initiated across VPNs MUST maintain a record of the IID 465 from which the subscription was requested. An ITR that issues a Map- 466 Request with the N-bit set from an Extranet-Subscriber-VPN will use 467 the IID of the Extranet-Subscriber-VPN as the IID for the XEID it 468 subscribes to. The Map-Request is routed to the Extranet-Provider- 469 VPN (Home-VPN) where the EID is registered, as defined in 470 Section 4.1.2. The subscription is maintained in the Home-VPN and 471 will include a record of the IID of the Extranet-Subscriber-VPN from 472 which the subscription was initiated. 474 Any changes in the RLOC set for the EID will be published using a 475 Map-Notify message. The Map-Notify message will include the 476 Extranet-Subscriber-VPN IID in the XEID and it will also include the 477 IID of the Home-VPN (Home-IID) encoded as specified in Section 4.1.4. 479 4.1.4. LISP Extranet VPN Home-IID encoding 481 The Home-IID is an attribute of the EID-RLOC mapping. The Home-IID 482 must be encoded as an additional RLOC within the record carried in 483 Map-Reply messages as defined in [RFC6830]. The Home-IID should also 484 be included in Map-Notify messages when LISP Extranet VPNs are 485 implemented together with LISP Publish/Subscribe functionality 486 [I-D.ietf-lisp-pubsub]. 488 The additional RLOC containing the Home-IID should use AFI = 16387 489 (LCAF) with a List type as described in Section 4.1.4.1. 491 4.1.4.1. Home-IID encoded in LCAF List type 493 The Home-IID may be encoded as LCAF AFI of type Instance ID (Type 2). 494 The IID LCAF AFI entry should be nested within a List Type LCAF (Type 495 1). The list type is used to include a distinguished name type that 496 would provide the semantical information that identifies this field 497 as a Home-IID to be used for the purposes of Extranet VPNs. Map- 498 Servers and XTRs receiving the encoded messages would leverage the 499 semantical information to parse the control plane message properly. 500 The different LCAF types are documented in [RFC8060]. The logical 501 structure of the nested LCAF structure is depicted below: 503 AFI = LCAF(16387) 504 Type = LIST(1) 505 ITEM1 506 AFI = Distinguished Name 507 Value = "Home-IID" 508 ITEM2 509 AFI = LCAF(16387) 510 Type = IID(2) 511 Value = 513 4.1.4.2. Home-IID encoded in dedicated LCAF Type 515 Alternatively, a new dedicated LCAF type could be used in order to 516 include application semantics to the encoding of the IID in a 517 purposely structured type. In the future, this document may be 518 updated to provide details of the definition of structure and 519 semantics for a dedicated LCAF type to be used in this application. 521 4.2. LISP Extranet VPN Data Plane 523 Traffic will be forwarded according to the procedures outlined in 524 [RFC6830]. The map-cache will include the Home-IID for the 525 destination EID as part of the mapping for the destination EID. In 526 an ITR, unicast traffic will be encapsulated using the Home-IID for 527 the destination EID as the Instance-ID in the encapsulation header. 528 On de-capsulation, the Instance-ID in the header points to the 529 destination VPN already so no further procedures are required. 531 4.3. LISP Extranet VPN Multicast Considerations 533 When Multicast traffic needs to be forwarded across VPNs, there are 534 special considerations that are closely tied to the definition of the 535 Extranet functionality. This specification will focus on the use of 536 Signal Free Multicast [RFC8378] for the delivery of a cross VPN 537 multicast service. 539 4.3.1. LISP Extranet VPN Multicast Control Plane 541 The Receiver-site Registration procedures described in [RFC8378] are 542 expanded to allow the formation of a replication-list inclusive of 543 Receivers detected in the different VPNs within the scope of the 544 Extranet Policy. 546 Once the Receiver-ETRs detect the presence of Receivers at the 547 Receiver-site, the Receiver-ETRs will issue Map-Register messages to 548 include the Receiver-ETR RLOCs in the replication-list for the 549 multicast-entry the Receivers joined. 551 The encodings for Map-Register messages and the EIDs and RLOCs within 552 follow the guidelines defined in [RFC8378]. 554 For VPNs within the scope of the Extranet Policy the multicast 555 receiver registrations will be used to build a common replication 556 list across all VPNs in the Extranet Policy scope. This replication 557 list is maintained within the scope of the VPN where the multicast 558 source resides. When Receivers are in the Extranet-Subscriber-VPN, 559 Multicast sources are assumed to be in the Extranet-VPN and 560 viceversa. 562 The Instance-ID used to Register the Receiver-ETR RLOCs in the 563 replication-list is the Instance-ID of the Extranet-VPN, i.e. the VPN 564 where the Multicast Source resides. When listeners are detected in 565 the Extranet-VPN, then multiple Registrations must be sent with the 566 Instance-IDs of the Extranet-Subscriber-VPNs under the assumption 567 that the Multicast sources could be in one or more of the Extranet- 568 Subscriber-VPNs. 570 Source-ITRs will complete lookups for the replication-list of a 571 particular multicast group destination as well as the forwarding of 572 traffic to this multicast group following the procedures defined in 573 [RFC8378] without any change. 575 4.3.2. LISP Extranet VPN Multicast Data Plane 577 It is desirable to send a single copy of the Multicast traffic over 578 the transit network and have the Receiver-ETRs locally replicate the 579 traffic to all Receiver-VPNs necessary. This replication is governed 580 by the Extranet Policy configured at the ETR. Thus, ITRs will 581 encapsulate the traffic with the Instance-ID for the VPN where the 582 Multicast Source resides. ETRs will receive traffic in the source 583 IID and replicate it to the Receiver VPNs per the Extranet Policy. 585 4.4. LISP Extranet SMR Considerations 587 Data driven SMRs MUST carry the IID for the VPNs of the receivers of 588 traffic. Data driven SMRs MAY carry the IID for the VPNs of senders 589 of traffic if the sender VPN IIDs are known by the ETR generating the 590 SMR. If the sender VPN's Instance-ID is not known, the ETR SHOULD 591 send the SMR to the RLOC of the sending ITR without the sender VPN's 592 IID. 594 The SMR MUST be replicated to all extranet VPNs that are defined in 595 the Extranet Policy and instantiated at the sending ITR. 597 When the IID of the sender VPN is known at the ETR, the ETR MAY 598 include the sender VPN's IID in the SMR and issue a separate SMR for 599 each sender VPN IID known to the ETR. Multicast optimizations could 600 be used to minimize the amount of traffic replicated when sending 601 these SMRs and potentially replicate only at the ITR. 603 When the IID of the sender VPN is not known at the ETR, the ETR 604 SHOULD issue a single SMR to each of the sending ITRs. The SMR will 605 then be replicated at the ITR to all extranet VPNs that are defined 606 in the Extranet Policy and instantiated at the sending ITR. 608 4.4.1. Home-IID inclusion in SMR messages 610 The Instance IDs relevant to the SMR signaling will be encoded in the 611 SMR Map-request message fields as follows: 613 Source-EID field: If known by the ETR, this field SHOULD carry the 614 instance-ID of the traffic source VPN at the ITR with the obsolete 615 map-cache. This is the IID of the senders of the traffic. 616 Otherwise, the Instance-ID in this field MUST be the same as the 617 Instance-ID of the destination VPN at the ETR generating the SMR. 619 EID-Prefix field: This field carries the Instance-ID of the 620 destination VPN at the ETR sending the SMR. This is the IID of the 621 receivers of the traffic. This field must always be set with the IID 622 of the receivers. 624 4.5. LISP Extranet RLOC Probing Considerations 626 RLOC Probes must be sent with the IID of the VPN originating the 627 probe. The XTR receiving the probe must identify the VPN for the 628 target EID. The XTR receiving the probe should run all verifications 629 as specified in [RFC6830] within the forwarding context corresponding 630 to the VPN where the target EID is connected. Once verifications are 631 completed, the reply to the probe should be sent in the IID of the 632 VPN that originated the probe. 634 5. Security Considerations 636 LISP [RFC 6830] incorporates many security mechanisms as part of the 637 mapping database service when using control-plane procedures for 638 obtaining EID-to-RLOC mappings. In general, data plane mechanisms 639 are not of primary concern for general Internet use-case. However, 640 when LISP VPNs are deployed, several additional security mechanisms 641 and considerations must be addressed. 643 Data plane traffic uses the LISP instance-id (IID) header field for 644 segmentation. in-flight modifications of this IID value could result 645 in violations to the tenant segmentation provided by the IID. 646 Protection against this attack can be achieved by using the integrity 647 protection mechanisms afforded by LISP Crypto, with or without 648 encryption depending on users' confidentiality requirements (see 649 below). 651 5.1. LISP VPNs and LISP Crypto 653 The procedures for data plane confidentiality in LISP are documented 654 in [RFC8061] and are primarily aimed at negotiating secret shared 655 keys between ITR and ETR in map-request and map-reply messages. 656 These secret shared keys are negotiated on a per RLOC basis and 657 without regard for any VPN segmentation done in the EID space. Thus, 658 multiple VPNs using a shared RLOC may also share a common secret key 659 to encrypt communications of the multiple VPNs. 661 It is possible to negotiate secret shared keys on a per EID basis by 662 applying the procedures described in [RFC8061] to RLOC probes. In a 663 VPN environment, RLOC probes would be aimed at Extended EIDs that 664 contain Instance-ID semantics, therefore resulting in the calculation 665 of different secret shared keys for different XEID. Since the keys 666 are calculated per XEID prefix rather than per VPN, there are scale 667 considerations when implementing this level of key negotiation 668 granularity. 670 6. IANA Considerations 672 This document has no IANA implications 674 7. Acknowledgements 676 The authors want to thank Marc Portoles, Vrushali Ashtaputre, Johnson 677 Leong, Jesus Arango, Prakash Jain, Sanjay Hooda, Alberto Rodriguez- 678 Natal, Darrel Lewis and Greg Schudel for their insightful 679 contribution to shaping the ideas in this document. 681 8. References 683 8.1. Normative References 685 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 686 Requirement Levels", BCP 14, RFC 2119, 687 DOI 10.17487/RFC2119, March 1997, 688 . 690 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 691 Discovery Protocol (MSDP)", RFC 3618, 692 DOI 10.17487/RFC3618, October 2003, 693 . 695 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 696 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 697 Protocol Specification (Revised)", RFC 4601, 698 DOI 10.17487/RFC4601, August 2006, 699 . 701 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 702 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 703 . 705 8.2. Informative References 707 [I-D.ietf-lisp-pubsub] 708 Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., 709 Cabellos-Aparicio, A., Barkai, S., Farinacci, D., 710 Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ 711 Subscribe Functionality for LISP", draft-ietf-lisp- 712 pubsub-02 (work in progress), November 2018. 714 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 715 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 716 October 2011, . 718 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 719 Locator/ID Separation Protocol (LISP)", RFC 6830, 720 DOI 10.17487/RFC6830, January 2013, 721 . 723 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 724 Locator/ID Separation Protocol (LISP) for Multicast 725 Environments", RFC 6831, DOI 10.17487/RFC6831, January 726 2013, . 728 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 729 Protocol (LISP) Map-Server Interface", RFC 6833, 730 DOI 10.17487/RFC6833, January 2013, 731 . 733 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 734 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 735 eXtensible Local Area Network (VXLAN): A Framework for 736 Overlaying Virtualized Layer 2 Networks over Layer 3 737 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 738 . 740 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 741 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 742 February 2017, . 744 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 745 (LISP) Data-Plane Confidentiality", RFC 8061, 746 DOI 10.17487/RFC8061, February 2017, 747 . 749 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 750 Smirnov, "Locator/ID Separation Protocol Delegated 751 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 752 May 2017, . 754 [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID 755 Separation Protocol (LISP) Multicast", RFC 8378, 756 DOI 10.17487/RFC8378, May 2018, 757 . 759 Authors' Addresses 761 Victor Moreno 762 Cisco Systems 763 170 Tasman Drive 764 San Jose, California 95134 765 USA 767 Email: vimoreno@cisco.com 769 Dino Farinacci 770 lispers.net 771 San Jose, CA 95120 772 USA 774 Email: farinacci@gmail.com