軟件定義網絡數據平面安全綜述

郭中孚，張興明，趙博，王蘇南

?

軟件定義網絡數據平面安全綜述

郭中孚1，張興明1，趙博1，王蘇南2

（1. 國家數字交換系統(tǒng)工程技術研究中心，河南 鄭州 450002； 2. 深圳職業(yè)技術學院，廣東 深圳 518000）

軟件定義網絡將數據平面與控制平面解耦，旨在更快地引入網絡創(chuàng)新，并從根本上實現大型網絡的自動化管理。架構創(chuàng)新帶來了挑戰(zhàn)與機遇，安全問題限制了軟件定義網絡的廣泛采用。針對數據平面的攻擊可能會損毀整個軟件定義網絡，首先介紹了數據平面結構與發(fā)展趨勢；然后分析了數據平面安全風險，指出漏洞，確定潛在的攻擊場景，并給出2種具體解決方案，討論其意義與局限性；最后展望未來的安全研究方向。

軟件定義網絡；數據平面；有狀態(tài)數據平面；軟件定義網絡安全；數據平面安全

1 引言

傳統(tǒng)的互聯(lián)網協(xié)議網絡以硬件為中心，網絡中底層設備配置管理需使用設備供應商的特定命令，繁雜耗時，此外，數據平面與控制平面的捆綁，使龍頭廠商的壟斷地位堅不可破，嚴重阻礙了網絡基礎設施的發(fā)展；云計算、物聯(lián)網等新技術使聯(lián)網設備數量爆炸式增長，從發(fā)展趨勢看，傳統(tǒng)網絡無法應對需求。軟件定義網絡（SDN，software defined network）是一種新興的網絡架構，控制與數據平面分離。SDN有邏輯上集中但物理上分布的控制機制，監(jiān)控整個網絡，并對數據平面中轉發(fā)設備的分組轉發(fā)做出決策。數據平面只是簡單的轉發(fā)元素，沒有嵌入式智能來自主決策，因此易引發(fā)諸多全新的安全問題。本文旨在研究如何保護SDN平臺本身，重點關注SDN數據平面相關安全問題。

2 SDN數據平面

2.1 SDN架構

SDN的核心架構如圖1所示，分為3層。頂層應用平面定義規(guī)則并提供不同服務（如負載均衡、流量監(jiān)控、入侵檢測/入侵防御、服務質量等）。應用平面通過北向應用程序設計接口（API，application programming interface）向SDN控制平面分發(fā)策略。第二層控制平面是網絡拓撲的抽象。控制器負責建立流量表和數據處理策略，通過南向API抽象網絡細節(jié)，并保持最新的網絡整體視圖。OpenDaylight[1]和開放式網絡操作系統(tǒng)（ONOS，open network operating system）[2]實現分布式控制，多個控制器之間通過東向/西向API（如HyperFlow[3]）交換數據平面中的流量控制信息。最底層稱為數據平面，提供網絡設備，如真實或虛擬的交換機、路由器和接入點。

圖1 SDN的核心架構

2.2 數據平面

數據平面由網絡設備組成，如專門用于分組轉發(fā)的交換機和路由器。與傳統(tǒng)網絡不同，這些只是簡單的網元設備，沒有嵌入式智能來自主決策。這些設備通過標準的OpenFlow接口與控制器進行通信，確保了不同設備之間的配置和通信兼容性以及互操作性。OpenFlow轉發(fā)設備具有轉發(fā)表，它由3部分組成：①規(guī)則匹配；②為匹配分組而執(zhí)行的操作；③用于統(tǒng)計匹配分組數量的計數器。規(guī)則匹配字段包括交換機端口、源媒體訪問控制（MAC，media access control）地址、目標MAC地址、以太網類型、虛擬局域網（VLAN，virtual local area network）ID、源IP、目標IP、傳輸控制協(xié)議（TCP，transmission control protocol）源端口、TCP目標端口。流規(guī)則可以定義為這些字段的組合。最常見的操作包括：將數據分組轉發(fā)到傳出端口、封裝并轉發(fā)給控制器、丟棄、排隊、修改字段等。最常見的情況是安裝一個默認規(guī)則指示交換機將數據分組轉發(fā)給控制器做出決定。

2.3 數據平面研究的最新進展

最初的OpenFlow標準過于嚴格，出現了各種提案，增加了額外的靈活性。它們可以分為3個不同的方向：①轉發(fā)設備添加多個流表；②改進的匹配規(guī)則；③定制的OpenFlow擴展。

2.3.1 將多個流表添加到轉發(fā)設備

最初在OpenFlow.1.0[4]中提出的單個流表模型會導致2個主要問題。首先，它會迫使開發(fā)者部署OpenFlow規(guī)則，這些規(guī)則結合了所需匹配的笛卡爾積，這種指數增長的部署規(guī)則將導致流量表容量使用效率非常低，通常需要昂貴且實際受限的三態(tài)內容尋址存儲器（TCAM，ternary content addressable memory）來實現。其次，許多應用程序自然受益于兩階段處理模型[5]，其中，在第一階段首先基于某些分組特征對分組進行標記，然后進行下一步的匹配和處理。因此，流水線流表是針對早期OpenFlow版本的一項重要改進，其通過一系列流表定義如何處理數據分組，可以顯著節(jié)省TCAM內存，同時擁有更簡潔的配置。

在標準化進程的同時，研究界提出了更進一步的硬件解決方案，以實現更靈活的多重匹配。此方面的突出成就是2013年提出的可重構匹配表（RMT，reconfigurable match table）[6]，該設計通過同一物理TCAM陣列非常靈活地映射任意數量的具有不同寬度和深度（邏輯）的匹配表，通過先前匹配計算或提取的參數定義匹配規(guī)則。

2.3.2 提高匹配規(guī)則的靈活性

不同類型網絡應用程序操作顯然要與不同類型的匹配相關聯(lián)，在最初的OpenFlow版本1.0 中僅限于12個匹配字段，OpenFlow版本1.3.4[7]已經支持40個匹配字段，最近OpenFlow版本1.5.1[8]中此數字增為45，其中包括細粒度的匹配，如TCP標志等。2013年，協(xié)議不經意轉發(fā)（POF，protocol oblivious forwarding）提案[9]通過組從數據分組頭字段提取任意位的匹配，靈活性顯著增強。

2.3.3 定制的OpenFlow擴展

