题干与适用场景
面试官给出一个前缀被错误 AS 宣告的场景，要求你说明如何判断该宣告是否得到地址持有者授权。请围绕 RPKI、Route Origin Authorization（ROA）和 BGP Prefix Origin Validation（ROV）回答，并明确它只验证起源 AS，不等同于验证整条 AS_PATH。题目适合网络、CDN、云平台和基础设施岗位。
面试官考察点
强回答会从“谁被授权宣告哪个前缀”开始，而不是把 RPKI 说成加密 BGP。候选人应能解释缓存中的 VRP 如何与 BGP 路由前缀和起源 AS 比对，得到 Valid、Invalid 或 NotFound；还要说明策略如何使用状态、缓存不一致为何存在，以及 Invalid 过滤可能造成误伤。只说“启用 RPKI 就能防止所有劫持”会暴露边界意识不足。
回答前需要澄清的问题
- 目标是保护前缀起源，还是验证整条 AS_PATH？ROV 只回答前者。
- 讨论的是创建 ROA、路由器验证，还是入站策略过滤？三者是不同控制点。
- 网络是否有冗余 ROA 缓存和明确的失联策略？缓存不可用时不能把所有路由突然判为 Invalid。
- 业务优先保证安全、可达性还是回滚速度？严格过滤要配合变更窗口和监控。
30 秒回答框架
“我会先让前缀持有者发布 ROA，声明某个 AS 可以起源该前缀以及允许的最大长度。验证器把签名对象处理成 VRP，BGP speaker 用路由前缀和 AS_PATH 最右侧起源 AS 比对：有覆盖且匹配为 Valid，有覆盖但不匹配为 Invalid，没有覆盖为 NotFound。路由策略可以拒绝 Invalid、对 NotFound 保持现状，但这只保护起源，不验证中间 AS。上线前我会检查 ROA 覆盖、缓存新鲜度、变更回滚和观测指标，因为分布式缓存会短暂不一致。”
分步骤深入解答
- 定义授权对象。 ROA 是签名对象，绑定 IP 前缀、最大前缀长度和允许的 origin AS；它表达“谁可以起源哪些前缀”，不是对所有 BGP 属性签名。
- 准备验证数据。 RPKI 依赖资源证书、签名对象和分布式仓库。验证器周期性取得并校验对象，形成本地 VRP；BGP speaker 使用本地缓存，不直接在每条路由上执行完整证书验证。
- 计算三种状态。 若 VRP 覆盖路由前缀且 origin AS 与 VRP 匹配，状态是 Valid；有覆盖但没有匹配，状态是 Invalid；没有任何 VRP 覆盖，状态是 NotFound。前缀更具体时仍须检查最大长度。
- 接入路由策略。 在入站策略中匹配验证状态，常见做法是拒绝 Invalid、记录或降低 NotFound 的信任度、接受 Valid。策略必须可回滚，避免误发 ROA 或缓存异常造成大面积不可达。
- 说明缓存边界。 RFC 6811 明确全球 RPKI 是松散一致的分布式视图；不同缓存因刷新时间不同可能暂时看到不同数据。监控 VRP 时间戳、缓存连接和状态分布，而不是把一次路由告警直接归因于攻击。
- 解释保护范围。 ROV 能缓解错误起源和部分劫持，NIST 将它定位为降低相关错误配置和恶意攻击的标准化平台。它不证明 AS_PATH 中间节点诚实，也不能单独阻止所有 route leak。
- 设计上线验证。 先在观测模式统计 Invalid/NotFound，再对少量邻居启用过滤；变更前核对 ROA 最大长度、冗余前缀和回滚命令。上线后同时看可达性、Invalid 数量、缓存健康和告警延迟。
高质量示范回答
“我会把问题拆成授权、验证和策略。前缀持有者发布 ROA，声明允许的 origin AS 与最大前缀长度。RPKI 验证器校验签名对象并生成 VRP，BGP speaker 再把收到的路由前缀和 ASPATH 的 origin AS 做比对：覆盖且匹配是 Valid，覆盖但不匹配是 Invalid，没有覆盖是 NotFound。路由器可以拒绝 Invalid，对 NotFound 采用记录或较低优先级，但这不等于验证整条 ASPATH，也不能解决所有 route leak。上线前我会先观测，核对 ROA 覆盖和最大长度，监控缓存新鲜度与可达性，再逐步启用过滤并保留回滚。”
常见错误
- 错误表现 → “RPKI 会验证整条 AS_PATH。” 失败原因 → RFC 6811 的状态只比较前缀覆盖和起源 AS。 修正方法 → 明确 ROV 是 origin validation，路径完整性需要其他机制和策略。
- 错误表现 → “没有 ROA 就一定是恶意路由。” 失败原因 → NotFound 只表示没有覆盖数据，不能推出错误。 修正方法 → 把 NotFound 与 Invalid 分开处理。
- 错误表现 → “缓存断开就把所有路由标成 Invalid。” 失败原因 → 分布式缓存可能暂时不可用或数据过期，突变过滤会扩大故障。 修正方法 → 说明缓存健康检查、冻结旧数据和可回滚策略。
- 错误表现 → “ROA 最大长度随便填。” 失败原因 → 过短会使合法更具体前缀变 Invalid，过长会扩大授权范围。 修正方法 → 根据实际公告集合核对 maxLength。
追问及应对
路由没有 ROA 时为什么不是 Invalid？
只有存在覆盖该前缀的 VRP、但 origin AS 没有匹配时才是 Invalid。没有任何覆盖数据是 NotFound；运营策略可以单独决定如何对待它，不能把缺少证据当成反证。
ROA 发布错误会发生什么？
合法路由可能被判为 Invalid，严格过滤的邻居会拒绝它。先撤销或修正 ROA，再等待仓库和缓存刷新；部署应监控状态变化并准备临时放宽策略的回滚路径。
RPKI 能阻止 route leak 吗？
不一定。ROV 检查起源 AS 是否获授权，合法起源 AS 仍可能把前缀传播到不应到达的邻居。还需要前缀过滤、邻居角色和导出策略等控制来降低泄漏风险。
你会如何验证过滤上线没有误伤？
先以记录模式比较 Valid、Invalid、NotFound 与实际路由表，抽样核对 ROA 和 maxLength；再分批启用拒绝规则，观察可达性探针、缓存健康、邻居会话和 Invalid 数量，异常时回滚到上一版策略。