冷峰，趙琦，延志偉，曾宇1,

資源公鑰基礎(chǔ)設(shè)施數(shù)據(jù)同步的改進(jìn)方法研究

冷峰1,2,3，趙琦2，延志偉2，曾宇1,2

（1. 中國(guó)科學(xué)院計(jì)算機(jī)網(wǎng)絡(luò)信息中心，北京 100190；2. 中國(guó)互聯(lián)網(wǎng)絡(luò)信息中心，北京 100190；3. 中國(guó)科學(xué)院大學(xué)，北京 100049）

資源公鑰基礎(chǔ)設(shè)施（RPKI）依賴方需定期從資料庫(kù)系統(tǒng)同步數(shù)據(jù)進(jìn)行信息驗(yàn)證。為了完成數(shù)據(jù)同步，當(dāng)前主流的方式是采用Rsync和RRDP兩種技術(shù)，但各自存在著相關(guān)問(wèn)題。針對(duì)上述問(wèn)題，通過(guò)分析研究依賴方從資料庫(kù)同步數(shù)據(jù)的方式，建立了數(shù)學(xué)模型，并根據(jù)兩種技術(shù)各自面臨的相關(guān)問(wèn)題，提出了一種改進(jìn)的RPKI數(shù)據(jù)同步方法，分析了傳統(tǒng)數(shù)據(jù)同步手段與改進(jìn)方法各自的優(yōu)缺點(diǎn)以及適應(yīng)的場(chǎng)景，為優(yōu)化RPKI的部署應(yīng)用提供了參考。

資源公鑰基礎(chǔ)設(shè)施；路由決策；數(shù)據(jù)同步；數(shù)學(xué)模型

1 引言

互聯(lián)網(wǎng)是由眾多計(jì)算機(jī)網(wǎng)絡(luò)相互連接組成的開(kāi)放性網(wǎng)絡(luò)，如何進(jìn)行網(wǎng)間尋址是解決互聯(lián)網(wǎng)互聯(lián)互通的關(guān)鍵問(wèn)題，其中邊界網(wǎng)關(guān)協(xié)議（BGP，border gateway protocol）是互聯(lián)網(wǎng)網(wǎng)間尋址的事實(shí)性標(biāo)準(zhǔn)[1]。

由于在設(shè)計(jì)之初并未充分考慮安全問(wèn)題，BGP存在較大的安全缺陷[2]，所導(dǎo)致的安全事件時(shí)有發(fā)生，典型事件包括：2018年亞馬遜權(quán)威域名服務(wù)器被劫持事件，2019年Verizon的錯(cuò)誤操作導(dǎo)致Facebook、AWS等公司遭遇連鎖性災(zāi)難故障以及2020年俄羅斯電信運(yùn)營(yíng)商路由劫持事件等[3]。以2020年的安全事件為例，俄羅斯運(yùn)營(yíng)商Rostelecom疑似發(fā)生路由劫持事件，包括谷歌、亞馬遜、臉書(shū)等共計(jì)200家CDN供應(yīng)商流量被牽引至俄羅斯。整個(gè)事件持續(xù)約1 h，影響路由條目約8 000條。

為增強(qiáng)域間路由系統(tǒng)安全，多項(xiàng)研究針對(duì)BGP層面的缺陷提出解決方案[4-5]，其中，資源公鑰基礎(chǔ)設(shè)施（RPKI，resource public key infrastructure）是較為成熟且已付諸實(shí)踐的安全技術(shù)之一，是目前最有可能大規(guī)模推廣應(yīng)用的增強(qiáng)路由安全的技術(shù)解決方案[6]。

RPKI通過(guò)構(gòu)建公鑰證書(shū)體系完成對(duì)互聯(lián)網(wǎng)碼號(hào)資源（INR，internet number resource）包括IP前綴和AS號(hào)的所有權(quán)和使用權(quán)的認(rèn)證，并以此“認(rèn)證信息”指導(dǎo)BGP路由器的路由決策，幫助其檢驗(yàn)BGP報(bào)文中路由源信息的真實(shí)性[7]。RPKI的體系結(jié)構(gòu)可主要被劃分為（CA，certification authority）、資料庫(kù)（repository）和依賴方（RP，relying party）3個(gè)基本功能模塊。CA負(fù)責(zé)簽發(fā)證書(shū)標(biāo)識(shí)INR的分配關(guān)系，以及簽發(fā)路由源授權(quán)（ROA，route origin authorization），授權(quán)某個(gè)AS針對(duì)自己的IP前綴發(fā)起路由起源通告等；Repository用于存儲(chǔ)CA發(fā)布的各種包含INR分配信息和授權(quán)信息的證書(shū)，以及ROA、證書(shū)吊銷列表（CRL，certificate revocation list）等數(shù)字簽名對(duì)象，提供給全球RP進(jìn)行同步和驗(yàn)證；RP負(fù)責(zé)從Repository同步RPKI的數(shù)字簽名對(duì)象并進(jìn)行驗(yàn)證，最終把驗(yàn)證結(jié)果提供給BGP路由器，用于指導(dǎo)BGP進(jìn)行可信路由決策[8]。

