基于事实所有权的RPKI缓存更新冲突检测机制①

肖文龙,马 迪,,毛 伟,邵 晴

1(中国科学院 计算机网络信息中心,北京 100190)

2(中国科学院大学,北京 100049)

3(互联网域名系统国家地方联合工程研究中心,北京,100190)

1 背景

随着全球互联网规模不断扩大,各个AS (autonomous system,自治系统)间的流量转发也愈发频繁.而不同AS 之间能够互联互通的关键就是BGP (border gateway protocol,边界网关协议) 协议[1].但其基于互联网安全可信原则,没有提供保障BGP 消息真实性和有效性等的安全机制,致使它很容易因网络运维者的配置失误或恶意攻击的影响,引发严重的BGP路由泄露与劫持事件,严重威胁全球互联网的安全与稳定.

有鉴于此,业界与学术界着手制定替代BGP的安全域间路由方案.其中应用最为广泛的是IETF (Internet Engineering Task Force,互联网工程任务组) 提出的通过RPKI (resource public key infrastructure,资源公钥基础设施)[2]来进行的BGP 路由起源验证的安全方案,即ROV (route origin validation,路由起源验证)[2].

1.1 RPKI 体系工作机制

RPKI 体系的核心设计思想是通过构建一套层次结构的PKI (public key infrastructure,公钥基础设施)实现对 INR (Internet number resource,互联网码号资源)所有权的分配和验证[3].如图1中所示,RPKI 是以RIR (regional internet registry,区域互联网注册机构)为单一信任锚点的层级信任模型.该模型通过逐层签发证书,构建出从根证书到最低层次的CA (certificate authority,证书颁发机构) 证书的信任链,使得RP (relaying partiy,依赖方)从统一的根证书就可以验证任意CA 证书[3].此外,从图1可知RPKI 体系对于IP 地址前缀与路由起源分配关系的签发和验证并不依赖BGP 协议,这最大程度的降低了在BGP 上广泛实施ROV 时,对全局BGP 路由收敛速度的不利影响.

1.2 RPKI 全面部署面临的障碍

RPKI 带外验证的优势使其迅速成为实施ROV的主流技术,但至今为止RPKI 覆盖的IP 地址空间占比仍然较小,实现全面部署依然漫长.根据来自ICANN的最新报告[4]以及APNIC (Asia Pacific Network Information Centre,亚太网络信息中心)的研究[5]表明RPKI 全面部署主要面临如下几个障碍:

(1)数据同步一致性问题;

(2)供给侧运维失误风险;

(3)5 大RIR的权利滥用风险.

1.2.1 数据同步非一致性问题

由于各个RP 服务器与RPKI 资料库进行数据同步及其验证是独立的,各个RP 之间的数据同步,验证并不会相互影响.这使得各个RP的本地数据不一致,这将致使其输出至各个AS的有效路由授权与全局实际有效路由信息发生冲突,最终导致不同AS 之间存在路由信息冲突.

1.2.2 供给侧运维失误风险

目前RPKI的CA 证书资料库依然是通过网络管理人员进行运维,难免会发生一些人为失误,主要的失误为:CA 资料库数据更新不及时.ISP (Internet service provider,网络服务提供商) 以授权模型部署RPKI 时,其被上级资源持有机构授权自行管理被分配的IP 地址前缀资源的RPKI 签名对象.ICANN 指出一些小型ISP 对于其CA 资料库的数据运维不及时或是放弃运维,导致资料库中的RPKI 签名对象文件过期[3].这将导致其他部署RPKI的AS 因该ISP 签发的ROA (route origin authorization,路由起源授权)证书过期而将其验证为无效.

1.2.3 5 大RIR的权利滥用风险

(1)单一撤销机制

RPKI 证书颁发机构通过签发CRL (certificate revocation list,证书撤销列表),对未过期的有效证书的撤销,并且这种撤销操作是单方面的,即无需要证书的私钥持有者许可.文献[6]指出这种权力的失衡使IP前缀资源的使用者暴露在随时可能被剥夺合法网络使用权的风险下.

(2)隐性撤销

RPKI 权威机构亦可以通过不发布绑定了IP 前缀使用者的签名对象文件,或是拒绝RP 访问该签名对象文件,来达到IP 前缀与使用者的授权关系实际不生效的效果[6].

(3)资源覆盖与重写

RPKI 权威机构将已分配给下级资源持有者的前缀区块重新签发给其他自治系统,亦或通过签发新ROA 覆盖未部署RPKI的事实有效前缀,这些情况的发生都将影响BGP 流量的正常转发.

