论文摘要：

本文为读者提供新兴的SDN带状态数据平面，集中关注SDN数据平面编程性带来的隐患。

I部分 介绍

A.带状态SDN数据平面的兴起

B.带状态数据平面带来的安全隐患

　　引出带状态数据平面的安全隐患问题（比如：有针对的服务否定攻击和状态耗尽攻击以及数据平面攻击等等），要求系统开发人员或者是应用开发人员遵循以下特征：

　　在交换机内部存储每一条流的信息，即状态，包括状态的分布式存储。

　　在数据平面，数据包到来或者数据平面事件触发时，有能力改变在交换机中的状态。

　　交换机基于当前本地的状态信息可以自动做出决定策略。

C.贡献

本文双层目标：

1）给读者提供一个新兴的带状态SDN数据平面

2）通过一个具体的用例应用，剖析相关的安全问题

本篇文献的贡献：

第一，对带状态数据平面最近提出的计划方案进行调查（第二部分C节）

第二，对现在的带状态SDN数据平面提案的漏洞进行分析（第三部分A节）

第三，利用带状态SDN数据平面交换机对潜在的应用攻击给出具体的证明（第三部分B节），集中在来源于不同文献的使用样例，并且选择出样例强调不同的漏洞

第四，阐明继承自传统SDN安全问题以及带状态SDN数据平面在安全问题的提高的意义（第三部分C节）。

第五，讨论可能的防御方法和对设计弹性对抗之前讨论过的漏洞的应用的建议，以及将来的研究方向（第四部分）。

 II部分  从SDN到带状态SDN数据平面

II-A，简短介绍SDN，OpenFlow的基本概念。II-B，在OpenFlow第一个标准制定之后的发生的演化。II-C，回顾带状态SDN数据平面领域当下最新的技术。II-D，列出了我们带状态SDN支持的使用用例（文中将会用到）。

II-A SDN和OpenFlow:背景

　　SDN就是将数据平面和控制平面分离，简化大型多供应商网络控制和管理。

　　 McKeoown 提出一个可编程流表的抽象模型，通常定义为“匹配/动作”概念，这个模型能在实现上高性能、低耗费，能够支持广泛的研究，并且与不同提供商的封闭平台需求相一致。

　　原始的OpenFlow的匹配/动作概念如图2所示，它包含三个主要部分，i)一个匹配规则，它使程序员通过匹配任何任意的从2层到4层选择的头域，从而指定一条流。ii) 一个或者多个转发/运行动作，程序员可以随意的将它们与考虑的匹配规则联系。iii) 一个数据域，设计来收集相关匹配规则鉴定的流数据

B.额外的灵活性需求

　　随着1.0OpenFlow版本的发布，很快发现最初的OpenFlow提议太过于严格，决定在三个方面给予灵活性。前面两个方向只是与本文主题相独立，只做简单回顾。我们的目的是最有趣的第三个方向（比如，定制带状态的操作），在交换机内部的带状态处理有很广泛的需求。

1）多流表：从1.1版本，OpenFlow表扩展以支持多管道流表。Reconfigurable Match Table是于2013年 设计，允许非常灵活的映射，基于同样的TCAM内存，可以匹配不同宽度和深度的表，甚至允许从之前的匹配中计算/抽取出参数，定义匹配规则。这里的RMT-type硬件使得P4数据平面编程语言兴起（II-C2讨论）。

2）提高匹配/动作灵活性：

3）定制带状态OpenFlow扩张：组表（Group tables)可能是最杰出的OpenFlow扩展例子，它引入了对定制带状态动作的支持。组表可以分步解决链接失败问题。最初的OpenFlow配置，在处理链路、端口的物理故障时，通常是由OpenFlow交换机唤醒远程控制器的介入，实例化新的转发规则，但这期间，必定耗费一些时间，而到达该故障处的包就被丢失了。更新版本的OpenFlow标准引入了一个称为快速故障转移的组类型，特别的解决了这个问题。其他的有重大意义的例子是为速率控制的计量器，支持学习类型功能的同步表等等。OpenFlow标准确定了在交换机内部支持带状态操作的需求，以防止远程控制器参与带来过度的延迟。

 C.带状态SDN数据平面的提出

　　图3提供了通常的带状态数据平面的概述，带状态SDN可总结为以下两个原则：

i)在交换机内部保留流的状态信息，并且允许以编程方式正式化数据包级别状态转换。

　　ii)给予交换机基于本地流状态信息（不需要接触控制器），做出转发状态更新决定的功能。

　　一个带状态交换机可能需要存储历史的进来/出去的包信息，这些信息可能由于接收/发送相同的新流量包而改变，因此，贼这样的一个交换机中，一个数据包级事件可能导致流的状态信息改变。此后，交换机为相应的流，基于当前流的状态做出转发决定。这应该在带状态数据平面进行记录，正如基本的SDN交换机那样，路由做出的决定是基于一系列之前控制器定义的行为规则。可是，带状态的本质是使交换机能够独立的基于流的历史信息选择适当的动作（action）。

　　 尽管出现技术差异，并且研究工作集中在不同的地方（核心平台、编程语言、编译器、网络级框架），底层的灵活性和高效转发状态可重构性以及数据平面可编程性是不变的原则。II-C1提出核心平台，II-C2提出编程框架，表I提供了以下讨论方案的特点总结。

1) 平台和使能技术

　　a)OpenState：接下来，将解释在OpenState中的带状态编程模型和包运行程序。XFSM由四个元组（S，I，O，T）构成，S是一个有限集状态，包括初始状态S0（默认），I是一个输入有限集（事件），O是一个有限集输出（动作），另外T是一个状态转换功能（规则）映射<状态，事件>到<状态，动作>。在OpenState，每一个交换机存储两个不一样的表（如图4所示）：1）状态表基于接收到的数据包的流，存储当前流的状态。2）XFSM表基于接收到的数据包的<状态，事件>信息，定义对应的规则（比如，状态转换），为了解决一个到来的数据包，每一个OpenState交换机要执行以下三步：

1.第一步，接收到数据包后，交换机执行状态表查询，检索接收到的数据包的当前状态（比如，数据包的流所属的状态），它使用流ID（比如，源IP地址）作为状态表查询的键。如果在状态表中没有匹配的键，交换机会将“默认”状态分配给刚进来的数据包（比如 ，流ID）.然后，交换机将检索到的状态标签(或者是默认)附加到包中作为一个元数据域。

2.第二步是查找XFSM表，寻找<状态，事件>匹配的规则，执行相关的动作并且按照XFSM表中提前定义的next-state字段更新数据包的状态域。

3.最后，交换机基于从前一步检索到的下一个状态（next state）域更新它的状态表相应的流ID。

　　很明显，交换机不需要要为每一个接收到的包请求控制器。相反，它基于接收到包的当前状态和控制器为每一个<状态，事件>预先定义的规则做出路由决定。

