陳浩宇，鄒德清，金海

面向SDN/NFV環(huán)境的網(wǎng)絡(luò)功能策略驗(yàn)證

陳浩宇1,2,3，鄒德清1,2,4，金海1,2,3

（1.大數(shù)據(jù)技術(shù)與系統(tǒng)國(guó)家地方聯(lián)合工程研究中心，華中科技大學(xué)計(jì)算機(jī)學(xué)院，湖北 武漢 430074；2. 服務(wù)計(jì)算技術(shù)與系統(tǒng)教育部重點(diǎn)實(shí)驗(yàn)室，華中科技大學(xué)計(jì)算機(jī)學(xué)院，湖北 武漢 430074；3. 集群與網(wǎng)格計(jì)算湖北省重點(diǎn)實(shí)驗(yàn)室，華中科技大學(xué)計(jì)算機(jī)學(xué)院，湖北 武漢 430074；4. 大數(shù)據(jù)安全湖北省工程研究中心，華中科技大學(xué)網(wǎng)絡(luò)空間安全學(xué)院，湖北 武漢 430074）

SDN與NFV技術(shù)帶來了網(wǎng)絡(luò)管理的靈活性與便捷性，但SDN的動(dòng)態(tài)轉(zhuǎn)發(fā)策略可能導(dǎo)致網(wǎng)絡(luò)功能策略失效，同時(shí)不同網(wǎng)絡(luò)功能的策略可能互相影響，引起沖突問題。為了在基于SDN/NFV的云網(wǎng)絡(luò)中對(duì)網(wǎng)絡(luò)功能的策略進(jìn)行驗(yàn)證，分析了網(wǎng)絡(luò)功能與SDN設(shè)備之間、跨網(wǎng)絡(luò)功能之間的策略沖突，建立了統(tǒng)一策略表達(dá)進(jìn)行策略解析，設(shè)計(jì)策略驗(yàn)證方案、框架并進(jìn)行原型實(shí)現(xiàn)，檢驗(yàn)不同場(chǎng)景下的虛擬網(wǎng)絡(luò)功能策略的正確性，并與現(xiàn)有策略沖突驗(yàn)證方案對(duì)比，用實(shí)驗(yàn)進(jìn)行了有效性與性能分析。

策略驗(yàn)證；云網(wǎng)絡(luò)；軟件定義網(wǎng)絡(luò)；網(wǎng)絡(luò)功能虛擬化

1 引言

現(xiàn)代網(wǎng)絡(luò)技術(shù)正朝虛擬化的方向快速發(fā)展。軟件定義網(wǎng)絡(luò)（SDN，software-defined network）[1-2]實(shí)現(xiàn)了網(wǎng)絡(luò)轉(zhuǎn)發(fā)設(shè)備的虛擬化，通過將傳統(tǒng)硬件交換機(jī)的控制層與數(shù)據(jù)層分離，以集中化、可編程的方式部署并執(zhí)行轉(zhuǎn)發(fā)控制邏輯。網(wǎng)絡(luò)功能虛擬化（NFV，network function virtualization）[3]技術(shù)將傳統(tǒng)的基于硬件的防火墻、入侵檢測(cè)/防御系統(tǒng)（IDS/IPS，intrusion detection/prevention system）、流量監(jiān)控器等網(wǎng)絡(luò)設(shè)備虛擬化，以軟件的形式運(yùn)行在通用硬件（如x86架構(gòu)的服務(wù)器）上，從而使管理員能夠?qū)崿F(xiàn)動(dòng)態(tài)的網(wǎng)絡(luò)服務(wù)按需調(diào)配。SDN和NFV技術(shù)得到了廣泛認(rèn)可，并在實(shí)際的生產(chǎn)環(huán)境中得到了應(yīng)用，如將SDN運(yùn)用在數(shù)據(jù)中心[4]，將SDN和NFV結(jié)合運(yùn)用于網(wǎng)絡(luò)切片等[5-6]。

然而，SDN和NFV技術(shù)為網(wǎng)絡(luò)管理帶來靈活性與便捷性的同時(shí)，基于SDN/NFV的網(wǎng)絡(luò)所具有的動(dòng)態(tài)性為策略驗(yàn)證帶來了新的挑戰(zhàn)。尤其在云環(huán)境中，SDN使云網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)能夠隨時(shí)改變，SDN交換機(jī)中的網(wǎng)絡(luò)轉(zhuǎn)發(fā)規(guī)則可以根據(jù)用戶需求進(jìn)行動(dòng)態(tài)調(diào)整[5]；NFV支持虛擬網(wǎng)絡(luò)功能實(shí)例，如軟件防火墻、軟件IDS等，根據(jù)業(yè)務(wù)需求，動(dòng)態(tài)地生成并部署在網(wǎng)絡(luò)中任意位置[7]。這兩個(gè)新特性給網(wǎng)絡(luò)中的策略驗(yàn)證帶來了兩方面新的挑戰(zhàn)。一方面，基于SDN中轉(zhuǎn)發(fā)策略處于動(dòng)態(tài)更新的狀態(tài)，網(wǎng)絡(luò)流量路徑可能在更新轉(zhuǎn)發(fā)策略后，繞過原先布置的網(wǎng)絡(luò)功能，從而導(dǎo)致網(wǎng)絡(luò)功能中的策略失效，即SDN與網(wǎng)絡(luò)功能的策略沖突；另一方面，不同于傳統(tǒng)硬件網(wǎng)絡(luò)功能部署在固定的位置上，NFV能夠在網(wǎng)絡(luò)拓?fù)淙我馕恢秒S時(shí)部署新的網(wǎng)絡(luò)功能實(shí)例，并且不同類型的網(wǎng)絡(luò)功能（如同時(shí)存在的網(wǎng)絡(luò)代理、防火墻、IDS等）之間可能導(dǎo)致策略的失效，即跨網(wǎng)絡(luò)功能的策略沖突。

為了解決基于SDN/NFV中的策略驗(yàn)證問題，本文設(shè)計(jì)了適用的動(dòng)態(tài)策略驗(yàn)證方案，對(duì)基于網(wǎng)絡(luò)功能策略中網(wǎng)絡(luò)數(shù)據(jù)包頭部匹配域以及動(dòng)作域的驗(yàn)證方案進(jìn)行擴(kuò)展，同時(shí)在SDN架構(gòu)中研究了動(dòng)態(tài)轉(zhuǎn)發(fā)規(guī)則更新可能引起的策略沖突問題以及驗(yàn)證方法，并進(jìn)一步研究了不同類型網(wǎng)絡(luò)功能自身行為可能引起的策略沖突。此外，基于SDN架構(gòu)，設(shè)計(jì)了專用的跨網(wǎng)絡(luò)功能的策略驗(yàn)證框架，并進(jìn)行了原型實(shí)現(xiàn)。在實(shí)驗(yàn)方面，基于SDN控制器（RYU）、網(wǎng)絡(luò)代理（squid）、防火墻（iptables）以及入侵檢測(cè)/防御系統(tǒng)（Snort）等代表性的開源工程實(shí)現(xiàn)原型系統(tǒng)并進(jìn)行了網(wǎng)絡(luò)功能的策略驗(yàn)證，證明了方案的有效性與執(zhí)行效率。

2 國(guó)內(nèi)外研究現(xiàn)狀