從OpenFlow v1.0至今已提出多種OpenFlow協(xié)議的擴展，以適應普通流表或OpenFlow操作無法處理的特定需求。組表是OpenFlow擴展最顯著的例子，它引入了有狀態(tài)操作支持。例如，OpenFlow v1.0中，當鏈路/端口發(fā)生（物理）故障時，OpenFlow交換機會請求遙遠的控制器來實例化一個新的轉發(fā)規(guī)則（例如，故障鏈路/端口處理的所有流量由備用鏈接轉發(fā)）。但是，控制器需要一些時間才能做出反應，因此這段時間內，所有發(fā)往故障端口的數據分組都將丟失（而在大型網絡中，該數量可能非常龐大：對于10 Gbit/s鏈路上的控制器，100 ms的響應時間將導致多達3×107個數據分組丟失）。為解決這個問題，新版本OpenFlow標準引入了一種快速故障轉移技術。一個快速故障轉移組包含多個操作集合，這些操作按照故障轉移組定義的順序進行評估，直到選出一個可用的方案。盡管解決了重要的問題，但快速故障轉移不僅是最新的OpenFlow規(guī)范中的備選項，且關鍵細節(jié)的實施不在OpenFlow規(guī)范內。有狀態(tài)OpenFlow擴展的其他重要例子如速率控制儀表、用于支持學習型功能的同步表格等，詳細信息見OpenFlow版本1.5.1[8]。

2.4 數據平面的發(fā)展趨勢

如2.3節(jié)所討論的，OpenFlow標準的發(fā)展證實在交換機內引入一些有狀態(tài)的操作是必要的，以減少遠程控制器實時參與（explicit involvement）帶來的過度延遲。本節(jié)所討論的內容也是當前數據平面的主要發(fā)展趨勢，普遍被稱為有狀態(tài)的數據平面（stateful data plane）[10,12,13]。

一般而言，有狀態(tài)的SDN數據平面提議有2個主要原則：①使流的狀態(tài)信息保存在轉發(fā)設備內部，允許以編程的方式實例化分組級別的狀態(tài)轉化；②賦予交換機做轉發(fā)狀態(tài)更新的權力，基于本地流的狀態(tài)信息而不需要同控制器進行通信。

主流的有狀態(tài)數據平面核心平臺有OpenState、流級狀態(tài)轉換（FAST，flow-level state transitions）和狀態(tài)數據平面抽象（SDPA，stateful data plane abstraction），3個平臺中使用的表格如圖2~圖4所示，每個表格都被表示為一個矩形，包含表格名稱和用“丨”分隔的相應表格項目。

2.4.1 OpenState

OpenState[10]通過擴展有限狀態(tài)機（XFSM，eXtended finite state machine）向SDN的數據平面引入了可編程性。OpenState的工作最近在文獻[11]中得到了進一步的擴展，更加全面地支持XFSM（與原始的Mealy狀態(tài)機不同）。

OpenState每個轉發(fā)設備都有2個獨立的表：狀態(tài)表和XFSM表（如圖2所示）。前者存儲接收到的數據分組當前流的狀態(tài)，這些狀態(tài)與該數據分組流相關。后者根據數據分組的接收信息來定義規(guī)則。XFSM由4元組（；；；）建模，其中，是包括起始狀態(tài)S0的一組有限狀態(tài)；是一組有限的輸入（事件）；是一組有限的輸出（操作）；是一個狀態(tài)轉換函數（規(guī)則），它將與相映射。使用OpenState，轉發(fā)設備中的數據分組處理是一個3步過程。

圖2 OpenState架構中使用的表格

Step1 轉發(fā)設備接收到數據分組后，在狀態(tài)表中檢索當前狀態(tài)（它使用流ID（如源IP地址）作為表檢索的關鍵字），將其作為元數據字段附加到數據分組。若狀態(tài)表查找未匹配，則轉發(fā)設備會為傳入數據分組分配默認狀態(tài)S0。

Step2 轉發(fā)查詢XFSM表以查找與“狀態(tài)事件對”匹配的規(guī)則，根據XFSM表執(zhí)行下一個狀態(tài)字段預先定義的相關操作，并更新數據分組的狀態(tài)字段。

Step3 轉發(fā)設備基于從對應流ID的先前步驟中檢索到的下一個狀態(tài)字段來更新其狀態(tài)表。

顯然，轉發(fā)設備無須為每個接收到的分組聯(lián)系控制器，可以基于接收到數據分組的當前狀態(tài)以及控制器對每個對的預定義規(guī)則進行路由決策。

2.4.2 FAST

與OpenState類似，FAST[12]還在每個轉發(fā)設備中存儲預裝的狀態(tài)機。但在FAST中，每個轉發(fā)設備可能有多個狀態(tài)機實例，每個實例都有特定的應用程序。而且，數據平面并不是在OpenState中使用的2個表，而是實現了包括狀態(tài)機過濾器表、狀態(tài)表、狀態(tài)轉換表、操作表（如圖3所示）。狀態(tài)機所有實例共用一個狀態(tài)機過濾器表，但每個狀態(tài)機都有自己的狀態(tài)表、狀態(tài)轉換表和操作表。狀態(tài)機過濾表用于選擇與數據分組相關對應狀態(tài)機。狀態(tài)表是一個散列表，將每個數據分組頭映射到流狀態(tài)，每個狀態(tài)值都存儲在一個變量內，就一個數字而言，一些高位用于存儲狀態(tài)，其他位表示相應的值。最后，操作表根據數據分組頭及其新狀態(tài)指定轉發(fā)設備應對數據分組執(zhí)行相應操作。

圖3 FAST架構中使用的表格

FAST控制平面有2個組件：編譯器和轉發(fā)設備代理。前者是一個脫機組件，負責將狀態(tài)機轉換為轉發(fā)設備代理。后者是在線組件：①管理轉發(fā)設備內部的狀態(tài)機；②基于從轉發(fā)設備接收到的更新執(zhí)行某些本地計算；③通過局部實現轉發(fā)設備內部的狀態(tài)機；④處理轉發(fā)設備與控制器之間的通信，同時更新控制器關于交換機的本地狀態(tài)。例如，如果交換機檢測到攻擊者，則更新交換代理，隨后更新控制器。

2.4.3 SDPA

SDPA[13]由3個主表組成，包括狀態(tài)表、狀態(tài)轉換表和操作表（如圖4所示），以及狀態(tài)處理模塊，即轉發(fā)處理器（FP，forwarding processor）。狀態(tài)表有3個字段值：匹配、狀態(tài)和指令。匹配值可以是數據分組頭部字段的任意組合，狀態(tài)值是流的當前狀態(tài)，指令值可以由狀態(tài)或數據分組指定。與前兩者不同，SDN控制器與FP模塊通信并啟動狀態(tài)表。此外，通過定期或特定的事件更新，控制器通過與FP的通信維護狀態(tài)表的完整控制和更新信息。通過SDPA，在接收到流的第一個分組后，交換機將分組發(fā)送到控制器，該控制器確定相應流狀態(tài)應存儲的狀態(tài)表。來自該流的其他輸入數據分組將在交換機內本地處理，而無須與控制器通信。控制器有絕對控制權且能決定何時更新，如接收FP更新（即定期更新或由于特定事件觸發(fā)更新）或控制器決定何時接收更新。

圖4 SDPA架構中使用的表格

2.5 安全發(fā)展態(tài)勢

