Who are you expecting to set or change the source port? If the IKE daemon, it does not know how much traffic an SA will do. So it won't do a good job.
If the network device will rewrite 4500, it is completely transparent to the IKE daemon. This is fine but then I do not see why you need a standards document? Paul Sent from my iPhone > On Nov 16, 2016, at 09:45, Xuxiaohu <xuxia...@huawei.com> wrote: > > 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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
