Vendors love to rain on open initiatives, so it’s not surprising that Ericsson, perhaps the leading 5G vendor, is now casting clouds and shade on Open RAN. Specifically, they’re warning about the security risks it might present. Is this yet another of those cynical vendor ploys, or is there something to the issue? In particular, are there practices that potential Open RAN users should look for, or look out for?
Open RAN is just what the name suggests, a model for implementing the 3GPP 5G RAN (or New Radio, NR) spec in an open way, rather than a way that encourages monolithic devices. It’s gained a lot of traction in the media (see HERE and HERE in just the last week), and a lot of operators are also paying attention. That, of course, is likely to arouse vendor concerns.
The fundamental objection Ericsson makes in the blog I referenced above is that Open RAN creates an “expanded threat surface.” The key quote is “The introduction of new and additional touch points in Open RAN architecture, along with the decoupling of hardware and software, has the potential to expand the threat and attack surface of the network in numerous ways….”
I have a major problem with this, frankly. What it sounds like is a plea to abandon software/hardware systems in favor of proprietary appliances. Every 5G network, or any other kind of network, is controlled at the service and network levels by software running on servers, which sounds like decoupling of hardware and software to me. Not to mention the fact that there’s probably not a single initiative in all of networking whose purpose is to bring software and hardware together in an appliance.
But let’s look at the specifics, and to do that, we have to use a reference for an Open RAN architecture, so I’m providing this figure from the O-RAN Software Community. One specific point is the hardware/software decoupling, which is IMHO total nonsense, so we won’t pursue that further.
The first specific complaint Ericsson makes is that “New interfaces increase threat surface – for example, open fronthaul, A1, E2, etc.” On the surface, this might seem at least possibly true, but I think that doesn’t survive examination.
The A1 interface, as the figure shows, links the Near-Real-Time RAN Intelligent Controller (RIC) element with orchestration and service management. Every device in any network is going to have a management interface. Every software element in an application or virtual-function-based service (remember that 3G is supposed to be based on NFV) has orchestration and management. To claim this is an attribute specific to Open RAN is silly. If your implementation of 5G doesn’t protect management and control-plane interfaces, you have a problem whether you’re Open RAN or not.
The E2 interface(s) are similar; they are part of the 5G “Control Plane” and should be totally separated from the user plane. Who’s attacking there? They’d have to be part of the 5G infrastructure, and again, if you have no protection for the components of your own infrastructure, there’s no hope for security in any form.
“Management interfaces may not be secured to industry best practices?” Sure, that’s true, and it’s true for all the management and control-plane interfaces in any compliant 5G implementation. One reason to separate data and control planes is to prevent security problems. 5G mandates that. Sorry, but this is silly too.
The final point Ericsson makes is “(not exclusive to Open RAN): adherence to Open Source best practices.” The parenthetical qualifier says it all. If this is a blog about Open RAN security problems, why include something that’s not specific to Open RAN? In any event, open-source best practices aren’t necessarily best for network function virtualization in any form; they tend to be oriented toward IT and applications.
It is true that there are orchestration (DevOps), administration, and security measures appropriate to the design, development, and deployment of the Open RAN elements. There are the same issues with VNFs, or management system components, or any other piece of software that’s used in a network service application. Again, the solution to any Open RAN issues would be to address the issues for everything that’s software-implemented in 5G, NFV, OSS/BSS, NMS, ZTA, and all the rest. We don’t even know at this point whether cloud solutions to deployment like Kubernetes, or for event movement like a service mesh (Istio) could fully address the requirements of a network implementation. Do we think that this means that we should turn back the clock to the network equivalent of the Old Stone Age and commit to a future of bearskins, stone knives, and network appliances?
So, is this a cynical play or a real definition of issues? Both. On the one hand, there is nothing in Ericsson’s blog that IMHO points to an Open RAN-specific problem with security. What they’re saying is that if you’re stupid enough to fail to secure your own control and management interfaces, Open RAN will add to the things you’ve been stupid about. True, but in a security sense, not relevant, which brings us to the other hand. 3GPP, NFV, SDN, and just about every other initiative in the telco space for the last decade, has played fast and loose with the question of how you isolate the critical control- and management-plane functions. If they’re even addressable in the data plane, it’s a problem, period. Even if they’re not, there needs to be a barrier between the components that could be provided as part of a service, and the components that are part of the service infrastructure.
I’ve complained about the lack of address space discipline in many of my blogs, relating most often to NFV (Ericsson was a member of the NFV ISG and they didn’t stand up in support). There’s a general tendency among telco people to ignore the issue, and I think it’s been ignored in the 3GPP too. Any service control plane or “Level 3 control plane” (the two are different; in 3GPP 5G terms, the “user plane” is the Level 3 data plane and control plane and the “control plane” is a higher-level 5G layer) should be separate from the data/user plane. That can be accomplished through maintaining them in a separate address space (one of the RFC1918 private IP addresses) or by defining a virtual private network or SD-WAN.
That same thing holds true for software elements and their deployment. If you have a lazy process of development and certification for security and compliance, nobody has to attack you from the outside, they can simply sell a piece of malware into your framework and let it eat everything from the inside out. A new generation of parasitism? That’s not what we should be doing, but Open RAN doesn’t create the risk.
It may be true that the Open RAN stuff adds interfaces and APIs and even components to the threat surface, but there are more than enough interfaces there already to constitute a threat, and I don’t think that Open RAN increases the threat level in any meaningful way. It’s surely true that if one were to apply address-space or virtual-network separation for the control layers of 5G, however it’s implemented, the result would protect all those interfaces/APIs and defend the threat surface universally, as long as you didn’t for some inexplicable reason keep some of the interfaces outside the scope of your remedy.
There are two lessons to be learned from Ericsson’s paper, I think. First, these are troubling times for network operators and network equipment vendors, and in those situations, we have to be particularly wary of any statements or documents that clearly serve vendors’ interests, even if they’re couched in service-to-the-industry terms. Vendors have always had blinders on with respect to things that touch their bottom lines, just as pretty much everyone else has always had. If this is a surprise to anyone, welcome to the real world.
The second lesson is more important. In the network operator or telco space, we are seeing a movement to the cloud that’s guided by bodies and people who don’t really understand the cloud. That’s perhaps understandable too, because the technologists in both the vendor and operator spaces have focused on network-building as a task of assembling and coordinating boxes. Once you make an explicit commitment to virtualization and functions, you are entering a whole new world. Add in an explicit commitment to the cloud, and it’s immeasurably worse. This is a field for specialists, and those specialists rarely work for telcos or their vendors.
At some point, the networking community is going to have to make a choice. They can keep blundering around in the pseudo-cloud world they’ve created, a world that bears little resemblance to the real cloud world. They can sit back and wait for the real cloud world to solve the problems of virtualized networking, either as a mission or by accident. Or…they can learn enough about the real world of the cloud to guide themselves to their own best outcome. The real message of the Ericsson complaint about Open RAN security is that it’s time to make that choice, or it will be made by default, and not in the optimum way.
I don’t want to beat Ericsson up unfairly on this; every single major network vendor engages in at least a subtle marketing sabotage campaign on threatening initiatives. I’ve seen real arguments between vendors and operators at standards meetings, around points that would threaten a vendor’s incumbency in the name of openness. I also want to note that the actual Ericsson blog is more a qualified list of concerns than the kind of overt attack on Open RAN that many stories on it described. Still, if the goal of the piece was to call attention to the risks of virtual infrastructure, it should have been done in a more general and constructive way.