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

（海軍工程大學(xué)電子工程學(xué)院，武漢 430033）

0 引言

在傳統(tǒng)的網(wǎng)絡(luò)架構(gòu)下，網(wǎng)絡(luò)設(shè)備的轉(zhuǎn)發(fā)平面和控制平面緊密耦合。為了對(duì)數(shù)據(jù)流進(jìn)行更加精細(xì)化的處理，解決負(fù)載均衡、訪問(wèn)控制等問(wèn)題，網(wǎng)絡(luò)設(shè)備制造商將包過(guò)濾、多播等功能集成到路由器、交換機(jī)等轉(zhuǎn)發(fā)設(shè)備中，這使得轉(zhuǎn)發(fā)設(shè)備的結(jié)構(gòu)更加復(fù)雜，網(wǎng)絡(luò)變得難以維護(hù)、管理和創(chuàng)新［1］。軟件定義網(wǎng)絡(luò)（Software Defined Network，SDN）由于其便于集中管理、接口可編程、設(shè)備成本低等優(yōu)點(diǎn)［2］，逐漸成為網(wǎng)絡(luò)架構(gòu)的新選擇。

在SDN 架構(gòu)（如圖1）中，南向接口一般采用OpenFlow［3］協(xié)議對(duì)網(wǎng)絡(luò)的轉(zhuǎn)發(fā)平面進(jìn)行編程和控制；北向接口則是為網(wǎng)絡(luò)應(yīng)用方便調(diào)用控制平面的各種功能而提供的各種應(yīng)用程序接口（Application Programming Interface，API），一般有表征狀態(tài)轉(zhuǎn)移（Representational State Transfer，REST）的API、Python API 等［4］。通過(guò)控制平面以及南向和北向接口，網(wǎng)絡(luò)應(yīng)用可以將生成的流規(guī)則下發(fā)到轉(zhuǎn)發(fā)平面的交換設(shè)備中。

圖1 SDN基本架構(gòu)Fig.1 SDN basic architecture

但網(wǎng)絡(luò)應(yīng)用通常獨(dú)立開(kāi)發(fā)，不可避免地會(huì)產(chǎn)生沖突，這將導(dǎo)致網(wǎng)絡(luò)性能降低、網(wǎng)絡(luò)功能失效，甚至引發(fā)嚴(yán)重的網(wǎng)絡(luò)安全問(wèn)題，造成難以估量的損失。而且由于SDN 的控制平面和轉(zhuǎn)發(fā)平面相分離，轉(zhuǎn)發(fā)平面缺乏策略分析能力，交換設(shè)備無(wú)法獨(dú)立檢測(cè)內(nèi)部流規(guī)則的合理性［5］。因此，亟須一種沖突檢測(cè)系統(tǒng)來(lái)對(duì)SDN 中的流規(guī)則進(jìn)行檢測(cè)。

為解決上述問(wèn)題，本文提出一種SDN 流規(guī)則沖突檢測(cè)系統(tǒng)，該系統(tǒng)將對(duì)應(yīng)用平面生成的待下發(fā)流規(guī)則進(jìn)行實(shí)時(shí)沖突檢測(cè)，并根據(jù)沖突檢測(cè)結(jié)果給出沖突消解策略。

1 相關(guān)工作

為解決SDN 中的流規(guī)則沖突問(wèn)題，文獻(xiàn)［6］在控制平面和轉(zhuǎn)發(fā)平面之間提出一個(gè)新的邏輯層VeriFlow。通過(guò)將具有相同轉(zhuǎn)發(fā)操作的數(shù)據(jù)包劃分為等價(jià)類并構(gòu)建轉(zhuǎn)發(fā)圖，VeriFlow 可在插入、修改或刪除流規(guī)則時(shí)動(dòng)態(tài)檢測(cè)網(wǎng)絡(luò)中是否存在轉(zhuǎn)發(fā)環(huán)和網(wǎng)絡(luò)的可達(dá)性等問(wèn)題；但VeriFlow 各模塊之間耦合較強(qiáng)，拓展性較差。文獻(xiàn)［7］提出了一種實(shí)驗(yàn)分析沖突的通用方法。該方法構(gòu)造了一個(gè)參數(shù)空間，將SDN 的網(wǎng)絡(luò)狀態(tài)抽象為空間中一系列的點(diǎn)，通過(guò)比較網(wǎng)絡(luò)狀態(tài)的預(yù)期行為和實(shí)驗(yàn)行為，對(duì)參數(shù)空間中的點(diǎn)進(jìn)行標(biāo)記并對(duì)根據(jù)沖突原因?qū)_突點(diǎn)進(jìn)行分類；但該方法需要進(jìn)行大量實(shí)驗(yàn)，且針對(duì)性較強(qiáng)，一旦網(wǎng)絡(luò)參數(shù)發(fā)生變化，需要通過(guò)實(shí)驗(yàn)重新構(gòu)建模型。

