論文摘要：

本文為讀者提供新興的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.結論

A Survey on the Security of Stateful SDN Data Planes