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

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

1(中國科學(xué)院 計算機網(wǎng)絡(luò)信息中心,北京 100190)

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

3(互聯(lián)網(wǎng)域名系統(tǒng)北京市工程研究中心,北京 100190)

1 背景

1.1 現(xiàn)狀

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

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

1.2 RPKI 體系架構(gòu)

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

圖1 RPKI 數(shù)據(jù)傳輸結(jié)構(gòu)

1.3 RPKI 大規(guī)模部署的體系要求

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

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

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

3)可靠性：傳輸架構(gòu)能適用于復(fù)雜的網(wǎng)絡(luò)環(huán)境.

但當(dāng)前現(xiàn)有的RPKI 緩存分發(fā)結(jié)構(gòu),在大規(guī)模部署的情況下,難以滿足RPKI 緩存分發(fā)的要求,從以下四點進行分析：

1.3.1 負載均衡問題

RPKI 緩存更新結(jié)構(gòu)存在如下幾個原因,難以滿足負載均衡的要求.

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

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

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

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

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

1.3.3 傳輸效率問題

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

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

圖2 RTR 協(xié)議應(yīng)用于多層傳輸結(jié)構(gòu)的問題

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

1.3.4 可靠性問題

IETF 在RFC 6810 中提到將RTR 協(xié)議不適合用于復(fù)雜的拓撲結(jié)構(gòu),因為RTR 協(xié)議在復(fù)雜拓撲結(jié)構(gòu)中容易出錯,例如：不能保持無環(huán)路條件.此外基于TCP協(xié)議的RTR 協(xié)議,在實際網(wǎng)絡(luò)情況下不便于進行跨網(wǎng)段傳輸.

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

2 基于HTTPS 的RPKI 緩存分發(fā)架構(gòu)

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

圖3 基于HTTPS 的緩存分發(fā)架構(gòu)圖

2.1 實際應(yīng)用場景分析

上述設(shè)計是大規(guī)模部署中RPKI 緩存分發(fā)的基本模型,在實際應(yīng)用場景中,可以根據(jù)不同場景下的需求對分發(fā)結(jié)構(gòu)進行進一步的優(yōu)化或修改.在實際生活場景中,部分路由系統(tǒng)的搭建由互聯(lián)網(wǎng)運營商完成.由于互聯(lián)網(wǎng)運營商的實際管理模式為層級化管理或扁平化管理.經(jīng)過探究,本文提出兩種不同應(yīng)用場景中RPKI緩存分發(fā)架構(gòu)的改進.

2.1.1 互聯(lián)網(wǎng)運營商扁平化管理場景

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

通過搭建中間多級VC 服務(wù)器,將單一VC 服務(wù)器對管理范圍內(nèi)其它VC 服務(wù)器的傳輸優(yōu)化為多VC 服務(wù)器對其它VC 服務(wù)器的傳輸.這種新的架構(gòu)能減少VC 服務(wù)器的負載壓力,此外新的傳輸架構(gòu)也能夠更好的契合互聯(lián)網(wǎng)運營商的扁平化管理.

圖4 扁平化管理場景下RPKI 緩存分發(fā)架構(gòu)的優(yōu)化

2.1.2 互聯(lián)網(wǎng)運營商層級化管理場景

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

2.2 RPKI 緩存分發(fā)設(shè)計

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

1)降低RP 負載：通過搭建VC 服務(wù)器,可以顯著降低RP 服務(wù)器的負載壓力.AS 內(nèi)部的路由器通過其所在AS 部署的VC 服務(wù)器獲取RPKI 緩存數(shù)據(jù).RP 服務(wù)器只需將通過驗證后的RPKI 緩存數(shù)據(jù)傳輸?shù)绞孪扰渲煤玫腣C 服務(wù)器處即可.

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

3) 保證路由信息的一致性：由VC 服務(wù)器進行RPKI 緩存的分發(fā),不需要大量部署RP 服務(wù)器.能夠保證一定區(qū)域內(nèi)路由信息的統(tǒng)一性.

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

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

