idnits 2.17.1 draft-ietf-lisp-gpe-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 7, 2020) is 1389 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-32 == Outdated reference: A later version (-05) exists of draft-brockners-ippm-ioam-vxlan-gpe-03 == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-ecn-encap-guidelines-13 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force F. Maino, Ed. 3 Internet-Draft Cisco 4 Intended status: Standards Track J. Lemon 5 Expires: January 8, 2021 Broadcom 6 P. Agarwal 7 Innovium 8 D. Lewis 9 M. Smith 10 Cisco 11 July 7, 2020 13 LISP Generic Protocol Extension 14 draft-ietf-lisp-gpe-17 16 Abstract 18 This document describes extensions to the Locator/ID Separation 19 Protocol (LISP) Data-Plane, via changes to the LISP header, to 20 support multi-protocol encapsulation. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 8, 2021. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 3 59 2. LISP Header Without Protocol Extensions . . . . . . . . . . . 3 60 3. Generic Protocol Extension for LISP (LISP-GPE) . . . . . . . 4 61 4. Implementation and Deployment Considerations . . . . . . . . 6 62 4.1. Applicability Statement . . . . . . . . . . . . . . . . . 6 63 4.2. Congestion Control Functionality . . . . . . . . . . . . 7 64 4.3. UDP Checksum . . . . . . . . . . . . . . . . . . . . . . 8 65 4.3.1. UDP Zero Checksum Handling with IPv6 . . . . . . . . 8 66 4.4. DSCP, ECN, TTL, and 802.1Q . . . . . . . . . . . . . . . 10 67 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10 68 5.1. Detection of ETR Capabilities . . . . . . . . . . . . . . 11 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 6.1. LISP-GPE Next Protocol Registry . . . . . . . . . . . . . 11 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 8. Acknowledgements and Contributors . . . . . . . . . . . . . . 12 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 75 9.2. Informative References . . . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 The LISP Data-Plane is defined in [I-D.ietf-lisp-rfc6830bis]. It 81 specifies an encapsulation format that carries IPv4 or IPv6 packets 82 (henceforth jointly referred to as IP) in a LISP header and outer 83 UDP/IP transport. 85 The LISP Data-Plane header does not specify the protocol being 86 encapsulated and therefore is currently limited to encapsulating only 87 IP packet payloads. Other protocols, most notably Virtual eXtensible 88 Local Area Network (VXLAN) [RFC7348] (which defines a similar header 89 format to LISP), are used to encapsulate Layer-2 (L2) protocols such 90 as Ethernet. 92 This document defines an extension for the LISP header, as defined in 93 [I-D.ietf-lisp-rfc6830bis], to indicate the inner protocol, enabling 94 the encapsulation of Ethernet, IP or any other desired protocol all 95 the while ensuring compatibility with existing LISP deployments. 97 A flag in the LISP header, called the P-bit, is used to signal the 98 presence of the 8-bit Next Protocol field. The Next Protocol field, 99 when present, uses 8 bits of the field that was allocated to the 100 echo-noncing and map-versioning features in 101 [I-D.ietf-lisp-rfc6830bis]. Those two features are no longer 102 available when the P-bit is used. However, appropriate LISP-GPE 103 (LISP Generic Protocol Extension) shim headers can be defined to 104 specify capabilities that are equivalent to echo-noncing and/or map- 105 versioning. 107 Since all of the reserved bits of the LISP Data-Plane header have 108 been allocated, LISP-GPE can also be used to extend the LISP Data- 109 Plane header by defining Next Protocol "shim" headers that implements 110 new data plane functions not supported in the LISP header. For 111 example, the use of the Group-Based Policy (GBP) header 112 [I-D.lemon-vxlan-lisp-gpe-gbp] or of the In-situ Operations, 113 Administration, and Maintenance (IOAM) header 114 [I-D.brockners-ippm-ioam-vxlan-gpe] with LISP-GPE, can be considered 115 an extension to add support in the Data-Plane for Group-Based Policy 116 functionalities or IOAM metadata. 118 1.1. Conventions 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in BCP 123 14 [RFC2119] [RFC8174] when, and only when, they appear in all 124 capitals, as shown here. 126 1.2. Definition of Terms 128 This document uses terms already defined in 129 [I-D.ietf-lisp-rfc6830bis]. 131 2. LISP Header Without Protocol Extensions 133 As described in Section 1, the LISP header has no protocol identifier 134 that indicates the type of payload being carried. Because of this, 135 LISP is limited to carrying IP payloads. 137 The LISP header [I-D.ietf-lisp-rfc6830bis] contains a series of flags 138 (some defined, some reserved), a Nonce/Map-version field and an 139 instance ID/Locator-status-bit field. The flags provide flexibility 140 to define how the various fields are encoded. Notably, Flag bit 5 is 141 the last reserved bit in the LISP header. 143 0 1 2 3 144 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 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 |N|L|E|V|I|R|K|K| Nonce/Map-Version | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Instance ID/Locator-Status-Bits | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 Figure 1: LISP Header 153 3. Generic Protocol Extension for LISP (LISP-GPE) 155 This document defines two changes to the LISP header in order to 156 support multi-protocol encapsulation: the introduction of the P-bit 157 and the definition of a Next Protocol field. This document specifies 158 the protocol behavior when the P-bit is set to 1, no changes are 159 introduced when the P-bit is set to 0. The LISP-GPE header is shown 160 in Figure 2 and described below. 162 0 1 2 3 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 |N|L|E|V|I|P|K|K| Nonce/Map-Version/Next Protocol | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Instance ID/Locator-Status-Bits | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 Figure 2: LISP-GPE Header 172 P-Bit: Flag bit 5 is defined as the Next Protocol bit. The P-bit is 173 set to 1 to indicate the presence of the 8 bit Next Protocol 174 field. 176 If the P-bit is clear (0) the LISP header is bit-by-bit equivalent 177 to the definition in [I-D.ietf-lisp-rfc6830bis]. 179 When the P-bit is set to 1, bits N, E, V, and bits 8-23 of the 180 'Nonce/Map-Version/Next Protocol' field MUST be set to zero on 181 transmission and MUST be ignored on receipt. Features equivalent 182 to those that were implemented with bits N,E and V in 183 [I-D.ietf-lisp-rfc6830bis], such as echo-noncing and map- 184 versioning, can be implemented by defining appropriate LISP-GPE 185 shim headers. 187 When the P-bit is set to 1, the LISP-GPE header is encoded as: 189 0 x 0 0 x 1 x x 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 |N|L|E|V|I|P|K|K| 0x0000 | Next Protocol | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Instance ID/Locator-Status-Bits | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Figure 3: LISP-GPE with P-bit set to 1 198 Next Protocol: When the P-bit is set to 1, the lower 8 bits of the 199 first 32-bit word are used to carry a Next Protocol. This Next 200 Protocol field contains the protocol of the encapsulated payload 201 packet. 203 This document defines the following Next Protocol values: 205 0x00 : Reserved 207 0x01 : IPv4 209 0x02 : IPv6 211 0x03 : Ethernet 213 0x04 : Network Service Header (NSH) [RFC8300] 215 0x05 to 0x7D: Unassigned 217 0x7E, 0x7F: Experimentation and testing 219 0x80 to 0xFD: Unassigned (shim headers) 221 0xFE, 0xFF: Experimentation and testing (shim headers) 223 The values are tracked in the IANA LISP-GPE Next Protocol Registry 224 as described in Section 6.1. 226 Next protocol values 0x7E, 0x7F and 0xFE, 0xFF are assigned for 227 experimentation and testing as per [RFC3692]. 229 Next protocol values from Ox80 to 0xFD are assigned to protocols 230 encoded as generic "shim" headers. All shim protocols MUST use the 231 header structure in Figure 4, which includes a Next Protocol field. 232 When shim headers are used with other protocols identified by next 233 protocol values from 0x00 to 0x7F, all the shim headers MUST come 234 first. 236 Shim headers can be used to incrementally deploy new GPE features, 237 keeping the processing of shim headers known to a given xTR 238 implementation in the 'fast' path (typically an ASIC), while punting 239 the processing of the remaining new GPE features to the 'slow' path. 241 Shim protocols MUST have the first 32 bits defined as: 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Type | Length | Reserved | Next Protocol | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | | 249 ~ Protocol Specific Fields ~ 250 | | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Figure 4: Shim Header 255 Where: 257 Type: This field identifies the different messages of this protocol. 259 Length: The length, in 4-octet units, of this protocol message not 260 including the first 4 octets. 262 Reserved: The use of this field is reserved to the protocol defined 263 in this message. 265 Next Protocol Field: The next protocol field contains the protocol 266 of the encapsulated payload. The values are tracked in the IANA 267 LISP-GPE Next Protocol Registry as described in Section 6.1. 269 4. Implementation and Deployment Considerations 271 4.1. Applicability Statement 273 LISP-GPE conforms, as an UDP-based encapsulation protocol, to the UDP 274 usage guidelines as specified in [RFC8085]. The applicability of 275 these guidelines are dependent on the underlay IP network and the 276 nature of the encapsulated payload. 278 [RFC8085] outlines two applicability scenarios for UDP applications, 279 1) general Internet and 2) controlled environment. The controlled 280 environment means a single administrative domain or adjacent set of 281 cooperating domains. A network in a controlled environment can be 282 managed to operate under certain conditions whereas in general 283 Internet this cannot be done. Hence requirements for a tunnel 284 protocol operating under a controlled environment can be less 285 restrictive than the requirements of general internet. 287 LISP-GPE scope of applicability is the same set of use cases covered 288 by[I-D.ietf-lisp-rfc6830bis] for the LISP dataplane protocol. The 289 common property of these use cases is a large set of cooperating 290 entities seeking to communicate over the public Internet or other 291 large underlay IP infrastructures, while keeping the addressing and 292 topology of the cooperating entities separate from the underlay and 293 Internet topology, routing, and addressing. 295 LISP-GPE is meant to be deployed in network environments operated by 296 a single operator or adjacent set of cooperating network operators 297 that fits with the definition of controlled environments in 298 [RFC8085]. 300 For the purpose of this document, a traffic-managed controlled 301 environment (TMCE), outlined in [RFC8086], is defined as an IP 302 network that is traffic-engineered and/or otherwise managed (e.g., 303 via use of traffic rate limiters) to avoid congestion. Significant 304 portions of text in this Section are based on [RFC8086]. 306 It is the responsibility of the network operators to ensure that the 307 guidelines/requirements in this section are followed as applicable to 308 their LISP-GPE deployments 310 4.2. Congestion Control Functionality 312 LISP-GPE does not natively provide congestion control functionality 313 and relies on the payload protocol traffic for congestion control. 314 As such LISP-GPE MUST be used with congestion controlled traffic or 315 within a network that is traffic managed to avoid congestion (TMCE). 316 An operator of a traffic managed network (TMCE) may avoid congestion 317 by careful provisioning of their networks, rate-limiting of user data 318 traffic and traffic engineering according to path capacity. 320 Encapsulated payloads may have Explicit Congestion Notification 321 mechanisms that may or may not be mapped to the outer IP header ECN 322 field. Such new encapsulated payloads, when registered with LISP- 323 GPE, MUST be accompanied by a set of guidelines derived from 324 [I-D.ietf-tsvwg-ecn-encap-guidelines] and [RFC6040]. 326 4.3. UDP Checksum 328 For IP payloads, section 5.3 of [I-D.ietf-lisp-rfc6830bis] specifies 329 how to handle UDP Checksums encouraging implementors to consider UDP 330 checksum usage guidelines in section 3.4 of [RFC8085] when it is 331 desirable to protect UDP and LISP headers against corruption. 333 In order to provide integrity of LISP-GPE headers, options and 334 payload, for example to avoid mis-delivery of payload to different 335 tenant systems in case of data corruption, outer UDP checksum SHOULD 336 be used with LISP-GPE when transported over IPv4. The UDP checksum 337 provides a statistical guarantee that a payload was not corrupted in 338 transit. These integrity checks are not strong from a coding or 339 cryptographic perspective and are not designed to detect physical- 340 layer errors or malicious modification of the datagram (see 341 Section 3.4 of [RFC8085]). In deployments where such a risk exists, 342 an operator SHOULD use additional data integrity mechanisms such as 343 offered by IPSec. 345 An operator MAY choose to disable UDP checksum and use zero checksum 346 if LISP-GPE packet integrity is provided by other data integrity 347 mechanisms such as IPsec or additional checksums or if one of the 348 conditions in Section 4.3.1 a, b, c are met. 350 4.3.1. UDP Zero Checksum Handling with IPv6 352 By default, UDP checksum MUST be used when LISP-GPE is transported 353 over IPv6. A tunnel endpoint MAY be configured for use with zero UDP 354 checksum if additional requirements in Section 4.3.1 are met. 356 When LISP-GPE is used over IPv6, UDP checksum is used to protect IPv6 357 headers, UDP headers and LISP-GPE headers and payload from potential 358 data corruption. As such by default LISP-GPE MUST use UDP checksum 359 when transported over IPv6. An operator MAY choose to configure to 360 operate with zero UDP checksum if operating in a traffic managed 361 controlled environment as stated in Section 4.1 if one of the 362 following conditions are met: 364 a. It is known that the packet corruption is exceptionally unlikely 365 (perhaps based on knowledge of equipment types in their underlay 366 network) and the operator is willing to take a risk of undetected 367 packet corruption 369 b. It is judged through observational measurements (perhaps through 370 historic or current traffic flows that use non zero checksum) 371 that the level of packet corruption is tolerably low and where 372 the operator is willing to take the risk of undetected corruption 374 c. LISP-GPE payload is carrying applications that are tolerant of 375 misdelivered or corrupted packets (perhaps through higher layer 376 checksum validation and/or reliability through retransmission) 378 In addition LISP-GPE tunnel implementations using Zero UDP checksum 379 MUST meet the following requirements: 381 1. Use of UDP checksum over IPv6 MUST be the default configuration 382 for all LISP-GPE tunnels 384 2. If LISP-GPE is used with zero UDP checksum over IPv6 then such 385 xTR implementation MUST meet all the requirements specified in 386 section 4 of [RFC6936] and requirements 1 as specified in section 387 5 of [RFC6936] 389 3. The ETR that decapsulates the packet SHOULD check the source and 390 destination IPv6 addresses are valid for the LISP-GPE tunnel that 391 is configured to receive Zero UDP checksum and discard other 392 packets for which such check fails 394 4. The ITR that encapsulates the packet MAY use different IPv6 395 source addresses for each LISP-GPE tunnel that uses Zero UDP 396 checksum mode in order to strengthen the decapsulator's check of 397 the IPv6 source address (i.e the same IPv6 source address is not 398 to be used with more than one IPv6 destination address, 399 irrespective of whether that destination address is a unicast or 400 multicast address). When this is not possible, it is RECOMMENDED 401 to use each source address for as few LISP-GPE tunnels that use 402 zero UDP checksum as is feasible 404 5. Measures SHOULD be taken to prevent LISP-GPE traffic over IPv6 405 with zero UDP checksum from escaping into the general Internet. 406 Examples of such measures include employing packet filters at the 407 PETR and/or keeping logical or physical separation of LISP 408 network from networks carrying General Internet 410 The above requirements do not change either the requirements 411 specified in [RFC2460] as modified by [RFC6935] or the requirements 412 specified in [RFC6936]. 414 The requirement to check the source IPv6 address in addition to the 415 destination IPv6 address, plus the recommendation against reuse of 416 source IPv6 addresses among LISP-GPE tunnels collectively provide 417 some mitigation for the absence of UDP checksum coverage of the IPv6 418 header. A traffic-managed controlled environment that satisfies at 419 least one of three conditions listed at the beginning of this section 420 provides additional assurance. 422 4.4. DSCP, ECN, TTL, and 802.1Q 424 When encapsulating IP (including over Ethernet) packets [RFC2983] 425 provides guidance for mapping DSCP between inner and outer IP 426 headers. The Pipe model typically fits better Network 427 virtualization. The DSCP value on the tunnel header is set based on 428 a policy (which may be a fixed value, one based on the inner traffic 429 class, or some other mechanism for grouping traffic). Some aspects 430 of the Uniform model (which treats the inner and outer DSCP value as 431 a single field by copying on ingress and egress) may also apply, such 432 as the ability to remark the inner header on tunnel egress based on 433 transit marking. However, the Uniform model is not conceptually 434 consistent with network virtualization, which seeks to provide strong 435 isolation between encapsulated traffic and the physical network. 437 [RFC6040] describes the mechanism for exposing ECN capabilities on IP 438 tunnels and propagating congestion markers to the inner packets. 439 This behavior MUST be followed for IP packets encapsulated in LISP- 440 GPE. 442 Though Uniform or Pipe models could be used for TTL (or Hop Limit in 443 case of IPv6) handling when tunneling IP packets, Pipe model is more 444 aligned with network virtualization. [RFC2003] provides guidance on 445 handling TTL between inner IP header and outer IP tunnels; this model 446 is more aligned with the Pipe model and is recommended for use with 447 LISP-GPE for network virtualization applications. 449 When a LISP-GPE router performs Ethernet encapsulation, the inner 450 802.1Q [IEEE.802.1Q_2014] 3-bit priority code point (PCP) field MAY 451 be mapped from the encapsulated frame to the DSCP codepoint of the DS 452 field defined in [RFC2474]. 454 When a LISP-GPE router performs Ethernet encapsulation, the inner 455 header 802.1Q [IEEE.802.1Q_2014] VLAN Identifier (VID) MAY be mapped 456 to, or used to determine the LISP Instance IDentifier (IID) field. 458 5. Backward Compatibility 460 LISP-GPE uses the same UDP destination port (4341) allocated to LISP. 462 When encapsulating IP packets to a non LISP-GPE capable router the 463 P-bit MUST be set to 0. That is, the encapsulation format defined in 464 this document MUST NOT be sent to a router that has not indicated 465 that it supports this specification because such a router would 466 ignore the P-bit (as described in [I-D.ietf-lisp-rfc6830bis]) and so 467 would misinterpret the other LISP header fields possibly causing 468 significant errors. 470 5.1. Detection of ETR Capabilities 472 The discovery of xTR capabilities to support LISP-GPE is out of the 473 scope of this document. Given that the applicability domain of LISP- 474 GPE is a traffic-managed controlled environment, ITR/ETR (xTR) 475 configuration mechanisms may be used for this purpose. 477 6. IANA Considerations 479 6.1. LISP-GPE Next Protocol Registry 481 IANA is requested to set up a registry of LISP-GPE "Next Protocol". 482 These are 8-bit values. Next Protocol values in the table below are 483 defined in this document. New values are assigned under the 484 Specification Required policy [RFC8126]. The protocols that are 485 being assigned values do not themselves need to be IETF standards 486 track protocols. 488 +--------------+-------------------------------------+--------------+ 489 | Next | Description | Reference | 490 | Protocol | | | 491 +--------------+-------------------------------------+--------------+ 492 | 0x0 | Reserved | This | 493 | | | Document | 494 | 0x1 | IPv4 | This | 495 | | | Document | 496 | 0x2 | IPv6 | This | 497 | | | Document | 498 | 0x3 | Ethernet | This | 499 | | | Document | 500 | 0x4 | NSH | This | 501 | | | Document | 502 | 0x05..0x7D | Unassigned | | 503 | 0x7E..0x7F | Experimentation and testing | This | 504 | | | Document | 505 | 0x80..0xFD | Unassigned (shim headers) | | 506 | 0x8E..0x8F | Experimentation and testing (shim | This | 507 | | headers) | Document | 508 +--------------+-------------------------------------+--------------+ 510 7. Security Considerations 512 LISP-GPE security considerations are similar to the LISP security 513 considerations and mitigation techniques documented in [RFC7835]. 515 LISP-GPE, as many encapsulations that use optional extensions, is 516 subject to on-path adversaries that by manipulating the P-Bit and the 517 packet itself can remove part of the payload or claim to encapsulate 518 any protocol payload type. Typical integrity protection mechanisms 519 (such as IPsec) SHOULD be used in combination with LISP-GPE by those 520 protocol extensions that want to protect from on-path attackers. 522 With LISP-GPE, issues such as data-plane spoofing, flooding, and 523 traffic redirection may depend on the particular protocol payload 524 encapsulated. 526 8. Acknowledgements and Contributors 528 A special thank you goes to Dino Farinacci for his guidance and 529 detailed review. 531 This Working Group (WG) document originated as draft-lewis-lisp-gpe; 532 the following are its coauthors and contributors along with their 533 respective affiliations at the time of WG adoption. The editor of 534 this document would like to thank and recognize them and their 535 contributions. These coauthors and contributors provided invaluable 536 concepts and content for this document's creation. 538 o Darrel Lewis, Cisco Systems, Inc. 540 o Fabio Maino, Cisco Systems, Inc. 542 o Paul Quinn, Cisco Systems, Inc. 544 o Michael Smith, Cisco Systems, Inc. 546 o Navindra Yadav, Cisco Systems, Inc. 548 o Larry Kreeger 550 o Jennifer Lemon, Broadcom 552 o Puneet Agarwal, Innovium 554 9. References 556 9.1. Normative References 558 [I-D.ietf-lisp-rfc6830bis] 559 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 560 Cabellos-Aparicio, "The Locator/ID Separation Protocol 561 (LISP)", draft-ietf-lisp-rfc6830bis-32 (work in progress), 562 March 2020. 564 [IEEE.802.1Q_2014] 565 IEEE, "IEEE Standard for Local and metropolitan area 566 networks--Bridges and Bridged Networks", IEEE 802.1Q-2014, 567 DOI 10.1109/ieeestd.2014.6991462, December 2014, 568 . 571 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 572 Requirement Levels", BCP 14, RFC 2119, 573 DOI 10.17487/RFC2119, March 1997, 574 . 576 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 577 Notification", RFC 6040, DOI 10.17487/RFC6040, November 578 2010, . 580 9.2. Informative References 582 [I-D.brockners-ippm-ioam-vxlan-gpe] 583 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 584 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Kfir, A., 585 Gafni, B., Lapukhov, P., and M. Spiegel, "VXLAN-GPE 586 Encapsulation for In-situ OAM Data", draft-brockners-ippm- 587 ioam-vxlan-gpe-03 (work in progress), November 2019. 589 [I-D.ietf-tsvwg-ecn-encap-guidelines] 590 Briscoe, B., Kaippallimalil, J., and P. Thaler, 591 "Guidelines for Adding Congestion Notification to 592 Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn- 593 encap-guidelines-13 (work in progress), May 2019. 595 [I-D.lemon-vxlan-lisp-gpe-gbp] 596 Lemon, J., Maino, F., Smith, M., and A. Isaac, "Group 597 Policy Encoding with VXLAN-GPE and LISP-GPE", draft-lemon- 598 vxlan-lisp-gpe-gbp-02 (work in progress), April 2019. 600 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 601 DOI 10.17487/RFC2003, October 1996, 602 . 604 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 605 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 606 December 1998, . 608 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 609 "Definition of the Differentiated Services Field (DS 610 Field) in the IPv4 and IPv6 Headers", RFC 2474, 611 DOI 10.17487/RFC2474, December 1998, 612 . 614 [RFC2983] Black, D., "Differentiated Services and Tunnels", 615 RFC 2983, DOI 10.17487/RFC2983, October 2000, 616 . 618 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 619 Considered Useful", BCP 82, RFC 3692, 620 DOI 10.17487/RFC3692, January 2004, 621 . 623 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 624 UDP Checksums for Tunneled Packets", RFC 6935, 625 DOI 10.17487/RFC6935, April 2013, 626 . 628 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 629 for the Use of IPv6 UDP Datagrams with Zero Checksums", 630 RFC 6936, DOI 10.17487/RFC6936, April 2013, 631 . 633 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 634 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 635 eXtensible Local Area Network (VXLAN): A Framework for 636 Overlaying Virtualized Layer 2 Networks over Layer 3 637 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 638 . 640 [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID 641 Separation Protocol (LISP) Threat Analysis", RFC 7835, 642 DOI 10.17487/RFC7835, April 2016, 643 . 645 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 646 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 647 March 2017, . 649 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 650 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, 651 March 2017, . 653 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 654 Writing an IANA Considerations Section in RFCs", BCP 26, 655 RFC 8126, DOI 10.17487/RFC8126, June 2017, 656 . 658 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 659 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 660 May 2017, . 662 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 663 "Network Service Header (NSH)", RFC 8300, 664 DOI 10.17487/RFC8300, January 2018, 665 . 667 Authors' Addresses 669 Fabio Maino (editor) 670 Cisco Systems 671 San Jose, CA 95134 672 USA 674 Email: fmaino@cisco.com 676 Jennifer Lemon 677 Broadcom 678 270 Innovation Drive 679 San Jose, CA 95134 680 USA 682 Email: jennifer.lemon@broadcom.com 684 Puneet Agarwal 685 Innovium 686 USA 688 Email: puneet@acm.org 690 Darrel Lewis 691 Cisco Systems 692 San Jose, CA 95134 693 USA 695 Email: darlewis@cisco.com 696 Michael Smith 697 Cisco Systems 698 San Jose, CA 95134 699 USA 701 Email: michsmit@cisco.com