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系统通过验证路由起源信息事实所有权来确定自治系统与网络资源的合法绑定关系. 由AS_i在DISCO_Registrar中申请资源绑定证书及其私钥(pk, sk), 并在向外宣告的BGP_ad消息的属性字段中附加由该资源证书私钥的签名Sign_sk(AS_i, IPPrefix). 当DISCO部署在实际网络中n≥N_Threshold个有利观测点DISCO_vp在一定时间间隔T内接收到携带于该证书签发的资源绑定关系一致的BGP_ad消息时, DISCO判定其路由源对其IP地址前缀是享有事实所有权的. 其主要过程描述如下:

(1) ${\text{A}}{{\text{S}}_{{i}}}{{{(pk, sk)}}} \leftarrow {\text{DISC}}{{\text{O}}_{{\text{Registrar}}}}$

(2) ${\text{\{ A}}{{\text{S}}_{\text{1}}}{\text{, }}\cdots{\text{, A}}{{\text{S}}_{{\text{neighbor}}}}{\text{\} }} \leftarrow {\rm{{BGP}}_{\rm{ad}}}({\text{Sig}}{{\text{n}}_{{\text{sk}}}}{\text{(A}}{{\text{S}}_{{i}}}{\text{, IPPrefix))}}$

(3) ${\text{DISC}}{{\text{O}}_{{\text{vp}}}}{\text{: Signe}}{{\text{d}}_{{\text{AS}}{{{i}}_{{\text{sk}}}}}}{{({\rm{BG}}}}{{{\rm{P}}}_{{{\rm{ad}}}}}{\text{)}} \leftarrow {\text{\{ A}}{{\text{S}}_{\text{1}}}{\text{, }}\cdots{\text{, A}}{{\text{S}}_{{n}}}{\text{\} }}$

(4) ${\text{DISCO:(A}}{{\text{S}}_{{i}}}{\text{, IPPrefix)}}\mathop \leftarrow \limits^{{{t }} \leqslant {{ T}}} {\text{\{ DISC}}{{\text{O}}_{{\text{VP1}}}}{\text{, }}\cdots{, {\text{DISC}}}{{\text{O}}}_{{{{\text{VP}}n}}}\}$

(5) ${{n}} \geqslant {{{N}}_{{\text{Threshold}}}} \Rightarrow {{\text{(A}}{{\text{S}}_{{i}}}{\text{, IPPrefix)}}_{\rm{valid}}}$

由此可知, 事实所有权是指域间路由系统中其他自治域对于某个自治域宣称对特定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结构的域间信息同步数据交互次数复杂度为n². 如图3所示, 文献[14]通过在RP服务器与 AS之间构建多层级VC (validation cache, 有效缓存) 服务器向不同AS进行RPKI数据分发, 以此将各个独立AS规划在统一的管理域内, 保证了RPKI数据的一致性, 而且将全球RP同步次数复杂度降低为n. 此外, 依托于此架构与DISCO事实所有权验证方案, 可以用底层VC_i服务器代替DISCO观测点DISCO_vp, 顶层VC_top服务器代替DISCO_Registrar, AS_j接入时上传其RC_j, ROA_j至底层VC_j, 故本方案的事实所有权验证过程如下:

(1) ${\text{V}}{{\text{C}}_{{j}}} \leftarrow {\text{A}}{{\text{S}}_{{j}}}{\text{(R}}{{\text{C}}_{{j}}}{\text{, RO}}{{\text{A}}_{{j}}}{\text{)}}$

(2) ${\text{\{ A}}{{\text{S}}_{\text{1}}}{\text{, }}\cdots{\text{, A}}{{\text{S}}_{{n}}}{\text{\} }} \leftarrow {\text{A}}{{\text{S}}_{{j}}}{\text{.BG}}{{\text{P}}_{{\text{ad}}}}$

(3) ${\text{V}}{{\text{C}}_{{i}}}{\text{: A}}{{\text{S}}_j}{\text{.BG}}{{\text{P}}_{{\text{ad}}}} \leftarrow {\text{\{ A}}{{\text{S}}_{\text{1}}}{\text{, }}\cdots{\text{, A}}{{\text{S}}_{{n}}}{\text{\} }}$

(4) ${\text{V}}{{\text{C}}_{{\text{top}}}}{\text{: (A}}{{\text{S}}_{{j}}}{\text{, IPPrefix)}}\mathop \leftarrow \limits^{{{t }} \leqslant {{ T}}} {\text{\{ V}}{{\text{C}}_{\text{1}}}{\text{, }}\cdots{\text{, V}}{{\text{C}}_{{n}}}{\text{\} }}$

