資源公鑰基礎設施RPKI：現狀與問題

蘇瑩瑩，李丹,2，葉洪琳

（1. 清華大學，北京 100084；2. 清華大學深圳國際研究生院，廣東 深圳 518055）

1 引言

BGP是支持網絡之間互聯互通的標準協議，作為域間路由至關重要的協議，其對互聯網的安全性有著重大影響。但BGP在設計之初并沒有充分考慮安全性，AS（autonomous system，自治系統）缺乏對路由通告（BGP宣告）內容真實性的驗證，使得BGP很容易受網絡管理員錯誤參數配置或惡意攻擊行為的影響。

目前BGP最嚴重的一個安全威脅是BGP前綴劫持[1]。由于誤配置或惡意行為，AS對外宣告了不屬于自己的IP地址前綴，從而將發往該IP地址前綴的一部分（或全部）流量吸引過來（前綴/子前綴劫持）或充當中繼節點竊聽流量（中間人劫持）[2]。

BGP前綴劫持事件每天都在發生，一些大規模的劫持事件更是對網絡造成了不可逆轉的影響[3-4]。針對BGP前綴劫持問題，較為早期的解決方案是1997年BBN公司提出的S-BGP[5]，S-BGP通過在BGP宣告中附加AS的簽名來驗證IP地址前綴和自治系統號（autonomous system number，ASN）的綁定關系。但由于S-BGP存在密鑰管理復雜、計算開銷大等缺陷，并沒有得以部署。RPKI沿用了S-BGP通過簽名將IP地址前綴和ASN綁定的思想，但為了不修改BGP以及盡可能降低邊界路由器的開銷，RPKI并沒有在BGP宣告中附加簽名，而是將簽名以一種帶外的方式獨立存儲于分布式RPKI資料庫中，由專門的服務器獲取并驗證簽名證書，路由器獲取驗證后的結果指導路由選擇。與BGP兼容、帶外的設計理念是RPKI能夠得以部署的重要原因。

IETF自2012年起對RPKI進行標準化[6]，并在之后對與RPKI相關的概念及標準不斷進行更新和完善。RPKI通過提供IP地址前綴和ASN之間的可信映射來防止源前綴劫持和源子前綴劫持。其將BGP宣告的“默認接受”模式更改為“默認拒絕”模式，只有被RPKI判定為真實有效的路由宣告才會被AS接受。在IANA以及五大RIR的不斷推動下，目前RPKI已初具部署規模。近兩年，RPKI部署率增長相對較快，多個大型AS也公開宣布正在部署RPKI并將丟棄被RPKI判斷為無效的BGP宣告[7]。

2 RPKI技術現狀

2.1 RPKI起源及發展

BGP前綴劫持可以分為前綴劫持和子前綴劫持。前綴劫持如圖1(a)所示，源AS1向外發出了帶有自身前綴1.1.0.0/16的BGP宣告，由于AS5的誤配置或攻擊行為，它也向外發出了帶有前綴1.1.0.0/16的BGP宣告。AS一般會優先選取到達某個前綴AS_path最短的BGP宣告，因此AS4發往1.1.0.0/16的流量大概率會發往AS5，AS3會綜合其他策略選擇到達前綴1.1.0.0/16的路徑。子前綴劫持如圖1(b)所示，AS5向外發出了相比于1.1.0.0/16更加具體的BGP宣告（帶有前綴1.1.0.0/24），根據BGP的最長前綴匹配原則，AS2、AS3以及AS4到達1.1.0.0/24的流量都將會發往AS5。

圖1 BGP前綴劫持及子前綴劫持示意圖

為了解決前綴劫持問題，BBN公司（即BBN Technology）早在1997年就提出安全邊界網關協議（secure BGP，S-BGP）[5]方案。發展至今，前綴劫持問題解決思路主要可分為兩大類：異常檢測與預防。

異常檢測通過對異常BGP宣告的識別，讓網絡管理員快速修復異常情況，從而盡可能降低前綴劫持造成的危害[8-18]，檢測的準確性和實時性是這類方案的關鍵。前綴劫持預防通過丟棄驗證失敗的BGP宣告來達到預防前綴劫持的目的，是一類從根本上解決BGP前綴劫持的方案。具有代表性的方案有S-BGP[5]以及在S-BGP基礎上發展來的SPV（secure path vector，安全路徑向量）[19]、APA（aggregated path authentication，聚合路徑驗證）[20]、soBGP（secure origin BGP，安全源邊界網關協議）[21]及psBGP（pretty secure BGP，非常安全的邊界網關協議）[22]等。S-BGP通過兩個PKI（public key infrastructure，公鑰基礎設施）體系對BGP宣告的源偽造及路徑偽造進行檢測[5]。對于一個AS內部的邊界路由器來說，每收到一個BGP宣告，都要確認這個BGP宣告中AS_path上的每個AS都被授權向外廣播了這條BGP宣告。S-BGP存在計算、存儲開銷較大、密鑰管理復雜等缺點，使邊界路由器負擔過重，難以部署。

