draft-xu-ipsecme-esp-in-udp-lb-11.txt   draft-xu-ipsecme-esp-in-udp-lb-12.txt 
Network Working Group X. Xu Network Working Group X. Xu
Internet-Draft China Mobile Internet-Draft China Mobile
Intended status: Standards Track S. Hegde Intended status: Standards Track S. Hegde
Expires: 15 March 2024 Juniper Networks Expires: 27 September 2024 Juniper Networks
B. Pismenny B. Pismenny
Nvidia Nvidia
D. Zhang D. Zhang
L. Xia L. Xia
Huawei Huawei
M. Puttaswamy M. Puttaswamy
Juniper Networks Juniper Networks
12 September 2023 26 March 2024
Encapsulating IPsec ESP in UDP for Load-balancing Encapsulating IPsec ESP in UDP for Load-balancing
draft-xu-ipsecme-esp-in-udp-lb-11 draft-xu-ipsecme-esp-in-udp-lb-12
Abstract Abstract
IPsec Virtual Private Network (VPN) is widely used by enterprises to IPsec Virtual Private Network (VPN) is widely used by enterprises to
interconnect their geographical dispersed branch office locations interconnect their geographical dispersed branch office locations
across the Wide Area Network (WAN) or the Internet, especially in the across the Wide Area Network (WAN) or the Internet, especially in the
Software-Defined-WAN (SD-WAN) era. In addition, IPsec is also Software-Defined-WAN (SD-WAN) era. In addition, IPsec is also
increasingly used by cloud providers to encrypt IP traffic traversing increasingly used by cloud providers to encrypt IP traffic traversing
data center networks and data center interconnect WANs so as to meet data center networks and data center interconnect WANs so as to meet
the security and compliance requirements, especially in financial the security and compliance requirements, especially in financial
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 15 March 2024. This Internet-Draft will expire on 27 September 2024.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
skipping to change at page 2, line 38 skipping to change at page 2, line 38
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Encapsulation in UDP . . . . . . . . . . . . . . . . . . . . 4 3. Encapsulation in UDP . . . . . . . . . . . . . . . . . . . . 4
4. Processing Procedures . . . . . . . . . . . . . . . . . . . . 5 4. Processing Procedures . . . . . . . . . . . . . . . . . . . . 5
5. Congestion Considerations . . . . . . . . . . . . . . . . . . 6 5. Congestion Considerations . . . . . . . . . . . . . . . . . . 6
6. Applicability Statements . . . . . . . . . . . . . . . . . . 6 6. Applicability Statements . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
IPsec Virtual Private Network (VPN) is widely used by enterprises to IPsec Virtual Private Network (VPN) is widely used by enterprises to
interconnect their geographical dispersed branch office locations interconnect their geographical dispersed branch office locations
across the Wide Area Network (WAN) or the Internet, especially in the across the Wide Area Network (WAN) or the Internet, especially in the
Software-Defined-WAN (SD-WAN) era. In addition, IPsec is also Software-Defined-WAN (SD-WAN) era. In addition, IPsec is also
increasingly used by cloud providers to encrypt IP traffic traversing increasingly used by cloud providers to encrypt IP traffic traversing
skipping to change at page 5, line 12 skipping to change at page 5, line 12
to identify specific applications/protocols) which may be to identify specific applications/protocols) which may be
required in some cases, instead of calculating a 16-bit hash, required in some cases, instead of calculating a 16-bit hash,
the encapsulator SHOULD calculate a 14-bit hash and use those the encapsulator SHOULD calculate a 14-bit hash and use those
14 bits as the least significant bits of the source port field 14 bits as the least significant bits of the source port field
while the most significant two bits SHOULD be set to binary 11. while the most significant two bits SHOULD be set to binary 11.
That still conveys 14 bits of entropy information which would That still conveys 14 bits of entropy information which would
be enough as well in practice. be enough as well in practice.
Destination Port of UDP: Destination Port of UDP:
This field is set to a value (TBD1) allocated by IANA to This field is set to a value (TBD1) allocated by IANA to
indicate that the UDP tunnel payload is an ESP packet. indicate that the UDP tunnel payload is an ESP packet.
UDP Length: UDP Length:
The usage of this field is in accordance with the current UDP The usage of this field is in accordance with the current UDP
specification [RFC0768]. specification [RFC0768].
UDP Checksum: UDP Checksum:
For IPv4 UDP encapsulation, this field is RECOMMENDED to be set For IPv4 UDP encapsulation, this field is RECOMMENDED to be set
to zero for performance or implementation reasons because the to zero for performance or implementation reasons because the
IPv4 header includes a checksum and use of the UDP checksum is IPv4 header includes a checksum and use of the UDP checksum is
optional with IPv4. For IPv6 UDP encapsulation, the IPv6 optional with IPv4. For IPv6 UDP encapsulation, the IPv6
header does not include a checksum, so this field MUST contain header does not include a checksum, so this field MUST contain
a UDP checksum that MUST be used as specified in [RFC0768] and a UDP checksum that MUST be used as specified in [RFC0768] and
[RFC2460] unless one of the exceptions that allows use of UDP [RFC2460] unless one of the exceptions that allows use of UDP
zero-checksum mode (as specified in [RFC6935]) applies. zero-checksum mode (as specified in [RFC6935]) applies.
ESP Packet: ESP Packet:
This field contains one ESP packet. This field contains one ESP packet.
4. Processing Procedures 4. Processing Procedures
This ESP-in-UDP encapsulation causes ESP [RFC2406] packets to be This ESP-in-UDP encapsulation causes ESP [RFC2406] packets to be
forwarded across IP WAN via "UDP tunnels". When performing ESP-in- forwarded across IP WAN via "UDP tunnels". When performing ESP-in-
UDP encapsulation by an IPsec VPN gateway, ordinary ESP encapsulation UDP encapsulation by an IPsec VPN gateway, ordinary ESP encapsulation
procedure is performed and then a formatted UDP header is inserted procedure is performed and then a formatted UDP header is inserted
between ESP header and IP header. The Source Port field of the UDP between ESP header and IP header. The Source Port field of the UDP
header is filled with an entropy value which is generated by the header is filled with an entropy value which is generated by the
IPsec VPN gateway. Upon receiving these UDP encapsulated packets, IPsec VPN gateway. Upon receiving these UDP encapsulated packets,
skipping to change at page 6, line 45 skipping to change at page 6, line 45
Service Name: ESP-in-UDP Transport Protocol(s):UDP Service Name: ESP-in-UDP Transport Protocol(s):UDP
Assignee: IESG <iesg@ietf.org> Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>. Contact: IETF Chair <chair@ietf.org>.
Description: Encapsulate ESP packets in UDP tunnels. Description: Encapsulate ESP packets in UDP tunnels.
Reference: This document. Reference: This document.
Port Number: TBD1 -- To be assigned by IANA. Port Number: TBD1 -- To be assigned by IANA.
9. Security Considerations 9. Security Considerations
TBD. If source port is generated using inner packet parameters, care
should be taken to not reveal those parameters. Including some
random bytes along with the inner packet parameters will ensure the
information of inner IP header is not revealed.
Because packets are traversing different paths and the ESP sequence
number is assigned sequencially by the encapsulator irrespective of
the packet flow, the receiver might receive packets out-of-order and
end up dropping them as delayed/out-of-order packets. Based on the
network speed and load, administrator should be able to adjust the
replay window size or entirely disable the replay check.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
 End of changes. 11 change blocks. 
12 lines changed or deleted 22 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/