SSU2 is a new generation I2P transport protocol based on UDP

SSU is an I2P protocol, which is a cryptographic wrapper of UDP from the TCP/IP stack, that is, it is a low-level transport protocol along with NTCP2, which is a similar encrypted TCP wrapper. This layer of I2P logic provides the first layer of security for all information transferred between network participants.

SSU is literally the first I2P transport protocol, it was created before NTCP and even more so before NTCP2. Since 2003, anonymous people have been sending SSU packages across the network! Since then, the NTCP transport and even its second version have appeared, and SSU has not received any updates for almost twenty years except for minor implementation fixes and, as the developers say, crutches like IPv support6.

Without this protocol, the full functioning of the network is impossible, especially on devices without a dedicated IP address, therefore, despite the optimized operation of TCP (NTCP2), the I2P network needed SSU2 - a new generation of UDP-based transport. Nineteen years later, the Invisible Internet Project (full name I2P) appeared official discussion of the second version of the SSU protocol.

The important role of SSU in a practical context is discussed in great detail in a separate article, so let's skip the timid introduction and get to the point.

SSU2 appeared in i2pd version 2.42 (05/22/2022), its stable implementation is in 2.43 (08/21/2022), in 2.44 (11/20/2022) SSU2 is enabled by default, and from version 2.45 (01/04/2023) SSU of the first version is completely removed (release of the same The period of an I2P router in Java is numbered as 2.1.0). The almost twenty-year history of SSU is over!

Over the long history of the I2P network, developers have identified many pitfalls and found optimal approaches to solving certain problems. All the best practices found their place in SSU2, but the matter was not limited to local developments. In many ways, the protocol architecture is based on QUIC — world-famous UDP-based protocol, which is focused on security and information integrity.

For example, packet numbering was borrowed from QUIC, which greatly simplifies delivery control. The protocol is such that an acknowledgment of packet receipt does not need to be sent after each packet received. Instead, the delivery status may contain information about a batch of the most recently received network messages. SSU of the first version did not have packet numbering at all, so there was a quiet horror with the status of receiving outgoing packets, which had an extremely negative impact on the stability and, consequently, the speed of the created encrypted channels.

SSU2 is not the same SSU that works on top of QUIC instead of bare UDP, but a fundamentally new I2P protocol that incorporates many QUIC mechanisms and even a couple of details from WireGuard.

Reasons for the emergence of SSU2

1. Slow cryptography. SSU uses the old Diffie-Hellman algorithm, which requires a lot of computing power, which entails additional delays and CPU load;

2. Address spoofing vulnerability. The UDP protocol does not imply session control; all incoming information falls into one network socket and is received without a full validity check;

3. Architectural deficiencies. It is unlikely that the first developer (jrandom) saw the whole picture of the protocol at once, so he wrote the code as is, and even then began to insert crutches into the SSU as needed. The accumulated piles do not allow us to improve the protocol and program work with it at the modern level.

Performance

The most important change for the speed of the protocol was the complete abandonment of the outdated Diffie-Hellman key agreement protocol. From a security point of view, this scheme is good and is widely used these days, but the old mechanism requires a lot of calculations on each side.

Let me remind you: the essence of asymmetric cryptography is that subscribers exchange public keys and, based on the received someone else’s public and their secret, receive a value common to both parties, which is then used as an encryption key (or the base material for it).

The old, or as it is also called “slow” Diffie-Hellman in the I2P router significantly loaded the system, and for small virtual servers it was completely critical, up to 100% of the CPU at the time of calculating the shared key! Obtaining a shared key is necessary to create an encrypted communication channel and until the operation is completed, the transmission of the payload does not begin. Obvious bottleneck preventing fast data transfer.

As a solution to the problem, SSU2 uses Noise cryptographic framework, which is based on elliptic curve cryptography Ed25519. Key agreement on this curve using the x25519 scheme is the fastest asymmetric encryption scheme to date. The speed is due to the small amount of required calculations in the standard use case. However, in terms of cryptographic strength, x25519 is not inferior to alternative solutions, since in essence it is the same DH, but based on the curve — ECDH. In general, don't confuse the old DH and the new ECDH on the elliptic curve. The first is legacy, the second is base, true and modern bro.

In turn, the Noise mechanics is a comprehensive solution for reconciling and retrieving shared keys with a guarantee of non-recoverability of information after the end of the session, even if the secret key of one of the parties falls into the hands of the analyzing party.

Anti-spoofing

In SSU, a data exchange session with another network node was identified by the address and port from which the packet came, that is, what can be provided by low-level UDP, which is not intended for security or for monitoring the integrity of transmitted information.

Thanks to this vulnerability, a global observer can terminate SSU sessions, depriving the user of a significant portion of the network quality. This hole is especially relevant for users without a dedicated IP address, most of whose communications rely on UDP and, accordingly, SSU.

To carry out an attack, an observer needs to intercept a real SSU packet (that is, a UDP datagram) containing cryptographic identifiers of the sender’s I2P router, delay it, and transmit the information to the recipient in a modified form: replace the source address and port in the UDP packet headers. As a result of this manipulation, the final recipient, having a false address, will send a response to the request past the real router, which is waiting for a response. Are you smelling DDoS attacks using unsuspecting I2P routers that innocently send replies to the wrong place? True, no such attacks were registered. And now it won't be anymore.

