2019, Vol. 45
b. 湘潭大学 信息工程学院, 湖南 湘潭 411105
b. College of Information Engineering, Xiangtan University, Xiangtan, Hunan 411105, China
软件定义网络(Software-Defined Networking, SDN)是一种新兴的网络体系结构, 它能够实现控制逻辑与转发功能的分离, 并采用集中式的控制方式, 向上层应用提供开放的可编程接口。这种设计模式简化了交换机的设计、网络协议的部署和网络策略的更新, 因此, 得到了广泛的应用[1-3]。谷歌通过在它的数据中心网络中部署SDN技术, 将链路带宽利用率提高到了近100%[4]。
尽管SDN取得了较大的成功, 但是这种体系结构也带来了新的安全威胁, 比如SDN中的DoS攻击[6]、网络拓扑投毒攻击[7]和标识符绑定攻击[8]等。SDN将网络设备中的控制逻辑分离之后, 采用集中式的方式控制整个网络。因此, 控制器成为整个网络的大脑, 也是最有价值的攻击目标。目前大多数SDN安全问题的研究都集中在控制器方面。比如FloodGuard[6]、AVANT-GUARD[9]和FloodDefender[10]等都是用来防御控制层的DoS攻击。但与此同时, SDN数据平面的安全问题并没有得到广泛关注。
在SDN网络中, 控制功能从转发设备中分离, 交换机只需负责完成数据包的转发以及与控制平面的通信。交换机中的所有控制逻辑都集中在控制代理组件中, 控制代理则运行在交换机CPU硬件上。此外, 原来需要许多硬件支持的机制, 如交换机端口安全、路由器中的路由协议等都在控制器中实现。这种方式极大地简化了SDN交换机的设计, 并降低了对交换机硬件配置的要求。因此, 多数交换机都使用了性能一般的ASIC芯片来实现数据包的转发。此外, SDN交换机还使用了低端的CPU来完成与控制平面的通信。比如Pica8的P-3297交换机使用的ASIC芯片是Triumph2, CPU是P2020。
SDN交换机的这种设计方式在数据平面和转发平面分离之后是合理的, 不仅节约了成本也能够满足网络和用户的需求, 但同时也带来了潜在的安全威胁。当交换机中没有对应的流表项匹配网络中的数据包时, 由交换机控制代理将这些不匹配的数据包封装成Packet-In消息发送到控制器请求处理。同时, 控制代理通过解析控制器下发的Flow-Mod和Packet-Out消息来完成流表的安装和数据包的转发。在这种情况下, 攻击者可以通过构造大量的不匹配数据包消耗交换机控制代理资源。一旦交换机控制代理过载, 将显著降低交换机的转发性能, 影响网络的正常运行。此外, 由于控制代理运行在交换机CPU之上, 而目前的硬件交换机普遍使用了低端的CPU, 降低了对交换机控制代理发起攻击的门槛。
针对以上问题, 本文设计一种交换机控制代理拒绝服务攻击, 并提出一种攻击检测算法。通过硬件实验环境, 分析攻击方法的可行性, 并在Floodlight控制器中对算法的有效性进行了验证。
1 相关工作目前, 国内外学者对SDN体系结构的安全问题研究已经取得了一些成果。其中, 数据平面的安全研究主要集中在主机、交换机和链路这些组件上。文献[7]提出数据平面的主机位置劫持攻击和链路虚构攻击, 并在此基础上实现了流量窃听、拒绝服务攻击和中间人攻击, 为了检测这些攻击并保护数据平面资源, 设计并实现了TopoGuard系统。文献[12]提出一种交换机流表容量和使用率推理攻击模型, 通过推理结果发起流表溢出攻击。文献[13]提出一种通过控制器中可疑应用程序和非法数据包发起流表溢出攻击的方法, 并设计一种动态的基于时间驱动的流表溢出攻击缓解策略。文献[14-15]研究SDN数据平面侧信道攻击, 并提出一些认证和授权策略来避免侧信道攻击。
尽管这些解决方案都能在一定程度上提高SDN数据平面的安全性, 但是交换机控制代理这一关键元素的安全性研究并没有得到关注。在现有的研究中, 文献[11]提出控制代理的性能瓶颈问题。通过研究发现, 交换机控制代理的吞吐量非常有限, 当交换机在处理高负载流量、突发流量或者DoS攻击流量时, 将会导致交换机处理能力显著下降, 为此, 提出Scotch架构, 即利用软件交换机控制代理吞吐量高的特点, 使用叠加(Overlay)网络的方法, 将硬件交换机的负载转移到软件交换机上以增强交换机控制代理的处理能力。Scotch虽然能够在一定程度上扩展交换机控制代理的处理能力, 但是需要额外技术手段(如在交换机之间建立隧道)的支持。此外, Scotch没有考虑交换机控制代理的安全性, 即这种方案无法检测针对交换机控制代理的拒绝服务攻击, 也无力应对交换机控制代理DoS攻击。
本文的主要贡献如下:
1) 提出针对交换机控制代理的DoS攻击, 并在物理实验环境下证明了攻击的可行性, 分析了攻击所产生的影响。
2) 给出一种层次化多阈值的交换机控制代理DoS攻击检测算法, 通过实验证了该算法的有效性。
3) 通过2种缓解交换机控制代理DoS攻击的防御策略, 以应对不同程度的控制代理DoS攻击。
2 交换机控制代理拒绝服务攻击 2.1 SDN交换机原理SDN中有2种类型的OpenFlow交换机, 即硬件交换机和软件交换机, 这2种交换机的设计原理遵循OpenFlow协议。
硬件OpenFlow交换机的主要应用场景是数据中心网络、骨干网和校园网, 是构建SDN物理网络的核心组件。硬件OpenFlow交换机的架构如图 1所示, 主要组件包括流表和OpenFlow控制代理。OpenFlow交换机在处理数据包时, 首先将数据包的指定字段与流表中的表项进行匹配。一旦匹配成功, 数据包按照流表项中的相关指令进行转发, 这个过程需要交换机中的ASIC芯片支持。当交换机中不存在与数据包匹配的表项时, 数据包的转发需要请求控制器进行处理。此时, OpenFlow控制代理将不匹配的数据包封装成Packet-In消息并转发到控制器。同时, 控制代理通过解析控制器下发的消息, 实现对交换机的控制。OpenFlow控制代理的主要组件是ovs-vswitchd进程, 运行在交换机CPU上, 所有不匹配数据包的处理过程都通过该进程进行处理。因此, OpenFlow交换机对不匹配数据包的处理能力主要取决于控制代理的吞吐量。此外, 由于控制代理运行在交换机CPU上, 因此交换机CPU的处理能力很大程度上决定了控制代理的吞吐量。
|
Download:
|
| 图 1 OpenFlow交换机架构 | |
软件OpenFlow交换机主要部署在云计算和hypervisor平台中, 是构建SDN虚拟网络的核心组件。在实际应用场景中, 使用最广泛的软件交换机是Open vSwitch, Open vSwitch架构如图 2所示[4]。Open vSwitch的主要组件包括运行在内核中的数据通道和流表以及运行在用户空间的ovs-vswitchd进程和ovs-db数据库、ovs-ofctl等管理工具。数据通道从物理网卡或者虚拟网卡处获取网络中的数据包, 并根据流表信息实现对数据包的转发。ovs-vswitchd进程根据ovs-db中的信息确定数据包转发路径, 实现对不匹配数据包的转发。因此, 软件交换机对不匹配数据包的处理能力主要取决于运行Open vSwitch交换机的虚拟机或主机的配置。在通常情况下, Open vSwitch交换机控制代理的吞吐量高于硬件交换机控制代理的吞吐量。但是, Open vSwitch交换机控制代理的吞吐量是有限的, 在交换机控制代理DoS攻击下, 也会成为网络的性能瓶颈。
|
Download:
|
| 图 2 Open vSwitch架构 | |
针对交换机控制代理吞吐量有限的不足, 本文提出一种控制代理拒绝服务攻击模型。如图 3所示, 主机A、B和攻击者控制的主机连接在SDN硬件交换机上, SDN控制器运行在服务器上并使用OpenFlow协议与交换机进行通信。假设攻击者可以通过恶意软件控制SDN网络中的一个或者多个主机, 并且拥有该主机对数据包的操作系统级读写权限。这种假设与文献[6-7]一致, 也是合理的。
|
Download:
|
| 图 3 交换机DoS攻击模型 | |
攻击者通过控制网络中的主机, 在短时间内构造大量交换机无法匹配的数据包发送到交换机中。交换机在处理这些数据包时, 首先通过控制代理将这些数据包封装起来, 以Packet-In消息的形式发送到SDN控制器请求处理。控制器通过解析Packet-In消息, 并根据自身运行的网络策略和路由算法, 确定数据包的转发路径。通常, 在控制器中没有攻击者所构造的这些数据包的目的地址信息。因此, 控制器将向交换机控制代理发送一个Packet-Out消息, 显示的命令交换机将该数据包从除入口以外其他所有端口洪泛。同时, 控制器还会下发一个Flow-Mod消息到控制代理中, 将与该数据包相关的流表项安装到交换机中。因此, 攻击者在短时间内注入的这些数据包会产生大量的Packet-In、Packet-Out和Flow-Mod消息, 这些消息的处理会给交换机控制代理带来极大的负载开销。由于终端主机的CPU和运行控制器的服务器CPU处理能力都远远超过交换机CPU的处理能力, 因此这种硬件资源的不对称性使得运行在交换机CPU上的控制代理很快满负载运行。一旦交换机控制代理过载, 当主机A中的合法流量需要通过交换机请求控制器进行处理时, 交换机控制代理无法将该请求送到控制器, 从而导致拒绝服务攻击。
在上述攻击模型中, 实现交换机控制代理DoS攻击的关键在于, 将构造交换机无法匹配的数据包与正常的网络流量一起发送到交换机中。本文通过给数据包的目的IP地址和端口随机赋值, 将这些数据包与正常流量混合之后发送到交换机中来发起攻击。此外, 本文通过控制同一交换机下的多个主机对边缘交换机发起攻击, 也可以控制多个交换机下的主机对核心层的交换机发起攻击。由于SDN数据平面与控制平面通信的主要瓶颈在于交换机CPU, 且攻击流量能够成倍地增加控制代理的负载, 因此这种攻击方式能够以很小的代价达到攻击的目的。与针对SDN控制器和流表的DoS攻击方式相比, 这种攻击方式不仅攻击代价小, 而且简单、高效。
2.3 实例分析为证明交换机控制代理拒绝服务攻击的可行性, 并测试控制代理的吞吐量, 本文在物理网络环境下进行了一系列的实验。网络中的主机使用的是常规的台式电脑。交换机的型号是Pica8 P-3297, 控制器使用的是Floodlight1.2, 运行在一台机架式服务器上。服务器的基本配置信息包括:Ubuntu 16.04操作系统, 2颗Intel Xeon E5-2650 v2 CPU, 主频为2.6 GHz, 32 GB运行内存。在实验中, 交换机和控制器之间使用OpenFlow 1.3协议进行通信。实验过程中使用packETH来构造各种类型的数据包。packETH是一个图形界面和命令行结合的数据包构造工具, 本文可以在攻击者控制的主机上运行packETH, 随机地给数据包各个字段赋值。随后, 根据实验需求灵活地设置数据包的发送速率。此外, 本文使用命令行工具Top来测量交换机的负载状况。Top所测量进程的CPU占用率是指该进程运行所占用的CPU时钟周期数在总的CPU时钟周期数中所占的比率。在对称多处理(Symmetrical Multi-Processing, SMP)环境中, 进程CPU的占用率是运行该进程的所有CPU核心上的占用率的和。当CPU过载时, 进程的CPU占用率可能超过100%。
本文共进行了5组实验, 每组实验的攻击速率从100 package/s递增到500 package/s, 其他条件都保持不变。为了比较交换机在正常工作和攻击状态下的负载情况, 本文在启动测量的10 s之后以设定的速率发起攻击, 攻击持续60 s。同时, 为了观测控制代理DoS攻击对网络的持续影响, 本文还测量了攻击结束后60 s时间内的交换机CPU使用率。根据交换机的架构, 本文控制代理的主要组件是ovs-vswitchd进程。所以, ovs-vswitchd进程的CPU使用率能够直接反映交换机控制代理的负载状况。因此, 本文将ovs-vswitchd进程的CPU使用率提取出来, 其结果如图 4所示。
|
Download:
|
| 图 4 不同攻击速率下ovs-vswitchd进程的CPU使用率 | |
根据图 4可以得出以下结论:
1) 在攻击发起之前, 即网络处于空闲状态时, 交换机控制代理主要处理的是LLDP数据包, ovs-vswitchd进程的CPU占用率保持在7%左右的水平。
2) 当攻击发起时, ovs-vswitchd进程的CPU占用率呈现跳跃式增长, 并始终保持在200%左右。由于实验中使用的交换机CPU是双核, 因此在攻击过程中, 交换机控制代理满负载运行。
3) 在攻击结束后的60 s内, 交换机控制代理仍然保持在100%左右。这表明交换机控制代理在这段时间中还需要继续处理在交换机中累积的Packet-In请求消息。
为说明交换机控制代理DoS攻击给网络通信带来的影响, 本文测量了主机A与主机B在不同状况下通信的往返时延, 实验结果如图 5所示。在空闲状态下, 主机A、B之间的往返时延始终保持在1 ms左右。随着攻击速率的增加, 主机A、B之间的往返时延也逐渐增加。当攻击速率达到500 package/s时, 主机A、B之间出现了60%的丢包率。此时, 交换机控制代理已经无法正常处理A、B之间通信的数据包。在攻击结束之后的一段时间内, 主机A、B之间的通信恢复正常, 往返时延与空闲状态几乎相同。实验结果表明, 当交换机控制代理满负载运行时, 交换机无法及时处理网络中的流量请求。
|
Download:
|
| 图 5 不同攻击速率下的往返时延 | |
根据上文实验结果可知, 攻击者可以通过控制网络中的主机对交换机控制代理发起拒绝服务攻击。这种攻击将会导致以下后果:交换机CPU持续工作在高负载状态下, 会缩短它的使用寿命; 来自被攻击交换机下的正常网络请求无法及时得到响应。
3 层次化多阈值攻击检测算法针对SDN基础设施的DoS攻击是目前SDN安全研究的热点。在现有的研究中, FloodGuard[6]和FloodDefender[10]提出根据Packet-In消息的实时速率和基础设施的资源利用率(控制器CPU、内存、交换机缓存)来检测SDN中数据平面-控制平面饱和攻击, 但是没有给出具体的算法和阈值的设定方法, 也无法定位攻击发生的位置。FloodShield[16]使用源地址验证方法检测数据平面伪造的数据包, 无法应对目的地址伪造的流量。MinDoS[17]使用综合评价因子对所有交换机进行攻击评估, 但是在应对突发流量情况时, 可能会产生错误的评估结果。因此, 这些方法都无法快速检测并定位交换机控制代理DoS攻击。
在SDN中, 控制器在正常网络状况下接收到来自于OpenFlow交换机的Packet-In消息保持在一个较低的速率, 并且比较随机。但是, 在交换机DoS攻击状况下, 被攻击交换机会频繁地向控制器发送Packet-In消息, 消耗控制代理的资源。因此, 交换机在被攻击状态下Packet-In消息的速率相对较高, 并且在一段时间内都保持在一个较高的水平上。此外, 当网络中突发流量产生时, 来自于交换机的Packet-In消息的速率也会较高, 但是通常持续时间较短。为了快速检测交换机控制代理DoS攻击, 定位攻击发生的位置, 根据SDN网络中的这些特征, 本文提出了层次化多阈值攻击检测(Hierarchical Multi-threshold Detection, HMTD)算法。与上文提到的方法相比, HMTD算法的主要创新是通过使用两阶段的阈值, 既能快速响应网络状态的突变, 也能快速地定位攻击可能发生的位置。
算法1 层次化多阈值攻击检测算法
输入 Packet-In消息M, 控制器接收的Packet-In消息的数量Count, 控制器接收的Packet-In消息的速率CurrentRate, 由交换机端口发送的数据包所导致的Packet-In消息的速率SwitchRate, 控制器接收Packet-In消息的阈值δ1, 交换机端口数据包导致的Packet-In消息阈值δ2
输出 数据包操作指令C(Command)
1.Count=0, CurrentRate=0, SwitchRate=0
2.for each M do
3.Count++
4.if Count % N ==0 then
5.CurrentRate = Compute_Controller_Packet-In_Rate()
6.if CurrentRate > δ1 then
7.SwitchRate = Compute_SwitchPort_Packet-In_Rate()
8.if SwitchRate > δ2 then
9.Logger.info(“Warn!!!”)
10.return Command.stop
11.end if
12.end if
13.else
14.return Command.continue
15.end if
16.end for
算法1描述了交换机DoS攻击检测的原理, 其基本步骤如下:
步骤1 初始化Packet-In消息计数器数量Count、控制器端的Packet-In消息速率CurrentRate和交换机各端口上报的Packet-In消息的速率SwitchRate(第1行)。
步骤2 当控制器接收到Packet-In消息时, 首先更新计数器Count的值(第2行、第3行)。控制器每收到N个Packet-In消息时, 计算控制器端的Packet-In消息速率CurrentRate(第4行、第5行)。
步骤3 当CurrentRate的值超过给定阈值δ1时, 计算每个交换机各端口上报的Packet-In消息的速率SwitchRate(第6行、第7行)。
步骤4 如果SwitchRate的值超过了给定的阈值δ2, 控制器将在终端发出消息, 告知网络管理员可能发生了交换机控制代理DoS攻击(第7行~第11行)。
需要注意的是, N、δ1和δ2的取值决定了攻击检测的准确度。本文根据网络的规模和流量请求等信息来设定N的值, 使计算的结果能够更加准确地反映网络中的负载变化。δ1的值应该根据网络中交换机的数量、交换机控制代理的吞吐量和控制器的处理能力来设置。如果δ1的值取得太大, 一些低速的DoS攻击不能被检测。如果δ1的值太小, 也会影响算法的执行效率。同样地, δ2的值应该根据交换机端口的数量、交换机控制代理的吞吐量和网络中流请求的分布情况来设置。
本文给出一个N、δ1和δ2取值的参考方法。假设网络中有n个OpenFlow交换机, 其中第i个交换机si的控制代理的吞吐量为Tsi, 端口数量为m, 控制器的吞吐量为C。本文可以根据网络中的历史流量数据求得过去一段时间中第i个交换机的平均Packet-In数量fsi。本文假设控制代理或者控制器的吞吐量超过80%时, 需要对Packet-In进行检测。因此, N、δ1和δ2的取值可以分别根据式(1)~式(3)来确定。在实际网络应用的过程中, 本文还可以根据网络运行的状况, 设计一些优化算法来动态地调整N、δ1和δ2的值。
| $N=\sum\limits_{i=1}^{n}{{{f}_{{{s}_{i}}}}} $ | (1) |
| $ {{\delta }_{1}}=\text{min}\{0.8\sum\limits_{{i=1}}^{n}{{{T}_{{{s}_{i}}}}, 0.8C}\} $ | (2) |
| $ {{\delta }_{2}}=\text{min}\left( \frac{\sum\limits_{i=1}^{n}{{{f}_{{{s}_{i}}}}}}{nm}, \frac{0.8\sum\limits_{i=1}^{n}{{{T}_{{{s}_{i}}}}}}{nm} \right) $ | (3) |
为验证HMTD算法的有效性, 本文在Floodlight控制器中实现了HMTD算法, 并在物理交换机环境进行了测试, 实验环境和硬件参数与2.2节一致。根据拓扑结构和交换机控制代理的吞吐量, 本文将N的值设置为500, δ1的值设置为400, δ2的值设置为50。即控制器每收到500个Packet-In消息计算一次Packet-In消息到达控制器的速率, 当CurrentRate值超过400时, 本文判断需要对网络中的Packet-In消息进行进一步的分析来确认是否发生了DoS攻击。此时, 根据算法1中的描述计算SwitchRate的值。如果SwitchRate的值大于50, 本文认为该交换机端口产生了针对交换机CPU和控制代理的拒绝服务攻击。
在实验中, 本文依然通过控制与交换机直连的主机, 使用packETH构建数据包发送到交换机中, 数据包发送速率设置为400 package/s。控制器在启动时启用switchdefense模块, 实验结果如图 6所示。当交换机数据包发送速率为400 package/s时, 在控制器一端计算的CurrentRate会超过400。因为网络中除了来自于主机流量的Packet-In请求之外, 同时还有其他的Packet-In请求消息, 比如包含了LLDP数据包的Packet-In消息。根据算法1, 会进一步计算交换机每个端口所产生的Packet-In请求。由于攻击产生的数据包都是从同一个交换机端口发送到网络中, 因此该端口的SwitchRate也会超过50。所以, 算法1会通过控制器终端发出警告信息, 告知用户网络中可能发生了交换拒绝服务攻击, 攻击流量可能来源于交换机<00:00:00:00:00:00:00:01>的1号端口。如果一段时间内switchdefense持续上报该端口的警告信息, 则认为该交换机端口发生了DoS攻击。实验结果表明, HMTD算法能够及时地发现可疑的DoS攻击并准确地定位到攻击的位置。
|
Download:
|
| 图 6 交换机DoS攻击检测结果 | |
当网络管理员接收到警告信息时, 本文提供2种方法来应对这种攻击。第1种方法是网络管理员可以通过下发流表的方式, 将该端口的流量定向到入侵检测系统进行深度分析, 以进一步确定是否发生该类DoS攻击。如果确认是攻击流量, 则将该交换机端口隔离, 阻止流量进入网络中。使用这种方法, 能够对交换机DoS攻击行为进行准确判断, 但是耗时较长, 也无法及时缓解针对交换机控制代理的DoS攻击。第2种方法是网络管理员在持续接收到同一个或者几个交换机端口的警告信息时, 通过下发流规则的方式在交换机一端直接丢弃随后一段时间内的网络流量。使用这种方式, 能够保证网络中其他位置的正常用户网络流量请求及时得到响应。但是, 可能导致可疑端口所连接的正常用户的流量请求无法得到响应。因此, 本文可以根据交换机控制代理的负载情况在不同的阶段部署这2种策略来应对交换机控制代理DoS攻击, 即交换机控制代理还没有达到饱和状态时, 使用第1种攻击防御策略, 否则, 网络管理员可以部署第2种策略来对抗这种攻击。
已有的方案在处理SDN基础设施DoS攻击时, 都是通过将Packet-In消息进行缓存, 再使用不同的调度策略处理Packet-In消息, 以达到缓解DoS攻击的目的。HMTD算法通过统计Packet-In消息的数量并计算其速率来实现对DoS攻击的检测。从理论上讲, Packet-In消息速率的计算所耗费的时间要远小于Packet-In消息缓存与调度的时间。因此, 该算法能够快速、实时地响应网络状态的突变。在攻击负载很大的情况下, 能够达到更好的效果。
5 结束语本文通过分析SDN交换机架构, 提出一种针对交换机控制代理的DoS攻击, 并设计一种层次化多阈值的攻击检测算法实时检测该攻击。同时, 给出2种不同的策略应对不同负载程度下的交换机控制代理DoS攻击。下一步将设计动态的阈值选取方法, 以准确检测控制代理DoS攻击并应对网络的动态变化。
| [1] |
MCKEOWN N, ANDERSON T, BALAKRISHNAN H, et al. OpenFlow:enabling Innovation in campus networks[J]. ACM SIGCOMM Computer Communications Review, 2008, 38(2): 69-74. DOI:10.1145/1355734.1355746 (  0)
|
| [2] |
GAO Xing, GU Zhongshu, KAYAALPP M, et al.ContainerLeaks: emerging security threats of information leakages in container clouds[C]//Proceedings of IEEE/IFIP International Conference on Dependable Systems and Networks.Washington D.C., USA: IEEE Press, 2017: 215-136.
( 0)
|
| [3] |
KOPONEN T, CASADO M, GUDE N, et al.Onix: a distributed control platform for large-scale production networks[C]//Proceedings of the 7th USENIX Symposium on Networked Systems and Design and Implementation.Washington D.C., USA: IEEE Press, 2010: 251-264.
( 0)
|
| [4] |
JAIN S, KUMAR S, MANDAL S, et al. B4:experience with a globally-deployed software defined wan[J]. ACM SIGCOMM Computer Communication Review, 2013, 43(3): 3-14. ( 0)
|
| [5] |
PFAFF B, PETTIT J, KOPONENT, et al.The design and implementation of open vSwitch[C]//Proceedings of the 12th USENIX Symposium on Networked Systems and Design and Implementation.New York, USA: ACM Press, 2015: 117-130.
( 0)
|
| [6] |
WANG Haopei, XU Lei, GU Guofei, et al.FloodGuard: a DoS attack prevention extension in software-defined networks[C]//Proceedings of IEEE/IFIP International Conference on Dependable Systems and Networks.Washington D.C., USA: IEEE Press, 2015: 239-250.
( 0)
|
| [7] |
HONG Sunming, XU Lei, WANG Haopei, et al.Poisoning network visibility in software-defined networks: new attacks and countermeasures[C]//Proceedings of Internet Society Network and Distributed System Security Symposium.San Diego, USA: [s.n.], 2015: 123-132.
( 0)
|
| [8] |
JERO S, KOCH W, SKOWYRA R, et al.Identifier binding attacks and defenses in software-defined networks[C]//Proceedings of the 26th USENIX Security Symposium.New York, USA: ACM Press, 2017: 485-496.
( 0)
|
| [9] |
SHIN S, YEGNESWARAN V, PORRAS P, et al.Avant-guard: scalable and vigilant switch flow management in software-defined networks[C]//Proceedings of the 2013 ACM SIGSAC Conference on Computer and Communications Security.New York, USA: ACM Press, 2013: 413-424.
( 0)
|
| [10] |
GANG Shang, PENG Zhe, XIAO Bin, et al.Flooddefender: protecting data and control plane resources under SDN-aimed dos attacks[C]//Proceedings of INFOCOM IEEE Conference on Computer Communications.Washington D.C., USA: IEEE Press, 2017: 1-9.
( 0)
|
| [11] |
WANG An, GUO Yang, HAO Fang, et al.Scotch: elastically scaling up SDN control-plane using vswitch based overlay[C]//Proceedings of the 10th ACM International Conference on Emerging Networking Experiments and Technologies.New York, USA: ACM Press, 2014: 403-414.
( 0)
|
| [12] |
LENG Junyuan, ZHOU Yadong, ZHANG Junjie, et al. An inference attack model for flow table capacity and usage:exploiting the vulnerability of flow table overflow in software-defined network[J]. Water Air and Soil Pollution, 2015, 85(3): 1413-1418. ( 0)
|
| [13] |
QIAN Ying, YOU Wangqing, QIAN Kai.OpenFlow flow table overflow attacks and countermeasures[C]//Proceedings of European Conference on Networks and Communications.Washington D.C., USA: IEEE Press, 2016: 205-209.
( 0)
|
| [14] |
SONCHACK J, DUBEY A, AVIV A J, et al.Timing-based reconnaissance and defense in software-defined networks[C]//Proceedings of the 32nd Annual Conference on Computer Security Applications.New York, USA: ACM Press, 2016: 89-100.
( 0)
|
| [15] |
AKHUNZADA A, AHMED E, GANI A, et al. Securing software defined networks:taxonomy, requirements, and open issues[J]. IEEE Communications Magazine, 2015, 53(4): 36-44. DOI:10.1109/MCOM.2015.7081073 ( 0)
|
| [16] |
张梦豪, 毕军, 白家松, 等. 针对SDN基础设施的拒绝服务攻击防护框架[J]. 东南大学学报(自然科学版), 2017, 47(增刊): 1-8. ( 0)
|
| [17] |
王涛, 陈鸿昶, 程国振. 基于网络资源管理技术的SDN DoS攻击动态防御机制[J]. 计算机研究与发展, 2017, 54(10): 2356-2368. DOI:10.7544/issn1000-1239.2017.20170389 ( 0)
|