摘要

  • Kotikalapudi Sriram 是 RFC 6472 与 RFC 9774 的共同作者，也是 RFC 8205 的共同编辑。三份 IETF 文件记录了一条连续但非个人独占的标准演进：从建议停止生成 AS_SET 和 AS_CONFED_SET，到用有序路径、签名与 RPKI 资源绑定表达 BGPsec 授权，再到默认禁止发送这些集合并对收到的相关路由执行 treat-as-withdraw。
  • 这条演进没有把标准文本等同于运行现实。聚合策略、四字节 ASN 能力、地址族与收发方向协商、ROA 和路由器证书、RPKI 缓存新鲜度、部分部署边界以及转发状态都需要分别核对；BGPsec 验证的是路由通告经过并获授权的 AS 序列，不保证数据包沿同一路径转发，也不证明任何具体部署已经取得量化成效。

从共同署名的标准记录出发

理解 Sriram 在这组文件中的技术轨迹，最可靠的起点不是职位、组织叙事或个人标签，而是文件本身的署名和规范范围。2011 年 12 月发布的 RFC 6472 由 Warren Kumari 与 K. Sriram 共同署名；2017 年 9 月发布的 RFC 8205 由 Matthew Lepinski 与 K. Sriram 共同编辑；2025 年 5 月发布的 RFC 9774 则列出 Warren Kumari、Kotikalapudi Sriram、Lilia Hannachi 与 Jeffrey Haas 四位共同作者。

这些身份足以证明 Sriram 持续参与了 AS 路径语义与路由安全标准化，却不支持把任一规范写成他的单人发明。RFC 是 IETF 共识文件，规范性结果属于完整作者或编辑协作、审查过程与共同体决策。文件也没有证明他亲自运营某张网络、控制某种实现、决定任何运营商的路由策略，或对一场具体事故和部署结果负责。

这种克制不是人物内容的缺失。相反，它让真正连续的技术问题变得清楚：当一条路由的来源和经过路径需要被验证时，控制面记录是否保留了足够明确的顺序、身份和授权关系；当新规则进入现实网络时，系统是否能区分已协商、未协商、已验证、未验证和无法验证，而不是用一个笼统的“安全”状态覆盖全部差异。

无序集合为何削弱路径含义

在传统 BGP 的 AS_PATH 中，AS_SET 是路由器聚合多个更具体路由时形成的无序自治系统集合。AS_CONFED_SET 采用相似形式，但记录本地联盟内相关成员 AS。它们可以保留“哪些 AS 曾出现在贡献路径中”的部分信息，却不保留这些 AS 的先后次序。

这种丢失并非纯粹的格式问题。路由聚合把多条更具体目的地的路由合并为一条较不具体的路由，聚合后需要回答的却仍是具体问题：谁是可被识别的起源 AS，哪条路径参与了形成该聚合，环路保护依赖什么信息，资源持有者应授权哪个 AS 发起该前缀，以及安全机制如何把声明与证书记录对齐。无序集合能够列出成员，却无法提供一条单义的顺序链。

RFC 6472 还指出，聚合可能丢失组成前缀的精确路径信息，由此影响流量工程。对安全机制而言，模糊的起源语义会让聚合前缀及其更具体前缀难以获得一致的来源认证。问题不在于集合本身“恶意”，而在于它保留的事实粒度不足以支撑后续需要明确起源和顺序的判断。

少见使用与复杂度之间的账

RFC 6472 所依据的历史路由数据分析认为，公共网络中的 AS_SET 聚合很少见，而且常见实例包括集合中只有一个 AS、出现保留 ASN 等不符合预期的情况。文件据此判断，聚合带来的路由表缩减非常有限，而协议设计、实现与安全机制需要承担额外复杂度。

这是一项明确带有时代和范围的证据。它说明 2011 年文件为何提出建议，却不能被外推成今天所有网络的实时测量，也不能证明每个曾出现 AS_SET 的网络都配置错误。可靠的使用方式，是把它理解为标准演进的决策基础：一项少见功能若持续模糊起源语义，并阻碍新的安全机制，其保留成本需要接受更严格的证明。

文件也承认 AS_SET 曾在少数聚合场景中承担环路保护作用。因此，弃用并不是一句“删除字段”就结束。若移除集合，运营者仍需保证聚合只覆盖适当的更具体前缀，处理对贡献 AS 的通告策略，并让数据面在只匹配聚合而不匹配任何更具体路由时有明确的丢弃行为。复杂度可以迁移，但不会凭标准措辞自动消失。

RFC 6472 先把责任放在发送侧