針對S-BGP密鑰管理復雜的缺點，SPV[19]和APA[20]通過對密碼技術進行改進，降低了S-BGP的開銷；針對S-BGP的計算、存儲開銷大的缺點，2003年思科公司提出了soBGP[21]，soBGP采用信任網絡（Web of trust）的分布式信任模型，犧牲了一定的安全性來提高S-BGP的性能；psBGP[22]結合了S-BGP和soBGP的特點，利用信任網絡實現AS之間的互相背書，進一步降低了驗證開銷，但同樣沒有在實際中得到部署；其他的一些改進方案[23-25]根據BGP宣告的特點有針對性地降低S-BGP的開銷。

由于上述方案對BGP有所修改，難以推動部署，之后又提出了不修改BGP的安全外包機制。主要有IRV（interdomain routing validation，域間路由驗證）[26]和ROVER（route origin verification，路由源認證）[27]。IRV通過向源AS詢問來實現路由源驗證，與源AS的通信開銷以及網絡不可達是IRV面臨的主要挑戰；ROVER利用DNS（domain name system，域名系統）反向查詢機制對源AS進行驗證，但ROVER依賴DNSSEC（DNS security，域名系統安全）的部署，而DNSSEC本身的部署情況也不理想[28]，因此ROVER的部署也受到了較大的阻礙。

2012年IETF安全域間路由（Secure Inter-Domain Routing，SIDR）工作組以S-BGP為基礎提出資源公鑰基礎設施（resource public key infrastructure，RPKI），并開始對其進行標準化[25]。RPKI是一套保障互聯網號碼資源（IP地址及自治系統號）安全使用的公鑰基礎設施。其通過對X.509公鑰證書進行拓展[29]，完成了公鑰及互聯網號碼資源與資源持有者的綁定和授權。RPKI通過由上至下逐級頒發資源證書來進行資源授權，最下層資源持有者頒發路由源認證（route origin authorization，ROA）來完成IP地址與具體AS的綁定。此外，作為一種帶外的驗證機制，RPKI證書及簽名對象被存放至RPKI資料庫，供需進行路由源驗證（route origin validation，ROV）的實體同步和驗證，而后將驗證結果下發至路由器，避免了路由器的加密和驗證開銷。

2.2 RPKI整體架構

RPKI體系由3部分組成：證書簽發體系、證書存儲系統以及證書同步驗證機制。RPKI的證書簽發體系與互聯網號碼資源由上至下的分配架構相對應（圖2左側）。作為一種帶外機制，RPKI涉及的所有證書都存放至RPKI資料庫中供依賴方（relying party，RP，即幫助AS同步并驗證證書的實體）同步（圖2中間部分），RP同步并驗證RPKI證書和簽名對象，而后將驗證結果（IP地址前綴和ASN的綁定關系）下放至AS邊界路由器指導路由過濾（圖2右側部分）。

圖2 RPKI整體架構及運行機制示意圖

RPKI利用X.509證書及其擴展[29]實現了互聯網號碼資源使用授權[25]。如圖2所示，互聯網號碼分配機構（如五大RIR）在給互聯網號碼資源持有者分配資源時，會用自己的私鑰簽發數字證書（certification authority，CA證書），證書中包括資源持有者的公鑰及相應的互聯網號碼資源，表明該資源持有者得到了使用此部分號碼資源的合法授權[30-31]。證書生成后，上層分配機構會將簽發的證書存放于自己的資料庫發布點（RPKI資料庫）供RP同步。當資源擁有者希望授權某個AS宣告自己擁有的IP地址前綴時，會先用自己的私鑰簽發一個終端實體（end-entity，EE）證書，而后用EE證書的私鑰簽發ROA[32]，完成IP地址前綴和此AS的綁定。為了減輕撤銷證書的負擔，EE證書和ROA是一一對應的，RPKI規定將EE證書作為ROA的一個字段進行存儲[25,33]，資源擁有者可通過撤銷EE證書來撤銷ROA。

擁有CA證書的實體稱為CA，每個CA都會維護一個資料庫發布點[34]供RP同步自己發布的證書和簽名對象，RPKI資料庫系統就是由所有CA的資料庫發布點共同組成的。RPKI使用CA證書的兩個擴展項來鏈接整個RPKI分布式資料庫系統：信息發布點（subject information authority，SIA）和權威發布點（authority information authority，AIA）。SIA記錄了該CA自身資料庫發布點的地址，可通過此字段查找到該CA簽發的所有證書和簽名對象；AIA記錄了該CA的父CA資料庫發布點的地址，可通過此字段查找到該CA的上層CA發布的所有證書和簽名對象。利用CA證書中的這兩個信息，理論上可以通過RPKI證書樹中的任意一個CA證書鏈接到整個RPKI證書樹。