文獻(xiàn)［8］針對(duì)NOX［9］設(shè)計(jì)了一款安全內(nèi)核FortNOX，可以提供基于角色的源身份認(rèn)證并提出一種別名簡(jiǎn)化的規(guī)則集算法。該算法可以檢測(cè)由于SET 指令導(dǎo)致的依賴沖突，但在某些復(fù)雜情況下可能會(huì)發(fā)生漏報(bào)和誤報(bào)。而且FortNOX只針對(duì)NOX，可移植性較差。文獻(xiàn)［10］則基于一階謂詞演算提出一種反射代理模型，對(duì)流規(guī)則可能產(chǎn)生的靜態(tài)沖突和動(dòng)態(tài)沖突進(jìn)行檢測(cè)，但其未對(duì)動(dòng)態(tài)沖突類型進(jìn)行更加細(xì)致的分類，不利于對(duì)沖突的消解。

文獻(xiàn)［11］提出一種動(dòng)態(tài)沖突檢測(cè)模型，該模型基于流規(guī)則匹配域和動(dòng)作域關(guān)系判別規(guī)則沖突，對(duì)沖突類型進(jìn)行了更為細(xì)致的分類，且檢測(cè)準(zhǔn)確率較高；但由于要對(duì)所有規(guī)則逐一判斷，且需對(duì)所有字段關(guān)系判斷完畢后才能得出沖突結(jié)果，檢測(cè)時(shí)間較長(zhǎng)。

上述檢測(cè)方法的主要不足如表1 所示。

表1 上述檢測(cè)方法的主要不足Tab.1 Main shortages of the above detection methods

2 系統(tǒng)架構(gòu)與組成

針對(duì)上述SDN 沖突檢測(cè)研究的不足，本文設(shè)計(jì)了一種新的沖突檢測(cè)系統(tǒng)。系統(tǒng)主要包含六個(gè)模塊：傳輸控制協(xié)議（Transmission Control Protocol，TCP）代理模塊、捕獲解析模塊、格式化模塊、沖突檢測(cè)模塊、規(guī)則數(shù)據(jù)庫(kù)模塊以及沖突消解模塊。系統(tǒng)結(jié)構(gòu)如圖2 所示。

圖2 系統(tǒng)結(jié)構(gòu)Fig.2 System structure

2.1 TCP代理模塊

在SDN 中，OpenFlow 交換設(shè)備通過(guò)基于TCP 的安全通道與控制器連接，用于傳輸與控制器之間的OpenFlow 報(bào)文。為此，可以通過(guò)建立TCP 代理來(lái)實(shí)現(xiàn)對(duì)安全通道中的OpenFlow 報(bào)文監(jiān)聽(tīng)和處理。

TCP 代理模塊實(shí)時(shí)監(jiān)聽(tīng)來(lái)自轉(zhuǎn)發(fā)設(shè)備的TCP 連接請(qǐng)求。當(dāng)監(jiān)聽(tīng)到建立TCP 連接的請(qǐng)求時(shí)，代理模塊創(chuàng)建線程Th 用于處理控制器與該轉(zhuǎn)發(fā)設(shè)備的代理連接，在線程Th 中創(chuàng)建兩個(gè)子線程Th_1 和Th_2 用于實(shí)現(xiàn)控制器與轉(zhuǎn)發(fā)設(shè)備的全雙工通信。其中Th_1 將來(lái)自交換設(shè)備的報(bào)文轉(zhuǎn)發(fā)給控制器，捕獲、處理轉(zhuǎn)發(fā)設(shè)備向控制器發(fā)送的報(bào)文；而Th_2 將來(lái)自控制設(shè)備的報(bào)文發(fā)送給轉(zhuǎn)發(fā)設(shè)備，捕獲、處理控制器下發(fā)至轉(zhuǎn)發(fā)設(shè)備的報(bào)文。