已有大量工作針對(duì)傳統(tǒng)網(wǎng)絡(luò)[8]和SDN[9]中的轉(zhuǎn)發(fā)策略進(jìn)行了可達(dá)性和隔離性的驗(yàn)證，主要研究在網(wǎng)絡(luò)轉(zhuǎn)發(fā)過程中，交換機(jī)中的轉(zhuǎn)發(fā)策略是否會(huì)導(dǎo)致網(wǎng)絡(luò)中主機(jī)無法正常通信或引起非法通信。文獻(xiàn)[10-11]實(shí)現(xiàn)了轉(zhuǎn)發(fā)策略的實(shí)時(shí)驗(yàn)證，即針對(duì)輸入的策略進(jìn)行動(dòng)態(tài)、即時(shí)逐條驗(yàn)證。此外，有研究指出網(wǎng)絡(luò)中的網(wǎng)絡(luò)功能數(shù)量已堪比轉(zhuǎn)發(fā)設(shè)備[12]，因此針對(duì)網(wǎng)絡(luò)功能的策略驗(yàn)證必不可少[13]。常見工作有專門針對(duì)防火墻[14-16]的策略驗(yàn)證，保證單個(gè)或多個(gè)防火墻策略的有效性；或者對(duì)防火墻與IPS之間的策略沖突進(jìn)行檢測(cè)[17]；還有一些工作采用對(duì)網(wǎng)絡(luò)功能的建模[18,19]或生成測(cè)試流量[20]的方案對(duì)網(wǎng)絡(luò)功能中的策略進(jìn)行驗(yàn)證。這些針對(duì)網(wǎng)絡(luò)功能的策略驗(yàn)證主要進(jìn)行可達(dá)性和隔離性的驗(yàn)證，技術(shù)思路上主要基于策略中關(guān)于網(wǎng)絡(luò)數(shù)據(jù)包的頭部匹配域以及動(dòng)作域進(jìn)行建模，通過比較策略的匹配域是否重疊，并判斷重疊部分的動(dòng)作域是否沖突來進(jìn)行驗(yàn)證。

具體而言，表1總結(jié)了目前不同場(chǎng)景下代表性策略驗(yàn)證工具的可用性。其中Veriflow[11]和其改進(jìn)版本工具Delta-net[10]用于網(wǎng)絡(luò)轉(zhuǎn)發(fā)策略的驗(yàn)證，主要先將網(wǎng)絡(luò)轉(zhuǎn)發(fā)策略進(jìn)行原子化切割形成不同的域，再使用增量查找的方式快速驗(yàn)證實(shí)時(shí)改變的轉(zhuǎn)發(fā)策略；但由于它們只支持轉(zhuǎn)發(fā)策略，因此無法實(shí)現(xiàn)與網(wǎng)絡(luò)功能相關(guān)的策略驗(yàn)證。Symnet[9]則使用符號(hào)執(zhí)行的方案，依據(jù)生成的符號(hào)模型產(chǎn)生測(cè)試流量來驗(yàn)證網(wǎng)絡(luò)整體的可達(dá)性和隔離性，因此它能夠?qū)崿F(xiàn)SDN交換機(jī)與網(wǎng)絡(luò)功能之間的策略驗(yàn)證，但是由于無法理解網(wǎng)絡(luò)功能策略的語義，無法執(zhí)行跨網(wǎng)絡(luò)功能的驗(yàn)證。FAME[14]和VFW[15]均支持防火墻策略驗(yàn)證，包括單一防火墻和跨防火墻之間的策略驗(yàn)證，但是并不支持其他類型的網(wǎng)絡(luò)功能。同時(shí)，VFW面向SDN環(huán)境，可以實(shí)現(xiàn)SDN交換機(jī)與網(wǎng)絡(luò)功能的策略驗(yàn)證，但是僅支持防火墻這一種跨網(wǎng)絡(luò)功能策略驗(yàn)證。Plankton[21]面向協(xié)議進(jìn)行策略驗(yàn)證，從而能夠在支持轉(zhuǎn)發(fā)策略驗(yàn)證的同時(shí)，兼顧多種網(wǎng)絡(luò)功能的策略驗(yàn)證；但是由于其只理解網(wǎng)絡(luò)協(xié)議而不理解網(wǎng)絡(luò)功能的策略語義，無法解決跨網(wǎng)絡(luò)功能策略沖突。NetSMC[22]則專門針對(duì)有狀態(tài)的網(wǎng)絡(luò)功能進(jìn)行有狀態(tài)的策略驗(yàn)證，能夠?qū)崿F(xiàn)跨網(wǎng)絡(luò)功能的策略驗(yàn)證；然而由于其并未考慮SDN的動(dòng)態(tài)轉(zhuǎn)發(fā)環(huán)境，因此無法實(shí)現(xiàn)SDN交換機(jī)與網(wǎng)絡(luò)功能的策略驗(yàn)證。

表1 不同場(chǎng)景下代表性策略驗(yàn)證工具的可用性

注：● 表示支持，◎ 表示部分/單一支持，○ 表示不支持

3 SDN架構(gòu)及網(wǎng)絡(luò)功能策略

本節(jié)對(duì)相關(guān)背景知識(shí)進(jìn)行介紹，首先描述SDN架構(gòu)，接著介紹各類網(wǎng)絡(luò)功能的安全策略模型，最后介紹常見的策略沖突問題與解決辦法。

3.1 SDN網(wǎng)絡(luò)架構(gòu)

SDN的基本架構(gòu)如圖1所示，分為數(shù)據(jù)層、控制層和應(yīng)用層3個(gè)層次。在數(shù)據(jù)層中，SDN將傳統(tǒng)交換機(jī)中的控制邏輯剝離出來，只留下基本的轉(zhuǎn)發(fā)功能，即只基于流表flowtable進(jìn)行流量轉(zhuǎn)發(fā)的SDN交換機(jī)?？刂茖觿t由SDN控制器構(gòu)成，通過南向接口的通信協(xié)議與數(shù)據(jù)層的SDN交換機(jī)進(jìn)行通信，并通過控制器中北向接口的可調(diào)用函數(shù)入口支撐上層的SDN應(yīng)用。應(yīng)用層運(yùn)行著開發(fā)者的SDN應(yīng)用，可以獲取全局的網(wǎng)絡(luò)信息，進(jìn)行交換機(jī)的功能、轉(zhuǎn)發(fā)策略配置，以及接收并響應(yīng)來自控制層的事件、通知等消息。

圖1 SDN的基本架構(gòu)

Figure 1 Basic architecture of SDN

目前，流行的SDN控制器包括RYU、floodlight、OpenDayLight、ONOS等，最主流的南向接口即SDN的通信協(xié)議，為OpenFlow協(xié)議，而北向接口則依據(jù)控制器的具體實(shí)現(xiàn)，由控制器的開發(fā)人員根據(jù)需要進(jìn)行設(shè)計(jì)與定義。

3.2 防火墻策略模型

防火墻策略是一系列防火墻規(guī)則的集合。防火墻規(guī)則具有→的形式。其中，order表示規(guī)則的優(yōu)先順序，匹配數(shù)據(jù)報(bào)字段時(shí)將依照order的順序?qū)?shù)據(jù)報(bào)依次進(jìn)行匹配，第一次匹配成功的規(guī)則即為將要執(zhí)行的規(guī)則，其后的規(guī)則不再進(jìn)行匹配。predicate是對(duì)數(shù)據(jù)報(bào)字段的描述，它包括協(xié)議、源端口、目的端口、源IP地址、目的IP地址等，字段滿足謂詞predicate的數(shù)據(jù)包即與該條規(guī)則匹配成功。action表示對(duì)滿足謂詞predicate的數(shù)據(jù)包進(jìn)行的具體操作，包括兩種操作：deny（丟棄數(shù)據(jù)包）與accept（允許通過數(shù)據(jù)包）。

防火墻檢測(cè)的數(shù)據(jù)包具有報(bào)頭，它是表示數(shù)據(jù)包中可尋址元素的一系列字段集合，同時(shí)它是與防火墻規(guī)則進(jìn)行匹配時(shí)要考察的字段，如式(1)所示。

一條過濾規(guī)則的過濾字段?也是一系列字段的集合，如式(2)所示。

其中，表示該條規(guī)則在防火墻規(guī)則集合中的匹配優(yōu)先度，當(dāng)一個(gè)數(shù)據(jù)包到達(dá)時(shí)，將依照自上而下的順序?qū)?shù)據(jù)包進(jìn)行匹配，匹配成功則執(zhí)行該條規(guī)則，否則將繼續(xù)匹配直到匹配成功或所有規(guī)則檢查完畢。action字段表示對(duì)數(shù)據(jù)包的操作。?為規(guī)則的過濾字段，用來與報(bào)頭進(jìn)行匹配，用如下五元組表示。

其中，protocol是協(xié)議類型，包括tcp、icmp等。src_ip是源IP地址，src_port是源端口，dest_ip是目的地址，dest_port是目的端口，與網(wǎng)絡(luò)流的五元組定義相同。

3.3 IDS/IPS策略模型

