李江¹, 徐明伟^1,2, 曹家浩^1,2, 孟子立², 张国强¹
1. 清华大学 计算机科学与技术系, 北京 100084;
2. 清华大学 网络科学与网络空间研究院, 北京 100084
收稿日期：2023-01-05
作者简介：李江(1997-), 男, 博士研究生
通讯作者：徐明伟, 教授, E-mail: xmw@cernet.edu.cn;
曹家浩, 博士后, E-mail: caojh2021@tsinghua.edu.cn

摘要：作为互联网唯一的域间路由协议, 边界网关协议(border gateway protocol, BGP)当前面临着互联网号码资源误用的威胁。现有安全方案——资源公钥基础设施(resource public key infrastructure, RPKI)通过中心化的基础设施维护互联网号码资源信息, 然而该方案面临着中心化导致的单点失效风险、收敛时间长和开销高的问题。该文提出了基于区块链技术的去中心化互联网号码资源管理系统(decentralized internet number resource management system, DINRMS)。为提高系统的可扩展性, 在结构上对全球自治系统(autonomous system, AS)分组分层, 并针对此结构设计了相应的工作流程。此外, 基于上述分组分层结构提出了一种基于互联网号码资源所有权信息和映射信息产生情况的启发式数据推送机制, 缩短AS获得这些信息的收敛时间, 同时减少交互开销。实验表明, DINRMS为域间路由提供了安全可信的互联网号码资源信息; 相比RPKI, DINRMS的中心化程度降低了60%以上, 收敛时间缩短了50%以上, 交互开销减少了50%以上。
关键词：边界网关协议互联网号码资源域间路由安全
Decentralized internet number resource management system based on blockchain technology
LI Jiang¹, XU Mingwei^1,2, CAO Jiahao^1,2, MENG Zili², ZHANG Guoqiang¹
1. Department of Computer Science and Technology, Tsinghua University, Beijing 100084, China;
2. Institute for Network Sciences and Cyberspace, Tsinghua University, Beijing 100084, China

Abstract: [Objective] Internet is an important infrastructure that has been evolving for decades. Border gateway protocol (BGP) is the de facto interdomain routing protocol on the internet and connects autonomous systems (ASes) around the world. The BGP uses internet number resources (INR), including internet protocol (IP) prefixes and autonomous system numbers for addressing and routing. However, BGP has been vulnerable to the INR misusage threat recently, which causes a common type of anomaly called prefix hijacking. In prefix hijacking, a malicious AS originates the victim AS's prefixes to blackhole or intercept the victim's data traffic. The existing security solution, called resource public key infrastructure (RPKI), provides INR ownership and prefix-to-AS mapping information through a centralized infrastructure. ASes can extract and use the information from RPKI to prevent prefix hijacking. However, this solution has three typical drawbacks. First, the centralized architecture of RPKI causes single-point failures. Second, to obtain consistent INR information from RPKI, ASes need a long convergence time owing to the disorderly distribution of information. Third, ASes incur high interaction cost for extracting real-time INR information frequently. [Methods] To solve the above mentioned shortcomings, this study proposes a decentralized internet number resource management system (DINRMS) based on blockchain technology. The proposed system adopts a hierarchical architecture consisting of an autonomy layer and an arbitration layer. DINRMS partitions all ASes on the internet into groups that form the autonomy layer. The arbitration layer comprises the Internet Assigned Numbers Authority, five Regional Internet Registries and representatives elected by each group in the autonomy layer. Each entity in DINRMS has nearly the same impact on the system and the single-point failure of an entity does not lead to a serious global breakdown. The architecture of the proposed system overcomes the poor scalability of blockchain technology, which cannot be applied to efficient global INR information management on the internet. A blockchain is maintained within each group to record the INR ownership and prefix-to-AS mapping information of the respective groups. Entities within a group use information from third parties, such as the Whois Lookup tool, to check the consistency of INR ownership information. For prefix-to-AS mapping information, entities within a group use routing data from public route collectors to check the consistency and then vote on the legitimacy of the information. Subsequently, the entities judge the legitimacy of the information according to the majority rule. The arbitration layer maintains the global INR ownership information in the form of group granularity and prefix-to-AS mapping information. This information is sourced from representatives elected by each group in the autonomy layer for mutual supervision and endorsement. The arbitration layer is responsible for arbitrating usage conflicts related to INR. The DINRMS proposes a heuristic INR information push mechanism based on the architecture and dynamics of INR information. The mechanism decides to push INR information to ASes if a long time has passed since the last information push or if many information items have not been pushed. [Results] Experiments results show that DINRMS provides secure and trusted INR information for interdomain routing. In addition, the degree of centralization of DINRMS is 60% less than that of RPKI in terms of the Gini coefficient. Moreover, DINRMS reduces the convergence time and interaction overhead by more than 50%. [Conclusions] DINRMS manages INRs based on blockchain technology using a decentralized approach. The hierarchical and grouping architecture of DINRMS improves system scalability. The efficient push mechanism based on the dynamics of INR information shortens the convergence time and reduces the interaction overhead for ASes to obtain consistent INR ownership and mapping information.
Key words: border gateway protocolinternet number resourceinterdomain routing security
边界网关协议(border gateway protocol，BGP)^[1]作为互联网目前唯一使用的域间路由协议，连接了全世界的网络。然而BGP依旧面临着严重的安全威胁——互联网号码资源(internet number resource，INR)误用。例如，2008年的巴基斯坦电信错误使用了YouTube的前缀造成YouTube全球业务宕机超过2 h^[2]，2022年恶意攻击者盗用了韩国加密货币公司KlaySwap的前缀造成该公司加密货币损失^[3]。为防止这类安全威胁，自治系统(autonomous system，AS)管理员需要获知合法的INR所有权信息进而取得前缀到起源AS的映射信息，以此来检查INR误用。因此，INR所有权信息以及前缀到起源AS的映射信息管理对于域间路由的安全性十分重要。
近些年，一些研究者不断提出各种增强域间路由安全的方案，包括S-BGP^[4]、PGBGP^[5]和Listen-Whisper^[6]等，其中基于S-BGP的资源公钥基础设施(resource public key infrastructure，RPKI)^[7]是目前最有前景的方案并且得到了一定的部署。RPKI旨在提供合法权威的INR所有权信息和前缀到起源AS的映射信息，为域间路由验证提供基准。RPKI通过一个分层的PKI体系来管理INR所有权信息和前缀到起源AS的映射信息，它使用证书记录INR所有权信息以及使用路由起源授权(route origin authorization，ROA)来记录前缀到起源AS的映射信息。AS从RPKI获取到这些基准信息，验证收到的BGP更新消息中前缀到起源AS的映射是否与基准信息一致，进而实现过滤包含错误的前缀到起源AS映射信息的BGP更新消息。
然而，RPKI存在以下问题：1) 中心化导致的单点作恶和单点失效问题。RPKI遵循自顶向下的原则来管理INR所有权信息和映射信息，上层实体可单点作恶，对下层实体的INR所有权进行单方面撤销。此外，RPKI的中心化引入了单点失效问题，一个高层实体的故障会导致大范围域间路由无法正常运转。2) AS收敛时间长。RPKI使用资料库发布点来存储和发布INR所有权信息和映射信息，AS自行决定数据拉取时间和周期，导致全球AS获取一致的INR所有权信息和映射信息的收敛时间较长，而长收敛时间可能会导致路由不一致问题，进而影响全球域间路由。3) 交互开销高。RPKI的INR所有权信息和映射信息分发机制对于信息供应方即资料库发布点和信息使用方即AS都带来了高负载。资料库发布点必须能够承载来自全世界的查询请求，而AS为了能及时获得INR所有权信息和映射信息，可能会盲目加快查询频率，这在加重自身负载的同时也进一步加重了资料库发布点的负载。随着AS号码和前缀数量的增多^[8-9]，这一开销将会进一步增加。
为克服以上不足，本文提出了基于区块链技术的去中心化互联网号码资源管理系统(decentralized internet number resource management system，DINRMS)。为提高系统的可扩展性，DINRMS在结构上对全球AS分组分层，并针对此结构设计了相应的工作流程。此外，基于上述分组分层结构DINRMS采用了一种基于INR所有权信息和映射信息产生情况的启发式数据推送机制。为了证明DINRMS的有效性，本文实现了原型系统并进行了实验评估。实验结果表明，DINRMS显著减少了中心化导致的单点作恶和单点失效风险。相比于RPKI，DINRMS极大缩短了AS获得INR所有权信息和映射信息的收敛时间，同时减少了交互开销。
1 背景介绍1.1 BGPBGP连接了全世界各地的AS，进而构成了互联网。AS通过BGP更新消息学习到去往各个目的地网络的路由信息，其中，AS从BGP更新消息中获知目的地网络前缀和目的地网络的AS编号，即起源AS。然而，BGP本身对其更新消息中的前缀到起源AS这一映射信息缺少验证，这导致了恶意AS可以任意宣告其他AS的前缀，进而劫持去往其他AS的流量，这就是BGP中的前缀劫持攻击^[10]。为了检测前缀劫持，AS需要获知合法的INR的所有权信息以及前缀到起源AS的映射信息。INR所有权信息和映射信息为域间路由验证提供了基准。
1.2 RPKIRPKI是目前互联网工程任务组(internet engineering task force，IETF)积极推广的前缀劫持防御方案。RPKI通过一个分层的PKI体系来管理INR所有权信息和前缀到起源AS的映射信息，使用证书记录INR所有权信息以及使用路由起源授权(route origin authorization，ROA)来记录前缀到起源AS的映射信息。RPKI的最终目的是为BGP更新消息中前缀到起源AS的映射是否合法提供合法权威的验证基准，进而防御前缀劫持。
RPKI管理架构如图 1所示。顶层的互联网号码分配局(internet assigned numbers authority，IANA)将互联网中的全部INR委托给5个区域互联网注册管理机构(regional internet registries，RIRs)进行管理。这5个区域互联网注册管理机构分别为：非洲网络信息中心(African network information centre，AFRINIC)、亚太互联网络信息中心(Asia-Pacific network information centre，APNIC)、美洲互联网号码注册管理机构(American registry for internet numbers，ARIN)、拉丁美洲和加勒比网络信息中心(Latin America and Caribbean network information centre，LACNIC)和欧洲IP网络资源协调中心(réseaux IP Européens network coordination centre，RIPE NCC)。这些RIRs又将各自的INR分配给位于其管理区域内的实体。这些实体包括国家级网络信息中心如中国互联网络信息中心(China internet network information center，CNNIC)以及大型运营商如美国电话电报公司(American telephone and telegraph，AT&T)等。这些实体又将它们获得的INR进一步分配给其下级实体。拥有INR的实体可以使用这些号码资源运行BGP来参与域间路由。