當前SDN安全研究可以分為3個主要方向。

1) 引入已有的安全方案，并在SDN架構內進行改進升級。例如，在SDN中構建可靠防火墻[14,15]，將防火墻、入侵防御系統(tǒng)（IPS，intrusion prevention system）、（分布式）拒絕服務攻擊（(D)DoS，（distributed）denial of service）探測器、反射器網絡等功能基于SDN集成起來增強網絡安全方案[16]。或者引入以太網[17]、信息中心網絡[18]等一些久經檢驗的成熟技術，該研究方向極大地推進了初期SDN安全的發(fā)展。

2) 基于SDN特性開發(fā)全新的安全服務，這些服務在SDN出現前是無法開展或很難開展的，如使用網絡功能來保護物聯(lián)網設備[19]、網絡取證[20]、流量監(jiān)控[20]，基于云的環(huán)境預防（D）DoS攻擊[21-22]。

3) 保證SDN平臺本身安全的研究，SDN平臺本身因控制器的存在具有單點脆弱性，2.4節(jié)所述狀態(tài)數據平面降低了數據平面對SDN控制平面的依賴性，是現在主流的研究方向，很多工作基于此展開，可以開發(fā)多種應用程序，包括狀態(tài)故障恢復[23]、HULA[24]、端口敲門[25]、SDN通道狀態(tài)檢測[26]和用戶數據報協(xié)議（UDP，user datagram protocol）洪泛狀態(tài)緩解[27]。隨著SDN的進一步發(fā)展，其自身雖引入了新的漏洞，但終將更安全，詳情參考文獻[28]。

3 數據平面安全風險

第2節(jié)中討論了現有SDN數據平面的結構與發(fā)展，SDN優(yōu)點很多，但安全性問題成為制約SDN廣泛應用的關鍵，傳統(tǒng)網絡中轉發(fā)設備普遍由不同設備商提供，設備異構性本身也是一種安全防護。在SDN架構中有邏輯集中的控制平面，通過開放、可編程的接口，基于設備管理協(xié)議與OpenFlow一起，對數據平面可編程轉發(fā)設備進行配置和管理，所以數據平面易受誤配置信息影響。接下來從數據平面漏洞和攻擊兩方面討論安全風險。

3.1 漏洞分析

在OpenFlow網絡交換模型中，控制器下發(fā)流規(guī)則到轉發(fā)設備流表中，流規(guī)則下發(fā)可分為2類：被動式和主動式。被動工作模式：用戶發(fā)送數據分組后，轉發(fā)設備產生 packet-in 消息傳遞到控制平面，控制器依據相應的網絡狀態(tài)下發(fā)流規(guī)則，轉發(fā)設備依據接收到的流規(guī)則完成轉發(fā)。主動工作模式：在用戶發(fā)送數據報之前，控制器已經下發(fā)流規(guī)則到轉發(fā)設備流表空間，需考慮轉發(fā)設備流規(guī)則存儲以及不同轉發(fā)設備的流規(guī)則不一致等問題。

數據平面拒絕服務攻擊。在轉發(fā)設備流表存儲空間有限的前提下，要保證表項合理使用且不被惡意侵占。在 OpenFlow 協(xié)議中，轉發(fā)設備需要在控制平面下發(fā)相應流規(guī)則前緩存數據分組，因此數據平面易受存儲器飽和攻擊。流表空間滿足正常情況下轉發(fā)設備工作需要，但在遭遇 (D)DoS攻擊時，攻擊者產生高速率大容量的數據分組，流表空間迅速耗盡，后續(xù)流被直接丟棄，導致拒絕服務問題。

惡意流規(guī)則注入導致流規(guī)則不一致，進而使 SDN網絡不穩(wěn)定，使流規(guī)則喪失可靠性。數據平面接收控制平面下發(fā)的流規(guī)則，挑戰(zhàn)在于如何隔離惡意或非正常流規(guī)則。轉發(fā)設備處于監(jiān)聽模式時，與控制平面連接無須認證，因此轉發(fā)設備被惡意控制器控制時流表信息易被篡改，造成單點失效或信息泄露等問題。當涉及物理分布式控制平面[29-31]，攻擊者影響并強制流規(guī)則分發(fā)，從而將網絡驅動為不一致的狀態(tài)，進而導致控制平面的癱瘓。

在SDN轉發(fā)與控制解耦的架構中，數據平面基本功能依賴于與控制平面通信，如果二者失去連接，沒有相應流轉發(fā)規(guī)則的指導，轉發(fā)設施構成的節(jié)點網絡會癱瘓[32]。因此，考慮數據平面安全問題，本文也將分析針對南向API的攻擊。

3.2 攻擊分析

因為針對同一個漏洞有多種不同攻擊方式，無法與上文分析的漏洞一一對應，本文按數據平面和南向API兩方面敘述針對3.1所述漏洞的攻擊。

3.2.1 數據平面

3種不同的攻擊可能被用來損害數據平面，包括設備攻擊、協(xié)議攻擊和側信道攻擊。

設備攻擊指通過SDN功能的交換機，利用其軟件或硬件漏洞來危害SDN的數據平面。攻擊者可以針對轉發(fā)設備的軟件缺陷（如固件攻擊）或硬件特征（如TCAM存儲器）。因OpenFlow交換機流量表容量有限，推理攻擊[33]可以推斷網絡參數且準確度較高（流量表容量和流量表使用情況）。

協(xié)議攻擊是指利用轉發(fā)設備中的網絡協(xié)議漏洞（如針對邊界網關協(xié)議的攻擊）而展開SDN數據平面的攻擊。Kloti等[34]詳細研究了SDN中的拒絕服務攻擊和信息泄露攻擊，這些攻擊因OpenFlow的性質而加劇。如文獻[35]中所述，大多數OpenFlow交換機具有不同定制功能且在獨立交換機固件上實現。例如，HP3800型交換機不支持TCAM流表中對OpenFlow所指定12位字段組的匹配。交換機固件缺陷會被攻擊者濫用導致木桶效應，降低整體網絡性能。惡意應用程序可以安裝針對性的流規(guī)則，用上述硬件不支持的匹配字段（MAC匹配）覆蓋現有流規(guī)則（IP匹配）來實現此類攻擊。

側信道攻擊是指攻擊者通過分析轉發(fā)設備的性能指標推斷出網絡的轉發(fā)策略。例如，攻擊者可以通過輸入緩沖區(qū)來識別規(guī)則，進而分析數據分組處理時間，最終識別轉發(fā)策略[36]。

3.2.2 南向API

