基于HTTPS的RPKI緩存更新機制①

耿新杰,馬 迪,,毛 偉,邵 晴

1(中國科學院 計算機網絡信息中心,北京 100190)

2(中國科學院大學,北京 100190)

3(互聯網域名系統北京市工程研究中心,北京 100190)

1 背景

1.1 現狀

BGP (Border Gateway Protocol,邊界網關協議)缺乏驗證真實性和合法性的安全手段,它容易遭到各種惡意攻擊.為解決BGP 缺乏安全認證的問題,Kent S 等人于2002年提出了S-BGP[1].基于S-BGP 的設計思想,IETF (Internet Engineering Task Force,互聯網工程任務組),RPKI (Resource Public Key Infrastructure,資源公鑰基礎設施)的技術標準化工作,旨在提供路由信息交換的認證[2].

RPKI 數據傳輸結構如圖1所示,RPKI 依賴方同步RPKI 認證中心或資料庫(供給側)的數據,并將驗證數據分發給BGP 路由系統(需求側)以供路由器進行驗證.RPKI 依賴方需要相當頻繁的驗證證書和CRL,性能將是數據傳輸首要考慮的問題[3].文獻[4]實現了一種基于有序哈希樹的RPKI 資料庫同步工具,改進了目前數據同步協議Rsync 協議[5]未考慮到RPKI中文目錄的缺陷,能夠大量減少中文數據同步時間和資源消耗.文獻[6]實現了基于Delta 協議[7]的RPKI 數據同步,能夠解決目前基于Rsync 協議進行數據同步所具有的安全隱患.文獻[8]實現了基于哈希表的RPKI證書驗證優化方法,通過使用哈希表的方式取代數據庫查詢進行數據驗證,能夠減少數據驗證時間消耗.這些研究逐步完善供給方與依賴方數據同步環節.但依賴方與需求側的數據傳輸研究目前被關注較少,伴隨著RPKI 在全球進入部署應用階段,依賴方與需求側的數據傳輸機制是RPKI 能夠發揮作用的關鍵要素.

1.2 RPKI 體系架構

RPKI 通過建立一整套公鑰證書體系對INR (Internet Number Resource,互聯網碼號資源)的所有權(分配)和使用權(路由起源通告)進行驗證,CA (Certificate Authority,證書頒發機構)在進行資源分配的過程中,同時會簽發一系列標識資源從屬關系的認證證書并將該證書數據分發到路由處以供驗證.數據傳輸結構如圖1所示,證書數據存儲于全球RPKI 數據庫,RP 服務器會從全球RPKI 數據庫同步證書信息并驗證,將驗證后的信息緩存于本地數據庫中.路由器通過RTR (RPKI To Router)[9]協議獲取RP 數據庫中的RPKI緩存數據,并將該緩存數據用于驗證路由起源通告是否合法.

圖1 RPKI 數據傳輸結構

1.3 RPKI 大規模部署的體系要求

目前RPKI 體系架構僅在部分ISP 或研究機構進行小規模部署實驗.根據文獻[10]結論,在大規模部署的條件下,需要滿足以下要求：

1)負載均衡：傳輸架構負載承受能力滿足實際運行需要.

2)傳輸效率：傳輸任務能在給定時間范圍內到達指定地址.

3)可靠性：傳輸架構能適用于復雜的網絡環境.

但當前現有的RPKI 緩存分發結構,在大規模部署的情況下,難以滿足RPKI 緩存分發的要求,從以下四點進行分析：

1.3.1 負載均衡問題

RPKI 緩存更新結構存在如下幾個原因,難以滿足負載均衡的要求.

1) RP 服務器的負載能力有限：目前的緩存更新結構中,RPKI 緩存由RP 服務器直接向所有的路由器進行分發.在實際部署過程中,RP 服務器的負載能力有限.一旦大量的路由器同時對RP 服務器發起數據傳輸請求,會給RP 服務器帶來巨大的負載壓力,有可能造成信息阻塞、RP 服務器宕機等問題.

2)對全球RPKI 數據庫構成壓力：為了降低實際部署情況下RP 服務器的負載壓力,需要在網絡中大量部署RP 服務器,這會給全球RPKI 數據庫帶來負載壓力.這種改進方案僅僅是將RP 服務器的負載壓力轉移到全球RPKI 數據庫處,同樣不能滿足運行穩定的要求.

1.3.2 非一致性和本地化控制問題

