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

[Paul Wouters <[e-mail]>]

On Mon, 11 Mar 2024, Panwei (William) wrote:

> Indeed, splitting the 32-bit SPI into two sub-fields, the VPN ID sub-field and SPI sub-field, may also be one option. This solution doesn't need to change the ESP packet format, but it also has some disadvantages.
> The first one is the scalable issue. 256 VPN IDs may be enough for use for current RAN Sharing scenario, but when considering the service slicing feature, thousands and even more VPNs will be needed in the future. So, it's better to assign 16 bits to the VPN ID sub-field. Therefore, the SPI sub-field will be trenched to 16 bits, which means the available SPIs are 64k. This can have a negative impact on the expansion of usable scenarios in the future.
> The second problem is the high possibility of packet disorder. Although all VPNs share one actual SA and the sender assigns sequence numbers in sequence to all the traffic no matter which VPN they belong to, different VPNs will use different SPIs in the ESP packets. This will interfere with the load balance process of the on-path routers because they usually look at the SPI field when doing the hash. This may lead to packet disorder at the IPsec receiver.
> Therefore, we currently still prefer a separate field representing the VPN ID. But we are open to more discussions and future changes.

Thanks, those arguments are clear. Perhaps Steffen can take these into
consideration as well when thinking about ESPv4 / WESP :)

>    > 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.
>
> We did consider this option before.
> A new notify or traffic selector type of just the VPN ID is also acceptable but has some disadvantages.
> When using the new notify or traffic selector type along with the existing traffic selectors of v4/v6 types, it will be impossible to differentiate which traffic selector of v4/v6 types is associated with which VPN. Therefore, all traffic selectors of v4/v6 types will be associated with each VPN, which may cause unwanted traffic to be included in the traffic selection result.
> When using the new notify or traffic selector type alone, it will allow all the traffic (from any to any) of one VPN to be selected, which will also cause unwanted traffic to be included.
> By considering this, our current design of copying and extending the existing v4/v6 types want to keep a more precious traffic selection.

Indeed. That is also the reasoning for the Labeled IPsec traffic
selector types. You could use those too, nothing prevents you
from filling the label with simple 16 bit numbers :)

Paul