BGP作为互联网域间路由协议，从诞生之初就建立在自治系统之间相互信任的基础上。一台路由器收到邻居发来的路由更新时，默认会接受其中的前缀和AS路径，并不会去核实该邻居是否真的拥有这个IP前缀。这个设计让全球路由表可以在去中心化环境中快速传播，但也给前缀劫持和路由泄露留下了天然缺口。

当某个AS广播了不属于自己的前缀，例如错误配置或恶意宣告其他机构的地址块，流量就可能被重定向、截获或丢弃。传统的Internet路由注册库IRR虽然记录了部分分配关系，但数据质量参差不齐，且缺乏强制校验机制。RPKI的出现正是为了给BGP增加一层可验证的授权来源，让路由起源不再依赖口头信任。

一、BGP的安全盲区：为什么前缀劫持如此容易

BGP协议在设计时没有内建的路由源验证机制，它假设所有参与方都会遵守规则。当一个自治系统向邻居通告某条前缀时，邻居路由器只会根据本地策略和路径属性决定是否接受，而无法判断这条前缀是否真的分配给该AS。这种去中心化信任模型支撑了互联网规模的快速扩展，却也导致任何人都可以宣告任意前缀，只要上游网络不加以过滤，错误路由就会扩散到全球。

前缀劫持大致分为两类：一类是误配置造成的路由泄露，比如把本应只向内部传播的更具体前缀误发到上游，导致流量被意外牵引；另一类是恶意劫持，攻击者通过宣告更具体的前缀或伪装合法起源AS来截取目标流量。无论哪种情况，受害者都会面临服务中断、数据被监听或流量路径异常的问题。在缺乏统一授权校验的环境下，发现和恢复往往需要人工协调，耗时较长。

传统防护手段主要依靠手工维护前缀列表、AS路径过滤或IRR数据比对。IRR虽然能够提供一些分配信息，但它的数据录入并不强制更新，很多记录已经过时或与实际情况不符。手工前缀列表也无法覆盖动态变化的路由策略，一旦出现遗漏就仍然可能放行非法通告。RPKI的价值在于把这些分散的、不可靠的授权信息转变为一种可验证、可自动同步的标准数据源。

二、RPKI核心机制：ROA、依赖方与RTR

RPKI的全称是资源公钥基础设施，它利用数字证书把IP地址块和AS号之间的分配关系绑定起来。证书层次从IANA开始，逐级下发给地区互联网注册机构RIR，再由RIR分发给地址持有者。地址持有者可以签署一种叫做ROA（Route Origin Authorization，路由源授权）的对象，声明某个AS被授权通告某个IP前缀。ROA中通常包含前缀、最大前缀长度和起源AS号三个关键信息。

Prefix: 192.0.2.0/24
Max Length: /24
Origin AS: 64500
Expires: 2027-01-01 00:00:00 UTC

这个ROA表示AS 64500可以通告192.0.2.0/24这条前缀，且最大长度不允许超过/24。如果有人在BGP中通告192.0.2.0/25，即使起源AS是64500，验证结果也会被视为invalid，因为更具体的子前缀没有被授权。这种限制能够有效阻止攻击者通过宣告更具体路由来劫持流量。

路由器不会直接去读取RIR的证书仓库，而是通过RPKI依赖方软件来汇总全球ROA数据。常见的依赖方软件包括Routinator、OctoRPKI、rpki-client等，它们周期性地从各RIR的公开仓库拉取ROA和证书，验证签名后生成一份可查询的路由源授权数据集。路由器使用RTR协议（RPKI to Router Protocol）连接到依赖方服务器，通常使用TCP端口323，以增量方式获取这些验证数据。

当路由器收到一条BGP路由时，会把路由的前缀和起源AS与ROA数据集进行比对，得到三种验证状态：valid表示路由前缀和起源AS均与ROA匹配；invalid表示存在覆盖该前缀的ROA，但起源AS不匹配，或者前缀长度超过了maxLength；not found表示当前RPKI数据集中没有覆盖该前缀的ROA记录。网络管理员可以基于这三种状态制定不同的路由策略。

三、路由器启用RPKI验证：配置与过滤策略