若代理模塊長(zhǎng)時(shí)間不能監(jiān)聽(tīng)到報(bào)文，則要檢測(cè)TCP 連接是否有效。若連接失效，則釋放代理連接；否則繼續(xù)監(jiān)聽(tīng)。

2.2 流規(guī)則捕獲解析模塊

現(xiàn)在SDN 中較常使用的南向協(xié)議是OpenFlow_1.0 和OpenFlow_1.3［12］。

TCP 代理實(shí)時(shí)監(jiān)聽(tīng)控制平面與轉(zhuǎn)發(fā)平面?zhèn)鬏數(shù)臄?shù)據(jù)報(bào)。對(duì)于OpenFlow_1.0［13］，主要是監(jiān)聽(tīng)Flow_MOD 報(bào)文、FEATURES_REPLY 報(bào)文和STATS_REPLY 報(bào)文。而在OpenFlow_1.3［14］中，則主要監(jiān)聽(tīng) Flow_MOD 報(bào)文、FEATURES_REPLY 報(bào)文以及MUIPART_REPLY 報(bào)文［4，14］。

當(dāng)模塊檢測(cè)到Flow_MOD 報(bào)文的Command 值為OFPFC_ADD 時(shí)，表明控制器正在下發(fā)新的流規(guī)則到轉(zhuǎn)發(fā)設(shè)備。模塊對(duì)該報(bào)文及進(jìn)行捕獲、解析，獲取新增規(guī)則的匹配域和動(dòng)作域信息，而后將該信息交由后續(xù)模塊進(jìn)行處理。

FEATURES_REPLY 報(bào)文中包含設(shè)備的數(shù)據(jù)路徑識(shí)別碼（Datapath Identity Document，DPID），據(jù)此可以對(duì)TCP 代理進(jìn)程進(jìn)行標(biāo)記，區(qū)分代理進(jìn)程所連接的交換設(shè)備。

STATS_REPLY 報(bào)文（OpenFlow_1.0）和 Type 值為OFPMP_FLOW 的MUIPART_REPLY 報(bào)文（OpenFlow_1.3）則包含了交換設(shè)備中存在的全部流規(guī)則。通過(guò)解析這些報(bào)文，可以獲取交換設(shè)備中已存在的流規(guī)則信息，信息經(jīng)過(guò)格式化模塊后用于構(gòu)建規(guī)則數(shù)據(jù)庫(kù)。

對(duì)于其他類型的報(bào)文，模塊不進(jìn)行處理，直接交付給接收方。若要對(duì)其他版本的OpenFlow 協(xié)議處理，只需對(duì)該模塊進(jìn)行相關(guān)解析函數(shù)的更新即可。

2.3 流規(guī)則格式化模塊

在OpenFlow_1.3［14］中，其match中的字段有40 多種。但在網(wǎng)絡(luò)中一般使用IP 地址、媒體接入控制（Media Access Control，MAC）地址、協(xié)議類型等字段就可以實(shí)現(xiàn)數(shù)據(jù)流的匹配，其他字段大多為通配值。同樣，管理網(wǎng)絡(luò)常用的動(dòng)作action主要有轉(zhuǎn)發(fā)、修改和丟棄［1］。本系統(tǒng)在確保沖突檢測(cè)準(zhǔn)確性的前提下，為方便沖突檢測(cè)過(guò)程，將流規(guī)則格式化為如下形式：

Ri={match，action}

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

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

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

表2 某個(gè)流規(guī)則中的字段名及含義Tab.2 Field names and meanings in a flow rule

若流規(guī)則match中的字段在Flow_Mod 報(bào)文中未賦值，則模塊將該字段的值設(shè)置為通配符“*”，即該字段匹配所有數(shù)據(jù)流；若在Flow_Mod 報(bào)文中流規(guī)則的action未賦值，則模塊設(shè)置該規(guī)則的action為drop。

2.4 規(guī)則數(shù)據(jù)庫(kù)模塊

