Rpki文件的同步方法及裝置的制造方法
【技術(shù)領(lǐng)域】
[0001] 本發(fā)明設(shè)及計算機技術(shù)領(lǐng)域，尤其設(shè)及一種資源公鑰證書體系巧esourcePublic IfeyIn化astruc化re,簡稱RPKI)文件的同步方法及裝置。
【背景技術(shù)】
[0002] 作為支撐互聯(lián)網(wǎng)基礎(chǔ)設(shè)施的域間路由系統(tǒng)，對互聯(lián)網(wǎng)的安全有著至關(guān)重要的影 響。由于邊界網(wǎng)關(guān)協(xié)議度orderGatewayProtocol,簡稱BGP)缺乏對路由通告內(nèi)容真實 性的保證，黑客的蓄意攻擊行為W及錯誤的網(wǎng)絡(luò)參數(shù)配置都可W導(dǎo)致路由劫持現(xiàn)象的發(fā) 生。為了增強域間路由系統(tǒng)的安全性，因此引入了互聯(lián)網(wǎng)基礎(chǔ)RPKI。RPKI構(gòu)建了個公鑰 證書體系（PublicKeyInfrast;ruc1:ure，簡稱PKI)來完成對互聯(lián)網(wǎng)碼號資源（Internet NumberResource,簡稱INR)的所有權(quán)和使用權(quán)的認(rèn)證，并W路由源聲明（Route化igin Attestation,簡稱R0A)的形式幫助域間路由系統(tǒng)，驗證某個自治系統(tǒng)（Autonomous System,簡稱A巧號針對特定網(wǎng)絡(luò)互連協(xié)議（InternetProtocol,簡稱I巧地址前綴的路由 通告是否合法，從而避免路由劫持；其中，INR包括IP地址前綴和AS號。
[0003] RPKI包括S大基本組件：認(rèn)證權(quán)威（CertificateAuthority,簡稱CA)、依賴方 (RelyingParty,簡稱RP)和資料庫Cr巧ository)。運立大組件通過簽發(fā)、傳送、存儲、驗證 各種數(shù)字對象（包括各種簽名對象和證書）來彼此協(xié)作，共同完成RPKI的功能。CA通過簽 發(fā)資源證書巧esourceCedificate,簡稱RC)將資源持有者和其持有的INR關(guān)聯(lián)起來，也 可W通過簽發(fā)路由起源聲明（Route化iginAuthorization,簡稱R0A)來授權(quán)某個互聯(lián)網(wǎng) 服務(wù)提供商（InternetServiceProvider,簡稱ISFO針對自己的一部分IP地址前綴發(fā)起 源路由通告，ROA包含一個AS號與一個或多個IP地址前綴之間的"綁定關(guān)系";RPKI中所 有數(shù)字對象都在RPKI資料庫存儲并加W發(fā)布，供全球的RP下載；RP負責(zé)從RPKI資料庫中 下載同步運些數(shù)字對象，將驗證之后的ROA分發(fā)給相關(guān)的邊界路由器。當(dāng)有新的路由通告 到達運些邊界路由器時，RP提供的ROA就成為邊界路由器判斷路由通告是否可信的一個依 據(jù)。
[0004] 現(xiàn)有技術(shù)中，RPKI體系的RP端在同步數(shù)據(jù)時使用的是開源軟件rsync，RP端在同 步文件時需要將文件讀入內(nèi)存進行分塊和計算校驗值，假設(shè)塊大小為S個字節(jié)，并將所有 校驗值傳給部署RPKI資料庫的設(shè)備，該設(shè)備對RPKI資料庫中文件進行同樣的分塊處理并 計算校驗值，將接收到的校驗值和計算出的校驗值進行比較，從而判斷文件是否相同，RP端 是否需要同步，將RP端需要同步的文件傳輸給RP端。上述過程中，RP端和部署RPKI資料 庫的設(shè)備都需要將文件讀入內(nèi)存進行分塊，如果文件數(shù)量巨大，那么讀取數(shù)量龐大的文件 會占用很多的1/0資源，同步數(shù)據(jù)時的效率較低。

【發(fā)明內(nèi)容】

