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