IDS/IPS策略包含一系列檢測(cè)規(guī)則，不同廠商/開發(fā)者的規(guī)則格式不一，但表達(dá)的內(nèi)容大同小異。以代表性的IDS/IPS——Snort為例，它采用了一種簡(jiǎn)單的輕量級(jí)語言來描述規(guī)則，一條完整規(guī)則的含義就是對(duì)具有特定特征的數(shù)據(jù)包進(jìn)行匹配并操作，允許通過或拒絕通過并發(fā)出警示。Snort規(guī)則的語義模型可以用如下二元組表示。

其中，packet表示滿足給定條件的所有數(shù)據(jù)包，這些條件包括源IP地址、目的IP地址、源端口、目的端口以及一些給定的特征值。action則表示對(duì)滿足給定條件數(shù)據(jù)包的具體操作，包括允許通過、拒絕通過、發(fā)送響應(yīng)報(bào)文3種，其中允許通過與拒絕通過統(tǒng)稱為控制動(dòng)作（control_ action），發(fā)送響應(yīng)報(bào)文稱為響應(yīng)動(dòng)作（resp_ action），響應(yīng)動(dòng)作是指Snort向發(fā)送數(shù)據(jù)的源地址發(fā)送響應(yīng)報(bào)文以告知它對(duì)數(shù)據(jù)的處理，而允許通過與拒絕通過又分別包括特定動(dòng)作，具體情況如下。

Control_action={permit,deny}

Permit={alert,log}

Deny={drop,reject,react,sdrop,resp}

Resp_action={resp,reject,react}

Snort規(guī)則分為如下兩部分：規(guī)則頭（rule_header）和規(guī)則選項(xiàng)（rule_option）。其中，規(guī)則頭包含五元組（對(duì)數(shù)據(jù)包采取的動(dòng)作，源IP地址，目的IP地址，源端口，目的端口）。而規(guī)則選項(xiàng)則包含數(shù)據(jù)包的具體特征，特征的種類很多，包括數(shù)據(jù)字段的值、icmp_seq等，而IDS/IPS的精髓在于其規(guī)則選項(xiàng)，通過設(shè)定規(guī)則選項(xiàng)篩選出具有特定特征的數(shù)據(jù)包，從而進(jìn)行進(jìn)一步處理。其模型如式(4)、式(5)所示。

以如下規(guī)則為例說明Snort規(guī)則。

Alert tcp 10.12.5.109 any->12.25.1.1 any (content:baf)

該規(guī)則含義為對(duì)于協(xié)議為tcp協(xié)議、從10.12.5.109任何端口發(fā)往12.25.1.1任何端口的包含字段“baf”的流量，采取告警措施。其中，alert表示動(dòng)作，tcp表示協(xié)議，any表示源端口/目的端口，10.12.5.109和12.25.1.1表示源地址目的地址，“->”表示流量方向，content：baf是規(guī)則選項(xiàng)，用于篩選包含baf字段的流量。

3.4 統(tǒng)一策略表示

觀察并總結(jié)防火墻、IDS/IPS的策略模型后，本文提出一種統(tǒng)一策略表示，用于描述不同類型虛擬網(wǎng)絡(luò)設(shè)備的策略并用于沖突檢測(cè)。從上文的不同類型網(wǎng)絡(luò)功能的策略模型可知，網(wǎng)絡(luò)功能甚至網(wǎng)絡(luò)交換機(jī)中的策略可以用四元組表示。

具體總結(jié)如表2所示，其中，priority字段通常為正整數(shù)；match字段則通常包含網(wǎng)絡(luò)流的五元組，或者根據(jù)策略表達(dá)的需求進(jìn)行擴(kuò)充；other字段則依據(jù)不同網(wǎng)絡(luò)功能的具體行為進(jìn)行定義，如IDS/IPS中定義的數(shù)據(jù)包c(diǎn)ontent匹配字符串或代理網(wǎng)關(guān)中定義緩存網(wǎng)站的域名字符串；action字段則通常用枚舉類型表示，指明動(dòng)作代碼。對(duì)于交換機(jī)和一般防火墻的策略，則包含priority、match和action域，按照策略順序，匹配數(shù)據(jù)包并進(jìn)行轉(zhuǎn)發(fā)或者訪問控制；而對(duì)于其他網(wǎng)絡(luò)功能（如Snort或Squid），還需要引入other字段以支撐更豐富的功能。本文基于統(tǒng)一策略表示對(duì)網(wǎng)絡(luò)中的轉(zhuǎn)發(fā)策略和網(wǎng)絡(luò)功能策略進(jìn)行解析，并進(jìn)行沖突檢測(cè)。

表2 統(tǒng)一策略表示域名

3.5 常見策略沖突分類

網(wǎng)絡(luò)設(shè)備中常常部署著大量不同的策略，這些策略雖然格式、語義等各不相同，但是互相之間易產(chǎn)生沖突，因此需對(duì)其進(jìn)行驗(yàn)證。策略沖突可能發(fā)生在單個(gè)設(shè)備內(nèi)部，也可能發(fā)生在多個(gè)設(shè)備之間。單設(shè)備中常見的策略沖突主要分為以下三類。

（1）互斥

每條策略都具有特定的作用域（如IP地址、端口號(hào)范圍），而不同策略的作用域可能有交叉重疊。如果兩條策略具有交叉的作用域，同時(shí)具有不同的行為（例如，防火墻的兩條具有IP域交叉的策略，一條為Allow，另一條為Deny），則會(huì)發(fā)生策略互斥沖突。

（2）冗余

兩條策略如果對(duì)相同的作用域制定了相同的動(dòng)作，則可以判定兩條策略發(fā)生了冗余沖突，需要對(duì)策略集進(jìn)行精簡(jiǎn)。

（3）覆蓋

一些訪問控制設(shè)備（如防火墻）中的策略往往具有優(yōu)先級(jí)，在成功匹配到一條策略后則不再匹配后續(xù)策略。如果具有高優(yōu)先級(jí)的策略作用域完全覆蓋了某一條具有低優(yōu)先級(jí)的策略，那么該低優(yōu)先級(jí)策略將永遠(yuǎn)無法被匹配到，此時(shí)發(fā)生策略覆蓋沖突。

多設(shè)備間的策略沖突可以看作單設(shè)備情形的擴(kuò)展，依據(jù)設(shè)備類型可以分為兩類。①同類設(shè)備策略沖突，即網(wǎng)絡(luò)中可能同時(shí)部署著多個(gè)同類型的設(shè)備，這些設(shè)備中的策略發(fā)生了與單設(shè)備中類似的沖突。在驗(yàn)證這類沖突時(shí)，需要從全局角度出發(fā)，再參照單設(shè)備中可能發(fā)生的策略沖突情形進(jìn)行驗(yàn)證。②異類設(shè)備策略沖突，即不同類型的設(shè)備中發(fā)生策略沖突。不同類型設(shè)備往往使用不同格式、語義和目的的策略，因此該類沖突最為復(fù)雜，需要對(duì)不同的策略語義進(jìn)行綜合考量，并找出潛在的策略沖突。

本文工作針對(duì)SDN/NFV網(wǎng)絡(luò)環(huán)境中的特有策略沖突場(chǎng)景提出驗(yàn)證方案，涉及的策略沖突屬于多設(shè)備中的異類設(shè)備策略沖突。雖然現(xiàn)有一些工作已經(jīng)針對(duì)各種各樣的策略沖突提出了驗(yàn)證方案，但在SDN/NFV這種特定上下文環(huán)境中仍包含特有的策略沖突場(chǎng)景亟待解決。

4 SDN/NFV中的策略沖突

本節(jié)用具體的案例對(duì)SDN/NFV中特有的SDN交換機(jī)與網(wǎng)絡(luò)功能之間以及跨網(wǎng)絡(luò)功能之間的策略沖突進(jìn)行場(chǎng)景介紹并分析原因。

4.1 SDN交換機(jī)與網(wǎng)絡(luò)功能的策略沖突

