基于屬性簽名標識的SDN 數據包轉發驗證方案

常朝穩，金建樹，韓培勝，祝現威

（信息工程大學，河南 鄭州 450001）

1 引言

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

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

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

P4 語言[12]是一種高級編程語言，它主要使用可編程包處理器來對數據平面進行編程。基于P4 語言的轉發設備可以自定義數據包的轉發處理動作，而不再受到現有協議的約束[13]。

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

本文方案主要面向工業控制系統、戰術互聯網以及校園網等場景。這些系統的特點是系統較為封閉、用戶數量相對較少但安全性要求較高。屬性簽名方案可以實現數據流的真實性與完整性檢測，在保證用戶匿名性的同時實現了用戶身份可追蹤功能，但會帶來一定的時間開銷。這些特點決定了該方案適用于上述場景。在實驗環節，本文搭建了一個與上述場景網絡拓撲相似的實驗環境，并測試了方案的功能和性能。

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

1) 將屬性簽名算法應用到SDN 數據流轉發驗證中，通過對用戶屬性的細粒度劃分以及對屬性集合的簽名驗證實現了對用戶在網絡中發送的數據流的精確轉發驗證，從而實現了數據流的真實性和完整性驗證，以及用戶身份可追蹤等功能。

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

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

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

2 方案內容

2.1 方案描述

2.1.1 基本原理

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

2.1.2 整體結構

基于屬性簽名標識的數據包轉發驗證方案由以下幾個部分組成，其基本結構如圖1 所示。

圖1 轉發驗證方案基本結構

1) 屬性簽名標識認證中心。首先，生成系統公開參數與主密鑰；然后，生成訪問控制結構的公開參數，根據用戶的屬性集生成用戶身份屬性的訪問控制結構的相關參數；最后，根據屬性標識生成用于屬性簽名的屬性私鑰。

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

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

4) 轉發設備，包括P4 轉發設備與OpenFlow交換機。

P4 轉發設備，實現了數據平面可編程功能。其主要由采樣控制模塊以及數據包鏡像模塊組成，主要負責屬性簽名標識的生成、數據包的采樣檢測以及精確轉發。

OpenFlow 交換機主要負責接收控制器發出的流表，并根據流表中的策略規則，對數據包進行轉發、丟棄等動作。

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

模型的安全性基于以下假設。

1) 控制平面與數據平面之間采用帶外的組網方式。

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

3) 屬性簽名標識認證中心與控制器采用TLS信道進行通信。

2.1.3 屬性簽名標識

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

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

圖2 屬性簽名標識格式

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

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

2.2 屬性簽名方案

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

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

圖3 屬性簽名具體過程

首先，屬性簽名標識認證中心（下文簡稱為認證中心）生成系統的公開參數與主密鑰；然后，屬性簽名驗證模塊生成用戶的訪問控制樹結構T并上傳給認證中心。認證中心根據T生成T的公開參數，并發送給屬性簽名驗證模塊。屬性簽名生成模塊將用戶的屬性集合發送給認證中心，認證中心根據用戶屬性集合生成相應的屬性私鑰并發給屬性簽名標識生成模塊。屬性簽名標識生成模塊使用數據包消息數據、屬性私鑰以及系統的公開參數進行哈希計算，并將計算值通過P4 轉發設備轉發給屬性簽名驗證模塊，由屬性簽名驗證模塊對其進行驗證。當用戶的訪問控制結構發生改變時，只需由屬性簽名驗證模塊上傳新的T給認證中心，從而獲得新的T公開參數。

2.2.2 訪問樹結構的生成過程

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

圖4 訪問樹結構

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

2.2.3 方案形式化定義

本節給出基于屬性的群簽名的相關定義。

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

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

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

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

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

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

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

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

2.2.4 時間復雜度分析

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

2.3 數據包轉發驗證方案具體實現

本章將具體介紹基于P4 可編程交換機的數據流轉發過程以及控制器上各個模塊的具體運行過程。

2.3.1 基于P4 轉發設備的數據平面轉發過程

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

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

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

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

數據包采樣表。其設置檢測因子θ為其他正常數據包/采樣檢測數據包，根據檢測因子θ應用modify_field_rng_uniform原語，對數據包進行采樣。設置一個自定義元數據字段sample_metadata 用于標識采樣數據包，當數據包確定為預采樣數據包后，其sample_metadata 字段的val 值被設為1。

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