由于RP 服務器直接從全球RPKI 數據庫獲取證書數據,其獲取數據內容的方式和驗證過程完全獨立,即不與其他RP 服務器相關,大規模部署RP 服務器,會導致同一區域內(例如一個ISP(Internet service provider,互聯網服務提供商))路由信息的沖突,產生非一致性問題.

IETF 在RFC 8416[11]中,考慮到ISP 本地化信息控制的需求,提出了SLURM (Simplified Local Internet Number Resource Management,簡化本地互聯網碼號資源管理).RP 服務器會通過本地信任錨點獲取SLURM文件來對RPKI 緩存數據進行補充和修改,以達到本地化信息控制的目的.在這種情況下,大量的部署RP 服務器會增加管理上的難度和本地化控制信息傳輸的難度.

1.3.3 傳輸效率問題

在現有的RPKI 緩存更新結構中,RP 服務器與路由器之間的緩存更新通過RTR 協議進行.RTR 協議是專門為存儲RPKI 緩存的服務器與路由器之間進行數據傳輸設計的一種協議結構,但RTR 協議僅能通過路由器主動發起傳輸請求,且不適用于復雜的網絡架構.因此既難以滿足實際在實際運行過程中對RPKI 緩存分發效率的要求也不能保證分發過程的穩定.具體原因如下.

1)無法主動推送及時響應：服務器不能主動向客戶端進行數據傳輸,只能依靠客戶端周期性的從服務器處獲取數據.如果直接將RTR 協議用于緩存分發,會出現如圖2所示的問題,即當實際部署中出現多層分發結構時,周期性的獲取數據會導致最下層的路由器獲取RPKI 緩存數據花費的時間是中間多層服務器獲取緩存數據的周期之和,導致重要的RPKI 緩存數據不能得到及時分發,無法及時響應.

圖2 RTR 協議應用于多層傳輸結構的問題

2)數據結構設計不合理：在目前的RPKI 緩存分發結構中,RPKI 緩存通過RFC 6810 規定的數據結構進行描述,這是一種專為RTR 協議設計的數據結構.該數據結構中只能包含一條RPKI 緩存更新數據,影響傳輸效率,并且該數據結構只能通過RTR 協議進行解析和編寫,缺少可讀性和通用性,實際部署成本較大.

1.3.4 可靠性問題

IETF 在RFC 6810 中提到將RTR 協議不適合用于復雜的拓撲結構,因為RTR 協議在復雜拓撲結構中容易出錯,例如：不能保持無環路條件.此外基于TCP協議的RTR 協議,在實際網絡情況下不便于進行跨網段傳輸.

經過上述分析,當前的RPKI 緩存分發機制不能滿足大規模部署時RPKI 緩存分發的需求.本文針對以上四種缺陷設計了一種基于HTTPS 的緩存更新機制,該機制能夠解決這些缺陷,滿足大規模部署時RPKI 緩存分發的需求.

2 基于HTTPS 的RPKI 緩存分發架構

本文針對實際部署中RPKI 緩存數據分發的問題,利用JSON 化的RPKI 驗證緩存數據實現了一種基于HTTPS 的緩存分發機制,如圖3所示.在本文設計的機制中,RP 服務器和路由器之間的RPKI 緩存分發,通過搭建多級VC 服務器實現.在ISP 的重要管理節點即RP 服務器的部署地點處,搭建VC 服務器.RP 服務器和該VC 服務器之間通過同一數據庫共享RPKI 緩存.該VC 服務器與其它VC 服務器之間通過HTTPS 協議構建安全傳輸信道進行RPKI 緩存數據的分發.此外在每個AS 內均部署有相應的VC 服務器.AS 內的路由器通過RTR 協議從VC 服務器處獲取RPKI 緩存數據.

圖3 基于HTTPS 的緩存分發架構圖

2.1 實際應用場景分析

上述設計是大規模部署中RPKI 緩存分發的基本模型,在實際應用場景中,可以根據不同場景下的需求對分發結構進行進一步的優化或修改.在實際生活場景中,部分路由系統的搭建由互聯網運營商完成.由于互聯網運營商的實際管理模式為層級化管理或扁平化管理.經過探究,本文提出兩種不同應用場景中RPKI緩存分發架構的改進.

2.1.1 互聯網運營商扁平化管理場景

在扁平化管理場景下,基本模型雖然能滿足管理架構的需求,但是直接由單一VC 服務器對其它所有管理范圍內的VC 服務器進行RPKI 緩存數據的分發并處理其它VC 服務器特殊情況下發來的請求,會使得服務器負載壓力過大.因此本文在基于基本模型提出一種優化架構,如圖4所示.

