对OpenFlow下的一种网络安全应用模型(OFX)的思考

最近有时间学习了一篇发表在NSDI’16的叫做 ”Enabling Practical Software-defined Networking Security Applications with OFX “的文章,文中提出的一种叫做OFX的基于OpenFlow的网络安全应用模型,考虑到这篇文章所提出的OFX模型与FAST在思想上有很多相通之处,所以再次将这篇文章的核心内容进行整理并将与FAST对比产生的一些思考记录下来。

研究背景

目前SDN已经成为了安全领域的研究热点,很多研究人员都在考虑以SDN作为平台应当如何部署网络安全应用。但是目前在SDN安全领域的研究有两个绕不开的坎:一是处理和转发性能差、二是整体部署难度大。处理和转发性能差体现在:目前多数研究中安全应用软件运行在控制器上,这很容易在控制平面与交换平面之间产生性能瓶颈。而部署难度大体现在:为了解决性能瓶颈的问题,部分研究人员也提出了将部分安全分析处理功能卸载到数据平面进行处理,也就是很多人提到的对数据平面进行“智能化”。但是这种方案一般要求对SDN交换机硬件平台及OpenFlow协议本身做出一定修改,并且这种方法也无法支持所有的安全应用,这就有可能会出现数据平面多样化和复杂化的情况,使得网络发展出现退化的趋势。在这篇关于OFX(OpenFlow eXtension framework)文章中,作者利用openflow交换机的处理能力在现有的openflow框架下将安全功能卸载到Openflow交换机的软件层面,既利用交换机较强的处理和转发能力解决了控制平面与数据平面间通信瓶颈的问题,使其转发速率更加接近线速转发,也充分利用了现有的openflow框架,不修改或增删任何硬件模块,使其在实际部署中也较为方便。另外,作者针对Silverline(ACSAC’13),BotMiner(Sec’08)和AVANT-GUARD(CCS’13)这三种安全机制在Pica8 3920交换机与Ryu控制器所组成的SDN网络中依照OFX框架上做了部署,并同时也搭建了部署上述三种安全机制的传统SDN拓扑环境,通过一系列实验,得到了如下结果:与在传统openflow网络中部署上述三种安全机制进行对比,在OFX的框架下,网络的整体转发性能提高了20-40倍。这在性能上是一个质的飞越。

核心思想

发表在NSDI’16上的这篇文章提出了一种叫做OFX的扩展架构以解决可部署性和转发性能两个重要问题。其主要思想是保持现有openflow交换机硬件平台不改变的情况下,将原先在控制器上运行的安全应用机制和处理逻辑卸载到数据平面上,利用数据平面高性能的报文处理能力实现对SDN中网络安全应用性能的极大提升。

OFX基本架构

OFX的全称是OpenFlow eXtension,它的架构图如下图所示。下图中,右边展示了OFX扩展模块逻辑组成,左边则展示了这几个部分在SDN中所处的位置和运行机制。

从整体上看,OFX Module是需要部署到网络中的网络安全应用的功能代码(包含需要分别部署在控制平面和数据平面的module),而interface则指定了运行在控制平面的应用软件调用module的接口,Controller handler和Switch handler则是分别在控制平面和数据平面运行module中处理方法的句柄。加载在控制平面的OFX library包含了interface和controller handler两个部分,从而可以被应用软件调用进行对OFX modules进行加载和管理。数据平面的上层是一个叫做OFX switch agent的代理。作为交换机Linux内的守护进程,它对整个交换机的工作进行调度和分配,同时还要处理控制器和交换机上module间的通信(在OpenFlow协议封装下)。OFX data plane agent在OFX switch agent的调度下执行packet handler,这里的packet handler就是卸载到交换机中的那部分module中所提供的对报文的处理方法。当开发者需要在OFX中开发一种应用时,首先需要定义这几个部件:

module interface: 一旦module在控制平面和数据平面加载完成后可供控制平面安全应用软件调用的接口。