b)FAST:  Fast，在每一个交换机内部有预先安装的状态机类似于OpenState。FAST设计上，在每一个交换机中将会有几个状态机实例，每一个实例致力于一个特殊的应用。在FAST上的控制平面和数据平面，以下几个方面不同于最初的SDN实现，控制平面有两个主要的组成部分，（i）一个编译器（ii）交换机代理。编译器是一个离线的组件，将状态机器翻译成交换机代理，而交换机代理，是在线的组件，管理在交换机内部的状态机。交换机代理有以下任务：（1）它关注在交换机内部的状态机功能。（2）它可以通过接收交换机的更新内容，执行一些本地计算，比如，在速率限制的情况下，它接收定期的数据来计算流速率。（3）它可以为受限制的交换机通过实现一部分的内部状态机，从而管理内存限制.(4)最后，它解决了在交换机和从之气之间的交流，并且更新了控制器上关于交换机本地的状态信息。比如，交换机受到巨大打击，它将更新交换机代理，随后更新到控制器。

　　FAST，数据平面包含四个表（图5 所示）：（i）状态机过滤 ，（ii）状态表 （iii）状态迁移表 (iv) 动作表。在一个交换机内部，有一个状态机过滤表为所有的状态机的所有实例进行过滤。但是，每一个状态机有它自己本身的状态表，状态迁移表和动作表。状态机过率表选择与进入包相关的对应的状态机，而状态表存储进来的数据包的状态信息。状态表是一个哈希表，它映射每一个包的头部（比如，源IP，或者目的IP）到相关的流状态。每一个状态都与其当前值存储在变量中，比如，考虑一个数字，某些高位用来存储状态，其他的位用来存储对应的值。

c)SDPA:SDPA平台包含三个表（如图6所示）（i）状态表（ii）状态迁移表（iii）动作表，以及状态处理模块，就是所谓的转发处理器。状态表的匹配域是当前数据包头的任意字段的组合，状态域是一个流的当前状态，另外指示域是一个”状态操作说明“，比如GOTO_FT(m)，这意味着以ID“m”进入流表。状态迁移表以及动作表分别为当前的流定义了下一个状态和对应的动作。在SDPA中，每一个应用有属于自己的三个表实例。专用于应用程序的状态表由控制器在接收到有状态处理请求时启动。在这样的一个样例中，控制器更新FP的在应用的相关联的状态表以及表中的请求字段。

　　在SDPA中,SDN控制器与转发处理（FP）模块进行通信。基于第一次收到某一条流（例如fi）的数据包，交换机将发送包到控制器，决定受否存储该流的对应状态。其他即将到来的流fi的数据包，将会通过本地交换机进行处理，无需与控制器通信。可是，控制器通过从FP接收更新消息，完全的控制和更新状态表的信息（比如，定期的更新或者由于特殊的事件进行更新），控制器可以决定什么时候接收更新（不需要每次状态迁移进行更新）。

　　当前来说，后面提到的三个带状态数据平面是在文献中提到的。

2）编译器，可编程语言，架构

　　a)P4:在2014年，在【23】中提出了一个为配置交换机的抽象转发模型和一个高级编程模型，作者提出，为数据包处理的目标独立抽象模型。就设备类型或者技术来说，程序员不需要知道底层转发设备的配置信息。因此，项目使用建议的语言编写，比如（lanuage for Programming Protocol-independent Packet Processors）P4，可以映射到几种类型的设备上。

　　　不同于OpenFlow，P4提出了一个可编程包解释器（基于【49】的提议），使交换机能够解析新的头字段。而且，P4允许匹配/动作选择并行，或者串行，或者两者皆存。然而在OpenFlow中，它尽可以串行。P4有两个主要的操作：（i）配置，配置包的解析器，定义动作的顺序，以及确定一个交换机运行数据包的方式。（ii）数量（Population），定义策略和匹配/动作表的条目。匹配/动作表分为：(i)进入权，基于这项，交换机决定控制器是否进入。这意味着，每一个交换机发送包到某个地方，在那里，包将被分析（比如，另一个交换机存储对应的状态变量）然后基于它的当前状态进行处理。SNAP仅在一个物理交换机上存储每一个状态变量，以防止交换机之间状态同步。然而，Arashloo指出，如果有兴趣分部状态变量，可能可以将变量分割为多个部分，比如s1到sk，每一个状态变量致力于一个端口/IP，并且存储每个si在不同的交换机上。为了硬件上实现状态变量，考虑到效率，延迟，状态一致性之间的权衡，作者提出使用hash表或者内容可寻址内存。

d)事件驱动程序：在【48】，研究人员提出一种在网络中为事件驱动更新的带状态运行语义。作者定义“事件驱动一致性更新”为在事件发生时，将一个配置移动到另外一个配置上。事件可以是要求的变换，在接收到一个，触发更新的数据包后，一个交换机上的转发行为。他们的提议确保，通过网络，数据包按一致性的配置运转，并且，在正确的时间，网络更新所有的交换机。最后，他们想到了事件驱动迁移系统（ETS），它类似于带状态数据平面的状态机（II-C1）。为了防止在网络中的冲突（可能由于不同交换机对网络事件不同的观点导致），我们提出，新的名为网络事件结构系统（NES）。特别的，NES考虑了两个迁移限制：（1）在网络事件之间的依赖性（2）在事件之间的兼容性

　　为了实现带状态项目，NES帮助网络设计者规划交换机，它规定，交换机能够存储即将到来的事件，基于网络事件和对其他交换机声明事件路由数据包。特别的，【48】中提议工作如下，（1）将状态作为标签的形式呈现，插入到数据包的头部。（2）在不同的配置上为迁移定义定义控制，这可能由于接收有特殊配置的标签数据包触发。（3）在本地交换机存储本地事件作为状态（4）基于交换机的本地状态和交换机的全局状态看法，改变交换机的配置。特别的，由于交换机的横断，每一个包进入网络，携带网络的一个全局状态。这种情况下，如果数据包通过了交换机，它的本地状态不同于数据包，他讲被更新为最新的状态。为了提供状态的一致性，虽然控制器可以根据全局的网络视图 按时地更新交换机状态，控制器仍然从交换机接收状态迁移信息。

D.带状态SDN的应用程序和用例

　　近年来，研究人员提出，应用程序运行在SDN带状态之上，采用II-C1中提出的平台和编程语言（II-C2）。这一节，我们介绍了一些带状态SDN的应用程序样例，另外，在本文中引入用例是为了显示带状态SDN的可用性。我们随后将为我们的漏洞分析实现一些应用程序和用例以及做出攻击效果评估。尤其，我们提出（i）带状态故障恢复，使用交换机的本地状态，快速进行节点/链路恢复 应用程序（II-D1）(ii) HULA，数据平面负载均衡应用（II-D2）， （iii）端口访问使用用例，访问控制技术允许用户在访问特殊序列的端口后通过防火墙（II-D3）;（iv）DNS 隧道带状态检测，检测试图忽略访问策略，使用DSN信息（II-D4）到达主机的用户。（v）UDP 泛洪带状态缓解，这将识别发送异常UDP数据包数字 的用户（II-D5）。

