UDP encapsulated ESP for ECMP

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 IPsec tunnel mode IPsec transport mode applied to the outer IP header of some other tunneling mechanism e.g. VXLAN or GRE 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.

UDP-Encapsulated ESP Header Format

It is RECOMMENDED that the UDP Source Port number be calculated using a hash of fields from the inner packet e.g. the original IP addresses of the payload packet inside the tunnel. When calculating the UDP Source Port number in this manner, it is RECOMMENDED that the value be in the dynamic/private port range 49152-65535 . The Destination Port MUST be the same as that used by IKE traffic, per . The UDP Checksum SHOULD be transmitted as a zero value, per . Receivers MUST NOT depend on the UDP checksum being a zero value, per . The SPI field in the ESP header MUST NOT be a zero value, per . Note that the use of the UDP source port is consistent with its usage in VXLAN,

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 , be disabled for a session using UDP encapsulated ESP for ECMP.

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 . In that case, the UDP Source Port number MUST be the same as that used by IKE traffic per , which supersedes the recommendation in this document.

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 when, and only when, they appear in all capitals, as shown here.

Security Considerations IPsec anti-replay service may have to be disabled when UDP encapsulated ESP is used for ECMP. . 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 The IPsec traffic distribution between different flows can be observed. Some information about the inner header fields is leaked via the UDP source port. However no more information is leaked than if per-flow IPSec Transport Mode were used between Tunnel Endpoints. The identification of the flow or the internal header fields, by itself, may not pose a security threat.

IANA Considerations This document has no IANA actions.