常朝穩(wěn)，金建樹，韓培勝，?，F(xiàn)威

（信息工程大學(xué)，河南 鄭州 450001）

1 引言

軟件定義網(wǎng)絡(luò)（SDN,software-defined networking）[1]通過采用集中的控制平面與分散的數(shù)據(jù)轉(zhuǎn)發(fā)平面，并將2 個平面解耦，從而實現(xiàn)了高度集中的控制轉(zhuǎn)發(fā)能力以及較靈活的擴展能力[2-3]。但是，隨著SDN 的深入發(fā)展，產(chǎn)生了不少安全問題，如：1) 對于SDN 中的數(shù)據(jù)流缺乏安全性驗證的缺陷，會導(dǎo)致惡意用戶發(fā)送一些非法數(shù)據(jù)流被SDN 正常轉(zhuǎn)發(fā)；2) SDN 與傳統(tǒng)網(wǎng)絡(luò)相比更加開放，一旦有惡意入侵，由于其隱蔽性極強，對于入侵者的流量篡改以及惡意竊聽等攻擊方式，現(xiàn)有的SDN 體系很難識別以及防御[4-5]；3) 數(shù)據(jù)完整性的保護較弱，正常用戶的數(shù)據(jù)包被篡改后很難被檢測[6-7]。

王首一等[8]提出了一種數(shù)據(jù)包安全轉(zhuǎn)發(fā)驗證方案，通過SDN 特有的消息機制以及統(tǒng)計數(shù)據(jù)流轉(zhuǎn)發(fā)設(shè)備的流轉(zhuǎn)發(fā)量，由控制器對數(shù)據(jù)包的MAC 值和其他統(tǒng)計信息進行對比，從而達(dá)到檢測異常轉(zhuǎn)發(fā)行為的功能，但該方案需要同時控制交換機的出入口，且適用的匹配字段數(shù)量有限。Sasaki 等[9]提出了一種SDNsec 方法，在數(shù)據(jù)流中添加特定的流標(biāo)簽，從而驗證數(shù)據(jù)是否安全轉(zhuǎn)發(fā)，但需要通過修改交換機內(nèi)部原有實現(xiàn)機制來實現(xiàn)。秦晰等[10]提出了一種基于密碼標(biāo)識的數(shù)據(jù)包驗證模型，通過在數(shù)據(jù)包中嵌入密碼標(biāo)識并設(shè)計SDN 匿名認(rèn)證協(xié)議，由認(rèn)證交換機對數(shù)據(jù)流進行驗證，但該方案需要在交換機上開發(fā)安全模塊，且在密鑰的存儲與管理方面存在問題。

在傳統(tǒng)的基于身份的密碼體制中，通常使用一段字符串來標(biāo)識用戶的身份。通信方式是一對一的，驗證者通過驗證簽名者的簽名來確認(rèn)簽名方的身份。但是，將這種方式應(yīng)用到SDN 這樣的分布式網(wǎng)絡(luò)中，不僅在密鑰管理和分配上較為煩瑣，缺乏有效的管理方式確保密鑰的安全性，而且會引入較大的通信開銷。而屬性簽名作為數(shù)字簽名的延伸，采用一對多的通信方式，被驗證者使用自身的屬性集對消息進行簽名，驗證者通過判斷得到的屬性集合是否與被驗證者聲稱的屬性集合一致來判斷簽名的真?zhèn)蝃11]。這種方案可以細(xì)粒度地劃分身份特征，具有很強的匿名性和靈活性，很適合SDN環(huán)境下的數(shù)據(jù)安全性驗證。

P4 語言[12]是一種高級編程語言，它主要使用可編程包處理器來對數(shù)據(jù)平面進行編程?；赑4 語言的轉(zhuǎn)發(fā)設(shè)備可以自定義數(shù)據(jù)包的轉(zhuǎn)發(fā)處理動作，而不再受到現(xiàn)有協(xié)議的約束[13]。

本文提出了一種基于屬性簽名標(biāo)識的SDN 數(shù)據(jù)包轉(zhuǎn)發(fā)驗證轉(zhuǎn)發(fā)方案，由P4 轉(zhuǎn)發(fā)設(shè)備對用戶發(fā)出的數(shù)據(jù)包添加屬性簽名標(biāo)識，同時完成了數(shù)據(jù)包采樣以及解析轉(zhuǎn)發(fā)控制等功能。然后使用在SDN控制器上開發(fā)App 的方法完成了對數(shù)據(jù)包的屬性簽名的驗證，以及對于異常數(shù)據(jù)流的轉(zhuǎn)發(fā)控制等功能。此外，本文還引入了多控制器架構(gòu)解決了控制器單點失效問題。

本文方案主要面向工業(yè)控制系統(tǒng)、戰(zhàn)術(shù)互聯(lián)網(wǎng)以及校園網(wǎng)等場景。這些系統(tǒng)的特點是系統(tǒng)較為封閉、用戶數(shù)量相對較少但安全性要求較高。屬性簽名方案可以實現(xiàn)數(shù)據(jù)流的真實性與完整性檢測，在保證用戶匿名性的同時實現(xiàn)了用戶身份可追蹤功能，但會帶來一定的時間開銷。這些特點決定了該方案適用于上述場景。在實驗環(huán)節(jié)，本文搭建了一個與上述場景網(wǎng)絡(luò)拓?fù)湎嗨频膶嶒灜h(huán)境，并測試了方案的功能和性能。

本文主要的貢獻有以下4 點。

1) 將屬性簽名算法應(yīng)用到SDN 數(shù)據(jù)流轉(zhuǎn)發(fā)驗證中，通過對用戶屬性的細(xì)粒度劃分以及對屬性集合的簽名驗證實現(xiàn)了對用戶在網(wǎng)絡(luò)中發(fā)送的數(shù)據(jù)流的精確轉(zhuǎn)發(fā)驗證，從而實現(xiàn)了數(shù)據(jù)流的真實性和完整性驗證，以及用戶身份可追蹤等功能。

2) 引入P4轉(zhuǎn)發(fā)設(shè)備實現(xiàn)了SDN數(shù)據(jù)平面可編程功能，通過在交換機對數(shù)據(jù)流進行解析的方式實現(xiàn)了添加屬性簽名標(biāo)識、隨機采樣以及轉(zhuǎn)發(fā)控制等功能。

3) 引入主從控制器模式，優(yōu)化了控制器性能，避免單點失效故障。

4) 實際部署了屬性簽名驗證原型系統(tǒng)，并在Mininet 環(huán)境下中進行了實驗驗證與分析。

2 方案內(nèi)容

2.1 方案描述

