SDN數據安全處理機制關鍵模塊的研究與實現

李兆斌，李偉隆，魏占禎，劉夢甜

(北京電子科技學院 通信工程系，北京 100070)(*通信作者電子郵箱lovewiser@163.com)

0 引言

軟件定義網絡(Software Defined Network， SDN)是網絡發展的新趨勢，它將傳統封閉的網絡體系解耦為數據平面、控制平面和應用平面，在邏輯上實現網絡的集中控制與管理[1]。OpenFlow協議是控制平面和數據平面之間的交互協議，可以將控制數據由控制平面的控制器下發至數據平面的數據轉發設備。目前，企業園區網絡、數據中心部署大量基于OpenFlow的SDN，其中承擔數據轉發功能的開源OpenFlow虛擬交換機Open VSwitch(OVS)更是在部署過程中得到廣泛應用。

不過，隨著SDN的迅猛發展，其安全問題也受到越來越多的關注，如控制器重要數據遭竊取、控制器因惡意分布式拒絕服務(Distributed Denial of Service, DDoS)攻擊導致宕機[2]、被安裝惡意應用等，這類問題給SDN的安全和穩定帶來極大的挑戰[3]。針對這些問題，國內外科研院所及安全企業提出多種SDN安全解決方案。有些解決方案以引入如防火墻、入侵檢測系統等傳統網絡安全設備來解決SDN安全問題為主要思路，這類方案的確能夠解決部分安全問題；但是卻要求安全設備部署在有確切邊界的區域，這違背了SDN結構靈活、可編程、轉控分離的核心指導思想。一部分解決方案是由安全設備廠商獨自開發新的SDN安全設備，這些新設備能夠與SDN契合，同時也能兼顧廠商已部署的傳統安全設備；但因各安全企業研發的SDN安全設備標準未能統一，數據安全處理過程也未融入到轉發設備的數據處理流程中，給全網安全視圖的形成造成阻礙。還有一些解決方案是將虛擬化的網絡安全設備與它們的接入模式、部署位置進行解耦，抽象為安全資源池里的資源，智能化、自動化管理安全資源池；然而這類方案的基礎是安全設備支持虛擬化，但這一前提在目前很難實現。

相比上述如企業獨自開發SDN安全設備亦或是引入傳統的網絡安全設備防范SDN網絡威脅等解決方案，文獻[4]通過分析SDN數據轉發平面的安全問題，提出了數據流表安全保護的方案，這一方案擺脫了區域限制、設備虛擬化等諸多要求，是解決SDN安全問題的新思路；但是，這一方案卻沒有考慮如何保護數據轉發平面的用戶數據完整和不被竊取。

因此，本文針對SDN的數據轉發平面的數據泄露隱患和完整性保護問題，通過對OpenFlow協議進行深入分析和擴展，在對OVS數據轉發流程[5]進行深入研究的基礎上，創新性地提出一種新的基于OpenFlow的SDN的數據安全處理機制——SDN-DataSec(Software Defined Network-DataSecurity)。這一機制將數據安全處理融入到OVS數據轉發過程中，在SDN的通用南向接口協議OpenFlow和虛擬交換機OVS中開發實現，包括OpenFlow安全策略解析、安全策略匹配、數據安全處理三個主要過程。SDN-DataSec不但不需要額外添加設備和安全軟件，更是可與現有的OVS數據處理流程完全融合。本文首先對SDN現存的數據安全問題進行分析，發現數據平面數據傳輸時保密性問題；然后結合SDN的分層架構提出SDN數據安全處理機制，并闡述其基本模型和數據安全處理過程；隨后重點闡述數據安全處理機制的關鍵模塊和OpenFlow協議開發實現，并分析了加解密操作的處理粒度；最后，搭建軟硬件平臺對本文設計實現的數據安全處理機制進行有效性和性能開銷測試。

1 SDN數據安全問題分析