針對SDN的南向API有2種主要攻擊：竊聽篡改攻擊和(D)DoS攻擊。在竊聽篡改攻擊中，攻擊者竊聽控制和數據平面之間交換的信息，進而通過修改數控平面間的消息來破壞網絡，如Benton等[37]提出的篡改信息攻擊。此類攻擊可能存在潛伏期，掌握盡可能多的信息通路，在特定時刻徹底損毀網絡。在(D)DoS攻擊中，南向API充斥著導致網絡策略實施失敗的請求，如文獻[38]中所述，攻擊者可以通過分析探測數據分組并將它們分類來評估延遲時間，從而通過探測數據分組推測SDN中的流量規(guī)則。已知流量規(guī)則的攻擊者可以通過發(fā)送大量規(guī)則匹配的數據分組來觸發(fā)(D)DoS攻擊，這些數據分組會觸大量packet-in數據分組，使控制器不堪重負而癱瘓。

4 數據平面安全措施

數據平面由網絡轉發(fā)設備組成，基礎設施受損會導致大量信息泄露，各國情報機構在內的攻擊者致力于在其上植入后門，即使是新手黑客也可以通過發(fā)送指定數據分組開啟后門進而在路由器上執(zhí)行任意代碼[39]。受損的轉發(fā)設備可能會惡意分組丟失、網絡減速、偽造網絡流量等，以發(fā)起針對網絡運營商及其用戶的攻擊，甚至取消整個軟件定義網絡[40-41]，相較傳統(tǒng)網絡而言，受損轉發(fā)設備對SDN造成的損害要高很多。

保護SDN數據平面，要考慮以下4方面因素。

1) 現有解決方案不兼容性：用于傳統(tǒng)網絡的防御機制不適用于SDN，為了將傳統(tǒng)的防御措施引入SDN中，需要對OpenFlow協(xié)議進行基本的重新設計[42]。

2) 控制平面對數據平面的依賴：SDN控制器依賴數據平面反饋信息了解整個網絡狀況，這些未經驗證的消息很容易被篡改，即使使用TLS身份驗證，惡意轉發(fā)設備也可能發(fā)送偽造的欺騙消息來破壞網絡的控制器視圖。

3) 軟件交換機：可編程軟件交換機（如Open vSwitch）運行在主機服務器上，較物理交換機攻擊面更大。

4) 有狀態(tài)的SDN數據平面：2.4節(jié)已提及，通過將流狀態(tài)壓入數據平面，使每個交換機都能夠進行一定的本地自治和智能決策，從而提高網絡的性能（這歸功于數據平面和控制平面之間的通信流量減少）。盡管有狀態(tài)的SDN數據平面好處顯而易見，但這增大了攻擊面，需要考慮狀態(tài)一致性、流表存儲空間等問題。

接下來就保護SDN數據層的基本要求出發(fā)（4.1節(jié)），并結合有狀態(tài)數據層討論最新安全措施（4.2節(jié)），列舉2種具體的解決方案（4.3節(jié)）。

4.1 解決方案基本要求

隨著SDN組件的持續(xù)改進和變化，保護數據平面轉發(fā)設備是一項具有挑戰(zhàn)性的任務。為保護整個數據平面，需要一種能夠自動檢測受損轉發(fā)設備并保護整個網絡免受攻擊的解決方案，這種檢測應該基于轉發(fā)設備的主要功能（而非任何協(xié)議、軟件或攻擊），要求如下。

掃描：保護機制能夠自主優(yōu)先檢查轉發(fā)設備，高效精準完成掃描任務。

識別惡意行為：為了保護網絡，防護機制必須能夠將惡意轉發(fā)設備隔離，快速識別惡意行為尤其重要。

對威脅智能響應：保護機制需可編程，允許管理員指定網絡策略且能智能響應。

支持有狀態(tài)數據平面：必須將數據平面解決方案的最新進展設計為保護機制。

考慮到數據平面是網絡基礎設施的重要組成部分，所有提出的解決方案在檢查和分析階段都不得破壞網絡性能。

4.2 有狀態(tài)數據平面的安全意義

2.4節(jié)討論的有狀態(tài)SDN數據平面是現在主流研究方向，因其增加了數據平面的復雜度，擴大了攻擊面，體現為以下3方面。

流狀態(tài)內存易受耗盡內存攻擊：數據平面的智能性需要對流狀態(tài)信息進行存儲，攻擊者可以發(fā)動內存耗盡攻擊。

無身份認證機制：控制平面的部分功能在數據平面上獨立實現，需要轉發(fā)設備之間傳遞信息，并在常規(guī)流量數據分組內捎帶信息，確保內部通信安全可靠是一個重要問題卻很少被提及，攻擊者可能將虛假信息數據分組注入網絡中，更改特定設備的流量狀態(tài)，攻擊者可以構造虛假的場景，引發(fā)鏈路故障降低網絡性能。

缺乏中央狀態(tài)管理：因為不存在管理轉發(fā)設備內狀態(tài)同步的中央實體，分布式系統(tǒng)易發(fā)生狀態(tài)不一致問題，如接收到數據分組才會觸發(fā)狀態(tài)更改，攻擊者可以強制網絡轉變?yōu)闋顟B(tài)不一致。

有狀態(tài)數據平面的智能性使數據平面更加安全，它可以減緩傳統(tǒng)SDN中面臨的安全威脅，首先得益于數據平面與控制層間的通信減少，如控制平面飽和攻擊。這種攻擊的目的是使控制平面無法工作，這也是數據平面和控制平面之間頻繁互動的結果。攻擊者可以通過生成大量不同的流量（使用虛假IP地址）來發(fā)起控制平面飽和攻擊，這導致數據平面交換機將許多packet-in請求轉發(fā)給控制器，可能使通信鏈路或控制器內部資源飽和。盡管研究人員提出了一些數據平面方案[43-45]來解決這個問題，但在傳統(tǒng)SDN環(huán)境中，緩解控制平面飽和仍然是一個公開挑戰(zhàn)。有狀態(tài)的SDN設計緩解了這種威脅，因為它減少了通信次數，且有狀態(tài)的數據平面減緩了常在傳統(tǒng)SDN中出現的2個漏洞、流量信息泄露和TCAM流表耗盡，傳統(tǒng)SDN中攻擊者刺探數控平面間的通信信息以獲取配置信息（如安裝規(guī)則的時間開銷），有狀態(tài)的SDN交換機因為自主決定如何處理流量，減少了依賴于定時信息攻擊者的攻擊面，針對TCAM流表的攻擊也因有狀態(tài)的SDN交換機流表更改次數更少而緩解。

4.3 現有解決方案

制定保護機制需要清晰描述對手模型。本文所考慮的攻擊模型是一個可以完全掌控一個甚至全部轉發(fā)設備的對手。這也是SDN數據平面可能存在的最強大的對手。攻擊者可以將全部或部分流量隨機或選擇性丟棄、錯誤路由、延遲、重新排序，甚至生成偽造數據分組。

