张立群，林海涛，郇文明，毕文婷

（海军工程大学电子工程学院，武汉 430033）

0 引言

在传统的网络架构下，网络设备的转发平面和控制平面紧密耦合。为了对数据流进行更加精细化的处理，解决负载均衡、访问控制等问题，网络设备制造商将包过滤、多播等功能集成到路由器、交换机等转发设备中，这使得转发设备的结构更加复杂，网络变得难以维护、管理和创新［1］。软件定义网络（Software Defined Network，SDN）由于其便于集中管理、接口可编程、设备成本低等优点［2］，逐渐成为网络架构的新选择。

在SDN 架构（如图1）中，南向接口一般采用OpenFlow［3］协议对网络的转发平面进行编程和控制；北向接口则是为网络应用方便调用控制平面的各种功能而提供的各种应用程序接口（Application Programming Interface，API），一般有表征状态转移（Representational State Transfer，REST）的API、Python API 等［4］。通过控制平面以及南向和北向接口，网络应用可以将生成的流规则下发到转发平面的交换设备中。

图1 SDN基本架构Fig.1 SDN basic architecture

但网络应用通常独立开发，不可避免地会产生冲突，这将导致网络性能降低、网络功能失效，甚至引发严重的网络安全问题，造成难以估量的损失。而且由于SDN 的控制平面和转发平面相分离，转发平面缺乏策略分析能力，交换设备无法独立检测内部流规则的合理性［5］。因此，亟须一种冲突检测系统来对SDN 中的流规则进行检测。

为解决上述问题，本文提出一种SDN 流规则冲突检测系统，该系统将对应用平面生成的待下发流规则进行实时冲突检测，并根据冲突检测结果给出冲突消解策略。

1 相关工作

为解决SDN 中的流规则冲突问题，文献［6］在控制平面和转发平面之间提出一个新的逻辑层VeriFlow。通过将具有相同转发操作的数据包划分为等价类并构建转发图，VeriFlow 可在插入、修改或删除流规则时动态检测网络中是否存在转发环和网络的可达性等问题；但VeriFlow 各模块之间耦合较强，拓展性较差。文献［7］提出了一种实验分析冲突的通用方法。该方法构造了一个参数空间，将SDN 的网络状态抽象为空间中一系列的点，通过比较网络状态的预期行为和实验行为，对参数空间中的点进行标记并对根据冲突原因对冲突点进行分类；但该方法需要进行大量实验，且针对性较强，一旦网络参数发生变化，需要通过实验重新构建模型。

文献［8］针对NOX［9］设计了一款安全内核FortNOX，可以提供基于角色的源身份认证并提出一种别名简化的规则集算法。该算法可以检测由于SET 指令导致的依赖冲突，但在某些复杂情况下可能会发生漏报和误报。而且FortNOX只针对NOX，可移植性较差。文献［10］则基于一阶谓词演算提出一种反射代理模型，对流规则可能产生的静态冲突和动态冲突进行检测，但其未对动态冲突类型进行更加细致的分类，不利于对冲突的消解。

文献［11］提出一种动态冲突检测模型，该模型基于流规则匹配域和动作域关系判别规则冲突，对冲突类型进行了更为细致的分类，且检测准确率较高；但由于要对所有规则逐一判断，且需对所有字段关系判断完毕后才能得出冲突结果，检测时间较长。

上述检测方法的主要不足如表1 所示。

表1 上述检测方法的主要不足Tab.1 Main shortages of the above detection methods

2 系统架构与组成

针对上述SDN 冲突检测研究的不足，本文设计了一种新的冲突检测系统。系统主要包含六个模块：传输控制协议（Transmission Control Protocol，TCP）代理模块、捕获解析模块、格式化模块、冲突检测模块、规则数据库模块以及冲突消解模块。系统结构如图2 所示。

图2 系统结构Fig.2 System structure

2.1 TCP代理模块

在SDN 中，OpenFlow 交换设备通过基于TCP 的安全通道与控制器连接，用于传输与控制器之间的OpenFlow 报文。为此，可以通过建立TCP 代理来实现对安全通道中的OpenFlow 报文监听和处理。

TCP 代理模块实时监听来自转发设备的TCP 连接请求。当监听到建立TCP 连接的请求时，代理模块创建线程Th 用于处理控制器与该转发设备的代理连接，在线程Th 中创建两个子线程Th_1 和Th_2 用于实现控制器与转发设备的全双工通信。其中Th_1 将来自交换设备的报文转发给控制器，捕获、处理转发设备向控制器发送的报文；而Th_2 将来自控制设备的报文发送给转发设备，捕获、处理控制器下发至转发设备的报文。

若代理模块长时间不能监听到报文，则要检测TCP 连接是否有效。若连接失效，则释放代理连接；否则继续监听。

2.2 流规则捕获解析模块