支持OpenFlow協議[6]的OVS通常包含三個部分，分別是OpenFlow客戶端、流緩沖區和流表，每個部分都可能成為數據轉發平面中被攻擊的目標，常見攻擊如下。

1)流表溢出攻擊導致數據泄露。OVS因設備性能的不同，導致其只能擁有數量有限的數據包緩沖區，存儲有限數量的流表[7]。當OVS接收到數據包后，它將被暫存在緩沖區流中，直到有新規則插入適配成功，或直到流表中已存的流表規則獲得響應，因此，攻擊者可以通過發送大量未知數據包來使緩沖區和流表飽和，這將導致OVS流表及緩沖模塊癱瘓。這種攻擊嚴重損害合法數據包的正常轉發，也為攻擊者提供了竊取SDN數據包的機會[8]。

2)傳輸通道的數據竊取攻擊。數據轉發平面位于SDN架構的底部，包含大量互相連接、負責轉發主機通信數據包的OVS。對于SDN網絡來說，只有部分OVS是客戶端主機訪問網絡的直接入口點和出口點，大部分OVS對數據包只作轉發等基本操作，而數據包在數據轉發面始終處于明態傳輸，一旦某個OVS受到控制，那么流經它的數據包將很容易泄露[9]。根據這種網絡特點，攻擊者可以通過簡單地將鏈路附加到OVS的端口或通過未經驗證的OVS接入網絡來達到竊取SDN網絡數據包[10]的目的。

針對SDN網絡的安全問題，蔡佳曄等[11]設計了一種基于Sibson距離的DDoS攻擊檢測架構，該分層式架構通過引入攻擊檢測算法并采用多個代理控制器有效提升DDoS攻擊檢測時效性和準確性；但該架構專注于控制器攻擊威脅的有效防范，缺少對數據平面交換機的安全研究。Afek等[12]舍棄中間件，基于數據平面提出了抗DDoS攻擊的網絡平臺，通過復雜的流表規則以及交換機與控制器共享網絡安全資源的方式增強SDN網絡的抗DDoS能力；但該平臺內部的安全性能較差，只能抵御外部的攻擊。Lee等[13]開發了安全評估框架——DELTA(A Security Assessment Framework for Software-Defined Network)，在深度融合系統論與方法論的基礎上開發了能夠自動識別新漏洞的模糊檢測機制，顯著提升了SDN網絡的整體安全性；但該框架的解決重點在于控制器和交換機的系統漏洞，對于SDN的傳輸網絡安全問題防范相對薄弱。吳泉峰等[14]設計了一種基于SDN的流接入安全系統(SDN based Flow Access Security System, SDN-FASS)，該系統通過設立接入實體的黑(白)名單的方式實時下發接入控制安全策略，有效地防范網絡外部的攻擊并能夠實時監測SDN網絡內部的非法操作；但該系統只針對接入SDN網絡的用戶實體行為進行審計和監測，用戶實體傳輸的數據安全缺少相關的防護，沒有解決數據包明態傳輸可能帶來的安全隱患。針對數據包在數據平面傳輸時處于明態傳輸狀態、極易被竊取、保密性和完整性無法保證等問題，本文選擇以OVS以及OpenFlow協議為研究對象，設計基于OpenFlow的SDN數據安全處理機制，將SDN數據平面中用戶數據的明態傳輸變為安全的密態傳輸。

2 SDN數據安全處理機制設計

2.1 基本模型闡述

支持OpenFlow協議的OVS可分為用戶層和內核層兩部分。用戶層包含了OVS的守護進程、OpenFlow管理工具以及數據庫等[15]。內核層包含OVS的流表以及一個或者多個數據鏈路處理模塊，可以快速地對數據包進行轉發等操作。

