RFC 9234 ：一种新的 BGP 路由泄露防御与检测方法

最近在 IETF 数据库上看近期的互联网草案和 RFC 文档。我特别关注到了 RFC 9234 - Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages 这篇文档。该文档在今年（2022年）5月份才正式被赋予 RFC 编号，算是一篇很新的文档。这篇文档描述了通过对 BGP 的 Open 和 Update 两种报文新字段属性的设计，实现域间路由泄露的检测与防御。对于 BGP 这个已经成熟了数年的协议来说，有一份新的 RFC 文档已经非常难能可贵了，更何况是对报文本身的修改。恰巧我的本科毕业设计和实验室里一位学姐的研究方向都是这方面的内容，同时也为了方便我的组会汇报，在这里记录一下我对这篇文档的粗略介绍。~~其实基本上就是翻译……~~

简介

路由泄露是指 BGP 前缀的传播违反了对 BGP 拓扑关系的预期。例如将从一个 provider 学到的路由宣布给另一个 provider ；或是将从一个 peer 学到的路由宣布给另一个 peer 或宣布给其直接的 provider。这往往是 BGP 路由配置错误或缺失，导致自治域系统（autonomous systems, AS）之间缺乏协调的结果。

现有的路由泄露防御方案基本依赖于运营商的人工配置，无法检查本地 AS 和目标 AS 的配置是否一致，也不存在定义两个 eBGP （External BGP）宣告者之间商业关系的协议。

RFC 9234 规定了一种带内的方法来预防和检测路由泄露以取代上述由网络管理员驱动的基于配置的泄露解决方法。这个方法增强了 BGP Open 报文的功能，使得 eBGP 会话能够达成一种商业关系协议，BGP 路由路径将会根据这个特点进行标记，从而能防止与检测路由泄露。

该方法使用了一个新的属性参数 BGP Role ，该参数通过在 BGP Open 报文中的 Capabilities 字段（见RFC 5492）进行配置。

RFC 5492 指出， Capabilities 字段是一个可选字段，它的一个重要特点之一是：当收到带有该字段 Open 报文的 BGP 路由器不支持 Capabilities 字段描述的功能时，将会把该功能忽略并正常建立 BGP 连接

+------------------------------+
| Capability Code (1 octet)    |
+------------------------------+
| Capability Length (1 octet)  |
+------------------------------+
| Capability Value (variable)  |
~                              ~
+------------------------------+

同时，该方法还定义了一个可选的、具有传递性的 BGP Path Attribute （在 Update 报文中的一个字段），名为 Only to Customer (OTC) 。该参数能防止 AS 创建泄露报文，并能检测出 AS Path 中的路由泄露。

本文所述方法仅适用于 IPv4 和 IPv6 的单播路由通告。

必须知识：RFC 9234 假定读者已经理解 BGP 5种基本报文的数据结构

术语

下文中，“ 本地AS ”和“ 远端AS ”用于指代 eBGP 会话的两端。 本地AS 指要执行所述协议操作的 AS ， 远端AS 指 eBGP 会话另一端的 AS 。

本文还定义了以下对等关系术语：

角色	路由规则
Provider	可能会向 Customer 传播任何可用路由
Customer	可能会将从自身的 Customer 那里学到的或是本地产生的路由传播到一个 Provider 。所有其它路线都无法传播
Route Server (RS)	可能会向 RS-Client 传播任何可用路由
Route Server Client (RS-Client)	可能会将从自身的 Customer 那里学到的或是本地产生的路由传播到一个 RS 。所有其它路线都无法传播
Peer	可能会将从自身的 Customer 那里学到的或是本地产生的路由传播到另一个 peer 。所有其它路线都无法传播

违反上述路由规则可能会导致路由泄露。

特别的，如果本地 AS 和远端 AS 有一个以上的对等角色，就应当被视为复杂对等关系。比如一对 AS 之间部分前缀是 Provider2Customer 关系，另一部分前缀是 Peer2Peer 关系。

BGP Role

BGP Role 描述了建立连接的 eBGP speaker 之间的关系，本地 AS 如果是下表描述的任何一个角色，都应当在 eBGP 报文中配置 BGP Role，除非 eBGP 连接之间是复杂对等关系。

