基于輸入輸出分離標識轉換系統的路由協議健壯性分析模型

周開波 張治兵 王小雨 劉欣東

(中國信息通信研究院泰爾系統實驗室，北京 100191)

0 引言

強制性國家標準GB 40050-2021《網絡關鍵設備安全通用要求》于2021年2月20日發布，并于2021年8月1日正式實施。GB 40050-2021的安全功能要求部分第5.8節提出，通信協議應滿足協議健壯性要求，防范異常報文攻擊。GB 40050-2021的安全保障要求部分第6.1節提出，網絡關鍵設備的提供者在設計和開發階段應采用健壯性測試等方式對設備進行安全性測試。

對用于跨網段互聯的網絡設備而言，為方便路由的通告，通常要求支持至少一種以上的路由轉發協議。路由轉發協議根據工作的機制，分為鏈路狀態協議和距離矢量協議，常見路由轉發協議包括RIP[1]、OSPF[2]和BGP[3]。其中，RIP屬于域內距離矢量協議、OSPF屬于域內鏈路狀態協議、BGP屬于域間距離矢量協議。

針對路由協議的攻擊是現實存在的并且多次出現過。2011年和2013年在美國舉辦的黑帽大會上，來自以色列的電子戰爭研究與仿真中心(National EW Research and Simulation Center)研究員GaBI Nakibly曝光了OSPF路由器協議存在的一個漏洞。攻擊者利用該漏洞可以欺騙正常的OSPF路由器，使之接受偽造的路由表更新，并最終控制整個網絡中所有路由器的路由表，通過偽造網絡路由，攻擊者可以改變網絡流量的流向，實現對數據流的監聽，或者造成路由環路，形成拒絕服務攻擊。2002年，FX在柏林舉辦的Chaos Communication Congress 2002大會上展示了針對Cisco路由器OSPF的攻擊概念驗證代碼，攻擊成功后可以將配置文件寫入到路由器的非易失隨機存儲器(Non-Volatile RAMs，NVRAM)中。對于BGP路由轉發協議，最具代表性的攻擊手段就是通過修改自身或者轉發的正確路由信息，引發自制系統被錯誤路由誤導的域間路由劫持[4-6]。

本文第2部分對LTS系統、IOLTS系統模型進行了介紹；第3部分結合路由協議的特點，提出了路由協議的通用健壯性分析模型；第4部分以網絡設備中部署量最大的OSPF路由協議為例進行了健壯性的分析，給出了生成健壯性測試路徑的方法；第5部分給出了總結。

1 標識轉換系統

1.1 LTS

對于轉移關系T，還有以下的推論。

1.2 IOLTS

輸入輸出分離的標識轉換系統(Input/ Output LTS，IOLTS)相對于LTS的主要改進是將動作標識的集合分為輸入和輸出兩個部分，以便于更好地分析基于狀態和輸入而進行狀態轉換的協議。其中L1表示輸入動作標識集合，L0表示輸出動作標識集合，L=LI∪LO，LI∩LO=?。

2 路由協議健壯性分析模型

健壯性指的是網絡關鍵設備或部件在無效數據輸入或者在高強度輸入等環境下，各項功能可保持正確運行的程度。健壯性測試中，特別關注的是無效的輸入對整個系統穩定運行的危害。一個健壯性良好的系統即使收到無效的輸入或處在不適當的使用環境中也能運行，不出現宕機等情況[9-10]。

圖1 LTS模型示例

圖2 IOLTS模型示例

一個運行路由協議的網絡可以簡化并抽象為具有多種狀態的兩個節點通過報文交互所組成的系統(見圖 3)。

其中，S1和S2代表兩個運行路由協議的節點。為體現在兩個節點之間的報文交互過程，引入了一個虛擬的中間層(Medium層)，在中間層用雙層圈代表對應節點中發送報文的狀態，其中用于交互的報文組合分別是{!a, ?a}、{!b, ?b}和{!m, ?m}。“!”表示這是一個輸出報文的動作，“？”表示這是一個收到報文的動作。

在圖3中，僅考慮路由協議正常交互的過程，但為分析協議的健壯性，還需要考慮路由協議在各個狀態下收到各種類型報文的情況。對于某一個協議狀態，對應的輸入可以分為以下3類。

(1)符合協議定義的報文且出現在合適的狀態，稱為有效的報文，其集合記為PEP。

(2)符合協議定義的報文但出現在不合適的狀態，稱為不合適的報文，其集合記為POP；所有符合協議定義的報文集合記為PP，PP=PEP∪POP。

綜合有效、不合適和無效輸入之后的協議模型見圖4。在圖4中IPP模塊用于處理無效報文，其中?A表示收到的無效報文的集合，!e為處理之后的輸出，處理完無效報文之后協議返回到原來的狀態。此外，針對每一個狀態，?Ni表示在該狀態下收到的不合適報文的集合。

圖3 路由協議模型

圖4 協議健壯性分析模型

需要注意的是，在分析模型的建立中，需要考慮到協議中沒有明確定義的狀態，但此類狀態對于明確模型又非常重要。此時，可以自主地在模型中增加此類狀態。因此，模型中的狀態總數應該≥協議中規定的狀態數量。PP=[?x,?y,?z,?a,?b,?m,!a,!b,!m,?A,!e,?N1,?N2,?N3,?N4,?N5]。轉移關系的生成步驟如下。

(1)明確初始狀態。在本協議健壯性分析模型中，初始狀態為S1-1,S2-1。

(2)確定終結狀態的集合。終結狀態指的是通過一次轉換就到達初始狀態的狀態。在圖4中，對于狀態S1-1，其終結狀態的集合記為S1-1End，S1-1End={S1-4,S1-5}。

(3)從每一個終結狀態開始，查找回溯到初始狀態的路徑。