RP執(zhí)行簽名對(duì)象的驗(yàn)證，因此需要獲得所有Repository公布的簽名對(duì)象數(shù)據(jù)。一旦RPKI在世界范圍內(nèi)大規(guī)模部署，相應(yīng)的數(shù)據(jù)傳輸規(guī)模將迅速增大，對(duì)互聯(lián)網(wǎng)帶寬以及Repository的處理能力等造成較大壓力。針對(duì)RPKI數(shù)據(jù)同步的優(yōu)化對(duì)于保障RPKI在大規(guī)模部署實(shí)施后維護(hù)互聯(lián)網(wǎng)的穩(wěn)定運(yùn)行具有重要意義。

2 RPKI數(shù)據(jù)同步方法概述

目前主流的RPKI數(shù)據(jù)同步方式是Rsync以及RRDP（RPKI repository delta protocol）。針對(duì)RPKI數(shù)據(jù)同步的研究數(shù)量偏少，是由于RPKI部署率仍然較低，數(shù)據(jù)同步未成為RPKI發(fā)展過(guò)程中的主要瓶頸。Kristoff等[9]針對(duì)RP的部署情況進(jìn)行全面評(píng)估，研究了生產(chǎn)環(huán)境中主流RP通過(guò)Rsync以及RRDP等協(xié)議進(jìn)行數(shù)據(jù)同步的頻率、RP在數(shù)據(jù)同步容錯(cuò)性方面的表現(xiàn)等，但并未針對(duì)RP數(shù)據(jù)同步效率方面提出解決方案。

2.1 Rsync數(shù)據(jù)同步方式存在的問(wèn)題

RFC 6480中要求，所有RPKI發(fā)布點(diǎn)都需要支持Rsync，為所有的RP獲取簽名對(duì)象提供服務(wù)[10]。Rsync已經(jīng)在業(yè)界廣泛應(yīng)用，因此在RPKI部署初期Rsync可以較好地用于數(shù)據(jù)同步，無(wú)須另行設(shè)計(jì)一套數(shù)據(jù)同步方案。

隨著RPKI部署工作在全球范圍內(nèi)的逐步開(kāi)展，Rsync顯露出一些有待解決的問(wèn)題，主要表現(xiàn)在：Rsync的設(shè)計(jì)目標(biāo)是在服務(wù)器和客戶端之間傳遞有限規(guī)模的數(shù)據(jù)。由于服務(wù)器端需要為每一個(gè)連接消耗大量的CPU及內(nèi)存資源，一旦RP數(shù)量急劇增加，位于中心的服務(wù)器端將承受巨大的計(jì)算壓力，同時(shí)使Repository容易遭受拒絕服務(wù)攻擊（DoS，denial-of-service）。

此外，Rsync數(shù)據(jù)同步的頻率由各個(gè)RP運(yùn)行者決定，當(dāng)前RPKI缺少對(duì)Rsync機(jī)制的標(biāo)準(zhǔn)化方案。RP[11]通常希望能更快地與Repository保持同步，這是提高RP緩存數(shù)據(jù)及時(shí)性的行之有效的手段。但盲目提高同步頻率的同時(shí)必然帶來(lái)無(wú)效同步請(qǐng)求的提升，造成Repository系統(tǒng)資源的無(wú)謂消耗。此現(xiàn)象導(dǎo)致的后果與數(shù)字證書(shū)更新頻率以及RP數(shù)量成正比，各種因素結(jié)合造成Repository消耗的資源遠(yuǎn)大于合理值。同時(shí)，Rsync數(shù)據(jù)同步的頻率由各個(gè)RP運(yùn)行者決定，根據(jù)經(jīng)驗(yàn)分析，存在較大概率造成部分時(shí)間段Repository同步壓力過(guò)大，其他時(shí)間段Repository又過(guò)于空閑，即無(wú)法合理分配Repository資源。

2.2 RRDP數(shù)據(jù)同步方式存在的問(wèn)題

基于Rsync存在的問(wèn)題，IETF針對(duì)RPKI的數(shù)據(jù)同步機(jī)制提出改進(jìn)方案，利用增量同步Delta協(xié)議替代Rsync，稱作RRDP[12]。RRDP利用Update Notification（更新通知）、Snapshot（快照）以及Delta Files（增量文件）進(jìn)行數(shù)據(jù)同步，并使用HTTPS協(xié)議進(jìn)行數(shù)據(jù)傳輸，便于使用如內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN，content delivery network）等機(jī)制進(jìn)行負(fù)載分擔(dān)，降低Repository的傳輸壓力。

RRDP的更新通知文件包含唯一的會(huì)話ID和序列號(hào)，RP可通過(guò)這兩項(xiàng)的值判斷是否與Repository處于完全同步狀態(tài)。如果未完全同步，Update Notification可以用來(lái)定位Snapshot及Delta Files的位置，RP可進(jìn)一步完成同步工作（快照文件包含了當(dāng)前RPKI資料庫(kù)中所有的對(duì)象）。RP為獲取新的數(shù)據(jù)，會(huì)定期向Repository發(fā)出數(shù)據(jù)同步請(qǐng)求。為保證RP能夠獲取到所有更新信息，Repository需將舊版本的Delta Files保存較長(zhǎng)一段時(shí)間。隨著RPKI CA系統(tǒng)不斷簽發(fā)、更新或撤銷對(duì)象，由此產(chǎn)生的海量的增量文件將對(duì)Repository的緩存基礎(chǔ)設(shè)施提出巨大挑戰(zhàn)[13]。