RFC 6472 的核心动作面向网络运营者：建议不要再生成包含 AS_SET 或 AS_CONFED_SET 的新通告；对于已经通告的相关路由，文件建议撤回聚合路由，并在不带这些集合的情况下重新通告组成前缀。它同时提醒，任何变更都应先理解完整影响。

这份文件刻意限制了接收侧结论。它观察到新安全技术或未来实现可能把相关路由视为不可行，运营者也可能提前过滤，但没有为收到此类路由时应采取何种动作给出统一建议。2011 年的边界因此很清楚：发送方应停止增加新集合，并规划对既有聚合的处理；接收方策略仍保留在本地判断中。

这种范围限制对运行连续性很重要。若把发送侧建议误读为接收侧强制丢弃，不同设备可能在没有共同规则的情况下突然改变可达性。反过来，若把“尚未规定接收动作”理解成可以无限期忽略，路径语义与安全机制之间的冲突又会持续存在。标准先明确最小方向，再为后续更强要求留下演进空间。

从建议推进到默认强制行为

RFC 9774 取代 RFC 6472，并把此前的最佳当前实践推进为 BGP 的标准要求。除非网络运营者为了过渡等目的明确配置例外，BGP speaker 不得发送在 AS_PATH 或 AS4_PATH 中包含 AS_SET 或 AS_CONFED_SET 的 UPDATE；收到这类 UPDATE 时，则必须按照 RFC 7606 使用 treat-as-withdraw 错误处理。

这一步同时改变了发送端和接收端。发送端从“建议不生成”变为默认禁止，接收端也从未统一规定变为可预测的处理。treat-as-withdraw 的重点是把受影响的路由当作撤回处理，而不是把一个不合规属性无条件扩展成整个 BGP 会话的失效。规则把错误影响尽量收束到相关路由，同时避免继续把模糊路径送入选路。

文件保留“明确配置例外”的过渡出口，说明标准知道现实网络不会在同一时刻完成切换。这个出口不是永久豁免的理由。若运营者使用它，至少需要知道例外适用于哪些邻居、地址族与路由，何时开始、何时结束，以及接收侧变化会不会让原本可达的聚合突然被视为撤回。

弃用集合不等于弃用聚合

RFC 9774 没有禁止 BGP 路由聚合。它区分了生成集合的复杂聚合与不包含集合的简式聚合，并进一步要求运营者采用能够维持一致起源 AS 的方式。关键不是让路径看起来更短，而是让聚合后的起源身份可预测，能够与 RPKI 来源验证所需的 ROA 对应。

对于一致的简式聚合，实现需要在期望的起源 AS 最右侧实例之后截断 AS_PATH；期望起源可以是聚合 AS 本身。资源持有者还需要为聚合前缀和该起源 AS 建立相应 ROA。如果截断让通常应保留的 AS 信息减少，则应按规范意图附带 ATOMIC_AGGREGATE，明确告诉下游路径信息已因聚合而丢失。

这组规则说明，删除无序集合之后仍必须保存损失信息。一个清楚的起源 AS 便于验证，却不意味着原始路径细节从未被压缩。ATOMIC_AGGREGATE、AGGREGATOR、ROA 与聚合策略各自记录不同事实，任何一个字段都不能单独证明整体配置正确。

可预测起源仍依赖运行配置

简式聚合若没有稳定选择期望起源 AS，结果可能随当时参与聚合的贡献路由变化。邻居可用性一变，路径的最右端候选也可能变化；资源持有者随后不得不为多个潜在起源维护 ROA，或者面对 RPKI-ROV 结果的不一致。

RFC 9774 所提出的一致简式聚合，是把这种变化收束到显式配置。它并不让配置自动正确：运营者仍要确认期望起源确实得到资源授权、截断位置符合实现行为、贡献路由集合符合预期，而且变更前后不会产生未被监控的可达性差异。

这里体现出一个可复用的运行原则。注册表、ROA 和路径属性是记录者，它们保存授权、起源和信息损失，但不会替设备执行聚合，也不会替运营者选择回退路径。记录必须准确地对应运行配置，运行代码才是最终产生 UPDATE 和转发行为的地方。

环路风险需要单独处理

移除 AS_SET 后，贡献 AS 不再一定能从聚合路径中看到自己的 ASN，原有的 AS_PATH 环路检测可能因此无法阻止其接受覆盖本地更具体目的地的较不具体路由。RFC 9774 为此要求运营者不要把聚合路由通告给贡献 AS，而应向每个贡献 AS 通告适当的更具体前缀，并排除从该 AS 学到的路由。