2.1.1 基本原理

針對SDN 數(shù)據(jù)流缺乏有效轉(zhuǎn)發(fā)驗證方法以及網(wǎng)絡(luò)中的數(shù)據(jù)流缺乏精確控制等問題，本文提出了一種基于屬性簽名標(biāo)識的SDN 數(shù)據(jù)包轉(zhuǎn)發(fā)驗證方案。通過將用戶的屬性與其所發(fā)送數(shù)據(jù)流進行綁定從而實現(xiàn)數(shù)據(jù)流的安全轉(zhuǎn)發(fā)。用戶的屬性是指每個用戶所具有的屬性集合，系統(tǒng)對該屬性進行簽名操作，并由控制器對其進行簽名驗證，從而判斷數(shù)據(jù)流在轉(zhuǎn)發(fā)過程中是否出現(xiàn)異常情況。同時，將數(shù)據(jù)平面可編程交換機P4 引入該方案中，實現(xiàn)了對數(shù)據(jù)流的精確采樣控制功能。該方案的核心技術(shù)為屬性簽名方案以及數(shù)據(jù)平面可編程技術(shù)，二者共同構(gòu)建了該安全體系。

2.1.2 整體結(jié)構(gòu)

基于屬性簽名標(biāo)識的數(shù)據(jù)包轉(zhuǎn)發(fā)驗證方案由以下幾個部分組成，其基本結(jié)構(gòu)如圖1 所示。

圖1 轉(zhuǎn)發(fā)驗證方案基本結(jié)構(gòu)

1) 屬性簽名標(biāo)識認(rèn)證中心。首先，生成系統(tǒng)公開參數(shù)與主密鑰；然后，生成訪問控制結(jié)構(gòu)的公開參數(shù)，根據(jù)用戶的屬性集生成用戶身份屬性的訪問控制結(jié)構(gòu)的相關(guān)參數(shù)；最后，根據(jù)屬性標(biāo)識生成用于屬性簽名的屬性私鑰。

2) 用戶，是指所有接入該SDN 的訪問用戶。每個訪問用戶都會有屬性信息（例如XX 大學(xué)XX 學(xué)院XX 系王XX 教授）。本文方案通過采集用戶的獨有屬性信息并生成屬性集合來實現(xiàn)針對每一個用戶的屬性簽名，每個屬性集合都代表著唯一的用戶。

3) 屬性簽名標(biāo)識生成模塊。該模塊是屬性簽名標(biāo)識管理的核心。其功能是為用戶生成屬性集，并發(fā)送給認(rèn)證中心；接收用戶的屬性私鑰，并用該私鑰對IP 數(shù)據(jù)包進行簽名，通過修改IP 數(shù)據(jù)包格式的方式將簽名封裝到數(shù)據(jù)包中。在文獻[14]中，該組件以應(yīng)用程序的形式安裝在用戶主機上。但是，考慮到首先為每個用戶所在的主機安裝應(yīng)用程序，增加了系統(tǒng)的開發(fā)成本以及管理難度；其次安裝在用戶主機上的組件對于用戶而言是不透明的，攻擊者可以通過入侵該應(yīng)用程序的方式截獲簽名標(biāo)識，從而給系統(tǒng)帶來一定的安全威脅，由于P4 轉(zhuǎn)發(fā)設(shè)備具有數(shù)據(jù)平面可編程的功能，本文方案將屬性簽名標(biāo)識生成組件安裝在P4 轉(zhuǎn)發(fā)設(shè)備上，由P4 交換機完成屬性簽名標(biāo)識的生成這一功能。

4) 轉(zhuǎn)發(fā)設(shè)備，包括P4 轉(zhuǎn)發(fā)設(shè)備與OpenFlow交換機。

P4 轉(zhuǎn)發(fā)設(shè)備，實現(xiàn)了數(shù)據(jù)平面可編程功能。其主要由采樣控制模塊以及數(shù)據(jù)包鏡像模塊組成，主要負(fù)責(zé)屬性簽名標(biāo)識的生成、數(shù)據(jù)包的采樣檢測以及精確轉(zhuǎn)發(fā)。

OpenFlow 交換機主要負(fù)責(zé)接收控制器發(fā)出的流表，并根據(jù)流表中的策略規(guī)則，對數(shù)據(jù)包進行轉(zhuǎn)發(fā)、丟棄等動作。

5) SDN 控制器（下文簡稱為控制器），由屬性簽名驗證模塊、異常告警模塊以及數(shù)據(jù)轉(zhuǎn)發(fā)處理模塊組成。其中，屬性簽名驗證模塊接收待檢測的數(shù)據(jù)流，從中解析出屬性簽名，對其進行屬性簽名驗證，并將未通過檢測的數(shù)據(jù)包轉(zhuǎn)發(fā)至異常告警模塊。異常告警模塊在接收到未通過檢測的數(shù)據(jù)包后，通過事件消息機制轉(zhuǎn)發(fā)給數(shù)據(jù)轉(zhuǎn)發(fā)處理模塊。數(shù)據(jù)轉(zhuǎn)發(fā)處理模塊下發(fā)相應(yīng)的流策略至OpenFlow轉(zhuǎn)發(fā)設(shè)備來對數(shù)據(jù)進行轉(zhuǎn)發(fā)控制。

模型的安全性基于以下假設(shè)。

1) 控制平面與數(shù)據(jù)平面之間采用帶外的組網(wǎng)方式。

2) 假設(shè)控制器是安全的，惡意用戶無法攻擊并控制SDN 控制器。

3) 屬性簽名標(biāo)識認(rèn)證中心與控制器采用TLS信道進行通信。

2.1.3 屬性簽名標(biāo)識

屬性簽名標(biāo)識主要用來精確定義用戶的身份以及進行數(shù)據(jù)流驗證，它被嵌入IP 首部的Option字段中。

屬性簽名標(biāo)識格式如圖2 所示。IP 頭部由20 B組成；Option 字段共40 B，其中用戶屬性集合字段長度為8 B，屬性簽名字段長度為32 B。

圖2 屬性簽名標(biāo)識格式

用戶屬性集合字段，長度為8 B，包含了數(shù)據(jù)包進行屬性簽名時所用到的該用戶的所有屬性。該字段傳送到控制器后，控制器會對其進行解析并提供給屬性簽名驗證模塊用來進行屬性簽名驗證。

屬性簽名字段。Option 字段為屬性簽名字段預(yù)留了32 B。該字段包含了屬性簽名生成模塊對用戶屬性進行簽名之后所產(chǎn)生的簽名值。簽名值包括了C1、C2、C3、c、{CTi}i∈ζ、sα、sβ、sx、sδ1、sδ2、η，其長度是可變的，但是不會超過32 B，因此一共為該字段預(yù)留32 B。