規(guī)則數(shù)據(jù)庫(kù)模塊可以模仿控制器發(fā)送請(qǐng)求流表狀態(tài)的MUIPART_REQUEST 報(bào)文，然后根據(jù)轉(zhuǎn)發(fā)平面返回的MUIPART_REPLY 報(bào)文解析構(gòu)建格式化流規(guī)則數(shù)據(jù)庫(kù)。每一個(gè)交換設(shè)備的流規(guī)則會(huì)根據(jù)協(xié)議類型存儲(chǔ)在SetTCP、SetUDP、SetOTH和Set*四個(gè)集合中，如圖3 所示。其中，SetTCP中存放協(xié)議類型是TCP 的流規(guī)則；SetUDP中存放協(xié)議類型是用戶數(shù)據(jù)報(bào)協(xié)議（User Datagram Protocol，UDP）的流規(guī)則；SetOTH中存放協(xié)議類型既不是TCP 也不是UDP 的流規(guī)則，Set*中存放協(xié)議類型是通配符的流規(guī)則。模塊定時(shí)發(fā)送報(bào)文對(duì)數(shù)據(jù)進(jìn)行更新。同時(shí)，每次下發(fā)新的流規(guī)則后，模塊也要對(duì)規(guī)則數(shù)據(jù)進(jìn)行更新，使得模塊內(nèi)數(shù)據(jù)與交換設(shè)備中的數(shù)據(jù)保持一致，確保沖突檢測(cè)結(jié)果的準(zhǔn)確性。

圖3 存儲(chǔ)結(jié)構(gòu)Fig.3 Storage structure

2.5 沖突檢測(cè)模塊

沖突檢測(cè)模塊是沖突檢測(cè)系統(tǒng)的核心模塊，對(duì)新下發(fā)規(guī)則和交換設(shè)備中已經(jīng)存在的規(guī)則進(jìn)行沖突檢測(cè)。模塊根據(jù)不同種類沖突［15］的特點(diǎn)將沖突類型劃分如下。

1）無(wú)沖突（Non-Conflict，NC）：兩條流規(guī)則的match無(wú)關(guān)，稱這兩條流規(guī)則間無(wú)沖突。

2）冗余沖突（Redundancy Conflict，RC）：兩條流規(guī)則的match是包含關(guān)系且對(duì)數(shù)據(jù)流所作操作相同，稱這兩條流規(guī)則之間發(fā)生冗余沖突。冗余流規(guī)則會(huì)占用交換設(shè)備內(nèi)存，增加匹配時(shí)間，引起一些優(yōu)化和效率問(wèn)題。

3）覆蓋沖突（Shadowing Conflict，SC）：兩條流規(guī)則的match是包含關(guān)系且對(duì)數(shù)據(jù)流所作操作不同，稱這兩條流規(guī)則之間發(fā)生覆蓋沖突。覆蓋沖突會(huì)導(dǎo)致管理員對(duì)網(wǎng)絡(luò)策略的更新失效，使數(shù)據(jù)在轉(zhuǎn)發(fā)時(shí)出現(xiàn)嚴(yán)重安全問(wèn)題。

4）相關(guān)沖突（Correlation Conflict，CC）：兩條流規(guī)則的match是相交關(guān)系，稱這兩條流規(guī)則之間發(fā)生相關(guān)沖突。相關(guān)沖突會(huì)造成部分冗余或者部分更新失敗，影響交換設(shè)備性能和上層策略實(shí)施。

為便于后續(xù)的沖突消解，本文將冗余沖突和覆蓋沖突進(jìn)行細(xì)化。對(duì)于冗余沖突，若規(guī)則Ri可以匹配規(guī)則Rj所匹配的全部數(shù)據(jù)流，稱Ri與Rj發(fā)生泛化冗余沖突（Redundancy Conflict of Generalization，RCG）；否則稱Ri與Rj發(fā)生部分冗余沖突（Redundancy Conflict of Part，RCP）。同理，覆蓋沖突可分為泛化覆蓋沖突（Shadowing Conflict of Generalization，SCG）和部分覆蓋沖突（Shadowing Conflict of Part，SCP）。

2.6 沖突消解模塊

模塊根據(jù)沖突檢測(cè)模塊的結(jié)果，對(duì)流規(guī)則進(jìn)行沖突消解處理。流規(guī)則Ri與Rj的沖突消解方案如表3 所示。

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

由于Ri在下發(fā)過(guò)程中可能與Set*中的多條規(guī)則發(fā)生沖突。為此，本文引入了沖突向量，對(duì)于新下發(fā)流規(guī)則Ri都有其對(duì)應(yīng)的沖突向量Vi=(vi1，vi2，…，vin)。其中n為Set*中的規(guī)則數(shù)，vij表示規(guī)則Ri與Rj發(fā)生沖突的類型序號(hào)。