1）带状态故障恢复：

　　在【31】中，提出了基于OpenState的一个独立控制器带状态 链路/节点 故障检测和恢复方案。这个方法使用标签对数据包进行标记，在检测到一个节点或者链路故障后，为了与之前的节点通信，为随后的包使用绕道路径。

　　这个协议运行如下：让我们考虑一个方案，通过带状态的SDN交换机网络，源主机H发送一个数据包pi到目的主机I，在意识到链路或者节点故障之后，离故障最近的节点用标签（比如MPLS标签）标记一样的数据包pi，标签包含故障事件的信息（操作（1）如图7所示），代替发送一个故障的通知。这个标记的包按照最初的路径路由（发送）返回到最方便重新路由的节点，比如节点N（图7操作（2））。在接收到一个标记的包后，节点N按照它的状态表，为对应的流执行状态迁移，然后，重新路由（通过之前定义的可选择路由）这条流随后的数据包（图7操作（3））。当到达路径上的合并节点时，标签将会从包上移出，另外包也将会转发到目的主机I（图7操作（4））。这个方案的带状态运行特点允许交换机重新路由数据包，同时无需给控制器报告链路故障，因为每一个节点（比如交换机）维持每一条流的状态，它可以自主的决定转发的路径（比如，正常的或者绕道的）。

 2) HULA：

　　最近，在【30】的研究中提出，HULA，针对数据中心的数据平面负载均衡技术，在可编程交换机顶层采用该技术以及P4可编程语言，比如RMT【27】。 在HULA，每一个交换机将前往目的地址（Top of Rack ）ToR的下一跳的信息，保留在下一跳最佳路径优化表中。最佳优化表的条目信息类似于<DestIp,BestHop,PathUtil>的形式。为了找到最佳的下一跳节点，每个ToR交换机通过网络按时地发送探测信息，收集全局链路优化信息。然后，基于收取到的探测信息，每个交换机利用最佳下一条，自主的更新最佳路径优化表，对所有的现有的路径来说，这均衡了通往目的地的负载。

　　每一个探测包的头部包含两个域：（i）24bit的torId,比如，产生探测信息的ToR交换机验证码，（ii）一个8bit的minUtil，为flowlets(比如 流的子分量)携带了最佳优化路径效用。一旦一个交换机从端口i接收到一个探测信息，它首先计算出在端口i上的maxUtil，作为minUtil和本地测量的链路效用的最大值。然后，交换机计算出在maxUtil和在利用率表中先前相应的PathUtil记录值之间的最小值。如果maxUtil是最小的值，交换机用maxUtil和torId更新在交换机内部的最佳路径利用率表的PathUtil和BestHop字段的值，而且，交换机产生新的探测配置，最新的torId和PathUtil，通过网络使用简单的无环路循环策略进行传播。图8展示了HULA的探测传播策略，在一个三层网络上，开始于ToR节点，ToR1。聚合节点（A1-A4）转发接收到的探测信息给下游的节点（比如，ToR），但是不转发给上游节点（S1-S4），除非探测信息接收自一个ToR节点（ToR1在图8所示）。当探测信息到达一个ToR节点，它停止被转发。

3）端口访问：

　　Bianchi在【18】中提出，将端口访问看做是一个展示OpenState结构和操作的应用程序。仅当它们成功的对一系列之前定义的不同端口进行连接尝试之后，，端口访问才允许带状态的防火墙给一台或者多台主机在具体的端口上授权（本文举例为，22），这样的有序序列代表了在防火墙和主机之间的“共享秘钥”。

　　看这个案例，主机H（用源ip区分）试图建立一个SSH回话（默认22端口），通过一个防火墙F，F在一个OpenState交换机上实现。在我们的例子中，让{3306，1810,450}作为访问的端口序列。如果主机H发送正确的三个请求序列进行连接，防火墙F将验证主机并且打开22端口，否则请求将被丢弃。图9阐释了这样的一个例子。

　　正如II-C1中提到的，OpenState保留了一个XFSM表，并且在交换机内部实现了扩展状态机在OpenState端口访问实现中，XFSM表与图4很相似，比如，规则是为五个事件定义的（比如，数据包在3306,1810,450，22等端口接收），四个状态（比如Default，State1，State2，Open），以及两个动作（比如丢弃和转发）。从主机H接收到一个包后，交换机执行状态查找程序，以检索出当前包的状态。开始为Default状态，仅当主机H访问防火墙F序列中期望的下一个端口时，状态迁移才会被触发。这导致一个的丢弃动作，并且状态迁移为State1,。新的状态将被写入状态表中对应主机ID(源IP)的状态。这个程序一致运作直到主机H访问了所有期望访问的端口，然后，它的状态将被更新为Open。这个状态下，在接收到22端口的请求时，防火墙为主机H的用户打开端口。在任何其他状态，如果主机发送一个请求到不正确的端口，它的状态将会被回滚到Default状态。在OpenState，作者假设XFSM表按照规则的优先级进行排序。而且，他们认为在状态表中的超时字段，可用在状态迁移到下一个状态（比如，下一个端口访问）：如果用户在之前定义的超时时间内，不访问正确的端口，它的状态同样将回滚到Default状态。

4) DNS 隧道带状态检测：

　　DNS带状态检测程序运行实例解释SNAP带状态框架。在DNS带状态隧道攻击案例中，恶毒的用户尝试滥用DNS信息来通过访问策略，从而发送数据。正如【16】所述，为了检测到DNS隧道尝试，以下几步应该被执行（如图10）。

　　i)给每一个客户机H分配一个计数器cH，以追踪所有解析的对应主机的IP地址。

　　ii)当客户机接收到DNS的反应时，cH增加，每当它使用一个解析地址时，cH减一。比如，当客户机发送一个包给相应的IP地址。

　　iii)为cH考虑一个阈值，并且当某个主机的计数值高于阈值时，将该客户机报告为恶意客户机。

　　为了执行第二步，SNAP在基于数组的变量中，维护发往H的所有的已解析的IP地址。特别的，SNAP交换机保留了一个变量，orphan,它映射了每一对源目的地址，<src,dst>，其值为boolean类型。入股客户机H从DNS接收到一个已解析的response，目的地址是发往IPI，<ipH,IPI>的值将变为True，并且cH的值将会增加（图10中的操作1和操作2）。当H发送一个包给I时，交换机联系<IPH,IPI>检查状态，如果状态为True，将这个值设置为False，并且减小cH的值，意味着主机H实际上“使用的”信息已经包含在已接收DNS记录中（图10操作3）。

