Re: [lisp] Benjamin Kaduk's Abstain on draft-ietf-lisp-gpe-09: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

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" <[e-mail]> 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: [e-mail]
> 
> 
> 
> 
> 
> 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: [e-mail]
> 
> 
>    Puneet Agarwal
>    Innovium
>    USA
> 
>    Email: [e-mail]
> 
> 
>    Darrel Lewis
>    Cisco Systems
> 
>    Email: [e-mail]
> 
> 
>    Michael Smith
>    Cisco Systems
> 
>    Email: [e-mail]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Maino, et al.              Expires May 7, 2020                 [Page 16]