图 1 RPKI管理架构

图选项

RPKI与BGP的协作机制路由起源验证(route origin validation，ROV)如图 2所示。在RPKI中，INR所有权信息和映射信息记录在资料库发布点(publication point)中。AS可通过依赖方(relying party，RP)周期性拉取资料库发布点中的INR所有权信息和映射信息并验证生成合法的前缀到起源AS的映射信息，目前依赖方的拉取周期一般为10~60 min^[11]。AS检查收到的BGP更新消息中前缀到起源AS的映射是否与从资料库发布点中获得的合法映射信息一致。AS将该BGP更新消息中的路由分别标记为一致(valid)、不一致(invalid)和无法找到对应的合法映射信息(unknown)3种情况。根据RFC6811^[12]，AS可以拒绝invalid路由或降低其优先级。实际情况中，AS通常会在后续的路由选择中拒绝invalid路由，在valid和unknown路由中选择去往目的地网络的最佳路由。

图 2 RPKI与BGP的协作机制

图选项

然而，RPKI存在着中心化导致的单点作恶和单点失效问题^[13-14]，高层实体可以单方面撤销低层实体的INR所有权，一个高层实体的故障会导致位于其下层的大量实体无法正常工作，降低了系统的鲁棒性。
此外，RPKI基于周期性拉取的信息分发机制导致全球AS获得一致的INR所有权信息和映射信息的收敛时间较长，这使得全球AS获得的上述信息可能在某段时间内不一致，进而不同的AS会做出不同的路由决策，最终导致路由问题。图 3中，当前缀P的起源AS从AS₁变为AS₂，相应地，RPKI资料库发布点中P到起源AS的映射从(P，AS₁)变为(P，AS₂)。假设此时AS₃和AS₆由于拉取周期计时器未触发而没有及时拉取到这个变化，用正斜杠填充实线圆圈表示，在它们看来，P的起源AS是AS₁；而AS₄和AS₅此时拉取到了这个变化，用反斜杠填充实线圆圈表示，在它们看来，P的起源AS是AS₂。在BGP层面，由于AS₁和AS₂是发生前缀迁移的AS，这里不讨论它们对P的可达性，用虚线圆圈表示。若AS₃只收到了AS₂对P的路由通告，AS₄没收到AS₁对P的撤销通告，则AS₃会拒绝AS₂的路由并使用AS₁的路由，AS₄会拒绝P的起源AS是AS₁的路由，因此，AS₃去往P的流量将被错误地发送至AS₁，而AS₄，AS₅和AS₆都无法到达P。该例表明了RPKI基于周期性拉取的信息分发机制可能会导致路由问题。此外，如果AS没有及时拉取INR所有权信息和映射信息，那么在其拉取周期内发生的前缀劫持可以绕过RPKI的防御。

图 3 RPKI基于周期性拉取的信息分发机制导致路由不一致问题

图选项