[0005] 本發(fā)明提供一種RPKI文件的同步方法及裝置，W克服現(xiàn)有技術(shù)中讀取數(shù)量龐大 的文件會占用很多的1/0資源，同步數(shù)據(jù)時的效率較低的問題。
[0006] 第一方面，本發(fā)明提供一種RPKI文件的同步方法，包括：
[0007] 接收依賴方RP端發(fā)送的文件同步請求，所述文件同步請求包括RP端目錄對應(yīng)的 第一有序哈希樹；
[0008] 獲取資源公鑰證書體系RPKI資料庫中目錄對應(yīng)的第二有序哈希樹；其中，所述第 一有序哈希樹和所述第二有序哈希樹分別由樹節(jié)點組成；
[0009] 遍歷所述第一有序哈希樹W及所述第二有序哈希樹，根據(jù)所述第一有序哈希樹和 所述第二有序哈希樹中樹節(jié)點的信息，確定所述RP端需同步的文件。
[0010] 第二方面，本發(fā)明提供一種RPKI文件的同步裝置，包括：
[0011] 接收模塊，用于接收依賴方RP端發(fā)送的文件同步請求，所述文件同步請求包括RP 端目錄對應(yīng)的第一有序哈希樹；
[0012] 獲取模塊，用于獲取資源公鑰證書體系RPKI資料庫中目錄對應(yīng)的第二有序哈希 樹；其中，所述第一有序哈希樹和所述第二有序哈希樹分別由樹節(jié)點組成；
[0013] 處理模塊，用于遍歷所述第一有序哈希樹W及所述第二有序哈希樹，根據(jù)所述第 一有序哈希樹和所述第二有序哈希樹中樹節(jié)點的信息，確定所述RP端需同步的文件。
[0014] 本發(fā)明提供的RPKI文件的同步方法及裝置，在同步時，首先獲取到RP端目錄對應(yīng) 的第一有序哈希樹W及RPKI資料庫中目錄對應(yīng)的第二有序哈希樹；然后遍歷所述第一有 序哈希樹W及所述第二有序哈希樹，根據(jù)所述第一有序哈希樹和所述第二有序哈希樹中樹 節(jié)點的信息，確定所述RP端需同步的文件，與現(xiàn)有技術(shù)相比，無需讀取數(shù)量龐大的文件，也 無需將文件進行分塊，直接獲取目錄對應(yīng)的有序哈希樹，遍歷有序哈希樹的樹節(jié)點，比現(xiàn)有 的分塊處理能夠更直接快速的查找到需同步的文件，同步數(shù)據(jù)時的效率較高，而且讀取目 錄對應(yīng)的有序哈希樹比讀取文件占用的I/O資源少的多。
【附圖說明】
[0015] 為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對實施例或現(xiàn) 有技術(shù)描述中所需要使用的附圖作一簡單地介紹，顯而易見地，下面描述中的附圖是本發(fā) 明的一些實施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動性的前提下，還可W 根據(jù)運些附圖獲得其他的附圖。
[0016] 圖1為本發(fā)明RPKI文件的同步方法一實施例的流程示意圖；
[0017] 圖2為本發(fā)明實施例的RPKI文件尺寸分布圖；
[0018] 圖3為本發(fā)明方法實施例中目錄轉(zhuǎn)化有序哈希樹的示意圖；
[0019] 圖4A為本發(fā)明方法實施例的第一有序哈希樹示意圖；
[0020] 圖4B為本發(fā)明方法實施例的第二有序哈希樹示意圖；
[0021] 圖5A為本發(fā)明方法另一實施例的第二有序哈希樹示意圖；
[0022] 圖5B為本發(fā)明方法另一實施例的第一有序哈希樹示意圖；
[0023] 圖5C為圖5B中經(jīng)過同步后的第一有序哈希樹示意圖；
[0024] 圖6A為本發(fā)明方法又一實施例的第一有序哈希樹示意圖； 陽0巧]圖6B為本發(fā)明方法又一實施例的第二有序哈希樹示意圖；
[00%] 圖6C為圖6A中經(jīng)過同步后的第一有序哈希樹示意圖；
[0027] 圖7為本發(fā)明RPKI文件的同步裝置一實施例的結(jié)構(gòu)示意圖。
【具體實施方式】
[0028] 為使本發(fā)明實施例的目的、技術(shù)方案和優(yōu)點更加清楚，下面將結(jié)合本發(fā)明實施例 中的附圖，對本發(fā)明實施例中的技術(shù)方案進行清楚、完整地描述，顯然，所描述的實施例是 本發(fā)明一部分實施例，而不是全部的實施例。基于本發(fā)明中的實施例，本領(lǐng)域普通技術(shù)人員 在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。
[0029] 本發(fā)明實施例設(shè)及的方法，旨在解決現(xiàn)有技術(shù)中讀取數(shù)量龐大的文件會占用很多 的I/O資源，同步數(shù)據(jù)時的效率較低的技術(shù)問題。
[0030] 下面W具體地實施例對本發(fā)明的技術(shù)方案進行詳細說明。下面運幾個具體的實施 例可W相互結(jié)合，對于相同或相似的概念或過程可能在某些實施例不再寶述。
[0031] 圖1為本發(fā)明RPKI文件的同步方法一實施例的流程示意圖。本實施例的執(zhí)行主 體可W為RPKI文件的同步裝置，該裝置可W設(shè)置在部署RPKI資料庫的設(shè)備內(nèi)。如圖1所 示，本實施例的方法包括：
[0032] 步驟101、接收RP端發(fā)送的文件同步請求，所述文件同步請求包括RP端目錄對應(yīng) 的第一有序哈希樹；
[0033] 步驟102、獲取RPKI資料庫中目錄對應(yīng)的第二有序哈希樹；
[0034] 步驟103、遍歷所述第一有序哈希樹W及所述第二有序哈希樹，根據(jù)所述第一有序 哈希樹和所述第二有序哈希樹中樹節(jié)點的信息，確定所述RP端需同步的文件。
[0035] 具體來說，RPKI資料庫同步過程設(shè)及到的文件種類有：CA證書（.cer)、R0A(. roa)、資料清單（.mft)、邸L證書（.Cd)和化OS憂listers證書（.gbr)等，而且文件數(shù)量 多。截止到2015年6月30日，全球RPKI體系中資料庫文件大小為290M字節(jié)，共47763個 文件，而此時RPKI在全球的部署率僅為6. 4%?？蒞想象，如果RPKI今后在全球普遍推廣 部署后，RPKI體系中資料庫將是十分龐大的。而現(xiàn)有的同步工具rsync在同步文件時需要 將文件讀入內(nèi)存進行分塊和計算校驗值，如果文件數(shù)量巨大，那么讀取數(shù)量龐大的文件無 疑會占用很多的I/O資源，對同步的整體性能會產(chǎn)生不利的影響。
[0036] 而RPKI體系中的文件的尺寸通常比較小。圖2為本發(fā)明實施例的RPKI文件尺寸 分布圖。經(jīng)統(tǒng)計，在上述資料庫的47763個文件中文件尺寸分布圖如圖2所示。從分布比 例可W看出，文件大小在2K字節(jié)W內(nèi)的文件數(shù)量占總文件數(shù)的93 %。運些文件按照發(fā)布點 的不同，組織在不同的目錄中。另外，RPKI體系中的文件是數(shù)字簽名對象，簽名對象的內(nèi)容 包含文件的語義內(nèi)容和該語義內(nèi)容的哈希值（即上述校驗值）。由于文件語義內(nèi)容的哈希 值和文件語義內(nèi)容之間的強關(guān)聯(lián)性，因此當(dāng)文件語義內(nèi)容發(fā)生變化時，即使是細微的改變， 哈希值也將徹底改變，結(jié)果整個簽名對象的內(nèi)容也會徹底的改變，即使將文件分塊，也不存 在簽名對象局部更新的情況。
[0037] 因此，在本發(fā)明實施例中，文件無需分塊。運樣一方面減少了讀取文件劃分文件塊 時的性能消耗，另一方面在同步時也不會傳輸過多的協(xié)議數(shù)據(jù)。
[0038] 本實施例的具體實現(xiàn)過程如下：
[0039] RP端會實時性的或周期性的發(fā)起文件同步請求，同步RPKI資料庫中的文件；所述 文件同步請求包括RP端目錄對應(yīng)的第一有序哈希樹。
[0040] 當(dāng)接收到RP端發(fā)送的文件同步請求后，需要獲取RPKI資料庫中目錄對應(yīng)的第二 有序哈希樹。
[0041] 圖3為本發(fā)明方法實施例中目錄轉(zhuǎn)化有序哈希樹的示意圖。第一有序哈希樹和第 二有序哈希樹是將文件目錄轉(zhuǎn)化成有序哈希樹進行表示，為了便于比較。如圖3所示，左邊 為文件目錄，右邊為轉(zhuǎn)化后的有序哈希樹。樹節(jié)點RPKI為該有序哈希樹的根節(jié)點，樹節(jié)點 ISPl為根節(jié)點的頭子節(jié)點，樹節(jié)點ISP2為ISPl的后繼兄弟節(jié)點。樹節(jié)點ISPl的相對路徑 為RPKI/1SP1，樹節(jié)點ISP2的相對路徑為RPKI/1SP2。
[0042] 遍歷所述第一有序哈希樹W及所述第二有序哈希樹，根據(jù)所述第一有序哈希樹和 所述第二有序哈希樹中樹節(jié)點的信息，確定所述RP端需同步的文件。通過一一比對第一有 序哈希樹和第二有序哈希樹的樹節(jié)點，比較兩顆哈希樹的同一相對路徑下的樹節(jié)點是否相 同，可W通過比較樹節(jié)點的哈希值是否相同，從而判斷樹節(jié)點是否相同。
[0043] 圖4A為本發(fā)明方法實施例的第一有序哈希樹示意圖。圖4B為本發(fā)明方法實施例 的第二有序哈希樹示意圖。
[0044] 具體來說，如圖4A、4B所示，假設(shè)圖4A所示的有序哈希樹為RP端目錄對應(yīng)的第一 有序哈希樹，圖4B所示的有序哈希樹為資料庫目錄對應(yīng)的第二有序哈希樹，遍歷第一有序 哈希樹W及第二有序哈希樹，即首先比較樹節(jié)點A和樹節(jié)點A'，若樹節(jié)點A和樹節(jié)點A'的 哈希值不同，然后比較樹節(jié)點B和樹節(jié)點B'，若樹節(jié)點B和樹節(jié)點B'的哈希值相同，則繼續(xù) 比較樹節(jié)點C和樹節(jié)點C'，進一步去確定是哪兩個