draft-ietf-lisp-6834bis-02.txt   draft-ietf-lisp-6834bis-03.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 INRIA Sophia Antipolis
Expires: March 10, 2019 O. Bonaventure Expires: August 19, 2019 O. Bonaventure
Universite catholique de Louvain Universite catholique de Louvain
September 6, 2018 February 15, 2019
Locator/ID Separation Protocol (LISP) Map-Versioning Locator/ID Separation Protocol (LISP) Map-Versioning
draft-ietf-lisp-6834bis-02 draft-ietf-lisp-6834bis-03
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 March 10, 2019. This Internet-Draft will expire on August 19, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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 44 skipping to change at page 2, line 44
8. Map Record and Map-Version . . . . . . . . . . . . . . . . . 11 8. Map Record and Map-Version . . . . . . . . . . . . . . . . . 11
9. Benefits and Case Studies for Map-Versioning . . . . . . . . 12 9. Benefits and Case Studies for Map-Versioning . . . . . . . . 12
9.1. Map-Versioning and Unidirectional Traffic . . . . . . . . 12 9.1. Map-Versioning and Unidirectional Traffic . . . . . . . . 12
9.2. Map-Versioning and Interworking . . . . . . . . . . . . . 13 9.2. Map-Versioning and Interworking . . . . . . . . . . . . . 13
9.2.1. Map-Versioning and Proxy-ITRs . . . . . . . . . . . . 13 9.2.1. Map-Versioning and Proxy-ITRs . . . . . . . . . . . . 13
9.2.2. Map-Versioning and LISP-NAT . . . . . . . . . . . . . 14 9.2.2. Map-Versioning and LISP-NAT . . . . . . . . . . . . . 14
9.2.3. Map-Versioning and Proxy-ETRs . . . . . . . . . . . . 14 9.2.3. Map-Versioning and Proxy-ETRs . . . . . . . . . . . . 14
9.3. RLOC Shutdown/Withdraw . . . . . . . . . . . . . . . . . 14 9.3. RLOC Shutdown/Withdraw . . . . . . . . . . . . . . . . . 14
9.4. Map-Version Additional Use Cases . . . . . . . . . . . . 15 9.4. Map-Version Additional Use Cases . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10.1. Map-Versioning against Traffic Disruption . . . . . . . 16 10.1. Map-Versioning against Traffic Disruption . . . . . . . 15
10.2. Map-Versioning against Reachability Information DoS . . 16 10.2. Map-Versioning against Reachability Information DoS . . 16
11. Considerations . . . . . . . . . . . . . . . . . . . . . . . 17 11. Deployment Considerations . . . . . . . . . . . . . . . . . . 16
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
14.1. Normative References . . . . . . . . . . . . . . . . . . 18 14.1. Normative References . . . . . . . . . . . . . . . . . . 18
14.2. Informative References . . . . . . . . . . . . . . . . . 19 14.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
skipping to change at page 4, line 6 skipping to change at page 4, line 6
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 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 (in the case of Cache the latest mapping for the source EID. If this is not the
bidirectional traffic). If this is not the case, a Map-Request can case, a Map-Request can be sent.
be sent.
Considerations about the deployment of LISP Map-Versioning for Considerations about the deployment of LISP Map-Versioning are
Internet traffic are discussed in Section 11. discussed in Section 11.
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 5, line 10 skipping to change at page 5, line 10
meaning that different mappings have a different version number, meaning that different mappings have a different version number,
which is also updated independently. An update in the version number which is also updated independently. An update in the version number
(i.e., a newer version) consists of incrementing by one the older (i.e., a newer version) consists of incrementing by one the older
version number. version number.
The space of version numbers has a circular order where half of the The space of version numbers has a circular order where half of the
version numbers are greater (i.e., newer) than the current Map- version numbers are greater (i.e., newer) than the current Map-
Version number and the other half of the version numbers are smaller Version number and the other half of the version numbers are smaller
(i.e., older) than the current Map-Version number. In a more formal (i.e., older) than the current Map-Version number. In a more formal
way, assuming that we have two version numbers V1 and V2 and that the way, assuming that we have two version numbers V1 and V2 and that the
numbers are expressed in N bits, the following steps MUST be numbers are expressed on N bits, the following steps MUST be
performed (in the same order as shown below) to strictly define their performed (in the same order as shown below) to strictly define their
order: order:
1. V1 = V2 : The map-version numbers are the same. 1. V1 = V2 : The Map-Version numbers are the same.
2. V2 > V1 : if and only if 2. V2 > V1 : if and only if
V2 > V1 AND (V2 - V1) <= 2**(N-1) V2 > V1 AND (V2 - V1) <= 2**(N-1)
OR OR
V1 > V2 AND (V1 - V2) > 2**(N-1) V1 > V2 AND (V1 - V2) > 2**(N-1)
3. V1 > V2 : otherwise. 3. V1 > V2 : otherwise.
skipping to change at page 5, line 52 skipping to change at page 5, line 52
4.1. The Null Map-Version 4.1. The Null Map-Version
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 Cache, then
the ETR MUST NOT compare the received Null Map-Version with the 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 Cache. When the Destination 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 destination site. This means version information is conveyed for the destination site. This means
that the ETR MUST NOT compare the value with the Map-Version number that the ETR MUST NOT compare the value with the Map-Version number
of the mapping for the destination EID present in the EID-to-RLOC of the mapping for the destination EID present in the EID-to-RLOC
Database. 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-
skipping to change at page 9, line 45 skipping to change at page 9, line 45
Such a case is not valid with respect to the specifications. Such a case is not valid with respect to the specifications.
Indeed, if the mapping is already present in the EID-to-RLOC Indeed, if the mapping is already present in the EID-to-RLOC
Cache, this means that an explicit Map-Request has been sent and Cache, this means that an explicit Map-Request has been sent and
a Map-Reply has been received from an authoritative source. a Map-Reply has been received from an authoritative source.
Assuming that the mapping system is not corrupted, the Map- Assuming that the mapping system is not corrupted, the Map-
Version in the EID-to-RLOC Cache is the correct one, while the Version in the EID-to-RLOC Cache is the correct one, while the
one carried by the packet is stale. In this situation, the one carried by the packet is stale. In this situation, the
packet MAY be silently dropped. 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 Cache for the
source EID, then the Source Map-Version number can be safely ignored. 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
skipping to change at page 15, line 13 skipping to change at page 15, 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.
9.4. Map-Version Additional Use Cases 9.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 is 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
explained in [I-D.ietf-lisp-rfc6830bis]. A new mapping with a new explained in [I-D.ietf-lisp-rfc6830bis]. A new mapping with a new
Map-Version number will be issued, and since the old locators are Map-Version number will be issued, and since the old locators are
still valid, the transition will occur with no disruptions. The same still valid, the transition will occur with no disruptions. The same
applies for the case where an RLOC is withdrawn. There is no need to 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.
Map-Versioning can be used as a substitute for the "clock sweep"
operation described in Section 6.6.1 of [I-D.ietf-lisp-rfc6833bis].
Indeed, every LISP site communicating to a specific LISP site that
has updated the mapping will be informed of the available new mapping
in a data-driven manner.
10. Security Considerations 10. 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
skipping to change at page 17, line 7 skipping to change at page 16, line 48
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. Considerations 11. 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. The implications mapping for the same EID-Prefix to a requester. Map-Versioning does
that a temporary lack of synchronization may have on the traffic are not require additional synchronization mechanisms as compared to the
yet to be fully explored. normal functioning of LISP without Map-Versioning. Clearly, all the
ETRs have to reply with the same Map-Version number; otherwise, there
Map-Versioning does not require additional synchronization mechanisms can be an inconsistency that creates additional control traffic,
as compared to the normal functioning of LISP without Map-Versioning. instabilities, and traffic disruptions. It is the same without Map-
Clearly, all the ETRs have to reply with the same Map-Version number; Versioning, with ETRs that have to reply with the same mapping;
otherwise, there can be an inconsistency that creates additional otherwise, the same problems can arise.
control traffic, instabilities, and traffic disruptions. It is the
same without Map-Versioning, with ETRs that have to reply with the
same mapping; otherwise, the same problems can arise.
There are two ways Map-Versioning is helpful with respect to the There are two ways Map-Versioning is helpful with respect to the
synchronization problem. On the one hand, assigning version numbers synchronization problem. On the one hand, assigning version numbers
to mappings helps in debugging, since quick checks on the consistency to mappings helps in debugging, since quick checks on the consistency
of the mappings on different ETRs can be done by looking at the Map- of the mappings on different ETRs can be done by looking at the Map-
Version number. On the other hand, Map-Versioning can be used to Version number. On the other hand, Map-Versioning can be used to
control the traffic toward ETRs that announce the latest mapping. control the traffic toward ETRs that announce the latest mapping.
As an example, let's consider the topology of Figure 4 where ITR A.1 As an example, let's consider the topology of Figure 4 where ITR A.1
of Domain A is sending unidirectional traffic to Domain B, while A.2 of Domain A is sending unidirectional traffic to Domain B, while A.2
skipping to change at page 18, line 42 skipping to change at page 18, line 31
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 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-lisp-gpe] [I-D.ietf-lisp-gpe]
Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M. Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M.
Smith, "LISP Generic Protocol Extension", draft-ietf-lisp- Smith, "LISP Generic Protocol Extension", draft-ietf-lisp-
gpe-05 (work in progress), August 2018. 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-16 (work in progress), (LISP)", draft-ietf-lisp-rfc6830bis-26 (work in progress),
August 2018. November 2018.
[I-D.ietf-lisp-rfc6833bis] [I-D.ietf-lisp-rfc6833bis]
Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, Fuller, V., Farinacci, D., and A. Cabellos-Aparicio,
"Locator/ID Separation Protocol (LISP) Control-Plane", "Locator/ID Separation Protocol (LISP) Control-Plane",
draft-ietf-lisp-rfc6833bis-13 (work in progress), August draft-ietf-lisp-rfc6833bis-24 (work in progress), February
2018. 2019.
[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>.
 End of changes. 21 change blocks. 
42 lines changed or deleted 32 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/