计算机网络 E02：路由安全与 RPKI、路由泄漏

一条 BGP 通告的起源 AS 与 RPKI 授权一致，并不表示整条 AS_PATH 都可信。RPKI 来源验证回答“这个前缀是否允许由这个 AS 起源”，路由泄漏还涉及路径如何跨越自治系统之间的业务关系传播。

第 12 篇介绍 BGP 路径和策略，第 37 篇讨论信任边界。本篇只用离线通告构造来源验证和导入策略案例，不建立公网 BGP 会话。

ROA 约束前缀、起源与最大长度

RPKI（Resource Public Key Infrastructure）用可验证对象把互联网号码资源与授权关联。ROA（Route Origin Authorization）声明某个 AS 可以起源某个前缀，并可用 maxLength 限制更具体通告的最长前缀长度。

来源验证有三种结果。通告被至少一条覆盖 ROA 授权时为 Valid；存在覆盖 ROA，但起源 AS 或长度不满足时为 Invalid；没有任何覆盖 ROA 时为 NotFound。NotFound 不是“已经证明恶意”，它表示缺少可用于该判断的授权对象。

样例 ROA 授权 AS64500 起源 203.0.113.0/24，最大长度为 /24。因此 AS64500 的 /24 为 Valid，AS64599 的同一 /24 因起源不符而 Invalid，AS64500 的 /25 因长度超过 maxLength 也为 Invalid。

来源状态 = 覆盖关系 + 前缀长度 + 起源 AS

AS_PATH 中间经过哪些自治系统不在这个公式里。用来源状态评价完整路径，等于把没有参与计算的字段当作已验证。

RFC 7908 把 route leak 描述为超出预期范围传播路由通告的情形。一个客户合法起源自己的前缀，某个中间 AS 却把从一个上游学到的路径错误通告给另一个上游时，起源仍可保持 Valid，传播关系却违反策略。

固定案例中，203.0.113.0/24 的起源仍是 AS64500，但 AS_PATH 为 [64530, 64520, 64500]，本地离线策略把该关系标记为不允许。RPKI 来源验证通过，最终导入仍被策略拒绝。这一案例不是对真实运营商关系的判断，只用于展示两个判定轴可以分离。

RFC 9234 的 BGP Roles 和 OTC 属性用于帮助表达与检测一类路由泄漏。它要求相邻 AS 采用相应角色与传播规则；没有协商这些能力时，不能假设泄漏会自动被阻止。

rpki_model.py 使用 Python ipaddress 标准库读取 ROA 和通告。它先计算来源状态，再独立应用样例中的 policy_permit，输出最终导入决定。

1 2	`python3 source/_posts/2026-09-24-计算机网络E02-路由安全与RPKI/rpki_model.py --help python3 source/_posts/2026-09-24-计算机网络E02-路由安全与RPKI/rpki_model.py`

RPKI 数据有效不等于路由一定应被接受。导入策略还可能考虑邻居关系、AS_PATH、社区、偏好和运营目标。

来源 Invalid 也不自动说明恶意劫持。ROA 配置错误、过严的 maxLength 或资源持有者尚未同步更新都可能造成误配，处置策略需要结合本地风险。

路径看起来符合 valley-free 关系也不证明 AS_PATH 中每一跳都经过密码学验证。本篇没有实现 BGPsec，也没有验证控制面通告与数据面实际转发一致。

练习一：ROA 为 10.0.0.0/16、AS65000、maxLength=20。判断 AS65000 起源 /18、AS65000 起源 /24、AS65001 起源 /18 的状态，并写出每个结论的两个检查条件。

练习二：构造一条起源 Valid 但违反“从上游学到的路由不得通告给另一上游”的路径，说明 RPKI 来源验证看不到哪个事实。