當(dāng)?vij=0 時(shí)，直接下發(fā)Ri；當(dāng)?vij=1 時(shí)，中止下發(fā)Ri.否則，根據(jù)Vi生成規(guī)則集Rnew={Ri，≥4}和Rdel={≥2}。將Rdel中的規(guī)則從對(duì)應(yīng)交換設(shè)備中刪除，然后將Rnew中的規(guī)則下發(fā)，完成沖突消解。

3 協(xié)議分集的沖突檢測(cè)算法

為方便對(duì)流規(guī)則之間的match關(guān)系進(jìn)行描述，現(xiàn)進(jìn)行如下定義：

定義1對(duì)于任意的Ri.field與Rj.field，其關(guān)系存在相等、屬于、包含和無(wú)關(guān)四種情況，分別記作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無(wú)關(guān)，記作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，并且對(duì)于?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，并且對(duì)于?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，并且對(duì)于?field∈match，都有Ri.field=Rj.field、Ri.field?Rj.field或者Ri.field?Rj.field，稱Ri.match與Rj.match相交，記作Ri.match?Rj.match。

當(dāng)兩條規(guī)則所匹配的協(xié)議不同時(shí)，這兩條規(guī)則顯然不會(huì)發(fā)生沖突。為此，本文提出一種協(xié)議分集的沖突檢測(cè)算法PDCD（Protocol-Diversity Conflict Detect）。PDCD 選取與待測(cè)規(guī)則Ri可能存在沖突的規(guī)則集合，對(duì)其中的NC 情況進(jìn)行檢測(cè)。當(dāng)檢測(cè)到NC 特征時(shí)，返回沖突類型；否則根據(jù)流規(guī)則match和action的關(guān)系對(duì)沖突類型作進(jìn)一步判斷。PDCD 檢測(cè)流程如下：

Step 1 根據(jù)Ri.pro在規(guī)則數(shù)據(jù)庫(kù)中選擇該規(guī)則可能存在沖突的規(guī)則集合Set*。若Ri.pro≠?，則Set*=Setpro∪Set*；否則Set*=Set*。

Step 2 若Set*=?，則Ri不與已有規(guī)則發(fā)生沖突；否則，從Set*中取出一條流規(guī)則Rj。

Step 3 若Ri.match?Rj.match，則Ri與Rj為NC，轉(zhuǎn)至Step 8。

Step 4 若Ri.match?Rj.match，則Ri與Rj為CC，轉(zhuǎn)至Step 8。

Step 5 若Ri.action≠Rj.action，轉(zhuǎn)至Step 6；若Ri.action=Rj.action轉(zhuǎn)至Step 7。

Step 6 判斷Ri.match與Rj.match的關(guān)系：若Ri.match?Rj.match，Ri與Rj為SCP；若Ri.match?Rj.match或Ri.match?Rj.match，Ri與Rj為SCG。轉(zhuǎn)至Step 8。

Step 7 判斷Ri.match與Rj.match的關(guān)系：若Ri.match?Rj.match，Ri與Rj為RCP；若Ri.match?Rj.match或Ri.match?Rj.match，Ri與Rj為RCG。轉(zhuǎn)至Step 8。

Step 8 若已取完Set*中所有規(guī)則，檢測(cè)結(jié)束；否則取出下一規(guī)則轉(zhuǎn)至Step 3。

PDCD 在進(jìn)行沖突檢測(cè)時(shí)只對(duì)可能發(fā)生沖突的規(guī)則集合進(jìn)行檢測(cè)，而文獻(xiàn)［11］提出的動(dòng)態(tài)沖突檢測(cè)模型則需要對(duì)規(guī)則集合內(nèi)的全部規(guī)則逐條判斷。從實(shí)際檢測(cè)規(guī)模來(lái)看，PDCD 要小于動(dòng)態(tài)沖突檢測(cè)模型。同時(shí)，PDCD 優(yōu)先對(duì)NC 規(guī)則進(jìn)行檢測(cè)，當(dāng)檢測(cè)到某一字段具有NC 規(guī)則特征時(shí)，立即返回沖突類型，即PDCD 對(duì)NC 規(guī)則的檢測(cè)時(shí)間更短；而動(dòng)態(tài)沖突檢測(cè)模型則需要檢測(cè)所有字段才能判斷流規(guī)則是否發(fā)生沖突。

