--- 1/draft-ietf-lisp-map-versioning-05.txt 2011-10-31 18:14:08.978671260 +0100 +++ 2/draft-ietf-lisp-map-versioning-06.txt 2011-10-31 18:14:09.022670939 +0100 @@ -1,54 +1,53 @@ Network Working Group L. Iannone -Internet-Draft TU Berlin - Deutsche Telekom -Intended status: Experimental Laboratories AG -Expires: April 15, 2012 D. Saucez - O. Bonaventure +Internet-Draft Telekom Innovation Laboratories +Intended status: Experimental D. Saucez +Expires: May 3, 2012 O. Bonaventure Universite catholique de Louvain - October 13, 2011 + October 31, 2011 LISP Map-Versioning - draft-ietf-lisp-map-versioning-05.txt + draft-ietf-lisp-map-versioning-06.txt Abstract This document describes the LISP (Locator/ID Separation Protocol) Map-Versioning mechanism, which provides in-packet information about Endpoint-ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and transport such a version number in the LISP specific header of LISP- encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to - encapsulate packets. The mechanism is transparent to legacy - implementations, since in the LISP-specific header and in the Map - Records, bits used for Map-Versioning can be safely ignored by ITRs - and ETRs that do not support the mechanism. + encapsulate packets. The mechanism is transparent to implementations + not supporting this feature, since in the LISP-specific header and in + the Map Records, bits used for Map-Versioning can be safely ignored + by ITRs and ETRs that do not support the mechanism. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on April 15, 2012. + This Internet-Draft will expire on May 3, 2012. Copyright Notice Copyright (c) 2011 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -61,43 +60,44 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 3. Definitions of Terms . . . . . . . . . . . . . . . . . . . . . 4 4. EID-to-RLOC Map-Version number . . . . . . . . . . . . . . . . 4 4.1. The Null Map-Version . . . . . . . . . . . . . . . . . . . 5 5. Dealing with Map-Version numbers . . . . . . . . . . . . . . . 6 5.1. Handling Destination Map-Version number . . . . . . . . . 7 5.2. Handling Source Map-Version number . . . . . . . . . . . . 9 - 6. LISP header and Map-Version numbers . . . . . . . . . . . . . 9 + 6. LISP header and Map-Version numbers . . . . . . . . . . . . . 10 7. Map Record and Map-Version . . . . . . . . . . . . . . . . . . 10 8. Benefits and case studies for Map-Versioning . . . . . . . . . 11 8.1. Synchronization of different xTRs . . . . . . . . . . . . 11 8.2. Map-Versioning and unidirectional traffic . . . . . . . . 12 8.3. Map-Versioning and interworking . . . . . . . . . . . . . 13 8.3.1. Map-Versioning and Proxy-ITRs . . . . . . . . . . . . 13 8.3.2. Map-Versioning and LISP-NAT . . . . . . . . . . . . . 14 8.3.3. Map-Versioning and Proxy-ETRs . . . . . . . . . . . . 14 8.4. RLOC shutdown/withdraw . . . . . . . . . . . . . . . . . . 15 8.5. Map-Version for lightweight LISP implementation . . . . . 15 9. Incremental deployment and implementation status . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10.1. Map-Versioning against traffic disruption . . . . . . . . 16 10.2. Map-Versioning against reachability information DoS . . . 17 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 - 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 13.1. Normative References . . . . . . . . . . . . . . . . . . . 18 - 13.2. Informative References . . . . . . . . . . . . . . . . . . 18 - Appendix A. Estimation of time before Map-Version wrap-around . . 18 - Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 19 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 12. Open Issues and Considerations . . . . . . . . . . . . . . . . 18 + 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 14.1. Normative References . . . . . . . . . . . . . . . . . . . 18 + 14.2. Informative References . . . . . . . . . . . . . . . . . . 19 + Appendix A. Estimation of time before Map-Version wrap-around . . 19 + Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 20 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction This document describes the Map-Versioning mechanism used to provide information on changes in the EID-to-RLOC mappings used in the LISP ([I-D.ietf-lisp]) context to perform packet encapsulation. The mechanism is totally transparent to xTRs not supporting such functionality. It is not meant to replace any existing LISP mechanism, but rather to extend them providing new functionalities. If for any unforseen reason a normative conflict between the present @@ -129,24 +129,29 @@ 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 has the latest version number that any ETR at the destination EID site has provided to the ITR in a Map-Reply. If it is not the case the ETR can send to the ITR a Map- Request containing the updated mapping or soliciting a Map-Request from the ITR (both cases are already defined in [I-D.ietf-lisp]). In - this way the ITR can update its cache. On the other hand, it enables - an ETR receiving such a packet to know if it has in its EID-to-RLOC - Cache the latest mapping for the source EID (in case of bidirectional - traffic). If it is not the case a Map-Request can be sent. + this way the ITR can update its EID-to-RLOC Cache. On the other + hand, it enables an ETR receiving such a packet to know if it has in + its EID-to-RLOC Cache the latest mapping for the source EID (in case + of bidirectional traffic). If it is not the case a Map-Request can + be sent. + + Issues and concerns about the deployment of LISP for Internet traffic + are discussed in [I-D.ietf-lisp]. Section 12 provides additional + issues and concerns raised by this document. 2. 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]. 3. Definitions of Terms The present document uses terms already defined in main LISP @@ -221,21 +226,21 @@ the version of the EID-to-RLOC mapping. Such a value is used for special purposes and is named the Null Map-Version number. The Null Map-Version MAY appear in the LISP specific header as either Source Map-Version number (cf. Section 5.2) or Destination Map- Version number (cf. Section 5.1). When the Source Map-Version number is set to the Null Map-version value it means that no map version information is conveyed for the source site. This means that if a mapping exists for the source EID in the EID-to-RLOC Cache, then the ETR MUST NOT compare the received Null Map-Version with the content - of the EID-to-RLOC cache. When the Destination Map-version number is + of the EID-to-RLOC Cache. When the Destination Map-version number is set to the Null Map-version value it means that no map version information is conveyed for the destination site. This means that the ETR MUST NOT compare the value with the Map-Version number of the mapping for the destination EID present in the EID-to-RLOC Database. The other use of the Null Map-Version number is in the Map Records, which are part of the Map-Request, Map-Reply and Map-Register messages (defined in [I-D.ietf-lisp]). Map Records that have a Null Map-Version number indicate that there is no Map-Version number associated with the mapping. This means that LISP encapsulated @@ -262,49 +267,50 @@ changes) the LISP site updates the mapping also assigning a new Map- Version number. To each mapping, a version number is associated and changes each time the mapping is changed. Note that map-versioning does not introduce new problems concerning the coordination of different ETRs of a domain. Indeed, ETRs belonging to the same LISP site must return for a specific EID-prefix the same mapping, including the same Map- Version number. In principle this is orthogonal to whether or not map-versioning is used. The synchronization problem and its - implication on the traffic is out of the scope of this document. + implication on the traffic is out of the scope of this document (see + Section 12). In order to announce in a data-driven fashion that the mapping has been updated, Map-Version numbers used to create the outer IP header of the LISP-encapsulated packet are embedded in the LISP-specific header. This means that the header needs to contain two Map-Version numbers: o The Source Map-Version number of the EID-to-RLOC mapping in the EID-to-RLOC Database used to select the source RLOC. o The Destination Map-Version number of the EID-to-RLOC mapping in the EID-to-RLOC Cache used to select the destination RLOC. By embedding both Source Map-Version number and Destination Map- Version number an ETR receiving a LISP packet with Map-Version numbers, can perform the following checks: 1. The ITR that has sent the packet has an up-to-date mapping in its - cache for the destination EID and is performing encapsulation - correctly. + EID-to-RLOC Cache for the destination EID and is performing + encapsulation correctly. 2. In case of bidirectional traffic, the mapping in the local ETR - EID-to-RLOC cache for the source EID is up-to-date. + EID-to-RLOC Cache for the source EID is up-to-date. If one or both of the above conditions do not hold, the ETR can send a Map-Request either to make the ITR aware that a new mapping is available (see Section 5.1) or to update the mapping in the local - cache (see Section 5.2). + EID-to-RLOC Cache (see Section 5.2). 5.1. Handling Destination Map-Version number When an ETR receives a packet, the Destination Map-Version number relates to the mapping for the destination EID for which the ETR is a RLOC. This mapping is part of the ETR EID-to-RLOC Database. Since the ETR is authoritative for the mapping, it has the correct and up- to-date Destination Map-Version number. A check on this version number can be done, where the following cases can arise: @@ -348,27 +354,27 @@ keeping sending Map-Requests at very low rate it is possible to recover from this situation. The rule in the third case MAY be more restrictive. If the mapping has been the same for a period of time as long as the TTL (defined in [I-D.ietf-lisp]) of the previous version of the mapping, all packets arriving with an old Map-Version SHOULD be silently dropped right away without issuing any Map-Request. The reason that allows such action is the fact that if the new mapping with the updated version number has been unchanged for at least the same time as the TTL of - the older mapping, all the entries in the caches of ITRs must have - expired. Hence, all ITRs sending traffic should have refreshed the - mapping according to [I-D.ietf-lisp]. If packets with old Map- - Version number are still received, then either someone has not - respected the TTL, or it is a form of spoof/attack. In both cases - this is not valid behavior with respect to the specifications and the - packet SHOULD be silently dropped. + the older mapping, all the entries in the EID-to-RLOC Caches of ITRs + must have expired. Hence, all ITRs sending traffic should have + refreshed the mapping according to [I-D.ietf-lisp]. If packets with + old Map-Version number are still received, then either someone has + not respected the TTL, or it is a form of spoof/attack. In both + cases this is not valid behavior with respect to the specifications + and the packet SHOULD be silently dropped. LISP-encapsulated packets with the V-bit set, when the original mapping in the EID-to-RLOC Database has version number set to the Null Map-Version value, MAY be silently dropped. As explained in Section 4.1, if an EID-to-RLOC mapping has a Null Map-Version, it means that ITRs, using the mapping for encapsulation, MUST NOT use Map-Version number in the LISP-specific header. For LISP-encapsulated packets with the V-bit set, when the original mapping in the EID-to-RLOC Database has version number set to a value @@ -379,30 +385,30 @@ 5.2. Handling Source Map-Version number When an ETR receives a packet, the Source Map-Version number relates to the mapping for the source EID for which the ITR that sent the packet is authoritative. If the ETR has an entry in its EID-to-RLOC Cache for the source EID, then a check can be performed and the following cases can arise: 1. The packet arrives with the same Source Map-Version number stored in the EID-to-RLOC Cache. This is the correct regular case. The - ITR has in its cache an up-to-date copy of the mapping. No - further actions are needed. + ITR has in its EID-to-RLOC Cache an up-to-date copy of the + mapping. No further actions are needed. 2. The packet arrives with a Source Map-Version number greater (i.e., newer) than the one stored in the local EID-to-RLOC Cache. - This means that ETR has in its cache a mapping that is stale and - needs to be updated. A Map-Request SHOULD be sent to get the new - mapping for the source EID. This is a normal Map-Request message - sent through the mapping system and MUST respect the - specifications in [I-D.ietf-lisp], including rate limitation + This means that ETR has in its EID-to-RLOC Cache a mapping that + is stale and needs to be updated. A Map-Request SHOULD be sent + to get the new mapping for the source EID. This is a normal Map- + Request message sent through the mapping system and MUST respect + the specifications in [I-D.ietf-lisp], including rate limitation policies. 3. The packet arrives with a Source Map-Version number smaller (i.e., older) than the one stored in the local EID-to-RLOC Cache. Such a case is not valid with respect to the specifications. Indeed, if the mapping is already present in the EID-to-RLOC Cache, this means that an explicit Map-Request has been sent and a Map-Reply has been received from an authoritative source. Assuming that the mapping system is not corrupted anyhow, the Map-Version in the EID-to-RLOC Cache is the correct one, while @@ -686,21 +692,21 @@ ones as explained in Section 6.5 of [I-D.ietf-lisp]. A new mapping with a new Map-Version number will be issued, and since the old locators are still valid the transition will be with no disruptions. The same applies for the case a RLOC is withdrawn. There is no need to maintain holes in the list of locators, as is the case when using Locator Status Bits, for sites that are not using the RLOC that has been withdrawn the transition will be with no disruptions. All of these operations, as already stated, do not need to maintain any consistency among Locator Status Bits, and the way RLOC are - stored in the cache. + stored in the EID-to-RLOC Cache. Further, Map-Version can be used to substitute the "clock sweep" operation described in Section 6.5.1 of [I-D.ietf-lisp]. Indeed, 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. Note that what is proposed in the present section is just an example and MUST NOT be considered as specifications for a lightweight LISP implementation. In case the IETF decides to undertake such a work, @@ -782,62 +788,89 @@ It is clear, that Map-Versioning does not protect against DoS and DDoS attacks, where an xTR looses processing power doing checks on the LISP header of packets sent by attackers. This is independent from Map-Versioning and is the same for Loc Status Bits. 11. IANA Considerations This document has no actions for IANA. -12. Acknowledgements +12. Open Issues and Considerations + + There are a number of implications of the use of Map-Versioning that + are not yet completely explored. Among these are: + + o Performance of the convergence time when an EID-to-RLOC mapping + changes, i.e., how much time is needed to update mappings in the + EID-to-RLOC Cache of the ITRs currently sending traffic to ETRs + for the EID whose mapping has been changed. + + o Support to ETR synchronization. Even without Map-Versioning, LISP + ([I-D.ietf-lisp]) requires ETRs to announce the same mapping for + the same EID-Prefix to a requester. The implications that a + temporary lack of synchronization may have on the traffic is yet + to be fully explored. There are two ways Map-Versioning is + helpful with respect to the synchronization problem. On the one + hand, assigning version numbers to mappings helps in debugging, + since quick checks on the consistency of the mappings on different + ETRs can be done by looking at the Map-Version number. On the + other hand, Map-Versioning can be used to control the traffic + toward ETRs that announce the latest mapping. + + The authors expect that experimentation will help assess the + performance and the limitations of the Map-Versioning mechanism. + Issues and concerns about the deployment of LISP for Internet traffic + are discussed in [I-D.ietf-lisp]. + +13. Acknowledgements The authors would like to thank Alia Atlas, Jesper Skriver, Pierre Francois, Noel Chiappa, Dino Farinacci for their comments and review. This work has been partially supported by the INFSO-ICT-216372 TRILOGY Project (www.trilogy-project.org). -13. References +14. References -13.1. Normative References +14.1. Normative References [I-D.ietf-lisp] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-15 (work in progress), July 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. -13.2. Informative References +14.2. Informative References [I-D.iannone-openlisp-implementation] Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP Implementation Report", draft-iannone-openlisp-implementation-01 (work in progress), July 2008. [I-D.ietf-lisp-alt] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-09 (work in progress), September 2011. [I-D.ietf-lisp-interworking] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking LISP with IPv4 and IPv6", draft-ietf-lisp-interworking-02 (work in progress), June 2011. [I-D.ietf-lisp-ms] - Fuller, V. and D. Farinacci, "LISP Map Server", - draft-ietf-lisp-ms-11 (work in progress), August 2011. + Fuller, V. and D. Farinacci, "LISP Map Server Interface", + draft-ietf-lisp-ms-12 (work in progress), October 2011. [I-D.ietf-lisp-threats] Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats Analysis", draft-ietf-lisp-threats-00 (work in progress), July 2011. Appendix A. Estimation of time before Map-Version wrap-around The present section proposes an estimation of the wrap-around time for the proposed 12 bits size for the Map-Version number. Using a @@ -871,20 +904,30 @@ | 15 | 22 Days | 9 Hours | | 14 | 11 Days | 4 Hours | | 13 | 5.6 Days | 2.2 Hours | | 12 | 2.8 Days | 1.1 Hours | +---------------+---------------------+----------------------+ Figure 5: Estimation of time before wrap-around Appendix B. Document Change Log + o Version 06 Posted October 2011. + + * Added disclaimer in the Introduction about general issues + concerning LISP as requested by A. Farrel. + + * Fixed sentence about legacy systems in the abstract as + requested by A. Farrel. + + * Added Section 12 as requested by A. Farrel. + o Version 05 Posted October 2011. * Added sentence in Section 3 on the use of Big Endian, as for comment of P. Resnick. * Extended the end of Section 4 in order to clarify that Map- Version numbers are assigned to mappings by configuration and not automatically generated by ETRs, as for comments of R. Sparks @@ -961,21 +1004,21 @@ * Editorial polishing of all sections. * Added clarifications in section "Dealing with Map-Version numbers" for the case of the special Map-Version number 0. * Rename of draft-iannone-mapping-versioning-02.txt. Authors' Addresses Luigi Iannone - TU Berlin - Deutsche Telekom Laboratories AG + Telekom Innovation Laboratories 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