数据面还需要遵守聚合路由的丢弃规则：报文若匹配聚合前缀，却不匹配任何实际存在的更具体路由，应被送往空目的地，而不是被来回转发。控制面的路径清理与数据面的丢弃行为解决的是不同层面；只完成其中一项，不能证明环路风险已经关闭。

因此，弃用工作的验收不应只扫描 UPDATE 中是否还出现集合。它还应核对贡献 AS 过滤、聚合前缀的下一跳行为、更具体路由的存在与撤回顺序。标准减少了一类模糊表示，却要求运营者用更明确的策略承担原本由集合部分提供的保护。

BGPsec 为什么需要有序路径

RFC 8205 定义 BGPsec_PATH，这是一项可选、非传递的 BGP 路径属性。它由 Secure_Path 与一个或两个签名块组成；路径上的 AS 为通告增加相应的签名段。验证成功时，接收方可以获得一项有边界的保证：列出的每个 AS 都曾明确授权把这条路由通告给路径中的下一个 AS。

签名所保护的信息包括目标对端 AS，因此向不同对端 AS 发送时需要分别形成 UPDATE。BGPsec UPDATE 也只通告一个前缀，且 BGPsec_PATH 与传统 AS_PATH 不能同时出现。路径、目标、地址族和前缀共同进入验证语境，说明授权不是对一段可任意重排的成员集合签字。

这正是 AS_SET 与 BGPsec 难以共存的原因之一。若一次聚合本来会产生 AS_SET，RFC 8205 要求不得附带 BGPsec_PATH，并把相关通告转回传统的非 BGPsec UPDATE。RFC 9774 后来直接说明 BGPsec 不支持 AS_SET。路径安全需要可重建的顺序，而无序集合无法提供同样的授权链。

能力协商必须对齐方向和地址族

BGPsec 不是一端声明支持，整个会话便自动进入签名模式。能力通告包含版本、方向与地址族。发送方需要为特定版本和地址族声明“可发送”，接收方则要为同一版本和地址族声明“可接收”；双方对应后，特定方向的 BGPsec UPDATE 才算协商成功。IPv4 与 IPv6 需要分别表达，收发双向也需要分别通告。

多协议扩展是另一个前置条件。speaker 若不支持 BGP 多协议扩展，就不得声明 BGPsec；对某一地址族声明 BGPsec 时，也必须为同一地址族声明相应的多协议能力。更重要的是，任何声明 BGPsec 的 speaker 都必须同时声明四字节 AS 支持，否则 BGPsec 协商不成立，包含 BGPsec_PATH 的 UPDATE 不得在该会话中发送。

未成功协商不一定让传统 BGP 会话停止。RFC 8205 允许会话继续交换无签名 UPDATE，并建议实现记录协商失败；若设备被配置为只允许 BGPsec，则实现必须具备阻止会话建立的能力。监控系统因此不能把“会话 Established”当作“BGPsec 已生效”的替代指标。

RPKI 把号码资源与密钥绑定到验证

BGPsec 依赖 RPKI 证书记录 AS 号码与 IP 地址资源的分配。speaker 若要向外部对端发送带签名的 BGPsec UPDATE，需要持有与自身 ASN 对应的 RPKI 路由器证书及相关私钥。生成签名所用私钥必须对应有效证书中的公钥，并且证书的 AS 号码资源扩展要包含该 speaker 的 ASN。

来源授权与路径授权仍是两个相邻但独立的判断。ROA 由地址空间合法持有者签发，用于授权某个 AS 发起特定前缀；BGPsec 则为路径传播建立逐段授权。RFC 8205 建议发起 BGPsec UPDATE 时存在有效 ROA，并说明接收方通常会把 BGPsec 与来源验证结合使用。验证收到的 BGPsec UPDATE 本身不要求本地持有签名证书，签发与验证的资源条件并不相同。

注册记录在这里承担的是证据保管，而不是网络主权。证书、ROA、ASN、前缀和密钥标识需要唯一、准确且可更新，验证器才能把签名段与正确资源绑定；但 RPKI 不会替运营者建立 BGP 会话，也不会让一条错误配置的聚合自动可达。授权记录与运行代码必须能够对账。

验证状态不能被压成一个“安全”标签

RFC 8205 的处理先检查 BGPsec_PATH 结构和协议关系，再检查可支持算法的签名。语法或协议错误需要按 treat-as-withdraw 处理。若没有任何本地支持的签名算法块，实现可以移除签名块、重建 AS_PATH，并把通告作为无签名 BGP UPDATE 参与处理。这里至少存在不合规、无可用算法、签名有效、签名无效和无签名等不同状态。

