idnits 2.17.1 draft-xu-ipsecme-esp-in-udp-lb-09.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 (7 March 2022) is 778 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.X. Xu 3 Internet-Draft Capital Online 4 Intended status: Standards Track S.H. Hegde 5 Expires: 8 September 2022 Juniper 6 B.P. Bottorff 7 HPE 8 B.P. Pismenny 9 Nvidia 10 D.Z. Zhang 11 L.X. Xia 12 Huawei 13 M.P. Puttaswamy 14 Juniper Networks 15 7 March 2022 17 Encapsulating IPsec ESP in UDP for Load-balancing 18 draft-xu-ipsecme-esp-in-udp-lb-09 20 Abstract 22 IPsec Virtual Private Network (VPN) is widely used by enterprises to 23 interconnect their geographical dispersed branch office locations 24 across the Wide Area Network (WAN) or the Internet, especially in the 25 Software-Defined-WAN (SD-WAN) era. In addition, IPsec is also 26 increasingly used by cloud providers to encrypt IP traffic traversing 27 data center networks and data center interconnect WANs so as to meet 28 the security and compliance requirements, especially in financial 29 cloud and governmental cloud environments. To fully utilize the 30 bandwidth available in the data center network, the data center 31 interconnect WAN or the Internet, load balancing of IPsec traffic 32 over Equal Cost Multi-Path (ECMP) and/or Link Aggregation Group (LAG) 33 is much attractive to those enterprises and cloud providers. This 34 document defines a method to encapsulate IPsec Encapsulating Security 35 Payload (ESP) packets over UDP tunnels for improving load-balancing 36 of IPsec ESP traffic. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on 8 September 2022. 55 Copyright Notice 57 Copyright (c) 2022 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 62 license-info) in effect on the date of publication of this document. 63 Please review these documents carefully, as they describe your rights 64 and restrictions with respect to this document. Code Components 65 extracted from this document must include Revised BSD License text as 66 described in Section 4.e of the Trust Legal Provisions and are 67 provided without warranty as described in the Revised BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. Encapsulation in UDP . . . . . . . . . . . . . . . . . . . . 4 75 4. Processing Procedures . . . . . . . . . . . . . . . . . . . . 5 76 5. Congestion Considerations . . . . . . . . . . . . . . . . . . 6 77 6. Applicability Statements . . . . . . . . . . . . . . . . . . 6 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 83 10.2. Informative References . . . . . . . . . . . . . . . . . 7 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 86 1. Introduction 88 IPsec Virtual Private Network (VPN) is widely used by enterprises to 89 interconnect their geographical dispersed branch office locations 90 across the Wide Area Network (WAN) or the Internet, especially in the 91 Software-Defined-WAN (SD-WAN) era. In addition, IPsec is also 92 increasingly used by cloud providers to encrypt IP traffic traversing 93 data center networks and data center interconnect WANs so as to meet 94 the security and compliance requirements, especially in financial 95 cloud and governmental cloud environments. To fully utilize the 96 bandwidth available in the WAN or the Internet, load balancing of 97 IPsec traffic over Equal Cost Multi-Path (ECMP) and/or Link 98 Aggregation Group (LAG) is much attractive to those enterprises and 99 cloud providers. Although the ESP SPI field within the IPsec packets 100 can be used as the load-balancing key, but it cannot be used by 101 legacy switches and routers. 103 Since most existing switches within data center networks and core 104 routers within IP WAN or the Internet can already support balancing 105 IP traffic flows based on the hash of the five-tuple of UDP packets, 106 by encapsulating IPsec Encapsulating Security Payload (ESP) packets 107 over UDP tunnels with the UDP source port being used as an entropy 108 field, it will enable existing data center switches and core routers 109 to perform efficient load-balancing of the IPsec ESP traffic without 110 requiring any change to them. Therefore, this specification defines 111 a method of encapsulating IPsec ESP packets over UDP tunnels for 112 improving load-balancing of IPsec ESP traffic. 114 Encapsulating ESP in UDP, as defined in this document, can be used in 115 both IPv4 and IPv6 networks. IPv6 flow label has been proposed as an 116 entropy field for load balancing in IPv6 network environment 117 [RFC6438]. However, as stated in [RFC6936], the end-to-end use of 118 flow labels for load balancing is a long-term solution and therefore 119 the use of load balancing using the transport header fields would 120 continue until any widespread deployment is finally achieved. As 121 such, ESP-in-UDP encapsulation would still have a practical 122 application value in the IPv6 networks during this transition 123 timeframe. 125 Note that the difference between the ESP-in-UDP encapsulation as 126 proposed in this document and the ESP-in-UDP encapsulation as 127 described in [RFC3948] is that the former uses the UDP tunnel for 128 load-balancing improvement purpose and therefore the source port is 129 used as an entropy field while the latter uses the UDP tunnel for NAT 130 traversal purpose and therefore the source port is set to a constant 131 value (i.e., 4500). In addition, the ESP-in-UDP encapsulation as 132 described in this document is applicable to both the tunnel mode ESP 133 encapsulation and the transport mode ESP encapsulation. 135 There are use cases that do not use NAT traversal such as multi-cloud 136 WAN. ESP-in-UDP encapsulation along with NAT traversal is out of 137 scope in this document. 139 1.1. Requirements Language 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [RFC2119]. 145 2. Terminology 147 This memo makes use of the terms defined in [RFC2401]and [RFC2406]. 149 3. Encapsulation in UDP 151 ESP-in-UDP encapsulation format is shown as follows: 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Source Port = Entropy | Dest Port = TBD1 | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | UDP Length | UDP Checksum | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | | 161 ~ ESP Packet ~ 162 | | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 Figure 1: ESP-in-UDP Encapsulation Format 166 Source Port of UDP: 168 This field contains a 16-bit entropy value that is generated by 169 the encapsulator to uniquely identify a flow. What constitutes 170 a flow is locally determined by the encapsulator and therefore 171 is outside the scope of this document. What algorithm is 172 actually used by the encapsulator to generate an entropy value 173 is outside the scope of this document. 175 In case the tunnel does not need entropy, this field of all 176 packets belonging to a given flow SHOULD be set to a randomly 177 selected constant value so as to avoid packet reordering. 179 In cases where single IPSec SA is used to protect different 180 flows, even though each flow gets a seperate source port, ESP 181 assigns continuous sequence number for each of them in the 182 order of processing. So, packets travelling on fast path may 183 reach the destination faster and slow path packets might get 184 dropped because of out of window sequence number. In such 185 cases, it is advisable to configure large replay window. 187 To ensure that the source port number is always in the range 188 49152 to 65535 (Note ports less than 49152 are reserved by IANA 189 to identify specific applications/protocols) which may be 190 required in some cases, instead of calculating a 16-bit hash, 191 the encapsulator SHOULD calculate a 14-bit hash and use those 192 14 bits as the least significant bits of the source port field 193 while the most significant two bits SHOULD be set to binary 11. 194 That still conveys 14 bits of entropy information which would 195 be enough as well in practice. 197 Destination Port of UDP: 199 This field is set to a value (TBD1) allocated by IANA to 200 indicate that the UDP tunnel payload is an ESP packet. 202 UDP Length: 204 The usage of this field is in accordance with the current UDP 205 specification [RFC0768]. 207 UDP Checksum: 209 For IPv4 UDP encapsulation, this field is RECOMMENDED to be set 210 to zero for performance or implementation reasons because the 211 IPv4 header includes a checksum and use of the UDP checksum is 212 optional with IPv4. For IPv6 UDP encapsulation, the IPv6 213 header does not include a checksum, so this field MUST contain 214 a UDP checksum that MUST be used as specified in [RFC0768] and 215 [RFC2460] unless one of the exceptions that allows use of UDP 216 zero-checksum mode (as specified in [RFC6935]) applies. 218 ESP Packet: 220 This field contains one ESP packet. 222 4. Processing Procedures 224 This ESP-in-UDP encapsulation causes ESP [RFC2406] packets to be 225 forwarded across IP WAN via "UDP tunnels". When performing ESP-in- 226 UDP encapsulation by an IPsec VPN gateway, ordinary ESP encapsulation 227 procedure is performed and then a formatted UDP header is inserted 228 between ESP header and IP header. The Source Port field of the UDP 229 header is filled with an entropy value which is generated by the 230 IPsec VPN gateway. Upon receiving these UDP encapsulated packets, 231 remote IPsec VPN gateway MUST decapsulate these packets by removing 232 the UDP header and then perform ordinary ESP decapsulation procedure 233 consequently. 235 Similar to all other IP-based tunneling technologies, ESP-in-UDP 236 encapsulation introduces overheads and reduces the effective Maximum 237 Transmission Unit (MTU) size. ESP-in-UDP encapsulation may also 238 impact Time-to-Live (TTL) or Hop Count (HC) and Differentiated 239 Services (DSCP). Hence, ESP-in-UDP MUST follow the corresponding 240 procedures defined in [RFC2003]. 242 Encapsulators MUST NOT fragment ESP packet, and when the outer IP 243 header is IPv4, encapsulators MUST set the DF bit in the outer IPv4 244 header. It is strongly RECOMMENDED that IP transit core be 245 configured to carry an MTU at least large enough to accommodate the 246 added encapsulation headers. Meanwhile, it is strongly RECOMMENDED 247 that Path MTU Discovery [RFC1191] [RFC1981] or Packetization Layer 248 Path MTU Discovery (PLPMTUD) [RFC4821] is used to prevent or minimize 249 fragmentation. 251 5. Congestion Considerations 253 TBD. 255 6. Applicability Statements 257 TBD. 259 7. Acknowledgements 261 8. IANA Considerations 263 One UDP destination port number indicating ESP needs to be allocated 264 by IANA: 266 Service Name: ESP-in-UDP Transport Protocol(s):UDP 267 Assignee: IESG 268 Contact: IETF Chair . 269 Description: Encapsulate ESP packets in UDP tunnels. 270 Reference: This document. 271 Port Number: TBD1 -- To be assigned by IANA. 273 9. Security Considerations 275 TBD. 277 10. References 279 10.1. Normative References 281 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 282 DOI 10.17487/RFC0768, August 1980, 283 . 285 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 286 DOI 10.17487/RFC1191, November 1990, 287 . 289 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 290 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 291 1996, . 293 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 294 DOI 10.17487/RFC2003, October 1996, 295 . 297 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 298 Requirement Levels", BCP 14, RFC 2119, 299 DOI 10.17487/RFC2119, March 1997, 300 . 302 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 303 Internet Protocol", RFC 2401, DOI 10.17487/RFC2401, 304 November 1998, . 306 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 307 Payload (ESP)", RFC 2406, DOI 10.17487/RFC2406, November 308 1998, . 310 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 311 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 312 December 1998, . 314 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 315 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 316 . 318 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 319 for Equal Cost Multipath Routing and Link Aggregation in 320 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 321 . 323 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 324 UDP Checksums for Tunneled Packets", RFC 6935, 325 DOI 10.17487/RFC6935, April 2013, 326 . 328 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 329 for the Use of IPv6 UDP Datagrams with Zero Checksums", 330 RFC 6936, DOI 10.17487/RFC6936, April 2013, 331 . 333 10.2. Informative References 335 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 336 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 337 RFC 3948, DOI 10.17487/RFC3948, January 2005, 338 . 340 Authors' Addresses 342 Xiaohu Xu 343 Capital Online 344 Email: 13910161692@qq.com 346 Shraddha Hegde 347 Juniper 348 Email: shraddha@juniper.net 350 Bottorff, Paul 351 HPE 352 Email: paul.bottorff@hpe.com 354 Boris Pismenny 355 Nvidia 356 Email: borisp@nvidia.com 358 Dacheng Zhang 359 Huawei 360 Email: dacheng.zhang@huawei.com 362 Liang Xia 363 Huawei 364 Email: frank.xialiang@huawei.com 366 Mahendra Puttaswamy 367 Juniper Networks 368 Email: mpmahendra@juniper.com