Re: [IPsec] I-D Action: draft-he-ipsecme-vpn-shared-ipsecsa-00.txt

Initial thought while having morning coffee.

I can see how you want an extra SPD selector for the VPN ID - but maybe call it Namespace ID or something else as VPN ID is confusing. 

Your gateway that needs to support say 256 VPN IDs could split up its SPI range so it can detect which VPN to send it to based on SPI range ? That would need no ESP changes. In linux terms that would mean you “mark” the skbuf with the VPN ID to steer it into the right place before/after decrypting / encrypting.
In Linux you could also use the “labeled IPsec” to label the packet with the VPN ID.
It would require you keep track of the SPI bundle of the SA, but again in Linux terms you could use marking of packets based on keeping a list of peer SPIs per VPN ID.

Usually, hardware offload and queueing looks at some (hash of) IP properties (eg port numbers or SPI). This might interfere but since you have many tunnels that might not matter?

The VPN ID could be done via notify instead of new traffic selector. Or you could add a new traffic selector type of just the VPN ID instead of copying and extending the existing v4/v6 types - similar to RFC 9478.

Paul

Sent using a virtual keyboard on a phone

> On Mar 5, 2024, at 03:55, Panwei (William) <william.panwei=40huawei.com@dmarc.ietf.org> wrote:
> 
> Hi folks,
> 
> We've encountered a real problem when using IPsec in the Multi-VPN environment.
> We find that separate IPsec tunnels (i.e., different IKE SAs and different Child SAs) are needed for each VPN to distingue the traffic from different VPNs.
> But, due to the number of peer devices and the number of VPNs increases, the number of IPsec tunnels needed is also explosively growing and exceeds the device's capacity.
> 
> Therefore, we are considering whether different VPNs can share the use of the same IPsec tunnel, i.e., the same IKE SA and Child SA.
> We've prepared a draft to present the problem and our considerations: https://datatracker.ietf.org/doc/draft-he-ipsecme-vpn-shared-ipsecsa/
> 
> We'd like to get comments and feedback from you experts. Thanks a lot in advance.
> 
> Regards & Thanks！
> Wei PAN (潘伟)
> 
> -----Original Message-----
> From: I-D-Announce <i-d-announce-bounces@ietf.org> On Behalf Of internet-drafts@ietf.org
> Sent: Monday, March 4, 2024 3:30 PM
> To: i-d-announce@ietf.org
> Subject: I-D Action: draft-he-ipsecme-vpn-shared-ipsecsa-00.txt
> 
> Internet-Draft draft-he-ipsecme-vpn-shared-ipsecsa-00.txt is now available.
> 
>   Title:   Shared Use of IPsec Tunnel in a Multi-VPN Environment
>   Authors: Qi He
>            Wei Pan
>            Xiaolan Chen
>            Beijing Ding
>   Name:    draft-he-ipsecme-vpn-shared-ipsecsa-00.txt
>   Pages:   18
>   Dates:   2024-03-03
> 
> Abstract:
> 
>   In a multi-VPN environment, currently, different IPsec tunnels (i.e.,
>   different IKE SAs and Child SAs) have to be created to differentiate
>   and protect the traffic of each VPN between the device and its peer.
>   When the number of neighbors of a device and the number of VPNs
>   increases, the number of IPsec tunnels also increases considerably.
>   This results in the need for a large number of SAs, which exceeds the
>   device's capacity.
> 
>   This document proposes a method for different VPNs to share the use
>   of a single IPsec tunnel, which can greatly reduce the number of SAs
>   required in a multi-VPN scenario.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-he-ipsecme-vpn-shared-ipsecsa/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-he-ipsecme-vpn-shared-ipsecsa-00.html
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec