The present document sketches an optional approach to provide in-packet information about 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. This versioning approach is particularly useful to inform communicating xTRs about modification of the mappings used to encapsulate packets. Modification of mappings could mean adding/removing an RLOC, or just a modification in the reachability, priority, or weight of one or more RLOCs. Each time a mapping is modified, a new version number is generated and propagated in the LISP data packet. The use of version numbers allows to avoid repeated Map-Request upon mappings change, limits the interaction between Control and Data planes, improves security, offer support for caching on Map-Servers, and could be used also in mobile scenarios.
The proposed mechanism is optional and does not need any modification on the base LISP encapsulation. Rather, it uses one of the reserved bits of the LISP specific header and overloads the Locator Status Bits. Similarly, no modification are necessary in the base LISP Map-Reply records. LISP versioning uses part of the reserved bits. In both cases, LISP encapsulation and Map-Reply records, bits used for LISP versioning can be safely ignored by xTRs that do not support the mechanism. Further, mappings can be distributed as usual through both existing and future mapping distribution system (e.g., ALT). The infrastructure build by each specific mapping distribution system does not change anyhow. Even more, existing mapping distribution protocol are able to rely LISP control plane packets containing version numbers and do not need modifications. All of these features make LISP versioning a completely transparent optional mechanism with respect to the LISP base specification.
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 9, 2010.
Copyright (c) 2010 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 BSD License.
3. EID-to-RLOC Mapping Version Number
3.1. Mapping Version Numbers wrap-around
4. Dealing with Version Numbers
4.1. Handling Destination Mapping Version Number
4.2. Handling Source Mapping Version Number
5. LISP header and Mapping Version Numbers
6. Map Record and Mapping Version Number
7. Benefits and case studies for Mapping Versioning
7.1. Mapping Versioning to simplify LISP implementation
7.2. Synchronization of different xTRs
7.3. Map Versioning and unidirectional traffic
7.4. Mapping Versioning and interworking
7.5. Mapping Versioning vs. Checksum
7.6. Mapping Versioning and mobility
8. Incremental deployment and implementation status
9. Mapping Versioning and path-liveness
10. Security Considerations
10.1. Mapping Versioning against traffic disruption
10.2. Mapping Versioning against reachability information DoS
12.1. Normative References
12.2. Informative References
§ Authors' Addresses
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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
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.ietf‑lisp] (Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, “Locator/ID Separation Protocol (LISP),” January 2010.) ) context to perform encapsulation. The mechanism is optional and totally transparent to xTRs not supporting such a functionality. The basic mechanism is to associate version numbers to each 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. 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] (Meyer, D. and D. Lewis, “Architectural Implications of Locator/ID Separation,” January 2009.).
With this approach, LISP-encapsulated data packets contain the version number of the mappings used to select the RLOCs in the outer header (both source and destination). These version numbers are contained in the second 32-bits of the LISP header and indicated a specific bit in the reserved flags (first 8 bits of the LISP header. Details about the header are described in Section 5 (LISP header and Mapping Version Numbers). Note that it is not all packets need to carry version numbers.
When an ITR encapsulates a packet, it puts in the LISP-specific header two version numbers:
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 can send to the ITR a Map-Request containing the updated mapping or invoking a Map-Request from the ITR (both cases are already defined in [I‑D.ietf‑lisp] (Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, “Locator/ID Separation Protocol (LISP),” January 2010.)). In this way the ITR can update its cache. 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. Is it is not the case a Map-Request can be send.
With Mapping Versioning there is no need to re-design the mapping distribution infrastructure, which is always done through the mapping distribution protocol (e.g., CONS, TREE, ALT [I‑D.ietf‑lisp‑alt] (Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, “LISP Alternative Topology (LISP+ALT),” January 2010.)). The mappings are distributed as usual through the Map-Request/Map-Reply message exchange. Map-Request and Map-Reply messages can carry mapping version in bits that are reserved (in the current version of the LISP specifications). Details on how to carry mapping version numbers in those messages are given in section Section 6 (Map Record and Mapping Version Number).
The EID-to-RLOC Mapping Version Number consist in an unsigned 16-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 initial version number of a new mapping can be randomly generated.
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 current 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)).
Using 16 bits, as proposed in this document, and if the Mapping Version Number is 0, versions in [1; (2**15)-1] are greater and versions in [2**15; (2**16)-1] are smaller.
The proposed 16 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 as worst case that a new version is issued each second, it takes around 18 hours 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.ietf‑lisp] (Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, “Locator/ID Separation Protocol (LISP),” January 2010.)). Using a granularity of minutes leads to very long time before wrap-around. Hereafter there is a table with a rough estimation of the time before wrap-around happens considering different sizes of the Mapping 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: Estimation of time before wrap-around |
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, 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, mapping 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 mapping version numbers:
By embedding both Source Mapping Version Number and Destination Mapping Version Number an ETR can perform the following checks:
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 4.1 (Handling Destination Mapping Version Number)) or to updated local mapping in the cache (see section Section 4.2 (Handling Source Mapping Version Number)).
When an ETR receives a packet, the Destination Mapping Version Number relates to the mapping for the destination EID for which the ETR is a RLOC. This mapping is part of the ETR LISP Database. Since the ETR is authoritative for the mapping, it has the correct and up-to-date Destination Mapping Version Number. A check on this version number is done, where the following cases can arise:
When an ETR receives a packet, the Source Mapping Version Number relates to the mapping for the source EID for which the ITR is authoritative. If the ETR has an entry in its LISP Cache a check is performed and the following cases can arise:
In order for the versioning approach to work, the LISP specific header has to carry both Source Mapping Version Number and Destination Mapping Version Number. This can be done by using one bit (indicated by V) of the reserved flags to state that the second 32 bits of the LISP header have to be interpreted as two version numbers of 16 bits each. The Source Version Number is carried in the 16 most significant bits of the second 32-bits of the LISP header. The Destination Version Number is carried in the 16 most significant bits of the second 32-bits of the LISP header.
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, 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /|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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |N|L|E|V| rflags| Nonce | LISP+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Source Mapping V.N. | Destination Mapping V.N. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /|Version| IHL |Type of Service| Total Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Identification |Flags| Fragment Offset | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IH | Time to Live | Protocol | Header Checksum | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Source EID | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \| Destination EID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- this is the Versioning bit. When this bit is set to 1 the second 32-bits of the LISP header contain version numbers.
- Source Mapping Version Number (16 bits):
- Version of the mapping used by the ITR to select the RLOC present in the "Source Routing Locator" field. Note that the mapping used for such a selection is determined by the Source EID through asearch in the LISP Database of the ITR.
- Destination Mapping Version Number (16 bits):
- Version of the mapping used by the ITR to select the RLOC present 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 LISP Cache of the ITR.
Not all of the LISP encapsulated packets need to carry version numbers. When mapping version number are carried the V bit must be set to 1. The V bit is conflict with the L bit, since both relate to the second 32 bits of the LISP header. The possible combinations (and related meaning) for L and V bits are the following:
- L=0, V=0:
- This is a valid combination. In this case neither Locator-Status-Bits nor Version Number are used. The second 32 bits of the LISP header can be ignored.
- L:0 V:1
- This is a valid combination. In this case the second 32 bits of the LISP header contain version numbers and should be treated according to the present document.
- L:1 V:1
- This is no a valid combination since two different bits indicate different content for the same 32 bits. For compatibility with the LISP specifications ([I‑D.ietf‑lisp] (Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, “Locator/ID Separation Protocol (LISP),” January 2010.)) each time the the L bit is set to 1 the V bit must be ignored and the second 32 bits of the LISP header interpreted as Locator-Status-Bits. This approach ensures transparent and coherent interoperability between xTRs using Versioning and xTRs that do not use it.
- L:1 V:0
- This is a valid combination. In this case the second 32 bits of the LISP header contain Locator-Status-Bit. Note that according with the previous combination, since the L bit is set to 1 the V bit can be safely ignored.
To accommodate the proposed mechanism, the Map records that are transported on Map-Request/Map-Reply messages need to carry the Mapping Version Number as well. For this purpose it is possible to use part of the reserved bits of the record. The original definition of Record is in [I‑D.ietf‑lisp] (Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, “Locator/ID Separation Protocol (LISP),” January 2010.).
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|V| Reserved | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c | Mapping Version Number | EID- AFI | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | EID-prefix | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Loc| Unused Flags |R| Loc-AFI | | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Mapping Version Number:
- Version Number of the mapping in the Record.
This is a simple change to carry the version number assigned to the mapping in this message and works perfectly with xTR that do not support mapping versioning, since they can simply ignore those bits. Furthermore, existing and futre mapping distribution protocol (e.g., ALT [I‑D.ietf‑lisp‑alt] (Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, “LISP Alternative Topology (LISP+ALT),” January 2010.)) are able to carry version numbers without needing any modification. The same applies to the LISP Map Server ([I‑D.ietf‑lisp‑ms] (Fuller, V. and D. Farinacci, “LISP Map Server,” October 2009.)) which will still work without any change since reserved bits are simply ignored.
In the following sections we provide more discussion on various aspects of the mapping versioning. Security observations are instead grouped in Section 10 (Security Considerations).
The use of mapping versioning can help in simplifying the implementation of LISP. In the current LISP specifications the set of RLOCs must always be maintained ordered and consistent with the content of the Loc Status Bits (see section 6.5 of [I‑D.ietf‑lisp] (Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, “Locator/ID Separation Protocol (LISP),” January 2010.)). When using mapping versioning such type of mechanisms are not necessary anymore since there is no direct relation between the order of the locators and the bits of the mapping version number.
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 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 is the case when using Loc Status Bits, 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 or announced as unreachable (R bit in the Map Record), but without actually turning it off. Once no more traffic is received by the RLOC, because all sites have updated the mapping, it can be shut down safely.
All of these operations, as already stated, do not need to maintain any consistency among Loc Status 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.
Mapping Versioning does not require additional synchronization mechanism compared to the normal functioning of LISP without mapping versioning. Clearly all the ETRs have to reply with the same versioning number, otherwise there can be an inconsistency that creates additional control traffic.
As an example, let's consider the topology of figure Figure 2 where ITR A.1 of domain A is sending unidirectional traffic to the xTR B of domain B, while xTR A.2 of domain A and xTR B of domain B exchange bidirectional traffic.
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | Domain A | | Domain B | | +-+-+-+-+-+ | | | | xTR A.1 |--- | | | +-+-+-+-+-+ \ +-+-+-+-+-+ | | | -------->| xTR B | | | | -------->| | | | +-+-+-+-+-+ / +-+-+-+-+-+ | | | xTR A.2 |<-- | | | +-+-+-+-+-+ | | | | | | +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+
| Figure 2 |
Obviously in the case of Mapping Versioning both xTRs of domain A must use the same value otherwise the xTR of domain B will start to sen Map-Requests.
The same problem can, however, arise without mapping versioning. For instance if the two xTRs of domain A send different Loc Status Bits. In this case either the traffic is disrupted, if the xTR B trusts the Loc Status Bits, or it xTR B will start sending Map-Requests to confirm the each change in the reachability.
So far, LISP does not provide any specific synchronization mechanism, but assumes that synchronization is provided by configuring the different xTRs consistently. The same applies for mapping versioning. If in the future any synchronization mechanism is provided, mapping versioning will take advantage of it automatically if the record format described in Section 6 (Map Record and Mapping Version Number) is used.
When using mapping versioning as specified in this document the
LIS specific header carries two mapping version numbers,
for both source and destination mapping.
This can raise the question on what will happen in the case of
unidirectional flows, like for instance in the case presented in
Figure 3, since LISP specification do
not mandate for ETR to have a mapping for the source EID.
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | Domain A | | Domain B | | +-+-+-+-+-+ +-+-+-+-+-+ | | | ITR A |----------->| ETR B | | | +-+-+-+-+-+ +-+-+-+-+-+ | | | | | +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+
| Figure 3 |
For what concerns the ITR, it is able to put both source and destination version number in the LISP header since the source mapping version number is in ITR's database, while the destination mapping version number is in ITR's cache.
For what concerns the ETR, it simply checks only the destination version number in the same way as described in Section 4 (Dealing with Version Numbers), ignoring the source mapping version number.
Mapping versioning works also in the context of interworking between LISP and IPv4 and IPv6 ([I‑D.ietf‑lisp‑interworking] (Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, “Interworking LISP with IPv4 and IPv6,” May 2009.)). The case of PTR encapsulating packet for LISP sites is basically the same as the unidirectional traffic case presented in the previous section. The same rules can be applied.
Noel Chiappa has several times proposed on the LISP WG mailing list to use a form of "checksum" as a mapping version number. This is an interesting idea. Nevertheless, from our understanding, this implies that the notion of ordering between different mappings for the same EID-Prefix (e.g., whether a mapping is more recent) get lost. This means that a large part of the filtering that can be done on not valid version numbers (see Section 4 (Dealing with Version Numbers)) cannot be done anymore, hence loosing an important feature of mapping versioning. Certainly, if it would be possible to find a "checksum" function that embeds some form of ordering, this can be discussed and integrated in future version of this document.
Mapping versioning can help in managing mobility in the LISP context ([I‑D.meyer‑lisp‑mn] (Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, “LISP Mobile Node,” February 2010.)). We are working in deploying Mapping Versioning on a Wireless Mesh Network. Results concerning this deployment will be provided in future versions of this document.
The solution proposed in this draft includes the use of bits that are marked as reserved in the main LISP specifications. This means that any LISP element that does not support Mapping Versioning will safely ignore them. Further, there is no need of any specific mechanism to discover if an xTR supports or not Mapping Versioning. This information is already included in the Map Record.
Mapping Versioning can be incrementally deployed without any negative impact on existing LISP xTRs. Mapping Versioning is currently implemented in OpenLISP [I‑D.iannone‑openlisp‑implementation] (Iannone, L., Saucez, D., and O. Bonaventure, “OpenLISP Implementation Report,” July 2008.).
Note that the reference document for LISP implementation and interoperability tests remains [I‑D.ietf‑lisp] (Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, “Locator/ID Separation Protocol (LISP),” January 2010.).
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] (Meyer, D. and D. Lewis, “Architectural Implications of Locator/ID Separation,” January 2009.)), 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.
Mapping Versioning does not introduces any new security issue concerning both the data-plane and the control-plane. On the contrary, as described in the following, if Mapping Versioning is used also to update mappings in case of change in the reachability information (i.e., instead of the Loc Status Bits) it is possible to reduce the effects of some DoS or spoofing attacks that can happen in an untrusted environment.
An attacker can try to disrupt ongoing communications by creating LISP encapsulated packets with wrong Loc Status Bits. If the xTR blindly trusts the Loc Status Bits it will change the encapsulation accordingly, which can result in traffic disruption.
This does not happen in the case of Mapping Versioning. As described in Section 4 (Dealing with Version Numbers), 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 system are out of the scope of this document. Note also that in the case of Mapping Versioning the attacker should "guess" a valid version number that triggers a Map-Request, as described in Section 4 (Dealing with Version Numbers), otherwise the packet is simply dropped.
Note that a similar level of security can be obtained with Loc Status Bits, by simply making mandatory to verify any change through a Map-Request. However, in this case Loc Status Bits loose their meaning, because, it does not matter anymore which specific bits has 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 the mapping versioning in order to drop packets that do not carry a valid mapping version number. In the case of Loc Status Bits, any random change can trigger a Map-Request (unless rate limitation is enabled which raise another type of attack discussed in Section 10.2 (Mapping Versioning against reachability information DoS)).
Attackers can try to trigger a large amount of Map-Request by simply by forging packets with random mapping version or random Loc Status Bits. In both cases the Map-Requests are rate limited as described in [I‑D.ietf‑lisp] (Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, “Locator/ID Separation Protocol (LISP),” January 2010.). However, differently from Loc Status Bit where there is no filtering possible, in the case of mapping versioning is possible to filter not valid version numbers before triggering a Map-Request, thus helping in reducing the effects of DoS attacks. In other words the use of mapping versioning enables a fine control on when to update a mapping or when to notify that a mapping has been updated.
It is clear, that mapping 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 mapping versioning and is the same for Loc Status Bits.
The authors would like to thank Pierre Francois, Noel Chiappa, Dino Farinacci for their comments and review.
|[RFC2119]||Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).|
|[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 (TXT).|
|[I-D.ietf-lisp]||Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, “Locator/ID Separation Protocol (LISP),” draft-ietf-lisp-06 (work in progress), January 2010 (TXT).|
|[I-D.ietf-lisp-alt]||Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, “LISP Alternative Topology (LISP+ALT),” draft-ietf-lisp-alt-02 (work in progress), January 2010 (TXT).|
|[I-D.ietf-lisp-interworking]||Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, “Interworking LISP with IPv4 and IPv6,” draft-ietf-lisp-interworking-00 (work in progress), May 2009 (TXT).|
|[I-D.ietf-lisp-ms]||Fuller, V. and D. Farinacci, “LISP Map Server,” draft-ietf-lisp-ms-04 (work in progress), October 2009 (TXT).|
|[I-D.meyer-lisp-mn]||Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, “LISP Mobile Node,” draft-meyer-lisp-mn-01 (work in progress), February 2010 (TXT).|
|[I-D.meyer-loc-id-implications]||Meyer, D. and D. Lewis, “Architectural Implications of Locator/ID Separation,” draft-meyer-loc-id-implications-01 (work in progress), January 2009 (TXT).|
|TU Berlin - Deutsche Telekom Laboratories AG|
|Ernst-Reuter Platz 7|
|Universite catholique de Louvain|
|Place St. Barbe 2|
|Louvain la Neuve|
|Universite catholique de Louvain|
|Place St. Barbe 2|
|Louvain la Neuve|