2.2 屬性簽名方案

2.2.1 屬性簽名方案理論性闡述

本文方案采用Khader[15]提出的基于屬性的群簽名（ABGS,attribute-based group signature）方案。該群簽名方案的主要原理是驗證者構(gòu)造一個訪問控制樹T，而所有簽名者（被驗證者）根據(jù)自身的屬性進行簽名，驗證者對簽名進行解密并判斷該用戶的屬性是否滿足訪問控制樹T來驗證簽名者的身份。通過橫向?qū)Ρ戎T多屬性簽名方案，該方案在實現(xiàn)屬性簽名的功能外，還引入了較低的驗證開銷，并細(xì)粒度地劃分身份特征，能夠很好地保護用戶個人隱私信息[16]，故本文方案中使用群簽名方案。本文方案通過屬性簽名標(biāo)識認(rèn)證中心、屬性簽名標(biāo)識生成模塊以及屬性簽名驗證模塊共同實現(xiàn)訪問控制結(jié)構(gòu)的生成以及數(shù)據(jù)包的屬性簽名驗證。其過程如圖3 所示。

圖3 屬性簽名具體過程

首先，屬性簽名標(biāo)識認(rèn)證中心（下文簡稱為認(rèn)證中心）生成系統(tǒng)的公開參數(shù)與主密鑰；然后，屬性簽名驗證模塊生成用戶的訪問控制樹結(jié)構(gòu)T并上傳給認(rèn)證中心。認(rèn)證中心根據(jù)T生成T的公開參數(shù)，并發(fā)送給屬性簽名驗證模塊。屬性簽名生成模塊將用戶的屬性集合發(fā)送給認(rèn)證中心，認(rèn)證中心根據(jù)用戶屬性集合生成相應(yīng)的屬性私鑰并發(fā)給屬性簽名標(biāo)識生成模塊。屬性簽名標(biāo)識生成模塊使用數(shù)據(jù)包消息數(shù)據(jù)、屬性私鑰以及系統(tǒng)的公開參數(shù)進行哈希計算，并將計算值通過P4 轉(zhuǎn)發(fā)設(shè)備轉(zhuǎn)發(fā)給屬性簽名驗證模塊，由屬性簽名驗證模塊對其進行驗證。當(dāng)用戶的訪問控制結(jié)構(gòu)發(fā)生改變時，只需由屬性簽名驗證模塊上傳新的T給認(rèn)證中心，從而獲得新的T公開參數(shù)。

2.2.2 訪問樹結(jié)構(gòu)的生成過程

訪問控制結(jié)構(gòu)T用來表示屬性簽名驗證的屬性集，由于其使用屬性樹Γ來表示，故稱為訪問樹結(jié)構(gòu)。這里使用Goyal 等[17]的方法來構(gòu)造訪問樹。在屬性樹中所有非葉子節(jié)點表示由其子節(jié)點和閾值所構(gòu)成的門限，而每個葉子節(jié)點作為屬性值與其連接。門限值表示所有與其相連的葉子節(jié)點所滿足的最低條件數(shù)。舉例說明訪問樹結(jié)構(gòu)如圖4 所示。

圖4 訪問樹結(jié)構(gòu)

只有滿足訪問樹中屬性要求的用戶才能通過屬性簽名驗證。如圖4 所示，一個professor 想要完成read 操作，因其滿足訪問樹要求，故可以通過屬性簽名驗證。而如果一個student 想要完成write 操作，其不滿足訪問樹要求，故不可以通過簽名驗證。

2.2.3 方案形式化定義

本節(jié)給出基于屬性的群簽名的相關(guān)定義。

定義1用屬性樹Γ來表示訪問結(jié)構(gòu)T，屬性樹的順序為“從上到下，從左到右”，非葉子節(jié)點表示為(m,n)。其中，m表示門限值，n表示其葉子節(jié)點的總個數(shù)，κ表示該樹的葉子節(jié)點總數(shù)。圖4中的屬性樹可以表示為

定義2γi表示每個用戶所擁有的屬性，μ表示屬性數(shù)即γi的數(shù)量。

定義3ζi表示用于簽名時所使用的屬性。它是用戶所有屬性的子集，即ζi?γi。例如Γ={(1,2),professor,student}，員 工i使 用ζi={student}可以通過驗證，τ表示ζi的個數(shù)。

定義4yT表示用戶滿足T的屬性集合。

該算法共包括以下4 個步驟。

步驟4驗證（Verify）。屬性簽名驗證模塊收到簽名后，分以下兩步進行驗證。

首先，驗證屬性集合是否滿足T。如果節(jié)點x是屬性樹中的一個葉子節(jié)點，則根據(jù)遞歸算法VerNode。

然后，使用拉格朗日插值法遞歸求出根節(jié)點Fr的值，并驗證Fr=e(C3,η)。如果成立，表示簽名滿足訪問樹T，則開始第二步驗證，繼續(xù)進行如下計算過程；否則拒絕接收此簽名。

2.2.4 時間復(fù)雜度分析

本文方案引入屬性簽名算法，會引入額外的時間開銷。下面就該簽名算法本身進行時間復(fù)雜度分析。假設(shè)Tem表示群上的點乘運算，Tea表示群上的點加運算，Tep表示群上的冪運算，Tbp表示雙線性對運算，Tpn表示群上的多項式求值運算。而其他運算（例如Hash 運算）的時間開銷遠(yuǎn)小于這些計算，故忽略不計。本文方案一共分為2 個過程，即簽名過程和驗證過程。方案的簽名過程需要2k+9 個G1群上的冪運算（其中k為屬性集合ζ的大?。?、k+4 個G1群上的點乘運算、一個G2群上的冪運算、3 個雙線性對運算和 3 個TG上的冪運算，總時間為。而方案的簽名過程需要8 個G1群上的冪運算、4 個G1群上的點乘運算、4 個GT群上的點乘運算、k+6 個雙線性對計算和至多hk個GT群上的多項式運算（h為訪問樹的高度），總時間為?？梢钥闯?，由于需要進行雙線性對運算以及群上的運算，該方案的實施過程會產(chǎn)生一些時間開銷。

2.3 數(shù)據(jù)包轉(zhuǎn)發(fā)驗證方案具體實現(xiàn)

本章將具體介紹基于P4 可編程交換機的數(shù)據(jù)流轉(zhuǎn)發(fā)過程以及控制器上各個模塊的具體運行過程。

