Torguard - Keep your identity private online!
Naming discussion - I2P
Skip navigation

Naming discussion

NOTE: The following is a discussion of the reasons behind the I2P naming system, common arguments and possible alternatives. See the naming page for current documentation.

Discarded alternatives

Naming within I2P has been an oft-debated topic since the very beginning with advocates across the spectrum of possibilities. However, given I2P's inherent demand for secure communication and decentralized operation, the traditional DNS-style naming system is clearly out, as are "majority rules" voting systems.

I2P does not promote the use of DNS-like services though, as the damage done by hijacking a site can be tremendous - and insecure destinations have no value. DNSsec itself still falls back on registrars and certificate authorities, while with I2P, requests sent to a destination cannot be intercepted or the reply spoofed, as they are encrypted to the destination's public keys, and a destination itself is just a pair of public keys and a certificate. DNS-style systems on the other hand allow any of the name servers on the lookup path to mount simple denial of service and spoofing attacks. Adding on a certificate authenticating the responses as signed by some centralized certificate authority would address many of the hostile nameserver issues but would leave open replay attacks as well as hostile certificate authority attacks.

Voting style naming is dangerous as well, especially given the effectiveness of Sybil attacks in anonymous systems - the attacker can simply create an arbitrarily high number of peers and "vote" with each to take over a given name. Proof-of-work methods can be used to make identity non-free, but as the network grows the load required to contact everyone to conduct online voting is implausible, or if the full network is not queried, different sets of answers may be reachable.

As with the Internet however, I2P is keeping the design and operation of a naming system out of the (IP-like) communication layer. The bundled naming library includes a simple service provider interface which alternate naming systems can plug into, allowing end users to drive what sort of naming tradeoffs they prefer.


See also Names: Decentralized, Secure, Human-Meaningful: Choose Two.

Comments by jrandom

(adapted from a post in the old Syndie, November 26, 2005)

Q: What to do if some hosts do not agree on one address and if some addresses are working, others are not? Who is the right source of a name?

A: You don't. This is actually a critical difference between names on I2P and how DNS works - names in I2P are human readable, secure, but not globally unique. This is by design, and an inherent part of our need for security.

If I could somehow convince you to change the destination associated with some name, I'd successfully "take over" the site, and under no circumstances is that acceptable. Instead, what we do is make names locally unique: they are what you use to call a site, just as how you can call things whatever you want when you add them to your browser's bookmarks, or your IM client's buddy list. Who you call "Boss" may be who someone else calls "Sally".

Names will not, ever, be securely human readable and globally unique.

Comments by zzz

The following from zzz is a review of several common complaints about I2P's naming system.

So, in summary, the current system is not horribly broken, inefficient, or un-scalable, and proposals to "just use DNS" aren't well thought-through.


The I2P source contains several pluggable naming systems and supports configuration options to enable experimentation with naming systems.

The current naming system can be changed with the advanced config option 'i2p.naming.impl' (restart required). See core/java/src/net/i2p/client/naming for details.

Any new system should be stacked with HostsTxt, or should implement local storage and/or the addressbook subscription functions, since addressbook only knows about the hosts.txt files and format.


I2P destinations contain a certificate, however at the moment that certificate is always null. With a null certificate, base64 destinations are always 516 bytes ending in "AAAA", and this is checked in the addressbook merge mechanism, and possibly other places. Also, there is no method available to generate a certificate or add it to a destination. So these will have to be updated to implement certificates.

One possible use of certificates is for proof of work.

Another is for "subdomains" (in quotes because there is really no such thing, i2p uses a flat naming system) to be signed by the 2nd level domain's keys.

With any certificate implementation must come the method for verifying the certificates. Presumably this would happen in the addressbook merge code. Is there a method for multiple types of certificates, or multiple certificates?

Adding on a certificate authenticating the responses as signed by some centralized certificate authority would address many of the hostile nameserver issues but would leave open replay attacks as well as hostile certificate authority attacks.