4、RPKI技术基础：RPKI架构、ROA对象、RPKI验证流程
聊到BGP安全，RPKI是个绕不开的话题。我记得刚接触这玩意儿的时候，觉得它挺玄乎的——不就是个PKI体系吗？后来在现网踩过几次坑，才真正理解它的价值。说白了，RPKI就是给BGP路由加了一把「数字锁」，让谁都能看出来这条路由到底是不是「正版」的。
4.1 RPKI架构：谁在管，怎么管
RPKI的全称是资源公钥基础设施。你想想看，互联网上的IP地址和AS号码是谁分配的？是IANA，然后层层下发给RIR（区域互联网注册机构），再到LIR（本地互联网注册机构）。RPKI就是在这个信任链上建立起来的。
整个架构分三层：
- 信任锚（Trust Anchor）：最顶层，通常是RIR维护的根CA。IANA把资源分给RIR，RIR就成了这些资源的信任起点。
- 下级CA：RIR再给LIR或ISP签发子证书，形成树状结构。每个节点只对自己名下的资源负责。
- 终端实体：最终的路由器或RPKI验证工具，拿着ROA（路由起源授权）对象去验证路由。
我在项目中遇到过一种情况：某家ISP从APNIC拿到了IP段，但自己没部署RPKI。结果下游运营商验证时发现这条路由没有对应的ROA，直接就给标记成了「无效」。嗯，这就是典型的「有资源但不声明」的坑。
核心要点：RPKI的信任链是自上而下的，根在IANA，中间是RIR，末端是运营商。谁持有资源，谁就有权签发ROA。
4.2 ROA对象：路由的「身份证」
ROA（Route Origin Authorization）是RPKI里最核心的数据对象。它长什么样？说白了就是一个数字签名文件，里面包含三个关键字段：
| 字段 | 含义 | 示例 |
|---|---|---|
| IP前缀 | 你声明的IP段 | 203.0.113.0/24 |
| 最大前缀长度 | 允许宣告的最小子网 | /24（不能宣告/25或更小） |
| AS号 | 允许起源的AS | AS64501 |
举个例子。假设你拥有203.0.113.0/24这个段，你只允许AS64501来宣告它，而且不能拆成更小的子网。那你的ROA就是：
IP前缀: 203.0.113.0/24
最大前缀长度: 24
AS号: 64501我个人习惯把ROA理解成「路由的出生证明」。你拿着这个证明，别人就知道这条路由是你合法生的。没有证明？那别人就可能认为你是「黑户」。
避坑指南：我曾经见过有人把最大前缀长度设成/32，结果下游收到了/24的路由，验证直接失败。记住：最大前缀长度不能小于你实际宣告的掩码，否则就是给自己挖坑。
4.3 RPKI验证流程：三步走
验证流程其实不复杂，我拆成三步来讲：
- 获取ROA：路由器或验证工具从RPKI缓存服务器（Relying Party）拉取所有ROA对象。这个过程通常通过RPKI-RTR协议完成。
- 匹配路由：收到一条BGP路由后，提取它的IP前缀和AS_PATH中的起源AS，去ROA数据库里找有没有匹配的记录。
- 判定结果：根据匹配情况，给出三种状态之一——有效（Valid）、无效（Invalid）、未找到（NotFound）。
判定逻辑是这样的：
- 有效：前缀和AS都匹配，且前缀长度不超过最大前缀长度。绿灯通行。
- 无效：前缀匹配，但AS不匹配，或者前缀长度超了。红灯警告，通常会被丢弃。
- 未找到：前缀在ROA库里压根没出现过。黄灯，由本地策略决定是收还是丢。
我给你们画个流程图，一看就明白：
为什么会分成三种状态？说白了，有效和无效是硬性判定，但未找到是个「灰色地带」。有些运营商把所有未找到的路由都当成无效处理，有些则放行。我个人建议：初期可以先对未找到的路由放行，等ROA覆盖率达到一定比例后再收紧策略。否则，你可能会把大量合法但没签ROA的路由给误杀了。
注意：RPKI验证只检查路由的起源AS，不检查AS_PATH的完整性。也就是说，它防不了路径篡改（比如中间人插入虚假AS）。要防路径篡改，还得靠BGPsec。这个我们后面章节会细讲。
4.4 部署建议：从哪开始
如果你现在想部署RPKI，我建议分三步走：
- 先做ROA声明：去你的RIR门户（比如APNIC的MyAPNIC）给你的IP段签发ROA。这一步不花钱，但需要你确认自己的资源归属。
- 搭建验证器：可以用开源工具如Routinator或OctoRPKI，从RIR拉取ROA数据，然后通过RPKI-RTR协议推送给路由器。
- 开启验证策略：先在边界路由器上启用RPKI验证，但策略设为「只记录不动作」。观察一段时间，确认没有误判后再改为「无效路由丢弃」。
我记得有一次帮客户做迁移，他们直接在生产网开了「无效丢弃」，结果发现自己的某个子网因为ROA没签对，导致整个BGP会话断了。嗯，这就是典型的「步子迈太大」。所以，慢慢来，先观察再动手。
小技巧：可以用bgp bestpath prefix-validate命令在Cisco路由器上开启RPKI验证。华为设备对应的是route-policy rpki-valid。不同厂商命令不同，但逻辑一样。
好了，RPKI的基础就这些。你想想看，它其实就是一个「谁持有资源，谁就有权说话」的机制。下一节我们会聊RPKI在实际网络中的部署案例，包括多厂商配置和常见故障排查。不过那是后话了，先把今天的内容消化掉。