通過搭建中間多級VC 服務器,將單一VC 服務器對管理范圍內其它VC 服務器的傳輸優化為多VC 服務器對其它VC 服務器的傳輸.這種新的架構能減少VC 服務器的負載壓力,此外新的傳輸架構也能夠更好的契合互聯網運營商的扁平化管理.

圖4 扁平化管理場景下RPKI 緩存分發架構的優化

2.1.2 互聯網運營商層級化管理場景

在層級化管理的場景下,由單一VC 服務器進行對其它所有管理范圍的VC 服務器進行RPKI 緩存數據分發的機制不能很好的契合互聯網運營商的管理模式的需求.因此可對這種場景下的RPKI 緩存分發架構進行相應的修改.在圖5所示的架構中,與層級化管理相對應的每一層VC 服務器都可以接受其本地信任錨點的本地化控制信息文件,并通過該文件對其子層級進行本地化信息控制.經過修改后的傳輸架構與互聯網運營商的層級化管理結構契合度更高,也更易于使用層級化管理的互聯網運營商進行本地化信息控制.

2.2 RPKI 緩存分發設計

本文實現的傳輸架構能夠解決實際部署中的負載均衡問題以及非一致性和本地化控制問題.架構設計出于以下考量.

1)降低RP 負載：通過搭建VC 服務器,可以顯著降低RP 服務器的負載壓力.AS 內部的路由器通過其所在AS 部署的VC 服務器獲取RPKI 緩存數據.RP 服務器只需將通過驗證后的RPKI 緩存數據傳輸到事先配置好的VC 服務器處即可.

2)降低全球RPKI 數據庫壓力：VC 服務器僅通過其上級VC 服務器或者RP 服務器獲取RPKI 緩存數據,并不需要訪問全球RPKI 數據庫進行證書數據同步,不會額外增加全球RPKI 數據庫的負載壓力.

3) 保證路由信息的一致性：由VC 服務器進行RPKI 緩存的分發,不需要大量部署RP 服務器.能夠保證一定區域內路由信息的統一性.

4)適應本地化控制的需求：VC 服務器從更高一級VC 服務器或RP 服務器中獲取驗證緩存數據,保證了同一區域內的路由信息通過同一RP 服務器進行管理和修改,降低了管理難度,也減少了本地化控制信息傳輸的難度.

5)降低RP 服務器的功能復雜度：通過在RP 服務器處搭建VC 服務器進行RPKI 緩存分發,降低RP 服務器設計的復雜度.將同步功能和分發功能分離,具有更高的松耦合度和靈活度,有效的降低了實際部署難度.

2.3 HTTPS 分發設計

本文設計方案選用HTTPS 協議作為VC 服務器之間RPKI 緩存分發的傳輸協議,能夠解決RTR 協議的周期疊加問題和可靠性問題.RFC8484[12]提出了一種基于HTTPS 的DNS 查詢機制,該文檔提出,可以使用HTTPS 發送DNS 查詢,并通過HTTP 獲取DNS 響應.本文設計方案參考了RFC 8484,將該文檔提出的場景視作是RPKI 緩存數據分發的一種相近場景.

圖5 層級化管理場景下RPKI 緩存分發架構的優化

本方案采用HTTPS 協議有以下原因：

1)允許主動推送,適用于應急響應：HTTPS 協議允許由客戶端主動發起連接請求,能夠迅速分發SLURM 文件進行本地化信息控制,避免錯誤配置長時間影響本地.

2) HTTPS 適用范圍廣,能夠適應復雜網絡拓撲結構：HTTPS 應用于幾乎所有的操作系統,適用范圍廣.

3) HTTPS 協議是一種面向內容的應用層協議,它簡化了對數據格式的要求和協議兼容設計的細節問題,可以傳輸任意的數據對象.

因此采用HTTPS 協議,既能夠滿足及時分發RPKI 緩存的需要,又能夠適應實際部署中復雜的網絡結構.所以本文提出的設計方案采用HTTPS 協議作為VC 服務器之間分發RPKI 緩存的傳輸協議.

2.4 通用的數據格式

本文基于RFC 8416 中用來描述SLURM 文件的JSON 格式的數據結構,參考了RFC 8427[13](該文檔中使用JSON 格式對DNS 查詢和響應進行了描述).使用JSON 用以描述RPKI 緩存更新,能夠解決RTR 協議規定的數據結構在實際部署中只能傳輸單條數據和缺少通用性的問題.

