On Mon, Mar 11, 2024 at 11:36:03AM -0400, Paul Wouters wrote: > 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 root cause what this draft tries to solve is that we need a possibility to expose information of the inner packet flow to the outer packet. Basically this is the same problem, the sequence number subspaces draft tries to solve. So instead of solving the same problem for every single usecase in a diffetent way, it would be nice to have a generic solution for that problem. I'm thinking of some 'Flow Identiyer' field that can be used for all this cases. The biggest problem here is that some usecases need to have this information transparent to the outer network. For instance the sequence number subspaces information is needed by the receiving NIC to do RSS properly. For that reason negotiating the new field does not help. The NIC can't know what you have negotiated, so the new field is useless in that case. Unfortunately ESP does not have a version number, so we can't change it in any transparent way. The only possibility for ESP is to use the SPI because this is already used as the ESP 'Flow Identifyer'. At the last IETF meeting I proposed to use an updated WESP to do changes that need to be transparent to the network. WESP has a version numbers and can be adjusted in a transparent way. I'm currently preparing a WESPv2 draft that I plan to publish after the next IETF meeting. Some people here on the list have seen it already, that's why Paul mentioned me in his mail. I know that switching to another protocol is always a pain, but I don't see other options do do that right. Steffen _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
