摘要

  • 8月20日公布的个人草案提出“丢弃起源授权”（DOA），把前缀、长度范围、起源AS、可选中继AS和BGP Community绑定到资源持有者的RPKI签名。
  • DOA匹配结果不会等同于ROV有效，也不得自动触发丢弃；该文件尚未被IETF或GROW采纳，安全、运营和RPKI-RTR传输仍是未完成工作。

在遭受DDoS攻击时，把一条更具体的路由交给上游并附上黑洞Community，可以让流量在拥塞客户链路之前被丢弃。问题在于，这条应急路由往往比ROA允许的最长前缀更长。资源持有者确实希望丢弃流量，ROV却可能把该公告判为Invalid。

draft-spaghetti-grow-rpki-doa-00给出的答案不是扩大ROV的含义，而是增加一张用途更窄的凭证。DOA将作为RPKI签名对象，说明某个起源AS可以针对哪些地址和前缀长度发送丢弃请求、哪些Classic或Large BGP Community构成触发条件，以及哪些中继AS可以传递请求。

这不是已经生效的标准。IETF Datatracker把它标为个人Internet-Draft，并明确提醒该文档没有正式标准地位，也不代表IETF背书。作者把2022年以SIDROPS为目标的旧稿转向GROW，但换到新的草案名称不等于工作组已经接纳。

重新提交仍带来了可核查的变化。2022年的文本没有决定多项Community应采用“且”还是“或”。新稿规定按逻辑“或”处理：收到的路由只要包含DOA列出的一项Community，就满足这一项匹配条件。如果签发者没有指定其他Community，签名工具还可以默认填入RFC 7999定义的知名BLACKHOLE值。

完整匹配不能只看标签。草案要求路由起源AS与DOA一致，前缀长度位于授权范围内，接收方直接从起源AS或列出的peerAsIDs之一收到路由，并且至少匹配一项Community。实现可以为路径赋予Matched、Unmatched或NotFound三种状态。可选的对等AS列表把授权延伸到一个AS跳，但没有赋予无限传播权。

这套设计刻意让DOA与ROV并行。合法的黑洞路由可能同时是DOA Matched和ROV Invalid。草案建议先检查用途受限的丢弃授权，没有匹配或没有对象的路由则继续进入常规策略，包括ROV。更重要的是，实现不得仅凭DOA或ROV状态默认采取策略动作。是否安装、拒绝、传播或丢弃，仍由运营商的明确配置决定。

传播边界也没有被取消。RFC 7999通常要求黑洞路由不要越过接收它的AS。只有当本地AS被DOA列入可选中继名单时，草案才允许把请求继续传给邻网。即使如此，起源、前缀长度和Community仍要同时满足约束。

DOA试图避开另一个危险选择。若想让更具体的黑洞路由通过普通ROV，资源持有者可以把ROA的maxLength放宽；但这样也扩大了普通路由起源授权。RFC 9319提醒运营者避免不必要的宽泛最大长度。独立DOA的结构价值，就在于不必为了应急丢弃而扩张日常起源权限。

现在还不能把这种结构写成可部署能力。草案把RPKI-RTR传输留给后续文档，运营注意事项和安全注意事项尚未撰写，IANA编号也未分配。文件只列出一个Python签名工具，并明确表示实现信息由贡献者提供、没有独立验证，也不代表IETF认可。公开证据没有显示签发器、仓库、验证器和路由器已经完成端到端互操作。

因此，8月20日事件真正增加的是一套更精确的授权模型，而不是一项已上线功能。它把“谁有权请求丢弃哪段流量”从单纯的Community约定提升为资源持有者签名，同时把最终动作留给网络运营商。其成败将取决于对象撤销、过期状态、传输一致性和审计，而这些仍是草案的空白处。

来源