由此可見(jiàn)，Rsync對(duì)服務(wù)器的計(jì)算能力有較大需求，而RRDP將這種計(jì)算需求轉(zhuǎn)化為較大的存儲(chǔ)需求。兩者在解決RPKI數(shù)據(jù)同步問(wèn)題時(shí)，仍存在一定的改進(jìn)空間。如何對(duì)兩種協(xié)議進(jìn)行融合，充分利用各自優(yōu)勢(shì)提出更佳的數(shù)據(jù)同步方式，是促進(jìn)RPKI部署應(yīng)用的一種有效手段。

2.3 已開(kāi)展的相關(guān)工作

針對(duì)RPKI數(shù)據(jù)同步的問(wèn)題，業(yè)界已逐步開(kāi)展相關(guān)工作。司昊林等[14]研究了增量同步協(xié)議的工作邏輯，并與Rsync進(jìn)行全面對(duì)比，證明了Delta協(xié)議具備較高的安全性和穩(wěn)定性。Kristoff等[9]針對(duì)RP部署情況進(jìn)行測(cè)量，其中一項(xiàng)主要內(nèi)容是統(tǒng)計(jì)了RP的刷新頻率，結(jié)果發(fā)現(xiàn)2019年Rsync仍然是RP主要采用的詢問(wèn)方式。Louis等[15]分析了當(dāng)前五大RIR機(jī)構(gòu)對(duì)RPKI的部署狀態(tài)，評(píng)估了各RIR對(duì)RRDP的支持程度，并提出了一種新的可實(shí)現(xiàn)RPKI核心功能的開(kāi)源軟件，可支持RRDP/Rsync兩種同步方式。

3 RPKI數(shù)據(jù)同步模型

為了直觀理解RPKI數(shù)據(jù)同步的壓力，本節(jié)針對(duì)RPKI數(shù)據(jù)同步建立數(shù)學(xué)模型，用于與后續(xù)提出優(yōu)化的RPKI數(shù)據(jù)同步方式進(jìn)行對(duì)比分析。

RPKI完全部署實(shí)施后，所有RPKI相關(guān)對(duì)象的總體大小可表達(dá)如下。

3.1 以Rsync方式進(jìn)行RPKI數(shù)據(jù)同步的主要步驟

以采用Rsync為手段的數(shù)據(jù)同步為例，根據(jù)Rsync的同步原理，Rsync客戶端（即RP）通過(guò)對(duì)比文件變化的方式保持與服務(wù)端的同步。假設(shè)有兩臺(tái)設(shè)備，其中α為服務(wù)端，控制文件A；β為客戶端，控制文件B，則Rsync算法的處理過(guò)程可歸納為以下幾個(gè)步驟[16]。

（1）β將文件B分割成一組不重疊的固定大小的數(shù)據(jù)塊。

（2）β對(duì)每一個(gè)分割好的數(shù)據(jù)塊執(zhí)行兩種校驗(yàn)：一種是32 bit滾動(dòng)弱校驗(yàn)；另一種是128 bit MD4強(qiáng)校驗(yàn)。

（3）β將這些校驗(yàn)結(jié)果發(fā)給α。

（4）α通過(guò)搜索文件A的所有同樣固定大小的數(shù)據(jù)塊，尋找與文件B的某一塊有相同弱校驗(yàn)碼和強(qiáng)校驗(yàn)碼的數(shù)據(jù)塊。

（5）α發(fā)給β一串指令來(lái)生成文件A在β上的備份（以上指令或者對(duì)文件B的某一個(gè)數(shù)據(jù)塊無(wú)須重傳的證明），或者一個(gè)數(shù)據(jù)塊，此數(shù)據(jù)塊未和文件B的任何一個(gè)數(shù)據(jù)塊匹配。

由以上過(guò)程可知，Rsync的技術(shù)特性更適合于數(shù)量較少的小文件同步，在客戶端與服務(wù)端之間存在相似的文件，對(duì)比后僅傳輸差異部分，這有助于節(jié)省客戶端及服務(wù)端之間的帶寬消耗。但與此同時(shí)，Rsync對(duì)數(shù)量大、體積大的數(shù)據(jù)進(jìn)行同步的效果并不理想，Rsync在處理大量小文件進(jìn)行數(shù)據(jù)同步的時(shí)間過(guò)長(zhǎng)，時(shí)而會(huì)出現(xiàn)進(jìn)程突然停止等異?，F(xiàn)象。同時(shí)，Rsync在同步大文件時(shí)容易無(wú)故中斷，針對(duì)大文件同步場(chǎng)景的適用性和穩(wěn)定性表現(xiàn)不盡理想。

3.2 傳統(tǒng)RPKI數(shù)據(jù)同步在一個(gè)時(shí)間周期內(nèi)的無(wú)效請(qǐng)求次數(shù)

為了進(jìn)一步研究RP數(shù)據(jù)同步效率與各資源消耗之間的關(guān)系，以下描述RP采用Rsync機(jī)制的資源消耗狀況。

以上的情況在RPKI實(shí)施過(guò)程中CA數(shù)據(jù)更新頻率較低時(shí)更為嚴(yán)重。同時(shí)，一旦RP數(shù)量急劇增多，將進(jìn)一步增加無(wú)效Rsync同步查詢的次數(shù)，導(dǎo)致負(fù)面影響加劇。

3.3 傳統(tǒng)RPKI數(shù)據(jù)同步的資源消耗的數(shù)學(xué)模型

對(duì)于一次典型的數(shù)據(jù)同步，其主要的系統(tǒng)資源消耗在于RP數(shù)據(jù)同步請(qǐng)求的接收，RP數(shù)據(jù)塊、Repository數(shù)據(jù)塊的對(duì)比以及對(duì)比結(jié)果回傳等3個(gè)動(dòng)作。

