I2P is an anonymizing network, offering a simple layer that identity-sensitive applications can use to securely communicate. All data is wrapped with several layers of encryption, and the network is both distributed and dynamic, with no trusted parties.
I2P 2.5.1 Point Release
I2P 2.5.1 is released to address Denial-of-Service Attacks affecting the I2P network and services. With this release we disable the IP-based parts of the Sybil attack detection tool which were targeted to amplify the effect and duration of the attack. This should help the network return to normal operation. Those of you who have disabled the Sybil attack detection tool may safely re-enable it. Adjustments to other subsystems to improve RouterInfo validation and peer selection have also been made.
As usual, we recommend that you update to this release. The best way to maintain security and help the network is to run the latest release.
This release, I2P 2.5.0, provides more user-facing improvements than the 2.4.0 release, which was focused on implementing the NetDB isolation strategy.
New features have been added to I2PSnark like the ability to search through torrents. Bugs have been fixed to improve compatibility with other I2P torrent clients like BiglyBT and qBittorrent. We would like to thank all of the developers who have worked with libtorrent and qBittorrent to enable and improve their I2P support. New features have also been added to SusiMail including support for Markdown formatting in emails and the ability to drag-and-drop attachments into emails. Tunnels created with the Hidden Services manager now support "Keepalive" which improves performance and compatibility with web technologies, enabling more sophisticated I2P sites.
During this release we also made several tweaks to the NetDB to improve its resilience to spam and to improve the router's ability to reject suspicious messages. This was part of an effort to "audit" the implementation of "Sub-DB isolation" defenses from the 2.4.0 release. This investigation uncovered one minor isolation-piercing event which we repaired. This issue was discovered and fixed internally by the I2P team.
During this release several improvements were made to the process of releasing our downstream distributions for Android and Windows. This should result in improved delivery and availability for these downstream products.
As usual, we recommend that you update to this release. The best way to maintain security and help the network is to run the latest release.
This dev build includes all the new features planned for I2P 2.5.0, including:
If you want to help, you can get a dev build at our official Github:
Please reach out:
This development build showcases some of the new features and improvements to the I2P router. Please help us test these changes incrementally while we work on the 2.5.0 release.
If you want to help, you can get a dev build at our official Github:
The I2P network is getting some big upgrades this release and we're excited to get them out to you. Please help us make the router better by reporting your bugs.
Please reach out to us at:
This release, I2P 2.4.0, continues our effort to improve the security and stability of the I2P network. It contains significant improvements to the Network Database, an essential structure within the I2P network used for disovering your peers.
The congestion handling changes will improve network stability by giving routers the ability to relieve congested peers by avoiding them. This will help the network limit the effect of tunnel spam. It will also help the network heal during and after DDOS attacks.
The NetDb changes also help secure individual routers and the applications that use them. Routers can now defend against attackers by separating the NetDB into multiple "Sub-DB's" which we use to prevent information leaks between applications and the router. This also improves the information available to Java routers about their NetDB activity and simplifies our support for multihoming applications.
Also included are a number of bug-fixes and enhancements across the I2PSnark and SusiMail applications.
As usual, we recommend that you update to this release. The best way to maintain security and help the network is to run the latest release.
This updated dev build fixes a regression discovered in the InboundMessageDistributor where garlic replies were being dropped inappropriately. It also includes the security improvements from 2.3.0-12 and 2.3.0-14-rc.
If you want to help, you can get a dev build at our official Github:
The I2P network is getting some big upgrades this release and we're excited to get them out to you. Please help us make the router better by reporting your bugs. For more background on the recent changes, see:
Please reach out to us at:
This updated dev build features the changes which were present in the earlier 2.3.0-12 dev build, plus it updates and implements handling for "Congestion Capabilities" a new feature which helps us respond to attackers who attempt to congest the network by consuming excessive resources.
If you want to help, you can get a dev build at our official Github:
When you are using I2P to make connections, you can be one of two basic things, a "Router" or a "Client." Routers make connections to eachother and they form the I2P Network itself, and Clients are used to build applications inside the I2P network like HTTP Servers, for instance by forming Tunnels between routers. In order to build these connections, a Router broadcasts it's "RouterInfo" to the Network Database, which is where Capabilities come in.
A RouterInfo contains a set of "Capabilities" which indicate what the Router it represents is capable of. If it is capable of connecting directly or whether it requires a relay/introducer, on which addresses, whether NTCP2 or SSU2, and bandwidth tier are all expressed inside the RouterInfo. With this change, when a router is nearing the limit of what it can handle, it will publish an additional Capability in it's RouterInfo which will indicate the level of congestion it is experiencing.
When other routers see that this router is in distress, they can then "back off" and request fewer or none of their client tunnels be built through the affected router, giving it time to recover and reducing the chances that it's resources will be exhausted.
Please help us test the Congestion Capabilities, and report your issues at:
I2P is closing in on the long-delayed release of the 2.4.0 router, which contains a major redesign of one of the oldest and most essential shared systems in I2P, the Network Database, or NetDB. The NetDB is I2P's DHT, a variant of Kademlia which uses a technique called "Floodfill" to elect peers to flood out information efficiently. If the DHT doesn't work, the routers that make up the network won't be able to find the peers that it needs to operate, so we have to be very sure that we've done it correctly.
If you want to help, you can get a dev build at our official Github:
After downloading, copy the i2pupdate.su3 file to your I2P install directory and restart. In about a minute, your I2P router will be upgraded to the new version.
This change will allow I2P to manage multiple versions of the NetDB, which may co-exist in different "Contexts" on the same router, allowing them to enforce secure behavior based upon their role when used by the router. In the new design, a NetDB can assigned either a "main" role, or a "client" role.
In this new model, every router has a single "main" NetDB, which is used for Floodfill operations, network maintenance, and detatched LeaseSet lookups. However, routers that have Client Tunnels also have an equal number of client NetDBs, which hold only the information required to operate their clients. When a client publishes it's LeaseSet out a client tunnel, it is managed from within the client NetDB, and when a client needs a LeaseSet, it is looked up and stored in the client NetDB. This allows 2 things to change:
This allows us to greatly simplify the way we handle LeaseSets by identifying how the LeaseSet will be used with the context in which it is being stored. This design can eliminate an entire hypothetical attack class where an attacker attempts to confuse the DHT about the origins of a particular LeaseSet. As an added benefit of employing this technique, the kinds of information that a NetDB needs to use is known in advance. This is therefore a significant advance for I2P's security and efficiency.
As I said in the pre-release forum post, this change has the potential to break the network, and it cannot go live if we're not sure it's working correctly. Please help us test the new NetDB, and report your issues at:
This release contains fixes for CVE-2023-36325. CVE-2023-36325 is a context-confusion bug which occurred in the bloom filter. An attacker crafts an I2NP message containing a unique messageID, and sends that messageID to a client. The message, after passing through the bloom filter, is not allowed to be re-used in a second message. The attacker then sends the same message directly to the router. The router passes the message to the bloom filter, and is dropped. This leaks the information that the messageID has been seen before, giving the attacker a strong reason to believe that the router is hosting the client. This has been fixed by separting the bloom filter's functionality into different contexts based on whether a message came down a client tunnel, an exploratory tunnel, was sent to the router directly. Under normal circumstances, this attack takes several days to perform successfully and may be confounded by several factors such as routers restarting during the attack phase and sensitivity to false-positives. Users of Java I2P are recommended to update immediately to avoid the attack.
In the course of fixing this context confusion bug, we have revised some of our strategies to code defensively, against these types of leaks. This includes tweaks to the netDb, the rate-limiting mechanisms, and the behavior of floodfill routers.
This release adds not_bob as a second default hosts provider, and adds notbob.i2p and ramble.i2p to the console homepage.
This release also contains a tweakable blocklist. Blocklisting is semi-permanent, each blocked IP address is normally blocked until the router is restarted. Users who observe explosive blocklist growth during sybil attacks may opt-in to shorter timeouts by configuring the blocklist to expire entries at an interval. This feature is off-by-default and is only recommended for advanced users at this time.
This release also includes an API for plugins to modify with the Desktop GUI(DTG). It is now possible to add menu items to the system tray, enabling more intuitive launching of plugins which use native application interfaces.
As usual, we recommend that you update to this release. The best way to maintain security and help the network is to run the latest release.