A Survey on the Security of Stateful SDN Data Planes

論文摘要：

本文爲讀者提供新興的SDN帶狀態數據平面，集中關注SDN數據平面編程性帶來的隱患。

I部分 介紹

A.帶狀態SDN數據平面的興起

B.帶狀態數據平面帶來的安全隱患

　　引出帶狀態數據平面的安全隱患問題（好比：有針對的服務否認攻擊和狀態耗盡攻擊以及數據平面攻擊等等），要求系統開發人員或者是應用開發人員遵循如下特徵：

　　在交換機內部存儲每一條流的信息，即狀態，包括狀態的分佈式存儲。

　　在數據平面，數據包到來或者數據平面事件觸發時，有能力改變在交換機中的狀態。

　　交換機基於當前本地的狀態信息能夠自動作出決定策略。

C.貢獻

本文雙層目標：

1）給讀者提供一個新興的帶狀態SDN數據平面

2）經過一個具體的用例應用，剖析相關的安全問題

本篇文獻的貢獻：

第一，對帶狀態數據平面最近提出的計劃方案進行調查（第二部分C節）

第二，對如今的帶狀態SDN數據平面提案的漏洞進行分析（第三部分A節）

第三，利用帶狀態SDN數據平面交換機對潛在的應用攻擊給出具體的證實（第三部分B節），集中在來源於不一樣文獻的使用樣例，而且選擇出樣例強調不一樣的漏洞

第四，闡明繼承自傳統SDN安全問題以及帶狀態SDN數據平面在安全問題的提升的意義（第三部分C節）。

第五，討論可能的防護方法和對設計彈性對抗以前討論過的漏洞的應用的建議，以及未來的研究方向（第四部分）。

 II部分  從SDN到帶狀態SDN數據平面

II-A，簡短介紹SDN，OpenFlow的基本概念。II-B，在OpenFlow第一個標準制定以後的發生的演化。II-C，回顧帶狀態SDN數據平面領域當下最新的技術。II-D，列出了咱們帶狀態SDN支持的使用用例（文中將會用到）。

II-A SDN和OpenFlow:背景

　　SDN就是將數據平面和控制平面分離，簡化大型多供應商網絡控制和管理。

　　 McKeoown 提出一個可編程流表的抽象模型，一般定義爲「匹配/動做」概念，這個模型能在實現上高性能、低耗費，可以支持普遍的研究，而且與不一樣提供商的封閉平臺需求相一致。

　　原始的OpenFlow的匹配/動做概念如圖2所示，它包含三個主要部分，i)一個匹配規則，它使程序員經過匹配任何任意的從2層到4層選擇的頭域，從而指定一條流。ii) 一個或者多個轉發/運行動做，程序員能夠隨意的將它們與考慮的匹配規則聯繫。iii) 一個數據域，設計來收集相關匹配規則鑑定的流數據

 

B.額外的靈活性需求

　　隨着1.0OpenFlow版本的發佈，很快發現最初的OpenFlow提議太過於嚴格，決定在三個方面給予靈活性。前面兩個方向只是與本文主題相獨立，只作簡單回顧。咱們的目的是最有趣的第三個方向（好比，定製帶狀態的操做），在交換機內部的帶狀態處理有很普遍的需求。

1）多流表：從1.1版本，OpenFlow表擴展以支持多管道流表。Reconfigurable Match Table是於2013年 設計，容許很是靈活的映射，基於一樣的TCAM內存，能夠匹配不一樣寬度和深度的表，甚至容許從以前的匹配中計算/抽取出參數，定義匹配規則。這裏的RMT-type硬件使得P4數據平面編程語言興起（II-C2討論）。

2）提升匹配/動做靈活性： 

 3）定製帶狀態OpenFlow擴張：組表（Group tables)多是最傑出的OpenFlow擴展例子，它引入了對定製帶狀態動做的支持。組表能夠分步解決連接失敗問題。最初的OpenFlow配置，在處理鏈路、端口的物理故障時，一般是由OpenFlow交換機喚醒遠程控制器的介入，實例化新的轉發規則，但這期間，一定耗費一些時間，而到達該故障處的包就被丟失了。更新版本的OpenFlow標準引入了一個稱爲快速故障轉移的組類型，特別的解決了這個問題。其餘的有重大意義的例子是爲速率控制的計量器，支持學習類型功能的同步表等等。OpenFlow標準肯定了在交換機內部支持帶狀態操做的需求，以防止遠程控制器參與帶來過分的延遲。

 

 C.帶狀態SDN數據平面的提出

　　圖3提供了一般的帶狀態數據平面的概述，帶狀態SDN可總結爲如下兩個原則：

        i)在交換機內部保留流的狀態信息，而且容許以編程方式正式化數據包級別狀態轉換。

　　ii)給予交換機基於本地流狀態信息（不須要接觸控制器），作出轉發狀態更新決定的功能。

　　一個帶狀態交換機可能須要存儲歷史的進來/出去的包信息，這些信息可能因爲接收/發送相同的新流量包而改變，所以，賊這樣的一個交換機中，一個數據包級事件可能致使流的狀態信息改變。此後，交換機爲相應的流，基於當前流的狀態作出轉發決定。這應該在帶狀態數據平面進行記錄，正如基本的SDN交換機那樣，路由作出的決定是基於一系列以前控制器定義的行爲規則。但是，帶狀態的本質是使交換機可以獨立的基於流的歷史信息選擇適當的動做（action）。

　　 儘管出現技術差別，而且研究工做集中在不一樣的地方（核心平臺、編程語言、編譯器、網絡級框架），底層的靈活性和高效轉發狀態可重構性以及數據平面可編程性是不變的原則。II-C1提出核心平臺，II-C2提出編程框架，表I提供瞭如下討論方案的特色總結。

1) 平臺和使能技術

　　a)OpenState：接下來，將解釋在OpenState中的帶狀態編程模型和包運行程序。XFSM由四個元組（S，I，O，T）構成，S是一個有限集狀態，包括初始狀態S0（默認），I是一個輸入有限集（事件），O是一個有限集輸出（動做），另外T是一個狀態轉換功能（規則）映射<狀態，事件>到<狀態，動做>。在OpenState，每個交換機存儲兩個不同的表（如圖4所示）：1）狀態表基於接收到的數據包的流，存儲當前流的狀態。2）XFSM表基於接收到的數據包的<狀態，事件>信息，定義對應的規則（好比，狀態轉換），爲了解決一個到來的數據包，每個OpenState交換機要執行如下三步：

1.第一步，接收到數據包後，交換機執行狀態表查詢，檢索接收到的數據包的當前狀態（好比，數據包的流所屬的狀態），它使用流ID（好比，源IP地址）做爲狀態表查詢的鍵。若是在狀態表中沒有匹配的鍵，交換機會將「默認」狀態分配給剛進來的數據包（好比 ，流ID）.而後，交換機將檢索到的狀態標籤(或者是默認)附加到包中做爲一個元數據域。

2.第二步是查找XFSM表，尋找<狀態，事件>匹配的規則，執行相關的動做而且按照XFSM表中提早定義的next-state字段更新數據包的狀態域。

 

 

3.最後，交換機基於從前一步檢索到的下一個狀態（next state）域更新它的狀態表相應的流ID。

 　　很明顯，交換機不須要要爲每個接收到的包請求控制器。相反，它基於接收到包的當前狀態和控制器爲每個<狀態，事件>預先定義的規則作出路由決定。