1.3 RPKI 缓存更新风险防范方案研究现状

由于上述风险与问题将直接影响RP 对RPKI 缓存更新结果的正确性.因此学者们提出了在CA 侧对CA 恶意或误操作的预防和在RP 侧的错误检测的方案.

刘晓伟等人提出建立CA 侧CA 资源分配误操作的检测方案[7],以防止CA 跨级的重复分配等误操作行为.该方案无需搭建另外的信任机制,仅通过规范CA的资源分配行为,提高了CA的资源分配的准确性,降低了供给侧运维失误风险.但是无法预防CA 恶意的权力滥用行为.Xing 等人利用区块链的去中心化的信任模型优势提出了BGPCoin 方案[8,9].BGPCoin 通过区块链公共账本记录网络资源所有权的实时变化,同时区块链的公开、不可篡改的特性使得CA 对网络资源所有权的分配更加透明和可追溯.但是BGPCoin 记账的时间、空间开销较大,其在实际网络中的性能是否满足实际需求仍然有待验证.Shrishak 等人提出通过门限签名算法使得每个RPKI 证书的签发与撤销都需要5 大RIR的协商同意,从而限制了单个RIR的绝对权力[10].其性能表现在5 大RIR的门限签名模型中比基于区块链得方案更加优秀,但是为了保证CA 行为受到严格的限制,则需要赋予更多方参与门限签名,这使得该方案的性能表现大大下降.Kent 等人提出当RP因无法获取原有证书文件而需要进行缓存删除时,RP可以暂停一段时间对此缓存删除,并允许RP 使用原文件进行更新,随后核实该操作确为所需后再删除[11].该方案的优势在于几乎不需要投入额外的基础设施的建设,但是该方案难以准确设定延迟操作的时间,时间过短无法保证能够恢复受影响的数据,时间太长降低了缓存更新的时效性,此外对于外部核实步骤亦没有明确的规则,更是加大了缓存更新的复杂性.Heilman等人提出资源使用者使用RPKI的资源证书签发该资源的.dead 对象来表示同意权威方对该资源的撤销,以此来防止未经许可的撤销或覆盖发生[12].该方案在现有的RPKI 机制中引入了对资源持有者的权益保障,对现有的RPKI 机制具有较好的兼容性.但该方案中需要对.dead 签名文件的同步与验证,同样会因为各RP 同步.dead 文件时间不一致,导致数据不一致问题.此外,通过签发同意撤销的.dead 文件的方式,消耗了RP 额外的计算资源.

1.4 基于事实所有权的RPKI 缓存更新冲突检测原理

1.4.1 事实所有权原理

本文的路由起源信息的事实所有权源于Hlavacek等人提出的路由起源信息事实所有权的验证系统——DISCO[13].DISCO 系统通过验证路由起源信息事实所有权来确定自治系统与网络资源的合法绑定关系.由ASi在DISCORegistrar中申请资源绑定证书及其私钥(pk,sk),并在向外宣告的BGPad消息的属性字段中附加由该资源证书私钥的签名Signsk(ASi,IPPrefix).当DISCO 部署在实际网络中n≥NThreshold个有利观测点DISCOvp在一定时间间隔T内接收到携带于该证书签发的资源绑定关系一致的BGPad消息时,DISCO 判定其路由源对其IP 地址前缀是享有事实所有权的.其主要过程描述如下:

由此可知,事实所有权是指域间路由系统中其他自治域对于某个自治域宣称对特定IP 前缀资源所有权声明的接受或认可.具体体现为自治域向其他自治域通告路由起源消息更新时,该条BGP 更新可以通过其他自治域的本地路由通告过滤策略被自治域BGP路由器保存至路由转发信息表中.且该条路由起源在生命周期内(生命周期指路由起源信息从被其他路由器接收的时间接收到至原自治域撤销的时间段)内不会被域间路由系统视为异常路由信息,而被其他路由器删除或忽略.

1.4.2 BGP 路由起源信息的稳定性

BGP 路由劫持者发起的非法的路由起源信息同样可能被全球BGP 路由器接收,如果仅凭大部分路由器是否接收该路由起源信息作为路由源合法的依据,将可能把非法路由起源信息错误识别为合法的.另一方面,非法的路由起源信息并不会在全局BGP 路由系统中长期存在.