5）UDP洪泛带状态迁移：在【51】中提出，是关于带状态数据平面使用用例的另外一个例子，使用SNAP实现。Arashloo在【16】中提供了一个算法来区分UDP洪泛攻击，,主要通过区分用户是否发送不合法的UDP包数值。最后，作者考虑了几个变量：（i）计数器cudph用来表示来自主机H的udp数据包（比如，每一个包的源IP），(ii)变量udp-flooder[H]，用来保存客户机H的状态；（iii）阈值T用来将来自源IP地址的UDP数据包的数值合法化。

　　当主机H发送一个UDP包，SNAP策略首先查看H的状态，判断udp-flooder[H]是否已经被认为是一个恶意的用户。如果udp-flooder[H]是True，算法将丢弃这个包。否则，如果udp-flooder[H]是False，算法增加cUDPH的计数值，如果检查到cUDPH=T(阈值)，算法将丢弃数据包并且将udp-flooder[H]设置为True。

　III带状态数据平面的安全问题

　　从一个高度的视角来看，所有的带状态SDN方案（本文中的）有这样的一个原则：它们都将流的状态

推送到数据平面。这使得每一个交换机自主作出智能的决定，由于减少了数据平面与控制平面的交互，从而提高网络性能。然而，尽管带状态平面的优点很明显，我们认为，在安全方面，当前还存在不足。

　　III-A，强调了由于带状态SDN数据平面固有的特点导致的肉冻，III-B描述了潜在的攻击方案，可能利用带状态SDN数据平面的漏洞进行攻击。III-D，用三个使用样例，展示攻击的可行性。最后，一个不变的事实是，带状态SDN的提出并不意味着传统SDN的安全问题被解决，III-C简短的谈论了传统SDN的漏洞。

A. 漏洞

　　　经过分析现在的带状态SDN数据平面提案和应用带状态SDN的应用，我们确定了四类主要的漏洞类型。III-A1：未绑定流状态内存分配，III-A2：可触发的CPU密集操作，III-A3：缺少验证机制；III-A4，缺少集中状态管理。随后，在III-B中，我们提供攻击的详细说明，利用这些漏洞，从现有的SDN带状态数据平面文献，选出三个实际的攻击样例.

　　1）未绑定流状态内存分配：为了数据平面可编程（比如，拥有带状态交换机），每个带状态SDN方案必须分配内存空间来追踪进入的流产生的状态。依赖于具体的带状态SDN方案，数据结构用于保留状态信息被定义为“状态表”【18】-【20】，或者基于数组的变量【16】。为了简化，本文其他地方使用“状态表”来代表用于状态存储的数据结构。

　　为了攻击一个交换机，一个攻击者可能利用潜在的每个交换机要求的巨大内存空间，以存储流的状态信息，来耗尽交换机的内存。

2）可触发的CPU密集操作：第二个攻击向是指，攻击者有机率可以强制交换机上的CPU密集操作进行执行。比如，*控制器必须对网络有完全的控制，从而验证网络功能【19】。在这个方案中，控制器平面要求接收网络中关于每个事件的更新，比如任一状态的迁移。

　　在这个例子中，一个攻击者可以通过前置交换机持续更新控制平面，操纵DoS攻击，耗费大量的计算资源，从而交换机不能够对包进行处理。应该注意的是，在资源耗尽的情况下，一些攻击可能与系统结构有关，而其他的可能来自实施不当的或者程序员定义的策略。

3）在数据平面缺少验证机制：

　　非常不幸，现在的方案在安全上的关注太少，特别的，在交换机和数据平面之间缺少通常的认证/加密机制。

　　利用这个漏洞，攻击者可能模仿一个诚实的交换机并且将虚假信息注入到网络中，或者是操纵在交换机之间传递的信息内容，结果使交换机基于虚假的内容做出决定。这个漏洞可以被利用，然后造成几种类型的DoS攻击，比如在网络中的虚假链路错误导致整体网络性能的下降。

　　4）*数据平面状态缺少管理：状态不一致实际上是存在于传统网络的一个担忧，尤其是当涉及到物理地分发控制平面【52】-【54】。可是，在带状态SDN上的在数据平面级别的状态分布变得更加更要和有挑战性。因为没有*实体：（i）涉及数据平面时间的运行（ii）对交换机内部的状态同步负责。特别的，因为接收到的包引起的状态迁移，攻击者有权力去影响和强制状态迁移，导致网络变成不一致的状态。

　　我们认为，状态不一致性和容易受到攻击与交换机内部的状态变化是没有关系的。然而，事实是，并没有控制器同步状态，这可能导致网络中的状态不一致性。为了处理这个问题，有人可能提出，保持控制器更新在交换机内部实现的状态机当前的流。然而，应当注意的是，控制器更新程序执行应当非常小心，以防引入新的潜在的瓶颈，并且因此导致攻击。状态不一致性可能由于虚假的包注入攻击或者是由于不合适的功能实现导致。尽管如此，这可能导致网络内部的安全或者性能问题。

B. 攻击举例

　　在这一节中，将利用III-A所提的漏洞对现在的带状态SDN方案进行攻击。我们考虑三个在II-D中所提的使用样例应用。比如，端口访问（II-D3），UDP洪泛迁移（II-D5），以及带状态故障恢复（II-D1），和显示潜在的攻击。对每一个攻击，我们列出利用的漏洞。我们选择三个使用样例,因为设计简单，并且易于实施。这让我们对实验有更多的控制权。我们在OpenState平台的基础上实现所有的用例，并且提供实验的结果展示攻击的可行性（实现细节与Appendix相关）。表II展示了考虑的攻击和利用的漏洞之间的映射关系。

　　另外，在III-B1，我们提供不同的用例，这些用例利用未绑定流状态内存分配漏洞，这将导致内存溢出攻击。在III-B2，我们介绍对用例应用程序（II-D1）的重新路由攻击，利用缺少验证机制漏洞（在III-A3中阐述）强加状态不一致性。最后，在III-B3，我们谈论了CPU耗尽攻击，它利用CPU紧密的操作漏洞触发（在III-A2叙述），可能导致分布的状态不一致性。每一节，我们提供必要的准备工作和攻击案例。读者可能通过我们在这一节提供的攻击的实现和实验评估了解到Appendix的详细信息。

　　1）交换机内存溢出攻击：关于带状态SDN简单高效的攻击是洪泛交换机状态表，使状态表持续的扩展和更新。另外，尽管通常没需要保留所有经过交换机的流，攻击者可以聪明地在具体的应用上强制这个行为，并且耗尽交换机内存，造成内存溢出攻击。这就是端口访问用例（III-B1a），以及洪泛状态迁移（III-B1b）。

　　a）端口访问攻击：我们提出一种针对访问应用的攻击（我们在II-D3中介绍）。

　　攻击模型：我们的攻击在端口访问应用来看，可以将攻击者分为两个类型：

　　知情的攻击者。攻击者直到正确的访问端口序列，这个信息可以从几个方式获得，比如嗅探流量。

　　未知攻击者。攻击者不知道确切的端口访问序列。

　　考虑这两种攻击类型，我们将描述可能的内存溢出攻击。