在异常负载下，实现可以暂缓验证，但应让运营者看到暂缓及相关通告状态。可见性非常关键：如果队列中的“尚未验证”被显示成“有效”，控制系统就会把计算资源不足改写成安全结论；若一律显示成“无效”，又可能把暂时等待误判为证据失败。

即使通告通过验证，选路如何使用结果仍属于本地策略。外部对端可以依据自身策略传播没有通过验证的 BGPsec UPDATE，因此接收方不能借对端“支持 BGPsec”而跳过独立验证。协议提供可检验状态，运营策略决定动作，两者必须在日志和控制权限上分开。

路径授权不等于数据转发证明

RFC 8205 对安全保证给出了一条重要边界：有效 BGPsec UPDATE 能证明通告消息沿 Secure_Path 所列 AS 序列传播，并且路径中的授权关系符合签名验证；它不保证数据包随后沿相同路径流动。控制平面的消息历史与数据平面的实际转发不是同一对象。

这一区别防止把密码学结果写成端到端服务保证。路由选择、下一跳解析、隧道、流量工程、故障切换和设备状态都可能影响实际转发。BGPsec 也不宣称阻止所有路由攻击；文件把它定位为对来源验证的补充，并让运营者以本地策略使用验证结果。

因此，一份“验证通过”的记录还需要带上时间、RPKI 数据视图、算法支持、对端、地址族和相关前缀。它是一项有语境的控制面证据，而不是永久证书。越能准确描述它证明了什么，也就越能避免它被用于并不支持的结论。

部分部署让保证拥有清楚终点

RFC 8205 没有把迁移写成瞬间覆盖整个互联网。它预期早期部署会形成若干相邻 AS 群组，密码学路径保护首先存在于这些连续区域内。若路径遇到不支持 BGPsec 的 AS，BGPsec UPDATE 会在继续传播前转换为传统无签名 UPDATE；从该边界之后，原有的逐段路径保证不再延续。

这不意味着边界之前的验证毫无价值，也不意味着边界之后的路由必然错误。正确结论是保证具有范围。监控与对外表述都应说明签名链覆盖到哪里、在哪个对端转换为传统模式、后续路径依赖什么证据，而不是把局部保护包装成全球覆盖。

部分部署也解释了为何移除签名需要谨慎。把带有验证信息的通告转成无签名状态，可能让下游无法区分“曾经验证失败”与“从未提供签名”。RFC 8205 倾向于尽量保留可用状态，让下游根据自己的算法与 RPKI 视图作判断，而不是由中间节点替所有接收者抹平证据。

RPKI 数据流本身也是连续性条件

验证器所看到的证书和撤销状态来自 RPKI 仓库，经依赖方缓存再到路由器。RFC 8205 的运营考虑提到基于序列号的增量更新、快照、增量差异和更新通知；这些机制帮助缓存发现变化，并减少每次同步所需传输的数据量。

这条数据链的健康状况会影响验证语境。缓存陈旧、通知未处理或同步中断，不会改变历史签名的字节，却可能改变本地是否拥有正确公钥、证书是否仍有效以及当前资源绑定如何解释。记录签名结果而不记录 RPKI 数据新鲜度，会让后续审计缺少关键前提。

标准描述了提高稳健性、效率和安全性的机制，但没有为任何具体部署提供可用性保证。运营者仍要观察仓库到缓存、缓存到路由器的更新时间，保留失败和回退状态，并明确数据过期时选路策略如何变化。

三份文件形成的是边界链，而不是胜利叙事

RFC 6472 说明为何不应继续增加无序路径集合，并把最初动作限定在发送侧；RFC 8205 说明有序路径、逐段签名、能力协商与 RPKI 资源绑定如何共同形成一项有限的路径保证；RFC 9774 则让集合弃用进入默认发送和接收行为，同时补充一致简式聚合与环路缓解的现实操作。

三份文件都没有报告某个运营网络的采用率、可达性提升、事故减少或成本收益。它们定义规范、错误处理和运营考虑，不是部署调查。Sriram 的公开贡献可以从持续署名和技术主题中确认，但不能被扩写成对实现、网络或结果的个人控制。

最稳定的结论因此落在现实层：号码资源和路径记录需要保持清楚，安全元数据需要与实际配置一致，运行代码决定最终通告与转发行为，迁移必须保存可回退的连续性。标准的价值不是替现实作出宣告，而是让系统在面对现实时有一套可核对的边界。