本文分析了正常情况下路由起源信息(即路由源与IP 地址资源的分配关系)在网络中存续时间的分布规律.数据源来自于比较权威的RIPE (regional internet registry for Europe,欧洲互联网注册机构)的rrc13 采集器的RIB (route information base,路由信息表)数据,采集范围为协调世界时间2020年10月17日0 时0 分至2020年10月31日0 时0 分.结果如图2所示,纵坐标BGP 路由前缀资源分配关系变化率表示路由源与IP 地址前缀的分配关系在存活时间内已改变占总数比,稳定存在时间小于等于8 h的占0.29%,路由源与IP 地址资源的分配关系稳定存在时间大于272 h的占97.53%.

如图2所示,在较长的时间内,绝大部分的路由源与IP 地址资源的分配关系是稳定不变的,只有极少部分的路由源与IP 地址资源的分配关系是存在变化的.那么依靠合法路由起源信息的稳定性特征,我们可以通过设置观察期来观察一个新增的路由起源信息是否是稳定存在的,进而防止短时存在的非法路由起源信息被误识别为事实存在路由起源信息.

因此,本文结合路由起源信息的事实所有权原理及其稳定性特征,提出了一种基于事实所有权的RPKI缓存更新冲突检测机制.下面对本方案的设计与实现进行详细阐述.

2 基于事实所有权的RPKI 缓存更新冲突检测机制设计

2.1 总体方案架构

BGP 网络里AS 之间部署的路由器是独立运行的,全局的事实路由起源信息同步结构为P2P (peer to peer,点对点)型.这种P2P 结构的域间信息同步数据交互次数复杂度为n2.如图3所示,文献[14]通过在RP 服务器与 AS 之间构建多层级VC (validation cache,有效缓存) 服务器向不同AS 进行RPKI 数据分发,以此将各个独立AS 规划在统一的管理域内,保证了RPKI 数据的一致性,而且将全球RP 同步次数复杂度降低为n.此外,依托于此架构与DISCO 事实所有权验证方案,可以用底层VCi服务器代替DISCO 观测点DISCOvp,顶层VCtop服务器代替DISCORegistrar,ASj接入时上传其RCj,ROAj至底层VCj,故本方案的事实所有权验证过程如下:

基于对AS 事实权益的保障,在AS 对网络资源事实所有权的存续期间对引发其绑定关系正常使用的RPKI 缓存更新应该视为冲突缓存,应停止将其更新进入路由器中.

所以,基于事实所有权的RPKI 缓存更新冲突检测机制分为如下3 个阶段,一是利用底层VC 服务器同路由器进行本地事实路由起源信息的同步;二是,底层VC 服务器将改变的本地同步数据发送至顶层VC 服务器进行全局路由起源数据汇总;三是,利用全局路由起源信息表对缓存更新进行冲突检测,排除对表内的路由源的冲突更新.本文在下文中分别对这3 个阶段的方案进行了设计.

2.2 本地事实路由起源信息同步方案设计

本文使用反向RTR 协议进行本地事实路由起源信息同步,即通过新增RTR[15]协议负载类型,使原有RTR的只有从RP 侧向BGP 路由器传输的单一方向的数据同步,增加从BGP 路由器侧至RP 侧传输ROI(router origin information,路由起源信息)的反向RIB数据同步.当RIBLocal发生ROIs {ROI1(updateStyle,ASn,IPPrefix),ROI2,…,ROIn}更新或ASi的路由源授权证书ASi.ROA 更新时,通过反向RTR 协议发送序列号ASi.Notifyn.SN为n的ASi.Notifyn开启与VCi本地ROI 数据库VCi.RoiLocal的ROIs 数据同步或(RCi,ROAi)更新,同步过程参照RTR 协议设计,具体同步流程如流程1 所示.

流程1.本地事实路由起源信息同步流程1) while RIBLocal‖(RCi,ROAi) update‖ASi ← VCi.Reset do 2) case:(RCi,ROAi) update 3) VCi.RCi=ASi.RC;VCi.ROAi=ASi.ROAi 4) case:VCi ← ASi.Notifyn 5) if VCi.RLSN==ASi.Notifyn.SN-1 6) VCi.RoiLocal=VCi.RoiLocal+ROIs;VCi.RLSN++7) else 8) ASi ← VCi.Reset 9) end if 10) case:ASi ← VCi.Reset 11) VCi← ASi.RoiLocal 12) VCi.RoiTable=ASi.RoiLocal;VCi.RoiTable.SN=ASi.RoiLocal.SN 13) end while

2.3 全局事实路由起源信息同步方案设计

