1 背景 1.1 现状

BGP (Border Gateway Protocol, 边界网关协议)缺乏验证真实性和合法性的安全手段, 它容易遭到各种恶意攻击. 为解决BGP缺乏安全认证的问题, Kent S等人于2002年提出了S-BGP^[1]. 基于S-BGP的设计思想, IETF (Internet Engineering Task Force, 互联网工程任务组), RPKI (Resource Public Key Infrastructure, 资源公钥基础设施)的技术标准化工作, 旨在提供路由信息交换的认证^[2].

RPKI数据传输结构如图1所示, RPKI依赖方同步RPKI认证中心或资料库(供给侧)的数据, 并将验证数据分发给BGP路由系统(需求侧)以供路由器进行验证. RPKI依赖方需要相当频繁的验证证书和CRL, 性能将是数据传输首要考虑的问题^[3]. 文献[4]实现了一种基于有序哈希树的RPKI资料库同步工具, 改进了目前数据同步协议Rsync协议^[5]未考虑到RPKI中文目录的缺陷, 能够大量减少中文数据同步时间和资源消耗. 文献[6]实现了基于Delta协议^[7]的RPKI数据同步, 能够解决目前基于Rsync协议进行数据同步所具有的安全隐患. 文献[8]实现了基于哈希表的RPKI证书验证优化方法, 通过使用哈希表的方式取代数据库查询进行数据验证, 能够减少数据验证时间消耗. 这些研究逐步完善供给方与依赖方数据同步环节. 但依赖方与需求侧的数据传输研究目前被关注较少, 伴随着RPKI在全球进入部署应用阶段, 依赖方与需求侧的数据传输机制是RPKI能够发挥作用的关键要素.

1.2 RPKI体系架构

RPKI通过建立一整套公钥证书体系对INR (Internet Number Resource, 互联网码号资源)的所有权(分配)和使用权(路由起源通告)进行验证, CA (Certificate Authority, 证书颁发机构)在进行资源分配的过程中, 同时会签发一系列标识资源从属关系的认证证书并将该证书数据分发到路由处以供验证. 数据传输结构如图1所示, 证书数据存储于全球RPKI数据库, RP服务器会从全球RPKI数据库同步证书信息并验证, 将验证后的信息缓存于本地数据库中. 路由器通过RTR (RPKI To Router)^[9]协议获取RP数据库中的RPKI缓存数据, 并将该缓存数据用于验证路由起源通告是否合法.

1.3 RPKI大规模部署的体系要求

目前RPKI体系架构仅在部分ISP或研究机构进行小规模部署实验. 根据文献[10]结论, 在大规模部署的条件下, 需要满足以下要求:

1)负载均衡: 传输架构负载承受能力满足实际运行需要.

2)传输效率: 传输任务能在给定时间范围内到达指定地址.

3)可靠性: 传输架构能适用于复杂的网络环境.

但当前现有的RPKI缓存分发结构, 在大规模部署的情况下, 难以满足RPKI缓存分发的要求, 从以下四点进行分析:

1.3.1 负载均衡问题

RPKI缓存更新结构存在如下几个原因, 难以满足负载均衡的要求.

1) RP服务器的负载能力有限: 目前的缓存更新结构中, RPKI缓存由RP服务器直接向所有的路由器进行分发. 在实际部署过程中, RP服务器的负载能力有限. 一旦大量的路由器同时对RP服务器发起数据传输请求, 会给RP服务器带来巨大的负载压力, 有可能造成信息阻塞、RP服务器宕机等问题.

2)对全球RPKI数据库构成压力: 为了降低实际部署情况下RP服务器的负载压力, 需要在网络中大量部署RP服务器, 这会给全球RPKI数据库带来负载压力. 这种改进方案仅仅是将RP服务器的负载压力转移到全球RPKI数据库处, 同样不能满足运行稳定的要求.

1.3.2 非一致性和本地化控制问题

由于RP服务器直接从全球RPKI数据库获取证书数据, 其获取数据内容的方式和验证过程完全独立, 即不与其他RP服务器相关, 大规模部署RP服务器, 会导致同一区域内(例如一个ISP(Internet service provider, 互联网服务提供商))路由信息的冲突, 产生非一致性问题.