OVS的主要功能是直接對用戶數據進行明態處理和轉發，并不負責轉發數據的保密性和完整性保護[16]。SDN數據安全處理機制SDN-DataSec基本模型如圖1所示，該機制擴展了OVS數據處理流程，添加了數據安全處理、安全解析、加解密處理，實現了數據加密傳輸，從而提高了OVS傳輸數據的保密性與完整性。

OVS支持兩種類型的流表，即由Ofproto維護的OpenFlow流表和由內核數據路徑維護的“Kernel”或“Datapath”流表。內核維護數據路徑流表的主要目的是提高性能，以便只將第一個數據包發送到用戶空間，并且隨后的數據包通過向內核數據路徑添加流表來避免影響到用戶空間[17]。因此，SDN-DataSec創新性地設計提出數據安全策略，即根據不同數據包匹配條件與安全動作組合而成的策略流表，實現以數據流表形式從控制器下發數據安全策略至轉發設備，轉發設備根據數據安全策略對數據包進行加解密等安全動作。

圖1 SDN-DataSec基本模型

SDN-DataSec模型覆蓋控制面與數據轉發面，包括控制器與OVS兩類設備。其中，控制器主要包括全局安全策略模塊和OpenFlow消息處理模塊，OVS主要包括OpenFlow消息處理模塊、OpenFlow安全策略模塊、安全策略匹配模塊、數據安全分析模塊、數據加解密模塊以及包重構模塊等。控制器的全局安全策略模塊可以根據用戶的媒體介入控制層(Media Access Control， MAC)地址或VLAN生成基于數據鏈路的加解密等安全處理動作，即安全策略，也可以根據傳統的IP地址、端口和協議生成基于數據流的安全策略。控制器通過OpenFlow協議向OVS下發包含安全策略的流表，OVS按照控制器下發的安全策略建立安全的數據轉發鏈路，保障OVS之間轉發數據的保密性和完整性。

2.2 SDN-DataSec數據安全處理過程

本文提出的數據安全處理過程機制，是對OpenFlow協議和OVS、控制器進行深度優化改進后設計實現的。SDN-DataSec中控制器和OVS各模塊間的數據處理過程如圖2所示。

圖2 SDN-DataSec數據處理過程

OVS內核層的Vport數據接收模塊負責接收網絡數據包，然后將數據發送至核心的Datapath轉發處理模塊，該模塊對數據包頭相應元素進行提取，將其與存儲在內核的流表進行匹配，如匹配不成功則使用Nelink通道上傳至OVS用戶層的數據處理模塊。若用戶層數據處理模塊也無相應流表與之匹配，則通過OpenFlow消息處理模塊上報控制器，請求數據轉發流表。控制器中的全局安全策略模塊可根據全局網絡安全需求生成并下發數據安全策略。OVS數據安全處理過程如下。

①數據安全策略接收和轉譯。

OpenFlow安全策略模塊主要承擔存儲、轉譯控制器下發的數據安全策略任務。OpenFlow協議是控制平面和數據平面之間的可編程接口，允許OVS接收控制器下發的控制信息。OVS內的OpenFlow協議主要由執行數據包查找和轉發任務的流表和組表組成。本文設計開發的OpenFlow數據安全策略基于標準的OpenFlow協議，對其進行了擴展，添加新的安全策略執行操作。

在OpenFlow安全策略當中，將具體的每條策略定義為條件和動作的組合，依據條件執行相應的安全動作指令。在宏觀上，控制層維護了一個全局的安全策略庫，自動地收集網絡內受管理的數據轉發層設備信息，更新全局安全策略數據庫，再將安全策略通過OpenFlow下發到數據轉發設備當中。轉發設備OVS內的OpenFlow安全策略模塊接收到OpenFlow下發的安全策略后，將其轉譯為OVS本地安全策略邏輯，再發送至安全策略匹配模塊。