如图3所示,本文通过部署在AS的VC 服务器利用反向RTR 协议实时采集BGP 路由起源信息,建立本地路由起源信息数据库VCi.RoiLocal.另外,通过底层VCi服务器记录下同步更新ROI 及其接收时间,再由顶层VCtop服务器进行汇总统计,最终VCtop将满足预设时间间隔T的ROIsj更新至VCtop.RoiGlobal,将不满足时间间隔T的ROIsj更新至VCtop.RoiRecv,并将本次全局更新结果VCtop.RoiGlobalIncr 反馈至底层VCi完成一次VCtop.RoiGlobal的更新.具体流程如流程2.

流程2.全局事实路由起源信息同步流程1) while VCi ← VCtop.RequestSN‖VCtop ← VCi.Reset‖ VCi←VCtop.RoiGlobalIncr 2) case:VCi← VCtop.RequestSN 3) if VCtop.RequestSN==VCi.RGSN+1 4) for j=1;j≤VCi.ROIs.Length;j++do 5) if VCi.ROIsj.LifeTime ≥ T 6) VCtop.RoiGlobal=VCtop.RoiGlobal+VCi.ROIsj 7) else 8) VCtop.RoiRecv=VCtop.RoiRecv+VCi.ROIsj 9) end if 10) end for 11) VCtop.RoiGlobal.SN++;VCi←VCtop.RoiGlobalIncr 12) else 13) VCtop ← VCi.Reset 14) case:VCi←VCtop.RoiGlobalIncr 15) VCi.RoiGlobal=VCi.RoiGlobal+VCtop.RoiGlobalIncr;VCi.RoiGlobal.SN++16) case:VCtop ← VCi.Reset 17) VCi ← VCtop.RoiGlobal 18) VCi.RoiGlobal=VCtop.RoiGlobal;VCi.RoiGlobal.SN=VCtop.RoiGlobal.SN 19) end while

2.4 基于事实所有权的RPKI 缓存更新冲突检测方案

通过对第1 节中RPKI 全面部署面临的障碍的分析,本文将RPKI 缓存更新与实际域间网络起源信息的冲突总结为以下4 种.

(1)因RPKI 证书维护不及时导致过期失效冲突.

(2)CA 失误撤销RPKI 证书导致证书无效冲突.

(3)资料库访问失败,原有证书过期失效冲突.

(4)CA 跨级签发已分配的IP 前缀的子前缀冲突.

因此,当顶层VC 服务器接收RPKI 缓存更新时,应提取撤销和新增操作的RPKI 缓存更新分别与最新的全局路由起源信息表核对,校验是否存在撤销当前仍然存在于网络中的路由起源信息,并输出存在冲突的RPKI 缓存更新.

2.4.1 RPKI 缓存撤销更新冲突检测

在对ROAi与当前全局路由起源信息核对过程中,首先需要查找出与该ROAi相关的ROI.虽然在当前ROA 中IP 前缀资源绑定大多是某条特定的前缀,但也存在部分的是IP 前缀区块(例如,{ASn:3,IPPrefix:103.134.63/22,maxLength:24}),故本前缀匹配函数ROILPM(ROAi)输出的是对ROAi前缀长度匹配的最长前缀,及其maxLength 划定的区块中包含的全部ROI 前缀.另外,当匹配的ROIj与撤销的ROAi相同或为其区块内子前缀的资源分配关系,则此撤销更新ROAi为无效.具体算法如算法1.

算法1.RPKI 缓存撤销更新冲突检测1) 输入:撤销缓存更新ROAi.2) 输出:本次检测结果Ri.3) 初始化:Ri=valid 4) ROI=ROILPM(ROAi)5) for j=1;j≤ROI.Length;j++do 6) if (ROIj.IPPrefix ϵ ROAi.IPPrefixBlock)||(ROIj.IPPrefix==ROAi.IPPrefix)7) if (ROIj.ASn==ROAi.ASn)8) Ri=invalid;break 9) end if 10) end if 11) end for

2.4.2 RPKI 缓存新增更新冲突检测

ROILPM 函数输出的ROIj同上,当ROIj为其区块内子前缀或相同前缀,但资源分配关系不一致时,则此新增更新ROAi为无效.另外ROI为IP 前缀与ASn的绑定关系,为防止出现ROIj所属的ROAj区块与检测的ROAi存在交叉覆盖,故当该ROAj与被检测的ROAi存在子前缀交集时,其也为无效.具体算法如算法2.

