Hi Yoav,
Your understanding is correct. BTW, it said in the draft that “Source Port of
UDP: This field contains a 16-bit entropy value that is
generated by the encapsulator to uniquely identify a
flow. What constitutes a flow is locally determined by
the encapsulator and therefore is outside the scope of
this document.”
For example, the encapsulator could calculate a hash of the five tuple of the
payload of the ESP if the ESP payload is an IP packet.
Best regards,
Xiaohu
发件人: Yoav Nir [mailto:[email protected]]
发送时间: 2016年11月3日 14:57
收件人: Xuxiaohu
抄送: [email protected]
主题: Re: [IPsec] New Version Notification for
draft-xu-ipsecme-esp-in-udp-lb-00.txt
The draft has no text about mapping SA to source port. So if I’m understanding
you correctly, the tunnel ingress calculates the port (is there actual
calculation, or just picking?), so if it sends all packets for a particular SA
with the same UDP source port, they will all traverse the same path and
therefore will likely not get re-ordered, or at least will not get any more
re-ordered than IPsec packets on the regular Internet.
Did I understand this correctly?
Yoav
On 3 Nov 2016, at 8:27, Xuxiaohu
<[email protected]<mailto:[email protected]>> wrote:
Hi Yoav,
The load-balancing mechanism as described in this draft would ensure a given
traffic flow to be forwarded over a certain path. In other words, there is no
disordering issue. The destination port is assigned by IANA while the source
port is dynamically calculated by the ingress of the IPsec/UDP tunnel.
Furthermore, a given traffic flow would be forwarded over a certain path and
therefore this is no disordering issue. As for why do we need a new port, I had
attempted to reply in another email.
Best regards,
XIaohu
发件人: Yoav Nir [mailto:[email protected]]
发送时间: 2016年11月1日 15:31
收件人: Xuxiaohu
抄送: [email protected]<mailto:[email protected]>
主题: Re: [IPsec] New Version Notification for
draft-xu-ipsecme-esp-in-udp-lb-00.txt
Hi, Xiaohu
A few comments. Actually, they’re more like questions.
1. How are IPsec SAs mapped to UDP pseudo-connections? Is it a 1:1 mapping
between SPI and source port?
2. If now, how do you deal with the packet reordering that the load balancer
will do? IPsec requires ordered or nearly-ordered delivery.
3. How is this negotiated? In IKE? Prior agreement?
4. Why do we need a new port? What goes wrong if the packets go to port
4500?
Thanks
Yoav
On 1 Nov 2016, at 3:45, Xuxiaohu
<[email protected]<mailto:[email protected]>> wrote:
Hi all,
Any comments and suggestions are welcome.
Best regards,
Xiaohu
-----邮件原件-----
发件人: [email protected]<mailto:[email protected]>
[mailto:[email protected]]
发送时间: 2016年10月31日 19:15
收件人: Xuxiaohu; zhangdacheng; Xialiang (Frank)
主题: New Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt
A new version of I-D, draft-xu-ipsecme-esp-in-udp-lb-00.txt
has been successfully submitted by Liang Xia and posted to the IETF repository.
Name: draft-xu-ipsecme-esp-in-udp-lb
Revision: 00
Title: Encapsulating IPsec ESP in UDP for Load-balancing
Document date: 2016-10-31
Group: Individual Submission
Pages: 7
URL:
https://www.ietf.org/internet-drafts/draft-xu-ipsecme-esp-in-udp-lb-00.txt
Status:
https://datatracker.ietf.org/doc/draft-xu-ipsecme-esp-in-udp-lb/
Htmlized: https://tools.ietf.org/html/draft-xu-ipsecme-esp-in-udp-lb-00
Abstract:
IPsec Virtual Private Network (VPN) is widely used by enterprises to
interconnect their geographical dispersed branch office locations
across IP Wide Area Network (WAN). To fully utilize the bandwidth
available in IP WAN, load balancing of traffic between different
IPsec VPN sites over Equal Cost Multi-Path (ECMP) and/or Link
Aggregation Group (LAG) within IP WAN is attractive to those
enterprises deploying IPsec VPN solutions. This document defines a
method to encapsulate IPsec Encapsulating Security Payload (ESP)
packets inside UDP packets for improving load-balancing of IPsec
tunneled traffic. In addition, this encapsulation is also applicable
to some special multi-tenant data center network environment where
the overlay tunnels need to be secured.
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at
tools.ietf.org<http://tools.ietf.org>.
The IETF Secretariat
_______________________________________________
IPsec mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec