On Fri, Aug 15, 2025 at 7:39 PM Linda Dunbar <[email protected]> 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] 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? Paul >
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
