RIPE 开始教路由泄漏防护了，这为什么重要
RIPE NCC 的 BGP 路由安全课程现在包含了基于 RFC 9234 的路由泄漏防护与检测理论，并配有一个动手实验，内容是配置 BGP Roles 和探索 Only-To-Customer。 1
当区域注册管理机构把某样东西写进标准课程时，它就已经从实验性提案走向了推荐的运维实践。
RPKI 留下的缺口
上周我们写过 RPKI 在哪里止步。那条主要限制值得重复：RPKI 不能消除路由泄漏。
路由泄漏不是伪造的源。源是合法的，ROA 也能完美通过验证。问题出在传播。一个网络从某个对等方或上游收到一条路由，又把它重新宣告给另一方，而它本不该去那里。突然之间，一个小型区域网络把自己宣告成通往互联网大片区域的路径，流量也就跟了过去，因为 BGP 相信别人告诉它的话。
历史上，路由泄漏造成过一些有记录以来最大的全球路由事故，而它们几乎总是意外：一条漏掉的过滤规则、一条应用到错误会话上的策略、一份从别的邻居那里抄来的模板。
RPKI 看不见这一切，因为链条上的每一次宣告都有合法的源。
Roles 与 OTC，简述
RFC 9234 把大家本来就非正式知道的事情——这条会话是对客户的、那条是对上游的、另一条是对等的——在协议内部明确表达出来。 2
你在每条 eBGP 会话上配置一个角色：provider、customer、route server、route server client 或 peer。Role 能力在 OPEN 消息中交换，因此双方都能确认这段关系，并拒绝不兼容的配置。角色一旦确定，Only-To-Customer 这个可选的传递性路径属性，就让路由器能够标记并检测那些去到了商业关系不允许之处的宣告。 2
它的精妙之处在于：给一个一直以来属于过滤范畴的问题，加上了协议层面的检查。传统的泄漏防护意味着为每一个邻居维护准确的前缀过滤表，这工作量巨大、易出错，而且永远是过期的。Roles 和 OTC 让合规的路由器能够从关系本身出发，结构性地检测出许多泄漏，从而降低对逐邻居前缀过滤的依赖。
是降低，不是取代。RFC 9234 是与你现有的控制手段并列，而不是把它们退役，所以你依然需要基于 IRR 的过滤、RPKI 源验证、max-prefix 限制和 bogon 过滤。它移除的是另一样东西：以为那些过滤规则是唯一挡在一条打错的策略与一次泄漏之间的假设。
它的部署也相对容易：在 BIRD、FRR 或 JunOS 里每条会话几行配置，而且当对端不支持时会优雅降级。
我们交给客户的控制权
我们运营 AS210464，而我们的立场是：客户应当能够在不开工单的情况下控制自己的路由。
这从我们对接受路由执行 RPKI 验证开始，也就是把源验证作为底线。接着是完整的 BGP community 集合，让你直接在自己的宣告里获得“泄漏形状”的控制：不要宣告给某个特定 AS、不要给客户、不要给直连对等方、不要给 IXP 对等方、不要给 route server、不要给上游，此外还有区域控制、一到三次 prepend、为备份路由控制 local-preference，以及当你需要在我们边缘而不是在你服务器上丢弃前缀时的远程触发黑洞路由。
这套 community 存在的理由是：宣告范围应当是你的决定，并写在宣告本身里，而不是由我们这边某个人手工维护、并终有一天弄错的过滤规则。
BGP 会话起价 €5/月。每台虚拟机附带一个可路由的 IPv6 /48；如果你需要的是可宣告的地址空间，而不只是可使用的，那就自带或向我们租用。会话与本地网关地址 10.0.0.1 和 fd10::1 建立对等，你这一侧需要启用 multihop 并把 TTL 设为 255；而我们的路由器究竟看到什么，你可以通过 looking glass 从地拉那、斯科普里、阿姆斯特丹或都柏林自行查看，无需账号，也无需销售通话。
值得花一个下午的三件事
如果你在跑 BGP，就从给 eBGP 会话设置角色开始，并且先从上游开始，因为泄漏在那里造成的损害最大。
顺手审计一下你的 ROA。过期 ROA 和过于宽松的 maxLength 之类的运维失误，仍然是 RPKI 无效宣告最常见的成因，所以你未来最可能遇到的路由事故，依然是你自己造成的那一次。
如果你在这个区域，就去上 RIPE 的课。实验环节是最快让你对角色和 OTC 上手的方式。
路由泄漏仍是少数几种这样的互联网故障之一：一条配置错误的会话，就能让从未听说过你的网络服务受损。如今解法已经标准化、有人教、而且便宜。可辩解的余地已经不多了。