现在SDN 中较常使用的南向协议是OpenFlow_1.0 和OpenFlow_1.3［12］。

TCP 代理实时监听控制平面与转发平面传输的数据报。对于OpenFlow_1.0［13］，主要是监听Flow_MOD 报文、FEATURES_REPLY 报文和STATS_REPLY 报文。而在OpenFlow_1.3［14］中，则主要监听 Flow_MOD 报文、FEATURES_REPLY 报文以及MUIPART_REPLY 报文［4，14］。

当模块检测到Flow_MOD 报文的Command 值为OFPFC_ADD 时，表明控制器正在下发新的流规则到转发设备。模块对该报文及进行捕获、解析，获取新增规则的匹配域和动作域信息，而后将该信息交由后续模块进行处理。

FEATURES_REPLY 报文中包含设备的数据路径识别码（Datapath Identity Document，DPID），据此可以对TCP 代理进程进行标记，区分代理进程所连接的交换设备。

STATS_REPLY 报文（OpenFlow_1.0）和 Type 值为OFPMP_FLOW 的MUIPART_REPLY 报文（OpenFlow_1.3）则包含了交换设备中存在的全部流规则。通过解析这些报文，可以获取交换设备中已存在的流规则信息，信息经过格式化模块后用于构建规则数据库。

对于其他类型的报文，模块不进行处理，直接交付给接收方。若要对其他版本的OpenFlow 协议处理，只需对该模块进行相关解析函数的更新即可。

2.3 流规则格式化模块

在OpenFlow_1.3［14］中，其match中的字段有40 多种。但在网络中一般使用IP 地址、媒体接入控制（Media Access Control，MAC）地址、协议类型等字段就可以实现数据流的匹配，其他字段大多为通配值。同样，管理网络常用的动作action主要有转发、修改和丢弃［1］。本系统在确保冲突检测准确性的前提下，为方便冲突检测过程，将流规则格式化为如下形式：

Ri={match，action}

match=(ingress，macsrc，macdst，ipsrc，ipdst，pro，portsrc，portdst)

action∈Setaction={drop，output：port，setfield：n}

match各字段以及action的含义如表2 所示。

表2 某个流规则中的字段名及含义Tab.2 Field names and meanings in a flow rule

若流规则match中的字段在Flow_Mod 报文中未赋值，则模块将该字段的值设置为通配符“*”，即该字段匹配所有数据流；若在Flow_Mod 报文中流规则的action未赋值，则模块设置该规则的action为drop。

2.4 规则数据库模块

规则数据库模块可以模仿控制器发送请求流表状态的MUIPART_REQUEST 报文，然后根据转发平面返回的MUIPART_REPLY 报文解析构建格式化流规则数据库。每一个交换设备的流规则会根据协议类型存储在SetTCP、SetUDP、SetOTH和Set*四个集合中，如图3 所示。其中，SetTCP中存放协议类型是TCP 的流规则；SetUDP中存放协议类型是用户数据报协议（User Datagram Protocol，UDP）的流规则；SetOTH中存放协议类型既不是TCP 也不是UDP 的流规则，Set*中存放协议类型是通配符的流规则。模块定时发送报文对数据进行更新。同时，每次下发新的流规则后，模块也要对规则数据进行更新，使得模块内数据与交换设备中的数据保持一致，确保冲突检测结果的准确性。

图3 存储结构Fig.3 Storage structure

2.5 冲突检测模块

冲突检测模块是冲突检测系统的核心模块，对新下发规则和交换设备中已经存在的规则进行冲突检测。模块根据不同种类冲突［15］的特点将冲突类型划分如下。

1）无冲突（Non-Conflict，NC）：两条流规则的match无关，称这两条流规则间无冲突。

2）冗余冲突（Redundancy Conflict，RC）：两条流规则的match是包含关系且对数据流所作操作相同，称这两条流规则之间发生冗余冲突。冗余流规则会占用交换设备内存，增加匹配时间，引起一些优化和效率问题。

3）覆盖冲突（Shadowing Conflict，SC）：两条流规则的match是包含关系且对数据流所作操作不同，称这两条流规则之间发生覆盖冲突。覆盖冲突会导致管理员对网络策略的更新失效，使数据在转发时出现严重安全问题。

4）相关冲突（Correlation Conflict，CC）：两条流规则的match是相交关系，称这两条流规则之间发生相关冲突。相关冲突会造成部分冗余或者部分更新失败，影响交换设备性能和上层策略实施。

为便于后续的冲突消解，本文将冗余冲突和覆盖冲突进行细化。对于冗余冲突，若规则Ri可以匹配规则Rj所匹配的全部数据流，称Ri与Rj发生泛化冗余冲突（Redundancy Conflict of Generalization，RCG）；否则称Ri与Rj发生部分冗余冲突（Redundancy Conflict of Part，RCP）。同理，覆盖冲突可分为泛化覆盖冲突（Shadowing Conflict of Generalization，SCG）和部分覆盖冲突（Shadowing Conflict of Part，SCP）。

