摘要

  • RFC 7999 定义了知名 BGP community BLACKHOLE，含义是请求邻网丢弃发往所标前缀的流量。它只是 advisory signal；接收方只有在特定 session 已达成约定、邻居有权通告覆盖前缀且本地策略明确启用时，才应执行。
  • 目的地址 RTBH 接收一条更具体路由，并把它解析到 discard/null 动作。攻击流量与合法流量一起在入口被丢弃；被攻击链路可能恢复，目标服务却会主动离线。
  • 完整证明必须串联原始 UPDATE、前缀授权、事件审批、ROV、import policy、传播约束、RIB、FIB、drop counter、数据包、撤回和服务恢复。BGP session 为 Established，不能证明这条链中的任何执行结果。

为了保住一条链路，先牺牲一个地址

设想一个合成场景。某 transit 客户的 203.0.113.19 遭遇大流量攻击。攻击先把客户接入链路塞满，流量到达客户侧防火墙时，损害已经发生。客户向上游通告 203.0.113.19/32，并附上 BLACKHOLE。双方事先在这条 BGP session 上开通黑洞服务；上游也确认客户有权通告 203.0.113.0/24。

上游接收 /32，在网络内部限制其传播，并让入口路由器把它解析到 discard。攻击包不再占用客户链路，合法访问也同样到不了该地址。/24 中其他地址仍然可达。这个动作没有“救活”目标，而是通过牺牲目标，保住周围系统和共享容量。

几个小时后，自动化误选了 203.0.113.91/32。它是同一 /24 内的另一个健康业务。对粗粒度控制而言，一切仍然正确：邻居正确、覆盖前缀正确、community 正确、session 没有掉线。如果系统只验证这些条件，错误事件意图就会借一条格式完全正确的路由执行。第二个业务从数据面消失。

这个场景不是公开事故的复述。它把问题缩小到一个清晰边界：拥有某段地址的路由通告权，不等于已经证明某个具体 host 在此时此刻应被切断。

全球统一的是语义，不是执行权

IANA 把 BLACKHOLE 登记为 0xFFFF029A，运营中常写成 65535:666。RFC 7999 把它定义为 well-known、advisory、transitive 的 BGP community，用于目的地址黑洞。一个统一 codepoint 让客户不必为每家运营商记住不同触发值。

但 RFC 同时把关键决定留给接收者：接受并执行，或者忽略，由每个 operator 自己选择。双边关系中，两张网络必须在通告前约定用途。设备在没有明确配置指令时，不应仅因看到该值就丢弃流量。

因此，发送者并没有获得对接收者 forwarding plane 的远程管理权。发送者附加一项请求；接收者判断这条 session、这个前缀和本地 policy 是否共同构成授权。没有提供服务的网络可以忽略；route collector 可以保存属性而不转发任何包；理解字符串的设备也可能没有对应 discard 行为。

这恰好对应 Heng Lu 的 Minimum Initial Specification。公共层只需要稳定数值和最小共同含义。商业服务、客户资格、地域范围、设备集合、持续时间和拒绝条件，不必被写成全球义务。Localized Future Decision 意味着每个运行网络保留本地选择；不采用并不产生“无效”身份。

Voluntary Adoption 则给出真实性测试：RFC 和 IANA 登记不会丢弃一个数据包。只有 policy 被部署、路由被接收、FIB 被编程且 operator 实际依赖结果时，这项行为才成为现实。

“最佳路由”也可以意味着“不送达”

日常语言容易把“路由被接收”简化成“目的地可达”。目的地址 RTBH 有意打破这个等式。

RFC 5635 描述的做法，是在参与设备上准备指向 null/discard interface 的路由，再用 BGP 通告把目标前缀的 next hop 导向该丢弃路径。更具体路由在最长前缀匹配下取得优先，入口包因此在接近进入点的位置被清除，而不是继续消耗到客户的带宽。

这条路由可以语法正确、通过 import、赢得 best path 并进入 Loc-RIB。它的 forwarding 结果却是“不交付”。所以 Loc-RIB presence 不能证明普通意义上的 reachability，甚至不能单独证明黑洞已经执行；还要检查 FIB entry、next-hop resolution 和每类入口设备的实际 disposition。

RFC 5635 对代价说得很直接：目的地址 RTBH 会让目标完全离线。好处是减少对其他主机、客户地点或 ISP 基础设施的连带影响。运营报告必须同时展示两个维度：共享链路是否得到保护，以及被牺牲地址是否仍可服务。前者改善、后者归零，完全可以同时成立。

因此，“mitigation successful”必须带主语。对 backbone capacity 成功，不代表对 customer service 成功。只看利用率下降，会把主动中断包装成业务恢复。

RFC 的两道锁，和运营系统必须补上的第三道锁

RFC 7999 对双边接收提出两项条件。