本文的SDN安全策略下發過程具有較高的兼容性。控制器針對數據平面現有的網絡情況制定安全策略并通過OpenFlow發送至相應的OVS,同時控制器與OVS也使用OpenFlow正常交互，下發標準的流表，可及時適應網絡拓撲變化，在保留了靈活性的同時也提高了控制器對OVS的全局安全管控能力，降低了網絡管理的復雜程度。

②安全策略匹配。

安全策略匹配模塊主要負責接收轉譯后的安全策略以及由用戶層數據處理模塊發來的未匹配數據包。將接收的數據包與安全策略匹配，若匹配失敗則將其發回用戶層數據處理模塊；若匹配成功，則將相應的數據包及匹配成功的安全策略發送至數據安全分析模塊。

③深度解析數據包。

OVS設備對于從端口進入的數據包只能根據流表的匹配項，針對數據包包頭某幾位特定的關鍵值(如傳輸控制協議(Transmission Control Protocol， TCP)和用戶數據報協議 (User Datagram Protocol， UDP)地址、端口號等)進行提取。由于OVS沒有相應的數據接口對網絡數據載荷進行提取，因此無法對數據包整體進行解析。本文對OVS數據處理流程進行了深度的擴展改造后，編寫凈載數據的提取接口，設計實現數據安全分析模塊，該模塊不僅能兼容OVS原有的數據包頭關鍵信息提取方法，還可以根據安全策略提取對應的數據包凈載信息。

數據安全分析模塊接收到安全策略及匹配成功的數據包后，對數據包進行深度解析。根據安全策略執行不同的安全操作，可以解析包頭的各項關鍵信息，同時也可解析提取出Payload凈載信息。在成功解析獲取數據信息后，數據安全分析模塊將解析的數據信息發送至數據加解密模塊。

④數據加解密。

OVS在對數據進行轉發時完全沒有對其所傳輸的敏感信息進行安全處理，這使得信息在數據轉發平面傳輸沒有任何安全防護。本文將密碼算法加入到OVS中，開發實現數據加解密模塊。

數據加解密模塊接收到數據安全分析模塊發來的數據信息后，將其進行加(解)密處理，并將加(解)密處理的密(明)文發送至包重構模塊。

⑤數據包重構。

傳統OVS設備中已含有包重構模塊，但其功能并不能滿足數據安全處理需求。本文對該模塊進行重新設計，使其具備了對凈載信息進行包重構的功能。

包重構模塊接收到加解密模塊發來的密(明)文后，從數據安全分析模塊獲取密數據對應的數據包頭信息，將密(明)文進行包重構操作。

⑥數據轉發。

包重構模塊將重構處理后的數據包發回用戶層數據處理模塊，數據安全處理過程結束，數據包進入OVS正常工作流程，OVS可對其進行相應的轉發操作。

3 SDN數據安全處理機制關鍵模塊實現

本文選擇Ryu[18]作為控制器，虛擬交換機OVS作為數據轉發設備，本文所提出的數據安全處理機制主要工作和創新點聚焦于安全策略匹配模塊、數據加解密模塊、數據安全分析模塊、包重構模塊等多個模塊的開發實現，OpenFlow協議的擴展及數據安全策略的匹配過程和數據安全處理的完整流程的設計。下面以涉及數據加解密的關鍵模塊為例體現本文機制的創新性和主要工作內容，介紹OVS數據安全處理關鍵技術的實現以及對OpenFlow協議的擴展方法。

3.1 OVS數據加解密

OVS的數據處理分別在內核和用戶兩個空間進行，本文開發的數據加解密模塊在用戶層進行編譯執行，該模塊主要負責對從數據包中提取的數據信息或關鍵流表項信息進行加解密處理。用戶層與內核層數據處理流程如圖3所示。

圖3 用戶層與內核層數據處理流程