4 分析驗(yàn)證

本文實(shí)驗(yàn)計(jì)算機(jī)的配置如下：Intel Core i7-9750H CPU 2.6 GHz 處理器，16 GB 內(nèi)存，Windows 10 操作系統(tǒng)。通過(guò)在PyCharm 平臺(tái)實(shí)現(xiàn)PDCD 算法，讀入隨機(jī)生成的流規(guī)則集合對(duì)算法進(jìn)行仿真驗(yàn)證，并將仿真結(jié)果與同樣基于匹配域字段關(guān)系判別沖突的動(dòng)態(tài)沖突檢測(cè)模型［11］進(jìn)行比較。

4.1 準(zhǔn)確性分析

能否準(zhǔn)確檢測(cè)沖突是衡量一個(gè)沖突檢測(cè)算法好壞的基本特征，本節(jié)通過(guò)改變流規(guī)則集合的規(guī)模和沖突規(guī)則的數(shù)目，對(duì)兩種方法進(jìn)行實(shí)驗(yàn)仿真，結(jié)果如表4 所示。從表4 可以看出，在規(guī)則集合的規(guī)模以及沖突規(guī)則數(shù)變化的情況下，PDCD 和動(dòng)態(tài)沖突檢測(cè)模型的沖突檢測(cè)率都為100%，兩者都能有效地對(duì)流規(guī)則沖突進(jìn)行檢測(cè)。

表4 PDCD與動(dòng)態(tài)沖突檢測(cè)模型檢測(cè)準(zhǔn)確率對(duì)比Tab.4 Comparison of detection accuracy between PDCD and dynamic conflict detection model

4.2 耗時(shí)分析

本系統(tǒng)使用TCP 代理監(jiān)聽(tīng)、處理控制器與交換設(shè)備之間的報(bào)文來(lái)進(jìn)行工作，過(guò)長(zhǎng)的處理時(shí)延會(huì)使得報(bào)文丟失，導(dǎo)致系統(tǒng)失效，這對(duì)算法的檢測(cè)時(shí)間提出了較高的要求。為此，本節(jié)將研究不同規(guī)模的流規(guī)則集合和不同沖突規(guī)則占比（保持集合規(guī)模為2 000 條規(guī)則不變）的流規(guī)則集合對(duì)兩種算法檢測(cè)時(shí)間的影響。

4.2.1 流規(guī)則集合規(guī)模對(duì)檢測(cè)時(shí)間的影響

本節(jié)對(duì)不同規(guī)模的流規(guī)則集合進(jìn)行仿真實(shí)驗(yàn)。設(shè)待測(cè)規(guī)則的協(xié)議類型為TCP。在網(wǎng)絡(luò)流量中約有51%采用的是TCP，約有47% 采用UDP，采用其他協(xié)議的流量?jī)H占約2%［16］。為模仿真實(shí)網(wǎng)絡(luò)流量，在生成的規(guī)則集合時(shí)，TCP 類規(guī)則占50%，UDP 類規(guī)則占46%，其他類型規(guī)則占2%，統(tǒng)配類規(guī)則占2%。同時(shí)，在改變流規(guī)則集合規(guī)模時(shí)，確保各沖突類型的流規(guī)則占比保持不變。其中NC 規(guī)則占40%，RCP 規(guī)則占10%，RCG 規(guī)則占10%，SCP 規(guī)則占10%，SCG 規(guī)則占10%，CC 規(guī)則占20%。實(shí)驗(yàn)結(jié)果如圖4 所示。

圖4 檢測(cè)時(shí)間與流規(guī)則集合規(guī)模的關(guān)系Fig.4 Relationship between detection time and size of flow rule set

通過(guò)圖4 可以看出，隨著流規(guī)則規(guī)模的增加，PDCD 和動(dòng)態(tài)沖突檢測(cè)模型的檢測(cè)耗時(shí)都在增加，但PDCD 相比較動(dòng)態(tài)沖突檢測(cè)模型，在同等流規(guī)則規(guī)模下檢測(cè)時(shí)間縮短約47%。這是由于PDCD 在沖突檢測(cè)之前，根據(jù)流規(guī)則協(xié)議對(duì)流規(guī)則進(jìn)行分集，在檢測(cè)時(shí)只選取可能發(fā)生沖突的部分規(guī)則集合，在一定程度上縮小了檢測(cè)規(guī)模。