傳統PKI在撤銷證書的時候，需要證書撤銷列表（certificate revocation list，CRL）記錄還未過期但是已被撤銷的證書[30]。RPKI在撤銷證書的時候沿用了此機制，每個CA的資料庫發布點中都會維護一個CRL用來記錄該資料庫發布點中還未過期但已被撤銷的證書的序列號及撤銷日期[31]。為了保證CRL不被篡改，CRL也需要對應的CA用自己的私鑰進行簽名。

為了方便RP檢查同步到的某個資料庫發布點中證書和簽名對象的正確性以及完整性，防止在傳輸的過程中資料庫發布點中的內容被惡意刪除或篡改，每個資料庫發布點還需要維護一個清單[35]。清單記錄了該資料庫發布點中所有合法（未過期也未被撤銷）的證書及簽名對象的名稱及哈希值。RP在同步完資料庫中的資料后，會根據清單的內容進行證書正確性和完整性驗證。同ROA一樣，清單作為RPKI的簽名對象，也需要與EE證書進行綁定，在撤銷清單的時候只需要撤銷對應的EE證書即可。

2.3 路由源驗證過程

RP通過rsync[36]協議或RRDP（RPKI repository delta protocol，RPKI資料庫更新協議）[37]從所有RPKI資料庫發布點中同步證書和簽名對象，而后沿著證書鏈由上至下驗證ROA的有效性，并提取所有有效ROA中記錄的IP地址前綴和ASN的映射關系生成路由過濾表，通過RTR協議[38]將路由過濾表下發至各個邊界路由器，路由器利用該路由過濾表來驗證收到的BGP宣告的有效性。

ROA中除了IP地址前綴和ASN的對應關系外，還有一個最長前綴長度（maxlength）字段。每個ROA中的有效條目都可以表示為三元組

路由器在收到RP下發的所有有效ROA條目集合后，就可以利用該集合對收到的BGP宣告進行路由源驗證（route origin validation，ROV）[39]，從而過濾掉驗證非法的BGP宣告。

一條BGP宣告的“源路由”定義如下：如果一條AS_path的最后一個元素是AS_sequence類型，那么源AS就是AS_path的最后一個元素；如果AS_path中的最后一個元素（或元素段）是AS_set類型，表明無法確定ASN的先后順序，也就無法確定源AS，此時不做判斷。

ROA與BGP宣告的有效性對應關系見表1[39]。

表1 ROA與BGP宣告的有效性對應關系

路由器利用RP下放的有效ROA條目進行ROV的具體過程如下。

步驟1選取滿足IPBGP?IPROA（BGP宣告中IP地址前綴覆蓋的IP地址是ROA中IP地址前綴覆蓋的IP地址的子集）的ROA，構成“候選ROA”的集合（即滿足表1中“與ROA中的IP地址前綴相匹配”或“比ROA中的IP地址前綴更具體”的所有ROA）。

步驟2如果“候選ROA”集合為空，那么判斷結束，返回“unknown”（未知）。

步驟3如果要判斷的BGP宣告的源AS可以確定（AS_path的最后一個元素是AS_sequence類型），且“候選ROA”集合中存在一個ROA的ASN字段與源AS相同（即滿足表1中“BGP宣告與ROA的ASN匹配”），且該BGP宣告的IP地址前綴長度不大于ROA中的maxlength值（即滿足表1中“與ROA中的IP地址前綴相匹配”），則判斷結束，返回“valid”（有效）。

步驟4否則返回“invalid”（無效）。

邊界路由器參考ROV的結果決定是否接受某條BGP宣告，IETF建議邊界路由器優先考慮被判斷為valid的BGP宣告，盡量丟棄被判斷為invalid的BGP宣告[25,39]。

2.4 本地化互聯網號碼資源管理策略

RPKI的資源授權是基于全局視角的，它使資源持有者可以對擁有的全局唯一的資源進行可驗證的聲明。但是，網絡管理員也有需求在某些本地化的場景中聲明對某些資源的持有情況，比如在本地化場景中聲明對RFC1918[40]規定的某些保留地址的使用權。或者國家出于某些原因需要指導國家內部的網絡按照國家權威機構的指示配置域間路由過濾規則。這些本地化的策略，只在本地上下文中生效，不會對超出本地范圍內的其他網絡的配置產生任何影響。

考慮到以上ISP本地化信息控制的需求，Ma等人[41]在RFC8416中提出了簡化本地互聯網資源管理（simplified local internet resource management，SLURM）。SLURM提供了一種簡單的使RP能夠對RPKI全局資料庫的驗證結果進行“重寫”的機制。如圖3所示，RP在驗證本地緩存的RPKI資料庫證書后獲取“全局策略”，之后再通過SLURM機制添加“本地策略”（“本地策略”與“全局策略”產生沖突時，服從“本地策略”），而后將“綜合策略”下放至邊界路由器，指導其進行BGP宣告過濾。

圖3 SLURM機制示意圖