本地 AS 角色	具体描述
Provider	本地 AS 是远端 AS 的 Provider
Customer	本地 AS 是远端 AS 的 Customer
Route Server (RS)	本地 AS 是一个 RS ，远端 AS 是其 RS-Client
Route Server Client (RS-Client)	本地 AS 是一个 RS-Client ，远端 AS 是其 RS
Peer	本地 AS 和远端 AS 之间是 Peer

BGP Role 通过 Update 报文的 Capabilities 字段确认其内容。

BGP Role 编码

BGP Role 在 Capabilities 字段的编码如下：

+-------------------------------------+
|              Code: 9                |
+-------------------------------------+
|         Length: 1 (octet)           |
+-------------------------------------+
| Value: integer (speaker's BGP Role) |
~                                     ~
+-------------------------------------+

其中，BGP Role 与 Value 字段的对应关系如下：

Value	（本地 AS） BGP Role
0	Provider
1	RS
2	RS-Client
3	Customer
4	Peer
5-255	Unassigned

BGP Role 属性一旦在本地被配置，其 eBGP speaker 必须在 BGP Open 报文中公布它。eBGP 路由器不能公布多种版本的 BGP Role 。下节将介绍收到多个 BGP Role 之后的错误处理。

BGP Role 正确性判断

仅仅收到 BGP Role 不能保证两个 eBGP 实例之间的角色关系是正确的。下表是能够正确匹配的 BGP 角色关系：

本地 AS 角色	远端 AS 角色
Provider	Customer
Customer	Provider
RS	RS-Client
RS-Client	RS
Peer	Peer

如果角色不匹配， BGP speaker 必须使用 Role Mismatch Notification (code 2, subcode 11) 拒绝连接。

考虑到向后兼容，如果收到的报文缺失了 BGP Role ，BGP speaker 应当忽略这个属性并继续连接的建立。

如果一个 BGP speaker 收到了多个相同的 BGP Role ，其 value 字段值都相同，则该 speaker 应当认为它们都是同一个 BGP Role 属性，并继续正常工作；一旦这些 BGP Role 中存在互不相同的 value ，则 BGP speaker 必须使用 Role Mismatch Notification (code 2, subcode 11) 拒绝连接。

和 Open 、 Update 一样， Notification 也是 BGP 报文的一种，code 2 代表 Open 消息错误，其后的 subcode 11 则是在该 RFC 中定义的，针对“角色不匹配”事件设定的。该错误码已被 IANA 收录。

Only to Customer (OTC) 属性

OTC 属性是 BGP Update 报文中 Path Attribute 字段的一个可选的且可传递的属性。

Path Attribute 字段大家可能第一眼比较陌生，但是要知道的是像 AS_PATH, NEXT_HOP, LOCAL_PREF 等著名属性都在这个字段里

OTC 属性的目的在于，一旦一个路由被 a 发送给 b，且 b 是 a 的 Customer 、 RS-Client 或 Peer 。那么在 b 要转发该路由给 c 时，OTC 属性强制保证了 c 必须是 b 的 Customer。

OTC 属性代码为35，长度为4个字节，属性值是一个 ASN ，该值由以下所述路由规则决定。

OTC 属性的处理

以下路由入口规则适用于路由器对 OTC 属性的处理
1. 如果从 Customer 或 RS-Client 处收到了带有 OTC 属性的路由，那么这就是一个路由泄露，该路由一定是不合格的
2. 如果从 Peer （即具有 Peer 角色的远端 AS）收到具有 OTC 属性的路由，且该属性的值不等于这个远端 AS 的 ASN，那么这就是一个路由泄露，该路由一定是不合格的
3. 如果从 Provider 、 Peer 或 RS 角色的远端 AS 收到路由，且 OTC 属性不存在，那么该路由必须被添加一个等于远端 AS 的 ASN 的值。
以下路由出口规则适用于路由器对 OTC 属性的处理
1. 如果一个路由公告要发送给 Customer 、 Peer 或 RS-Client （当发送者为 RS 时），且 OTC 属性不存在，那么当公告该路由时，必须添加一个 OTC 属性，其值等于本地 AS 的 ASN。
2. 如果一个路由已经包含了 OTC 属性，它一定不会被转发给 Provider 、 Peer 或 RS 。

OTC 属性的应用

以上路由规则能为本地 AS 提供泄露预防。在本地 AS 部署以上规则的前提下， OTC 属性的存在能向出口路由器表明该路由是从 Provider 、 Peer 或 RS 学习来的，它只能被发送到 Customer 。
如果收到了来自 Customer 、 Peer 或 RS-Client 的路由，在本地设置的 OTC 属性也提供了一种方法来在多跳以外检测 AS 的路由泄露。例如，如果一个 AS 在发送给 peer 的路由上设置了 OTC 属性，且该路由随后被一个路径上的 AS 从其 customer 那里收到，那么接受路由的 AS 会由于 OTC 的存在检测到该路由是一个路由泄露。

多跳外检测路由泄露是由 OTC 属性的传递性决定的

OTC 属性可以在远端 AS 的出口设置，也可以在本地 AS 的入口设置。也就是说，如果远端 AS 不支持 OTC 属性，但本地 AS 支持，那么本地 AS 根据规则也一定会将来自远端 AS 路由设置 OTC 属性，OTC 属性总是能设置为符合预期的值。这样的特性加之 OTC 属性多跳外检测路由泄露的能力，使得该路由泄露防御与检测方法可行性更高，满足在网络中部分部署的条件。

OTC 属性使用建议

如果报文中 OTC 属性长度值不是4，那么认为 OTC 属性是畸形的。根据 RFC 7606 ，带有畸形属性的 Update 报文应使用“视同撤回”的方法处理。
上文提到的OTC 属性的处理不建议在 RFC 5065 定义的 AS 联盟（Autonomous System Confederations）的自治系统之间使用。如果 OTC 被添加到 AS 联盟出口，其值必须等于 AS 联盟标识符，不能与 AS 联盟任何一个成员的 ASN 对应。
对于面向互联网的 ASN 及其背后绑定的私有 ASN，可以使用本文制定的规则。但任何内部细节都不在本文讨论范围内，在面向互联网的 AS 出口处， OTC 属性不得包含面向互联网的 ASN 以外的值。
一旦 OTC 属性被设置，必须保持不变。
所有入站和出站规则仅适用 IPv4 与 IPv6 地址族，默认情况下不得用于其它地址族。
网络操作员/管理员不得修改本节中制定的规则。

额外考量

不得在具有复杂对等关系的 eBGP 连接上配置 BGP Role，除非能将 eBGP 的复杂对等关系连接拆分为正常对等关系连接。
运营商可能希望精确到以每个前缀为基准配置该方法，但目前还没有带内的方案来检测对每个前缀进行配置的正确性。~~这句话原文我也看不懂啊！~~
BGP Role 或 OTC 属性的错误设置可能会导致路由错误传播。另外，本文没有规定对 OTC 属性中不正确 ASN 的特殊处理
在 RFC7705 定义的路由迁移的情况下，一个路由器可能能够将自己表示为几个不同 ASN 中的任意一个。不过，根据上文定义的出口规则，只要路由器将 OTC 值设置为其当前代表的 ASN 就不会出现问题。
RFC 7606 的第六节提到了“视同撤回”策略可能产生的负面影响，这也同样适用于本方案的 OTC 属性。

关于该路由泄露防御与检测方法的安全考虑

BGP Role 的错误配置可能会影响路由的传播。例如，如果下游（即面向 Customer ）的对等链路被错误配置为 Provider 或 Peer 角色，向这个方向传播的路由会被限制；如果一个上游 Provider 被错误配置为 Customer ，可能会导致其传播从其它 Provider 或 Peer 收到的路由。但 BGP 商业关系一般由人为制定与配置，使得这种错误配置发生的机率不大。
非常不建议将 BGP Role 严格协商机制作为默认配置，这可能会导致 eBGP 会话无法启动的情况。
删除或改变 OTC 属性值可能会成为一种新的主动路由泄露攻击的方式
不鼓励无条件在从 Customer 到 Provider 的链路上部署 OTC 属性，因为这会限制路由的传播。