以Rsync同步方式為例，在某一RP發(fā)起數(shù)據(jù)同步請(qǐng)求后，Repository的主要資源消耗可分為三個(gè)步驟：①接收RP的數(shù)據(jù)同步請(qǐng)求；②對(duì)比數(shù)據(jù)塊異同；③返回?zé)o須重傳的證明，或者對(duì)應(yīng)數(shù)據(jù)塊。

則在此周期內(nèi)第個(gè)RP發(fā)起的所有同步請(qǐng)求次數(shù)為

每次同步請(qǐng)求發(fā)生的時(shí)間為

對(duì)于任意RP，其一次常規(guī)的數(shù)據(jù)同步經(jīng)歷的總時(shí)長(zhǎng)可以表示為

則一輪數(shù)據(jù)同步的截止時(shí)間可以表示為

因此，在一個(gè)周期內(nèi)，有效同步的結(jié)束時(shí)間為

4 RPKI數(shù)據(jù)同步的改進(jìn)方案

針對(duì)傳統(tǒng)RPKI數(shù)據(jù)同步存在的問(wèn)題，本文提出了一種RPKI數(shù)據(jù)同步的改進(jìn)方案，改進(jìn)點(diǎn)可概括為以下幾方面。

（1）建立主動(dòng)通知機(jī)制，利用Repository建立RP資料庫(kù)，由Repository主動(dòng)發(fā)起數(shù)據(jù)同步通知。

（2）提出慢啟動(dòng)數(shù)據(jù)傳輸機(jī)制，在Repository主動(dòng)發(fā)起數(shù)據(jù)同步通知時(shí)，按照批次向RP發(fā)出同步通知。

（3）改進(jìn)方案的有效性和效能可通過(guò)教學(xué)模型及仿真實(shí)驗(yàn)加以驗(yàn)證。

（4）設(shè)立增量文件監(jiān)測(cè)系統(tǒng)，及時(shí)刪除訪問(wèn)頻率低的增量文件。

（5）根據(jù)以上機(jī)制存在的安全風(fēng)險(xiǎn)增加RP安全認(rèn)證機(jī)制。

其中，（1）、（2）方面用于減少RP對(duì)Repository的無(wú)效同步請(qǐng)求，降低Repository的無(wú)效負(fù)載，第（4）方面用于緩解Repository存儲(chǔ)空間壓力，第（5）方面用于增強(qiáng)系統(tǒng)安全。

4.1 建立主動(dòng)通知機(jī)制

在初始階段，Repository并不知道RP的具體信息，因此RP一開(kāi)始需自發(fā)發(fā)起對(duì)Repository的數(shù)據(jù)同步請(qǐng)求。RP在前往某一Repository獲得數(shù)據(jù)的同時(shí)，Repository需記錄RP的IP地址，并將其添加至RP列表。Repository在產(chǎn)生新的更新通知時(shí)，將更新通知文件的URI主動(dòng)發(fā)送給列表中的RP。在RPKI廣泛部署、RP數(shù)量眾多的情況下，可采用如CDN等降低發(fā)送主動(dòng)通知給RPKI資料庫(kù)帶來(lái)的壓力。當(dāng)產(chǎn)生數(shù)據(jù)更新時(shí)，RPKI資料庫(kù)將觸發(fā)CDN機(jī)制為列表中的RP發(fā)送主動(dòng)通知。

4.2 提出慢啟動(dòng)數(shù)據(jù)傳輸機(jī)制

在RRDP中，RP端的數(shù)據(jù)同步依靠RP定期前往Repository拉取實(shí)現(xiàn)，Repository僅能被動(dòng)提供相關(guān)數(shù)據(jù)，缺乏統(tǒng)一協(xié)調(diào)機(jī)制，易出現(xiàn)由于各RP數(shù)據(jù)同步時(shí)間重合而引發(fā)的Repository瞬時(shí)壓力陡增，或RP查詢頻率過(guò)高而導(dǎo)致Repository產(chǎn)生無(wú)謂的資源浪費(fèi)等情形。第3節(jié)利用數(shù)學(xué)模型討論了RP產(chǎn)生的無(wú)效請(qǐng)求次數(shù)。但RPKI數(shù)據(jù)同步模型可被歸類為客戶端/服務(wù)器模式（C/S模式）。位于中心的Repository作為服務(wù)器端，要同時(shí)響應(yīng)來(lái)自各個(gè)區(qū)域的RP的同步請(qǐng)求?？紤]到RP的數(shù)據(jù)同步時(shí)間將因Repository負(fù)載的動(dòng)態(tài)變化而受到相應(yīng)影響，在有數(shù)據(jù)更新時(shí)統(tǒng)一向所有RP發(fā)出更新通知并不是最優(yōu)解決方案。為了避免同步操作過(guò)于集中，優(yōu)化數(shù)據(jù)同步表現(xiàn)，本文提出慢啟動(dòng)機(jī)制，在Repository主動(dòng)發(fā)起數(shù)據(jù)同步通知時(shí)，按照批次向RP發(fā)出同步通知。

4.3 RPKI數(shù)據(jù)同步改進(jìn)方案的數(shù)學(xué)模型

對(duì)于返回?cái)?shù)據(jù)塊操作的持續(xù)時(shí)間可用同樣的公式表示。