2.3 HTTPS 分發(fā)設(shè)計

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

圖5 層級化管理場景下RPKI 緩存分發(fā)架構(gòu)的優(yōu)化

本方案采用HTTPS 協(xié)議有以下原因：

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

2) HTTPS 適用范圍廣,能夠適應(yīng)復(fù)雜網(wǎng)絡(luò)拓撲結(jié)構(gòu)：HTTPS 應(yīng)用于幾乎所有的操作系統(tǒng),適用范圍廣.

3) HTTPS 協(xié)議是一種面向內(nèi)容的應(yīng)用層協(xié)議,它簡化了對數(shù)據(jù)格式的要求和協(xié)議兼容設(shè)計的細節(jié)問題,可以傳輸任意的數(shù)據(jù)對象.

因此采用HTTPS 協(xié)議,既能夠滿足及時分發(fā)RPKI 緩存的需要,又能夠適應(yīng)實際部署中復(fù)雜的網(wǎng)絡(luò)結(jié)構(gòu).所以本文提出的設(shè)計方案采用HTTPS 協(xié)議作為VC 服務(wù)器之間分發(fā)RPKI 緩存的傳輸協(xié)議.

2.4 通用的數(shù)據(jù)格式

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

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

因此,本文提出的設(shè)計方案采用RFC 8416 中規(guī)定的JSON 格式的數(shù)據(jù)結(jié)構(gòu)來描述VC 服務(wù)器之間分發(fā)的RPKI 緩存.

3 詳細設(shè)計

3.1 數(shù)據(jù)結(jié)構(gòu)完整設(shè)計

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

JSON 格式如下：

XML 格式如下：

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

表1 頭部(header)字段

Operate 字段包括new和back 兩個方式,new 表示直接在VC 服務(wù)器當(dāng)前狀態(tài)的數(shù)據(jù)庫進行RPKI 緩存更新,back 表示需要VC 服務(wù)器回退到之前版本的數(shù)據(jù)庫.

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

3.2 VC 服務(wù)器

在本文的設(shè)計方案中,共有3 個實體,RP 服務(wù)器,VC 服務(wù)器和路由器,由于RP 服務(wù)器與路由器的設(shè)計在工業(yè)上已有實現(xiàn),故本文設(shè)計方案僅討論分發(fā)架構(gòu)中VC 服務(wù)器的設(shè)計.

3.2.1 VC 服務(wù)器功能模塊

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

圖6 VC 功能模塊示意圖

3.2.2 安全保護與可靠性

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

1) IP 訪問控制

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

2)數(shù)據(jù)完整性檢查

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

3)重傳機制

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

4 實驗與分析

4.1 RPKI 緩存分發(fā)實驗

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

4.1.1 RPKI 緩存分發(fā)實驗設(shè)計與結(jié)果分析

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

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

圖7 RPKI 緩存分發(fā)流程圖

圖8 RPKI 緩存分發(fā)用時圖

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

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

4.1.2 數(shù)據(jù)包構(gòu)建模塊

數(shù)據(jù)包構(gòu)建模塊通過用戶輸入或者根據(jù)重傳請求構(gòu)建數(shù)據(jù)包,以JSON 格式為例.

運行結(jié)果如圖9所示.

圖9 數(shù)據(jù)包構(gòu)建模塊測試結(jié)果

4.1.3 傳輸模塊

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

圖10 服務(wù)器端運行結(jié)果

4.1.4 數(shù)據(jù)處理模塊

數(shù)據(jù)處理模塊功能主要分為以下兩部分：

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

2)數(shù)據(jù)處理與儲存

運行結(jié)果如圖11所示.

圖11 數(shù)據(jù)處理模塊運行結(jié)果

4.2 性能測試

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

圖12 性能比較結(jié)果

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

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

5 結(jié)束語

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

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