Hi Paul, Thanks for your comments. It said in the draft that
" Note that the difference between the ESP-in-UDP encapsulation as proposed in this document and the ESP-in-UDP encapsulation as described in [RFC3948] is that the former uses the UDP tunnel for load-balancing improvement purpose and therefore the source port is used as an entropy field while the latter uses the UDP tunnel for NAT traverse purpose and therefore the source port is set to a constant value (i.e., 4500)." More specifically, when using the ESP-in-UDP encapsulation as per RFC 3948, all traffic flows would be encapsulated within a single UDP tunnel where the srt and dest port are set to 4500. As a result, all encapsulated traffic flows would have to forwarded along a single path by core routers when using the widely supported UDP five-tuple based load-balancing mechanism. In contrast, when using the ESP-in-UDP encapsulation as described in this draft, different traffic flows would be encapsulated within UDP tunnels with different srt port values. In this way, those encapsulated traffic flows could be distributed among different ECMPs by core routers on basis of the five tuple of the UDP packets. Best regards, Xiaohu ________________________________________ 发件人: Paul Wouters [p...@nohats.ca] 发送时间: 2016年11月15日 20:54 收件人: Xuxiaohu 抄送: ipsec@ietf.org WG 主题: Encaps document, was Re: [IPsec] 答复: IETF97 meeting raw notes Sent from my iPhone > On Nov 15, 2016, at 18:12, Xuxiaohu <xuxia...@huawei.com> wrote: > > Hi all, > > Just some clarifications of the motivation for Enapsulating ESP in UDP for > load balancing: > > 1) The load-balancing here means distributing IPsec traffic flows over > mulitple ECMPs (Equal-Cost Multipath) within IP WAN (Wide Area Network), > rather than multiple IPsec gateways. Since most existing core routers within > IP WAN can already support balancing IP traffic flows based on the hash of > the five-tuple of UDP packets, by encapsulating IPsec Encapsulating Security > Payload (ESP) packets inside UDP packets with the UDP source port being used > as an entropy field, it will enable existing core routers to perform > efficient load-balancing of the IPsec tunneled traffic without requiring any > change to them. I do not understand "entropy"? If you have non-NATed endpoints and you do ESPinUDP as per RFC 3948, isn't that unique enough since you assume no NAT? On our implementation (libreswan) you can configure this using forceencaps=yes which results that endpoint in "lying" with the NAT discovery payloads so it "detects NAT" and uses encapsulation. Can you explain why you think you need a new document? Paul > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
