idnits 2.17.1 draft-iannone-lisp-mapping-versioning-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 3, 2009) is 5533 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-11 == Outdated reference: A later version (-05) exists of draft-fuller-lisp-alt-03 == Outdated reference: A later version (-01) exists of draft-meyer-loc-id-implications-00 Summary: 2 errors (**), 0 flaws (~~), 5 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 4, 2009 D. Saucez 6 O. Bonaventure 7 Universite catholique de Louvain 8 March 3, 2009 10 LISP Mapping Versioning 11 draft-iannone-lisp-mapping-versioning-00.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 4, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 The present document sketches an alternative approach to provide 50 information about changes to EID-to-RLOC mappings in the context of 51 LISP. The proposed approach is based on a versioning system for the 52 EID-to-RLOC mapping itself. When there is a change in the mapping 53 (where change could mean adding/removing an RLOC or just a 54 modification in the priority or weight of one or more RLOCs) a new 55 version number is generated and propagated in the LISP data packet. 56 In the LISP context, ETRs do not keep state that allows to know when 57 an ITR changes a mapping. The versioning system is a data-driven 58 mechanism to annonce those changes. 60 In order to support such an approach, the LISP encapsulation need to 61 be modified. In particular LISP-encapsulated data packets have to 62 contain the version number of the mapings used to select the RLOCs in 63 the outer header. These version numbers are contained in a "new" 64 LISP header. 66 The mappings are distributed as usual through the mapping 67 distribution system (e.g., CONS, ALT); versioning is only a mean to 68 announce that something has changed in the mapping. The 69 infrastructure built by each specific mapping protocol does not 70 change anyhow. Nevertheless, two modifications are needed. The 71 first modification consist in including version number in the Map- 72 Reply messages. The second modification consist in the introduction 73 of a new message, the "Map-Update-Notification" message used by ETRs 74 to notify ITRs that the mapping used to encapsulate the packet is old 75 and needs to be updated. This message does not contain the mapping, 76 it just suggests ITRs to perform a Map-Request in order to retrieve 77 the updated mapping. 79 Table of Contents 81 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 82 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 83 3. EID-to-RLOC Mapping Version Number . . . . . . . . . . . . . . 7 84 4. Version Numbers wrap-around . . . . . . . . . . . . . . . . . 8 85 5. Dealing with Version Numbers . . . . . . . . . . . . . . . . . 9 86 5.1. Handling Destination Mapping Version Number . . . . . . . 9 87 5.2. Handling Source Mapping Version Number . . . . . . . . . . 10 88 6. Proposed changes to the LISP header . . . . . . . . . . . . . 12 89 7. Proposed changes to the Map-Reply Packet format . . . . . . . 14 90 8. Map-Update-Notification Message . . . . . . . . . . . . . . . 15 91 9. Further Observations . . . . . . . . . . . . . . . . . . . . . 16 92 9.1. Mapping Versioning and RLOCs reachability . . . . . . . . 16 93 9.2. Mapping Versioning to simplify LISP implementation . . . . 16 94 9.3. Mapping Versioning and original LISP cohexistence . . . . 17 95 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 96 10.1. Robustness against reachability information spoofing. . . 18 97 10.2. Robustness against traffic disruption . . . . . . . . . . 18 98 10.3. Robustness of the Map-Update-Notification message . . . . 18 99 10.4. About robusteness of Reachability bits . . . . . . . . . . 19 100 11. Aknoledgements . . . . . . . . . . . . . . . . . . . . . . . . 20 101 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 102 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 103 12.2. Informative References . . . . . . . . . . . . . . . . . . 21 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 106 1. Requirements notation 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 2. Introduction 114 The present document introduces the use of version numbers in order 115 to provide information on a change in the EID-to-RLOC mappings used 116 in the LISP ([I-D.farinacci-lisp] ) context to perform encapsulation. 117 The approach is based on the idea that version numbers are associated 118 to each mapping. When a mapping is changes, a new version number is 119 assigned to the updated mapping. A change in a EID-to-RLOC mapping 120 can be a change in the RLOCs set, by adding or removing one or more 121 RLOCs, but it can also be a change in the priority or weight of one 122 or more RLOCs. The change can even consist in the reachability of 123 one or more RLOCs. Reachability information is intended from the 124 local-domain perspective, and can be obtained for instance monitoring 125 IGP's routing tables. This should not be confused with the intra- 126 domain "Locator Path Liveness problem" described in 127 [I-D.meyer-loc-id-implications]. 129 With this approach, LISP-encapsulated data packets have to contain 130 the version number of the mapings used to select the RLOCs in the 131 outer header. These version numbers are contained in a "new" LISP 132 header (described in Section 6). When an ITR encapsulates a packet, 133 it puts in the LISP-specific header two version numbers: 135 1. The version number assigned to the mapping (contained in the EID- 136 to-RLOC Database) used to select the source RLOC. 138 2. The version number assigned to the mapping (contained in the EID- 139 to-RLOC Cache) used to select the destination RLOC. 141 This operation is two-fold. On the one hand it enables the ETR 142 receiving the packet to know if the ITR that sent it is using the 143 latest mapping for the destination EID. If it is not the case the 144 ETR will send a "Map-Update-Notification" message (newly defined in 145 Section 8) to notify the ITR that a more recent version of the 146 mapping is available and can be retrieved as usual from the mapping 147 distribution system. Due to security issues (discussed in 148 Section 10.3), this message does not contain the mapping. On the 149 other hand, it enables the ETR receiving the packet to know if it has 150 in its cache the latest mapping for the source EID. 152 The versioning approach does not need to re-design the mapping 153 distribution infrastructure, which is always done through the mapping 154 distribution protocol (e.g., CONS [I-D.meyer-lisp-cons], ALT 155 [I-D.fuller-lisp-alt]). The mappings are distributed as usual 156 through the Map-Request/Map-Reply message exchange. There are only 157 the following two modifications that need to be introduced: 159 1. Map-Reply messages need to include the mapping version (described 160 in Section 7). 162 2. Support has to be added for the new Map-Update-Notification 163 message. 165 3. EID-to-RLOC Mapping Version Number 167 The EID-to-RLOC Mapping Version Number consist in an unsigned 15-bit 168 integer. The version number is assigned in a per-mapping fashion, 169 meaning that different mappings will have assigned a different 170 version number, which is also updated independently. An update in 171 the version number (i.e., a newer version) consist in incrementing by 172 one the older version number. 174 The space of version numbers has a circular order where half of the 175 version numbers is greater than the current Mapping Version Number 176 and the other half is smaller than Mapping Version Number. In a more 177 formal way, assuming we have two version numbers V1 and V2 and that 178 the numbers are expressed on N bits, the following three cases may 179 happen: 181 V1 = V2 : This is the exact match case. 183 V1 < V2 : True if and only if V1 < V2 < (V1 + 2**(N-1)). 185 V1 > V2 : True if and only if V1 > V2 > (V1 - 2**(N-1)). 187 As an example, using 24 bits, if the Mapping Version Number is 0, 188 versions in ]1; (2**14)-1[ are greater and versions in [2**14; 189 (2**15)-1[ are smaller. 191 4. Version Numbers wrap-around 193 The proposed 15 bits size for the Mapping Version Number based on the 194 assumption that Map-Requests are rate limited with a granularity of 195 seconds. Using a granularity of seconds and assuming that a new 196 version is issued each second, we have around 9 hours of autonomy 197 before the versions wraps around, which is a reasonable time. 198 Alternatively a granularity of minutes can also be used, as for the 199 TTL of the Map-Reply([I-D.farinacci-lisp]). Nevertheless, using a 200 granularity of minutes leads to very long (pointless) wrap-around 201 periods. Hereafter there is a table with a rough estimation of the 202 obtained autonomy with different sizes of the version number and 203 different time granularity. 205 +---------------+--------------------------------------------+ 206 |Version Number | Time before wrap around | 207 | Size (bits) +--------------------------------------------+ 208 | |Granularity: Minutes | Granularity: Seconds | 209 +------------------------------------------------------------+ 210 | 32 | 8171 Years | 136 Years | 211 | 30 | 2042 Years | 34 Years | 212 | 24 | 31 Years | 194 Days | 213 | 16 | 45 Days | 18 Hours | 214 | 15 | 22 Days | 9 Hours | 215 | 14 | 11 Days | 4 Hours | 216 +---------------+---------------------+----------------------+ 218 Figure 1 220 5. Dealing with Version Numbers 222 The main idea of using Mapping Version Numbers is that whenever there 223 is a change in the mapping (e.g., adding/removing RLOCs, a change in 224 the weights due to new TE policies, or a change in the priorities) or 225 an ISP realizes that one or more of its own RLOCs are not reachable 226 anymore from a local perspective (e.g., through IGP, due to route 227 flap, or policy changes) the ISP updates the mapping with a new 228 mapping version number. 230 In order to announce in a data-driven fashion that the mapping has 231 been updated, the version numbers used to encapsulate the packet are 232 embedded in the packets encapsulation. This means that the header 233 needs to contain two mapping version numbers. A first one from the 234 EID-to-RLOC mapping in the EID-to-RLOC Database used to select the 235 source RLOC, and called Source Mapping Version Number. A second one 236 from the EID-to-RLOC mapping in the EID-to-RLOC Cache used to select 237 the destination RLOC, and called Destination Mapping Version Number. 238 The purpose of carring these version numbers is two-fold, allowing 239 the ETR receiving the encapsulated packet to check if i) the ITR has 240 an up-to-date mapping; ii) the mapping in the local cache for the 241 source EID is up-to-date. If the first condition does not hold the 242 Map-Update-Notification (see Section 8) is used to make the ITR aware 243 that a newer mapping is available. The ITR will retrieve the mapping 244 with the normal Map-Request/Map-Reply mechanism. If the second 245 condition does not hold the ETR sends a Map-Request for the source 246 EID (obtained from the inner header of the packet) in order to 247 retrieve the up-to-date mapping. 249 Further details on how to handle the Source and Destination Mapping 250 Version Numbers are provided hereafter, while the proposed new LISP 251 header format is detailled in Section 6 (Figure 2). 253 5.1. Handling Destination Mapping Version Number 255 When an ETR receives a packet, the destination mapping version number 256 relates to the mapping of the domain the ETR is part of, thus the ETR 257 has the correct and up-to-date Version Number for the destination 258 mapping. A check on this version number is done, where the following 259 cases can arise: 261 o The packets arrive with the same destination mapping version 262 number stored in the LEID-to-RLOC Database. This is the correct 263 regular case. The ITR sending the packet has in its EID-to-RLOC 264 Cache an up-to-date mapping. No further actions are needed. 266 o The packets arrive with an destination mapping version number 267 smaller (i.e., older) than the one stored in the EID-to-RLOC 268 Database. This means that the ITR sending the packet has an old 269 mapping, in its EID-to-RLOC Cache, containing stale information. 270 Further actions are needed. The ITR sending the packet should be 271 informed that a newer mapping is available. This is done with a 272 "Map-Update-Notification" message sent back to the ITR, soliciting 273 an update of the mapping. This message should be rate limited and 274 if after a certain amount of retries the mapping is not updated 275 packets coming from that ITR with smaller mapping version number 276 can be silently dropped, since most likely there is a spoof or the 277 ITR is not behaving correctly. Note that the rule can be even 278 more restrictive. If the mapping has been the same for a period 279 of time as long as the TTL (defined in LISP [I-D.farinacci-lisp]) 280 of the previous version of the mapping, all packets arriving with 281 an old mapping version can be silently dropped right away. 282 Indeed, if the new mapping with the updated version number has 283 been stable for at least the same time as the TTL of the older 284 mapping, all the entries in the caches of ITRs must have expired. 285 If packets with old mapping version number are still received, the 286 reason is that either someone has not respected the TTL, or it is 287 a spoof, or a not valid behaviour w.r.t. the specifications. In 288 all those cases the packet can be silently dropped. 290 o The packet arrives with a destination mapping version number 291 greater (i.e., newer) than the one stored in the EID-to-RLOC 292 Database. Since the ETR is in the domain owning the mapping, this 293 means that someone is not behaving correctly w.r.t. the 294 specifications, thus the packets carries a not valid version 295 number and can be silently dropped. 297 5.2. Handling Source Mapping Version Number 299 When an ETR receives a packet, the source mapping version number 300 relates to the mapping owned by the domain the ITR is part of and 301 whose copy should be present in the EID-to-RLOC Cache of the ETR 302 (except for the first packet that generates a cache miss triggering a 303 Map-Request message). A check on this version number is done, where 304 the following cases can arise: 306 o The packet arrives with the same source mapping version number 307 stored in the EID-to-RLOC Cache. This is the correct regular 308 case. The ETR has in its EID-to-RLOC Cache an up-to-date copy of 309 the mapping. No further actions are needed. 311 o The packet arrives with a source mapping version number smaller 312 (i.e., older) than the one stored in the local EID-to-RLOC Cache. 313 Such a case is not valid w.r.t. the specifications and hence the 314 packet is silently dropped. If the mapping is already present in 315 the EID-to-RLOC Cache, this means that an explicit Map-Request has 316 been send and a Map-Reply has been received. The latter sent by 317 the "owner" of the mapping. Assuming the mapping system is not 318 corrupted anyhow, the mapping version in the EID-to-RLOC Cache is 319 the correct one, hence the packet is not valid. 321 o The packet arrives with a source mapping version number greater 322 (i.e., newer) than the one stored in the local EID-to-RLOC Cache. 323 The ETR has in its EID-to-RLOC Cache a mapping that is stale and 324 needs to be updated. The packet is considered valid but further 325 actions are needed. In particular a Map-Request must be sent to 326 the owner of the source mapping to retrieve the new mapping. This 327 should be rate limited. 329 6. Proposed changes to the LISP header 331 In order for the versioning approach to work, the LISP encapsulation 332 format needs to be changed. In particular the LISP header is 333 modified to include the source mapping version number and the 334 destination mapping version number. 336 Here is the new packet format, changes occur only on the LISP header: 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 /|Version| IHL |Type of Service| Total Length | 342 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 / | Identification |Flags| Fragment Offset | 344 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 OH | Time to Live | Protocol = 17 | Header Checksum | 346 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 \ | Source Routing Locator | 348 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 \| Destination Routing Locator | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 / | Source Port = xxxx | Dest Port = 4341 | 352 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 \ | UDP Length | UDP Checksum | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 / |Res| Source Mapping V.N. | Destination Mapping V. N. | 356 LISP+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 \ | Nonce | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 /|Version| IHL |Type of Service| Total Length | 360 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 / | Identification |Flags| Fragment Offset | 362 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 IH | Time to Live | Protocol | Header Checksum | 364 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 \ | Source EID | 366 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 \| Destination EID | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 Figure 2 372 Reserved (2 bits): Reserved for future use. Sent as 0 and ignored 373 on reception. A possible use of these two bits is proposed in 374 Section 9.3. 376 Source Mapping Version Number (15 bits): Version of the mapping used 377 by the ITR to select the RLOC to put in the "Source Routing 378 Locator" field. Note that the mapping used for such a selection 379 is determined by the Source EID, used as lookup key in the EID-to- 380 RLOC Database of the ITR. 382 Destination Mapping Version Number (15 bits): Version of the mapping 383 used by the ITR to select the RLOC to put in the "Destination 384 Routing Locator" field. Note that the mapping used for such a 385 selection is determined by the Destination EID, used as lookup key 386 in the EID-to-RLOC Cache of the ITR. 388 Note that the change proposed concerns only the part of the LISP 389 specific header originally containing the reachability bits. 391 7. Proposed changes to the Map-Reply Packet format 393 To accommodate the proposed mechanism, also the Map-Reply packet 394 format needs to be changed (original definition of the Map-Reply 395 packet format can be found in [I-D.farinacci-lisp]). This is a 396 simple change to carry the version number assigned to the mapping in 397 this message. It does not mean a change in the mapping distribution 398 system from an architectural point of view. 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Nonce | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 |Type=2 | Reserved | Record Count | 404 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | | Record TTL | 406 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 R |A| Reserved | Mapping Version Number | 408 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 c | Locator Count | EID mask-len | EID-AFI | 410 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 r | EID-prefix | 412 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | /| Priority | Weight | M Priority | M Weight | 414 | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 |Loc| Unused Flags |R| Loc-AFI | 416 | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | \| Locator | 418 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Mapping Protocol Data | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 Mapping Version Number: Version Number of the mapping in the Record. 424 The proposed change does not make the whole packet bigger. Indeed, 425 the proposed solution is to put the fields "Locator Count", "EID 426 mask-len" and "EID-AFI" in the same 32 bits block. In 427 [I-D.farinacci-lisp] "locator Count" and "EID mask-len" are in the 428 same 32 bits block but "EID-AFI" is in a different 32 bits block. 429 The first two fields are alligned left, while the latter is alligned 430 right, with a gap of 32 bits, from which only one is used (the 431 authoritative bit "A") while the other 31 are just marked as 432 "Reserved". After compacting the fields, the "A" bit is now placed 433 in the same 32 bits block like the mapping version number. Even, if 434 fields have been displaced, they keep their original definition 435 described in [I-D.farinacci-lisp]. 437 8. Map-Update-Notification Message 439 From the LISP packet that triggered a Map-Update-Notification, it is 440 known the ITR has to be notified about the existence of a newer 441 mapping. It is not possible to send the mapping directly with a Map- 442 Reply message, since this can introduce security threats. This is 443 why the Map-Update-Notification message is needed and must only be a 444 notification that a new version of the mapping is available. The 445 message is meant to trigger a Map-Request from the ITR, in order to 446 update its copy of the mapping. 448 In [I-D.farinacci-lisp], the equivalent of the Map-Update- 449 Notification message is the SMR bit set in the LISP header of the 450 data packets. The SMR bit approach does not work in the case of 451 unidirectional traffic (e.g., due to unidirectional flows or Traffic 452 Engineering). The ETR has no mean to send back to the ITR that a new 453 mapping is available. Moreover,with the SMR bit only there is not 454 enough information for understanding if ITRs have updated the mapping 455 so that the SMR bit can be reset. 457 The format for the Map-Update-Notification message will be provided 458 in future versions of this draft. 460 9. Further Observations 462 In the following sections we provide more discussion on various 463 aspects of the mapping versioning. Security observations are instead 464 grouped in Section 10. 466 9.1. Mapping Versioning and RLOCs reachability 468 When the reachability problem occurs on the path between two RLOCs of 469 different LISP sites (this is called path-liveness problem in the 470 recent draft by D. Meyer and D. Lewis 471 [I-D.meyer-loc-id-implications]), the versioning approach does not 472 help. In this case other mechanisms are necessary, however, such an 473 issue is not new and is part of all loc/ID split solutions, thus 474 versioning does not introduce a new issue. 476 9.2. Mapping Versioning to simplify LISP implementation 478 The use of versioning numbers for mapping has also the effect of 479 simplifying operations. The set of RLOCs can always be maintained 480 ordered, since no consistency must be preserved with the reachability 481 bits. 483 In other words it is not necessary to "append" new locators to the 484 existing ones as explained in Section 6.5 of the LISP draft. A new 485 mapping with a new version number will be issued, and since the old 486 locators are still valid the transition will be disruptionless. The 487 same applies for the case a RLOC is withdrawn. There is no need to 488 maintain holes in the list of locators, as previously, for sites that 489 are not using the RLOC that has been withdrawn, the transition will 490 be disruptionless. 492 It is even possible to perform a graceful shutdown. This is obtained 493 by simply issuing a mapping where the specific RLOC to be shut down 494 is withdrawn, but without actually turning it off. Once no more 495 traffic is received by the RLOC, because all sites have updated the 496 mapping the RLOC can be shut down safely. 498 All of these operations, as already stated, do not need to maintain 499 any consistency among reachability bits, and the way RLOC are stored 500 in the cache. This eases implementation. 502 Finally, with the versioning approach there is no need to perform a 503 "clock sweep" as described in Section 6.5.1 of the LISP draft. Every 504 LISP site communicating to a specific LISP site that has updated the 505 mapping will be informed of the available new mapping in a data- 506 driven manner. 508 9.3. Mapping Versioning and original LISP cohexistence 510 The solution proposed in this draft includes changes in the LISP 511 header. However, and for experimentation purpose, it could be worth 512 instead of replacing the original LISP header, to extend the original 513 LISP header by appending the one proposed in this draft. 515 Alternatively, the first two bits of the LISP specific header can be 516 used to select the type of header. For instance the second leftmost 517 bit can be used to state if the following bits have to be interpreted 518 as reachability bits or version numbers. 520 Note that the reference document for LISP implementation and 521 interoperability tests remains [I-D.farinacci-lisp]. The present 522 draft proposes an alternative approach that needs experimental 523 validation and should not be considered as a permanent design of the 524 LISP protocol. 526 10. Security Considerations 528 Mapping Versioning present the same reactivity of Reachability bits 529 and SMR bit, however, provides more robustness to possible attacks. 531 10.1. Robustness against reachability information spoofing. 533 Compared to the reachability bits solution, since the new mapping is 534 obtained through the mapping system the data plane results robust to 535 reachability information spoofing. Such a statement is true assuming 536 that the mapping distribution system is secure. Security issues 537 concerning specific mapping distribution system are described in the 538 documents specific to each proposal. 540 10.2. Robustness against traffic disruption 542 Attackers can try to use the Mapping version number to trigger either 543 Map-Update-Notification messages or Map-Request messages, by simply 544 sending packets for all the possible version numbers. Nevertheless, 545 as described in Section 5 it is possible to easily filter a large 546 part of the packets containing a wrong version number. If the 547 version number is sufficiently large, exploring all the possible 548 numbers will take too much time to be really feasible. 550 Furthermore, even if the attacker is able to "guess" the correct 551 version number to trigger a Map-Request, the traffic is not stopped. 552 The normal behavior will be that the xTR continue to use the mapping, 553 while asking in parallel for a new one, in a rate limited fashion. 554 This is not the case with explicit reachability bits where an 555 attacker can set all RLOCs to down with one single packet, with 556 disruptive consequences on the traffic. 558 It is clear, that mapping versioning does not protect against DoS and 559 DDoS attacks, where an xTR looses processing power doing version 560 number checks on packets sent by attackers. 562 10.3. Robustness of the Map-Update-Notification message 564 The Map-Update-Notification should never include the new mapping 565 inside the packet itself, otherwise a security threat would be 566 introduced, where attackers send fake Map-Update-Notifications 567 messages poisoning the cache. 569 The mapping could be included in the Map-Update-Notification only in 570 the case where the sender can be clearly identified (e.g., using 571 certificates or a PKI). 573 10.4. About robusteness of Reachability bits 575 The scenarii presented in the previous sections are correct if ETR 576 react to Reachability bits change without performing a further check 577 with the ITR. In other ways the ETR blindly trusts the content of 578 the Reachability bits. If ETR does not trust such a content and 579 before changing the reachability state of the RLOCs it can send a 580 Map-Request in order to confirm the change. On the one hand, having 581 such a confirmation improves the robusteness of the reachability bits 582 mechanism. On the other hand, this is very close to the mapping 583 versioning system, with the only difference that the use of version 584 numbers enables a fine control on when to update a mapping or when to 585 notify that a mapping has been updated. 587 11. Aknoledgements 589 The authors would like to thank Pierre Francois and Dino Farinacci 590 for their comments and review. 592 12. References 594 12.1. Normative References 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, March 1997. 599 12.2. Informative References 601 [I-D.farinacci-lisp] 602 Farinacci, D., Fuller, V., Oran, D., Meyer, D., and S. 603 Brim, "Locator/ID Separation Protocol (LISP)", 604 draft-farinacci-lisp-11 (work in progress), December 2008. 606 [I-D.fuller-lisp-alt] 607 Fuller, V., Meyer, D., and D. Farinacci, "LISP Alternative 608 Topology (LISP+ALT)", draft-fuller-lisp-alt-03 (work in 609 progress), October 2008. 611 [I-D.meyer-lisp-cons] 612 Brim, S., "LISP-CONS: A Content distribution Overlay 613 Network Service for LISP", draft-meyer-lisp-cons-04 (work 614 in progress), April 2008. 616 [I-D.meyer-loc-id-implications] 617 Meyer, D. and D. Lewis, "Architectural Implications of 618 Locator/ID Separation", draft-meyer-loc-id-implications-00 619 (work in progress), December 2008. 621 Authors' Addresses 623 Luigi Iannone 624 TU Berlin - Deutsche Telekom Laboratories AG 625 Ernst-Reuter Platz 7 626 Berlin 627 Germany 629 Email: luigi@net.t-labs.tu-berlin.de 631 Damien Saucez 632 Universite catholique de Louvain 633 Place St. Barbe 2 634 Louvain la Neuve 635 Belgium 637 Email: damien.saucez@uclouvain.be 639 Olivier Bonaventure 640 Universite catholique de Louvain 641 Place St. Barbe 2 642 Louvain la Neuve 643 Belgium 645 Email: olivier.bonaventure@uclouvain.be