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

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

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

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

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

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

1 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（2）β對每一個分割好的數(shù)據(jù)塊執(zhí)行兩種校驗：一種是32 bit滾動弱校驗；另一種是128 bit MD4強校驗。

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

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

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

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

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

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

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

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

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

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

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

每次同步請求發(fā)生的時間為

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

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

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

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

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

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

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

（3）改進方案的有效性和效能可通過教學模型及仿真實驗加以驗證。

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

（5）根據(jù)以上機制存在的安全風險增加RP安全認證機制。

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

4.1 建立主動通知機制

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

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

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

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

對于返回數(shù)據(jù)塊操作的持續(xù)時間可用同樣的公式表示。

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

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

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

則

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

則其結(jié)束時間為

即

針對第三階段，即返回數(shù)據(jù)塊動作的開始結(jié)束時間的推演過程可參考第二階段。

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

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

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

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

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

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

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

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

4.5 增加RP安全認證機制

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

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

5 仿真實驗

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

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

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

Figure 2 Experimental environment system architecture

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

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

為了對比兩種同步方式的差異，設定以下兩種場景模擬各自同步操作。

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

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

以上情形設定可在相似基礎條件下客觀評測兩種更新方式為Repository帶來的壓力。

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

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

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

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

Figure 3 Improved mechanism occupancy statistics

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

Figure 4 Rsync synchronization system occupancy statistics

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

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

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

Figure 5 System occupancy statistics of encrypted Rsync synchronization

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

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

6 結(jié)束語

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

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

[1] 龐超, 李曉紅. BGP4+協(xié)議研究與應用[J].無線電工程, 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]. 軟件學報, 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] 賈佳, 延志偉, 耿光剛, 等. 一種改進的BGP路由源認證機[J]. 計算機系統(tǒ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] 蘇瑩瑩, 李丹, 葉洪琳. 資源公鑰基礎設施RPKI：現(xiàn)狀與問題[J].電信科學, 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é)議的形式化檢測與實現(xiàn)[J]. 計算機系統(tǒ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] 王賓,劉釗遠.基于Rsync的遠程文件同步優(yōu)化模型[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

北京市科技新星計劃項目（Z191100001119113）

Beijing Nova Program of Science and Technology (Z191100001119113)

冷峰, 趙琦, 延志偉, 等. 資源公鑰基礎設施數(shù)據(jù)同步的改進方法研究[J]. 網(wǎng)絡與信息安全學報, 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?），男，山東萊陽人，中國科學院大學博士生，中國互聯(lián)網(wǎng)絡信息中心高級工程師，主要研究方向為互聯(lián)網(wǎng)基礎資源安全。

趙琦（1982?），男，吉林長春人，中國互聯(lián)網(wǎng)絡信息中心高級工程師，主要研究方向為系統(tǒng)架構(gòu)設計、優(yōu)化和網(wǎng)絡安全。

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

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