SDN中應(yīng)用最廣泛的協(xié)議是OpenFlow協(xié)議，用于OpenFlow交換機(jī)與控制器之間的通信。OpenFlow交換機(jī)基于流表中的流表項(xiàng)進(jìn)行轉(zhuǎn)發(fā)，而一條流表主要包含匹配域、統(tǒng)計(jì)域與動(dòng)作域3個(gè)域，如圖2所示。其中，匹配域用于匹配數(shù)據(jù)包頭，可以基于任意字段進(jìn)行匹配，如IP/MAC地址、入端口或者協(xié)議等；統(tǒng)計(jì)域則針對(duì)匹配域所表示的數(shù)據(jù)流記錄統(tǒng)計(jì)信息，包括該流表項(xiàng)匹配到的數(shù)據(jù)包個(gè)數(shù)等；動(dòng)作域則表示在OpenFlow交換機(jī)中對(duì)匹配到的數(shù)據(jù)包如何操作，如轉(zhuǎn)發(fā)到某端口、鏡像流量、廣播流量等。

圖2 OpenFlow交換機(jī)流表項(xiàng)示意

Figure 2 Illustration on an entry of flowtable in OpenFlow switches

在基于OpenFlow協(xié)議的SDN環(huán)境中，用戶根據(jù)自己的需求設(shè)計(jì)并編寫應(yīng)用，并將應(yīng)用運(yùn)行在控制器上；轉(zhuǎn)發(fā)策略由應(yīng)用生成，并調(diào)用控制器的配置接口以安裝到OpenFlow交換機(jī)中。雖然這種設(shè)定頗具靈活性，有利于自動(dòng)化的轉(zhuǎn)發(fā)策略生成與部署，但是帶來了網(wǎng)絡(luò)動(dòng)態(tài)性，在配置轉(zhuǎn)發(fā)策略時(shí)，很難綜合考慮到網(wǎng)絡(luò)功能的策略，從而引起沖突，如配置OpenFlow交換機(jī)的轉(zhuǎn)發(fā)策略時(shí)，可能會(huì)忽略網(wǎng)絡(luò)功能（如防火墻的策略），使交換機(jī)的功能滿足了需求，卻造成防火墻策略失效。

在基于SDN的云網(wǎng)絡(luò)中，內(nèi)部網(wǎng)絡(luò)的主機(jī)需要與外部的文件服務(wù)器進(jìn)行通信來獲取數(shù)據(jù)。假設(shè)在內(nèi)部網(wǎng)絡(luò)出入口的防火墻中定制了安全策略，允許文件服務(wù)器與主機(jī)X之間的通信，但是禁止文件服務(wù)器的數(shù)據(jù)發(fā)送給主機(jī)Y。SDN中的轉(zhuǎn)發(fā)策略是動(dòng)態(tài)下發(fā)的，由上層應(yīng)用安裝，因此可能出現(xiàn)如圖3所示的情形。①在S2交換機(jī)的流表中臨時(shí)安裝了一條規(guī)則，將入端口來自S1交換機(jī)的數(shù)據(jù)包進(jìn)行鏡像，同時(shí)轉(zhuǎn)發(fā)給S3交換機(jī)和主機(jī)X所在的端口。②同時(shí)在S3交換機(jī)的流表中臨時(shí)安裝了一條規(guī)則，將入端口來自S2交換機(jī)的流量轉(zhuǎn)發(fā)給主機(jī)Y所在的端口。當(dāng)文件服務(wù)器向主機(jī)X發(fā)送數(shù)據(jù)時(shí)，由于數(shù)據(jù)包經(jīng)由S1交換機(jī)轉(zhuǎn)發(fā)給了S2交換機(jī)，而S2交換機(jī)鏡像轉(zhuǎn)發(fā)給S3交換機(jī)的流量最終可以達(dá)到主機(jī)Y，結(jié)合源地址來看，從文件服務(wù)器發(fā)出的流量除了抵達(dá)主機(jī)X，還抵達(dá)了主機(jī)Y。雖然它們之間的數(shù)據(jù)傳輸不是直接而是間接進(jìn)行，但這依然繞過了防火墻策略，出現(xiàn)了策略失效的情況。該情況下，認(rèn)為防火墻規(guī)則與交換機(jī)之間產(chǎn)生了沖突。同理，將防火墻替換為IPS，依然會(huì)出現(xiàn)同樣的策略失效。

圖3 SDN交換機(jī)與防火墻策略沖突場(chǎng)景

Figure 3 The scenario of policy conflicts between SDN switches and firewalls

SDN交換機(jī)與網(wǎng)絡(luò)功能的策略沖突產(chǎn)生的原因?yàn)榻粨Q機(jī)中的轉(zhuǎn)發(fā)策略配置不當(dāng)，導(dǎo)致出現(xiàn)了不合理的轉(zhuǎn)發(fā)路徑，因此需要根據(jù)網(wǎng)絡(luò)功能中配置的策略，對(duì)比找出是否存在對(duì)應(yīng)的非法轉(zhuǎn)發(fā)路徑。

4.2 跨網(wǎng)絡(luò)功能策略的沖突

網(wǎng)絡(luò)中可能由于具體業(yè)務(wù)的需求同時(shí)存在多個(gè)功能不同的網(wǎng)絡(luò)功能，如云環(huán)境中為了優(yōu)化主機(jī)對(duì)外部網(wǎng)站的訪問，添加了可用于緩存的代理網(wǎng)關(guān)，并且在網(wǎng)絡(luò)出入口處部署了訪問控制設(shè)備。它們可能由于策略配置不當(dāng)出現(xiàn)沖突。

考慮如圖4所示的場(chǎng)景，在該場(chǎng)景中云網(wǎng)絡(luò)中運(yùn)行著兩個(gè)不同的網(wǎng)絡(luò)功能——代理網(wǎng)關(guān)和防火墻。云內(nèi)主機(jī)對(duì)外部網(wǎng)站的訪問均會(huì)經(jīng)過代理網(wǎng)關(guān)和防火墻處理。該場(chǎng)景中，在策略配置時(shí)，代理網(wǎng)關(guān)被配置為可以對(duì)任意網(wǎng)頁進(jìn)行緩存，從而加快主機(jī)重復(fù)訪問的速度，而防火墻則被配置為禁止主機(jī)2訪問ABC.com這個(gè)網(wǎng)站，其他主機(jī)對(duì)該網(wǎng)站的訪問則被放行。當(dāng)主機(jī)1首次訪問ABC.com時(shí)，防火墻放行了該主機(jī)的訪問，并且代理網(wǎng)關(guān)中自動(dòng)對(duì)該網(wǎng)站進(jìn)行了緩存以加快再次訪問的速度。然而，當(dāng)之后主機(jī)2試圖訪問ABC.com時(shí)，代理網(wǎng)關(guān)發(fā)現(xiàn)緩存中存在該網(wǎng)站后將會(huì)直接返回給主機(jī)2，因此主機(jī)2可以順利訪問到ABC.com的緩存版本。但是在防火墻策略中應(yīng)當(dāng)拒絕主機(jī)2對(duì)ABC.com的訪問，這就導(dǎo)致了防火墻策略的失效。

圖4 代理網(wǎng)關(guān)與防火墻策略沖突場(chǎng)景

Figure 4 The scenario of policy conflicts between the proxy and the firewall

跨網(wǎng)絡(luò)功能的策略沖突主要來自不同網(wǎng)絡(luò)功能對(duì)于同一個(gè)流或者會(huì)話的策略定義了沖突的動(dòng)作，如該場(chǎng)景中代理網(wǎng)關(guān)將ABC.com進(jìn)行緩存，發(fā)送給主機(jī)2，而防火墻則拒絕了ABC.com與主機(jī)2之間的通信。這兩個(gè)網(wǎng)絡(luò)功能的動(dòng)作產(chǎn)生了矛盾，造成了策略沖突。

5 策略驗(yàn)證

本節(jié)針對(duì)第4節(jié)中提出的兩種基于SDN/NFV云環(huán)境中特有的策略沖突場(chǎng)景適用的安全策略進(jìn)行驗(yàn)證。

5.1 SDN交換機(jī)與網(wǎng)絡(luò)功能策略驗(yàn)證

依據(jù)SDN交換機(jī)（即OpenFlow交換機(jī)）與防火墻策略沖突產(chǎn)生的場(chǎng)景與原因，提出沖突檢測(cè)算法，如算法1所示，尋找OpenFlow交換機(jī)與防火墻安全策略之間的沖突，即從一系列防火墻規(guī)則中尋找兩條規(guī)則，它們滿足如下約束條件。

（1）[].action== deny

（2）[j].action==accept

（3）[].src_ip==[].src_ip

