[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07

Network Working Group                                             X. Xu
Internet Draft                                                 D. Zhang
Category: Standard Track                                          L.Xia
                                                                 Huawei

Expires: December 2016                                 October 31, 2016


            Encapsulating IPsec ESP in UDP for Load-balancing

                    draft-xu-ipsecme-esp-in-udp-lb-00

    Abstract

  IPsec Virtual Private Network (VPN) is widely used by enterprises to
  interconnect their geographical dispersed branch office locations
  across IP Wide Area Network (WAN). To fully utilize the bandwidth
  available in IP WAN, load balancing of traffic between different
  IPsec VPN sites over Equal Cost Multi-Path (ECMP) and/or Link
  Aggregation Group (LAG) within IP WAN is attractive to those
  enterprises deploying IPsec VPN solutions. This document defines a
  method to encapsulate IPsec Encapsulating Security Payload (ESP)
  packets inside UDP packets for improving load-balancing of IPsec
  tunneled traffic. In addition, this encapsulation is also applicable
  to some special multi-tenant data center network environment where
  the overlay tunnels need to be secured.

    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), its areas, and its working groups. Note that
  other groups may also distribute working documents as Internet-
  Drafts.

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

  The list of current Internet-Drafts can be accessed at
  http://www.ietf.org/ietf/1id-abstracts.txt.

  The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html.




    Xu, et al.            Expires December 31, 2016               [Page 1]


    Internet-Draft   Encapsulating ESP in UDP for Load-balancing    October
    2016

  This Internet-Draft will expire on December 31, 2016.

    Copyright Notice

  Copyright (c) 2013 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
  (http://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 Simplified BSD License text as described in
  Section 4.e of the Trust Legal Provisions and are provided without
  warranty as described in the Simplified BSD License.

    Conventions used in this document

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in RFC-2119 [RFC2119].

    Table of Contents


  1. Introduction ................................................ 3
  2. Terminology ................................................. 4
  3. Encapsulating ESP in UDP .................................... 4
  4. Encapsulation and Decapsulation Procedures .................. 5
  5. Congestion Considerations ................................... 5
  6. Security Considerations ..................................... 5
  7. IANA Considerations ......................................... 6
  8. Acknowledgements ............................................ 6
  9. References .................................................. 6
     9.1. Normative References ................................... 6
     9.2. Informative References ................................. 6
  Authors' Addresses ............................................. 7










    Xu, et al.            Expires December 31, 2016               [Page 2]


    Internet-Draft   Encapsulating ESP in UDP for Load-balancing    October
    2016


    1. Introduction

  IPsec Virtual Private Network (VPN) is widely used by enterprises to
  interconnect their geographical dispersed branch office locations
  across IP Wide Area Network (WAN). To fully utilize the bandwidth
  available in IP WAN, load balancing of traffic between different
  IPsec VPN sites over Equal Cost Multi-Path (ECMP) and/or Link
  Aggregation Group (LAG) within IP WAN is much attractive to those
  enterprises that deploy IPsec VPN solutions. Since most existing
  core routers within IP WAN can already support balancing IP traffic
  flows based on the hash of the five-tuple of UDP packets, by
  encapsulating IPsec Encapsulating Security Payload (ESP) packets
  inside UDP packets with the UDP source port being used as an entropy
  field, it will enable existing core routers to perform efficient
  load-balancing of the IPsec tunneled traffic without requiring any
  change to them. Therefore, this specification defines a method of
  encapsulating IPsec ESP packets inside UDP packets for improving
  load-balancing of IPsec tunneled traffic. This is similar to why
  LISP [RFC6830], MPLS-in-UDP [RFC7510] and VXLAN [RFC7348] use UDP
  encapsulation.

  In addition, this encapsulation is also applicable to some special
  multi-tenant data center network environment where the overlay
  tunnels need to be secured while the UDP-based ECMP capability is
  desired as well (see [draft-ietf-nvo3-use-case]).

  Encapsulating ESP in UDP, as defined in this document, can be used
  in both IPv4 and IPv6 scenarios. IPv6 flow label has been proposed
  as an entropy field for load balancing in IPv6 network environment
  [RFC6438]. However, as stated in [RFC6936], the end-to-end use of
  flow labels for load balancing is a long-term solution and therefore
  the use of load balancing using the transport header fields would
  continue until any widespread deployment is finally achieved.  As
  such, IP-in-UDP encapsulation would still have a practical
  application value in the IPv6 networks during this transition
  timeframe.

  Note that the difference between the ESP-in-UDP encapsulation as
  proposed in this document and the ESP-in-UDP encapsulation as
  described in [RFC3948] is that the former uses the UDP tunnel for
  load-balancing improvement purpose and therefore the source port is
  used as an entropy field while the latter uses the UDP tunnel for
  NAT traverse purpose and therefore the source port is set to a
  constant value (i.e., 4500). In addition, the document only
  discusses about the tunnel mode ESP encapsulation.



    Xu, et al.            Expires December 31, 2016               [Page 3]


    Internet-Draft   Encapsulating ESP in UDP for Load-balancing    October
    2016

    2. Terminology

  This memo makes use of the terms defined in [RFC2401] and [RFC2406].

    3. Encapsulating ESP in UDP

  ESP-in-UDP encapsulation format is shown as follows:

  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 = entropy      |       Dest Port = ESP         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |           UDP Length          |        UDP Checksum           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  ~                         ESP Packet                            ~
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Source Port of UDP

               This field contains a 16-bit entropy value that is
               generated by the encapsulator to uniquely identify a
               flow.  What constitutes a flow is locally determined by
               the encapsulator and therefore is outside the scope of
               this document.  What algorithm is actually used by the
               encapsulator to generate an entropy value is outside the
               scope of this document. In case the tunnel does not need
               entropy, this field of all packets belonging to a given
               flow SHOULD be set to a randomly selected constant value
               so as to avoid packet reordering.

               To ensure that the source port number is always in the
               range 49152 to 65535 (Note that those ports less than
               49152 are reserved by IANA to identify specific
               applications/protocols) which may be required in some
               cases, instead of calculating a 16-bit hash, the
               encapsulator SHOULD calculate a 14-bit hash and use
               those 14 bits as the least significant bits of the
               source port field while the most significant two bits
               SHOULD be set to binary 11.  That still conveys 14 bits
               of entropy information which would be enough as well in
               practice.

           Destination Port of UDP



    Xu, et al.            Expires December 31, 2016               [Page 4]


    Internet-Draft   Encapsulating ESP in UDP for Load-balancing    October
    2016

               This field is set to a value (TBD) indicating the
               encapsulated payload in the UDP header is an ESP packet.

           UDP Length

               The usage of this field is in accordance with the
               current UDP specification [RFC768].

           UDP Checksum

               For IPv4 UDP encapsulation, this field is RECOMMENDED to
               be set to zero for performance or implementation reasons
               because the IPv4 header includes a checksum and use of
               the UDP checksum is optional with IPv4.  For IPv6 UDP
               encapsulation, the IPv6 header does not include a
               checksum, so this field MUST contain a UDP checksum that
               MUST be used as specified in [RFC0768] and [RFC2460]
               unless one of the exceptions that allows use of UDP
               zero-checksum mode (as specified in [RFC6935]) applies.

    4. Encapsulation and Decapsulation Procedures

  This ESP-in-UDP encapsulation causes ESP [RFC2406] packets to be
  forwarded across IP WAN via "UDP tunnels". When performing ESP-in-
  UDP encapsulation by an IPsec VPN gateway, ordinary ESP
  encapsulation procedure is performed and then a formatted UDP header
  is inserted between ESP header and IP header. The Source Port field
  of the UDP header is filled with an entropy value which is generated
  by the IPsec VPN gateway.

  Upon receiving these UDP encapsulated packets, remote IPsec VPN
  gateway MUST decapsulate these packets by removing the UDP header
  and then perform ordinary ESP decapsulation procedure consequently.

    5. Congestion Considerations

  TBD

    6. Security Considerations

  TBD.








    Xu, et al.            Expires December 31, 2016               [Page 5]


    Internet-Draft   Encapsulating ESP in UDP for Load-balancing    October
    2016

    7. IANA Considerations

  A new UDP destination port number which indicates the encapsulated
  payload following the UDP header is an ESP packet needs to be
  assigned by IANA.

    8. Acknowledgements

  Thanks to.

    9. References

  9.1. Normative References

  [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.

  9.2. Informative References

  [RFC768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
            August 1980.

  [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
            Internet Protocol", RFC 2401, November 1998.

  [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
            Payload (ESP)", RFC 2406, November 1998.

  [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "UDP
            Checksums for Tunneled Packets", RFC6935, Feburary 2013.

  [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
            Stenberg, "UDP Encapsulation of IPsec Packets", RFC 3948,
            January 2005.

  [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
            for the use of IPv6 UDP Datagrams with Zero Checksums",
            RFC6936, Feburary 2013.

    [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
             "Encapsulating MPLS in UDP", RFC 7510,
             DOI 10.17487/RFC7510, April 2015,
             <http://www.rfc-editor.org/info/rfc7510>.






    Xu, et al.            Expires December 31, 2016               [Page 6]


    Internet-Draft   Encapsulating ESP in UDP for Load-balancing    October
    2016

    Authors' Addresses

  Xiaohu Xu
  Huawei Technologies,
  Beijing, China
  Phone: +86-10-60610041
  Email: xuxiaohu@huawei.com

  Dacheng Zhang
  Huawei Technologies,
  Beijing, China
  Phone: +86-13621142434
  Email: dacheng.zhang@huawei.com

  Liang Xia
  Huawei Technologies,
  Email: frank.xialiang@huawei.com































    Xu, et al.            Expires December 31, 2016               [Page 7]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/