IETF在RFC 8416^[11]中, 考虑到ISP本地化信息控制的需求, 提出了SLURM (Simplified Local Internet Number Resource Management, 简化本地互联网码号资源管理). RP服务器会通过本地信任锚点获取SLURM文件来对RPKI缓存数据进行补充和修改, 以达到本地化信息控制的目的. 在这种情况下, 大量的部署RP服务器会增加管理上的难度和本地化控制信息传输的难度.

1.3.3 传输效率问题

在现有的RPKI缓存更新结构中, RP服务器与路由器之间的缓存更新通过RTR协议进行. RTR协议是专门为存储RPKI缓存的服务器与路由器之间进行数据传输设计的一种协议结构, 但RTR协议仅能通过路由器主动发起传输请求, 且不适用于复杂的网络架构. 因此既难以满足实际在实际运行过程中对RPKI缓存分发效率的要求也不能保证分发过程的稳定. 具体原因如下.

1)无法主动推送及时响应: 服务器不能主动向客户端进行数据传输, 只能依靠客户端周期性的从服务器处获取数据. 如果直接将RTR协议用于缓存分发, 会出现如图2所示的问题, 即当实际部署中出现多层分发结构时, 周期性的获取数据会导致最下层的路由器获取RPKI缓存数据花费的时间是中间多层服务器获取缓存数据的周期之和, 导致重要的RPKI缓存数据不能得到及时分发, 无法及时响应.

2)数据结构设计不合理: 在目前的RPKI缓存分发结构中, RPKI缓存通过RFC 6810规定的数据结构进行描述, 这是一种专为RTR协议设计的数据结构. 该数据结构中只能包含一条RPKI缓存更新数据, 影响传输效率, 并且该数据结构只能通过RTR协议进行解析和编写, 缺少可读性和通用性, 实际部署成本较大.

1.3.4 可靠性问题

IETF在RFC 6810中提到将RTR协议不适合用于复杂的拓扑结构, 因为RTR协议在复杂拓扑结构中容易出错, 例如: 不能保持无环路条件. 此外基于TCP协议的RTR协议, 在实际网络情况下不便于进行跨网段传输.

经过上述分析, 当前的RPKI缓存分发机制不能满足大规模部署时RPKI缓存分发的需求. 本文针对以上四种缺陷设计了一种基于HTTPS的缓存更新机制, 该机制能够解决这些缺陷, 满足大规模部署时RPKI缓存分发的需求.

2 基于HTTPS的RPKI缓存分发架构

本文针对实际部署中RPKI缓存数据分发的问题, 利用JSON化的RPKI验证缓存数据实现了一种基于HTTPS的缓存分发机制, 如图3所示. 在本文设计的机制中, RP服务器和路由器之间的RPKI缓存分发, 通过搭建多级VC服务器实现. 在ISP的重要管理节点即RP服务器的部署地点处, 搭建VC服务器. RP服务器和该VC服务器之间通过同一数据库共享RPKI缓存. 该VC服务器与其它VC服务器之间通过HTTPS协议构建安全传输信道进行RPKI缓存数据的分发. 此外在每个AS内均部署有相应的VC服务器. AS内的路由器通过RTR协议从VC服务器处获取RPKI缓存数据.

2.1 实际应用场景分析

上述设计是大规模部署中RPKI缓存分发的基本模型, 在实际应用场景中, 可以根据不同场景下的需求对分发结构进行进一步的优化或修改. 在实际生活场景中, 部分路由系统的搭建由互联网运营商完成. 由于互联网运营商的实际管理模式为层级化管理或扁平化管理. 经过探究, 本文提出两种不同应用场景中RPKI缓存分发架构的改进.

2.1.1 互联网运营商扁平化管理场景

在扁平化管理场景下, 基本模型虽然能满足管理架构的需求, 但是直接由单一VC服务器对其它所有管理范围内的VC服务器进行RPKI缓存数据的分发并处理其它VC服务器特殊情况下发来的请求, 会使得服务器负载压力过大. 因此本文在基于基本模型提出一种优化架构, 如图4所示.

通过搭建中间多级VC服务器, 将单一VC服务器对管理范围内其它VC服务器的传输优化为多VC服务器对其它VC服务器的传输. 这种新的架构能减少VC服务器的负载压力, 此外新的传输架构也能够更好的契合互联网运营商的扁平化管理.

2.1.2 互联网运营商层级化管理场景