流控制程序（Control Program）。主要包括以下幾個部分：Input、Parser、Ingress、Egress、Output。控制程序流程如圖5 所示。

圖5 控制程序流程

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

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

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

1) 屬性簽名驗證模塊

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

2) 異常告警模塊

當收到無效數據包時，該模塊發送自定義異常數據包告警事件EventWarning 至Ryu 控制器。控制器通過Ryu 的事件機制將EventWarning 事件發送至數據轉發處理模塊進行下一步處理。

3) 數據轉發處理模塊

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

圖6 數據轉發處理模塊工作過程

2.4 基于容災機制的多控制器架構

單控制器的單點失效問題一直是困擾SDN 控制器性能方面的一個重要問題[20]。在本文方案中，由于向控制器中添加了部分功能模塊，控制器除了要完成正常的數據轉發控制功能外還需要完成屬性簽名驗證以及異常處理等功能，因此其受到單點失效問題的影響比正常控制器要大。針對這一問題，本文設計了一種多控制器集群的控制器容災機制[21]。當主控制器失效時，通過選舉機制將備份控制器切換為主控制器并接管原主控制器的工作，從而解決了控制器單點失效問題。基于目前已經成熟的分布式系統集群管理技術Zookeeper，解決了多控制器之間信息共享與數據一致性問題，并根據OpenFlow1.5 協議支持多控制器協同工作的特性，實現了交換機與多控制器通信的功能。

2.4.1 基本架構

多控制器架構如圖 7 所示。首先，采用Zookeeper 管理服務器來負責管理集群內部所有控制器。Zookeeper[22]是雅虎研究院的一個分布式數據管理系統項目，該項目通過允許用戶調用其接口的方式來實現分布式一致性服務。使用Zookeeper 管理多控制器集群，可以提供分布式協調管理服務、數據一致性機制等。所有控制器均與Zookeeper 服務器建立通信連接，并通過開發通信模塊的方式完成對Zookeeper 消息的監聽與響應[21]。

圖7 多控制器架構

在控制器層使用3 個控制器進行集群部署（根據系統的可擴展性，可以向系統動態增加控制器數量，但本文機制使用3 個控制器已經能夠滿足系統的可用性）。控制器間采用主從（Master/Slaves）結構（主從控制器模式），其中一個控制器為主控制器，2 個控制器為從控制器。在正常通信階段，由主控制器負責控制數據平面的數據轉發。從控制器在主控制器工作時處于熱備份模式，即只備份SDN數據信息并與主控制器保持同步，但不下發流表給交換機。控制器之間需要建立通信鏈路用來進行信息交互。控制器間交互數據包主要有3 種類型，即同步數據包、請求轉發數據包以及保活數據包[23]。同步數據包由主控制器發送給從控制器，內容包括控制器自身狀態變化信息。請求轉發數據包將發送至控制器的數據包轉發至負載比它小的其他控制器。保活數據包主要用來測試連接狀態和網絡時延。

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

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

Zookeeper 服務器負責多控制器的集群管理以及分布式協調，實現了多控制器間的信息共享與數據一致性。Zookeeper 使用樹形結構數據單元ZNode來存儲數據，服務器通過監控ZNode 節點中數據的變化來感知事件，并做出響應。ZNode 節點關系如圖8 所示。

圖8 ZNode 節點關系

ZNode“/controller”及其子節點用于記錄每個控制器的信息。“/cid1”至“/cidN”節點代表網絡內的不同控制器，每個節點代表一臺控制器。

ZNode“/topology”節點用于存儲全局網絡拓撲信息以及交換機連接信息，這2 種信息是多控制器之間需要共享的信息。子節點“/IP”標識了不同的控制器，該節點下的數據代表一個控制器掌握的拓撲信息和設備連接信息。當網絡中的拓撲或交換機連接狀態發生變化時，主控制器首先負責將更新后的信息存儲至每一個“/IP”節點內，Zookeeper通過Watcher 監聽“/IP”節點內的數據變化，并通過Watch 事件通知從控制器。隨后從控制器訪問Zookeeper 服務器中自身對應的“IP”節點，獲取新的全網拓撲信息以及交換機連接信息。上述方法能夠使多控制器中的網絡拓撲信息數據保持一致，并且當網絡更新后，多控制器的數據仍處于一致狀態。

2.4.3 容災機制實現過程

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

3 方案整體設計

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

