--- 1/draft-ietf-lisp-gpe-07.txt 2019-10-24 16:13:08.659525761 -0700 +++ 2/draft-ietf-lisp-gpe-08.txt 2019-10-24 16:13:08.699526779 -0700 @@ -1,24 +1,24 @@ Internet Engineering Task Force F. Maino, Ed. Internet-Draft Cisco Intended status: Standards Track J. Lemon -Expires: April 20, 2020 Broadcom +Expires: April 26, 2020 Broadcom P. Agarwal Innovium D. Lewis M. Smith Cisco - October 18, 2019 + October 24, 2019 LISP Generic Protocol Extension - draft-ietf-lisp-gpe-07 + draft-ietf-lisp-gpe-08 Abstract This document describes extentions to the Locator/ID Separation Protocol (LISP) Data-Plane, via changes to the LISP header, to support multi-protocol encapsulation. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -27,21 +27,21 @@ 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 April 20, 2020. + This Internet-Draft will expire on April 26, 2020. Copyright Notice Copyright (c) 2019 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 @@ -59,25 +59,25 @@ 2. LISP Header Without Protocol Extensions . . . . . . . . . . . 3 3. Generic Protocol Extension for LISP (LISP-GPE) . . . . . . . 4 4. Implementation and Deployment Considerations . . . . . . . . 7 4.1. Applicability Statement . . . . . . . . . . . . . . . . . 7 4.2. Congestion Control Functionality . . . . . . . . . . . . 7 4.3. UDP Checksum . . . . . . . . . . . . . . . . . . . . . . 8 4.3.1. UDP Zero Checksum Handling with IPv6 . . . . . . . . 8 4.4. Ethernet Encapsulated Payloads . . . . . . . . . . . . . 10 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10 5.1. Use of "Multiple Data-Planes" LCAF to Determine ETR - Capabilities . . . . . . . . . . . . . . . . . . . . . . 11 + Capabilities . . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6.1. LISP-GPE Next Protocol Registry . . . . . . . . . . . . . 11 - 6.2. Multiple Data-Planes Encapsulation Bitmap Registry . . . 12 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 6.2. Multiple Data-Planes Encapsulation Bitmap Registry . . . 11 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements and Contributors . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction The LISP Data-Plane is defined in [I-D.ietf-lisp-rfc6830bis]. It specifies an encapsulation format that carries IPv4 or IPv6 packets @@ -164,21 +164,23 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: LISP-GPE Header P-Bit: Flag bit 5 is defined as the Next Protocol bit. If the P-bit is clear (0) the LISP header is bit-by-bit equivalent to the definition in [I-D.ietf-lisp-rfc6830bis]. The P-bit is set to 1 to indicate the presence of the 8 bit Next - Protocol field. + Protocol field. The combinations of bits that are allowed when + the P-bit is set are the same allowed by + [I-D.ietf-lisp-rfc6830bis]. Nonce/Map-Version: In [I-D.ietf-lisp-6834bis], LISP uses the lower 24 bits of the first word for a nonce, an echo-nonce, or to support map- versioning. These are all optional capabilities that are indicated in the LISP header by setting the N, E, and V bits respectively. When the P-bit and the N-bit are set to 1, the Nonce field is the middle 16 bits (i.e., encoded in 16 bits, not 24 bits). Note that the E-bit only has meaning when the N-bit is set. @@ -193,28 +195,32 @@ The encoding of the Nonce field in LISP-GPE, compared with the one used in [I-D.ietf-lisp-rfc6830bis] for the LISP data plane encapsulation, reduces the length of the nonce from 24 to 16 bits. As per [I-D.ietf-lisp-rfc6830bis], Ingress Tunnel Routers (ITRs) are required to generate different nonces when sending to different Routing Locators (RLOCs), but the same nonce can be used for a period of time when encapsulating to the same Egress Tunnel Router (ETR). The use of 16 bits nonces still allows an ITR to determine to and from reachability for up to 64k RLOCs at the same - time. + time, but reduces the overall robustness of the nonce mechanism to + off-path attackers. Please refer to Section Section 7 for + security considerations that apply to the use of the Nonce field. Similarly, the encoding of the Source and Dest Map-Version fields, compared with [I-D.ietf-lisp-rfc6830bis], is reduced from 12 to 8 - bits. This still allows to associate 256 different versions to + bits. This allows to associate only 256 different versions to each Endpoint Identifier to Routing Locator (EID-to-RLOC) mapping to inform commmunicating ITRs and ETRs about modifications of the - mapping. + mapping, reducing the Map-versioning wrap-around time. Please + refer to Section Section 7 for security considerations that apply + to the use of the Map-Versioning field. Next Protocol: The lower 8 bits of the first 32-bit word are used to carry a Next Protocol. This Next Protocol field contains the protocol of the encapsulated payload packet. This document defines the following Next Protocol values: 0x01 : IPv4 0x02 : IPv6 @@ -444,23 +450,20 @@ (xTR) configuration, but are out of the scope of this document. When encapsulating IP packets to a non LISP-GPE capable router the P-bit MUST be set to 0. That is, the encapsulation format defined in this document MUST NOT be sent to a router that has not indicated that it supports this specification because such a router would ignore the P-bit (as described in [I-D.ietf-lisp-rfc6830bis]) and so would misinterpret the other LISP header fields possibly causing significant errors. - A LISP-GPE router MUST NOT encapsulate non-IP packets (that have the - P-bit set to 1) to a non-LISP-GPE capable router. - 5.1. Use of "Multiple Data-Planes" LCAF to Determine ETR Capabilities LISP Canonical Address Format (LCAF) [RFC8060] defines the "Multiple Data-Planes" LCAF type, that can be included by an ETR in a Map-Reply to encode the encapsulation formats supported by a given RLOC. In this way an ITR can be made aware of the capability to support LISP- GPE, as well as other encapsulations, on a given RLOC of that ETR. The 3rd 32-bit word of the "Multiple Data-Planes" LCAF type, as defined in [RFC8060], is a bitmap whose bits are set to one (1) to @@ -488,38 +491,35 @@ +---------------+-------------+---------------+ | Next Protocol | Description | Reference | +---------------+-------------+---------------+ | 0x00 | Reserved | This Document | | 0x01 | IPv4 | This Document | | 0x02 | IPv6 | This Document | | 0x03 | Ethernet | This Document | | 0x04 | NSH | This Document | | 0x05..0x7F | Unassigned | | - | 0x80 | GBP | This Document | - | 0x81 | iOAM | This Document | | 0x82..0xFF | Unassigned | | +---------------+-------------+---------------+ 6.2. Multiple Data-Planes Encapsulation Bitmap Registry IANA is requested to set up a registry of "Multiple Data-Planes Encapsulation Bitmap" to identify the encapsulations supported by an ETR in the Multiple Data-Planes LCAF Type defined in [RFC8060]. The bitmap is the 3rd 32-bit word of the Multiple Data-Planes LCAF type. Each bit of the bitmap represents a Data-Plane Encapsulation. New values are assigned under the Specification Required policy [RFC8126]. Bits 0-23 are unassigned. This document assigns bits 24-31. Bit 24 - (bit 'g') is assigned to LISP-GPE, bits 25-31 assignment is - conformant with [RFC8060]. + (bit 'g') is assigned to LISP-GPE. +----------+-------+------------------------------------+-----------+ | Bit | Bit | Assigned to | Reference | | Position | Name | | | +----------+-------+------------------------------------+-----------+ | 0-23 | | Unassigned | | | 24 | g | LISP Generic Protocol Extension | This | | | | (LISP-GPE) | Document | | 25 | U | Generic UDP Encapsulation (GUE) | This | | | | | Document | @@ -536,40 +536,43 @@ | 31 | L | Locator/ID Separation Protocol | This | | | | (LISP) | Document | +----------+-------+------------------------------------+-----------+ Editorial Note (The following paragraph to be removed by the RFC Editor before publication) The "Multiple Data-Planes Encapsulation Bitmap" was "hardcoded" in RFC8060, assigning values to bits 25-31. This draft allocates the "Multiple Data-Planes Encapsulation Bitmap" registry assigning a - value to bit 24 for the LISP-GPE encapsualtion, assigning bits 25-31 + value to bit 24 for the LISP-GPE encapsulation, assigning bits 25-31 values that are conformant with RFC8060. This will allow future allocation of values 0-23. 7. Security Considerations LISP-GPE security considerations are similar to the LISP security considerations and mitigation techniques documented in [RFC7835]. The Echo Nonce Algorithm described in [I-D.ietf-lisp-rfc6830bis] relies on the nonce to detect reachability from ITR to ETR. In LISP- GPE the use of a 16-bit nonce, compared with the 24-bit nonce used in LISP, increases the probability of an off-path attacker to correctly guess the nonce and force the ITR to believe that a non-reachable RLOC is reachable. However, the use of common anti-spoofing - mechanisms such as uRPF prevents this form of attack. + mechanisms such as uRPF mitigates this form of attack. - The considerations made in [I-D.ietf-lisp-rfc6830bis] about use of - Echo Nonce, Map-Versioning, and Locator-Status-Bits apply to LISP-GPE - as well. + The considerations made in [I-D.ietf-lisp-rfc6830bis] that Echo + Nonce, Map-Versioning, and Locator-Status-Bits SHOULD NOT be used + over the public Internet and SHOULD only be used in trusted and + closed deployments apply to LISP-GPE as well. These considerations + are even more important for LISP-GPE, considering the reduced size of + the Nonce/Map-versioning field. LISP-GPE, as many encapsulations that use optional extensions, is subject to on-path adversaries that by manipulating the g-Bit and the packet itself can remove part of the payload. Typical integrity protection mechanisms (such as IPsec) SHOULD be used in combination with LISP-GPE by those protocol extensions that want to protect from on-path attackers. With LISP-GPE, issues such as data-plane spoofing, flooding, and traffic redirection may depend on the particular protocol payload @@ -623,20 +626,28 @@ networks--Bridges and Bridged Networks", IEEE 802.1Q-2014, DOI 10.1109/ieeestd.2014.6991462, December 2014, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . + [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion + Notification", RFC 6040, DOI 10.17487/RFC6040, November + 2010, . + + [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical + Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, + February 2017, . + 9.2. Informative References [I-D.brockners-ippm-ioam-vxlan-gpe] Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., Lapukhov, P., and M. Spiegel, "VXLAN-GPE Encapsulation for In-situ OAM Data", draft-brockners-ippm- ioam-vxlan-gpe-02 (work in progress), July 2019. [I-D.ietf-tsvwg-ecn-encap-guidelines] @@ -647,24 +658,20 @@ [I-D.lemon-vxlan-lisp-gpe-gbp] Lemon, J., Maino, F., Smith, M., and A. Isaac, "Group Policy Encoding with VXLAN-GPE and LISP-GPE", draft-lemon- vxlan-lisp-gpe-gbp-02 (work in progress), April 2019. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . - [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion - Notification", RFC 6040, DOI 10.17487/RFC6040, November - 2010, . - [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, DOI 10.17487/RFC6935, April 2013, . [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, . @@ -673,24 +680,20 @@ eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, . [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Threat Analysis", RFC 7835, DOI 10.17487/RFC7835, April 2016, . - [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical - Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, - February 2017, . - [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, . [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, March 2017, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26,