draft-ietf-lisp-gpe-18.txt   draft-ietf-lisp-gpe-19.txt 
Internet Engineering Task Force F. Maino, Ed. Internet Engineering Task Force F. Maino, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track J. Lemon Intended status: Standards Track J. Lemon
Expires: January 14, 2021 Broadcom Expires: January 27, 2021 Broadcom
P. Agarwal P. Agarwal
Innovium Innovium
D. Lewis D. Lewis
M. Smith M. Smith
Cisco Cisco
July 13, 2020 July 26, 2020
LISP Generic Protocol Extension LISP Generic Protocol Extension
draft-ietf-lisp-gpe-18 draft-ietf-lisp-gpe-19
Abstract Abstract
This document describes extensions to the Locator/ID Separation This document describes extensions to the Locator/ID Separation
Protocol (LISP) Data-Plane, via changes to the LISP header, to Protocol (LISP) Data-Plane, via changes to the LISP header, to
support multi-protocol encapsulation and allow to introduce new support multi-protocol encapsulation and allow to introduce new
protocol capabilities. protocol capabilities.
Status of This Memo Status of This Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 14, 2021. This Internet-Draft will expire on January 27, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 23 skipping to change at page 2, line 23
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 3 1.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 3
2. LISP Header Without Protocol Extensions . . . . . . . . . . . 3 2. LISP Header Without Protocol Extensions . . . . . . . . . . . 3
3. Generic Protocol Extension for LISP (LISP-GPE) . . . . . . . 4 3. Generic Protocol Extension for LISP (LISP-GPE) . . . . . . . 4
4. Implementation and Deployment Considerations . . . . . . . . 6 4. Implementation and Deployment Considerations . . . . . . . . 6
4.1. Applicability Statement . . . . . . . . . . . . . . . . . 6 4.1. Applicability Statement . . . . . . . . . . . . . . . . . 6
4.2. Congestion Control Functionality . . . . . . . . . . . . 7 4.2. Congestion Control Functionality . . . . . . . . . . . . 7
4.3. UDP Checksum . . . . . . . . . . . . . . . . . . . . . . 8 4.3. UDP Checksum . . . . . . . . . . . . . . . . . . . . . . 8
4.3.1. UDP Zero Checksum Handling with IPv6 . . . . . . . . 8 4.3.1. UDP Zero Checksum Handling with IPv6 . . . . . . . . 8
4.4. DSCP, ECN, TTL, and 802.1Q . . . . . . . . . . . . . . . 10 4.4. DSCP, ECN, TTL, and 802.1Q . . . . . . . . . . . . . . . 10
5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 11
5.1. Detection of ETR Capabilities . . . . . . . . . . . . . . 11 5.1. Detection of ETR Capabilities . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6.1. LISP-GPE Next Protocol Registry . . . . . . . . . . . . . 11 6.1. LISP-GPE Next Protocol Registry . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements and Contributors . . . . . . . . . . . . . . 12 8. Acknowledgements and Contributors . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The LISP Data-Plane is defined in [I-D.ietf-lisp-rfc6830bis]. It The LISP Data-Plane is defined in [I-D.ietf-lisp-rfc6830bis]. It
specifies an encapsulation format that carries IPv4 or IPv6 packets specifies an encapsulation format that carries IPv4 or IPv6 packets
(henceforth jointly referred to as IP) in a LISP header and outer (henceforth jointly referred to as IP) in a LISP header and outer
UDP/IP transport. UDP/IP transport.
The LISP Data-Plane header does not specify the protocol being The LISP Data-Plane header does not specify the protocol being
encapsulated and therefore is currently limited to encapsulating only encapsulated and therefore is currently limited to encapsulating only
skipping to change at page 7, line 44 skipping to change at page 7, line 44
LISP-GPE does not natively provide congestion control functionality LISP-GPE does not natively provide congestion control functionality
and relies on the payload protocol traffic for congestion control. and relies on the payload protocol traffic for congestion control.
As such LISP-GPE MUST be used with congestion controlled traffic or As such LISP-GPE MUST be used with congestion controlled traffic or
within a network that is traffic managed to avoid congestion (TMCE). within a network that is traffic managed to avoid congestion (TMCE).
An operator of a traffic managed network (TMCE) may avoid congestion An operator of a traffic managed network (TMCE) may avoid congestion
by careful provisioning of their networks, rate-limiting of user data by careful provisioning of their networks, rate-limiting of user data
traffic and traffic engineering according to path capacity. traffic and traffic engineering according to path capacity.
Keeping in mind the reccomendation above, new encapsulated payloads, Keeping in mind the reccomendation above, new encapsulated payloads,
when registered with LISP-GPE, should be designed for explicit when registered with LISP-GPE, MUST be accompained by a set of
congestion signals to propagate consistently from lower layer guidelines derived from [I-D.ietf-lisp-rfc6830bis]. Such new
protocols into IP. Then the IP internetwork layer can act as a protocols should be designed for explicit congestion signals to
portability layer to carry congestion notification from non-IP-aware propagate consistently from lower layer protocols into IP. Then the
congested nodes up to the transport layer (L4). Such new IP internetwork layer can act as a portability layer to carry
encapsulated payloads, when registered with LISP-GPE, MUST be congestion notification from non-IP-aware congested nodes up to the
accompanied by a set of guidelines derived from [RFC6040] and SHOULD transport layer (L4). By following the guidelines in
follow the guidelines defined in [I-D.ietf-tsvwg-ecn-encap-guidelines], subnetwork designers can
[I-D.ietf-tsvwg-ecn-encap-guidelines]. enable a layer-2 protocol to participate in congestion control
without dropping packets via propagation of explicit congestion
notification (ECN [RFC3168] ) to receivers.
4.3. UDP Checksum 4.3. UDP Checksum
For IP payloads, section 5.3 of [I-D.ietf-lisp-rfc6830bis] specifies For IP payloads, section 5.3 of [I-D.ietf-lisp-rfc6830bis] specifies
how to handle UDP Checksums encouraging implementors to consider UDP how to handle UDP Checksums encouraging implementors to consider UDP
checksum usage guidelines in section 3.4 of [RFC8085] when it is checksum usage guidelines in section 3.4 of [RFC8085] when it is
desirable to protect UDP and LISP headers against corruption. desirable to protect UDP and LISP headers against corruption.
In order to provide integrity of LISP-GPE headers, options and In order to provide integrity of LISP-GPE headers, options and
payload, for example to avoid mis-delivery of payload to different payload, for example to avoid mis-delivery of payload to different
skipping to change at page 10, line 45 skipping to change at page 10, line 45
When a LISP-GPE router performs Ethernet encapsulation, the inner When a LISP-GPE router performs Ethernet encapsulation, the inner
802.1Q [IEEE.802.1Q_2014] 3-bit priority code point (PCP) field MAY 802.1Q [IEEE.802.1Q_2014] 3-bit priority code point (PCP) field MAY
be mapped from the encapsulated frame to the DSCP codepoint of the DS be mapped from the encapsulated frame to the DSCP codepoint of the DS
field defined in [RFC2474]. field defined in [RFC2474].
When a LISP-GPE router performs Ethernet encapsulation, the inner When a LISP-GPE router performs Ethernet encapsulation, the inner
header 802.1Q [IEEE.802.1Q_2014] VLAN Identifier (VID) MAY be mapped header 802.1Q [IEEE.802.1Q_2014] VLAN Identifier (VID) MAY be mapped
to, or used to determine the LISP Instance IDentifier (IID) field. to, or used to determine the LISP Instance IDentifier (IID) field.
Refer to Section 7 for consideration about the use of integrity
protection for deployments, such as the public Internet, concerned
with on-path attackers.
5. Backward Compatibility 5. Backward Compatibility
LISP-GPE uses the same UDP destination port (4341) allocated to LISP. LISP-GPE uses the same UDP destination port (4341) allocated to LISP.
When encapsulating IP packets to a non LISP-GPE capable router the 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 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 this document MUST NOT be sent to a router that has not indicated
that it supports this specification because such a router would that it supports this specification because such a router would
ignore the P-bit (as described in [I-D.ietf-lisp-rfc6830bis]) and so ignore the P-bit (as described in [I-D.ietf-lisp-rfc6830bis]) and so
would misinterpret the other LISP header fields possibly causing would misinterpret the other LISP header fields possibly causing
skipping to change at page 12, line 11 skipping to change at page 12, line 33
| 0x8E..0x8F | Experimentation and testing (shim | This | | 0x8E..0x8F | Experimentation and testing (shim | This |
| | headers) | Document | | | headers) | Document |
+--------------+-------------------------------------+--------------+ +--------------+-------------------------------------+--------------+
7. Security Considerations 7. Security Considerations
LISP-GPE security considerations are similar to the LISP security LISP-GPE security considerations are similar to the LISP security
considerations and mitigation techniques documented in [RFC7835]. considerations and mitigation techniques documented in [RFC7835].
LISP-GPE, as many encapsulations that use optional extensions, is LISP-GPE, as many encapsulations that use optional extensions, is
subject to on-path adversaries that by manipulating the P-Bit and the subject to on-path adversaries that can make arbitrary modifications
packet itself can remove part of the payload or claim to encapsulate to the packet (including the P-Bit) to change or remove any part of
any protocol payload type. Typical integrity protection mechanisms the payload, or claim to encapsulate any protocol payload type.
(such as IPsec) SHOULD be used in combination with LISP-GPE by those Typical integrity protection mechanisms (such as IPsec) SHOULD be
protocol extensions that want to protect from on-path attackers. 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 With LISP-GPE, issues such as data-plane spoofing, flooding, and
traffic redirection may depend on the particular protocol payload traffic redirection may depend on the particular protocol payload
encapsulated. encapsulated.
8. Acknowledgements and Contributors 8. Acknowledgements and Contributors
A special thank you goes to Dino Farinacci for his guidance and A special thank you goes to Dino Farinacci for his guidance and
detailed review. Thanks to Tom Herbert for the suggestion to assign detailed review. Thanks to Tom Herbert for the suggestion to assign
codepoints for experimentations and testing. codepoints for experimentations and testing.
skipping to change at page 14, line 23 skipping to change at page 14, line 43
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>. <https://www.rfc-editor.org/info/rfc2474>.
[RFC2983] Black, D., "Differentiated Services and Tunnels", [RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, DOI 10.17487/RFC2983, October 2000, RFC 2983, DOI 10.17487/RFC2983, October 2000,
<https://www.rfc-editor.org/info/rfc2983>. <https://www.rfc-editor.org/info/rfc2983>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, Considered Useful", BCP 82, RFC 3692,
DOI 10.17487/RFC3692, January 2004, DOI 10.17487/RFC3692, January 2004,
<https://www.rfc-editor.org/info/rfc3692>. <https://www.rfc-editor.org/info/rfc3692>.
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
UDP Checksums for Tunneled Packets", RFC 6935, UDP Checksums for Tunneled Packets", RFC 6935,
DOI 10.17487/RFC6935, April 2013, DOI 10.17487/RFC6935, April 2013,
<https://www.rfc-editor.org/info/rfc6935>. <https://www.rfc-editor.org/info/rfc6935>.
 End of changes. 10 change blocks. 
21 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/