第一，BLACKHOLE 前缀必须被一个相同或更短的前缀覆盖，而且邻居有权通告那个覆盖前缀。客户不能借黑洞服务把任意互联网地址导向上游的 null interface。

第二，接收方必须已经同意在这条具体 BGP session 上执行 BLACKHOLE。即使客户对地址空间有权，也不能把所有 peering 自动变成丢弃通道。

这两道锁是必要条件，但不是完整的事件授权系统。错误 /32 仍可能处于正确 /24 内；客户路由器可能被攻陷；控制 API 可能重放旧目标；紧急权限可能在攻击结束后继续存在。BGP UPDATE 不携带一张全球可验证的事件票据，告诉接收者是谁批准牺牲哪个服务、原因是什么、何时到期。

第三道锁必须由 BGP 周边系统补足。每次 trigger 至少记录请求者身份、incident ID、精确前缀、业务名称、理由、执行区域、批准时间、过期时间和撤回负责人，并与实际 peer、AFI/SAFI、接收策略版本绑定。

覆盖前缀检查回答：“这个客户能否在这段空间内通告？”事件记录回答：“授权人员是否真的要在现在切断这个地址？”只有人工审批而没有确定性过滤，会留下输入错误；只有过滤而没有事件意图，就等于给自动化一项覆盖整个地址段的常设 kill privilege。

越具体越精确，也越需要特殊通道

RFC 7999 建议黑洞前缀尽可能具体，典型值是 IPv4 /32 与 IPv6 /128。只牺牲一个地址，通常比牺牲整个 aggregate 更安全。

但这类 host route 会穿越普通互联网策略边界。运营网络通常不接受长于 IPv4 /24 或 IPv6 /48 的公网路由。提供跨 AS RTBH 的上游，需要有意打开一条例外：为指定客户接收授权 host route，在本地执行 discard，同时绝不让它成为普通全球 reachability。

这条例外至少由四个边界构成：客户可控的精确覆盖前缀；按地址族设定的允许长度；指定 session 上的指定 community；不能越出批准区域的本地动作与传播策略。

“越具体越安全”只在这些边界内成立。错误 /32 虽只影响一个地址，却可能正好是 resolver、authentication endpoint 或控制系统。/24 黑洞或许能应对广泛攻击，却会同时牺牲 256 个 IPv4 地址。prefix length 是 blast-radius 决策，不是格式字段。

普通 maximum-prefix 计数也不够。一条错误黑洞路由可能比数千条正常前缀造成更大服务损失。系统还应限制同时 active 的黑洞数量、不可自动触发的 protected endpoint、允许持续时间和执行区域。

破坏性更具体路由必须被关在授权域内

RFC 7999 建议接收方加上 NO_ADVERTISE、NO_EXPORT 或类似 community。RFC 1997 赋予两者不同范围：NO_ADVERTISE 禁止向任何其他 BGP peer 继续通告；NO_EXPORT 允许 AS 或 confederation 内部分发，但禁止越过边界。

上游可能需要把黑洞路由分发到所有 ingress，也可能只在攻击流量进入的若干区域执行。约束必须匹配真实执行图。过早使用 NO_ADVERTISE 会阻断内部所需分发；只靠 NO_EXPORT 而缺少 egress filter，也可能漏掉重新分发或策略错误。

host route 泄漏具有双重危险。即使远端不理解 BLACKHOLE，最长前缀匹配也可能把流量吸向错误路径；若远端执行该 community，丢弃范围进一步扩大。因此 RFC 5635 强调 egress prefix filter，而不是把不外泄当成信号的天然属性。

FRRouting 当前文档说明，收到 BLACKHOLE 后会自动添加 NO_ADVERTISE。这是某一 implementation 的 running evidence，不是所有厂商与版本的共同保证。其他系统可能需要明确 route-map；一条“替换全部 communities”的策略也可能无意删除保护值。

真正的传播证明，是每类相关邻居在 policy 之后的 Adj-RIB-Out 或等价 advertised-route view。配置行只表达意图，输出路由才显示设备准备发出什么。

安全系统可以认证通道，却没有认证“该丢弃谁”

BLACKHOLE 位于 classic COMMUNITIES attribute 中。RFC 1997 允许设备按本地 policy 修改该属性。RFC 7999 进一步警告：BGP 没有专门机制阻止中间 speaker 增删或修改 community，接收者也未必能发现。BGPsec 不能解决 community integrity。未经授权添加 BLACKHOLE，本身就可能形成 denial of reachability。

保护 BGP session 仍然重要，它能降低链路外注入与 peer 冒充。但它证明的是某个认证邻居发送了字节，不是自动化选中了正确业务，也不是该账户仍拥有当前事件权限。

RPKI origin validation 回答另一个问题：根据 covering VRP、origin AS 和最大前缀长度，这个 AS 是否有权 originate 该前缀。它不签名 BLACKHOLE community，也不认证“请求丢弃”的意图。一条 RPKI Valid 路由仍可携带未经授权的黑洞值；一条合法 /32 黑洞路由也可能因为 ROA 的 maxLength 只允许 /24 而成为 Invalid。

