PDF为什么互联网路由安全需要这么长时间？
路由安全事件仍然可以绕过已部署的安全防御措施。
Sharon Goldberg，波士顿大学
BGP（边界网关协议）是将互联网粘合在一起的粘合剂，它实现了由不同组织运营的大型网络之间的数据通信。BGP 通过为组织之间的流量设置路由，使互联网通信实现全球化——例如，从波士顿大学的网络，通过更大的 ISP（互联网服务提供商），如 Level3、巴基斯坦电信和中国电信，然后到达住宅网络，如 Comcast 或企业网络，如美国银行。
虽然 BGP 在互联网通信中起着至关重要的作用，但它仍然非常容易受到攻击。过去几年发生了一系列路由事件，突显了 BGP 路由的脆弱性。这些事件包括：一家小型印度尼西亚 ISP 的简单错误配置导致亚洲部分地区的 Google 服务离线32；一起基于 BGP 的审查事件从巴基斯坦电信泄露，导致 YouTube 对互联网大部分地区离线2；一个路由错误导致世界上很大一部分互联网流量通过中国电信路由6；以及冰岛和白俄罗斯的网络进行的高度定向的流量拦截34。
人们已经意识到 BGP 的安全问题 लगभग 20 年了，并提出了许多解决方案，其中大多数解决方案都应用了简单且易于理解的密码学或白名单技术。然而，这些解决方案中的许多仍然在全球互联网中未部署（或未完全部署），并且漏洞仍然存在。为什么 BGP 安全需要这么长时间？
这个问题的答案在于 BGP 是一种全球协议，跨越组织和国界运行。因此，它缺乏一个可以强制部署安全解决方案的中央权威机构；相反，每个组织都可以自主决定在其自己的网络中部署哪些路由安全解决方案。因此，部署变成了数千个独立运营的网络之间的协调博弈。更复杂的是，许多安全解决方案只有在大量网络部署它们时才能良好地工作。
路由入门
BGP 使网络能够路由到目标 IP 前缀。IP 前缀是一组具有共同前缀的互联网协议地址，该前缀的长度为 n 位。例如，IP 地址集合 {8.0.0.0, 8.0.0.1,..., 8.255.255.255} 被写为 8.0.0.0/8，其中符号 /8（“斜杠八”）表示前八位（前缀）对于集合中的所有地址都是通用的（在本例中，是那些以数字 8 开头的地址）。IP 前缀可以具有可变长度，并且一个 IP 前缀中的地址可能完全包含在另一个 IP 前缀中。例如，分配给 Google 的前缀 8.8.8.0/24 完全包含在分配给 Level 3 的前缀 8.0.0.0/8 中；我们说 IP 前缀 8.0.0.0/8 覆盖 IP 前缀 8.8.8.0/24。
最长前缀匹配路由
为了决定如何转发 IP 数据包，互联网路由器会识别 最长 IP 前缀，该前缀覆盖数据包中目标 IP 地址。例如，目标 IP 地址为 8.8.8.8 的数据包将被转发到更长的 24 位 IP 前缀 8.8.8.0/24 的路由，而不是更短的 8 位 IP 前缀 8.0.0.0/8 的路由。
自治系统
BGP 允许 AS（自治系统）发现到目标 IP 前缀的路由。AS 是由不同组织运营的大型自治网络。每个 AS 都被分配一个不同的 AS 号（例如，Google [AS 15169]，中国电信 [AS 4134]，Comcast [AS 7922]，波士顿大学 [AS 111]，Verizon Wireless [AS 22394 和 AS 6167]），并被分配一组 IP 前缀。AS 是分配给它的前缀的 源。AS 互连，创建了一个图，其中节点是 AS，边是它们之间的链接，如图 1 所示。AS 通过从其邻居接收的 BGP 宣告，通过 AS 级别图发现到 IP 前缀的路由。每个 BGP 宣告都包含邻居 AS 用于到达目标 IP 前缀的 AS 级别路径。在图 1 17,41 中，IP 前缀 66.174.161.0/24 被分配给 Verizon Wireless，其 AS 22394 通过向 AS 6167 发送以下 BGP 宣告，将前缀 发起 到路由系统中
22394
66.174.161.0/24
AS 6167 选择路由，并将所有针对前缀 66.174.161.0/24 的流量转发到其邻居 AS 22394。然后，AS 6167 将其自身名称附加到路径，并将该路径宣告给其邻居 AS 2828 和 AS 3356，如下所示
6167, 22394
66.174.161.0/24
Level 3 的 AS 3356 选择该路径，并将其继续宣告给其邻居 AT&T AS 7018，如下所示
3356, 6167, 22394
66.174.161.0/24
这个过程持续下去，并且到前缀 66.174.161.0/24 的 AS 级别路径在网络中传播。
业务关系和路由策略
如果一个 AS 学习到到特定 IP 前缀的多条路由，那么它将使用其本地路由策略选择一条最优选的路由。BGP 为 AS 提供了相当大的灵活性，使其可以灵活地选择其路由。路由决策通常独立于给定时刻路由的性能；相反，它们基于多种因素，包括路由长度（即 AS 级别路径上的 AS 数量）以及将流量转发到宣告路由的邻居的价格。
转发流量的价格取决于相邻 AS 之间的 业务关系9,19,20。虽然存在许多业务关系，但这里有两种特别相关。第一种是 客户-提供商 关系，其中客户 AS 向提供商 AS 付费以发送和接收流量；Level 3 和 Verizon Wireless 具有客户-提供商关系，在图 1 中用从客户（Verizon Wireless）到提供商（Level 3）的有向边表示17。第二种相关的业务关系是 免结算对等互连，其中两个 AS 同意免费传输彼此的流量；Level 3 和 AT&T 具有对等互连关系，在图 1 中用无向边表示。
如果一个 AS 无法通过转发流量来产生收入，那么它几乎总是会避免将流量从一个邻居转发到另一个邻居；例如，图 1 中的中国电信 AS 4134 不会将来自其对等方 Level 3 (AS 3356) 的流量传输到其另一个对等方 AT&T (AS 7018)，因为这两个邻居都没有为这项服务向中国电信付费。因此，中国电信不会向 AT&T (AS 7018) 发送 BGP 宣告，以宣告其从图 1 中的 Level 3 (AS 3356) 学习到的前缀路由。
这种经济动机驱动的行为9,19,20 通常概括为以下 经验法则：AS a 通常只会向相邻 AS n 宣告路由，如果：(1) n 是 a 的客户；(2) 路由是针对 a 发起的前缀；或者 (3) 路由是通过 a 的客户。
对 BGP 的攻击
BGP 设计于 1990 年代初期——一个更简单的时代，当时互联网的争议较少。因此，BGP 缺乏基本的身份验证机制，使其极易受到攻击。我们使用几个真实的路由事件来说明这些漏洞。
劫持
BGP 缺乏对 IP 前缀分配给自治系统进行身份验证的机制；前缀劫持者通过发起一个未分配给其 AS 的前缀来利用这一点。劫持可以分为两种类型：前缀 劫持和 子前缀 劫持。
前缀劫持。 在前缀劫持中，劫持 AS 发起与合法分配了受害者 IP 前缀的 AS 完全相同的前缀。劫持 AS 发起的虚假 BGP 宣告将在整个路由系统中传播，其他 AS 将使用其本地策略在到合法源 AS 和劫持 AS 发起的虚假路由之间进行选择。
在 2010 年 4 月 8 日的 18 分钟内，中国电信针对 15% 的互联网前缀发起了前缀劫持6,17。虽然没有证据表明该事件是由错误配置以外的任何原因造成的，但它为“经典”前缀劫持提供了一个有益的例子。图 217 显示了其中一次劫持17：中国电信的 AS 22724 劫持了 Verizon Wireless 的前缀 66.174.161.0/24。AS 22724 发起的虚假路由在 AS 级别图中传播，并最终被 AT&T 选择，因为它比 Verizon Wireless 的 AS 22394 发起的合法路由更短。与此同时，Level3 选择合法路由，因为它比虚假路由更短。因此，网络流量在劫持 AS 和合法源 AS 之间分配，分配的性质取决于各个 AS 使用的路由策略以及 AS 级别图的拓扑结构。
子前缀劫持。 子前缀劫持是一种更恶劣的攻击，可能允许劫持者拦截 100% направленный受害者 IP 前缀的网络流量。在子前缀劫持中，劫持 AS 发起受害者 IP 前缀的子前缀——即受害者 IP 前缀覆盖的前缀。
也许最著名的子前缀劫持发生在 2008 年 2 月 24 日，当时巴基斯坦电信导致 YouTube 下线。该事件2 始于巴基斯坦当局要求在巴基斯坦境内审查 YouTube。为了实现这一目标，巴基斯坦电信的 AS 17557 通过发起 YouTube 前缀 208.65.153.0/22 的子前缀 208.65.153.0/24 给其在巴基斯坦的客户 AS（例如，阿迦汗大学、拉合尔证券交易所、联合银行巴基斯坦），如图 3 所示37,41，从而发起了子前缀劫持。这意味着 направленный YouTube 在 AS 36561 服务器的流量将改为转发到巴基斯坦电信 AS 17557 发起的 更长 IP 前缀，流量随后可以在那里被丢弃。
当巴基斯坦电信的虚假 BGP 宣告泄露到巴基斯坦境外时，事件发生了意想不到的转折。为巴基斯坦电信提供全球网络连接的大型 ISP PCCW 接收到虚假路由宣告，选择了虚假路由，并将其宣告给自己的邻居。由于虚假路由的前缀长度 (/24) 比合法路由 (/22) 更长，最长前缀匹配路由意味着虚假路由 总是 比合法路由更优选，并且在几分钟内，至少有三分之二的互联网将其 YouTube 流量发送到巴基斯坦2。该事件最终通过 YouTube、PCCW 和全球其他 ISP 的网络运营商的人工干预得到解决。
检测劫持。 前缀劫持似乎很容易检测，只需检查特定前缀是否由多个 AS 发起即可。然而，单个前缀可能出于合法原因由多个 AS 发起（例如，AS 级别拓扑结构中不同部分的多个 AS 可能发起单个前缀以减少延迟，以便其他 AS 可以“更接近”前缀）。在某些情况下，只有前缀的合法持有者才能绝对确定前缀是否被劫持。使用异常检测技术识别劫持是当前研究的一个活跃领域3,21。
路由泄露
路由泄露是另一类常见的路由事件28。这些泄露特别有趣，因为它们不涉及宣告虚假路由。相反，肇事者宣告了它实际正在使用的合法路由，但将其宣告给 太多 的邻居。然后，肇事者会被来自选择泄露路由的邻居的流量洪流淹没。
图 432,33 说明了印度尼西亚本地 ISP Moratel (AS 23947) 参与的此类事件。Moratel 并非设计用于传输来自国际通信提供商（如 PCCW (AS 3491)）到重要内容提供商（如 Google (AS 15169)）的大量流量。根据第一部分的经验法则，因此 Moratel 不应将其到前缀 8.8.8.0/24 的路由宣告给其提供商 PCCW。
然而，在 2012 年 11 月 6 日，Moratel 的错误配置确实做到了这一点，将路由 “泄露”
23947, 15169
8.8.8.0/24
给 PCCW。理解为什么这会产生影响需要了解 PCCW 的本地路由策略。许多路由器9,19,20，可能包括 PCCW 的 AS 中的路由器，都配置为优先选择通过邻居客户的路由，而不是通过邻居免结算对等方的路由。通过通过其客户转发流量，AS 可以产生更多收入。因此，PCCW 的路由器优先选择通过客户 Moratel 的路由，而不是通常的直接到 Google AS 15196 的免结算对等互连路由。结果，Moratel 收到了来自 PCCW 的大量网络流量，这迅速导致 Moratel 网络的部分地区离线，并使 8.8.8.0/24 对 PCCW 及其一些邻居（包括 AS 4436）不可访问。
路由事件的影响
此类事件可能会以不同的方式影响路由，这些方式可以分为 黑洞 或 拦截。
黑洞。 在黑洞中，网络流量在肇事者 AS 处停止，并且永远无法到达其合法目的地。黑洞会导致最终用户可见的网络中断。黑洞的发生是因为 BGP 路由决策通常独立于路由的瞬时性能。Moratel 事件是一个典型的路由泄漏导致黑洞的例子。劫持也可能导致黑洞；巴基斯坦电信/YouTube 事件创建了一个黑洞，因为巴基斯坦电信的所有邻居都选择了其虚假路由，导致巴基斯坦电信没有到 YouTube 的工作路由，并迫使其丢弃 направленный YouTube 前缀的流量。
拦截。 当肇事者 AS 拦截 направленный受害者 IP 前缀的流量，然后静默地将其传递给合法源 AS 时，就会发生流量拦截。拦截对最终用户是不可见的。只要肇事者具有到合法源 AS 的工作路由以及足够的网络容量来传输其吸引的额外流量，路由泄露和劫持都可能导致流量拦截。2010 年中国电信劫持就是一个例子。图 2 显示了中国电信的路由器之一如何向其邻居宣告虚假的劫持路由，而其他中国电信路由器则保持了到前缀合法源的工作路由。然后，流量从劫持路由器，通过中国电信的高容量网络，返回到更广泛的互联网，并最终到达受害者 IP 前缀的合法源 AS2,17。Renesys 去年观察到了类似的事件，该公司报告了几起短暂的劫持事件，这些事件导致 направленный目标 IP 前缀的流量被位于冰岛和白俄罗斯的 AS 拦截34。
防御措施
许多此类事件可以通过基于简单密码学或白名单技术的安全解决方案来消除。本节着眼于这些解决方案——前缀过滤、RPKI（资源公钥基础设施）和 BGPSEC——并强调在全球互联网上部署它们所涉及的挑战。
前缀过滤
前缀过滤是一种用于过滤掉虚假 BGP 宣告的白名单技术。它基于第一部分的经验法则，该法则暗示 AS（例如，图 3 中的巴基斯坦电信）只会向其提供商（PCCW）宣告 BGP 路由，如果这些路由是：(1) 针对其自身分配的前缀；或 (2) 通过其自身的客户（阿迦汗大学、拉合尔证券交易所等）。因此，提供商通常可以枚举由其客户宣告的一小部分 IP 前缀：即分配给巴基斯坦电信及其巴基斯坦客户 AS 的 IP 前缀集合。因此，提供商可以为每个客户保留这些 IP 前缀的 前缀列表，并在来自客户的 BGP 宣告不针对列表上的前缀时丢弃它们。
优点：前缀过滤简单有效。 由于前缀过滤器是一个简单的白名单，因此它通常不会给路由器带来很大的计算负担。自 1990 年代后期以来，各种 ISP 一直使用前缀过滤，并且它是防御客户 AS 发起的劫持和泄露的高度有效防御措施。我们的研究表明，如果每个拥有至少 25 个客户 AS 的互联网提供商都正确部署前缀过滤器，这将阻止很大一部分互联网 AS 发起路由泄露或劫持12。此外，如果 PCCW 在 2008 年 4 月正确配置了前缀过滤器，那么巴基斯坦电信对 YouTube 的劫持可能永远不会发生。2012 年 11 月的 Moratel 路由泄露也是如此。
挑战：前缀过滤仅在客户链接上有效。 然而，前缀过滤器通常仅过滤来自 客户 AS 的 BGP 宣告；这是因为前缀过滤器建立在这样的假设之上，即被过滤的 AS 将仅向过滤 AS 宣告 少量 IP 前缀。前缀过滤通常不用于过滤来自提供商或免结算对等方的 BGP 宣告。例如，图 2 中的 2010 年中国电信事件不可能通过前缀过滤来预防，因为中国电信沿着中国电信 (AS 4134) 和 AT&T (AS 7018) 之间的免结算对等互连边缘宣告了虚假路由。
挑战：倾斜的激励机制。 部署前缀过滤器的激励机制有些倾斜。例如，2008 年巴基斯坦电信/YouTube 事件的“受害者”是 YouTube 和所有无法访问 YouTube 被劫持前缀的受影响 AS。然而，唯一可以通过使用前缀过滤来预防该事件的 AS 是 PCCW 本身；在其他受害者 AS 上部署前缀过滤器对于阻止被劫持的路由在互联网上传播没有任何作用。因此，部署前缀过滤器 (例如，PCCW) 的 AS 没有特别强烈的动机这样做，除了保护 互联网的其余部分 免受其 自身客户 的攻击。
RPKI：密码源验证
前缀过滤的问题导致了许多替代安全解决方案的开发。当前具有显着吸引力的一种方法是 RPKI26。RPKI 自本年代初开始部署，它提供从分配的 IP 前缀到授权在 BGP 中发起它们的 AS 的可信映射。为此，RPKI 建立了一个 权威机构 的密码层次结构，这些机构分配和再分配 IP 地址空间，并授权其在 BGP 中的使用。
RPKI 层次结构的根位于 RIR（地区互联网注册管理机构）；每个大陆大约有一个 RIR：欧洲的 RIPE；北美的 ARIN；拉丁美洲的 LACNIC；非洲的 AfriNIC；以及亚太地区的 APNIC。图 55 显示了 ARIN 如何将前缀 8.0.0.0/8 分配给 Level 3，后者将前缀 8.8.8.0/24 再分配给 Google；这些分配是使用密码证书完成的。前缀的密码证书持有者随后可以签署 ROA（路由源授权），授权在 BGP 中发起前缀（或其子前缀）；例如，在图 5 中，Google 发布了一个 ROA，授权其 AS 15169 发起 8.8.8.0/24。
优点：离线密码学。 RPKI 不需要对 BGP 消息格式进行任何修改；也不需要在路由期间在线执行任何密码学操作。相反，每个 AS 每天将其本地缓存同步到存储 RPKI 对象的公共存储库，以密码学方式验证其本地缓存中的 RPKI 对象，并将生成的白名单（映射 IP 前缀及其授权的源 AS）推送到其 AS 中的边界路由器26。
优点：防止劫持。 路由器使用此白名单来过滤被劫持的 BGP 路由（即，那些具有未经授权的源 AS 的路由）。例如，在图 2 中，AT&T 可以使用 RPKI 来确定路由
3356, 6167, 22394, 22394
66.174.161.0/24
是合法的；AS 22394 是路由的源，并且图 5 的 RPKI 中有一个 ROA 授权 AS 22394 发起 66.174.161.0/24。与此同时，图 2 中中国电信 AS 22724 发起的路由是虚假的，因为没有 ROA 授权 AS 22724 发起 66.174.161.0/24。
优点：有效的激励机制。 RPKI 还避免了困扰前缀过滤的两个问题：它可以用于过滤 任何 邻居（不仅仅是邻居客户）发出的 BGP 宣告，并且它避免了倾斜的部署激励机制。在 RPKI 部署的第一阶段，想要保护其 发起 的路由的 AS 可以使用其发起路由的 ROA 填充 RPKI 存储库。（今天，RPKI 包含大约 4% 的 BGP 中宣告的路由的 ROA31。）在 RPKI 部署的第二阶段，AS 可以使用 RPKI 来丢弃虚假路由，从而保护其 选择 的路由。（目前我们正处于这个阶段的早期步骤，全球只有少数 AS 正在试验基于 RPKI 的过滤。）
挑战：RPKI 撤销和错误配置。 RPKI 部署的一个关键挑战源于 RPKI 本身的滥用5,7,8,30。RPKI 被设计为一种威胁模型，其中 BGP 受到攻击，但 RPKI 是可信的。RPKI 本身是否会受到攻击、错误配置或在法律上被迫将合法 BGP 路由错误分类为虚假路由？（DNS 受制于撤销域名的法律命令14,35；RPKI 是否可以用于撤销 IP 前缀？类似的问题已经在几个法庭案件中出现13,22,29。）由于路由器使用 RPKI 来过滤虚假 BGP 路由，因此路由器将失去对错误分类路由的访问权限。这意味着 RPKI 创建了一个新的攻击向量，可以用于黑洞路由。RPKI 标准社区已经知道这些问题，并且正在通过开发配置工具24,31,36 和故障安全机制16, 23 来加强 RPKI 以应对此类滥用。现在判断这些努力的结果还为时过早。
挑战：RPKI 可以被规避。 不幸的是，RPKI 无法阻止某些类型的攻击。
第一个是路由泄露。RPKI 旨在检测具有未经授权的源 AS 的路由，但在路由泄露中，肇事者泄露了具有授权源 AS 的合法路由。例如，即使图 4 中的 nLayer (AS 4436) 一直在基于 RPKI 过滤路由，它仍然会选择“泄露”的 Moratel 路由，因为 Google 是前缀 8.8.8.0/24 的合法源。
第二个是 路径缩短攻击，其中攻击者宣告到终止于授权源 AS 的前缀的短虚假路径。例如，即使 RPKI 完全部署，如果中国电信 (AS 4134) 宣告路由
4134, 22394
66.174.161.0/24
到图 2 中的 AT&T，它仍然可以拦截流量。要了解原因，请注意该路由具有合法的 源 AS (AS 22394)，但该路由实际上是虚假的：AS 4134 和 AS 22394 之间没有边缘。因此，即使 AT&T 使用 RPKI 来过滤路由，它仍然会选择到中国电信的虚假路由，因为它具有合法的源 AS，并且比通过 Level 3 的合法路由更短。
幸运的是，然而，研究1,12,27 表明，与子前缀劫持相比，选择泄露或缩短路由的 AS 可能更少。在子前缀劫持期间，劫持者利用最长前缀匹配路由来（可能）说服互联网上的 所有 AS 选择虚假路由。与此同时，路由泄露和路径缩短攻击都不会利用最长前缀匹配路由。相反，它们会导致流量在合法路由和泄露/缩短路由之间分配，大部分流量采用合法路由12,27。分配的性质由路由策略和 AS 级别拓扑结构决定（因为更接近攻击者的 AS 更可能选择攻击者的路由）。
BGPSEC：密码路径验证
社区已经考虑了许多可以消除针对 RPKI 发起的攻击的解决方案。有关这些解决方案（从密码协议修改到异常检测技术）的优秀调查报告是可用的3,21。在这里，我们重点关注 BGPSEC，这是 IETF（互联网工程任务组）当前正在标准化的协议25。BGPSEC 基于 RPKI 保证 BGP 路由具有授权源 AS 的基础上，还提供了 路径验证。
BGPSEC 通过向 BGP 消息添加密码签名来构建在 RPKI 之上。它要求每个 AS 对其发送的每条 BGP 消息进行数字签名。BGPSEC 消息上的签名涵盖 (1) 前缀和 AS 级别路径；(2) 接收 BGPSEC 消息的 AS 的 AS 号；并包括 (3) 从路径上的先前 AS 接收的所有签名消息。例如，在图 2 中，AT&T 的 AS 7018 将从 Level 3 的 AS 3356 接收以下 BGPSEC 消息
[66.174.161.0/24: 7018; 3356; 6167; 22394]3356
[66.174.161.0/24: 3356; 6167; 22394]6167
[66.174.161.0/24: 6167; 22394]22394
其中符号 [m]A 表示由 AS A 签名的消息 m。收到 BGPSEC 宣告后，AS 验证签名，并在签名无效时过滤路由。
优点：无路径缩短攻击。 BGPSEC 消除了路径缩短攻击。在图 2 中，中国电信 (AS 4134) 宣告了路径
4134, 22394
66.174.161.0/24
到 AT&T。使用 BGPSEC，此攻击将失败。中国电信 (AS 4134) 不会收到 BGPSEC 宣告
[66.174.161.0/24: 4134; 22394]22394
来自 Verizon Wireless (AS 22394)，因为 AS 22394 和 AS 4134 不是邻居，因此无法形成“缩短”的虚假路径，该路径通过了 BGPSEC 要求的数字签名检查。
挑战：在线密码学。 与迄今为止讨论的解决方案不同，BGPSEC 是一种 在线 密码协议；路由器必须对其发送的每条 BGP 消息进行密码签名和验证。这种高计算开销可能需要使用加密硬件加速器升级路由器，这可能会减慢 BGPSEC 的部署速度。
挑战：向 BGPSEC 的过渡。 这里考虑的所有安全解决方案都面临一个挑战，即每个 AS 将根据其自身的业务目标来决定是否部署它们。BGPSEC 的这一挑战尤为严峻，因为除非路径上的所有 AS 都已将签名应用于消息，否则 AS 无法验证 AS 级别路径的正确性（因此也无法过滤虚假路由）。这意味着 BGPSEC 的安全优势仅在路径上的 每个 AS 都部署了 BGPSEC 之后才适用。这与此处讨论的其他两个解决方案（前缀过滤和 RPKI）形成鲜明对比，在后两种解决方案中，只有执行过滤的 AS 需要部署安全解决方案。这造成了一个鸡生蛋蛋生鸡的问题；BGPSEC 的安全优势仅在大量 AS 部署 BGPSEC 后才适用，但对于任何人来说，成为第一个部署 BGPSEC 的人几乎没有安全激励。
有很多方法可以解决这个鸡生蛋蛋生鸡的问题。一种想法是，一组早期采用者 AS 将部署 BGPSEC（例如，为了符合法规、因为补贴或为了公共关系目的），然后触发 BGPSEC 部署的级联效应4,10。支持部署 BGPSEC 的一个论点是，由于 BGPSEC 必然会影响路由选择，因此部署了 BGPSEC 的 AS 可能会从其客户那里吸引更多产生收入的流量，这些客户更喜欢选择 BGPSEC 安全的路由。我们的研究表明，这些经济激励以及其他几个条件可能会产生级联效应，从而导致互联网上大多数 AS 采用 BGPSEC10。
除了经济激励之外，还存在一个问题，即在向 BGPSEC 过渡期间，当一些 AS 采用它而其他 AS 没有采用时，能提供哪些安全优势。 遗憾的是，答案并不那么乐观。 鉴于在向 BGPSEC 过渡期间可能最流行的路由策略11，我们最近的研究认为，BGPSEC 提供的安全性改进仅仅略高于 RPKI 已经可以提供的安全性。27 这是因为 AS 可能会优先考虑经济因素而非安全问题。 例如，如果需要在通过提供商的昂贵的、BGPSEC 安全路由和通过客户的廉价的、不安全的 BGP 路由之间做出选择，则 AS 可能会选择廉价的不安全路径。 因此，即使已部署 BGPSEC 的 AS 也可能遭受协议降级攻击，攻击者在协议降级攻击中说服他们选择虚假路径而不是合法的 BGPSEC 安全路径。
结论
今天，我们生活在一个不完美的世界中，路由安全事件仍然可能绕过已部署的安全防御措施，并且没有单一的路由安全解决方案可以完全阻止路由攻击。 然而，研究表明，RPKI 与前缀过滤相结合可以显着提高路由安全性； 这两种解决方案都基于白名单技术，并且可以减少受前缀劫持、路由泄漏和路径缩短攻击影响的 AS 数量。 仍然有几个部署挑战需要克服，因为前缀过滤受到不对称部署激励的限制，而 RPKI 引入了对中心化机构的新依赖。
本文重点关注基于协议的 BGP 攻击。 最近的研究38,39 和媒体披露15,18,40 表明，路由器本身可能会以绕过基于协议的防御措施（例如前缀过滤、RPKI 和 BGPSEC）的方式遭到入侵。 因此，虽然我们在基于协议的路由安全防御方面不断取得进展，但路由安全的下一个前沿很可能是在于加强互联网路由器中使用的软件和硬件。
致谢
感谢所有与我合作进行本文所依据研究的合作者：Kyle Brogle、Danny Cooper、Phillipa Gill、Shai Halevi、Ethan Heilman、Pete Hummon、Alison Kendlar、Robert Lychev、Aanchal Malhotra、Leonid Reyzin、Jennifer Rexford、Michael Schapira 和 Tony Tauber。 我非常感谢 NSF (1017907)、思科和斯隆基金会为我们对该主题的研究提供资助。
参考文献
1. Ballani, H., Francis, P., Zhang, X. 2007. A study of prefix hijacking and interception in the Internet. Proceedings of the SIGCOMM 2007 Conference: 265-276.
2. Brown, M. 2008. Pakistan hijacks YouTube. Renesys blog; http://www.renesys.com/blog/2008/02/pakistan_hijacks_youtube_1.shtml.
3. Butler, K., Farley, T. McDaniel, P., Rexford, J. 2010. A survey of BGP security issues and solutions. In Proceedings of the IEEE 98(1): 100-122.
4. Chan, H., Dash, D., Perrig, A., Zhang, H. 2006. Modeling adoptability of secure BGP protocols. Proceedings of the SIGCOMM 2006 Conference. 36(4): 279-290.
5. Cooper, D., Heilman, E., Brogle, K., Reyzin, L., Goldberg, S. 2013. On the risk of misbehaving RPKI authorities. In Proceedings of the 12th Workshop on Hot Topics in Networks (HotNets XII).
6. Cowie, J. 2010. China’s 18-minute mystery. Renesys blog; http://www.renesys.com/blog/2010/11/chinas-18-minute-mystery.shtml.
7. FCC Communications Security, Reliability and Interoperability Council III (CSRIC). 2012. Secure BGP deployment. Communications and Strategies; http://transition.fcc.gov/bureaus/pshs/advisory/csric3/CSRICIII_9-12-12_WG6-Final-Report.pdf.
8. FCC Communications Security, Reliability and Interoperability Council, Working Group 6. 2013. Secure BGP deployment, final report. http://transition.fcc.gov/bureaus/pshs/advisory/csric3/CSRIC_III_WG6_Report_March_%202013.pdf
9. Gao, L., Rexford, J. 2001. Stable Internet routing without global coordination. IEEE/ Transactions on Networking 9(6): 681-692.
10. Gill, P., Schapira, M., Goldberg, S. 2011. Let the market drive deployment: a strategy for transitioning to BGP security. In Proceedings of the SIGCOMM 2011 Conference: 14-25.
11. Gill, P., Schapira, M., Goldberg, S. 2013. A survey of interdomain routing policies. SIGCOMM Computer Communication Review 44(1):28-34.
12. Goldberg, S., Schapira, M., Hummon, P., Rexford, J. 2010. How secure are secure interdomain routing protocols? In Proceedings of the SIGCOMM 2010 Conference: 87-98.
13. Goldman, E. 2006. Sex.com–An update. Technology and Marketing Law blog; http://blog.ericgoldman.org/archives/2006/10/sexcom_an_updat.htm.
14. Government Printing Office. 2011. H.R.3261 - Stop Online Piracy Act.
15. Greenwald, G. 2014. How the NSA tampers with US-made Internet routers. The Guardian (May 12).
16. Heilman, E., Cooper, D., Reyzin, L., Goldberg, S. 2014. From the consent of the routed: improving the transparency of the RPKI. Proceedings of the SIGCOMM 2014.
17. Hiran, R., Carlsson, N., Gill, P. 2013. Characterizing large-scale routing anomalies: a case study of the China Telecom incident. In Passive and Active Measurement: 229-238. Springer Berlin Heidelberg.
18. Horchert, J., Appelbaum, J., Stöocker, C. 2013. Shopping for spy gear: catalog advertises NSA toolbox. Der Spiegel (December 29); http://www.spiegel.de/international/world/catalog-reveals-nsa-has-back-doors-for-numerous-devices-a-940994.html.
19. Huston, G. 1999. Interconnection, peering and settlements, part I. Internet Protocol Journal 2(1).
20. Huston, G. 1999. Interconnection, peering and settlements, Part II. Internet Protocol Journal 2(2).
21. Huston, G., Rossi, M., Armitage, G. 2011. Securing BGP: a literature survey. IEEE Communications Surveys and Tutorials 13(2): 199-222.
22. Mueller, M. L., Internet Governance Project. 2011. In important case, RIPE-NCC seeks legal clarity on how it responds to foreign court orders; http://www.internetgovernance.org/2011/11/23/in-important-case-ripe-ncc-seeks-legal-clarity-on-how-it-responds-to-foreign-court-orders/.
23. Kent, S., Mandelberg, D. 2014. Suspenders: a fail-safe mechanism for the RPKI. Internet Engineering Task Force (IETF); http://tools.ietf.org/html/draft-kent-sidr-suspenders-01.
24. LACNIC Labs. RPKI looking glass; http://www.labs.lacnic.net/rpkitools/looking_glass/.
25. Lepinski, M., ed. 2014. BGPSEC protocol specification. IETF Network Working Group; http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-05.
26. Lepinski, M., Kent, S. 2012. RFC 6480: an infrastructure to support secure Internet routing. Internet Engineering Task Force (IETF); http://tools.ietf.org/html/rfc6480.
27. Lychev, R., Goldberg, S., Schapira, M. 2013. BGP security in partial deployment. Is the juice worth the squeeze? In Proceedings of the SIGCOMM 2013 Conference: 171-182.
28. McPherson, D., Amante, S., Osterweil, E., Mitchell, D. eds. 2013. Draft: Route-leaks & MITM attacks against BGPSEC. IETF Network Working Group; http://tools.ietf.org/html/draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.
29. Miller, R. 2014. Court ruling: Israeli and US terrorism victims now “own” Iran’s Internet. Joshuapundit blog (June 25); http://joshuapundit.blogspot.com/2014/06/court-ruling-israeli-and-us-terrorism.html.
30. Mueller, M., Kuerbis, B. 2011. Negotiating a new governance hierarchy: an analysis of the conflicting incentives to secure Internet routing. Communications and Strategies 81: 125-142.
31. National Institute of Standards and Technology. RPKI deployment monitor; http://www-x.antd.nist.gov/rpki-monitor/.
32. Paseka, T. 2012. Why Google went offline today and a bit about how the Internet works. Cloudflare blog (November 6); https://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about.
33. PeeringDB. 2014; https://www.peeringdb.com/.
34. Peterson, A. 2013. Researchers say U.S. Internet traffic was re-routed through Belarus. That’s a problem. Washington Post (November 20).
35. Piscitello, D. 2012. Guidance for preparing domain name orders, seizures and takedowns. Thought Paper, ICANN (March).
36. RIPE Network Coordination Centre. RPKI validator; http://localcert.ripe.net:8088/trust-anchors.
37. RIPE Network Coordination Centre. 2008. YouTube hijacking: A RIPE NCC RIS case study. RIPE NCC Blog; http://www.ripe.net/internet-coordination/news/industry-developments/youtube-hijacking-a-ripe-ncc-ris-case-study.
38. Schuchard, M., Thompson, C., Hopper, N., Kim, Y. 2012. Taking routers off their meds: why assumptions of router stability are dangerous. In Proceedings of the Network and Distributed System Security Symposium (NDSS).
39. Schuchard, M., Thompson, C., Hopper, N., Kim, Y. 2013. Peer pressure: exerting malicious influence on routers at a distance. In IEEE 33rd International Conference on Distributed Computing Systems (ICDCS): 571-580.
40. Storm, D. 2014. 17 exploits the NSA uses to hack PCs, routers and servers for surveillance. ComputerWorld (January 3); http://blogs.computerworld.com/cybercrime-and-hacking/23347/17-exploits-nsa-uses-hack-pcs-routers-and-servers-surveillance.
41. Wang, L., Park, J., Oliveira, R., Zhang, B. Internet AS-level topology archive; http://irl.cs.ucla.edu/topology/.
LOVE IT, HATE IT? LET US KNOW
Sharon Goldberg 是波士顿大学计算机科学助理教授。 她的研究重点是网络安全，特别是与核心互联网相关的问题。
© 2014 1542-7730/14/0800 $10.00
最初发表于 Queue vol. 12, no. 8—
在 数字图书馆 中评论本文
更多相关文章
Paul Vixie - 保持静态或回家
当前和历史上计算机与网络安全中的大多数问题都归结为一个简单的观察：让其他人控制我们的设备对我们不利。 在另一个时间，我将解释“其他人”和“不利”的含义。 就本文而言，我将完全关注我对控制的理解。 我们失去对设备控制的一种方式是外部分布式拒绝服务 (DDoS) 攻击，这种攻击用不需要的流量填充网络，从而没有空间容纳真正的（“需要的”）流量。 其他形式的 DDoS 攻击类似：例如，低轨道离子炮 (LOIC) 的攻击可能不会完全填满网络，但它可以使 Web 服务器忙于响应无用的攻击请求，以至于服务器无法响应任何有用的客户请求。
Axel Arnbak, Hadi Asghari, Michel Van Eeten, Nico Van Eijk - HTTPS 市场中的安全崩溃
HTTPS（超文本传输协议安全）已发展成为安全 Web 浏览的事实标准。 通过基于证书的身份验证协议，Web 服务和互联网用户首先使用 TLS/SSL 证书相互验证身份（“握手”），对 Web 通信进行端到端加密，并在浏览器中显示挂锁，以指示通信是安全的。 近年来，HTTPS 已成为保护在线社交、政治和经济活动的重要技术。
Ben Laurie - 证书透明度
2011 年 8 月 28 日，一个错误颁发的 google.com 通配符 HTTPS 证书被用于对伊朗的多个用户进行中间人攻击。 该证书由一家荷兰 CA（证书颁发机构）DigiNotar 颁发，DigiNotar 是 VASCO Data Security International 的子公司。 后来的分析表明，DigiNotar 在一个多月前就意识到了其系统中的漏洞——至少从 7 月 19 日起。 它还表明，至少颁发了 531 个欺诈性证书。 最终计数可能永远不会知道，因为 DigiNotar 没有所有错误颁发的证书的记录。
Christoph Kern - 保护错综复杂的 Web
脚本注入漏洞是 Web 应用程序开发的一个祸根：从原因和补救措施来看，它们具有欺骗性的简单性，但在大规模 Web 开发中，它们却出奇地难以预防。
© 保留所有权利。