已知SDN數據平面需面對不確定的敵對模型[46]，這將直接限制解決方案的采用。例如，文獻[47-51]中提出的解決方案假定全部或大部分的轉發(fā)設備是可信的。本文分析可以實施并在實際條件下進行評估的SPHINX和WedgeTail。接下來，首先討論現有解決方案，接著在5.1節(jié)和5.2節(jié)中概述2個最突出的解決方案，并在5.3節(jié)中討論它們的局限性。

有關分組轉發(fā)異常檢測的文獻可分為4類：① 密碼機制；②流量統(tǒng)計；③分組探測；④基于確認的機制。這些方法在部署時受到兩方面限制：①密碼操作會顯著增加計算開銷；②需要修改IP分組格式。例如，文獻[52-56]等加密方案將簽名嵌入分組中，轉發(fā)設備通過簽名驗證分組是否被正確路由轉發(fā)。另一種加密方案是分析轉發(fā)設備端口處的流量統(tǒng)計[57-58]。但流量統(tǒng)計依賴于轉發(fā)設備間嚴格的時間同步，這在大規(guī)模網絡中很難實現，且該方法無法防御數據分組篡改攻擊。分組探測方法，如文獻[59-61]中方法對探測分組進行采樣和分析，以檢測轉發(fā)異常。這些解決方案大多集中在網絡的第一跳和最后一跳異常檢測上，并顯著增加通信開銷。基于確認的解決方案，如文獻[62-64]方法通過相鄰轉發(fā)設備之間的定期通信檢測是否有分組丟失。此時，由于每個轉發(fā)設備需存儲整個流的轉發(fā)路徑并周期性地收集確認分組，所以轉發(fā)設備計算和存儲方面開銷很大。

4.3.1 SPHINX

SPHINX是一種檢測SDN網絡拓撲和數據平面轉發(fā)攻擊的框架。SPHINX也是維護SDN數據平面安全的解決方案之一，它不會假設轉發(fā)設備是可信的。它通過監(jiān)控所有OpenFlow的消息，分析消息的功能，并對所有網絡更新進行驗證，是一種實時的解決方案。

SPHINX體系結構如圖5所示，SPHINX利用流程圖這一新穎抽象（與實際網絡操作非常接近）：①對網絡更新和約束進行增量驗證，從而實時驗證網絡屬性；②檢測網絡拓撲和數據平面轉發(fā)中已知或未知的安全威脅且不影響性能。它分析4類消息（packet-in、stats-reply、features-reply和flow-mod）以了解網絡拓撲和轉發(fā)狀態(tài)，并為網絡中觀察到的每個流量構建流圖。它不斷更新并監(jiān)控這些流程圖中的更改，當發(fā)現可疑變化時發(fā)出警報，SPHINX利用自定義算法逐步處理網絡更新，實時分析是否會導致異常行為并決定是否授權更新。網絡行為通過SPHINX策略引擎進行驗證。策略引擎使管理員能夠驗證增量流圖。管理員指定的限制條件是使用策略語言編寫的。

圖5 SPHINX體系結構

4.3.2 WedgeTail

WedgeTail是一個與控制器無關的入侵防御系統(tǒng)（IPS），旨在尋找未按預期處理數據分組的轉發(fā)設備。它首先將轉發(fā)設備映射為幾何空間內的點，并將數據分組視為其中的隨機步行者。WedgeTail在遍歷網絡時跟蹤數據分組路徑并生成相應的軌跡。此后，為了檢測惡意轉發(fā)設備，找到它們并識別具體的惡意行為（如分組丟失、偽造等），它將實際的分組軌跡與預期的分組軌跡進行比較（即根據網絡策略）。如果檢測到惡意轉發(fā)設備，則WedgeTail按照管理員預定義的策略進行響應。例如，即刻隔離策略可以由2個操作組成。首先指示潛在的惡意設備重置所有流量規(guī)則，然后通過重復引起懷疑的數據分組以不同的間隔重新檢查。如果惡意行為持續(xù)存在，轉發(fā)設備即刻與網絡隔離。

為了增加成功查找惡意設備的概率，WedgeTail依據轉發(fā)設備的優(yōu)先級進行檢查。它采用無監(jiān)督的軌跡采樣[65]，分析所有軌跡數據庫，依據分組軌跡中出現的累積頻率將轉發(fā)設備分成不同優(yōu)先級的組。Wedgetail攔截在控制和數據平面之間的OpenFlow消息，并維護網絡的虛擬副本。它使用這個虛擬副本計算預期的數據分組軌跡，從而消除對任何轉發(fā)設備的信任。為了計算數據分組的實際軌跡，WedgeTail依賴于NetSight[66]，并在數據分組穿越網絡時查詢它的歷史記錄。但當NetSight不可用時（如在小型網絡中），可以使用該文中提出的定制數據分組跟蹤機制來跟蹤數據分組。

WedgeTail由2個主要部分組成，即檢測引擎和響應引擎。檢測引擎負責檢索實際和預期的數據分組軌跡，創(chuàng)建掃描區(qū)域并實施攻擊檢測算法。無論何時檢測到受損設備，響應引擎都會向控制器提交策略以保護網絡。

如圖6所示，粗線顯示的路徑表示通過轉發(fā)設備f d（a）將數據分組發(fā)送到轉發(fā)設備f d（f）的預期路徑。有蟲子標記的是已被攻擊者入侵的惡意設備。以虛線顯示的路徑為惡意轉發(fā)設備將數據分組發(fā)送給攻擊者的路徑，理想結果為WedgeTail找到并禁止這些轉發(fā)設備繼續(xù)惡意轉發(fā)。

圖6 WedgeTail架構

4.3.3 討論

針對數據平面攻擊的形式可以劃分為兩類。

1) 網絡拓撲攻擊：如地址解析協(xié)議（ARP，address resolution protocol）污染攻擊和鏈路層發(fā)現協(xié)議（LLDP，link layer discovery protocol）拓撲欺騙（破壞物理拓撲狀態(tài)），來自惡意主機的以太網組管理協(xié)議（IGMP, internet group management protocol）消息建立虛假鏈路（破壞邏輯拓撲狀態(tài)）。

2) 數據平面轉發(fā)攻擊：網絡DDoS攻擊（一個或多個受感染的轉發(fā)設備，制造換路或者放大流量進而耗盡帶寬）；網絡向主機的DoS攻擊（向一個用戶發(fā)送大量流量，使其癱瘓）； TCAM耗盡攻擊（驅使控制器安裝大量的流表信息）；交換機黑洞攻擊（丟棄或延時發(fā)送途徑數據分組，使途經流量不能路由到目的地）。

SPHINX和WedgeTail在前人工作[67-70]基礎上，消除了轉發(fā)設備必須可信的限制，在有惡意轉發(fā)設備的實驗場景下，攻擊檢測的準確性、時效性都符合實際應用的需求，監(jiān)測到攻擊后阻止的成功率較高，且資源消耗低未影響SDN的性能。SPHINX特有優(yōu)勢是策略引擎可以由管理員編寫，在不同場景下可以保持適用性，WedgeTail在一個相當大的網絡中，能夠檢測隱藏于最底層基礎架構的惡意實體。

