Paul, I believe I’ve addressed the questions you raised in our earlier email exchanges, but please let me know if I’ve missed anything.
Could you share your recommendation on the best path forward? Should we consider AD sponsorship, pursue adoption in IPsecme, or take another route? Also, does the Security Area have a forum for drafts that don’t clearly fit into any of the existing WGs — something similar to RTGWG in the Routing Area? Would SECDISPATCH be the right venue? For context, the draft was presented at the combined DISPATCH session at IETF 120, where the feedback suggested IPsecme might be the right place. Any advice you can offer would be greatly appreciated. Best regards, Linda From: Linda Dunbar Sent: Tuesday, August 26, 2025 6:22 PM To: Paul Wouters <[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 Paul, Sorry for the delayed response. I have been pulled to other works. See below of the detailed responses [Linda4] to your questions. Linda From: Paul Wouters <[email protected]<mailto:[email protected]>> Sent: Tuesday, August 19, 2025 1:56 PM To: Linda Dunbar <[email protected]<mailto:[email protected]>> Cc: ipsecme-chairs <[email protected]<mailto:[email protected]>>; IPSEC <[email protected]<mailto:[email protected]>>; Deb Cooley <[email protected]<mailto:[email protected]>> Subject: Re: Follow-up on adoption options for draft-dunbar-ipsecme-lightweight-authenticatee On Tue, Aug 19, 2025 at 2:10 PM Linda Dunbar <[email protected]<mailto:[email protected]>> wrote: 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 So are these constraints technology limitations on their end or administrative constraints ? Because if those providers just want to limit the incoming stream irrespective of technology, then defining a new protocol to work around these would just end up getting the same rate limits applied. [Linda4] The short answer is: it’s both—there are real technology/architecture ceilings on the providers’ managed IPsec VPN (packet processing, crypto offload, flow tables, NIC/scale unit boundaries ) and explicit product/SKU quotas that enforce per-tunnel or per-gateway limits. Those limits apply to the managed IPsec service (e.g., “per-tunnel ~1.25 Gbps,” “250k pps per tunnel,” “SKU-bounded aggregate”), not to every possible datapath in the cloud. Our proposal does not attempt to circumvent those quotas with a new protocol. Instead, it removes the provider-managed limit from the bulk data path by keeping ESP end-to-end between enterprise CPEs and authenticating only the additional encapsulation header at the Cloud GW for steering. This allows traffic to ride the cloud backbone without ESP terminate/re-encrypt at the provider SGW, so throughput scales with the forwarding/NIC capacity and interconnect of the Cloud GW/backbone rather than the per-tunnel or per-gateway SGW quotas. 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. I do not understand this. If you send an IPIP or GRE packet to the cloud GW, can't the cloud GW not just decapsulate that packet and place it in the incoming packet queue that will have the regular firewall rules applied? Whether the packet is spoofed with or without IPIP/GRE should not matter for the GW device. It should treat both in the same way - as untrusted packets from the network. eg if it has a firewall rule that says "destination CPE devices at all my clouds then traffic MUST be IKE or ESP" would avoid these issues and you would not need to deploy an additional AUTH HMAC signature with another key distribution protocol to funnel these packets into the GW. [Linda4] Cloud GWs need to steer ESP-encrypted traffic without terminating ESP, so they need authenticated policy metadata in the outer header. IP-in-IP offers no option space at all, and GRE’s optional Key/Sequence isn’t a TLV container. “Decap then firewall” still leaves the GW with opaque ESP and no basis for egress decisions unless it terminates ESP (which we avoid). IP options / IPv6 HbH are operationally fragile and still lack per-packet integrity. Therefore, we introduce a minimal authenticated sub-TLV in the encapsulation to convey policy and cryptographically bind it to the CPE↔GW peer; IP-in-IP/GRE alone cannot satisfy both expressiveness and integrity. 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. See above. I think when properly processing an IPIP or GRE packet that is not signed or authenticated, there is no "exposure or risk". 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. Sure, but for traffic from a CPE to within the Cloud, the exact same as above applies, other than tweaking the input firewall rules that should apply even if the packet arrived within IPIP or GRE or other encapsulation. It doesn't really matter. Your Cloud GW with have a list of destination address space that is valid for the inner packet. Is enterprise-encrypted the same as CPE-CPE end-to-end encrypted? [Linda3] Yes. So then it is the same problem as above, allow IKE and ESP traffic to the CPE destination IPs plus the cloud services destination IPs. 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.” Sure, use GENEVE instead of GRE or IPIP, but you still don't need a new security protocol to add AUTH HMAC to it I think. Just decapsulate the GENEVE header and put the resulting packet in front of the input firewall to be processed. Paul
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