In SSU version two (SSU2), sessions are managed without using unprotected UDP header information. Now all important information is read from the body of the packets and has the necessary cryptographic protection (encryption and signature). In addition to the fact that SSU2 is not guided by the sender address from the UDP header, it allows you to save the session if the IP address of one of the parties unexpectedly changes thanks to a special mechanism path challenge.

About DPI

SSU's greatest vulnerability to traffic analysis systems was in the characteristic HolePunch message. Hole punch or window breaking is a UDP feature that allows subscribers without a dedicated IP address to receive external requests by reserving a port on the edge router, all information from which is addressed to a specific subscriber. The old implementation of SSU implied HolePunch messages of zero length, which, when observing traffic from the outside, is a very specific and recognizable behavior: to whom should an empty message be sent, i.e. bare UDP packet headers? That's right, an I2P router. According to one of the leading developers, such things in I2P developed for historical reasons. Sometimes these reasons are hidden in the annals of history under the heading of secrecy “jrandom did it that way.” Fortunately, as the hidden network evolves, legacy solutions are being replaced by modern solutions with detailed discussions and documentation.

In SSU2, the issue with the zero-length packet has been fixed. HolePunch messages are now dynamically sized and are not separated from the general stream of encrypted UDP packets. This problem was not solved point-by-point, but disappeared due to a colossal protocol upgrade, but eliminating the hole still needed to be said separately.

Architecturally, SSU2 borrows the block system from NTCP2 (TCP-based I2P transport) as an integral part of the transport logic. This system involves an additional wrapper for all service and user messages, forming them into blocks transmitted over the network as a single whole. Thus, the same HolePunch request can be transmitted in one message with accompanying data, which in the first version of SSU inevitably came separately and in a row, creating a recognizable pattern. In addition to unpredictable content, messages with blocks have arbitrary padding, which, when observed from the outside, completely confuses all attempts to guess the content.

From a technical point of view, the block paradigm is a very flexible basis for further expansion of the protocol, since it does not require the introduction of new types of messages at the network level.

Even more about DPI

Let's clarify the topic of deep traffic analysis within models I2P community. This will allow us to understand in more detail the nature of the problem and the vectors that were taken into account when developing the protocol. A haven for discussions and armchair analytics. Not everything is as simple as they say...

It is proposed to divide the analysis into two types: online and offline.

• Online DPI checks all network traffic flows in real time. Due to the forces of such a system, connections can be blocked or somehow corrupted (as happens with requests to blocked services and sites). With the online DPI system, data about each specific connection can be saved for offline analysis.

  The following online DPI capabilities are expected:

  • Ability to view all data sent or received by the target;

  • Ability to perform operations on observed data, such as using block ciphers or hash functions;

  • Ability to store and compare with previously sent messages;

  • Ability to modify, delay or fragment packets.

  However, real-time observer DPI is assumed to have the following limitations:

  • Inability to match the IP address with I2P router hashes (RouterInfo). While this is trivial when accessing a network database (netDb) in real time, it will require a DPI system specifically designed for I2P;

  • Inability to interact with I2P to create honey pots to check subscribers for the presence of an I2P router.

• Offline DPI checks the data stored by the online system for later analysis. A standalone DPI can be designed specifically for I2P detection and have real-time access to the I2P network database (netDb and lysset information from controlled floodfills). Offline DPI developers have access to I2P specifications and unlimited computing capabilities, including all cryptographic functions.

  In this case, the theory proceeds from the fact that offline DPI does not have the ability to block existing connections, but can replay intercepted messages (modified or not) in almost real time, as well as initiate its own attempts to establish a handshake with supposed I2P routers for research or other purposes.

The challenge for SSU2 was to prevent or critically impede real-time protocol identification, thereby preventing I2P traffic from being blocked.

To counter systems built on patterns, the described monitoring model requires that all messages be indistinguishable from random ones. For this purpose, their unpredictable length and lack of a natural sequence at each stage of network interaction are implemented..

Also, to counter DPI, it is necessary to reject connection attempts that use replay of intercepted previous packets in any form: modified or original..

It would seem that it’s quite a struggle with DPI. However, preventing protocol identification by offline DPI is not the purpose of SSU2. This means that developers are aware that careful monitoring of the network will identify some of its participants. Do not detect a specific anonymous user or the hosting of a hidden resource, but only understand that someone has installed an I2P router. By the way, due to transit traffic, this will not give an idea of ​​the subscriber’s intranet activity.

Let's summarize. In the context of the DPI debate, SSU2 aims to make I2P blocking more difficult at the protocol level: detecting I2P traffic is a very large task that dwarfs the complexity of many solutions that flippantly claim to be completely undetectable. On the other hand, there is no protection against passive surveillance based on complex analysis using peer-to-peer connections (with the integration of the DPI system into I2P as a participant to collect information about routers).

In the end, identifying a router on your home computer or server only means that you read this article and, out of curiosity, downloaded the subject of discussion to your machine. The more users in the network, the more fault-tolerant the network due to decentralization.

PS.

С пессимизмом могу предположить уголовный запрет на использование анонимизирующих технологий, как это принято в тоталитарных государствах, или вовсе интернет "по белым спискам", как это сделано в Туркменистане. Светлая надежда на слова Postman'а (администратор mail.i2p): пока государство хоть как-то старается изображать право на приватность и свободу слова, технологии вроде I2P не попадут под запрет. TOR в России, кстати, попал. Правда, на уровне провайдеров, а не уголовного законодательства...