在层级化管理的场景下, 由单一VC服务器进行对其它所有管理范围的VC服务器进行RPKI缓存数据分发的机制不能很好的契合互联网运营商的管理模式的需求. 因此可对这种场景下的RPKI缓存分发架构进行相应的修改. 在图5所示的架构中, 与层级化管理相对应的每一层VC服务器都可以接受其本地信任锚点的本地化控制信息文件, 并通过该文件对其子层级进行本地化信息控制. 经过修改后的传输架构与互联网运营商的层级化管理结构契合度更高, 也更易于使用层级化管理的互联网运营商进行本地化信息控制.

2.2 RPKI缓存分发设计

本文实现的传输架构能够解决实际部署中的负载均衡问题以及非一致性和本地化控制问题. 架构设计出于以下考量.

1)降低RP负载: 通过搭建VC服务器, 可以显著降低RP服务器的负载压力. AS内部的路由器通过其所在AS部署的VC服务器获取RPKI缓存数据. RP服务器只需将通过验证后的RPKI缓存数据传输到事先配置好的VC服务器处即可.

2)降低全球RPKI数据库压力: VC服务器仅通过其上级VC服务器或者RP服务器获取RPKI缓存数据, 并不需要访问全球RPKI数据库进行证书数据同步, 不会额外增加全球RPKI数据库的负载压力.

3)保证路由信息的一致性: 由VC服务器进行RPKI缓存的分发, 不需要大量部署RP服务器. 能够保证一定区域内路由信息的统一性.

4)适应本地化控制的需求: VC服务器从更高一级VC服务器或RP服务器中获取验证缓存数据, 保证了同一区域内的路由信息通过同一RP服务器进行管理和修改, 降低了管理难度, 也减少了本地化控制信息传输的难度.

5)降低RP服务器的功能复杂度: 通过在RP服务器处搭建VC服务器进行RPKI缓存分发, 降低RP服务器设计的复杂度. 将同步功能和分发功能分离, 具有更高的松耦合度和灵活度, 有效的降低了实际部署难度.

2.3 HTTPS分发设计

本文设计方案选用HTTPS协议作为VC服务器之间RPKI缓存分发的传输协议, 能够解决RTR协议的周期叠加问题和可靠性问题. RFC8484^[12]提出了一种基于HTTPS的DNS查询机制, 该文档提出, 可以使用HTTPS发送DNS查询, 并通过HTTP获取DNS响应. 本文设计方案参考了RFC 8484, 将该文档提出的场景视作是RPKI缓存数据分发的一种相近场景.

本方案采用HTTPS协议有以下原因:

1)允许主动推送, 适用于应急响应: HTTPS协议允许由客户端主动发起连接请求, 能够迅速分发SLURM文件进行本地化信息控制, 避免错误配置长时间影响本地.

2) HTTPS适用范围广, 能够适应复杂网络拓扑结构: HTTPS应用于几乎所有的操作系统, 适用范围广.

3) HTTPS协议是一种面向内容的应用层协议, 它简化了对数据格式的要求和协议兼容设计的细节问题, 可以传输任意的数据对象.

因此采用HTTPS协议, 既能够满足及时分发RPKI缓存的需要, 又能够适应实际部署中复杂的网络结构. 所以本文提出的设计方案采用HTTPS协议作为VC服务器之间分发RPKI缓存的传输协议.

2.4 通用的数据格式

本文基于RFC 8416中用来描述SLURM文件的JSON格式的数据结构, 参考了RFC 8427^[13](该文档中使用JSON格式对DNS查询和响应进行了描述). 使用JSON用以描述RPKI缓存更新, 能够解决RTR协议规定的数据结构在实际部署中只能传输单条数据和缺少通用性的问题.

RFC8416中为描述SLURM文件制定了一种JSON格式的数据结构. 在实际分发过程中, 通过该结构来描述RPKI缓存更新的内容, 可以简化与SLURM文件的交互接口. 不需要提供专门的解析和重构模块,. 同时该数据结构可应用于增量更新, 增量更新的方式可以降低全量更新所消耗的资源, 提高分发效率, 能够满足实际运行的需要.

因此, 本文提出的设计方案采用RFC 8416中规定的JSON格式的数据结构来描述VC服务器之间分发的RPKI缓存.

3 详细设计 3.1 数据结构完整设计

考虑到网络传输的复杂性, 以及在实际场景中, ISP对VC服务器数据库中RPKI缓存数据的管理控制需求, 本方案在RPKI缓存更新的基础上添加控制信息, 将RPKI缓存与控制信息封装为一个完整的数据包. 控制信息和JSON格式的RPKI缓存数据完全解耦, 控制信息可用JSON和XML等结构化语言进行描述, JSON和XML数据包结构的具体设计如下所示.

