Draft: start working on a nesting-netDB design, where it is possible to segment the netDB

start working on a nesting-netDB design, where it is possible to segment the netDB.

Proposal to allow Java I2P to Host Multiple NetDB's

This outlines a proposed way to allow Java I2P to host multiple "contexts" of NetDB, similar to i2pd.

Current situation

Java I2P has existed for 20 years, and during that time it has experienced several revisions to it's NetDB. However, throughout most of that time, there has only ever been one NetDB, managed in the Router context, which is queried for data. This one-NetDB approach requires, at various layers, that the NetDB keep track individually what RouterInfos and LeaseSets are acceptable to send or store, and when. Currently, the Java I2P NetDB does this by maintaining a set of "Flags" on each "DatabaseEntry." These flags indicate the circumstances under which a LeaseSet or RouterInfo has been encountered. Without these, the router would be vulnerable to attackers who submit crafted LeaseSets in order to "Tag" clients and routers for context-confusion attacks. This is extremely complicated to maintain and keep track of the validity of any given NetDB operation, and has led to difficult to predict and difficult to fix attacks.

Proposed Solution

Background: The solution adopted in i2pd, and often lauded by those who study it, is to give each potential context in which the NetDB might be required it's own NetDB to communicate with, treating each NetDB as an entirely separate entity with each context. The simplicity of this solution has great appeal, but it is almost antithetical to the incumbent design of the NetDB in relation to the router context.

In order to maintain the existing functionality of the Java I2P router while also providing a way of interfacing with multiple NetDB's to avoid context confusion attacks, a global "Meta-NetDB" will replace the existing NetDB, which will consist of an interface to manage multiple Sub-NetDB's. The outer, "Meta-NetDB" is a "SegmentedNetworkDatabase," and the inner, "Sub-NetDBs" are a string-addressed map of "FloodfillNetworkDatabases."

Goals of the proposed solution

0. Don't Break Anything - make no mistake, this could break everything,.potentially, because it's going to affect everything that touches the NetDB, which is everything. The potentially impacted places run from pages in the router console UI to NetDB on-disk persistence to the viability of encrypted leaseSets. This is the hardest thing to do while also fixing the problem.
1. Make context-confusion attacks more difficult by providing differing NetDB contexts as-neeeded - Contexts will be necessary for clients and floodfills, but they might also be necessary for exploratory clients and potentially other parts of the router.
2. Preserve the ability to communicate with the NetDB globally via the Meta-NetDB - Especially in router console pages, it will be important to talk to all of the NetDB contexts.
3. Leave Existing Defenses Intact - Using the existing defenses is still viable to an extent, we're not going to remove them. It's more work for one thing, and for another we can use the existing defenses to track the consistency where the new defenses are applied.

Details of the Proposed Solution

• A new abstract Class is created, SegmentedNetworkDatabaseFacade
• A new implementation FloodfillNetworkDatabaseSegmentor
• In RouterContext, getDb() is changed to return the global FloodfillNetworkDatabaseSegmentor
• In RouterContext, new functions floodfillNetDB() and clientNetDB(), clientNetDB(string) return FloodfillNetworkDatabaseFacade
• Clients must use clientNetDB(string) call to obtain a private context, where the string is the key used to look them up in the map
• Floodfills must use the floodfillNetDB() call to obtain the NetDB context for acting as a floodfill
• Local displays(such as on the routerconsole) will need to call getDb() to get the global NetDB context and query all peers