2.3.1 基于P4 轉(zhuǎn)發(fā)設(shè)備的數(shù)據(jù)平面轉(zhuǎn)發(fā)過程

P4 轉(zhuǎn)發(fā)設(shè)備作為數(shù)據(jù)平面可編程的中間件，可以實現(xiàn)對用戶發(fā)出的數(shù)據(jù)包的精確解析，同時通過設(shè)置檢測因子θ來完成對數(shù)據(jù)包的檢測采樣。被選中的數(shù)據(jù)包經(jīng)P4 轉(zhuǎn)發(fā)設(shè)備發(fā)送至控制器，供控制器進行屬性簽名驗證，整個采樣過程并不影響其他數(shù)據(jù)流的轉(zhuǎn)發(fā)[18]。下面介紹P4 轉(zhuǎn)發(fā)設(shè)備的主要模塊。

首部（Header）。首部指定了屬于該首部的字段、字段大小以及首部中字段的順序。

解析器（Parser）。解析器的功能是將數(shù)據(jù)包映射成以狀態(tài)機形式編寫的首部，然后按照規(guī)定順序解析首部中的所有協(xié)議。在將屬性簽名數(shù)據(jù)包加載至Option 字段后，解析順序為：Ethernet、Vlan、IPv4_base、Option。這里根據(jù)IPv4_base 中的ihl 值來驗證Option 首部的有效性。當(dāng)IPv4_base.ihl 值為0x05 時，即IP 首部長度為20 B，說明該數(shù)據(jù)包未攜帶Option 首部，即該數(shù)據(jù)包未攜帶屬性簽名，因此為非法數(shù)據(jù)包；當(dāng)值不為0x05 時，說明Option字段攜帶了屬性簽名，在解析Option 字段后按照規(guī)定順序繼續(xù)解析。解析狀態(tài)一共有3 種：開始（Start）、接收（Accept）、拒絕（Reject）。解析從開始狀態(tài)開始，如果解析正常則進入接收狀態(tài)，進行下一步操作。如果解析出現(xiàn)錯誤，則轉(zhuǎn)入拒絕狀態(tài)，從而解析結(jié)束，輸出錯誤信息。若解析正常，解析器將數(shù)據(jù)流信息解析為對應(yīng)的協(xié)議數(shù)據(jù)包，用于后續(xù)的流表項匹配和動作轉(zhuǎn)發(fā)執(zhí)行[19]。

表（Table）。P4 轉(zhuǎn)發(fā)設(shè)備采用“匹配?動作”表機制來處理數(shù)據(jù)包的轉(zhuǎn)發(fā)。此表包括3 項內(nèi)容：key 值、Action 與ActionData。其中，key 值為匹配域，表示動作要匹配的具體實例（例如源IP 地址等）；Action 為具體行為，P4 語言可以通過自主編程來定義轉(zhuǎn)發(fā)行為；ActionData 表示具體的動作數(shù)據(jù)。在本文機制中重點定義了2 種表，即數(shù)據(jù)包采樣表和數(shù)據(jù)包鏡像表。

數(shù)據(jù)包采樣表。其設(shè)置檢測因子θ為其他正常數(shù)據(jù)包/采樣檢測數(shù)據(jù)包，根據(jù)檢測因子θ應(yīng)用modify_field_rng_uniform原語，對數(shù)據(jù)包進行采樣。設(shè)置一個自定義元數(shù)據(jù)字段sample_metadata 用于標(biāo)識采樣數(shù)據(jù)包，當(dāng)數(shù)據(jù)包確定為預(yù)采樣數(shù)據(jù)包后，其sample_metadata 字段的val 值被設(shè)為1。

數(shù)據(jù)包鏡像表。其主要功能是根據(jù)采樣結(jié)果，將預(yù)采樣數(shù)據(jù)包復(fù)制至連接控制器的端口。其應(yīng)用clone_ingress_pkt_to_egressaction原語將sample_metadata.val 為1 的數(shù)據(jù)包設(shè)置鏡像ID 為特定值10，并鏡像到連接控制器的端口。所有鏡像ID為10 的采樣數(shù)據(jù)包將被發(fā)送到通向控制器的指定端口進行處理。

流控制程序（Control Program）。主要包括以下幾個部分：Input、Parser、Ingress、Egress、Output?？刂瞥绦蛄鞒倘鐖D5 所示。

圖5 控制程序流程

Ingress 過程中，首先加載θ值，然后判斷Option 字段是否存在。若存在，則將數(shù)據(jù)包加載至數(shù)據(jù)包采樣表進行數(shù)據(jù)包采樣；否則視為無效數(shù)據(jù)包，控制器負(fù)責(zé)將此數(shù)據(jù)包丟棄。數(shù)據(jù)包采樣表根據(jù)預(yù)設(shè)的θ值確定采樣比例后，進行采樣操作。預(yù)采樣數(shù)據(jù)包的自定義元數(shù)據(jù)字段sample_metadata 中的 val 值被設(shè)為 1。所有sample_metadata.val 為1 的數(shù)據(jù)包將被加載至數(shù)據(jù)包鏡像表，然后鏡像至控制器，其余數(shù)據(jù)包正常轉(zhuǎn)發(fā)。所有具有屬性簽名標(biāo)識的數(shù)據(jù)包正常轉(zhuǎn)發(fā)至輸出端口。

2.3.2 控制器各個模塊的運行過程

控制器中主要包括了3 個模塊：屬性簽名驗證模塊、異常告警模塊以及數(shù)據(jù)轉(zhuǎn)發(fā)處理模塊。前2 個模塊之間使用AF_UNIX 域上的socket 協(xié)議進行通信。而異常告警模塊與數(shù)據(jù)轉(zhuǎn)發(fā)處理模塊通過控制器的事件機制進行通信[20]。

1) 屬性簽名驗證模塊

該模塊收到數(shù)據(jù)包后，首先提取用戶用于屬性簽名的集合，看其是否滿足訪問樹結(jié)構(gòu)T。若滿足，進行下一步驗證；否則，視為無效數(shù)據(jù)包，將其發(fā)送給監(jiān)聽告警模塊。接著，從屬性簽名標(biāo)識中提取出C1、C2、C3、{CTi}i∈ζ、sα、sβ、sx、sδ1、sδ2、η，計 算。然 后，計 算，將其與簽名c進行比較，若相等，則驗證通過；否則，發(fā)送給異常告警模塊處理。

2) 異常告警模塊

當(dāng)收到無效數(shù)據(jù)包時，該模塊發(fā)送自定義異常數(shù)據(jù)包告警事件EventWarning 至Ryu 控制器?？刂破魍ㄟ^Ryu 的事件機制將EventWarning 事件發(fā)送至數(shù)據(jù)轉(zhuǎn)發(fā)處理模塊進行下一步處理。