SPHINX有3方面的主要局限性。首先，系統(tǒng)不容忍拜占庭轉發(fā)故障，即它并不假定惡意轉發(fā)設備可能會有任意行為，因此，SPHINX不是用來檢測諸如數據分組丟失、偽造和延遲等特定惡意操作的。其次，檢測機制依賴于管理員定義的策略，流程圖組件不是根據控制器策略驗證轉發(fā)設備，但與其隨時間推移的行為之間相比較。因此，如果轉發(fā)設備從一開始就是惡意的，將永遠無法被檢測到，或者當網絡配置發(fā)生根本性變化時，SPHINX將產生大量誤報。第三，SPHINX不包括掃描機制，并且在檢查數據平面的威脅時未設優(yōu)先級。而且，SPHINX要求網絡中大多數轉發(fā)設備是可信的。雖然該假設符合現實，但更好的解決方案不應如此。

WedgeTail依靠網絡快照來計算數據分組的預期行為。但是，維護大型網絡的快照有擴展性和性能方面的限制。WedgeTail在檢測針對不同用例和場景的攻擊方面尚未被準確評估。此外，WedgeTail與分布式控制器的兼容性尚未得到解決，考慮到未來趨勢可能是分布式控制器，這可能是采用WedgeTail的主要障礙。而且，SPHINX和WedgeTail都無法識別危害轉發(fā)設備的漏洞（軟件、硬件等）。

任何一種解決方案都要注意SDN轉發(fā)設備硬件開銷，以及硬件延遲是否會影響這些解決方案在攻擊檢測中的實用性。

4.4 研究方向

考慮到針對SDN數據平面的攻擊日新月異，如傳送攻擊[71]，攻擊者能夠繞過數據平面中關鍵網絡功能，違反安全策略。SPHINX和WedgeTail都沒有針對此類攻擊進行評估，現有解決方案要預先考慮部署后可能面臨的攻擊，TopoGuard[72]、SDNsec[73]進行改進升級即可應對全新的、更狡猾的攻擊者，正是SDN這一架構為升級解決方案提供了必要的支持。此外，未來需結合數據平面最新進展開展研究。例如，解決方案對有狀態(tài)數據平面的適用性，研究有狀態(tài)數據平面引入了哪些新的安全問題，此類問題可與其他網絡安全問題做類比，如信息中心網絡[74-75]的興趣表（PIT，pending interest table）和有狀態(tài)的數據平面的狀態(tài)表有相似性，此類表項易受(D) DoS攻擊，某些問題已經得到一定程度的解決，如針對以路由器內部的PIT為目標的(D) DoS攻擊類型的緩解方法[76]、本地基于監(jiān)測的解決方案[77]等。最后，筆者認為SDN架構為開發(fā)獨立于底層軟件、硬件和協(xié)議的安全技術解決方案提供了必要基礎，這也正是推動安全部署這一開放、動態(tài)和不斷發(fā)展的技術的不竭動力。

5 結束語

以性能為首要指標的SDN，安全研究方興未艾，鑒于數據平面在SDN中的基礎性作用，本文討論了數據平面研究最新進展，列舉了針對SDN數據平面的攻擊。分析攻擊者如何利用漏洞并討論防御方法。此后給出了本文安全方案的基本要求，分析了攻擊模型，列舉了2個具體解決方案，并參考SDN數據平面安全要求討論審查這些解決方案，最后針對未來研究方案給出想法。隨著SDN的廣泛采用，針對數據平面的安全討論必將引人矚目。

[1] MEDVED J, VARGA R, TKACIK A, et al. Opendaylight: towards a model-driven sdn controller architecture[C]//2014 IEEE 15th International Symposium on. IEEE, 2014: 1-6.

[2] BERDE P, GEROLA M, HART J, et al. ONOS: towards an open, distributed SDN OS[C]//The Third Workshop on Hot topics in Software Defined Networking. 2014: 1-6.

[3] TOOTOONCHIAN A, GANJALI Y. HYPERFLOW: a distributed control plane for openflow[C]//2010 Internet Network Management Conference on Research on Enterprise Networking. 2010: 3.

[4] Heller B. Openflow switch specification, version 1.0. 0[J]. Wire, 2009,12.

[5] FUNDATION O N. The benefits of multiple flow tables and ttps[R]. 2015.

[6] BOSSHART P, GIBB G, KIM H S, et al. Forwarding metamorphosis: fast programmable match-action processing in hardware for SDN[C]//ACM sigcomm Computer Communication Review. 2013, 99-110.

[7] ZAL M, KLEBAN J. Performance evaluation of OpenFlow devices[J]. 2014.

[8] BAKTIR A C, OZGOVDE A, ERSOY C. Implementing service-centric model with P4: a fully-programmable approach[C]//IEEE/IFIP Network Operations and Management Symposium. 2018: 1-6.

[9] SONG H. Protocol-oblivious forwarding: unleash the power of SDN through a future-proof forwarding plane[C]//The Second ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking. 2013: 127-132.

[10] BIANCHI G, BONOLA M, CAPONE A, et al. OpenState: programming platform-independent stateful openflow applications inside the switch[J]. ACM sigcomm Computer Communication Review, 2014, 44(2): 44-51.

[11] BIANCHI G, BONOLA M, PONTARELLI S, et al. Open packet processor: a programmable architecture for wire speed platform- independent stateful in-network processing[R]. 2016.

[12] MOSHREF M, BHARGAVA A, GUPTA A, et al. Flow-level state transition as a new switch primitive for SDN[C]//The third WorkShop on Hot Topics in Software Defined Networking. 2014: 61-66.

[13] ZHU S, BI J, SUN C, et al. Sdpa: enhancing stateful forwarding for software-defined networking[C]//IEEE 23rd International Conference on Network Protocols (ICNP). 2015: 323-333.

[14] HU H, HAN W, AHN G J, et al. FLOWGUARD: building robust firewalls for software-defined networks[C]//The Third Workshop on Hot Topics in Software Defined Networking. 2014: 97-102.

[15] CHANG Y, LIN T. Cloud-clustered firewall with distributed SDN devices[C]//IEEE Wireless Communications and Networking Conference (WCNC). 2018: 1-5.

[16] KIRAVUO T, SARELA M, MANNER J. A survey of Ethernet LAN security[J]. IEEE Communications Surveys & Tutorials, 2013, 15(3): 1477-1491.

[17] AHLGREN B, DANNEWITZ C, IMBRENDA C, et al. A survey of information-centric networking[J]. IEEE Communications Magazine, 2012, 50(7).

[18] ZIER L, FISCHER W, BROCKNERS F. Ethernet-based public communication services: challenge and opportunity[J]. IEEE Communications Magazine, 2004, 42(3): 88-95.

