Как добавить блог в сервис Форумка???

ZLT say:

SSU2 is a new generation I2P transport protocol based on UDP

Hornbeam

10 min

View Original

KDPV

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

SSU is the first I2P transport protocol in the literal sense, it was created before NTCP and even more so before NTCP2. Since the bearded year 2003, anonymous people have been chasing SSU packets over the network! Since then, NTCP transport and even its second version have appeared, and SSU has not received any updates for nearly twenty years, except for minor implementation fixes and, as the developers say, crutches like IPv6 support.

Without this protocol, the full functioning of the network is impossible, especially on devices without a dedicated IP address, therefore, despite the optimized work on TCP (NTCP2), the I2P network needed SSU2, a new generation of transport based on UDP. After nineteen years of existence of the Invisible Internet Project (full name I2P), there was an 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 we will omit the timid introduction and get to the point.

SSU2 appeared in i2pd version 2.42 (05/22/2022), its stable implementation - 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 (the release of the same period of the I2P router in Java is numbered as 2.1.0). Almost twenty years of SSU history is over!

Over the long history of the I2P network, developers have identified many pitfalls and found optimal approaches to solving some 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 , a world-famous UDP-based protocol that focuses on the security and integrity of information.

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

SSU2 is not the same SSU that runs 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 appearance of SSU2

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

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 flaws. It is unlikely that the first developer (jrandom) saw the whole picture of the protocol at once, so he wrote the code as it is, even then starting to insert crutches into SSU as needed. The accumulated heaps do not allow improving the protocol and programming 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 ubiquitous these days, but the old mechanism requires a lot of computation 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 basic material for it).

The old, or as it is also called, the "slow" Diffie-Hellman in the I2P router noticeably 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 payload transfer does not begin. Obvious bottleneck preventing fast data transfer.

As a solution to the problem, SSU2 uses the Noise cryptographic framework, which is based on Ed25519 elliptic curve cryptography. The x25519 key agreement on this curve 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 it is essentially the same DH, but based on the curve - ECDH . In general, don't confuse old DH and new ECDH on an elliptic curve. The first is legacy, the second is base, true and modern bro.

In turn, the Noise mechanics is a comprehensive solution for agreeing and deriving shared keys with a guarantee of irrecoverability 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.

Spoofing protection

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

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

To carry out an attack, an observer needs to intercept a real SSU packet (that is, UDP datagrams) containing the cryptographic identifiers of the sender's I2P router, delay it, and transmit the information to the recipient in a modified form: change 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. Feel the taste of DDoS attacks using unsuspecting I2P routers that innocently send "wrong" responses? True, no such attacks were registered. And now it won't.

In SSU version 2 (SSU2), session management occurs without using unprotected information from UDP headers. 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 in case of an unexpected change in the IP address of one of the parties thanks to the special path challenge mechanism .

About DPI

SSU's major vulnerability to traffic analysis systems was in a characteristic HolePunch message. Hole punch or window punching is a UDP feature that allows subscribers without a dedicated IP address to receive external calls by reserving a port on the border router, all information from which is addressed to a specific subscriber. The old implementation of SSU implied zero-length HolePunch messages, which, when observing traffic from the outside, is a very specific and recognizable behavior: who needs to send an empty message, i.e. naked UDP packet headers? That's right, I2P router. According to one of the leading developers, such things in I2P have developed for historical reasons. Sometimes these reasons are hidden in the annals of history under the heading of secrecy "that's what jrandom did." Fortunately, as the hidden web develops,

In SSU2, the incident with a packet of zero length has been fixed. Now HolePunch messages have a dynamic size and are not separated from the general stream of encrypted UDP packets. This problem was not solved pointwise, but disappeared due to a colossal upgrade of the protocol, but the elimination of the hole still had to be said separately.

Architecturally, SSU2 borrowed the block system from NTCP2 (TCP-based I2P transport) as an integral part of the transport logic. This system implies an additional wrapper for all service and user messages, forming blocks from them that are 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 went 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 knocks down all attempts to guess the content.

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

More about DPI

Let's clarify the topic of deep traffic analysis within the framework of the I2P community model . This will allow a more detailed understanding of the nature of the problem and the vectors that were taken into account when developing the protocol. Expanse for discussions and armchair analytics. Not everything is as clear cut 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. By the forces of such a system, connections can be blocked or somehow corrupted (as happens with requests to blocked services and sites). With an online DPI system, data about each specific compound can be stored for offline analysis.

  The following online DPI capabilities are assumed:

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

  • The ability to perform operations on observable data, such as using block ciphers or hash functions;

  • Ability to store and compare with previously sent messages;

  • The ability to modify, delay or fragment packets.

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

  • The inability to match the IP address with the hashes of I2P routers (RouterInfo). While this is trivial when accessing the network database (netDb) in real time, this would require a DPI system specifically designed for I2P;

  • The impossibility of interacting with I2P to create honeypots (honey pot, "honey traps") to ring 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 discovery and have real-time access to the I2P network database (netDb and lisset information from controlled floodfills). Standalone DPI developers have access to I2P specifications and unlimited computing power, including all cryptographic functions.

  At the same time, 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) almost in real time, as well as initiate its own attempts to establish a handshake with alleged I2P routers for research or other purposes. .

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

To counter the systems built on patterns, with the described monitoring model, it is necessary that all messages be indistinguishable from random ones. For this, their unpredictable length and the absence of a regular sequence at each stage of network interaction are implemented.

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

It would seem that quite a struggle with DPI. However, it is not the purpose of SSU2 to prevent protocol identification by offline DPI. This means that the developers are aware that close observation of the network will allow to identify a part of its participants. Not to detect a specific anonymous user or hidden resource hosting, but only to 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 discussion, SSU2 aims to make it harder to block I2P at the protocol level: detecting I2P traffic is a very voluminous task that exceeds the complexity of many solutions that frivolously scream about the complete impossibility of detecting them. 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 I2P DPI system as a participant to collect information about routers).

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

P.S.

Unlock exclusive features

Take your reading experience to the next level when you join Pocket Premium.

Upgrade

Pocket - SSU2 - next generation I2P transport protocol based on UDP