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

["Panwei (William)" <[e-mail]>]

Hi Steffen,

Thanks for your input and that is very useful for us.

At yesterday's meeting, I think people basically understood and accepted the problem statement itself, but also raised different ideas regarding to the solutions.
We'll try to do more analysis and comparison of possible solutions, including what you suggested.

What you are doing (new version of WESP) is also interesting to us, we'd like to know more if it's OK.
Switching to a new protocol is still a reasonable solution for us, although it has pains.
Developing a new protocol in IETF will cost time, we'd like to adopt the new protocol after it's standardized.
But we need to solve our problem now, and therefore, it's better for us to consider some forward compatible things in advance. For example, do you think it's better to encrypt the "Flow Identifier" field or not?

Regards & Thanks！
Wei PAN (潘伟)

    > -----Original Message-----
    > From: Steffen Klassert <[e-mail]>
    > Sent: Friday, March 15, 2024 5:31 PM
    > To: Paul Wouters <[e-mail]>
    > Cc: Panwei (William) <[e-mail]>; [e-mail] WG
    > <[e-mail]>
    > Subject: Re: [IPsec] I-D Action:
    > draft-he-ipsecme-vpn-shared-ipsecsa-00.txt
    > 
    > 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