b)FAST:  Fast，在每個交換機內部有預先安裝的狀態機相似於OpenState。FAST設計上，在每個交換機中將會有幾個狀態機實例，每個實例致力於一個特殊的應用。在FAST上的控制平面和數據平面，如下幾個方面不一樣於最初的SDN實現，控制平面有兩個主要的組成部分，（i）一個編譯器（ii）交換機代理。編譯器是一個離線的組件，將狀態機器翻譯成交換機代理，而交換機代理，是在線的組件，管理在交換機內部的狀態機。交換機代理有如下任務：（1）它關注在交換機內部的狀態機功能。（2）它能夠經過接收交換機的更新內容，執行一些本地計算，好比，在速率限制的狀況下，它接收按期的數據來計算流速率。（3）它能夠爲受限制的交換機經過實現一部分的內部狀態機，從而管理內存限制.(4)最後，它解決了在交換機和從之氣之間的交流，而且更新了控制器上關於交換機本地的狀態信息。好比，交換機受到巨大打擊，它將更新交換機代理，隨後更新到控制器。

　　FAST，數據平面包含四個表（圖5 所示）：（i）狀態機過濾 ，（ii）狀態表 （iii）狀態遷移表 (iv) 動做表。在一個交換機內部，有一個狀態機過濾表爲全部的狀態機的全部實例進行過濾。可是，每個狀態機有它本身自己的狀態表，狀態遷移表和動做表。狀態機過率表選擇與進入包相關的對應的狀態機，而狀態表存儲進來的數據包的狀態信息。狀態表是一個哈希表，它映射每個包的頭部（好比，源IP，或者目的IP）到相關的流狀態。每個狀態都與其當前值存儲在變量中，好比，考慮一個數字，某些高位用來存儲狀態，其餘的位用來存儲對應的值。

 c)SDPA:SDPA平臺包含三個表（如圖6所示）（i）狀態表（ii）狀態遷移表（iii）動做表，以及狀態處理模塊，就是所謂的轉發處理器。狀態表的匹配域是當前數據包頭的任意字段的組合，狀態域是一個流的當前狀態，另外指示域是一個」狀態操做說明「，好比GOTO_FT(m)，這意味着以ID「m」進入流表。狀態遷移表以及動做表分別爲當前的流定義了下一個狀態和對應的動做。在SDPA中，每個應用有屬於本身的三個表實例。專用於應用程序的狀態表由控制器在接收到有狀態處理請求時啓動。在這樣的一個樣例中，控制器更新FP的在應用的相關聯的狀態表以及表中的請求字段。

　　在SDPA中,SDN控制器與轉發處理（FP）模塊進行通訊。基於第一次收到某一條流（例如fi）的數據包，交換機將發送包到控制器，決定受否存儲該流的對應狀態。其餘即將到來的流fi的數據包，將會經過本地交換機進行處理，無需與控制器通訊。但是，控制器經過從FP接收更新消息，徹底的控制和更新狀態表的信息（好比，按期的更新或者因爲特殊的事件進行更新），控制器能夠決定何時接收更新（不須要每次狀態遷移進行更新）。

　　當前來講，後面提到的三個帶狀態數據平面是在文獻中提到的。

2）編譯器，可編程語言，架構

　　a)P4:在2014年，在【23】中提出了一個爲配置交換機的抽象轉發模型和一個高級編程模型，做者提出，爲數據包處理的目標獨立抽象模型。就設備類型或者技術來講，程序員不須要知道底層轉發設備的配置信息。所以，項目使用建議的語言編寫，好比（lanuage for Programming Protocol-independent Packet Processors）P4，能夠映射到幾種類型的設備上。

　　　不一樣於OpenFlow，P4提出了一個可編程包解釋器（基於【49】的提議），使交換機可以解析新的頭字段。並且，P4容許匹配/動做選擇並行，或者串行，或者二者皆存。然而在OpenFlow中，它盡能夠串行。P4有兩個主要的操做：（i）配置，配置包的解析器，定義動做的順序，以及肯定一個交換機運行數據包的方式。（ii）數量（Population），定義策略和匹配/動做表的條目。匹配/動做表分爲：(i)進入權，基於這項，交換機決定控制器是否進入。這意味着，每個交換機發送包到某個地方，在那裏，包將被分析（好比，另外一個交換機存儲對應的狀態變量）而後基於它的當前狀態進行處理。SNAP僅在一個物理交換機上存儲每個狀態變量，以防止交換機之間狀態同步。然而，Arashloo指出，若是有興趣分部狀態變量，可能能夠將變量分割爲多個部分，好比s1到sk，每個狀態變量致力於一個端口/IP，而且存儲每一個si在不一樣的交換機上。爲了硬件上實現狀態變量，考慮到效率，延遲，狀態一致性之間的權衡，做者提出使用hash表或者內容可尋址內存。

d)事件驅動程序：在【48】，研究人員提出一種在網絡中爲事件驅動更新的帶狀態運行語義。做者定義「事件驅動一致性更新」爲在事件發生時，將一個配置移動到另一個配置上。事件能夠是要求的變換，在接收到一個，觸發更新的數據包後，一個交換機上的轉發行爲。他們的提議確保，經過網絡，數據包按一致性的配置運轉，而且，在正確的時間，網絡更新全部的交換機。最後，他們想到了事件驅動遷移系統（ETS），它相似於帶狀態數據平面的狀態機（II-C1）。爲了防止在網絡中的衝突（可能因爲不一樣交換機對網絡事件不一樣的觀點致使），咱們提出，新的名爲網絡事件結構系統（NES）。特別的，NES考慮了兩個遷移限制：（1）在網絡事件之間的依賴性（2）在事件之間的兼容性

　　爲了實現帶狀態項目，NES幫助網絡設計者規劃交換機，它規定，交換機可以存儲即將到來的事件，基於網絡事件和對其餘交換機聲明事件路由數據包。特別的，【48】中提議工做以下，（1）將狀態做爲標籤的形式呈現，插入到數據包的頭部。（2）在不一樣的配置上爲遷移定義定義控制，這可能因爲接收有特殊配置的標籤數據包觸發。（3）在本地交換機存儲本地事件做爲狀態（4）基於交換機的本地狀態和交換機的全局狀態見解，改變交換機的配置。特別的，因爲交換機的橫斷，每個包進入網絡，攜帶網絡的一個全局狀態。這種狀況下，若是數據包經過了交換機，它的本地狀態不一樣於數據包，他講被更新爲最新的狀態。爲了提供狀態的一致性，雖然控制器能夠根據全局的網絡視圖 按時地更新交換機狀態，控制器仍然從交換機接收狀態遷移信息。

D.帶狀態SDN的應用程序和用例

　　近年來，研究人員提出，應用程序運行在SDN帶狀態之上，採用II-C1中提出的平臺和編程語言（II-C2）。這一節，咱們介紹了一些帶狀態SDN的應用程序樣例，另外，在本文中引入用例是爲了顯示帶狀態SDN的可用性。咱們隨後將爲咱們的漏洞分析實現一些應用程序和用例以及作出攻擊效果評估。尤爲，咱們提出（i）帶狀態故障恢復，使用交換機的本地狀態，快速進行節點/鏈路恢復 應用程序（II-D1）(ii) HULA，數據平面負載均衡應用（II-D2）， （iii）端口訪問使用用例，訪問控制技術容許用戶在訪問特殊序列的端口後經過防火牆（II-D3）;（iv）DNS 隧道帶狀態檢測，檢測試圖忽略訪問策略，使用DSN信息（II-D4）到達主機的用戶。（v）UDP 泛洪帶狀態緩解，這將識別發送異常UDP數據包數字 的用戶（II-D5）。