算法2.RPKI 缓存新增更新冲突检测1) 输入:新增的缓存更新ROAi.2) 输出:本次检测结果Ri.3) 初始化:Ri=valid 4) ROI=ROI LPM(ROAi)5) for j=1;j≤ROI.Length;j++do 6) if (ROIj.IPPrefix∈ROAi.IPPrefixBlock)&&(ROAi.ASn≠ROIj.ASn)7) Ri=invalid 8) end if 9) if (ROAi.IPPrefix==ROIj.IPPrefix) &&(ROAi.ASn≠ROIj.ASn)10) Ri=invalid 11) end if if ROAj∩ROAi 12)13) Ri=invalid 14) end if 15) end for

2.4.3 实际部署中的方案优化

此外,在实际BGP 网络的运行中还需要针对BGP网络与RPKI的运维特性对本方案的相关参数及判定进行相应优化.

(1)时间间隔参数T

在实际BGP 网络中BGP 通告全局传播存在一定的时延,即其他AS 收到的BGP 通告存活时间相较于真实存活少了时延Ts,因此对于各个AS 收到通告的存活时间T应该加上传播时延Ts,而一般BGP 消息的全局传播时延Ts在38 s 至2 min 之间[16].

(2)全局快速撤销与未在网使用撤销确认

如图4所示,正常情况下AS的BGP 路由器停用前缀,会先主动断开BGP 连接,如有必要在RPKI 中撤销该前缀,还会进行请求CA 撤销该ROA.当全局VC绝大多数都收到一个BGP 撤销消息时,此时不必等待时间间隔T,立即确认全局ROI 撤销事实成立.另一方面,ISP 会签发少量特定用途的ROA,比如用在流量工程中,这些ROA 签发后并不会立即启用,故针对此类ROA的撤销应该通过VCtop与该AS 相连的VC 进行撤销确认.

(3)新增快速确认

如图5所示,在部署了RPKI的AS 每当启用新的前缀资源时需要先签发ROA,即使冲突检测为有效,但此时AS 与该前缀绑定关系存在时间小于预设T,此期间对其发起的错误撤销则无法检测出,故当此ROA冲突检测为有效且新增的ROA 与VCtop接收的ROA相同时,应立即确认其新增事实成立.

3 实验与分析

为了验证方案的可行性和性能表现,本文配置了1 台服务器分别对全局路由起源信息的同步和RPKI缓存更新冲突检测的数据同步性能进行了测试,实验所用服务器配置如表1.

表1 服务器配置

3.1 全局路由起源信息同步实验

全局路由起源信息同步实验中各模块数据流如图6所示,底层VC 服务器通过反向RTR 来采集路由起源更新信息,并且在解析,校验反向RTR PDU 数据包和请求更新的序列号无误后,进行更新本地路由起源信息表.底层VC 服务器定期向汇聚层发送对全局路由起源信息表的路由起源更新信息.汇聚层VC 服务器校验更新序列号无误后,进行更新信息汇总,统计每条更新信息提交的AS 数,统计完毕后将汇聚结果发送至顶层VC 服务器进行全局同步.

实验使用1 号物理机22229 端口模拟底层VC 服务器进行本地同步和底层全局同步,2181 端口模拟汇聚层VC 服务器进行汇聚处理,33339 端口作为顶层VC 服务器进行顶层全局路由起源信息同步.并且通过向1 号物理机的汇聚层服务器的路由起源消息接收队列中分别并行发送(2 000 个,4 000 个,6 000 个,8 000 个,10 000 个)路由源数据包,每个数据包含有100 条路由起源更新信息,以此模拟不同的AS 接入规模,并记录同步花费的时间(单位:s).

由图7可知,随着接入的底层VC 服务器增多,本方案的全局路由起源信息同步时间也将越来越长.

3.2 冲突检测分析

3.2.1 效率分析

本文依照文献[12]的全网部署的假设条件,在实际RPKI 数据中随机选择5 组不同规模的AS 组成的5 个规模的域间网络.分别测试了不同规模下单节点进行.dead 对象和全量全局路由信息数据同步的时间消耗.如图8所示,横坐标表示网络中AS的数量,纵坐标为同步耗时(单位:s).

本方案不仅在数据的全量同步时间消耗上表现更佳,而且部署在服务器上的全量数据所占用的存储空间也更少.对比结果如图9所示.

