• 发表时间： 2022-10-11
  • 文章作者： zzz
  • 发表于 development

概述

I2P自2005年以来一直使用抗审查的UDP传输协议 "SSU"。 17年来，我们从未有SSU被屏蔽的报告。 然而，以今天的安全、抗封锁和性能的标准来看，我们可以做得更好，好得多。

这就是为什么我们与`i2pd项目<https://i2pd.xyz/>`_一起，创造并实现了 "SSU2"。 这是一个现代的UDP协议，按照最高的安全和抗封锁标准设计。 这个协议将取代SSU。

我们将工业标准的加密与UDP协议WireGuard和QUIC的最佳功能结合起来，以及我们的TCP协议 "NTCP2 "的抗审查功能。 SSU2可能是迄今为止最安全的传输协议之一。

Java I2P和i2pd团队正在完善`SSU2传输</spec/proposals/159>`_，我们将在下一个版本中为所有路由器启用它。 这就完成了我们长达十年的加密升级计划。 SSU2将取代`SSU </en/docs/transport/ssu>`_，这是我们唯一剩下的使用缓慢的`ElGamal <https://en.wikipedia.org/wiki/ElGamal_encryption>`_的加密协议。

  • Signature types and ECDSA signatures (0.9.8, 2013)
  • Ed25519 signatures and leasesets (0.9.15, 2014)
  • Ed25519 routers (0.9.22, 2015)
  • Destination encryption types and X25519 leasesets (0.9.46, 2020)
  • Router encryption types and X25519 routers (0.9.49, 2021)

在过渡到SSU2之后。 我们将把所有的认证和加密协议迁移到标准的 "Noise 协议<https://noiseprotocol.org/>"_握手。

所有I2P Noise 协议都使用以下标准加密算法：

目标

  • 将非对称加密技术升级到更快的X25519
  • 使用标准的对称验证式加密算法 ChaCha20/Poly1305
  • 改进SSU的混淆和抗封锁功能
  • 通过调整QUIC的策略，提高对欺骗性地址的抗性
  • 改善握手了CPU效率
  • 通过较小的握手信息和确认信息来提高带宽效率
  • 提高SSU的节点测试和中继功能的安全性
  • 通过调整后的QUIC "连接迁移" 功能，改进对节点IP和端口变化的适应。
  • 从包处理的启发式代码转向文件化、算法化处理
  • 从SSU到SSU2的逐步过渡
  • 使用NTCP2的模块化设计，易于扩展

设计

I2P使用多层加密来保护通信免受攻击，最低的一层是传输协议层，用于两个路由器之间的点对点链接。 我们目前有两个传输协议： NTCP2，一个在2018年推出的现代TCP协议。 和SSU，一个2005年开发的UDP协议。

SSU2和以前的I2P传输协议一样，不是一个通用的数据管道。 它的主要任务是安全地将I2P的低级别的`I2NP消息</spec/i2np>`_ 从一个路由器传递到另一个路由器。 这些点对点的连接包括I2P隧道中的一跳。 高层的I2P协议通过这些点对点连接运行，在I2P的目的地之间端到端传递大蒜信息。

设计UDP传输带来了独特而复杂的挑战，这是TCP协议所不具备的。 UDP协议必须处理由地址欺骗引起的安全问题，并且必须实现自己的拥堵控制。 此外，所有的信息必须被分割成碎片，以适应网络路径的最大数据包大小（MTU），并由接收方重新组装。

我们在很大程度上依赖于我们以前的NTCP2、SSU和streaming协议的经验。 然后，我们仔细审查并大量借鉴了最近开发的两个UDP协议。

在这些协议的威胁模型中，民族国家防火墙不是一个明确的部分。 然而，它是I2P威胁模型的一个重要部分，因为我们的任务是为世界各地的高危用户提供一个匿名和抗审查的通信系统。 因此，我们的大部分设计工作涉及到将从NTCP2和SSU中吸取的教训与NTCP2 和 SSU 的经验，以及 QUIC 和 WireGuard 所支持的功能和安全性。