　　知情的攻击者场景：假设A是一个知情攻击者，如图11所示，A发送一个大量的来自某一些虚假的IP地址的连接尝试（包）给第一个预定义的端口序列（比如3306）给换机F。在从源IP接收到一个包之后，比如1.2.3.4，F检查它的状态表，查找出进入的流的状态。如果对于IP地址没有记录，F为源IP地址分配一个Default状态，然后在XFSM表执行查找操作。。现在，由于所有到来的包发给了正确的端口，所有进入的包的状态（比如，对应的IP地址）将更新到下一个状态（比如：状态1：3306端口访问）。因此，我们在交换机的状态表中有更多的条目。有意识的攻击者能够强制在状态表中产生成千上万的状态记录，并且导致交换机内存耗尽。

　　未知攻击者：假设攻击者A不知道访问序列。在这种情况下，A可以通过从虚假的IP地址集合（比如IP属于D1=[128.0.0.1-128.0.255.254]）产生大量的数据包，发送给F的所有端口，比如从65535个包来自于65535个虚假IP地址（如图12所示）。假设选择的IP地址之前没有使用过，F对所有的IP分配默认的状态并且执行XFSM查找。注意，如果程序员由于不合适的实现，存储来了默认的每条流的记录（比如，每一个即将到来的流，在表中进行一次记录），然后，状态表中的结果将达到65535个记录，如果攻击者接着对F的端口使用洪泛攻击，这将陈宫完成内存溢出攻击。然而，一个正确的实现，对应的默认状态应该只有一个记录。现在，对于来自IP1.2.3.4的包可能会发生两种情况：

　　意外的，A访问了正确的端口（比如3306），这种情况下，IP1.2.3.4的状态将更新到下一个状态（比如状态1）。　　

　　A没有访问正确的端口，它的状态将继续为默认。这种情况下，不需要保留IP1.2.3.4的状态。

　　现在，因为A可以按时的简单的执行数据包的洪泛。她可以选择如下的IP地址：

选择一个不属于D1集合的IP：这种情况下，它可能有几率访问正确的端口并且依据IP地址（比如：5.6.7.8）对于在状态表中的正确访问的端口产生一个新的记录。

选择一个IP属于D1：如果她以IP1.2.3.4访问一个错误的端口，基于在【18】中阐述的状态，状态表这个IP的状态变为Default。注意，如果我们不小心设计了这样的一个接口，并非重写状态表中的记录（实际上是从状态表中移除），交换机可能为1.2.3.4设置一个新的默认状态。

　　一旦交换机内存被攻击者利用，交换机将不能够处理新到来的数据包，这些数据包可能来自合法的用户。现在，交换机决定执行以下的一个动作：

　　将包发给控制器，这种情况下，交换机的行为类似于传统的SDN。

　　将包丢弃，这将导致DoS变成一个合法的用户。

　　在状态表中重写已有的记录，其中的挑战是如何解决记录的重写问题。

　　为了解决端口随机扫描攻击，Bonola提出，考虑新的状态，称之为攻击状态。作者提出度量的M1来计数主机使用SYN的数量。如果交换机通过一条流探测到端口扫描，它将更新对应“要被攻击”流的状态，将对应的主机阻塞2分钟，并且弹出警告。可是，这个方案不能用到我们提出的内存耗尽攻击。

　　b)攻击UDP防洪迁移：这里，我们展示了带状态UDP洪泛迁移应用的漏洞（在II-D5介绍），可以同内存耗竭攻击作对比。

　　攻击场景：如II-D5所示，SNAP存储了来自每个客户端的UDP包的数，以及对应客户端的状态。比如，如果客户端是一个UDP防洪者等。因此，如果一个攻击者发送大量来自不同的IP地址的UDP数据包，SNAP将会为每一个不同的IP地址分配状态变量和为计数器。这个情况下，因为这两个变量，攻击者很容易就将脆弱的内存耗竭。

　　为了减轻这样的攻击，有人想到使用为计数器和状态变量设置一个过期时间。这意味着，如果交换机在预先定义的时间里（比如过期时间值），未接收到来自客户机H的任何UDP数据包，交换机可以释放分配给客户机H的内存空间。可是，“聪明的”攻击者可以定时的发送UDP数据包，从而强制交换机保留对应主机的状态。

　　2）状态不一致攻击：另一个对于带状态SDN可能的攻击是状态不一致攻击，这来自于缺少验证机制漏洞，并且可能导致事件欺骗攻击和重新路由攻击。如之前解释的，在带状态SDN中，每一个交换机基于对应流的<state，event>信息对到来的数据包做出路由决定。另一方面，在网络中的数据包级别事件，将导致在交换机内部的具体的流造成状态迁移。因此，一个攻击者可以轻松地执行虚假包的注入并且对某个具体的流强制状态迁移。对于相同的流，不同的交换机来说，这将导致不同实例存储状态的不一致性。这样的状态不一致性，将强制交换机做出攻击者需要的路由决策。

　　以下，我们将通过带状态故障恢复使用用例（II-D1）更清晰的阐述这个攻击。特别的，我们展示了我们是如何通过在带状态交换机引发不一致状态，发动重路由攻击。值得注意的是，这样的攻击同样可以应用到任何带状态负载均衡应用程序，这些应用程序利用交换机之间的内置信号。比如，在【30】中。在负载均衡场景，一个攻击者可以重定向网络负载到一个不恰当的链路上，引发链路故障。

　　a)重路由攻击：我们考虑在【31】中提出的（在II-D1介绍的）改道计划方案，我们用它来阐述攻击者如何执行重路由攻击。

　　攻击场景，在这个场景，一个攻击者可以注入虚假数据包，用“损坏链路”标记，并且欺骗链路故障事件如下：攻击者窃听在两个节点之间的流量变化（比如，节点N和如图7的侦测节点），捕获一个数据包，在数据包插入一个标签，说明转发节点已被破坏，从而标记这个数据包，然后将数据包返回给N。在接收到伪造标记的包后，N为对应的流和执行状态迁移并且绕过所有依赖分组。

　　基于以上所解释，对于一个攻击者可能很容易执行重路由攻击，并且对网络造成不一致性和延迟，以及造成降低性能。这个攻击实际上可能由于在两个带状态SDN结构交换机内部的流量变化，没有认证机制和加密机制导致。注意，当所有交换机是可信的，这个攻击不能够应用在网络中。

　　3）CPU耗竭攻击：另一个对于带状态SDN可能的攻击是具体应用攻击。如III-A2所述，在一些网络应用上，如网络监控和DDoS侦测，控制器需要对网络的全局视图进行完整更新。为了这个结果，交换机可能设置成每次更新状态迁移，就更新控偶之器（如【19】所示）。这样的场景下，攻击者可以以两种方式，通过在交换机内部强加大量的状态迁移。

　　1.发送大量的数据包导致在状态表内部插入新的流表。

　　2.发送几个关于正在进行的流的数据包（在状态表中已经有记录），这个结果导致每个对应的流的数据包状态迁移。

