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

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

2(中國(guó)科學(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é)議)缺乏驗(yàn)證真實(shí)性和合法性的安全手段,它容易遭到各種惡意攻擊.為解決BGP 缺乏安全認(rèn)證的問(wèn)題,Kent S 等人于2002年提出了S-BGP[1].基于S-BGP 的設(shè)計(jì)思想,IETF (Internet Engineering Task Force,互聯(lián)網(wǎng)工程任務(wù)組),RPKI (Resource Public Key Infrastructure,資源公鑰基礎(chǔ)設(shè)施)的技術(shù)標(biāo)準(zhǔn)化工作,旨在提供路由信息交換的認(rèn)證[2].

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

1.2 RPKI 體系架構(gòu)

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

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

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

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

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

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

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

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

1.3.1 負(fù)載均衡問(wèn)題

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

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

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

1.3.2 非一致性和本地化控制問(wèn)題

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

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

1.3.3 傳輸效率問(wèn)題

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

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

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

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

1.3.4 可靠性問(wèn)題

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

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

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

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

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

2.1 實(shí)際應(yīng)用場(chǎng)景分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 詳細(xì)設(shè)計(jì)

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

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

JSON 格式如下：

XML 格式如下：

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

表1 頭部(header)字段

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

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

3.2 VC 服務(wù)器

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

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

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

圖6 VC 功能模塊示意圖

3.2.2 安全保護(hù)與可靠性

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

1) IP 訪問(wèn)控制

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

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

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

3)重傳機(jī)制

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

4 實(shí)驗(yàn)與分析

4.1 RPKI 緩存分發(fā)實(shí)驗(yàn)

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

4.1.1 RPKI 緩存分發(fā)實(shí)驗(yàn)設(shè)計(jì)與結(jié)果分析

實(shí)驗(yàn)中使用五臺(tái)物理機(jī)模擬傳輸架構(gòu)進(jìn)行實(shí)驗(yàn),將五臺(tái)物理機(jī)分別標(biāo)號(hào)為1-5,其中1 號(hào)機(jī)7999 端口作為RP 服務(wù)器,8000 端口作為VC 服務(wù)器,2-5 號(hào)機(jī)依次作為不同層級(jí)的VC 服務(wù)器.

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

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

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

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

本文還對(duì)核心模塊進(jìn)行單獨(dú)測(cè)試,以下給出運(yùn)行結(jié)果.

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

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

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

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

4.1.3 傳輸模塊

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

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

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

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

1) IP 訪問(wèn)控制,完整性檢測(cè)與版本控制

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

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

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

4.2 性能測(cè)試

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

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

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

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

5 結(jié)束語(yǔ)

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

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