圖9 本文方案的主要流程

1) 當用戶接入該SDN 時，屬性簽名標識生成模塊根據入網用戶的身份屬性，生成用戶的屬性集合。

2) 屬性簽名標識認證中心生成系統的公開參數與主密鑰。

3) 屬性簽名驗證模塊生成訪問控制樹T，并將T發送給認證中心。認證中心根據T生成T的公開參數。

4) 屬性簽名標識生成模塊將用戶的屬性集合發給認證中心。認證中心根據屬性集合為用戶生成用戶私鑰。

5) 認證中心將用戶私鑰發送給屬性簽名標識生成模塊。

6) 屬性簽名標識生成模塊以用戶用于簽名的屬性集、T的公開參數和數據包傳輸的消息m為輸入，計算出屬性簽名值。然后將屬性簽名值以及用戶的簽名屬性放入數據包的Option 字段中。

7) P4 轉發設備解析數據包中的屬性簽名標識。采樣控制模塊根據設置的檢測因子θ來判斷當前數據包是否為采樣檢測數據包，若是，執行8a)；否則執行8b)。

8a) 待檢測數據包被加載至數據包鏡像模塊，該模塊將待檢測數據包復制，并將鏡像數據包發送至P4 轉發設備出端口，原數據包執行8b)。

8b) P4 轉發設備轉發數據包至OpenFlow 交換機，而OpenFlow 交換機通過匹配流規則執行相應的數據包轉發動作。

9) P4 轉發設備將其出端口中的待檢測數據包發送至控制器，并由控制器的屬性簽名驗證模塊接收。

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

11) 異常告警模塊收到無效數據包后，根據Ryu 控制器事件機制，向數據轉發處理模塊發送告警事件EventWarning。

12) 數據轉發處理模塊監聽到EventWarning事件后，下發相應的流規則給OpenFlow 交換機，令其對于檢測異常的數據流進行攔截。

13) 如果出現控制器單點失效情況時，根據控制器容災機制使用從控制器接替當前主控制器的工作。

4 仿真實驗及評估

4.1 實驗設置

本實驗采用一臺Windows Server2012 服務器作為屬性簽名標識認證中心，一臺Windows Server2012 服務器作為Zookeeper 服務器，2 臺Windows主機作為終端，一臺虛擬機上安裝3 臺Ryu 控制器，另一臺虛擬機安裝一個Bmv2 軟件交換機以及2 個OpenFlow 軟件交換機。控制器與交換機在Mininet環境下實現網絡互聯，服務器、終端以及虛擬機通過網線互聯。圖10 顯示了實驗環境的拓撲結構。本實驗主要測試該機制的檢測準確率、數據包轉發時延以及系統性能。

圖10 實驗環境的拓撲結構

4.2 檢測準確率

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

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

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

4.3 數據包轉發時延

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

圖12 數據包轉發時延

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

4.4 網絡吞吐量開銷

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

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

圖13 網絡吞吐量對比

4.5 擴展實驗

本節實驗增加了數據平面上的用戶節點，通過這種方式來測試當網絡規模擴大時數據包轉發時延以及網絡吞吐量的變化情況。由于實驗條件有限，系統共添加了32 臺主機作為用戶主機，負責向網絡中發送數據包。本文分別測試用戶主機數為1、2、4、8、16、32 時的數據包轉發時延和網絡吞吐量，擴展實驗拓撲如圖14 所示。

圖14 擴展實驗拓撲

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

圖15 不同主機數量下的數據包轉發時延

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

圖16 不同主機數量下的網絡吞吐量

綜上所述，擴展網絡規模會給網絡的吞吐量以及數據包轉發時延帶來一定的影響，但通過實驗結果的分析可知對于添加了數據轉發驗證機制的網絡影響有限，網絡開銷并非成倍增長，仍處于可接受范圍內。

4.6 機制對比

將本文的轉發驗證方案與已經提出的一些轉發驗證方案[8,10,18]進行對比，如表1 所示。

表1 不同方案特點比較

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

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

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

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

在實現功能方面，4 種方案都可以實現檢測偽造、篡改數據包的功能，而由于本文方案將用戶的身份屬性與用戶發出的數據包進行了綁定，一旦發現用戶在網絡中的違規行為，可以利用屬性簽名標識追蹤其真實身份，因此相比其他方案，實現了用戶身份的可追蹤性。

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

5 結束語

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