　　这两种情况下，交换机应该更新控制器上流的新状态，导致大量的数据包运行，以及在交换机与控制器之间数据包的交换。这将导致交换机的CPU运行能力耗竭。因为CUP每一秒仅能够运行一定量的数据包，由于上述的攻击，状态数据包的运行将会失败。

　　另外一个这样的攻击的后果是在交换机和控制器之间状态不一致性。让我们考虑这样的一个场景，交换机s1是一个高端交换机，运行着指令监测系统。特别的，s1的责任在于侦测恶意的IP地址 和更新控制器。控制器应该为侦测到的恶意IP地址，在交换机内部安装新的规则。现在，攻击者A想访问网络资源。他有关于s1的了解，攻击者A（或者某些同谋）可以执行CPU耗竭攻击，这种情况下 ，因为s1遭到攻击，它将不能够处理任何数据包以及更新控制器。因此，A将能够s1访问网络。

C.从传统SDN遗留下的安全问题

　　带状态SDN通过提出带状态数据平面从而改变了传统SDN的设计。因为这个原因，带状态SDN自然的继承了某些漏洞，特别是关于应用层的，以及与控制平面交互的漏洞。接下来，我们总结传统SDN存在的漏洞，讨论：（i）那些漏洞仍然影响这带状态SDN（ii）哪些带状态SDN带来的安全改善是适用的。（iii）带状态SDN新的挑战。这节，有限定的对SDN控制平面和数据平面漏洞进行分析（因为他们与本文的主题相关），这些漏洞对于带状态SDN没有显而易见的映射关系。读者对于传统SDN的安全问题如果有兴趣可以看【2】-【7】文献。

　　表III提供了主要的传统SDN漏洞的总结，是从【2】-【7】中的调查中提取出来的，加上了这个工作中发现的流动。对于传统SDN的漏洞，表III的漏洞同样影响带状态SDN。尽管本文现在的工作主要在于传统SDN的攻击和安全问题，这节将集中讨论传统SDN和带状态SDN的漏洞。因此，表III源于【2】-【7】中报告的攻击（因为一个漏洞可以导致更多的攻击/事件）。我们将表III列出的漏洞分为三类（比如，控制平面，数据/控制平面，以及数据平面）。

　　1）控制平面漏洞：带状态SDN导致SDN控制平面实际上不变化，因此继承了许多传统SDN的漏洞。另外，尽管带状态SDN将一些状态移到了数据平面，核心逻辑主要由控制平面管理；所以，由于全局网络视图的不一致性产生了潜在的问题。比如，在分发控制器上，导致控制器碰撞和控制器失联（见【52】-【54】）。然而，将状态移动到数据平面，可能消除很多特殊应用的漏洞。比如，当端口访问应用（在II-D3提出的）。这种情况下，由交换机执行的操作完全是本地的，并且与控制平面维护的不一致状态相独立。

　　2）交叉数据平面/控制平面漏洞：就安全来说，与传统SDN相比，带状态SDN的主要提高在于减少了数据平面和控制平面之间的交互。由于这个，带状态SDN的设计解决了由SDN控制逻辑集中引发的扩展性相关的问题。一个典型的攻击是控制平面溢出攻击。这个攻击的目的在于致残控制平面，主要由数据平面和控制平面交互需求过高导致。攻击者能够通过产生大量不同的流（使用虚假Ip地址）发动控制平面溢出攻击；这将导致数据平面交换机将很多的packetIn请求转发到控制器，可能使通信链路饱和，或者使控制器内部资源饱和。尽管研究人员提出【56】-【58】数据平面解决方案来解决这个问题，减轻控制平面饱和仍然是SDN环境遗留下来的一个挑战。通过设计，带状态SDN对这个威胁变得更有弹性，因为它的带状态本质限制了数据平面和控制平面之间的通信需求。

　　3）数据平面漏洞：在数据平面级别，带状态SDN自然地减轻了传统SDN的两个主要漏洞：（1）流信息泄露，通过定时侧通道【59】；在很多例子中，可耗尽TCAM主要用在流表。漏洞（i）可能被攻击者用于得知网络的配置。这可能是由于控制平面为了安装规则导致时间的开销过大，比如，当一个新进来的流不能匹配交换机中任何的流表【60】。然而，带状态SDN，这将不会发生：控制平面可以编排带状态交换机，使其自动做出关于如何处理到来的流的决定，而不需要与控制器联系。这明显地降低了攻击者依赖定时信息进行攻击的攻击面。同理，借助编程带状态SDN交换机，利用漏洞（ii）的攻击被隐含的降低了；另外，带状态平面的功能对流表来说，可以降低所需的变化。注意，尽管漏洞（ii）本质上与III-A1描述的漏洞类似（比如，未绑定流状态内存分配），但是，后者与SDN交换机在数据平面保留数据使用的数据结构相关，这可能不同于传统SDN使用的流表。最后，在III-A2中提到的漏洞可能影响传统SDN。为了应对控制平面溢出攻击，其中，攻击者能够强制SDN交换机之间进行通信。攻击不仅对控制平面有影响，同时对于交换机本身也有影响：交换机必须通过TLS加密渠道发送它的packetIn信息，并且，需要使用加密操作。加密的使用对于被攻击的交换机增加了不可忽视的开销，造成DoS攻击漏洞。

IV.讨论及未来的工作方向

　　在第III节，我们讨论了针对带状态SDN数据平面主要的漏洞以及可能的攻击。表IV总结了所描述的存在的安全问题，这些问题基于在II-C中引入的不同的带状态方案类别进行分类。漏洞列包含了每一个带状态SDN数据平面类别的漏洞（III-A介绍），“漏洞动机”描述了每种漏洞出现的原因。“潜在的攻击”列展示了III-B所述的攻击运用到相应的分类。最后，“Remarks”列列出了一个或者多个应该被考虑的原则或者重点，本节将讨论。尽管本文的目的在于提出关于带状态SDN数据平面安全问题的认识，为了更加完整，本节我们提供有用的实践的原则，这些原则将应用到SDN带状态的安全认识设计上，并且得出一些将来的可能的研究方向。

　　A.与其他网络环境的类比

　　当然，尽管带状态SDN有新兴的趋势，至少从安全的挑战来说，它与传统网络系统完成的工作具有相似性，它依赖于交换机的状态通过数据平面的事件（比如，特殊类型的数据包的到来等）进行动态的设置和更新。换句话说，本文开篇所述的带状态SDN数据平面的安全问题，某种程度来说，可能需要认为是在现在已建立的网络环境存在的“超级”安全挑战。比如，以太网【33】或者最近的信息中心网络（ICN【61】）。以下，我们将通过简短的安全问题的共性缕清这个问题，安全问题影响到两个例子背景，以及相关的迁移技术，迁移技术可能激发更多通常的SDN场景的适应性。