2.6 冲突消解模块

模块根据冲突检测模块的结果，对流规则进行冲突消解处理。流规则Ri与Rj的冲突消解方案如表3 所示。

表3 冲突消解方案Tab.3 Scheme of conflict resolution

由于Ri在下发过程中可能与Set*中的多条规则发生冲突。为此，本文引入了冲突向量，对于新下发流规则Ri都有其对应的冲突向量Vi=(vi1，vi2，…，vin)。其中n为Set*中的规则数，vij表示规则Ri与Rj发生冲突的类型序号。

当∀vij=0 时，直接下发Ri；当∃vij=1 时，中止下发Ri.否则，根据Vi生成规则集Rnew={Ri，≥4}和Rdel={≥2}。将Rdel中的规则从对应交换设备中删除，然后将Rnew中的规则下发，完成冲突消解。

3 协议分集的冲突检测算法

为方便对流规则之间的match关系进行描述，现进行如下定义：

定义1对于任意的Ri.field与Rj.field，其关系存在相等、属于、包含和无关四种情况，分别记作Ri.field=Rj.field、Ri.field⊂Rj.field、Ri.field⊃Rj.field、Ri.field≠Rj.field。

定义2若∃field∈match，使得Ri.field≠Rj.field，称Ri.match与Rj.match无关，记作Ri.matchⓃRj.match。

定义3若∀field∈match，都有Ri.field=Rj.field，称Ri.match与Rj.match相等，记作Ri.matchⒺRj.match。

定义4若∃field∈match，使得Ri.field⊂Rj.field，并且对于∀field∈match，都有Ri.field=Rj.field或Ri.field⊂Rj.field，称Ri.match属于Rj.match，记作Ri.matchⒷRj.match。

定义5若∃field∈match，使得Ri.field⊃Rj.field，并且对于∀field∈match，都有Ri.field=Rj.field或Ri.field⊃Rj.field，称Ri.match包含Rj.match，记作Ri.matchⒸRj.match。

定义6若∃field1，field2∈match，使得Ri.field1⊃Rj.field1，Ri.field2⊃Rj.field2，并且对于∀field∈match，都有Ri.field=Rj.field、Ri.field⊂Rj.field或者Ri.field⊃Rj.field，称Ri.match与Rj.match相交，记作Ri.matchⒾRj.match。

当两条规则所匹配的协议不同时，这两条规则显然不会发生冲突。为此，本文提出一种协议分集的冲突检测算法PDCD（Protocol-Diversity Conflict Detect）。PDCD 选取与待测规则Ri可能存在冲突的规则集合，对其中的NC 情况进行检测。当检测到NC 特征时，返回冲突类型；否则根据流规则match和action的关系对冲突类型作进一步判断。PDCD 检测流程如下：

Step 1 根据Ri.pro在规则数据库中选择该规则可能存在冲突的规则集合Set*。若Ri.pro≠∗，则Set*=Setpro∪Set*；否则Set*=Set*。

Step 2 若Set*=∅，则Ri不与已有规则发生冲突；否则，从Set*中取出一条流规则Rj。

Step 3 若Ri.matchⓃRj.match，则Ri与Rj为NC，转至Step 8。

Step 4 若Ri.matchⒾRj.match，则Ri与Rj为CC，转至Step 8。

Step 5 若Ri.action≠Rj.action，转至Step 6；若Ri.action=Rj.action转至Step 7。

Step 6 判断Ri.match与Rj.match的关系：若Ri.matchⒷRj.match，Ri与Rj为SCP；若Ri.matchⒺRj.match或Ri.matchⒸRj.match，Ri与Rj为SCG。转至Step 8。

Step 7 判断Ri.match与Rj.match的关系：若Ri.matchⒷRj.match，Ri与Rj为RCP；若Ri.matchⒺRj.match或Ri.matchⒸRj.match，Ri与Rj为RCG。转至Step 8。

Step 8 若已取完Set*中所有规则，检测结束；否则取出下一规则转至Step 3。

PDCD 在进行冲突检测时只对可能发生冲突的规则集合进行检测，而文献［11］提出的动态冲突检测模型则需要对规则集合内的全部规则逐条判断。从实际检测规模来看，PDCD 要小于动态冲突检测模型。同时，PDCD 优先对NC 规则进行检测，当检测到某一字段具有NC 规则特征时，立即返回冲突类型，即PDCD 对NC 规则的检测时间更短；而动态冲突检测模型则需要检测所有字段才能判断流规则是否发生冲突。

4 分析验证

