idnits 2.17.1 draft-ietf-lisp-6834bis-09.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 (August 31, 2021) is 968 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-36 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-30 -- Obsolete informational reference (is this intentional?): RFC 6834 (Obsoleted by RFC 9302) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Iannone 3 Internet-Draft Huawei 4 Obsoletes: 6834 (if approved) D. Saucez 5 Intended status: Standards Track INRIA 6 Expires: March 4, 2022 O. Bonaventure 7 Universite catholique de Louvain 8 August 31, 2021 10 Locator/ID Separation Protocol (LISP) Map-Versioning 11 draft-ietf-lisp-6834bis-09 13 Abstract 15 This document describes the LISP (Locator/ID Separation Protocol) 16 Map-Versioning mechanism, which provides in-packet information about 17 Endpoint ID to Routing Locator (EID-to-RLOC) mappings used to 18 encapsulate LISP data packets. The proposed approach is based on 19 associating a version number to EID-to-RLOC mappings and the 20 transport of such a version number in the LISP-specific header of 21 LISP-encapsulated packets. LISP Map-Versioning is particularly 22 useful to inform communicating Ingress Tunnel Routers (ITRs) and 23 Egress Tunnel Routers (ETRs) about modifications of the mappings used 24 to encapsulate packets. The mechanism is optional and transparent to 25 implementations not supporting this feature, since in the LISP- 26 specific header and in the Map Records, bits used for Map-Versioning 27 can be safely ignored by ITRs and ETRs that do not support or do not 28 want to use the mechanism. 30 This document obsoletes RFC 6834 "Locator/ID Separation Protocol 31 (LISP) Map-Versioning", which is the initial experimental 32 specifications of the mechanisms updated by this document. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on March 4, 2022. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 69 3. Definitions of Terms . . . . . . . . . . . . . . . . . . . . 4 70 4. EID-to-RLOC Map-Version Number . . . . . . . . . . . . . . . 4 71 4.1. The Null Map-Version . . . . . . . . . . . . . . . . . . 5 72 5. Dealing with Map-Version Numbers . . . . . . . . . . . . . . 6 73 5.1. Handling Destination Map-Version Number . . . . . . . . . 7 74 5.2. Handling Source Map-Version Number . . . . . . . . . . . 9 75 6. LISP Header and Map-Version Numbers . . . . . . . . . . . . . 9 76 7. Map Record and Map-Version . . . . . . . . . . . . . . . . . 10 77 8. Benefits and Case Studies for Map-Versioning . . . . . . . . 11 78 8.1. Map-Versioning and Unidirectional Traffic . . . . . . . . 11 79 8.2. Map-Versioning and Interworking . . . . . . . . . . . . . 12 80 8.2.1. Map-Versioning and Proxy-ITRs . . . . . . . . . . . . 12 81 8.2.2. Map-Versioning and LISP-NAT . . . . . . . . . . . . . 13 82 8.2.3. Map-Versioning and Proxy-ETRs . . . . . . . . . . . . 13 83 8.3. RLOC Shutdown/Withdraw . . . . . . . . . . . . . . . . . 13 84 8.4. Map-Version Additional Use Cases . . . . . . . . . . . . 14 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 86 10. Deployment Considerations . . . . . . . . . . . . . . . . . . 14 87 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 90 12.2. Informative References . . . . . . . . . . . . . . . . . 16 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 93 1. Introduction 95 This document describes the Map-Versioning mechanism used to provide 96 information on changes in the EID-to-RLOC (Endpoint ID to Routing 97 Locator) mappings used in the LISP (Locator/ID Separation Protocol 98 [I-D.ietf-lisp-rfc6830bis][I-D.ietf-lisp-rfc6833bis]) context to 99 perform packet encapsulation. The mechanism is totally transparent 100 to xTRs (Ingress and Egress Tunnel Routers) not supporting or not 101 using such functionality. 103 This document obsoletes [RFC6834], which is the initial experimental 104 specifications of the mechanisms updated by this document. 106 The basic mechanism is to associate a Map-Version number to each LISP 107 EID-to-RLOC mapping and transport such a version number in the LISP- 108 specific header. When a mapping changes, a new version number is 109 assigned to the updated mapping. A change in an EID-to-RLOC mapping 110 can be a modification in the RLOCs set such as addition, removal, or 111 change in priority or weight of one or more RLOCs. 113 When Map-Versioning is used, LISP-encapsulated data packets contain 114 the version number of the two mappings used to select the RLOCs in 115 the outer header (i.e., both source and destination RLOCs). These 116 version numbers are encoded in the 24 low-order bits of the first 117 longword of the LISP header and indicated by a specific bit in the 118 flags (first 8 high-order bits of the first longword of the LISP 119 header). Note that not all packets need to carry version numbers. 121 When an ITR (Ingress Tunnel Router) encapsulates a data packet, with 122 a LISP header containing the Map-Version numbers, it puts in the 123 LISP-specific header two version numbers: 125 1. The version number assigned to the mapping used to select the 126 source RLOC (contained in the EID-to-RLOC Database). 128 2. The version number assigned to the mapping used to select the 129 destination RLOC (contained in the EID-to-RLOC Map-Cache). 131 This operation is two-fold. On the one hand, it enables the ETR 132 (Egress Tunnel Router) receiving the packet to know if the ITR is 133 using the latest mapping version that any ETR at the destination EID 134 site would provide to the ITR in a Map-Reply. If this is not the 135 case, the ETR can send to the ITR a Map-Request containing the 136 updated mapping or solicit a Map-Request from the ITR (both cases are 137 already defined in [I-D.ietf-lisp-rfc6833bis]). In this way, the ITR 138 can update its EID-to-RLOC Map-Cache. On the other hand, it enables 139 an ETR receiving such a packet to know if it has in its EID-to-RLOC 140 Map-Cache the latest mapping for the source EID. If this is not the 141 case, a Map-Request can be sent. 143 Considerations about the deployment of LISP Map-Versioning are 144 discussed in Section 10. 146 2. Requirements Notation 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 150 "OPTIONAL" in this document are to be interpreted as described in BCP 151 14 [RFC2119] [RFC8174] when, and only when, they appear in all 152 capitals, as shown here. 154 3. Definitions of Terms 156 This document uses terms already defined in the main LISP 157 specification ([I-D.ietf-lisp-rfc6830bis], 158 [I-D.ietf-lisp-rfc6833bis]). Here, we define the terms that are 159 specific to the Map-Versioning mechanism. Throughout the whole 160 document, Big Endian bit ordering is used. 162 Map-Version number: An unsigned 12-bit integer is assigned to an 163 EID-to-RLOC mapping, excluding the value 0 (0x000). 165 Null Map-Version: The 12-bit null value of 0 (0x000) is not used as 166 a Map-Version number. It is used to signal that no Map-Version 167 number is assigned to the EID-to-RLOC mapping. 169 Source Map-Version number: This Map-Version number of the EID-to- 170 RLOC mapping is used to select the source address (RLOC) of the 171 outer IP header of LISP-encapsulated packets. 173 Destination Map-Version number: This Map-Version number of the EID- 174 to-RLOC mapping is used to select the destination address (RLOC) of 175 the outer IP header of LISP-encapsulated packets. 177 4. EID-to-RLOC Map-Version Number 179 The EID-to-RLOC Map-Version number consists of an unsigned 12-bit 180 integer. The version number is assigned on a per-mapping basis, 181 meaning that different mappings have a different version number, 182 which is also updated independently. An update in the version number 183 (i.e., a newer version) consists of incrementing by one the older 184 version number. 186 The space of version numbers has a circular order where half of the 187 version numbers are greater (i.e., newer) than the current Map- 188 Version number and the other half of the version numbers are smaller 189 (i.e., older) than the current Map-Version number. In a more formal 190 way, assuming that we have two version numbers V1 and V2 and that the 191 numbers are expressed on N bits, the following steps MUST be 192 performed (in the same order as shown below) to strictly define their 193 order: 195 1. V1 = V2 : The Map-Version numbers are the same. 197 2. V2 > V1 : if and only if 199 V2 > V1 AND (V2 - V1) <= 2**(N-1) 201 OR 203 V1 > V2 AND (V1 - V2) > 2**(N-1) 205 3. V1 > V2 : otherwise. 207 Using 12 bits, as defined in this document, and assuming a Map- 208 Version value of 69, Map-Version numbers in the range [70; 69 + 2048] 209 are greater than 69, while Map-Version numbers in the range [69 + 210 2049; (69 + 4096) mod 4096] are smaller than 69. 212 Map-version numbers are assigned to mappings by configuration. The 213 initial Map-Version number of a new EID-to-RLOC mapping SHOULD be 214 assigned randomly, but it MUST NOT be set to the Null Map-Version 215 value (0x000), because the Null Map-Version number has a special 216 meaning (see Section 4.1). 218 Upon reboot, an ETR will use mappings configured in its EID-to-RLOC 219 Database. If those mappings have a Map-Version number, it will be 220 used according to the mechanisms described in this document. ETRs 221 MUST NOT automatically generate and assign Map-Version numbers to 222 mappings in the EID-to-RLOC Database. 224 4.1. The Null Map-Version 226 The value 0x000 (zero) is not a valid Map-Version number indicating 227 the version of the EID-to-RLOC mapping. Such a value is used for 228 special purposes and is named the Null Map-Version number. 230 The Null Map-Version MAY appear in the LISP-specific header as either 231 a Source Map-Version number (cf. Section 5.2) or a Destination Map- 232 Version number (cf. Section 5.1). When the Source Map-Version 233 number is set to the Null Map-Version value, it means that no map 234 version information is conveyed for the source site. This means that 235 if a mapping exists for the source EID in the EID-to-RLOC Map-Cache, 236 then the ETR MUST NOT compare the received Null Map-Version with the 237 content of the EID-to-RLOC Map-Cache. When the Destination Map- 238 Version number is set to the Null Map-Version value, it means that no 239 map version information is conveyed for the destination site. This 240 means that the ETR MUST NOT compare the value with the Map-Version 241 number of the mapping for the destination EID present in the EID-to- 242 RLOC Database. 244 The other use of the Null Map-Version number is in the Map Records, 245 which are part of the Map-Request, Map-Reply, and Map-Register 246 messages (defined in [I-D.ietf-lisp-rfc6833bis]). Map Records that 247 have a Null Map-Version number indicate that there is no Map-Version 248 number associated with the mapping. This means that LISP- 249 encapsulated packets destined to the EID-Prefix referred to by the 250 Map Record MUST either not contain any Map-Version numbers (V bit set 251 to 0) or, if they contain Map-Version numbers (V bit set to 1), then 252 the destination Map-Version number MUST be set to the Null Map- 253 Version number. Any value different from zero means that Map- 254 Versioning is supported and MAY be used. 256 The fact that the 0 value has a special meaning for the Map-Version 257 number implies that, when updating a Map-Version number because of a 258 change in the mapping, if the next value is 0, then the Map-Version 259 number MUST be incremented by 2 (i.e., set to 1 (0x001), which is the 260 next valid value). 262 5. Dealing with Map-Version Numbers 264 The main idea of using Map-Version numbers is that whenever there is 265 a change in the mapping (e.g., adding/removing RLOCs, a change in the 266 weights due to Traffic Engineering policies, or a change in the 267 priorities) or a LISP site realizes that one or more of its own RLOCs 268 are not reachable anymore from a local perspective (e.g., through 269 IGP, or policy changes) the LISP site updates the mapping, also 270 assigning a new Map-Version number. 272 To each mapping, a version number is associated and changes each time 273 the mapping is changed. Note that Map-Versioning does not introduce 274 new problems concerning the coordination of different ETRs of a 275 domain. Indeed, ETRs belonging to the same LISP site must return for 276 a specific EID-prefix the same mapping, including the same Map- 277 Version number. This is orthogonal to whether or not Map-Versioning 278 is used. The synchronization problem and its implications on the 279 traffic are out of the scope of this document. 281 In order to announce in a data-driven fashion that the mapping has 282 been updated, Map-Version numbers used to create the outer IP header 283 of the LISP-encapsulated packet are embedded in the LISP-specific 284 header. This means that the header needs to contain two Map-Version 285 numbers: 287 o The Source Map-Version number of the EID-to-RLOC mapping in the 288 EID-to-RLOC Database used to select the source RLOC. 290 o The Destination Map-Version number of the EID-to-RLOC mapping in 291 the EID-to-RLOC Map-Cache used to select the destination RLOC. 293 By embedding both the Source Map-Version number and the Destination 294 Map-Version number, an ETR receiving a LISP packet with Map-Version 295 numbers can perform the following checks: 297 1. The ITR that has sent the packet has an up-to-date mapping in its 298 EID-to-RLOC Map-Cache for the destination EID and is performing 299 encapsulation correctly. 301 2. In the case of bidirectional traffic, the mapping in the local 302 ETR EID-to-RLOC Map-Cache for the source EID is up to date. 304 If one or both of the above conditions do not hold, the ETR can send 305 a Map-Request either to make the ITR aware that a new mapping is 306 available (see Section 5.1) or to update the mapping in the local 307 EID-to-RLOC Map-Cache (see Section 5.2). 309 5.1. Handling Destination Map-Version Number 311 When an ETR receives a packet, the Destination Map-Version number 312 relates to the mapping for the destination EID for which the ETR is 313 an RLOC. This mapping is part of the ETR EID-to-RLOC Database. 314 Since the ETR is authoritative for the mapping, it has the correct 315 and up-to-date Destination Map-Version number. A check on this 316 version number can be done, where the following cases can arise: 318 1. The packet arrives with the same Destination Map-Version number 319 stored in the EID-to-RLOC Database. This is the regular case. 320 The ITR sending the packet has in its EID-to-RLOC Map-Cache an 321 up-to-date mapping. No further actions are needed. 323 2. The packet arrives with a Destination Map-Version number greater 324 (i.e., newer) than the one stored in the EID-to-RLOC Database. 325 Since the ETR is authoritative on the mapping, meaning that the 326 Map-Version number of its mapping is the correct one, this 327 implies that someone is not behaving correctly with respect to 328 the specifications. In this case, the packet carries a version 329 number that is not valid; otherwise, the ETR would have the same 330 number, and the packet SHOULD be silently dropped. 332 3. The packets arrive with a Destination Map-Version number smaller 333 (i.e., older) than the one stored in the EID-to-RLOC Database. 334 This means that the ITR sending the packet has an old mapping in 335 its EID-to-RLOC Map-Cache containing stale information. The ETR 336 MAY choose to normally process the encapsulated datagram 337 according to [I-D.ietf-lisp-rfc6830bis]; however, the ITR sending 338 the packet has to be informed that a newer mapping is available. 339 This is done with a Map-Request message sent back to the ITR. 340 The Map-Request will either trigger a Map-Request back using the 341 Solicit-Map-Request (SMR) bit or it will piggyback the newer 342 mapping. These are not new mechanisms; how to use the SMR bit or 343 how to piggyback mappings in Map-Request messages is already 344 described in [I-D.ietf-lisp-rfc6833bis]. One feature introduced 345 by Map-Version numbers is the possibility of blocking traffic not 346 using the latest mapping. Indeed, after a certain number of 347 retries, if the Destination Map-Version number in the packets is 348 not updated, the ETR MAY drop packets with a stale Map-Version 349 number while limiting the rate of Map-Request messages. This is 350 because either the ITR is refusing to use the mapping for which 351 the ETR is authoritative, or (worse) it might be some form of 352 attack. 354 The rule in the third case MAY be more restrictive. If the mapping 355 has been the same for a period of time as long as the Time To Live 356 (TTL) (defined in [I-D.ietf-lisp-rfc6833bis]) of the previous version 357 of the mapping, all packets arriving with an old Map-Version SHOULD 358 be silently dropped right away without issuing any Map-Request. Such 359 action is permitted because if the new mapping with the updated 360 version number has been unchanged for at least the same time as the 361 TTL of the older mapping, all the entries in the EID-to-RLOC Map- 362 Caches of ITRs must have expired. Hence, all ITRs sending traffic 363 should have refreshed the mapping according to 364 [I-D.ietf-lisp-rfc6833bis]. If packets with old Map-Version numbers 365 are still received, then either someone has not respected the TTL or 366 it is a form of spoof/attack. In both cases, this is not valid 367 behavior with respect to the specifications and the packet SHOULD be 368 silently dropped. 370 LISP-encapsulated packets with the V-bit set, when the original 371 mapping in the EID-to-RLOC Database has the version number set to the 372 Null Map-Version value, MAY be silently dropped. As explained in 373 Section 4.1, if an EID-to-RLOC mapping has a Null Map-Version, it 374 means that ITRs, using the mapping for encapsulation, MUST NOT use a 375 Map-Version number in the LISP-specific header. 377 For LISP-encapsulated packets with the V-bit set, when the original 378 mapping in the EID-to-RLOC Database has the version number set to a 379 value different from the Null Map-Version value, a Destination Map- 380 Version number equal to the Null Map-Version value means that the 381 Destination Map-Version number MUST be ignored. 383 5.2. Handling Source Map-Version Number 385 When an ETR receives a packet, the Source Map-Version number relates 386 to the mapping for the source EID for which the ITR that sent the 387 packet is authoritative. If the ETR has an entry in its EID-to-RLOC 388 Map-Cache for the source EID, then a check can be performed and the 389 following cases can arise: 391 1. The packet arrives with the same Source Map-Version number as 392 that stored in the EID-to-RLOC Map-Cache. This is the correct 393 regular case. The ITR has in its EID-to-RLOC Map-Cache an up-to- 394 date copy of the mapping. No further actions are needed. 396 2. The packet arrives with a Source Map-Version number greater 397 (i.e., newer) than the one stored in the local EID-to-RLOC Map- 398 Cache. This means that the ETR has in its EID-to-RLOC Map-Cache 399 a stale mapping that needs to be updated. A Map-Request SHOULD 400 be sent to get the new mapping for the source EID. This is a 401 normal Map-Request message sent through the mapping system and 402 MUST respect the specifications in [I-D.ietf-lisp-rfc6833bis], 403 including rate-limitation policies. 405 3. The packet arrives with a Source Map-Version number smaller 406 (i.e., older) than the one stored in the local EID-to-RLOC Map- 407 Cache. Such a case is not valid with respect to the 408 specifications. Indeed, if the mapping is already present in the 409 EID-to-RLOC Map-Cache, this means that an explicit Map-Request 410 has been sent and a Map-Reply has been received from an 411 authoritative source. Assuming that the mapping system is not 412 corrupted, the Map-Version in the EID-to-RLOC Map-Cache is the 413 correct one, while the one carried by the packet is stale. In 414 this situation, the packet MAY be silently dropped. 416 If the ETR does not have an entry in the EID-to-RLOC Map-Cache for 417 the source EID, then the Source Map-Version number can be ignored. 419 For LISP-encapsulated packets with the V-bit set, if the Source Map- 420 Version number is the Null Map-Version value, it means that the 421 Source Map-Version number MUST be ignored. 423 6. LISP Header and Map-Version Numbers 425 In order for the versioning approach to work, the LISP-specific 426 header has to carry both the Source Map-Version number and 427 Destination Map-Version number. This is done by setting the V-bit in 428 the LISP-specific header as specified in [I-D.ietf-lisp-rfc6830bis]. 429 When the V-bit is set and the N bit is reset (0), the low-order 24 430 bits of the first longword are used to transport both the source and 431 destination Map-Version numbers. In particular, the first 12 bits 432 are used for the Source Map-Version number and the second 12 bits for 433 the Destination Map-Version number. 435 Below is an example of a LISP header carrying version numbers. 437 0 1 2 3 438 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 / |N|L|E|V|I|R|K|K| Source Map-Version |Destination Map-Version| 441 LISP+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 \ | Instance ID/Locator Status Bits | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 Source Map-Version number (12 bits): Map-Version of the mapping used 446 by the ITR to select the RLOC present in the "Source Routing 447 Locator" field. Section 5.2 describes how to set this value on 448 transmission and handle it on reception. 450 Destination Map-Version number (12 bits): Map-Version of the mapping 451 used by the ITR to select the RLOC present in the "Destination 452 Routing Locator" field. Section 5.1 describes how to set this 453 value on transmission and handle it on reception. 455 Not all of the LISP-encapsulated packets need to carry version 456 numbers. When Map-Version numbers are carried, the V-bit MUST be set 457 to 1. All permissible combinations of the flags when the V-bit is 458 set to 1 are described in [I-D.ietf-lisp-rfc6830bis]. 460 7. Map Record and Map-Version 462 To accommodate the proposed mechanism, the Map Records that are 463 transported in Map-Request/Map-Reply/Map-Register messages need to 464 carry the Map-Version number as well. For this purpose, the 12 bits 465 before the EID-AFI field in the Record that describes a mapping are 466 used (see [I-D.ietf-lisp-rfc6833bis] and reported here as an example. 468 0 1 2 3 469 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 470 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | | Record TTL | 472 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 R | Locator Count | EID mask-len | ACT |A| Reserved | 474 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 476 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 r | EID-Prefix | 478 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | /| Priority | Weight | M Priority | M Weight | 480 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | o | Unused Flags |L|p|R| Loc-AFI | 482 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | \| Locator | 484 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Map-Version Number: Map-Version of the mapping contained in the 487 Record. As explained in Section 4.1, this field can be zero (0), 488 meaning that no Map-Version is associated to the mapping; hence, 489 packets that are LISP encapsulated using this mapping MUST NOT 490 contain Map-Version numbers in the LISP-specific header, and the 491 V-bit MUST be set to 0. 493 This packet format works perfectly with xTRs that do not support Map- 494 Versioning, since they can simply ignore those bits. 496 8. Benefits and Case Studies for Map-Versioning 498 In the following sections, we provide more discussion on various 499 aspects and uses of Map-Versioning. Security observations are 500 grouped in Section 9. 502 8.1. Map-Versioning and Unidirectional Traffic 504 When using Map-Versioning, the LISP-specific header carries two Map- 505 Version numbers, for both source and destination mappings. This can 506 raise the question on what will happen in the case of unidirectional 507 flows, for instance, in the case presented in Figure 1, since the 508 LISP specification does not mandate that the ETR have a mapping for 509 the source EID. 511 +-----------------+ +-----------------+ 512 | Domain A | | Domain B | 513 | +---------+ +---------+ | 514 | | ITR A |----------->| ETR B | | 515 | +---------+ +---------+ | 516 | | | | 517 +-----------------+ +-----------------+ 519 Figure 1: Unidirectional traffic between LISP domains. 521 In the case of the ITR, the ITR is able to put both the source and 522 destination version number in the LISP header, since the Source Map- 523 Version number is in the ITR's database, while the Destination Map- 524 Version number is in the ITR's cache. 526 In the case of the ETR, the ETR simply checks only the Destination 527 Map-Version number in the same way as that described in Section 5, 528 ignoring the Source Map-Version number. 530 8.2. Map-Versioning and Interworking 532 Map-Versioning is compatible with the LISP interworking between LISP 533 and non-LISP sites as defined in [RFC6832]. LISP interworking 534 defines three techniques to make LISP sites and non-LISP sites, 535 namely Proxy-ITR, LISP-NAT, and Proxy-ETR. The following text 536 describes how Map-Versioning relates to these three mechanisms. 538 8.2.1. Map-Versioning and Proxy-ITRs 540 The purpose of the Proxy-ITR (PITR) is to encapsulate traffic 541 originating in a non-LISP site in order to deliver the packet to one 542 of the ETRs of the LISP site (cf. Figure 2). This case is very 543 similar to the unidirectional traffic case described in Section 8.1; 544 hence, similar rules apply. 546 +----------+ +-------------+ 547 | LISP | | non-LISP | 548 | Domain A | | Domain B | 549 | +-------+ +-----------+ | | 550 | | ETR A |<-------| Proxy ITR |<-------| | 551 | +-------+ +-----------+ | | 552 | | | | 553 +----------+ +-------------+ 555 Figure 2: Unidirectional traffic from non-LISP domain to LISP domain. 557 The main difference is that a Proxy-ITR does not have any mapping, 558 since it just encapsulates packets arriving from the non-LISP site, 559 and thus cannot provide a Source Map-Version. In this case, the 560 proxy-ITR will just put the Null Map-Version value as the Source Map- 561 Version number, while the receiving ETR will ignore the field. 563 With this setup, LISP Domain A is able to check whether or not the 564 PITR is using the latest mapping. 566 8.2.2. Map-Versioning and LISP-NAT 568 The LISP-NAT mechanism is based on address translation from non- 569 routable EIDs to routable EIDs and does not involve any form of 570 encapsulation. As such, Map-Versioning does not apply in this case. 572 8.2.3. Map-Versioning and Proxy-ETRs 574 The purpose of the Proxy-ETR (PETR) is to decapsulate traffic 575 originating in a LISP site in order to deliver the packet to the non- 576 LISP site (cf. Figure 3). One of the main reasons to deploy PETRs 577 is to bypass uRPF (Unicast Reverse Path Forwarding) checks on the 578 provider edge. 580 +----------+ +-------------+ 581 | LISP | | non-LISP | 582 | Domain A | | Domain B | 583 | +-------+ +-----------+ | | 584 | | ITR A |------->| Proxy ETR |------->| | 585 | +-------+ +-----------+ | | 586 | | | | 587 +----------+ +-------------+ 589 Figure 3: Unidirectional traffic from LISP domain to non-LISP domain. 591 A Proxy-ETR does not have any mapping, since it just decapsulates 592 packets arriving from the LISP site. In this case, the ITR will just 593 put the Null Map-Version value as the Destination Map-Version number, 594 while the receiving Proxy-ETR will ignore the field. 596 With this setup, the Proxy-ETR is able to check whether or not the 597 mapping has changed. 599 8.3. RLOC Shutdown/Withdraw 601 Map-Versioning can also be used to perform a graceful shutdown or 602 withdraw of a specific RLOC. This is achieved by simply issuing a 603 new mapping, with an updated Map-Version number where the specific 604 RLOC to be shut down is withdrawn or announced as unreachable (via 605 the R bit in the Map Record; see [I-D.ietf-lisp-rfc6833bis]), but 606 without actually turning it off. 608 Once no more traffic is received by the RLOC, it can be shut down 609 gracefully, because all sites actively using the mapping have updated 610 it. 612 8.4. Map-Version Additional Use Cases 614 The use of Map-Versioning can help in developing a lightweight 615 implementation of LISP. However, this comes with the price of not 616 supporting the Loc Status Bit, which may be useful in some contexts. 618 In the current LISP specifications, the set of RLOCs must always be 619 maintained ordered and consistent with the content of the Loc Status 620 Bits ([I-D.ietf-lisp-rfc6830bis]). When a new RLOC is added to a 621 mapping, a new mapping with a new Map-Version number will be issued, 622 and since the old locators are still valid, the transition will occur 623 with no disruptions. The same applies for the case where an RLOC is 624 withdrawn. The use of Map-Versioning allows to avoiding using the 625 "use-LSB" timer (cf. [I-D.ietf-lisp-rfc6830bis]) since it allows to 626 check whether or not the mapping has been updated. 628 9. Security Considerations 630 Attackers can try to trigger a large number of Map-Requests by simply 631 forging packets with random Map-Versions. The Map-Requests are rate- 632 limited as described in [I-D.ietf-lisp-rfc6833bis]. With Map- 633 Versioning it is possible to filter invalid version numbers before 634 triggering a Map-Request, thus helping to reduce the effects of DoS 635 attacks. However, it might not be enough to really protect from a 636 DDoS attack. 638 Robustness of the Map-Versioning mechanism leverages on a trusted 639 Mapping Distribution System. A thorough security analysis of LISP is 640 documented in [RFC7835]. 642 As specified in [I-D.ietf-lisp-rfc6830bis], Map-Versioning MUST NOT 643 be used over the public Internet and SHOULD only be used in trusted 644 and closed deployments. 646 10. Deployment Considerations 648 Even without Map-Versioning, LISP requires ETRs to announce the same 649 mapping for the same EID-Prefix to a requester. Map-Versioning does 650 not require additional synchronization mechanisms as compared to the 651 normal functioning of LISP without Map-Versioning. Clearly, all the 652 ETRs have to reply with the same Map-Version number; otherwise, there 653 can be an inconsistency that creates additional control traffic, 654 instabilities, and traffic disruptions. It is the same without Map- 655 Versioning, with ETRs that have to reply with the same mapping; 656 otherwise, the same problems arise. 658 There are two ways Map-Versioning is helpful with respect to the 659 synchronization problem. On the one hand, assigning version numbers 660 to mappings helps in debugging, since quick checks on the consistency 661 of the mappings on different ETRs can be done by looking at the Map- 662 Version number. On the other hand, Map-Versioning can be used to 663 control the traffic toward ETRs that announce the latest mapping. 665 As an example, let's consider the topology of Figure 4 where ITR A.1 666 of Domain A is sending unidirectional traffic to Domain B, while A.2 667 of Domain A exchanges bidirectional traffic with Domain B. In 668 particular, ITR A.2 sends traffic to ETR B, and ETR A.2 receives 669 traffic from ITR B. 671 +-----------------+ +-----------------+ 672 | Domain A | | Domain B | 673 | +---------+ | | 674 | | ITR A.1 |--- | | 675 | +---------+ \ +---------+ | 676 | | ------->| ETR B | | 677 | | ------->| | | 678 | +---------+ / | | | 679 | | ITR A.2 |--- -----| ITR B | | 680 | | | / +---------+ | 681 | | ETR A.2 |<----- | | 682 | +---------+ | | 683 | | | | 684 +-----------------+ +-----------------+ 686 Figure 4: Example topology. 688 Obviously, in the case of Map-Versioning, both ITR A.1 and ITR A.2 of 689 Domain A must use the same value; otherwise, the ETR of Domain B will 690 start to send Map-Requests. 692 The same problem can, however, arise without Map-Versioning, for 693 instance, if the two ITRs of Domain A send different Locator Status 694 Bits. In this case, either the traffic is disrupted if ETR B trusts 695 the Locator Status Bits, or if ETR B does not trust the Locator 696 Status Bits it will start sending Map-Requests to confirm each change 697 in reachability. 699 So far, LISP does not provide any specific synchronization mechanism 700 but assumes that synchronization is provided by configuring the 701 different xTRs consistently. The same applies for Map-Versioning. 702 If in the future any synchronization mechanism is provided, Map- 703 Versioning will take advantage of it automatically, since it is 704 included in the Record format, as described in Section 7. 706 11. IANA Considerations 708 This document includes no request to IANA. 710 12. References 712 12.1. Normative References 714 [I-D.ietf-lisp-rfc6830bis] 715 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 716 Cabellos-Aparicio, "The Locator/ID Separation Protocol 717 (LISP)", draft-ietf-lisp-rfc6830bis-36 (work in progress), 718 November 2020. 720 [I-D.ietf-lisp-rfc6833bis] 721 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- 722 Aparicio, "Locator/ID Separation Protocol (LISP) Control- 723 Plane", draft-ietf-lisp-rfc6833bis-30 (work in progress), 724 November 2020. 726 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 727 Requirement Levels", BCP 14, RFC 2119, 728 DOI 10.17487/RFC2119, March 1997, 729 . 731 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 732 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 733 May 2017, . 735 12.2. Informative References 737 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 738 "Interworking between Locator/ID Separation Protocol 739 (LISP) and Non-LISP Sites", RFC 6832, 740 DOI 10.17487/RFC6832, January 2013, 741 . 743 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 744 Separation Protocol (LISP) Map-Versioning", RFC 6834, 745 DOI 10.17487/RFC6834, January 2013, 746 . 748 [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID 749 Separation Protocol (LISP) Threat Analysis", RFC 7835, 750 DOI 10.17487/RFC7835, April 2016, 751 . 753 Authors' Addresses 755 Luigi Iannone 756 Huawei Technologies France S.A.S.U 758 EMail: luigi.iannone@huawei.com 760 Damien Saucez 761 INRIA 763 EMail: damien.saucez@inria.fr 765 Olivier Bonaventure 766 Universite catholique de Louvain 768 EMail: olivier.bonaventure@uclouvain.be