4.2.2 沖突規(guī)則占比對(duì)檢測(cè)時(shí)間的影響

在本節(jié)中，主要研究沖突類型占比對(duì)檢測(cè)時(shí)間的影響。設(shè)待測(cè)規(guī)則的協(xié)議類型為TCP。為了降低協(xié)議分集對(duì)檢測(cè)時(shí)間造成的影響，在生成的規(guī)則集合時(shí)，令TCP 類規(guī)則占80%，其余協(xié)議類型規(guī)則占20%。流規(guī)則集合中保持2 000條規(guī)則不變，改變集合中各類沖突規(guī)則所占比重，如表5 所示。實(shí)驗(yàn)結(jié)果如圖5 所示。

表5 各類沖突規(guī)則所占比重 單位：%Tab.5 Percentages of various types of conflict rules unit：%

圖5 檢測(cè)時(shí)間與NC規(guī)則占比的關(guān)系Fig.5 Relationship between detection time and percentage of NC rules

如圖5 所示，隨著NC 規(guī)則在規(guī)則集合中所占比重逐漸增加，PDCD 的檢測(cè)耗時(shí)逐漸縮短，而動(dòng)態(tài)沖突檢測(cè)模型的檢測(cè)時(shí)間基本維持不變。當(dāng)流規(guī)則集合中NC 規(guī)則達(dá)到90%時(shí)，相較于動(dòng)態(tài)沖突檢測(cè)模型，PDCD 的檢測(cè)時(shí)間可以節(jié)省約55%；相較于NC 規(guī)則占比為40%的情況，性能提升約46%。

由此可以得出，在檢測(cè)效率上，PDCD 要優(yōu)于動(dòng)態(tài)沖突檢測(cè)模型，且隨著NC 規(guī)則在規(guī)則集合中所占比重增加，PDCD的檢測(cè)效率能夠進(jìn)一步提升。

5 結(jié)語(yǔ)

本文基于OpenFlow 協(xié)議設(shè)計(jì)了一款SDN 流規(guī)則沖突檢測(cè)系統(tǒng)，該系統(tǒng)具有可移植性好、拓展性強(qiáng)等優(yōu)點(diǎn)，并可以根據(jù)沖突類型自動(dòng)進(jìn)行沖突消解。本文還提出一種流規(guī)則沖突檢測(cè)算法PDCD。實(shí)驗(yàn)結(jié)果表明，PDCD 能準(zhǔn)確檢測(cè)出規(guī)則沖突，且在檢測(cè)效率上，要優(yōu)于動(dòng)態(tài)沖突檢測(cè)模型。

但SDN 中的流規(guī)則沖突并不只在單個(gè)交換設(shè)備中存在，不同的交換設(shè)備之間還可能存在依賴沖突，即網(wǎng)絡(luò)在運(yùn)行過(guò)程中或遭受到攻擊時(shí)產(chǎn)生了與安全規(guī)則相沖突的轉(zhuǎn)發(fā)路徑［17］，這些非法的轉(zhuǎn)發(fā)路徑會(huì)導(dǎo)致數(shù)據(jù)泄露或者成為其他網(wǎng)絡(luò)攻擊的“跳板”，例如攻擊者可以利用“僵尸網(wǎng)絡(luò)”通過(guò)這些非法路徑繞過(guò)防火墻對(duì)核心服務(wù)器進(jìn)行分布式拒絕服務(wù)（Distributed Denial of Service，DDoS）攻擊［18］。依賴沖突本質(zhì)上是轉(zhuǎn)發(fā)平面（數(shù)據(jù)平面）的安全問(wèn)題，文獻(xiàn)［19］針對(duì)此類問(wèn)題給出了部分安全對(duì)策，如確保轉(zhuǎn)發(fā)平面軟件的安全性以及正確合理的網(wǎng)絡(luò)規(guī)劃等。下一步，將針對(duì)SDN 中流規(guī)則依賴沖突的檢測(cè)展開(kāi)研究，優(yōu)化檢測(cè)算法，增強(qiáng)系統(tǒng)的檢測(cè)能力，提高SDN 數(shù)據(jù)平面的安全性。