　JSON格式如下:

{

　"head": {

　　"operate": "new",

　　"time": "2019-02/22/19 15:31:24",

　　　"newversion": "2",

　　"toversion": "2",

　　"sha1":"**********************",

　　"as": "1"

　},

　"data": {

　　"slurmVersion": 1,

　　"validationOutputFilters": {

　　"prefixFilters": [

　　　{

　　　　"prefix": "1.10.10.0/24",

　　　　"comment": "test prefix filters"

　　　}

　　]

　},

　"locallyAddedAssertions": {

　"prefixAssertions": [

　　{

　　"asn": 199998,

　　"prefix": "19.99.98.0/24",

　　"comment": "test assertions"

　　　}

　　]

　　}

　}

}

XML格式如下:

<?xml version="1.0" encoding="utf-8"?>

<test>

　　<head>

　　　　<operate>new</operate>

　　　　<time>2019-02/22/19 15:31:24</time>

　　　　<newversion>2</newversion>

　　　　<toversion>2</toversion>

　　　　<sha1>**********************</sha1>

　　　　<as>1</as>

　　</head>

　　<data>{

　　　　"slurmVersion": 1,

　　　　　　　　"validationOutputFilters": {

　　　　"prefixFilters": [

　　　　　{

　　　　　"prefix": "1.10.10.0/24",

　　　　　"comment": "test prefix filters"

　　　　　}

　　　　]

　　　},

　　　"locallyAddedAssertions": {

　　　"prefixAssertions": [

　　　{

　　　　"asn": 199998,

　　　　"prefix": "19.99.98.0/24",

　　　　"comment": "test assertions"

　　　}

　　]

　}</data>

</test>

在上述所示的数据包结构中, 数据包由头部(header)和数据(data)两部分构成. 其中头部字段含义如表1所示.

Operate字段包括new和back两个方式, new表示直接在VC服务器当前状态的数据库进行RPKI缓存更新, back表示需要VC服务器回退到之前版本的数据库.

As字段用以实现面向不同的AS的本地化信息控制视图, 管理者可通过修改as字段, 构建针对不同AS的本地化信息控制视图.

3.2 VC服务器

在本文的设计方案中, 共有3个实体, RP服务器, VC服务器和路由器, 由于RP服务器与路由器的设计在工业上已有实现, 故本文设计方案仅讨论分发架构中VC服务器的设计.

3.2.1 VC服务器功能模块

为了能够安全高效的进行RPKI缓存分发, 结合第2节中的设计思路, VC服务器应具有五种功能模块. (1)数据包构建模块: 该模块用于将RPKI缓存描述为如2.3所述格式, 并通过添加头部控制信息, 构建如3.1所述的数据包; (2)传输模块: 根据头部控制信息中的as字段将RPKI 缓存通过HTTPS协议分发到对应as区域中的VC服务器, 并通过多线程实现一次性多目标分发; (3)数据解析模块: 该模块用于解析收到的RPKI缓存数据包, 通过头部控制信息对RPKI缓存进行相应的处理; (4)重传模块: 当VC服务器收到不完整数据包或者发现有数据包遗漏时, 该模块会向其上级VC服务器请求重新获取RPKI缓存更新, 并提供相应的控制信息. 当VC服务器接收到下级VC服务器的重发请求时, 将根据其提供的控制信息, 调用数据包构建模块构建数据包, 并通过传输模块进行信息的传输. 如图6所示.

3.2.2 安全保护与可靠性

由于HTTPS的安全加密通道只能够保证传输过程中的数据安全. 在本文的设计方案中还建立了IP访问控制和数据完整性检查两种机制进行安全性保护, 并通过重传机制增强分发架构的可靠性.

1) IP访问控制

VC服务器在接受数据包之前, 首先会对传输数据的IP进行检查, 如果该IP不合法, VC服务器会直接抛弃该数据包, 不对其中的数据进行解析. 该机制可以保证VC服务器接受的RPKI缓存数据的来源是可靠的.

2)数据完整性检查

VC服务器在进行数据包解析之前, 首先会根据sha1字段中的数据对数据包进行完整性校验, 如果校验结果不相符, 则抛弃该数据包, 并通过重传请求模块向上级VC服务器申请数据包的重传.

