--- 1/draft-ietf-lisp-map-versioning-03.txt 2011-09-20 10:14:03.894133741 +0200 +++ 2/draft-ietf-lisp-map-versioning-04.txt 2011-09-20 10:14:03.934180203 +0200 @@ -1,21 +1,21 @@ Network Working Group L. Iannone Internet-Draft TU Berlin - Deutsche Telekom Intended status: Experimental Laboratories AG -Expires: March 16, 2012 D. Saucez +Expires: March 23, 2012 D. Saucez O. Bonaventure Universite catholique de Louvain - September 13, 2011 + September 20, 2011 LISP Map-Versioning - draft-ietf-lisp-map-versioning-03.txt + draft-ietf-lisp-map-versioning-04.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 @@ -34,21 +34,21 @@ 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 March 16, 2012. + This Internet-Draft will expire on March 23, 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 @@ -92,21 +92,21 @@ Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 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 complete them providing new functionalities. + mechanism, but rather to extend them providing new functionalities. The basic mechanism is to associate a Map-Version number to each LISP EID-to-RLOC mapping and transport such a version number in the LISP- specific header. When a mapping changes, a new version number is assigned to the updated mapping. A change in an 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. When Map-Versioning is used, LISP-encapsulated data packets contain the version number of the two mappings used to select the RLOCs in @@ -160,26 +160,26 @@ mapping used to select the source address (RLOC) of the outer IP header of LISP-encapsulated packets. Destination Map-Version number: Map-Version number of the EID-to- RLOC mapping used to select the destination address (RLOC) of the outer IP header of LISP-encapsulated packets. 4. EID-to-RLOC Map-Version number The EID-to-RLOC Map-Version number consists in an unsigned 12-bits - 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. Appendix A contains a rough estimation - of the wrap-around time for the Map-Version number. + integer. The version number is assigned on a per-mapping basis, + meaning that different mappings have a different version number, + which is also updated independently. An update in the version number + (i.e., a newer version) consists in incrementing by one the older + version number. Appendix A contains a rough estimation of the wrap- + around time for the Map-Version number. The space of version numbers has a circular order where half of the version numbers is greater than the current Map-Version number and the other half is smaller than current Map-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. @@ -231,24 +231,25 @@ The fact that the 0 value has a special meaning for the Map-Version number implies that, when updating a Map-Version number because of a change in the mapping, if the next value is 0 then Map-Version number MUST be incremented by 2 (i.e., set to 1, which is the next valid value). 5. Dealing with Map-Version numbers The main idea of using Map-Version numbers is that whenever there is a change in the mapping (e.g., adding/removing RLOCs, a change in the - weights due to 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, or policy changes) the - ISP updates the mapping also assigning a new Map-Version number. + weights due to TE policies, or a change in the priorities) or a LISP + site realizes that one or more of its own RLOCs are not reachable + anymore from a local perspective (e.g., through IGP, or policy + 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 is out of the scope of this document. @@ -289,24 +290,26 @@ to-date Destination Map-Version number. A check on this version number can be done, where the following cases can arise: 1. The packets arrive with the same Destination Map-Version number stored in the EID-to-RLOC Database. This is the regular case. The ITR sending the packet has in its EID-to-RLOC Cache an up-to- date mapping. No further actions are needed. 2. The packet arrives with a Destination Map-Version number greater (i.e., newer) than the one stored in the EID-to-RLOC Database. - Since the ETR is authoritative on the mapping, this means that - someone is not behaving correctly with respect to the - specifications, thus the packet carries a not valid version - number and SHOULD be silently dropped. + Since the ETR is authoritative on the mapping, meaning that the + Map-Version number of its mapping is the correct one, this + implies that someone is not behaving correctly with respect to + the specifications. In this case the packet carries a version + number that is not valid, otherwise the ETR would have the same, + and SHOULD be silently dropped. 3. The packets arrive with a Destination Map-Version number smaller (i.e., older) than the one stored in the EID-to-RLOC Database. This means that the ITR sending the packet has an old mapping in its EID-to-RLOC Cache containing stale information. The ITR sending the packet has to be informed that a newer mapping is available. This is done with a Map-Request message sent back to the ITR. The Map-Request will either trigger a Map-Request back using the Solicit-Map-Request (SMR) bit or it will piggyback the newer mapping. These are not new mechanisms; how to SMR or @@ -377,42 +380,42 @@ 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 and the + Map-Version in the EID-to-RLOC Cache is the correct one, while + the one carried by the packet is stale. In this situation the packet MAY be silently dropped. If the ETR does not have an entry in the EID-to-RLOC Cache for the source EID (e.g., in case of unidirectional traffic) then the Source Map-Version number can be safely ignored. For LISP-encapsulated packets with the V-bit set, if the Source Map- Version number is the Null Map-Version value, it means that the Source Map-Version number MUST be ignored. 6. LISP header and Map-Version numbers In order for the versioning approach to work, the LISP specific header has to carry both Source Map-Version number and Destination Map-Version number. This is done by setting the V-bit in the LISP specific header as defined in [I-D.ietf-lisp] Section 5.3. When the - V-bit is set the low-order 24-bits of the first longword (which - usually contains the nonce) are used to transport both source and - destination Map-Version numbers. In particular the first 12 bits are - used for Source Map-Version number and the second 12 bits for the - Destination Map-Version number. + V-bit is set the low-order 24-bits of the first longword are used to + transport both source and destination Map-Version numbers. In + particular the first 12 bits are used for Source Map-Version number + and the second 12 bits for the Destination Map-Version number. Hereafter is the example of LISP header carrying version numbers in the case of IPv4-in-IPv4 encapsulation. The same setting can be used for any other case (IPv4-in-IPv6, IPv6-in-IPv4, and IPv6-in-IPv6). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |N|L|E|V|I|flags| Source Map-Version |Destination Map-Version| LISP+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -437,40 +440,41 @@ packets need to carry version numbers. When Map-Version numbers are carried the V-bit MUST be set to 1. All legal combinations of the flags, when the V-bit is set to 1, are described in [I-D.ietf-lisp]. 7. Map Record and Map-Version To accommodate the proposed mechanism, the Map Records that are transported on Map-Request/Map-Reply/Map-Register messages need to carry the Map-Version number as well. For this purpose the 12-bits before the EID-AFI field in the Record that describe a mapping is - used. This is defined in [I-D.ietf-lisp] and reported here as - example. + used. This is defined in Section 6.1.4 of [I-D.ietf-lisp] and + reported here as example. 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 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| Reserved | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - c | Rsvd | Map-Version Number | EID-AFI | + c | Rsvd | Map-Version Number | EID-prefix-AFI | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | EID-prefix | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o | Unused Flags |L|p|R| Loc-AFI | | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Map-Version Number: Map-Version of the mapping contained in the Record. As explained in Section 4.1 this field can be zero (0), meaning that no Map-Version is associated to the mapping, hence packets that are LISP-encapsulated using this mapping MUST NOT contain Map-Version numbers in the LISP specific header and the V-bit MUST be set to 0. This packet format works perfectly with xTRs that do not support Map- Versioning, since they can simply ignore those bits. @@ -702,21 +706,21 @@ 10. Security Considerations Map-Versioning does not introduce any security issue concerning both the data-plane and the control-plane. On the contrary, as described in the following, if Map-Versioning may be used also to update mappings in case of change in the reachability information (i.e., instead of the Locator Status Bits) it is possible to reduce the effects of some DoS or spoofing attacks that can happen in an untrusted environment. - Robusteness of the Map-Versioning mechanism leverages on a trusted + Robustness of the Map-Versioning mechanism leverages on a trusted Mapping Distribution System. A thorough security analysis of LISP is documented in [I-D.ietf-lisp-threats]. 10.1. Map-Versioning against traffic disruption An attacker can try to disrupt ongoing communications by creating LISP encapsulated packets with wrong Locator Status Bits. If the xTR blindly trusts the Locator Status Bits it will change the encapsulation accordingly, which can result in traffic disruption. @@ -790,21 +794,21 @@ 13.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-08 + 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", @@ -849,20 +853,33 @@ | 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 04 Posted September 2011. + + * Added clarifications in Section 1, Section 4, Section 5.2, and + Section 5.1 to address Stephen Farrell's comments. + + * Used the term LISP Site instead of ISP in Section 5 as + suggested by Stephen Farrell. + + * Deleted "(usually contains the nonce)" from Section 6 because + confusing, as suggested by Stephen Farrell. + + * Fixed several typos pointed out by Stephen Farrell. + o Version 03 Posted September 2011. * Added reference in Section 7 toward the main lisp documents specifying the section, as requested by Jari Arkko. * Fixed all typos and editorial issues pointed out by Jari Arkko. * Added clarification in Section 8.4 as requested by Jari Arkko. * Extentend all acronyms in the abstract as requested by Jari