RPKI 路由起源验证用一张密码学签名的授权表，回答某个 IP 前缀能不能由某个自治系统发起宣告。区域互联网注册机构签发资源证书，前缀持有者据此发布路由起源授权，也就是 ROA，里面写着前缀、允许发起的 AS 号和最长掩码。路由器把这些 ROA 校验成有效载荷表，再拿 BGP 收到的每条路由去比对，判定为有效、无效或者未覆盖。它挡的是前缀被别的 AS 冒名宣告，挡不住路径篡改和路由泄露。国内做多线接入或者骨干互联的团队，值得把它排进今年的网络加固清单。
ROA 里到底写了什么
一份 ROA 的最小内容是三个字段。前缀是授权范围，AS 号是唯一被允许发起该前缀的自治系统，最长掩码限制这个前缀能细分到多细。第三个字段决定误伤的多少。
最长掩码写小了，下游客户把前缀切细再用就会变成无效路由。持有 203.0.113.0/24 的运营商如果同时给接入客户做分配，把最长掩码写到 24 会挡住客户宣告 /25 的能力。这类问题往往在上线之后才炸出来，排查时又容易当成上游过滤。
稳妥的做法是先只读不写，把门户里当前生效的 ROA 清单导出来核对，确认没有遗漏的客户前缀之后再动手。
验证状态只有三种，语义却容易被搞错
没有任何有效载荷覆盖这条路由，状态是未覆盖。至少有一条有效载荷匹配前缀、掩码长度不超过上限、AS 号也一致，状态是有效。有有效载荷覆盖了这个前缀却没有一条匹配，状态是无效。
覆盖和匹配是两回事。一条 203.0.113.0/24 的 ROA 会覆盖所有 203.0.113.0/24 及更长掩码的路由，包括 /25 和 /28。只要最长掩码没放开，这些更长前缀就全部落到无效。
这就解释了一个反复出现的现场事故。边缘设备启用了丢弃无效路由的策略，某天上游签发了覆盖本地区地址块的 ROA，本地一条没有 ROA 的细分路由立刻被丢弃。
从只读到丢弃，应该怎么分批推进
- 先做可见性，把验证结果记录下来，导出无效路由清单。这一步不改转发表，风险最低。
- 核对清单，逐条判断无效的原因是本侧 ROA 缺失、最长掩码写窄，还是真的存在冒名宣告。属于前两类的，回到门户修正自己的 ROA。
- 再动策略。运营商通常先对自有前缀和直连客户做丢弃，观察一段时间没有异常再扩到对等互联，全程保留按 AS 豁免的能力。
- 最后把验证结果接进告警。无效路由的数量突然抬升，通常对上游配置变更或者真实的劫持尝试。
它防不住什么
RPKI 只校验起源。宣告路径中间被插入一段伪造的 AS 序列，验证结果照样是有效，因为起源没有变。路由泄露同理，一条从对等方学来的路由被转告给另一个对等方，起源正确，验证通过。
AS 号本身也拿不到密码学保护。攻击者只要从合法来源学到某个前缀的路由，再伪造路径属性重新宣告，就能通过起源验证。让路径也可验证的那套机制还在标准化阶段。
大量地址块没有签发 ROA，这些前缀对任何验证者都显示为未覆盖。攻击者把目标放在没有 ROA 的地址空间上，效果一样。
未覆盖不等于安全，默认值要写清楚
把未覆盖当成通过检验是常见的误会。未覆盖只表示查不到证据，不代表这个宣告合法，默认放行是工程上的妥协。如果改成丢弃未覆盖，一部分合法路由会消失，所以常见的组合是无效丢弃、未覆盖放行。
常见问题
已经签了 ROA，还需要开丢弃吗。需要。签发只让别的网络能验证你，自己的策略要单独配置。
一个小型网络值得做吗。地址块自有且长期不变就值得，成本很低。地址由上游动态分配的话，优先级往后放。