From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6834.txt | 1179 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1179 insertions(+) create mode 100644 doc/rfc/rfc6834.txt (limited to 'doc/rfc/rfc6834.txt') diff --git a/doc/rfc/rfc6834.txt b/doc/rfc/rfc6834.txt new file mode 100644 index 0000000..440db34 --- /dev/null +++ b/doc/rfc/rfc6834.txt @@ -0,0 +1,1179 @@ + + + + + + +Internet Engineering Task Force (IETF) L. Iannone +Request for Comments: 6834 Telecom ParisTech +Category: Experimental D. Saucez +ISSN: 2070-1721 INRIA Sophia Antipolis + O. Bonaventure + Universite catholique de Louvain + January 2013 + + + Locator/ID Separation Protocol (LISP) Map-Versioning + +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 the + transport of 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 + 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 document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It represents the consensus of the IETF + community. It has received public review and has been approved for + publication by the Internet Engineering Steering Group (IESG). Not + all documents approved by the IESG are a candidate for any level of + Internet Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6834. + + + + + + +Iannone, et al. Experimental [Page 1] + +RFC 6834 LISP Map-Versioning January 2013 + + +Copyright Notice + + Copyright (c) 2013 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 + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +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 ............................10 + 7. Map Record and Map-Version .....................................11 + 8. Benefits and Case Studies for Map-Versioning ...................12 + 8.1. Map-Versioning and Unidirectional Traffic .................12 + 8.2. Map-Versioning and Interworking ...........................12 + 8.2.1. Map-Versioning and Proxy-ITRs ......................13 + 8.2.2. Map-Versioning and LISP-NAT ........................13 + 8.2.3. Map-Versioning and Proxy-ETRs ......................14 + 8.3. RLOC Shutdown/Withdraw ....................................14 + 8.4. Map-Version for Lightweight LISP Implementation ...........15 + 9. Incremental Deployment and Implementation Status ...............15 + 10. Security Considerations .......................................16 + 10.1. Map-Versioning against Traffic Disruption ................16 + 10.2. Map-Versioning against Reachability Information DoS ......17 + 11. Open Issues and Considerations ................................17 + 11.1. Lack of Synchronization among ETRs .......................17 + 12. Acknowledgments ...............................................19 + 13. References ....................................................19 + 13.1. Normative References .....................................19 + 13.2. Informative References ...................................19 + Appendix A. Estimation of Time before Map-Version Wrap-Around .....21 + + + + + +Iannone, et al. Experimental [Page 2] + +RFC 6834 LISP Map-Versioning January 2013 + + +1. Introduction + + This document describes the Map-Versioning mechanism used to provide + information on changes in the EID-to-RLOC (Endpoint ID to Routing + Locator) mappings used in the LISP (Locator/ID Separation Protocol + [RFC6830]) context to perform packet encapsulation. The mechanism is + totally transparent to xTRs (Ingress and Egress Tunnel Routers) not + supporting such functionality. It is not meant to replace any + existing LISP mechanisms but rather to extend them by providing new + functionalities. If for any unforeseen reason a normative conflict + between this document and the LISP main specifications is found, the + latter ([RFC6830]) has precedence over this document. + + 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 + the outer header (i.e., both source and destination). These version + numbers are encoded in the 24 low-order bits of the first longword of + the LISP header and indicated by a specific bit in the flags (first 8 + high-order bits of the first longword of the LISP header). Note that + not all packets need to carry version numbers. + + When an ITR (Ingress Tunnel Router) encapsulates a data packet, with + a LISP header containing the Map-Version numbers, 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 + (Egress Tunnel Router) 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 this is not the case, the + ETR can send to the ITR a Map-Request containing the updated mapping + or solicit a Map-Request from the ITR (both cases are already defined + in [RFC6830]). In this way, the ITR can update its EID-to-RLOC + Cache. On the other hand, it enables an ETR receiving such a packet + + + + +Iannone, et al. Experimental [Page 3] + +RFC 6834 LISP Map-Versioning January 2013 + + + to know if it has in its EID-to-RLOC Cache the latest mapping for the + source EID (in the case of bidirectional traffic). If this is not + the case, a Map-Request can be sent. + + Issues and concerns about the deployment of LISP for Internet traffic + are discussed in [RFC6830]. Section 11 provides additional issues + and concerns raised by this document. In particular, Section 11.1 + provides details about the ETRs' synchronization issue in the context + of Map-Versioning. + +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 + + This document uses terms already defined in the main LISP + specification [RFC6830]. Here, we define the terms that are specific + to the Map-Versioning mechanism. Throughout the whole document, Big + Endian bit ordering is used. + + Map-Version number: An unsigned 12-bit integer is assigned to an + EID-to-RLOC mapping, not including the value 0 (0x000). + + Null Map-Version: The 12-bit null value of 0 (0x000) is not used as + a Map-Version number. It is used to signal that no Map-Version + number is assigned to the EID-to-RLOC mapping. + + Source Map-Version number: This Map-Version number of the + EID-to-RLOC mapping is used to select the source address (RLOC) + of the outer IP header of LISP-encapsulated packets. + + Destination Map-Version number: This Map-Version number of the + EID-to-RLOC mapping is 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 of an unsigned 12-bit + 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 of incrementing by one the older + version number. Appendix A contains a rough estimation of the + wrap-around time for the Map-Version number. + + + + +Iannone, et al. Experimental [Page 4] + +RFC 6834 LISP Map-Versioning January 2013 + + + The space of version numbers has a circular order where half of the + version numbers are greater (i.e., newer) than the current + Map-Version number and the other half of the version numbers are + smaller (i.e., older) than the current Map-Version number. In a more + formal way, assuming that we have two version numbers V1 and V2 and + that the numbers are expressed in N bits, the following steps MUST be + performed (in the same order as shown below) to strictly define their + order: + + 1. V1 = V2 : The Map-Version numbers are the same. + + 2. V2 > V1 : if and only if + + V2 > V1 AND (V2 - V1) <= 2**(N-1) + + OR + + V1 > V2 AND (V1 - V2) > 2**(N-1) + + 3. V1 > V2 : otherwise. + + Using 12 bits, as defined in this document, and assuming a + Map-Version value of 69, Map-Version numbers in the range + [70; 69 + 2048] are greater than 69, while Map-Version numbers in the + range [69 + 2049; (69 + 4096) mod 4096] are smaller than 69. + + Map-Version numbers are assigned to mappings by configuration. The + initial Map-Version number of a new EID-to-RLOC mapping SHOULD be + assigned randomly, but it MUST NOT be set to the Null Map-Version + value (0x000), because the Null Map-Version number has a special + meaning (see Section 4.1). + + Upon reboot, an ETR will use mappings configured in its EID-to-RLOC + Database. If those mappings have a Map-Version number, it will be + used according to the mechanisms described in this document. ETRs + MUST NOT automatically generate and assign Map-Version numbers to + mappings in the EID-to-RLOC Database. + +4.1. The Null Map-Version + + The value 0x000 (zero) is not a valid Map-Version number indicating + 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 + a Source Map-Version number (cf. Section 5.2) or a 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 + + + +Iannone, et al. Experimental [Page 5] + +RFC 6834 LISP Map-Versioning January 2013 + + + 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 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 [RFC6830]). 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 + packets destined to the EID-Prefix referred to by the Map Record MUST + either not contain any Map-Version numbers (V-bit set to 0) or, if + they contain Map-Version numbers (V-bit set to 1), then the + destination Map-Version number MUST be set to the Null Map-Version + number. Any value different from zero means that Map-Versioning is + supported and MAY be used. + + 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 the 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 Traffic Engineering 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 and its + implication on the traffic are out of the scope of this document (see + Section 11). + + + + +Iannone, et al. Experimental [Page 6] + +RFC 6834 LISP Map-Versioning January 2013 + + + 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 the Source Map-Version number and the 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 + EID-to-RLOC Cache for the destination EID and is performing + encapsulation correctly. + + 2. In the case of bidirectional traffic, the mapping in the local + ETR 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 + 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 + an 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: + + 1. The packet arrives 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, meaning that the + Map-Version number of its mapping is the correct one, this + implies that someone is not behaving correctly with respect to + + + + +Iannone, et al. Experimental [Page 7] + +RFC 6834 LISP Map-Versioning January 2013 + + + the specifications. In this case, the packet carries a version + number that is not valid; otherwise, the ETR would have the same + number, and the packet 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 ETR MAY + choose to normally process the encapsulated datagram according to + [RFC6830]; however, 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 use the SMR bit or how to piggyback + mappings in Map-Request messages is already described in + [RFC6830], while their security is discussed in [LISP-THREATS]. + These Map-Request messages should be rate-limited + (rate-limitation policies are also described in [RFC6830]). The + feature introduced by Map-Version numbers is the possibility of + blocking traffic not using the latest mapping. Indeed, after a + certain number of retries, if the Destination Map-Version number + in the packets is not updated, the ETR MAY drop packets with a + stale Map-Version number while strongly reducing the rate of + Map-Request messages. This is because either the ITR is refusing + to use the mapping for which the ETR is authoritative, or (worse) + it might be some form of attack. Another case might be that the + control plane is experiencing transient failures, so the + Map-Requests cannot reach that ITR. By continually sending + Map-Requests at a 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 Time to Live + (TTL) (defined in [RFC6830]) 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. Such action is + permitted because 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 EID-to-RLOC Caches of ITRs must have + expired. Hence, all ITRs sending traffic should have refreshed the + mapping according to [RFC6830]. If packets with old Map-Version + numbers 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. + + + + + +Iannone, et al. Experimental [Page 8] + +RFC 6834 LISP Map-Versioning January 2013 + + + LISP-encapsulated packets with the V-bit set, when the original + mapping in the EID-to-RLOC Database has the 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 a + 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 the version number set to a + value different from the Null Map-Version value, a Destination + Map-Version number equal to the Null Map-Version value means that the + Destination Map-Version number MUST be ignored. + +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 as + that stored in the EID-to-RLOC Cache. This is the correct + regular case. The 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 the 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 [RFC6830], 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, 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. + + + + + + +Iannone, et al. Experimental [Page 9] + +RFC 6834 LISP Map-Versioning January 2013 + + + If the ETR does not have an entry in the EID-to-RLOC Cache for the + source EID (e.g., in the 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 the 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 [RFC6830] Section 5.3. When + the V-bit is set, the low-order 24 bits of the first longword are + used to transport both the source and destination Map-Version + numbers. In particular, the first 12 bits are used for the Source + Map-Version number and the second 12 bits for the Destination + Map-Version number. + + Below is an example of a 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ | Instance ID/Locator-Status-Bits | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Source Map-Version number (12 bits): Map-Version of the mapping used + by the ITR to select the RLOC present in the 'Source Routing + Locator' field. Section 5.2 describes how to set this value on + transmission and handle it on reception. + + Destination Map-Version number (12 bits): Map-Version of the mapping + used by the ITR to select the RLOC present in the 'Destination + Routing Locator' field. Section 5.1 describes how to set this + value on transmission and handle it on reception. + + This document only specifies how to use the low-order 24 bits of the + first longword of the LISP-specific header when the V-bit is set to + 1. All other cases, including the bit fields of the rest of the + LISP-specific header and the whole LISP packet format, are specified + in [RFC6830]. Not all of the LISP-encapsulated packets need to carry + + + + +Iannone, et al. Experimental [Page 10] + +RFC 6834 LISP Map-Versioning January 2013 + + + version numbers. When Map-Version numbers are carried in these + packets, the V-bit MUST be set to 1. All permissible combinations of + the flags when the V-bit is set to 1 are described in [RFC6830]. + +7. Map Record and Map-Version + + To accommodate the proposed mechanism, the Map Records that are + transported in 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-Prefix-AFI' field in the Record that describes a + mapping are used. This is defined in Section 6.1.4 of [RFC6830] and + reported here as an 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-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. + + + + + + + + + + + +Iannone, et al. Experimental [Page 11] + +RFC 6834 LISP Map-Versioning January 2013 + + +8. Benefits and Case Studies for Map-Versioning + + In the following sections, we provide more discussion on various + aspects and uses of Map-Versioning. Security observations are + grouped in Section 10. + +8.1. Map-Versioning and Unidirectional Traffic + + When using Map-Versioning, the LISP-specific header carries two + Map-Version numbers, for both source and destination mappings. This + can raise the question on what will happen in the case of + unidirectional flows, for instance, in the case presented in + Figure 1, since the LISP specification does not mandate that the ETR + have a mapping for the source EID. + + +-----------------+ +-----------------+ + | Domain A | | Domain B | + | +---------+ +---------+ | + | | ITR A |----------->| ETR B | | + | +---------+ +---------+ | + | | | | + +-----------------+ +-----------------+ + + Figure 1: Unidirectional Traffic between LISP Domains + + In the case of the ITR, the ITR is able to put both the source and + destination version number in the LISP header, since the Source + Map-Version number is in the ITR's database, while the Destination + Map-Version number is in the ITR's cache. + + In the case of the ETR, the ETR simply checks only the Destination + Map-Version number in the same way as that described in Section 5, + ignoring the Source Map-Version number. + +8.2. Map-Versioning and Interworking + + Map-Versioning is compatible with the LISP interworking between LISP + and non-LISP sites as defined in [RFC6832]. LISP interworking + defines three techniques to make LISP sites and non-LISP sites, + namely Proxy-ITR, LISP-NAT, and Proxy-ETR. The following text + describes how Map-Versioning relates to these three mechanisms. + + + + + + + + + + +Iannone, et al. Experimental [Page 12] + +RFC 6834 LISP Map-Versioning January 2013 + + +8.2.1. Map-Versioning and Proxy-ITRs + + The purpose of the Proxy-ITR (PITR) is to encapsulate traffic + originating in a non-LISP site in order to deliver the packet to one + of the ETRs of the LISP site (cf. Figure 2). This case is very + similar to the unidirectional traffic case described in Section 8.1; + hence, similar rules apply. + + +----------+ +-------------+ + | LISP | | non-LISP | + | Domain A | | Domain B | + | +-------+ +-----------+ | | + | | ETR A |<-------| Proxy-ITR |<-------| | + | +-------+ +-----------+ | | + | | | | + +----------+ +-------------+ + + Figure 2: Unidirectional Traffic from Non-LISP Domain to LISP Domain + + The main difference is that a Proxy-ITR does not have any mapping, + since it just encapsulates packets arriving from the non-LISP site + and thus cannot provide a Source Map-Version. In this case, the + Proxy-ITR will just put the Null Map-Version value as the Source + Map-Version number, while the receiving ETR will ignore the field. + + With this setup, LISP Domain A is able to check whether or not the + PITR is using the latest mapping. If this is not the case, the + mapping for LISP Domain A on the PITR can be updated using one of the + mechanisms defined in [RFC6830] and [RFC6832]. + +8.2.2. Map-Versioning and LISP-NAT + + The LISP-NAT mechanism is based on address translation from + non-routable EIDs to routable EIDs and does not involve any form of + encapsulation. As such, Map-Versioning does not apply in this case. + + + + + + + + + + + + + + + + +Iannone, et al. Experimental [Page 13] + +RFC 6834 LISP Map-Versioning January 2013 + + +8.2.3. Map-Versioning and Proxy-ETRs + + The purpose of the Proxy-ETR (PETR) is to decapsulate traffic + originating in a LISP site in order to deliver the packet to the + non-LISP site (cf. Figure 3). One of the main reasons to deploy + PETRs is to bypass uRPF (Unicast Reverse Path Forwarding) checks on + the provider edge. + + +----------+ +-------------+ + | LISP | | non-LISP | + | Domain A | | Domain B | + | +-------+ +-----------+ | | + | | ITR A |------->| Proxy-ETR |------->| | + | +-------+ +-----------+ | | + | | | | + +----------+ +-------------+ + + Figure 3: Unidirectional Traffic from LISP Domain to Non-LISP Domain + + A Proxy-ETR does not have any mapping, since it just decapsulates + packets arriving from the LISP site. In this case, the ITR will just + put the Null Map-Version value as the Destination Map-Version number, + while the receiving Proxy-ETR will ignore the field. + + With this setup, the Proxy-ETR is able to check whether or not the + mapping has changed. If this is the case, the mapping for LISP + Domain A on the PETR can be updated using one of the mechanisms + defined in [RFC6830] and [RFC6832]. + +8.3. RLOC Shutdown/Withdraw + + Map-Versioning can also be used to perform a graceful shutdown or + withdraw of a specific RLOC. This is achieved by simply issuing a + new mapping, with an updated Map-Version number where the specific + RLOC to be shut down is withdrawn or announced as unreachable (via + the R-bit in the Map Record; see [RFC6830]), but without actually + turning it off. + + Once no more traffic is received by the RLOC, it can be shut down + gracefully, because all sites actively using the mapping have + updated it. + + It should be pointed out that for frequent up/down changes such a + mechanism should not be used, since this can generate excessive load + on the mapping system. + + + + + + +Iannone, et al. Experimental [Page 14] + +RFC 6834 LISP Map-Versioning January 2013 + + +8.4. Map-Version for Lightweight LISP Implementation + + The use of Map-Versioning can help in developing a lightweight + implementation of LISP. However, this comes with the price of not + supporting the Locator-Status-Bit, which is useful in some contexts. + + In the current LISP specifications, the set of RLOCs must always be + maintained ordered and consistent with the content of the + Locator-Status-Bits (see Section 6.5 of [RFC6830]). With + Map-Versioning, such types of mechanisms can be avoided. When a new + RLOC is added to a mapping, it is not necessary to "append" new + Locators to the existing ones as explained in Section 6.5 of + [RFC6830]. A new mapping with a new Map-Version number will be + issued, and since the old Locators are still valid, the transition + will occur with no disruptions. The same applies for the case where + an 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; in this case, + the transition will occur with no disruptions. + + All of these operations, as already stated, do not need to maintain + any consistency among Locator-Status-Bits and in the way that the + RLOCs are stored in the EID-to-RLOC Cache. + + Further, Map-Versioning can be used as a substitute for the "clock + sweep" operation described in Section 6.6.1 of [RFC6830]. 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 this section is just an example and + MUST NOT be considered as specifications for a lightweight LISP + implementation. If the IETF decides to undertake such work, it will + be documented elsewhere. + +9. Incremental Deployment and Implementation Status + + Map-Versioning can be incrementally deployed without any negative + impact on existing LISP elements (e.g., xTRs, Map-Servers, + Proxy-ITRs, etc.). Any LISP element that does not support + Map-Versioning can safely ignore Map-Version numbers carried in the + LISP header. Further, there is no need of any specific mechanism to + discover whether or not an xTR supports Map-Versioning. This + information is already included in the Map Record. + + Map-Versioning is currently implemented in OpenLISP [OPENLISP]. + + + + + +Iannone, et al. Experimental [Page 15] + +RFC 6834 LISP Map-Versioning January 2013 + + + Note that the reference document for LISP implementations and + interoperability tests remains [RFC6830]. + +10. Security Considerations + + Map-Versioning does not introduce any security issues concerning both + the data plane and the control plane. On the contrary, as described + below, if Map-Versioning may also be used to update mappings in the + 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. + + Robustness of the Map-Versioning mechanism leverages on a trusted + Mapping Distribution System. A thorough security analysis of LISP is + documented in [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. + + This does not happen in the case of Map-Versioning. As described in + Section 5, upon a version number change the xTR first issues a + Map-Request. The assumption is that the mapping distribution system + is sufficiently secure that Map-Request and Map-Reply messages and + their content can be trusted. Security issues concerning specific + mapping distribution systems are out of the scope of this document. + In the case of Map-Versioning, the attacker should "guess" a valid + version number that triggers a Map-Request as described in Section 5; + otherwise, the packet is simply dropped. Nevertheless, guessing a + version number that generates a Map-Request is easy; hence, it is + important to follow the rate-limitation policies described in + [RFC6830] in order to avoid DoS attacks. + + Note that a similar level of security can be obtained with + Locator-Status-Bits by simply making it mandatory to verify any + change through a Map-Request. However, in this case + Locator-Status-Bits lose their meaning, because it does not matter + anymore which specific bits have changed; the xTR will query the + mapping system and trust the content of the received Map-Reply. + Furthermore, there is no way to perform filtering as in + Map-Versioning in order to drop packets that do not carry a valid + Map-Version number. In the case of Locator-Status-Bits, any random + change can trigger a Map-Request (unless rate limitation is enabled, + which raises another type of attack as discussed in Section 10.2). + + + + +Iannone, et al. Experimental [Page 16] + +RFC 6834 LISP Map-Versioning January 2013 + + +10.2. Map-Versioning against Reachability Information DoS + + Attackers can try to trigger a large amount of Map-Requests by simply + forging packets with random Map-Versions or random + Locator-Status-Bits. In both cases, the Map-Requests are + rate-limited as described in [RFC6830]. However, in contrast to the + Locator-Status-Bit, where there is no filtering possible, in the case + of Map-Versioning it is possible to filter invalid version numbers + before triggering a Map-Request, thus helping to reduce the effects + of DoS attacks. In other words, the use of Map-Versioning enables a + fine control on when to update a mapping or when to notify someone + that a mapping has been updated. + + It is clear that Map-Versioning does not protect against DoS and DDoS + attacks, where an xTR loses processing power when doing checks on the + LISP header of packets sent by attackers. This is independent of + Map-Versioning and is the same for Locator-Status-Bits. + +11. 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 for ETR synchronization. The implications that a + temporary lack of synchronization may have on the traffic are yet + to be fully explored. Details on how to maintain synchronization + are presented in Section 6.6 of [RFC6830]. Section 11.1 discusses + the issue in further detail with respect to the Map-Versioning + mechanism. + + The authors expect that experimentation will help assess the + performance and limitations of the Map-Versioning mechanism. Issues + and concerns about the deployment of LISP for Internet traffic are + discussed in [RFC6830]. + +11.1. Lack of Synchronization among ETRs + + Even without Map-Versioning, LISP ([RFC6830]) 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 are yet to be fully explored. + + + + + +Iannone, et al. Experimental [Page 17] + +RFC 6834 LISP Map-Versioning January 2013 + + + Map-Versioning does not require additional synchronization mechanisms + as compared to the normal functioning of LISP without Map-Versioning. + Clearly, all the ETRs have to reply with the same Map-Version number; + otherwise, there can be an inconsistency that creates additional + control traffic, instabilities, and traffic disruptions. It is the + same without Map-Versioning, with ETRs that have to reply with the + same mapping; otherwise, the same problems can arise. + + 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. + + As an example, let's consider the topology of Figure 4 where ITR A.1 + of Domain A is sending unidirectional traffic to Domain B, while A.2 + of Domain A exchanges bidirectional traffic with Domain B. In + particular, ITR A.2 sends traffic to ETR B, and ETR A.2 receives + traffic from ITR B. + + +-----------------+ +-----------------+ + | Domain A | | Domain B | + | +---------+ | | + | | ITR A.1 |--- | | + | +---------+ \ +---------+ | + | | ------->| ETR B | | + | | ------->| | | + | +---------+ / | | | + | | ITR A.2 |--- -----| ITR B | | + | | | / +---------+ | + | | ETR A.2 |<----- | | + | +---------+ | | + | | | | + +-----------------+ +-----------------+ + + Figure 4: Example Topology + + Obviously, in the case of Map-Versioning, both ITR A.1 and ITR A.2 of + Domain A must use the same value; otherwise, the ETR of Domain B will + start to send Map-Requests. + + The same problem can, however, arise without Map-Versioning, for + instance, if the two ITRs of Domain A send different + Locator-Status-Bits. In this case, either the traffic is disrupted + if ETR B trusts the Locator-Status-Bits, or if ETR B does not trust + the Locator-Status-Bits it will start sending Map-Requests to confirm + each change in reachability. + + + +Iannone, et al. Experimental [Page 18] + +RFC 6834 LISP Map-Versioning January 2013 + + + So far, LISP does not provide any specific synchronization mechanism + but assumes that synchronization is provided by configuring the + different xTRs consistently (see Section 6.6 in [RFC6830]). The same + applies for Map-Versioning. If in the future any synchronization + mechanism is provided, Map-Versioning will take advantage of it + automatically, since it is included in the Record format, as + described in Section 7. + +12. Acknowledgments + + The authors would like to thank Alia Atlas, Jesper Skriver, Pierre + Francois, Noel Chiappa, and Dino Farinacci for their comments and + review. + + This work has been partially supported by the INFSO-ICT-216372 + TRILOGY Project (http://www.trilogy-project.org). + +13. References + +13.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The + Locator/ID Separation Protocol (LISP)", RFC 6830, + January 2013. + + [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, + "Interworking between Locator/ID Separation Protocol + (LISP) and Non-LISP Sites", RFC 6832, January 2013. + +13.2. Informative References + + [LISP-THREATS] + Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats + Analysis", Work in Progress, October 2012. + + [OPENLISP] Iannone, L., Saucez, D., and O. Bonaventure, "Implementing + the Locator/ID Separation Protocol: Design and + experience", Computer Networks Vol. 55, Number 4, + Pages 948-958, March 2011. + + + + + + + + + +Iannone, et al. Experimental [Page 19] + +RFC 6834 LISP Map-Versioning January 2013 + + +Appendix A. Estimation of Time before Map-Version Wrap-Around + + This section proposes an estimation of the wrap-around time for the + 12-bit size of the Map-Version number. + + Using a granularity of seconds and assuming as worst case that a new + version is issued each second, it takes slightly more than 1 hour + before the version wraps around. Note that the granularity of + seconds is in line with the rate-limitation policy for Map-Request + messages, as proposed in the LISP main specifications ([RFC6830]). + + Alternatively, a granularity of minutes can also be used, as for the + TTL of the Map-Reply ([RFC6830]). In this case, the worst-case + scenario is when a new version is issued every minute, leading to a + much longer time before wrap-around. In particular, when using + 12 bits, the wrap-around time is almost 3 days. + + For general information, Figure 5 below provides a rough estimation + of the time before wrap-around in the worst-case scenario, + considering different sizes (length in bits) of the Map-Version + number and different time granularities. + + Since even in the case of a high mapping change rate (1 per second) + the wrap-around time using 12 bits is far larger than any reasonable + Round-Trip Time (RTT), there is no risk of race conditions. + + +---------------+--------------------------------------------+ + |Version Number | Time before Wrap-Around | + | Size (bits) +---------------------+----------------------+ + | |Granularity: Minutes | Granularity: Seconds | + | | (mapping changes | (mapping changes | + | | every 1 minute) | every 1 second) | + +-------------------------------------+----------------------+ + | 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 | + | 13 | 5.6 days | 2.2 hours | + | 12 | 2.8 days | 1.1 hours | + +---------------+---------------------+----------------------+ + + Figure 5: Estimation of Time before Wrap-Around + + + + + + + +Iannone, et al. Experimental [Page 20] + +RFC 6834 LISP Map-Versioning January 2013 + + +Authors' Addresses + + Luigi Iannone + Telecom ParisTech + + EMail: luigi.iannone@telecom-paristech.fr + + + Damien Saucez + INRIA Sophia Antipolis + 2004 route des Lucioles - BP 93 + Sophia Antipolis + France + + EMail: damien.saucez@inria.fr + + + Olivier Bonaventure + Universite catholique de Louvain + Place St. Barbe 2 + Louvain-la-Neuve + Belgium + + EMail: olivier.bonaventure@uclouvain.be + + + + + + + + + + + + + + + + + + + + + + + + + + + +Iannone, et al. Experimental [Page 21] + -- cgit v1.2.3