Network Working Group L. Iannone Internet-Draft TU Berlin - Deutsche Telekom Intended status: Experimental Laboratories AG Expires: September 4, 2009 D. Saucez O. Bonaventure Universite catholique de Louvain March 3, 2009 LISP Mapping Versioning draft-iannone-lisp-mapping-versioning-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 4, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Iannone, et al. Expires September 4, 2009 [Page 1] Internet-Draft LISP Mapping Versioning March 2009 Abstract The present document sketches an alternative approach to provide information about changes to EID-to-RLOC mappings in the context of LISP. The proposed approach is based on a versioning system for the EID-to-RLOC mapping itself. When there is a change in the mapping (where change could mean adding/removing an RLOC or just a modification in the priority or weight of one or more RLOCs) a new version number is generated and propagated in the LISP data packet. In the LISP context, ETRs do not keep state that allows to know when an ITR changes a mapping. The versioning system is a data-driven mechanism to annonce those changes. In order to support such an approach, the LISP encapsulation need to be modified. In particular LISP-encapsulated data packets have to contain the version number of the mapings used to select the RLOCs in the outer header. These version numbers are contained in a "new" LISP header. The mappings are distributed as usual through the mapping distribution system (e.g., CONS, ALT); versioning is only a mean to announce that something has changed in the mapping. The infrastructure built by each specific mapping protocol does not change anyhow. Nevertheless, two modifications are needed. The first modification consist in including version number in the Map- Reply messages. The second modification consist in the introduction of a new message, the "Map-Update-Notification" message used by ETRs to notify ITRs that the mapping used to encapsulate the packet is old and needs to be updated. This message does not contain the mapping, it just suggests ITRs to perform a Map-Request in order to retrieve the updated mapping. Iannone, et al. Expires September 4, 2009 [Page 2] Internet-Draft LISP Mapping Versioning March 2009 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. EID-to-RLOC Mapping Version Number . . . . . . . . . . . . . . 7 4. Version Numbers wrap-around . . . . . . . . . . . . . . . . . 8 5. Dealing with Version Numbers . . . . . . . . . . . . . . . . . 9 5.1. Handling Destination Mapping Version Number . . . . . . . 9 5.2. Handling Source Mapping Version Number . . . . . . . . . . 10 6. Proposed changes to the LISP header . . . . . . . . . . . . . 12 7. Proposed changes to the Map-Reply Packet format . . . . . . . 14 8. Map-Update-Notification Message . . . . . . . . . . . . . . . 15 9. Further Observations . . . . . . . . . . . . . . . . . . . . . 16 9.1. Mapping Versioning and RLOCs reachability . . . . . . . . 16 9.2. Mapping Versioning to simplify LISP implementation . . . . 16 9.3. Mapping Versioning and original LISP cohexistence . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10.1. Robustness against reachability information spoofing. . . 18 10.2. Robustness against traffic disruption . . . . . . . . . . 18 10.3. Robustness of the Map-Update-Notification message . . . . 18 10.4. About robusteness of Reachability bits . . . . . . . . . . 19 11. Aknoledgements . . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Iannone, et al. Expires September 4, 2009 [Page 3] Internet-Draft LISP Mapping Versioning March 2009 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Iannone, et al. Expires September 4, 2009 [Page 4] Internet-Draft LISP Mapping Versioning March 2009 2. Introduction The present document introduces the use of version numbers in order to provide information on a change in the EID-to-RLOC mappings used in the LISP ([I-D.farinacci-lisp] ) context to perform encapsulation. The approach is based on the idea that version numbers are associated to each mapping. When a mapping is changes, a new version number is assigned to the updated mapping. A change in a EID-to-RLOC mapping can be a change in the RLOCs set, by adding or removing one or more RLOCs, but it can also be a change in the priority or weight of one or more RLOCs. The change can even consist in the reachability of one or more RLOCs. Reachability information is intended from the local-domain perspective, and can be obtained for instance monitoring IGP's routing tables. This should not be confused with the intra- domain "Locator Path Liveness problem" described in [I-D.meyer-loc-id-implications]. With this approach, LISP-encapsulated data packets have to contain the version number of the mapings used to select the RLOCs in the outer header. These version numbers are contained in a "new" LISP header (described in Section 6). When an ITR encapsulates a packet, it puts in the LISP-specific header two version numbers: 1. The version number assigned to the mapping (contained in the EID- to-RLOC Database) used to select the source RLOC. 2. The version number assigned to the mapping (contained in the EID- to-RLOC Cache) used to select the destination RLOC. This operation is two-fold. On the one hand it enables the ETR receiving the packet to know if the ITR that sent it is using the latest mapping for the destination EID. If it is not the case the ETR will send a "Map-Update-Notification" message (newly defined in Section 8) to notify the ITR that a more recent version of the mapping is available and can be retrieved as usual from the mapping distribution system. Due to security issues (discussed in Section 10.3), this message does not contain the mapping. On the other hand, it enables the ETR receiving the packet to know if it has in its cache the latest mapping for the source EID. The versioning approach does not need to re-design the mapping distribution infrastructure, which is always done through the mapping distribution protocol (e.g., CONS [I-D.meyer-lisp-cons], ALT [I-D.fuller-lisp-alt]). The mappings are distributed as usual through the Map-Request/Map-Reply message exchange. There are only the following two modifications that need to be introduced: Iannone, et al. Expires September 4, 2009 [Page 5] Internet-Draft LISP Mapping Versioning March 2009 1. Map-Reply messages need to include the mapping version (described in Section 7). 2. Support has to be added for the new Map-Update-Notification message. Iannone, et al. Expires September 4, 2009 [Page 6] Internet-Draft LISP Mapping Versioning March 2009 3. EID-to-RLOC Mapping Version Number The EID-to-RLOC Mapping Version Number consist in an unsigned 15-bit integer. The version number is assigned in a per-mapping fashion, meaning that different mappings will have assigned a different version number, which is also updated independently. An update in the version number (i.e., a newer version) consist in incrementing by one the older version number. The space of version numbers has a circular order where half of the version numbers is greater than the current Mapping Version Number and the other half is smaller than Mapping Version Number. In a more formal way, assuming we have two version numbers V1 and V2 and that the numbers are expressed on N bits, the following three cases may happen: V1 = V2 : This is the exact match case. V1 < V2 : True if and only if V1 < V2 < (V1 + 2**(N-1)). V1 > V2 : True if and only if V1 > V2 > (V1 - 2**(N-1)). As an example, using 24 bits, if the Mapping Version Number is 0, versions in ]1; (2**14)-1[ are greater and versions in [2**14; (2**15)-1[ are smaller. Iannone, et al. Expires September 4, 2009 [Page 7] Internet-Draft LISP Mapping Versioning March 2009 4. Version Numbers wrap-around The proposed 15 bits size for the Mapping Version Number based on the assumption that Map-Requests are rate limited with a granularity of seconds. Using a granularity of seconds and assuming that a new version is issued each second, we have around 9 hours of autonomy before the versions wraps around, which is a reasonable time. Alternatively a granularity of minutes can also be used, as for the TTL of the Map-Reply([I-D.farinacci-lisp]). Nevertheless, using a granularity of minutes leads to very long (pointless) wrap-around periods. Hereafter there is a table with a rough estimation of the obtained autonomy with different sizes of the version number and different time granularity. +---------------+--------------------------------------------+ |Version Number | Time before wrap around | | Size (bits) +--------------------------------------------+ | |Granularity: Minutes | Granularity: Seconds | +------------------------------------------------------------+ | 32 | 8171 Years | 136 Years | | 30 | 2042 Years | 34 Years | | 24 | 31 Years | 194 Days | | 16 | 45 Days | 18 Hours | | 15 | 22 Days | 9 Hours | | 14 | 11 Days | 4 Hours | +---------------+---------------------+----------------------+ Figure 1 Iannone, et al. Expires September 4, 2009 [Page 8] Internet-Draft LISP Mapping Versioning March 2009 5. Dealing with Version Numbers The main idea of using Mapping Version Numbers is that whenever there is a change in the mapping (e.g., adding/removing RLOCs, a change in the weights due to new TE policies, or a change in the priorities) or an ISP realizes that one or more of its own RLOCs are not reachable anymore from a local perspective (e.g., through IGP, due to route flap, or policy changes) the ISP updates the mapping with a new mapping version number. In order to announce in a data-driven fashion that the mapping has been updated, the version numbers used to encapsulate the packet are embedded in the packets encapsulation. This means that the header needs to contain two mapping version numbers. A first one from the EID-to-RLOC mapping in the EID-to-RLOC Database used to select the source RLOC, and called Source Mapping Version Number. A second one from the EID-to-RLOC mapping in the EID-to-RLOC Cache used to select the destination RLOC, and called Destination Mapping Version Number. The purpose of carring these version numbers is two-fold, allowing the ETR receiving the encapsulated packet to check if i) the ITR has an up-to-date mapping; ii) the mapping in the local cache for the source EID is up-to-date. If the first condition does not hold the Map-Update-Notification (see Section 8) is used to make the ITR aware that a newer mapping is available. The ITR will retrieve the mapping with the normal Map-Request/Map-Reply mechanism. If the second condition does not hold the ETR sends a Map-Request for the source EID (obtained from the inner header of the packet) in order to retrieve the up-to-date mapping. Further details on how to handle the Source and Destination Mapping Version Numbers are provided hereafter, while the proposed new LISP header format is detailled in Section 6 (Figure 2). 5.1. Handling Destination Mapping Version Number When an ETR receives a packet, the destination mapping version number relates to the mapping of the domain the ETR is part of, thus the ETR has the correct and up-to-date Version Number for the destination mapping. A check on this version number is done, where the following cases can arise: o The packets arrive with the same destination mapping version number stored in the LEID-to-RLOC Database. This is the correct regular case. The ITR sending the packet has in its EID-to-RLOC Cache an up-to-date mapping. No further actions are needed. o The packets arrive with an destination mapping version number smaller (i.e., older) than the one stored in the EID-to-RLOC Iannone, et al. Expires September 4, 2009 [Page 9] Internet-Draft LISP Mapping Versioning March 2009 Database. This means that the ITR sending the packet has an old mapping, in its EID-to-RLOC Cache, containing stale information. Further actions are needed. The ITR sending the packet should be informed that a newer mapping is available. This is done with a "Map-Update-Notification" message sent back to the ITR, soliciting an update of the mapping. This message should be rate limited and if after a certain amount of retries the mapping is not updated packets coming from that ITR with smaller mapping version number can be silently dropped, since most likely there is a spoof or the ITR is not behaving correctly. Note that the rule can be even more restrictive. If the mapping has been the same for a period of time as long as the TTL (defined in LISP [I-D.farinacci-lisp]) of the previous version of the mapping, all packets arriving with an old mapping version can be silently dropped right away. Indeed, if the new mapping with the updated version number has been stable for at least the same time as the TTL of the older mapping, all the entries in the caches of ITRs must have expired. If packets with old mapping version number are still received, the reason is that either someone has not respected the TTL, or it is a spoof, or a not valid behaviour w.r.t. the specifications. In all those cases the packet can be silently dropped. o The packet arrives with a destination mapping version number greater (i.e., newer) than the one stored in the EID-to-RLOC Database. Since the ETR is in the domain owning the mapping, this means that someone is not behaving correctly w.r.t. the specifications, thus the packets carries a not valid version number and can be silently dropped. 5.2. Handling Source Mapping Version Number When an ETR receives a packet, the source mapping version number relates to the mapping owned by the domain the ITR is part of and whose copy should be present in the EID-to-RLOC Cache of the ETR (except for the first packet that generates a cache miss triggering a Map-Request message). A check on this version number is done, where the following cases can arise: o The packet arrives with the same source mapping version number stored in the EID-to-RLOC Cache. This is the correct regular case. The ETR has in its EID-to-RLOC Cache an up-to-date copy of the mapping. No further actions are needed. o The packet arrives with a source mapping version number smaller (i.e., older) than the one stored in the local EID-to-RLOC Cache. Such a case is not valid w.r.t. the specifications and hence the packet is silently dropped. If the mapping is already present in the EID-to-RLOC Cache, this means that an explicit Map-Request has Iannone, et al. Expires September 4, 2009 [Page 10] Internet-Draft LISP Mapping Versioning March 2009 been send and a Map-Reply has been received. The latter sent by the "owner" of the mapping. Assuming the mapping system is not corrupted anyhow, the mapping version in the EID-to-RLOC Cache is the correct one, hence the packet is not valid. o The packet arrives with a source mapping version number greater (i.e., newer) than the one stored in the local EID-to-RLOC Cache. The ETR has in its EID-to-RLOC Cache a mapping that is stale and needs to be updated. The packet is considered valid but further actions are needed. In particular a Map-Request must be sent to the owner of the source mapping to retrieve the new mapping. This should be rate limited. Iannone, et al. Expires September 4, 2009 [Page 11] Internet-Draft LISP Mapping Versioning March 2009 6. Proposed changes to the LISP header In order for the versioning approach to work, the LISP encapsulation format needs to be changed. In particular the LISP header is modified to include the source mapping version number and the destination mapping version number. Here is the new packet format, changes occur only on the LISP header: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /|Version| IHL |Type of Service| Total Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Identification |Flags| Fragment Offset | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OH | Time to Live | Protocol = 17 | Header Checksum | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Source Routing Locator | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \| Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port = xxxx | Dest Port = 4341 | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Res| Source Mapping V.N. | Destination Mapping V. N. | LISP+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /|Version| IHL |Type of Service| Total Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Identification |Flags| Fragment Offset | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IH | Time to Live | Protocol | Header Checksum | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Source EID | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \| Destination EID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Reserved (2 bits): Reserved for future use. Sent as 0 and ignored on reception. A possible use of these two bits is proposed in Section 9.3. Iannone, et al. Expires September 4, 2009 [Page 12] Internet-Draft LISP Mapping Versioning March 2009 Source Mapping Version Number (15 bits): Version of the mapping used by the ITR to select the RLOC to put in the "Source Routing Locator" field. Note that the mapping used for such a selection is determined by the Source EID, used as lookup key in the EID-to- RLOC Database of the ITR. Destination Mapping Version Number (15 bits): Version of the mapping used by the ITR to select the RLOC to put in the "Destination Routing Locator" field. Note that the mapping used for such a selection is determined by the Destination EID, used as lookup key in the EID-to-RLOC Cache of the ITR. Note that the change proposed concerns only the part of the LISP specific header originally containing the reachability bits. Iannone, et al. Expires September 4, 2009 [Page 13] Internet-Draft LISP Mapping Versioning March 2009 7. Proposed changes to the Map-Reply Packet format To accommodate the proposed mechanism, also the Map-Reply packet format needs to be changed (original definition of the Map-Reply packet format can be found in [I-D.farinacci-lisp]). This is a simple change to carry the version number assigned to the mapping in this message. It does not mean a change in the mapping distribution system from an architectural point of view. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=2 | Reserved | Record Count | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R |A| Reserved | Mapping Version Number | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c | Locator Count | EID mask-len | EID-AFI | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | EID-prefix | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Loc| Unused Flags |R| Loc-AFI | | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mapping Protocol Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mapping Version Number: Version Number of the mapping in the Record. The proposed change does not make the whole packet bigger. Indeed, the proposed solution is to put the fields "Locator Count", "EID mask-len" and "EID-AFI" in the same 32 bits block. In [I-D.farinacci-lisp] "locator Count" and "EID mask-len" are in the same 32 bits block but "EID-AFI" is in a different 32 bits block. The first two fields are alligned left, while the latter is alligned right, with a gap of 32 bits, from which only one is used (the authoritative bit "A") while the other 31 are just marked as "Reserved". After compacting the fields, the "A" bit is now placed in the same 32 bits block like the mapping version number. Even, if fields have been displaced, they keep their original definition described in [I-D.farinacci-lisp]. Iannone, et al. Expires September 4, 2009 [Page 14] Internet-Draft LISP Mapping Versioning March 2009 8. Map-Update-Notification Message From the LISP packet that triggered a Map-Update-Notification, it is known the ITR has to be notified about the existence of a newer mapping. It is not possible to send the mapping directly with a Map- Reply message, since this can introduce security threats. This is why the Map-Update-Notification message is needed and must only be a notification that a new version of the mapping is available. The message is meant to trigger a Map-Request from the ITR, in order to update its copy of the mapping. In [I-D.farinacci-lisp], the equivalent of the Map-Update- Notification message is the SMR bit set in the LISP header of the data packets. The SMR bit approach does not work in the case of unidirectional traffic (e.g., due to unidirectional flows or Traffic Engineering). The ETR has no mean to send back to the ITR that a new mapping is available. Moreover,with the SMR bit only there is not enough information for understanding if ITRs have updated the mapping so that the SMR bit can be reset. The format for the Map-Update-Notification message will be provided in future versions of this draft. Iannone, et al. Expires September 4, 2009 [Page 15] Internet-Draft LISP Mapping Versioning March 2009 9. Further Observations In the following sections we provide more discussion on various aspects of the mapping versioning. Security observations are instead grouped in Section 10. 9.1. Mapping Versioning and RLOCs reachability When the reachability problem occurs on the path between two RLOCs of different LISP sites (this is called path-liveness problem in the recent draft by D. Meyer and D. Lewis [I-D.meyer-loc-id-implications]), the versioning approach does not help. In this case other mechanisms are necessary, however, such an issue is not new and is part of all loc/ID split solutions, thus versioning does not introduce a new issue. 9.2. Mapping Versioning to simplify LISP implementation The use of versioning numbers for mapping has also the effect of simplifying operations. The set of RLOCs can always be maintained ordered, since no consistency must be preserved with the reachability bits. In other words it is not necessary to "append" new locators to the existing ones as explained in Section 6.5 of the LISP draft. A new mapping with a new version number will be issued, and since the old locators are still valid the transition will be disruptionless. The same applies for the case a RLOC is withdrawn. There is no need to maintain holes in the list of locators, as previously, for sites that are not using the RLOC that has been withdrawn, the transition will be disruptionless. It is even possible to perform a graceful shutdown. This is obtained by simply issuing a mapping where the specific RLOC to be shut down is withdrawn, but without actually turning it off. Once no more traffic is received by the RLOC, because all sites have updated the mapping the RLOC can be shut down safely. All of these operations, as already stated, do not need to maintain any consistency among reachability bits, and the way RLOC are stored in the cache. This eases implementation. Finally, with the versioning approach there is no need to perform a "clock sweep" as described in Section 6.5.1 of the LISP draft. Every LISP site communicating to a specific LISP site that has updated the mapping will be informed of the available new mapping in a data- driven manner. Iannone, et al. Expires September 4, 2009 [Page 16] Internet-Draft LISP Mapping Versioning March 2009 9.3. Mapping Versioning and original LISP cohexistence The solution proposed in this draft includes changes in the LISP header. However, and for experimentation purpose, it could be worth instead of replacing the original LISP header, to extend the original LISP header by appending the one proposed in this draft. Alternatively, the first two bits of the LISP specific header can be used to select the type of header. For instance the second leftmost bit can be used to state if the following bits have to be interpreted as reachability bits or version numbers. Note that the reference document for LISP implementation and interoperability tests remains [I-D.farinacci-lisp]. The present draft proposes an alternative approach that needs experimental validation and should not be considered as a permanent design of the LISP protocol. Iannone, et al. Expires September 4, 2009 [Page 17] Internet-Draft LISP Mapping Versioning March 2009 10. Security Considerations Mapping Versioning present the same reactivity of Reachability bits and SMR bit, however, provides more robustness to possible attacks. 10.1. Robustness against reachability information spoofing. Compared to the reachability bits solution, since the new mapping is obtained through the mapping system the data plane results robust to reachability information spoofing. Such a statement is true assuming that the mapping distribution system is secure. Security issues concerning specific mapping distribution system are described in the documents specific to each proposal. 10.2. Robustness against traffic disruption Attackers can try to use the Mapping version number to trigger either Map-Update-Notification messages or Map-Request messages, by simply sending packets for all the possible version numbers. Nevertheless, as described in Section 5 it is possible to easily filter a large part of the packets containing a wrong version number. If the version number is sufficiently large, exploring all the possible numbers will take too much time to be really feasible. Furthermore, even if the attacker is able to "guess" the correct version number to trigger a Map-Request, the traffic is not stopped. The normal behavior will be that the xTR continue to use the mapping, while asking in parallel for a new one, in a rate limited fashion. This is not the case with explicit reachability bits where an attacker can set all RLOCs to down with one single packet, with disruptive consequences on the traffic. It is clear, that mapping versioning does not protect against DoS and DDoS attacks, where an xTR looses processing power doing version number checks on packets sent by attackers. 10.3. Robustness of the Map-Update-Notification message The Map-Update-Notification should never include the new mapping inside the packet itself, otherwise a security threat would be introduced, where attackers send fake Map-Update-Notifications messages poisoning the cache. The mapping could be included in the Map-Update-Notification only in the case where the sender can be clearly identified (e.g., using certificates or a PKI). Iannone, et al. Expires September 4, 2009 [Page 18] Internet-Draft LISP Mapping Versioning March 2009 10.4. About robusteness of Reachability bits The scenarii presented in the previous sections are correct if ETR react to Reachability bits change without performing a further check with the ITR. In other ways the ETR blindly trusts the content of the Reachability bits. If ETR does not trust such a content and before changing the reachability state of the RLOCs it can send a Map-Request in order to confirm the change. On the one hand, having such a confirmation improves the robusteness of the reachability bits mechanism. On the other hand, this is very close to the mapping versioning system, with the only difference that the use of version numbers enables a fine control on when to update a mapping or when to notify that a mapping has been updated. Iannone, et al. Expires September 4, 2009 [Page 19] Internet-Draft LISP Mapping Versioning March 2009 11. Aknoledgements The authors would like to thank Pierre Francois and Dino Farinacci for their comments and review. Iannone, et al. Expires September 4, 2009 [Page 20] Internet-Draft LISP Mapping Versioning March 2009 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 12.2. Informative References [I-D.farinacci-lisp] Farinacci, D., Fuller, V., Oran, D., Meyer, D., and S. Brim, "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-11 (work in progress), December 2008. [I-D.fuller-lisp-alt] Fuller, V., Meyer, D., and D. Farinacci, "LISP Alternative Topology (LISP+ALT)", draft-fuller-lisp-alt-03 (work in progress), October 2008. [I-D.meyer-lisp-cons] Brim, S., "LISP-CONS: A Content distribution Overlay Network Service for LISP", draft-meyer-lisp-cons-04 (work in progress), April 2008. [I-D.meyer-loc-id-implications] Meyer, D. and D. Lewis, "Architectural Implications of Locator/ID Separation", draft-meyer-loc-id-implications-00 (work in progress), December 2008. Iannone, et al. Expires September 4, 2009 [Page 21] Internet-Draft LISP Mapping Versioning March 2009 Authors' Addresses Luigi Iannone TU Berlin - Deutsche Telekom Laboratories AG Ernst-Reuter Platz 7 Berlin Germany Email: luigi@net.t-labs.tu-berlin.de Damien Saucez Universite catholique de Louvain Place St. Barbe 2 Louvain la Neuve Belgium Email: damien.saucez@uclouvain.be Olivier Bonaventure Universite catholique de Louvain Place St. Barbe 2 Louvain la Neuve Belgium Email: olivier.bonaventure@uclouvain.be Iannone, et al. Expires September 4, 2009 [Page 22]