1）帶狀態故障恢復：

　　在【31】中，提出了基於OpenState的一個獨立控制器帶狀態 鏈路/節點 故障檢測和恢復方案。這個方法使用標籤對數據包進行標記，在檢測到一個節點或者鏈路故障後，爲了與以前的節點通訊，爲隨後的包使用繞道路徑。

　　這個協議運行以下：讓咱們考慮一個方案，經過帶狀態的SDN交換機網絡，源主機H發送一個數據包pi到目的主機I，在乎識到鏈路或者節點故障以後，離故障最近的節點用標籤（好比MPLS標籤）標記同樣的數據包pi，標籤包含故障事件的信息（操做（1）如圖7所示），代替發送一個故障的通知。這個標記的包按照最初的路徑路由（發送）返回到最方便從新路由的節點，好比節點N（圖7操做（2））。在接收到一個標記的包後，節點N按照它的狀態表，爲對應的流執行狀態遷移，而後，從新路由（經過以前定義的可選擇路由）這條流隨後的數據包（圖7操做（3））。當到達路徑上的合併節點時，標籤將會從包上移出，另外包也將會轉發到目的主機I（圖7操做（4））。這個方案的帶狀態運行特色容許交換機從新路由數據包，同時無需給控制器報告鏈路故障，由於每個節點（好比交換機）維持每一條流的狀態，它能夠自主的決定轉發的路徑（好比，正常的或者繞道的）。

 

 

 2) HULA：

　　最近，在【30】的研究中提出，HULA，針對數據中心的數據平面負載均衡技術，在可編程交換機頂層採用該技術以及P4可編程語言，好比RMT【27】。 在HULA，每個交換機將前往目的地址（Top of Rack ）ToR的下一跳的信息，保留在下一跳最佳路徑優化表中。最佳優化表的條目信息相似於<DestIp,BestHop,PathUtil>的形式。爲了找到最佳的下一跳節點，每一個ToR交換機經過網絡按時地發送探測信息，收集全局鏈路優化信息。而後，基於收取到的探測信息，每一個交換機利用最佳下一條，自主的更新最佳路徑優化表，對全部的現有的路徑來講，這均衡了通往目的地的負載。

 　　每個探測包的頭部包含兩個域：（i）24bit的torId,好比，產生探測信息的ToR交換機驗證碼，（ii）一個8bit的minUtil，爲flowlets(好比 流的子份量)攜帶了最佳優化路徑效用。一旦一個交換機從端口i接收到一個探測信息，它首先計算出在端口i上的maxUtil，做爲minUtil和本地測量的鏈路效用的最大值。而後，交換機計算出在maxUtil和在利用率表中先前相應的PathUtil記錄值之間的最小值。若是maxUtil是最小的值，交換機用maxUtil和torId更新在交換機內部的最佳路徑利用率表的PathUtil和BestHop字段的值，並且，交換機產生新的探測配置，最新的torId和PathUtil，經過網絡使用簡單的無環路循環策略進行傳播。圖8展現了HULA的探測傳播策略，在一個三層網絡上，開始於ToR節點，ToR1。聚合節點（A1-A4）轉發接收到的探測信息給下游的節點（好比，ToR），可是不轉發給上游節點（S1-S4），除非探測信息接收自一個ToR節點（ToR1在圖8所示）。當探測信息到達一個ToR節點，它中止被轉發。

 

3）端口訪問：

　　Bianchi在【18】中提出，將端口訪問看作是一個展現OpenState結構和操做的應用程序。僅當它們成功的對一系列以前定義的不一樣端口進行鏈接嘗試以後，，端口訪問才容許帶狀態的防火牆給一臺或者多臺主機在具體的端口上受權（本文舉例爲，22），這樣的有序序列表明瞭在防火牆和主機之間的「共享祕鑰」。

　　看這個案例，主機H（用源ip區分）試圖創建一個SSH回話（默認22端口），經過一個防火牆F，F在一個OpenState交換機上實現。在咱們的例子中，讓{3306，1810,450}做爲訪問的端口序列。若是主機H發送正確的三個請求序列進行鏈接，防火牆F將驗證主機而且打開22端口，不然請求將被丟棄。圖9闡釋了這樣的一個例子。

　　正如II-C1中提到的，OpenState保留了一個XFSM表，而且在交換機內部實現了擴展狀態機在OpenState端口訪問實現中，XFSM表與圖4很類似，好比，規則是爲五個事件定義的（好比，數據包在3306,1810,450，22等端口接收），四個狀態（好比Default，State1，State2，Open），以及兩個動做（好比丟棄和轉發）。從主機H接收到一個包後，交換機執行狀態查找程序，以檢索出當前包的狀態。開始爲Default狀態，僅當主機H訪問防火牆F序列中指望的下一個端口時，狀態遷移纔會被觸發。這致使一個的丟棄動做，而且狀態遷移爲State1,。新的狀態將被寫入狀態表中對應主機ID(源IP)的狀態。這個程序一致運做直到主機H訪問了全部指望訪問的端口，而後，它的狀態將被更新爲Open。這個狀態下，在接收到22端口的請求時，防火牆爲主機H的用戶打開端口。在任何其餘狀態，若是主機發送一個請求到不正確的端口，它的狀態將會被回滾到Default狀態。在OpenState，做者假設XFSM表按照規則的優先級進行排序。並且，他們認爲在狀態表中的超時字段，可用在狀態遷移到下一個狀態（好比，下一個端口訪問）：若是用戶在以前定義的超時時間內，不訪問正確的端口，它的狀態一樣將回滾到Default狀態。

4) DNS 隧道帶狀態檢測：

　　DNS帶狀態檢測程序運行實例解釋SNAP帶狀態框架。在DNS帶狀態隧道攻擊案例中，惡毒的用戶嘗試濫用DNS信息來經過訪問策略，從而發送數據。正如【16】所述，爲了檢測到DNS隧道嘗試，如下幾步應該被執行（如圖10）。

　　i)給每個客戶機H分配一個計數器cH，以追蹤全部解析的對應主機的IP地址。

　　ii)當客戶機接收到DNS的反應時，cH增長，每當它使用一個解析地址時，cH減一。好比，當客戶機發送一個包給相應的IP地址。

　　iii)爲cH考慮一個閾值，而且當某個主機的計數值高於閾值時，將該客戶機報告爲惡意客戶機。

　　爲了執行第二步，SNAP在基於數組的變量中，維護髮往H的全部的已解析的IP地址。特別的，SNAP交換機保留了一個變量，orphan,它映射了每一對源目的地址，<src,dst>，其值爲boolean類型。入股客戶機H從DNS接收到一個已解析的response，目的地址是發往IPI，<ipH,IPI>的值將變爲True，而且cH的值將會增長（圖10中的操做1和操做2）。當H發送一個包給I時，交換機聯繫<IPH,IPI>檢查狀態，若是狀態爲True，將這個值設置爲False，而且減少cH的值，意味着主機H實際上「使用的」信息已經包含在已接收DNS記錄中（圖10操做3）。

 

 5）UDP洪泛帶狀態遷移：在【51】中提出，是關於帶狀態數據平面使用用例的另一個例子，使用SNAP實現。Arashloo在【16】中提供了一個算法來區分UDP洪泛攻擊，,主要經過區分用戶是否發送不合法的UDP包數值。最後，做者考慮了幾個變量：（i）計數器cudph用來表示來自主機H的udp數據包（好比，每個包的源IP），(ii)變量udp-flooder[H]，用來保存客戶機H的狀態；（iii）閾值T用來未來自源IP地址的UDP數據包的數值合法化。

 　　當主機H發送一個UDP包，SNAP策略首先查看H的狀態，判斷udp-flooder[H]是否已經被認爲是一個惡意的用戶。若是udp-flooder[H]是True，算法將丟棄這個包。不然，若是udp-flooder[H]是False，算法增長cUDPH的計數值，若是檢查到cUDPH=T(閾值)，算法將丟棄數據包而且將udp-flooder[H]設置爲True。

