idnits 2.17.00 (12 Aug 2021) /tmp/idnits54226/draft-xu-ipsecme-esp-in-udp-lb-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 17, 2020) is 550 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Xu 3 Internet-Draft Alibaba, Inc 4 Intended status: Standards Track S. Hegde 5 Expires: May 21, 2021 Juniper 6 B. Pismenny 7 Nvidia 8 D. Zhang 9 L. Xia 10 Huawei 11 November 17, 2020 13 Encapsulating IPsec ESP in UDP for Load-balancing 14 draft-xu-ipsecme-esp-in-udp-lb-06 16 Abstract 18 IPsec Virtual Private Network (VPN) is widely used by enterprises to 19 interconnect their geographical dispersed branch office locations 20 across the Wide Area Network (WAN) or the Internet, especially in the 21 Software-Defined-WAN (SD-WAN) era. In addition, IPsec is also 22 increasingly used by cloud providers to encrypt IP traffic traversing 23 data center interconnect WAN so as to meet the security and 24 compliance requirements, especially in financial cloud and 25 governmental cloud environments. To fully utilize the bandwidth 26 available in the WAN or the Internet, load balancing of IPsec traffic 27 over Equal Cost Multi-Path (ECMP) and/or Link Aggregation Group (LAG) 28 is much attractive to those enterprises and cloud providers. This 29 document defines a method to encapsulate IPsec Encapsulating Security 30 Payload (ESP) packets over UDP tunnels for improving load-balancing 31 of IPsec ESP traffic. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 21, 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Encapsulation in UDP . . . . . . . . . . . . . . . . . . . . 3 71 4. Processing Procedures . . . . . . . . . . . . . . . . . . . . 5 72 5. Congestion Considerations . . . . . . . . . . . . . . . . . . 6 73 6. Applicability Statements . . . . . . . . . . . . . . . . . . 6 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 79 10.2. Informative References . . . . . . . . . . . . . . . . . 7 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 82 1. Introduction 84 IPsec Virtual Private Network (VPN) is widely used by enterprises to 85 interconnect their geographical dispersed branch office locations 86 across the Wide Area Network (WAN) or the Internet, especially in the 87 Software-Defined-WAN (SD-WAN) era. In addition, IPsec is also 88 increasingly used by cloud providers to encrypt IP traffic traversing 89 data center interconnect WAN so as to meet the security and 90 compliance requirements, especially in financial cloud and 91 governmental cloud environments. To fully utilize the bandwidth 92 available in the WAN or the Internet, load balancing of IPsec traffic 93 over Equal Cost Multi-Path (ECMP) and/or Link Aggregation Group (LAG) 94 is much attractive to those enterprises and cloud providers. Since 95 most existing core routers within IP WAN or the Internet can already 96 support balancing IP traffic flows based on the hash of the five- 97 tuple of UDP packets, by encapsulating IPsec Encapsulating Security 98 Payload (ESP) packets over UDP tunnels with the UDP source port being 99 used as an entropy field, it will enable existing core routers to 100 perform efficient load-balancing of the IPsec ESP traffic without 101 requiring any change to them. Therefore, this specification defines 102 a method of encapsulating IPsec ESP packets over UDP tunnels for 103 improving load-balancing of IPsec ESP traffic. 105 Encapsulating ESP in UDP, as defined in this document, can be used in 106 both IPv4 and IPv6 networks. IPv6 flow label has been proposed as an 107 entropy field for load balancing in IPv6 network environment 108 [RFC6438]. However, as stated in [RFC6936], the end-to-end use of 109 flow labels for load balancing is a long-term solution and therefore 110 the use of load balancing using the transport header fields would 111 continue until any widespread deployment is finally achieved. As 112 such, ESP-in-UDP encapsulation would still have a practical 113 application value in the IPv6 networks during this transition 114 timeframe. 116 Note that the difference between the ESP-in-UDP encapsulation as 117 proposed in this document and the ESP-in-UDP encapsulation as 118 described in [RFC3948] is that the former uses the UDP tunnel for 119 load-balancing improvement purpose and therefore the source port is 120 used as an entropy field while the latter uses the UDP tunnel for NAT 121 traverse purpose and therefore the source port is set to a constant 122 value (i.e., 4500). In addition, the ESP-in-UDP encapsulation as 123 described in this document is applicable to both the tunnel mode ESP 124 encapsulation and the transport mode ESP encapsulation. 126 1.1. Requirements Language 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [RFC2119]. 132 2. Terminology 134 This memo makes use of the terms defined in [RFC2401]and [RFC2406]. 136 3. Encapsulation in UDP 138 ESP-in-UDP encapsulation format is shown as follows: 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Source Port = Entropy | Dest Port = TBD1 | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | UDP Length | UDP Checksum | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | | 148 ~ ESP Packet ~ 149 | | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 Figure 1: ESP-in-UDP Encapsulation Format 153 Source Port of UDP: 155 This field contains a 16-bit entropy value that is generated by 156 the encapsulator to uniquely identify a flow. What constitutes 157 a flow is locally determined by the encapsulator and therefore 158 is outside the scope of this document. What algorithm is 159 actually used by the encapsulator to generate an entropy value 160 is outside the scope of this document. 162 In case the tunnel does not need entropy, this field of all 163 packets belonging to a given flow SHOULD be set to a randomly 164 selected constant value so as to avoid packet reordering. 166 To ensure that the source port number is always in the range 167 49152 to 65535 (Note that those ports less than 49152 are 168 reserved by IANA to identify specific applications/protocols) 169 which may be required in some cases, instead of calculating a 170 16-bit hash, the encapsulator SHOULD calculate a 14-bit hash 171 and use those 14 bits as the least significant bits of the 172 source port field while the most significant two bits SHOULD be 173 set to binary 11. That still conveys 14 bits of entropy 174 information which would be enough as well in practice. 176 Destination Port of UDP: 178 This field is set to a value (TBD1) allocated by IANA to 179 indicate that the UDP tunnel payload is an ESP packet. 181 UDP Length: 183 The usage of this field is in accordance with the current UDP 184 specification [RFC0768]. 186 UDP Checksum: 188 For IPv4 UDP encapsulation, this field is RECOMMENDED to be set 189 to zero for performance or implementation reasons because the 190 IPv4 header includes a checksum and use of the UDP checksum is 191 optional with IPv4. For IPv6 UDP encapsulation, the IPv6 192 header does not include a checksum, so this field MUST contain 193 a UDP checksum that MUST be used as specified in [RFC0768] and 194 [RFC2460] unless one of the exceptions that allows use of UDP 195 zero-checksum mode (as specified in [RFC6935]) applies. 197 ESP Packet: 199 This field contains one ESP packet. 201 4. Processing Procedures 203 This ESP-in-UDP encapsulation causes ESP [RFC2406] packets to be 204 forwarded across IP WAN via "UDP tunnels". When performing ESP-in- 205 UDP encapsulation by an IPsec VPN gateway, ordinary ESP encapsulation 206 procedure is performed and then a formatted UDP header is inserted 207 between ESP header and IP header. The Source Port field of the UDP 208 header is filled with an entropy value which is generated by the 209 IPsec VPN gateway. Upon receiving these UDP encapsulated packets, 210 remote IPsec VPN gateway MUST decapsulate these packets by removing 211 the UDP header and then perform ordinary ESP decapsulation procedure 212 consequently. 214 Similar to all other IP-based tunneling technologies, ESP-in-UDP 215 encapsulation introduces overheads and reduces the effective Maximum 216 Transmission Unit (MTU) size. ESP-in-UDP encapsulation may also 217 impact Time-to-Live (TTL) or Hop Count (HC) and Differentiated 218 Services (DSCP). Hence, ESP-in-UDP MUST follow the corresponding 219 procedures defined in [RFC2003]. 221 Encapsulators MUST NOT fragment ESP packet, and when the outer IP 222 header is IPv4, encapsulators MUST set the DF bit in the outer IPv4 223 header. It is strongly RECOMMENDED that IP transit core be 224 configured to carry an MTU at least large enough to accommodate the 225 added encapsulation headers. Meanwhile, it is strongly RECOMMENDED 226 that Path MTU Discovery [RFC1191] [RFC1981] or Packetization Layer 227 Path MTU Discovery (PLPMTUD) [RFC4821] is used to prevent or minimize 228 fragmentation. 230 5. Congestion Considerations 232 TBD. 234 6. Applicability Statements 236 TBD. 238 7. Acknowledgements 240 8. IANA Considerations 242 One UDP destination port number indicating ESP needs to be allocated 243 by IANA: 245 Service Name: ESP-in-UDP Transport Protocol(s):UDP 246 Assignee: IESG 247 Contact: IETF Chair . 248 Description: Encapsulate ESP packets in UDP tunnels. 249 Reference: This document. 250 Port Number: TBD1 -- To be assigned by IANA. 252 9. Security Considerations 254 TBD. 256 10. References 258 10.1. Normative References 260 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 261 DOI 10.17487/RFC0768, August 1980, 262 . 264 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 265 DOI 10.17487/RFC1191, November 1990, 266 . 268 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 269 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 270 1996, . 272 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 273 DOI 10.17487/RFC2003, October 1996, 274 . 276 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 277 Requirement Levels", BCP 14, RFC 2119, 278 DOI 10.17487/RFC2119, March 1997, 279 . 281 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 282 Internet Protocol", RFC 2401, DOI 10.17487/RFC2401, 283 November 1998, . 285 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 286 Payload (ESP)", RFC 2406, DOI 10.17487/RFC2406, November 287 1998, . 289 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 290 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 291 December 1998, . 293 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 294 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 295 . 297 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 298 for Equal Cost Multipath Routing and Link Aggregation in 299 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 300 . 302 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 303 UDP Checksums for Tunneled Packets", RFC 6935, 304 DOI 10.17487/RFC6935, April 2013, 305 . 307 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 308 for the Use of IPv6 UDP Datagrams with Zero Checksums", 309 RFC 6936, DOI 10.17487/RFC6936, April 2013, 310 . 312 10.2. Informative References 314 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 315 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 316 RFC 3948, DOI 10.17487/RFC3948, January 2005, 317 . 319 Authors' Addresses 320 Xiaohu Xu 321 Alibaba, Inc 323 Email: xiaohu.xxh@alibaba-inc.com 325 Shraddha Hegde 326 Juniper 328 Email: shraddha@juniper.net 330 Boris Pismenny 331 Nvidia 333 Email: borisp@nvidia.com 335 Dacheng Zhang 336 Huawei 338 Email: dacheng.zhang@huawei.com 340 Liang Xia 341 Huawei 343 Email: frank.xialiang@huawei.com