最后，RPKI基于周期性拉取的信息分发机制也引入了较高的交互开销，资料库发布点需要响应来自全球的大量INR所有权信息和映射信息查询请求，而信息使用方为了获取较实时的INR所有权信息和映射信息，有可能会盲目加快查询频率，这样既增加了它们自身的查询开销，同时也进一步增加了资料库发布点的负载。
1.3 区块链随着比特币和以太坊的出现，区块链技术成为了解决某些网络安全问题的选择^[15-16]。区块链系统中的参与者形成一个点对点(peer-to-peer，P2P)式的网络，这种底层网络结构具有较好的去中心化特性和较强的鲁棒性，减少了故障或恶意参与者对整个系统的影响。此外，这种P2P式的网络也加速了参与者之间的信息传递。
区块链系统参与者使用多方共识机制如工作量证明等，去中心化地共同维护一个分布式账本，用来安全可信地记录交易数据和智能合约。该分布式账本通过使用哈希链将需要记录的数据链接起来，因此具备了防篡改不可逆的属性。区块链系统中的基础数据是参与者之间的交易数据，这些数据表明了参与者之间的交互状态。智能合约是一些执行合约条款的计算机交易协议，使参与者多方协商的交易逻辑能自动安全地执行。
1.4 相关工作除1.2节中不足之外，一些研究还发现了RPKI的其他问题并提出了一些改进方案^[17-27]。此外，目前还有很多工作对RPKI进行观测以提供研究数据^[28-37]，它们主要分为2类，一类使用ROA的快照来验证公开路由收集器的路由，另一类测量分析ROV的部署情况。域间路由安全领域一直备受关注，很多工作尝试提升BGP的安全性^{[4, 38-45]}，但是它们面临中心化基础设施带来的单点失效风险或不能全面保护BGP。一些工作也探索了将区块链技术应用到域间路由安全的可能性^[46-52]，然而它们缺少对系统可扩展性及互联网号码资源信息分发延迟和交互开销的深入思考。
2 DINRMS结构DINRMS面临如下技术挑战：1) 基于区块链技术的去中心化系统存在扩展性问题。去中心化系统的吞吐能力，即每秒能处理的交易数量较为有限，然而管理全球互联网号码资源是一个较为复杂且需要较高处理能力的任务。扩展性不好的管理系统难以适应互联网的不断发展。2) 互联网号码资源信息的分发难以同时取得较低的延迟和交互开销。管理系统频繁分发互联网号码资源信息可以取得较低的延迟，但是会导致较高的交互开销。反之，管理系统降低互联网号码资源信息分发的频率可以减少交互开销，但是会导致较高的延迟。为解决上述挑战，DINRMS分别在结构和工作流程上进行了针对性的优化设计。
DINRMS的结构如图 4所示。DINRMS是一个2层结构的INR管理系统。下层是自治层，由若干个分组组成，其中每个分组由参与域间路由的实体构成。这里的实体指的是运营商、内容服务提供商和企业等拥有INR的机构，他们往往运营着AS来参与域间路由。分组中的实体将各自的INR所有权信息和映射信息记录到本组维护的区块链即本地INRchain上，每个分组维护各自的本地INR所有权信息和映射信息，这极大减少了直接管理全球互联网号码资源的复杂性。对于要记录到分组中区块链上的一条INR所有权信息和映射信息，只需同一分组内的AS而无需全球AS进行验证，因为大多数AS都是正常合法的AS，因此对该INR所有权信息和映射信息的检查不会由于少数恶意者失效。上层是仲裁层，由IANA、5个RIRs以及自治层中各个分组选出的代表组成。该层维护分组的INR所有权信息来避免INR的全局使用冲突，同时维护全局的前缀到起源AS的映射信息。仲裁层将这些全局信息去中心化地记录在其维护的区块链即全局INRchain上以实现各个分组之间的信息传递。此外，区块链的防篡改和可溯源性能够有效减少INR的使用纠纷。

图 4 DINRMS结构

图选项

DINRMS区分了对INR的2种权力：一是所有权，二是仲裁权。在DINRMS中，自治层中的实体拥有对INR的所有权，这些实体可以将自己的前缀授权给AS使用。INR所有权意味着相关实体拥有对INR的最大权力，包括使用、注销和转让。对于已分配的INR，实体使用这些INR创造了大量的数据和价值，他们和这些INR在互联网上已经形成了某种默认的绑定关系，例如，包含地址1.1.1.1的前缀属于Cloudflare。仲裁层则拥有对INR的仲裁权，以维护INR所有权在全局域间路由中的唯一性。INR仲裁权意味着INR使用中的冲突避免和纠纷解决的权力，在INR发生使用纠纷时，仲裁层对这些纠纷进行协调和解决。
INR管理涉及到的参与者较多，当前互联网中AS的数量就超过了7万个，其背后的实体数量也大体相当，且未来互联网的规模还会继续扩张。然而区块链系统的吞吐能力较差，其中公链系统在上万参与者规模时每秒能处理的交易最多仅有几十条，联盟链系统在上百参与者规模时每秒能处理的交易最多为几千条，且区块链系统的吞吐能力会随着系统参与者数量的增加而下降。因此，直接将区块链技术用于INR管理是不可行的，DINRMS分组分层结构的设计克服了这一问题。此外，DINRMS中每个实体对系统的影响几乎是相同的，单个实体的故障不会导致严重的全局瘫痪，因此该系统可以避免由于系统的中心化结构导致的单点作恶和单点失效问题。
3 DINRMS工作流程DINRMS的工作流程遵循自底向上的INR代议制协作管理。自治层中的AS形成分组来管理各组的INR所有权信息和映射信息，每个分组选出自己组的代表参与仲裁层，各分组代表将本组的INR所有权信息和映射信息记录在仲裁层并且将其他分组的前缀到起源AS的映射信息推送到本分组。仲裁层则负责INR的使用以避免冲突，记录全局的INR所有权信息和映射信息。
3.1 自治层工作流程自治层由若干AS分组组成，本文旨在将AS分成若干个分组，且每个分组持有的地址空间较为接近，这样可以使系统具有较好的去中心化程度。本文将AS拓扑看做被分组的图，将AS持有的地址空间看做是点的权重，因此这是一个图分组问题，该问题已被证明为NP难^[53]。本文使用性能良好的图分组工具KaHIP^[54]对AS拓扑进行分组。每个分组中的实体在运行BGP之前需要在本组维护的区块链即本地INRchain上记录各自的INR所有权信息，即本组中的实体拥有哪些INR。此外，该实体在本地INRchain上记录其对自己所拥有前缀的起源AS的授权信息。一个分组内的实体共同协商本组的本地INR管理策略，例如验证INR所有权信息和映射信息的方式，记录INR所有权信息和映射信息所需的背书(endorsement)数量和选举本组仲裁层代表等。
本地INRchain上除了记录本组的INR所有权信息和映射信息，还需要记录分组代表从仲裁层获取的其他前缀到起源AS的映射信息。分组中的实体选出代表参与仲裁层，代表负责将本组的INR所有权信息和映射信息分发到仲裁层并从仲裁层获得其他分组的前缀到起源AS的映射信息。分组内的实体将本地INRchain上的全部前缀到起源AS映射信息作为合法权威的基准来验证BGP更新消息中前缀到起源AS的映射是否合法，进而防御前缀劫持。
分组中的实体在本地INRchain上记录的信息需要被验证为合法之后才能记录到本地INRchain上，以防止本组中实体的不当行为。对于分组本地的INR所有权信息，当一个实体在其所在分组中宣称其拥有某个INR，并想将这个所有权数据记录在本地INRchain上，组内的其他实体需要判定这个宣称是否合法。其他实体首先检查该宣称是否会导致全局INR使用冲突，即检查本地INRchain上对应的INR所有权信息以及由该组仲裁层代表查询到的全局INRchain上对应的INR所有权信息是否一致。若一致，则对该宣称进行后续检查；否则，该宣称为非法，不得被记录到本地INRchain上。在极端情况下，在2个不同分组中的2个实体同时宣称自己对同一INR的所有权，这种情况下，冲突不会出现在自治层2个分组的本地INRchain，而是会出现在仲裁层。此时，仲裁层的参与者负责处理该全局冲突，这个过程可能需要管理员的人工参与。在确认没有INR冲突之后，出于对已有INR分配的兼容性考虑，组内实体使用第三方如whois工具的信息作为检查的依据或遵循本组制定的检查INR所有权信息一致性的策略。
对于分组本地的前缀到起源AS的映射信息，组内实体首先检测声明前缀的起源AS的实体是否对该前缀拥有所有权，这通过查询本地INRchain记录的INR所有权信息即可实现。其次，组内实体需要检查该声明中的起源AS是否是该前缀的合法起源AS。对于已分配在使用的前缀，由于前缀与其合法起源AS的映射信息几乎全局可见^[55]，组内实体使用来自俄勒冈大学的RouteViews项目和RIPE NCC的路由信息服务(routing information service，RIS)项目的路由数据^[56]作为对前缀起源AS的检查依据，之后对该声明做投票，最终根据该组少数服从多数的背书策略对该声明做出判断。对于已分配未使用的前缀，考虑到组内实体难以对这种前缀的实际起源AS做出判断，因此将该前缀的对应起源授权注册交易中的ASes字段填充为“allocated but unused”。对于未分配的前缀，组内实体同样难以对这种前缀的实际起源AS做出判断，因此将该前缀的对应起源授权注册交易中的ASes字段填充为“unallocated”。对于从仲裁层获取的其他前缀到起源AS的映射信息，分组选出的仲裁层代表之间互相监督即可。因为这些信息是由分组仲裁层代表从仲裁层获取然后记录到本地INRchain，这些信息已经在仲裁层得到了有效的验证和背书，而且各组选出的仲裁层代表具有较高可信性。
自治层中的分组使用区块链智能合约来执行管理逻辑，该智能合约将各项管理事务抽象为各种交易。本地INRchain的交易类型如表 1所示。INR注册和注销交易负责管理本分组的INR所有权信息。起源授权注册和注销交易负责管理本分组和其他分组的前缀到起源AS的映射信息。
表 1 本地INRchain的交易类型

