idnits 2.17.1 draft-iannone-lisp-mapping-versioning-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 8, 2010) is 5135 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-24) exists of draft-ietf-lisp-06 == Outdated reference: A later version (-10) exists of draft-ietf-lisp-alt-02 == Outdated reference: A later version (-06) exists of draft-ietf-lisp-interworking-00 == Outdated reference: A later version (-16) exists of draft-ietf-lisp-ms-04 == Outdated reference: A later version (-16) exists of draft-meyer-lisp-mn-01 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Iannone 3 Internet-Draft TU Berlin - Deutsche Telekom 4 Intended status: Experimental Laboratories AG 5 Expires: September 9, 2010 D. Saucez 6 O. Bonaventure 7 Universite catholique de Louvain 8 March 8, 2010 10 LISP Mapping Versioning 11 draft-iannone-lisp-mapping-versioning-01.txt 13 Abstract 15 The present document sketches an optional approach to provide in- 16 packet information about EID-to-RLOC mappings used to encapsulate 17 LISP data packets. The proposed approach is based on associating a 18 version number to EID-to-RLOC mappings and transport such a version 19 number in the LISP specific header of LISP-encapsulated packets. 20 This versioning approach is particularly useful to inform 21 communicating xTRs about modification of the mappings used to 22 encapsulate packets. Modification of mappings could mean adding/ 23 removing an RLOC, or just a modification in the reachability, 24 priority, or weight of one or more RLOCs. Each time a mapping is 25 modified, a new version number is generated and propagated in the 26 LISP data packet. The use of version numbers allows to avoid 27 repeated Map-Request upon mappings change, limits the interaction 28 between Control and Data planes, improves security, offer support for 29 caching on Map-Servers, and could be used also in mobile scenarios. 31 The proposed mechanism is optional and does not need any modification 32 on the base LISP encapsulation. Rather, it uses one of the reserved 33 bits of the LISP specific header and overloads the Locator Status 34 Bits. Similarly, no modification are necessary in the base LISP Map- 35 Reply records. LISP versioning uses part of the reserved bits. In 36 both cases, LISP encapsulation and Map-Reply records, bits used for 37 LISP versioning can be safely ignored by xTRs that do not support the 38 mechanism. Further, mappings can be distributed as usual through 39 both existing and future mapping distribution system (e.g., ALT). 40 The infrastructure build by each specific mapping distribution system 41 does not change anyhow. Even more, existing mapping distribution 42 protocol are able to rely LISP control plane packets containing 43 version numbers and do not need modifications. All of these features 44 make LISP versioning a completely transparent optional mechanism with 45 respect to the LISP base specification. 47 Status of this Memo 48 This Internet-Draft is submitted to IETF in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF), its areas, and its working groups. Note that 53 other groups may also distribute working documents as Internet- 54 Drafts. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 The list of current Internet-Drafts can be accessed at 62 http://www.ietf.org/ietf/1id-abstracts.txt. 64 The list of Internet-Draft Shadow Directories can be accessed at 65 http://www.ietf.org/shadow.html. 67 This Internet-Draft will expire on September 9, 2010. 69 Copyright Notice 71 Copyright (c) 2010 IETF Trust and the persons identified as the 72 document authors. All rights reserved. 74 This document is subject to BCP 78 and the IETF Trust's Legal 75 Provisions Relating to IETF Documents 76 (http://trustee.ietf.org/license-info) in effect on the date of 77 publication of this document. Please review these documents 78 carefully, as they describe your rights and restrictions with respect 79 to this document. Code Components extracted from this document must 80 include Simplified BSD License text as described in Section 4.e of 81 the Trust Legal Provisions and are provided without warranty as 82 described in the BSD License. 84 Table of Contents 86 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 87 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 88 3. EID-to-RLOC Mapping Version Number . . . . . . . . . . . . . . 7 89 3.1. Mapping Version Numbers wrap-around . . . . . . . . . . . 7 90 4. Dealing with Version Numbers . . . . . . . . . . . . . . . . . 9 91 4.1. Handling Destination Mapping Version Number . . . . . . . 9 92 4.2. Handling Source Mapping Version Number . . . . . . . . . . 10 93 5. LISP header and Mapping Version Numbers . . . . . . . . . . . 12 94 6. Map Record and Mapping Version Number . . . . . . . . . . . . 14 95 7. Benefits and case studies for Mapping Versioning . . . . . . . 15 96 7.1. Mapping Versioning to simplify LISP implementation . . . . 15 97 7.2. Synchronization of different xTRs . . . . . . . . . . . . 15 98 7.3. Map Versioning and unidirectional traffic . . . . . . . . 16 99 7.4. Mapping Versioning and interworking . . . . . . . . . . . 17 100 7.5. Mapping Versioning vs. Checksum . . . . . . . . . . . . . 17 101 7.6. Mapping Versioning and mobility . . . . . . . . . . . . . 17 102 8. Incremental deployment and implementation status . . . . . . . 19 103 9. Mapping Versioning and path-liveness . . . . . . . . . . . . . 20 104 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 105 10.1. Mapping Versioning against traffic disruption . . . . . . 21 106 10.2. Mapping Versioning against reachability information DoS . 21 107 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 108 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 109 12.1. Normative References . . . . . . . . . . . . . . . . . . . 24 110 12.2. Informative References . . . . . . . . . . . . . . . . . . 24 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 113 1. Requirements notation 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 2. Introduction 121 The present document introduces the use of version numbers in order 122 to provide information on a change in the EID-to-RLOC mappings used 123 in the LISP ([I-D.ietf-lisp] ) context to perform encapsulation. The 124 mechanism is optional and totally transparent to xTRs not supporting 125 such a functionality. The basic mechanism is to associate version 126 numbers to each mapping and transport such a version number in the 127 LISP specific header. When a mapping changes, a new version number 128 is assigned to the updated mapping. A change in an EID-to-RLOC 129 mapping can be a change in the RLOCs set, by adding or removing one 130 or more RLOCs, but it can also be a change in the priority or weight 131 of one or more RLOCs. The change can even consist in the 132 reachability of one or more RLOCs. Reachability information is 133 intended from the local-domain perspective, and can be obtained for 134 instance monitoring IGP's routing tables. This should not be 135 confused with the intra-domain "Locator Path Liveness problem" 136 described in [I-D.meyer-loc-id-implications]. 138 With this approach, LISP-encapsulated data packets contain the 139 version number of the mappings used to select the RLOCs in the outer 140 header (both source and destination). These version numbers are 141 contained in the second 32-bits of the LISP header and indicated a 142 specific bit in the reserved flags (first 8 bits of the LISP header. 143 Details about the header are described in Section 5. Note that it is 144 not all packets need to carry version numbers. 146 When an ITR encapsulates a packet, it puts in the LISP-specific 147 header two version numbers: 149 1. The version number assigned to the mapping (contained in the EID- 150 to-RLOC Database) used to select the source RLOC. 152 2. The version number assigned to the mapping (contained in the EID- 153 to-RLOC Cache) used to select the destination RLOC. 155 This operation is two-fold. On the one hand it enables the ETR 156 receiving the packet to know if the ITR that sent it is using the 157 latest mapping for the destination EID. If it is not the case the 158 ETR can send to the ITR a Map-Request containing the updated mapping 159 or invoking a Map-Request from the ITR (both cases are already 160 defined in [I-D.ietf-lisp]). In this way the ITR can update its 161 cache. On the other hand, it enables the ETR receiving the packet to 162 know if it has in its cache the latest mapping for the source EID. 163 Is it is not the case a Map-Request can be send. 165 With Mapping Versioning there is no need to re-design the mapping 166 distribution infrastructure, which is always done through the mapping 167 distribution protocol (e.g., CONS, TREE, ALT [I-D.ietf-lisp-alt]). 168 The mappings are distributed as usual through the Map-Request/ 169 Map-Reply message exchange. Map-Request and Map-Reply messages can 170 carry mapping version in bits that are reserved (in the current 171 version of the LISP specifications). Details on how to carry mapping 172 version numbers in those messages are given in section Section 6. 174 3. EID-to-RLOC Mapping Version Number 176 The EID-to-RLOC Mapping Version Number consist in an unsigned 16-bit 177 integer. The version number is assigned in a per-mapping fashion, 178 meaning that different mappings will have assigned a different 179 version number, which is also updated independently. An update in 180 the version number (i.e., a newer version) consist in incrementing by 181 one the older version number. The initial version number of a new 182 mapping can be randomly generated. 184 The space of version numbers has a circular order where half of the 185 version numbers is greater than the current mapping version number 186 and the other half is smaller than current mapping version number. 187 In a more formal way, assuming we have two version numbers V1 and V2 188 and that the numbers are expressed on N bits, the following three 189 cases may happen: 191 V1 = V2 : This is the exact match case. 193 V1 < V2 : True if and only if V1 < V2 < (V1 + 2**(N-1)). 195 V1 > V2 : True if and only if V1 > V2 > (V1 - 2**(N-1)). 197 Using 16 bits, as proposed in this document, and if the Mapping 198 Version Number is 0, versions in [1; (2**15)-1] are greater and 199 versions in [2**15; (2**16)-1] are smaller. 201 3.1. Mapping Version Numbers wrap-around 203 The proposed 16 bits size for the Mapping Version Number based on the 204 assumption that Map-Requests are rate limited with a granularity of 205 seconds. Using a granularity of seconds and assuming as worst case 206 that a new version is issued each second, it takes around 18 hours 207 before the versions wraps around, which is a reasonable time. 208 Alternatively a granularity of minutes can also be used, as for the 209 TTL of the Map-Reply ([I-D.ietf-lisp]). Using a granularity of 210 minutes leads to very long time before wrap-around. Hereafter there 211 is a table with a rough estimation of the time before wrap-around 212 happens considering different sizes of the Mapping Version Number and 213 different time granularity. 215 +---------------+--------------------------------------------+ 216 |Version Number | Time before wrap around | 217 | Size (bits) +--------------------------------------------+ 218 | |Granularity: Minutes | Granularity: Seconds | 219 +------------------------------------------------------------+ 220 | 32 | 8171 Years | 136 Years | 221 | 30 | 2042 Years | 34 Years | 222 | 24 | 31 Years | 194 Days | 223 | 16 | 45 Days | 18 Hours | 224 | 15 | 22 Days | 9 Hours | 225 | 14 | 11 Days | 4 Hours | 226 +---------------+---------------------+----------------------+ 228 Figure 1: Estimation of time before wrap-around 230 4. Dealing with Version Numbers 232 The main idea of using Mapping Version Numbers is that whenever there 233 is a change in the mapping (e.g., adding/removing RLOCs, a change in 234 the weights due to new TE policies, or a change in the priorities) or 235 an ISP realizes that one or more of its own RLOCs are not reachable 236 anymore from a local perspective (e.g., through IGP, or policy 237 changes) the ISP updates the mapping with a new mapping version 238 number. 240 In order to announce in a data-driven fashion that the mapping has 241 been updated, mapping version numbers used to create the outer IP 242 header of the LISP encapsulated packet are embedded in the LISP 243 specific header. This means that the header needs to contain two 244 mapping version numbers: 246 o A first one from the EID-to-RLOC mapping in the EID-to-RLOC 247 Database used to select the source RLOC, and called Source Mapping 248 Version Number. 250 o A second one from the EID-to-RLOC mapping in the EID-to-RLOC Cache 251 used to select the destination RLOC, and called Destination 252 Mapping Version Number. 254 By embedding both Source Mapping Version Number and Destination 255 Mapping Version Number an ETR can perform the following checks: 257 1. The ITR has an up-to-date mapping in its cache for the 258 destination EID and is performing encapsulation correctly. 260 2. The mapping in the local ETR cache for the source EID is up-to- 261 date. 263 If one or both of the above conditions do not hold, the ETR can send 264 a Map-Request either to make the ITR aware that a new mapping is 265 available (see Section 4.1) or to updated local mapping in the cache 266 (see section Section 4.2). 268 4.1. Handling Destination Mapping Version Number 270 When an ETR receives a packet, the Destination Mapping Version Number 271 relates to the mapping for the destination EID for which the ETR is a 272 RLOC. This mapping is part of the ETR LISP Database. Since the ETR 273 is authoritative for the mapping, it has the correct and up-to-date 274 Destination Mapping Version Number. A check on this version number 275 is done, where the following cases can arise: 277 o The packets arrive with the same Destination Mapping Version 278 Number stored in the EID-to-RLOC Database. This is the regular 279 case. The ITR sending the packet has in its EID-to-RLOC Cache an 280 up-to-date mapping. No further actions are needed. 282 o The packet arrives with a Destination Mapping Version Number 283 greater (i.e., newer) than the one stored in the EID-to-RLOC 284 Database. Since the ETR is authoritative on the mapping, this 285 means that someone is not behaving correctly w.r.t. the 286 specifications, thus the packets carries a not valid version 287 number and can be silently dropped. 289 o The packets arrive with an Destination Mapping Version Number 290 smaller (i.e., older) than the one stored in the EID-to-RLOC 291 Database. This means that the ITR sending the packet has an old 292 mapping in its EID-to-RLOC Cache containing stale information. 293 Further actions are needed. The ITR sending the packet must be 294 informed that a newer mapping is available. This is done with a 295 "Map-Request" message sent back to the ITR. The Map-Request will 296 piggy-back the newer mapping. This is not a new mechanism, how to 297 piggy-back mappings in Map-Request messages is already described 298 in [I-D.ietf-lisp]. These Map-Request message should be rate 299 limited (rate limitation policies are also described in 300 [I-D.ietf-lisp]). The gain introduced by Mapping Version Numbers 301 is that after a certain number of retries, if the Destination 302 Mapping Version Number in the packets is not updated, packet can 303 be silently dropped because either the ITR is refusing to use the 304 mapping for which the ETR is authoritative or it might be some 305 form of attack. Note that the rule can be even more restrictive. 306 If the mapping has been the same for a period of time as long as 307 the TTL (defined in LISP [I-D.ietf-lisp]) of the previous version 308 of the mapping, all packets arriving with an old mapping version 309 can be silently dropped right away without issuing any Map- 310 Request. Indeed, if the new mapping with the updated version 311 number has been stable for at least the same time as the TTL of 312 the older mapping, all the entries in the caches of ITRs must have 313 expired. If packets with old mapping version number are still 314 received, the reason is that either someone has not respected the 315 TTL, or it is a spoof. In both cases this is not valid behavior 316 w.r.t. the specifications and the packet can be silently dropped. 318 4.2. Handling Source Mapping Version Number 320 When an ETR receives a packet, the Source Mapping Version Number 321 relates to the mapping for the source EID for which the ITR is 322 authoritative. If the ETR has an entry in its LISP Cache a check is 323 performed and the following cases can arise: 325 o The packet arrives with the same Source Mapping Version Number 326 stored in the LISP Cache. This is the correct regular case. The 327 ETR has in its cache an up-to-date copy of the mapping. No 328 further actions are needed. 330 o The packet arrives with a Source Mapping Version Number greater 331 (i.e., newer) than the one stored in the local LISP Cache. This 332 means that ETR has in its cache a mapping that is stale and needs 333 to be updated. The packet is considered valid but further actions 334 are needed. In particular a Map-Request must be sent to get the 335 new mapping for the source EID. This is a normal Map-Request 336 message and must respect the specifications in [I-D.ietf-lisp]. 338 o The packet arrives with a Source Mapping Version Number smaller 339 (i.e., older) than the one stored in the local LISP Cache. Such a 340 case is not valid w.r.t. the specifications. Indeed, if the 341 mapping is already present in the LISP Cache, this means that an 342 explicit Map-Request has been send and a Map-Reply has been 343 received from an authoritative source. Assuming that the mapping 344 system is not corrupted anyhow, the mapping version in the LISP 345 Cache is the correct one, hence the packet is not valid and can be 346 silently dropped. 348 5. LISP header and Mapping Version Numbers 350 In order for the versioning approach to work, the LISP specific 351 header has to carry both Source Mapping Version Number and 352 Destination Mapping Version Number. This can be done by using one 353 bit (indicated by V) of the reserved flags to state that the second 354 32 bits of the LISP header have to be interpreted as two version 355 numbers of 16 bits each. The Source Version Number is carried in the 356 16 most significant bits of the second 32-bits of the LISP header. 357 The Destination Version Number is carried in the 16 most significant 358 bits of the second 32-bits of the LISP header. 360 Hereafter is the example of LISP header carrying version numbers in 361 the case of IPv4-in-IPv4 encapsulation. The same setting can be used 362 for any other case (IPv4-in-IPv6, IPv6-in-IPv4, IPv6-in-IPv6). 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 /|Version| IHL |Type of Service| Total Length | 368 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 / | Identification |Flags| Fragment Offset | 370 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 OH | Time to Live | Protocol = 17 | Header Checksum | 372 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 \ | Source Routing Locator | 374 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 \| Destination Routing Locator | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 / | Source Port = xxxx | Dest Port = 4341 | 378 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 \ | UDP Length | UDP Checksum | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 / |N|L|E|V| rflags| Nonce | 382 LISP+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 \ | Source Mapping V.N. | Destination Mapping V.N. | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 /|Version| IHL |Type of Service| Total Length | 386 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 / | Identification |Flags| Fragment Offset | 388 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 IH | Time to Live | Protocol | Header Checksum | 390 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 \ | Source EID | 392 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 \| Destination EID | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 V: this is the Versioning bit. When this bit is set to 1 the second 397 32-bits of the LISP header contain version numbers. 399 Source Mapping Version Number (16 bits): Version of the mapping used 400 by the ITR to select the RLOC present in the "Source Routing 401 Locator" field. Note that the mapping used for such a selection 402 is determined by the Source EID through asearch in the LISP 403 Database of the ITR. 405 Destination Mapping Version Number (16 bits): Version of the mapping 406 used by the ITR to select the RLOC present in the "Destination 407 Routing Locator" field. Note that the mapping used for such a 408 selection is determined by the Destination EID, used as lookup key 409 in the LISP Cache of the ITR. 411 Not all of the LISP encapsulated packets need to carry version 412 numbers. When mapping version number are carried the V bit must be 413 set to 1. The V bit is conflict with the L bit, since both relate to 414 the second 32 bits of the LISP header. The possible combinations 415 (and related meaning) for L and V bits are the following: 417 L=0, V=0: This is a valid combination. In this case neither 418 Locator-Status-Bits nor Version Number are used. The second 32 419 bits of the LISP header can be ignored. 421 L:0 V:1 This is a valid combination. In this case the second 32 422 bits of the LISP header contain version numbers and should be 423 treated according to the present document. 425 L:1 V:1 This is no a valid combination since two different bits 426 indicate different content for the same 32 bits. For 427 compatibility with the LISP specifications ([I-D.ietf-lisp]) each 428 time the the L bit is set to 1 the V bit must be ignored and the 429 second 32 bits of the LISP header interpreted as Locator-Status- 430 Bits. This approach ensures transparent and coherent 431 interoperability between xTRs using Versioning and xTRs that do 432 not use it. 434 L:1 V:0 This is a valid combination. In this case the second 32 435 bits of the LISP header contain Locator-Status-Bit. Note that 436 according with the previous combination, since the L bit is set to 437 1 the V bit can be safely ignored. 439 6. Map Record and Mapping Version Number 441 To accommodate the proposed mechanism, the Map records that are 442 transported on Map-Request/Map-Reply messages need to carry the 443 Mapping Version Number as well. For this purpose it is possible to 444 use part of the reserved bits of the record. The original definition 445 of Record is in [I-D.ietf-lisp]. 447 0 1 2 3 448 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 449 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | | Record TTL | 451 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 R | Locator Count | EID mask-len | ACT |A|V| Reserved | 453 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 c | Mapping Version Number | EID- AFI | 455 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 r | EID-prefix | 457 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | /| Priority | Weight | M Priority | M Weight | 459 | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 |Loc| Unused Flags |R| Loc-AFI | 461 | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | \| Locator | 463 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 Mapping Version Number: Version Number of the mapping in the Record. 467 This is a simple change to carry the version number assigned to the 468 mapping in this message and works perfectly with xTR that do not 469 support mapping versioning, since they can simply ignore those bits. 470 Furthermore, existing and futre mapping distribution protocol (e.g., 471 ALT [I-D.ietf-lisp-alt]) are able to carry version numbers without 472 needing any modification. The same applies to the LISP Map Server 473 ([I-D.ietf-lisp-ms]) which will still work without any change since 474 reserved bits are simply ignored. 476 7. Benefits and case studies for Mapping Versioning 478 In the following sections we provide more discussion on various 479 aspects of the mapping versioning. Security observations are instead 480 grouped in Section 10. 482 7.1. Mapping Versioning to simplify LISP implementation 484 The use of mapping versioning can help in simplifying the 485 implementation of LISP. In the current LISP specifications the set 486 of RLOCs must always be maintained ordered and consistent with the 487 content of the Loc Status Bits (see section 6.5 of [I-D.ietf-lisp]). 488 When using mapping versioning such type of mechanisms are not 489 necessary anymore since there is no direct relation between the order 490 of the locators and the bits of the mapping version number. 492 When a new RLOC is added to a mapping, it is not necessary to 493 "append" new locators to the existing ones as explained in Section 494 6.5 of the LISP draft. A new mapping with a new version number will 495 be issued, and since the old locators are still valid the transition 496 will be disruptionless. The same applies for the case a RLOC is 497 withdrawn. There is no need to maintain holes in the list of 498 locators, as is the case when using Loc Status Bits, for sites that 499 are not using the RLOC that has been withdrawn, the transition will 500 be disruptionless. 502 It is even possible to perform a graceful shutdown. This is obtained 503 by simply issuing a mapping where the specific RLOC to be shut down 504 is withdrawn or announced as unreachable (R bit in the Map Record), 505 but without actually turning it off. Once no more traffic is 506 received by the RLOC, because all sites have updated the mapping, it 507 can be shut down safely. 509 All of these operations, as already stated, do not need to maintain 510 any consistency among Loc Status Bits, and the way RLOC are stored in 511 the cache. This eases implementation. 513 Finally, with the versioning approach there is no need to perform a 514 "clock sweep" as described in Section 6.5.1 of the LISP draft. Every 515 LISP site communicating to a specific LISP site that has updated the 516 mapping will be informed of the available new mapping in a data- 517 driven manner. 519 7.2. Synchronization of different xTRs 521 Mapping Versioning does not require additional synchronization 522 mechanism compared to the normal functioning of LISP without mapping 523 versioning. Clearly all the ETRs have to reply with the same 524 versioning number, otherwise there can be an inconsistency that 525 creates additional control traffic. 527 As an example, let's consider the topology of figure Figure 2 where 528 ITR A.1 of domain A is sending unidirectional traffic to the xTR B of 529 domain B, while xTR A.2 of domain A and xTR B of domain B exchange 530 bidirectional traffic. 532 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ 533 | Domain A | | Domain B | 534 | +-+-+-+-+-+ | | 535 | | xTR A.1 |--- | | 536 | +-+-+-+-+-+ \ +-+-+-+-+-+ | 537 | | -------->| xTR B | | 538 | | -------->| | | 539 | +-+-+-+-+-+ / +-+-+-+-+-+ | 540 | | xTR A.2 |<-- | | 541 | +-+-+-+-+-+ | | 542 | | | | 543 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ 545 Figure 2 547 Obviously in the case of Mapping Versioning both xTRs of domain A 548 must use the same value otherwise the xTR of domain B will start to 549 sen Map-Requests. 551 The same problem can, however, arise without mapping versioning. For 552 instance if the two xTRs of domain A send different Loc Status Bits. 553 In this case either the traffic is disrupted, if the xTR B trusts the 554 Loc Status Bits, or it xTR B will start sending Map-Requests to 555 confirm the each change in the reachability. 557 So far, LISP does not provide any specific synchronization mechanism, 558 but assumes that synchronization is provided by configuring the 559 different xTRs consistently. The same applies for mapping 560 versioning. If in the future any synchronization mechanism is 561 provided, mapping versioning will take advantage of it automatically 562 if the record format described in Section 6 is used. 564 7.3. Map Versioning and unidirectional traffic 566 When using mapping versioning as specified in this document the LIS 567 specific header carries two mapping version numbers, for both source 568 and destination mapping. This can raise the question on what will 569 happen in the case of unidirectional flows, like for instance in the 570 case presented in Figure 3, since LISP specification do not mandate 571 for ETR to have a mapping for the source EID. 573 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ 574 | Domain A | | Domain B | 575 | +-+-+-+-+-+ +-+-+-+-+-+ | 576 | | ITR A |----------->| ETR B | | 577 | +-+-+-+-+-+ +-+-+-+-+-+ | 578 | | | | 579 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ 581 Figure 3 583 For what concerns the ITR, it is able to put both source and 584 destination version number in the LISP header since the source 585 mapping version number is in ITR's database, while the destination 586 mapping version number is in ITR's cache. 588 For what concerns the ETR, it simply checks only the destination 589 version number in the same way as described in Section 4, ignoring 590 the source mapping version number. 592 7.4. Mapping Versioning and interworking 594 Mapping versioning works also in the context of interworking between 595 LISP and IPv4 and IPv6 ([I-D.ietf-lisp-interworking]). The case of 596 PTR encapsulating packet for LISP sites is basically the same as the 597 unidirectional traffic case presented in the previous section. The 598 same rules can be applied. 600 7.5. Mapping Versioning vs. Checksum 602 Noel Chiappa has several times proposed on the LISP WG mailing list 603 to use a form of "checksum" as a mapping version number. This is an 604 interesting idea. Nevertheless, from our understanding, this implies 605 that the notion of ordering between different mappings for the same 606 EID-Prefix (e.g., whether a mapping is more recent) get lost. This 607 means that a large part of the filtering that can be done on not 608 valid version numbers (see Section 4) cannot be done anymore, hence 609 loosing an important feature of mapping versioning. Certainly, if it 610 would be possible to find a "checksum" function that embeds some form 611 of ordering, this can be discussed and integrated in future version 612 of this document. 614 7.6. Mapping Versioning and mobility 616 Mapping versioning can help in managing mobility in the LISP context 617 ([I-D.meyer-lisp-mn]). We are working in deploying Mapping 618 Versioning on a Wireless Mesh Network. Results concerning this 619 deployment will be provided in future versions of this document. 621 8. Incremental deployment and implementation status 623 The solution proposed in this draft includes the use of bits that are 624 marked as reserved in the main LISP specifications. This means that 625 any LISP element that does not support Mapping Versioning will safely 626 ignore them. Further, there is no need of any specific mechanism to 627 discover if an xTR supports or not Mapping Versioning. This 628 information is already included in the Map Record. 630 Mapping Versioning can be incrementally deployed without any negative 631 impact on existing LISP xTRs. Mapping Versioning is currently 632 implemented in OpenLISP [I-D.iannone-openlisp-implementation]. 634 Note that the reference document for LISP implementation and 635 interoperability tests remains [I-D.ietf-lisp]. 637 9. Mapping Versioning and path-liveness 639 When the reachability problem occurs on the path between two RLOCs of 640 different LISP sites (this is called path-liveness problem in the 641 recent draft by D. Meyer and D. Lewis 642 [I-D.meyer-loc-id-implications]), the versioning approach does not 643 help. In this case other mechanisms are necessary, however, such an 644 issue is not new and is part of all loc/ID split solutions, thus 645 versioning does not introduce a new issue. 647 10. Security Considerations 649 Mapping Versioning does not introduces any new security issue 650 concerning both the data-plane and the control-plane. On the 651 contrary, as described in the following, if Mapping Versioning is 652 used also to update mappings in case of change in the reachability 653 information (i.e., instead of the Loc Status Bits) it is possible to 654 reduce the effects of some DoS or spoofing attacks that can happen in 655 an untrusted environment. 657 10.1. Mapping Versioning against traffic disruption 659 An attacker can try to disrupt ongoing communications by creating 660 LISP encapsulated packets with wrong Loc Status Bits. If the xTR 661 blindly trusts the Loc Status Bits it will change the encapsulation 662 accordingly, which can result in traffic disruption. 664 This does not happen in the case of Mapping Versioning. As described 665 in Section 4, upon a version number change the xTR first issues a 666 Map-Request. The assumption is that the mapping distribution system 667 is sufficiently secure that Map-Request and Map-Reply messages and 668 their content can be trusted. Security issues concerning specific 669 mapping distribution system are out of the scope of this document. 670 Note also that in the case of Mapping Versioning the attacker should 671 "guess" a valid version number that triggers a Map-Request, as 672 described in Section 4, otherwise the packet is simply dropped. 674 Note that a similar level of security can be obtained with Loc Status 675 Bits, by simply making mandatory to verify any change through a Map- 676 Request. However, in this case Loc Status Bits loose their meaning, 677 because, it does not matter anymore which specific bits has changed, 678 the xTR will query the mapping system and trust the content of the 679 received Map-Reply. Furthermore there is no way to perform filtering 680 as in the mapping versioning in order to drop packets that do not 681 carry a valid mapping version number. In the case of Loc Status 682 Bits, any random change can trigger a Map-Request (unless rate 683 limitation is enabled which raise another type of attack discussed in 684 Section 10.2). 686 10.2. Mapping Versioning against reachability information DoS 688 Attackers can try to trigger a large amount of Map-Request by simply 689 by forging packets with random mapping version or random Loc Status 690 Bits. In both cases the Map-Requests are rate limited as described 691 in [I-D.ietf-lisp]. However, differently from Loc Status Bit where 692 there is no filtering possible, in the case of mapping versioning is 693 possible to filter not valid version numbers before triggering a Map- 694 Request, thus helping in reducing the effects of DoS attacks. In 695 other words the use of mapping versioning enables a fine control on 696 when to update a mapping or when to notify that a mapping has been 697 updated. 699 It is clear, that mapping versioning does not protect against DoS and 700 DDoS attacks, where an xTR looses processing power doing checks on 701 the LISP header of packets sent by attackers. This is independent 702 from mapping versioning and is the same for Loc Status Bits. 704 11. Acknowledgements 706 The authors would like to thank Pierre Francois, Noel Chiappa, Dino 707 Farinacci for their comments and review. 709 12. References 711 12.1. Normative References 713 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 714 Requirement Levels", BCP 14, RFC 2119, March 1997. 716 12.2. Informative References 718 [I-D.iannone-openlisp-implementation] 719 Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP 720 Implementation Report", 721 draft-iannone-openlisp-implementation-01 (work in 722 progress), July 2008. 724 [I-D.ietf-lisp] 725 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 726 "Locator/ID Separation Protocol (LISP)", 727 draft-ietf-lisp-06 (work in progress), January 2010. 729 [I-D.ietf-lisp-alt] 730 Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP 731 Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-02 732 (work in progress), January 2010. 734 [I-D.ietf-lisp-interworking] 735 Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 736 "Interworking LISP with IPv4 and IPv6", 737 draft-ietf-lisp-interworking-00 (work in progress), 738 May 2009. 740 [I-D.ietf-lisp-ms] 741 Fuller, V. and D. Farinacci, "LISP Map Server", 742 draft-ietf-lisp-ms-04 (work in progress), October 2009. 744 [I-D.meyer-lisp-mn] 745 Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP 746 Mobile Node", draft-meyer-lisp-mn-01 (work in progress), 747 February 2010. 749 [I-D.meyer-loc-id-implications] 750 Meyer, D. and D. Lewis, "Architectural Implications of 751 Locator/ID Separation", draft-meyer-loc-id-implications-01 752 (work in progress), January 2009. 754 Authors' Addresses 756 Luigi Iannone 757 TU Berlin - Deutsche Telekom Laboratories AG 758 Ernst-Reuter Platz 7 759 Berlin 760 Germany 762 Email: luigi@net.t-labs.tu-berlin.de 764 Damien Saucez 765 Universite catholique de Louvain 766 Place St. Barbe 2 767 Louvain la Neuve 768 Belgium 770 Email: damien.saucez@uclouvain.be 772 Olivier Bonaventure 773 Universite catholique de Louvain 774 Place St. Barbe 2 775 Louvain la Neuve 776 Belgium 778 Email: olivier.bonaventure@uclouvain.be