3) 數(shù)據(jù)轉(zhuǎn)發(fā)處理模塊

數(shù)據(jù)轉(zhuǎn)發(fā)處理模塊在正常通信階段，接收來自監(jiān)聽告警模塊的異常數(shù)據(jù)包告警事件EventWarning，然后下發(fā)相應(yīng)的流規(guī)則至OpenFlow交換機對異常數(shù)據(jù)包進行相應(yīng)處理。若發(fā)送過來的數(shù)據(jù)包是正常數(shù)據(jù)包，則直接由OpenFlow 交換機進行正常的轉(zhuǎn)發(fā)工作。數(shù)據(jù)轉(zhuǎn)發(fā)處理模塊工作過程如圖6 所示。

圖6 數(shù)據(jù)轉(zhuǎn)發(fā)處理模塊工作過程

2.4 基于容災(zāi)機制的多控制器架構(gòu)

單控制器的單點失效問題一直是困擾SDN 控制器性能方面的一個重要問題[20]。在本文方案中，由于向控制器中添加了部分功能模塊，控制器除了要完成正常的數(shù)據(jù)轉(zhuǎn)發(fā)控制功能外還需要完成屬性簽名驗證以及異常處理等功能，因此其受到單點失效問題的影響比正?？刂破饕蟆ａ槍@一問題，本文設(shè)計了一種多控制器集群的控制器容災(zāi)機制[21]。當(dāng)主控制器失效時，通過選舉機制將備份控制器切換為主控制器并接管原主控制器的工作，從而解決了控制器單點失效問題。基于目前已經(jīng)成熟的分布式系統(tǒng)集群管理技術(shù)Zookeeper，解決了多控制器之間信息共享與數(shù)據(jù)一致性問題，并根據(jù)OpenFlow1.5 協(xié)議支持多控制器協(xié)同工作的特性，實現(xiàn)了交換機與多控制器通信的功能。

2.4.1 基本架構(gòu)

多控制器架構(gòu)如圖 7 所示。首先，采用Zookeeper 管理服務(wù)器來負(fù)責(zé)管理集群內(nèi)部所有控制器。Zookeeper[22]是雅虎研究院的一個分布式數(shù)據(jù)管理系統(tǒng)項目，該項目通過允許用戶調(diào)用其接口的方式來實現(xiàn)分布式一致性服務(wù)。使用Zookeeper 管理多控制器集群，可以提供分布式協(xié)調(diào)管理服務(wù)、數(shù)據(jù)一致性機制等。所有控制器均與Zookeeper 服務(wù)器建立通信連接，并通過開發(fā)通信模塊的方式完成對Zookeeper 消息的監(jiān)聽與響應(yīng)[21]。

圖7 多控制器架構(gòu)

在控制器層使用3 個控制器進行集群部署（根據(jù)系統(tǒng)的可擴展性，可以向系統(tǒng)動態(tài)增加控制器數(shù)量，但本文機制使用3 個控制器已經(jīng)能夠滿足系統(tǒng)的可用性）?？刂破鏖g采用主從（Master/Slaves）結(jié)構(gòu)（主從控制器模式），其中一個控制器為主控制器，2 個控制器為從控制器。在正常通信階段，由主控制器負(fù)責(zé)控制數(shù)據(jù)平面的數(shù)據(jù)轉(zhuǎn)發(fā)。從控制器在主控制器工作時處于熱備份模式，即只備份SDN數(shù)據(jù)信息并與主控制器保持同步，但不下發(fā)流表給交換機?？刂破髦g需要建立通信鏈路用來進行信息交互?？刂破鏖g交互數(shù)據(jù)包主要有3 種類型，即同步數(shù)據(jù)包、請求轉(zhuǎn)發(fā)數(shù)據(jù)包以及?；顢?shù)據(jù)包[23]。同步數(shù)據(jù)包由主控制器發(fā)送給從控制器，內(nèi)容包括控制器自身狀態(tài)變化信息。請求轉(zhuǎn)發(fā)數(shù)據(jù)包將發(fā)送至控制器的數(shù)據(jù)包轉(zhuǎn)發(fā)至負(fù)載比它小的其他控制器。?；顢?shù)據(jù)包主要用來測試連接狀態(tài)和網(wǎng)絡(luò)時延。

在交換機層中每個交換機可以與所有控制器進行通信。在 OpenFlow 協(xié)議中，控制器有MASTER、SLAVE、EQUAL 這3 種角色，其中MASTER 表示主控制器，可以接收交換機發(fā)送的消息以及下發(fā)流表。SLAVE 表示從控制器，只能監(jiān)聽來自交換機的消息。EQUAL 表示默認(rèn)狀態(tài)。只有控制器可以修改角色，交換機沒有修改角色的權(quán)限。一個交換機同一時刻只有一個MASTER，當(dāng)主控制器出現(xiàn)故障時，通過選舉機制選出新的主控制器，并將該控制器的角色切換為MASTER，從而保證了網(wǎng)絡(luò)的可用性和可靠性。

2.4.2 信息共享以及一致性問題解決方法

Zookeeper 服務(wù)器負(fù)責(zé)多控制器的集群管理以及分布式協(xié)調(diào)，實現(xiàn)了多控制器間的信息共享與數(shù)據(jù)一致性。Zookeeper 使用樹形結(jié)構(gòu)數(shù)據(jù)單元ZNode來存儲數(shù)據(jù)，服務(wù)器通過監(jiān)控ZNode 節(jié)點中數(shù)據(jù)的變化來感知事件，并做出響應(yīng)。ZNode 節(jié)點關(guān)系如圖8 所示。

圖8 ZNode 節(jié)點關(guān)系

ZNode“/controller”及其子節(jié)點用于記錄每個控制器的信息?！?cid1”至“/cidN”節(jié)點代表網(wǎng)絡(luò)內(nèi)的不同控制器，每個節(jié)點代表一臺控制器。

