起源验证判断路由是否被授权
RPKI 用签名的 ROA（Route Origin Authorization）声明「某前缀可以由某个 AS 始发」。路由器收到路由后，把更新里的起源 AS 与 ROA 比对，得到三种结果：valid（有覆盖且匹配）、invalid（有覆盖但不匹配）、notfound（没有覆盖）。运营商据此丢弃被劫持或误宣告的路由，是遏制前缀劫持的基础手段之一。
基本信息
| 依据 | ROA 声明前缀、最大长度与授权的起源 AS |
|---|---|
| 数据链 | RPKI 校验器通过 RTR 协议（RFC 6810）把结果同步到路由器 |
| 判断标准 | RFC 6811 定义前缀起源验证算法 |
| 三种状态 | valid / invalid / notfound |
| 常见策略 | 丢弃 invalid，放行 valid 与 notfound |
典型使用场景
- 客户接入侧防护：阻断明显与授权不符的起源宣告
- 自有前缀保护：先给自己的网段创建 ROA，再对入向路由启用校验
- 观测阶段：只统计三种状态分布，不改变选路结果
- 逐步加严：从仅告警到丢弃 invalid，分阶段推进并逐步扩大范围
- 对等互联治理：把起源验证纳入互联规范，与安全基线一起执行
状态观察与策略引用
状态观察与策略引用
# FRR 示例：查看前缀的验证状态
show bgp ipv4 unicast 10.1.1.0/24
# 输出含 RPKI validation state 字段
!
# 按状态丢弃 invalid（示意，具体语法以平台为准）
route-map RM-RPKI deny 10
match rpki invalid
route-map RM-RPKI permit 20
!
# 统计三种状态的分布
show bgp ipv4 unicast summary三种状态与处理建议
| 状态 | 含义 | 处理建议 |
|---|---|---|
| valid | 有 ROA 且起源与授权匹配 | 正常放行，可提高优先级 |
| invalid | 有 ROA 但起源或长度不符 | 多数网络选择丢弃，需评估误伤 |
| notfound | 没有 ROA 覆盖 | 一般放行，避免影响尚未部署 ROA 的前缀 |
上线前的准备
上线前的准备
# 1) 核对自有前缀是否已创建 ROA
# 2) 确认校验器与路由器之间的 RTR 会话正常
show rpki cache-connection
# 3) 统计入向路由中三种状态的数量分布
show bgp ipv4 unicast
# 4) 先在观测模式运行一段时间，再决定是否启用丢弃策略校验器不可用时策略如何降级需要提前确定：默认全放行会让防护失效，默认全丢弃则可能造成大面积中断。建议按业务重要性分级设定降级行为，并在变更记录中写明。