[19] OLIVIER F, CARLOS G, FLORENT N. New security architecture for IoT network[J]. Procedia Computer Science, 2015, 52: 1028-1033.

[20] KHAN S, GANI A, WAHAB A W A, et al. Software-defined network forensics: motivation, potential locations, requirements, and challenges[J]. IEEE Network, 2016, 30(6): 6-13.

[21] CHOWDHARY A, PISHARODY S, HUANG D. SDN based scalable mtd solution in cloud network[C]//Proceedings of the 2016 ACM Workshop on Moving Target Defense. ACM, 2016: 27-36.

[22] YAN Q, YU F R, GONG Q, et al. Software-defined networking (SDN) and distributed denial of service (DDoS) attacks in cloud computing environments: a survey, some research issues, and challenges[J]. IEEE Communications Surveys & Tutorials, 2016, 18(1): 602-622.

[23] CAPONE A, CASCONE C, NGUYEN A Q T, et al. Detour planning for fast and reliable failure recovery in SDN with OpenState[C]//2015 11th International Conference on the Design of Reliable Communication Networks (DRCN), 2015: 25-32.

[24] KATTA N, HIRA M, KIM C, et al. Hula: scalable load balancing using programmable data planes[C]//The Symposium on SDN Research. 2016: 10.

[25] BIANCHI G, BONOLA M, CAPONE A, et al. OpenState: programming platform-independent stateful openflow applications inside the switch[J]. ACM sigcomm Computer Communication Review, 2014, 44(2): 44-51.

[26] ARASHLOO M T, KORAL Y, GREENBERG M, et al. SNAP: stateful network-wide abstractions for packet processing[C]//The 2016 ACM SIGCOMM Conference. ACM, 2016: 29-43.

[27] ARASHLOO M T, KORAL Y, GREENBERG M, et al. SNAP: stateful network-wide abstractions for packet processing[C]//The 2016 ACM SIGCOMM Conference. ACM, 2016: 29-43.

[28] DARGAHI T, CAPONI A, AMBROSIN M, et al. A survey on the security of stateful SDN data planes[J]. IEEE Communications Surveys & Tutorials, 2017, 19(3): 1701-1725.

[29] LEVIN D, WUNDSAM A, HELLER B, et al. Logically centralized? state distribution trade-offs in software defined networks[C]//The First Workshop on Hot Topics in Software Defined Networks. 2012: 1-6.

[30] PERE?íNi P, KUZNIAr M, KOSTI? D. Rule-level data plane monitoring with monocle[C]//ACM sigcomm Computer Communication Review. 2015, 45(4): 595-596.

[31] KU?NIAR M, PERE?íNi P, KOSTI? D. What you need to know about SDN flow tables[C]//International Conference on Passive and Active Network Measurement. 2015: 347-359.

[32] ZHANG Y, BEHESHTI N, TATIPAMULA M. On resilience of split-architecture networks[C]//Global Communications Conference, GLOBECOM. 2011: 1-6.

[33] ZHOU Y, CHEN K, ZHANG J, et al. Exploiting the vulnerability of flow table overflow in software-defined network: attack model, evaluation, and defense[J]. Security and Communication Networks, 2018, 2018.

[34] KLOTI R, KOTRONIS V, SMITH P. Openflow: a security analysis[C]// 2013 21st IEEE International Conference on Network Protocols (ICNP), 2013: 1-6.

[35] YOON C, LEE S, KANG H, et al. Flow wars: systemizing the attack surface and defenses in software-defined networks[J]. IEEE/ACM Transactions on Networking, 2017, 25(6): 3514-3530.

[36] SCOTT-HAYWARD S, NATARAJAN S, SEZER S. A survey of security in software defined networks[J]. IEEE Communications Surveys & Tutorials, 2016, 18(1): 623-654.

[37] BENTON K, CAMP L J, SMALL, C. Openflow vulnerability assessment[C]//The Second ACM SIGCOMM Workshop on Hot topics in Software Defined Networking ACM 2013: 151-152.

[38] LIN P C, LI P C, NGUYEN V L. Inferring OpenFlow rules by active probing in software-defined networks[C]// 2017 19th International Conference on Advanced Communication Technology (ICACT), 2017: 415-420.

[39] NIST: CVE-2014-9295 Detail[EB/OL]. https://nvd.nist. gov/vuln/ detail/CVE-2014-9295, 2014

[40] KLOTI R, KOTRONIS V, SMITH P. Openflow: a security analysis[C]//IEEE International Conference on In Network Protocols (ICNP), 2013:1-6.

[41] KREUTZ D, RAMOS F, VERISSIMO P. Towards secure and dependable software-defined networks[C]//The Second ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking. 2013: 55-60.

[42] MCKEOWN N, ANDERSON T, BALAKRISHNAN H, et al. OpenFlow: enabling innovation in campus networks[J]. ACM SIGCOMM Computer Communication Review, 2008, 38(2): 69-74.

[43] KIM T H J, BASESCU C, JIA L, et al. Lightweight source authentication and path validation[C]//ACM sigcomm Computer Communication Review. 2014, 44(4): 271-282.

[44] KIRKPATRICK K. Software-defined networking[J]. Communications of the ACM, 2013, 56(9): 16-19.

[45] KLOTI R, KOTRONIS V, SMITH P. Openflow: a security analysis[C]//IEEE International Conference on Network Protocols(ICNP). 2013: 1-6.

[46] SHAGHAGHI A, KAAFAR M A, JHA S. Wedgetail: an intrusion prevention system for the data plane of software defined networks[C]//2017 ACM on Asia Conference on Computer and Communications Security. 2017: 849-861.

[47] DHAWAN M, PODDAR R, MAHAJAN K, et al. Sphinx: detecting security attacks in software-defined networks[C]//NDSS. 2015.

[48] KAZEMIAN P, CHAN M, ZENG H, et al. Real time network policy checking using header space analysis[C]//NSDI. 2013: 99-111.

[49] KAZEMIAN P, VARGHESE G, MCKEOWN N. Header space analysis: static checking for networks[C]//NSDI. 2012: 113-126.

[50] KHURSHID A, ZHOU W, CAESAR M, et al. Veriflow: Verifying network-wide invariants in real time[C]//The First Workshop on Hot Topics in Software Defined Networks. ACM, 2012: 49-54.

[51] MAI H, KHURSHID A, AGARWAl R, et al. Debugging the data plane with anteater[C]//ACM SIGCOMM Computer Communication Review. 2011, 41(4): 290-301.

[52] KIM T H J, BASESCU C, JIA L, et al. Lightweight source authentication and path validation[C]//ACM SIGCOMM Computer Communication Review. ACM, 2014, 44(4): 271-282.

[53] LIU X, LI A, YANG X, et al. Passport: secure and adoptable source authentication[C]//NSDI. 2008, 8: 365-378.

[54] NAOUS J, WALFISH M, NICOLOSI A, et al. Verifying and enforcing network paths with icing[C]//The Seventh Conference on Emerging Networking Experiments and Technologies. 2011: 30.