基于以上式子和前文表述，可以計(jì)算完成一輪數(shù)據(jù)更新的截止時(shí)間為

將新舊兩種方法完成一輪數(shù)據(jù)更新的截止時(shí)間相比較，可以看出，當(dāng)公式右側(cè)第二、三個(gè)變量相同時(shí)，數(shù)據(jù)更新總時(shí)間主要由第一個(gè)變量決定。而影響第一個(gè)變量的主要因素包括RP數(shù)量、Repository處理能力以及簽名對(duì)象更新頻率等。在RP數(shù)量較少、簽名對(duì)象更新頻率較低以及Repository處理能力較強(qiáng)的場(chǎng)景，原數(shù)據(jù)同步手段的處理總時(shí)長(zhǎng)較短，反之則新的數(shù)據(jù)同步方式更具優(yōu)勢(shì)。并且，在一個(gè)簽名對(duì)象更新周期內(nèi)一旦完成數(shù)據(jù)同步，新方案不會(huì)產(chǎn)生多余的無(wú)效更新通知，而原有方案則仍會(huì)源源不斷地定期產(chǎn)生無(wú)效更新請(qǐng)求。

其結(jié)束時(shí)間是最后一批向RP發(fā)送數(shù)據(jù)更新通知的結(jié)束時(shí)間，即

則

根據(jù)上述公式，可以計(jì)算針對(duì)第二階段，即對(duì)比數(shù)據(jù)塊異同動(dòng)作的起始時(shí)間，按照每輪動(dòng)作為一個(gè)單位，表示為

則其結(jié)束時(shí)間為

即

針對(duì)第三階段，即返回?cái)?shù)據(jù)塊動(dòng)作的開(kāi)始結(jié)束時(shí)間的推演過(guò)程可參考第二階段。

則判斷時(shí)刻Repository正在執(zhí)行的動(dòng)作，可以由以下式子表示。

注：以上同樣僅考慮有效的數(shù)據(jù)同步。

從兩者同步方式的原理可以直觀得出以下結(jié)論：由于新的數(shù)據(jù)同步方式將RP的同步請(qǐng)求進(jìn)行分時(shí)處置，對(duì)于時(shí)刻承載的任務(wù)量明顯小于原數(shù)據(jù)同步方式，在頻繁產(chǎn)生簽名對(duì)象更新以及大量RP需開(kāi)展數(shù)據(jù)同步請(qǐng)求的情形下，可有效優(yōu)化Repository負(fù)載。

為對(duì)比兩種數(shù)據(jù)同步方式的差異，假設(shè)條件如下：①共有10個(gè)RP需進(jìn)行數(shù)據(jù)同步；②傳統(tǒng)RPKI同步周期為4 min；③以Repository系統(tǒng)處理能力為基準(zhǔn)，其總處理表示為100%。④rsyc、compare、reply所占用的系統(tǒng)處理能力（即系統(tǒng)消耗量）各為10%。

根據(jù)以上假設(shè)，結(jié)合前文描述的兩種數(shù)據(jù)同步方式的數(shù)據(jù)量描述，兩種數(shù)據(jù)同步方式下Repository系統(tǒng)負(fù)載情況如圖1所示。其中，點(diǎn)狀綠色面積代表傳統(tǒng)RPKI數(shù)據(jù)同步機(jī)制下在同步過(guò)程中的系統(tǒng)消耗情況，紫色區(qū)域面積代表改進(jìn)RPKI數(shù)據(jù)同步機(jī)制下在同步過(guò)程中的系統(tǒng)消耗情況，綠色區(qū)域代表兩種數(shù)據(jù)同步方式同時(shí)占用的系統(tǒng)消耗情況。可以看出，相較于傳統(tǒng)同步機(jī)制，改進(jìn)的同步方法可以更加合理地調(diào)用系統(tǒng)資源，同時(shí)可有效減少在同步空閑時(shí)間對(duì)Repository系統(tǒng)的無(wú)效占用，降低系統(tǒng)無(wú)謂消耗。

圖1 RPKI 數(shù)據(jù)同步系統(tǒng)負(fù)載比較

4.4 設(shè)立增量文件監(jiān)測(cè)系統(tǒng)

RFC 8182中建議，當(dāng)增量文件大小總和大于快照文件大小時(shí)，RP不應(yīng)繼續(xù)采用增量更新的方式進(jìn)行同步，以免造成不必要的文件傳輸[17]。此時(shí)應(yīng)啟動(dòng)清理機(jī)制，將早期的增量文件刪除，從而保證RP請(qǐng)求增量文件的總消耗始終小于請(qǐng)求快照文件的消耗，從而降低系統(tǒng)負(fù)載。以上機(jī)制對(duì)于RRDP數(shù)據(jù)同步方式而言，一方面避免了增量更新情形下不必要的數(shù)據(jù)傳輸，另一方面提出了較小限度地減小Repository磁盤(pán)空間占用的清理機(jī)制。但隨著RPKI的逐步推廣，快照文件將根據(jù)RPKI對(duì)象數(shù)量多少以及變化頻率逐步變大，相應(yīng)對(duì)于增量更新文件的清理周期會(huì)逐步變長(zhǎng)。根據(jù)本文提出的主動(dòng)通知機(jī)制，常規(guī)情況下，絕大多數(shù)RP開(kāi)展新的數(shù)據(jù)同步操作時(shí)以訪問(wèn)較新的增量文件為主，較早版本的增量文件被訪問(wèn)的概率極低，將長(zhǎng)時(shí)間存儲(chǔ)在Repository中，對(duì)資料庫(kù)造成不必要的負(fù)載。為了進(jìn)一步優(yōu)化系統(tǒng)占用，本文提出增量文件監(jiān)測(cè)系統(tǒng)。