SLURM采用單個JSON文件來導入本地策略。圖4是SLURM文件的格式展示：slurmVersion字段是SLURM的版本號；validationOutputFilters字段包含需要被過濾掉的與前綴相關條目（prefixFilters）及與BGPsec相關條目（bgpsecFilters），所有驗證通過的ROA條目只要被此字段包含，就必須從RP輸出給路由器的合法條目中剔除；locallyAdded Assertions字段表示需要添加的與前綴相關條目（prefixAssertions）及與BGPsec（bgpsecAssertions）相關的條目，所有驗證通過的ROA條目只要不包含此字段的內容，RP輸出給路由器的合法條目中必須再額外將此條目的內容添加進來。SLURM文件的操作是“原子性”的，RP要么采用SLURM文件列出的全部內容，要么完全不采用此SLURM文件的策略。當存在多個SLURM文件時，RP需要檢查這些文件是否存在沖突，如果存在沖突，RP需將沖突內容報告給SLURM文件的創建者，沖突解決后才能采用這些SLURM文件。

圖4 SLURM文件格式

SLURM給RP提供了自由配置自己本地BGP宣告過濾策略的機制，且該策略不會影響到除本地之外的其他網絡，但是RP也需仔細考慮使用SLURM所帶來的安全隱患，尤其需要關注SLURM文件是否存在配置錯誤或此文件是否由第三方所提供。

2.5 RPKI部署情況

自2012年RPKI被標準化以來，IANA和五大RIR就在不斷推動RPKI的部署，利用RIPE NCC維護的RPKI歷史資料庫[42]，對RPKI的部署情況進行了分析。

2.5.1 部署RPKI的AS數量及比例變化

圖5 五大RIR部署RPKI的AS增長趨勢

五大RIR部署RPKI的AS增長趨勢如圖5所示，圖5展示了自2015年至2020年，每年的11月1日，部署了RPKI的AS數量及比例的變化。圖5中的柱狀圖表示在五大RIR中，部署了RPKI的AS數量上的變化；折線圖表示部署了RPKI的AS占在本RIR注冊的所有AS在百分比上的變化。從圖5可以看出，從2015年開始，五大RIR的AS部署RPKI的數量和比例都呈上升趨勢。2015—2017年增長趨勢較為平緩，在2018年及以后，增長逐漸加快，其中RIPE NCC的變化趨勢最為明顯，且部署的數量和比例在5個RIR中都是最高的，到了2020年11月1日，部署RPKI的AS比例更是超過了30%。

2.5.2 被ROA覆蓋的BGP前綴比例變化

ROA覆蓋的BGP宣告中的IP地址前綴的比例也是衡量RPKI部署情況的一個重要指標。使用了Routeviews[43]觀測點所維護的RIB表數據，截至2020年11月1日，Routeviews共有26個觀測點，但是由于在2015—2020年時間段內，觀測點的數量有所變化，為了更加真實地反映被ROA覆蓋的BGP宣告中的IP地址前綴的變化趨勢，本文選取了Routeviews中一個較大的觀測點所維護的RIB表進行分析。圖6是從2015—2020年，被ROA覆蓋的BGP宣告（IPv4前綴及IPv6前綴）的變化趨勢。從圖6可以看出，2015—2017年，BGP宣告中的前綴被ROA覆蓋的比例不到0.1，但2018年以后，BGP宣告中的前綴被ROA覆蓋的比例逐漸上升。這與圖5中2018年后部署RPKI的AS數量增長變快相符。但從圖6也可以發現，截至2020年11月1日，在所有BGP宣告的IP地址前綴中，被ROA覆蓋的比例仍不到0.25，因此距離RPKI的全面部署仍有較大距離。

圖6 BGP宣告的前綴被ROA覆蓋的比例

3 RPKI存在的問題及研究進展

3.1 RPKI可擴展性問題

作為一種帶外機制，RPKI不利用BGP傳輸證書內容，而是建立“資料庫”來存儲證書，供RP下載使用。目前網絡中大約有65 000個活躍的AS，如果所有的AS都使用RPKI進行路由源驗證，且假設一個RP服務一個AS，那么每一個RPKI資料庫發布點的服務器都需要滿足65 000個RP同時同步資料的需求。

RPKI設計之初采用的同步協議是rsync[36]。rsync使用了增量同步機制，有效地避免了大量數據的傳輸，但rsync要求資料庫發布點服務器為每一個有同步資料需求的RP計算其距上次同步需要增量同步的內容，如果65 000個RP同時同步，RPKI資料庫服務器需要消耗大量的內存和CPU資源，這對服務器提出了較高的要求。對于一些ISP來說，部署一個7×24 h在線，并且能同時支持65 000個RP頻繁地進行同步的RPKI資料庫發布點，其開銷可能是無法承受的[44]。

