SDN數(shù)據(jù)安全處理機(jī)制關(guān)鍵模塊的研究與實(shí)現(xiàn)

李兆斌，李偉隆，魏占禎，劉夢(mèng)甜

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

0 引言

軟件定義網(wǎng)絡(luò)(Software Defined Network， SDN)是網(wǎng)絡(luò)發(fā)展的新趨勢(shì)，它將傳統(tǒng)封閉的網(wǎng)絡(luò)體系解耦為數(shù)據(jù)平面、控制平面和應(yīng)用平面，在邏輯上實(shí)現(xiàn)網(wǎng)絡(luò)的集中控制與管理[1]。OpenFlow協(xié)議是控制平面和數(shù)據(jù)平面之間的交互協(xié)議，可以將控制數(shù)據(jù)由控制平面的控制器下發(fā)至數(shù)據(jù)平面的數(shù)據(jù)轉(zhuǎn)發(fā)設(shè)備。目前，企業(yè)園區(qū)網(wǎng)絡(luò)、數(shù)據(jù)中心部署大量基于OpenFlow的SDN，其中承擔(dān)數(shù)據(jù)轉(zhuǎn)發(fā)功能的開(kāi)源OpenFlow虛擬交換機(jī)Open VSwitch(OVS)更是在部署過(guò)程中得到廣泛應(yīng)用。

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

相比上述如企業(yè)獨(dú)自開(kāi)發(fā)SDN安全設(shè)備亦或是引入傳統(tǒng)的網(wǎng)絡(luò)安全設(shè)備防范SDN網(wǎng)絡(luò)威脅等解決方案，文獻(xiàn)[4]通過(guò)分析SDN數(shù)據(jù)轉(zhuǎn)發(fā)平面的安全問(wèn)題，提出了數(shù)據(jù)流表安全保護(hù)的方案，這一方案擺脫了區(qū)域限制、設(shè)備虛擬化等諸多要求，是解決SDN安全問(wèn)題的新思路；但是，這一方案卻沒(méi)有考慮如何保護(hù)數(shù)據(jù)轉(zhuǎn)發(fā)平面的用戶數(shù)據(jù)完整和不被竊取。

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

1 SDN數(shù)據(jù)安全問(wèn)題分析

支持OpenFlow協(xié)議[6]的OVS通常包含三個(gè)部分，分別是OpenFlow客戶端、流緩沖區(qū)和流表，每個(gè)部分都可能成為數(shù)據(jù)轉(zhuǎn)發(fā)平面中被攻擊的目標(biāo)，常見(jiàn)攻擊如下。

1)流表溢出攻擊導(dǎo)致數(shù)據(jù)泄露。OVS因設(shè)備性能的不同，導(dǎo)致其只能擁有數(shù)量有限的數(shù)據(jù)包緩沖區(qū)，存儲(chǔ)有限數(shù)量的流表[7]。當(dāng)OVS接收到數(shù)據(jù)包后，它將被暫存在緩沖區(qū)流中，直到有新規(guī)則插入適配成功，或直到流表中已存的流表規(guī)則獲得響應(yīng)，因此，攻擊者可以通過(guò)發(fā)送大量未知數(shù)據(jù)包來(lái)使緩沖區(qū)和流表飽和，這將導(dǎo)致OVS流表及緩沖模塊癱瘓。這種攻擊嚴(yán)重?fù)p害合法數(shù)據(jù)包的正常轉(zhuǎn)發(fā)，也為攻擊者提供了竊取SDN數(shù)據(jù)包的機(jī)會(huì)[8]。