　III帶狀態數據平面的安全問題

　　從一個高度的視角來看，全部的帶狀態SDN方案（本文中的）有這樣的一個原則：它們都將流的狀態

 推送到數據平面。這使得每個交換機自主做出智能的決定，因爲減小了數據平面與控制平面的交互，從而提升網絡性能。然而，儘管帶狀態平面的優勢很明顯，咱們認爲，在安全方面，當前還存在不足。

　　III-A，強調了因爲帶狀態SDN數據平面固有的特色致使的肉凍，III-B描述了潛在的攻擊方案，可能利用帶狀態SDN數據平面的漏洞進行攻擊。III-D，用三個使用樣例，展現攻擊的可行性。最後，一個不變的事實是，帶狀態SDN的提出並不意味着傳統SDN的安全問題被解決，III-C簡短的談論了傳統SDN的漏洞。

A. 漏洞

　　　通過分析如今的帶狀態SDN數據平面提案和應用帶狀態SDN的應用，咱們肯定了四類主要的漏洞類型。III-A1：未綁定流狀態內存分配，III-A2：可觸發的CPU密集操做，III-A3：缺乏驗證機制；III-A4，缺乏集中狀態管理。隨後，在III-B中，咱們提供攻擊的詳細說明，利用這些漏洞，從現有的SDN帶狀態數據平面文獻，選出三個實際的攻擊樣例.

　　1）未綁定流狀態內存分配：爲了數據平面可編程（好比，擁有帶狀態交換機），每一個帶狀態SDN方案必須分配內存空間來追蹤進入的流產生的狀態。依賴於具體的帶狀態SDN方案，數據結構用於保留狀態信息被定義爲「狀態表」【18】-【20】，或者基於數組的變量【16】。爲了簡化，本文其餘地方使用「狀態表」來表明用於狀態存儲的數據結構。

　　爲了攻擊一個交換機，一個攻擊者可能利用潛在的每一個交換機要求的巨大內存空間，以存儲流的狀態信息，來耗盡交換機的內存。

2）可觸發的CPU密集操做：第二個攻擊向是指，攻擊者有機率能夠強制交換機上的CPU密集操做進行執行。好比，中央控制器必須對網絡有徹底的控制，從而驗證網絡功能【19】。在這個方案中，控制器平面要求接收網絡中關於每一個事件的更新，好比任一狀態的遷移。

　　在這個例子中，一個攻擊者能夠經過前置交換機持續更新控制平面，操縱DoS攻擊，耗費大量的計算資源，從而交換機不可以對包進行處理。應該注意的是，在資源耗盡的狀況下，一些攻擊可能與系統結構有關，而其餘的可能來自實施不當的或者程序員定義的策略。

 3）在數據平面缺乏驗證機制：

　　很是不幸，如今的方案在安全上的關注太少，特別的，在交換機和數據平面之間缺乏一般的認證/加密機制。

　　利用這個漏洞，攻擊者可能模仿一個誠實的交換機而且將虛假信息注入到網絡中，或者是操縱在交換機之間傳遞的信息內容，結果使交換機基於虛假的內容作出決定。這個漏洞能夠被利用，而後形成幾種類型的DoS攻擊，好比在網絡中的虛假鏈路錯誤致使總體網絡性能的降低。

　　4）中央數據平面狀態缺乏管理：狀態不一致其實是存在於傳統網絡的一個擔心，尤爲是當涉及到物理地分發控制平面【52】-【54】。但是，在帶狀態SDN上的在數據平面級別的狀態分佈變得更加更要和有挑戰性。由於沒有中央實體：（i）涉及數據平面時間的運行（ii）對交換機內部的狀態同步負責。特別的，由於接收到的包引發的狀態遷移，攻擊者有權力去影響和強制狀態遷移，致使網絡變成不一致的狀態。

　　咱們認爲，狀態不一致性和容易受到攻擊與交換機內部的狀態變化是沒有關係的。然而，事實是，並無控制器同步狀態，這可能致使網絡中的狀態不一致性。爲了處理這個問題，有人可能提出，保持控制器更新在交換機內部實現的狀態機當前的流。然而，應當注意的是，控制器更新程序執行應當很是當心，以防引入新的潛在的瓶頸，而且所以致使攻擊。狀態不一致性可能因爲虛假的包注入攻擊或者是因爲不合適的功能實現致使。儘管如此，這可能致使網絡內部的安全或者性能問題。

B. 攻擊舉例

　　在這一節中，將利用III-A所提的漏洞對如今的帶狀態SDN方案進行攻擊。咱們考慮三個在II-D中所提的使用樣例應用。好比，端口訪問（II-D3），UDP洪泛遷移（II-D5），以及帶狀態故障恢復（II-D1），和顯示潛在的攻擊。對每個攻擊，咱們列出利用的漏洞。咱們選擇三個使用樣例,由於設計簡單，而且易於實施。這讓咱們對實驗有更多的控制權。咱們在OpenState平臺的基礎上實現全部的用例，而且提供實驗的結果展現攻擊的可行性（實現細節與Appendix相關）。表II展現了考慮的攻擊和利用的漏洞之間的映射關係。

 　　另外，在III-B1，咱們提供不一樣的用例，這些用例利用未綁定流狀態內存分配漏洞，這將致使內存溢出攻擊。在III-B2，咱們介紹對用例應用程序（II-D1）的從新路由攻擊，利用缺乏驗證機制漏洞（在III-A3中闡述）強加狀態不一致性。最後，在III-B3，咱們談論了CPU耗盡攻擊，它利用CPU緊密的操做漏洞觸發（在III-A2敘述），可能致使分佈的狀態不一致性。每一節，咱們提供必要的準備工做和攻擊案例。讀者可能經過咱們在這一節提供的攻擊的實現和實驗評估瞭解到Appendix的詳細信息。

　　1）交換機內存溢出攻擊：關於帶狀態SDN簡單高效的攻擊是洪泛交換機狀態表，使狀態表持續的擴展和更新。另外，儘管一般沒須要保留全部通過交換機的流，攻擊者能夠聰明地在具體的應用上強制這個行爲，而且耗盡交換機內存，形成內存溢出攻擊。這就是端口訪問用例（III-B1a），以及洪泛狀態遷移（III-B1b）。

　　a）端口訪問攻擊：咱們提出一種針對訪問應用的攻擊（咱們在II-D3中介紹）。

　　攻擊模型：咱們的攻擊在端口訪問應用來看，能夠將攻擊者分爲兩個類型：

　　知情的攻擊者。攻擊者直到正確的訪問端口序列，這個信息能夠從幾個方式得到，好比嗅探流量。

　　未知攻擊者。攻擊者不知道確切的端口訪問序列。

　　考慮這兩種攻擊類型，咱們將描述可能的內存溢出攻擊。

