On Tue, Aug 19, 2025 at 2:10 PM Linda Dunbar <[email protected]> wrote:
> But for example, my mailserver 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. > > 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. 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]
