BGPsec

Implementation

https://github.com/usnistgov/NIST-BGP-SRx

https://github.com/usnistgov/gobgpsrx

https://github.com/usnistgov/exabgpsrx

https://github.com/colinbs/frr

Files · int-new-bgpsec · labs / BIRD Internet Routing Daemon · GitLab

BGP Secure Routing Extension (BGP‑SRx) Software Suite

RTRlib，用于实现RPKI（资源公钥基础设施）到路由器协议（RTR）

BGPsec Protocol Specification(RFC 8205)

BGPsec 在 UPDATE 报文中引入了一个新的路径属性

仅对 BGP UPDATE 有改动

Intro

UPDATE 消息中 AS-PATH 上每个 AS 列都已经授权了路径中的后续 AS 的宣告行为

non-transitive 非传递性参数 BGPsec_PATH

BGP origin validation

based on RPKI

发向 external 的 UPDATE 都需要私钥加密方便验证

BGPsec Negotiation

BGPsec Capability: 3个8bit

Dir：能接收 → 0，能发送UPDATE → 1，both → 发送两份BGPsec copy 一个0一个1

AFI：支持的地址族 Address Family Identifier，IPv4，IPv6等

需要支持多协议拓展

peering session 协商:

1. 双方 version 一样
2. 双方 AFI 一样
3. 发送方 Dir=1，接收方 Dir=0

如果未对应上，即为 session 协商失败，无法连接并传递 UPDATE

必须要有 4-octet AS number capability （在 OPEN 中的可选参数中的 Capability 内要有 Support for 4-octet AS number capability）才能够协商成功

The BGPsec_PATH Attribute

The UPDATE messages that contain the BGPsec_PATH attribute are referred to as “BGPsec UPDATE messages”

BGPsec_PATH replaces AS_PATH

SKI – Subject Key Identifier

Secure_Path

one Secure_Path Segment for each AS in the path

each Secure_Path Segment is 6 octets long

AS Number: 向 BGPsec_Path 添加这条 Secure_Path Segment 的 BGP Speaker’s ASN

pCount:

BGP Speaker 通过将 BGPsec_Path 属性中的pCount值相加，计算AS路径的长度

pCount 已签署 BGPsec_Path 的 AS 数量，BGP Speaker 可以通过和预期比较来检验是否被篡改；

另外，在传统的BGP中，为了改变路由的路径优先级，AS 可以多次复制自己的 ASN 并将其添加到AS_PATH中来降低优先级。但在BGPsec中，因为验证路径的完整性需要每个AS都生成签名，复制添加 ASN 就会导致额外的计算和存储开销，所以 BGPsec 引入了 pCount，通过递增 pCount 字段的值，BGPsec Speaker 可以模拟多次复制自己的 AS 到 AS_PATH 中的效果，而无需生成多个签名进行验证。这样，发言者可以在不产生额外计算和存储开销的情况下，改变路径的优先级

Confed_Segment flag: 当发向相同 AS confederation 的 peer AS 时设为1，其余为0

Signature_Block

同时实现前一 AS 的验证和对目标 AS 添加路径的授权

路径中的每一个 AS 对应一个签名

签名包括：

1. 当前 ASN
2. 路径中的前一个签名
3. 下一跳
4. 一些其他 BGP 属性
5. 签名算法和参数
6. 公钥标识符

BGPsec UPDATE Messages

“双向“

• 对不同 AS 发送不同的 UPDATE
• 对每个不同的前缀发送不同的 UPDATE
• BGPsec_PATH 和 AS_PATH 参数冲突，AS_PATH 已被包含在 BGPsec_Path 中
• 根据合法的 RPKI 生成的私钥进行签名
• ROA 授权 AS，并指示其可以发布 UPDATE 到指定的前缀
• new signatures are only added to a BGPsec UPDATE message when a BGPsec speaker is generating an UPDATE message to send to an external peer(different ASN)
• 当收到 non-BGPsec UPDATE 时，拒绝添加 AS_PATH 路径到已有的 BGPsec_PATH 中
• internal(within an AS) 可能收到 non-BGPsec UPDATE，此时接收并仅添加 Network Layer Reachability Information(NLRI)，external 则必须要 BGPsec

BGPsec_PATH Attribute

转发给 external peer 时，需要更新 BGPsec_PATH 参数的值，而 internal 则不需要

更新 BGPsec_PATH 时，目标是 Secure_PATH 部分，路径上每个 AS 都需要数字证书验证才能添加

The pCount field of the Secure_Path Segment is typically set to the value 1. However, a BGPsec speaker may set the pCount field to a value greater than 1. Setting the pCount field to a value greater than 1 has the same semantics as repeating an AS number multiple times in the AS_PATH of a non-BGPsec UPDATE message (e.g., for traffic engineering purposes).

连续的k次 ⇒ 只需一个 Segment & pCount=k

参与 BGP 控制平面但不作为数据平面中的传输的路由服务器可以选择将pCount设置为0，这样既可以参与BGPsec 但又不会被计算到长度中

Signature_Blocks