為了解決這個問題，IETF提出了一個新的同步協議——RRDP[37]，其實現了增量同步，且極大地降低了資料庫發布點服務器的開銷。RRDP讓資料庫發布點服務器維護一個更新文件，資料庫發布點中的所有的更新操作（如更新了清單和CRL、發布了新的證書或ROA等）及更新的時間戳都被記錄在此文件中，RP只需要同步更新文件，根據更新文件中的更新內容及時間戳去增量同步指定的對象即可。RRDP同時結合了Web緩存機制，能夠極大地緩解rsync帶來的可擴展性問題。但是目前RPKI并沒有實現完全部署，RRDP是否能夠完全滿足同步的性能要求還有待考證。

RPKI部署的早期，為了簡化CA的資料庫管理負擔，推動部署，五大RIR為下屬的NIR/ISP提供了“托管模式”服務。NIR/ISP只需要在RIR提供的網頁上進行注冊，就可以將自己的資料庫發布點完全托管給RIR。NIR/ISP不再維護自己的資料庫發布點，降低了自己的管理開銷，也更有動力去部署RPKI。但“托管模式”要求NIR/ISP將自己的密鑰和資料庫管理權都上交給RIR，這導致RIR可以隨意修改NIR/ISP資料庫發布點中的內容，為RIR的主動惡意行為或被迫惡意行為提供了便利。目前，大多數部署了RPKI的機構都選擇了“托管模式”，只有極少數的ISP選擇親自管理自身的資料庫發布點。

3.2 RPKI資料庫對象相關惡意操作

RP通過獲取并驗證RPKI資料庫所有的資源證書及簽名對象（統稱為資料庫對象）來生成路由源驗證條目，因此任何針對RPKI資料庫對象的誤操作或惡意操作都會影響驗證結果，從而影響BGP宣告過濾規則的準確性。關于對象的惡意操作主要分為以下幾類[45]。

· 刪除：任何有權限操控資料庫發布點的實體惡意刪除資料庫發布點中的對象（CA證書、ROA、CRL、清單），使RP無法同步這部分證書。

· 抑制：任何有權限操控資料庫發布點的實體惡意抑制CA對其資料庫所進行的更新，使RP無法同步到CA進行的更新。

· 損壞：任何有權限操控資料庫發布點的實體損壞資料庫發布點中的對象（CA證書、ROA、CRL、清單），使證書內容無法解析驗證。

· 篡改：掌握資料庫發布點對應的CA證書私鑰的實體任意篡改資料庫發布點中的對象（CA證書、ROA、CRL、清單）。

· 撤銷：掌握資料庫發布點對應的CA證書私鑰的實體惡意將CA證書、ROA和清單列入CRL列表，使其驗證失敗。

· 注入：掌握資料庫發布點對應的CA證書私鑰的實體任意使用其私鑰發布沒有經過此CA同意的證書或簽名對象。

上述6種惡意操作的前兩種，只要有資料庫發布點的操作權限即可進行，后3種需要掌握資料庫發布點對應的CA證書的私鑰。需要注意的是，上層CA可以通過刪除、篡改、撤銷自己給下層CA頒發的CA證書來影響下層CA資料庫中對象的有效性。目前，RPKI的資料庫主要采用的是托管模式（hosted model），CA將自己的資料庫和私鑰交給五大RIR統一管理，僅少數的ISP采用自主管理資料庫及私鑰的模式（delegated model）。本文將自身資料庫發布點中的證書或自身的CA證書受到破壞的CA稱為受害CA，對受害CA產生影響的兩個主要來源有受害CA的上層CA以及外界攻擊者。表2列出了在兩種資料庫發布點管理模式下，兩個威脅源分別可以對受害CA的CA證書及其資料庫發布點的對象進行的惡意操作。

表2 在不同管理模式下可進行的惡意操作

由于資料庫發布點中的對象有多種類型（CA證書、ROA、CRL、清單），對每種對象采取上述5種不同的操作產生的不良影響也是不一樣的。這里僅介紹幾種危害較為嚴重的惡意操作，更多關于證書的惡意操作可參考RFC 8211[45]。

上層CA惡意撤銷、刪除下層CA的CA證書：由于下層CA的CA證書存放在上層CA的資料庫發布點中，上層CA可直接刪除下層受害CA的CA證書（無須修改CRL列表）或撤銷下層受害CA的CA證書（需將下層CA的CA證書放至CRL列表）。兩者產生的效果是相似的，RP無法再同步到下層受害CA的CA證書，無法定位受害CA的資料庫發布點，進而導致受害CA資料庫中的所有對象都不能被同步到。不同的是，刪除CA證書的情況下，RP還會繼續使用之前緩存的受害CA的CA證書及其資料庫發布點中的對象，直到CA證書和資料庫中的對象過期；而撤銷CA證書會導致所有受害CA簽發的對象都驗證失敗。

上層CA惡意篡改下層CA的CA證書：與撤銷、刪除下層受害CA的CA證書不同，篡改證書一般是更改原CA證書的資源授權情況，比如減少對下層CA授權的IP地址資源或ASN資源（一般不會增加對下層CA的授權資源），導致下層CA簽發的與減少的那部分資源相關的ROA驗證失敗，進而影響相關AS的BGP宣告的有效性。

