近日，爱立信官网发布了一篇名为《Security considerations of Open RAN》的文章，引起业内人士广泛转发。
文中指出，随着行业向vRAN和O-RAN发展，采用基于风险的方法来充分解决安全风险非常重要。对于包括O-RAN的任何新兴技术，安全性在设计之初就应该完整构建，而不是事后再补。为了确保O-RAN能满足运营商安全级别，爱立信基于对O-RAN标准的参与和实践，指出其存在一些安全风险。
3GPP RAN架构与O-RAN架构的区别
如上图，3GPP R15引入了CU和DU分离的RAN架构，定义了CU-CP（控制面）和CU-UP（用户面）之间的E1接口，以及CU与DU之间的F1接口。
但O-RAN进一步开放前传接口，并在管理层和RAN新引入了Non-Real-Time RIC和Near-Real-Time RIC两个控制器，同时新增了A1、E2、O1、O2等接口。
从架构上不难看出，为了实现开放化和智能化，Open RAN架构更加复杂，这可能会增加如下安全风险。
开放前传接口安全风险
在传统RAN部署方式下，DU和RU来自同一厂家，DU和RU之间的前传接口由单厂家实现。而O-RAN采用7-2x开放前传接口，O-DU和O-RU可以来自不同的厂家。
当O-DU和O-RU来自不同厂家时，意味着O-DU不能完全控制O-RU，需要通过更高层的服务管理与编排层来辅助管理，这可能会带来通过前传接口向O-DU之上的北向系统发起中间人攻击的风险。
Near-Real-Time RIC安全风险
为了便于理解，我们先来科普一下O-RAN架构中的Non-Real-Time RIC和Near-Real-Time RIC这两个控制器，以及SMO（服务管理与编排）。
（O-RAN架构）
SMO，Service Management and Orchestration，类似NFV中的MANO，负责管理网络功能和NFVI基础设施，其包含的管理接口和管理内容如下：
O1接口：负责管理网络功能（vNF），包括配置、告警、性能、安全管理等。
O2接口：负责管理云平台（o-cloud）的资源和负载管理。
M-Plane接口：负责对O-RU管理。
RIC，全称为Radio intelligent controller，无线智能控制器。顾名思义，就是通过引入AI实现RAN运维自动化、智能化。
Non-Real-Time，指非实时部分，负责处理时延要求大于1秒的业务，比如数据分析、AI模型训练等。
Near-Real-Time，指近实时部分，负责处理时延要求小于1秒（50ms-200ms）的业务，比如无线资源管理、切换决策、双连接控制、负载均衡等。
Non-Real-Time RIC位于SMO内，通过从RAN和应用服务器收集全域相关数据，进行数据分析和AI训练，并将推理和策略通过A1接口下发、部署于Near-Real-Time RIC。
Near-Real-Time RIC位于RAN内，负责收集和分析RAN的即时信息，结合Non-Real-Time RIC提供的额外或全局信息，并通过Non-Real-Time RIC下发的推理模型和策略，实时监控和预测网络和用户行为变化，并根据策略（比如QoE目标）实时对RAN参数进行调整，包括调整资源分配、优先级、切换等。比如，预测到网络即将发生拥塞，Near-RT RIC根据推理实时调整网络参数以预防拥塞。
Near-Real-Time RIC中包含了多个xAPP。
（xAPPs与RAN功能的关系）
xAPP是可以由第三方独立部署的应用，它将AI推理模型和策略部署于其中，并且不同的xAPP与不同的RAN功能关联，从而使得RAN功能组件具备灵活的可编程性和可扩展性。
总之，O-RAN通过引入Non-Real-Time RIC和Near-Real-Time RIC，两者合力可基于AI对网络负载均衡、移动性管理、多连接控制、QoS管理、网络节能等功能进行主动优化和调整，最终实现网络智能化、自动化。
但对于这样的架构，爱立信指出，O-RAN中的Near-Real-Time RIC存在潜在的安全漏洞，包括Near-Real-Time RIC与gNodeB冲突、xAPPs冲突、xAPP信任根、RIC中的UE标识等问题。
Near-Real-Time RIC与gNodeB冲突
由O-RAN架构可知，Near-Real-Time RIC作为一个逻辑实体，或者说由多个xAPPs组成的软件平台，其部署于gNodeB（CU-CP、CU-UP和/或DU）之上。
Near-Real-Time RIC可通过E2接口在xAPPs与gNodeB之间交换数据，来实现每个xAPP控制一个或多个RRM（无线资源管理）功能。比如，Near-Real-Time RIC可以通过E2接口让特定的xAPP与CU-CP之间交换数据来控制移动性和负载均衡。
但问题来了，Near-Real-Time RIC控制RRM功能，gNodeB也执行RRM功能，两者之间没有明确的功能界限划分，这可能造成Near-Real-Time RIC和gNodeB供应商之间存在决策冲突，从而可能导致网络不稳定，甚至带来攻击者可以利用的漏洞，比如，攻击者可以利用恶意的xAPP故意触发与gNodeB内部相冲突的RRM决策而导致服务拒绝。
xAPPs冲突
Near-Real-Time RIC中的xAPPs可以由不同的供应商提供，比如，一家供应商可提供用于移动性管理的xAPP，另一家供应商可提供用于负载均衡的xAPP。
除非能做到完美协调，否则不同xAPP可能会做出相互冲突的决策，比如，用于移动性管理的xAPP和用于负载均衡的xAPP，在同一时刻为同一用户触发了不同的切换决策，该听谁的？这可能会引发无线链路故障风险。
在O-RAN规范中已指出xAPPs之间存在以下可能的冲突：
直接冲突：不同的xAPPs请求修改同一参数。
间接冲突：不同的xAPPs请求修改不同的参数，但修改这些参数会产生相反的效果，比如天线下倾角和测量偏移。
隐式冲突：不同的xAPPs请求修改不同的参数，这些参数不会产生相反的效果，但可能会导致网络整体性能下降。
由于xAPPs冲突会导致网络不稳定或性能下降，攻击者就可能会利用这个漏洞来攻击网络，令网络存在安全隐患。
xAPP信任根
Near-Real-Time RIC中的xAPP具有处理特定小区，一组UE，以及特定UE的行为的能力。简单的说，xAPP可以追踪某个特定用户，并可以通过从A1接口接收命令设定特定UE的优先级，这存在VIP用户的大致位置和优先级设置会通过故障xAPP暴露或恶意更改的潜在风险。因此，为了减轻这些风险，需要从硬件到应用程序建立牢固的信任链。
此外，爱立信在文章中还指出软硬件解耦增加了对信任链的威胁，以及开源代码增加了漏洞的暴露等其他安全隐患。
对于这些问题，爱立信认为，随着RAN向虚拟化、开放化发展，行业应该采用全新的方式来处理安全性，并表示将继续在O-RAN联盟中发挥领导作用，整合安全最佳实践，以确保O-RAN满足运营商的安全级别。
爱立信于2018年12月申请加入O-RAN，2019年2月正式加入O-RAN，并在O-RAN工作组中占有两个主席职位。作为O-RAN的主要成员之一，爱立信基于对O-RAN的深入研究，在今年3月份主持的一次Open RAN网络研讨会上，也提出了以上类似的观点。
在会上，爱立信O-RAN Program Manager Per Emanuelsson指出，由于O-RAN引入了Non-Real-Time RIC、Near-Real-Time RIC和更多开放接口，存在以下挑战：
1）Non-Real-Time RIC和A1接口
尽管通过Non-Real-Time RIC和A1接口，可收集包括核心网、传输网和应用等更广域的数据，并实现闭环的自动化网络等，但存在用例不清晰、价值不明确等问题。
2）Near-Real-Time RIC
Near-Real-Time RIC包含了多个xAPP，需一组xAPP与CU-CP（CU的控制面）交互完成无线管理决策，比如切换，这可能会带来以下问题：
xAPP之间发生冲突
不同的xAPP同时运行于相同的无线资源和UE，要实现在ms级内相互协作是一大挑战。
xAPP与CU-CP冲突
像切换、负载均衡等无线资源管理功能，本身是相互强关联的，而O-RAN将这些功能模块通过xAPP的方式拆分部署于Near-Real-Time RIC和CU-CP中，这并不是最优的选择。
3）开放的前传接口
爱立信认为，开放前传接口后，运营商可以从不同的设备商购买DU和RU设备，有助于扩大产业生态。
但存在以下挑战：
增加测试和集成工作量
会明显降低RAN性能
4）云化RAN
云化RAN解耦了硬件和软件，并将软件部署于标准的COTS硬件之上（至少部分是COTS硬件），有利于组成资源池，扩大供应商生态。
但存在以下挑战：
相比专用硬件，性能会下降
设备功耗会增加
本文参考：
Security considerations of Open RAN，Ericsson
O-RAN overview，Per Emanuelsson，Ericsson O-RAN Program Manager
如有翻译和理解不当之处，请留言指正。
通信路上，一起走！
