I2P 2.4.0 Release

[eyedeekay]

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.

RELEASE DETAILS

Changes

Router: Restructure netDb to isolate data recieved as a client from data recieved as a router
Router: Implement handling and penalties for congestion caps
Router: Temp. ban routers publishing in the future
NetDB: Lookup handler/throttler fixes
i2psnark: Uncomment and fix local torrent file picker

Bug Fixes

i2ptunnel: Exempt tunnel name from XSS filter (Gitlab #467)
i2ptunnel: Fix gzip footer check in GunzipOutputStream (Gitlab #458)
SAM: Fix accept after soft restart (Gitlab #399)
SAM: Reset incoming socket if no subsession is matched (Gitlab #456)

Full list of fixed bugs

SHA256 Checksums:

d08db62457d4106ca0e36df3487bdf6731cbb81045b824a003cde38c7e1dfa27 i2pinstall_2.4.0_windows.exe
ef5f3d0629fec292aae15d027f1ecb3cc7f2432a99a5f7738803b453eaad9cad i2pinstall_2.4.0.jar
30ef8afcad0fffafd94d30ac307f86b5a6b318e2c1f44a023005841a1fcd077c i2psource_2.4.0.tar.bz2
97be217bf07319a50b6496f932700c3f3c0cceeaf1e0643260d38c9e6e139b53 i2pupdate_2.4.0.zip
8f4a17a8cbadb2eabeb527a36389fd266a4bbcfd9d634fa4f20281f48c486e11 i2pupdate.su3


==================================================================================================

See also: https://geti2p.net/en/get-involved/roadmap

This release is going to focus on identifying hardening the netDb against context confusion attacks, refining and elaborating upon the behavior of the blocklist, and mitigating some of the types of spam which have appeared on the network. We will be implementing handling of congestion capabilities, eliminating the majority of lookup spam, and implementing an i2pd-style multiple-netDb design which allows each client to use a different store of LeaseSets than a floodfill running on the same router, providing us with a clear boundary between information sent to and used by clients and information sent to and used by the router. By doing things this way, we can also make make it easier for the netDb to handle obscure cases like multihoming. Please test, test, test, and report your findings, these are big changes and they won't go in unless we are sure they're right.

• Target Release Date: December 18, 2023.
  Major Changes Due Date: November 13 2023
  Tag Freeze Date: December 6, 2023

If you want to run the code I am running, clone the master branch from git.

[eyedeekay]

Dates updated above.

[eyedeekay]

Major changes will now be accepted until the 30th.

[eyedeekay]

Dates updated again.

[eyedeekay]

We're pushing it back one last time. Like I said in the OP, if it's not right it's not going in. New dates added above.

[eyedeekay]

Most important dev build this cycle is out:

https://github.com/i2p/i2p.i2p/releases ... p-2.3.0-12

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.
TL:DR This change needs widespread testing

If you want to help, you can get a dev build at our official Github:

https://github.com/i2p/i2p.i2p/releases ... p-2.3.0-12

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.
Want to learn more? Read on...

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:

when using the main NetDB, the router is able to handle every LeaseSet in
exactly the same way, including those belonging to it's own clients.
it allows us to maintain and organize multiple copies of a single LeaseSet
so that a client maintains a copy of all the LeaseSets it needs, and the client
is solely responsible for keeping them up to date.

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:

i2pgit.org
git.idk.i2p
i2pforum.net
i2pforum.i2p
github.com

[eyedeekay]

# I2P 2.3.0-14-rc **Release Candidate Needs Testers**

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.

## Help us test this new feature for hardening the network against attack

If you want to help, you can get a dev build at our official Github:

- https://github.com/i2p/i2p.i2p/releases ... .3.0-14-rc

### What are Congestion Capabilities?

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:

- [i2pgit.org](https://i2pgit.org/i2p-hackers/i2p.i2p)
- [git.idk.i2p](http://git.idk.i2p/i2p-hackers/i2p.i2p)
- [i2pforum.net](https://i2pforum.net)
- [i2pforum.i2p](http://i2pforum.i2p)
- [github.com](https://github.com/i2p/i2p.i2p)

[echelon]

Hi

Today I built the Mac 2.4.0 release on my Mac, but cannot sign it for Mac Apple Store distribution.
If you want to test it, check it out on

http://files.i2p-projekt.de/update/MAC/

echelon