| < 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 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 exmple 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. 43 change blocks. | ||||
| 74 lines changed or deleted | 83 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/ | ||||