算法1 OpenFlow交換機(jī)與防火墻策略驗(yàn)證算法

BEGIN

For i from 0 to rule_number in 防火墻：

do: 尋找規(guī)則[]，其動(dòng)作[].action == deny

for j from 0 to rule_number in 防火墻：

do: 尋找規(guī)則[]，其動(dòng)作[].action == accept

if ([].src_addr ==[].src_addr)：

for 交換機(jī)in 防火墻直連交換機(jī)集合：

if (findpath([].dest_ip,) ≥1&&

findpath([].dest_ip,)≥1)：

showpath([]);

showpath([]);

END

針對(duì)以上約束條件進(jìn)行說明。

（1）防火墻規(guī)則[].action動(dòng)作為deny，即本規(guī)則定義中的源地址與目的地址不能直接通信。

（2）防火墻規(guī)則[].action動(dòng)作為accept，即本規(guī)則定義中的源地址流出的流量能順利抵達(dá)目的地址。

（3）規(guī)則[]和規(guī)則[]的源IP地址src_ip相同，則意味著通信流量是從同一個(gè)源地址流出的。

（4）存在某個(gè)直接連接防火墻的OpenFlow交換機(jī)，同時(shí)滿足兩個(gè)條件：從源地址[].src_ip流出的流量能通過該交換機(jī)順利抵達(dá)規(guī)則[]的目的地址[].dest_ip，即findpath([].dest_ip,)≥1；從源地址[].src_ip流出的流量能通過該交換機(jī)順利抵達(dá)規(guī)則[]的目的地址[].dest_ip，即findpath([].dest_ip,)≥1。

此處規(guī)則[]為不允許，即從源地址[].src_ip發(fā)出，目的地址為[].dest_ip的流量不能通過防火墻。但由于從源地址[].src_ip =[].src_ip發(fā)出的目的地址為x[j].dest_ip的流量可以通過防火墻，并且存在OpenFlow交換機(jī)能夠使該流量經(jīng)過該交換機(jī)或其后某個(gè)交換機(jī)時(shí)發(fā)生分流，導(dǎo)致該流量的一部分流向目的地址[].dest_ip，這就間接導(dǎo)致源地址[].src_ip和目的地址[].dest_ip之間存在可行的流通路徑，違背了規(guī)則[]的定義。此時(shí)，即使防火墻的規(guī)則正確執(zhí)行，依然可能由于OpenFlow交換機(jī)的轉(zhuǎn)發(fā)策略配置不當(dāng)，使防火墻中定義為無法通信的兩端出現(xiàn)可通信路徑，造成策略失效，因此造成SDN交換機(jī)與防火墻策略沖突。策略驗(yàn)證的核心思路為先查找防火墻或IPS中每條動(dòng)作為拒絕的策略，對(duì)交換機(jī)轉(zhuǎn)發(fā)路徑建立樹狀模型，尋找是否有可達(dá)路徑，最終找出策略失效所在。算法中有兩個(gè)關(guān)鍵函數(shù)。

（1）findpath函數(shù)

該函數(shù)檢查所有直接連接防火墻的OpenFlow交換機(jī)，旨在找出從某個(gè)直接連接防火墻的OpenFlow交換機(jī)抵達(dá)目的地址的所有路徑，并將路徑存放在樹中，然后依據(jù)返回值路徑的條數(shù)判斷防火墻與交換機(jī)之間是否有沖突。函數(shù)使用兩個(gè)重要參數(shù)：①目的地址；②直連防火墻的OpenFlow交換機(jī)設(shè)備號(hào)。如果該OpenFlow交換機(jī)到該目的地址具有一條或一條以上路徑，返回路徑條數(shù)，否則返回0。

該函數(shù)在尋找路徑的同時(shí)對(duì)路徑樹進(jìn)行構(gòu)建，此處選擇構(gòu)建一棵前綴樹。構(gòu)建樹形數(shù)據(jù)結(jié)構(gòu)一方面是便于分析路徑，另一方面是為之后的打印路徑做鋪墊。因此，該函數(shù)主體包括兩部分：①尋找路徑，具體過程如算法2所示，算法主要使用遞歸的方式，對(duì)流表項(xiàng)的下一跳地址反復(fù)查詢，直至下一跳地址為目的地址時(shí)，遞歸結(jié)束。②構(gòu)建前綴樹，如何把下一跳OpenFlow交換機(jī)的流表創(chuàng)建一棵樹并將這棵樹映射到下一棵樹的地址。該過程由兩個(gè)步驟完成：其一是創(chuàng)建下一棵樹，給它分配存儲(chǔ)空間；其二是將下一跳OpenFlow交換機(jī)地址存入樹的數(shù)據(jù)結(jié)構(gòu)中。

算法2 尋找路徑算法

BEGIN

For each rule in OpenFlow交換機(jī)流表:

If (該流表項(xiàng)下一跳地址==目的地址）

return 1;

else

result = result + findpath（目的地址,該流表項(xiàng)下一跳設(shè)備號(hào)）;

return result;

END

（2）showpath函數(shù)

該函數(shù)的功能是打印某個(gè)OpenFlow交換機(jī)設(shè)備號(hào)及經(jīng)由該交換機(jī)后抵達(dá)目的地址的所有路徑上的設(shè)備號(hào)。當(dāng)findpath()函數(shù)返回值大于或等于1時(shí)，說明從直接連接防火墻的OpenFlow交換機(jī)到達(dá)目的地址的路徑存在，此時(shí)可以調(diào)用showpath()將findpath()構(gòu)建的樹中的所有路徑打印出來。函數(shù)包含兩個(gè)參數(shù)：①要打印的樹的根節(jié)點(diǎn)；②樹的深度，利用調(diào)整打印格式，決定交換機(jī)設(shè)備號(hào)的縮進(jìn)關(guān)系，以便查看路徑。

5.2 跨網(wǎng)絡(luò)功能策略驗(yàn)證

跨網(wǎng)絡(luò)功能的策略檢測(cè)相對(duì)簡(jiǎn)單，只需先找到匹配域相同的網(wǎng)絡(luò)功能策略，再分析并對(duì)比這些策略的動(dòng)作是否存在沖突，具體的驗(yàn)證流程如圖5所示，共包含5個(gè)步驟。

（1）策略解析。該步驟以網(wǎng)絡(luò)功能策略作為輸入，用統(tǒng)一策略表達(dá)對(duì)規(guī)則進(jìn)行解析，分解成priority、match、other和action域。

（2）對(duì)比match域。該步驟為了找出針對(duì)的流有重疊的規(guī)則，因?yàn)樗鼈兛赡軐?duì)同一條流采用不同的動(dòng)作。具體的提取算法可以采用已有工作的防火墻策略檢測(cè)算法[16]。

（3）提取action域。該步驟找出有重疊match域的策略的動(dòng)作域，通常防火墻或者IDS/IPS包含allow、deny、drop等。

（4）提取other域。該步驟是策略驗(yàn)證中容易忽略的部分，與網(wǎng)絡(luò)功能自身的功能相關(guān)。存在一些網(wǎng)絡(luò)功能的策略中并不直接定義action域（默認(rèn)allow），但是在other域中隱含動(dòng)作，如代理網(wǎng)關(guān)中存在存儲(chǔ)行為（cache），而NAT（network address translation）設(shè)備則可能存在包重寫行為（重新定義包頭）。

（5）交叉對(duì)比。對(duì)重疊策略中所提取出的action域和other域動(dòng)作進(jìn)行交叉對(duì)比，并輸出策略檢測(cè)報(bào)告，警告管理員是否存在沖突。

圖5 網(wǎng)絡(luò)功能策略驗(yàn)證流程

Figure 5 The flow of policy verification across network functions

該策略沖突的解決方案通常需要管理員根據(jù)實(shí)際情況進(jìn)行調(diào)整，即對(duì)于引起策略沖突的流量進(jìn)行人為決策。這是因?yàn)槭欠判羞€是阻止流量取決于實(shí)際網(wǎng)絡(luò)環(huán)境以及該流量的用途。

6 基于SDN的策略驗(yàn)證框架

