知识库 / RPKI 资源公钥基础设施：BGP 路由安全的密码学基石

RPKI 资源公钥基础设施：BGP 路由安全的密码学基石

协议详解 · 2026-10-11

引言：BGP 的信任危机

BGP（边界网关协议）是互联网骨干网络的"路由器语言"，负责在不同自治系统（AS）之间交换路由信息。然而，BGP 在设计时假设所有参与者都是诚实的，导致了一个致命缺陷：任何人都可以声明自己拥有任意 IP 地址段。

现实中的攻击案例触目惊心：

  • 2008 年巴基斯坦电信劫持 YouTube 流量，导致全球用户无法访问
  • 2012 年伊朗 BT 宣布拥有 Google 的所有 IP 前缀，Google 流量被截获两周
  • 2018 年委内瑞拉 BGP 泄漏事件，攻击者篡改 DNS 记录并拦截用户流量
这些事件暴露了一个根本问题：BGP 路由声明缺少加密验证机制。RPKI（Resource Public Key Infrastructure，资源公钥基础设施）正是为了解决这个问题而生。

RPKI 的核心设计思想

RPKI 借鉴了传统 PKI 的思路，但有一个关键差异：证书不绑定身份，而是绑定资源。

在传统 PKI 中，X.509 证书证明"这个人/这个服务器拥有这个域名"。而在 RPKI 中，资源证书证明"这个组织持有这批 IP 地址或 AS 编号"。

三层信任模型

RPKI 的信任锚点就是 5 个 RIR 的根证书。与 TLS 的数百个根证书不同，RPKI 只有 5 个信任锚点，这是有意为之的设计简化。

RFC 6480-6488 标准体系

RPKI 不是一个单一协议，而是一组相互关联的 RFC：

RFC名称作用
RFC 6480RPKI 架构定义整体架构、组件关系
RFC 6481仓库结构定义证书仓库的文件结构和同步机制
RFC 6482ROA 格式定义路由源授权的结构和语义
RFC 6483路由验证定义 BGP 路由来源验证的逻辑
RFC 6484证书策略定义 RPKI PKI 的证书政策
RFC 6485GRXP 协议定义注册机构与 RIR 之间的协议
RFC 6486Manifest定义仓库完整性验证机制
RFC 6487资源证书定义 X.509 资源证书的扩展格式
RFC 6488签名对象定义 CMS 包装的签名对象格式
RFC 6489密钥轮换定义 CA 密钥轮换程序
RFC 6490信任锚定义信任锚发布机制
RFC 6491-6493GRXP 扩展补充 GRXP 协议的细节
这些 RFC 由 IETF 的 SIDR（Secure Inter-Domain Routing）工作组制定，2012 年 2 月统一发布。

资源证书：IP 资源的身份凭证

证书结构

RPKI 使用修改版的 X.509 证书，核心扩展在 RFC 3779（IP 地址和 AS 标识符扩展）中定义。

资源证书包含两个关键扩展：

  • IP Address Delegation 扩展：声明该实体持有的 IP 地址范围
  • AS Identifier 扩展：声明该实体管理的 AS 编号
ASN1
IPAddressFamily ::= SEQUENCE {
    addressFamily   (IPv4 | IPv6),
    ipAddrBlocks    SEQUENCE OF IPAddressAssignments
}

IPAddressAssignments ::= SEQUENCE {
    address         IPAddressOrPrefix,
    length          INTEGER
}

示例：一个典型的资源证书

假设 ABC ISP 从 RIPE NCC 获得了 192.0.2.0/24 和 AS65001：

CODE
Subject: CN=ABC ISP
IP Address Delegation:
  IPv4: 192.0.2.0/24 (max prefix length: /24)
AS Identifier: AS65001
Validity: 2024-01-01 ~ 2026-12-31
Signature: RIPE NCC's CA key

这个证书本身不授予路由权，只是证明"ABC ISP 持有这个地址段"。要实际授权路由，还需要签发 ROA。

ROA：路由授权的核心对象

ROA 的 ASN.1 结构

ROA（Route Origin Authorization，路由源授权）是 RPKI 的核心签名对象，定义在 RFC 6482 中。

ROA 字段解读

字段含义示例值
asID被授权的 AS 编号65001
address允许宣告的 IP 前缀192.0.2.0/24
maxLength最长前缀掩码（可选）26

maxLength 语义

maxLength 是关键参数，它允许父级授权子级宣告更具体的路由：

CODE
父级 ROA: AS65001, 192.0.2.0/24, maxLength=26
允许宣告:
  - 192.0.2.0/24 (精确匹配)
  - 192.0.2.0/25 (更具体)
  - 192.0.2.128/25 (更具体)
不允许宣告:
  - 192.0.2.0/26 (超过 maxLength)
  - 192.0.3.0/24 (不在授权范围内)

如果没有 maxLength，则只允许宣告精确匹配的前缀。

ROA 的签名格式

ROA 使用 CMS（Cryptographic Message Syntax）包装，定义在 RFC 6488 中。内容类型 OID 为：