RFC 7999 要求 operator 避免 origin validation 误挡合法黑洞通告。但把所有带 BLACKHOLE 的路由一律排除在 ROV 之外，会让可修改属性成为 bypass token；把所有 ROA 扩到 /32 或 /128，又会扩大可通过验证的 more-specific 集合。

2022 年有一份个人 Internet-Draft 提议用 RPKI Discard Origin Authorization 分离普通 origin 权限和 discard 权限。它已经过期，也没有 IETF 正式地位。它证明问题有人研究，不能被描述成生产网络已经具备的标准控制。

当前可执行信任链只能由多项证据拼成：peer identity、精确 prefix filter、解释清楚的 ROV 处理、community match、事件审批、本地 scope 和实际 FIB action。任何一个绿色状态都不能覆盖其他项。

四种常被混在一起的机制

目的地址 RTBH 按 destination 丢弃，指向目标的攻击包和合法包一起消失。

源地址 RTBH 把 discard route 与 uRPF 结合，在选定入口让 source lookup 失败。RFC 5635 明确要求不要复用目的地址黑洞 community，并建议 source-based trigger 通常由本地攻击管理系统生成，而不是像普通客户路由一样从外部接收。两者的地址控制关系与安全假设不同。

FlowSpec 分发流量匹配条件和动作。RFC 7999 明确说 BLACKHOLE 不用于 FlowSpec NLRI。sinkhole 把流量改送观察设备；scrubbing 尝试从攻击中保留合法流量。目的地址黑洞既不分析，也不清洗，只负责删除。

决策记录必须写清采用哪一种机制与预期客户结果。若目标是保持被攻击业务在线，destination RTBH 通常是最后的容量保护手段，而不是业务被保护的证明。

从 UPDATE 一直证明到“没有包”

启用服务前，机器可读合同应列出客户、peer/session、AFI/SAFI、覆盖前缀、允许长度、community、保护性排除、执行区域、ROV 规则、最长时限和 withdrawal owner。

每次触发保留下列链条：

  1. 原始 UPDATE、时间、peer、AS_PATH、origin、next hop 和完整 community set；
  2. 命中的 prefix-authorization 条目及其来源；
  3. ROV state 与 blackhole specificity 例外的明确规则；
  4. 命中的 import-policy term、添加的传播约束与 next-hop 变化；
  5. Adj-RIB-In、Loc-RIB 结果和 candidate 获胜原因；
  6. 每类目标 ingress 的 FIB，以及解析后的 discard action；
  7. 带设备、接口、语义和 baseline 的 drop counter；
  8. 丢弃边界前后的 packet observation；
  9. 每类禁止接收该路由的邻居对应 Adj-RIB-Out；
  10. withdrawal、policy re-evaluation、FIB 删除、正常路由重选和业务恢复探测。

每层回答不同问题。UPDATE 证明收到什么；policy log 证明为何接收；RIB 证明谁被选中；FIB 证明将执行什么；counter 与 packet 证明结果；Adj-RIB-Out 证明没有越界；恢复探测证明紧急权力已经终止。

不要把它们压缩成一个“blackhole active”布尔值。这个值无法区分路由存在但未被选择、路由已选但 next hop 未解析到 discard、只有半数入口写入 FIB，或 UPDATE 已撤回但 stale forwarding 仍在。

RFC 7999 鼓励长期保存携带 BLACKHOLE 的 BGP update。完整审计还必须保存策略版本、FIB、计数器和事件授权，因为单独的路由历史无法重建实际执行。

演练牺牲，也要演练归还

服务需要一个可安全测量的 canary prefix。它必须覆盖每类客户 session、地址族、route-server path、ingress region、平台和软件版本。

测试应证明：授权 canary 被接收；无关前缀、错误 session 和过宽长度被拒绝；传播约束出现在每个必要边界；FIB 确实是 discard；只有预期 counter 上升；撤回后正常路由与数据包一起恢复。

如果前缀没有 live incident、属于 protected endpoint、产生无法解释的 ROV 结果、丢失传播约束、进入未授权区域、出现在意外 eBGP output，或没有 expiry 与 withdrawal owner，应暂停触发。

错误业务失联、范围超出批准、more-specific 外泄、不同版本 FIB 动作不一致、prefix 外出现 packet loss，或者组织无法用证据重建动作时，应立即 rollback。

rollback 从撤回开始，不以撤回结束。必须逐个确认 discard FIB 已删除、预期 less-specific 或 alternate route 重新选中、服务探测恢复、链路没有再次失控拥塞。一项 forwarding action 可以技术上可逆；若原始 UPDATE、审批与计数器已经过期，谁动用了这项权力则再也无法证明。

Sources