目前，防止上層CA單方撤銷下層CA的CA證書的方案有兩種，第一種是改進RPKI機制，使其能夠平衡上下層CA的權利；第二種是設計全新的去中心化互聯網基礎設施方案。Heilman等[46]于2014年提出的RPKI證書透明機制屬于第一種。其核心思想是上層CA想要撤銷下層CA的CA證書，必須經過所有可能受影響的下層機構的“同意簽名”，但是在目前90%以上的CA資料庫都由RIR托管的模式下，此方案起不到限制作用。第二種方案的典型代表就是基于區塊鏈的去中心化互聯網基礎設施方案。

2016年Hari等[47]首次在文獻中提出了基于區塊鏈的去中心化互聯網基礎設置方案的基本框架，其核心思想是把IP地址的分配與IP地址和ASN的綁定關系抽象成交易發布到區塊鏈系統中，利用區塊鏈賬本的分布式和防篡改特性防止惡意操作，但是文獻并沒有提出一個完整的解決方案。隨后Alfonso等[48]提出的SBTM、Paillisse等[49]提出的IPchain、Xing等[50]提出的BGPcoin、Angieri等[51]提出的InBlock和DII[52]、Saad等[53]提出的RouteChain以及He等[54]提出的ROAchain和Chen等[55]提出的ISRchain都是基于此思想的去中心化方案。InBlock強調互聯網號碼資源在初始時不屬于任何一個機構，資源的分配依靠智能合約完成，從根本上避免了互聯網號碼資源在屬于某個實體時（比如RIR），此實體封鎖資源分配的情況；BGPcoin解決了基于區塊鏈的去中心化互聯網號碼資源方案與BGP兼容性問題，其對資源分配對應交易的流程設計完整，且基于以太坊搭建了本地仿真網絡；ROAchain指出了之前方案采用基于PoW或PoS共識機制的不合理性，并設計了一套理論上更加安全有效的共識機制，大大提高了交易速率；ISRchain將AS之間的鄰接關系數據和商業關系數據上傳至區塊鏈，使系統能同時解決域間路由的路徑篡改和路由泄露問題。基于區塊鏈的方案有諸多優勢，比如：能有效防止CA惡意撤銷證書、相比于RPKI能保證RP獲取資源分配數據的一致性、簡化證書管理的復雜度等。但是，由于區塊鏈技術尚未完全發展成熟，基于區塊鏈的方案也存在一定的問題，比如交易吞吐量低、智能合約的安全性問題等。但由于區塊鏈去中心化、防篡改、可追溯的特性使得采用區塊鏈技術解決互聯網號碼資源分配的去中心化問題成為未來的一大趨勢。

3.3 最長前綴長度

ROA中maxlength字段使得ROA能以單個IP地址前綴的形式授權一個AS宣告一組合法的子前綴，其優勢主要有以下兩點：（1）減少ROA中IP地址前綴條目，書寫方便，且減少了RP下放給路由器的IP地址前綴條目數量；（2）可使網絡管理員更加靈活便捷地重新配置其網絡，無須更改ROA即可靈活地宣告maxlength范圍內的任意子前綴。但同時，maxlength也給域間路由引入了新的安全風險。

定義一個ROA中授權給某一AS的所有IP地址前綴（包括maxlength內的子前綴）都在此AS的BGP宣告中出現，則稱此ROA為“minimal ROA（最小化ROA）”，否則稱其為“loose ROA（松散ROA）”[56]。比如maxlength值設置為/24，但是只有/20的子前綴出現在了此AS的BGP宣告中，則此ROA為“loose ROA”。參考文獻[56]顯示2017年RPKI資料庫中30%的ROA都屬于“loose ROA”。其主要原因是網絡管理員在設置maxlength值時一般非常寬松，超過85%的“loose ROA”的maxlength值為24（IPv4）或48（IPv6）。但是網絡管理員一般不會將maxlength包含的所有子前綴都宣告出去，這部分被ROA覆蓋但是并沒有宣告出去的IP地址前綴很容易受到偽造源子前綴劫持（forged origin subprefix hijack）。

偽造源子前綴劫持示意圖如圖7所示，AS A是IP地址前綴1.2.0.0/16的合法擁有者，其允許宣告的最長前綴長度是24，但是其僅向AS B宣告了/16位的前綴，顯然此ROA為“loose ROA”。惡意攻擊者AS 666通過偽造與AS A的鄰接關系，向AS B宣告了通過路徑666-A能到達前綴1.2.0.0/24。由于AS 666并沒有偽造IP地址前綴和源AS的對應關系，此宣告并不會被AS B判斷為非法（invalid）。通過借助AS A發布的“loose ROA”以及篡改路徑，AS 666能夠吸引到AS A沒有宣告出去的所有IP子前綴的流量。這種攻擊手段即被稱為偽造源子前綴劫持。

圖7 偽造源子前綴劫持示意圖