　　1）以太网：以太网交换机有动态更新转发表，映射MAC地址到交换机的端口，在这，相关的帧必须被转发。以太网帧是基于目的MAC地址进行转发的，但是，同时，转发表通过动态学习程序动态地建立和更新。一个包到来后，表通过增加（或者修改）一条流表项进行更新，这个流表项匹配MAC地址到交换机的输入端口，比如，包接收到的端口。这个表，通常定义为Content Adddress Momory(CAM)，由于通常在一些硬件（HW）中实现，可能存储一些其他的信息，比如超时值或者虚拟 局域网认证。在CAM表结构和用于带状态SDN的带状态表概念之间的相似性是很明显的，因为这两者都在交换机内部执行自动驱动对数据包进行更新。尽管以太网有几个完善的特点，比如灵活性，弹性，简易性【62】，它易于多个DoS和欺骗攻击，比如MAC泛洪攻击，ARP中毒，端口偷窃以及资源耗竭攻击。值得注意的是，在迁移技术中，到目前为止，最广泛的、最实际的是建立端口安全，这是本地监测技术运行于以太网交换机顶层的本质。它在交换机端口监测MAC地址，以限制在相同端口学习的最大的MAC地址数量，并且防止局域网MAC地址欺骗和转发表溢出攻击【33】，【63】。以太网例子建议交换机级别（本地）监测是第一个候选的减缓方法，同时也适用于带状态SDN通常例子。

　　

　　　　2）信息集中网络：ICN是一个新兴的网络范式，在网络层，使用数据集中发布/订阅取代了传统的IP-集中网络通信。在不同的ICN实例之间，Content-Centric Networking(CCN)【64】最有代表性和确定性。CCN和NDN却别在于设计和实现，但是有共同的原则。在ICN中，内容是通过生产者产生的，并且由消费者请求；内容通过数据包传送给消费者，每个请求都是通过一个interest packect。每个数据包都是通过分级名称（比如com/cnn/news）进行独特的处理，这些在interest packets包中进行了配置，并且用于路由。ICN路由器在内部的Pending Interest Table（PIT）结构中保留了关于到来请求的状态。通过哦这个表，ICN路由器记录接收到的interest的接口I，以及由interest数据包携带的内容N。路由器使用另一个名为Forwarding Interest Base（FIB）的表，根据名字前缀和相应的接口来路由interest包。每个数据包通过相反的路径（根据对应interest包来的路径）路由回到用户：当一个数据包被路由器接收，它检测在PIT内部的匹配项，如果一个匹配被找到，路由器从这个接口转发这个数据包回到接口知识的条目，并且移除流表项，否则，它简单地抛弃数据包。很容易发现ICN路由器使用的PIT数据结构与带状态SDN使用的状态表类似。另外，研究人员显示， PIT可以在带状态SDN数据平面的顶层实现【66】。而ICN相比于基于Ip的网络有几个有点，比如低延迟，以及改善可扩展性以及移动性【67】，【68】，他介绍了新的安全挑战。在ICN中要求的PIT状态管理使它容易遭受DoS攻击，比如，资源耗竭攻击活状态不一致攻击【68】-【69】。安全社区已经考虑了这些安全问题并且解决一部分问题。比如，在【72】提出的迁移方法防止了DoS攻击路由器内部的PIT。最后，许多方法提出，在ICN领域已经依赖基于本地监测方法【68】，比如路由器上使用本地的度量，比如PIT 用法【72】，interes 【追踪】、限制请求率【74】。

B. 走向可编程监控

　　正如之前谈论的以太网交换机和ICN路由器安全性的讨论所预料的那样，对于带状态SDN安全威胁来说，本地监控技术的弹性似乎是自然而然的首选防御策略。通常的方法是设计监控技术，运行在网络节点中，并且设计以区分异常的流量模式和针对带状态SDN的攻击的发生。本地监控技术和相关的特点萃取以及数据收集可能在将来组成更加复杂、广阔的网络监控架构，这个架构涉及SDN控制器以及控制器对全局网络状态的视图。

　　可是，在带状态SDN和传统的网络场景（比如以太网或者ICN交换机）之间的关键差异是，在随后的例子中，网络节点操作是先验的，因此，监控技术可以专门地设计用以监控特殊的异常和与特殊网络节点操作相关的攻击。相反地，带状态SDN中的节点行为并不是提现配置的，而是任意编程的（比如，通过状态机【18】，P4程序【23】，或者其他的II-C讨论的数据平面编程概念）。换句话说，在带状态SDN数据平面的监控问题的空间要比对应的传统网络节点的操作解决问题的空间更宽广。

　　我们提出一个引人注目的解决方法，这个方法包含设计互补的技术以及方法学，从而不仅允许网络节点的可编程，同时可以进行监控。研究的挑战是概念设计以及可编程监控任务平台，为了允许网络应用开发人员能够设计量身定制的监控策略以通过节点操作进行部署。本质上，关于SDN范式，对应的软件定义监控范式可能为应用设计者提供简易使用的模型，原语，以及语言，从而在编程网络节点上部署监控算法。在这个方向上的初步成果可以在【28】中找到，Bonola提出了基于扩展有限状态机的编程监控方法，它允许编程人员正式地描述和执行实时、多步骤、定制的本地监控操作。

　　另一个有趣的前瞻性的带状态SDN网络节点的演化是同时支持转发和监控任务，包括在硬件（HW)中以线速、更加及的源于设计节点。这些原语不仅仅是转发，另外允许对每条流进行抽取特点和数据收集。

C.带内信令和可验证状态转换的安全

　　利用带状态SDN数据平面的能力，最近提案为故障恢复或者负载均衡提供方法，在交换机之间使用带内信令；通过控制数据包或者是最初的数据包作为带内信令（最终用控制信息加入标签或者标记）。然而，如III-A和III-B所述，对交换机之间交换的数据包，缺少身份和完整性验证机制，会被攻击者欺骗或这注入恶意的控制包到网络中，并且可能导致DoS攻击。

　　为了解决这个问题的研究方向是为内部交换机的安全设计一个信任模型，以及为验证信令数据包的完整性和出处进行加密。不幸的是，身份、完整性验证机制的状态加密可能很难获得线速包运转速度，而这，可能是一些应用所需求的。

D.状态一致性检测

　　交换机内部的流的状态迁移是基于数据包级别事件，控制器对于交换机内部的状态没有完全的控制，这将可能导致交换机之间、交换机与控制器之间的不一致性。为了防止这样的漏洞，交换机需要对控制器检查。针对状态不一致的解决方法可能是：考虑交换机更新的一致性【48】提出，以及状态集中存储，在NAP【16】提出。

 E.安全意识发展

　　如IV所示，许多漏洞由于不适当的实现带状态存储内存和访问策略导致。为了减轻旨在耗尽带状态SDN交换机内部内存的攻击，开发人员可以（i）为状态交换机/变量估计预先需要的内存空间，（ii）为状态移除定义适当的条件另外，应用程序应该包括基本的带状态网络的基本功能，依靠本地的状态做出决定，这样可以防止攻击者强制内存分配（III-A1）或者触发CPU密集操作（III-A2）。

