Proposal by weko, orignal, the Anonymous and zzz.
Overview
Suggesting changes in SSU2 after the attack on I2P that used SSU2’s problem.
Threat model
An attacker creates new fake RIs (router doesn’t exist): is regular RI, but he puts address, port, s and i keys from real Bob’s router, then he floods the network. When we are trying to connect to this (as we think real) router, we, as Alice can connect to this address, but we can’t be sure what done it with real Bob’s RI. This is possible and was used for a Distributed Denial of Service attack (make big amount of such RIs and flood the network), also this can make de-anon attacks easier by framing good routers and do not framing attacker’s routers, if we ban IP with many RIs (instead better distrubute tunnel building to this RIs as to one router).
Potential fixes
1. Fix with support for old (before the change) routers
Overview
A workaround to support SSU2 connections with old routers.
Behavivor
Bob’s router profile should have ‘verified’ flag, it’s false by default for all new routers (with no profile yet). When ‘verified’ flag is false, we never do connections with SSU2 as Alice to Bob - we can’t be sure in RI. If Bob connected to us (Alice) with NTCP2 or SSU2 or we (Alice) connected to Bob with NTCP2 once (we can verify Bob’s RouterIdent in these cases) - flag is set to true.
Problems
So, there is a problem with fake SSU2-only RI flood: we can’t verify it by ourselves and are forced to wait when the real router will make connections with us.
2. Verify RouterIdent during connection creation
Overview
Add “RouterIdent” block for SessionRequest and SessionCreated.
Possible format of RouterIdent block
1 byte flags, 32 bytes RouterIdent. Flag_0: 0 if receiver’s RouterIdent; 1 if sender’s RouterIdent
Behavior
Alice (should(1), can(2)) send in payload RouterIdent block Flag_0 = 0 and Bob’s RouterIdent. Bob (should(3), can(4)) check if is it his RouterIdent, and if not: terminate the session with “Wrong RouterIdent” reason, if it is his RouterIdent: send RI block with 1 in Flag_0 and Bob’s RouterIdent.
With (1) Bob does not support old routers. With (2) Bob supports old routers, but can be a victim of DDoS from routers that are trying to make connection with fake RIs. With (3) Alice does not support old routers. With (4) Alice supports old routers and is using a hybrid scheme: Fix 1 for old routers and Fix 2 for new routers. If RI says new version, but while in the connection we didnt’s recieve the RouterIdent block - terminate and remove RI.
Problems
An attacker can mask his fake routers as old, and with (4) we are waiting for ‘verified’ as in fix 1 anyways.
Notes
Instead of 32 byte RouterIdent, we can probably use 4 byte siphash-of-the-hash, some HKDF or something else, which must be sufficient.
3. Bob sets i = RouterIdent
Overview
Bob uses his RouterIdent as i key.
Behavior
Bob (should(1), can(2)) uses his own RouterIdent as i key for SSU2.
Alice with (1) connects only if i = Bob’s RouterIdent. Alice with (2) uses the hybrid scheme (fix 3 and 1): if i = Bob’s RouterIdent, we can make the connection, otherwise we should verify it first (see fix 1).
With (1) Alice does not support old routers. With (2) Alice supports old routers.
Problems
An attacker can mask his fake routers as old, and with (2) we are waiting for ‘verified’ as in fix 1 anyways.
Notes
To save on RI size, better add handling if i key isn’t specified. If it is, then i = RouterIdent. In that case, Bob does not support old routers.
Backward compability
Described in fixes.
Current status
i2pd: Fix 1.