IETF草案[57]建議網絡管理員盡量將maxlength值設置成IP地址前綴的原始長度，或盡量把maxlength包含的子前綴都宣告出去，從而避免“loose ROA”帶來的危害。參考文獻[58]指出，棄用maxlength并不會導致ROA數量的增加（一個ROA可包含多個IP地址前綴），且在RPKI全面部署的情況下，也不會對路由器需要驗證的IP地址前綴條目數量造成太大影響。已被標準化但尚未被部署的BGP安全（BGP security，BGPsec）[59]是基于RPKI的防止路徑篡改的方案。BGPsec的大規模部署能夠解決偽造源子前綴劫持問題，但由于其開銷極大，推廣部署進行得十分緩慢，第4節將對BGPsec方案進行介紹。

3.4 資源重復分配

RPKI通過上層機構給下層機構簽發CA證書來實現資源授權，但是由于上層機構的錯誤配置或惡意操作等原因，同一個資源可能會被上層機構分配給多個下層機構，造成資源所有權沖突。

目前真實運行的RPKI架構存在多個信任錨，包括IANA和五大RIR[25]，它們都擁有一個包含所有IP地址資源的自簽名根證書，可為下層機構簽發帶有任意IP地址資源的CA證書（正常情況下，一個RIR只能再分配自己擁有的那部分IP地址）。這就會導致潛在的一個IP地址前綴（一塊IP地址）被多個RIR同時分配給下層機構，資源的重復分配造成路由沖突。但多個信任錨也存在一定的優勢，當一個RIR受限于某個國家或者其他外界因素的壓力，被迫封鎖一塊IP地址資源時，其他RIR依然可以完成這塊IP地址的再分配。

除了擁有所有IP地址資源根證書的五大RIR可以造成資源重復分配之外，由于RPKI并沒有機制從技術上保證同一塊IP地址不能被分配多次，RPKI架構中的任意資源持有者理論上都可以重復分配其資源。但除了合法的MOAS，任何IP地址資源都不應該被同時分配給兩個機構。因此，資源持有者也應通過驗證證書的過程及時發現自己持有的資源是否被上層機構重復分配。

3.5 上下層CA依賴

由于RPKI的層級化資源授權架構，下層機構簽發ROA需要上層機構提前簽發CA證書（向上依賴），上層機構簽發的ROA也可能會影響下層機構的BGP宣告（向下影響）。機構之間簽發證書的依賴和簽名對象相互影響會對路由源驗證造成一定的危害[56]。

向上依賴：RPKI體系中向上依賴示意圖如圖8(a)所示，ISP A從RIR處分得地址10.1.0.0/16，但是RIR并沒有給其簽發CA證書，因此ISP A不能通過簽發ROA對象來保護自己擁有的地址塊，同時ISP A也不能進一步給下層機構AS 1和AS 2簽發CA證書。由于下層機構對上層機構的依賴，導致下層機構部署RPKI受到限制（需等上層機構先部署），不利于RPKI部署率的增加。

圖8 RPKI體系上下層依賴示意圖

向下影響：RPKI體系中向下影響示意圖如圖8(b)所示，ISP A從RIR處分得地址10.1.0.0/16，并獲取相應的CA證書，ISP A通過簽署ROA將此地址塊與AS1綁定。隨后ISP A將子前綴10.1.8.0/21分配給AS2，但是AS2 并沒有簽發ROA保護自己擁有的地址塊。由于路由源驗證的規則（前綴覆蓋、maxlength符合、ASN不匹配），AS2的BGP宣告會受ISP A簽發ROA的影響被誤判為前綴劫持，進而導致BGP宣告被其他AS拒收。

因此建議下層機構從上層機構分得IP地址資源時，盡量要求上層機構為其簽發CA證書，避免“向上依賴”；上層機構在為擁有的大塊IP地址簽發ROA時，盡量幫助或者督促下層機構（分得了子前綴）簽發ROA保護地址塊。參考文獻[56]提出了“wildcard ROA”方案緩解“向下影響”，核心思想是在ROA中增加一個剔除某些IP地址塊的字段，使得上層機構在為擁有的IP地址塊簽署ROA時，能夠將已經分配出去的子前綴剔除掉，從而避免影響下層機構的BGP宣告。

4 RPKI功能擴展

4.1 BGPsec簽名機制

BGPsec[59]是建立在RPKI基礎上的防止域間路由路徑篡改的方案。BGPsec要求前一個AS在向下一跳AS傳播BGP宣告時，附帶上自身的簽名保證路徑的真實性。與RPKI不同的是，其并非帶外路徑驗證機制，BGPsec對BGP進行了修改，在BGP報文中增加了BGPsec_path字段來攜帶逐跳的路徑簽名信息。BGPsec逐跳加密示意圖如圖9所示，ASa向ASb發起原始路由宣告，ASa在BGP宣告的BGPsec_path字段加入前綴和路徑信息（ap1），并用自己的密鑰對ap1進行簽名；ASb收到來自ASa的宣告后，提取BGPsec_path中的簽名(sign1)、自身的ASN及下一跳的ASN組合成ap2，并對其簽名生成sign2，而后將