4.5 增加RP安全認(rèn)證機(jī)制

增加的主動(dòng)通知機(jī)制將成為數(shù)據(jù)同步的關(guān)鍵環(huán)節(jié)，即通知功能集中在Repository處。假設(shè)不增加任何限制，黑客可通過(guò)偽造RP的方式短時(shí)間內(nèi)向Repository發(fā)送大量同步請(qǐng)求，導(dǎo)致Repository無(wú)法響應(yīng)正常同步請(qǐng)求，造成服務(wù)中斷。為緩解以上威脅，在增加主動(dòng)通知機(jī)制的同時(shí)，應(yīng)輔以認(rèn)證機(jī)制。具體做法為：首先驗(yàn)證RP端的合法身份，如利用帶外的方式令RP端完成身份認(rèn)證，成功后加入合法RP地址列表；其次為每一個(gè)合法RP派發(fā)數(shù)據(jù)同步密鑰，在Repository主動(dòng)發(fā)起數(shù)據(jù)同步通知時(shí)，雙方利用密鑰完成身份認(rèn)證后方可進(jìn)行數(shù)據(jù)傳輸。

需要注意的是，在現(xiàn)有的RPKI數(shù)據(jù)同步機(jī)制中，Repository對(duì)外提供公開(kāi)類別的服務(wù)，并未設(shè)定關(guān)于RP的身份認(rèn)證機(jī)制。為了能與現(xiàn)有機(jī)制充分保持一致，Repository應(yīng)最大限度響應(yīng)由RP主動(dòng)發(fā)起的數(shù)據(jù)同步請(qǐng)求，此時(shí)的安全防護(hù)策略與現(xiàn)有機(jī)制下的防護(hù)策略并無(wú)明顯差異。

5 仿真實(shí)驗(yàn)

為驗(yàn)證改進(jìn)方案的有效性，以下搭建模擬環(huán)境后并利用仿真實(shí)驗(yàn)開(kāi)展驗(yàn)證。設(shè)計(jì)思路為使用虛擬機(jī)建立Repository以及RP，采用傳統(tǒng)RPKI數(shù)據(jù)同步方式以及改進(jìn)方案分別完成數(shù)據(jù)同步，對(duì)比兩種方式下Repository系統(tǒng)的CPU以及I/O負(fù)載變化情況。為了突出主要矛盾，以下選定Rsync同步方式與改進(jìn)方案進(jìn)行性能對(duì)比。

以兩臺(tái)x86主機(jī)搭建實(shí)驗(yàn)環(huán)境，其中一臺(tái)主機(jī)承載Repository功能，另一臺(tái)承載RP功能，實(shí)驗(yàn)環(huán)境系統(tǒng)架構(gòu)如圖2所示。

圖2 實(shí)驗(yàn)環(huán)境系統(tǒng)架構(gòu)

Figure 2 Experimental environment system architecture

表1 實(shí)驗(yàn)環(huán)境系統(tǒng)信息

實(shí)驗(yàn)環(huán)境系統(tǒng)信息如表1所示。

為了對(duì)比兩種同步方式的差異，設(shè)定以下兩種場(chǎng)景模擬各自同步操作。

（1）對(duì)于Rsync同步方式，Repository目錄中存儲(chǔ)同步文件大小為200～500 MB，更新頻率3 min；所有RP同時(shí)更新，更新頻率設(shè)置為1min。為了同時(shí)對(duì)比加密傳輸時(shí)對(duì)Repository系統(tǒng)的負(fù)載情況，設(shè)定了在啟用/非啟用加密數(shù)據(jù)傳輸時(shí)的同步場(chǎng)景。

（2）對(duì)于改進(jìn)的同步方式，Repository目錄中存儲(chǔ)同步文件以及RP設(shè)定與上一種情況一致。設(shè)定Repository向所有RP發(fā)起同步通知，以分組的方式發(fā)出通知信息，每3個(gè)RP為一組。

以上情形設(shè)定可在相似基礎(chǔ)條件下客觀評(píng)測(cè)兩種更新方式為Repository帶來(lái)的壓力。

經(jīng)過(guò)多輪評(píng)測(cè)，針對(duì)不同情形，分別記錄Repository系統(tǒng)壓力以及傳輸時(shí)間。整個(gè)測(cè)試期間為三組更新，其中每個(gè)周期內(nèi)文件的大小不一。圖3展示了改進(jìn)方式下的測(cè)試情況。

如圖3所示，在改進(jìn)方式下，共統(tǒng)計(jì)了Repository在3個(gè)變更周期下的系統(tǒng)占用情況，主要以CPU占用率為主要參考依據(jù)。從圖中數(shù)據(jù)可以看出，第一個(gè)周期于108 s完成同步，第二個(gè)周期于82 s完成同步，第三個(gè)周期于73 s完成同步，同時(shí)，系統(tǒng)資源占用較為穩(wěn)定，整體占用率小于50%。

