Hi Paul,
Thanks for your quick comments. But I'm sorry for the late response due to I
was out of the office for a few days.
> 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.
Thanks for pointing out this, we'll change it to a better name in the next
version.
> 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.
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.
> 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?
I think this will matter because on-path routers will look into the SPI field
and one possible result is packet disorder at the IPsec receiver.
> 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.
Regards & Thanks！
Wei PAN (潘伟)
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
