Author basilguo@163.com
Date Aug. 14, 2023
Description BGPsec的简要介绍以及实际部署测试问题。
[TOC]
首先需要声明的是，这是2022年的报告。说BGPsec还只是停留在理论和paper中，实际部署还很少，所以社区实际上也没搞明白。经过在Equinix网络持续两年的测试，发现了一些值得记录的设计问题。
另外，最权威的肯定是去啃RFC，例如RFC8205。如果本文和RFC的描述有冲突，一切以RFC和RFC errata为准。
1. 背景
1.1. BGP和网络
整个网络在构建的时候就是注重效率而非安全。这无可厚非，最开始的时候，路由设备效率都不能满足，还需要兼顾便宜可靠，所以安全就不是第一位的。实际上以后对网络协议的改动会越来越难，整个TCP/IP协议栈和路由体系只能不停的打补丁。
BGP也是这样设计出来的，所以BGP的安全也是有问题的。BGP的安全问题可以分为两大类：路由泄露和路由劫持。这些安全问题还可以分为：有些是无意的行为比如误配置误操作，还有一些就是恶意行为。
源验证实际上是有助于发现无意的泄露，但是对于大部分劫持没有太大的意义，而且源验证对实际路径也不关心。
1.2. PRKI
RPKI即resource PKI，资源PKI，而非Routing PKI。所以实际上它是用来保护互联网数字资源的。互联网数字资源包括ASN、prefix、router keys、peer sets等。
RPKI是层次化的，从RIR到LIR、NIR到ISP到AS，一层层的进行资源的分配和授权，但是这个授权不是绑定到持有者的。
就RPKI中的I代表含义，sidrops专门回答了一个问题：即RFC9255，The 'I' in RPKI does not standard for identity。也就是说RPKI只管互联网数字资源之间的联系，而不保证互联网数字资源和真实拥有者之间的联系。emmm，很奇怪。
There is a false notion that Internet Number Resources (INRs) in the RPKI can be associated with the real-world identity of the 'holder' of an INR. This document specifies that RPKI does not associate to the INR holder.
RPKI是一种带外机制，也就是实际上路由器和RPKI并不直接耦合。例如ROA，RPKI验证器验证了RPKI repository中的ROA，然后通过RTR协议发送给路由器，路由器不用二次验证。直接使用ROA过滤路由就行了。
RPKI这种不和路由进行耦合，也导致了它就是慢。但好处就是不修改BGP路由协议。算是有利有弊吧。
2. BGPsec
BGP协议分为iBGP和eBGP，BGPsec只运行在external BGP上。
BGPsec是需要修改BGP协议的，创建了一个新的Path Attribute：BGPsec_PATH。它在原地签名经过的AS路径，包括当前路径和下一跳路径：signs<AS Path, prefix, target ASN>。签名肯定是公钥密码体系，私钥签名公钥验证。理论上需要每个路径上的AS都进行签名，不能既有没有签名的，还有签过名的，不然肯定数量上对不上，有没有index，就全乱了，验证起来很花费时间的。所以碰到legacy路由器（就是未部署BGPsec的路由器），那就重来呗，肯定签名不对了。在协议规范RFC8205第4.1节中规定了，每个前缀都需要单独的签名，所以聚合前缀应该是不可行了（原来BGPsec也不能搞定前缀聚合啊！！！）。
但是这就有个严重的问题（看年限很久远了，现在是否严重未知）。理论上的AS-PATH可能包含任何一个ASN。假设现在已经分配的ASN都在使用中，也就是10万个AS都在使用，那么BGP路由器就需要存储这10万个AS的公钥，还要不考虑key-rollover情况下（signature中就携带有路由器公钥标识，这样找起来应该不会太费劲，就是存储占用多 ）。所以他们在研究懒验证的事情，等路由器有时间遍历签名者公钥的时候，或者等路由器负载较小的时候再去验证BGPsec签名。不过这貌似不又回到了RPKI的方式上了嘛。推动RPKI和BGPsec的本来就是NIST和IETF联合的，所以他们研究这个也很正常。计算机世界到处都是这样的妥协：例如TCP的慢启动、拥塞避免、快重传快恢复就是这样，反正先用起来，然后出现问题再纠正呗。另外这个工作叫做Aggregate Signatures for BGPsec，没找到具体的方案。通过搜索找到不是相同团队做的APAT: An Application of Aggregate Signatures to BGPSEC，数学不好，公式多，有时间再研究一下。好吧，开始给自己挖坑。
在BGP路由器接收到了一个BGPsec宣告后，它需要去验证<all AS path hops, prefix>，也就是验证整个原地签名块。所需的公钥是需要通过RTR协议从RPKI存储库中传递过来。验证结果只有valid和invalid两种，如果这个签名块完全验证通过，那么路径就是合法的。验证的结果就是用于过滤路由。
BGPsec如上面所述，是一个end-to-end安全协议，端是指AS。它是可以进行部分部署和增量部署的，也是有意义的，只是意义可能就不完整了，导致的结果就是非全网部署安全意义不大。BGPsec也可能会泄露内部拓扑信息（没搞明白，可能是因为需要eBGP路由器的公钥签名原因吧，然后签名信息中还携带了路由器的公钥标识。）
从IXP的角度来看，BGPsec这种要求end-to-end的协议在全网范围内是不实际的（又没搞懂了，大概是想说一条特别特别长的AS-PATH不切实际吧，BGP都没有的，BGPsec应该更不可能有了）。所以从IXP开始部署或许是一个良好的开始。简单来说，IXP是路由孤岛，很适合增量部署BGPsec；IXP路由对于BGP公开路由收集器是隐藏的（毕竟它在中间）；IXP之间的AS-hop很短，这样加密开销就会较小。最重要的就是，对于IXP来说，安全收益可能超过成本开销。
从Vendor的角度来看，BGPsec是开源实现居多，商业供应商的实现是落后的。嗯，确实，查了下，ISOC 2017年文章中说，Cisco、Juniper、Quagga才堪堪实现了源验证，也就是支持了RIR以及RPKI。BGPSEC还真的没影吧。而且感觉开源的也不是特别多，更新也不是很快，可以查看 bgpsec.net 的实现软件。所以说还活在研究中一点也不假。
所以说实话，BGPsec的部署还是很难，尤其是全网内end-to-end部署（哦，它这个end-to-end是指全路径吧），更有可能是部分域部署。所以，2017年那篇文章就是在唬人了。
对BGPsec的感受就是：
- Does it exist at all?
- Won't work.
- Too slow.
- Need to replace all the hardware.
- Isn't origin validation enough?
- Not scalable.
- Leaks private information.
- Does not address the real problem.
- BGP is secure anyway.
- Key management is complex.
这个调查结果，倒是挺符合对IETF社区的印象的：一个以market驱动的组织。
3. 实验
好吧，它的实验条件我没有看懂，实际上好像也都是定性的？先列下来，再琢磨吧。
- Take realistic absolute and relative state distribution numbers.
- The overall setup models a route server in a moderately sized IX.
- Instrumented implementation for performance measurement.
- No codepointhijacks.
- Feeder side is precomputedahead of time.
- Verification is performed prior to path selection.
- The results should not be generalized and interpreted outside of the experiment context.
- Number of prefixes and paths.
- Number of prefixes sharing the same path.
- Fanoutratio.
- Caching aspects.
然后实验结果就是BGP 83秒收敛，BGPsec 2049秒收敛，足足25倍。
然后就开始分析原因，主要涉及到：大量计算导致性能瓶颈、内存容量和延迟、矢量化、批处理和缓存、协议工程需要考虑软硬件细节。实际上没有迭代的产品就是优化不足。
以下是在一个BGP speaker的处理流程，不是两个分开的，是从接收到转发的过程。
3.1. BGPsec接收侧处理
主要涉及到：rx-> hash -> verify -> process prefix and path。接下来是两种算法分析，我对这个hash以及公钥了解很少，所以不太清楚具体的算法流程，HASH肯定比公钥快就是了，后面就简要跳过了。（挖坑，后面研究下各类算法以及特点吧）
- hash使用SHA2，计算不昂贵，但是内存开销大；一次性操作4字节，矢量化操作但受到数据布局限制（内存对齐呗）。
- verification使用P-256（一种椭圆曲线算法），计算非常昂贵，但不接触内存？可以进行批处理，例如ECDSA。
数据分块，并行计算。导致结果就是+20% latency results in +1500% throughput（意思应该是＋20%延时就可以提升+1500%吞吐，时间换吞吐？）。
3.2. BGPsec转发侧处理
主要涉及：{Prefix, Path and signature elements, Target} -> hash -> sign -> tx。
SHA2，和接收端处理流程一样。但需要额外的块，HASH和wire format布局不同，target ASN位置阻止了缓存的可能性。emmm，说人话就是缓存失效了呗。
P-256用于signing。计算昂贵但是不接触内存，可以矢量化处理。
矢量化处理，按照我的理解，应该就是指并行处理，例如VPP（Vector Packet Processor）中就是对于一个函数功能，一次性处理了多个数据包。如果有不当之处，后面再细细研究1, 2。
经过优化，BGPsec可以达到272秒的收敛时间，但是还是比BGP要慢3倍左右。那么BGPsec就不能用了吗？不，它只是现在还没有达到最优，没有很好的考虑硬件细节。（专门硬件？）
BGPsec就是这么复杂。重点是还要看RPKI的部署率。所幸，RPKI还在稳步推进中，不过RPKI部署率还不如IRR。