[55] SASAKI T, PAPPAS C, LEE T, et al. SDNsec: Forwarding accountability for the SDN data plane[C]//25th International Conference on Computer Communication and Networks (ICCCN). 2016: 1-10.

[56] ZHANG X, ZHOU Z, HSIAO H C, et al. ShortMAC: efficient Data-Plane Fault Localization[C]//NDSS. 2012.

[57] AVRAMOPOULOS I, KOBAYASHI H, WANG R, et al. Highly secure and efficient routing[C]//Twentythird Annual Joint Conference of the IEEE Computer and Communications Societies. IEEE, 2004, 1.

[58] MAHAJAN R, RODRIG M, WETHERALL D, et al. Sustaining cooperation in multi-hop wireless networks[C]//The 2nd Conference on Symposium on Networked Systems Design & Implementation-Volume 2. 2005: 231-244.

[59] AGARWAL K, ROZNER E, DIXON C, et al. SDN traceroute: Tracing SDN forwarding without changing network behavior[C]//The third Workshop on Hot Topics in Software Defined Networking. ACM, 2014: 145-150.

[60] AWERBUCH B, CURTMOLA R, HOLMER D, et al. ODSBR: an on-demand secure Byzantine resilient routing protocol for wireless ad hoc networks[J]. ACM Transactions on Information and System Security (TISSEC), 2008, 10(4): 6.

[61] PADMANABHAN V N, SIMON D R. Secure traceroute to detect faulty or malicious routing[J]. ACM SIGCOMM Computer Communication Review, 2003, 33(1): 77-82.

[62] LIU K, DENG J, VARSHNEY P K, et al. An ackno- wledgment- based approach for the detection of routing misbehavior in MANETs[J]. IEEE Transactions on Mobile Computing, 2007, 6(5): 536-550.

[63] MARTI S, GIULI T J, LAI K, et al. Mitigating routing misbehavior in mobile ad hoc networks[C]//The 6th Annual International Conference on Mobile Computing and Networking. 2000: 255-265.

[64] ZHANG X, JAIN A, PERRIG A. Packet-dropping adversary identification for data plane security[C]//2008 ACM CoNEXT Conference. ACM, 2008: 24.

[65] PELEKIS N, KOPANAKIS I, PANAGIOTAKIS C, et al. Unsupervised trajectory sampling[J]. Machine Learning and Knowledge Discovery in Databases. 2010:17-33.

[66] HANDIGOL N, HELLER B, JEYAKUMAR V, et al. I know what your packet did last hop: using packet histories to troubleshoot networks[C]//NSDI. 2014, 14: 71-85.

[67] KAZEMIAN P, CHANG M, ZENG H, et al. Real time network policy checking using header space analysis[C]//The 10th USENIX Symposium on Networked Systems Design and Implementation (NSDI 13). 2013: 99-111.

[68] KAZEMIAN P, VARGHESE G, MCKEOWN N. Header space analysis: Static checking for networks[C]//The 9th USENIX Symposium on Networked Systems Design and Implementation (NSDI 12). 2012: 113-126.

[69] KHURSHID A, ZOU X, ZHOU W, et al. Veriflow: Verifying network-wide invariants in real time[C]//The 10th USENIX Symposium on Networked Systems Design and Implementation (NSDI 13). 2013: 15-27.

[70] MAI H, KHURSHID A, AGARWAL R, et al. Debugging the data plane with anteater[C]//ACM SIGCOMM Computer Communication Review. 2011: 290-301.

[71] THIMMARAJU K, SCHIFF L, SCHMID S. Outsmarting network security with SDN teleportation[C]//IEEE European Symposium on Security and Privacy (EuroS&P). 2017: 563-578.

[72] HONG S, XU L, WANG H, et al. Poisoning network visibility in software-defined networks: new attacks and countermeasures[C]//NDSS. 2015: 8-11.

[73] XIA W, WEN Y, FOH C H, et al. A survey on software-defined networking[J]. IEEE Communications Surveys & Tutorials, 2015, 17(1): 27-51.

[74] JACOBSON V, SMETTERS D K, THORNTON J D, et al. Networking named content[C]//The 5th International Conference on Emerging Networking Experiments and Technologies. 2009: 1-12.

[75] AHLGREN B, DANNEWITZ C, IMBRENDA C, et al. A survey of information-centric networking[J]. IEEE Communications Magazine, 2012, 50(7).

[76] ABDALLAH E G, HASSANEIN H S, ZULKERNINE M. A survey of security attacks in information-centric networking[J]. IEEE Communications Surveys & Tutorials, 2015, 17(3): 1441-1454.

[77] COMPAGNO A, CONTI M, GASTI P, et al. Poseidon: mitigating interest flooding DDoS attacks in named data networking[C]// 2013 IEEE 38th Conference on Local Computer Networks (LCN). 2013: 630-638.

Survey of software-defined networking data plane security

GUO Zhongfu1, ZHANG Xingming1, ZHAO Bo1, WANG Sunan2

1. National Digital Switching System Engineering & Technological R&D Center, Zhengzhou 450002, China 2. Shenzhen Polytechnic, Shenzhen 518000，China

The software-defined network decouples the data plane from the control plane, aiming to introduce network innovation faster and fundamentally automate the management of large networks. Architecture innovation brings challenges and opportunities. Security issues limit the widespread adoption of software-defined networks. Attacks on the data plane may damage the entire software-defined network. The data plane structure and development trends were introduced, data plane security risks were analyzed, vulnerabilities were pointed out, and potential attack scenarios were identified. It also presents two specific solutions, discusses the significance and limitations, and looks forward to future security research directions.

software-defined network (SDN), data plane, stateful SDN data plane, SDN security, data plane security

TP393

A

10.11959/j.issn.2096-109x.2018087

郭中孚（1994-），男，遼寧大連人，國家數字交換系統(tǒng)工程技術研究中心碩士生，主要研究方向為SDN網絡、DDoS攻擊防御。

張興明（1963-），男，河南新鄉(xiāng)人，國家數字交換系統(tǒng)工程技術研究中心教授、碩士生導師，主要研究方向為新型網絡體系結構。

趙博（1981-），男，吉林公主嶺人，博士，國家數字交換系統(tǒng)工程技術研究中心助理研究員，主要研究方向擬態(tài)防御架構。

王蘇南（1984-），男，河南洛陽人，博士，深圳職業(yè)技術學院副教授，主要研究方向為網絡信息安全、數據流分析。

2018-08-24；

2018-09-10

郭中孚，gzf0309@mail.dlut.edu.cn

高安全等級網絡基礎設施關鍵裝備核心芯片及軟件研發(fā)基金資助項目（No.2017ZX01030301）

High Level Security Network Infrastructure Key Equipment Core Chip and Software Development Fund Funding Project (No.2017ZX01030301)