ZNode“/topology”節(jié)點用于存儲全局網(wǎng)絡(luò)拓?fù)湫畔⒁约敖粨Q機連接信息，這2 種信息是多控制器之間需要共享的信息。子節(jié)點“/IP”標(biāo)識了不同的控制器，該節(jié)點下的數(shù)據(jù)代表一個控制器掌握的拓?fù)湫畔⒑驮O(shè)備連接信息。當(dāng)網(wǎng)絡(luò)中的拓?fù)浠蚪粨Q機連接狀態(tài)發(fā)生變化時，主控制器首先負(fù)責(zé)將更新后的信息存儲至每一個“/IP”節(jié)點內(nèi)，Zookeeper通過Watcher 監(jiān)聽“/IP”節(jié)點內(nèi)的數(shù)據(jù)變化，并通過Watch 事件通知從控制器。隨后從控制器訪問Zookeeper 服務(wù)器中自身對應(yīng)的“IP”節(jié)點，獲取新的全網(wǎng)拓?fù)湫畔⒁约敖粨Q機連接信息。上述方法能夠使多控制器中的網(wǎng)絡(luò)拓?fù)湫畔?shù)據(jù)保持一致，并且當(dāng)網(wǎng)絡(luò)更新后，多控制器的數(shù)據(jù)仍處于一致狀態(tài)。

2.4.3 容災(zāi)機制實現(xiàn)過程

當(dāng)出現(xiàn)單點失效情況時，主控制器發(fā)送同步數(shù)據(jù)包至所有從控制器，將自身單點失效的消息通知從控制器。隨后集群內(nèi)部所有控制器根據(jù)選舉機制選出新的主控制器。選舉出的主控制器將自己在交換機中的角色由SLAVE 切換為MASTER，其余控制器將角色設(shè)置為SLAVE。此時選舉出的主控制器成功接替原主控制器的工作，控制交換機中的數(shù)據(jù)轉(zhuǎn)發(fā)。上述容災(zāi)機制實現(xiàn)了主從控制器之間的切換，解決了控制器單點失效問題。

3 方案整體設(shè)計

本文方案的主要流程如圖9 所示。

圖9 本文方案的主要流程

1) 當(dāng)用戶接入該SDN 時，屬性簽名標(biāo)識生成模塊根據(jù)入網(wǎng)用戶的身份屬性，生成用戶的屬性集合。

2) 屬性簽名標(biāo)識認(rèn)證中心生成系統(tǒng)的公開參數(shù)與主密鑰。

3) 屬性簽名驗證模塊生成訪問控制樹T，并將T發(fā)送給認(rèn)證中心。認(rèn)證中心根據(jù)T生成T的公開參數(shù)。

4) 屬性簽名標(biāo)識生成模塊將用戶的屬性集合發(fā)給認(rèn)證中心。認(rèn)證中心根據(jù)屬性集合為用戶生成用戶私鑰。

5) 認(rèn)證中心將用戶私鑰發(fā)送給屬性簽名標(biāo)識生成模塊。

6) 屬性簽名標(biāo)識生成模塊以用戶用于簽名的屬性集、T的公開參數(shù)和數(shù)據(jù)包傳輸?shù)南為輸入，計算出屬性簽名值。然后將屬性簽名值以及用戶的簽名屬性放入數(shù)據(jù)包的Option 字段中。

7) P4 轉(zhuǎn)發(fā)設(shè)備解析數(shù)據(jù)包中的屬性簽名標(biāo)識。采樣控制模塊根據(jù)設(shè)置的檢測因子θ來判斷當(dāng)前數(shù)據(jù)包是否為采樣檢測數(shù)據(jù)包，若是，執(zhí)行8a)；否則執(zhí)行8b)。

8a) 待檢測數(shù)據(jù)包被加載至數(shù)據(jù)包鏡像模塊，該模塊將待檢測數(shù)據(jù)包復(fù)制，并將鏡像數(shù)據(jù)包發(fā)送至P4 轉(zhuǎn)發(fā)設(shè)備出端口，原數(shù)據(jù)包執(zhí)行8b)。

8b) P4 轉(zhuǎn)發(fā)設(shè)備轉(zhuǎn)發(fā)數(shù)據(jù)包至OpenFlow 交換機，而OpenFlow 交換機通過匹配流規(guī)則執(zhí)行相應(yīng)的數(shù)據(jù)包轉(zhuǎn)發(fā)動作。

9) P4 轉(zhuǎn)發(fā)設(shè)備將其出端口中的待檢測數(shù)據(jù)包發(fā)送至控制器，并由控制器的屬性簽名驗證模塊接收。

10) 屬性簽名驗證模塊對用戶的屬性以及簽名值進行驗證。若驗證通過，說明該數(shù)據(jù)包是有效數(shù)據(jù)包。若驗證不通過，將數(shù)據(jù)包轉(zhuǎn)發(fā)給異常告警模塊。

11) 異常告警模塊收到無效數(shù)據(jù)包后，根據(jù)Ryu 控制器事件機制，向數(shù)據(jù)轉(zhuǎn)發(fā)處理模塊發(fā)送告警事件EventWarning。

12) 數(shù)據(jù)轉(zhuǎn)發(fā)處理模塊監(jiān)聽到EventWarning事件后，下發(fā)相應(yīng)的流規(guī)則給OpenFlow 交換機，令其對于檢測異常的數(shù)據(jù)流進行攔截。

13) 如果出現(xiàn)控制器單點失效情況時，根據(jù)控制器容災(zāi)機制使用從控制器接替當(dāng)前主控制器的工作。

4 仿真實驗及評估

4.1 實驗設(shè)置

本實驗采用一臺Windows Server2012 服務(wù)器作為屬性簽名標(biāo)識認(rèn)證中心，一臺Windows Server2012 服務(wù)器作為Zookeeper 服務(wù)器，2 臺Windows主機作為終端，一臺虛擬機上安裝3 臺Ryu 控制器，另一臺虛擬機安裝一個Bmv2 軟件交換機以及2 個OpenFlow 軟件交換機?？刂破髋c交換機在Mininet環(huán)境下實現(xiàn)網(wǎng)絡(luò)互聯(lián)，服務(wù)器、終端以及虛擬機通過網(wǎng)線互聯(lián)。圖10 顯示了實驗環(huán)境的拓?fù)浣Y(jié)構(gòu)。本實驗主要測試該機制的檢測準(zhǔn)確率、數(shù)據(jù)包轉(zhuǎn)發(fā)時延以及系統(tǒng)性能。

圖10 實驗環(huán)境的拓?fù)浣Y(jié)構(gòu)

4.2 檢測準(zhǔn)確率

在終端H1上使用發(fā)包腳本對網(wǎng)絡(luò)進行模擬攻擊，分別以0.1 的概率發(fā)送2 種數(shù)據(jù)流，一種數(shù)據(jù)流中偽造了屬性簽名驗證字段，另一種數(shù)據(jù)流中篡改了數(shù)據(jù)包中的數(shù)據(jù)字段。不同數(shù)據(jù)流中數(shù)據(jù)包數(shù)量為10 000 個，攻擊各進行100 次，實驗結(jié)果取平均值，并以漏報率作為衡量系統(tǒng)檢測準(zhǔn)確率的實驗指標(biāo)。檢測因子θ分別設(shè)置為9、7、4。若數(shù)據(jù)包驗證檢測系統(tǒng)檢測到異常數(shù)據(jù)包并下發(fā)流表，則記錄為檢測成功；若未檢測到，則記錄為漏報。不同檢測因子下的漏報率如圖11 所示。