基于上文分析的策略驗(yàn)證需求，本文提出了一種云環(huán)境中基于SDN的策略驗(yàn)證框架，如圖6所示。該框架以SDN轉(zhuǎn)發(fā)和網(wǎng)絡(luò)功能策略為輸入，包含策略檢測(cè)引擎、沖突報(bào)告器和策略安裝器3個(gè)部分，其中策略檢測(cè)引擎包含策略解析器、轉(zhuǎn)發(fā)策略檢測(cè)器和網(wǎng)絡(luò)功能檢測(cè)器3個(gè)子模塊；作為輸出，將策略沖突警告報(bào)告給網(wǎng)絡(luò)管理員，以及將合法網(wǎng)絡(luò)功能策略直接安裝到網(wǎng)絡(luò)功能中，或通過SDN控制器將合法轉(zhuǎn)發(fā)策略安裝到SDN交換機(jī)中。

圖6 基于SDN的策略驗(yàn)證框架

Figure 6 SDN-based policy verification framework

首先，SDN轉(zhuǎn)發(fā)策略（運(yùn)行在SDN交換機(jī)中）以及網(wǎng)絡(luò)功能策略（運(yùn)行在防火墻、IDS/IPS、代理等網(wǎng)絡(luò)功能中）作為策略檢測(cè)引擎的輸入。在策略檢測(cè)引擎中，每條策略先被策略解析器進(jìn)行解析，填充進(jìn)3.4節(jié)中定義的統(tǒng)一策略表示所對(duì)應(yīng)的數(shù)據(jù)結(jié)構(gòu)中。接著，策略解析器根據(jù)策略的類型，將結(jié)構(gòu)化的策略分別發(fā)送到轉(zhuǎn)發(fā)策略檢測(cè)器和網(wǎng)絡(luò)功能策略檢測(cè)器中進(jìn)行檢測(cè)。在轉(zhuǎn)發(fā)策略檢測(cè)器中，SDN轉(zhuǎn)發(fā)策略可以進(jìn)行網(wǎng)絡(luò)轉(zhuǎn)發(fā)的可達(dá)性或隔離性檢測(cè)，也可以對(duì)網(wǎng)絡(luò)功能策略進(jìn)行交叉檢測(cè)（即第5.1節(jié)中的檢測(cè)算法），保障SDN交換機(jī)中與網(wǎng)絡(luò)功能中的策略不沖突；在網(wǎng)絡(luò)功能策略檢測(cè)器中，網(wǎng)絡(luò)功能策略將會(huì)進(jìn)行交叉檢測(cè)（如第5.2節(jié)中的檢測(cè)流程），確保網(wǎng)絡(luò)功能中的策略不沖突。策略檢測(cè)引擎中的兩個(gè)策略檢測(cè)器會(huì)將結(jié)果輸出到?jīng)_突報(bào)告器中。沖突報(bào)告器策略檢測(cè)引擎中檢測(cè)到的策略沖突作為警告通知網(wǎng)絡(luò)管理員，并且將合法策略作為輸出發(fā)送給策略安裝器，然后策略安裝器通過SDN控制器安裝合法轉(zhuǎn)發(fā)策略，或直接將合法網(wǎng)絡(luò)功能策略安裝到網(wǎng)絡(luò)功能中。

在該框架的原型實(shí)現(xiàn)中，策略檢測(cè)引擎、沖突報(bào)告器、策略安裝器均以SDN應(yīng)用的形式運(yùn)行在SDN控制器中。本文選用基于Python語言的RYU控制器作為SDN控制器。其中，策略檢測(cè)引擎應(yīng)用包含3個(gè)類class，分別對(duì)應(yīng)策略解析器、轉(zhuǎn)發(fā)策略檢測(cè)器和網(wǎng)絡(luò)功能策略檢測(cè)器；沖突報(bào)告器應(yīng)用運(yùn)行時(shí)直接在終端輸出警告信息；策略安裝器則采用RYU控制器提供的基于OpenFlow協(xié)議的消息接口——flow_mod和add_flow安裝SDN轉(zhuǎn)發(fā)策略，并且直接利用socket通信調(diào)用網(wǎng)絡(luò)功能的遠(yuǎn)程配置接口進(jìn)行策略的安裝。

7 實(shí)驗(yàn)測(cè)試與分析

本文利用上述策略驗(yàn)證框架的原型實(shí)現(xiàn)，對(duì)有效性和性能進(jìn)行分析。實(shí)驗(yàn)環(huán)境由2臺(tái)運(yùn)行ubuntu 16.04操作系統(tǒng)的服務(wù)器組成，服務(wù)器的配置為英特爾至強(qiáng)Xeon E3-1230 v3 CPU，32 GB內(nèi)存，100Mbit/s網(wǎng)卡，250 GB Samsung EVO850 SSD+2 TB 西部數(shù)據(jù)硬盤。每臺(tái)服務(wù)器使用VMware Workstation 12.0運(yùn)行若干虛擬機(jī)，采用ubuntu 16.04操作系統(tǒng)，配置2 GB內(nèi)存、60 GB硬盤空間以及雙核雙線程的虛擬CPU。此外，SDN控制器選用RYU 4.2版本，虛擬交換機(jī)使用OpenvSwitch 2.5.0，運(yùn)行OpenFlow 1.3版本，并且支持開源iptables-v1.4.21、Snort-2.9.8.2的策略解析與驗(yàn)證。

圖7為實(shí)驗(yàn)測(cè)試的網(wǎng)絡(luò)拓?fù)渑c設(shè)備id。其中，主機(jī)7、15、16分別使用一個(gè)虛擬機(jī)，iptables運(yùn)行在一個(gè)虛擬機(jī)中，而用于模擬所有OpenFlow交換機(jī)的mininet則單獨(dú)運(yùn)行在另外一個(gè)虛擬機(jī)中。表3為OpenFlow交換機(jī)中的轉(zhuǎn)發(fā)策略。為了便于分析，此處只列出會(huì)引起沖突問題的策略，并且IP地址用主機(jī)id和交換機(jī)id表示。

圖7 實(shí)驗(yàn)拓?fù)?/p>

Figure 7 Topology of experiment settings

表3 交換機(jī)轉(zhuǎn)發(fā)規(guī)則

7.1 有效性測(cè)試

7.1.1 SDN交換機(jī)與網(wǎng)絡(luò)功能策略驗(yàn)證

SDN交換機(jī)與網(wǎng)絡(luò)功能策略的沖突驗(yàn)證。實(shí)驗(yàn)中，使用防火墻iptables作為網(wǎng)絡(luò)功能的代表進(jìn)行驗(yàn)證，與部署在網(wǎng)絡(luò)中的OpenFlow交換機(jī)一起進(jìn)行策略驗(yàn)證。其中iptables規(guī)則如表4所示。

SDN交換機(jī)與網(wǎng)絡(luò)功能策略檢測(cè)結(jié)果如圖8所示。防火墻規(guī)則2允許通過的流量間接抵達(dá)規(guī)則1的目的地址，此時(shí)防火墻規(guī)則與OpenFlow交換機(jī)之間產(chǎn)生了沖突。由打印序列可知，從源地址7到目的地址16的路徑有如下3種：①1-2-5-16；②1-2-16；③1-3-16。而從源地址7到目的地址15的路徑為1-2-15。將兩者的路徑進(jìn)行對(duì)比，可以發(fā)現(xiàn)1-2-5-16與1-2-15具有公共部分交換機(jī)1和交換機(jī)2，說明數(shù)據(jù)經(jīng)過這兩個(gè)交換機(jī)時(shí)如果發(fā)生流量分流，會(huì)導(dǎo)致部分流量流向另一個(gè)目的地址，而這是與防火墻安全策略相違背的，因?yàn)橐?guī)則2允許流量抵達(dá)地址15，規(guī)則1不允許流量抵達(dá)地址16，現(xiàn)在流向15的流量卻可能到達(dá)16，因此防火墻策略與OpenFlow交換機(jī)1、2之間產(chǎn)生了沖突。

表4 防火墻iptables規(guī)則（驗(yàn)證轉(zhuǎn)發(fā)策略）

圖8 SDN交換機(jī)與網(wǎng)絡(luò)功能策略檢測(cè)結(jié)果

Figure 8 Results of policy verification between SDN switches and network functions

7.1.2 跨網(wǎng)絡(luò)功能策略驗(yàn)證