在數據包到達OVS端口時，數據包與內核空間中存在的流表進行匹配。如果匹配成功，則執行相應的動作(Action)對數據包進行處理；否則，使用Netlink套接字將數據包發送到用戶空間進行OpenFlow流表查找。如果能夠與用戶空間維護的流表匹配，則進行相應的處理。如果沒有找到匹配項，則將數據包發送到控制器。數據加解密模塊的具體函數處理流程如圖4所示。

由于OVS的Datapath模塊(數據路徑)是數據的“必經之路”[19]，本文對該模塊進行了深入研究，添加了自定義的加解密動作指令及動作執行邏輯。以下是在Datapath模塊中添加的Action操作定義：

enum ovs action attr {

OVS ACTION ATTR OUTPUT,

OVS ACTION ATTR PUSH VLAN,

OVS ACTION ATTR POP VLAN,

OVS ACTION ATTR SDN_ENCRYPT

OVS ACTION ATTR SDN_DECRYPT}；

其中SDN_ENCRYPT、SDN_DECRYPT是新添加的執行動作來支持加密和解密功能。同時為了支持新的動作，還需完成適當的結構定義，如struct ovs action sdn_encrypt等。

圖4 數據加解密函數處理流程

為了OVS能夠查看并檢索到加解密動作，需對Ofproto子模塊進行擴展改造，將加解密動作名稱添加到該模塊中的宏定義動作集中，如下：

#define OFPACTS

DEFINE OFPACT(OUTPUT, ofpact output, ofpact)

DEFINE OFPACT(SET VLAN VID,ofpact vlan vid,ofpact)

DEFINE OFPACT(PUSH VLAN, ofpact null, ofpact)

DEFINE OFPACT(SDN_ENCRYPT,ofpact_null,ofpact,

"sdn_encrypt")

以上完成了數據加解密動作指令Action的添加。為了能夠在OVS中執行具體的加解密操作，必須添加執行加解密的邏輯函數，需對Ofp-action模塊及Ofproto模塊進行適當的擴展，使其兼容新添加的動作指令。不僅如此，為了使添加的動作能夠被OVS提取和搜索/匹配流表項，還需對數據庫模塊目錄中的流表項模塊、篩選匹配模塊進行擴展改造。

3.2 OpenFlow協議擴展

通過對OpenFlow協議的匹配項和動作擴展，添加OpenFlow安全策略模塊，可使控制器能夠根據安全策略生成數據安全處理策略，并將安全策略下發到OVS中，增強了SDN網絡應對安全問題的處理能力。

新添加的基于OpenFlow的安全策略模塊處于OVS的數據層面。一方面OpenFlow安全策略模塊可以不完全依賴控制器而是在數據層面直接對數據進行相應處理；另一方面OVS中的OpenFlow安全策略模塊符合OpenFlow API調用標準，控制器可以對其進行靈活調用以便與控制器中的全局安全策略模塊交互。不僅如此，通過擴展OpenFlow協議添加的OpenFlow安全策略模塊所產生的流表和原有的OpenFlow流表規則標準相同，可以融入到原有的OpenFlow流表中，保證OpenFlow的流表一致性。

OpenFlow安全策略模塊主要工作流程如圖5所示，該模塊有兩種安全策略流表創建方式：

1)主動式。即安全策略流表被提前寫入OVS中，使用時OpenFlow安全策略模塊根據數據分析模塊解析已存在的安全策略進行相應處理。

2)被動式。由控制器通過Packet_out報文將控制器全局安全策略模塊產生的安全策略流表下發至各OVS。

圖5 安全策略模塊主要工作流程

在被動式網絡中，若下發的一條安全策略與OVS中目前使用的所有安全策略都不匹配或有沖突，則OVS將該數據信息解析封裝為Packet_in報文中并上報給控制器。控制器收到報文后，利用已掌握的全局網絡情況再次根據全局安全解析模塊決定丟棄或者對數據包進行其他處理，并將更新后的安全策略下發給OVS。OVS收到新的安全策略后，OpenFlow安全策略模塊自動更新流表，之后再次處理該類型的數據包時，會有相應的流表與其匹配。

