设为书签 Ctrl+D将本页面保存为书签,全面了解最新资讯,方便快捷。 您也可下载桌面快捷方式。点击下载 | 新浪科技 | 新浪首页 | 新浪导航

爱立信:O-RAN存在的安全风险

2020-08-23 23:27:08    创事记 微博 作者:   

近日,爱立信官网发布了一篇名为《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硬件),有利于组成资源池,扩大供应商生态。

但存在以下挑战:

• 相比专用硬件,性能会下降

• 设备功耗会增加

(声明:本文仅代表作者观点,不代表新浪网立场。)

分享到:
保存   |   打印   |   关闭