　　知情的攻擊者場景：假設A是一個知情攻擊者，如圖11所示，A發送一個大量的來自某一些虛假的IP地址的鏈接嘗試（包）給第一個預約義的端口序列（好比3306）給換機F。在從源IP接收到一個包以後，好比1.2.3.4，F檢查它的狀態表，查找出進入的流的狀態。若是對於IP地址沒有記錄，F爲源IP地址分配一個Default狀態，而後在XFSM表執行查找操做。。如今，因爲全部到來的包發給了正確的端口，全部進入的包的狀態（好比，對應的IP地址）將更新到下一個狀態（好比：狀態1：3306端口訪問）。所以，咱們在交換機的狀態表中有更多的條目。有意識的攻擊者可以強制在狀態表中產生成千上萬的狀態記錄，而且致使交換機內存耗盡。

 　　未知攻擊者：假設攻擊者A不知道訪問序列。在這種狀況下，A能夠經過從虛假的IP地址集合（好比IP屬於D1=[128.0.0.1-128.0.255.254]）產生大量的數據包，發送給F的全部端口，好比從65535個包來自於65535個虛假IP地址（如圖12所示）。假設選擇的IP地址以前沒有使用過，F對全部的IP分配默認的狀態而且執行XFSM查找。注意，若是程序員因爲不合適的實現，存儲來了默認的每條流的記錄（好比，每個即將到來的流，在表中進行一次記錄），而後，狀態表中的結果將達到65535個記錄，若是攻擊者接着對F的端口使用洪泛攻擊，這將陳宮完成內存溢出攻擊。然而，一個正確的實現，對應的默認狀態應該只有一個記錄。如今，對於來自IP1.2.3.4的包可能會發生兩種狀況：

　　意外的，A訪問了正確的端口（好比3306），這種狀況下，IP1.2.3.4的狀態將更新到下一個狀態（好比狀態1）。　　

　　A沒有訪問正確的端口，它的狀態將繼續爲默認。這種狀況下，不須要保留IP1.2.3.4的狀態。

　　如今，由於A能夠按時的簡單的執行數據包的洪泛。她能夠選擇以下的IP地址：

選擇一個不屬於D1集合的IP：這種狀況下，它可能有概率訪問正確的端口而且依據IP地址（好比：5.6.7.8）對於在狀態表中的正確訪問的端口產生一個新的記錄。

選擇一個IP屬於D1：若是她以IP1.2.3.4訪問一個錯誤的端口，基於在【18】中闡述的狀態，狀態表這個IP的狀態變爲Default。注意，若是咱們不當心設計了這樣的一個接口，並不是重寫狀態表中的記錄（其實是從狀態表中移除），交換機可能爲1.2.3.4設置一個新的默認狀態。

　　一旦交換機內存被攻擊者利用，交換機將不可以處理新到來的數據包，這些數據包可能來自合法的用戶。如今，交換機決定執行如下的一個動做：

　　將包發給控制器，這種狀況下，交換機的行爲相似於傳統的SDN。

　　將包丟棄，這將致使DoS變成一個合法的用戶。

　　在狀態表中重寫已有的記錄，其中的挑戰是如何解決記錄的重寫問題。

　　爲了解決端口隨機掃描攻擊，Bonola提出，考慮新的狀態，稱之爲攻擊狀態。做者提出度量的M1來計數主機使用SYN的數量。若是交換機經過一條流探測到端口掃描，它將更新對應「要被攻擊」流的狀態，將對應的主機阻塞2分鐘，而且彈出警告。但是，這個方案不能用到咱們提出的內存耗盡攻擊。

　　b)攻擊UDP防洪遷移：這裏，咱們展現了帶狀態UDP洪泛遷移應用的漏洞（在II-D5介紹），能夠同內存耗竭攻擊做對比。

　　攻擊場景：如II-D5所示，SNAP存儲了來自每一個客戶端的UDP包的數，以及對應客戶端的狀態。好比，若是客戶端是一個UDP防洪者等。所以，若是一個攻擊者發送大量來自不一樣的IP地址的UDP數據包，SNAP將會爲每個不一樣的IP地址分配狀態變量和爲計數器。這個狀況下，由於這兩個變量，攻擊者很容易就將脆弱的內存耗竭。

　　爲了減輕這樣的攻擊，有人想到使用爲計數器和狀態變量設置一個過時時間。這意味着，若是交換機在預先定義的時間裏（好比過時時間值），未接收到來自客戶機H的任何UDP數據包，交換機能夠釋放分配給客戶機H的內存空間。但是，「聰明的」攻擊者能夠定時的發送UDP數據包，從而強制交換機保留對應主機的狀態。

　　2）狀態不一致攻擊：另外一個對於帶狀態SDN可能的攻擊是狀態不一致攻擊，這來自於缺乏驗證機制漏洞，而且可能致使事件欺騙攻擊和從新路由攻擊。如以前解釋的，在帶狀態SDN中，每個交換機基於對應流的<state，event>信息對到來的數據包作出路由決定。另外一方面，在網絡中的數據包級別事件，將致使在交換機內部的具體的流形成狀態遷移。所以，一個攻擊者能夠輕鬆地執行虛假包的注入而且對某個具體的流強制狀態遷移。對於相同的流，不一樣的交換機來講，這將致使不一樣實例存儲狀態的不一致性。這樣的狀態不一致性，將強制交換機作出攻擊者須要的路由決策。

　　如下，咱們將經過帶狀態故障恢復使用用例（II-D1）更清晰的闡述這個攻擊。特別的，咱們展現了咱們是如何經過在帶狀態交換機引起不一致狀態，發動重路由攻擊。值得注意的是，這樣的攻擊一樣能夠應用到任何帶狀態負載均衡應用程序，這些應用程序利用交換機之間的內置信號。好比，在【30】中。在負載均衡場景，一個攻擊者能夠重定向網絡負載到一個不恰當的鏈路上，引起鏈路故障。

　　a)重路由攻擊：咱們考慮在【31】中提出的（在II-D1介紹的）改道計劃方案，咱們用它來闡述攻擊者如何執行重路由攻擊。

　　攻擊場景，在這個場景，一個攻擊者能夠注入虛假數據包，用「損壞鏈路」標記，而且欺騙鏈路故障事件以下：攻擊者竊聽在兩個節點之間的流量變化（好比，節點N和如圖7的偵測節點），捕獲一個數據包，在數據包插入一個標籤，說明轉發節點已被破壞，從而標記這個數據包，而後將數據包返回給N。在接收到僞造標記的包後，N爲對應的流和執行狀態遷移而且繞過全部依賴分組。

　　基於以上所解釋，對於一個攻擊者可能很容易執行重路由攻擊，而且對網絡形成不一致性和延遲，以及形成下降性能。這個攻擊實際上可能因爲在兩個帶狀態SDN結構交換機內部的流量變化，沒有認證機制和加密機制致使。注意，當全部交換機是可信的，這個攻擊不可以應用在網絡中。

　　3）CPU耗竭攻擊：另外一個對於帶狀態SDN可能的攻擊是具體應用攻擊。如III-A2所述，在一些網絡應用上，如網絡監控和DDoS偵測，控制器須要對網絡的全局視圖進行完整更新。爲了這個結果，交換機可能設置成每次更新狀態遷移，就更新控偶之器（如【19】所示）。這樣的場景下，攻擊者能夠以兩種方式，經過在交換機內部強加大量的狀態遷移。

　　1.發送大量的數據包致使在狀態表內部插入新的流表。

