We continue our series of interviews with I2P network participants (past interviews here and here). Today on diva.exchange blog we present a unique guest, a talented programmer, and one of the most active participants of the I2P community – idk. With idk we will talk about recent attacks on I2P infrastructure, the latest innovations in the network, MoneroKon, and, of course, philosophical issues.

DIVA: Idk, how to introduce you to our readers, what is your job?

idk:  I think I currently have half a dozen or so jobs listed on the I2P website that I do for them. Right now my biggest job is probably as the release maintainer. I also work on the core Java code and some client libraries. The whole Go language part of the ecosystem maintains the Android branch, writes some news, updates the website, and all kinds of stuff.

DIVA: I’d like to start with a difficult, but important question. Not too long ago, the I2P network was attacked. Please tell us more about it. Was it competitors, amateur hackers, or someone else?

idk:  Well there is probably more than one group actually at this point. There’s at least been one very talented script kiddy. There was at least one attack that could have been conducted from a fairly small number of routers. And so that begins to suggest that there were at least a few attacks kind of that were relatively low skill, relatively low resource and we’ve dealt with those in some different ways and we’re continuing to find better ways to deal with them too.

One kind of interesting one was the clone attack, which affected I2Pd a little worse than it affected Java I2P at first because of the differences in the way that we profile existing routers. The way that the clone attack works was that the attacker would generate a legitimate-looking RouterInfo for a non-existent router that was on the same host and IP address as one that existed, and then it would broadcast that to the DHT and people would get confused about which router on which IP address to use. To do this all you need is to generate a RouterInfo in the same way you would if you were newly joining the network. So in that particular case, an attacker doesn’t necessarily need to have a great deal of resources to just broadcast something out to the DHT, they just need a hacked router to generate these fake RouterInfos.

So that was a pretty critical one that we needed to defend against because it was being used to really confuse the network and make, and drive down tunnel build success, pretty extraordinarily. Then, we’ve implemented some things that make it easier to spot those clones and make it easier to spot those clones earlier. There’s no good way to prevent somebody from generating RouterInfos that look like they are on the same IP addresses as somebody else because it’s an anonymous network. We want everybody to be able to join with no barrier to entry.  If everybody’s got to have their IP, then that becomes a barrier to entry and we have to find our way to navigate between those two goalposts.

But then there are other sorts of attacks, too, where there are, botnets that will run large numbers of routers that participate in networking sort of weird ways sometimes. In particular, they like to request extremely high numbers of resources through a few tunnels and that ends up being a thing that clouds have to bend with the available or the routers are willing to share and ends up causing the network to have fewer resources available to build tunnels with.

Both of those are sort of the big attacks that happened most recently and the effect of both of them is to drive down the metric that we use the exploratory tunnel built success. Exploratory tunnels are used to gather information about your view of the DHT so that you have routers to build tunnels with. And if you can’t build exploratory tunnels then you can’t explore the DHT and you can’t participate in the network. That’s kind of a becomes a pretty big problem.

Fortunately, it never got to zero. It got into the teens a few times. But currently if it never actually went to zero the network actually, never actually broke. But it was down as low as 12% at the earliest, at the lowest that I saw. Currently, let’s see, I’m having it hover between 40 and 70 though, that’s pretty good.

DIVA: Did the I2P network pass this stress test? Have the developers learned a lesson from this situation? What do you think?

idk: Well, certainly might take away from some of the earlier attacks to try and be more proactive about things, architecturally speaking.

In particular, what goes into and what comes out of the DHT by what path became a pretty big issue for me last year. My raison d’etre for about six months became auditing what went into and out of the DHT at any given point. And that is the big takeaway for me was we need to be more proactive about things like separating the state between different areas of the router and different parts of the clients and limiting what clients can see relative to what the whole router can see things along those lines. So, a big takeaway was to find ways to be proactive about these defenses and these attack classes where they’re identified.

DIVA:  Did the attacks help you find exploits in the network?

idk: Oh, yes. It did indeed. A good example of the unexpected effects of the attack was on the Sybil subsystem, the attack elucidated a vulnerability. And we have this probabilistic sybil attack detection tool. Essentially, it takes characteristics out of the information that routers broadcast and turns it into a score that allows you to basically sort of assess whether it’s likely to be part of a group that is colluding to try to take over a tunnel. This is probably kind of effective at looking at identifying this type of attack (Tunnel Takeover). But when the clone attack occurred there was a problem which was that this sybil attack tool identified all of these cloned fake routers that were on the same IP as other real routers.

For reference: Sybil attacks are a type of attack on peer-to-peer networks where an attacker creates a large number of peers in order to control a larger share of the network’s resources. In anonymous networks like I2P, this is used to carry out a “takeover” of peers in an anonymous user’s network route.

So, we would have this situation where as far as the Sybil attack identification tool’s view of the network was concerned, it was seeing 30 or 40 or a hundred different cloned RouterInfo that all existed on the same IP address, and they were all getting assigned the same IP score in the sybil attack tool, which resulted in them getting what I call threat inflation, because what would happen is they would have the appearance of all these same IP routers rather would show a threat score in the sybil attack tool as being in the thousands when the threshold for being banned was in the fifties. If you conduct this clone attack you could get routers banned from the entire Java portion of the network fairly easily, and the only recourse that we had was to disable that section of the sybil attack tool, which we did. We’re redesigning it to mitigate that threat inflation problem so that nobody can just join the network a million times to blow up somebody else’s router.

For reference: Threat Inflation refers to the “inflated” estimate of the threat posed by a large number of routers on the same IP address. Since all but one of the cloned routers was fake, they posed no actual threat.

And so that’s the long shot of the attacks actually did show us a lot about what the weak points in the Java router were. To a pretty good extent, although I know less about this also the C++, I2PD router. As I said, the clone attack kind of affected them worse.

Read about the rest of the topics in the second part of the interview with idk. Don’t miss it, it will be interesting.

THIS IS DIVA.EXCHANGE

The non-profit association diva.exchange, Switzerland, uses a barrier-free and collaborative approach to create free banking technology for everyone. Open-source technology ensures the privacy of all participants in the financial system of the future. The blockchain-based system is fully distributed. Everyone can participate in diva.exchange.

Diva.exchange is committed to the belief that only commercially free technology can reliably protect user privacy.

Collaboration with the scientific community plays an important role in the development of diva.exchange. The results of diva.exchange research are constantly being validated by academic institutions and publicly presented at specialized conferences.

LEARN MORE ABOUT OUR WORK

All technical information is available at: https://github.com/diva-exchange/

I2P beginner’s guide and installation guide:https://www.diva.exchange/en/privacy/introduction-to-i2p-your-own-internet-secure-private-and-free/

All videos are here: https://odysee.com/@diva.exchange:d/

Introduction to I2P: https://en.wikipedia.org/wiki/I2P

Testnet of diva.exchange: https://testnet.diva.exchange

CONTACT US

Twitter: https://twitter.com/@DigitalValueX

Mastodon: https://social.diva.exchange/@social

If you still have questions you can always find us on Telegram: https://t.me/diva_exchange_chat_de (in English, German, or Russian)