Security Platforms/Tools

Mobile Sentiment Begins to Favor IPsec

Around the world, mobile operator sentiment around whether or not to use IPsec encryption and authentication from LTE cell sites seems to be shifting in favor of using it. In 3G, the user traffic is encrypted all the way to the RNC. In LTE, by contrast, it terminates at the base station or eNode B, creating what some believe will be a significant security vulnerability that has to be defended against.

A number of mobile operator delegates at Light Reading's Mobile Broadband Summit & Expo 2011 in Delhi assumed that IPsec will likely need to be deployed with LTE. India has become one of the world's most unpredictable markets in recent years. New network security mandates have a habit of erupting from government circles, only to be parked a few months later and then quietly forgotten.

Nevertheless, several coffee-break conversations during the conference suggested to me that the consensus in India does seems to be edging that way. Support is also building in Europe. One of the big pan-European carriers is now mandating that IPsec must be rolled out to every LTE cell site at all of its affiliates, and this is triggering a knee-jerk competitive response on the part of other operators, including other pan-European players, to do the same.

Certainly, the prospect of having to deploy IPsec isn't something that mobile network planners approach with any enthusiasm. One of the many legitimate concerns is the operational cost of managing huge numbers of IPsec tunnels in the network. Experience from the enterprise and wireline environments suggests that it is not only costly on opex, but also imposes a substantial drain on system processing resources. In particular, operators fear the complexity of having to manage multiple IPsec tunnels for multiple X2 as well as S1 interfaces across the network.

Consistent with this concern, Heavy Reading's research has shown that those mobile operators that are moving forward with deploying IPsec are pretty much universally looking at a single IPsec tunnel deployment model in the initial launch phase. What that consists of is one single tunnel being instantiated at the cell site – typically by the eNode B itself – and all of the user plane and control plane traffic being transported across that single tunnel to the core network, where it is unencrypted by the new 3GPP-defined Security Gateway or SEG. This pretty much permanent IPsec tunnel across the LTE backhaul network provides the stability and predictability that the operator requires. Critically, it avoids the highly dynamic instantiation and tearing down of tunnels that operators are most wary of at the outset.

Heavy Reading research also shows consistently that mobile operators are typically looking to implement between four and five QoS levels in across their network, especially with LTE. IPsec will typically need to be deployed with that in mind, since encrypting traffic affects the way that QoS markings can be read and adhered to by intermediate network elements. The initial one-tunnel model for IPsec deployment also precludes deploying one tunnel per QoS class.

One solution would be to over-provision the network. Where a backhaul wholesaler is cost-effective and flexible enough, bandwidth can be leased at a committed information rate equal to the bandwidth of the tunnel. Then only the mobile operator's equipment needs to worry about classification and queuing, so the intermediate transport network doesn't need to worry about QoS.

Another option involves exploiting options in the types of encryption that IPsec allows. In addition to encrypting the whole packet, IPsec allows a model whereby the original header can be kept and only the payload is encrypted. If the latter model is implemented, then intermediate DHCP markings in the original IP header can be preserved for the intermediate transit across the S1.

Since it introduces additional processing and overhead in the network, network planners are wise to consider the requirements for deploying IPsec when they are also implementing one of the new packet network synchronization standards that are being implemented in the backhaul and have proved challenging to deploy without IPsec, let alone with it.

In fact, deployed the right way, IPsec should not affect synchronization in the network at all. Several major vendors are supporting a means whereby synchronization traffic can be excluded from the IPsec tunnel and transmitted along an express path where the synchronization traffic is marked up with the highest Ethernet and DiffServ codepoint QoS level.

This enables the synchronization packets to bypass all the standard queuing mechanisms in the switches and routers along the way. Leaving the synchronization traffic unencrypted would still count as a security vulnerability, but it would be a very minor one in the scheme of things. And it is an approach that is recommended by some of the leading LTE RAN vendors. Not only would an attack on the synchronization traffic require a very high level of sophistication, it would also typically result in a very gradual loss of synchronization that the operator would typically have plenty of time to respond to before it affected the user experience.

The tendency for LTE operators to begin thinking in favor of using IPsec in the backhaul is by no means a universal one. A great many operators continue to be comfortable that their backhaul is what 3GPP defines as "trusted" and therefore doesn't require IPsec for LTE or any other currently available technology. Nevertheless, from the indications I can see, the global "needle" is starting to inch its way in favor of operators thinking they will have to use it.

— Patrick Donegan, Senior Analyst, Wireless, Heavy Reading

arivanov 12/5/2012 | 5:03:17 PM
re: Mobile Sentiment Begins to Favor IPsec

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?

pdonegan67 12/5/2012 | 5:03:16 PM
re: Mobile Sentiment Begins to Favor IPsec

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.

Kevin Mitchell 12/5/2012 | 5:01:16 PM
re: Mobile Sentiment Begins to Favor IPsec

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.

Sign In