Paul, Good questions. Please see the answers inserted below after [Linda 2].
Linda From: Paul Wouters <paul.wout...@aiven.io> Sent: Friday, August 15, 2025 4:51 PM To: Linda Dunbar <linda.dun...@futurewei.com> Cc: ipsecme-chairs <ipsecme-cha...@ietf.org>; IPSEC <ipsec@ietf.org>; Deb Cooley <debcool...@gmail.com> Subject: Re: Follow-up on adoption options for draft-dunbar-ipsecme-lightweight-authenticatee On Fri, Aug 15, 2025 at 7:39 PM Linda Dunbar <linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>> wrote: Please see below of the response. If there is still confusion, can we have a zoom chat? I'd rather we discuss this further online so others can listen and speak up too. I read the draft again, and I still don't really understand it. It seems to be CPE to Cloud GW but the connection between these is "the internet". [Linda] Correct. For example, an enterprise has multiple locations, say Seattle, Boston, or Singapore. Seattle-CPE establishes an IPsec tunnel with Boston-CPE. Instead of best effort forwarding of the IPsec encrypted packets from Seattle-CPE to Boston-CPE via internet, the IPsec encrypted packets from Seattle-CPE is encapsulated with GENEVE header (with Destination address set to the Seattle Cloud GW) to force the packet to the Seattle Cloud GW, which in turn can transport the IPsec encrypted packets to the Boston Cloud GW via Cloud Backbone. The Boston Cloud GW then strip the outer GENEVE header and forward the original IPsec encrypted packets to the Boston-CPE. So if the Seattle-CPE is smart enough pick the Seattle Cloud GW for GENEVE, why can't it build up an IPsec tunnel to that destination to reach the Boston-CPE, and let the backbone do the work of building the additional IPsec tunnels within its cloud? If the Boston-CPE does the same, then you have your result without needing a new protocol (or the extra GENEVE encryption) [Linda 2] The IPsec tunnel from Seattle-CPE to Boston-CPE cannot dictate the specific transit nodes along the Internet path—it is purely best-effort forwarding. There is no mechanism to mandate which path the encrypted traffic will traverse. In fact, IPsec packets sent directly from Seattle-CPE to Boston-CPE, with the outer IP destination set to Boston-CPE, are not guaranteed to traverse the Seattle Cloud GW. By contrast, building a dedicated transport path (e.g., an MPLS circuit from Seattle to Boston) would provide deterministic control, but that option is very expensive. A Cloud Backbone, on the other hand, is a provider-managed network that almost always supports traffic engineering. The advantage of using GENEVE encapsulation toward the Seattle Cloud GW is that it anchors traffic into the Cloud Backbone, where the provider can ensure consistent and optimized delivery across its managed infrastructure. Simply creating a direct IPsec tunnel between Seattle-CPE and Boston-CPE still leaves traffic dependent on the unpredictable Internet path, whereas the Cloud GW–based approach delivers the benefits of deterministic routing without the high cost of private circuits. [Linda] It is for deployment where there is shared key between the CPE and Cloud GW for other traffic (i.e. the services that needs to be terminated within the cloud) I would say you can just setup a regular IPsec tunnel from the CPEs to their nearest Cloud GW, and then run IPsec between your Cloud GWs? Why have additional different auth mechanisms? [Linda 2] The Seattle-CPE to Boston-CPE traffic is already enterprise-encrypted, and the Cloud GW cannot decrypt that payload. Adding another layer of IPsec encryption solely for header information would create overhead. It is also costly, since Cloud Providers typically impose limits on the traffic volume of IPsec tunnel that a customer can send, which can quickly become a bottleneck for large-scale deployments. In contrast, HMAC is far more lightweight than establishing a full IPsec tunnel. A detailed analysis is provided in draft-ietf-rtgwg-multisegment-sdwan<https://datatracker.ietf.org/doc/draft-ietf-rtgwg-multisegment-sdwan/>. Paul
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
