draft-ietf-lisp-6834bis-07.txt   draft-ietf-lisp-6834bis-08.txt 
Network Working Group L. Iannone Network Working Group L. Iannone
Internet-Draft Huawei Technologies France S.A.S.U Internet-Draft Huawei Technologies France S.A.S.U
Obsoletes: 6834 (if approved) D. Saucez Obsoletes: 6834 (if approved) D. Saucez
Intended status: Standards Track INRIA Intended status: Standards Track INRIA
Expires: April 18, 2021 O. Bonaventure Expires: September 25, 2021 O. Bonaventure
Universite catholique de Louvain Universite catholique de Louvain
October 15, 2020 March 24, 2021
Locator/ID Separation Protocol (LISP) Map-Versioning Locator/ID Separation Protocol (LISP) Map-Versioning
draft-ietf-lisp-6834bis-07 draft-ietf-lisp-6834bis-08
Abstract Abstract
This document describes the LISP (Locator/ID Separation Protocol) This document describes the LISP (Locator/ID Separation Protocol)
Map-Versioning mechanism, which provides in-packet information about Map-Versioning mechanism, which provides in-packet information about
Endpoint ID to Routing Locator (EID-to-RLOC) mappings used to Endpoint ID to Routing Locator (EID-to-RLOC) mappings used to
encapsulate LISP data packets. The proposed approach is based on encapsulate LISP data packets. The proposed approach is based on
associating a version number to EID-to-RLOC mappings and the associating a version number to EID-to-RLOC mappings and the
transport of such a version number in the LISP-specific header of transport of such a version number in the LISP-specific header of
LISP-encapsulated packets. LISP Map-Versioning is particularly LISP-encapsulated packets. LISP Map-Versioning is particularly
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 18, 2021. This Internet-Draft will expire on September 25, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 42 skipping to change at page 2, line 42
7. Map Record and Map-Version . . . . . . . . . . . . . . . . . 10 7. Map Record and Map-Version . . . . . . . . . . . . . . . . . 10
8. Benefits and Case Studies for Map-Versioning . . . . . . . . 11 8. Benefits and Case Studies for Map-Versioning . . . . . . . . 11
8.1. Map-Versioning and Unidirectional Traffic . . . . . . . . 11 8.1. Map-Versioning and Unidirectional Traffic . . . . . . . . 11
8.2. Map-Versioning and Interworking . . . . . . . . . . . . . 12 8.2. Map-Versioning and Interworking . . . . . . . . . . . . . 12
8.2.1. Map-Versioning and Proxy-ITRs . . . . . . . . . . . . 12 8.2.1. Map-Versioning and Proxy-ITRs . . . . . . . . . . . . 12
8.2.2. Map-Versioning and LISP-NAT . . . . . . . . . . . . . 13 8.2.2. Map-Versioning and LISP-NAT . . . . . . . . . . . . . 13
8.2.3. Map-Versioning and Proxy-ETRs . . . . . . . . . . . . 13 8.2.3. Map-Versioning and Proxy-ETRs . . . . . . . . . . . . 13
8.3. RLOC Shutdown/Withdraw . . . . . . . . . . . . . . . . . 13 8.3. RLOC Shutdown/Withdraw . . . . . . . . . . . . . . . . . 13
8.4. Map-Version Additional Use Cases . . . . . . . . . . . . 14 8.4. Map-Version Additional Use Cases . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9.1. Map-Versioning against Traffic Disruption . . . . . . . . 14 10. Deployment Considerations . . . . . . . . . . . . . . . . . . 14
9.2. Map-Versioning against Reachability Information DoS . . . 15 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Deployment Considerations . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 12.1. Normative References . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 12.2. Informative References . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
This document describes the Map-Versioning mechanism used to provide This document describes the Map-Versioning mechanism used to provide
information on changes in the EID-to-RLOC (Endpoint ID to Routing information on changes in the EID-to-RLOC (Endpoint ID to Routing
Locator) mappings used in the LISP (Locator/ID Separation Protocol Locator) mappings used in the LISP (Locator/ID Separation Protocol
[I-D.ietf-lisp-rfc6830bis][I-D.ietf-lisp-rfc6833bis]) context to [I-D.ietf-lisp-rfc6830bis][I-D.ietf-lisp-rfc6833bis]) context to
perform packet encapsulation. The mechanism is totally transparent perform packet encapsulation. The mechanism is totally transparent
to xTRs (Ingress and Egress Tunnel Routers) not supporting or not to xTRs (Ingress and Egress Tunnel Routers) not supporting or not
using such functionality. using such functionality.
skipping to change at page 3, line 28 skipping to change at page 3, line 28
The basic mechanism is to associate a Map-Version number to each LISP 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- EID-to-RLOC mapping and transport such a version number in the LISP-
specific header. When a mapping changes, a new version number is specific header. When a mapping changes, a new version number is
assigned to the updated mapping. A change in an EID-to-RLOC mapping 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 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 RLOCs, but it can also be a change in the priority or weight of one
or more RLOCs. or more RLOCs.
When Map-Versioning is used, LISP-encapsulated data packets contain When Map-Versioning is used, LISP-encapsulated data packets contain
the version number of the two mappings used to select the RLOCs in the version number of the two mappings used to select the RLOCs in
the outer header (i.e., both source and destination). These version the outer header (i.e., both source and destination RLOCs). These
numbers are encoded in the 24 low-order bits of the first longword of version numbers are encoded in the 24 low-order bits of the first
the LISP header and indicated by a specific bit in the flags (first 8 longword of the LISP header and indicated by a specific bit in the
high-order bits of the first longword of the LISP header). Note that flags (first 8 high-order bits of the first longword of the LISP
not all packets need to carry version numbers. header). Note that not all packets need to carry version numbers.
When an ITR (Ingress Tunnel Router) encapsulates a data packet, with When an ITR (Ingress Tunnel Router) encapsulates a data packet, with
a LISP header containing the Map-Version numbers, it puts in the a LISP header containing the Map-Version numbers, it puts in the
LISP-specific header two version numbers: LISP-specific header two version numbers:
1. The version number assigned to the mapping (contained in the EID- 1. The version number assigned to the mapping used to select the
to-RLOC Database) used to select the source RLOC. source RLOC (contained in the EID-to-RLOC Database).
2. The version number assigned to the mapping (contained in the EID- 2. The version number assigned to the mapping used to select the
to-RLOC Cache) used to select the destination RLOC. destination RLOC (contained in the EID-to-RLOC Map-Cache).
This operation is two-fold. On the one hand, it enables the ETR This operation is two-fold. On the one hand, it enables the ETR
(Egress Tunnel Router) receiving the packet to know if the ITR is (Egress Tunnel Router) receiving the packet to know if the ITR is
using the latest mapping version that any ETR at the destination EID using the latest mapping version that any ETR at the destination EID
site would provide to the ITR in a Map-Reply. If this is not the site would provide 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 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 updated mapping or solicit a Map-Request from the ITR (both cases are
already defined in [I-D.ietf-lisp-rfc6833bis]). In this way, the ITR already defined in [I-D.ietf-lisp-rfc6833bis]). In this way, the ITR
can update its EID-to-RLOC Cache. On the other hand, it enables an can update its EID-to-RLOC Map-Cache. On the other hand, it enables
ETR receiving such a packet to know if it has in its EID-to-RLOC an ETR receiving such a packet to know if it has in its EID-to-RLOC
Cache the latest mapping for the source EID. If this is not the Map-Cache the latest mapping for the source EID. If this is not the
case, a Map-Request can be sent. case, a Map-Request can be sent.
Considerations about the deployment of LISP Map-Versioning are Considerations about the deployment of LISP Map-Versioning are
discussed in Section 10. discussed in Section 10.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
skipping to change at page 5, line 51 skipping to change at page 5, line 51
The value 0x000 (zero) is not a valid Map-Version number indicating 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 the version of the EID-to-RLOC mapping. Such a value is used for
special purposes and is named the Null Map-Version number. special purposes and is named the Null Map-Version number.
The Null Map-Version MAY appear in the LISP-specific header as either 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- a Source Map-Version number (cf. Section 5.2) or a Destination Map-
Version number (cf. Section 5.1). When the Source Map-Version 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 number is set to the Null Map-Version value, it means that no map
version information is conveyed for the source site. This means that 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 if a mapping exists for the source EID in the EID-to-RLOC Map-Cache,
the ETR MUST NOT compare the received Null Map-Version with the 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 content of the EID-to-RLOC Map-Cache. When the Destination Map-
number is set to the Null Map-Version value, it means that no map Version number is set to the Null Map-Version value, it means that no
version information is conveyed for the destination site. This means map version information is conveyed for the destination site. This
that the ETR MUST NOT compare the value with the Map-Version number means that the ETR MUST NOT compare the value with the Map-Version
of the mapping for the destination EID present in the EID-to-RLOC number of the mapping for the destination EID present in the EID-to-
Database. RLOC Database.
The other use of the Null Map-Version number is in the Map Records, 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 which are part of the Map-Request, Map-Reply, and Map-Register
messages (defined in [I-D.ietf-lisp-rfc6833bis]). Map Records that messages (defined in [I-D.ietf-lisp-rfc6833bis]). Map Records that
have a Null Map-Version number indicate that there is no Map-Version have a Null Map-Version number indicate that there is no Map-Version
number associated with the mapping. This means that LISP- number associated with the mapping. This means that LISP-
encapsulated packets destined to the EID-Prefix referred to by the encapsulated packets destined to the EID-Prefix referred to by the
Map Record MUST either not contain any Map-Version numbers (V bit set 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 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- the destination Map-Version number MUST be set to the Null Map-
Version number. Any value different from zero means that Map- Version number. Any value different from zero means that Map-
Versioning is supported and MAY be used. Versioning is supported and MAY be used.
The fact that the 0 value has a special meaning for the Map-Version 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 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 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 number MUST be incremented by 2 (i.e., set to 1 (0x001), which is the
valid value). next valid value).
5. Dealing with Map-Version Numbers 5. Dealing with Map-Version Numbers
The main idea of using Map-Version numbers is that whenever there is 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 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 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 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 are not reachable anymore from a local perspective (e.g., through
IGP, or policy changes) the LISP site updates the mapping, also IGP, or policy changes) the LISP site updates the mapping, also
assigning a new Map-Version number. assigning a new Map-Version number.
skipping to change at page 7, line 11 skipping to change at page 7, line 11
In order to announce in a data-driven fashion that the mapping has 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 been updated, Map-Version numbers used to create the outer IP header
of the LISP-encapsulated packet are embedded in the LISP-specific of the LISP-encapsulated packet are embedded in the LISP-specific
header. This means that the header needs to contain two Map-Version header. This means that the header needs to contain two Map-Version
numbers: numbers:
o The Source Map-Version number of the EID-to-RLOC mapping in the o The Source Map-Version number of the EID-to-RLOC mapping in the
EID-to-RLOC Database used to select the source RLOC. EID-to-RLOC Database used to select the source RLOC.
o The Destination Map-Version number of the EID-to-RLOC mapping in o The Destination Map-Version number of the EID-to-RLOC mapping in
the EID-to-RLOC Cache used to select the destination RLOC. the EID-to-RLOC Map-Cache used to select the destination RLOC.
By embedding both the Source Map-Version number and the Destination By embedding both the Source Map-Version number and the Destination
Map-Version number, an ETR receiving a LISP packet with Map-Version Map-Version number, an ETR receiving a LISP packet with Map-Version
numbers can perform the following checks: numbers can perform the following checks:
1. The ITR that has sent the packet has an up-to-date mapping in its 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 EID-to-RLOC Map-Cache for the destination EID and is performing
encapsulation correctly. encapsulation correctly.
2. In the case of bidirectional traffic, the mapping in the local 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. ETR EID-to-RLOC Map-Cache for the source EID is up to date.
If one or both of the above conditions do not hold, the ETR can send 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 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 available (see Section 5.1) or to update the mapping in the local
EID-to-RLOC Cache (see Section 5.2). EID-to-RLOC Map-Cache (see Section 5.2).
5.1. Handling Destination Map-Version Number 5.1. Handling Destination Map-Version Number
When an ETR receives a packet, the 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 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. 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 Since the ETR is authoritative for the mapping, it has the correct
and up to-date Destination Map-Version number. A check on this and up-to-date Destination Map-Version number. A check on this
version number can be done, where the following cases can arise: version number can be done, where the following cases can arise:
1. The packet arrives with the same Destination Map-Version number 1. The packet arrives with the same Destination Map-Version number
stored in the EID-to-RLOC Database. This is the regular case. 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- The ITR sending the packet has in its EID-to-RLOC Map-Cache an
date mapping. No further actions are needed. up-to-date mapping. No further actions are needed.
2. The packet arrives with a Destination Map-Version number greater 2. The packet arrives with a Destination Map-Version number greater
(i.e., newer) than the one stored in the EID-to-RLOC Database. (i.e., newer) than the one stored in the EID-to-RLOC Database.
Since the ETR is authoritative on the mapping, meaning that the Since the ETR is authoritative on the mapping, meaning that the
Map-Version number of its mapping is the correct one, this Map-Version number of its mapping is the correct one, this
implies that someone is not behaving correctly with respect to implies that someone is not behaving correctly with respect to
the specifications. In this case, the packet carries a version the specifications. In this case, the packet carries a version
number that is not valid; otherwise, the ETR would have the same number that is not valid; otherwise, the ETR would have the same
number, and the packet SHOULD be silently dropped. number, and the packet SHOULD be silently dropped.
3. The packets arrive with a Destination Map-Version number smaller 3. The packets arrive with a Destination Map-Version number smaller
(i.e., older) than the one stored in the EID-to-RLOC Database. (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 This means that the ITR sending the packet has an old mapping in
its EID-to-RLOC Cache containing stale information. The ETR MAY its EID-to-RLOC Map-Cache containing stale information. The ETR
choose to normally process the encapsulated datagram according to MAY choose to normally process the encapsulated datagram
[I-D.ietf-lisp-rfc6830bis]; however, the ITR sending the packet according to [I-D.ietf-lisp-rfc6830bis]; however, the ITR sending
has to be informed that a newer mapping is available. This is the packet has to be informed that a newer mapping is available.
done with a Map-Request message sent back to the ITR. The Map- This is done with a Map-Request message sent back to the ITR.
Request will either trigger a Map-Request back using the Solicit- The Map-Request will either trigger a Map-Request back using the
Map-Request (SMR) bit or it will piggyback the newer mapping. Solicit-Map-Request (SMR) bit or it will piggyback the newer
These are not new mechanisms; how to use the SMR bit or how to mapping. These are not new mechanisms; how to use the SMR bit or
piggyback mappings in Map-Request messages is already described how to piggyback mappings in Map-Request messages is already
in [I-D.ietf-lisp-rfc6833bis]. One feature introduced by Map- described in [I-D.ietf-lisp-rfc6833bis]. One feature introduced
Version numbers is the possibility of blocking traffic not using by Map-Version numbers is the possibility of blocking traffic not
the latest mapping. Indeed, after a certain number of retries, using the latest mapping. Indeed, after a certain number of
if the Destination Map-Version number in the packets is not retries, if the Destination Map-Version number in the packets is
updated, the ETR MAY drop packets with a stale Map-Version number not updated, the ETR MAY drop packets with a stale Map-Version
while strongly reducing the rate of Map-Request messages. This number while limiting the rate of Map-Request messages. This is
is because either the ITR is refusing to use the mapping for because either the ITR is refusing to use the mapping for which
which the ETR is authoritative, or (worse) it might be some form the ETR is authoritative, or (worse) it might be some form of
of attack. attack.
The rule in the third case MAY be more restrictive. If the mapping 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 has been the same for a period of time as long as the Time To Live
(TTL) (defined in [I-D.ietf-lisp-rfc6833bis]) of the previous version (TTL) (defined in [I-D.ietf-lisp-rfc6833bis]) of the previous version
of the mapping, all packets arriving with an old Map-Version SHOULD of the mapping, all packets arriving with an old Map-Version SHOULD
be silently dropped right away without issuing any Map-Request. Such be silently dropped right away without issuing any Map-Request. Such
action is permitted because if the new mapping with the updated action is permitted because if the new mapping with the updated
version number has been unchanged for at least the same time as the 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 TTL of the older mapping, all the entries in the EID-to-RLOC Map-
of ITRs must have expired. Hence, all ITRs sending traffic should Caches of ITRs must have expired. Hence, all ITRs sending traffic
have refreshed the mapping according to [I-D.ietf-lisp-rfc6833bis]. should have refreshed the mapping according to
If packets with old Map-Version numbers are still received, then [I-D.ietf-lisp-rfc6833bis]. If packets with old Map-Version numbers
either someone has not respected the TTL or it is a form of spoof/ are still received, then either someone has not respected the TTL or
attack. In both cases, this is not valid behavior with respect to it is a form of spoof/attack. In both cases, this is not valid
the specifications and the packet SHOULD be silently dropped. behavior with respect to the specifications and the packet SHOULD be
silently dropped.
LISP-encapsulated packets with the V-bit set, when the original 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 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 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 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 means that ITRs, using the mapping for encapsulation, MUST NOT use a
Map-Version number in the LISP-specific header. Map-Version number in the LISP-specific header.
For LISP-encapsulated packets with the V-bit set, when the original 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 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- value different from the Null Map-Version value, a Destination Map-
Version number equal to the Null Map-Version value means that the Version number equal to the Null Map-Version value means that the
Destination Map-Version number MUST be ignored. Destination Map-Version number MUST be ignored.
5.2. Handling Source Map-Version Number 5.2. Handling Source Map-Version Number
When an ETR receives a packet, the Source Map-Version number relates 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 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 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 Map-Cache for the source EID, then a check can be performed and the
following cases can arise: following cases can arise:
1. The packet arrives with the same Source Map-Version number as 1. The packet arrives with the same Source Map-Version number as
that stored in the EID-to-RLOC Cache. This is the correct that stored in the EID-to-RLOC Map-Cache. This is the correct
regular case. The ITR has in its EID-to-RLOC Cache an up-to-date regular case. The ITR has in its EID-to-RLOC Map-Cache an up-to-
copy of the mapping. No further actions are needed. date copy of the mapping. No further actions are needed.
2. The packet arrives with a Source Map-Version number greater 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. (i.e., newer) than the one stored in the local EID-to-RLOC Map-
This means that the ETR has in its EID-to-RLOC Cache a mapping Cache. This means that the ETR has in its EID-to-RLOC Map-Cache
that is stale and needs to be updated. A Map-Request SHOULD be a mapping that is stale and needs to be updated. A Map-Request
sent to get the new mapping for the source EID. This is a normal SHOULD be sent to get the new mapping for the source EID. This
Map-Request message sent through the mapping system and MUST is a normal Map-Request message sent through the mapping system
respect the specifications in [I-D.ietf-lisp-rfc6833bis], and MUST respect the specifications in
including rate-limitation policies. [I-D.ietf-lisp-rfc6833bis], including rate-limitation policies.
3. The packet arrives with a Source Map-Version number smaller 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. (i.e., older) than the one stored in the local EID-to-RLOC Map-
Such a case is not valid with respect to the specifications. Cache. Such a case is not valid with respect to the
Indeed, if the mapping is already present in the EID-to-RLOC specifications. Indeed, if the mapping is already present in the
Cache, this means that an explicit Map-Request has been sent and EID-to-RLOC Map-Cache, this means that an explicit Map-Request
a Map-Reply has been received from an authoritative source. has been sent and a Map-Reply has been received from an
Assuming that the mapping system is not corrupted, the Map- authoritative source. Assuming that the mapping system is not
Version in the EID-to-RLOC Cache is the correct one, while the corrupted, the Map-Version in the EID-to-RLOC Map-Cache is the
one carried by the packet is stale. In this situation, the correct one, while the one carried by the packet is stale. In
packet MAY be silently dropped. this situation, the packet MAY be silently dropped.
If the ETR does not have an entry in the EID-to-RLOC Cache for the If the ETR does not have an entry in the EID-to-RLOC Map-Cache for
source EID, then the Source Map-Version number can be ignored. the source EID, then the Source Map-Version number can be ignored.
For LISP-encapsulated packets with the V-bit set, if the Source Map- 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 Version number is the Null Map-Version value, it means that the
Source Map-Version number MUST be ignored. Source Map-Version number MUST be ignored.
6. LISP Header and Map-Version Numbers 6. LISP Header and Map-Version Numbers
In order for the versioning approach to work, the LISP-specific In order for the versioning approach to work, the LISP-specific
header has to carry both the Source Map-Version number and header has to carry both the Source Map-Version number and
Destination Map-Version number. This is done by setting the V-bit in Destination Map-Version number. This is done by setting the V-bit in
the LISP-specific header as defined in [I-D.ietf-lisp-rfc6830bis]. the LISP-specific header as specified in [I-D.ietf-lisp-rfc6830bis].
When the V-bit is set and the P bit is reset (0), the low-order 24 When the V-bit is set and the N bit is reset (0), the low-order 24
bits of the first longword are used to transport both the source and bits of the first longword are used to transport both the source and
destination Map-Version numbers. In particular, the first 12 bits destination Map-Version numbers. In particular, the first 12 bits
are used for the Source Map-Version number and the second 12 bits for are used for the Source Map-Version number and the second 12 bits for
the Destination Map-Version number. the Destination Map-Version number.
Below is an example of a LISP header carrying version numbers. Below is an example of a LISP header carrying version numbers.
0 1 2 3 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 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|P|K|K| Source Map-Version |Destination Map-Version| / |N|L|E|V|I|R|K|K| Source Map-Version |Destination Map-Version|
LISP+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LISP+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Instance ID/Locator Status Bits | \ | Instance ID/Locator Status Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Map-Version number (12 bits): Map-Version of the mapping used Source Map-Version number (12 bits): Map-Version of the mapping used
by the ITR to select the RLOC present in the "Source Routing by the ITR to select the RLOC present in the "Source Routing
Locator" field. Section 5.2 describes how to set this value on Locator" field. Section 5.2 describes how to set this value on
transmission and handle it on reception. transmission and handle it on reception.
Destination Map-Version number (12 bits): Map-Version of the mapping Destination Map-Version number (12 bits): Map-Version of the mapping
skipping to change at page 14, line 13 skipping to change at page 14, line 13
without actually turning it off. without actually turning it off.
Once no more traffic is received by the RLOC, it can be shut down Once no more traffic is received by the RLOC, it can be shut down
gracefully, because all sites actively using the mapping have updated gracefully, because all sites actively using the mapping have updated
it. it.
8.4. Map-Version Additional Use Cases 8.4. Map-Version Additional Use Cases
The use of Map-Versioning can help in developing a lightweight The use of Map-Versioning can help in developing a lightweight
implementation of LISP. However, this comes with the price of not implementation of LISP. However, this comes with the price of not
supporting the Loc-Status-Bit, which may be useful in some contexts. supporting the Loc Status Bit, which may be useful in some contexts.
In the current LISP specifications, the set of RLOCs must always be In the current LISP specifications, the set of RLOCs must always be
maintained ordered and consistent with the content of the Loc Status maintained ordered and consistent with the content of the Loc Status
Bits ([I-D.ietf-lisp-rfc6830bis]). With Map-Versioning, such types Bits ([I-D.ietf-lisp-rfc6830bis]). . When a new RLOC is added to a
of mechanisms can be avoided. When a new RLOC is added to a mapping, mapping, a new mapping with a new Map-Version number will be issued,
it is not necessary to "append" new locators to the existing ones as and since the old locators are still valid, the transition will occur
explained in [I-D.ietf-lisp-rfc6830bis]. A new mapping with a new with no disruptions. The same applies for the case where an RLOC is
Map-Version number will be issued, and since the old locators are withdrawn. The use of Map-Versioning allows to avoiding using the
still valid, the transition will occur with no disruptions. The same "use-LSB" timer (cf. [I-D.ietf-lisp-rfc6830bis]) since it allows to
applies for the case where an RLOC is withdrawn. There is no need to check whether or not the mapping has been updated.
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.
9. Security Considerations 9. Security Considerations
Map-Versioning does not introduce any security issues concerning both Attackers can try to trigger a large number of Map-Requests by simply
the data plane and the control plane. On the contrary, as described forging packets with random Map-Versions. The Map-Requests are rate-
below, if Map-Versioning may also be used to update mappings in the limited as described in [I-D.ietf-lisp-rfc6833bis]. With Map-
case of change in the reachability information (i.e., instead of the Versioning it is possible to filter invalid version numbers before
Locator Status Bits), it is possible to reduce the effects of some triggering a Map-Request, thus helping to reduce the effects of DoS
DoS or spoofing attacks that can happen in an untrusted environment. attacks. However, it might not be enough to really protect from a
DDoS attack.
Robustness of the Map-Versioning mechanism leverages on a trusted Robustness of the Map-Versioning mechanism leverages on a trusted
Mapping Distribution System. A thorough security analysis of LISP is Mapping Distribution System. A thorough security analysis of LISP is
documented in [RFC7835]. documented in [RFC7835].
9.1. Map-Versioning against Traffic Disruption As specified in [I-D.ietf-lisp-rfc6830bis], Map-Versioning MUST NOT
be used over the public Internet and SHOULD only be used in trusted
An attacker can try to disrupt ongoing communications by creating and closed deployments.
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
[I-D.ietf-lisp-rfc6833bis] in order to avoid DoS attacks.
Note that a similar level of security can be obtained with Loc 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 9.2).
9.2. Map-Versioning against Reachability Information DoS
Attackers can try to trigger a large number 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 [I-D.ietf-lisp-rfc6833bis]. 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 Loc Status Bits.
10. Deployment Considerations 10. Deployment Considerations
Even without Map-Versioning, LISP requires ETRs to announce the same Even without Map-Versioning, LISP requires ETRs to announce the same
mapping for the same EID-Prefix to a requester. Map-Versioning does mapping for the same EID-Prefix to a requester. Map-Versioning does
not require additional synchronization mechanisms as compared to the not require additional synchronization mechanisms as compared to the
normal functioning of LISP without Map-Versioning. Clearly, all the normal functioning of LISP without Map-Versioning. Clearly, all the
ETRs have to reply with the same Map-Version number; otherwise, there ETRs have to reply with the same Map-Version number; otherwise, there
can be an inconsistency that creates additional control traffic, can be an inconsistency that creates additional control traffic,
instabilities, and traffic disruptions. It is the same without Map- instabilities, and traffic disruptions. It is the same without Map-
skipping to change at page 17, line 23 skipping to change at page 16, line 18
This document includes no request to IANA. This document includes no request to IANA.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-lisp-rfc6830bis] [I-D.ietf-lisp-rfc6830bis]
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos-Aparicio, "The Locator/ID Separation Protocol Cabellos-Aparicio, "The Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-rfc6830bis-35 (work in progress), (LISP)", draft-ietf-lisp-rfc6830bis-36 (work in progress),
September 2020. November 2020.
[I-D.ietf-lisp-rfc6833bis] [I-D.ietf-lisp-rfc6833bis]
Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- Farinacci, D., Maino, F., Fuller, V., and A. Cabellos-
Aparicio, "Locator/ID Separation Protocol (LISP) Control- Aparicio, "Locator/ID Separation Protocol (LISP) Control-
Plane", draft-ietf-lisp-rfc6833bis-29 (work in progress), Plane", draft-ietf-lisp-rfc6833bis-30 (work in progress),
September 2020. November 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
skipping to change at page 18, line 20 skipping to change at page 17, line 20
Authors' Addresses Authors' Addresses
Luigi Iannone Luigi Iannone
Huawei Technologies France S.A.S.U Huawei Technologies France S.A.S.U
EMail: luigi.iannone@huawei.com EMail: luigi.iannone@huawei.com
Damien Saucez Damien Saucez
INRIA INRIA
EMail: damien.saucez@gmail.com EMail: damien.saucez@inria.fr
Olivier Bonaventure Olivier Bonaventure
Universite catholique de Louvain Universite catholique de Louvain
EMail: olivier.bonaventure@uclouvain.be EMail: olivier.bonaventure@uclouvain.be
 End of changes. 34 change blocks. 
168 lines changed or deleted 114 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/