V.结论

　　最近，研究人员意识到在SDN中需要可编程交换机，并且提出带状态SDN数据平面。用可编程SDN交换机提高网络性能和灵活性以实时反应网络应用程序，因为可编程交换机允许交换机更快更高效的管理动态应用。我们认为，带状态SDN数据平面尽管很有能力，但是容易受到不同的安全攻击。本文献中提出了几种不同的场景，每种都解决了带状态SDN数据平面在实际应用中的一个具体的需求。但是，它们都没有建立安全措施。因此，据我们所知，我们是第一个回顾和分析带状态数据平面方案主要特点，通过强调由于带状态方案内在属性，引发主要存在的安全漏洞。

　　附录

　　实验性攻击评估

　　本节，我们提出在III-B介绍的实验性攻击样例评估。

　　　在我们的实验中，我们使用Mininet,OpenFlow1.3仿真SDN交换机。我们采用开源OpenState（基于OpenFlow）和它的应用程序实现我们的用例。基于此设置，所有的OpenState应用程序都在 ofdatapath进程上运行，这个进程由OpenFlow数据路径的用户空间实现。所有的实验运行在一个配置了i7CPU（2核）16GRAM的台式机上，Mininet VM使用4个虚拟核心512M RAM运行。要注意的是，在真实的SDN交换机上，RAM的容量大概是10M左右。因此，当可能时，我们以百分比的形式报告我们的结果，以提供一个平*立的攻击介绍，并且使读者简单的模拟真实世界交换机的设置。以下，我们定义OS为OpenState交换机，OF为正常的OpenFlow交换机。而且，我们考虑用于存储流的数据结构是状态表。我们强调，本节相关攻击背后的原因相同，也使用与任何其他数据结构。

A.端口访问攻击

　　我们现在展示在端口访问应用上进行内存溢出攻击的可行性和高效性，这在III-B1a有所介绍。 我们的实验设置中，我们假设已知的攻击者A知道端口序列的第一个端口（3306）。A的目标是洪泛交换机s1的内存，在OpenState上运行端口访问应用程序。最后，A使用几个虚假元IP地址，以205Mbps的攻击速度防洪3306端口。交换机配置的超时字段值为5s，如果交换机没有接收到相同流访问下一个端口的第二个数据包，s1将重置流的状态并且将流的状态从状态表移除。

　　图13显示了我们的评测结果。如图所示，ofdatapath进程使用的内存，比如，OpenState实现的主进程，随着时间快速增加，在第34秒后，平均达到了整个交换机内存的70%。这导致ofdatapath进程进入紧急状态。交换机CPU使用发生了同样的情况。Mininet VM的整个空间是512MB。

　　图14展示了在达到紧急情况之前的实验期间，状态表中存储交换机状态的数量。我们可看见，在状态数量达到约为200k的流时，数量变成了常量。这是由于超时时间为5s，从表中移除状态，交换机等待了5s。从这个实验可以观察到，尽管存储状态的最大值仍然大约是常量（图14），交换机的内存用量随着时间继续上升（图13）。我们认为这个趋势来源于OpenState的底层OFSoftswitch平台的实现，由于它的低效率的管理内存，导致了内存泄漏。

B.UDP泛洪攻击缓解

　　在这，我们给出关于UDP洪泛迁移攻击的结果（在III-B1b介绍），展示了这种场景下内存溢出攻击的可行性。攻击者A，通过大量的虚假源IP地址，洪泛UDP连接。攻击者给每个源IP地址打开新的UPD连接，并且强制交换机在状态表中为每个UDP连接考虑新的状态。图15显示了该攻击的实验结果。

　　从图15，我们观察到，类似于端口访问洪泛攻击例子，ofdatapath进程需要的内存如飞一般增长，在大约34s时，使用了超过60%的内存，导致ofdatapath进程崩溃。图16显示了在交换机内部状态表中存储的状态数量。值得注意的是，不同于端口访问攻击场景（图14），这个攻击下，状态表中存储的状态线性地增长。。即使为状态表设置了删除超时状态，这种情况仍然成立。原因是，由于内部发送到静态/动态数据包到每一个已经使用过的源IP地址，A强制交换机为对应的IP地址执行状态迁移并且保留最新的状态。这种情况下，由于状态表强加大量的状态，ofdatapath进程使交换机内存溢出，结果使交换机A耗尽交换机的内存。整个用于Mininet VM的内存RAM是512MB。

C.状态不一致攻击

　　为了证明状态不一致攻击（我们在III-B2中介绍）的可行性，我们使用OpenState在【31】实现了故障恢复应用。这个应用程序使用标识符来代表在每一对节点X和Y之间的故障。比如，标识符是一个前进的序列数字，从1开始，用作：（1）MPLS（多协议标签交换机）标记，以标记故障；（2）流的状态值，表示对应的流在通常的转发路径遇到一个故障。MPLS标签和状态值移动了16，因为0到15之间的值是保留的。因此，标识符“16”表示没有故障，而故障事件是从数字17开始的。如果攻击者可以使一个包有正确的MPLS标签（比如17），她可以假装，转发路径有一个故障并且让交换机从正常状态 变为故障状态。这使得交换机相信流量需要进行重路由。

　　我们的评测的网络设置如17所示，在这个简单的测试场景，主机H1（IP为10.0.0.1），通过以下路径发送数据包给H6（IP地址为10.0.0.6）：H1->S2->S3->S4->H6，另一方面，H6回复H1是通过H6->S4->S5->S2->H1。注意，这是在【31】OpenState中实现的故障恢复应用的最初配置，图19展示了我们的原型在没有攻击的情况下运行，比如，正常的交换机行为，考虑故障恢复应用程序的默认配置。正如图19a所示，在一个无攻击的情况下，因为在网络中没有故障，交换机的状态表被认为是空的，比如，保留一个默认的状态。图19b显示了从10.0.0.1过来到10.0.0.6去，通过S3的eth2接口的正常流量。同时，图19（c）从10.0.0.6通过S5的eth1接口到达10.0.0.1的对应路径。

　　为了证明重路由攻击，我们考虑了如图18所示的攻击场景。攻击者A发送虚假的标记着17的MPLS数据包给交换机S2（如图20a）。这种情况下，A假装这个路径有一个链路故障，并且让S2通过恢复路径，对相应的流执行重路由。这种情况下，在接收到虚假的MPLS后，S2在状态表中，为从源IP10.0.0.1到目的IP10.0.0.6插入一条新的记录，如图20d所示。兔兔，S2为表中对应的流定义了一个新的状态，比如，状态17。然后，由于当前的状态，S2通过交换机S5（图20c所示）为对应的流重路由其他到来的数据包，并非S3（图20b）。正如我们从20（b）所示，交换机S3在常规路径只接受虚假数据包，而其他的流量则通过重路由路径进行接收，比如S5。