control message: 控制器与交换机之间交换信息的消息体。用于提供控制器向下调用卸载在交换机上的功能或交换机向控制器返回执行状态信息的数据通路。需要指出的是这些消息都封装在OpenFlow1.3.0 Experimenter Messages中,所以无需对现有的openflow协议进行扩展。

switch handler: 一旦交换机收到一条加载在其上的module所定义的message,OFX Switch Agent将会调用message所属module的switch handler进行处理。

controller handler:而一旦控制器收到一条来自交换机的message,同样会调用该message所属的module中的controller handler进行处理。

packet handler:packet handler首先要根据OFX Switch Agent所提供的接口在其中进行注册,然后才可根据module的要求对交换机所收到的报文进行处理。

startup functions: OFX module在控制平面和数据平面加载时需要预先运行的代码。

下表展示了OFX Module API提供的用于控制平面与交换平面通信等多种功能的API:

Function Description
MessageSwitch(Message,SwitchID)
MessageController(MessageContent)
AddInterceptFlow(MatchPattern)

AddTapFlow(MatchPattern)

AddNegativeInterceptFlow(MatchPattern)
AddNegativeTapFlow(MatchPattern)
GetFlowStats(FlowIdList)
RemoveFlows(FlowIdList)
SendPacketIn(Packet)

从某个module的控制器部件向交换机部件发送一条消息。
从某个module的交换机部件向控制器部件发送一条消息。
注册一个packet handler,一旦报文匹配到该MatchPattern,则packet handler接收该报文并进行处理。
注册一个packet handler,一旦报文匹配到该MatchPattern,则packet handler复制该报文并对复制的报文进行处理。
与AddInterceptFlow(MatchPattern)功能相反。
与AddTapFlow(MatchPattern)功能相反。
获取module通过OFX加入到流表中的规则的状态信息。
删除module通过OFX添加到流表中的规则。
由OFX Switch agent向控制器的packet_in handler发送一条消息,该API允许OFX module在交换机发送前对packet_in消息进行处理和过滤。

需要注意的是在数据平面上,OFX Switch Agent作为管理进程调度整个交换机的运转,它的工作包括:作为代理进行OpenFlow management和控制器间的OpenFlow通信,在交换机上加载OFX module,管理流表并将所需的报文定向到已在Agent注册过的packet handler上进行处理等。

另外,为了符合安全设备应当先于转发设备对报文进行处理的原则,OFX提出了它的流表管理机制(Flow Table Management)。限于篇幅,这里只介绍它的核心思想:除了硬件上所维护的一张转发表外,OFX还在软件层面维护另外4张流表,如下图:

也就是说,在报文到达硬件上的流表进行匹配之前,首先要在软件层面针对OFX module中的安全规则做Match操作。若匹配到则将报文送至包含了packet handler的OFX Data Plane Agent来进行处理,之后再将报文(若符合安全规则)则送至硬件的OpenFlow转发表进行正常转发。

最后,作者还将AVANT-GUARD(CCS’16)中的两种安全机制在OFX中进行了部署,实验显示出其可完成AVANT-GUARD中的安全功能,而这一切都是在未对硬件进行任何改变的情况下进行的。

总结(优缺点/可研究方向)

优:如文中所言,OFX所解决的两个主要问题是性能问题和易部署性的问题。性能问题目前最通用的解决方案就是将部分控制器中的功能卸载到数据平面从而节省了时延开销和南向通信的带宽消耗,这一点上OFX与大部分的解决方案保持了一致;而虽然OFX对数据平面进行了扩展,但是由于所有的扩展都集中在数据平面的软件部分(在文章中作者使用了Pica8 OpenFlow交换机的基于轻量级Linux内核的软件部分),所以直观上讲易部署性也可以得到保证。

另外,OFX还有一个突出优点是提出了一种在SDN中进行网络安全应用部署的设计规范。目前在SDN安全领域,已经出现了很多算法与机制。但是还缺少一种模型来规范如何就将这些算法与机制高效、合理地部署在实际SDN中。从而既减少部署难度,又能满足高性能的要求。另外,作者还以OFX为规范在OpenFlow网络中对AVANT-GUARD(CCS’13)、防火墙、蜜罐等几种典型的网络安全应用进行了部署与验证,也从一定程度上证明了OFX的可行性。可以说,OFX为以后的SDN安全和SDN网络管理领域的研究提供了一个很好的思路。