交易类型	格式
INR注册	|Entity|INR|
INR注销	|Entity|INR|
起源授权注册	|(Prefix, ASes)|
起源授权注销	|(Prefix, ASes)|

表选项






在上述交易类型的基础上，本地INRchain智能合约执行管理逻辑如图 5所示。

图 5 本地INRchain智能合约算法

图选项

智能合约根据交易的类型处理各项交易(行2)。对于INR注册交易，智能合约首先通过查询全局和本地INRchain避免INR冲突，然后对分组本地的INR所有权信息进行检查(行3—6)。对于INR注销交易，智能合约检查对应的注册交易是否存在以及注销交易和注册交易的发起实体是否相同(行7—10)。对于起源授权注册交易，如果前缀是来自组内的实体，首先检查该交易发起实体是否拥有对该前缀的所有权，然后检查该交易中的起源AS是否是该前缀的合法起源AS。如果前缀不是来自组内的实体，即本分组仲裁层代表从仲裁层获得的前缀到起源AS的映射信息，该组的仲裁层代表对其互相监督不作恶即可(行11—17)。对于起源授权注销交易，智能合约检查对应的注册交易是否存在以及注册交易和注销交易的发起实体是否相同(行18—21)。若交易正确通过上述各项检查，则该交易被记录到本地INRchain上。
3.2 仲裁层工作流程自治层中各个分组的INR所有权信息和映射信息都得到共识并记录在其本地INRchain后，各组的仲裁层代表将各自组的INR所有权信息以组的粒度记录在仲裁层的全局INRchain。此外，仲裁层代表还需将本组的前缀到起源AS的映射信息记录在仲裁层全局INRchain上。当INR的所有权变化发生在不同分组，该组的仲裁层代表在仲裁层声明这一变化并记录在全局INRchain上；否则，同一组内实体的INR所有权变化只需记录在本组本地INRchain，这一设计减少了INR变化带来的仲裁层开销。为确保分组的仲裁层代表不会在仲裁层中故意作恶，每个组需选派多个代表参与仲裁层，起到互相监督背书的作用。仲裁层解决INR使用纠纷的策略可借鉴现今RIR的一些策略^[57]。
全局INRchain通过表 2中的交易来执行仲裁和管理逻辑。对于INR注册和注销交易，全局INRchain记录分组的INR来避免所有权冲突，同时减少INR变化的处理开销。全局INRchain实现INR使用的全局冲突避免即可，记录实体的INR所有权信息是不必要的。起源授权注册和注销交易负责管理全部分组的前缀到起源AS的映射信息。
表 2 全局INRchain的交易类型

交易类型	格式
INR注册	|Group|INR|
INR注销	|Group|INR|
起源授权注册	|(Prefix, ASes)|
起源授权注销	|(Prefix, ASes)|

表选项






在上述交易类型的基础上，全局INRchain智能合约逻辑如图 6所示。智能合约根据交易的类型处理交易(行2)。对于来自分组代表的INR注册交易，合约首先通过全局INRchain查询避免INR冲突，然后执行代表检查，由来自同一分组的其他代表为该交易背书(行3—6)。对于INR注销交易，合约需检查对应的注册交易是否存在以及注销交易和注册交易的发起者是否来自相同分组(行7—10)。对于起源授权注册交易，合约通过同一分组代表互相检查和背书确保分组代表没有作恶，且其他仲裁层参与者检查该起源授权中的前缀是否属于该授权交易发起者所在的分组(行11—14)，这一步骤阻止了错误路由起源授权的出现。对于起源授权撤销交易，合约检查对应的注册交易是否存在以及注册和注销交易的发起者是否来自相同分组(行15—18)。若交易正确通过上述各项检查，则该交易被记录到本地INRchain上。

图 6 全局INRchain智能合约算法

图选项