RFC8416 中為描述SLURM 文件制定了一種JSON 格式的數據結構.在實際分發過程中,通過該結構來描述RPKI 緩存更新的內容,可以簡化與SLURM文件的交互接口.不需要提供專門的解析和重構模塊,.同時該數據結構可應用于增量更新,增量更新的方式可以降低全量更新所消耗的資源,提高分發效率,能夠滿足實際運行的需要.

因此,本文提出的設計方案采用RFC 8416 中規定的JSON 格式的數據結構來描述VC 服務器之間分發的RPKI 緩存.

3 詳細設計

3.1 數據結構完整設計

考慮到網絡傳輸的復雜性,以及在實際場景中,ISP 對VC 服務器數據庫中RPKI 緩存數據的管理控制需求,本方案在RPKI 緩存更新的基礎上添加控制信息,將RPKI 緩存與控制信息封裝為一個完整的數據包.控制信息和JSON 格式的RPKI 緩存數據完全解耦,控制信息可用JSON和XML 等結構化語言進行描述,JSON和XML 數據包結構的具體設計如下所示.

JSON 格式如下：

XML 格式如下：

在上述所示的數據包結構中,數據包由頭部(header)和數據(data)兩部分構成.其中頭部字段含義如表1所示.

表1 頭部(header)字段

Operate 字段包括new和back 兩個方式,new 表示直接在VC 服務器當前狀態的數據庫進行RPKI 緩存更新,back 表示需要VC 服務器回退到之前版本的數據庫.

As 字段用以實現面向不同的AS 的本地化信息控制視圖,管理者可通過修改as 字段,構建針對不同AS 的本地化信息控制視圖.

3.2 VC 服務器

在本文的設計方案中,共有3 個實體,RP 服務器,VC 服務器和路由器,由于RP 服務器與路由器的設計在工業上已有實現,故本文設計方案僅討論分發架構中VC 服務器的設計.

3.2.1 VC 服務器功能模塊

為了能夠安全高效的進行RPKI 緩存分發,結合第2 節中的設計思路,VC 服務器應具有五種功能模塊.(1)數據包構建模塊：該模塊用于將RPKI 緩存描述為如2.3 所述格式,并通過添加頭部控制信息,構建如3.1 所述的數據包；(2)傳輸模塊：根據頭部控制信息中的as 字段將RPKI 緩存通過HTTPS 協議分發到對應as 區域中的VC 服務器,并通過多線程實現一次性多目標分發；(3)數據解析模塊：該模塊用于解析收到的RPKI 緩存數據包,通過頭部控制信息對RPKI 緩存進行相應的處理；(4)重傳模塊：當VC 服務器收到不完整數據包或者發現有數據包遺漏時,該模塊會向其上級VC 服務器請求重新獲取RPKI 緩存更新,并提供相應的控制信息.當VC 服務器接收到下級VC 服務器的重發請求時,將根據其提供的控制信息,調用數據包構建模塊構建數據包,并通過傳輸模塊進行信息的傳輸.如圖6所示.

圖6 VC 功能模塊示意圖

3.2.2 安全保護與可靠性

由于HTTPS 的安全加密通道只能夠保證傳輸過程中的數據安全.在本文的設計方案中還建立了IP 訪問控制和數據完整性檢查兩種機制進行安全性保護,并通過重傳機制增強分發架構的可靠性.

1) IP 訪問控制

VC 服務器在接受數據包之前,首先會對傳輸數據的IP 進行檢查,如果該IP 不合法,VC 服務器會直接拋棄該數據包,不對其中的數據進行解析.該機制可以保證VC 服務器接受的RPKI 緩存數據的來源是可靠的.

2)數據完整性檢查

VC 服務器在進行數據包解析之前,首先會根據sha1 字段中的數據對數據包進行完整性校驗,如果校驗結果不相符,則拋棄該數據包,并通過重傳請求模塊向上級VC 服務器申請數據包的重傳.

3)重傳機制

當數據包未能通過數據完整性檢測或者數據解析過程中發現newversion 字段與數據庫中的最新版本相差大于1,VC 服務器就會啟用重傳機制,向上級VC 服務器發出請求重新獲取數據包.

4 實驗與分析

4.1 RPKI 緩存分發實驗

