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

[Michael Richardson <[e-mail]>]

Panwei (William) <[e-mail]> wrote:
    > 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> [Wei (William) Pan] We did consider this before. Sharing the same IKE
    wei> SA can partly release the pain, but not much.  Assuming there are N

The reason I ask is if you can *NOT* share the IKE SA, then one solution is
to just give each base station a bunch of IP addresses. N of them.
Given RFC1918 this might be limiting.  Given IPv6, a /64 per base station is
plenty.   The advantage of that is that rather than having a VPNID, one has a
source/destination pair per RAN.

How are the base stations connected?  Is it ethernet to the basestation?
Or do the base stations have direct fiber connections to each other?  What
does the physical connectivity look like?  I also wonder if there is a
metro-ethernet occuring, if the full mesh isn't overkill because the
metro-ethernet has other topological issues.  {This question is mostly just
for my full understanding}

    wei> the base station is deployed in a crowded area.  We got from the
    wei> customers that they want to double the number of operators sharing the
    wei> RAN. Therefore, this solution isn't scalable enough for this need and
    wei> future expansion.

What is the order of magnitude of N and M today?
2^4? 2^8? 2^16?

When you double, what is the starting order?

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

Yes, if you can tolerate the CHILD SA traffic being shared between all the
RANs, then having a new layer would let you scale without concern for IPsec.
You didn't answer that question: can they tolerate this?

Also, I think that this traffic is control plane traffic that allows for the
mobility of the devices attached to these base stations.  I don't know the
3GPP protocol names for that.

But, does it also include encapsulated end-customer traffic?
I would assume that each base station has an SA to connect it to each of the
RAN's concentrators.  L2TP or something like that.


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*