Internet-Draft UDP encapsulated ESP for ECMP April 2023
Acharya & Holbrook Expires 23 October 2023 [Page]
Workgroup:
IP Security Maintenance and Extensions Working Group
Internet-Draft:
draft-acharya-ipsecme-esp-ecmp-00
Published:
Intended Status:
Informational
Expires:
Authors:
D. Acharya
Arista Networks, Inc.
H. Holbrook
Arista Networks, Inc.

UDP encapsulated ESP for ECMP

Abstract

This document modifies [RFC3948] to allow the UDP source port of a UDP-Encapsulated ESP packet to provide entropy for ECMP load balancing between IPSec tunnel endpoints. This document provides guidelines for safely allowing this behavior and falling back to the encapsulation defined in [RFC3948] when a NAT gateway is discovered in the path.

About This Document

This note is to be removed before publishing as an RFC.

The latest revision of this draft can be found at https://example.com/LATEST. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-acharya-ipsecme-esp-ecmp/.

Discussion of this document takes place on the WG Working Group mailing list (mailto:[email protected]), which is archived at https://example.com/WG.

Source for this draft and an issue tracker can be found at https://github.com/USER/REPO.

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 https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 23 October 2023.

Table of Contents

1. Introduction

Equal Cost Multi-Path (ECMP) can be used to balance traffic across multiple paths between 2 end-points. An important requirement is to have packets belonging to the same “flow” use the same path to prevent reordering of packets within a flow.

IPsec can be used to secure traffic between two Tunnel End Points (TEPs). Two ways of doing this are to use

Either way, one IPsec session, identified by outer IP addresses and SPI value in the ESP header, can be used to protect packets belonging to multiple “flows”. In this context, a “flow” is a sequence of packets with common inner header fields.. Examples of such inner packet header fields are the original IP addresses of the payload packet inside an IPsec tunnel.

The flow to which an IPsec encrypted packet belongs cannot generally be identified because the inner packet headers are encrypted. This document defines a mechanism that allows different flows using the same IPsec session to take different paths, while still maintaining a single path for each flow. In order to do this, the UDP source port of a UDP-encapsulated ESP packet carries a “digest” of inner packet headers. The “digest” enables this outer source port to be used for load balancing in the transport network between TEPs.

2. UDP-Encapsulated ESP Header Format

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Source Port            |      Destination Port         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Length              |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ESP header [RFC4303]                     |
~                                                               ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note that the use of the UDP source port is consistent with its usage in VXLAN, [RFC7348]

3. ECMP and IPsec sequence check

When different flows take different paths between tunnel endpoints there can be big differences in path-delay and out-of-order packets are more likely to arrive outside the anti-replay window. Therefore, it is RECOMMENDED that the IPsec anti-replay service, defined in [RFC4301], be disabled for a session using UDP encapsulated ESP for ECMP.

4. Interaction with NAT-Traversal

If IKE is configured to support NAT-Traversal and detects NAT along the path between IKE peers, then UDP encapsulated ESP is used for NAT-Traversal, per [RFC3947]. In that case, the UDP Source Port number MUST be the same as that used by IKE traffic per [RFC3948], which supersedes the recommendation in this document.

5. Conventions and Definitions

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.

6. Security Considerations

  1. IPsec anti-replay service may have to be disabled when UDP encapsulated ESP is used for ECMP. .
  2. Some sort of flow-identification in the packet header is necessary to make sure packets of a flow are routed in the same path. That means the packets belonging to the same flow or a set of flows can be identified by examining the Source Port in the outer UDP header. This implies that

7. IANA Considerations

This document has no IANA actions.

8. References

8.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3947]
Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, DOI 10.17487/RFC3947, , <https://www.rfc-editor.org/rfc/rfc3947>.
[RFC3948]
Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, DOI 10.17487/RFC3948, , <https://www.rfc-editor.org/rfc/rfc3948>.
[RFC4301]
Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, , <https://www.rfc-editor.org/rfc/rfc4301>.
[RFC4303]
Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, , <https://www.rfc-editor.org/rfc/rfc4303>.
[RFC6335]
Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, , <https://www.rfc-editor.org/rfc/rfc6335>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.

8.2. Informative References

[RFC2784]
Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, , <https://www.rfc-editor.org/rfc/rfc2784>.
[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, , <https://www.rfc-editor.org/rfc/rfc7348>.

Authors' Addresses

Dipankar Acharya
Arista Networks, Inc.
5453 Great America Pkwy
Santa Clara, CA 95054
United States of America
Hugh Holbrook
Arista Networks, Inc.
5453 Great America Pkwy
Santa Clara, CA 95054
United States of America