(4)在回溯的路徑中，如果出現了交互報文組合中的輸入動作，則在回溯的路徑中添加對應的輸出動作，開始遞歸回溯。

(5)輸出所有的轉移關系。

例如，在圖4中，其中一條轉移關系就是[S1-5,?m,S1-2,?x,S1-1,S2-2,?a,S2-1]。

之后，根據轉移關系編寫測試例，指的是在轉移關系Si的情況下，生成測試例Ti，其對應的系統響應為Result。對網絡路由協議的具體實現而言，如果滿足：?{Si∈L*}|:Result=Pass，則認為該協議實現滿足健壯性的要求。

3 OSPFv2協議健壯性分析

OSPF是互聯網上最為常見的鏈路狀態路由協議，使用在自治域內部。OSPF路由協議通過收集路由域內各路由器的鏈路狀態，形成網絡的拓撲，再根據網絡拓撲，利用最短路徑算法得出該路由器至其他網絡(主機)的路由表。適用于IPv4的OSPF v2版本于1998年發布，編號為RFC 2328[3]。OSPF將數據直接封裝在IP包中，所使用的IP協議號是89。由于IP協議不能保證協議報文的可靠傳送，OSPF自身實現了消息檢錯糾錯功能和報文的重傳機制。OSPFv2采用鑒權機制來保證安全，只允許可信任的OSPF路由器加入路由域。

3.1 正常協議交互流程

路由器RT1和RT2 OSPF協議交互的流程見圖 5。初始階段，兩個路由器的OSPF協議均處于Down狀態。RT1在發出Hello報文后，收到了RT2的Hello報文，并在RT2發來的Hello報文中看到RT1已經列入到鄰居列表，表示雙方已經建立起雙向會話。之后，RT1和RT2通過交互數據庫描述(Database Description，DD)報文協商以誰為主進行下一步的數據庫信息交互。數據庫信息交互完成后，RT1和RT2分別向對方請求鏈路狀態(Link State，LS)信息，實現雙方鏈路狀態數據庫信息的同步。鏈路狀態數據庫同步之后，RT1和RT2進入Full狀態，表示雙方的OSPF鄰接關系建立，并基于各自的鏈路狀態數據庫計算路由表。

3.2 健壯性分析

根據RFC2328的定義和圖 5所示的協議交互流程，再考慮到系統在各狀態可能收到的報文情況，得到OSPFv2協議的IOLTS模型，如圖 6所示。為便于展示OSPF的IOLTS模型，無效報文處理模塊IPP分為4個邏輯模塊。為便于更好地分析OSPF路由協議的轉移狀態，在圖 6中引入了協議中沒有的狀態，用比正常狀態更小的、加粗的、斷續圓圈表示。

圖5 OSPF路由協議交互過程

圖6 OSPFv2 IOLTS模型

OSPFv2模型中的各動作說明見表1。Medium層展示RT1和RT2之間有消息交互的狀態和交互的消息內容，其中RT1在狀態S1、S2、S4、S5、S6與RT2有消息交互，RT2在狀態S2、S8、S9、S10、S21與RT2有消息交互。交互的動作組合為：、、、、、、、、、。

表1 OSPFv2 IOLTS模型動作說明

3.3 健壯性測試例

根據第3部分提供的轉移路徑的生成方法，以RT1的S1-Down狀態作為初始狀態，其對應的終結狀態的集合S1-Down-End={S2-Init,S3-2Way,S4-ExStart,S5-Exchange,S6-Loading,S7-Full}。

接下來以S7-Full為例進行回溯，查找回溯到初始狀態S1-Down的路徑，即S1-Down到S7-Full的轉移關系。首先，在RT1中查找其中一條轉移關系為：{RT1{S7-Full,!E11,S18-D7,?E9-y+011-R2,S9-ExchangeD,!E9-y010-R1,S5-Exchange,?E2,S1-Down}。

到達初始狀態之后，檢查現在的轉移關系是否存在消息交互的工作組合，發現有動作組合存在。在RT2中繼續查找至初始狀態的轉移關系，新的轉移為：{RT1{S7-Full,!E11,S18-D7,?E9-y+011-R2,S9-ExchangeD,!E9-y010-R1,S5-Exchange,?E2,S1-Down}RT2{S9-ExchangeD,Tau,S22-D9,?E9-y010-R1,S5-Exchange,?E2,S1-Down}}。

再次檢查新增的轉移關系中是否存在消息交互的工作組合，發現有 動作組合存在。在RT1中繼續查找至初始狀態的轉移關系，新的轉移為：{RT1{S7-Full,!E11,S18-D7,?E9-y+011-R2,S9-ExchangeD,!E9-y010-R1,S5-Exchange,?E2,S1-Down}RT2{S9-ExchangeD,Tau,S22-D9,?E9-y010-R1,S5-Exchange,?E2,S1-Down}RT1{S5-Exchange,?E2,S1-Down}}。在新增的轉移關系中沒有發現動作組合的存在。至此，一條完整的轉移關系查找完成。

考慮到最后生成的轉移關系跨越了系統中的兩個節點，為方便測試例的編寫，可以將每一個節點相關的轉移關系生成一個測試例。在上述的轉移關系中，RT1和RT2相關的轉移關系可以生成3個測試例，其中與RT1相關的測試例為2個，與RT2相關的測試例為1個。

4 結束語

路由協議的健壯性可以通過上述方法生成的測試例來進行驗證。但在實際的驗證過程中，按照上述的分析模型會生成巨量的測試例，執行全部的測試例需要較長的時間。而且根據不同的轉移關系生成的測試例可能有重復，如何消除重復的測試例、優化同類無效報文測試例集、提高測試例生成的效率等是下一步需要研究的重點。