idnits 2.17.1 draft-xu-ipsecme-esp-in-udp-lb-08.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 (July 12, 2021) is 1012 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: January 13, 2022 Juniper 6 B. Pismenny 7 Nvidia 8 D. Zhang 9 L. Xia 10 Huawei 11 July 12, 2021 13 Encapsulating IPsec ESP in UDP for Load-balancing 14 draft-xu-ipsecme-esp-in-udp-lb-08 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 networks and data center interconnect WANs so as to meet 24 the security and compliance requirements, especially in financial 25 cloud and governmental cloud environments. To fully utilize the 26 bandwidth available in the data center network, the data center 27 interconnect WAN or the Internet, load balancing of IPsec traffic 28 over Equal Cost Multi-Path (ECMP) and/or Link Aggregation Group (LAG) 29 is much attractive to those enterprises and cloud providers. This 30 document defines a method to encapsulate IPsec Encapsulating Security 31 Payload (ESP) packets over UDP tunnels for improving load-balancing 32 of IPsec ESP traffic. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 13, 2022. 50 Copyright Notice 52 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . 4 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 networks and data center interconnect WANs so as to meet 90 the security and compliance requirements, especially in financial 91 cloud and governmental cloud environments. To fully utilize the 92 bandwidth available in the WAN or the Internet, load balancing of 93 IPsec traffic over Equal Cost Multi-Path (ECMP) and/or Link 94 Aggregation Group (LAG) is much attractive to those enterprises and 95 cloud providers. Although the ESP SPI field within the IPsec packets 96 can be used as the load-balancing key, but it cannot be used by 97 legacy switches and routers. 99 Since most existing switches within data center networks and core 100 routers within IP WAN or the Internet can already support balancing 101 IP traffic flows based on the hash of the five-tuple of UDP packets, 102 by encapsulating IPsec Encapsulating Security Payload (ESP) packets 103 over UDP tunnels with the UDP source port being used as an entropy 104 field, it will enable existing data center switches and core routers 105 to perform efficient load-balancing of the IPsec ESP traffic without 106 requiring any change to them. Therefore, this specification defines 107 a method of encapsulating IPsec ESP packets over UDP tunnels for 108 improving load-balancing of IPsec ESP traffic. 110 Encapsulating ESP in UDP, as defined in this document, can be used in 111 both IPv4 and IPv6 networks. IPv6 flow label has been proposed as an 112 entropy field for load balancing in IPv6 network environment 113 [RFC6438]. However, as stated in [RFC6936], the end-to-end use of 114 flow labels for load balancing is a long-term solution and therefore 115 the use of load balancing using the transport header fields would 116 continue until any widespread deployment is finally achieved. As 117 such, ESP-in-UDP encapsulation would still have a practical 118 application value in the IPv6 networks during this transition 119 timeframe. 121 Note that the difference between the ESP-in-UDP encapsulation as 122 proposed in this document and the ESP-in-UDP encapsulation as 123 described in [RFC3948] is that the former uses the UDP tunnel for 124 load-balancing improvement purpose and therefore the source port is 125 used as an entropy field while the latter uses the UDP tunnel for NAT 126 traversal purpose and therefore the source port is set to a constant 127 value (i.e., 4500). In addition, the ESP-in-UDP encapsulation as 128 described in this document is applicable to both the tunnel mode ESP 129 encapsulation and the transport mode ESP encapsulation. 131 1.1. Requirements Language 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [RFC2119]. 137 2. Terminology 139 This memo makes use of the terms defined in [RFC2401]and [RFC2406]. 141 3. Encapsulation in UDP 143 ESP-in-UDP encapsulation format is shown as follows: 145 0 1 2 3 146 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 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Source Port = Entropy | Dest Port = TBD1 | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | UDP Length | UDP Checksum | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | | 153 ~ ESP Packet ~ 154 | | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 Figure 1: ESP-in-UDP Encapsulation Format 158 Source Port of UDP: 160 This field contains a 16-bit entropy value that is generated by 161 the encapsulator to uniquely identify a flow. What constitutes 162 a flow is locally determined by the encapsulator and therefore 163 is outside the scope of this document. What algorithm is 164 actually used by the encapsulator to generate an entropy value 165 is outside the scope of this document. 167 In case the tunnel does not need entropy, this field of all 168 packets belonging to a given flow SHOULD be set to a randomly 169 selected constant value so as to avoid packet reordering. 171 To ensure that the source port number is always in the range 172 49152 to 65535 (Note ports less than 49152 are reserved by IANA 173 to identify specific applications/protocols) which may be 174 required in some cases, instead of calculating a 16-bit hash, 175 the encapsulator SHOULD calculate a 14-bit hash and use those 176 14 bits as the least significant bits of the source port field 177 while the most significant two bits SHOULD be set to binary 11. 178 That still conveys 14 bits of entropy information which would 179 be enough as well in practice. 181 Destination Port of UDP: 183 This field is set to a value (TBD1) allocated by IANA to 184 indicate that the UDP tunnel payload is an ESP packet. 186 UDP Length: 188 The usage of this field is in accordance with the current UDP 189 specification [RFC0768]. 191 UDP Checksum: 193 For IPv4 UDP encapsulation, this field is RECOMMENDED to be set 194 to zero for performance or implementation reasons because the 195 IPv4 header includes a checksum and use of the UDP checksum is 196 optional with IPv4. For IPv6 UDP encapsulation, the IPv6 197 header does not include a checksum, so this field MUST contain 198 a UDP checksum that MUST be used as specified in [RFC0768] and 199 [RFC2460] unless one of the exceptions that allows use of UDP 200 zero-checksum mode (as specified in [RFC6935]) applies. 202 ESP Packet: 204 This field contains one ESP packet. 206 4. Processing Procedures 208 This ESP-in-UDP encapsulation causes ESP [RFC2406] packets to be 209 forwarded across IP WAN via "UDP tunnels". When performing ESP-in- 210 UDP encapsulation by an IPsec VPN gateway, ordinary ESP encapsulation 211 procedure is performed and then a formatted UDP header is inserted 212 between ESP header and IP header. The Source Port field of the UDP 213 header is filled with an entropy value which is generated by the 214 IPsec VPN gateway. Upon receiving these UDP encapsulated packets, 215 remote IPsec VPN gateway MUST decapsulate these packets by removing 216 the UDP header and then perform ordinary ESP decapsulation procedure 217 consequently. 219 Similar to all other IP-based tunneling technologies, ESP-in-UDP 220 encapsulation introduces overheads and reduces the effective Maximum 221 Transmission Unit (MTU) size. ESP-in-UDP encapsulation may also 222 impact Time-to-Live (TTL) or Hop Count (HC) and Differentiated 223 Services (DSCP). Hence, ESP-in-UDP MUST follow the corresponding 224 procedures defined in [RFC2003]. 226 Encapsulators MUST NOT fragment ESP packet, and when the outer IP 227 header is IPv4, encapsulators MUST set the DF bit in the outer IPv4 228 header. It is strongly RECOMMENDED that IP transit core be 229 configured to carry an MTU at least large enough to accommodate the 230 added encapsulation headers. Meanwhile, it is strongly RECOMMENDED 231 that Path MTU Discovery [RFC1191] [RFC1981] or Packetization Layer 232 Path MTU Discovery (PLPMTUD) [RFC4821] is used to prevent or minimize 233 fragmentation. 235 5. Congestion Considerations 237 TBD. 239 6. Applicability Statements 241 TBD. 243 7. Acknowledgements 245 8. IANA Considerations 247 One UDP destination port number indicating ESP needs to be allocated 248 by IANA: 250 Service Name: ESP-in-UDP Transport Protocol(s):UDP 251 Assignee: IESG 252 Contact: IETF Chair . 253 Description: Encapsulate ESP packets in UDP tunnels. 254 Reference: This document. 255 Port Number: TBD1 -- To be assigned by IANA. 257 9. Security Considerations 259 TBD. 261 10. References 263 10.1. Normative References 265 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 266 DOI 10.17487/RFC0768, August 1980, 267 . 269 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 270 DOI 10.17487/RFC1191, November 1990, 271 . 273 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 274 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 275 1996, . 277 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 278 DOI 10.17487/RFC2003, October 1996, 279 . 281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 282 Requirement Levels", BCP 14, RFC 2119, 283 DOI 10.17487/RFC2119, March 1997, 284 . 286 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 287 Internet Protocol", RFC 2401, DOI 10.17487/RFC2401, 288 November 1998, . 290 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 291 Payload (ESP)", RFC 2406, DOI 10.17487/RFC2406, November 292 1998, . 294 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 295 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 296 December 1998, . 298 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 299 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 300 . 302 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 303 for Equal Cost Multipath Routing and Link Aggregation in 304 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 305 . 307 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 308 UDP Checksums for Tunneled Packets", RFC 6935, 309 DOI 10.17487/RFC6935, April 2013, 310 . 312 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 313 for the Use of IPv6 UDP Datagrams with Zero Checksums", 314 RFC 6936, DOI 10.17487/RFC6936, April 2013, 315 . 317 10.2. Informative References 319 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 320 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 321 RFC 3948, DOI 10.17487/RFC3948, January 2005, 322 . 324 Authors' Addresses 325 Xiaohu Xu 326 Alibaba, Inc 328 Email: 13910161692@qq.com 330 Shraddha Hegde 331 Juniper 333 Email: shraddha@juniper.net 335 Boris Pismenny 336 Nvidia 338 Email: borisp@nvidia.com 340 Dacheng Zhang 341 Huawei 343 Email: dacheng.zhang@huawei.com 345 Liang Xia 346 Huawei 348 Email: frank.xialiang@huawei.com