　　2.發送幾個關於正在進行的流的數據包（在狀態表中已經有記錄），這個結果致使每一個對應的流的數據包狀態遷移。

　　這兩種狀況下，交換機應該更新控制器上流的新狀態，致使大量的數據包運行，以及在交換機與控制器之間數據包的交換。這將致使交換機的CPU運行能力耗竭。由於CUP每一秒僅可以運行必定量的數據包，因爲上述的攻擊，狀態數據包的運行將會失敗。

　　另一個這樣的攻擊的後果是在交換機和控制器之間狀態不一致性。讓咱們考慮這樣的一個場景，交換機s1是一個高端交換機，運行着指令監測系統。特別的，s1的責任在於偵測惡意的IP地址 和更新控制器。控制器應該爲偵測到的惡意IP地址，在交換機內部安裝新的規則。如今，攻擊者A想訪問網絡資源。他有關於s1的瞭解，攻擊者A（或者某些同謀）能夠執行CPU耗竭攻擊，這種狀況下 ，由於s1遭到攻擊，它將不可以處理任何數據包以及更新控制器。所以，A將可以s1訪問網絡。

C.從傳統SDN遺留下的安全問題

　　帶狀態SDN經過提出帶狀態數據平面從而改變了傳統SDN的設計。由於這個緣由，帶狀態SDN天然的繼承了某些漏洞，特別是關於應用層的，以及與控制平面交互的漏洞。接下來，咱們總結傳統SDN存在的漏洞，討論：（i）那些漏洞仍然影響這帶狀態SDN（ii）哪些帶狀態SDN帶來的安全改善是適用的。（iii）帶狀態SDN新的挑戰。這節，有限定的對SDN控制平面和數據平面漏洞進行分析（由於他們與本文的主題相關），這些漏洞對於帶狀態SDN沒有顯而易見的映射關係。讀者對於傳統SDN的安全問題若是有興趣能夠看【2】-【7】文獻。

　　表III提供了主要的傳統SDN漏洞的總結，是從【2】-【7】中的調查中提取出來的，加上了這個工做中發現的流動。對於傳統SDN的漏洞，表III的漏洞一樣影響帶狀態SDN。儘管本文如今的工做主要在於傳統SDN的攻擊和安全問題，這節將集中討論傳統SDN和帶狀態SDN的漏洞。所以，表III源於【2】-【7】中報告的攻擊（由於一個漏洞能夠致使更多的攻擊/事件）。咱們將表III列出的漏洞分爲三類（好比，控制平面，數據/控制平面，以及數據平面）。

　　1）控制平面漏洞：帶狀態SDN致使SDN控制平面實際上不變化，所以繼承了許多傳統SDN的漏洞。另外，儘管帶狀態SDN將一些狀態移到了數據平面，核心邏輯主要由控制平面管理；因此，因爲全局網絡視圖的不一致性產生了潛在的問題。好比，在分發控制器上，致使控制器碰撞和控制器失聯（見【52】-【54】）。然而，將狀態移動到數據平面，可能消除不少特殊應用的漏洞。好比，當端口訪問應用（在II-D3提出的）。這種狀況下，由交換機執行的操做徹底是本地的，而且與控制平面維護的不一致狀態相獨立。

　　2）交叉數據平面/控制平面漏洞：就安全來講，與傳統SDN相比，帶狀態SDN的主要提升在於減小了數據平面和控制平面之間的交互。因爲這個，帶狀態SDN的設計解決了由SDN控制邏輯集中引起的擴展性相關的問題。一個典型的攻擊是控制平面溢出攻擊。這個攻擊的目的在於致殘控制平面，主要由數據平面和控制平面交互需求太高致使。攻擊者可以經過產生大量不一樣的流（使用虛假Ip地址）發動控制平面溢出攻擊；這將致使數據平面交換機將不少的packetIn請求轉發到控制器，可能使通訊鏈路飽和，或者使控制器內部資源飽和。儘管研究人員提出【56】-【58】數據平面解決方案來解決這個問題，減輕控制平面飽和仍然是SDN環境遺留下來的一個挑戰。經過設計，帶狀態SDN對這個威脅變得更有彈性，由於它的帶狀態本質限制了數據平面和控制平面之間的通訊需求。

　　3）數據平面漏洞：在數據平面級別，帶狀態SDN天然地減輕了傳統SDN的兩個主要漏洞：（1）流信息泄露，經過定時側通道【59】；在不少例子中，可耗盡TCAM主要用在流表。漏洞（i）可能被攻擊者用於得知網絡的配置。這多是因爲控制平面爲了安裝規則致使時間的開銷過大，好比，當一個新進來的流不能匹配交換機中任何的流表【60】。然而，帶狀態SDN，這將不會發生：控制平面能夠編排帶狀態交換機，使其自動作出關於如何處理到來的流的決定，而不須要與控制器聯繫。這明顯地下降了攻擊者依賴定時信息進行攻擊的攻擊面。同理，藉助編程帶狀態SDN交換機，利用漏洞（ii）的攻擊被隱含的下降了；另外，帶狀態平面的功能對流表來講，能夠下降所需的變化。注意，儘管漏洞（ii）本質上與III-A1描述的漏洞相似（好比，未綁定流狀態內存分配），可是，後者與SDN交換機在數據平面保留數據使用的數據結構相關，這可能不一樣於傳統SDN使用的流表。最後，在III-A2中提到的漏洞可能影響傳統SDN。爲了應對控制平面溢出攻擊，其中，攻擊者可以強制SDN交換機之間進行通訊。攻擊不只對控制平面有影響，同時對於交換機自己也有影響：交換機必須經過TLS加密渠道發送它的packetIn信息，而且，須要使用加密操做。加密的使用對於被攻擊的交換機增長了不可忽視的開銷，形成DoS攻擊漏洞。

IV.討論及將來的工做方向

　　在第III節，咱們討論了針對帶狀態SDN數據平面主要的漏洞以及可能的攻擊。表IV總結了所描述的存在的安全問題，這些問題基於在II-C中引入的不一樣的帶狀態方案類別進行分類。漏洞列包含了每個帶狀態SDN數據平面類別的漏洞（III-A介紹），「漏洞動機」描述了每種漏洞出現的緣由。「潛在的攻擊」列展現了III-B所述的攻擊運用到相應的分類。最後，「Remarks」列列出了一個或者多個應該被考慮的原則或者重點，本節將討論。儘管本文的目的在於提出關於帶狀態SDN數據平面安全問題的認識，爲了更加完整，本節咱們提供有用的實踐的原則，這些原則將應用到SDN帶狀態的安全認識設計上，而且得出一些未來的可能的研究方向。

　　A.與其餘網絡環境的類比

 　　固然，儘管帶狀態SDN有新興的趨勢，至少從安全的挑戰來講，它與傳統網絡系統完成的工做具備類似性，它依賴於交換機的狀態經過數據平面的事件（好比，特殊類型的數據包的到來等）進行動態的設置和更新。換句話說，本文開篇所述的帶狀態SDN數據平面的安全問題，某種程度來講，可能須要認爲是在如今已創建的網絡環境存在的「超級」安全挑戰。好比，以太網【33】或者最近的信息中心網絡（ICN【61】）。如下，咱們將經過簡短的安全問題的共性縷清這個問題，安全問題影響到兩個例子背景，以及相關的遷移技術，遷移技術可能激發更多一般的SDN場景的適應性。

