--- 1/draft-ietf-lisp-rfc6830bis-00.txt 2017-03-28 16:13:53.147330924 -0700 +++ 2/draft-ietf-lisp-rfc6830bis-01.txt 2017-03-28 16:13:53.259333598 -0700 @@ -1,59 +1,59 @@ Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Standards Track D. Meyer -Expires: June 9, 2017 D. Lewis +Expires: September 27, 2017 D. Lewis Cisco Systems A. Cabellos (Ed.) UPC/BarcelonaTech - December 6, 2016 + March 26, 2017 The Locator/ID Separation Protocol (LISP) - draft-ietf-lisp-rfc6830bis-00 + draft-ietf-lisp-rfc6830bis-01 Abstract This document describes the Locator/ID Separation Protocol (LISP) data-plane encapsulation protocol. LISP defines two namespaces, End- point Identifiers (EIDs) that identify end-hosts and Routing Locators (RLOCs) that identify network attachment points. With this, LISP effectively separates control from data, and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local map-cache. The map-cache is populated by the LISP Control-Plane protocol - [REF_TO_RFC6833bis]. + [I-D.ietf-lisp-rfc6833bis]. LISP requires no change to either host protocol stacks or to underlay routers and offers Traffic Engineering, multihoming and mobility, among other features. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on June 9, 2017. + This Internet-Draft will expire on September 27, 2017. Copyright Notice - Copyright (c) 2016 IETF Trust and the persons identified as the + Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -85,79 +85,82 @@ 13.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 31 13.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . 32 13.3. Database Map-Versioning . . . . . . . . . . . . . . . . 33 14. Multicast Considerations . . . . . . . . . . . . . . . . . . 34 15. Router Performance Considerations . . . . . . . . . . . . . . 35 16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 36 16.1. Slow Mobility . . . . . . . . . . . . . . . . . . . . . 36 16.2. Fast Mobility . . . . . . . . . . . . . . . . . . . . . 36 16.3. LISP Mobile Node Mobility . . . . . . . . . . . . . . . 37 17. LISP xTR Placement and Encapsulation Methods . . . . . . . . 37 - 17.1. First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 39 + 17.1. First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 38 17.2. Border/Edge xTRs . . . . . . . . . . . . . . . . . . . . 39 - 17.3. ISP Provider Edge (PE) xTRs . . . . . . . . . . . . . . 40 + 17.3. ISP Provider Edge (PE) xTRs . . . . . . . . . . . . . . 39 17.4. LISP Functionality with Conventional NATs . . . . . . . 40 17.5. Packets Egressing a LISP Site . . . . . . . . . . . . . 40 18. Traceroute Considerations . . . . . . . . . . . . . . . . . . 41 18.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . 42 18.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . 42 - 18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . 43 + 18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . 42 19. Security Considerations . . . . . . . . . . . . . . . . . . . 43 - 20. Network Management Considerations . . . . . . . . . . . . . . 43 - 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 + 20. Network Management Considerations . . . . . . . . . . . . . . 44 + 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 21.1. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 44 21.2. LISP Address Type Codes . . . . . . . . . . . . . . . . 44 - 21.3. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 44 - 21.4. LISP Key ID Numbers . . . . . . . . . . . . . . . . . . 44 + 21.3. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 45 + 21.4. LISP Key ID Numbers . . . . . . . . . . . . . . . . . . 45 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 22.1. Normative References . . . . . . . . . . . . . . . . . . 45 - 22.2. Informative References . . . . . . . . . . . . . . . . . 47 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 51 - Appendix B. Document Change Log . . . . . . . . . . . . . . . . 51 - B.1. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 52 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 + 22.2. Informative References . . . . . . . . . . . . . . . . . 48 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 52 + Appendix B. Document Change Log . . . . . . . . . . . . . . . . 52 + B.1. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 53 + B.2. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 53 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 1. Introduction This document describes the Locator/Identifier Separation Protocol (LISP). LISP is an encapsulation protocol built around the fundamental idea of separating the topological location of a network attachment point from the node's identity [CHIAPPA]. As a result LISP creates two namespaces: Endpoint Identifiers (EIDs), that are used to identify end-hosts (e.g., nodes or Virtual Machines) and routable Routing Locators (RLOCs), used to identify network attachment points. LISP then defines functions for mapping between the two numbering spaces and for encapsulating traffic originated by devices using non-routable EIDs for transport across a network infrastructure that routes and forwards using RLOCs. LISP is an overlay protocol that separates control from data-plane, this document specifies the data-plane, how LISP-capable routers (Tunnel Routers) exchange packets by encapsulating them to the appropriate location. Tunnel routers are equipped with a cache, called map-cache, that contains EID-to-RLOC mappings. The map-cache - is populated using the LISP Control-Plane protocol [REF_to_6833bis]. + is populated using the LISP Control-Plane protocol + [I-D.ietf-lisp-rfc6833bis]. LISP does not require changes to either host protocol stack or to underlay routers. By separating the EID from the RLOC space, LISP offers native Traffic Engineering, multihoming and mobility, among other features. Creation of LISP was initially motivated by discussions during the IAB-sponsored Routing and Addressing Workshop held in Amsterdam in October 2006 (see [RFC4984]) This document specifies the LISP data-plane encapsulation and other - xTR functionality while [REF_to_6833bis] specifies the LISP control - plane. LISP deployment guidelines can be found in [RFC7215] and - [RFC6835] describes considerations for network operational - management. Finally, [LISP-INTRO] describes the LISP architecture. + xTR functionality while [I-D.ietf-lisp-rfc6833bis] specifies the LISP + control plane. LISP deployment guidelines can be found in [RFC7215] + and [RFC6835] describes considerations for network operational + management. Finally, [I-D.ietf-lisp-introduction] describes the LISP + architecture. 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Definition of Terms Provider-Independent (PI) Addresses: PI addresses are an address @@ -330,21 +333,21 @@ must be taken to not create re-encapsulation loops through misconfiguration. LISP Header: LISP header is a term used in this document to refer to the outer IPv4 or IPv6 header, a UDP header, and a LISP- specific 8-octet header that follow the UDP header and that an ITR prepends or an ETR strips. Address Family Identifier (AFI): AFI is a term used to describe an address encoding in a packet. An address family currently - pertains to an IPv4 or IPv6 address. See [AFI] and [RFC3232] for + pertains to an IPv4 or IPv6 address. See [AFN] and [RFC3232] for details. An AFI value of 0 used in this specification indicates an unspecified encoded address where the length of the address is 0 octets following the 16-bit AFI value of 0. Negative Mapping Entry: A negative mapping entry, also known as a negative cache entry, is an EID-to-RLOC entry where an EID-Prefix is advertised or stored with no RLOCs. That is, the Locator-Set for the EID-to-RLOC entry is empty or has an encoded Locator count of 0. This type of entry could be used to describe a prefix from a non-LISP site, which is explicitly not in the mapping database. @@ -443,22 +447,22 @@ o End-systems only send to addresses that are EIDs. They don't know that addresses are EIDs versus RLOCs but assume that packets get to their intended destinations. In a system where LISP is deployed, LISP routers intercept EID-addressed packets and assist in delivering them across the network core where EIDs cannot be routed. The procedure a host uses to send IP packets does not change. o EIDs are typically IP addresses assigned to hosts. - o Other types of EID are supported by LISP, see [LCAF] for further - information. + o Other types of EID are supported by LISP, see [RFC8060] for + further information. o LISP routers mostly deal with Routing Locator addresses. See details in Section 4.1 to clarify what is meant by "mostly". o RLOCs are always IP addresses assigned to routers, preferably topologically oriented addresses from provider CIDR (Classless Inter-Domain Routing) blocks. o When a router originates packets, it may use as a source address either an EID or RLOC. When acting as a host (e.g., when @@ -511,62 +515,62 @@ connected to the destination host. Another example, perhaps for a VPN service outsourced to an ISP by a site, the ITR could be the site's border router at the service provider attachment point. Mixing and matching of site-operated, ISP-operated, and other Tunnel Routers is allowed for maximum flexibility. 4.1. Packet Flow Sequence This section provides an example of the unicast packet flow, including also control-plane information as specified in - [REF_TO_RFC6833bis]. The example also assumes the following + [I-D.ietf-lisp-rfc6833bis]. The example also assumes the following conditions: o Source host "host1.abc.example.com" is sending a packet to "host2.xyz.example.com", exactly what host1 would do if the site was not using LISP. o Each site is multihomed, so each Tunnel Router has an address (RLOC) assigned from the service provider address block for each provider to which that particular Tunnel Router is attached. o The ITR(s) and ETR(s) are directly connected to the source and destination, respectively, but the source and destination can be located anywhere in the LISP site. o Map-Requests are sent to the mapping database system by using the - LISP control-plane protocol documented in [REF_to_RFC6833bis]. A - Map-Request is sent for an external destination when the - destination is not found in the forwarding table or matches a - default route. + LISP control-plane protocol documented in + [I-D.ietf-lisp-rfc6833bis]. A Map-Request is sent for an external + destination when the destination is not found in the forwarding + table or matches a default route. o Map-Replies are sent on the underlying routing system topology - using the [REF_TO_RFC6833bis] control-plane protocol. + using the [I-D.ietf-lisp-rfc6833bis] control-plane protocol. Client host1.abc.example.com wants to communicate with server host2.xyz.example.com: 1. host1.abc.example.com wants to open a TCP connection to host2.xyz.example.com. It does a DNS lookup on host2.xyz.example.com. An A/AAAA record is returned. This address is the destination EID. The locally assigned address of host1.abc.example.com is used as the source EID. An IPv4 or IPv6 packet is built and forwarded through the LISP site as a normal IP packet until it reaches a LISP ITR. 2. The LISP ITR must be able to map the destination EID to an RLOC of one of the ETRs at the destination site. The specific method used to do this is not described in this example. See - [REF_to_RFC6833bis] for further information. + [I-D.ietf-lisp-rfc6833bis] for further information. 3. The ITR sends a LISP Map-Request as specified in - [REF_TO_RFC6833bis]. Map-Requests SHOULD be rate-limited. + [I-D.ietf-lisp-rfc6833bis]. Map-Requests SHOULD be rate-limited. 4. The mapping system helps forwarding the Map-Request to the corresponding ETR. When the Map-Request arrives at one of the ETRs at the destination site, it will process the packet as a control message. 5. The ETR looks at the destination EID of the Map-Request and matches it against the prefixes in the ETR's configured EID-to- RLOC mapping database. This is the list of EID-Prefixes the ETR is supporting for the site it resides in. If there is no match, @@ -616,21 +620,21 @@ existing schemes are detailed in Section 7. Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the LISP architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner header is in IPv4 packet format and the outer header is in IPv6 packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header is in IPv6 packet format and the outer header is in IPv4 packet format). The next sub-sections illustrate packet formats for the homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but all 4 combinations MUST be supported. Additional types of EIDs are defined - in [LCAF]. + in [RFC8060]. 5.1. LISP IPv4-in-IPv4 Header Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| IHL |Type of Service| Total Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identification |Flags| Fragment Offset | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -730,22 +734,22 @@ 7.2. UDP Header: The UDP header contains an ITR selected source port when encapsulating a packet. See Section 12 for details on the hash algorithm used to select a source port based on the 5-tuple of the inner header. The destination port MUST be set to the well-known IANA-assigned port value 4341. UDP Checksum: The 'UDP Checksum' field SHOULD be transmitted as zero by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation - [UDP-TUNNELS] [UDP-ZERO]. When a packet with a zero UDP checksum - is received by an ETR, the ETR MUST accept the packet for + [RFC6935] [RFC6936]. When a packet with a zero UDP checksum is + received by an ETR, the ETR MUST accept the packet for decapsulation. When an ITR transmits a non-zero value for the UDP checksum, it MUST send a correctly computed value in this field. When an ETR receives a packet with a non-zero UDP checksum, it MAY choose to verify the checksum value. If it chooses to perform such verification, and the verification fails, the packet MUST be silently dropped. If the ETR chooses not to perform the verification, or performs the verification successfully, the packet MUST be accepted for decapsulation. The handling of UDP checksums for all tunneling protocols, including LISP, is under active discussion within the IETF. When that discussion @@ -808,21 +812,21 @@ |N|L|E|V|I|R|K|K| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID | LSBs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R: The R-bit is a Reserved bit for future use. It MUST be set to 0 on transmit and MUST be ignored on receipt. KK: The KK-bits are a 2-bit field used when encapsualted packets are encrypted. The field is set to 00 when the packet is not - encrypted. See [I.D-ietf-lisp-crypto] for further information. + encrypted. See [RFC8061] for further information. LISP Nonce: The LISP 'Nonce' field is a 24-bit value that is randomly generated by an ITR when the N-bit is set to 1. Nonce generation algorithms are an implementation matter but are required to generate different nonces when sending to different destinations. However, the same nonce can be used for a period of time to the same destination. The nonce is also used when the E-bit is set to request the nonce value to be echoed by the other side when packets are returned. When the E-bit is clear but the N-bit is set, a remote ITR is either echoing a previously @@ -909,23 +913,23 @@ the corresponding RLOC network attachment point. When an ITR/PITR receives a packet from inside of the LISP site to destinations outside of the site a longest-prefix match lookup of the EID is done to the map-cache. When the lookup succeeds, the locator-set retrieved from the map- cache is used to send the packet to the EID's topological location. If the lookup fails, the ITR/PITR needs to retrieve the mapping using - the LISP control-plane protocol [REF_TO_RFC6833bis]. The mapping is - then stored in the local map-cache to forward subsequent packets - addressed to the same EID-prefix. + the LISP control-plane protocol [I-D.ietf-lisp-rfc6833bis]. The + mapping is then stored in the local map-cache to forward subsequent + packets addressed to the same EID-prefix. The map-cache is a local cache of mappings, entries are expired based on the associated Time to live. In addition, entries can be updated with more current information, see Section 13 for further information on this. Finally, the map-cache also contains reachability information about EIDs and RLOCs, and uses LISP reachability information mechanisms to determine the reachability of RLOCs, see Section 10 for the specific mechanisms. 7. Dealing with Large Encapsulated Packets @@ -1015,43 +1019,46 @@ back to the source. The packet size advertised by the ITR in the ICMP Too Big message is the effective MTU minus the LISP encapsulation length. Even though this mechanism is stateful, it has advantages over the stateless IP fragmentation mechanism, by not involving the destination host with reassembly of ITR fragmented packets. 8. Using Virtualization and Segmentation with LISP - FIXME: Indicate how the instance-ID is 32 bits in control-plane and - 24-bits in the data-plane. - When multiple organizations inside of a LISP site are using private addresses [RFC1918] as EID-Prefixes, their address spaces MUST remain segregated due to possible address duplication. An Instance ID in the address encoding can aid in making the entire AFI-based address unique. See IANA Considerations (Section 21.2) for details on possible address encodings. An Instance ID can be carried in a LISP-encapsulated packet. An ITR that prepends a LISP header will copy a 24-bit value used by the LISP router to uniquely identify the address space. The value is copied to the 'Instance ID' field of the LISP header, and the I-bit is set to 1. When an ETR decapsulates a packet, the Instance ID from the LISP header is used as a table identifier to locate the forwarding table to use for the inner destination EID lookup. For example, an 802.1Q VLAN tag or VPN identifier could be used as a 24-bit Instance ID. + The Instance ID that is stored in the mapping database when LISP-DDT + [I-D.ietf-lisp-ddt] is used is 32 bits in length. That means the + control-plane can store more instances than a given data-plane can + use. Multiple data-planes can use the same 32-bit space as long as + the low-order 24 bits don't overlap among xTRs. + 9. Routing Locator Selection Both the client-side and server-side may need control over the selection of RLOCs for conversations between them. This control is achieved by manipulating the 'Priority' and 'Weight' fields in EID- to-RLOC Map-Reply messages. Alternatively, RLOC information MAY be gleaned from received tunneled packets or EID-to-RLOC Map-Request messages. The following are different scenarios for choosing RLOCs and the @@ -1207,21 +1215,21 @@ Unreachable message, it MAY originate its own ICMP Destination Unreachable message destined for the host that originated the data packet the ITR encapsulated. Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a locator address from a Locator-Set in a mapping entry matches a prefix. If it does not find one and BGP is running in the Default- Free Zone (DFZ), it can decide to not use the Locator even though the Locator-Status-Bits indicate that the Locator is up. In this case, the path from the ITR to the ETR that is assigned the Locator is not - available. More details are in [LOC-ID-ARCH]. + available. More details are in [I-D.meyer-loc-id-implications]. Optionally, an ITR can send a Map-Request to a Locator, and if a Map- Reply is returned, reachability of the Locator has been determined. Obviously, sending such probes increases the number of control messages originated by Tunnel Routers for active flows, so Locators are assumed to be reachable when they are advertised. This assumption does create a dependency: Locator unreachability is detected by the receipt of ICMP Host Unreachable messages. When a Locator has been determined to be unreachable, it is not used for @@ -1314,23 +1322,23 @@ the mapping database system as one would when soliciting mapping data. The EID record encoded in the Map-Request is the EID-Prefix of the Map-Cache entry cached by the ITR or PITR. The ITR may include a mapping data record for its own database mapping information that contains the local EID-Prefixes and RLOCs for its site. RLOC-probes are sent periodically using a jittered timer interval. When an ETR receives a Map-Request message with the probe-bit set, it returns a Map-Reply with the probe-bit set. The source address of the Map-Reply is set according to the procedure described in - [REF_TO_RFC6833bis]. The Map-Reply SHOULD contain mapping data for - the EID-Prefix contained in the Map-Request. This provides the - opportunity for the ITR or PITR that sent the RLOC-probe to get + [I-D.ietf-lisp-rfc6833bis]. The Map-Reply SHOULD contain mapping + data for the EID-Prefix contained in the Map-Request. This provides + the opportunity for the ITR or PITR that sent the RLOC-probe to get mapping updates if there were changes to the ETR's database mapping entries. There are advantages and disadvantages of RLOC-Probing. The greatest benefit of RLOC-Probing is that it can handle many failure scenarios allowing the ITR to determine when the path to a specific Locator is reachable or has become unreachable, thus providing a robust mechanism for switching to using another Locator from the cached Locator. RLOC-Probing can also provide rough Round-Trip Time (RTT) estimates between a pair of Locators, which can be useful for network @@ -1533,23 +1541,20 @@ SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate- limited. This is important to avoid Map-Reply implosion. 5. The ETRs at the site with the changed mapping record the fact that the site that sent the Map-Request has received the new mapping data in the Map-Cache entry for the remote site so the Locator-Status-Bits are reflective of the new mapping for packets going to the remote site. The ETR then stops sending SMR messages. - Experimentation is in progress to determine the appropriate rate- - limit parameters. - For security reasons, an ITR MUST NOT process unsolicited Map- Replies. To avoid Map-Cache entry corruption by a third party, a sender of an SMR-based Map-Request MUST be verified. If an ITR receives an SMR-based Map-Request and the source is not in the Locator-Set for the stored Map-Cache entry, then the responding Map- Request MUST be sent with an EID destination to the mapping database system. Since the mapping database system is a more secure way to reach an authoritative ETR, it will deliver the Map-Request to the authoritative source of the mapping data. @@ -1621,21 +1626,21 @@ With respect to the source Routing Locator address, the ITR prepends its own IP address as the source address of the outer IP header. Just like it would if the destination EID was a unicast address. This source Routing Locator address, like any other Routing Locator address, MUST be globally routable. There are two approaches for LISP-Multicast, one that uses native multicast routing in the underlay with no support from the Mapping System and the other that uses only unicast routing in the underlay with support from the Mapping System. See [RFC6831] and - [I.D-ietf-lisp-signal-free-multicast], respectively, for details. + [I-D.ietf-lisp-signal-free-multicast], respectively, for details. Details for LISP-Multicast and interworking with non-LISP sites are described in [RFC6831] and [RFC6832]. 15. Router Performance Considerations LISP is designed to be very "hardware-based forwarding friendly". A few implementation techniques can be used to incrementally implement LISP: o When a tunnel-encapsulated packet is received by an ETR, the outer @@ -1719,42 +1724,40 @@ for any endpoint will return a binding for the entire mobile prefix. If mobile networks become a more common occurrence, it may be useful to revisit the design of the mapping service and allow for dynamic updates of the database. The issue of interactions between mobility and LISP needs to be explored further. Specific improvements to the entire system will depend on the details of mapping mechanisms. Mapping mechanisms should be evaluated on how well they support session continuity for - mobile nodes. See [REF_TO_I-D.farinacci-lisp-predictive-rlocs] for - more recent mechanisms which can provide near-zero packet loss during + mobile nodes. See [I-D.farinacci-lisp-predictive-rlocs] for more + recent mechanisms which can provide near-zero packet loss during handoffs. 16.3. LISP Mobile Node Mobility A mobile device can use the LISP infrastructure to achieve mobility by implementing the LISP encapsulation and decapsulation functions and acting as a simple ITR/ETR. By doing this, such a "LISP mobile node" can use topologically independent EID IP addresses that are not advertised into and do not impose a cost on the global routing system. These EIDs are maintained at the edges of the mapping system - (in LISP Map-Servers and Map-Resolvers) and are provided on demand to + in LISP Map-Servers and Map-Resolvers) and are provided on demand to only the correspondents of the LISP mobile node. - Refer to [LISP-MN] for more details for when the EID and RLOC are co- - located in the roaming node. + Refer to [I-D.meyer-lisp-mn] for more details for when the EID and + RLOC are co-located in the roaming node. 17. LISP xTR Placement and Encapsulation Methods - [FIXME: The Authors/Ed. agree on adding further scenarios.] - This section will explore how and where ITRs and ETRs can be placed in the networkand will discuss the pros and cons of each scenario. For a more detailed networkd design deployment recommendation, refer to [RFC7215]. There are two basic deployment tradeoffs to consider: centralized versus distributed caches; and flat, Recursive, or Re-encapsulating Tunneling. When deciding on centralized versus distributed caching, the following issues should be considered: @@ -1894,22 +1897,20 @@ 17.5. Packets Egressing a LISP Site When a LISP site is using two ITRs for redundancy, the failure of one ITR will likely shift outbound traffic to the second. This second ITR's cache may not be populated with the same EID-to-RLOC mapping entries as the first. If this second ITR does not have these mappings, traffic will be dropped while the mappings are retrieved from the mapping system. The retrieval of these messages may increase the load of requests being sent into the mapping system. - Deployment and experimentation will determine whether this issue - requires more attention. 18. Traceroute Considerations When a source host in a LISP site initiates a traceroute to a destination host in another LISP site, it is highly desirable for it to see the entire path. Since packets are encapsulated from the ITR to the ETR, the hop across the tunnel could be viewed as a single hop. However, LISP traceroute will provide the entire path so the user can see 3 distinct segments of the path from a source LISP host to a destination LISP host: @@ -2004,73 +2005,104 @@ expecting addresses from intermediate hops in the same address format for the type of traceroute it originated. Therefore, in this case, segment 2 will make the tunnel look like one hop. All the ITR has to do to make this work is to not copy the inner TTL to the outer, encapsulating header's TTL when a traceroute packet is encapsulated using an RLOC from a different address family. This will cause no TTL decrement to 0 to occur in core routers between the ITR and ETR. 19. Security Considerations - FIXME: ToDo + Security considerations for LISP are discussed in [RFC7833], in + addition [I-D.ietf-lisp-sec] provides authentication and integrity to + LISP mappings. - Security considerations for LISP are discussed in [LISP-THREATS], in - addition [LISP-SEC] provides authentication and integrity to LISP - mappings. + A complete LISP threat analysis can be found in [RFC7835], in what + follows we provide a summary. + + The optional mechanisms of gleaning is offered to directly obtain a + mapping from the LISP encapsulated packets. Specifically, an xTR can + learn the EID-to-RLOC mapping by inspecting the source RLOC and + source EID of an encapsulated packet, and insert this new mapping + into its map-cache. An off-path attacker can spoof the source EID + address to divert the traffic sent to the victim's spoofed EID. If + the attacker spoofs the source RLOC, it can mount a DoS attack by + redirecting traffic to the spoofed victim;s RLOC, potentially + overloading it. + + The LISP Data-Plane defines several mechanisms to monitor RLOC data- + plane reachability, in this context Locator-Status Bits, Nonce- + Present and Echo-Nonce bits of the LISP encapsulation header can be + manipulated by an attacker to mount a DoS attack. An off-path + attacker able to spoof the RLOC of a victim's xTR can manipulate such + mechanisms to declare a set of RLOCs unreachable. This can be used + also, for instance, to declare only one RLOC reachable with the aim + of overload it. + + 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 + peering xTR uses LISP Control-Plane signaling message to retrieve a + fresh mapping. This can be used by an attacker to forge the map- + versioning field of a LISP encapsulated header and force an excessive + amount of signaling between xTRs that may overload them. + + Most of the attack vectors can be mitigated with careful deployment + and configuration, information learned opportunistically (such as LSB + or gleaning) should be verified with other reachability mechanisms. + + In addition, systematic rate-limitation and filtering is an effective + technique to mitigate attacks that aim to overload the control-plane. 20. Network Management Considerations Considerations for network management tools exist so the LISP protocol suite can be operationally managed. These mechanisms can be - found in [LISP-MIB] and [RFC6835]. + found in [RFC7052] and [RFC6835]. 21. IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the LISP specification, in accordance with BCP 26 [RFC5226]. There are four namespaces (listed in the sub-sections below) in LISP that have been registered. o LISP IANA registry allocations should not be made for purposes unrelated to LISP routing or transport protocols. o The following policies are used here with the meanings defined in BCP 26: "Specification Required", "IETF Review", "Experimental Use", and "First Come First Served". 21.1. LISP ACT and Flag Fields - New ACT values [REF_TO_RFC6833bis] can be allocated through IETF - review or IESG approval. Four values have already been allocated by - this specification ([REF_TO_RFC6833bis]. + New ACT values [I-D.ietf-lisp-rfc6833bis] can be allocated through + IETF review or IESG approval. Four values have already been + allocated by this specification [I-D.ietf-lisp-rfc6833bis]. In addition, LISP has a number of flag fields and reserved fields, such as the LISP header flags field (Section 5.3). New bits for flags in these fields can be implemented after IETF review or IESG approval, but these need not be managed by IANA. 21.2. LISP Address Type Codes - LISP Address [LCAF] type codes have a range from 0 to 255. New type - codes MUST be allocated consecutively, starting at 0. Type Codes - 0-127 are to be assigned by IETF review or IESG approval. - - Type Codes 128-255 are available according to the [RFC5226] First - Come First Served policy. + LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that + defines LISP-specific encodings for AFI value 16387. LCAF encodings + are used for specific use-cases where different address types for + EID-records and RLOC-records are required. - This registry, initially empty, is constructed for future use in - experimental work related to LISP Canonical Address Format (LCAF) - values. See [LCAF] for details of other possible unapproved address - encodings. The unapproved LCAF encodings are an area for further - study and experimentation. + The IANA registry "LISP Canonical Address Format (LCAF) Types" is + used for LCAF types, the registry for LCAF types use the + Specification Required policy [RFC5226]. Initial values for the + registry as well as further information can be found in [RFC8060]. 21.3. LISP UDP Port Numbers The IANA registry has allocated UDP port numbers 4341 and 4342 for lisp-data and lisp-control operation, respectively. IANA has updated the description for UDP ports 4341 and 4342 as follows: lisp-data 4341 udp LISP Data Packets lisp-control 4342 udp LISP Control Packets @@ -2085,23 +2117,41 @@ HMAC-SHA-1-96 1 [RFC2404] HMAC-SHA-256-128 2 [RFC4868] Number values are in the range of 0 to 65535. The allocation of values is on a first come first served basis. 22. References 22.1. Normative References - [I.D-ietf-lisp-crypto] - Farinacci, D. and B. Weiss, "LISP Data-Plane - Confidentiality", October 2016. + [I-D.ietf-lisp-ddt] + Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. + Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- + ddt-09 (work in progress), January 2017. + + [I-D.ietf-lisp-introduction] + Cabellos-Aparicio, A. and D. Saucez, "An Architectural + Introduction to the Locator/ID Separation Protocol + (LISP)", draft-ietf-lisp-introduction-13 (work in + progress), April 2015. + + [I-D.ietf-lisp-rfc6833bis] + Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, + "Locator/ID Separation Protocol (LISP) Control-Plane", + draft-ietf-lisp-rfc6833bis-00 (work in progress), December + 2016. + + [I-D.ietf-lisp-sec] + Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. + Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-12 + (work in progress), November 2016. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., @@ -2161,111 +2211,106 @@ . [RFC6115] Li, T., Ed., "Recommendation for a Routing Architecture", RFC 6115, DOI 10.17487/RFC6115, February 2011, . [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, . - [RFC6833] Farinacci, D. and V. Fuller, "Locator/ID Separation - Protocol (LISP) Map-Server Interface", RFC 6833, January - 2013. - [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 6834, - January 2013. + DOI 10.17487/RFC6834, January 2013, + . - [RFC6836] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, + [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical - Topology (LISP+ALT)", RFC 6836, January 2013. + Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, + January 2013, . - [RFC7215] Jakab, L., Cabellos, A., Coras, F., Domingo-Pascual, J., - and D. Lewis, "Locator/Identifier Separation Protocol - (LISP) Network Element Deployment Considerations", - RFC 6834, April 2014. + [RFC7052] Schudel, G., Jain, A., and V. Moreno, "Locator/ID + Separation Protocol (LISP) MIB", RFC 7052, + DOI 10.17487/RFC7052, October 2013, + . + + [RFC7214] Andersson, L. and C. Pignataro, "Moving Generic Associated + Channel (G-ACh) IANA Registries to a New Registry", + RFC 7214, DOI 10.17487/RFC7214, May 2014, + . + + [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- + Pascual, J., and D. Lewis, "Locator/Identifier Separation + Protocol (LISP) Network Element Deployment + Considerations", RFC 7215, DOI 10.17487/RFC7215, April + 2014, . + + [RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A + RADIUS Attribute, Binding, Profiles, Name Identifier + Format, and Confirmation Methods for the Security + Assertion Markup Language (SAML)", RFC 7833, + DOI 10.17487/RFC7833, May 2016, + . + + [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID + Separation Protocol (LISP) Threat Analysis", RFC 7835, + DOI 10.17487/RFC7835, April 2016, + . + + [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol + (LISP) Data-Plane Confidentiality", RFC 8061, + DOI 10.17487/RFC8061, February 2017, + . 22.2. Informative References - [AFI] IANA, "Address Family Numbers", November 2007, + [AFN] IANA, "Address Family Numbers", August 2016, . - [BGP-SEC] Lepinski, M. and S. Turner, "An Overview of BGPSEC", Work - in Progress, May 2012. - - [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed - Enhancement to the Internet Architecture", 1999, + [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed", + 1999, . - [CONS] Brim, S., Chiappa, N., Farinacci, D., Fuller, V., Lewis, - D., and D. Meyer, "LISP-CONS: A Content distribution - Overlay Network Service for LISP", Work in Progress, April - 2008. + [I-D.farinacci-lisp-predictive-rlocs] + Farinacci, D. and P. Pillay-Esnault, "LISP Predictive + RLOCs", draft-farinacci-lisp-predictive-rlocs-01 (work in + progress), November 2016. - [EMACS] Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID - Mappings Multicast Across Cooperating Systems for LISP", - Work in Progress, November 2007. + [I-D.ietf-lisp-signal-free-multicast] + Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", + draft-ietf-lisp-signal-free-multicast-02 (work in + progress), October 2016. - [I-D.portoles-lisp-eid-mobility] - Portoles, M., Ashtaputre, V., Moreno, V., Maino, F., and - D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified - Control Plane", Work in Progress, April 2016. + [I-D.meyer-lisp-mn] + Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP + Mobile Node", draft-meyer-lisp-mn-16 (work in progress), + December 2016. - [I.D-ietf-lisp-signal-free-multicast] - Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", - Work in Progress, October 2016. + [I-D.meyer-loc-id-implications] + Meyer, D. and D. Lewis, "Architectural Implications of + Locator/ID Separation", draft-meyer-loc-id-implications-01 + (work in progress), January 2009. - [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical - Address Format (LCAF)", Work in Progress, January 2013. + [I-D.portoles-lisp-eid-mobility] + Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, + F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a + Unified Control Plane", draft-portoles-lisp-eid- + mobility-01 (work in progress), October 2016. [LISA96] Lear, E., Tharp, D., Katinsky, J., and J. Coffin, "Renumbering: Threat or Menace?", Usenix Tenth System Administration Conference (LISA 96), October 1996. - [LISP-DDT] - Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. - Smirnov, "LISP Delegated Database Tree", Work in Progress, - April 2015. - - [LISP-INTRO] - Cabellos, A. and D. Saucez, "An Architectural Introduction - to the Locator/ID Separation Protocol (LISP)", Work - in Progress, April 2015. - - [LISP-MIB] - Schudel, G., Jain, A., and V. Moreno, "LISP MIB", Work - in Progress, January 2013. - - [LISP-MN] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP - Mobile Node", Work in Progress, October 2012. - - [LISP-SEC] - Maino, F., Ermagan, V., Cabellos, A., Saucez, D., and O. - Bonaventure, "LISP-Security (LISP-SEC)", Work in Progress, - October 2012. - - [LISP-THREATS] - Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats - Analysis", Work in Progress, January 2016. - - [LOC-ID-ARCH] - Meyer, D. and D. Lewis, "Architectural Implications of - Locator/ID Separation", Work in Progress, January 2009. - [OPENLISP] Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP Implementation Report", Work in Progress, July 2008. - [RADIR] Narten, T., "On the Scalability of Internet Routing", Work - in Progress, February 2010. - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, . [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains @@ -2301,41 +2346,52 @@ Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", RFC 6518, DOI 10.17487/RFC6518, February 2012, . [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The Locator/ID Separation Protocol (LISP) for Multicast - Environments", RFC 6831, January 2013. + Environments", RFC 6831, DOI 10.17487/RFC6831, January + 2013, . [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol - (LISP) and Non-LISP Sites", RFC 6832, January 2013. + (LISP) and Non-LISP Sites", RFC 6832, + DOI 10.17487/RFC6832, January 2013, + . [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation - Protocol Internet Groper (LIG)", RFC 6835, January 2013. + Protocol Internet Groper (LIG)", RFC 6835, + DOI 10.17487/RFC6835, January 2013, + . [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to - Routing Locator (RLOC) Database", RFC 6837, January 2013. + Routing Locator (RLOC) Database", RFC 6837, + DOI 10.17487/RFC6837, January 2013, + . - [UDP-TUNNELS] - Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and - UDP Checksums for Tunneled Packets", Work in Progress, - January 2013. + [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and + UDP Checksums for Tunneled Packets", RFC 6935, + DOI 10.17487/RFC6935, April 2013, + . - [UDP-ZERO] - Fairhurst, G. and M. Westerlund, "Applicability Statement - for the use of IPv6 UDP Datagrams with Zero Checksums", - Work in Progress, December 2012. + [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement + for the Use of IPv6 UDP Datagrams with Zero Checksums", + RFC 6936, DOI 10.17487/RFC6936, April 2013, + . + + [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical + Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, + February 2017, . Appendix A. Acknowledgments An initial thank you goes to Dave Oran for planting the seeds for the initial ideas for LISP. His consultation continues to provide value to the LISP authors. A special and appreciative thank you goes to Noel Chiappa for providing architectural impetus over the past decades on separation of location and identity, as well as detailed reviews of the LISP @@ -2362,27 +2418,39 @@ Alia Atlas, Florin Coras and Alberto Rodriguez. This work originated in the Routing Research Group (RRG) of the IRTF. An individual submission was converted into the IETF LISP working group document that became this RFC. The LISP working group would like to give a special thanks to Jari Arkko, the Internet Area AD at the time that the set of LISP documents were being prepared for IESG last call, and for his meticulous reviews and detailed commentaries on the 7 working group - last call documents progressing toward experimental RFCs. + last call documents progressing toward standards-track RFCs. Appendix B. Document Change Log [RFC Editor: Please delete this section on publication as RFC.] -B.1. Changes to draft-ietf-lisp-rfc6830bis-00 +B.1. Changes to draft-ietf-lisp-rfc6830bis-01 + + o Posted March 2017. + + o Include references to new RFCs published. + + o Change references from RFC6833 to RFC6833bis. + + o Clarified LCAF text in the IANA section. + + o Remove references to "experimental". + +B.2. Changes to draft-ietf-lisp-rfc6830bis-00 o Posted December 2016. o Created working group document from draft-farinacci-lisp -rfc6830-00 individual submission. No other changes made. Authors' Addresses Dino Farinacci Cisco Systems @@ -2391,34 +2459,34 @@ USA EMail: farinacci@gmail.com Vince Fuller Cisco Systems Tasman Drive San Jose, CA 95134 USA - EMail: vaf@vaf.net + EMail: vince.fuller@gmail.com Dave Meyer Cisco Systems 170 Tasman Drive San Jose, CA USA EMail: dmm@1-4-5.net - Darrel Lewis Cisco Systems 170 Tasman Drive San Jose, CA USA EMail: darlewis@cisco.com + Albert Cabellos UPC/BarcelonaTech Campus Nord, C. Jordi Girona 1-3 Barcelona, Catalunya Spain EMail: acabello@ac.upc.edu