RPKI 緩存分發流程如圖7所示,VC 服務器會根據需要分發的RPKI 緩存更新,利用3.1 所述數據結構構建分發數據包,通過HTTPS 協議將數據包分發到指定AS 處的VC 服務器.VC 服務器會對數據包進行檢測,如果驗證失敗則觸發重傳請求,請求重傳RPKI 數據包.之后,根據數據包進行相應的處理和更新.

4.1.1 RPKI 緩存分發實驗設計與結果分析

實驗中使用五臺物理機模擬傳輸架構進行實驗,將五臺物理機分別標號為1-5,其中1 號機7999 端口作為RP 服務器,8000 端口作為VC 服務器,2-5 號機依次作為不同層級的VC 服務器.

實驗使用JSON 格式的數據包進行傳輸測試.通過輸出時間戳(毫秒精度)計算發起連接到通信完成之間的時間差,從而得到實際過程中的時間效率.本實驗通過3 個端口(8000-8002)得到每個層級分發用時的平均值(同時測試多線程分發)并計算總分發用時,如圖8所示.

圖7 RPKI 緩存分發流程圖

圖8 RPKI 緩存分發用時圖

圖中的X 軸表示分發結構中VC 服務器的傳輸層數,Y 軸表示總分發用時平均值(單位：ms),實際測量得到,5 層分發結構僅用時26 010.8 ms(26.0108 s).在實際部署場景中,該架構能夠迅速穩定的分發RPKI 緩存,可以滿足實際運行的需要.

本文還對核心模塊進行單獨測試,以下給出運行結果.

4.1.2 數據包構建模塊

數據包構建模塊通過用戶輸入或者根據重傳請求構建數據包,以JSON 格式為例.

運行結果如圖9所示.

圖9 數據包構建模塊測試結果

4.1.3 傳輸模塊

傳輸模塊根據數據包頭部AS 字段獲取目標AS 的IP 地址,并通過多線程的方式分發RPKI 緩存,服務器端運行結果如圖10所示.

圖10 服務器端運行結果

4.1.4 數據處理模塊

數據處理模塊功能主要分為以下兩部分：

1) IP 訪問控制,完整性檢測與版本控制

2)數據處理與儲存

運行結果如圖11所示.

圖11 數據處理模塊運行結果

4.2 性能測試

為了準確評估本方案的實際運行效果,還設計了對比試驗.第一組為使用RTR 協議進行RPKI 緩存的分發.第二組為使用HTTPS 協議進行RPKI 緩存的分發.由于架構和數據處理操作相同,本實驗只對RTR 協議和HTTPS 協議的傳輸時間進行測試(不計算數據處理用時),本實驗根據RTR 協議逐條傳輸的特點,測試在五種不同數目的RPKI 更新緩存數據(分別為10 條,20 條,50 條,100 條,200 條)的情況下,RTR協議與HTTPS 協議的傳輸時間對比.實驗結果如圖12所示.

圖12 性能比較結果

從圖11可以看出,當RPKI 緩存更新數較少的時候,RTR 協議傳輸效率比HTTPS 協議高,但是隨著緩存更新數的增加,RTR 協議傳輸時間也顯著增加,而HTTPS 協議并無明顯變化.在RPKI 緩存更新數達到200 時,RTR 協議用時為HTTPS 協議的6.28 倍.因此在實際部署環境中,使用HTTPS 協議可以使得傳輸效率更加穩定.

此外,文獻[9]提到在RTR 協議中客戶端每間隔一小時通過服務器端獲取一次數據.在多層分發架構中,客戶端獲取數據的周期疊加會使得分發時間長達數小時.而本文提出的基于HTTPS 協議的分發架構能夠使得分發時間不會受到周期疊加的影響,可以高效分發RPKI 緩存.

5 結束語

隨著互聯網時代的進一步發展,RPKI 的部署勢在必行,也獲得了國內外許多組織的大力推行.但是在實際部署過程中還有許多問題需要進行研究.在這種背景下,本文利用JSON 化的RPKI 驗證緩存數據實現了一種基于HTTPS 的緩存更新機制.本文首先說明了現有RPKI 架構的難以應用于實際部署的缺陷,并給出了本方案的設計考量,然后給出了設計的完整內容和具體細節.在此基礎上本文用python 對該設計進行了實現并與RTR 協議進行對比.

RPKI 作為路由安全領域的熱點話題,既是為互聯網運行保駕護航的重要舉措,也是互聯網進一步發展的基石.因此如何將RPKI 更好的部署在實際場景中也是一個重要的探索方向和研究內容.