　　1）以太網：以太網交換機有動態更新轉發表，映射MAC地址到交換機的端口，在這，相關的幀必須被轉發。以太網幀是基於目的MAC地址進行轉發的，可是，同時，轉發表經過動態學習程序動態地創建和更新。一個包到來後，表經過增長（或者修改）一條流表項進行更新，這個流表項匹配MAC地址到交換機的輸入端口，好比，包接收到的端口。這個表，一般定義爲Content Adddress Momory(CAM)，因爲一般在一些硬件（HW）中實現，可能存儲一些其餘的信息，好比超時值或者虛擬 局域網認證。在CAM表結構和用於帶狀態SDN的帶狀態表概念之間的類似性是很明顯的，由於這二者都在交換機內部執行自動驅動對數據包進行更新。儘管以太網有幾個完善的特色，好比靈活性，彈性，簡易性【62】，它易於多個DoS和欺騙攻擊，好比MAC泛洪攻擊，ARP中毒，端口偷竊以及資源耗竭攻擊。值得注意的是，在遷移技術中，到目前爲止，最普遍的、最實際的是創建端口安全，這是本地監測技術運行於以太網交換機頂層的本質。它在交換機端口監測MAC地址，以限制在相同端口學習的最大的MAC地址數量，而且防止局域網MAC地址欺騙和轉發表溢出攻擊【33】，【63】。以太網例子建議交換機級別（本地）監測是第一個候選的減緩方法，同時也適用於帶狀態SDN一般例子。

 　　

　　　　2）信息集中網絡：ICN是一個新興的網絡範式，在網絡層，使用數據集中發佈/訂閱取代了傳統的IP-集中網絡通訊。在不一樣的ICN實例之間，Content-Centric Networking(CCN)【64】最有表明性和肯定性。CCN和NDN卻別在於設計和實現，可是有共同的原則。在ICN中，內容是經過生產者產生的，而且由消費者請求；內容經過數據包傳送給消費者，每一個請求都是經過一個interest packect。每一個數據包都是經過分級名稱（好比com/cnn/news）進行獨特的處理，這些在interest packets包中進行了配置，而且用於路由。ICN路由器在內部的Pending Interest Table（PIT）結構中保留了關於到來請求的狀態。經過哦這個表，ICN路由器記錄接收到的interest的接口I，以及由interest數據包攜帶的內容N。路由器使用另外一個名爲Forwarding Interest Base（FIB）的表，根據名字前綴和相應的接口來路由interest包。每一個數據包經過相反的路徑（根據對應interest包來的路徑）路由回到用戶：當一個數據包被路由器接收，它檢測在PIT內部的匹配項，若是一個匹配被找到，路由器從這個接口轉發這個數據包回到接口知識的條目，而且移除流表項，不然，它簡單地拋棄數據包。很容易發現ICN路由器使用的PIT數據結構與帶狀態SDN使用的狀態表相似。另外，研究人員顯示， PIT能夠在帶狀態SDN數據平面的頂層實現【66】。而ICN相比於基於Ip的網絡有幾個有點，好比低延遲，以及改善可擴展性以及移動性【67】，【68】，他介紹了新的安全挑戰。在ICN中要求的PIT狀態管理使它容易遭受DoS攻擊，好比，資源耗竭攻擊活狀態不一致攻擊【68】-【69】。安全社區已經考慮了這些安全問題而且解決一部分問題。好比，在【72】提出的遷移方法防止了DoS攻擊路由器內部的PIT。最後，許多方法提出，在ICN領域已經依賴基於本地監測方法【68】，好比路由器上使用本地的度量，好比PIT 用法【72】，interes 【追蹤】、限制請求率【74】。

B. 走向可編程監控

　　正如以前談論的以太網交換機和ICN路由器安全性的討論所預料的那樣，對於帶狀態SDN安全威脅來講，本地監控技術的彈性彷佛是天然而然的首選防護策略。一般的方法是設計監控技術，運行在網絡節點中，而且設計以區分異常的流量模式和針對帶狀態SDN的攻擊的發生。本地監控技術和相關的特色萃取以及數據收集可能在未來組成更加複雜、廣闊的網絡監控架構，這個架構涉及SDN控制器以及控制器對全局網絡狀態的視圖。

　　但是，在帶狀態SDN和傳統的網絡場景（好比以太網或者ICN交換機）之間的關鍵差別是，在隨後的例子中，網絡節點操做是先驗的，所以，監控技術能夠專門地設計用以監控特殊的異常和與特殊網絡節點操做相關的攻擊。相反地，帶狀態SDN中的節點行爲並非提現配置的，而是任意編程的（好比，經過狀態機【18】，P4程序【23】，或者其餘的II-C討論的數據平面編程概念）。換句話說，在帶狀態SDN數據平面的監控問題的空間要比對應的傳統網絡節點的操做解決問題的空間更寬廣。

　　咱們提出一個引人注目的解決方法，這個方法包含設計互補的技術以及方法學，從而不只容許網絡節點的可編程，同時能夠進行監控。研究的挑戰是概念設計以及可編程監控任務平臺，爲了容許網絡應用開發人員可以設計量身定製的監控策略以經過節點操做進行部署。本質上，關於SDN範式，對應的軟件定義監控範式可能爲應用設計者提供簡易使用的模型，原語，以及語言，從而在編程網絡節點上部署監控算法。在這個方向上的初步成果能夠在【28】中找到，Bonola提出了基於擴展有限狀態機的編程監控方法，它容許編程人員正式地描述和執行實時、多步驟、定製的本地監控操做。

　　另外一個有趣的前瞻性的帶狀態SDN網絡節點的演化是同時支持轉發和監控任務，包括在硬件（HW)中以線速、更加及的源於設計節點。這些原語不只僅是轉發，另外容許對每條流進行抽取特色和數據收集。

C.帶內信令和可驗證狀態轉換的安全

 　　利用帶狀態SDN數據平面的能力，最近提案爲故障恢復或者負載均衡提供方法，在交換機之間使用帶內信令；經過控制數據包或者是最初的數據包做爲帶內信令（最終用控制信息加入標籤或者標記）。然而，如III-A和III-B所述，對交換機之間交換的數據包，缺乏身份和完整性驗證機制，會被攻擊者欺騙或這注入惡意的控制包到網絡中，而且可能致使DoS攻擊。

　　爲了解決這個問題的研究方向是爲內部交換機的安全設計一個信任模型，以及爲驗證信令數據包的完整性和出處進行加密。不幸的是，身份、完整性驗證機制的狀態加密可能很難得到線速包運轉速度，而這，多是一些應用所需求的。

D.狀態一致性檢測

　　交換機內部的流的狀態遷移是基於數據包級別事件，控制器對於交換機內部的狀態沒有徹底的控制，這將可能致使交換機之間、交換機與控制器之間的不一致性。爲了防止這樣的漏洞，交換機須要對控制器檢查。針對狀態不一致的解決方法多是：考慮交換機更新的一致性【48】提出，以及狀態集中存儲，在NAP【16】提出。

 E.安全意識發展

　　如IV所示，許多漏洞因爲不適當的實現帶狀態存儲內存和訪問策略致使。爲了減輕旨在耗盡帶狀態SDN交換機內部內存的攻擊，開發人員能夠（i）爲狀態交換機/變量估計預先須要的內存空間，（ii）爲狀態移除定義適當的條件另外，應用程序應該包括基本的帶狀態網絡的基本功能，依靠本地的狀態作出決定，這樣能夠防止攻擊者強制內存分配（III-A1）或者觸發CPU密集操做（III-A2）。