本文实验计算机的配置如下：Intel Core i7-9750H CPU 2.6 GHz 处理器，16 GB 内存，Windows 10 操作系统。通过在PyCharm 平台实现PDCD 算法，读入随机生成的流规则集合对算法进行仿真验证，并将仿真结果与同样基于匹配域字段关系判别冲突的动态冲突检测模型［11］进行比较。

4.1 准确性分析

能否准确检测冲突是衡量一个冲突检测算法好坏的基本特征，本节通过改变流规则集合的规模和冲突规则的数目，对两种方法进行实验仿真，结果如表4 所示。从表4 可以看出，在规则集合的规模以及冲突规则数变化的情况下，PDCD 和动态冲突检测模型的冲突检测率都为100%，两者都能有效地对流规则冲突进行检测。

表4 PDCD与动态冲突检测模型检测准确率对比Tab.4 Comparison of detection accuracy between PDCD and dynamic conflict detection model

4.2 耗时分析

本系统使用TCP 代理监听、处理控制器与交换设备之间的报文来进行工作，过长的处理时延会使得报文丢失，导致系统失效，这对算法的检测时间提出了较高的要求。为此，本节将研究不同规模的流规则集合和不同冲突规则占比（保持集合规模为2 000 条规则不变）的流规则集合对两种算法检测时间的影响。

4.2.1 流规则集合规模对检测时间的影响

本节对不同规模的流规则集合进行仿真实验。设待测规则的协议类型为TCP。在网络流量中约有51%采用的是TCP，约有47% 采用UDP，采用其他协议的流量仅占约2%［16］。为模仿真实网络流量，在生成的规则集合时，TCP 类规则占50%，UDP 类规则占46%，其他类型规则占2%，统配类规则占2%。同时，在改变流规则集合规模时，确保各冲突类型的流规则占比保持不变。其中NC 规则占40%，RCP 规则占10%，RCG 规则占10%，SCP 规则占10%，SCG 规则占10%，CC 规则占20%。实验结果如图4 所示。

图4 检测时间与流规则集合规模的关系Fig.4 Relationship between detection time and size of flow rule set

通过图4 可以看出，随着流规则规模的增加，PDCD 和动态冲突检测模型的检测耗时都在增加，但PDCD 相比较动态冲突检测模型，在同等流规则规模下检测时间缩短约47%。这是由于PDCD 在冲突检测之前，根据流规则协议对流规则进行分集，在检测时只选取可能发生冲突的部分规则集合，在一定程度上缩小了检测规模。

4.2.2 冲突规则占比对检测时间的影响

在本节中，主要研究冲突类型占比对检测时间的影响。设待测规则的协议类型为TCP。为了降低协议分集对检测时间造成的影响，在生成的规则集合时，令TCP 类规则占80%，其余协议类型规则占20%。流规则集合中保持2 000条规则不变，改变集合中各类冲突规则所占比重，如表5 所示。实验结果如图5 所示。

表5 各类冲突规则所占比重 单位：%Tab.5 Percentages of various types of conflict rules unit：%

图5 检测时间与NC规则占比的关系Fig.5 Relationship between detection time and percentage of NC rules

如图5 所示，随着NC 规则在规则集合中所占比重逐渐增加，PDCD 的检测耗时逐渐缩短，而动态冲突检测模型的检测时间基本维持不变。当流规则集合中NC 规则达到90%时，相较于动态冲突检测模型，PDCD 的检测时间可以节省约55%；相较于NC 规则占比为40%的情况，性能提升约46%。

由此可以得出，在检测效率上，PDCD 要优于动态冲突检测模型，且随着NC 规则在规则集合中所占比重增加，PDCD的检测效率能够进一步提升。

5 结语

本文基于OpenFlow 协议设计了一款SDN 流规则冲突检测系统，该系统具有可移植性好、拓展性强等优点，并可以根据冲突类型自动进行冲突消解。本文还提出一种流规则冲突检测算法PDCD。实验结果表明，PDCD 能准确检测出规则冲突，且在检测效率上，要优于动态冲突检测模型。

但SDN 中的流规则冲突并不只在单个交换设备中存在，不同的交换设备之间还可能存在依赖冲突，即网络在运行过程中或遭受到攻击时产生了与安全规则相冲突的转发路径［17］，这些非法的转发路径会导致数据泄露或者成为其他网络攻击的“跳板”，例如攻击者可以利用“僵尸网络”通过这些非法路径绕过防火墙对核心服务器进行分布式拒绝服务（Distributed Denial of Service，DDoS）攻击［18］。依赖冲突本质上是转发平面（数据平面）的安全问题，文献［19］针对此类问题给出了部分安全对策，如确保转发平面软件的安全性以及正确合理的网络规划等。下一步，将针对SDN 中流规则依赖冲突的检测展开研究，优化检测算法，增强系统的检测能力，提高SDN 数据平面的安全性。