BGP角色模型：追踪RFC 9234的采用情况
Routing leaks（路由泄漏）将流量引导到本不该去的路径。我们曾在关于Border Gateway Protocol (BGP) 的路由泄漏方面撰写过文章和公开演讲，阐述这些事件作为影响流量误导事件的影响。BGP路由受到自主系统（ASes）间关系（如客户-提供商和对等）的驱动。客户支付提供商以接入互联网，同行之间则通常在“无结算”的安排下交换流量。这样的关系帮助确定形成合理路径的路由规则。例如，这些规则形成“无谷”层次结构：从提供商或对等方学习到的路径只应向下通告给客户，绝不能向上返回给其他提供商或对等方。像这样的规则表达了对互联网路由的意图或期望。当这种意图被违反时，就形成了路由泄漏。
在历史上，每个网络必须独自实施这种意图，使用复杂且容易出错的路由策略。RFC 9234（《使用UPDATE和OPEN消息中的角色进行路由泄漏预防和检测》）通过在协议内部表达意图来简化此过程。它引入了一种新的“BGP角色”能力，要求两个BGP邻居在会话建立时达成协议，并添加“仅对客户”(OTC)的路径属性，标记必须不再超出客户传播的路由。理解OTC的路由器可以自主拒绝被泄漏的路由，而无需编写运营商策略。
我们开始评估RFC 9234在互联网中的效果以及它的采用情况。依靠我们全球的对等网络，我们开发了一种独特的方法，通过监测哪些对等AS向Cloudflare发送OTC属性，来追踪BGP角色配置的采用情况。在此过程中，我们发现了一些意想不到的事情：两家大型Tier-1网络移除它们转发路由的OTC属性。我们一直在与这些Tier-1网络接触，希望通过其网络允许OTC属性传播，从而帮助促进RFC 9234的早期采用者的路由泄漏预防能力。接下来，我们将详细分析我们的研究，以及OTC剥离的重要性，以及如何在自己的网络中启用BGP角色。
## 使用BGP角色和OTC属性进行路由泄漏预防
在测量之前，我们先谈谈BGP角色和OTC属性实际上是如何运作的。
### 路由泄漏
路由泄漏被定义为“路由通告超出了意图范围”，如RFC 7908所定义。意图的范围由AS关系决定：提供商-客户或对等-对等。
这些规则是不对称的，归结为方向。路由可以自由向下传播：提供商可以向客户交付任何在其表中的内容。向上或横向传播的路由则受限于“本地”信息。具体来说，AS只能在向上或横向方向发送其原始并从其客户处学到的路由。
简单地说，当一个AS将从提供商或对等处学习到的路由通告给另一个提供商或对等方时，就会发生路由泄漏。路径在层级中往下传播，然后再向上返回，形成一个“谷”——这一过程并未获权。
违反无谷属性的形式多种多样，其中一个常见情形是客户在两个提供商之间通告路由，这也被称为“发夹转弯”。这种情况对所有人都不利：客户（AS64504）并没有获得在其提供商之间发送流量的报酬，并且它可能没有能力承载在两个上游网络之间流动的流量，导致延迟增加或丢包。
路由泄漏影响所有人，且发生得相当频繁。因此我们开发了Cloudflare Radar路由泄漏检测系统，以持续追踪路由异常。然而，尽管路由泄漏具有较高的频率及影响，现有的防御措施仍将负担放在网络运营商身上，后者必须依赖前缀过滤器和基于IRR的政策。这些机制要求每个AS必须在每个会话上正确表达其关系，采用手动的方式。RFC 9234将这种负担转移到了BGP路由协议上。
### BGP角色
BGP角色声明你在给定eBGP (External BGP) 会话中与邻居关系的相对位置。角色描述了邻居关系的各方：在与你的过境提供商的会话中，你配置角色为客户，而他们的角色配置为提供商。
有效的角色配对仅有五种：提供商、客户、对等、RS和RS-Client。前三种描述了上文提到的过境和横向对等关系。RS和RS-Client则涉及到互联网交换（IX）路由服务器，其中路由服务器作为所有客户的提供商，透明地重新通告前缀。
RFC 9234规定角色应在每个eBGP会话中在本地AS上进行配置。在部分部署情况下，大多数会话可能仅在一侧具有角色。RFC 9234通过默认方式处理这一情况：如果你发送角色能力而邻居未发送，会话依旧可以启动，而你本地配置的角色仍会推动部分路由泄漏预防。希望获得更强保障的运营商可以启用“严格模式”，拒绝邻居未发送角色能力的任何会话。严格模式为可选项，正如后文所示，它对于大多数网络来说还不现实。
当双方都发送角色而配对不属于上述五种之一时（例如，一端说客户，另一端说对等），会话将因角色不匹配通知（代码2，子码11）而被拒绝。
这种拒绝是角色极具价值的原因之一：角色不匹配意味着两个网络对彼此的关系存在不同的理解，这是在后续作为路由泄漏时会暴露出来的潜在误解。角色不匹配在握手时失败，而不是在作为事件之后再失败。
单一角色无法描述多个角色，例如，如果你与同一邻居在单个会话中持有多种关系（例如，某些前缀上为提供商-客户，其他为对等-对等）。RFC 9234指出不应在这样的会话中配置任何角色。相反，网络需要将复杂关系分割成具有正常关系的独立eBGP会话，并在每个会话上配置相关角色。没有分配角色的单独会话，网络运营商就必须实施更复杂的逐前缀策略，且没有方式可以检查该策略是否正确——这回归到最初促使角色产生的易出错的“手动”机制。
角色还有第二个用途，超越会话协商。在我们之前关于ASPA验证的文章中，我们描述了不同算法如何应用于从提供商获取的路径与从对等、客户、路由服务器或路由服务器客户端接收的路径。来自提供商的路由可以包含在路径中的向上、横向和向下的全方位运动，然而来自非提供商的路由只能包含朝客户ASes的向下坡道。
BGP角色告诉路由器需要运行哪个算法，因此支持这两者的路由器应当同时配置BGP角色和ASPA。
### 仅对客户（OTC）属性
OTC是一种可选的可转移路径属性（类型代码35），携带一个值，即AS号。这个值记录首次横向或向下发送路由的AS，它标记路径的顶端，之后路由只能继续向下。一旦OTC被设置，RFC 9234要求它保持不变。由于该属性是可选的可转移，即使一个没有RFC 9234支持的路由器也应当传递它，而不是将其丢弃。这两个事实随后影响深远。
每个会话中的角色决定哪些规则适用。
**设置OTC**。当一条路由首次停止严格向上移动时会加上OTC：
- 如果向未附加OTC的客户、对等方或RS客户端公告，则附加OTC并携带自身ASN；
- 如果从未附加OTC的提供商、对等方或RS接收，则附加OTC并携带其ASN。
**检查OTC**。一旦路由携带OTC，则只能向下流动：
- 切勿将携带OTC的路由公告给提供商、对等方或RS；
- 从客户或RS客户端到达的携带OTC的路由是泄漏，因此拒绝之；
- 从对等方到达的携带OTC的路由，其值不同于该对等方的自身ASN也是泄漏，因此拒绝之。
作为具体示例，我们回到发夹泄漏，但添加角色和OTC。AS64502将路由通告给它的对等方AS64503，并附加OTC=64502。AS64503则将其继续传递给自己的客户AS64504，同时保持OTC不变。接下来，AS64504意外地违反了意图BGP关系，通告该路由给它的另一个提供商。
OTC有两个机会可以阻止泄漏。如果AS64504合规，它不应当向任何提供商通告携带OTC的路由，这样泄漏就从未发生。如果AS64504不合规，如上例所示，接收的提供商看到的路由来自客户，附带OTC，RFC 9234定义这为泄漏，并标记為不合格。以上任一情况均足以阻止泄漏。
总而言之，在eBGP会话上配置角色，就能自动获得BGP中的路由泄漏保护。
## 追踪RFC 9234的采用情况很具挑战性
### 谁在设置OTC？
如上所述，RFC 9234概述了在出口和入口路由上设置OTC的规则。在一个理想世界中，完整（且正确）的部署，出口OTC附加即可。然而，在部分部署或配置错误的情况下，接收RS-客户端、客户或对等方的入口戳记可填补缺失的OTC值。引用RFC 9234第5节的相关规则：
> 如果路由从提供商、对等方或路由服务器接收且OTC属性不存在，则必须添加，值等于远程AS的AS号。
尽管这种双侧OTC附加方式试图标识尽可能多的路由，但这也模糊了谁设定了OTC值。例如，通过观察路径64506 64507且OTC=64507，我们无法推断AS64507是在出口设置了OTC，还是AS64506在入口设置了缺失的值。
由于这一点，追踪RFC 9234采用情况的OTC值识别变得困难，但我们认为这一点足够重要，值得我们尝试。
### 使用公共BGP数据
考虑到这个限制，我们首先尝试通过分析来自RouteViews和RIPE RIS的所有公共BGP收集器的路由信息库（RIB）转储，来检测哪些ASes正在设置OTC值。尽管直观地计算不同的OTC值为我们提供了361个潜在设置者ASes，但这个数字被那些从其对等、提供商和（较少）RS那里填充缺失值的ASes所膨胀。为了对此进行调整，我们的第一步是计算OTC值与AS_PATH首个AS相等的数量。这些ASes向捕获“原始接收”的BGP消息的路由收集器设置了OTC属性。这一步给我们一个初步的设置者AS数量，为9。
将这项分析扩展到在AS_PATH中检测OTC是设置在出口还是入口的，需要使用多个保护手段来进行区分。我们开始时使用一种简单且放松的方法来估算可能设置OTC的ASes。我们查看携带OTC值的所有AS_PATH，并收集所有边（ASX ASZ），其中OTC = ASZ。然后，我们根据这些边创建两个映射：下游：ASN→next_hops和上游：ASN→previous_hops。例如，在（ASX ASZ）的情况下，我们将ASX添加到downstream(ASZ)，并将ASZ添加到upstream(ASX)。下一步，我们希望从两侧去除那些更有可能在另一侧设置OTC的ASes。为此，我们收集所有拥有|downstream(Y)| ≥ 10或|upstream(Y)| ≥ 10的ASes，并将其分别从previous_hops或next_hops中删除。
最后，从这两个映射中我们保留至少有三个next或previous hops的ASes，找到18个潜在设置OTC的ASes和20个可能在入口填充缺失OTC值的ASes。综合这些结果与直接对等ASes的结果，我们发现只有36个ASes是**潜在**RFC 9234兼容的，尽管真实数量还需进一步调查。
我们理解，为了确保准确性，这种方法可能会遗漏那些下游或上游数量极少的ASes。我们还在寻求改进。例如，缺失OTC值的AS_PATH可能对一个**未**设置OTC的AS提供否定证据。在这种方法中，了解AS间的关系对于仅关注OTC应当被设置的情况至关重要，即不在上游。但获取准确的AS关系已经是一个超过20年的难题，然而，多个努力正在进行中，可能会有所帮助，如CAIDA和BGPKIT的AS关系数据集。公共数据非常宝贵，即使存在固有缺陷。
我们决定通过使用Cloudflare网络进行实验，以补充RFC 9234合规性的视角，为开放和公共互联网的服务和精神。
### 使用Cloudflare的全球对等网络
Cloudflare拥有成千上万的对等连接和开放的对等政策，可以帮助追踪谁实施了RFC 9234。如前所述，核心挑战在于如何自信地区分OTC是在出口还是入口。由于Cloudflare与许多AS直接对等，我们可以直接评估它们的RFC 9234合规性，而不受中间AS带来的不确定因素影响。
我们的方法论简单且具体：我们使用来自Cloudflare路由器的BGP监控协议（BMP）馈送，监测我们从对等方接收的OTC。当OTC值等于对等方ASN时，我们会进行检查。我们处理了过去三个月的BMP数据，发现67个AS设置了OTC属性。以下图显示了根据PeeringDB的一些手动修正，设置OTC的这些AS的网络类型的分布。
---
原文链接：[点击查看](https://blog.cloudflare.com/rfc9234-bgp-role-model/)
在历史上，每个网络必须独自实施这种意图，使用复杂且容易出错的路由策略。RFC 9234（《使用UPDATE和OPEN消息中的角色进行路由泄漏预防和检测》）通过在协议内部表达意图来简化此过程。它引入了一种新的“BGP角色”能力，要求两个BGP邻居在会话建立时达成协议，并添加“仅对客户”(OTC)的路径属性，标记必须不再超出客户传播的路由。理解OTC的路由器可以自主拒绝被泄漏的路由，而无需编写运营商策略。
我们开始评估RFC 9234在互联网中的效果以及它的采用情况。依靠我们全球的对等网络，我们开发了一种独特的方法，通过监测哪些对等AS向Cloudflare发送OTC属性，来追踪BGP角色配置的采用情况。在此过程中，我们发现了一些意想不到的事情：两家大型Tier-1网络移除它们转发路由的OTC属性。我们一直在与这些Tier-1网络接触，希望通过其网络允许OTC属性传播，从而帮助促进RFC 9234的早期采用者的路由泄漏预防能力。接下来，我们将详细分析我们的研究，以及OTC剥离的重要性，以及如何在自己的网络中启用BGP角色。
## 使用BGP角色和OTC属性进行路由泄漏预防
在测量之前，我们先谈谈BGP角色和OTC属性实际上是如何运作的。
### 路由泄漏
路由泄漏被定义为“路由通告超出了意图范围”，如RFC 7908所定义。意图的范围由AS关系决定：提供商-客户或对等-对等。
这些规则是不对称的，归结为方向。路由可以自由向下传播：提供商可以向客户交付任何在其表中的内容。向上或横向传播的路由则受限于“本地”信息。具体来说，AS只能在向上或横向方向发送其原始并从其客户处学到的路由。
简单地说，当一个AS将从提供商或对等处学习到的路由通告给另一个提供商或对等方时，就会发生路由泄漏。路径在层级中往下传播，然后再向上返回，形成一个“谷”——这一过程并未获权。
违反无谷属性的形式多种多样，其中一个常见情形是客户在两个提供商之间通告路由，这也被称为“发夹转弯”。这种情况对所有人都不利：客户（AS64504）并没有获得在其提供商之间发送流量的报酬，并且它可能没有能力承载在两个上游网络之间流动的流量，导致延迟增加或丢包。
路由泄漏影响所有人，且发生得相当频繁。因此我们开发了Cloudflare Radar路由泄漏检测系统，以持续追踪路由异常。然而，尽管路由泄漏具有较高的频率及影响，现有的防御措施仍将负担放在网络运营商身上，后者必须依赖前缀过滤器和基于IRR的政策。这些机制要求每个AS必须在每个会话上正确表达其关系，采用手动的方式。RFC 9234将这种负担转移到了BGP路由协议上。
### BGP角色
BGP角色声明你在给定eBGP (External BGP) 会话中与邻居关系的相对位置。角色描述了邻居关系的各方：在与你的过境提供商的会话中，你配置角色为客户，而他们的角色配置为提供商。
有效的角色配对仅有五种：提供商、客户、对等、RS和RS-Client。前三种描述了上文提到的过境和横向对等关系。RS和RS-Client则涉及到互联网交换（IX）路由服务器，其中路由服务器作为所有客户的提供商，透明地重新通告前缀。
RFC 9234规定角色应在每个eBGP会话中在本地AS上进行配置。在部分部署情况下，大多数会话可能仅在一侧具有角色。RFC 9234通过默认方式处理这一情况：如果你发送角色能力而邻居未发送，会话依旧可以启动，而你本地配置的角色仍会推动部分路由泄漏预防。希望获得更强保障的运营商可以启用“严格模式”，拒绝邻居未发送角色能力的任何会话。严格模式为可选项，正如后文所示，它对于大多数网络来说还不现实。
当双方都发送角色而配对不属于上述五种之一时（例如，一端说客户，另一端说对等），会话将因角色不匹配通知（代码2，子码11）而被拒绝。
这种拒绝是角色极具价值的原因之一：角色不匹配意味着两个网络对彼此的关系存在不同的理解，这是在后续作为路由泄漏时会暴露出来的潜在误解。角色不匹配在握手时失败，而不是在作为事件之后再失败。
单一角色无法描述多个角色，例如，如果你与同一邻居在单个会话中持有多种关系（例如，某些前缀上为提供商-客户，其他为对等-对等）。RFC 9234指出不应在这样的会话中配置任何角色。相反，网络需要将复杂关系分割成具有正常关系的独立eBGP会话，并在每个会话上配置相关角色。没有分配角色的单独会话，网络运营商就必须实施更复杂的逐前缀策略，且没有方式可以检查该策略是否正确——这回归到最初促使角色产生的易出错的“手动”机制。
角色还有第二个用途，超越会话协商。在我们之前关于ASPA验证的文章中，我们描述了不同算法如何应用于从提供商获取的路径与从对等、客户、路由服务器或路由服务器客户端接收的路径。来自提供商的路由可以包含在路径中的向上、横向和向下的全方位运动，然而来自非提供商的路由只能包含朝客户ASes的向下坡道。
BGP角色告诉路由器需要运行哪个算法，因此支持这两者的路由器应当同时配置BGP角色和ASPA。
### 仅对客户（OTC）属性
OTC是一种可选的可转移路径属性（类型代码35），携带一个值，即AS号。这个值记录首次横向或向下发送路由的AS，它标记路径的顶端，之后路由只能继续向下。一旦OTC被设置，RFC 9234要求它保持不变。由于该属性是可选的可转移，即使一个没有RFC 9234支持的路由器也应当传递它，而不是将其丢弃。这两个事实随后影响深远。
每个会话中的角色决定哪些规则适用。
**设置OTC**。当一条路由首次停止严格向上移动时会加上OTC：
- 如果向未附加OTC的客户、对等方或RS客户端公告，则附加OTC并携带自身ASN；
- 如果从未附加OTC的提供商、对等方或RS接收，则附加OTC并携带其ASN。
**检查OTC**。一旦路由携带OTC，则只能向下流动：
- 切勿将携带OTC的路由公告给提供商、对等方或RS；
- 从客户或RS客户端到达的携带OTC的路由是泄漏，因此拒绝之；
- 从对等方到达的携带OTC的路由，其值不同于该对等方的自身ASN也是泄漏，因此拒绝之。
作为具体示例，我们回到发夹泄漏，但添加角色和OTC。AS64502将路由通告给它的对等方AS64503，并附加OTC=64502。AS64503则将其继续传递给自己的客户AS64504，同时保持OTC不变。接下来，AS64504意外地违反了意图BGP关系，通告该路由给它的另一个提供商。
OTC有两个机会可以阻止泄漏。如果AS64504合规，它不应当向任何提供商通告携带OTC的路由，这样泄漏就从未发生。如果AS64504不合规，如上例所示，接收的提供商看到的路由来自客户，附带OTC，RFC 9234定义这为泄漏，并标记為不合格。以上任一情况均足以阻止泄漏。
总而言之，在eBGP会话上配置角色，就能自动获得BGP中的路由泄漏保护。
## 追踪RFC 9234的采用情况很具挑战性
### 谁在设置OTC？
如上所述，RFC 9234概述了在出口和入口路由上设置OTC的规则。在一个理想世界中，完整（且正确）的部署，出口OTC附加即可。然而，在部分部署或配置错误的情况下，接收RS-客户端、客户或对等方的入口戳记可填补缺失的OTC值。引用RFC 9234第5节的相关规则：
> 如果路由从提供商、对等方或路由服务器接收且OTC属性不存在，则必须添加，值等于远程AS的AS号。
尽管这种双侧OTC附加方式试图标识尽可能多的路由，但这也模糊了谁设定了OTC值。例如，通过观察路径64506 64507且OTC=64507，我们无法推断AS64507是在出口设置了OTC，还是AS64506在入口设置了缺失的值。
由于这一点，追踪RFC 9234采用情况的OTC值识别变得困难，但我们认为这一点足够重要，值得我们尝试。
### 使用公共BGP数据
考虑到这个限制，我们首先尝试通过分析来自RouteViews和RIPE RIS的所有公共BGP收集器的路由信息库（RIB）转储，来检测哪些ASes正在设置OTC值。尽管直观地计算不同的OTC值为我们提供了361个潜在设置者ASes，但这个数字被那些从其对等、提供商和（较少）RS那里填充缺失值的ASes所膨胀。为了对此进行调整，我们的第一步是计算OTC值与AS_PATH首个AS相等的数量。这些ASes向捕获“原始接收”的BGP消息的路由收集器设置了OTC属性。这一步给我们一个初步的设置者AS数量，为9。
将这项分析扩展到在AS_PATH中检测OTC是设置在出口还是入口的，需要使用多个保护手段来进行区分。我们开始时使用一种简单且放松的方法来估算可能设置OTC的ASes。我们查看携带OTC值的所有AS_PATH，并收集所有边（ASX ASZ），其中OTC = ASZ。然后，我们根据这些边创建两个映射：下游：ASN→next_hops和上游：ASN→previous_hops。例如，在（ASX ASZ）的情况下，我们将ASX添加到downstream(ASZ)，并将ASZ添加到upstream(ASX)。下一步，我们希望从两侧去除那些更有可能在另一侧设置OTC的ASes。为此，我们收集所有拥有|downstream(Y)| ≥ 10或|upstream(Y)| ≥ 10的ASes，并将其分别从previous_hops或next_hops中删除。
最后，从这两个映射中我们保留至少有三个next或previous hops的ASes，找到18个潜在设置OTC的ASes和20个可能在入口填充缺失OTC值的ASes。综合这些结果与直接对等ASes的结果，我们发现只有36个ASes是**潜在**RFC 9234兼容的，尽管真实数量还需进一步调查。
我们理解，为了确保准确性，这种方法可能会遗漏那些下游或上游数量极少的ASes。我们还在寻求改进。例如，缺失OTC值的AS_PATH可能对一个**未**设置OTC的AS提供否定证据。在这种方法中，了解AS间的关系对于仅关注OTC应当被设置的情况至关重要，即不在上游。但获取准确的AS关系已经是一个超过20年的难题，然而，多个努力正在进行中，可能会有所帮助，如CAIDA和BGPKIT的AS关系数据集。公共数据非常宝贵，即使存在固有缺陷。
我们决定通过使用Cloudflare网络进行实验，以补充RFC 9234合规性的视角，为开放和公共互联网的服务和精神。
### 使用Cloudflare的全球对等网络
Cloudflare拥有成千上万的对等连接和开放的对等政策，可以帮助追踪谁实施了RFC 9234。如前所述，核心挑战在于如何自信地区分OTC是在出口还是入口。由于Cloudflare与许多AS直接对等，我们可以直接评估它们的RFC 9234合规性，而不受中间AS带来的不确定因素影响。
我们的方法论简单且具体：我们使用来自Cloudflare路由器的BGP监控协议（BMP）馈送，监测我们从对等方接收的OTC。当OTC值等于对等方ASN时，我们会进行检查。我们处理了过去三个月的BMP数据，发现67个AS设置了OTC属性。以下图显示了根据PeeringDB的一些手动修正，设置OTC的这些AS的网络类型的分布。
---
原文链接：[点击查看](https://blog.cloudflare.com/rfc9234-bgp-role-model/)
评论
暂无评论。