根據(jù)圖11 可知，對于相同的檢測因子偽造驗證字段與篡改數(shù)據(jù)字段的漏報率差別不大，原因是系統(tǒng)通過驗證數(shù)據(jù)包中的屬性簽名來識別異常數(shù)據(jù)包，2 種攻擊方式都能使屬性簽名驗證失敗。隨著θ的減小，漏報率降低，這說明采樣比越高，系統(tǒng)安全性越高。但同時較高的采樣比會增加CPU的使用率，從而增加系統(tǒng)的開銷。實驗發(fā)現(xiàn)，現(xiàn)在檢測因子分別設(shè)為9、7、4 的情況下，控制器CPU平均使用率分別為7.8%，10.3%以及16.2%。綜合考慮系統(tǒng)的安全性能以及CPU 的利用率，檢測率設(shè)置為7 時，可以獲得很好的檢測準(zhǔn)確率，且不需要較高的系統(tǒng)開銷。

圖11 不同檢測因子下的漏報率

4.3 數(shù)據(jù)包轉(zhuǎn)發(fā)時延

通過編寫自定義發(fā)包腳本程序模擬用戶主機的行為，區(qū)分?jǐn)?shù)據(jù)包攜帶屬性簽名標(biāo)識（檢測因子設(shè)為7）與不攜帶屬性簽名標(biāo)識2 種情況，分別發(fā)送10 000 個數(shù)據(jù)包進行測試。通過比較2 種情況下的轉(zhuǎn)發(fā)時延，分析添加屬性簽名標(biāo)識后對交換機的轉(zhuǎn)發(fā)行為的影響。采用Wireshark 工具在該網(wǎng)絡(luò)的出入口進行抓包，并計算數(shù)據(jù)包轉(zhuǎn)發(fā)時延。本實驗分別統(tǒng)計20 次轉(zhuǎn)發(fā)時延（其中每次的時延是由10 次重復(fù)實驗得出的平均值），結(jié)果如圖12 所示。

圖12 數(shù)據(jù)包轉(zhuǎn)發(fā)時延

如圖12 可看出，正常情況下的轉(zhuǎn)發(fā)時延的平均值為10.75 ms，在加入屬性簽名標(biāo)識后平均值為30.95 ms，其平均轉(zhuǎn)發(fā)時延增加了20.20 ms，通過分析可知在本原型系統(tǒng)中，由于數(shù)據(jù)包中攜帶了屬性簽名標(biāo)識（40 B），使傳輸?shù)臄?shù)據(jù)包要比正常的數(shù)據(jù)包大，在加之部分?jǐn)?shù)據(jù)包還要作為采樣檢測數(shù)據(jù)包進行屬性簽名驗證，而簽名驗證時又要與認(rèn)證中心進行數(shù)據(jù)互傳，導(dǎo)致該系統(tǒng)的轉(zhuǎn)發(fā)時延增大，在增大的時延中用于屬性簽名以及簽名驗證的時間約占整個時延的65.2%，所以簽名算法的復(fù)雜度直接決定了轉(zhuǎn)發(fā)時延。由于該方案在仿真環(huán)境下的平均轉(zhuǎn)發(fā)時延為30.95 ms，這表示控制器平均每秒處理33 個數(shù)據(jù)流。根據(jù)Stanford University 提供的實驗數(shù)據(jù)[24]，一個擁有300 臺用戶主機的網(wǎng)絡(luò)每秒處理的數(shù)據(jù)流請求約在30～40。因此該機制雖然由于引入屬性簽名驗證而增大了轉(zhuǎn)發(fā)時延，但是仍能滿足一般中小型網(wǎng)絡(luò)的通信需求。

4.4 網(wǎng)絡(luò)吞吐量開銷

在本實驗中，首先設(shè)定不同的檢測因子θ（θ值設(shè)為9、7、4、3、1），然后分別測量吞吐量開銷，并與正常情況進行對比。網(wǎng)絡(luò)吞吐量對比如圖13所示。

由圖13 可以看出，與未使用屬性簽名標(biāo)識機制的正常網(wǎng)絡(luò)吞吐量相比，在θ為9 時，吞吐量下降7.7%，隨著θ的減少，吞吐量隨之下降，當(dāng)θ=1 時，吞吐量降低了約29.8%左右。因此可以看出網(wǎng)絡(luò)吞吐量與θ成正比，θ越大，網(wǎng)絡(luò)吞吐量越大。

圖13 網(wǎng)絡(luò)吞吐量對比

4.5 擴展實驗

本節(jié)實驗增加了數(shù)據(jù)平面上的用戶節(jié)點，通過這種方式來測試當(dāng)網(wǎng)絡(luò)規(guī)模擴大時數(shù)據(jù)包轉(zhuǎn)發(fā)時延以及網(wǎng)絡(luò)吞吐量的變化情況。由于實驗條件有限，系統(tǒng)共添加了32 臺主機作為用戶主機，負(fù)責(zé)向網(wǎng)絡(luò)中發(fā)送數(shù)據(jù)包。本文分別測試用戶主機數(shù)為1、2、4、8、16、32 時的數(shù)據(jù)包轉(zhuǎn)發(fā)時延和網(wǎng)絡(luò)吞吐量，擴展實驗拓?fù)淙鐖D14 所示。

圖14 擴展實驗拓?fù)?/p>

首先，本文在每個用戶主機上發(fā)送10 000 個數(shù)據(jù)包，并設(shè)定檢測因子θ為7，測量在不同的用戶主機數(shù)量條件下該網(wǎng)絡(luò)中數(shù)據(jù)包轉(zhuǎn)發(fā)時延，并與未添加屬性簽名標(biāo)識的網(wǎng)絡(luò)的數(shù)據(jù)包轉(zhuǎn)發(fā)時延進行對比，結(jié)果如圖15 所示。隨著網(wǎng)絡(luò)中主機數(shù)量的增多，轉(zhuǎn)發(fā)時延不斷增大。而隨著用戶數(shù)量的增多，添加了屬性簽名標(biāo)識的網(wǎng)絡(luò)的數(shù)據(jù)包轉(zhuǎn)發(fā)時延的增長率要更高，但是仍屬于較為平緩的增長，處于可接受范圍內(nèi)。