• 每个 Signature_Blocks 对应一个 algorithm suites
• 收到的信息包含多个 Signature_Blocks 时，支持的算法全部包含在发送出去的消息中，不支持的算法则移除对应签名块
• 只要有一个自身支持的算法就认定接收到的消息是有效的
• Secure_Blocks 和 签名段对应

构造过程

Processing Instructions

收到外部消息 并在 AS 内部传播时，pCount=0，Confed_Segment=1

收到内部消息 并向外部传播时：

1. 把最近添加的连续的 Confed_Segment=1 的 Secure_Path Segment 全部移除
2. 把刚刚移除的 Segment 对应的 Signature Segment 也全部移除
3. 把己方 AS 添加到路径中，ASN & 签名

可选：不验证内部添加的签名（先判断 Confed_Segment=1 ）

Reconstructing the AS_PATH Attribute

重建 AS_PATH

先检查完整性，再进行路径还原

pCount=0 跳过，大于0按一定流程来整理顺序

Processing a Received BGPsec UPDATE Message

BGPsec验证只需在eBGP边缘执行，转发基于本地策略，完整转发

具体流程

1. 检查规范性
2. 检查 ASN
3. 检查整个签名块
4. 检查是否不包含 AS_PATH
5. 检查 Confed_Segment=1 等关键参数和实际情况的匹配
6. 检查循环（检查等效路径，检查是否存在 pCount=0 ）
7. 具体的签名检查：计算摘要函数，公钥解密，ASN 和路径对应，依照 Algorithm Suite 验证签名

Questions

• 性能方面
• 安全方面
• 部署
• 计算资源
• BGPsec-capable路由器？

路由器内存

硬件问题

APVAS: Reducing the Memory Requirement of AS_PATH Validation by Introducing Aggregate Signatures into BGPsec

信息泄漏

证书层次结构

BGPSEC期望运营商在其自治系统（AS）内部构建证书层次结构。AS本身从区域互联网注册机构（RIR）或其他权威机构获得证书。然后，运营商为其AS中的每个边缘路由器（eBGP扬声器）生成私钥/公钥对，并使用由外部权威机构分配的认证的私钥签署公钥对。

问题1：复杂性增加

这种方法的一个问题是，每个路由器使用不同的证书签署每个路由，因此您不仅需要找到路由经过的AS，还需要找到路由经过的路由器。这大大增加了BGP更新处理的复杂性，因为现在必须通过至少100倍的证书数据库来验证任何给定路由。

问题2：eBGP扬声器的暴露

更严重的问题是，如果每个eBGP扬声器使用不同的证书，攻击者现在可以绘制出世界范围内每个AS中的每个eBGP扬声器的地图。这不仅为攻击者提供了一个巨大的新分布式拒绝服务（DDoS）攻击向量，而且还向他们展示了如何到达每个eBGP扬声器。这相当于将整个Internet的基础设施暴露给潜在的攻击者。

问题3：对等点的暴露

更糟糕的是，攻击者不仅可以了解每个AS中的每个eBGP扬声器，还可以了解它们连接到的内容。换句话说，攻击者不仅可以知道AT&T与Level 3对等，还可以知道它们如何以及与哪些其他提供商在同一对等点连接。这允许攻击者有效地构建整个Internet的每个对等点的地图。

结论

这种信息泄漏的可能性揭示了BGPSEC设计中的严重缺陷。虽然其目的是增强BGP路由的安全性，但它实际上可能会暴露整个Internet的基础设施，从而增加了攻击的风险和复杂性。这种泄漏可能比BGPSEC试图解决的问题更糟糕，因为它可能会暴露整个Internet的关键部分，从而使其容易受到攻击。

Possible Attacks

Wormhole

MITM

并不需要改动报文内容，而是通过模仿进行宣告，路线一样，只是在中间引流，不涉及到AS

MITM 攻击在 BGPsec 框架中的具体流程可以从以下几个方面来理解：

1. 选择路由：攻击者选择一个中转提供商宣布的路由。
2. 重新宣布路由：攻击者将选定的路由传播到另一个中转提供商。这种重新宣布的路由可能具有较长的AS路径。
3. 利用路由策略：许多路由策略更倾向于由客户宣布的路由。因此，即使重新宣布的路由具有较长的AS路径，本地路由策略也可能更倾向于此路由。
4. 重定向流量：如果上游B更喜欢MITM网络宣布的前缀，则可能会选择该路径。这样，MITM网络就可以检查从上游B（及其其他客户）到目标网络之间传递的所有流量。
5. 数据窃取或篡改：一旦流量被重定向，攻击者就可以窃取、检查或修改流量，然后将其传递给预期的接收者。
6. 无协议违规：关键的是，这种重新宣布的形式并不违反协议，即使所有涉及方都使用BGPSEC，它也不会将此重新宣布标记为无效路由宣布。

Reference

RFC 8205: BGPsec Protocol Specification

BGPSEC: Leaks and Leaks – Packet Pushers

MITM and Routing Security

BGP – 两山下 | 麦田旁