So, let me see if I understand this correctly. In LTE all clients use a Mobile IP/IPv6 protocol stack which has a mandatory requirement as per current RFCs to support end to end IPSEC.
So once again, why is the need to put IPSEC in the backhaul instead of just enabling it end-to-end?
Since in LTE 3GPP-defined protocols handle over-the-air encryption and authentication from the handset to the eNode B , I would think that renders IPsec superfluous at least in this domain.
More generally, as stated in the column, IPsec represents a potentially significant opex and capex cost to mobile operators that they are keen to avoid wherever they can. End-to End isn't a model that any of them would relish today.
IPsec is potentially applicable to backhaul because cell sites tend to be less well physically protected than core sites and because until LTE, user traffic in the mobile network has always been encrypted across the backhaul.
I don't know how consistent or inconsistent that is with the relevant RFCs but that's how things seems to be playing out over here in 3GPP-land at the moment. I'd be interested to hear more.
3 major drivers for this need for authentication and encryption of IPsec for secure LTE backhaul:
1) LTE changes the architecture compared to 3G and the security association terminates further out in network at radio network as opposed at the aggregation edge
2) The backhaul network moves from nailed up circuits to IP/metro Ethernet which may be shared
3) RAN sharing
All 3 of thee drivers means that there may be an untrusted, unmanaged access network between the radio asset and the aggregation edge and this creates security threats.
So, let me see if I understand this correctly. In LTE all clients use a Mobile IP/IPv6 protocol stack which has a mandatory requirement as per current RFCs to support end to end IPSEC.
So once again, why is the need to put IPSEC in the backhaul instead of just enabling it end-to-end?