idnits 2.17.00 (12 Aug 2021) /tmp/idnits57411/draft-xu-ipsecme-esp-in-udp-lb-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' scope of this document. In case the tunnel does not need' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 7. IANA Considerations' ) ** There are 6 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC2401], [RFC7510], [RFC6830], [RFC2460], [RFC2119], [RFC0768], [RFC2406], [RFC768], [RFC7348], [RFC3948], [RFC6935], [RFC6936], [RFC6438]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2016) is 2028 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) -- Missing reference section? 'RFC2119' on line 249 looks like a reference -- Missing reference section? 'RFC6830' on line 109 looks like a reference -- Missing reference section? 'RFC7510' on line 274 looks like a reference -- Missing reference section? 'RFC7348' on line 109 looks like a reference -- Missing reference section? 'RFC6438' on line 120 looks like a reference -- Missing reference section? 'RFC6936' on line 270 looks like a reference -- Missing reference section? 'RFC3948' on line 266 looks like a reference -- Missing reference section? 'RFC2401' on line 257 looks like a reference -- Missing reference section? 'RFC2406' on line 260 looks like a reference -- Missing reference section? 'RFC768' on line 254 looks like a reference -- Missing reference section? 'RFC0768' on line 206 looks like a reference -- Missing reference section? 'RFC2460' on line 206 looks like a reference -- Missing reference section? 'RFC6935' on line 263 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group X. Xu 2 Internet Draft D. Zhang 3 Category: Standard Track L.Xia 4 Huawei 6 Expires: December 2016 October 31, 2016 8 Encapsulating IPsec ESP in UDP for Load-balancing 10 draft-xu-ipsecme-esp-in-udp-lb-00 12 Abstract 14 IPsec Virtual Private Network (VPN) is widely used by enterprises to 15 interconnect their geographical dispersed branch office locations 16 across IP Wide Area Network (WAN). To fully utilize the bandwidth 17 available in IP WAN, load balancing of traffic between different 18 IPsec VPN sites over Equal Cost Multi-Path (ECMP) and/or Link 19 Aggregation Group (LAG) within IP WAN is attractive to those 20 enterprises deploying IPsec VPN solutions. This document defines a 21 method to encapsulate IPsec Encapsulating Security Payload (ESP) 22 packets inside UDP packets for improving load-balancing of IPsec 23 tunneled traffic. In addition, this encapsulation is also applicable 24 to some special multi-tenant data center network environment where 25 the overlay tunnels need to be secured. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other documents 39 at any time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 Internet-Draft Encapsulating ESP in UDP for Load-balancing October 49 2016 51 This Internet-Draft will expire on December 31, 2016. 53 Copyright Notice 55 Copyright (c) 2013 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with 63 respect to this document. Code Components extracted from this 64 document must include Simplified BSD License text as described in 65 Section 4.e of the Trust Legal Provisions and are provided without 66 warranty as described in the Simplified BSD License. 68 Conventions used in this document 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in RFC-2119 [RFC2119]. 74 Table of Contents 76 1. Introduction ................................................ 3 77 2. Terminology ................................................. 4 78 3. Encapsulating ESP in UDP .................................... 4 79 4. Encapsulation and Decapsulation Procedures .................. 5 80 5. Congestion Considerations ................................... 5 81 6. Security Considerations ..................................... 5 82 7. IANA Considerations ......................................... 6 83 8. Acknowledgements ............................................ 6 84 9. References .................................................. 6 85 9.1. Normative References ................................... 6 86 9.2. Informative References ................................. 6 87 Authors' Addresses ............................................. 7 88 Internet-Draft Encapsulating ESP in UDP for Load-balancing October 89 2016 91 1. Introduction 93 IPsec Virtual Private Network (VPN) is widely used by enterprises to 94 interconnect their geographical dispersed branch office locations 95 across IP Wide Area Network (WAN). To fully utilize the bandwidth 96 available in IP WAN, load balancing of traffic between different 97 IPsec VPN sites over Equal Cost Multi-Path (ECMP) and/or Link 98 Aggregation Group (LAG) within IP WAN is much attractive to those 99 enterprises that deploy IPsec VPN solutions. Since most existing 100 core routers within IP WAN can already support balancing IP traffic 101 flows based on the hash of the five-tuple of UDP packets, by 102 encapsulating IPsec Encapsulating Security Payload (ESP) packets 103 inside UDP packets with the UDP source port being used as an entropy 104 field, it will enable existing core routers to perform efficient 105 load-balancing of the IPsec tunneled traffic without requiring any 106 change to them. Therefore, this specification defines a method of 107 encapsulating IPsec ESP packets inside UDP packets for improving 108 load-balancing of IPsec tunneled traffic. This is similar to why 109 LISP [RFC6830], MPLS-in-UDP [RFC7510] and VXLAN [RFC7348] use UDP 110 encapsulation. 112 In addition, this encapsulation is also applicable to some special 113 multi-tenant data center network environment where the overlay 114 tunnels need to be secured while the UDP-based ECMP capability is 115 desired as well (see [draft-ietf-nvo3-use-case]). 117 Encapsulating ESP in UDP, as defined in this document, can be used 118 in both IPv4 and IPv6 scenarios. IPv6 flow label has been proposed 119 as an entropy field for load balancing in IPv6 network environment 120 [RFC6438]. However, as stated in [RFC6936], the end-to-end use of 121 flow labels for load balancing is a long-term solution and therefore 122 the use of load balancing using the transport header fields would 123 continue until any widespread deployment is finally achieved. As 124 such, IP-in-UDP encapsulation would still have a practical 125 application value in the IPv6 networks during this transition 126 timeframe. 128 Note that the difference between the ESP-in-UDP encapsulation as 129 proposed in this document and the ESP-in-UDP encapsulation as 130 described in [RFC3948] is that the former uses the UDP tunnel for 131 load-balancing improvement purpose and therefore the source port is 132 used as an entropy field while the latter uses the UDP tunnel for 133 NAT traverse purpose and therefore the source port is set to a 134 constant value (i.e., 4500). In addition, the document only 135 discusses about the tunnel mode ESP encapsulation. 137 Internet-Draft Encapsulating ESP in UDP for Load-balancing October 138 2016 140 2. Terminology 142 This memo makes use of the terms defined in [RFC2401] and [RFC2406]. 144 3. Encapsulating ESP in UDP 146 ESP-in-UDP encapsulation format is shown as follows: 148 0 1 2 3 149 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 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Source Port = entropy | Dest Port = ESP | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | UDP Length | UDP Checksum | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | | 156 ~ ESP Packet ~ 157 | | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Source Port of UDP 162 This field contains a 16-bit entropy value that is 163 generated by the encapsulator to uniquely identify a 164 flow. What constitutes a flow is locally determined by 165 the encapsulator and therefore is outside the scope of 166 this document. What algorithm is actually used by the 167 encapsulator to generate an entropy value is outside the 168 scope of this document. In case the tunnel does not need 169 entropy, this field of all packets belonging to a given 170 flow SHOULD be set to a randomly selected constant value 171 so as to avoid packet reordering. 173 To ensure that the source port number is always in the 174 range 49152 to 65535 (Note that those ports less than 175 49152 are reserved by IANA to identify specific 176 applications/protocols) which may be required in some 177 cases, instead of calculating a 16-bit hash, the 178 encapsulator SHOULD calculate a 14-bit hash and use 179 those 14 bits as the least significant bits of the 180 source port field while the most significant two bits 181 SHOULD be set to binary 11. That still conveys 14 bits 182 of entropy information which would be enough as well in 183 practice. 185 Destination Port of UDP 187 Internet-Draft Encapsulating ESP in UDP for Load-balancing October 188 2016 190 This field is set to a value (TBD) indicating the 191 encapsulated payload in the UDP header is an ESP packet. 193 UDP Length 195 The usage of this field is in accordance with the 196 current UDP specification [RFC768]. 198 UDP Checksum 200 For IPv4 UDP encapsulation, this field is RECOMMENDED to 201 be set to zero for performance or implementation reasons 202 because the IPv4 header includes a checksum and use of 203 the UDP checksum is optional with IPv4. For IPv6 UDP 204 encapsulation, the IPv6 header does not include a 205 checksum, so this field MUST contain a UDP checksum that 206 MUST be used as specified in [RFC0768] and [RFC2460] 207 unless one of the exceptions that allows use of UDP 208 zero-checksum mode (as specified in [RFC6935]) applies. 210 4. Encapsulation and Decapsulation Procedures 212 This ESP-in-UDP encapsulation causes ESP [RFC2406] packets to be 213 forwarded across IP WAN via "UDP tunnels". When performing ESP-in- 214 UDP encapsulation by an IPsec VPN gateway, ordinary ESP 215 encapsulation procedure is performed and then a formatted UDP header 216 is inserted between ESP header and IP header. The Source Port field 217 of the UDP header is filled with an entropy value which is generated 218 by the IPsec VPN gateway. 220 Upon receiving these UDP encapsulated packets, remote IPsec VPN 221 gateway MUST decapsulate these packets by removing the UDP header 222 and then perform ordinary ESP decapsulation procedure consequently. 224 5. Congestion Considerations 226 TBD 228 6. Security Considerations 230 TBD. 232 Internet-Draft Encapsulating ESP in UDP for Load-balancing October 233 2016 235 7. IANA Considerations 237 A new UDP destination port number which indicates the encapsulated 238 payload following the UDP header is an ESP packet needs to be 239 assigned by IANA. 241 8. Acknowledgements 243 Thanks to. 245 9. References 247 9.1. Normative References 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, March 1997. 252 9.2. Informative References 254 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 255 August 1980. 257 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 258 Internet Protocol", RFC 2401, November 1998. 260 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 261 Payload (ESP)", RFC 2406, November 1998. 263 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "UDP 264 Checksums for Tunneled Packets", RFC6935, Feburary 2013. 266 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 267 Stenberg, "UDP Encapsulation of IPsec Packets", RFC 3948, 268 January 2005. 270 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 271 for the use of IPv6 UDP Datagrams with Zero Checksums", 272 RFC6936, Feburary 2013. 274 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 275 "Encapsulating MPLS in UDP", RFC 7510, 276 DOI 10.17487/RFC7510, April 2015, 277 . 279 Internet-Draft Encapsulating ESP in UDP for Load-balancing October 280 2016 282 Authors' Addresses 284 Xiaohu Xu 285 Huawei Technologies, 286 Beijing, China 287 Phone: +86-10-60610041 288 Email: xuxiaohu@huawei.com 290 Dacheng Zhang 291 Huawei Technologies, 292 Beijing, China 293 Phone: +86-13621142434 294 Email: dacheng.zhang@huawei.com 296 Liang Xia 297 Huawei Technologies, 298 Email: frank.xialiang@huawei.com