与QUIC不同，I2P传输协议是点对点的，没有确定的服务器/客户关系。 身份和公钥都公布在I2P的网络数据库中。 握手必须对参与者的身份进行认证。

对SSU2设计的完整总结超出了本文的范围。 然而，我们在下面强调了该协议的几个特点。 强调了UDP协议设计和威胁模型的挑战。

抵抗DoS攻击

UDP协议特别容易受到拒绝服务（DoS）攻击。 通过向受害者发送大量带有欺骗性源地址的数据包。 攻击者可以诱使受害者消耗大量的CPU和带宽来响应。 在SSU2中，我们采用了QUIC和WireGuard的令牌概念。 当一个路由器收到一个没有有效令牌的连接请求时，它不会执行昂贵的加密DH操作，只是用包含有效令牌的小消息来回应。 如果启动者没有欺骗他的地址，他将收到令牌，握手可以正常进行。 这可以防止任何使用虚假地址的流量放大攻击。

报头加密

SSU2的数据包头与WireGuard类似，并以类似于QUIC的方式进行加密。

标头加密对于防止流量分类、协议识别和审查是非常重要的。 报头还包含一些信息，使攻击者更容易干扰甚至解密数据包内容甚至是解密数据包内容。 虽然民族国家防火墙主要集中在分类和破坏TCP流量上。 但我们预计，他们的UDP应对能力将增加，以应对新的UDP协议的挑战，如QUIC和WireGuard。 确保SSU2报头被充分混淆和加密是我们处理的第一项任务。

头部使用头部保护方案，通过与已知密钥计算的数据进行XOR来加密。 使用ChaCha20，类似于QUIC RFC-9001_和`Nonces are Noticed <https://eprint.iacr.org/2019/624.pdf>`_。 这确保了加密的头文件看起来是随机的，没有任何可区分的特征。

与QUIC RFC-9001_报头保护方案不同，所有报头的所有部分，包括目的地和源连接ID，都是加密的。 QUIC RFC-9001_和`Nonces are Noticed <https://eprint.iacr.org/2019/624.pdf>`_主要侧重于加密头的 "关键 "部分，即数据包编号（ChaCha20 nonce）。 虽然加密会话ID使传入的数据包分类更复杂一些，但它使一些攻击更困难。

我们的威胁模型假设审查防火墙不能实时访问I2P的网络数据库。 头信息用网络数据库中公布的或后来计算的已知密钥进行加密。 在握手阶段，报头加密只是为了抵抗流量分类。 因为解密密钥是公开的，密钥和nonces可以重复使用。 这个阶段的头加密实际上只是混淆。 请注意，头加密也用于混淆握手中的X25519瞬时密钥。 以提供额外的保护。

在数据阶段，只有会话ID字段用来自网络数据库的密钥进行了加密。 关键的nonce字段是用来自握手的密钥加密的。 因此，即使是对网络数据库有访问权的一方也不可能解密它。

数据包编号、ACKS和重传

SSU2在安全和效率方面比SSU有一些改进。 数据包编号是AEAD nonce，并且每个数据包编号只使用一次。 确认（ACK）是针对包号的，而不是I2NP消息号或片段。 ACK是以一种非常高效、紧凑的格式发送的，该格式改编自QUIC。 支持即时ACK请求机制，与SSU类似。 拥塞控制、窗口期、定时器和重传策略没有被完全指定以允许实现的灵活处理和改进空间。 指导文件是来自TCP的RFC。 计时器的其他算法来自I2P的 "streaming协议</en/docs/api/streaming>"_和SSU。

连接迁移

UDP协议很容易受到端口和IP变化的影响 导致的端口和IP的变化而被破坏，包括NAT重新绑定、IPv6临时地址变化和移动设备地址变化。 以前的SSU实现试图通过复杂和脆弱的启发式方法来处理其中的一些情况。 SSU2提供了一个正式的、有据可查的过程来检测和验证节点地址的变化，并将连接迁移到节点的新地址而不丢失数据。 它可以防止由数据包注入或攻击者修改引起的迁移。 实现连接迁移的协议是由QUIC改编和简化的。

节点测试和中继