3.3 仲裁层推送机制RPKI基于周期性拉取的信息分发机制导致全球AS获得一致INR所有权信息和映射信息的收敛时间较长。此外，RPKI中AS由于缺少对INR所有权信息和映射信息产生情况的了解只能盲目地周期性拉取数据，而INR所有权信息和映射信息相对稳定，这使得部分拉取不能获取到有效增量信息从而徒增交互开销。基于上述DINRMS的分组分层结构和工作流程，仲裁层的各个分组代表在仲裁层获得来自其他组的前缀到起源AS映射信息后，可将这些信息推送到他们各自的分组并记录到其所在分组的本地INRchain上。如果分组代表对仲裁层产生的每个前缀到起源AS的映射信息都进行实时推送，那么将会产生较大的信息分发开销，而如果分组代表等待一定数量的映射信息之后再合并进行一次推送，那么将会导致各分组中实体运营的AS获得一致的INR所有权信息和映射信息的收敛时间较长。为了实现将这些信息尽快传递到全部分组中实体运营的AS以及尽可能减少信息分发过程导致的交互次数，分组仲裁层代表需要一种高效机制来分发这一信息。假设当前仲裁层有K个前缀到起源AS映射构成的时间序列，如果仲裁层代表在每个映射产生时决策是否进行推送，该问题的解空间为2^K，且随着互联网规模扩大，K将持续变大，因此该问题解空间过大，不适宜求最优解。
本文设计了一个基于前缀到起源AS映射信息产生情况的启发式推送机制。本文设计推送函数f(N, T, q)，其中N表示当前仲裁层映射信息队列中还未推送的个数阈值，T表示当前距离上次推送的时间间隔阈值，q为当前映射信息时间序列。函数值为1的条件是q中还未推送的映射个数不小于N或当前时刻与上次推送的时刻间隔不小于T，此时仲裁层代表进行一次推送。否则，函数值为0，仲裁层代表不进行推送。仲裁层代表可以根据实际映射信息产生情况动态设置参数N和T的最佳经验值。
4 实验评估4.1 实验设置本文使用Hyperledger Fabric^[58]实现DINRMS的原型系统，用一个Fabric网络中的2个通道(channel)来分别模拟仲裁层和自治层中的一个分组。仲裁层由5个RIR组织和2个自治层分组代表组成，维护全局INRchain。自治层分组由5个实体组成，维护本地INRchain。本文使用了2022年7月的真实域间路由数据进行去中心化程度评估实验。其中AS数量为73 769，AS运营组织实体数量为66 043，使用中的IPv4地址数量为4 261 940 347，参与域间路由的国家及地区数量为242。本文收敛时间实验对RPKI的拉取周期配置进行保守估计，其中90%的AS使用600 s的拉取周期，剩余10%的AS使用1 000 s的拉取周期。选择N=2和T=100的参数配置，此时的平均延迟为125 s。本文使用真实RPKI系统2022年7月的2 729个INR所有权信息和映射信息发生变化事件的时间序列来进行负载开销评估实验。
4.2 去中心化程度一个系统的去中心化程度，可以由构成该系统的各个部分对该系统的影响大小来评估^[59]。RPKI和DINRMS都是由各个参与实体构成的，本文使用这些参与实体拥有的IPv4地址空间大小来量化它们对整个系统的影响，拥有地址空间越大对系统的影响越大。本文分别评估不同参与实体粒度下RPKI和DINRMS的去中心化程度，因为地址空间是自底向上聚合的，不区分实体粒度笼统地评估系统的去中心化程度会造成地址空间的重叠，进而导致不准确。本文使用Gini系数和Lorenz曲线作为评价去中心化程度的指标。为便于分析，本文假设如下：1) RPKI和DINRMS的参与实体都分为高层、中层和低层3层。RPKI的高层参与实体为5个RIRs，中层参与实体为位于RIR下面的国家级互联网注册处(national internet registry，NIR)，低层参与实体为直接参加域间路由的AS运营组织实体。DINRMS的高层参与实体为仲裁层参与者，中层参与实体为自治层中各个分组，低层参与实体也为直接参加域间路由的AS运营组织实体。2) 在RPKI中每个国家通过一个NIR来代表该国内拥有INR的全部实体。
图 7为RPKI和DINRMS在低层参与实体粒度上的去中心化程度。本文使用应用互联网数据分析中心(center for applied internet data analysis，CAIDA)的公开数据获得各个AS运营组织实体宣告的IPv4地址空间，并将全部实体按照地址空间大小升序排序，然后计算前百分之几(记为“参与实体累计占比”)数量的实体的地址空间在全部地址空间的占比，这个数值就是地址空间累计占比。图中平等线代表一个完全去中心化的地址空间分布，即每个参与实体对系统的影响是相同的。平等线下的面积记为S_a，系统Lorenz曲线下的面积记为S_b，则该系统的Gini系数为$\frac{S_a-S_b}{S_a} $，Gini系数越小，系统Lorenz曲线越接近平等线，则系统的去中心化程度越好。

图 7 低层参与实体粒度的去中心化程度

图选项

图 7中，RPKI和DINRMS在AS运营组织实体粒度的地址空间分布是相同的，都近似服从幂律分布，即小比例的AS运营组织实体持有大比例的地址空间。DINRMS不能改进AS运营组织实体粒度的系统去中心化程度，因为这是现实互联网中AS运营组织实体的地址空间分布情况。
图 8为RPKI和DINRMS在中层参与实体粒度上的去中心化程度。本文使用CAIDA的公开数据获得各个AS的地址空间，并结合AS的所属国家数据获得了RPKI在中层实体粒度的地址空间分布。本文使用AS地址空间结合AS在自治层的分组情况获得了DINRMS在中层实体粒度的地址空间分布，本文使用KaHIP工具实现图分组，将互联网中的AS分成150个分组。DINRMS的Lorenz曲线比RPKI的更接近平等线，因此在中层参与实体粒度上，DINRMS比RPKI实现了更好的去中心化。在DINRMS中，由于AS之间的连接较丰富，IPv4地址可以被几乎均匀地分配到自治层中的各个分组。然而在RPKI中，中层参与实体的地址空间分布依旧服从幂律分布，小比例的国家级互联网注册处拥有大比例的地址空间，这意味着RPKI中的少量中层参与实体可以影响大量地址空间，这些实体的故障或作恶可以导致RPKI以及域间路由的重大故障。

图 8 中层参与实体粒度的去中心化程度

图选项

图 9为RPKI和DINRMS在高层参与实体粒度上的去中心化程度。DINRMS的高层参与实体为仲裁层参与者，它们对于INR使用冲突的仲裁权代表了其在高层实体粒度上对系统的影响。因此，DINRMS仲裁层参与者对系统的影响力可以使用它们的仲裁权大小来量化分析。RPKI高层参与实体对系统的影响力依然使用地址空间来量化。本文使用IANA的数据获得了RPKI高层参与实体的地址空间并将全部实体按照地址空间大小升序排序，然后进行类似图 7的计算。

图 9 高层参与实体粒度的去中心化程度

图选项

图 9中，DINRMS的Lorenz曲线与平等线重叠，因为仲裁层参与者对INR使用冲突有同等的仲裁权。RPKI的Lorenz曲线比DINRMS的更远离平等线，因此DINRMS比RPKI在高层参与实体粒度上实现了更好的去中心化。RPKI的Lorenz曲线代表了5个RIRs的地址空间分布，由于历史原因，地址空间最大的美洲区域互联网注册机构持有的地址数量是地址空间最小的非洲区域互联网注册机构的14倍。这意味着美洲区域互联网注册机构对RPKI的影响远大于非洲区域互联网注册机构，这不是一个去中心化程度很好的系统。
图 10为RPKI和DINRMS在不同参与实体粒度的Gini系数。Gini系数计算如下：

