Paul, Replies to your additional comments are after [Linda 3] inserted below:
Linda From: Paul Wouters <[email protected]> Sent: Tuesday, August 19, 2025 8:09 AM To: Linda Dunbar <[email protected]> Cc: ipsecme-chairs <[email protected]>; IPSEC <[email protected]>; Deb Cooley <[email protected]> Subject: Re: Follow-up on adoption options for draft-dunbar-ipsecme-lightweight-authenticatee On Mon, Aug 18, 2025 at 6:05 PM Linda Dunbar <[email protected]<mailto:[email protected]>> wrote: 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 Right. You have Seattle-CPE and Boston-CPE connect via IPsec to their respective local IPsec GWs and from there handle things within your administrative domain between the GWs ? —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. This is why you setup IPsec tunnels to the GWs and then the GW backplane to their thing to move packets. The only new caveat you added now is that this has to be CPE-to-CPE encrypted. This could ofcourse be mTLS if you really didnt want another layer of IPsec. But for example, my mailserver bofh.nohats.ca<http://bofh.nohats.ca/> is located in Toronto. To you it appears to be in Amsterdam. I use an IPsec tunnel to give it an IP from an Amsterdam /24. The server itself also initiates IPsec tunnels and of course those appear to be initiated from amsterdam. I don't really see MTU issues on my mail server, but if there were, I could try using IPsec IPTFS set to like 1400 packet size to allow for the space of two ESP headers and one ESPinUDP header. [Linda 3] Section 9.3 of draft-ietf-rtgwg-multisegment-sdwan<https://datatracker.ietf.org/doc/draft-ietf-rtgwg-multisegment-sdwan/> already describes options of using AH, ESP-NULL for protection between a CPE and a Cloud GW. However, major cloud providers impose strict limits on IPsec capacity—AWS caps each tunnel at ~1.25 Gbps, Google Cloud at ~1–3 Gbps (250k pps), Azure bounds throughput by the VPN gateway SKU with all tunnels sharing that limit, and Oracle typically delivers ~250 Mbps per tunnel on a best-effort basis. Under these constraints, adding another full IPsec layer on top of enterprise-encrypted CPE-to-CPE traffic may not be possible for some deployments. The lightweight authentication mechanism (e.g., GENEVE + HMAC) is intended for such cases where Cloud GW IPsec capacity is limited. It is not required in environments where Cloud GWs can support essentially unlimited IPsec throughput. The IETF’s role is to provide the nuts and bolts to support a range of environments, including those with constrained resources. 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. You could setup GENEVE (or GRE or IPIP) to sling the Seattle-CPE traffic to Cloud GW Seattle and let the cloud route it. If Buston-CPE does the same for Cloud GW Boston, wouldn't that address your problem? Sure, there is no authentication on that, but I don't see how authentication helps you secure the Seattle-CPE to Seattle-Cloud-GW traffic anyway if that is just regular internet. [Linda3] The description in the document applies to both sides: Boston-CPE to Boston-Cloud GW also requires authentication under normal Internet-based deployments. The purpose of this authentication is not to re-encrypt the end-to-end payload (already protected by the CPE-to-CPE IPsec tunnel), but to safeguard the encapsulation header and prevent spoofing or injection on the CPE-to-Cloud GW segment. That said, if the network segment between a CPE and its closest Cloud GW is inherently secure—for example, a direct Ethernet link or a private line—then additional authentication of the GENEVE header is not needed. Authentication is only necessary on segments where there is exposure or risk. Do you think adding a following paragraph in Section 3.1 could help explain it better? “This requirement applies symmetrically to both sides. For example, CPE1 to GW1 and CPE10 to GW2 each require authentication when their connectivity to the Cloud GW traverses the Internet. The authentication protects the encapsulation header rather than the already-encrypted payload. However, if the CPE-to-Cloud GW segment is inherently secure, for example, a single Ethernet link or private line, then additional authentication of the encapsulation header is not required.” 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) If services need to be terminated in the cloud, there are not CPE-to-CPE end encrypted? So that is a whole other new discussion then right ? [Linda3] Some of the traffic from enterprise CPEs are to reach the Services hosted in the Cloud. Some are to reach other CPEs in different locations. 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, Is enterprise-encrypted the same as CPE-CPE end-to-end encrypted? [Linda3] Yes. 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/>. What offers this in addition to a GRE tunnel ? the GRE endpoints are IP locked and they can inspect the inner IP packets. They can drop all inner IP traffic that is not CPE-to-CPE (or even that is not CPE-to-CPE IPsec traffic). Why is a new authentication protocol needed for the outer IP layer (eg GRE or IPIP) [Linda3] The analysis comparing GRE, IPinIP, with GENEVE is documented in the Section 4 of https://datatracker.ietf.org/doc/draft-ietf-rtgwg-multisegment-sdwan/ : “Many encapsulation methods, such as VLAN tags, IP-in-IP, GRE, etc., can be used to steer traffic from a CPE to its nearest Cloud GW. However, GENEVE encapsulation [RFC8926] offers significant advantages, including flexible option Sub-TLVs that can signal routing and policy preferences, such as Restricted Regions, Exclude Regions, preferred egress Cloud GWs, and other service specific requirements. In addition, GENEVE Encapsulation [RFC8926] is widely supported by major Cloud Service Providers, which allows Cloud GWs to efficiently steer IPsec-encrypted packets between CPEs via Cloud Backbone without decryption, reducing processing overhead and improving performance while maintaining end-to-end encryption.” Paul
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