圖9 BGPsec逐跳加密示意圖

BGPsec通過逐跳簽名的機制有效地防止了路徑篡改，但是其要求一條路徑上的所有AS都具備簽名和驗證的功能，在網絡中的AS部分部署BGPsec的情況下，效果有限（一條路徑上的一跳不可驗證，則這條路徑就無法驗證）。同時，BGPsec面臨著協議降級攻擊，有些惡意AS故意采用舊版本的BGP（不支持BGPsec），使得其惡意行為并不能被檢測[60]。BGPsec由于需要邊界路由器對每一個BGP宣告都驗證、簽名，無疑給路由器帶來了不小的開銷。

4.2 ASPA供應商授權機制

正在IETF標準化的草案AS供應商授權（autonomous system provider authorization，ASPA）[61]旨在解決如何使RPKI支持路由泄露檢測的問題。草案建議在RPKI資料庫中新增一種簽名對象ASPA表示AS之間的客戶到提供商（customer to provider，C2P）關系（BGP宣告層面的C2P關系，非具體的商業關系）。ASPA是由扮演客戶角色的AS進行簽名的簽名對象，對于選定的一組IP地址簇（address family identifier，AFI），該對象將一組供應商ASN與此客戶ASN綁定。ASPA簽名對象可由三元組

RP可以利用同步到的ASPA簽名對象驗證一條AS-path是否存在路由泄露。一條AS-path是否存在路由泄露可以通過驗證這條AS-path上所有相鄰的AS是否存在路由泄露完成。輸入為

ASPA繼承了RPKI技術的思想，不改動BGP，避免給交換機增加額外的開銷，是一種帶外的驗證機制。其支持增量部署，不存在BGPsec的“降級攻擊”問題。但其不能驗證更復雜的傳輸關系，比如AS之間的互相傳輸關系（mutual transit）。同時，AS之間的傳輸關系一般由AS之間的商業關系確定，存在間接暴露AS之間的商業關系的風險，而商業關系一般被AS視為機密，影響AS部署的積極性。

5 結束語

作為保障域間路由安全的重要互聯網基礎設施，RPKI技術及相關問題越來越受工業界和學術界重視。自2019年，RPKI的部署率得到了極大的改善。但是，RPKI同樣也存在著自身的缺陷，比如可擴展性問題、maxlength帶來的安全風險、潛在的資源重復分配以及上下層CA權利不均衡等問題。已有工作提出了諸多解決或緩解方案，但是目前這些方案自身也存在不足，有效性也有待驗證，距離被IETF采納尚有距離。且RPKI只能預防最簡單的前綴劫持或子前綴劫持，并不能預防帶有路徑篡改和路由泄露的更“高級”的劫持或惡意攻擊。因此，改進RPKI以及對RPKI進行功能擴展是目前研究的焦點。下面對RPKI未來的研究重點和發展趨勢進行探討。

（1）去中心化RPKI

如何平衡RPKI架構中上層CA與下層CA的權利、如何避免資料庫中的對象被惡意破壞是研究人員關注的焦點。由于區塊鏈的去中心化、防篡改、可追溯的特性，使其有望解決RPKI存在的中心化、可篡改的問題。目前學術界也提出了多種基于區塊鏈的去中心化互聯網基礎設施方案（參考第3.2節），但區塊鏈本身的技術限制以及目前RPKI已初具部署規模的事實使得完全基于區塊鏈的方案離真正落地還有距離。將區塊鏈技術或其他防篡改賬本技術作為保障RPKI去中心化以及防篡改的帶外機制，在RPKI的基礎上設計與RPKI兼容的輕量級方案來限制CA或者RIR惡意頒發、破壞證書的機制有望解決目前完全基于區塊鏈去中心化方案面臨的困境。

（2）RPKI功能擴展

RPKI目前僅支持簡單的前綴劫持和子前綴劫持預防，并不能預防路徑篡改和路由泄露。擴展RPKI的功能，使其支持預防BGP面臨的其他安全問題也是研究關注的焦點。目前，基于RPKI的BGPsec方案面臨開銷較大、協議降級攻擊等問題；ASPA存在暴露AS之間商業關系的風險。如何降低基于RPKI的功能擴展方案的開銷、如何使其支持增量部署、如何保護AS隱私性是亟待解決的問題。目前，如SMPC（secure multi-party computation，安全多方計算）等基于隱私保護的計算模式有望使得AS在不泄露具體隱私信息的場景下，聯合完成某一計算任務（判斷一條AS-PATH是否存在路由泄露等），為AS之間協作檢測異常提供了可能性。

目前，RPKI的部署規模雖有較大的增長，但是距離全面部署仍存在距離，讓網絡管理員深入了解RPKI技術、解決RPKI存在的問題以及擴展RPKI的功能是提高RPKI部署率的關鍵。