圖15 不同主機數(shù)量下的數(shù)據(jù)包轉(zhuǎn)發(fā)時延

其次，區(qū)分添加屬性簽名標(biāo)識與不添加屬性簽名標(biāo)識2 種情況分別測量在不同的用戶主機數(shù)量情況下的網(wǎng)絡(luò)吞吐量，如圖16 所示。可以看出，隨著用戶主機數(shù)量的增多，網(wǎng)絡(luò)吞吐量下降，雖然添加了屬性簽名標(biāo)識的網(wǎng)絡(luò)吞吐量下降率較高，但總體來說下降幅度不大，仍處于可接受范圍內(nèi)。

圖16 不同主機數(shù)量下的網(wǎng)絡(luò)吞吐量

綜上所述，擴展網(wǎng)絡(luò)規(guī)模會給網(wǎng)絡(luò)的吞吐量以及數(shù)據(jù)包轉(zhuǎn)發(fā)時延帶來一定的影響，但通過實驗結(jié)果的分析可知對于添加了數(shù)據(jù)轉(zhuǎn)發(fā)驗證機制的網(wǎng)絡(luò)影響有限，網(wǎng)絡(luò)開銷并非成倍增長，仍處于可接受范圍內(nèi)。

4.6 機制對比

將本文的轉(zhuǎn)發(fā)驗證方案與已經(jīng)提出的一些轉(zhuǎn)發(fā)驗證方案[8,10,18]進行對比，如表1 所示。

表1 不同方案特點比較

本文采用基于用戶屬性的簽名方案，而其他方案均是基于用戶身份的，相較而言，本文方案更加細(xì)粒度地劃分了用戶身份特征，具有更強的靈活性和匿名性。本文方案與方案3 采用了P4 轉(zhuǎn)發(fā)設(shè)備通過自定義匹配字段來完成對數(shù)據(jù)流的精確采樣，相比于其他方案采用的OpenFlow 匹配字段，能夠更細(xì)粒度地對數(shù)據(jù)包進行控制。

在驗證設(shè)備方面，本文方案和方案1、方案3均采用了控制器作為驗證設(shè)備，這樣會增加控制器的負(fù)載，造成控制器單點失效等問題。本文方案通過構(gòu)建多控制器架構(gòu)有效避免了該問題。方案2 使用了交換機作為驗證設(shè)備，雖然能減輕控制器負(fù)擔(dān)，但對交換機的安全性要求較高。

在驗證開銷方面，方案1～方案3 均通過驗證Hmac 消息摘要的方式來對數(shù)據(jù)流進行驗證。而本方面采用屬性簽名技術(shù)，涉及雙線性對運算等耗時計算，所以在時間開銷上要大于其他3 種方案。

在轉(zhuǎn)發(fā)時延方面，方案1 轉(zhuǎn)發(fā)時延為33.17 ms，方案2轉(zhuǎn)發(fā)時延為33.65 ms，方案3轉(zhuǎn)發(fā)時延為0.83 ms，本文方案的轉(zhuǎn)發(fā)時延為30.95 ms。可以看出，本文方案雖然驗證開銷較大，但整體轉(zhuǎn)發(fā)時延并不比方案1 和方案2 大。這是由于本文方案采用采樣檢測的方法，對于未被采樣的數(shù)據(jù)轉(zhuǎn)發(fā)設(shè)備進行正常的匹配轉(zhuǎn)發(fā)，且本文方案主要的時延來自驗證開銷，密鑰傳輸次數(shù)較少，通信開銷較低，故轉(zhuǎn)發(fā)時延方面與方案1 和方案2 無較大差距。

在實現(xiàn)功能方面，4 種方案都可以實現(xiàn)檢測偽造、篡改數(shù)據(jù)包的功能，而由于本文方案將用戶的身份屬性與用戶發(fā)出的數(shù)據(jù)包進行了綁定，一旦發(fā)現(xiàn)用戶在網(wǎng)絡(luò)中的違規(guī)行為，可以利用屬性簽名標(biāo)識追蹤其真實身份，因此相比其他方案，實現(xiàn)了用戶身份的可追蹤性。

最后，本文分析了所有方案存在的局限性。本簽名方案采用屬性簽名方法，所采用的通信方式是一對多，驗證者只需驗證被驗證者是否滿足訪問控制結(jié)構(gòu)即可。而其他方案采用基于身份的簽名驗證，采用的通信方式是一對一，為保證安全性采用“一次一密”的方式，這需要進行較頻繁的密鑰傳輸，增大了密鑰通信的時間，此外還給密鑰管理增加了難度。此外，方案1 與方案3 均使用單控制器架構(gòu)，并使用控制器作為驗證設(shè)備，這樣會增大控制器的開銷，容易出現(xiàn)單點失效問題。而方案2 將驗證功能放在傳統(tǒng)OpenFlow 交換機上，實際上要在OpenFlow 交換機上開發(fā)安全模塊，不僅開發(fā)難度較大，可行性未知，而且很難維護和添加新功能。本文方案的不足在于，由于引入屬性簽名技術(shù)導(dǎo)致計算開銷增大。

5 結(jié)束語

針對SDN 中數(shù)據(jù)包缺乏有效的轉(zhuǎn)發(fā)驗證以及數(shù)據(jù)流缺乏精確控制方法的問題，本文提出一種基于屬性簽名標(biāo)識的數(shù)據(jù)包轉(zhuǎn)發(fā)驗證方案。采用根據(jù)用戶的屬性集合進行簽名，并在控制器上進行驗證的方式，實現(xiàn)了數(shù)據(jù)包的安全轉(zhuǎn)發(fā)驗證功能。在SDN 中利用P4 轉(zhuǎn)發(fā)設(shè)備，生成并解析屬性簽名標(biāo)識，實現(xiàn)了對數(shù)據(jù)流的更細(xì)粒度的精準(zhǔn)控制以及采樣等目的。本文還設(shè)計了一種多控制器架構(gòu)，解決了控制器單點失效問題。最后，在基于Ryu 控制器和Mininet 的實驗環(huán)境中對該方案進行了實現(xiàn)。結(jié)果表明該方案能夠有效檢測出數(shù)據(jù)流被惡意篡改、偽造等異常攻擊行為，雖引入了相對較高的轉(zhuǎn)發(fā)時延，但仍處于可接受范圍之內(nèi)。針對驗證功能給控制器帶來的性能問題，未來的工作將研究在P4 交換機上開發(fā)驗證模塊，將驗證功能放置到交換機中進行，從而進一步提升控制器的性能。