不足:作为一种SDN安全应用部署模型的探索,个人认为OFX也存在以下几点不足:

首先,存在安全应用是需要对交换机硬件平台做出修改的,如果部署这种安全应用,OFX就无能为力了。其次,由于OFX在交换平面的实际工作借助于Pica8交换机实现,在其与其他公司的ASIC交换芯片的适配性上可能存在一些问题。

与FAST的比较

通过对OFX模型的介绍可以发现,OFX与FAST之间存在很多相似之处:比如两种机制都希望通过将网络功能拆解为子模块并分别加载到网络中不同位置从而实现高性能和易部署的统一;同时,在数据平面,两者都希望借助软件(或被称作交换机操作系统)来实现数据平面的管理功能,并借助常驻内存的守护进程(对应FAST UA模块中的管理单元)完成整个交换机的业务流程的调度和管理。另外,虽然OFX的设计初衷是为了解决SDN中网络安全应用的部署问题,但是与FAST相同,其应用场景拓宽来讲并不局限在安全领域,两者都有能力作为网络测量、网络管理软件等众多网络功能的部署平台。但是,两者的区别也显而易见,我们对FAST与OFX的区别也进行了分析:

1.两者最大的区别体现在OFX基于ASIC交换机,而FAST的底层硬件平台的FPGA,在可重构性上两者有巨大的差别。在FAST的《UM设计规范.0》中介绍过,FAST的UM模块(硬件平台)的最大特点是流水线的可重构性,开发者可根据需求利用对报文处理流水线进行重构。FPGA硬件平台的这种“离线重构”的能力赋予了FAST架构更大的灵活性。倘若未来新的网络功能要求必须对硬件处理逻辑进行修改,则将必须借助FPGA的可重构性来实现。

2.考虑到控制平面本身的灵活性和已经百花齐放的局面,FAST重点所关注的是SDN数据平面的设计与重构;而OFX虽然核心关注点在于数据平面,但是将控制平面与数据平面作为OFX模块的逻辑整体来进行考虑与设计,使得新型网络安全或其它功能的逻辑实体更加完整,也就是说,对于新型应用设计与开发时,在数据平面和控制平面配套进行,这一点可能也是FAST未来可能关注的地方。

3.最后,OFX更像是一种模型,而FAST则是一种符合OFX模型的设计原则的实例。目前,FAST拥有自己的开源社区和UA/UM模块的开发规范与指南,支持开发者根据设计规范进行开发和研究,同时目前也已经实现了许多基于该平台的demo并且在开源社区中开放共享。

目前,OFX的作者宾夕法尼亚大学的博士生John Sonchack正在OFX框架下进行新的安全应用的设计与研究(the Defense of Timing Attack)。下一步,我们也将会考虑对FAST在SDN安全领域的应用进行探索和实践。

参考文献
1.John Sonchack, Adam J. Aviv, Eric Keller, and Jonathan M.Smith. Enabling Practical Software-defined Networking Security Applications with OFX. In NSDI’16, 2016.

2.Seungwon Shin and Vinod Yegneswaran and Phil Porras and Guofei Gu. Avant-guard: Scalable and vigilant switch flow management in software-defined networks. In Proceedings of the 20th ACM Conference on Computer and Communications Security (CCS13), November 2013.

3.BigSwitch.Bigtap: Monitor traffic everywhere. http://www.bigswitch.com/products/big-tap-network-monitoring/.

4.FAST开源社区:FAST技术白皮书. http://www.fastswitch.org/

作者简介:杨翔瑞,国防科技大学计算机学院计算机科学与技术硕士研究生,研究方向:SDN安全、SDN数据平面可编程

来源:FAST开源社区


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/18436.html
分享到:
相关文章
条评论

登录后才可以评论

SDNLAB君 发表于17-01-23
0