V.結論

 　　最近，研究人員意識到在SDN中須要可編程交換機，而且提出帶狀態SDN數據平面。用可編程SDN交換機提升網絡性能和靈活性以實時反應網絡應用程序，由於可編程交換機容許交換機更快更高效的管理動態應用。咱們認爲，帶狀態SDN數據平面儘管頗有能力，可是容易受到不一樣的安全攻擊。本文獻中提出了幾種不一樣的場景，每種都解決了帶狀態SDN數據平面在實際應用中的一個具體的需求。可是，它們都沒有創建安全措施。所以，據咱們所知，咱們是第一個回顧和分析帶狀態數據平面方案主要特色，經過強調因爲帶狀態方案內在屬性，引起主要存在的安全漏洞。

　　附錄

　　實驗性攻擊評估

 　　本節，咱們提出在III-B介紹的實驗性攻擊樣例評估。

　　　在咱們的實驗中，咱們使用Mininet,OpenFlow1.3仿真SDN交換機。咱們採用開源OpenState（基於OpenFlow）和它的應用程序實現咱們的用例。基於此設置，全部的OpenState應用程序都在 ofdatapath進程上運行，這個進程由OpenFlow數據路徑的用戶空間實現。全部的實驗運行在一個配置了i7CPU（2核）16GRAM的臺式機上，Mininet VM使用4個虛擬核心512M RAM運行。要注意的是，在真實的SDN交換機上，RAM的容量大概是10M左右。所以，當可能時，咱們以百分比的形式報告咱們的結果，以提供一個平臺獨立的攻擊介紹，而且使讀者簡單的模擬真實世界交換機的設置。如下，咱們定義OS爲OpenState交換機，OF爲正常的OpenFlow交換機。並且，咱們考慮用於存儲流的數據結構是狀態表。咱們強調，本節相關攻擊背後的緣由相同，也使用與任何其餘數據結構。

A.端口訪問攻擊

　　咱們如今展現在端口訪問應用上進行內存溢出攻擊的可行性和高效性，這在III-B1a有所介紹。 咱們的實驗設置中，咱們假設已知的攻擊者A知道端口序列的第一個端口（3306）。A的目標是洪泛交換機s1的內存，在OpenState上運行端口訪問應用程序。最後，A使用幾個虛假元IP地址，以205Mbps的攻擊速度防洪3306端口。交換機配置的超時字段值爲5s，若是交換機沒有接收到相同流訪問下一個端口的第二個數據包，s1將重置流的狀態而且將流的狀態從狀態表移除。

　　圖13顯示了咱們的評測結果。如圖所示，ofdatapath進程使用的內存，好比，OpenState實現的主進程，隨着時間快速增長，在第34秒後，平均達到了整個交換機內存的70%。這致使ofdatapath進程進入緊急狀態。交換機CPU使用發生了一樣的狀況。Mininet VM的整個空間是512MB。

　　圖14展現了在達到緊急狀況以前的實驗期間，狀態表中存儲交換機狀態的數量。咱們可看見，在狀態數量達到約爲200k的流時，數量變成了常量。這是因爲超時時間爲5s，從表中移除狀態，交換機等待了5s。從這個實驗能夠觀察到，儘管存儲狀態的最大值仍然大約是常量（圖14），交換機的內存用量隨着時間繼續上升（圖13）。咱們認爲這個趨勢來源於OpenState的底層OFSoftswitch平臺的實現，因爲它的低效率的管理內存，致使了內存泄漏。

B.UDP泛洪攻擊緩解

　　在這，咱們給出關於UDP洪泛遷移攻擊的結果（在III-B1b介紹），展現了這種場景下內存溢出攻擊的可行性。攻擊者A，經過大量的虛假源IP地址，洪泛UDP鏈接。攻擊者給每一個源IP地址打開新的UPD鏈接，而且強制交換機在狀態表中爲每一個UDP鏈接考慮新的狀態。圖15顯示了該攻擊的實驗結果。

　　從圖15，咱們觀察到，相似於端口訪問洪泛攻擊例子，ofdatapath進程須要的內存如飛通常增加，在大約34s時，使用了超過60%的內存，致使ofdatapath進程崩潰。圖16顯示了在交換機內部狀態表中存儲的狀態數量。值得注意的是，不一樣於端口訪問攻擊場景（圖14），這個攻擊下，狀態表中存儲的狀態線性地增加。。即便爲狀態表設置了刪除超時狀態，這種狀況仍然成立。緣由是，因爲內部發送到靜態/動態數據包到每個已經使用過的源IP地址，A強制交換機爲對應的IP地址執行狀態遷移而且保留最新的狀態。這種狀況下，因爲狀態表強加大量的狀態，ofdatapath進程使交換機內存溢出，結果使交換機A耗盡交換機的內存。整個用於Mininet VM的內存RAM是512MB。

 

C.狀態不一致攻擊

 

 

 　　爲了證實狀態不一致攻擊（咱們在III-B2中介紹）的可行性，咱們使用OpenState在【31】實現了故障恢復應用。這個應用程序使用標識符來表明在每一對節點X和Y之間的故障。好比，標識符是一個前進的序列數字，從1開始，用做：（1）MPLS（多協議標籤交換機）標記，以標記故障；（2）流的狀態值，表示對應的流在一般的轉發路徑遇到一個故障。MPLS標籤和狀態值移動了16，由於0到15之間的值是保留的。所以，標識符「16」表示沒有故障，而故障事件是從數字17開始的。若是攻擊者可使一個包有正確的MPLS標籤（好比17），她能夠僞裝，轉發路徑有一個故障而且讓交換機從正常狀態 變爲故障狀態。這使得交換機相信流量須要進行重路由。

　　咱們的評測的網絡設置如17所示，在這個簡單的測試場景，主機H1（IP爲10.0.0.1），經過如下路徑發送數據包給H6（IP地址爲10.0.0.6）：H1->S2->S3->S4->H6，另外一方面，H6回覆H1是經過H6->S4->S5->S2->H1。注意，這是在【31】OpenState中實現的故障恢復應用的最初配置，圖19展現了咱們的原型在沒有攻擊的狀況下運行，好比，正常的交換機行爲，考慮故障恢復應用程序的默認配置。正如圖19a所示，在一個無攻擊的狀況下，由於在網絡中沒有故障，交換機的狀態表被認爲是空的，好比，保留一個默認的狀態。圖19b顯示了從10.0.0.1過來到10.0.0.6去，經過S3的eth2接口的正常流量。同時，圖19（c）從10.0.0.6經過S5的eth1接口到達10.0.0.1的對應路徑。

　　爲了證實重路由攻擊，咱們考慮瞭如圖18所示的攻擊場景。攻擊者A發送虛假的標記着17的MPLS數據包給交換機S2（如圖20a）。這種狀況下，A僞裝這個路徑有一個鏈路故障，而且讓S2經過恢復路徑，對相應的流執行重路由。這種狀況下，在接收到虛假的MPLS後，S2在狀態表中，爲從源IP10.0.0.1到目的IP10.0.0.6插入一條新的記錄，如圖20d所示。兔兔，S2爲表中對應的流定義了一個新的狀態，好比，狀態17。而後，因爲當前的狀態，S2經過交換機S5（圖20c所示）爲對應的流重路由其餘到來的數據包，並不是S3（圖20b）。正如咱們從20（b）所示，交換機S3在常規路徑只接受虛假數據包，而其餘的流量則經過重路由路徑進行接收，好比S5。