2)傳輸通道的數(shù)據(jù)竊取攻擊。數(shù)據(jù)轉(zhuǎn)發(fā)平面位于SDN架構(gòu)的底部，包含大量互相連接、負(fù)責(zé)轉(zhuǎn)發(fā)主機(jī)通信數(shù)據(jù)包的OVS。對(duì)于SDN網(wǎng)絡(luò)來(lái)說(shuō)，只有部分OVS是客戶端主機(jī)訪問(wèn)網(wǎng)絡(luò)的直接入口點(diǎn)和出口點(diǎn)，大部分OVS對(duì)數(shù)據(jù)包只作轉(zhuǎn)發(fā)等基本操作，而數(shù)據(jù)包在數(shù)據(jù)轉(zhuǎn)發(fā)面始終處于明態(tài)傳輸，一旦某個(gè)OVS受到控制，那么流經(jīng)它的數(shù)據(jù)包將很容易泄露[9]。根據(jù)這種網(wǎng)絡(luò)特點(diǎn)，攻擊者可以通過(guò)簡(jiǎn)單地將鏈路附加到OVS的端口或通過(guò)未經(jīng)驗(yàn)證的OVS接入網(wǎng)絡(luò)來(lái)達(dá)到竊取SDN網(wǎng)絡(luò)數(shù)據(jù)包[10]的目的。

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

2 SDN數(shù)據(jù)安全處理機(jī)制設(shè)計(jì)

2.1 基本模型闡述

支持OpenFlow協(xié)議的OVS可分為用戶層和內(nèi)核層兩部分。用戶層包含了OVS的守護(hù)進(jìn)程、OpenFlow管理工具以及數(shù)據(jù)庫(kù)等[15]。內(nèi)核層包含OVS的流表以及一個(gè)或者多個(gè)數(shù)據(jù)鏈路處理模塊，可以快速地對(duì)數(shù)據(jù)包進(jìn)行轉(zhuǎn)發(fā)等操作。

OVS的主要功能是直接對(duì)用戶數(shù)據(jù)進(jìn)行明態(tài)處理和轉(zhuǎn)發(fā)，并不負(fù)責(zé)轉(zhuǎn)發(fā)數(shù)據(jù)的保密性和完整性保護(hù)[16]。SDN數(shù)據(jù)安全處理機(jī)制SDN-DataSec基本模型如圖1所示，該機(jī)制擴(kuò)展了OVS數(shù)據(jù)處理流程，添加了數(shù)據(jù)安全處理、安全解析、加解密處理，實(shí)現(xiàn)了數(shù)據(jù)加密傳輸，從而提高了OVS傳輸數(shù)據(jù)的保密性與完整性。

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

圖1 SDN-DataSec基本模型

SDN-DataSec模型覆蓋控制面與數(shù)據(jù)轉(zhuǎn)發(fā)面，包括控制器與OVS兩類設(shè)備。其中，控制器主要包括全局安全策略模塊和OpenFlow消息處理模塊，OVS主要包括OpenFlow消息處理模塊、OpenFlow安全策略模塊、安全策略匹配模塊、數(shù)據(jù)安全分析模塊、數(shù)據(jù)加解密模塊以及包重構(gòu)模塊等。控制器的全局安全策略模塊可以根據(jù)用戶的媒體介入控制層(Media Access Control， MAC)地址或VLAN生成基于數(shù)據(jù)鏈路的加解密等安全處理動(dòng)作，即安全策略，也可以根據(jù)傳統(tǒng)的IP地址、端口和協(xié)議生成基于數(shù)據(jù)流的安全策略?？刂破魍ㄟ^(guò)OpenFlow協(xié)議向OVS下發(fā)包含安全策略的流表，OVS按照控制器下發(fā)的安全策略建立安全的數(shù)據(jù)轉(zhuǎn)發(fā)鏈路，保障OVS之間轉(zhuǎn)發(fā)數(shù)據(jù)的保密性和完整性。

2.2 SDN-DataSec數(shù)據(jù)安全處理過(guò)程

本文提出的數(shù)據(jù)安全處理過(guò)程機(jī)制，是對(duì)OpenFlow協(xié)議和OVS、控制器進(jìn)行深度優(yōu)化改進(jìn)后設(shè)計(jì)實(shí)現(xiàn)的。SDN-DataSec中控制器和OVS各模塊間的數(shù)據(jù)處理過(guò)程如圖2所示。

圖2 SDN-DataSec數(shù)據(jù)處理過(guò)程

