4. BGPsec协议：给BGP加上数字签名
聊到BGP安全，RPKI是个好东西，但它只能解决「这个前缀该不该由这个AS宣告」的问题。说白了，RPKI管的是所有权验证。但还有一个更棘手的问题——路径完整性。你想想看，就算前缀是合法的，中间的路由器有没有篡改AS_PATH？有没有偷偷插入一个恶意AS？
这就是BGPsec要干的事。我最早接触BGPsec是在一次运营商的安全评估项目里，客户问：「我们部署了RPKI，是不是就高枕无忧了？」我当时就笑了——RPKI只能防前缀劫持，防不了路径篡改。嗯，BGPsec才是那个补上最后一块拼图的方案。
4.1 BGPsec设计目标
BGPsec的设计目标其实很纯粹，就三个核心点：
- 路径完整性保护：确保AS_PATH没有被中间路由器增删改
- 源AS验证：确认路由的起源AS确实是合法的
- 逐跳签名：每一跳AS都要对收到的路由进行签名，形成一条签名链
说白了，BGPsec要保证的是：你收到的这条路由，从源头到你这里，每一跳都是真实的、没有被篡改过的。
核心区别：RPKI验证「这个前缀属于谁」，BGPsec验证「这条路径是怎么走过来的」。两者互补，缺一不可。
4.2 BGPsec工作机制
BGPsec的工作机制，我习惯用一个比喻来解释——快递包裹的签收单。
想象一下：你从北京寄一个包裹到上海，每经过一个中转站，快递员都要在签收单上签字盖章。最后收件人拿到包裹时，可以检查签收单上的每一个签名，确认包裹确实经过了正确的路线，没有被中途拆包。
BGPsec就是给BGP路由加上了这样一张「电子签收单」。具体流程如下：
- 源AS签名：起源AS（比如AS 100）宣告一条路由时，用自己的私钥对NLRI（网络层可达信息）进行签名
- 逐跳转发签名：每一跳AS收到路由后，先验证上一跳的签名，然后用自己的私钥对整条路径进行签名，再转发给下一跳
- 最终验证：接收AS收到路由后，沿着签名链从源头到本地，逐跳验证每一个签名
这里有个关键点——BGPsec只保护AS_PATH，不保护其他属性。比如MED、Local Preference这些属性，BGPsec是不管的。为什么？因为设计者认为，路径完整性是全局安全的基础，而其他属性属于本地策略范畴。
我个人经验：在实验室测试BGPsec时，最容易踩的坑是签名验证超时。BGPsec的签名验证需要CPU计算，如果路由器性能不够，会导致路由收敛时间大幅增加。我曾经在一个老旧的思科7600上测试，结果路由收敛时间从原来的几秒变成了几分钟……嗯，硬件性能是个硬门槛。
4.3 BGPsec与RPKI的关系
很多人搞不清BGPsec和RPKI到底什么关系。我直接说结论：RPKI是BGPsec的基础设施，BGPsec是RPKI的扩展应用。
具体来说：
- RPKI提供信任锚：BGPsec的证书体系完全建立在RPKI的信任锚（Trust Anchor）之上。每个AS的BGPsec证书都是由RPKI的CA签发的
- RPKI验证前缀所有权：BGPsec在验证源AS时，会依赖RPKI的ROA（路由起源授权）来确认这个AS是否有权宣告该前缀
- BGPsec扩展了RPKI的能力：RPKI只能验证「谁拥有前缀」，BGPsec在此基础上增加了「路径是否被篡改」的验证
我画了一张图，帮你理清两者的关系：
注意：BGPsec不能替代RPKI。两者是互补关系。我见过一些团队只部署了BGPsec就以为万事大吉，结果被前缀劫持打了个措手不及。记住，BGPsec依赖RPKI提供信任锚，没有RPKI，BGPsec就是空中楼阁。
4.4 BGPsec部署挑战
说到部署挑战，我得坦白说——BGPsec从2008年提出到现在，全球部署率依然很低。为什么？因为现实很骨感。我总结了几大痛点：
| 挑战 | 具体问题 | 我的经验 |
|---|---|---|
| 性能开销 | BGPsec的签名验证需要大量CPU计算，尤其是RSA签名验证。一台路由器可能同时处理数十万条路由，每条都要验证签名链 | 我曾经在实验室用Juniper MX960测试，开启BGPsec后CPU利用率从15%飙升到85%。后来换了支持硬件加速的线卡才解决问题 |
| 路由收敛 | 签名验证增加了路由处理时间，导致BGP收敛速度变慢。在大型网络中，这可能从秒级变成分钟级 | 嗯，这个我深有体会。有一次模拟BGP会话中断，结果全网路由收敛花了将近8分钟——这在生产环境是不可接受的 |
| 证书管理 | 每个AS都需要申请BGPsec证书，并且要定期更新。证书吊销也是个麻烦事 | 我建议自动化证书管理。手动更新几百个AS的证书？那简直是噩梦。我曾经帮一个运营商设计过自动续期方案，用ACME协议类似的方式 |
| 兼容性问题 | BGPsec需要全网或至少路径上的所有AS都支持。如果中间有一个AS不支持，整条路径的BGPsec保护就断了 | 这就是典型的「木桶效应」。我见过一个案例，两个大型ISP都部署了BGPsec，但中间经过一个小型ISP不支持，结果BGPsec完全没起作用 |
| 部署成本 | 需要升级路由器硬件、软件，还要培训运维团队。对于中小型ISP来说，投入产出比不高 | 说实话，BGPsec的部署成本确实不低。我建议先从核心骨干网开始，逐步向边缘扩展 |
避坑指南：我曾经在一个项目中建议客户全网部署BGPsec，结果被CTO一句话问住了——「你算过全网路由收敛时间会变成多少吗？」后来我学乖了，部署前一定要做性能评估和收敛时间测试。建议先在实验室搭建一个缩小版的拓扑，模拟真实流量和路由数量，跑一遍压力测试。
还有一个容易被忽略的问题——BGPsec的路径MTU。BGPsec给UPDATE消息增加了签名信息，导致报文变大。如果路径上有MTU限制，可能会导致报文分片甚至丢弃。我记得有一次在MPLS网络中部署BGPsec，结果因为MTU问题导致BGP会话反复震荡，排查了两天才找到原因。
最后说一句：BGPsec是个好技术，但现阶段更适合关键基础设施和大型骨干网。对于普通企业网络，先部署RPKI可能更实际。毕竟，安全是个渐进的过程，一口吃不成胖子。
公众号:蓝海资料掘金营，微信deep3321