Vista general

I2P viene con una librería genérica de asignación de nombres y una implementación base diseñada para entregar un mapeado desde nombre local a destino, además de una aplicación add-on llamada libreta de direcciones (`adressbook`). I2P también soporta nombres de servidor Base32 similares a las direcciones .onion de Tor.

La libreta de direcciones es un sistema de nombres asegurado mediante web-of-trust, distribuido, y legible por humanos, que tan solo sacrifica el que los nombres sean globalmente únicos, obligando a que sólo lo sean localmente. Mientras todos los mensajes en I2P son criptográficamente direccionados por su destino, diferentes personas puede tener diferentes entradas "Alice" en sus libros de direcciones locales que se refieran a diferentes destinos. El público aún puede descubrir nuevos nombres importando libros de direcciones publicados, de pares (`peers`) especificados en sus web-of-trust, incorporando las entradas provistas por terceros, o (si algunas personas organizan series de libros de direcciones publicados usando un sistema de registro tipo `primero en venir primero en ser servido`) la gente puede elegir tratar estos libros de direcciones como servidores de nombres, emulando al tradicional DNS.

NOTA: Para encontrar las razones detrás del sistema de nombres de I2P, los argumentos habituales contra él y las posibles alternativas, vea la página de discusión sobre el sistema de nombres.

Componentes del sistema de nombres

No hay una autoridad central de nombres en I2P. Todos los nombres de servidor están en local.

El sistema de nombres es bastante simple, y la mayoria de él está implementado en aplicaciones externas al router pero empaquetadas con la distribución I2P. Los componentes son:

1. El servicio de nombres local que hace búsquedas y también maneja los nombres de equipos Base32.
2. El proxy HTTP que realiza consultas al router I2P y dirige al usuario a servicios de salto (jump, de direccionamiento distribuido) remotos para asistirle con las consultas fallidas.
3. Formularios de añadido de servidores HTTP que permiten a los usuarios añadir servidores a su hosts.txt local.
4. Servicios de salto (jump) HTTP que proporcionan sus propias búsquedas y redireccionamiento distribuido.
5. La aplicación de libreta de direcciones que fusiona listas externas de servidores, con la lista local.
6. La aplicación SusiDNS que es un sencillo frontal web para la configuración de la libreta de direcciones y el visionado de las listas locales de servidores.

Servicios de nombres