為了保證OVS的OpenFlow安全策略模塊可以與控制器正常使用OpenFlow協議進行交互，添加的新動作應與OVS支持的所有OpenFlow協議版本兼容。

3.3 加解密處理粒度分析

在目前OVS的流表使用中，已不僅是單純的精確匹配了，而是一種精確匹配+帶掩碼匹配合并在一起的方式。該方式的目的是為了減少Datapath里精確流表的條目數，將部分模糊匹配下放到內核態處理，以減少每次因為不同的包被遞送時都要Upcall到用戶空間的時間，借此提高效率，因此本文在添加加解密操作后，根據不同數據包類型，在開發實現的數據安全分析模塊以及安全策略模塊基礎上，優化加解密操作，細化加解密操作粒度，提高處理效率，減少處理時間。根據控制器下發的安全策略，加解密處理基本操作粒度如表1所示。

每條策略定義為條件和動作的組合，依據由基本條件字段、細粒度條件字段組成的條件執行相應的安全動作指令。基本條件字段規定本條策略的生存時長，處理數據包數量，具體包括生效時間Duration_sec、所屬表項Table_id、優先級Priority、處理的數據包數、空閑超時時間Idle_timeout等，超過設置的空閑超時時間后該策略將被自動刪除，空閑超時時間設置為0表示該策略永不過期，從而保證策略實時更新，實時有效。細粒度條件字段包括輸入端口號In_port、源/目的MAC地址Dl_src/Dl_dst、源/目的IP地址Nw_src/Nw_dst、數據包類型Dl_type、網絡層協議類型Nw_proto等。

表1 基本操作粒度

一條策略需由以上條件輔以執行動作組成，當數據包進入安全策略匹配模塊時，即根據細粒度條件對數據包進行篩選：

1)當多個細粒度條件均滿足時，即將安全策略與匹配成功的數據包一并發給數據安全模塊。

2)當多個細粒度條件只滿足其中幾項時，即查看是否匹配成功表1中帶(*)條件字段，若匹配成功即交由數據安全模塊處理。

3)若未匹配成功，則將數據返回用戶層數據處理模塊進行后續轉發等操作。為了保證OVS的OpenFlow安全策略模塊可以與控制器正常使用OpenFlow協議進行交互，添加的新動作應與OVS支持的所有OpenFlow協議版本兼容。

4 測試與結果分析

4.1 測試環境

本文提出了數據安全處理機制，與之相關的SDN數據安全研究成果，目前有杭州華三通信公司的SDN安全功能方法和裝置[20]和上海斐訊數據通信公司的基于SDN的數據流加密方法和系統[21]均屬于相關企業的發明專利，難以比較分析，因此，本文就所設計實現的數據安全處理機制的有效性和性能開銷進行相關測試。

測試主機選用Ubuntu15.10系統，2.6.0版本OVS，4.13版本Ryu，測試拓撲如圖6所示。

圖6 測試拓撲結構

4.2 有效性測試

本次測試OVS1和OVS2傳輸Host1、Host2通信數據時是否可以針對下發的安全策略對敏感數據進行加解密操作。為方便驗證，本次測試中OVS使用基本的異或算法進行加解密操作。

1)Ryu控制器下發安全策略：OVS1對Host1發往Host2的UDP數據包進行加密操作，同時OVS2不作解密操作，直接轉發至Host2。

如圖7所示，使用抓包工具在Host1處抓包，顯示Host1向Host2發出消息：Besti。

圖7 Host1發送數據抓取

Fig. 7 Data crawl sent by Host1

使用抓包工具在Host2上抓取來自Host1的UDP數據包，抓取的數據包如圖8所示，Besti已被OVS1完整地解析獲取并使用密碼算法加密成功，重構數據包后再次發送出去。

圖8 Host2接收數據抓取

Fig. 8 Data crawl received by Host2

