Re: [lisp] Benjamin Kaduk's Abstain on draft-ietf-lisp-gpe-09: (with COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Fri, 08 November 2019 06:09 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619801200E6; Thu, 7 Nov 2019 22:09:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3BsQ4_aU2U8; Thu, 7 Nov 2019 22:09:38 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D078E120041; Thu, 7 Nov 2019 22:09:37 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xA869SMW011960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 8 Nov 2019 01:09:31 -0500
Date: Thu, 07 Nov 2019 22:09:27 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Fabio Maino (fmaino)" <fmaino@cisco.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-lisp-gpe@ietf.org" <draft-ietf-lisp-gpe@ietf.org>, Luigi Iannone <ggx@gigix.net>, "lisp-chairs@ietf.org" <lisp-chairs@ietf.org>, "lisp@ietf.org" <lisp@ietf.org>
Message-ID: <20191108060927.GF47216@kduck.mit.edu>
References: <157204919563.2852.6106492473556191612.idtracker@ietfa.amsl.com> <03D311AF-6BF8-47AF-9620-859535BCD1D0@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <03D311AF-6BF8-47AF-9620-859535BCD1D0@cisco.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/wAqLD5oL9URaO3JWMlQjmjsigJ4>
Subject: Re: [lisp] Benjamin Kaduk's Abstain on draft-ietf-lisp-gpe-09: (with COMMENT)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Nov 2019 06:09:42 -0000
Hi Fabio, That seems like a reasonable approach -- thanks for taking my comments into consideration! -Ben On Mon, Nov 04, 2019 at 07:53:41PM +0000, Fabio Maino (fmaino) wrote: > Hi Ben, > Here is how we propose to move forward. > > Given that with LISP-GPE we have the opportunity to add additional protocol features defining new shim headers, we have removed the Nonce, Map-Versioning, and LSBs fields from the main LISP-GPE header. > > It will then be possible to define a LISP-GPE shim header that includes a 64-bit (or even 128-bit) Nonce, as well as a proper Map-versioning and LSBs fields. That could be done with an appropriate separate draft, that hopefully will address the concerns about those 3 features that have been expressed in the review of 6830bis. > > I have attached rev -11 of the draft and a diff file that reflects the approach above. > > It'd be great to hear your thoughts. > > We will discuss this approach with the WG in Singapore, and if there's support, we could go to LC right after the meeting. > > Thanks, > Fabio > > > > > > > > On 10/25/19, 5:20 PM, "Benjamin Kaduk via Datatracker" <noreply@ietf.org> wrote: > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-lisp-gpe-09: Abstain > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for addressing my Discuss-level points (I can accept that for the -09 > that RFC 8060 need not be a normative reference). I am balloting Abstain because > I am uncomfortable with only 16 bits of nonce, but I recognize that there is a need > for this sort of encapsulation and it must fit within the constraints of the core protocol. > Though, given Alissa's Discuss, it is technically still possible for the core protocol to > grow a larger nonce that would alleviate my concerns. But, since the issue stems from > a different document (and because I did not raise the issue earlier), it is not appropriate > for me to ballot Discuss on this document for that point. > > [original COMMENT section unchanged; contents presumably stale] > > Section 1 > > LISP-GPE MAY also be used to extend the LISP Data-Plane header, that > has allocated all by defining a Next Protocol "shim" header that > > nit: allocated all of what? > > Section 3 > > This is not exactly the responsibility of LISP-GPE merely because it > allocates the last bit in this bitmap, but it seems like it would be quite > useful to have a table of which combinations of values are valid vs. > nonsensical, given the somewhat complicated interaction between some of > these flag bits. > > 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 > each Endpoint Identifier to Routing Locator (EID-to-RLOC) mapping > to inform commmunicating ITRs and ETRs about modifications of the > mapping. > > Are we limited to 256 versions total, or is there some sort of larger > version space that we truncate to send (a la a wraparound process)? > I understand that map-versioning is primarily in a separate document but it > seems important for this document to describe to what extent it is limiting > functionality. > > Section 3.1 > > To ensure that protocols that are encapsulated in LISP-GPE will work > well from a transport interaction perspective, the specification of a > new encapsulated payload MUST contain an analysis of how LISP-GPE > SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit > Congestion Notification (ECN) bits whenever they apply to the new > encapsulated payload. > > This MUST is duplicated in the next three paragraphs; I would suggest > leaving this introduction as non-normative, with something like "needs to > contain an analysis of how LISP-GPE will deal with [...]" > Also, nit: "the outer UDP Checksum" > > Section 4 > > When encapsulating IP packets to a non LISP-GPE capable router the > P-bit MUST be set to 0. [...] > > 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. > > I'm failing to see how these two sentences are not redundant. > > Section 5.1 > > Just to be clear, the intent is that if there is some non-IETF protocol > that we want to encapsulate, we write a two-page Standards-Track RFC that > says "this GPE codepoint means to do what this non-IETF document says"? > > Section 6 > > However, the use of common anti-spoofing > mechanisms such as uRPF prevents this form of attack. > > I think "mitigates" is probably better than "prevents" in this case. > > 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. > > The g-Bit is present in the Map-Reply message, which can in the general > case be sent via triangle-routing, in which case the establishment and > selection of IPsec security associations is somewhat nontrivial and > probably does not quality as "typical", based on my limited experience. > I think a more general scheme for providing integrity protection for > mapping messages is needed as a mandatory mechanism, but that's a topic for > the control-plane document so I will not belabor it here. > > > > > > > > > Internet Engineering Task Force F. Maino, Ed. > Internet-Draft Cisco > Intended status: Standards Track J. Lemon > Expires: May 7, 2020 Broadcom > P. Agarwal > Innovium > D. Lewis > M. Smith > Cisco > November 4, 2019 > > > LISP Generic Protocol Extension > draft-ietf-lisp-gpe-11 > > 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 > 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 May 7, 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 > carefully, as they describe your rights and restrictions with respect > > > > Maino, et al. Expires May 7, 2020 [Page 1] > > Internet-Draft LISP Generic Protocol Extension November 2019 > > > 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 > described in the Simplified BSD License. > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 > 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 . . . . . . . . . . . . . . . . . . . . . . 7 > 4.3.1. UDP Zero Checksum Handling with IPv6 . . . . . . . . 8 > 4.4. Ethernet Encapsulated Payloads . . . . . . . . . . . . . 9 > 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10 > 5.1. Use of "Multiple Data-Planes" LCAF to Determine ETR > Capabilities . . . . . . . . . . . . . . . . . . . . . . 10 > 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 > 6.1. LISP-GPE Next Protocol Registry . . . . . . . . . . . . . 10 > 6.2. Multiple Data-Planes Encapsulation Bitmap Registry . . . 11 > 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 > 8. Acknowledgements and Contributors . . . . . . . . . . . . . . 13 > 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 > 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 > 9.2. Informative References . . . . . . . . . . . . . . . . . 14 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 > > 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 > IP packet payloads. Other protocols, most notably Virtual eXtensible > Local Area Network (VXLAN) [RFC7348] (which defines a similar header > format to LISP), are used to encapsulate Layer-2 (L2) protocols such > as Ethernet. > > This document defines an extension for the LISP header, as defined in > [I-D.ietf-lisp-rfc6830bis], to indicate the inner protocol, enabling > > > > > Maino, et al. Expires May 7, 2020 [Page 2] > > Internet-Draft LISP Generic Protocol Extension November 2019 > > > the encapsulation of Ethernet, IP or any other desired protocol all > the while ensuring compatibility with existing LISP deployments. > > A flag in the LISP header, called the P-bit, is used to signal the > presence of the 8-bit Next Protocol field. The Next Protocol field, > when present, uses 8 bits of the field that was allocated to the > echo-noncing and map-versioning features in > [I-D.ietf-lisp-rfc6830bis]. > > Since all of the reserved bits of the LISP Data-Plane header have > been allocated, LISP-GPE can also be used to extend the LISP Data- > Plane header by defining Next Protocol "shim" headers that implements > new data plane functions not supported in the LISP header. For > example, the use of the Group-Based Policy (GBP) header > [I-D.lemon-vxlan-lisp-gpe-gbp] or of the In-situ Operations, > Administration, and Maintenance (IOAM) header > [I-D.brockners-ippm-ioam-vxlan-gpe] with LISP-GPE, can be considered > an extension to add support in the Data-Plane for Group-Based Policy > functionalities or IOAM metadata. > > Nonce, Map-Versioning and Locator Status Bit fields are not part of > the LISP-GPE header. Shim headers can be used to specify features > such as echo-noncing, map-versioning or reachability by defining > fields of the same size, or larger, of those specified in > [I-D.ietf-lisp-rfc6830bis]. > > 1.1. Conventions > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in BCP > 14 [RFC2119] [RFC8174] when, and only when, they appear in all > capitals, as shown here. > > 1.2. Definition of Terms > > This document uses terms already defined in > [I-D.ietf-lisp-rfc6830bis]. > > 2. LISP Header Without Protocol Extensions > > As described in Section 1, the LISP header has no protocol identifier > that indicates the type of payload being carried. Because of this, > LISP is limited to carrying IP payloads. > > The LISP header [I-D.ietf-lisp-rfc6830bis] contains a series of flags > (some defined, some reserved), a Nonce/Map-version field and an > instance ID/Locator-status-bit field. The flags provide flexibility > > > > Maino, et al. Expires May 7, 2020 [Page 3] > > Internet-Draft LISP Generic Protocol Extension November 2019 > > > to define how the various fields are encoded. Notably, Flag bit 5 is > the last reserved bit in the LISP header. > > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |N|L|E|V|I|R|K|K| Nonce/Map-Version | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Instance ID/Locator-Status-Bits | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 1: LISP Header > > 3. Generic Protocol Extension for LISP (LISP-GPE) > > This document defines two changes to the LISP header in order to > support multi-protocol encapsulation: the introduction of the P-bit > and the definition of a Next Protocol field. This is shown in > Figure 2 and described below. > > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Res. |I|P|K|K| Reserved | Next Protocol | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Instance ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 2: LISP-GPE Header > > Bits 0-3 and 8-23: Bits 0-3 and 8-23 of the LISP-GPE header are > Reserved. They MUST be set to zero on transmission and ignored on > receipt. > > Features that were implemented with bits 0-3 in > [I-D.ietf-lisp-rfc6830bis], such as echo-noncing, map-versioning > and reachability, can be implemented by defining the appropriate > shim headers. > > Instance ID When the I-Bit is set to 1 the high-order 24 bits of the > Instance ID field are used as an Instance ID, as specified in > [I-D.ietf-lisp-rfc6830bis]. The low-order 8 bits are set to zero, > as the Locator-Status-Bits feature is not supported in LISP-GPE. > > > > > Maino, et al. Expires May 7, 2020 [Page 4] > > Internet-Draft LISP Generic Protocol Extension November 2019 > > > 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] with bits N, L, E > and V set to 0. > > The P-bit is set to 1 to indicate the presence of the 8 bit Next > 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] when bits N, L, E and V are set to 0. > > 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 > > 0x03 : Ethernet > > 0x04 : Network Service Header (NSH) [RFC8300] > > 0x05 to 0x7F: Unassigned > > 0x80 to 0xFF: Unassigned (shim headers) > > The values are tracked in an IANA registry as described in > Section 6.1. > > Next protocol values from Ox80 to 0xFF are assigned to protocols > encoded as generic "shim" headers. Shim protocols all use a common > header structure, which includes a next header field using the same > values as described above. When a shim header protocol is used with > other data described by protocols identified by next protocol values > from 0x0 to 0x7F, the shim header MUST come before the further > protocol, and the next header of the shim will indicate what follows > the shim protocol. > > Implementations that are not aware of a given shim header MUST ignore > the header and proceed to parse the next protocol. Shim protocols > MUST have the first 32 bits defined as: > > > > > > Maino, et al. Expires May 7, 2020 [Page 5] > > Internet-Draft LISP Generic Protocol Extension November 2019 > > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Reserved | Next Protocol | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Protocol Specific Fields ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 3: Shim Header > > Where: > > Type: This field identifies the different messages of this protocol. > > Length: The length, in 4-octect units, of this protocol message not > including the first 4 octects. > > Reserved: The use of this field is reserved to the protocol defined > in this message. > > Next Protocol Field: This next protocol field contains the protocol > of the encapsulated payload. The protocol registry will be > requested from IANA as per section 10.2. > > 4. Implementation and Deployment Considerations > > 4.1. Applicability Statement > > LISP-GPE conforms, as an UDP-based encapsulation protocol, to the UDP > usage guidelines as specified in [RFC8085]. The applicability of > these guidelines are dependent on the underlay IP network and the > nature of the encapsulated payload. > > [RFC8085] outlines two applicability scenarios for UDP applications, > 1) general Internet and 2) controlled environment. The controlled > environment means a single administrative domain or adjacent set of > cooperating domains. A network in a controlled environment can be > managed to operate under certain conditions whereas in general > Internet this cannot be done. Hence requirements for a tunnel > protocol operating under a controlled environment can be less > restrictive than the requirements of general internet. > > LISP-GPE scope of applicability is the same set of use cases covered > by[I-D.ietf-lisp-rfc6830bis] for the LISP dataplane protocol. The > common property of these use cases is a large set of cooperating > entities seeking to communicate over the public Internet or other > > > > Maino, et al. Expires May 7, 2020 [Page 6] > > Internet-Draft LISP Generic Protocol Extension November 2019 > > > large underlay IP infrastructures, while keeping the addressing and > topology of the cooperating entities separate from the underlay and > Internet topology, routing, and addressing. > > LISP-GPE is meant to be deployed in network environments operated by > a single operator or adjacent set of cooperating network operators > that fits with the definition of controlled environments in > [RFC8085]. > > For the purpose of this document, a traffic-managed controlled > environment (TMCE), outlined in [RFC8086], is defined as an IP > network that is traffic-engineered and/or otherwise managed (e.g., > via use of traffic rate limiters) to avoid congestion. Significant > portions of text in this Section are based on [RFC8086]. > > It is the responsibility of the network operators to ensure that the > guidelines/requirements in this section are followed as applicable to > their LISP-GPE deployments > > 4.2. Congestion Control Functionality > > 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. > > Encapsulated payloads may have Explicit Congestion Notification > mechanisms that may or may not be mapped to the outer IP header ECN > field. Such new encapsulated payolads, when registered with LISP- > GPE, MUST be accompanied by a set of guidelines derived from > [I-D.ietf-tsvwg-ecn-encap-guidelines] and [RFC6040]. > > 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 > tenant systems in case of data corruption, outer UDP checksum SHOULD > be used with LISP-GPE when transported over IPv4. The UDP checksum > provides a statistical guarantee that a payload was not corrupted in > transit. These integrity checks are not strong from a coding or > > > > Maino, et al. Expires May 7, 2020 [Page 7] > > Internet-Draft LISP Generic Protocol Extension November 2019 > > > cryptographic perspective and are not designed to detect physical- > layer errors or malicious modification of the datagram (see > Section 3.4 of [RFC8085]). In deployments where such a risk exists, > an operator SHOULD use additional data integrity mechanisms such as > offered by IPSec. > > An operator MAY choose to disable UDP checksum and use zero checksum > if LISP-GPE packet integrity is provided by other data integrity > mechanisms such as IPsec or additional checksums or if one of the > conditions in Section 4.3.1 a, b, c are met. > > By default, UDP checksum MUST be used when LISP-GPE is transported > over IPv6. A tunnel endpoint MAY be configured for use with zero UDP > checksum if additional requirements in Section 4.3.1 are met. > > 4.3.1. UDP Zero Checksum Handling with IPv6 > > When LISP-GPE is used over IPv6, UDP checksum is used to protect IPv6 > headers, UDP headers and LISP-GPE headers and payload from potential > data corruption. As such by default LISP-GPE MUST use UDP checksum > when transported over IPv6. An operator MAY choose to configure to > operate with zero UDP checksum if operating in a traffic managed > controlled environment as stated in Section 4.1 if one of the > following conditions are met: > > a. It is known that the packet corruption is exceptionally unlikely > (perhaps based on knowledge of equipment types in their underlay > network) and the operator is willing to take a risk of undetected > packet corruption > > b. It is judged through observational measurements (perhaps through > historic or current traffic flows that use non zero checksum) > that the level of packet corruption is tolerably low and where > the operator is willing to take the risk of undetected corruption > > c. LISP-GPE payload is carrying applications that are tolerant of > misdelivered or corrupted packets (perhaps through higher layer > checksum validation and/or reliability through retransmission) > > In addition LISP-GPE tunnel implementations using Zero UDP checksum > MUST meet the following requirements: > > 1. Use of UDP checksum over IPv6 MUST be the default configuration > for all LISP-GPE tunnels > > 2. If LISP-GPE is used with zero UDP checksum over IPv6 then such > xTR implementation MUST meet all the requirements specified in > > > > > Maino, et al. Expires May 7, 2020 [Page 8] > > Internet-Draft LISP Generic Protocol Extension November 2019 > > > section 4 of [RFC6936] and requirements 1 as specified in section > 5 of [RFC6936] > > 3. The ETR that decapsulates the packet SHOULD check the source and > destination IPv6 addresses are valid for the LISP-GPE tunnel that > is configured to receive Zero UDP checksum and discard other > packets for which such check fails > > 4. The ITR that encapsulates the packet MAY use different IPv6 > source addresses for each LISP-GPE tunnel that uses Zero UDP > checksum mode in order to strengthen the decapsulator's check of > the IPv6 source address (i.e the same IPv6 source address is not > to be used with more than one IPv6 destination address, > irrespective of whether that destination address is a unicast or > multicast address). When this is not possible, it is RECOMMENDED > to use each source address for as few LISP-GPE tunnels that use > zero UDP checksum as is feasible > > 5. Measures SHOULD be taken to prevent LISP-GPE traffic over IPv6 > with zero UDP checksum from escaping into the general Internet. > Examples of such measures include employing packet filters at the > PETR and/or keeping logical or physical separation of LISP > network from networks carrying General Internet > > The above requirements do not change either the requirements > specified in [RFC2460] as modified by [RFC6935] or the requirements > specified in [RFC6936]. > > The requirement to check the source IPv6 address in addition to the > destination IPv6 address, plus the recommendation against reuse of > source IPv6 addresses among LISP-GPE tunnels collectively provide > some mitigation for the absence of UDP checksum coverage of the IPv6 > header. A traffic-managed controlled environment that satisfies at > least one of three conditions listed at the beginning of this section > provides additional assurance. > > 4.4. Ethernet Encapsulated Payloads > > 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 3-bit Type of Service > field in the outer IPv4 header, or in the case of IPv6 the 'Traffic > Class' field. > > 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. > > > > > Maino, et al. Expires May 7, 2020 [Page 9] > > Internet-Draft LISP Generic Protocol Extension November 2019 > > > 5. Backward Compatibility > > LISP-GPE uses the same UDP destination port (4341) allocated to LISP. > > The next Section describes a method to determine the Data-Plane > capabilities of a LISP ETR, based on the use of the "Multiple Data- > Planes" LISP Canonical Address Format (LCAF) type defined in > [RFC8060]. Other mechanisms can be used, including static ETR/ITR > (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. > > 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 > represent support for each Data-Plane encapsulation. The values are > tracked in an IANA registry as described in Section 6.2. > > This document defines bit 24 in the third 32-bit word of the > "Multiple Data-Planes" LCAF as: > > g-Bit: The RLOCs listed in the Address Family Identifier (AFI) > encoded addresses in the next longword can accept LISP-GPE > (Generic Protocol Extension) encapsulation using destination UDP > port 4341 > > 6. IANA Considerations > > 6.1. LISP-GPE Next Protocol Registry > > IANA is requested to set up a registry of LISP-GPE "Next Protocol". > These are 8-bit values. Next Protocol values in the table below are > defined in this document. New values are assigned under the > Specification Required policy [RFC8126]. The protocols that are > > > > > Maino, et al. Expires May 7, 2020 [Page 10] > > Internet-Draft LISP Generic Protocol Extension November 2019 > > > being assigned values do not themselves need to be IETF standards > track protocols. > > +---------------+-------------+---------------+ > | 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 | | > | 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. > > > > > > > > > > > > > > > > > > > > > > > > > Maino, et al. Expires May 7, 2020 [Page 11] > > Internet-Draft LISP Generic Protocol Extension November 2019 > > > +----------+-------+------------------------------------+-----------+ > | 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 | > | 26 | G | Generic Network Virtualization | This | > | | | Encapsulation (GENEVE) | Document | > | 27 | N | Network Virtualization - Generic | This | > | | | Routing Encapsulation (NV-GRE) | Document | > | 28 | v | VXLAN Generic Protocol Extension | This | > | | | (VXLAN-GPE) | Document | > | 29 | V | Virtual eXtensible Local Area | This | > | | | Network (VXLAN) | Document | > | 30 | l | Layer 2 LISP (LISP-L2) | This | > | | | | Document | > | 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 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]. > > 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 > encapsulated. > > > > Maino, et al. Expires May 7, 2020 [Page 12] > > Internet-Draft LISP Generic Protocol Extension November 2019 > > > 8. Acknowledgements and Contributors > > A special thank you goes to Dino Farinacci for his guidance and > detailed review. > > This Working Group (WG) document originated as draft-lewis-lisp-gpe; > the following are its coauthors and contributors along with their > respective affiliations at the time of WG adoption. The editor of > this document would like to thank and recognize them and their > contributions. These coauthors and contributors provided invaluable > concepts and content for this document's creation. > > o Darrel Lewis, Cisco Systems, Inc. > > o Fabio Maino, Cisco Systems, Inc. > > o Paul Quinn, Cisco Systems, Inc. > > o Michael Smith, Cisco Systems, Inc. > > o Navindra Yadav, Cisco Systems, Inc. > > o Larry Kreeger > > o John Lemon, Broadcom > > o Puneet Agarwal, Innovium > > 9. References > > 9.1. Normative References > > [I-D.ietf-lisp-rfc6830bis] > Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. > Cabellos-Aparicio, "The Locator/ID Separation Protocol > (LISP)", draft-ietf-lisp-rfc6830bis-27 (work in progress), > June 2019. > > [IEEE.802.1Q_2014] > IEEE, "IEEE Standard for Local and metropolitan area > networks--Bridges and Bridged Networks", IEEE 802.1Q-2014, > DOI 10.1109/ieeestd.2014.6991462, December 2014, > <http://ieeexplore.ieee.org/servlet/ > opac?punumber=6991460>. > > > > > > > > Maino, et al. Expires May 7, 2020 [Page 13] > > Internet-Draft LISP Generic Protocol Extension November 2019 > > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, > DOI 10.17487/RFC2119, March 1997, <https://www.rfc- > editor.org/info/rfc2119>. > > [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion > Notification", RFC 6040, DOI 10.17487/RFC6040, November > 2010, <https://www.rfc-editor.org/info/rfc6040>. > > 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] > Briscoe, B., Kaippallimalil, J., and P. Thaler, > "Guidelines for Adding Congestion Notification to > Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn- > encap-guidelines-13 (work in progress), May 2019. > > [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, <https://www.rfc-editor.org/info/rfc2460>. > > [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and > UDP Checksums for Tunneled Packets", RFC 6935, > DOI 10.17487/RFC6935, April 2013, <https://www.rfc- > editor.org/info/rfc6935>. > > [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, > <https://www.rfc-editor.org/info/rfc6936>. > > > > > > > > > > Maino, et al. Expires May 7, 2020 [Page 14] > > Internet-Draft LISP Generic Protocol Extension November 2019 > > > [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, > L., Sridhar, T., Bursell, M., and C. Wright, "Virtual > 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, > <https://www.rfc-editor.org/info/rfc7348>. > > [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID > Separation Protocol (LISP) Threat Analysis", RFC 7835, > DOI 10.17487/RFC7835, April 2016, <https://www.rfc- > editor.org/info/rfc7835>. > > [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical > Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, > February 2017, <https://www.rfc-editor.org/info/rfc8060>. > > [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage > Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, > March 2017, <https://www.rfc-editor.org/info/rfc8085>. > > [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- > in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, > March 2017, <https://www.rfc-editor.org/info/rfc8086>. > > [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for > Writing an IANA Considerations Section in RFCs", BCP 26, > RFC 8126, DOI 10.17487/RFC8126, June 2017, > <https://www.rfc-editor.org/info/rfc8126>. > > [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC > 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, > May 2017, <https://www.rfc-editor.org/info/rfc8174>. > > [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., > "Network Service Header (NSH)", RFC 8300, > DOI 10.17487/RFC8300, January 2018, <https://www.rfc- > editor.org/info/rfc8300>. > > Authors' Addresses > > Fabio Maino (editor) > Cisco Systems > San Jose, CA 95134 > USA > > Email: fmaino@cisco.com > > > > > > Maino, et al. Expires May 7, 2020 [Page 15] > > Internet-Draft LISP Generic Protocol Extension November 2019 > > > Jennifer Lemon > Broadcom > 270 Innovation Drive > San Jose, CA 95134 > USA > > Email: jennifer.lemon@broadcom.com > > > Puneet Agarwal > Innovium > USA > > Email: puneet@acm.org > > > Darrel Lewis > Cisco Systems > > Email: darlewis@cisco.com > > > Michael Smith > Cisco Systems > > Email: michsmit@cisco.com > > > > > > > > > > > > > > > > > > > > > > > > > > Maino, et al. Expires May 7, 2020 [Page 16]
- [lisp] Benjamin Kaduk's Abstain on draft-ietf-lis… Benjamin Kaduk via Datatracker
- Re: [lisp] Benjamin Kaduk's Abstain on draft-ietf… Fabio Maino (fmaino)
- Re: [lisp] Benjamin Kaduk's Abstain on draft-ietf… Benjamin Kaduk
- Re: [lisp] Benjamin Kaduk's Abstain on draft-ietf… Fabio Maino (fmaino)
- Re: [lisp] Benjamin Kaduk's Abstain on draft-ietf… Fabio Maino (fmaino)