< draft-ietf-lisp-rfc6830bis-26.txt | draft-ietf-lisp-rfc6830bis-27.txt > | |||
---|---|---|---|---|
Network Working Group D. Farinacci | Network Working Group D. Farinacci | |||
Internet-Draft V. Fuller | Internet-Draft V. Fuller | |||
Obsoletes: 6830 (if approved) D. Meyer | Obsoletes: 6830 (if approved) D. Meyer | |||
Intended status: Standards Track D. Lewis | Intended status: Standards Track D. Lewis | |||
Expires: May 8, 2019 Cisco Systems | Expires: August 10, 2019 Cisco Systems | |||
A. Cabellos (Ed.) | A. Cabellos (Ed.) | |||
UPC/BarcelonaTech | UPC/BarcelonaTech | |||
November 4, 2018 | February 6, 2019 | |||
The Locator/ID Separation Protocol (LISP) | The Locator/ID Separation Protocol (LISP) | |||
draft-ietf-lisp-rfc6830bis-26 | draft-ietf-lisp-rfc6830bis-27 | |||
Abstract | Abstract | |||
This document describes the Data-Plane protocol for the Locator/ID | This document describes the Data-Plane protocol for the Locator/ID | |||
Separation Protocol (LISP). LISP defines two namespaces, End-point | Separation Protocol (LISP). LISP defines two namespaces, End-point | |||
Identifiers (EIDs) that identify end-hosts and Routing Locators | Identifiers (EIDs) that identify end-hosts and Routing Locators | |||
(RLOCs) that identify network attachment points. With this, LISP | (RLOCs) that identify network attachment points. With this, LISP | |||
effectively separates control from data, and allows routers to create | effectively separates control from data, and allows routers to create | |||
overlay networks. LISP-capable routers exchange encapsulated packets | overlay networks. LISP-capable routers exchange encapsulated packets | |||
according to EID-to-RLOC mappings stored in a local Map-Cache. | according to EID-to-RLOC mappings stored in a local Map-Cache. | |||
skipping to change at page 1, line 46 ¶ | skipping to change at page 1, line 46 ¶ | |||
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 May 8, 2019. | This Internet-Draft will expire on August 10, 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 40 ¶ | skipping to change at page 2, line 40 ¶ | |||
5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 14 | 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 14 | |||
5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . 15 | 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . 15 | |||
6. LISP EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 20 | 6. LISP EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 20 | |||
7. Dealing with Large Encapsulated Packets . . . . . . . . . . . 20 | 7. Dealing with Large Encapsulated Packets . . . . . . . . . . . 20 | |||
7.1. A Stateless Solution to MTU Handling . . . . . . . . . . 21 | 7.1. A Stateless Solution to MTU Handling . . . . . . . . . . 21 | |||
7.2. A Stateful Solution to MTU Handling . . . . . . . . . . . 22 | 7.2. A Stateful Solution to MTU Handling . . . . . . . . . . . 22 | |||
8. Using Virtualization and Segmentation with LISP . . . . . . . 22 | 8. Using Virtualization and Segmentation with LISP . . . . . . . 22 | |||
9. Routing Locator Selection . . . . . . . . . . . . . . . . . . 23 | 9. Routing Locator Selection . . . . . . . . . . . . . . . . . . 23 | |||
10. Routing Locator Reachability . . . . . . . . . . . . . . . . 25 | 10. Routing Locator Reachability . . . . . . . . . . . . . . . . 25 | |||
10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 26 | 10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 26 | |||
11. EID Reachability within a LISP Site . . . . . . . . . . . . . 27 | 11. EID Reachability within a LISP Site . . . . . . . . . . . . . 28 | |||
12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 28 | 12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 28 | |||
13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 29 | 13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 29 | |||
13.1. Database Map-Versioning . . . . . . . . . . . . . . . . 30 | 13.1. Database Map-Versioning . . . . . . . . . . . . . . . . 30 | |||
14. Multicast Considerations . . . . . . . . . . . . . . . . . . 31 | 14. Multicast Considerations . . . . . . . . . . . . . . . . . . 31 | |||
15. Router Performance Considerations . . . . . . . . . . . . . . 31 | 15. Router Performance Considerations . . . . . . . . . . . . . . 32 | |||
16. Security Considerations . . . . . . . . . . . . . . . . . . . 32 | 16. Security Considerations . . . . . . . . . . . . . . . . . . . 32 | |||
17. Network Management Considerations . . . . . . . . . . . . . . 33 | 17. Network Management Considerations . . . . . . . . . . . . . . 33 | |||
18. Changes since RFC 6830 . . . . . . . . . . . . . . . . . . . 33 | 18. Changes since RFC 6830 . . . . . . . . . . . . . . . . . . . 33 | |||
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 | 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 | |||
19.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 34 | 19.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 34 | |||
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 | 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
20.1. Normative References . . . . . . . . . . . . . . . . . . 34 | 20.1. Normative References . . . . . . . . . . . . . . . . . . 34 | |||
20.2. Informative References . . . . . . . . . . . . . . . . . 35 | 20.2. Informative References . . . . . . . . . . . . . . . . . 36 | |||
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39 | Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39 | |||
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 40 | Appendix B. Document Change Log . . . . . . . . . . . . . . . . 40 | |||
B.1. Changes to draft-ietf-lisp-rfc6830bis-26 . . . . . . . . 40 | B.1. Changes to draft-ietf-lisp-rfc6830bis-27 . . . . . . . . 40 | |||
B.2. Changes to draft-ietf-lisp-rfc6830bis-25 . . . . . . . . 40 | B.2. Changes to draft-ietf-lisp-rfc6830bis-26 . . . . . . . . 40 | |||
B.3. Changes to draft-ietf-lisp-rfc6830bis-24 . . . . . . . . 40 | B.3. Changes to draft-ietf-lisp-rfc6830bis-25 . . . . . . . . 40 | |||
B.4. Changes to draft-ietf-lisp-rfc6830bis-23 . . . . . . . . 40 | B.4. Changes to draft-ietf-lisp-rfc6830bis-24 . . . . . . . . 40 | |||
B.5. Changes to draft-ietf-lisp-rfc6830bis-22 . . . . . . . . 40 | B.5. Changes to draft-ietf-lisp-rfc6830bis-23 . . . . . . . . 40 | |||
B.6. Changes to draft-ietf-lisp-rfc6830bis-21 . . . . . . . . 40 | B.6. Changes to draft-ietf-lisp-rfc6830bis-22 . . . . . . . . 40 | |||
B.7. Changes to draft-ietf-lisp-rfc6830bis-20 . . . . . . . . 41 | B.7. Changes to draft-ietf-lisp-rfc6830bis-21 . . . . . . . . 41 | |||
B.8. Changes to draft-ietf-lisp-rfc6830bis-19 . . . . . . . . 41 | B.8. Changes to draft-ietf-lisp-rfc6830bis-20 . . . . . . . . 41 | |||
B.9. Changes to draft-ietf-lisp-rfc6830bis-18 . . . . . . . . 41 | B.9. Changes to draft-ietf-lisp-rfc6830bis-19 . . . . . . . . 41 | |||
B.10. Changes to draft-ietf-lisp-rfc6830bis-17 . . . . . . . . 41 | B.10. Changes to draft-ietf-lisp-rfc6830bis-18 . . . . . . . . 41 | |||
B.11. Changes to draft-ietf-lisp-rfc6830bis-16 . . . . . . . . 41 | B.11. Changes to draft-ietf-lisp-rfc6830bis-17 . . . . . . . . 41 | |||
B.12. Changes to draft-ietf-lisp-rfc6830bis-15 . . . . . . . . 41 | B.12. Changes to draft-ietf-lisp-rfc6830bis-16 . . . . . . . . 41 | |||
B.13. Changes to draft-ietf-lisp-rfc6830bis-14 . . . . . . . . 42 | B.13. Changes to draft-ietf-lisp-rfc6830bis-15 . . . . . . . . 41 | |||
B.14. Changes to draft-ietf-lisp-rfc6830bis-13 . . . . . . . . 42 | B.14. Changes to draft-ietf-lisp-rfc6830bis-14 . . . . . . . . 42 | |||
B.15. Changes to draft-ietf-lisp-rfc6830bis-12 . . . . . . . . 42 | B.15. Changes to draft-ietf-lisp-rfc6830bis-13 . . . . . . . . 42 | |||
B.16. Changes to draft-ietf-lisp-rfc6830bis-11 . . . . . . . . 42 | B.16. Changes to draft-ietf-lisp-rfc6830bis-12 . . . . . . . . 42 | |||
B.17. Changes to draft-ietf-lisp-rfc6830bis-10 . . . . . . . . 42 | B.17. Changes to draft-ietf-lisp-rfc6830bis-11 . . . . . . . . 42 | |||
B.18. Changes to draft-ietf-lisp-rfc6830bis-09 . . . . . . . . 43 | B.18. Changes to draft-ietf-lisp-rfc6830bis-10 . . . . . . . . 42 | |||
B.19. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . 43 | B.19. Changes to draft-ietf-lisp-rfc6830bis-09 . . . . . . . . 43 | |||
B.20. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . 43 | B.20. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . 43 | |||
B.21. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 43 | B.21. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . 43 | |||
B.22. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 44 | B.22. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 43 | |||
B.23. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 44 | B.23. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 44 | |||
B.24. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 44 | B.24. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 44 | |||
B.25. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 44 | B.25. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 44 | |||
B.26. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 44 | B.26. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 44 | |||
B.27. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 45 | B.27. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 44 | |||
B.28. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 45 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 | |||
1. Introduction | 1. Introduction | |||
This document describes the Locator/Identifier Separation Protocol | This document describes the Locator/Identifier Separation Protocol | |||
(LISP). LISP is an encapsulation protocol built around the | (LISP). LISP is an encapsulation protocol built around the | |||
fundamental idea of separating the topological location of a network | fundamental idea of separating the topological location of a network | |||
attachment point from the node's identity [CHIAPPA]. As a result | attachment point from the node's identity [CHIAPPA]. As a result | |||
LISP creates two namespaces: Endpoint Identifiers (EIDs), that are | LISP creates two namespaces: Endpoint Identifiers (EIDs), that are | |||
used to identify end-hosts (e.g., nodes or Virtual Machines) and | used to identify end-hosts (e.g., nodes or Virtual Machines) and | |||
skipping to change at page 4, line 13 ¶ | skipping to change at page 4, line 13 ¶ | |||
provisioning is required or necessary. | provisioning is required or necessary. | |||
LISP is an overlay protocol that separates control from Data-Plane, | LISP is an overlay protocol that separates control from Data-Plane, | |||
this document specifies the Data-Plane, how LISP-capable routers | this document specifies the Data-Plane, how LISP-capable routers | |||
(Tunnel Routers) exchange packets by encapsulating them to the | (Tunnel Routers) exchange packets by encapsulating them to the | |||
appropriate location. Tunnel routers are equipped with a cache, | appropriate location. Tunnel routers are equipped with a cache, | |||
called Map-Cache, that contains EID-to-RLOC mappings. The Map-Cache | called Map-Cache, that contains EID-to-RLOC mappings. The Map-Cache | |||
is populated using the LISP Control-Plane protocol | is populated using the LISP Control-Plane protocol | |||
[I-D.ietf-lisp-rfc6833bis]. | [I-D.ietf-lisp-rfc6833bis]. | |||
LISP does not require changes to either host protocol stack or to | LISP does not require changes to either the host protocol stack or to | |||
underlay routers. By separating the EID from the RLOC space, LISP | underlay routers. By separating the EID from the RLOC space, LISP | |||
offers native Traffic Engineering, multihoming and mobility, among | offers native Traffic Engineering, multihoming and mobility, among | |||
other features. | other features. | |||
Creation of LISP was initially motivated by discussions during the | Creation of LISP was initially motivated by discussions during the | |||
IAB-sponsored Routing and Addressing Workshop held in Amsterdam in | IAB-sponsored Routing and Addressing Workshop held in Amsterdam in | |||
October 2006 (see [RFC4984]). | October 2006 (see [RFC4984]). | |||
This document specifies the LISP Data-Plane encapsulation and other | This document specifies the LISP Data-Plane encapsulation and other | |||
LISP forwarding node functionality while [I-D.ietf-lisp-rfc6833bis] | LISP forwarding node functionality while [I-D.ietf-lisp-rfc6833bis] | |||
skipping to change at page 21, line 49 ¶ | skipping to change at page 21, line 49 ¶ | |||
then forwards each fragment to the destination host of the | then forwards each fragment to the destination host of the | |||
destination site. The two fragments are reassembled at the | destination site. The two fragments are reassembled at the | |||
destination host into the single IP datagram that was originated by | destination host into the single IP datagram that was originated by | |||
the source host. Note that reassembly can happen at the ETR if the | the source host. Note that reassembly can happen at the ETR if the | |||
encapsulated packet was fragmented at or after the ITR. | encapsulated packet was fragmented at or after the ITR. | |||
This behavior MUST be performed by the ITR only when the source host | This behavior MUST be performed by the ITR only when the source host | |||
originates a packet with the 'DF' field of the IP header set to 0. | originates a packet with the 'DF' field of the IP header set to 0. | |||
When the 'DF' field of the IP header is set to 1, or the packet is an | When the 'DF' field of the IP header is set to 1, or the packet is an | |||
IPv6 packet originated by the source host, the ITR will drop the | IPv6 packet originated by the source host, the ITR will drop the | |||
packet when the size is greater than L and send an ICMPv4 ICMP | packet when the size (adding in the size of the encapsulation header) | |||
Unreachable/Fragmentation-Needed or ICMPv6 "Packet Too Big" message | is greater than L and send an ICMPv4 ICMP Unreachable/Fragmentation- | |||
to the source with a value of S, where S is (L - H). | Needed or ICMPv6 "Packet Too Big" message to the source with a value | |||
of S, where S is (L - H). | ||||
When the outer-header encapsulation uses an IPv4 header, an | When the outer-header encapsulation uses an IPv4 header, an | |||
implementation SHOULD set the DF bit to 1 so ETR fragment reassembly | implementation SHOULD set the DF bit to 1 so ETR fragment reassembly | |||
can be avoided. An implementation MAY set the DF bit in such headers | can be avoided. An implementation MAY set the DF bit in such headers | |||
to 0 if it has good reason to believe there are unresolvable path MTU | to 0 if it has good reason to believe there are unresolvable path MTU | |||
issues between the sending ITR and the receiving ETR. | issues between the sending ITR and the receiving ETR. | |||
This specification RECOMMENDS that L be defined as 1500. | This specification RECOMMENDS that L be defined as 1500. | |||
7.2. A Stateful Solution to MTU Handling | 7.2. A Stateful Solution to MTU Handling | |||
skipping to change at page 24, line 14 ¶ | skipping to change at page 24, line 19 ¶ | |||
splitting across its members. The client-side can use RLOCs | splitting across its members. The client-side can use RLOCs | |||
outside of the subset list if it determines that the subset list | outside of the subset list if it determines that the subset list | |||
is unreachable (unless RLOCs are set to a Priority of 255). Some | is unreachable (unless RLOCs are set to a Priority of 255). Some | |||
sharing of control exists: the server-side determines the | sharing of control exists: the server-side determines the | |||
destination RLOC list and load distribution while the client-side | destination RLOC list and load distribution while the client-side | |||
has the option of using alternatives to this list if RLOCs in the | has the option of using alternatives to this list if RLOCs in the | |||
list are unreachable. | list are unreachable. | |||
o The server-side sets a Weight of zero for the RLOC subset list. | o The server-side sets a Weight of zero for the RLOC subset list. | |||
In this case, the client-side can choose how the traffic load is | In this case, the client-side can choose how the traffic load is | |||
spread across the subset list. Control is shared by the server- | spread across the subset list. See Section 12 for details on | |||
side determining the list and the client-side determining load | load-sharing mechanisms. Control is shared by the server-side | |||
determining the list and the client-side determining load | ||||
distribution. Again, the client can use alternative RLOCs if the | distribution. Again, the client can use alternative RLOCs if the | |||
server-provided list of RLOCs is unreachable. | server-provided list of RLOCs is unreachable. | |||
o Either side (more likely the server-side ETR) decides not to send | o Either side (more likely the server-side ETR) decides not to send | |||
a Map-Request. For example, if the server-side ETR does not send | a Map-Request. For example, if the server-side ETR does not send | |||
Map-Requests, it gleans RLOCs from the client-side ITR, giving the | Map-Requests, it gleans RLOCs from the client-side ITR, giving the | |||
client-side ITR responsibility for bidirectional RLOC reachability | client-side ITR responsibility for bidirectional RLOC reachability | |||
and preferability. Server-side ETR gleaning of the client-side | and preferability. Server-side ETR gleaning of the client-side | |||
ITR RLOC is done by caching the inner-header source EID and the | ITR RLOC is done by caching the inner-header source EID and the | |||
outer-header source RLOC of received packets. The client-side ITR | outer-header source RLOC of received packets. The client-side ITR | |||
skipping to change at page 27, line 44 ¶ | skipping to change at page 27, line 49 ¶ | |||
unidirectional so there is no ITR returning traffic. | unidirectional so there is no ITR returning traffic. | |||
The echo-nonce algorithm is bilateral. That is, if one side sets the | The echo-nonce algorithm is bilateral. That is, if one side sets the | |||
E-bit and the other side is not enabled for echo-noncing, then the | E-bit and the other side is not enabled for echo-noncing, then the | |||
echoing of the nonce does not occur and the requesting side may | echoing of the nonce does not occur and the requesting side may | |||
erroneously consider the Locator unreachable. An ITR SHOULD only set | erroneously consider the Locator unreachable. An ITR SHOULD only set | |||
the E-bit in an encapsulated data packet when it knows the ETR is | the E-bit in an encapsulated data packet when it knows the ETR is | |||
enabled for echo-noncing. This is conveyed by the E-bit in the RLOC- | enabled for echo-noncing. This is conveyed by the E-bit in the RLOC- | |||
probe Map-Reply message. | probe Map-Reply message. | |||
Many implementations default to not advertising they are echo-nonce | ||||
capable in Map-Reply messages and so RLOC-probing tends to be used | ||||
for RLOC reachability. | ||||
11. EID Reachability within a LISP Site | 11. EID Reachability within a LISP Site | |||
A site MAY be multihomed using two or more ETRs. The hosts and | A site MAY be multihomed using two or more ETRs. The hosts and | |||
infrastructure within a site will be addressed using one or more EID- | infrastructure within a site will be addressed using one or more EID- | |||
Prefixes that are mapped to the RLOCs of the relevant ETRs in the | Prefixes that are mapped to the RLOCs of the relevant ETRs in the | |||
mapping system. One possible failure mode is for an ETR to lose | mapping system. One possible failure mode is for an ETR to lose | |||
reachability to one or more of the EID-Prefixes within its own site. | reachability to one or more of the EID-Prefixes within its own site. | |||
When this occurs when the ETR sends Map-Replies, it can clear the | When this occurs when the ETR sends Map-Replies, it can clear the | |||
R-bit associated with its own Locator. And when the ETR is also an | R-bit associated with its own Locator. And when the ETR is also an | |||
ITR, it can clear its Locator-Status-Bit in the encapsulation data | ITR, it can clear its Locator-Status-Bit in the encapsulation data | |||
skipping to change at page 33, line 5 ¶ | skipping to change at page 33, line 13 ¶ | |||
overloading it. | overloading it. | |||
The LISP Data-Plane defines several mechanisms to monitor RLOC Data- | The LISP Data-Plane defines several mechanisms to monitor RLOC Data- | |||
Plane reachability, in this context Locator-Status Bits, Nonce- | Plane reachability, in this context Locator-Status Bits, Nonce- | |||
Present and Echo-Nonce bits of the LISP encapsulation header can be | Present and Echo-Nonce bits of the LISP encapsulation header can be | |||
manipulated by an attacker to mount a DoS attack. An off-path | manipulated by an attacker to mount a DoS attack. An off-path | |||
attacker able to spoof the RLOC and/or nonce of a victim's xTR can | attacker able to spoof the RLOC and/or nonce of a victim's xTR can | |||
manipulate such mechanisms to declare false information about the | manipulate such mechanisms to declare false information about the | |||
RLOC's reachability status. | RLOC's reachability status. | |||
As an exmple of such attacks an off-path attacker can exploit the | For example of such attacks, an off-path attacker can exploit the | |||
echo-nonce mechanism by sending data packets to an ITR with a random | echo-nonce mechanism by sending data packets to an ITR with a random | |||
nonce from an ETR's spoofed RLOC. Note the attacker must guess a | nonce from an ETR's spoofed RLOC. Note the attacker must guess a | |||
valid nonce the ITR is requesting to be echoed within a small window | valid nonce the ITR is requesting to be echoed within a small window | |||
of time. The goal is to convince the ITR that the ETR's RLOC is | of time. The goal is to convince the ITR that the ETR's RLOC is | |||
reachable even when it may not be reachable. If the attack is | reachable even when it may not be reachable. If the attack is | |||
successful, the ITR believes the wrong reachability status of the | successful, the ITR believes the wrong reachability status of the | |||
ETR's RLOC until RLOC-probing detects the correct status. This time | ETR's RLOC until RLOC-probing detects the correct status. This time | |||
frame is on the order of 10s of seconds. This specific attack can be | frame is on the order of 10s of seconds. This specific attack can be | |||
mitigated by preventing RLOC spoofing in the network by deploying | mitigated by preventing RLOC spoofing in the network by deploying | |||
uRPF BCP 38 [RFC2827]. In addition and in order to exploit this | uRPF BCP 38 [RFC2827]. In addition and in order to exploit this | |||
vulnerability, the off-path attacker must send echo-nonce packets at | vulnerability, the off-path attacker must send echo-nonce packets at | |||
high rate. If the nonces have never been requested by the ITR, it | high rate. If the nonces have never been requested by the ITR, it | |||
can protect itself from erroneious reachability attacks. | can protect itself from erroneous reachability attacks. | |||
Map-Versioning is a Data-Plane mechanism used to signal a peering xTR | Map-Versioning is a Data-Plane mechanism used to signal a peering xTR | |||
that a local EID-to-RLOC mapping has been updated, so that the | that a local EID-to-RLOC mapping has been updated, so that the | |||
peering xTR uses LISP Control-Plane signaling message to retrieve a | peering xTR uses LISP Control-Plane signaling message to retrieve a | |||
fresh mapping. This can be used by an attacker to forge the map- | fresh mapping. This can be used by an attacker to forge the map- | |||
versioning field of a LISP encapsulated header and force an excessive | versioning field of a LISP encapsulated header and force an excessive | |||
amount of signaling between xTRs that may overload them. | amount of signaling between xTRs that may overload them. | |||
Most of the attack vectors can be mitigated with careful deployment | Most of the attack vectors can be mitigated with careful deployment | |||
and configuration, information learned opportunistically (such as LSB | and configuration, information learned opportunistically (such as LSB | |||
skipping to change at page 34, line 44 ¶ | skipping to change at page 35, line 8 ¶ | |||
20.1. Normative References | 20.1. Normative References | |||
[I-D.ietf-lisp-6834bis] | [I-D.ietf-lisp-6834bis] | |||
Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID | Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID | |||
Separation Protocol (LISP) Map-Versioning", draft-ietf- | Separation Protocol (LISP) Map-Versioning", draft-ietf- | |||
lisp-6834bis-02 (work in progress), September 2018. | lisp-6834bis-02 (work in progress), September 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-19 (work in progress), October | draft-ietf-lisp-rfc6833bis-24 (work in progress), February | |||
2018. | 2019. | |||
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | |||
DOI 10.17487/RFC0768, August 1980, | DOI 10.17487/RFC0768, August 1980, | |||
<https://www.rfc-editor.org/info/rfc768>. | <https://www.rfc-editor.org/info/rfc768>. | |||
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, | [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, | |||
DOI 10.17487/RFC0791, September 1981, | DOI 10.17487/RFC0791, September 1981, | |||
<https://www.rfc-editor.org/info/rfc791>. | <https://www.rfc-editor.org/info/rfc791>. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
skipping to change at page 36, line 13 ¶ | skipping to change at page 36, line 22 ¶ | |||
<http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>. | <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>. | |||
[I-D.ietf-lisp-introduction] | [I-D.ietf-lisp-introduction] | |||
Cabellos-Aparicio, A. and D. Saucez, "An Architectural | Cabellos-Aparicio, A. and D. Saucez, "An Architectural | |||
Introduction to the Locator/ID Separation Protocol | Introduction to the Locator/ID Separation Protocol | |||
(LISP)", draft-ietf-lisp-introduction-13 (work in | (LISP)", draft-ietf-lisp-introduction-13 (work in | |||
progress), April 2015. | progress), April 2015. | |||
[I-D.ietf-lisp-vpn] | [I-D.ietf-lisp-vpn] | |||
Moreno, V. and D. Farinacci, "LISP Virtual Private | Moreno, V. and D. Farinacci, "LISP Virtual Private | |||
Networks (VPNs)", draft-ietf-lisp-vpn-02 (work in | Networks (VPNs)", draft-ietf-lisp-vpn-03 (work in | |||
progress), May 2018. | progress), November 2018. | |||
[OPENLISP] | [OPENLISP] | |||
Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP | Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP | |||
Implementation Report", Work in Progress, July 2008. | Implementation Report", Work in Progress, July 2008. | |||
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", | [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", | |||
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, | STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, | |||
<https://www.rfc-editor.org/info/rfc1034>. | <https://www.rfc-editor.org/info/rfc1034>. | |||
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., | [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., | |||
skipping to change at page 40, line 12 ¶ | skipping to change at page 40, line 12 ¶ | |||
Kaduk, Eric Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper, | Kaduk, Eric Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper, | |||
Suresh Krishnan, Alberto Rodriguez-Natal, Vina Ermagen, Mohamed | Suresh Krishnan, Alberto Rodriguez-Natal, Vina Ermagen, Mohamed | |||
Boucadair, Brian Trammell, Sabrina Tanamal, and John Drake. The | Boucadair, Brian Trammell, Sabrina Tanamal, and John Drake. The | |||
contributions they offered greatly added to the security, scale, and | contributions they offered greatly added to the security, scale, and | |||
robustness of the LISP architecture and protocols. | robustness of the LISP architecture and protocols. | |||
Appendix B. Document Change Log | Appendix B. Document Change Log | |||
[RFC Editor: Please delete this section on publication as RFC.] | [RFC Editor: Please delete this section on publication as RFC.] | |||
B.1. Changes to draft-ietf-lisp-rfc6830bis-26 | B.1. Changes to draft-ietf-lisp-rfc6830bis-27 | |||
o Posted February 2019 just before Thu telechat. | ||||
o Made editorial corrections per Warren's suggestions. | ||||
B.2. Changes to draft-ietf-lisp-rfc6830bis-26 | ||||
o Posted late October 2018. | o Posted late October 2018. | |||
o Changed description about "reserved" bits to state "reserved and | o Changed description about "reserved" bits to state "reserved and | |||
unassigned". | unassigned". | |||
B.2. Changes to draft-ietf-lisp-rfc6830bis-25 | B.3. Changes to draft-ietf-lisp-rfc6830bis-25 | |||
o Posted mid October 2018. | o Posted mid October 2018. | |||
o Added more to the Security Considerations section with discussion | o Added more to the Security Considerations section with discussion | |||
about echo-nonce attacks. | about echo-nonce attacks. | |||
B.3. Changes to draft-ietf-lisp-rfc6830bis-24 | B.4. Changes to draft-ietf-lisp-rfc6830bis-24 | |||
o Posted mid October 2018. | o Posted mid October 2018. | |||
o Final editorial changes for Eric and Ben. | o Final editorial changes for Eric and Ben. | |||
B.4. Changes to draft-ietf-lisp-rfc6830bis-23 | B.5. Changes to draft-ietf-lisp-rfc6830bis-23 | |||
o Posted early October 2018. | o Posted early October 2018. | |||
o Added an applicability statement in section 1 to address security | o Added an applicability statement in section 1 to address security | |||
concerns from Telechat. | concerns from Telechat. | |||
B.5. Changes to draft-ietf-lisp-rfc6830bis-22 | B.6. Changes to draft-ietf-lisp-rfc6830bis-22 | |||
o Posted early October 2018. | o Posted early October 2018. | |||
o Changes to reflect comments post Telechat. | o Changes to reflect comments post Telechat. | |||
B.6. Changes to draft-ietf-lisp-rfc6830bis-21 | B.7. Changes to draft-ietf-lisp-rfc6830bis-21 | |||
o Posted late-September 2018. | o Posted late-September 2018. | |||
o Changes to reflect comments from Sep 27th Telechat. | o Changes to reflect comments from Sep 27th Telechat. | |||
B.7. Changes to draft-ietf-lisp-rfc6830bis-20 | B.8. Changes to draft-ietf-lisp-rfc6830bis-20 | |||
o Posted late-September 2018. | o Posted late-September 2018. | |||
o Fix old reference to RFC3168, changed to RFC6040. | o Fix old reference to RFC3168, changed to RFC6040. | |||
B.8. Changes to draft-ietf-lisp-rfc6830bis-19 | B.9. Changes to draft-ietf-lisp-rfc6830bis-19 | |||
o Posted late-September 2018. | o Posted late-September 2018. | |||
o More editorial changes. | o More editorial changes. | |||
B.9. Changes to draft-ietf-lisp-rfc6830bis-18 | B.10. Changes to draft-ietf-lisp-rfc6830bis-18 | |||
o Posted mid-September 2018. | o Posted mid-September 2018. | |||
o Changes to reflect comments from Secdir review (Mirja). | o Changes to reflect comments from Secdir review (Mirja). | |||
B.10. Changes to draft-ietf-lisp-rfc6830bis-17 | B.11. Changes to draft-ietf-lisp-rfc6830bis-17 | |||
o Posted September 2018. | o Posted September 2018. | |||
o Indicate in the "Changes since RFC 6830" section why the document | o Indicate in the "Changes since RFC 6830" section why the document | |||
has been shortened in length. | has been shortened in length. | |||
o Make reference to RFC 8085 about UDP congestion control. | o Make reference to RFC 8085 about UDP congestion control. | |||
o More editorial changes from multiple IESG reviews. | o More editorial changes from multiple IESG reviews. | |||
B.11. Changes to draft-ietf-lisp-rfc6830bis-16 | B.12. Changes to draft-ietf-lisp-rfc6830bis-16 | |||
o Posted late August 2018. | o Posted late August 2018. | |||
o Distinguish the message type names between ICMP for IPv4 and ICMP | o Distinguish the message type names between ICMP for IPv4 and ICMP | |||
for IPv6 for handling MTU issues. | for IPv6 for handling MTU issues. | |||
B.12. Changes to draft-ietf-lisp-rfc6830bis-15 | B.13. Changes to draft-ietf-lisp-rfc6830bis-15 | |||
o Posted August 2018. | o Posted August 2018. | |||
o Final editorial changes before RFC submission for Proposed | o Final editorial changes before RFC submission for Proposed | |||
Standard. | Standard. | |||
o Added section "Changes since RFC 6830" so implementers are | o Added section "Changes since RFC 6830" so implementers are | |||
informed of any changes since the last RFC publication. | informed of any changes since the last RFC publication. | |||
B.13. Changes to draft-ietf-lisp-rfc6830bis-14 | B.14. Changes to draft-ietf-lisp-rfc6830bis-14 | |||
o Posted July 2018 IETF week. | o Posted July 2018 IETF week. | |||
o Put obsolete of RFC 6830 in Intro section in addition to abstract. | o Put obsolete of RFC 6830 in Intro section in addition to abstract. | |||
B.14. Changes to draft-ietf-lisp-rfc6830bis-13 | B.15. Changes to draft-ietf-lisp-rfc6830bis-13 | |||
o Posted March IETF Week 2018. | o Posted March IETF Week 2018. | |||
o Clarified that a new nonce is required per RLOC. | o Clarified that a new nonce is required per RLOC. | |||
o Removed 'Clock Sweep' section. This text must be placed in a new | o Removed 'Clock Sweep' section. This text must be placed in a new | |||
OAM document. | OAM document. | |||
o Some references changed from normative to informative | o Some references changed from normative to informative | |||
B.15. Changes to draft-ietf-lisp-rfc6830bis-12 | B.16. Changes to draft-ietf-lisp-rfc6830bis-12 | |||
o Posted July 2018. | o Posted July 2018. | |||
o Fixed Luigi editorial comments to ready draft for RFC status. | o Fixed Luigi editorial comments to ready draft for RFC status. | |||
B.16. Changes to draft-ietf-lisp-rfc6830bis-11 | B.17. Changes to draft-ietf-lisp-rfc6830bis-11 | |||
o Posted March 2018. | o Posted March 2018. | |||
o Removed sections 16, 17 and 18 (Mobility, Deployment and | o Removed sections 16, 17 and 18 (Mobility, Deployment and | |||
Traceroute considerations). This text must be placed in a new OAM | Traceroute considerations). This text must be placed in a new OAM | |||
document. | document. | |||
B.17. Changes to draft-ietf-lisp-rfc6830bis-10 | B.18. Changes to draft-ietf-lisp-rfc6830bis-10 | |||
o Posted March 2018. | o Posted March 2018. | |||
o Updated section 'Router Locator Selection' stating that the Data- | o Updated section 'Router Locator Selection' stating that the Data- | |||
Plane MUST follow what's stored in the Map-Cache (priorities and | Plane MUST follow what's stored in the Map-Cache (priorities and | |||
weights). | weights). | |||
o Section 'Routing Locator Reachability': Removed bullet point 2 | o Section 'Routing Locator Reachability': Removed bullet point 2 | |||
(ICMP Network/Host Unreachable),3 (hints from BGP),4 (ICMP Port | (ICMP Network/Host Unreachable),3 (hints from BGP),4 (ICMP Port | |||
Unreachable),5 (receive a Map-Reply as a response) and RLOC | Unreachable),5 (receive a Map-Reply as a response) and RLOC | |||
probing | probing | |||
o Removed 'Solicit-Map Request'. | o Removed 'Solicit-Map Request'. | |||
B.18. Changes to draft-ietf-lisp-rfc6830bis-09 | B.19. Changes to draft-ietf-lisp-rfc6830bis-09 | |||
o Posted January 2018. | o Posted January 2018. | |||
o Add more details in section 5.3 about DSCP processing during | o Add more details in section 5.3 about DSCP processing during | |||
encapsulation and decapsulation. | encapsulation and decapsulation. | |||
o Added clarity to definitions in the Definition of Terms section | o Added clarity to definitions in the Definition of Terms section | |||
from various commenters. | from various commenters. | |||
o Removed PA and PI definitions from Definition of Terms section. | o Removed PA and PI definitions from Definition of Terms section. | |||
o More editorial changes. | o More editorial changes. | |||
o Removed 4342 from IANA section and move to RFC6833 IANA section. | o Removed 4342 from IANA section and move to RFC6833 IANA section. | |||
B.19. Changes to draft-ietf-lisp-rfc6830bis-08 | B.20. Changes to draft-ietf-lisp-rfc6830bis-08 | |||
o Posted January 2018. | o Posted January 2018. | |||
o Remove references to research work for any protocol mechanisms. | o Remove references to research work for any protocol mechanisms. | |||
o Document scanned to make sure it is RFC 2119 compliant. | o Document scanned to make sure it is RFC 2119 compliant. | |||
o Made changes to reflect comments from document WG shepherd Luigi | o Made changes to reflect comments from document WG shepherd Luigi | |||
Iannone. | Iannone. | |||
o Ran IDNITs on the document. | o Ran IDNITs on the document. | |||
B.20. Changes to draft-ietf-lisp-rfc6830bis-07 | B.21. Changes to draft-ietf-lisp-rfc6830bis-07 | |||
o Posted November 2017. | o Posted November 2017. | |||
o Rephrase how Instance-IDs are used and don't refer to [RFC1918] | o Rephrase how Instance-IDs are used and don't refer to [RFC1918] | |||
addresses. | addresses. | |||
B.21. Changes to draft-ietf-lisp-rfc6830bis-06 | B.22. Changes to draft-ietf-lisp-rfc6830bis-06 | |||
o Posted October 2017. | o Posted October 2017. | |||
o Put RTR definition before it is used. | o Put RTR definition before it is used. | |||
o Rename references that are now working group drafts. | o Rename references that are now working group drafts. | |||
o Remove "EIDs MUST NOT be used as used by a host to refer to other | o Remove "EIDs MUST NOT be used as used by a host to refer to other | |||
hosts. Note that EID blocks MAY LISP RLOCs". | hosts. Note that EID blocks MAY LISP RLOCs". | |||
skipping to change at page 44, line 15 ¶ | skipping to change at page 44, line 15 ¶ | |||
o ETRs may, rather than will, be the ones to send Map-Replies. | o ETRs may, rather than will, be the ones to send Map-Replies. | |||
o Recommend, rather than mandate, max encapsulation headers to 2. | o Recommend, rather than mandate, max encapsulation headers to 2. | |||
o Reference VPN draft when introducing Instance-ID. | o Reference VPN draft when introducing Instance-ID. | |||
o Indicate that SMRs can be sent when ITR/ETR are in the same node. | o Indicate that SMRs can be sent when ITR/ETR are in the same node. | |||
o Clarify when private addresses can be used. | o Clarify when private addresses can be used. | |||
B.22. Changes to draft-ietf-lisp-rfc6830bis-05 | B.23. Changes to draft-ietf-lisp-rfc6830bis-05 | |||
o Posted August 2017. | o Posted August 2017. | |||
o Make it clear that a Re-encapsulating Tunnel Router is an RTR. | o Make it clear that a Re-encapsulating Tunnel Router is an RTR. | |||
B.23. Changes to draft-ietf-lisp-rfc6830bis-04 | B.24. Changes to draft-ietf-lisp-rfc6830bis-04 | |||
o Posted July 2017. | o Posted July 2017. | |||
o Changed reference of IPv6 RFC2460 to RFC8200. | o Changed reference of IPv6 RFC2460 to RFC8200. | |||
o Indicate that the applicability statement for UDP zero checksums | o Indicate that the applicability statement for UDP zero checksums | |||
over IPv6 adheres to RFC6936. | over IPv6 adheres to RFC6936. | |||
B.24. Changes to draft-ietf-lisp-rfc6830bis-03 | B.25. Changes to draft-ietf-lisp-rfc6830bis-03 | |||
o Posted May 2017. | o Posted May 2017. | |||
o Move the control-plane related codepoints in the IANA | o Move the control-plane related codepoints in the IANA | |||
Considerations section to RFC6833bis. | Considerations section to RFC6833bis. | |||
B.25. Changes to draft-ietf-lisp-rfc6830bis-02 | B.26. Changes to draft-ietf-lisp-rfc6830bis-02 | |||
o Posted April 2017. | o Posted April 2017. | |||
o Reflect some editorial comments from Damien Sausez. | o Reflect some editorial comments from Damien Sausez. | |||
B.26. Changes to draft-ietf-lisp-rfc6830bis-01 | B.27. Changes to draft-ietf-lisp-rfc6830bis-01 | |||
o Posted March 2017. | o Posted March 2017. | |||
o Include references to new RFCs published. | o Include references to new RFCs published. | |||
o Change references from RFC6833 to RFC6833bis. | o Change references from RFC6833 to RFC6833bis. | |||
o Clarified LCAF text in the IANA section. | o Clarified LCAF text in the IANA section. | |||
o Remove references to "experimental". | o Remove references to "experimental". | |||
B.27. Changes to draft-ietf-lisp-rfc6830bis-00 | B.28. Changes to draft-ietf-lisp-rfc6830bis-00 | |||
o Posted December 2016. | o Posted December 2016. | |||
o Created working group document from draft-farinacci-lisp | o Created working group document from draft-farinacci-lisp | |||
-rfc6830-00 individual submission. No other changes made. | -rfc6830-00 individual submission. No other changes made. | |||
Authors' Addresses | Authors' Addresses | |||
Dino Farinacci | Dino Farinacci | |||
Cisco Systems | Cisco Systems | |||
End of changes. 44 change blocks. | ||||
74 lines changed or deleted | 87 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/ |