2)Ryu控制器下發安全策略：OVS1對Host1發往Host2的UDP數據包進行加密操作，同時OVS2對Host1發往Host2的UDP數據包進行解密操作，處理后轉發至Host2。

如圖9～10所示，兩臺OVS的加密、解密安全策略已經運作，并成功處理數據。同時于Host1處抓包，顯示Host1向Host2發出消息：Besti、OVS1、OVS2已運行加密，解密安全策略(sdn_encrypt,sdn_decrypt)，對Host1、Host2往來的通信信息分別進行加密和解密處理，Host2收到完整的數據。

圖9 加密策略執行

Fig. 9 Encryption strategy implementation

圖10 解密策略執行

Fig. 10 Decryption strategy implementation

4.3 性能測試

1)OVS1、OVS2均執行基本的OUTPUT(轉發)動作，OVS1執行其自帶的更改VLAN的PUSH VLAN操作，OVS2執行POP VLAN動作；在OVS1、OVS2處分別執行開發的加解密動作處理，然后(如圖11所示)統計對比相同數量的數據包所產生的時延情況。本次測試通過發送大量的相同內容數據包測試不同動作產生的時延情況。

圖11 3種執行操作的時延對比

由圖11可知，當數據包發送數量為200 000時，時延基本一致。在發送量為400 000數據包以后，時延開始變大并且三種動作的時延差距趨于明顯。本文加密動作所產生的時延雖略高于基本的轉發動作，但與對數據包進行修改處理的PUSH VLAN+POP VLAN時延相近，說明該功能不會對正常的數據交換造成較大影響。

2)OVS1、OVS2均執行基本的OUTPUT(轉發)動作；在OVS1、OVS2處分別執行開發的加解密動作處理，并(如圖12所示)統計和對比當不同數據包大小時，加解密動作和轉發動作的吞吐量情況。

圖12 兩種操作的吞吐量對比

如圖12所示，加解密動作的吞吐量低于OVS的基本動作(轉發)，但差距不影響數據的正常傳輸。

3)OVS1、OVS2分別針對不同類型的數據包(TCP、UDP、IP、MAC)執行轉發處理和加解密處理，統計并對比CPU使用情況，如圖13所示。注：本次測試中相同類型的數據包大小內容均相同。

圖13 兩種操作處理不同類型數據包的CPU使用率對比

如圖13所示，可知正常轉發動作因未對數據進行處理即CPU使用率低，始終低于10%；加解密操作因處理的數據包類型不同，其CPU使用率在45%～60%浮動，CPU使用率高，但仍可正常傳輸數據。

綜合以上測試結果，本文設計并實現數據安全處理機制能夠有效地對數據進行加解密操作，并且不會對正常的數據傳輸造成較大影響。

5 結語

當下軟件定義網絡對數據的轉發均處于“明態”傳輸模式，網絡架構缺乏安全策略，數據信息安全得不到保證，本文針對軟件定義網絡中的數據泄露問題，設計實現了SDN數據安全處理平臺。通過對控制器和OVS的多個功能模塊的開發實現，完成了本平臺的數據安全策略細粒度匹配和數據安全處理全過程。最后，通過有效性和性能開銷測試，結果表明本文提出的數據安全處理機制能夠準確、有效地對數據進行加解密處理，時延和吞吐量數據處于正常水平但CPU使用率較高，負載較大。

本文提出的數據安全處理機制雖然能夠基本滿足SDN網絡架構下的數據保密需求，但存在CPU負荷較大的不足，因此進一步的研究方向是深度優化數據安全處理流程，降低負載開銷，降低CPU使用率，提高吞吐量，提升性能；深入研究本機制使用同種加(解)密算法能否處理不同類型的數據包，研究密鑰分配方式能否深層次融入機制功能當中，研究非對稱加(解)密算法和對稱加(解)密算法的使用對機制功能的不同影響。