--- 1/draft-ietf-lisp-gpe-18.txt 2020-07-26 22:13:09.887677295 -0700 +++ 2/draft-ietf-lisp-gpe-19.txt 2020-07-26 22:13:09.923678215 -0700 @@ -1,24 +1,24 @@ Internet Engineering Task Force F. Maino, Ed. Internet-Draft Cisco Intended status: Standards Track J. Lemon -Expires: January 14, 2021 Broadcom +Expires: January 27, 2021 Broadcom P. Agarwal Innovium D. Lewis M. Smith Cisco - July 13, 2020 + July 26, 2020 LISP Generic Protocol Extension - draft-ietf-lisp-gpe-18 + draft-ietf-lisp-gpe-19 Abstract This document describes extensions to the Locator/ID Separation Protocol (LISP) Data-Plane, via changes to the LISP header, to support multi-protocol encapsulation and allow to introduce new protocol capabilities. Status of This Memo @@ -28,21 +28,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 https://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 January 14, 2021. + This Internet-Draft will expire on January 27, 2021. Copyright Notice Copyright (c) 2020 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -58,30 +58,30 @@ 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 3 2. LISP Header Without Protocol Extensions . . . . . . . . . . . 3 3. Generic Protocol Extension for LISP (LISP-GPE) . . . . . . . 4 4. Implementation and Deployment Considerations . . . . . . . . 6 4.1. Applicability Statement . . . . . . . . . . . . . . . . . 6 4.2. Congestion Control Functionality . . . . . . . . . . . . 7 4.3. UDP Checksum . . . . . . . . . . . . . . . . . . . . . . 8 4.3.1. UDP Zero Checksum Handling with IPv6 . . . . . . . . 8 4.4. DSCP, ECN, TTL, and 802.1Q . . . . . . . . . . . . . . . 10 - 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10 + 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 11 5.1. Detection of ETR Capabilities . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6.1. LISP-GPE Next Protocol Registry . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements and Contributors . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 - 9.2. Informative References . . . . . . . . . . . . . . . . . 13 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 + 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 (henceforth jointly referred to as IP) in a LISP header and outer UDP/IP transport. The LISP Data-Plane header does not specify the protocol being encapsulated and therefore is currently limited to encapsulating only @@ -312,29 +312,31 @@ LISP-GPE does not natively provide congestion control functionality and relies on the payload protocol traffic for congestion control. As such LISP-GPE MUST be used with congestion controlled traffic or within a network that is traffic managed to avoid congestion (TMCE). An operator of a traffic managed network (TMCE) may avoid congestion by careful provisioning of their networks, rate-limiting of user data traffic and traffic engineering according to path capacity. Keeping in mind the reccomendation above, new encapsulated payloads, - when registered with LISP-GPE, should be designed for explicit - congestion signals to propagate consistently from lower layer - protocols into IP. Then the IP internetwork layer can act as a - portability layer to carry congestion notification from non-IP-aware - congested nodes up to the transport layer (L4). Such new - encapsulated payloads, when registered with LISP-GPE, MUST be - accompanied by a set of guidelines derived from [RFC6040] and SHOULD - follow the guidelines defined in - [I-D.ietf-tsvwg-ecn-encap-guidelines]. + when registered with LISP-GPE, MUST be accompained by a set of + guidelines derived from [I-D.ietf-lisp-rfc6830bis]. Such new + protocols should be designed for explicit congestion signals to + propagate consistently from lower layer protocols into IP. Then the + IP internetwork layer can act as a portability layer to carry + congestion notification from non-IP-aware congested nodes up to the + transport layer (L4). By following the guidelines in + [I-D.ietf-tsvwg-ecn-encap-guidelines], subnetwork designers can + enable a layer-2 protocol to participate in congestion control + without dropping packets via propagation of explicit congestion + notification (ECN [RFC3168] ) to receivers. 4.3. UDP Checksum For IP payloads, section 5.3 of [I-D.ietf-lisp-rfc6830bis] specifies how to handle UDP Checksums encouraging implementors to consider UDP checksum usage guidelines in section 3.4 of [RFC8085] when it is desirable to protect UDP and LISP headers against corruption. In order to provide integrity of LISP-GPE headers, options and payload, for example to avoid mis-delivery of payload to different @@ -455,20 +457,24 @@ When a LISP-GPE router performs Ethernet encapsulation, the inner 802.1Q [IEEE.802.1Q_2014] 3-bit priority code point (PCP) field MAY be mapped from the encapsulated frame to the DSCP codepoint of the DS field defined in [RFC2474]. When a LISP-GPE router performs Ethernet encapsulation, the inner header 802.1Q [IEEE.802.1Q_2014] VLAN Identifier (VID) MAY be mapped to, or used to determine the LISP Instance IDentifier (IID) field. + Refer to Section 7 for consideration about the use of integrity + protection for deployments, such as the public Internet, concerned + with on-path attackers. + 5. Backward Compatibility LISP-GPE uses the same UDP destination port (4341) allocated to LISP. 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 @@ -513,25 +519,26 @@ | 0x8E..0x8F | Experimentation and testing (shim | This | | | headers) | Document | +--------------+-------------------------------------+--------------+ 7. Security Considerations LISP-GPE security considerations are similar to the LISP security considerations and mitigation techniques documented in [RFC7835]. LISP-GPE, as many encapsulations that use optional extensions, is - subject to on-path adversaries that by manipulating the P-Bit and the - packet itself can remove part of the payload or claim to encapsulate - any protocol payload type. 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. + subject to on-path adversaries that can make arbitrary modifications + to the packet (including the P-Bit) to change or remove any part of + the payload, or claim to encapsulate any protocol payload type. + 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 encapsulated. 8. Acknowledgements and Contributors A special thank you goes to Dino Farinacci for his guidance and detailed review. Thanks to Tom Herbert for the suggestion to assign codepoints for experimentations and testing. @@ -616,20 +623,25 @@ [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, DOI 10.17487/RFC2983, October 2000, . + [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition + of Explicit Congestion Notification (ECN) to IP", + RFC 3168, DOI 10.17487/RFC3168, September 2001, + . + [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, DOI 10.17487/RFC3692, January 2004, . [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, DOI 10.17487/RFC6935, April 2013, .