01 · RPKI v0能力回顾：ROA与ROV做了什么
1.1 ROA与ROV的机制要点
ROA（Route Origin Authorization，RFC 6482）是IP地址资源持有者签发的RPKI签名对象，声明"前缀P可由自治系统AS_X宣告"。路由器或验证器对BGP路由执行ROV（Route Origin Validation，RFC 6811）时，只检查一个事实：宣告的起源AS是否在任一覆盖该前缀的ROA中被授权。判定结果分三态：
| 判定 | 含义 | 策略含义（常见做法） |
|---|---|---|
| Valid | 存在覆盖该前缀与起源AS的ROA | 正常采纳（策略优先级可视运营需求调整） |
| Invalid | 存在覆盖该前缀的ROA，但起源AS未被授权 | 丢弃或降格（拒收为业界对劫持的标准处置） |
| NotFound | 不存在覆盖该前缀的ROA | 按未保护处理（多数网络保持采纳）——这是ROV覆盖率之外的主要残余风险 |
验证所需的RPKI数据经RTR协议（RFC 8210）从验证器推送到路由器。这一体系已规模化运行：RIPE区域IPv4地址空间ROA覆盖率约75%（2025年底，RIPE NCC年度报告），多个国家级与运营商级网络在边缘启用"Invalid即丢弃"。
1.2 ROV的结构性强约束
ROV的有效性建立在两个前提上：其一，前缀已签发ROA——未签发ROA的前缀（全球仍有相当比例）处于NotFound盲区；其二，攻击面在起源层。只要攻击者不碰起源（起源AS正确、ROA验证通过），而是操纵路由的传播路径，ROV完全无感。这决定了v0体系必须向路径验证演进。
关键判断：路径验证不是对ROV的替代，而是其"后半场"。一次完整的非法路由事件往往同时包含起源与路径两个维度（如2024年Cloudflare 1.1.1.1事件中的"劫持＋泄露"叠加）。只有ROV与路径验证联合部署，才能形成端到端的宣告合法性判定。
02 · 路径层威胁模型细化
2.1 路由泄露的类型学（RFC 7908）
RFC 7908将路由泄露按成因与传播方向系统分类，核心类型包括：
- 类型1：从客户学到的路由传播给另一客户（违反"客户路由不外泄给其他客户"）；
- 类型2：从客户学到的路由传播给对等体（peer）；
- 类型3：从客户学到的路由传播给提供商（provider）——"上坡转发"，使流量绕经非最优路径；
- 类型4：从对等体学到的路由传播给另一对等体；
- 类型5：从对等体学到的路由传播给提供商；
- 类型6：将带有NO_EXPORT等限制属性的路由继续传播。
泄露的共同特征是传播方向违反了AS间商业关系，而起源本身完全合法——这正是ROV的盲区，也是ASPA验证算法（up-ramp/down-ramp模型）直接针对的对象。
2.2 AS_PATH操纵手法（防御者视角的概念性描述）
- 路径短化：从AS_PATH中删除若干ASN，使路径在基于AS_PATH长度的选路中占优，吸引流量经过攻击者。
- 路径嫁接：把两段不相干的真实路径拼接（伪造中间段），使路径"看起来"经过可信骨干。
- prepending滥用：合法技术（重复自身ASN以降低被选概率）与路径操纵在数据层面难以区分，验证算法必须显式容忍——aspa-verification草案规定验证时忽略相邻重复ASN。
- AS_SET使用：聚合路由中的AS_SET使路径语义模糊，处理规则见RFC 6472的建议与草案中的专门约定。
2.3 威胁模型的资产与攻击者假设
本课题的资产模型：BGP宣告的路径真实性（流量按发件方意图、符合商业拓扑的方式流动）。攻击者能力假设：控制至少一个AS的BGP宣告能力（可独立宣告或作为中间转发者），掌握RPKI体系公开知识，但无法伪造他人AS签发的RPKI对象（私钥安全假设与RPKI整体一致）。攻击者目标：将流量牵引至己方或指定位置（窃听、黑洞、钓鱼重定向），或绕过基于路径的安全过滤。
03 · 路线A：BGPsec全路径签名（RFC 8205—8209）
3.1 设计思想
BGPsec（RFC 8205，2017年9月发布）为BGP UPDATE添加新的路径属性BGPsec_PATH：每个转发AS在收到BGPsec路由后，验证前序签名的有效性，再将自己的AS号与下一跳信息加入签名目标并重新签名，形成逐跳累积的签名链。配套文档：RFC 8206（设计选择与权衡）、RFC 8207（运维考虑）、RFC 8208（安全考虑）、RFC 8209（BGPsec路由器证书规范）。
3.2 部署困境的结构性分析
| 困境维度 | 具体表现 |
|---|---|
| 性能成本 | 逐跳签名/验签消耗CPU；签名长度随路径增长（典型路径下每UPDATE附加数百字节），对高更新频率会话与路由表存储造成压力 |
| 密钥与证书运营 | 每台参与路由器需BGPsec路由器证书与私钥管理，密钥轮换、证书吊销、跨厂商证书分发均为重运营负担 |
| 信任模型的"逐跳"要求 | 路径上任何一个AS未部署BGPsec，签名链即断裂——与BGP的任意拓扑连通性根本矛盾 |
| 缺乏部署激励 | 部署方承担全部成本，收益（路径真实性）却依赖全网；早期采用者无法获得与其成本相称的防护收益 |
| 与现有机制的落差 | 当ROV已能拦截多数起源劫持时，运营商为边际增益投入BGPsec全栈改造的动力进一步下降 |
结论：BGPsec提供了密码学意义上的强保证，但其部署模式（逐跳逐设备参与）与互联网的经济和运营现实冲突。截至2026年，除科研试验床（如美国NIST/NTIA支持的BGPsec测试环境）、厂商试验与个别实验性部署外，BGPsec在全球骨干网中几乎没有生产应用。BGPsec路由器证书的分发体系从未达到支撑全球部署的规模，个别试验性支持并未改变全局停滞的现实。BGPsec的价值更多体现为"为后续轻量方案界定安全上限"的参照系。
04 · 路线B：ASPA授权验证的设计哲学
4.1 核心思路：验证"关系"而非签名"路径"
ASPA放弃了"对路径本身签名"，改为让每个AS对自己的商业关系声明签名：AS_X签发ASPA对象，声明"AS_P1、AS_P2……是我的合法上游提供商"。验证器拿到一条AS_PATH后，不需要任何路径上的签名，只需检查：路径中每一跳的"提供商—客户"关系，是否都有来自客户一侧的密码学授权。这带来根本性的成本重分配：
- 签名成本O(1)：每个AS只为自己的一份（或少量）关系声明签名，与路径长度无关；
- 验证成本O(路径长度)：纯查表比对，无密码学运算，可在普通RPKI验证器上全量执行；
- 部署模式与ROA完全一致：复用RIR托管服务、EE证书、Manifest/CRL撤销体系与RTR分发通道，运营者无需新增密钥管理体系。
4.2 三段式路径语义（up-ramp / peak / down-ramp）
合法的客户—提供商拓扑是"有向无环"的：流量从起源向上流向顶层（上坡），再向下流向接收者（下坡）。aspa-verification草案将AS_PATH解读为三段：上坡段（朝起源方向，每相邻两跳A←B须满足"B的ASPA授权A为提供商"）；顶点（peak）（路径最高层，通常是tier-1，其无上游——若签发provider-free ASPA则可被明确验证）；下坡段（朝接收方方向，每相邻两跳须满足"A的ASPA授权B为提供商"，即下坡方向看到的是授权的客户链）。三段之外若还存在违反方向的"第二上坡"，即判定为Invalid（泄露特征）。
4.3 安全保证的性质（与BGPsec对比）
ASPA提供的是关系一致性保证而非路径完整性保证：它能证明"这条路径中的每一段转接都有客户侧授权"，但不能证明"这条路径就是发件方通告的那一条"（路径可以被替换成另一条同样满足授权关系的路径，即"等效路径替换"攻击，见第7页）。BGPsec能抵抗等效路径替换，ASPA不能——这是ASPA用部署性换安全强度的明确边界。工程界的判断是：在泄露占路径事件绝大多数的现实威胁分布下，ASPA的性价比远高于BGPsec。
05 · 路线C：BGP角色与OTC属性（RFC 9234）
5.1 机制要点
RFC 9234（2022年5月发布）定义了两件套：BGP角色（BGP Role）与Only to Customer（OTC）属性。角色在BGP OPEN消息中按方向成对协商（RFC 9234定义五类角色：Provider、Peer、Customer、RS（route-server）、RS-Client），双方角色必须互补一致，否则会话建立失败。路由在宣告时被打上OTC属性，语义为"本路由只能向客户方向传播"；任何AS收到带有OTC的路由却来自客户或共享方向时，即可确定发生了泄露。
5.2 与ASPA的关系：轻量信号 vs 密码学授权
| 维度 | OTC / BGP Role（RFC 9234） | ASPA（SIDROPS草案） |
|---|---|---|
| 密码学强度 | 无——属性可被任意宣告者设置或移除，防御价值依赖"假设攻击者不配合" | 有——基于RPKI签名，攻击者无法伪造他人声明 |
| 部署成本 | 极低——纯BGP配置属性，无需PKI | 低——复用RPKI托管与分发体系 |
| 检测范围 | 在"打上OTC的AS的下游"检测泄露；无法约束未打OTC的路径段 | 覆盖全部有ASPA声明的段；无声明段为Unknown |
| 标准化状态 | 已发布RFC（2022） | 草案（2026年处WG Last Call） |
| 互补用法 | 实践观点：OTC可作过渡期的泄露信号与基线过滤输入；ASPA是终态的关系验证层。两者可叠加（如OTC提供早期告警、ASPA提供权威判定） | |
06 · 三路线综合对比矩阵
| 维度 | ROV（RPKI v0） | BGPsec（RFC 8205） | ASPA（RPKI v2） | OTC（RFC 9234） |
|---|---|---|---|---|
| 验证对象 | 起源AS | 完整AS路径（逐跳签名） | 路径中的提供商—客户授权关系 | 传播方向合规性（局部信号） |
| 签名主体 | 前缀持有者 | 路径上每个转发AS | 客户侧AS（声明其提供商） | 无（属性由宣告者设置） |
| 密码学强度 | 强（起源维度） | 最强（全路径） | 中（关系维度） | 弱（可被操纵） |
| 部署状态（2026） | 规模化（RIPE区域IPv4 ROA约75%） | 几乎无生产部署 | 极早期（全球约0.5% AS已签发） | 早期（部分厂商/IXP支持） |
| 主要盲区 | 路径操纵、NotFound前缀 | 签名链断点、运营成本 | 对等关系、未声明段（Unknown）、等效路径替换 | 属性操纵、未打OTC路径段 |
07 · 标准演进时间线
| 时间 | 事件 |
|---|---|
| 2000—2003 | S-BGP与soBGP路径安全方案提出，未获规模化采用 |
| 2012—2013 | RPKI核心标准族RFC 6480—6482发布（2012），起源验证具备工程基础；RFC 6810（RTR v0，2012）与RFC 6811（ROV，2013年1月）相继标准化 |
| 2016—2017 | RFC 7908定义泄露问题框架（2016）；BGPsec协议簇RFC 8205—8209发布（2017）；RTR协议RFC 8210发布（2017） |
| 2019—2020 | ASPA思路进入SIDR/SIDROPS工作组讨论，aspa-profile等草案开始长期迭代 |
| 2022 | 泄露治理的轻量路线标准化：RFC 9234（BGP角色＋OTC）发布；RIPE NCC在其RPKI试验环境提供ASPA API |
| 2023—2024 | 开源生态就绪（rpki-client、OpenBGPD、Routinator、Krill、RTRTR、StayRTR等支持ASPA）；RIPE NCC按草案v16更新试验环境；2024年底全球ASPA customer ASID仅87个 |
| 2025 | RIPE NCC于11月26日在RPKI Dashboard提供ASPA生产支持；customer ASID增至556个（RIPE Labs统计） |
| 2026 | ARIN于1月20日全面提供ASPA；APNIC于上半年上线；aspa-verification完成WGLC后于8月达成共识（Waiting for Write-Up），aspa-profile完成WGLC评审——两份草案趋近定稿但尚未分配RFC编号 |
本节参考来源（第2页）
以下均为真实可查的权威来源。
IETF RFC 6811《BGP Prefix Origin Validation》（2013年1月）：rfc-editor.org/rfc/rfc6811。
IETF RFC 8210《The Resource Public Key Infrastructure (RPKI) to Router Protocol》（2017年9月）：rfc-editor.org/rfc/rfc8210。
IETF RFC 7908《Problems with Problematic BGP Routes》（2016年6月，泄露类型学）：rfc-editor.org/rfc/rfc7908。
IETF RFC 8205—8209（BGPsec协议簇，2017年）：rfc-editor.org/rfc/rfc8205；RFC 9234（2022年5月）：rfc-editor.org/rfc/rfc9234。
RIPE NCC Annual Report 2025（ripe-855，ROA/ASPA覆盖率数据）：ripe.net/publications/docs。
APNIC Blog《RPKI's 2025 year in review》（2026年2月，ASPA约0.5% AS）：blog.apnic.net。
Kent S., Lynn C., Seo K.（BBN）《Secure Border Gateway Protocol (S-BGP)》，IEEE JSAC 2000；White R.（Cisco）《Securing BGP through Secure Origin BGP (soBGP)》，2003。两条早期路径安全路线。