除了传输I2NP消息外，SSU还提供两项重要的个功能。 首先，它支持对等测试，这是一个合作工程，以确定本地IP并检测网络地址转换（NAT）和防火墙设备的存在。 这种检测被用来更新路由器状态，并在I2P的网络数据库中公布当前地址和状态。 其次，它支持中继（Relaying），在这种情况下，路由器合作穿越防火墙，以便所有路由器都能接受传入的连接。 这两项服务本质上是SSU传输中的子协议。

SSU2更新了这些服务的安全性和可靠性，增加了更多的响应代码、加密、认证以及对设计和实施的限制。

性能

I2P网络是各种路由器的复杂组合，有两种主要的实现，在世界各地运行。 从高性能数据中心计算机到Raspberry Pis和Android手机。 路由器同时使用TCP和UDP传输，虽然SSU2的改进是显著的，但我们并不指望它们对用户来说是显而易见的，无论是在本地还是在端到端的传输速度上。 端到端传输取决于其他13个路由器的性能和14个点对点传输链路的性能，其中每个链路都可能是SSU2、NTCP2、或SSU。

In the live network, latency and packet loss vary widely. Even in a test setup, performance depends on configured latency and packet loss. The i2pd project reports that maximum transfer rates for SSU2 were over 3 times faster than SSU in some tests. However, they completely redesigned their SSU code for SSU2 as their previous implementation was rather poor. The Java I2P project does not expect that their SSU2 implementation will be any faster than SSU.

Very low-end platforms such as Raspberry Pis and OpenWRT may see substantial improvements from the elimination of SSU. ElGamal is extremely slow and limits performance on those platforms.

SSU2 data phase encryption uses ChaCha20/Poly1305, compared to AES with a MD5 HMAC for SSU. Both are very fast and the change is not expected to measurably affect performance.

Here are some highlights of the estimated improvements for SSU2 vs. SSU:

  • 40% reduction in total handshake packet size
  • 50% or more reduction in handshake CPU
  • 90% or more reduction in ACK overhead
  • 50% reduction in packet fragmentation
  • 10% reduction in data phase overhead

Transition Plan

I2P strives to maintain backward compatibility, both to ensure network stability, and to allow older routers to continue to be useful and secure. However, there are limits, because compatibility increases code complexity and maintenance requirements.

The Java I2P and i2pd projects will both enable SSU2 by default in their next releases (2.0.0 and 2.44.0) in late November 2022. However, they have different plans for disabling SSU. I2pd will disable SSU immediately, because SSU2 is a vast improvement over their SSU implementation. Java I2P plans to disable SSU in mid-2023, to support a gradual transition and give older routers time to upgrade. Because Java I2P release 0.9.36 and i2pd release 2.20.0 (2018) were the first to support NTCP2, routers older than that will not be able to connect to i2pd routers 2.44.0 or higher, as they have no compatible transports.

概要

The founders of I2P had to make several choices for cryptographic algorithms and protocols. Some of those choices were better than others, but twenty years later, most are showing their age. Of course, we knew this was coming, and we've spent the last decade planning and implementing cryptographic upgrades. As the old saying goes, upgrading things while maintaining backward compatibility and avoiding a "flag day" is quite challenging, like changing the tires on the bus while it's rolling down the road.

SSU2 was the last and most complex protocol to develop in our long upgrade path. UDP has a very challenging set of assumptions and threat model. We first designed and rolled out three other flavors of Noise protocols, and gained experience and deeper understanding of the security and protocol design issues. Finally, we had to research and fully understand other modern UDP protocols - WireGuard and QUIC. While the authors of those protocols didn't solve all of our problems for us, their documentation of the UDP threat models and their designed countermeasures gave us the confidence that we too would be able to complete our task. We thank them as well as the creators of all the cryptography we rely on to keep our users safe.

Expect SSU2 to be enabled in the i2pd and Java I2P releases scheduled for late November 2022. If the update goes well, nobody will notice anything different at all. The performance benefits, while significant, will probably not be measurable for most people.

As usual, we recommend that you update to the new release when it's available. The best way to maintain security and help the network is to run the latest release.