OVS內(nèi)核層的Vport數(shù)據(jù)接收模塊負(fù)責(zé)接收網(wǎng)絡(luò)數(shù)據(jù)包，然后將數(shù)據(jù)發(fā)送至核心的Datapath轉(zhuǎn)發(fā)處理模塊，該模塊對(duì)數(shù)據(jù)包頭相應(yīng)元素進(jìn)行提取，將其與存儲(chǔ)在內(nèi)核的流表進(jìn)行匹配，如匹配不成功則使用Nelink通道上傳至OVS用戶層的數(shù)據(jù)處理模塊。若用戶層數(shù)據(jù)處理模塊也無(wú)相應(yīng)流表與之匹配，則通過(guò)OpenFlow消息處理模塊上報(bào)控制器，請(qǐng)求數(shù)據(jù)轉(zhuǎn)發(fā)流表?？刂破髦械娜职踩呗阅K可根據(jù)全局網(wǎng)絡(luò)安全需求生成并下發(fā)數(shù)據(jù)安全策略。OVS數(shù)據(jù)安全處理過(guò)程如下。

①數(shù)據(jù)安全策略接收和轉(zhuǎn)譯。

OpenFlow安全策略模塊主要承擔(dān)存儲(chǔ)、轉(zhuǎn)譯控制器下發(fā)的數(shù)據(jù)安全策略任務(wù)。OpenFlow協(xié)議是控制平面和數(shù)據(jù)平面之間的可編程接口，允許OVS接收控制器下發(fā)的控制信息。OVS內(nèi)的OpenFlow協(xié)議主要由執(zhí)行數(shù)據(jù)包查找和轉(zhuǎn)發(fā)任務(wù)的流表和組表組成。本文設(shè)計(jì)開(kāi)發(fā)的OpenFlow數(shù)據(jù)安全策略基于標(biāo)準(zhǔn)的OpenFlow協(xié)議，對(duì)其進(jìn)行了擴(kuò)展，添加新的安全策略執(zhí)行操作。

在OpenFlow安全策略當(dāng)中，將具體的每條策略定義為條件和動(dòng)作的組合，依據(jù)條件執(zhí)行相應(yīng)的安全動(dòng)作指令。在宏觀上，控制層維護(hù)了一個(gè)全局的安全策略庫(kù)，自動(dòng)地收集網(wǎng)絡(luò)內(nèi)受管理的數(shù)據(jù)轉(zhuǎn)發(fā)層設(shè)備信息，更新全局安全策略數(shù)據(jù)庫(kù)，再將安全策略通過(guò)OpenFlow下發(fā)到數(shù)據(jù)轉(zhuǎn)發(fā)設(shè)備當(dāng)中。轉(zhuǎn)發(fā)設(shè)備OVS內(nèi)的OpenFlow安全策略模塊接收到OpenFlow下發(fā)的安全策略后，將其轉(zhuǎn)譯為OVS本地安全策略邏輯，再發(fā)送至安全策略匹配模塊。