(5) ${{n}} \geqslant {{{N}}_{{\text{Threshold}}}} \Rightarrow {{\text{(A}}{{\text{S}}_{{j}}}{\text{, IPPrefix)}}_{\rm{valid}}}$

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

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

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

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

流程1. 本地事实路由起源信息同步流程

1) while RIB_Local‖(RC_i, ROA_i) update‖AS_i ← VC_i.Reset do

2)　case: (RC_i, ROA_i) update

3)　　VC_i.RC_i = AS_i.RC; VC_i.ROA_i =AS_i.ROA_i

4)　case: VC_i ← AS_i.Notify_n

5)　　if VC_i.RLSN == AS_i.Notify_n.SN-1

6)　　　VC_i.RoiLocal = VC_i.RoiLocal+ROIs; VC_i.RLSN++

7)　　else

8)　　　AS_i ← VC_i.Reset

9)　　end if

10)　 case: AS_i ← VC_i.Reset

11)　　VC_i ← AS_i.RoiLocal

12)　　VC_i.RoiTable = AS_i.RoiLocal;

　　　 VC_i.RoiTable.SN= AS_i.RoiLocal.SN

13) end while

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

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

流程2. 全局事实路由起源信息同步流程

1) while VC_i ← VC_top.RequestSN‖VC_top ← VC_i.Reset‖ VC_i←VC_top.RoiGlobalIncr

2)　　case: VC_i ← VC_top.RequestSN

3)　　　if VC_top.RequestSN == VC_i.RGSN+1

4)　　　　for j=1; j≤VC_i.ROIs.Length;j++ do

5) 　　　　if VC_i.ROIs_j.LifeTime ≥ T

6)　　　　　 VC_top.RoiGlobal = VC_top.RoiGlobal +VC_i.ROIs_j

7) 　　　　else

8) 　　　　　VC_top.RoiRecv = VC_top.RoiRecv+VC_i.ROIs_j

9) 　　　　end if

10) 　　　end for

11) 　　　VC_top.RoiGlobal.SN++; VC_i←VC_top.RoiGlobalIncr

12) 　　else

13) 　　　VC_top ← VC_i.Reset

14) 　case: VC_i←VC_top.RoiGlobalIncr

15) 　　　VC_i.RoiGlobal = VC_i.RoiGlobal+VC_top.RoiGlobalIncr; VC_i.RoiGlobal.SN++

16) 　case: VC_top ← VC_i.Reset

17) 　　VC_i ← VC_top.RoiGlobal

18) 　　VC_i.RoiGlobal = VC_top.RoiGlobal; VC_i. RoiGlobal.SN=VC_top.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缓存撤销更新冲突检测

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

算法1. RPKI缓存撤销更新冲突检测

1) 输入: 撤销缓存更新ROA_i.

2) 输出: 本次检测结果R_i.

3) 初始化: R_i=valid

4) ROI = ROILPM(ROA_i)

5) for j=1; j≤ROI.Length;j++ do

6)　　if (ROI_j.IPPrefix ϵ ROA_i.IPPrefixBlock)||(ROI_j.IPPrefix = = ROA_i.IPPrefix)

7)　　　if (ROI_j.AS_n==ROA_i.AS_n)

8)　　　　R_i=invalid; break

9)　　　end if

10)　　end if

11) end for

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

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

算法2. RPKI缓存新增更新冲突检测

1) 输入: 新增的缓存更新ROA_i.

2) 输出: 本次检测结果R_i.

3) 初始化: R_i=valid

4) ROI =ROI LPM(ROA_i)

5) for j=1; j≤ROI.Length;j++ do

6)　if (ROI_j.IPPrefix∈ROA_i.IPPrefixBlock)&&(ROA_i.AS_n≠ROI_j.AS_n)

7)　　R_i=invalid

8)　end if

9)　if (ROA_i.IPPrefix == ROI_j.IPPrefix) &&(ROA _i.AS_n ≠ ROI_j.AS_n)

10)　　R_i=invalid

11)　 end if

12)　 $\scriptstyle {\text{if RO}}{{\text{A}}_{{j}}} \cap {\text{RO}}{{\text{A}}_{{i}}}$

13)　　R_i=invalid

14)　end if

15)　end for

2.4.3 实际部署中的方案优化

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

(1) 时间间隔参数T

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

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

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

(3) 新增快速确认

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

3 实验与分析

为了验证方案的可行性和性能表现, 本文配置了1台服务器分别对全局路由起源信息的同步和RPKI缓存更新冲突检测的数据同步性能进行了测试, 实验所用服务器配置如表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对VC_top的撤销确认机制, 此类情况下同文献[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种冲突缓存更新检出性能上存在一定优势.