资源公钥基础设施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部署率的关键。