CODE
id-ct-routeOriginAuthz OBJECT IDENTIFIER ::= { 1 2 840 113549 1 9 16 1 24 }

实际 ROA 文件包含：

  • CMS 签名数据结构
  • 内嵌的 ROA 内容（ASN.1 DER 编码）
  • 签发者的 EE 证书
  • 上级 CA 的证书链

仓库系统：分布式对象存储

仓库层级结构

RPKI 仓库是一个分层的分布式文件系统，每个 CA 节点有一个仓库发布点：

CODE
https://rpki.ripe.net/
├── manifests/
│   └── a1b2c3d4e5.mft      # CA 的清单文件
├── certificates/
│   ├── xyz789.cer           # 子级 CA 证书
│   └── def456.cer           # EE 证书
├── crls/
│   └── a1b2c3d4e5.crl       # CRL
└── roas/
    ├── route-123.roa         # ROA 文件
    └── route-456.roa         # ROA 文件

对象命名规范

扩展名对象类型RFC 引用
.cer证书RFC 6487
.crl吊销列表RFC 5280
.mft清单文件RFC 6486
.roa路由授权RFC 6482
文件名使用对象的 SHA-256 哈希值，确保全局唯一性。

Manifest：仓库完整性保障

Manifest 是 CA 仓库的"目录清单"，包含所有发布对象的哈希值：

ASN1
ManifestData ::= SEQUENCE {
    certificateURL  IA5String,
    thisUpdate      Time,
    nextUpdate      Time,
    repoFileHashes  SEQUENCE OF RepoFileHash
}

RepoFileHash ::= SEQUENCE {
    fileName    IA5String,
    hashValue   BIT STRING
}

每个 CA 必须在其仓库中维护一个有效的 Manifest。RPKI 消费者通过验证 Manifest 的完整性来确保仓库内容未被篡改。

路由验证：RTR 协议

验证流程

当 BGP 路由器收到路由更新时，验证流程如下：

RTR 协议：缓存器与路由器的通信

路由器不直接访问 RPKI 仓库，而是通过 RTR（Router-to-Router）协议从缓存器获取验证结果。RTR 定义在 RFC 6483 中：

CODE
RPKI 消费者 ──RTR──▶ 缓存器 ──rsync──▶ RPKI 仓库
    │                           │
    ▼                           ▼
 BGP 路由器              定期同步

RTR 协议的消息格式：

CODE
Message Type    Length    Payload
─────────────────────────────────
INIT          4 bytes     Serial Number
SOA           4 bytes     Serial, Refresh, Retry, Expire, Minimum
RESPONSE      variable  ROA objects or NULL
END_OF_RECORD 0 bytes
NOTIFY        4 bytes     Error Code

验证状态

BGP 路由有三种验证状态：

状态含义处理
Valid存在匹配的 ROA接受路由
Invalid存在 ROA 但 AS 或前缀不匹配拒绝路由
Not Found没有匹配的 ROA默认处理（依策略）

国密视角：RPKI 与中国的部署现状

中国的 RPKI 实践

中国作为互联网大国，积极参与 RPKI 部署：

  • CNNIC（中国互联网络信息中心） 担任 APNIC 下属的注册机构，为国内 ISP 签发资源证书
  • CHINANET、CN2 等骨干网已部署 RPKI 验证功能
  • 2023 年，工信部推动"国家互联网路由资源管理系统"建设，部分借鉴 RPKI 理念

国密适配挑战

RPKI 当前基于 RSA 和 ECDSA，而国密标准使用 SM2。如果要构建国密版 RPKI，需要考虑：

  • 证书扩展：RFC 3779 的 IP Address Delegation 扩展需要适配 SM2 证书格式
  • 签名算法：CMS 包装需要支持 SM2 签名（参考 GM/T 0034-2014）
  • 仓库协议：rsync 协议本身无关算法，但对象格式需要调整
目前国密环境下，运营商更多采用"双轨制"——国际业务使用标准 RPKI，国内监管要求使用国密算法。

部署现状与挑战

全球部署数据

截至 2024 年：

  • 全球 ROA 数量：约 300 万+
  • 部署 RPKI 验证的运营商：超过 500 家
  • 中国 ROA 数量：约 50 万+（CNNIC 统计数据）

主要挑战

  • 部署门槛：需要理解 BGP、PKI、ASN.1 等多个技术领域
  • 父子协调：父级 RIR 必须先部署，子级 ISP 才能使用
  • 错误配置：错误的 maxLength 设置会导致路由被标记为 Invalid
  • 安全性局限：RPKI 只能验证路由来源，不能防止路径污染（BGP Path Validation 仍在研究中）

结语

RPKI 是互联网基础设施安全的重要里程碑。它用密码学的严格性填补了 BGP 的信任空白，将"谁可以宣告这个前缀"从一个道德问题变成了一个数学问题。

对于网络安全从业者而言，理解 RPKI 不仅是掌握一项技术，更是理解互联网治理的基础设施逻辑。随着 BGP 劫持事件的频发，RPKI 的部署只会越来越广泛。

参考资料

← 返回知识库