對(duì)于跨網(wǎng)絡(luò)功能的策略沖突，實(shí)驗(yàn)中首先使用Snort和iptables進(jìn)行測(cè)試。其中，iptables使用表5中的規(guī)則，而Snort規(guī)則為

① alert tcp 10.12.5.109 any -> 12.25.1.1 any (content: baf)

② drop tcp 5.2.14.66 any -> 19.48.5.182 any (id:5)

③ reject tcp 31.73.244.5 any -> 6.1.53.29 any (id:7)

表5 防火墻規(guī)則（驗(yàn)證跨網(wǎng)絡(luò)功能策略）

圖9為跨網(wǎng)絡(luò)功能策略檢測(cè)結(jié)果。其中，Snort規(guī)則1與iptables規(guī)則1產(chǎn)生沖突，Snort允許通過的數(shù)據(jù)報(bào)被iptables策略拒絕；Snort規(guī)則2與iptables規(guī)則3產(chǎn)生沖突，iptables允許通過的數(shù)據(jù)報(bào)被Snort策略拒絕；Snort的規(guī)則3與iptables的規(guī)則2產(chǎn)生沖突，Snort的動(dòng)作是reject，在拒絕數(shù)據(jù)報(bào)通過之外還要向數(shù)據(jù)報(bào)的發(fā)送者發(fā)送響應(yīng)報(bào)文，而響應(yīng)報(bào)文被iptables策略拒絕，產(chǎn)生了沖突。

圖9 跨網(wǎng)絡(luò)功能策略檢測(cè)結(jié)果

Figure 9 Results of policy verification across network functions

7.2 性能測(cè)試

本節(jié)對(duì)第6節(jié)提出的策略驗(yàn)證框架進(jìn)行了原型實(shí)現(xiàn)，并進(jìn)行了性能測(cè)試。

（1）OpenFlow交換機(jī)與網(wǎng)絡(luò)功能策略驗(yàn)證性能

對(duì)于SDN轉(zhuǎn)發(fā)策略與網(wǎng)絡(luò)功能策略驗(yàn)證，其中轉(zhuǎn)發(fā)路徑需要構(gòu)建前綴樹，與交換機(jī)的實(shí)際數(shù)量、策略的具體定義以及策略的數(shù)目有關(guān)；網(wǎng)絡(luò)功能策略需要兩兩對(duì)比，尋找兩條滿足約束條件的規(guī)則，因此分析時(shí)間是(2)（為網(wǎng)絡(luò)功能策略數(shù)）。圖10為檢測(cè)結(jié)果，用時(shí)符合預(yù)期：當(dāng)轉(zhuǎn)發(fā)路徑策略數(shù)目不同時(shí)，網(wǎng)絡(luò)功能策略數(shù)量越多，則驗(yàn)證時(shí)間越長(zhǎng)，且增長(zhǎng)時(shí)間與網(wǎng)絡(luò)功能策略數(shù)的平方基本呈線性關(guān)系。

圖10 OpenFlow交換機(jī)與網(wǎng)絡(luò)功能策略檢測(cè)開銷對(duì)比

Figure 10 Comparison of time overhead in policy verification among OpenFlow switches and network functions with policies of different numbers

（2）跨網(wǎng)絡(luò)功能策略驗(yàn)證性能測(cè)試

對(duì)于跨網(wǎng)絡(luò)功能的策略驗(yàn)證，由于兩個(gè)網(wǎng)絡(luò)功能之間的策略需要兩兩進(jìn)行交叉對(duì)比，因此算法的復(fù)雜度為()，其中、分別代表兩個(gè)網(wǎng)絡(luò)功能的規(guī)則數(shù)目。表6為性能測(cè)試結(jié)果，用iptables()和Snort()，用時(shí)與×基本呈線性相關(guān)，但規(guī)則數(shù)目過多時(shí)，由于沖突數(shù)量大幅增加，結(jié)果略有偏差。

表6 跨網(wǎng)絡(luò)功能策略驗(yàn)證性能測(cè)試結(jié)果

7.3 對(duì)比實(shí)驗(yàn)測(cè)試

如上文所述，現(xiàn)有工具并不具備同時(shí)檢測(cè)SDN交換機(jī)與網(wǎng)絡(luò)功能之間以及跨網(wǎng)絡(luò)功能之間策略沖突的驗(yàn)證能力，因此主要對(duì)比策略驗(yàn)證性能。選取同樣以策略為單位的驗(yàn)證工具Veriflow[11]和Symnet[9]進(jìn)行對(duì)比，其中Veriflow專用于驗(yàn)證SDN交換機(jī)中的策略是否存在沖突，而Symnet則使用符號(hào)執(zhí)行的模型，專用于網(wǎng)絡(luò)功能中有狀態(tài)的策略驗(yàn)證。對(duì)比實(shí)驗(yàn)考慮了策略總數(shù)從0～200的情形，圖11為對(duì)比實(shí)驗(yàn)結(jié)果。從結(jié)果可以看出，相比Veriflow這種只針對(duì)SDN交換機(jī)規(guī)則的驗(yàn)證工具，本文工作驗(yàn)證時(shí)間更長(zhǎng)（如SDN+FW曲線所示）；但是對(duì)比Symnet這種采用了更加復(fù)雜的驗(yàn)證方案的工具，本文工作的驗(yàn)證過程更為迅速（如FW+IPS曲線所示）。這是由于：①Veriflow只涉及簡(jiǎn)單的交換機(jī)轉(zhuǎn)發(fā)策略，而本文工作涉及網(wǎng)絡(luò)功能中語義和結(jié)構(gòu)更為復(fù)雜的策略，因此時(shí)間開銷更大；②Veriflow采用了增量驗(yàn)證方案，將轉(zhuǎn)發(fā)策略變成等效類后再進(jìn)行驗(yàn)證，提高了效率；③Symnet可以支持有狀態(tài)的網(wǎng)絡(luò)功能，因此功能實(shí)現(xiàn)更加復(fù)雜。由此可見，策略驗(yàn)證的性能與復(fù)雜度受多方面影響，但是本文工作仍然有優(yōu)化空間，可以考慮加入Veriflow的增量策略驗(yàn)證方案，作為未來改進(jìn)方向。

圖11 對(duì)比實(shí)驗(yàn)結(jié)果

Figure 11 Comparison on performance overhead between this work and related tools

7.4 實(shí)驗(yàn)結(jié)果總結(jié)分析

由實(shí)驗(yàn)結(jié)果可知，策略檢測(cè)引擎可以正確檢測(cè)出SDN轉(zhuǎn)發(fā)策略與網(wǎng)絡(luò)功能、跨網(wǎng)絡(luò)功能策略之間的沖突問題；檢測(cè)的性能符合復(fù)雜度預(yù)期，檢測(cè)速度較快。但性能方面仍然具有改進(jìn)空間，可以進(jìn)一步優(yōu)化。

8 結(jié)束語

由于SDN和NFV技術(shù)的引入，云環(huán)境下基于SDN/NFV的網(wǎng)絡(luò)中，不僅網(wǎng)絡(luò)結(jié)構(gòu)變得更加靈活、復(fù)雜，網(wǎng)絡(luò)轉(zhuǎn)發(fā)策略也變得更加動(dòng)態(tài)。動(dòng)態(tài)策略的引入，出現(xiàn)了不同于傳統(tǒng)網(wǎng)絡(luò)中的動(dòng)態(tài)策略沖突問題。為了進(jìn)行基于SDN/NFV的云環(huán)境網(wǎng)絡(luò)中的動(dòng)態(tài)策略驗(yàn)證，本文分析了網(wǎng)絡(luò)轉(zhuǎn)發(fā)設(shè)備與網(wǎng)絡(luò)功能之間、跨網(wǎng)絡(luò)功能之間的策略沖突場(chǎng)景與原因，并提出了驗(yàn)證方案；此外，基于SDN的網(wǎng)絡(luò)架構(gòu)進(jìn)行擴(kuò)展，在SDN的基礎(chǔ)上提出了策略驗(yàn)證框架，并基于實(shí)用的SDN平臺(tái)進(jìn)行了原型實(shí)現(xiàn)，支持多種流行的網(wǎng)絡(luò)功能以及SDN交換機(jī)中的策略檢測(cè)，最后在實(shí)驗(yàn)中驗(yàn)證了方案的有效性與原型實(shí)現(xiàn)的性能。

