基于OpenFlow的軟件定義網絡流規則沖突檢測系統

張立群，林海濤，郇文明，畢文婷

（海軍工程大學電子工程學院，武漢 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 數據平面的安全性。