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

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

Hi Michael,

    >     > 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.
    > 
    > I think that one thing that is unclear to me is whether the different RANs
    > can tolerate that all the different traffic share the same *IKE* SA.

[Wei (William) Pan] We did consider this before. Sharing the same IKE SA can partly release the pain, but not much.
Assuming there are N peer devices and M operators sharing the RAN, currently, at least (2* N * M) SAs are needed: (N * M) IKE SAs and at least (N * M) Child SAs. Sharing the same IKE SA will still need at least (N * M) Child SAs.
In our evaluation based on today's actual scenarios, the Child SAs needed will still be going to reach the base station's capacity if the base station is deployed in a crowded area.
We got from the customers that they want to double the number of operators sharing the RAN. Therefore, this solution isn't scalable enough for this need and future expansion.

    > The next level is whether or not they can tolerate being in the same
    > CHILD SA.  We could put the "VPN ID" at another layer (inside the
    > common tunnel), such as some kind of L3VPN, GRE, VXLAN.

[Wei (William) Pan] Do you mean first encapsulating the original traffic into a tunnel that can carry the VPN info and then encapsulating the tunneled traffic into the IPsec tunnel?
My initial feeling is that there may be operational and maintenance difficulties. We can have more thinking on this and reply later.

    >     > 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
    > 
    > I don't think you need any new protocols, but maybe new ways to
    > combine existing protocols.  For instance, some IKEv2 support for
    > configuring VXLAN.
    > But, this depends upon the *security* and traffic isolation that you need.
    > For instance, do you have issues of traffic accounting between the RANs
    > that occurs on the outside (ESP) packets.

[Wei (William) Pan] Thanks for your feedback, we will put it into consideration.
This is why we think we need to do the analysis and comparison of solutions, to find out what is the most possible and reasonable solution.

Regards & Thanks！
Wei PAN (潘伟)