圖4展示了默認(rèn)的Rsync同步方式的測(cè)試情況。在默認(rèn)的Rsync同步方式下，第一個(gè)周期于114 s完成同步，第二個(gè)周期于118 s完成同步，第三個(gè)周期于100 s完成同步，系統(tǒng)資源占用相對(duì)有較大波動(dòng)，但平均系統(tǒng)占用在30%以下，部分時(shí)刻系統(tǒng)占用率突發(fā)至45%左右?？梢钥闯觯捎赗sync未使用加密傳輸方式，其對(duì)系統(tǒng)資源的消耗小于改進(jìn)方式，但3個(gè)周期的傳輸速率相對(duì)改進(jìn)方式分別有5.56%、43.90%、36.99%的滯后。隨著RP同步時(shí)間的逐步延長(zhǎng)，改進(jìn)方式的同步效率優(yōu)勢(shì)則更為明顯。

圖3 改進(jìn)方式的系統(tǒng)占用統(tǒng)計(jì)

Figure 3 Improved mechanism occupancy statistics

圖4 Rsync同步的系統(tǒng)占用統(tǒng)計(jì)

Figure 4 Rsync synchronization system occupancy statistics

圖5展示啟用加密傳輸后Rsync同步的測(cè)試情況，此舉是為了側(cè)面驗(yàn)證在實(shí)施安全手段后對(duì)系統(tǒng)性能的損耗。帶有加密的Rsync同步方式下，第一個(gè)周期于153 s完成同步，第二個(gè)周期于118 s完成同步，第三個(gè)周期于101 s完成同步，系統(tǒng)資源占用相對(duì)穩(wěn)定，平均系統(tǒng)占用在60%以下。可以看出，在使用加密手段后，Rsync對(duì)系統(tǒng)資源的消耗進(jìn)一步加大，同時(shí)3個(gè)周期的傳輸速率相對(duì)改進(jìn)方式分別有41.67%、43.90%、38.36%的滯后，加密方式對(duì)于數(shù)據(jù)傳輸造成明顯影響。

同時(shí)從圖5中可以看出，Rsync在周期外系統(tǒng)資源的小幅占用明顯高于改進(jìn)方式，這是由于無(wú)效Rsync對(duì)比操作而形成的資源浪費(fèi)，改進(jìn)方式可以顯著消除此部分系統(tǒng)占用，進(jìn)一步優(yōu)化系統(tǒng)效率。

圖5 帶加密的Rsync同步的系統(tǒng)占用統(tǒng)計(jì)

Figure 5 System occupancy statistics of encrypted Rsync synchronization

實(shí)驗(yàn)數(shù)據(jù)統(tǒng)計(jì)結(jié)果如表2所示。

表2 實(shí)驗(yàn)數(shù)據(jù)統(tǒng)計(jì)結(jié)果

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

本文針對(duì)RPKI數(shù)據(jù)同步進(jìn)行研究，分析了Rsync以及RRDP各自面臨的問(wèn)題，并提出針對(duì)性改進(jìn)方案，同時(shí)利用數(shù)學(xué)模型對(duì)比了新舊數(shù)據(jù)同步方法的優(yōu)劣，指出了各自適應(yīng)的應(yīng)用環(huán)境。

本文的研究存在兩方面局限：（1）為了突出主要問(wèn)題，研究過(guò)程中對(duì)于某些因素進(jìn)行了部分簡(jiǎn)化，如未過(guò)多考慮網(wǎng)絡(luò)傳輸時(shí)延的影響，針對(duì)Repository壓力的計(jì)算也僅測(cè)算了有效傳輸?shù)牟糠?；?）未在現(xiàn)行RPKI生產(chǎn)環(huán)境中進(jìn)行實(shí)際驗(yàn)證。后續(xù)的研究工作可以從以上方面著手改進(jìn)。一是可以進(jìn)一步全面評(píng)估改進(jìn)算法對(duì)Repository以及RP產(chǎn)生的影響，可結(jié)合當(dāng)前Repository和RP的實(shí)際數(shù)量及負(fù)載等現(xiàn)狀進(jìn)行綜合評(píng)估；二是可以在生產(chǎn)環(huán)境中搭建原型系統(tǒng)，使部分Repository與RP間利用改進(jìn)方法進(jìn)行數(shù)據(jù)同步并供少量用戶實(shí)際使用，驗(yàn)證改進(jìn)方案的有效性和穩(wěn)定性。若能有效解決上述問(wèn)題，RPKI數(shù)據(jù)同步改進(jìn)方案可逐步在生產(chǎn)環(huán)境中推廣應(yīng)用，成為優(yōu)化RPKI數(shù)據(jù)傳輸?shù)挠行侄巍?/p>

[1] 龐超, 李曉紅. BGP4+協(xié)議研究與應(yīng)用[J].無(wú)線電工程, 2011, 41(2): 4-6.

PANG C, LI X H. Study and application of BGP4+ protocol[J]. Radio Engineering, 2011, 41(2): 4-6.

[2] 黎松, 諸葛建偉, 李星. BGP安全研究[J]. 軟件學(xué)報(bào), 2013, 24(1): 121-138.

LI S, ZHUGE J W, LI X. BGP security research[J]. Journal of Software, 2013, 24(1): 121-138.

[3] SARA B, HAFSSA, MOUAD B M. Security problems in BGP: An overview[C]//2013 National Security Days (JNS3). 2013: 1-5.

[4] IETF. Secure BGP (S-BGP)[S].

[5] IETF. Extensions to BGP to support secure origin BGP (soBGP)[S].

[6] RIPE NCC. Number of certificates[S].