3)重传机制

当数据包未能通过数据完整性检测或者数据解析过程中发现newversion字段与数据库中的最新版本相差大于1, VC服务器就会启用重传机制, 向上级VC服务器发出请求重新获取数据包.

4 实验与分析 4.1 RPKI缓存分发实验

RPKI缓存分发流程如图7所示, VC服务器会根据需要分发的RPKI缓存更新, 利用3.1所述数据结构构建分发数据包, 通过HTTPS协议将数据包分发到指定AS处的VC服务器. VC服务器会对数据包进行检测, 如果验证失败则触发重传请求, 请求重传RPKI数据包. 之后, 根据数据包进行相应的处理和更新.

4.1.1 RPKI缓存分发实验设计与结果分析

实验中使用五台物理机模拟传输架构进行实验, 将五台物理机分别标号为1–5, 其中1号机7999端口作为RP服务器, 8000端口作为VC服务器, 2–5号机依次作为不同层级的VC服务器.

实验使用JSON格式的数据包进行传输测试. 通过输出时间戳(毫秒精度)计算发起连接到通信完成之间的时间差, 从而得到实际过程中的时间效率. 本实验通过3个端口(8000–8002)得到每个层级分发用时的平均值(同时测试多线程分发)并计算总分发用时, 如图8所示.

图中的X轴表示分发结构中VC服务器的传输层数, Y轴表示总分发用时平均值(单位: ms), 实际测量得到, 5层分发结构仅用时26 010.8 ms(26.0108 s). 在实际部署场景中, 该架构能够迅速稳定的分发RPKI缓存, 可以满足实际运行的需要.

本文还对核心模块进行单独测试, 以下给出运行结果.

4.1.2 数据包构建模块

数据包构建模块通过用户输入或者根据重传请求构建数据包, 以JSON格式为例.

运行结果如图9所示.

4.1.3 传输模块

传输模块根据数据包头部AS字段获取目标AS的IP地址, 并通过多线程的方式分发RPKI缓存, 服务器端运行结果如图10所示.

4.1.4 数据处理模块

数据处理模块功能主要分为以下两部分:

1) IP访问控制, 完整性检测与版本控制

2)数据处理与储存

运行结果如图11所示.

4.2 性能测试

为了准确评估本方案的实际运行效果, 还设计了对比试验. 第一组为使用RTR协议进行RPKI缓存的分发. 第二组为使用HTTPS协议进行RPKI缓存的分发. 由于架构和数据处理操作相同, 本实验只对RTR协议和HTTPS协议的传输时间进行测试(不计算数据处理用时), 本实验根据RTR协议逐条传输的特点, 测试在五种不同数目的RPKI更新缓存数据(分别为10条, 20条, 50条, 100条, 200条)的情况下, RTR协议与HTTPS协议的传输时间对比. 实验结果如图12所示.

从图11可以看出, 当RPKI缓存更新数较少的时候, RTR协议传输效率比HTTPS协议高, 但是随着缓存更新数的增加, RTR协议传输时间也显著增加, 而HTTPS协议并无明显变化. 在RPKI缓存更新数达到200时, RTR协议用时为HTTPS协议的6.28倍. 因此在实际部署环境中, 使用HTTPS协议可以使得传输效率更加稳定.

此外, 文献[9]提到在RTR协议中客户端每间隔一小时通过服务器端获取一次数据. 在多层分发架构中, 客户端获取数据的周期叠加会使得分发时间长达数小时. 而本文提出的基于HTTPS协议的分发架构能够使得分发时间不会受到周期叠加的影响, 可以高效分发RPKI缓存.

5 结束语

随着互联网时代的进一步发展, RPKI的部署势在必行, 也获得了国内外许多组织的大力推行. 但是在实际部署过程中还有许多问题需要进行研究. 在这种背景下, 本文利用JSON化的RPKI验证缓存数据实现了一种基于HTTPS的缓存更新机制. 本文首先说明了现有RPKI架构的难以应用于实际部署的缺陷, 并给出了本方案的设计考量, 然后给出了设计的完整内容和具体细节. 在此基础上本文用python对该设计进行了实现并与RTR协议进行对比.

RPKI作为路由安全领域的热点话题, 既是为互联网运行保驾护航的重要举措, 也是互联网进一步发展的基石. 因此如何将RPKI更好的部署在实际场景中也是一个重要的探索方向和研究内容.