$G=\frac{1}{2 n^2 u} \sum\limits_{j=1}^n \sum\limits_{i=1}^n\left|P_j-P_i\right| .$

(1)

图 10 不同参与实体粒度的Gini系数

图选项

其中：n代表参与实体的数量，u代表参与实体持有的平均地址空间大小，也就是实体对系统的平均影响。|P_j-P_i|表示任意2个参与实体能影响的地址空间大小的绝对差。Gini系数越接近1，表示该系统的中心化程度越大。DINRMS在中层和高层参与实体粒度上的中心化程度比RPKI降低了60%以上。
4.3 收敛时间收敛时间表示RPKI和DINRMS中全部AS获得一致INR所有权信息和映射信息所需要的平均时间。收敛时间越短，AS采取不一致路由决策的可能性越小，出现域间路由问题的概率越低。
图 11为在一次模拟INR所有权信息和映射信息分发中，从INR所有权信息和映射信息产生时刻开始计时，随着时间推移，统计获得该信息的AS数量比例变化情况。实验选取RPKI中70 000个AS模拟其获取INR所有权信息和映射信息的情况，其中假设全部AS均使用目前拉取周期的常用配置600 s。这一实验配置是对当前RPKI拉取周期的保守估计，根据已有研究，当前RPKI中依赖方配置的最长拉取周期可达1 h。在DINRMS中，位于INR所有权信息和映射信息产生的分组中的AS能几乎实时获得这一信息，之后该信息被记录到仲裁层，最后被其他分组的仲裁层代表推送到其他分组中的AS，经过计算，全部AS获知这个INR所有权信息和映射信息的平均时间为125 s，这里使用了优化收敛时间的仲裁层推送机制参数配置即N=2和T=100。本文将在4.4节中通过进一步实验评估该推送机制。而在RPKI中，AS只能通过周期性的查询来获得INR所有权信息和映射信息，AS获得INR所有权信息和映射信息的平均延迟是拉取周期的一半，因此，AS获得INR所有权信息和映射信息的平均时间为300 s。在300 s左右时，50%的AS获得该INR所有权信息和映射信息，随着时间增长，剩余50%的AS将陆续获得这个信息。相比RPKI，DINRMS的收敛时间减少了50%以上，这是由于二者获取INR所有权信息和映射信息的不同方式所导致的。随着AS数量和前缀数量的增加，请求INR所有权信息和映射信息的AS会日益增多，考虑到资料库发布点的承载能力，该拉取周期在未来有可能会超过600 s，这将会使RPKI中AS获得一致的INR所有权信息和映射信息的收敛时间更长。

图 11 收敛时间

图选项

本文还探索了DINRMS中分组数量对AS获得一致INR所有权信息和映射信息所需收敛时间的影响。DINRMS中AS获得一致INR所有权信息和映射信息所需收敛时间的一个构成是该信息经过共识被记录到区块链上的时间。INR所有权信息和映射信息被记录到区块链上需要的背书数量和该信息被记录到区块链上的时间成正比例，需要的背书越多，该数据记录到链上所需的时间越长。为便于分析，本文假设自治层每个分组的大小是相同的且每个分组选出的仲裁层代表数量也是相同的。此外，区块链系统参与者遵循少数服从多数的背书投票策略，即区块链系统中的数据要记录到链上需要取得超过50%的参与者的同意背书。
一个INR所有权信息和映射信息被记录到区块链上所需的背书数量为

$E=\frac{A}{2 K}+K P-\frac{P}{2} .$

(2)

其中：A代表自治层全部的AS数量，K代表自治层全部的分组数量，P代表每个分组选出的仲裁层代表数量。式中$\frac{A}{2 K} $表示该INR所有权信息和映射信息被记录到其分组内本地INRchain所需要取得的最少背书数量，该INR所有权信息和映射信息被记录到仲裁层全局INRchain所需要取得的最少背书数量为$\frac{K P}{2} $，此外，该INR所有权信息和映射信息从仲裁层被推送到其他分组且记录到其他分组的本地INRchain上所需的最少背书数量为$\frac{(K-1) P}{2} $。
图 12为自治层分组数量以及每个分组选出的仲裁层代表数量对INR所有权信息和映射信息记录到区块链上所需的背书数量的影响。根据当前互联网中AS的数量，设置A=70 000。随着分组数量的增加，所需的背书数量先减少后增加。P也会影响所需的背书数量，当P值较小时，所需背书数量也较小。然而，太小的P值不利于保证仲裁层全局INRchain的正确运行，每个分组应选举出一定数量的仲裁层代表在仲裁层互相监督背书，例如选择P=2和K=150的配置可以取得相对较好的一个折中。

图 12 分组及仲裁层代表数量对背书数量的影响

图选项

4.4 负载开销本文使用INR所有权信息和映射信息分发过程中的交互次数，即拉取和推送的次数来表示RPKI和DINRMS的负载开销。分发相同数量的INR所有权信息和映射信息所需的交互次数越少的系统其负载开销越小。在DINRMS中，全部的AS被分成150个分组，每个分组选出2个仲裁层代表。实验数据使用2022年7月的真实INR所有权信息和映射信息时间序列。
图 13为在仲裁层推送机制的不同参数配置下，DINRMS中一个仲裁层代表分发2022年7月的INR所有权信息和映射信息所需的推送次数。随着推送时间间隔阈值的增大和仲裁层映射信息队列中还未推送的个数阈值的增大，推送次数减少，且DINRMS中仲裁层代表最多的推送次数不超过3 000，而RPKI中一个依赖方需要拉取次数为6×24×31=4 464。

图 13 DINRMS推送次数

图选项

图 13中，当前配置中推送次数最多的配置为N=2和T=100，DINRMS中仲裁层代表产生最多的推送次数为2 204，少于RPKI中依赖方所需拉取次数的一半。这是因为INR所有权信息和映射信息是相对稳定的，基于拉取的数据分发方式缺少对INR所有权信息和映射信息产生情况的了解，部分拉取不能获取到新的增量信息从而徒增开销。
图 14为在仲裁层推送机制的不同参数配置下，DINRMS对INR所有权信息和映射信息延迟的影响，延迟定义为从INR所有权信息和映射信息产生到被推送之间的时间间隔。可以看出随着推送时间间隔阈值的增大和仲裁层映射信息队列中还未推送的个数阈值的增大，平均延迟增大。当前RPKI中依赖方的常见拉取周期配置为600 s，因此RPKI中AS获取到INR所有权信息和映射信息的平均延迟为300 s，而在DINRMS中，当N=2时，对于任意的T，平均延迟都低于300 s；对于N=3或4时，也有一半左右的T的配置可以使平均延迟低于300 s。直观来看，DINRMS推送次数和平均延迟存在反比例变化关系，仲裁层分组代表可以根据实际情况选择不同的配置，例如为了优化延迟，进而优化收敛时间，仲裁层可以选择更小的T和更小的N，如图 11中DINRMS仲裁层推送机制选择N=2和T=100的参数配置可以取得很好的延迟，此时的平均延迟为125 s，仅为RPKI中平均延迟300 s的42%。

