Network Working Group L. Iannone
Internet-Draft TU Berlin - Deutsche Telekom
Intended status: Experimental Laboratories AG
Expires: September 9, 2010 D. Saucez
O. Bonaventure
Universite catholique de Louvain
March 8, 2010
LISP Mapping Versioning
draft-iannone-lisp-mapping-versioning-01.txt
Abstract
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.
Status of this Memo
Iannone, et al. Expires September 9, 2010 [Page 1]
Internet-Draft LISP Mapping Versioning March 2010
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 Notice
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.
Iannone, et al. Expires September 9, 2010 [Page 2]
Internet-Draft LISP Mapping Versioning March 2010
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. EID-to-RLOC Mapping Version Number . . . . . . . . . . . . . . 7
3.1. Mapping Version Numbers wrap-around . . . . . . . . . . . 7
4. Dealing with Version Numbers . . . . . . . . . . . . . . . . . 9
4.1. Handling Destination Mapping Version Number . . . . . . . 9
4.2. Handling Source Mapping Version Number . . . . . . . . . . 10
5. LISP header and Mapping Version Numbers . . . . . . . . . . . 12
6. Map Record and Mapping Version Number . . . . . . . . . . . . 14
7. Benefits and case studies for Mapping Versioning . . . . . . . 15
7.1. Mapping Versioning to simplify LISP implementation . . . . 15
7.2. Synchronization of different xTRs . . . . . . . . . . . . 15
7.3. Map Versioning and unidirectional traffic . . . . . . . . 16
7.4. Mapping Versioning and interworking . . . . . . . . . . . 17
7.5. Mapping Versioning vs. Checksum . . . . . . . . . . . . . 17
7.6. Mapping Versioning and mobility . . . . . . . . . . . . . 17
8. Incremental deployment and implementation status . . . . . . . 19
9. Mapping Versioning and path-liveness . . . . . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10.1. Mapping Versioning against traffic disruption . . . . . . 21
10.2. Mapping Versioning against reachability information DoS . 21
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Iannone, et al. Expires September 9, 2010 [Page 3]
Internet-Draft LISP Mapping Versioning March 2010
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Iannone, et al. Expires September 9, 2010 [Page 4]
Internet-Draft LISP Mapping Versioning March 2010
2. Introduction
The present document introduces the use of version numbers in order
to provide information on a change in the EID-to-RLOC mappings used
in the LISP ([I-D.ietf-lisp] ) 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].
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. 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:
1. The version number assigned to the mapping (contained in the EID-
to-RLOC Database) used to select the source RLOC.
2. The version number assigned to the mapping (contained in the EID-
to-RLOC Cache) used to select the destination RLOC.
This operation is two-fold. On the one hand it enables the ETR
receiving the packet to know if the ITR that sent it is using the
latest mapping for the destination EID. If it is not the case the
ETR 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]). 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
Iannone, et al. Expires September 9, 2010 [Page 5]
Internet-Draft LISP Mapping Versioning March 2010
distribution protocol (e.g., CONS, TREE, ALT [I-D.ietf-lisp-alt]).
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.
Iannone, et al. Expires September 9, 2010 [Page 6]
Internet-Draft LISP Mapping Versioning March 2010
3. EID-to-RLOC 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.
3.1. Mapping Version Numbers wrap-around
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]). 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.
Iannone, et al. Expires September 9, 2010 [Page 7]
Internet-Draft LISP Mapping Versioning March 2010
+---------------+--------------------------------------------+
|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
Iannone, et al. Expires September 9, 2010 [Page 8]
Internet-Draft LISP Mapping Versioning March 2010
4. Dealing with Version Numbers
The main idea of using Mapping Version Numbers is that whenever there
is a change in the mapping (e.g., adding/removing RLOCs, a change in
the weights due to new TE policies, or a change in the priorities) or
an ISP realizes that one or more of its own RLOCs are not reachable
anymore from a local perspective (e.g., through IGP, 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:
o A first one from the EID-to-RLOC mapping in the EID-to-RLOC
Database used to select the source RLOC, and called Source Mapping
Version Number.
o A second one from the EID-to-RLOC mapping in the EID-to-RLOC Cache
used to select the destination RLOC, and called Destination
Mapping Version Number.
By embedding both Source Mapping Version Number and Destination
Mapping Version Number an ETR can perform the following checks:
1. The ITR has an up-to-date mapping in its cache for the
destination EID and is performing encapsulation correctly.
2. The mapping in the local ETR 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 4.1) or to updated local mapping in the cache
(see section Section 4.2).
4.1. Handling Destination 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:
Iannone, et al. Expires September 9, 2010 [Page 9]
Internet-Draft LISP Mapping Versioning March 2010
o The packets arrive with the same Destination Mapping 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.
o The packet arrives with a Destination Mapping Version Number
greater (i.e., newer) than the one stored in the EID-to-RLOC
Database. Since the ETR is authoritative on the mapping, this
means that someone is not behaving correctly w.r.t. the
specifications, thus the packets carries a not valid version
number and can be silently dropped.
o The packets arrive with an Destination Mapping 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.
Further actions are needed. The ITR sending the packet must 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
piggy-back the newer mapping. This is not a new mechanism, how to
piggy-back mappings in Map-Request messages is already described
in [I-D.ietf-lisp]. These Map-Request message should be rate
limited (rate limitation policies are also described in
[I-D.ietf-lisp]). The gain introduced by Mapping Version Numbers
is that after a certain number of retries, if the Destination
Mapping Version Number in the packets is not updated, packet can
be silently dropped because either the ITR is refusing to use the
mapping for which the ETR is authoritative or it might be some
form of attack. Note that the rule can be even more restrictive.
If the mapping has been the same for a period of time as long as
the TTL (defined in LISP [I-D.ietf-lisp]) of the previous version
of the mapping, all packets arriving with an old mapping version
can be silently dropped right away without issuing any Map-
Request. Indeed, if the new mapping with the updated version
number has been stable for at least the same time as the TTL of
the older mapping, all the entries in the caches of ITRs must have
expired. If packets with old mapping version number are still
received, the reason is that either someone has not respected the
TTL, or it is a spoof. In both cases this is not valid behavior
w.r.t. the specifications and the packet can be silently dropped.
4.2. Handling Source Mapping Version Number
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:
Iannone, et al. Expires September 9, 2010 [Page 10]
Internet-Draft LISP Mapping Versioning March 2010
o The packet arrives with the same Source Mapping Version Number
stored in the LISP Cache. This is the correct regular case. The
ETR has in its cache an up-to-date copy of the mapping. No
further actions are needed.
o The packet arrives with a Source Mapping Version Number greater
(i.e., newer) than the one stored in the local LISP Cache. This
means that ETR has in its cache a mapping that is stale and needs
to be updated. The packet is considered valid but further actions
are needed. In particular a Map-Request must be sent to get the
new mapping for the source EID. This is a normal Map-Request
message and must respect the specifications in [I-D.ietf-lisp].
o The packet arrives with a Source Mapping Version Number smaller
(i.e., older) than the one stored in the local LISP Cache. Such a
case is not valid w.r.t. the specifications. Indeed, if the
mapping is already present in the LISP Cache, this means that an
explicit Map-Request has been send and a Map-Reply has been
received from an authoritative source. Assuming that the mapping
system is not corrupted anyhow, the mapping version in the LISP
Cache is the correct one, hence the packet is not valid and can be
silently dropped.
Iannone, et al. Expires September 9, 2010 [Page 11]
Internet-Draft LISP Mapping Versioning March 2010
5. LISP header and Mapping Version Numbers
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Iannone, et al. Expires September 9, 2010 [Page 12]
Internet-Draft LISP Mapping Versioning March 2010
V: 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]) 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.
Iannone, et al. Expires September 9, 2010 [Page 13]
Internet-Draft LISP Mapping Versioning March 2010
6. Map Record and Mapping Version Number
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].
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]) are able to carry version numbers without
needing any modification. The same applies to the LISP Map Server
([I-D.ietf-lisp-ms]) which will still work without any change since
reserved bits are simply ignored.
Iannone, et al. Expires September 9, 2010 [Page 14]
Internet-Draft LISP Mapping Versioning March 2010
7. Benefits and case studies for Mapping Versioning
In the following sections we provide more discussion on various
aspects of the mapping versioning. Security observations are instead
grouped in Section 10.
7.1. Mapping Versioning to simplify LISP implementation
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]).
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.
7.2. Synchronization of different xTRs
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
Iannone, et al. Expires September 9, 2010 [Page 15]
Internet-Draft LISP Mapping Versioning March 2010
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 is used.
7.3. Map Versioning and unidirectional traffic
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
Iannone, et al. Expires September 9, 2010 [Page 16]
Internet-Draft LISP Mapping Versioning March 2010
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, ignoring
the source mapping version number.
7.4. Mapping Versioning and interworking
Mapping versioning works also in the context of interworking between
LISP and IPv4 and IPv6 ([I-D.ietf-lisp-interworking]). 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.
7.5. Mapping Versioning vs. Checksum
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) 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.
7.6. Mapping Versioning and mobility
Mapping versioning can help in managing mobility in the LISP context
([I-D.meyer-lisp-mn]). We are working in deploying Mapping
Versioning on a Wireless Mesh Network. Results concerning this
Iannone, et al. Expires September 9, 2010 [Page 17]
Internet-Draft LISP Mapping Versioning March 2010
deployment will be provided in future versions of this document.
Iannone, et al. Expires September 9, 2010 [Page 18]
Internet-Draft LISP Mapping Versioning March 2010
8. Incremental deployment and implementation status
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].
Note that the reference document for LISP implementation and
interoperability tests remains [I-D.ietf-lisp].
Iannone, et al. Expires September 9, 2010 [Page 19]
Internet-Draft LISP Mapping Versioning March 2010
9. Mapping Versioning and path-liveness
When the reachability problem occurs on the path between two RLOCs of
different LISP sites (this is called path-liveness problem in the
recent draft by D. Meyer and D. Lewis
[I-D.meyer-loc-id-implications]), the versioning approach does not
help. In this case other mechanisms are necessary, however, such an
issue is not new and is part of all loc/ID split solutions, thus
versioning does not introduce a new issue.
Iannone, et al. Expires September 9, 2010 [Page 20]
Internet-Draft LISP Mapping Versioning March 2010
10. Security Considerations
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.
10.1. Mapping Versioning against traffic disruption
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, 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, 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).
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]. 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
Iannone, et al. Expires September 9, 2010 [Page 21]
Internet-Draft LISP Mapping Versioning March 2010
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.
Iannone, et al. Expires September 9, 2010 [Page 22]
Internet-Draft LISP Mapping Versioning March 2010
11. Acknowledgements
The authors would like to thank Pierre Francois, Noel Chiappa, Dino
Farinacci for their comments and review.
Iannone, et al. Expires September 9, 2010 [Page 23]
Internet-Draft LISP Mapping Versioning March 2010
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
12.2. Informative References
[I-D.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]
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-06 (work in progress), January 2010.
[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.
[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.
[I-D.ietf-lisp-ms]
Fuller, V. and D. Farinacci, "LISP Map Server",
draft-ietf-lisp-ms-04 (work in progress), October 2009.
[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.
[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.
Iannone, et al. Expires September 9, 2010 [Page 24]
Internet-Draft LISP Mapping Versioning March 2010
Authors' Addresses
Luigi Iannone
TU Berlin - Deutsche Telekom Laboratories AG
Ernst-Reuter Platz 7
Berlin
Germany
Email: luigi@net.t-labs.tu-berlin.de
Damien Saucez
Universite catholique de Louvain
Place St. Barbe 2
Louvain la Neuve
Belgium
Email: damien.saucez@uclouvain.be
Olivier Bonaventure
Universite catholique de Louvain
Place St. Barbe 2
Louvain la Neuve
Belgium
Email: olivier.bonaventure@uclouvain.be
Iannone, et al. Expires September 9, 2010 [Page 25]