文献[12]的方案需要每个AS 对来自不同的上级CA 签发的证书,动态维护一个包含同意删除的资源集合签名.dead 对象,则每个AS 至少维护一个.dead 资料库.并且RP 需要对其进行同步和链式验证,不同于ROA的验证的是.dead的验证是逆向的,即叶子节点的.dead 对象只需验证叶子证书的有效性,中间CA 签发的.dead 对象则需验证其包含的全部子资源的.dead对象.因此,如图8所示,虽然其需要签发的文件少于ROA,但对其签名文件的同步验证依然将消耗比本方案更多的计算时间.同时,随着部署率上升对于部署文献[12]方案的存储消耗也远超本方案.

3.2.2 检出性能分析

本文基于文献[12]中的假设,即在网络全部部署RPKI,各个AS 与RP 行为是诚实可信且公钥密码体系无法破解的条件下,仅就两方案对于由权威方过失行为导致的冲突缓存的检测性能进行分析.实验数据取自6月4日的RPKI 数据和实际长期存活的BGP 数据,随机选取的100 个AS 对应的前缀分配数据,并就3 种冲突情况分别进行了模拟.在本方案和文献[12]的部署率下降时的冲突检出率进行了对比.实验结果如下:

(1)CA 单边撤销证书与资料库证书异常过期失效

撤销更新的检测实验模拟的数据分为两类,一类是对已在网络中使用BGP 前缀的ROA 进行单边撤销(异常过期失效),另一类是对已签发ROA 但是ROA的前缀未在BGP 中使用的单边撤销(异常过期失效),两类数据量占比相等.

如图10所示,本方案的检出率下降速度慢于文献[12]方案.因为本方案对全局ROI的采集率不会随着部署率的下降而下降,这使得其在部署率下降的情况下仍能保护网络中在使用的BGP 前缀.另一方面,对于未在现网中使用的ROA的撤销依赖于AS 对VCtop的撤销确认机制,此类情况下同文献[12]一样检出率等同于方案的部署率.故在相同部署率下本方案的综合检出率更高.

(2)资源重写冲突检测

资源重写冲突检测实验模拟的数据分为两类,一大类是对已在网络中使用BGP 前缀的ROA 重写,其中重写的类型亦分为全部重写(ROA 包含的全部前缀区块)与部分重写(ROA 包含的部分前缀区块).另一大类是对ROA 已签发但是其前缀未在BGP 中使用的ROA 重写,其中重写的类型同上.各类数据量比例相等.

如图11所示,对于已在网使用的ROA,本方案可以不受部署率限制获取网络中的全局ROI,但是CA 可以部分重写ROA 区块,避开与ROI 存在冲突的部分.文献[12]则需要通过发布的.dead 文件,才能对重写冲突进行校验.故在相同部署率下本方案的检出率更高.

如图12所示,对于未在网使用的ROA,本方案无法获取在网使用的ROI,只能通过AS 上传至VC的ROA 进行重写检测,检出性能受部署率变化与文献[12]相同故在相同部署率下本方案的检出率无优势.

(3)资源覆盖冲突检测

资源覆盖的冲突检测实验针对未被ROA 数据覆盖但已在网使用的IP 前缀,故RPKI的部署率始终为0.即仅依靠ROI 或签发.dead 对象能够检出资源覆盖冲突的比率.

如图13所示,对于已在网使用的IP 前缀,虽然本方案检出性能不受部署率变化的影响,但是本方案事实所有权路由源判定模型属于多方共识决策模型,故实际部署中参与决策的节点(部署的节点)的数量比例不应太低.

(4)RPKI 数据一致性问题分析

文献[12] 描述了一种镜像世界的数据不一致情况,在这种情况下两个资源持有者因同步的时间先后,产生完全不同的RPKI 视野,该种情况下文献[12]方案无法通过验证.dead 文件保持全局RPKI 视野一致.而本方案的全局路由起源信息表是严格序列全局同步的,全局各节点处在统一的事实有效路由信息和RPKI缓存视图.

4 结束语

随着部署RPKI 进行ROV的网络运营商的不断增多,RPKI 在域间路由系统实际部署中的存在的问题和风险也愈加凸显.在此背景下,本文通过分析RPKI进入全面部署的问题和风险,定位阻碍RPKI 全面部署的根源所在,并提出基于事实BGP 路由起源信息的原理和路由起源信息的稳定性,实现了一种基于事实所有权的RPKI 缓存更新冲突检测机制.最后模拟了5 种不同规模的BGP 网络,实验对比了本方案与现有的其它方案的时间效率.另外对3 种冲突缓存更新的检出性能,实验结果与分析表明本文方案3 种冲突缓存更新检出性能上存在一定优势.