在路由器上启用RPKI验证之前，需要先部署一台或多台RPKI缓存服务器。缓存服务器可以是独立运行的软件实例，也可以使用云服务商提供的验证端点。路由器作为RTR客户端，通过TCP连接定期从缓存服务器拉取ROA数据。连接断开时，路由器通常会继续使用最后一次成功获取的数据，避免验证状态突然全部消失导致路由策略震荡。

下面是一个Cisco IOS XE风格的基础配置示例，展示如何连接RPKI缓存服务器，并使用route-map对不同验证状态的路由设置不同的本地优先级。

router bgp 65001
 bgp rpki server tcp 192.0.2.1 port 323 refresh 600
 address-family ipv4 unicast
  neighbor 203.0.113.2 route-map RPKI-POLICY in
 exit-address-family
!
route-map RPKI-POLICY permit 10
 match rpki invalid
 set local-preference 50
!
route-map RPKI-POLICY permit 20
 match rpki not-found
 set local-preference 100
!
route-map RPKI-POLICY permit 30
 match rpki valid
 set local-preference 200

上述配置中，bgp rpki server tcp 192.0.2.1 port 323 refresh 600指定了缓存服务器地址和刷新周期。route-map首先匹配invalid状态的路由，将其本地优先级降为50；not found状态保持默认的100；valid状态提升到200。这样路由器在选择最佳路径时会更倾向于RPKI验证通过的路由。

实际部署时，很多网络会选择直接拒绝invalid路由，而不是仅仅降低优先级。直接拒绝能够更彻底地阻断非法通告，但前提是自己的ROA数据足够准确，否则可能因为自己或上游的ROA未及时更新而误伤正常路由。对于not found状态，如果全部拒绝，可能切断大量尚未创建ROA的合法前缀，因此多数初期部署只对invalid采取动作，并持续观察验证结果。

Juniper设备同样支持RPKI验证，配置思路类似，需要先定义验证服务器会话，再在策略中引用验证状态。一个简化示例如下：

set routing-options validation group RPKI-SERVER session 192.0.2.1 local-address 203.0.113.1 port 323
set policy-options policy-statement RPKI-VALIDATION term invalid from rpki-validation-state invalid
set policy-options policy-statement RPKI-VALIDATION term invalid then reject
set policy-options policy-statement RPKI-VALIDATION term valid from rpki-validation-state valid
set policy-options policy-statement RPKI-VALIDATION term valid then accept
set protocols bgp group ebgp import RPKI-VALIDATION

无论使用哪种设备，策略制定原则是一样的：先确保缓存服务器数据可靠，再逐步从观察模式切换到实际过滤，并配合监控告警及时处理验证状态异常。

四、RPKI的局限与部署价值

RPKI解决的只是路由起源验证问题，它告诉路由器某个AS是否有权通告某个前缀，但无法验证AS路径中每一个AS是否真的参与了转发。攻击者仍然可以在AS路径中插入虚假的AS号，或者利用路径中间节点进行流量劫持。要防御路径级别的伪造，还需要结合BGPsec或ASPA等更进一步的机制，这些技术目前仍处于较早期的部署阶段。

另一个实际限制是ROA的覆盖范围。只有在地址持有者主动创建ROA之后，RPKI才能对相关前缀给出valid或invalid判断。如果某个前缀完全没有ROA记录，验证状态就是not found，RPKI无法提供直接的授权信息。此外，ROA中maxLength设置过大也会削弱保护效果，因为允许更具体的子前缀被宣告会增加劫持面。

尽管存在局限，RPKI仍然是目前拦截BGP前缀劫持最有效的自动化手段之一。它把原本依赖人工整理和信任的授权信息，转变为可由路由器实时验证的数据。对网络运营方来说，创建ROA是第一步，它保护自己的地址块不被他人轻易劫持；随后启用RPKI验证则是保护自己的网络，不让非法通告进入路由表。随着创建ROA的地址块数量持续增长，RPKI对整体路由安全的改善会越来越明显。

运维实践中，建议先从内部路由验证和监控开始，观察实际收到的invalid路由数量以及来源，确认没有因为自身ROA缺失造成误判后，再逐步过渡到拒绝invalid。同时要保证RPKI缓存服务器的高可用，避免单点故障导致验证数据不可用。这样既能获得实时验证带来的安全收益，又不会对网络稳定性造成额外风险。