draft-ietf-lisp-6834bis-04.txt   draft-ietf-lisp-6834bis-05.txt 
Network Working Group L. Iannone Network Working Group L. Iannone
Internet-Draft Telecom ParisTech Internet-Draft Telecom ParisTech
Obsoletes: 6834 (if approved) D. Saucez Obsoletes: 6834 (if approved) D. Saucez
Intended status: Standards Track INRIA Sophia Antipolis Intended status: Standards Track Safran Electrical and Power
Expires: February 17, 2020 O. Bonaventure Expires: August 16, 2020 O. Bonaventure
Universite catholique de Louvain Universite catholique de Louvain
August 16, 2019 February 13, 2020
Locator/ID Separation Protocol (LISP) Map-Versioning Locator/ID Separation Protocol (LISP) Map-Versioning
draft-ietf-lisp-6834bis-04 draft-ietf-lisp-6834bis-05
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 February 17, 2020. This Internet-Draft will expire on August 16, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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 31 skipping to change at page 2, line 31
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Definitions of Terms . . . . . . . . . . . . . . . . . . . . 4 3. Definitions of Terms . . . . . . . . . . . . . . . . . . . . 4
4. EID-to-RLOC Map-Version Number . . . . . . . . . . . . . . . 4 4. EID-to-RLOC Map-Version Number . . . . . . . . . . . . . . . 4
4.1. The Null Map-Version . . . . . . . . . . . . . . . . . . 5 4.1. The Null Map-Version . . . . . . . . . . . . . . . . . . 5
5. Dealing with Map-Version Numbers . . . . . . . . . . . . . . 6 5. Dealing with Map-Version Numbers . . . . . . . . . . . . . . 6
5.1. Handling Destination Map-Version Number . . . . . . . . . 7 5.1. Handling Destination Map-Version Number . . . . . . . . . 7
5.2. Handling Source Map-Version Number . . . . . . . . . . . 9 5.2. Handling Source Map-Version Number . . . . . . . . . . . 9
6. LISP Header and Map-Version Numbers . . . . . . . . . . . . . 10 6. LISP Header and Map-Version Numbers . . . . . . . . . . . . . 9
7. LISP Generic Protocol Encapsulation (GPE) Header and Map- 7. Map Record and Map-Version . . . . . . . . . . . . . . . . . 10
Version Numbers . . . . . . . . . . . . . . . . . . . . . . . 10 8. Benefits and Case Studies for Map-Versioning . . . . . . . . 11
8. Map Record and Map-Version . . . . . . . . . . . . . . . . . 11 8.1. Map-Versioning and Unidirectional Traffic . . . . . . . . 11
9. Benefits and Case Studies for Map-Versioning . . . . . . . . 12 8.2. Map-Versioning and Interworking . . . . . . . . . . . . . 12
9.1. Map-Versioning and Unidirectional Traffic . . . . . . . . 12 8.2.1. Map-Versioning and Proxy-ITRs . . . . . . . . . . . . 12
9.2. Map-Versioning and Interworking . . . . . . . . . . . . . 13 8.2.2. Map-Versioning and LISP-NAT . . . . . . . . . . . . . 13
9.2.1. Map-Versioning and Proxy-ITRs . . . . . . . . . . . . 13 8.2.3. Map-Versioning and Proxy-ETRs . . . . . . . . . . . . 13
9.2.2. Map-Versioning and LISP-NAT . . . . . . . . . . . . . 14 8.3. RLOC Shutdown/Withdraw . . . . . . . . . . . . . . . . . 13
9.2.3. Map-Versioning and Proxy-ETRs . . . . . . . . . . . . 14 8.4. Map-Version Additional Use Cases . . . . . . . . . . . . 14
9.3. RLOC Shutdown/Withdraw . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9.4. Map-Version Additional Use Cases . . . . . . . . . . . . 15 9.1. Map-Versioning against Traffic Disruption . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9.2. Map-Versioning against Reachability Information DoS . . . 15
10.1. Map-Versioning against Traffic Disruption . . . . . . . 15 10. Deployment Considerations . . . . . . . . . . . . . . . . . . 15
10.2. Map-Versioning against Reachability Information DoS . . 16 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. Deployment Considerations . . . . . . . . . . . . . . . . . . 16 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 13.1. Normative References . . . . . . . . . . . . . . . . . . 17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 13.2. Informative References . . . . . . . . . . . . . . . . . 18
14.1. Normative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
14.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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 4, line 10 skipping to change at page 4, line 8
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 Cache. On the other hand, it enables an
ETR receiving such a packet to know if it has in its EID-to-RLOC 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 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 11. 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
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Definitions of Terms 3. Definitions of Terms
skipping to change at page 10, line 41 skipping to change at page 10, line 35
Destination Map-Version number (12 bits): Map-Version of the mapping Destination Map-Version number (12 bits): Map-Version of the mapping
used by the ITR to select the RLOC present in the "Destination used by the ITR to select the RLOC present in the "Destination
Routing Locator" field. Section 5.1 describes how to set this Routing Locator" field. Section 5.1 describes how to set this
value on transmission and handle it on reception. value on transmission and handle it on reception.
Not all of the LISP-encapsulated packets need to carry version Not all of the LISP-encapsulated packets need to carry version
numbers. When Map-Version numbers are carried in these packets, the numbers. When Map-Version numbers are carried in these packets, the
V-bit MUST be set to 1. All permissible combinations of the flags V-bit MUST be set to 1. All permissible combinations of the flags
when the V-bit is set to 1 are described in when the V-bit is set to 1 are described in
[I-D.ietf-lisp-rfc6830bis] and [I-D.ietf-lisp-gpe]. [I-D.ietf-lisp-rfc6830bis].
7. LISP Generic Protocol Encapsulation (GPE) Header and Map-Version
Numbers
[I-D.ietf-lisp-gpe] extends the Locator/ID Separation Protocol (LISP)
Data-Plane, changing the LISP header, to support multi-protocol
encapsulation. A flag in the LISP header, called the P-bit, is used
to signal the presence of the Next Protocol field in the low-order 8
bits of the first longword. When the V-bit and P-bit are both set,
the middle-order 16 bits of the first longword are used to transport
both the source and destination Map-Version numbers. In particular,
the first 8 bits are used for the Source Map-Version number and the
second 8 bits for the Destination Map-Version number.
Below is an example of a LISP header carrying version numbers.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |N|L|E|V|I|P|K|K|Src Map-Version|Dst Map-Version| Next Protocol |
LISP+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Instance ID/Locator Status Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Source Map-Version number and the Destination Map-Version number
are used exactly in the same way previously described. There are
only three differences:
o When filling the LISP-GPE-specific header only the low order 8
bits are copied in the Source and Destination Map-Version Number
(out of the original 12 bits).
o When comparing a Map-Version retrieved from the LISP-GPE-specific
header (either Source or Destination Map-Version number) with the
version number of a mapping (stored in the LISP Cache or LISP
Database) only the low-order 8 bits of the latter are used for the
comparison.
o When trimming a Map-Version number from 12 to 8 bits it may happen
that it is converted to a Null Map-Version number, which will
change the way Map-Version number is interpreted as described in
Section 4.1. To avoid such wrong behavior, Map-Version number
with the low-order 8 bits all equal to zero SHOULD be avoided on
xTRs using LISP-GPE.
8. Map Record and Map-Version 7. Map Record and Map-Version
To accommodate the proposed mechanism, the Map Records that are To accommodate the proposed mechanism, the Map Records that are
transported in Map-Request/Map-Reply/Map-Register messages need to transported in Map-Request/Map-Reply/Map-Register messages need to
carry the Map-Version number as well. For this purpose, the 12 bits carry the Map-Version number as well. For this purpose, the 12 bits
before the EID-AFI field in the Record that describes a mapping are before the EID-AFI field in the Record that describes a mapping are
used (see [I-D.ietf-lisp-rfc6833bis] and reported here as an example. used (see [I-D.ietf-lisp-rfc6833bis] and reported here as an example.
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
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 33 skipping to change at page 11, line 33
Map-Version Number: Map-Version of the mapping contained in the Map-Version Number: Map-Version of the mapping contained in the
Record. As explained in Section 4.1, this field can be zero (0), Record. As explained in Section 4.1, this field can be zero (0),
meaning that no Map-Version is associated to the mapping; hence, meaning that no Map-Version is associated to the mapping; hence,
packets that are LISP encapsulated using this mapping MUST NOT packets that are LISP encapsulated using this mapping MUST NOT
contain Map-Version numbers in the LISP-specific header, and the contain Map-Version numbers in the LISP-specific header, and the
V-bit MUST be set to 0. V-bit MUST be set to 0.
This packet format works perfectly with xTRs that do not support Map- This packet format works perfectly with xTRs that do not support Map-
Versioning, since they can simply ignore those bits. Versioning, since they can simply ignore those bits.
9. Benefits and Case Studies for Map-Versioning 8. Benefits and Case Studies for Map-Versioning
In the following sections, we provide more discussion on various In the following sections, we provide more discussion on various
aspects and uses of Map-Versioning. Security observations are aspects and uses of Map-Versioning. Security observations are
grouped in Section 10. grouped in Section 9.
9.1. Map-Versioning and Unidirectional Traffic 8.1. Map-Versioning and Unidirectional Traffic
When using Map-Versioning, the LISP-specific header carries two Map- When using Map-Versioning, the LISP-specific header carries two Map-
Version numbers, for both source and destination mappings. This can Version numbers, for both source and destination mappings. This can
raise the question on what will happen in the case of unidirectional raise the question on what will happen in the case of unidirectional
flows, for instance, in the case presented in Figure 1, since the flows, for instance, in the case presented in Figure 1, since the
LISP specification does not mandate that the ETR have a mapping for LISP specification does not mandate that the ETR have a mapping for
the source EID. the source EID.
+-----------------+ +-----------------+ +-----------------+ +-----------------+
| Domain A | | Domain B | | Domain A | | Domain B |
skipping to change at page 13, line 24 skipping to change at page 12, line 24
In the case of the ITR, the ITR is able to put both the source and In the case of the ITR, the ITR is able to put both the source and
destination version number in the LISP header, since the Source Map- destination version number in the LISP header, since the Source Map-
Version number is in the ITR's database, while the Destination Map- Version number is in the ITR's database, while the Destination Map-
Version number is in the ITR's cache. Version number is in the ITR's cache.
In the case of the ETR, the ETR simply checks only the Destination In the case of the ETR, the ETR simply checks only the Destination
Map-Version number in the same way as that described in Section 5, Map-Version number in the same way as that described in Section 5,
ignoring the Source Map-Version number. ignoring the Source Map-Version number.
9.2. Map-Versioning and Interworking 8.2. Map-Versioning and Interworking
Map-Versioning is compatible with the LISP interworking between LISP Map-Versioning is compatible with the LISP interworking between LISP
and non-LISP sites as defined in [RFC6832]. LISP interworking and non-LISP sites as defined in [RFC6832]. LISP interworking
defines three techniques to make LISP sites and non-LISP sites, defines three techniques to make LISP sites and non-LISP sites,
namely Proxy-ITR, LISP-NAT, and Proxy-ETR. The following text namely Proxy-ITR, LISP-NAT, and Proxy-ETR. The following text
describes how Map-Versioning relates to these three mechanisms. describes how Map-Versioning relates to these three mechanisms.
9.2.1. Map-Versioning and Proxy-ITRs 8.2.1. Map-Versioning and Proxy-ITRs
The purpose of the Proxy-ITR (PITR) is to encapsulate traffic The purpose of the Proxy-ITR (PITR) is to encapsulate traffic
originating in a non-LISP site in order to deliver the packet to one originating in a non-LISP site in order to deliver the packet to one
of the ETRs of the LISP site (cf. Figure 2). This case is very of the ETRs of the LISP site (cf. Figure 2). This case is very
similar to the unidirectional traffic case described in Section 9.1; similar to the unidirectional traffic case described in Section 8.1;
hence, similar rules apply. hence, similar rules apply.
+----------+ +-------------+ +----------+ +-------------+
| LISP | | non-LISP | | LISP | | non-LISP |
| Domain A | | Domain B | | Domain A | | Domain B |
| +-------+ +-----------+ | | | +-------+ +-----------+ | |
| | ETR A |<-------| Proxy ITR |<-------| | | | ETR A |<-------| Proxy ITR |<-------| |
| +-------+ +-----------+ | | | +-------+ +-----------+ | |
| | | | | | | |
+----------+ +-------------+ +----------+ +-------------+
skipping to change at page 14, line 11 skipping to change at page 13, line 11
The main difference is that a Proxy-ITR does not have any mapping, The main difference is that a Proxy-ITR does not have any mapping,
since it just encapsulates packets arriving from the non-LISP site, since it just encapsulates packets arriving from the non-LISP site,
and thus cannot provide a Source Map-Version. In this case, the and thus cannot provide a Source Map-Version. In this case, the
proxy-ITR will just put the Null Map-Version value as the Source Map- proxy-ITR will just put the Null Map-Version value as the Source Map-
Version number, while the receiving ETR will ignore the field. Version number, while the receiving ETR will ignore the field.
With this setup, LISP Domain A is able to check whether or not the With this setup, LISP Domain A is able to check whether or not the
PITR is using the latest mapping. PITR is using the latest mapping.
9.2.2. Map-Versioning and LISP-NAT 8.2.2. Map-Versioning and LISP-NAT
The LISP-NAT mechanism is based on address translation from non- The LISP-NAT mechanism is based on address translation from non-
routable EIDs to routable EIDs and does not involve any form of routable EIDs to routable EIDs and does not involve any form of
encapsulation. As such, Map-Versioning does not apply in this case. encapsulation. As such, Map-Versioning does not apply in this case.
9.2.3. Map-Versioning and Proxy-ETRs 8.2.3. Map-Versioning and Proxy-ETRs
The purpose of the Proxy-ETR (PETR) is to decapsulate traffic The purpose of the Proxy-ETR (PETR) is to decapsulate traffic
originating in a LISP site in order to deliver the packet to the non- originating in a LISP site in order to deliver the packet to the non-
LISP site (cf. Figure 3). One of the main reasons to deploy PETRs LISP site (cf. Figure 3). One of the main reasons to deploy PETRs
is to bypass uRPF (Unicast Reverse Path Forwarding) checks on the is to bypass uRPF (Unicast Reverse Path Forwarding) checks on the
provider edge. provider edge.
+----------+ +-------------+ +----------+ +-------------+
| LISP | | non-LISP | | LISP | | non-LISP |
| Domain A | | Domain B | | Domain A | | Domain B |
skipping to change at page 14, line 44 skipping to change at page 13, line 44
Figure 3: Unidirectional traffic from LISP domain to non-LISP domain. Figure 3: Unidirectional traffic from LISP domain to non-LISP domain.
A Proxy-ETR does not have any mapping, since it just decapsulates A Proxy-ETR does not have any mapping, since it just decapsulates
packets arriving from the LISP site. In this case, the ITR will just packets arriving from the LISP site. In this case, the ITR will just
put the Null Map-Version value as the Destination Map-Version number, put the Null Map-Version value as the Destination Map-Version number,
while the receiving Proxy-ETR will ignore the field. while the receiving Proxy-ETR will ignore the field.
With this setup, the Proxy-ETR is able to check whether or not the With this setup, the Proxy-ETR is able to check whether or not the
mapping has changed. mapping has changed.
9.3. RLOC Shutdown/Withdraw 8.3. RLOC Shutdown/Withdraw
Map-Versioning can also be used to perform a graceful shutdown or Map-Versioning can also be used to perform a graceful shutdown or
withdraw of a specific RLOC. This is achieved by simply issuing a withdraw of a specific RLOC. This is achieved by simply issuing a
new mapping, with an updated Map-Version number where the specific new mapping, with an updated Map-Version number where the specific
RLOC to be shut down is withdrawn or announced as unreachable (via RLOC to be shut down is withdrawn or announced as unreachable (via
the R bit in the Map Record; see [I-D.ietf-lisp-rfc6833bis]), but the R bit in the Map Record; see [I-D.ietf-lisp-rfc6833bis]), but
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.
9.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]). With Map-Versioning, such types
of mechanisms can be avoided. When a new RLOC is added to a mapping, of mechanisms can be avoided. When a new RLOC is added to a mapping,
it is not necessary to "append" new locators to the existing ones as it is not necessary to "append" new locators to the existing ones as
skipping to change at page 15, line 33 skipping to change at page 14, line 33
applies for the case where an RLOC is withdrawn. There is no need to applies for the case where an RLOC is withdrawn. There is no need to
maintain holes in the list of locators, as is the case when using 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 Locator Status Bits, for sites that are not using the RLOC that has
been withdrawn; in this case, the transition will occur with no been withdrawn; in this case, the transition will occur with no
disruptions. disruptions.
All of these operations, as already stated, do not need to maintain All of these operations, as already stated, do not need to maintain
any consistency among Locator Status Bits and in the way that the any consistency among Locator Status Bits and in the way that the
RLOCs are stored in the EID-to-RLOC Cache. RLOCs are stored in the EID-to-RLOC Cache.
10. Security Considerations 9. Security Considerations
Map-Versioning does not introduce any security issues concerning both Map-Versioning does not introduce any security issues concerning both
the data plane and the control plane. On the contrary, as described the data plane and the control plane. On the contrary, as described
below, if Map-Versioning may also be used to update mappings in the below, if Map-Versioning may also be used to update mappings in the
case of change in the reachability information (i.e., instead of the case of change in the reachability information (i.e., instead of the
Locator Status Bits), it is possible to reduce the effects of some Locator Status Bits), it is possible to reduce the effects of some
DoS or spoofing attacks that can happen in an untrusted environment. DoS or spoofing attacks that can happen in an untrusted environment.
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].
10.1. Map-Versioning against Traffic Disruption 9.1. Map-Versioning against Traffic Disruption
An attacker can try to disrupt ongoing communications by creating An attacker can try to disrupt ongoing communications by creating
LISP-encapsulated packets with wrong Locator Status Bits. If the xTR LISP-encapsulated packets with wrong Locator Status Bits. If the xTR
blindly trusts the Locator Status Bits, it will change the blindly trusts the Locator Status Bits, it will change the
encapsulation accordingly, which can result in traffic disruption. encapsulation accordingly, which can result in traffic disruption.
This does not happen in the case of Map-Versioning. As described in 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- Section 5, upon a version number change the xTR first issues a Map-
Request. The assumption is that the mapping distribution system is Request. The assumption is that the mapping distribution system is
sufficiently secure that Map-Request and Map-Reply messages and their sufficiently secure that Map-Request and Map-Reply messages and their
skipping to change at page 16, line 28 skipping to change at page 15, line 28
Note that a similar level of security can be obtained with Loc Status 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 Bits by simply making it mandatory to verify any change through a
Map-Request. However, in this case Locator Status Bits lose their Map-Request. However, in this case Locator Status Bits lose their
meaning, because it does not matter anymore which specific bits have meaning, because it does not matter anymore which specific bits have
changed; the xTR will query the mapping system and trust the content changed; the xTR will query the mapping system and trust the content
of the received Map-Reply. Furthermore, there is no way to perform 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 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 carry a valid Map-Version number. In the case of Locator Status
Bits, any random change can trigger a Map-Request (unless rate Bits, any random change can trigger a Map-Request (unless rate
limitation is enabled, which raises another type of attack as limitation is enabled, which raises another type of attack as
discussed in Section 10.2). discussed in Section 9.2).
10.2. Map-Versioning against Reachability Information DoS 9.2. Map-Versioning against Reachability Information DoS
Attackers can try to trigger a large number of Map-Requests by simply Attackers can try to trigger a large number of Map-Requests by simply
forging packets with random Map-Versions or random Locator Status forging packets with random Map-Versions or random Locator Status
Bits. In both cases, the Map-Requests are rate-limited as described Bits. In both cases, the Map-Requests are rate-limited as described
in [I-D.ietf-lisp-rfc6833bis]. However, in contrast to the Locator 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- Status Bit, where there is no filtering possible, in the case of Map-
Versioning it is possible to filter invalid version numbers before Versioning it is possible to filter invalid version numbers before
triggering a Map-Request, thus helping to reduce the effects of DoS triggering a Map-Request, thus helping to reduce the effects of DoS
attacks. In other words, the use of Map-Versioning enables a fine 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 control on when to update a mapping or when to notify someone that a
mapping has been updated. mapping has been updated.
It is clear that Map-Versioning does not protect against DoS and DDoS 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 attacks, where an xTR loses processing power when doing checks on the
LISP header of packets sent by attackers. This is independent of LISP header of packets sent by attackers. This is independent of
Map-Versioning and is the same for Loc Status Bits. Map-Versioning and is the same for Loc Status Bits.
11. 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-
Versioning, with ETRs that have to reply with the same mapping; Versioning, with ETRs that have to reply with the same mapping;
otherwise, the same problems can arise. otherwise, the same problems can arise.
skipping to change at page 18, line 10 skipping to change at page 17, line 10
Bits. In this case, either the traffic is disrupted if ETR B trusts Bits. In this case, either the traffic is disrupted if ETR B trusts
the Locator Status Bits, or if ETR B does not trust the Locator the Locator Status Bits, or if ETR B does not trust the Locator
Status Bits it will start sending Map-Requests to confirm each change Status Bits it will start sending Map-Requests to confirm each change
in reachability. in reachability.
So far, LISP does not provide any specific synchronization mechanism So far, LISP does not provide any specific synchronization mechanism
but assumes that synchronization is provided by configuring the but assumes that synchronization is provided by configuring the
different xTRs consistently. The same applies for Map-Versioning. different xTRs consistently. The same applies for Map-Versioning.
If in the future any synchronization mechanism is provided, Map- If in the future any synchronization mechanism is provided, Map-
Versioning will take advantage of it automatically, since it is Versioning will take advantage of it automatically, since it is
included in the Record format, as described in Section 8. included in the Record format, as described in Section 7.
12. IANA Considerations 11. IANA Considerations
This document includes no request to IANA. This document includes no request to IANA.
13. Acknowledgments 12. Acknowledgments
This work benefited support from NewNet@Paris, Cisco's Chair This work benefited support from NewNet@Paris, Cisco's Chair
"Networks for the Future" at Telecom ParisTech "Networks for the Future" at Telecom ParisTech
(http://newnet.telecom-paristech.fr). Any opinions, findings or (http://newnet.telecom-paristech.fr). Any opinions, findings or
recommendations expressed in this material are those of the author(s) recommendations expressed in this material are those of the author(s)
and do not necessarily reflect the views of partners of the Chair. and do not necessarily reflect the views of partners of the Chair.
14. References 13. References
14.1. Normative References
[I-D.ietf-lisp-gpe] 13.1. Normative References
Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M.
Smith, "LISP Generic Protocol Extension", draft-ietf-lisp-
gpe-06 (work in progress), September 2018.
[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-27 (work in progress), (LISP)", draft-ietf-lisp-rfc6830bis-27 (work in progress),
June 2019. June 2019.
[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-
skipping to change at page 19, line 5 skipping to change at page 18, line 5
[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>.
14.2. Informative References 13.2. Informative References
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking between Locator/ID Separation Protocol "Interworking between Locator/ID Separation Protocol
(LISP) and Non-LISP Sites", RFC 6832, (LISP) and Non-LISP Sites", RFC 6832,
DOI 10.17487/RFC6832, January 2013, DOI 10.17487/RFC6832, January 2013,
<https://www.rfc-editor.org/info/rfc6832>. <https://www.rfc-editor.org/info/rfc6832>.
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", RFC 6834, Separation Protocol (LISP) Map-Versioning", RFC 6834,
DOI 10.17487/RFC6834, January 2013, DOI 10.17487/RFC6834, January 2013,
skipping to change at page 19, line 31 skipping to change at page 18, line 31
<https://www.rfc-editor.org/info/rfc7835>. <https://www.rfc-editor.org/info/rfc7835>.
Authors' Addresses Authors' Addresses
Luigi Iannone Luigi Iannone
Telecom ParisTech Telecom ParisTech
EMail: ggx@gigix.net EMail: ggx@gigix.net
Damien Saucez Damien Saucez
INRIA Sophia Antipolis Safran Electrical and Power
EMail: damien.saucez@inria.fr EMail: damien.saucez@safrangroup.com
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. 32 change blocks. 
104 lines changed or deleted 52 lines changed or added

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