[1]MANAR J, TARANPREET S, ABDALLAH S, et al. Software defined networking: state of the art and research challenges[J]. Computer Networks,2014,72: 74-98.

[2]Software-defined network[EB].

[3]RASHID M, JOAN S, JUAN-LUIS G, et al. Network function virtualization: state-of-the-art and research challenges[J]. IEEE Communications Surveys & Tutorials, 2016, 18(1): 236-262.

[4]饒少陽, 陳運(yùn)清, 馮明. 基于SDN的云數(shù)據(jù)中心網(wǎng)絡(luò)[J]. 電信科學(xué), 2014(8): 33-41.

RAO S Y, CHEN Y Q, FENG M. cloud data center based on SDN[J]. Telecommunications Science, 2014(8): 33-41.

[5]安琪, 劉艷萍, 孫茜, 等. 基于SDN與NFV的網(wǎng)絡(luò)切片架構(gòu)[J]. 電信科學(xué), 2016(11): 119-126.

ANQ, LIU Y P, SUN Q, et al. Network slicing architecture based on SDN and NFV[J]. Telecommunications Science. 2016(11): 119-126.

[6]SDN & NFV use cases defined[EB].

[7]WANG Y, LI Z, XIE G, KAVE S. Enabling automatic composition and verification of service function chain[C]//IEEE/ACM International Symposium on Quality of Service (IWQoS’17). 2017: 1-5.

[8]PANDA A, ARGYRAKI K, SAGIV M, et al. New directions for network verification[C]//LIPIcs-Leibniz International Proceedings in Informatics 2015: 209-220

[9]STOENESCU R, POPOVICI M, NEGREANU L, et al. Symnet: scalable symbolic execution for modern networks[C]//Proceedings of the 2016 ACM SIGCOMM Conference (SIGCOMM’16). 2016: 314-327.

[10]HORN A, KHERADMAND A, PRASAD M R. Delta-net: real-time network verification using atoms[C]//Proceedings of the 14th USENIX Symposium on Networked Systems Design and Implementation (NSDI’17). 2017: 735-749

[11]KHURSHID A, ZHOU W, CAESAR M, et al. Veriflow: verifying network-wide invariants in real time[C]//Proceedings of the 10th USENIX Symposium on Networked Systems Design and Implementation (NSDI’13). 2013: 15-27.

[12]SHERRY J, HASAN S, SCOTT C, et al. Making middleboxes someone else's problem: network processing as a cloud service[J]. ACM SIGCOMM Computer Communication Review, 2012, 42(4): 13-24.

[13]PANDA A, LAHAV O, ARGYRAKI K, et al. Verifying isolation properties in the presence of middleboxes[J]. arXiv preprint, 2014, arXiv:1409.7687.

[14]HU H, AHN G J, KULKARNI K. Detecting and resolving firewall policy anomalies[J]. IEEE Transactions on Dependable & Secure Computing(TDSC’12), 2012, 9(3): 318-331.

[15]DENG J, LI H. On the safety and efficiency of virtual firewall elasticity control[C]//24th Network and Distributed System Security Symposium (NDSS’17). 2017.

[16]MALDONADO-LOPEZ F A, CALLE E, DONOSO Y. Detection and prevention of firewall-rule conflicts on software-defined networking[C]//7th IEEE international Workshop on Reliable Networks Design and Modeling (RNDM’15). 2015: 259-265.

[17]邱松, 焦健, 張東陽. 面向防火墻和IDS/IPS協(xié)同防御的策略沖突檢測(cè)算法[J]. 系統(tǒng)仿真學(xué)報(bào), 2015, 27(11): 2770-2777.

QIU S, JIAO J, ZHANG D Y. Policy conflicts verification algorithm towards collaborative defense with firewalls and IDS/IPS[J]. Journal of System Simulation, 2015, 27(11): 2770-2777.

[18]PANDA A, LAHAV O, ARGYRAKI K, et al. Verifying reachability in networks with mutable datapaths[C]//Proceedings of the 14th USENIX Symposium on Networked Systems Design and Implementation (NSDI’17). 2017: 699-718.

[19]WU W, ZHANG Y, BANERJEE S. Automatic synthesis of NF models by program analysis[C]//ACM Workshop on Hot Topics in Networks (HotNets’16). 2016: 29-35.

[20]FAYAZ S K, YU T, TOBIOKA Y, CHAKI S, SEKAR V. BUZZ: testing context-dependent policies in stateful networks[C]//13th USENIX Conference on Networked Systems Design and Implementation (NSDI’16). 2016: 275-289.

[21]PRABHU S, CHOU K Y, KHERADMAND A, et al. Plankton: Scalable network configuration verification through model checking[C]//Proceedings of the 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI’20). 2020: 953-967.

[22]YUAN Y, MOON S J, UPPAL S, et al. NetSMC: a custom symbolic model checker for stateful network verification[C]//Proceedings of the 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI’20). 2020: 181-200.

Verification on policies for network functions in SDN/NFV-based environment

CHEN Haoyu1,2,3, ZOU Deqing1,2,4, JIN Hai1,2,3

1. National Engineering Research Center for Big Data Technology and System, School of Computer Science and Technology, Huazhong University of Science and Technology, Wuhan 430074, China 2. Services Computing Technology and System Lab, School of Computer Science and Technology, Huazhong University of Science and Technology, Wuhan 430074, China 3. Cluster and Grid Computing Lab, School of Computer Science and Technology, Huazhong University of Science and Technology, Wuhan 430074, China 4. Hubei Engineering Research Center on Big Data Security, School of Cyber Science and Engineering, Huazhong University of Science and Technology, Wuhan 430074, China

Although the newly introduced SDN and NFV technologies bring flexibility and convenience in network management, the dynamic forwarding policies introduced by SDN may cause invalidation in the network function policies, and the policies in different network functions may also cause conflicts due to their own behaviors. In order to verify the policies in SDN/NFV-based cloud network, the verification on policies between the network function and the SDN device, as well as across the network functions were considered. A unified policy expression for analysis was summarized, and policy verification scheme, framework and prototype implementation were proposed to verify the correctness of polices in different scenarios, then experiments were conducted to justify the effectiveness and performance.

policy verification, cloud network, software-defined networking, network function virtualization

TP393

A

10.11959/j.issn.2096?109x.2021035

2020?12?14；

2021?01?21

金海，hjin＠hust.edu.cn

國(guó)家重點(diǎn)研發(fā)計(jì)劃（2019YFB2101700）；廣州市未來產(chǎn)業(yè)關(guān)鍵技術(shù)研發(fā)專題項(xiàng)目（201902020016）

The National Key R&D Program of China (2019YFB2101700), The Science and Technology Program of Guangzhou (201902020016)

陳浩宇, 鄒德清, 金海. 面向SDN/NFV環(huán)境的網(wǎng)絡(luò)功能策略驗(yàn)證[J]. 網(wǎng)絡(luò)與信息安全學(xué)報(bào), 2021, 7(3): 59-71.

CHEN H Y, ZOU D Q, JIN H. Verification on policies for network functions in SDN/NFV-based environment[J]. Chinese Journal of Network and Information Security, 2021, 7(3): 59-71.

陳浩宇（1992?），男，江蘇揚(yáng)州人，華中科技大學(xué)博士生，主要研究方向?yàn)榫W(wǎng)絡(luò)安全測(cè)試、網(wǎng)絡(luò)模糊測(cè)試、軟件定義網(wǎng)絡(luò)、網(wǎng)絡(luò)功能虛擬化、軟件定義網(wǎng)絡(luò)安全。

鄒德清（1975? )，男，湖南長(zhǎng)沙人，華中科技大學(xué)教授、博士生導(dǎo)師，主要研究方向?yàn)樘摂M化安全與云安全、網(wǎng)絡(luò)攻防與漏洞檢測(cè)、大數(shù)據(jù)安全、容錯(cuò)計(jì)算。

金海（1966? ）男，上海人，華中科技大學(xué)教授、博士生導(dǎo)師，主要研究方向?yàn)橛?jì)算機(jī)體系結(jié)構(gòu)、虛擬化技術(shù)、集群計(jì)算與云計(jì)算、P2P計(jì)算、網(wǎng)絡(luò)存儲(chǔ)以及網(wǎng)絡(luò)安全。