本文的SDN安全策略下發(fā)過(guò)程具有較高的兼容性?？刂破麽槍?duì)數(shù)據(jù)平面現(xiàn)有的網(wǎng)絡(luò)情況制定安全策略并通過(guò)OpenFlow發(fā)送至相應(yīng)的OVS,同時(shí)控制器與OVS也使用OpenFlow正常交互，下發(fā)標(biāo)準(zhǔn)的流表，可及時(shí)適應(yīng)網(wǎng)絡(luò)拓?fù)渥兓诒Ａ袅遂`活性的同時(shí)也提高了控制器對(duì)OVS的全局安全管控能力，降低了網(wǎng)絡(luò)管理的復(fù)雜程度。

②安全策略匹配。

安全策略匹配模塊主要負(fù)責(zé)接收轉(zhuǎn)譯后的安全策略以及由用戶層數(shù)據(jù)處理模塊發(fā)來(lái)的未匹配數(shù)據(jù)包。將接收的數(shù)據(jù)包與安全策略匹配，若匹配失敗則將其發(fā)回用戶層數(shù)據(jù)處理模塊；若匹配成功，則將相應(yīng)的數(shù)據(jù)包及匹配成功的安全策略發(fā)送至數(shù)據(jù)安全分析模塊。

③深度解析數(shù)據(jù)包。

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

數(shù)據(jù)安全分析模塊接收到安全策略及匹配成功的數(shù)據(jù)包后，對(duì)數(shù)據(jù)包進(jìn)行深度解析。根據(jù)安全策略執(zhí)行不同的安全操作，可以解析包頭的各項(xiàng)關(guān)鍵信息，同時(shí)也可解析提取出Payload凈載信息。在成功解析獲取數(shù)據(jù)信息后，數(shù)據(jù)安全分析模塊將解析的數(shù)據(jù)信息發(fā)送至數(shù)據(jù)加解密模塊。

④數(shù)據(jù)加解密。

OVS在對(duì)數(shù)據(jù)進(jìn)行轉(zhuǎn)發(fā)時(shí)完全沒(méi)有對(duì)其所傳輸?shù)拿舾行畔⑦M(jìn)行安全處理，這使得信息在數(shù)據(jù)轉(zhuǎn)發(fā)平面?zhèn)鬏敍](méi)有任何安全防護(hù)。本文將密碼算法加入到OVS中，開(kāi)發(fā)實(shí)現(xiàn)數(shù)據(jù)加解密模塊。

數(shù)據(jù)加解密模塊接收到數(shù)據(jù)安全分析模塊發(fā)來(lái)的數(shù)據(jù)信息后，將其進(jìn)行加(解)密處理，并將加(解)密處理的密(明)文發(fā)送至包重構(gòu)模塊。

⑤數(shù)據(jù)包重構(gòu)。

傳統(tǒng)OVS設(shè)備中已含有包重構(gòu)模塊，但其功能并不能滿足數(shù)據(jù)安全處理需求。本文對(duì)該模塊進(jìn)行重新設(shè)計(jì)，使其具備了對(duì)凈載信息進(jìn)行包重構(gòu)的功能。

包重構(gòu)模塊接收到加解密模塊發(fā)來(lái)的密(明)文后，從數(shù)據(jù)安全分析模塊獲取密數(shù)據(jù)對(duì)應(yīng)的數(shù)據(jù)包頭信息，將密(明)文進(jìn)行包重構(gòu)操作。

⑥數(shù)據(jù)轉(zhuǎn)發(fā)。

包重構(gòu)模塊將重構(gòu)處理后的數(shù)據(jù)包發(fā)回用戶層數(shù)據(jù)處理模塊，數(shù)據(jù)安全處理過(guò)程結(jié)束，數(shù)據(jù)包進(jìn)入OVS正常工作流程，OVS可對(duì)其進(jìn)行相應(yīng)的轉(zhuǎn)發(fā)操作。

3 SDN數(shù)據(jù)安全處理機(jī)制關(guān)鍵模塊實(shí)現(xiàn)

本文選擇Ryu[18]作為控制器，虛擬交換機(jī)OVS作為數(shù)據(jù)轉(zhuǎn)發(fā)設(shè)備，本文所提出的數(shù)據(jù)安全處理機(jī)制主要工作和創(chuàng)新點(diǎn)聚焦于安全策略匹配模塊、數(shù)據(jù)加解密模塊、數(shù)據(jù)安全分析模塊、包重構(gòu)模塊等多個(gè)模塊的開(kāi)發(fā)實(shí)現(xiàn)，OpenFlow協(xié)議的擴(kuò)展及數(shù)據(jù)安全策略的匹配過(guò)程和數(shù)據(jù)安全處理的完整流程的設(shè)計(jì)。下面以涉及數(shù)據(jù)加解密的關(guān)鍵模塊為例體現(xiàn)本文機(jī)制的創(chuàng)新性和主要工作內(nèi)容，介紹OVS數(shù)據(jù)安全處理關(guān)鍵技術(shù)的實(shí)現(xiàn)以及對(duì)OpenFlow協(xié)議的擴(kuò)展方法。

3.1 OVS數(shù)據(jù)加解密

OVS的數(shù)據(jù)處理分別在內(nèi)核和用戶兩個(gè)空間進(jìn)行，本文開(kāi)發(fā)的數(shù)據(jù)加解密模塊在用戶層進(jìn)行編譯執(zhí)行，該模塊主要負(fù)責(zé)對(duì)從數(shù)據(jù)包中提取的數(shù)據(jù)信息或關(guān)鍵流表項(xiàng)信息進(jìn)行加解密處理。用戶層與內(nèi)核層數(shù)據(jù)處理流程如圖3所示。

圖3 用戶層與內(nèi)核層數(shù)據(jù)處理流程

在數(shù)據(jù)包到達(dá)OVS端口時(shí)，數(shù)據(jù)包與內(nèi)核空間中存在的流表進(jìn)行匹配。如果匹配成功，則執(zhí)行相應(yīng)的動(dòng)作(Action)對(duì)數(shù)據(jù)包進(jìn)行處理；否則，使用Netlink套接字將數(shù)據(jù)包發(fā)送到用戶空間進(jìn)行OpenFlow流表查找。如果能夠與用戶空間維護(hù)的流表匹配，則進(jìn)行相應(yīng)的處理。如果沒(méi)有找到匹配項(xiàng)，則將數(shù)據(jù)包發(fā)送到控制器。數(shù)據(jù)加解密模塊的具體函數(shù)處理流程如圖4所示。

由于OVS的Datapath模塊(數(shù)據(jù)路徑)是數(shù)據(jù)的“必經(jīng)之路”[19]，本文對(duì)該模塊進(jìn)行了深入研究，添加了自定義的加解密動(dòng)作指令及動(dòng)作執(zhí)行邏輯。以下是在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是新添加的執(zhí)行動(dòng)作來(lái)支持加密和解密功能。同時(shí)為了支持新的動(dòng)作，還需完成適當(dāng)?shù)慕Y(jié)構(gòu)定義，如struct ovs action sdn_encrypt等。

圖4 數(shù)據(jù)加解密函數(shù)處理流程

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

#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")

以上完成了數(shù)據(jù)加解密動(dòng)作指令A(yù)ction的添加。為了能夠在OVS中執(zhí)行具體的加解密操作，必須添加執(zhí)行加解密的邏輯函數(shù)，需對(duì)Ofp-action模塊及Ofproto模塊進(jìn)行適當(dāng)?shù)臄U(kuò)展，使其兼容新添加的動(dòng)作指令。不僅如此，為了使添加的動(dòng)作能夠被OVS提取和搜索/匹配流表項(xiàng)，還需對(duì)數(shù)據(jù)庫(kù)模塊目錄中的流表項(xiàng)模塊、篩選匹配模塊進(jìn)行擴(kuò)展改造。

3.2 OpenFlow協(xié)議擴(kuò)展

通過(guò)對(duì)OpenFlow協(xié)議的匹配項(xiàng)和動(dòng)作擴(kuò)展，添加OpenFlow安全策略模塊，可使控制器能夠根據(jù)安全策略生成數(shù)據(jù)安全處理策略，并將安全策略下發(fā)到OVS中，增強(qiáng)了SDN網(wǎng)絡(luò)應(yīng)對(duì)安全問(wèn)題的處理能力。

新添加的基于OpenFlow的安全策略模塊處于OVS的數(shù)據(jù)層面。一方面OpenFlow安全策略模塊可以不完全依賴控制器而是在數(shù)據(jù)層面直接對(duì)數(shù)據(jù)進(jìn)行相應(yīng)處理；另一方面OVS中的OpenFlow安全策略模塊符合OpenFlow API調(diào)用標(biāo)準(zhǔn)，控制器可以對(duì)其進(jìn)行靈活調(diào)用以便與控制器中的全局安全策略模塊交互。不僅如此，通過(guò)擴(kuò)展OpenFlow協(xié)議添加的OpenFlow安全策略模塊所產(chǎn)生的流表和原有的OpenFlow流表規(guī)則標(biāo)準(zhǔn)相同，可以融入到原有的OpenFlow流表中，保證OpenFlow的流表一致性。

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

1)主動(dòng)式。即安全策略流表被提前寫(xiě)入OVS中，使用時(shí)OpenFlow安全策略模塊根據(jù)數(shù)據(jù)分析模塊解析已存在的安全策略進(jìn)行相應(yīng)處理。

2)被動(dòng)式。由控制器通過(guò)Packet_out報(bào)文將控制器全局安全策略模塊產(chǎn)生的安全策略流表下發(fā)至各OVS。

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

在被動(dòng)式網(wǎng)絡(luò)中，若下發(fā)的一條安全策略與OVS中目前使用的所有安全策略都不匹配或有沖突，則OVS將該數(shù)據(jù)信息解析封裝為Packet_in報(bào)文中并上報(bào)給控制器?？刂破魇盏綀?bào)文后，利用已掌握的全局網(wǎng)絡(luò)情況再次根據(jù)全局安全解析模塊決定丟棄或者對(duì)數(shù)據(jù)包進(jìn)行其他處理，并將更新后的安全策略下發(fā)給OVS。OVS收到新的安全策略后，OpenFlow安全策略模塊自動(dòng)更新流表，之后再次處理該類型的數(shù)據(jù)包時(shí)，會(huì)有相應(yīng)的流表與其匹配。

為了保證OVS的OpenFlow安全策略模塊可以與控制器正常使用OpenFlow協(xié)議進(jìn)行交互，添加的新動(dòng)作應(yīng)與OVS支持的所有OpenFlow協(xié)議版本兼容。

3.3 加解密處理粒度分析

在目前OVS的流表使用中，已不僅是單純的精確匹配了，而是一種精確匹配+帶掩碼匹配合并在一起的方式。該方式的目的是為了減少Datapath里精確流表的條目數(shù)，將部分模糊匹配下放到內(nèi)核態(tài)處理，以減少每次因?yàn)椴煌陌贿f送時(shí)都要Upcall到用戶空間的時(shí)間，借此提高效率，因此本文在添加加解密操作后，根據(jù)不同數(shù)據(jù)包類型，在開(kāi)發(fā)實(shí)現(xiàn)的數(shù)據(jù)安全分析模塊以及安全策略模塊基礎(chǔ)上，優(yōu)化加解密操作，細(xì)化加解密操作粒度，提高處理效率，減少處理時(shí)間。根據(jù)控制器下發(fā)的安全策略，加解密處理基本操作粒度如表1所示。

每條策略定義為條件和動(dòng)作的組合，依據(jù)由基本條件字段、細(xì)粒度條件字段組成的條件執(zhí)行相應(yīng)的安全動(dòng)作指令?；緱l件字段規(guī)定本條策略的生存時(shí)長(zhǎng)，處理數(shù)據(jù)包數(shù)量，具體包括生效時(shí)間Duration_sec、所屬表項(xiàng)Table_id、優(yōu)先級(jí)Priority、處理的數(shù)據(jù)包數(shù)、空閑超時(shí)時(shí)間Idle_timeout等，超過(guò)設(shè)置的空閑超時(shí)時(shí)間后該策略將被自動(dòng)刪除，空閑超時(shí)時(shí)間設(shè)置為0表示該策略永不過(guò)期，從而保證策略實(shí)時(shí)更新，實(shí)時(shí)有效。細(xì)粒度條件字段包括輸入端口號(hào)In_port、源/目的MAC地址Dl_src/Dl_dst、源/目的IP地址Nw_src/Nw_dst、數(shù)據(jù)包類型Dl_type、網(wǎng)絡(luò)層協(xié)議類型Nw_proto等。

表1 基本操作粒度

一條策略需由以上條件輔以執(zhí)行動(dòng)作組成，當(dāng)數(shù)據(jù)包進(jìn)入安全策略匹配模塊時(shí)，即根據(jù)細(xì)粒度條件對(duì)數(shù)據(jù)包進(jìn)行篩選：

1)當(dāng)多個(gè)細(xì)粒度條件均滿足時(shí)，即將安全策略與匹配成功的數(shù)據(jù)包一并發(fā)給數(shù)據(jù)安全模塊。

2)當(dāng)多個(gè)細(xì)粒度條件只滿足其中幾項(xiàng)時(shí)，即查看是否匹配成功表1中帶(*)條件字段，若匹配成功即交由數(shù)據(jù)安全模塊處理。

3)若未匹配成功，則將數(shù)據(jù)返回用戶層數(shù)據(jù)處理模塊進(jìn)行后續(xù)轉(zhuǎn)發(fā)等操作。為了保證OVS的OpenFlow安全策略模塊可以與控制器正常使用OpenFlow協(xié)議進(jìn)行交互，添加的新動(dòng)作應(yīng)與OVS支持的所有OpenFlow協(xié)議版本兼容。

4 測(cè)試與結(jié)果分析

4.1 測(cè)試環(huán)境

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

測(cè)試主機(jī)選用Ubuntu15.10系統(tǒng)，2.6.0版本OVS，4.13版本Ryu，測(cè)試拓?fù)淙鐖D6所示。

圖6 測(cè)試拓?fù)浣Y(jié)構(gòu)

4.2 有效性測(cè)試

本次測(cè)試OVS1和OVS2傳輸Host1、Host2通信數(shù)據(jù)時(shí)是否可以針對(duì)下發(fā)的安全策略對(duì)敏感數(shù)據(jù)進(jìn)行加解密操作。為方便驗(yàn)證，本次測(cè)試中OVS使用基本的異或算法進(jìn)行加解密操作。

1)Ryu控制器下發(fā)安全策略：OVS1對(duì)Host1發(fā)往Host2的UDP數(shù)據(jù)包進(jìn)行加密操作，同時(shí)OVS2不作解密操作，直接轉(zhuǎn)發(fā)至Host2。

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

圖7 Host1發(fā)送數(shù)據(jù)抓取

Fig. 7 Data crawl sent by Host1

使用抓包工具在Host2上抓取來(lái)自Host1的UDP數(shù)據(jù)包，抓取的數(shù)據(jù)包如圖8所示，Besti已被OVS1完整地解析獲取并使用密碼算法加密成功，重構(gòu)數(shù)據(jù)包后再次發(fā)送出去。

圖8 Host2接收數(shù)據(jù)抓取

Fig. 8 Data crawl received by Host2

2)Ryu控制器下發(fā)安全策略：OVS1對(duì)Host1發(fā)往Host2的UDP數(shù)據(jù)包進(jìn)行加密操作，同時(shí)OVS2對(duì)Host1發(fā)往Host2的UDP數(shù)據(jù)包進(jìn)行解密操作，處理后轉(zhuǎn)發(fā)至Host2。

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

圖9 加密策略執(zhí)行

Fig. 9 Encryption strategy implementation

圖10 解密策略執(zhí)行

Fig. 10 Decryption strategy implementation

4.3 性能測(cè)試

1)OVS1、OVS2均執(zhí)行基本的OUTPUT(轉(zhuǎn)發(fā))動(dòng)作，OVS1執(zhí)行其自帶的更改VLAN的PUSH VLAN操作，OVS2執(zhí)行POP VLAN動(dòng)作；在OVS1、OVS2處分別執(zhí)行開(kāi)發(fā)的加解密動(dòng)作處理，然后(如圖11所示)統(tǒng)計(jì)對(duì)比相同數(shù)量的數(shù)據(jù)包所產(chǎn)生的時(shí)延情況。本次測(cè)試通過(guò)發(fā)送大量的相同內(nèi)容數(shù)據(jù)包測(cè)試不同動(dòng)作產(chǎn)生的時(shí)延情況。

圖11 3種執(zhí)行操作的時(shí)延對(duì)比

由圖11可知，當(dāng)數(shù)據(jù)包發(fā)送數(shù)量為200 000時(shí)，時(shí)延基本一致。在發(fā)送量為400 000數(shù)據(jù)包以后，時(shí)延開(kāi)始變大并且三種動(dòng)作的時(shí)延差距趨于明顯。本文加密動(dòng)作所產(chǎn)生的時(shí)延雖略高于基本的轉(zhuǎn)發(fā)動(dòng)作，但與對(duì)數(shù)據(jù)包進(jìn)行修改處理的PUSH VLAN+POP VLAN時(shí)延相近，說(shuō)明該功能不會(huì)對(duì)正常的數(shù)據(jù)交換造成較大影響。

2)OVS1、OVS2均執(zhí)行基本的OUTPUT(轉(zhuǎn)發(fā))動(dòng)作；在OVS1、OVS2處分別執(zhí)行開(kāi)發(fā)的加解密動(dòng)作處理，并(如圖12所示)統(tǒng)計(jì)和對(duì)比當(dāng)不同數(shù)據(jù)包大小時(shí)，加解密動(dòng)作和轉(zhuǎn)發(fā)動(dòng)作的吞吐量情況。

圖12 兩種操作的吞吐量對(duì)比

如圖12所示，加解密動(dòng)作的吞吐量低于OVS的基本動(dòng)作(轉(zhuǎn)發(fā))，但差距不影響數(shù)據(jù)的正常傳輸。

3)OVS1、OVS2分別針對(duì)不同類型的數(shù)據(jù)包(TCP、UDP、IP、MAC)執(zhí)行轉(zhuǎn)發(fā)處理和加解密處理，統(tǒng)計(jì)并對(duì)比CPU使用情況，如圖13所示。注：本次測(cè)試中相同類型的數(shù)據(jù)包大小內(nèi)容均相同。

圖13 兩種操作處理不同類型數(shù)據(jù)包的CPU使用率對(duì)比

如圖13所示，可知正常轉(zhuǎn)發(fā)動(dòng)作因未對(duì)數(shù)據(jù)進(jìn)行處理即CPU使用率低，始終低于10%；加解密操作因處理的數(shù)據(jù)包類型不同，其CPU使用率在45%～60%浮動(dòng)，CPU使用率高，但仍可正常傳輸數(shù)據(jù)。

綜合以上測(cè)試結(jié)果，本文設(shè)計(jì)并實(shí)現(xiàn)數(shù)據(jù)安全處理機(jī)制能夠有效地對(duì)數(shù)據(jù)進(jìn)行加解密操作，并且不會(huì)對(duì)正常的數(shù)據(jù)傳輸造成較大影響。

5 結(jié)語(yǔ)

當(dāng)下軟件定義網(wǎng)絡(luò)對(duì)數(shù)據(jù)的轉(zhuǎn)發(fā)均處于“明態(tài)”傳輸模式，網(wǎng)絡(luò)架構(gòu)缺乏安全策略，數(shù)據(jù)信息安全得不到保證，本文針對(duì)軟件定義網(wǎng)絡(luò)中的數(shù)據(jù)泄露問(wèn)題，設(shè)計(jì)實(shí)現(xiàn)了SDN數(shù)據(jù)安全處理平臺(tái)。通過(guò)對(duì)控制器和OVS的多個(gè)功能模塊的開(kāi)發(fā)實(shí)現(xiàn)，完成了本平臺(tái)的數(shù)據(jù)安全策略細(xì)粒度匹配和數(shù)據(jù)安全處理全過(guò)程。最后，通過(guò)有效性和性能開(kāi)銷測(cè)試，結(jié)果表明本文提出的數(shù)據(jù)安全處理機(jī)制能夠準(zhǔn)確、有效地對(duì)數(shù)據(jù)進(jìn)行加解密處理，時(shí)延和吞吐量數(shù)據(jù)處于正常水平但CPU使用率較高，負(fù)載較大。

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