摘要

  • BGP 角色让相邻网络在交换路由前核对供应商、客户、对等体或路由服务器关系；双方确认的角色不匹配时，会话可以直接失败。
  • OTC 会随路由携带传播边界，但它不会认证商业合同，不能替代显式导入与导出策略，也无法用一个标签表达按前缀变化的复杂关系。

分析

路由泄漏不一定是假冒起源。RFC 7908 将它定义为路由通告超出预期范围。某条路由的目的地和起源都可能正确，却从一个上游被送往另一个上游，或从对等体被送往供应商，违反相关网络原本的传播约束。错误发生在交接链条，而不是终点名称。

长期以来，这条链主要依靠单方配置。一家运营商把邻居标成客户、供应商或对等体，再围绕这种判断编写路由策略，并假定另一端采用相同理解。会话本身无需比较双方说法。一个拼写错误、遗漏的过滤器或有缺陷的自动化，就可能把局部错误变成远端接受的路由。

RFC 9234 在路由交换前加入了一个小而关键的步骤。BGP OPEN 报文可以携带角色能力，正常角色包括 Provider、Customer、Route Server、Route Server Client 和 Peer。双方都发送角色时，组合必须相容：Provider 对 Customer，Route Server 对 Route Server Client，Peer 对 Peer。否则，连接以 Role Mismatch 通知被拒绝。

这项机制检查的是协议一致性，不是商业事实。路由器不会读取传输合同、发票或流量承诺。双方完全可能配置一组彼此相容但实际上错误的角色。双方关系还可能因前缀、服务或地区而变化。RFC 9234 把这种情形称为复杂关系，并规定不能在同一会话上配置单一角色。若能拆分，就应使用多条正常关系会话；否则仍需按前缀执行策略。

第二项机制随 UPDATE 报文工作。Only to Customer，简称 OTC，是类型代码 35 的可选传递路径属性，四字节值保存一个自治系统号。路由一旦被发往客户、对等体或路由服务器客户，OTC 就表明它之后只应继续发往客户方向。

带 OTC 的路由如果从客户或路由服务器客户方向到达，就属于泄漏并失去资格；从对等体收到且 OTC 值出现 RFC 指定的不一致时也同样处理。导出时，已带 OTC 的路由不得再发往供应商、对等体或路由服务器。因此，这个信号既能阻止本地错误，也能在数跳之后暴露前方泄漏。

部分部署仍有价值。路由从供应商、对等体或路由服务器到达且没有 OTC 时，合规的接收方可以补上属性。RFC 明确认为这有利于早期采用者，因为不必等待路径上所有网络同时升级。但 OTC 没有密码学保护，中间 AS 可以删除或修改它；错误标记也可能压缩合法可达范围。

向后兼容又带来一项选择。如果一端发送角色而另一端没有发送，默认做法是继续建立会话并使用本地配置角色。运营商可以启用严格模式，拒绝没有角色能力的邻居。RFC 9234 不建议把严格模式设为默认，因为一次软件升级就可能导致 eBGP 会话无法建立。安全收益真实存在，可达性成本也同样真实。

RFC 8212 仍是基础：没有显式策略时，eBGP 路由不应被导入或导出。BGP 角色和 OTC 不会验证路由起源，不能让过度宽松的策略自动安全，也不能替代前缀和路径过滤。IANA 登记只确认线上编码——OTC 为属性 35、Role Mismatch 为 OPEN 错误子码 11——并不证明任何具名网络或软件版本已经部署。

来源