[7] 賈佳, 延志偉, 耿光剛, 等. 一種改進(jìn)的BGP路由源認(rèn)證機(jī)[J]. 計(jì)算機(jī)系統(tǒng)應(yīng)用, 2017(1): 240-245.

JIA J, YAN Z W, GENG G G. An improved BGP routing source authentication mechanism[J]. Computer Systems Application, 2017(1): 240-245.

[8] 蘇瑩瑩, 李丹, 葉洪琳. 資源公鑰基礎(chǔ)設(shè)施RPKI：現(xiàn)狀與問(wèn)題[J].電信科學(xué), 2021, 37(3): 75-89.

SU Y Y, LI D, YE H L. Resource public key infrastructure RPKI: status and problems[J]. Telecommunications Science, 2021, 37(3): 75-89.

[9] KRISTOFF J, RANDY B, CHRIS K, et al. On measuring RPKI relying parties[C]//Proceedings of the ACM Internet Measurement Conference(IMC '20). 2020: 484-491.

[10] IETF. An infrastructure to support secure internet routing[S].

[11] WEBERB, BRUIJNZEELST, MURAVSKIYO. RPKI repository analysis and requirements[R].

[12] IETF. The RPKI repository delta protocol (RRDP)[S].

[13] OSTERWEIL E, MANDERSON T. Sizing estimates for a fully deployed RPKI[R].

[14] 司昊林, 馬迪, 毛偉, 等. RPKI增量同步Delta協(xié)議的形式化檢測(cè)與實(shí)現(xiàn)[J]. 計(jì)算機(jī)系統(tǒng)應(yīng)用, 2018, 27(11): 1-8.

SI H L, MA D, MAO W. Formal verification and implementation of RPKI incremental synchronous delta protocol[J]. Computer Systems Application, 2018, 27(11): 1-8.

[15] LOUIS P, MARTIN J L. Cloudflare and RPKI at scale[EB].

[16] 王賓,劉釗遠(yuǎn).基于Rsync的遠(yuǎn)程文件同步優(yōu)化模型[J].計(jì)算機(jī)與現(xiàn)代化,2015(4):10-13.

WANG B, LIU Z Y. Optimization model of remote file synchronization based on Rsync algorithm[J]. Computer and Modernization, 2015(4):10-13.

[17] PHOKEERA.Interdomain routing security: motivation and challenges of RPKI [D]. Royal Holloway, University of London, 2014.

Research on improved scheme of resource public key infrastructure data synchronization

LENG Feng1, 2, 3, ZHAO Qi2, YAN Zhiwei2, ZENG Yu1, 2

1. Computer Network Information Center, Chinese Academy of Sciences, Beijing 100190, China 2. China Internet Network Information Center, Beijing 100190, China 3. University of Chinese Academy of Sciences, Beijing 100049, China

RPKI Relying party needs to synchronizing data from repository periodically to verify information. In general, Rsync and RRDP are the two common means to complete data synchronization, however, each of them has related problems. In order to solve these problems, through analyzingthe way for synchronizing data from repository by the relying party, a mathematical model was established. Furthermore, based on the current problems faced by the two synchronization means, an improved RPKI data synchronization scheme was proposed. The advantages and disadvantages of the improved scheme were analyzed in detail, as well as the applicable scenarios. The improved scheme could provide a reference for optimizing the deployment and application of RPKI.

resource public key infrastructure, routing decision, data synchronization, mathematical model

TN915.08

A

10.11959/j.issn.2096?109x.2021064

2020?12?22；

2021?03?23

曾宇，zengyu@cnnic.cn

北京市科技新星計(jì)劃項(xiàng)目（Z191100001119113）

Beijing Nova Program of Science and Technology (Z191100001119113)

冷峰, 趙琦, 延志偉, 等. 資源公鑰基礎(chǔ)設(shè)施數(shù)據(jù)同步的改進(jìn)方法研究[J]. 網(wǎng)絡(luò)與信息安全學(xué)報(bào), 2021, 7(3): 123-133.

LENG F, ZHAO Q, YAN Z W, et al. Research on improved scheme of resource public key infrastructure data synchronization[J]. Chinese Journal of Network and Information Security, 2021, 7(3): 123-133.

冷峰（1982?），男，山東萊陽(yáng)人，中國(guó)科學(xué)院大學(xué)博士生，中國(guó)互聯(lián)網(wǎng)絡(luò)信息中心高級(jí)工程師，主要研究方向?yàn)榛ヂ?lián)網(wǎng)基礎(chǔ)資源安全。

趙琦（1982?），男，吉林長(zhǎng)春人，中國(guó)互聯(lián)網(wǎng)絡(luò)信息中心高級(jí)工程師，主要研究方向?yàn)橄到y(tǒng)架構(gòu)設(shè)計(jì)、優(yōu)化和網(wǎng)絡(luò)安全。

延志偉（1985?），男，山西興縣人，博士，中國(guó)互聯(lián)網(wǎng)絡(luò)信息中心研究員，主要研究方向?yàn)榛ヂ?lián)網(wǎng)名址協(xié)議及下一代網(wǎng)絡(luò)架構(gòu)。

曾宇（1973?），男，湖南邵陽(yáng)人，博士，中國(guó)互聯(lián)網(wǎng)絡(luò)信息中心研究員，主要研究方向?yàn)橛?jì)算機(jī)體系結(jié)構(gòu)、網(wǎng)絡(luò)安全、數(shù)字經(jīng)濟(jì)。