图 14 DINRMS平均延迟

图选项

5 结论本文提出了一个基于区块链技术的去中心化的互联网号码资源管理系统DINRMS。DINRMS使用区块链存储INR所有权信息和映射信息以及使用智能合约去中心化地执行管理逻辑。为解决区块链的扩展性问题，DINRMS使用分组分层机制以使得区块链系统的吞吐能力可以满足互联网号码资源管理的需求。此外，基于DINRMS分组分层结构，本文设计了对应的工作流程以及一种高效的INR所有权信息和映射信息推送机制，缩短了AS获得一致的INR所有权信息和映射信息的收敛时间，进而减少路由不一致。此外，该机制还减少了INR所有权信息和映射信息分发所需的交互开销。实验结果表明，相比RPKI，DINRMS的中心化程度降低了60%以上，收敛时间缩短了50%以上，交互开销减少了50%以上。DINRMS为未来去中心化的互联网治理提供了启发和参考。

参考文献

[1]	REKHTER Y, LI T, HARES S. A border gateway protocol 4 (BGP-4)[R]. San Francisco: IETF, 2006.
[2]	MCCULLAGH D. How Pakistan knocked YouTube offline (and how to make sure it never happens again)[EB/OL]. (2008-02-25)[2023-01-04]. https://www.cnet.com/culture/how-pakistan-knocked-youtube-offline-and-how-to-make-sure-it-never-happens-again/.
[3]	SIDDIQUI A. KlaySwap-another BGP hijack targeting crypto wallets[EB/OL]. (2022-02-17)[2023-01-04]. https://www.manrs.org/2022/02/klayswap-another-bgp-hijack-tar-geting-crypto-wallets/.
[4]	KENT S, LYNN C, SEO K. Secure border gateway protocol (S-BGP)[J]. IEEE Journal on Selected areas in Communications, 2000, 18(4): 582-592. DOI:10.1109/49.839934
[5]	KARLIN J, FORREST S, REXFORD J. Pretty good BGP: improving BGP by cautiously adopting routes[C]//Proceedings of 2006 IEEE International Conference on Network Protocols. Santa Barbara, USA: IEEE, 2006: 290-299.
[6]	SUBRAMANIAN L, ROTH V, STOICA I, et al. Listen and whisper: Security mechanisms for BGP[C]//Proceedings of the 1st Conference on Symposium on Networked Systems Design and Implementation. San Francisco, USA: USENIX Association, 2004: 127-140.
[7]	LEPINSKI M, KENT S. An infrastructure to support secure internet routing[R]. San Francisco: IETF, 2012.
[8]	VOHRA Q, CHEN E. BGP support for four-octet as number space[R]. San Francisco: IETF, 2007.
[9]	DEERING S, HINDEN R. Internet protocol, version 6 (IPv6) specification[R]. San Francisco: IETF, 1998.
[10]	ROBACHEVSKY A. 14, 000 incidents: A 2017 routing security year in review[EB/OL]. (2018-01-09)[2022-07-27]. https://www.internetsociety.org/blog/2018/01/14000-incidents-2017-routing-security-year-review/.
[11]	KRISTOFF J, BUSH R, KANICH C, et al. On measuring RPKI relying parties[C]//Proceedings of ACM Internet Measurement Conference. Pittsburgh, USA: ACM, 2020: 484-491.
[12]	MOHAPATRA P, SCUDDER J, WARD D, et al. BGP prefix origin validation[J]. San Francisco: IETF, 2013.
[13]	COOPER D, HEILMAN E, BROGLE K, et al. On the risk of misbehaving RPKI authorities[C]//Proceedings of the Twelfth ACM Workshop on Hot Topics in Networks. College Park, USA: ACM, 2013: 16.
[14]	SHRISHAK K, SHULMAN H. Limiting the power of RPKI authorities[C]//Proceedings of Applied Networking Research Workshop. ACM, 2020: 12-18.
[15]	KARAARSLAN E, ADIGUZEL E. Blockchain based DNS and PKI solutions[J]. IEEE Communications Standards Magazine, 2018, 2(3): 52-57. DOI:10.1109/MCOMSTD.2018.1800023
[16]	MATSUMOTO S, REISCHUK R M. IKP: turning a PKI around with decentralized automated incentives[C]//Proceedings of 2017 IEEE Symposium on Security and Privacy. San Jose, USA: IEEE, 2017: 410-426.
[17]	Town M. Explore the certificate transparency ecosystem[EB/OL]. [2023-03-11]. https://ct.cloudflare.com/.
[18]	BROGLE K, COOPER D, GOLDBERG S, et al. Impacting IP prefix reachability via RPKI manipulations[R]. Boston: Boston University, 2013.
[19]	HEILMAN E, COOPER D, REYZIN L, et al. From the consent of the routed: Improving the transparency of the RPKI[C]//Proceedings of 2014 ACM conference on SIGCOMM. Chicago, USA: ACM, 2014: 51-62.
[20]	KENT S, MANDELBERG D. Suspenders: A fail-safe mechanism for the RPKI[R]. San Francisco: IETF, 2014.
[21]	REYNOLDS M, KENT S, LEPINSKI M. Local trust anchor management for the resource public key infrastructure[R]. San Francisco: IETF, 2013.
[22]	MA D, MANDELBERG D, BRUIJNZEELS T. Simplified local internet number resource management with the RPKI (SLURM)[R]. San Francisco: IETF, 2018.
[23]	BARNES E. Resource public key infrastructure (RPKI) resource transfer protocol and transfer authorization object (TAO)[R]. San Francisco: IETF, 2014.
[24]	HUSTON G, MICHAELSON G, LOOMANS R. A profile for X. 509 PKIX resource certificates[R]. San Francisco: IETF, 2012.
[25]	HUSTON G, MICHAELSON G, MARTíNEZ C. Resource public key infrastructure (RPKI) validation reconsidered[R]. San Francisco: IETF, 2018.
[26]	HUSTON G. Is rsync that bad?[EB/OL]. (2020-10-27)[2023-03-11]. https://blog.apnic.net/2020/10/27/rpki-qa-the-trouble-with-rsync/.
[27]	HLAVACEK T, JEITNER P, MIRDITA D, et al. Stalloris: RPKI downgrade attack[C]//Proceedings of the 31st USENIX Security Symposium. Boston, USA: USENIX Association, 2022: 4455-4471.
[28]	NIST. NIST RPKI monitor[EB/OL]. [2023-03-11]. https://rpki-monitor.antd.nist.gov/.
[29]	NUSENU. The RPKI observatory[EB/OL]. [2023-03-11]. https://nusenu.github.io/RPKI-Observatory/index.html.
[30]	ZDNS. RPKIVIZ[EB/OL]. [2023-03-11]. https://rpkiviz.zdns.cn/statistic.
[31]	W?HLISCH M, SCHMIDT R, SCHMIDT T C, et al. RiPKI: The tragic story of RPKI deployment in the web ecosystem[C]//Proceedings of the 14th ACM Workshop on Hot Topics in Networks. Philadelphia, USA: ACM, 2015: 11.
[32]	CHUNG T, ABEN E, BRUIJNZEELS T, et al. RPKI is coming of age: A longitudinal study of RPKI deployment and invalid route origins[C]//Proceedings of the Internet Measurement Conference. Amsterdam, Netherlands: ACM, 2019: 406-419.
[33]	OSTERWEIL E, MANDERSON T, WHITE R, et al. Sizing estimates for a fully deployed rpki[R]. Reston: Verisign Labs, 2012.
[34]	GILAD Y, COHEN A, HERZBERG A, et al. Are we there yet? On RPKI's deployment and security[C]//Proceedings of Network and Distributed System Security Symposium. San Diego, USA: The Internet Society, 2017.
[35]	REUTER A, BUSH R, CUNHA I, et al. Towards a rigorous methodology for measuring adoption of RPKI route validation and filtering[J]. ACM SIGCOMM Computer Communication Review, 2018, 48(1): 19-27. DOI:10.1145/3211852.3211856
[36]	REUTER A, BUSH R, CUNHA I, et al. ROV deployment monitor[EB/OL]. [2023-03-11]. https://rov.rpki.net/.
[37]	CHEN W Q, WANG Z L, HAN D Q, et al. ROV-MI: Large-scale, accurate and efficient measurement of ROV deployment[C]//Proceedings of Network and Distributed System Security Symposium. San Diego, USA: The Internet Society, 2022.
[38]	WAN T, KRANAKIS E, VAN OORSCHOT P C. Pretty secure BGP, psBGP[C]//Proceedings of Network and Distributed System Security Symposium. San Diego, USA: The Internet Society, 2005.
[39]	HU Y C, PERRIG A, SIRBU M A. SPV: Secure path vector routing for securing BGP[C]//Proceedings of 2004 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications. Portland, USA: ACM, 2004: 179-192.
[40]	ZHAO M Y, SMITH S W, NICOL D M. Aggregated path authentication for efficient BGP security[C]//Proceedings of the 12th ACM Conference on Computer and Communications Security. Alexandria, USA: ACM, 2005: 128-138.
[41]	XIANG Y, SHI X G, WU J P, et al. Sign what you really care about-secure BGP AS-paths efficiently[J]. Computer Networks, 2013, 57(10): 2250-2265. DOI:10.1016/j.comnet.2012.11.019
[42]	HU Y C, PERRIG A, JOHNSON D B. Efficient security mechanisms for routing protocolsa[C]//Proceedings of Network and Distributed System Security Symposium. San Diego, USA: The Internet Society, 2003.
[43]	BUTLER K, MCDANIEL P, AIELLO W. Optimizing BGP security by exploiting path stability[C]//Proceedings of the 13th ACM conference on Computer and communications security. Alexandria, USA: ACM, 2006: 298-310.
[44]	WHITE R. Securing BGP through secure origin BGP (soBGP)[J]. Business Communications Review: Hinsdale, 2003, 33(5): 47-53.
[45]	GOODELL G, AIELLO W, GRIFFIN T, et al. Working around BGP: An incremental approach to improving security and accuracy in interdomain routing[C]//Proceedings of Network and Distributed System Security Symposium. San Diego, USA: The Internet Society, 2003.
[46]	HARI A, LAKSHMAN T V. The internet blockchain: A distributed, tamper-resistant transaction framework for the internet[C]//Proceedings of the 15th ACM Workshop on Hot Topics in Networks. Atlanta, USA: ACM, 2016: 204-210.
[47]	PAILLISSE J, FERRIOL M, GARCIA E, et al. IPchain: Securing IP prefix allocation and delegation with blockchain[C]//Proceedings of 2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData). Halifax, Canada: IEEE, 2018: 1236-1243.
[48]	XING Q Q, WANG B S, WANG X F. BGPcoin: Blockchain-based internet number resource authority and BGP security solution[J]. Symmetry, 2018, 10(9): 408. DOI:10.3390/sym10090408
[49]	SAAD M, ANWAR A, AHMAD A, et al. RouteChain: Towards blockchain-based secure and efficient BGP routing[J]. Computer Networks, 2022, 217: 109362. DOI:10.1016/j.comnet.2022.109362
[50]	CHEN D, BA Y, QIU H, et al. ISRchain: Achieving efficient interdomain secure routing with blockchain[J]. Computers & Electrical Engineering, 2020, 83: 106584.
[51]	HE G B, SU W, GAO S, et al. ROAchain: Securing route origin authorization with blockchain for inter-domain routing[J]. IEEE Transactions on Network and Service Management, 2021, 18(2): 1690-1705. DOI:10.1109/TNSM.2020.3015557
[52]	SENTANA I W B, IKRAM M, KAAFAR M A. BlockJack: Blocking IP prefix hijacker in inter-domain routing[C]//Proceedings of the Student Workshop. Barcelona, Spain: ACM, 2020: 1-2.
[53]	FELDMANN A E, FOSCHINI L. Balanced partitions of trees and applications[J]. Algorithmica, 2015, 71(2): 354-376. DOI:10.1007/s00453-013-9802-3
[54]	SANDERS P, SCHULZ C. Think locally, act globally: Highly balanced graph partitioning[C]//Proceedings of the 12th International Symposium on Experimental Algorithms. Rome, Italy: Springer, 2013: 164-175.
[55]	HLAVACEK T, CUNHA I, GILAD Y, et al. DISCO: Sidestepping RPKI's deployment barriers[C]//Proceedings of the 27th Annual Network and Distributed System Security Symposium. San Diego, USA: The Internet Society, 2020.
[56]	ORSINI C, KING A, GIORDANO D, et al. BGPStream: A software framework for live and historical BGP data analysis[C]//Proceedings of 2016 Internet Measurement Conference. Santa Monica, USA: ACM, 2016: 429-444.
[57]	APNIC. APNIC guidelines for IPv4 allocation and assignment requests[EB/OL]. (2005-09-01)[2022-12-19]. https://www.apnic.net/about-apnic/corporate-documents/documents/resource-guidelines/ipv4-guidelines/.
[58]	ANDROULAKI E, BARGER A, BORTNIKOV V, et al. Hyperledger fabric: A distributed operating system for permissioned blockchains[C]//Proceedings of the thirteenth EuroSys conference. Porto, Portugal: ACM, 2018: 30.
[59]	LIN Q W, LI C, ZHAO X F, et al. Measuring decentralization in bitcoin and ethereum using multiple metrics and granularities[C]//Proceedings of the 2021 IEEE 37th International Conference on Data Engineering Workshops. Chania, Greece: IEEE, 2021: 80-87.