Internet DRAFT - draft-acharya-ipsecme-esp-ecmp

draft-acharya-ipsecme-esp-ecmp







IP Security Maintenance and Extensions Working Group          D. Acharya
Internet-Draft                                               H. Holbrook
Intended status: Informational                     Arista Networks, Inc.
Expires: 23 October 2023                                   21 April 2023


                     UDP encapsulated ESP for ECMP
                   draft-acharya-ipsecme-esp-ecmp-00

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:WG@example.com), 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."



Acharya & Holbrook       Expires 23 October 2023                [Page 1]

Internet-Draft        UDP encapsulated ESP for ECMP           April 2023


   This Internet-Draft will expire on 23 October 2023.

Copyright Notice

   Copyright (c) 2023 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 (https://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 to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  UDP-Encapsulated ESP Header Format  . . . . . . . . . . . . .   3
   3.  ECMP and IPsec sequence check . . . . . . . . . . . . . . . .   4
   4.  Interaction with NAT-Traversal  . . . . . . . . . . . . . . .   4
   5.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

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

   *  IPsec tunnel mode

   *  IPsec transport mode applied to the outer IP header of some other
      tunneling mechanism e.g.  VXLAN [RFC7348] or GRE [RFC2784]

   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



Acharya & Holbrook       Expires 23 October 2023                [Page 2]

Internet-Draft        UDP encapsulated ESP for ECMP           April 2023


   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]                     |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   *  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 [RFC6335].

   *  The Destination Port MUST be the same as that used by IKE traffic,
      per [RFC3948].

   *  The UDP Checksum SHOULD be transmitted as a zero value, per
      [RFC3948].

   *  Receivers MUST NOT depend on the UDP checksum being a zero value,
      per [RFC3948].

   *  The SPI field in the ESP header MUST NOT be a zero value, per
      [RFC3948].

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



Acharya & Holbrook       Expires 23 October 2023                [Page 3]

Internet-Draft        UDP encapsulated ESP for ECMP           April 2023


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

   *  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.







Acharya & Holbrook       Expires 23 October 2023                [Page 4]

Internet-Draft        UDP encapsulated ESP for ECMP           April 2023


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, March 1997,
              <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, January 2005,
              <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, January 2005,
              <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,
              December 2005, <https://www.rfc-editor.org/rfc/rfc4301>.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, DOI 10.17487/RFC4303, December 2005,
              <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, August 2011,
              <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,
              May 2017, <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, March 2000,
              <https://www.rfc-editor.org/rfc/rfc2784>.



Acharya & Holbrook       Expires 23 October 2023                [Page 5]

Internet-Draft        UDP encapsulated ESP for ECMP           April 2023


   [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/rfc/rfc7348>.

Authors' Addresses

   Dipankar Acharya
   Arista Networks, Inc.
   5453 Great America Pkwy
   Santa Clara, CA 95054
   United States of America
   Email: dipankar@arista.com


   Hugh Holbrook
   Arista Networks, Inc.
   5453 Great America Pkwy
   Santa Clara, CA 95054
   United States of America
   Email: holbrook@arista.com




























Acharya & Holbrook       Expires 23 October 2023                [Page 6]