All destinations in I2P are 516-byte (or longer) keys. (To be more precise, it is a 256-byte public key plus a 128-byte signing key plus a 3-or-more byte certificate, which in Base64 representation is 516 or more bytes. Non-null Certificates are in use now for signature type indication. Therefore, certificates in recently-generated destinations are more than 3 bytes.

Si una aplicación (i2ptunnel o el proxy HTTP) quiere acceder a un destino mediante el nombre, el router hace una búsqueda local muy simple para resolver ese nombre.

Servicio de nombres hosts.txt

El servicio de nombres hosts.txt hace una búsqueda lineal simple a través de ficheros de texto. Este servicio de nombres fue la norma hasta la versión 0.8.8 cuando fue reemplazado por el servicio de nombres blockfile (fichero de bloques). El formato de hosts.txt ha llegado a ser demasiado lento después de que el fichero creciera hasta las miles de entradas.

Realiza una búsqueda lineal a través de tres ficheros locales, en orden, para buscar nombres de equipos y convertirlos a claves de destinos de 516-bytes. Cada fichero está en un formato de fichero de configuración simple, con (nombre de equipo) hostname=base64, uno por línea. Los ficheros son:

1. privatehosts.txt
2. userhosts.txt
3. hosts.txt

Servicio de nombres blockfile

El servicio de nombres blockfile (fichero de bloques) almacena múltiples "addressbooks" (libretas de direcciones) en un único fichero de base de datos llamado hostsdb.blockfile. Este servicio de nombres es el predeterminado desde la versión 0.8.8.

Un blockfile (fichero de bloques) es simplemente un almacenamiento en-disco de múltiples mapeados (pares clave-valor) ordenados implementados como listas por saltos ('skiplists'). El formato blockfile está especificado en la página de Blockfile. Proporciona búsqueda rápida de destinos en un formato compacto. Aunque el tráfico de control de blockfile es sustancial, los destinos están almacenados en binario en lugar de en Base 64 como en el formato hosts.txt . Además, blockfile proporciona la posibilidad de almacenar metadatos arbitrarios (tales como fecha añadida, fuente, y comentarios) por cada entrada, para implementar características avanzadas de libreta de direcciones. El requisito para el almacenamiento blockfile es un modesto incremento sobre el tamaño del formato hosts.txt, y el blockfile proporcionará una reducción en los tiempos de búsqueda por un factor aproximado de 10x.

Al crearse, el servicio de nombres importa entradas desde los tres ficheros usados por el servicio de nombres hosts.txt. El blockfile imita la anterior implementación al mantener tres mapeados que se buscan en-orden, llamados privatehosts.txt, userhosts.txt, y hosts.txt. También mantiene un mapeado de búsqueda-inversa para implementar búsquedas inversas rápidas.

Otras infraestructuras de servicio de nombres

La búsqueda distingue mayúsculas/minúsculas. Se usa la primera coincidencia, y no se detectan los conflictos. No se hace aplicación de las reglas de nombres en las búsquedas. Las búsquedas se guardan en caché durante unos pocos minutos. La resolución Base32 se describe debajo. Para una descripción completa de la API del servicio de nombres vea los Javadocs del servicio de nombres. Esta API fue expandida significativamente en la versión 0.8.7 para proporcionar adiciones y eliminaciones, almacenamiento de propiedades arbitrarias junto al el nombre del equipo, y otras características.

Alternativas y servicios de nombres experimentales

El servicio de nombres se especifica con la propiedad de configuración i2p.naming.impl=class. Otras implementaciones son posibles. Por ejemplo, hay una infraestructura experimental para búsquedas en tiempo-real (estilo DNS) sobre la red interior al router. Para más información vea la página de discusión sobre alternativas.

The HTTP proxy does a lookup via the router for all hostnames ending in '.i2p'. Otherwise, it forwards the request to a configured HTTP outproxy. Thus, in practice, all HTTP (I2P Site) hostnames must end in the pseudo-Top Level Domain '.i2p'.

Tenemos solicitada la reserva del TLD (dominio de primer nivel) .i2p siguiendo los procedimientos especificados en la RFC 6761.

Si el router I2P falla al resolver el nombre del servidor, el proxy HTTP devuelve una página de error al usuario con enlaces a varios servicios de salto (jump, direccionamiento distribuido). Más detalles debajo.

Libreta de direcciones

Suscripciones entrantes y fusionado

La aplicación de la libreta de direcciones obtiene periódicamente los ficheros hosts.txt de otros usuarios y los fusiona con el fichero hosts.txt local tras varias comprobaciones. Los conflictos de nombres se resuelven en base al criterio `el primero en venir es el primero en ser servido`.

Suscribirse al fichero hosts.txt de otros usuarios implica darles un cierto nivel de confianza. No querrá que ellos, por ejemplo, 'secuestren' un sitio nuevo introduciendo rápidamente su propia clave para el nuevo sitio antes de pasarle el nuevo servidor/clave a usted.

Por esta razón, el único suscriptor configurado por defecto es http://i2p-projekt.i2p/hosts.txt (http://udhdrtrcetjm5sxzskjyr5ztpeszydbh4dpl3pl4utgqqw2v4jna.b32.i2p/hosts.txt), que contiene una copia del hosts.txt incluido en la versión de I2P. Los usuarios tienen que configurar suscripciones adicionales en sus aplicaciones de libreta de direcciones (vía suscriptions.txt o SusiDNS).

Some other public address book subscription links:

• http://i2host.i2p.xyz/cgi-bin/i2hostetag
• http://stats.i2p/cgi-bin/newhosts.txt

Los operadores de estos servicios pueden tener diferentes políticas para listar servidores. La presencia en esta lista no implica su respaldo.

Reglas de nombres

Aunque afortunadamente no hay limitación técnica alguna en I2P para los nombres de servidor, la libreta de direcciones impone varias restricciones sobre los nombres de servidor importados desde suscripciones. Hace esto por higiene tipográfica básica y compatibilidad con navegadores, y por seguridad. Las reglas son esencialmente las mismas que aquellas de la Sección 3.2.2. en el RFC2396. Cualquier nombre de servidor que viole esas reglas puede no ser propagado a otros routers.

Reglas de nombres:

• Los nombres se convierten a minúsculas al importarlos.
• Se comprueban los conflictos entre los nombres y los nombres existentes en userhosts.txt y hosts.txt (pero no privatehosts.txt) tras su conversión a minúsculas.
• Sólo deben contener [a-z] [0-9] '.' y '-' tras su conversión a minúsculas.
• No deben comenzar con '.' o '-'.
• Debe terminar en «.i2p».
• Máximo 67 caracteres, incluyendo el '.i2p'.
• No puede contener «..».
• No deben contener '.-' o '-.' (a partir de la 0.6.1.33).
• No deben contener '--' excepto en 'xn--' para IDN.
• Los nombres de equipo Base32 (*.b32.i2p) están reservados para el uso de base 32 y por tanto no está permitida su importación.
• Ciertos nombres de servidor reservados para uso del proyecto no están autorizados (proxy.i2p, router.i2p, console.i2p, *.proxy.i2p, *.router.i2p, *.console.i2p, y otros)
• Se comprueba la validez base64 de las claves.
• Se comprueba si las claves tienen conflictos con claves existentes en hosts.txt (pero no privatehosts.txt).
• La longitud mínima de clave es 516 bytes.
• La longitud máxima de clave es 616 bytes (para contar con certificados de hasta 100 bytes).

Cualquier nombre recibido vía suscripción que pase todas las comprobaciones, se añade a través del servicio de nombres local.

Observe que los símbolos '.' en el nombre de servidor no tienen significado, y no denotan jerarquía de confianza o de nombres alguna. Si el nombre 'host.i2p' ya existe, no hay nada que evite que alguien añada un nombre 'a.host.i2p' a su(s) hosts.txt, y este nombre pueda ser importado por las libretas de direcciones de otros. Los métodos para denegar subdominios a propietarios de no-dominios (¿certificados?), y lo deseable y factible de estos métodos, son temas para futura discusión.

Los Nombres de Dominio Internacionales (IDN) también funcionan con I2P (usando la forma punycode 'xn--'). Para ver nombres de dominio .i2p IDN correctamente formados en la barra de direcciones de Firefox, añada 'network.IDN.whitelist.i2p (boolean) = true' en about:config

Como la aplicación libreta de direcciones no usa privatehosts.txt para nada, en la práctica este fichero es el único lugar donde es apropiado emplazar alias privados o "nombres de mascota" para sitios ya existentes en hosts.txt

Formato de suscripción (feed) avanzado

Suscripciones salientes

Address Book will publish the merged hosts.txt to a location (traditionally hosts.txt in the local I2P Site's home directory) to be accessed by others for their subscriptions. This step is optional and is disabled by default.

Hosting and HTTP Transport Issues

La aplicación libreta de direcciones, junto con eepget, previene que la información del Etag y/o la de Última-modificación sea devuelta por el servidor web de la suscripción. Esto reduce enormemente el ancho de banda requerido ya que el servidor web devolverá un '304 No Modificado' en la la siguiente toma de datos (`fetch`) si nada ha cambiado.

Sin embargo, si ha cambiado se descarga el hosts.txt completo. Mire debajo las discusiones sobre este asunto.

Se recomienda que los servidores que sirven un archivo host.txt o una aplicación CGI equivalente, lleven una cabecera con el tqmaño del contenido, Content-Length header, y una Etag o la última cabecera modificada, Last-Modified header. Además asegúrese de que el servidor muestra el aviso '304 Not Modified' cuando sea apropiado. Esto reducirá dramáticamente el ancho de banda usado, y reducirá las posibilidades de corrupción.

Servicio de gestión de dominios

Un servicio de gestión de dominios es una aplicación CGI simple que toma un nombre de dominio y una clave Base64 como parámetros y loa añade a su hosts.txt local. SI otros ruters se suscriben a ese host.txt, el nuevo nombre de domino/clave serán propagados a través de la red.

Se recomienda que los servicios de gestión de dominios impongan, como mínimo, las restricciones impuestas por la aplicación libreta de direcciones listadas anteriormente. Los servicios de gestión de dominios deben imponer restricciones adicionales en los nombres de dominio y en las claves, por ejemplo:

• Un 'límite' en el número de 'subdominios'.
• Autorización para los 'subdominios' a través de varios métodos.
• Hashcash o certificados firmados.
• Revisión editorial de los nombres de dominio y/o su contenido.
• Clasificación de los dominios según su contenido.
• Reserva o rechazo de ciertos dominios.
• Restricciones en el número de dominios registrados en un determinado periodo de tiempo.
• Intervalos entre los registros y las publicaciones.
• Exigir que el servidor esté funcionando para su verificaión.
• Expiración y/o revocación.
• Denegación de IDN spoof.

Servicios de salto (jump)

Un servicio de salto (jump), es una simple aplicación CGI que toma un nombre de servidor como parámetro y devuelve un redireccionamiento 301 hacia la URL adecuada con una cadena de texto ?i2paddresshelper=clave anexa. El proxy HTTP interpretará la cadena de texto anexa y usará esa clave como el destino I2P de facto. Además, el proxy guardará en caché esa clave de forma que el ayudante de direccionamiento (address helper) no sea necesario hasta reiniciar.

Dese cuenta que, al igual que con las suscripciones, usar un servicio de salto (jum p, direccionamiento distribuido) implica una cierta dosis de confianza, ya que un servicio de salto podría redirigir maliciosamente a un usuario a un destino I2P incorrecto.

Para proporcionar el mejor servicio, un servicio de salto (jump, direccionamiento distribuido) debe estar suscrito a varios proveedores de ficheros hosts.txt para que su lista local de servidores esté al día.

SusiDNS

SusiDNS is simply a web interface front-end to configuring address book subscriptions and accessing the four address book files. All the real work is done by the 'address book' application.

Currently, there is little enforcement of address book naming rules within SusiDNS, so a user may enter hostnames locally that would be rejected by the address book subscription rules.

Dominios Base32

I2P soporta nombres de dominios Base32 similares a las direcciones .onion de Tor. Las direcciones Base32 son mucho más fáciles de manejar y mucho más cortas que los addresshelpers o las Destinaciones Base64 de 516 caracteres. Ejemplo: ukeu3k5oycgaauneqgtnvselmt4yemvoilkln7jpvamvfx7dnkdq.b32.i2p

In Tor, the address is 16 characters (80 bits), or half of the SHA-1 hash. I2P uses 52 characters (256 bits) to represent the full SHA-256 hash. The form is {52 chars}.b32.i2p. Tor has a proposal to convert to an identical format of {52 chars}.onion for their hidden services. Base32 is implemented in the naming service, which queries the router over I2CP to lookup the LeaseSet to get the full Destination. Base32 lookups will only be successful when the Destination is up and publishing a LeaseSet. Because resolution may require a network database lookup, it may take significantly longer than a local address book lookup.

Las direcciones Base32 pueden ser usadas en la mayoría de sitios donde se puedan usar los nombres de dominios o la Destinación completa, aunque hay algunas excepciones donde podría fallar sin el dominio no se resuelve inmediatamente, Por ejemplo, I2PTunnel fallará si el domino no resuelve una destinación.