Esta página fue actualizada por última vez el September 2017 y es precisa con la versión 0.9.32 del router I2P.

Vista general

La netDb de I2P es una base de datos distribuida especializada que contiene 2 tipos de datos - información de contacto del ruter y la información de contacto de la destinación. Cada parte de los datos es firmada por la parte apropiada y verificada por cualquiera que las use o las almacene. Además, los datos tienen información cambiante, permitiendo que las entradas irrelevantes sean desechadas, que nuevas entradas puedan reemplazar las antiguas y protección contra cierto tipos de ataques.

La netDb se distribuye con una técnica simple llamada "FloodFill", donde un subconjunto de ruters, llamados ruters "floodfill", mantienen la base de datos distribuida.

RouterInfo

Cuando un ruter I2P quiere contactar con otro ruter, necesitan conocer algunas partes claves de los datos - estas partes están agrupadas y firmadas por el ruter dentro de una estructura llamda "RouterInfo", que es distribuida con el hash SHA256 de la identidad del ruter como una clave de cifrado. La estructura en sí misma contiene:

  • The router's identity (a 2048bit ElGamal encryption key, a signing key, and a certificate)
  • La dirección de contacto en la que puede ser accedida (por ejemplo TCP: example.org puerto 4108)
  • Cuándo fue publicada.
  • Un conjunto de opciones de texto arbitrarias
  • The signature of the above, generated by the identity's signing key

Expected Options

Las siguientes opciones de texto, que aunque no son requeridas explicitamente se espera que esten presentes:

  • caps (Datos de capacidad - usados para indicar si se participa como floodfill, ancho de banda aproximado y la accesibilidad observada.)
    • f: FloodFill
    • H: Oculto
    • K: Por debajo del 12 KBps de ancho de banda compartido
    • L: 12 - 48 KBps de ancho de banda compartido (predeterminado)
    • M: 48 - 64 KBps de ancho de banda compartido
    • N: 64 - 128 KBps de ancho de banda compartido
    • O: 128 - 256 KBps de ancho de banda compartido
    • P: 256 - 2000 KBps de ancho de banda compartido (as of release 0.9.20)
    • R: Alcanzable
    • U: No alcanzable
    • X: Por encima del 2000 KBps de ancho de banda compartido (as of release 0.9.20)
    "Shared bandwidth" == (share %) * min(in bw, out bw)
    For compatibility with older routers, a router may publish multiple bandwidth letters, for example "PO".
  • coreVersion (La versión de la librería del núcleo, siempre la misma que la versión del ruter) (Never used, removed in release 0.9.24)
  • netId = 2 (Compatibilidad básica de la red - Un ruter no se comunicará con un par que tenga un netId diferente)
  • router.version (Se utiliza para determinar la compatibilidad con las nuevas características y mensajes.)
  • stat_uptime = 90m (Always sent as 90m, for compatibility with an older scheme where routers published their actual uptime, and only sent tunnel requests to peers whose uptime was more than 60m) (Unused since version 0.7.9, removed in release 0.9.24)

Estos valores pueden ser usados por otros ruters para tomar decisiones básicas. ¿Deberíamos conectar con este ruter? ¿Deberíamos intentar rutar un túnel a través de ese ruter? En particular, la opción de la capacidad de ancho de banda sólo se usa para determinar cuando el ruter cumple un umbral para poder rutar túneles. Por encima del umbral mínimo el ancho de banda anunciado no es usado o confiable en ningún sitio del ruter, excepto para mostrar en el interfaz del usuario para depurar y para el análisis de tráfico.

Additional Options

La opciones de texto adicionales incluyen un pequeño número de estadísticas sobre la salud de los ruters, que son añadidas por las webs como stats.i2p, estadísticas, para el análisis del rendimiento de la red y su depuración. Estas estadísticas fueron elegidas para proporcionar datos importantes a los desarrolladores, como la tasa de éxito al construir los túneles, mientras se hace un balanceo de los posibles daños causados por la revelación de estos datos y necesidad de obtenerlos. Estas estadísticas están limitadas a:

  • Tasas de creación de túneles exploratorios exitosos, rechazados y con periodo de espera agotado
  • Media del número de túneles participantes en 1 hora

Los routers de inundación (floodfill) publican datos adicionales sobre el número de entradas en sus base de datos de red.

Los datos publicados pueden verse en en interfaz del ruter,, pero el ruter no los usa ni confía en ellos. Según madura la red, hemos eliminado la mayoría de las estadísticas publicadas para mejorar el anonimato, y tenemos planeado eliminar más en las próximas versiones.

Family Options

As of release 0.9.24, routers may declare that they are part of a "family", operated by the same entity. Multiple routers in the same family will not be used in a single tunnel.

The family options are:

  • family (The family name)
  • family.key The signature type code of the family's Signing Public Key (in ASCII digits) concatenated with ':' concatenated with the Signing Public Key in base 64
  • family.sig The signature of ((family name in UTF-8) concatenated with (32 byte router hash)) in base 64

Caducidad de RouterInfo

RouterInfo no tienen tiempo de caducidad. Cada ruter puede mantener su propia política local a la hora de controlar la frecuencia de las búsquedas de RouterInfo y el uso de memoria y espacio en le disco. En la implementación actual, estas son las políticas generales:

  • No existe vencimiento durante la primera hora encendido, ya que los datos almacenados podrían ser viejos.
  • No existe vencimiento si hay 25 o menos menos routerInfos
  • Según aumenta el número de RouterInfos, el tiempo de espiración disminuye, en el intento de mantener un número razonable de RouterInfos . El número de espiración con menos de 120 ruters es de 72 horas, mientras que el tiempo de caducidad con 300 ruters es de 30 horas.
  • Los RoutersInfos que contienen introductores SSU expiran en 1 hora más o menos, ya que la lista del introductor expiran en ese mismo tiempo.
  • Los FloodFills tienen un tiempo de expiración corto (1 hora) para todos los RoutersInfos locales, ya que como RoutersInfos válidos serán re publicados.

Almacenamiento persistente de RouterInfo

Los RoutersInfos son periodicamente escritos en el disco duro para que estén disponibles después de reiniciar.

Consulte también

Especifiaciones de RouterInfo

Javadoc de RouterInfo

LeaseSet

La segunda parte de los datos distribuidos en la netDb es un "LeaseSet" - el cual documenta un conjunto de puntos de entradas de túnel (leases o contratos) para una destinación de un cliente en particular. Cada uno de estos leases especifica la siguiente información:

  • La puerta de salida de túnel del ruter (especificando su identidad)
  • El ID del túnel con los que el túnel envía mensajes (un número de 4 bytes)
  • Cuando expirará ese túnel.

El propio LeaseSet es almacenado en la netDb bajo la clave derivada del hash SHA256 de la destinación.

Además de estos leases, el LeaseSet incluye:

  • The destination itself (a 2048bit ElGamal encryption key, a signing key and a certificate)
  • Una clave pública de cifrado adicional: usada para el cifrado de fin a fin de los mensajes garlic
  • Una clave de firma pública adicional: para la revocación del LeaseSet, pero actualmente no se usa.
  • La firma de toda la información del LeaseSet, para asegurarse de que la Destinación publicó ese LeaseSet.

Especificaciones del Lease
Especificaciones del LeaseSet

Javadoc del Lease
Javadoc del LeaseSet

LeaseSets no publicados

Una destinación LeaseSet sólo usada para conexiones de salida que no será publicada. Nunca será enviada para publicarse en los ruters floodfill. Los túneles "Cliente", como aquellos que se usan para navegarse o para los clientes IRC, nunca se publican. Los servidores podrán todavía enviar mensajes a esas destinaciones no publicadas, gracias a los mensajes de almacenamiento I2NP.

LeaseSets Revocados

Un LeaseSet puede ser revocado publicando un nuevo LeaseSet sin leases. Las revocaciones tienen que ser firmadas por la clave de firmado adicional del LeaseSet. La revocación no está completamente implementada, y no está claro si tiene algún uso práctico. Este es el único uso planeado para la clave de firmado, por lo cual no se usa.

LeaseSets Cifrados

In an encrypted LeaseSet, all Leases are encrypted with a separate key. The leases may only be decoded, and thus the destination may only be contacted, by those with the key. There is no flag or other direct indication that the LeaseSet is encrypted. Encrypted LeaseSets are not widely used, and it is a topic for future work to research whether the user interface and implementation of encrypted LeaseSets could be improved.

Expiración del LeaseSet

Todos los Leases (túneles) son válidos sólo durante 10 minutos; por lo tanto, un LeaseSet expira 10 minutos más tarde que el tiempo de creación de todos sus Leases.

Almacenamiento persistente del LeaseSet

No existe el almacenamiento persistente de LeaseSets ya que expiran muy rápido.

Secuencia de arranque

La netDb (base de datos de red) es descentralizada, aún así necesita al menos una referencia a un par (peer) para que el proceso de integración le una a la red. Esto se consigue "resembrando" el router I2P con la RouterInfo de un par activo - específicamente, obteniendo su fichero routerInfo-$hash.dat y almacenándolo en su directorio netDb/. Cualquiera puede proporcionarle estos ficheros - incluso usted puede proporcionárselos a otros exponiendo su propio directorio netDb. Para simplificar el proceso, hay voluntarios que publican sus directorios netDb (o un subconjunto) en Internet (fuera de I2P), y las URLs de estos directorios están codificadas dentro de la aplicación I2P. Cuando el router I2P arranca por primera vez, descarga automáticamente el fichero de una de estas URLs seleccionada de forma aleatoria.

FloodFill

El floodfill netDb is simplemente un mecanismo de almacenamiento distribuido. El algoritmo de almacenamiento es simple: envía los datos al par más cercano que se haya anunciado como floodfill. Espera 10 segundos, alije otro ruter floodfill y le pregunta por la entrada a enviar, verificando su propia introducción / distribución. Si el par de verificación no responde, o no tienen la entrada pedida, el transmisor repite el proceso. Cuando un par de la netDb floodfill recibe un almacenamiento netDb de un par que no está en la netDb floodfill, lo envía a un subconjunto del los pares floodfill netDb. Los pares seleccionados son los más cercanos a una clave especificada (de acuerdo con el XOR-metric).

Determinar quien es parte del floodfill netDb es algo trivial - se muestra en el routerinfo publicado de cada ruter como una capacidad.

Los flodfill no tienen inguna autoridad central y no forman ningún "consenso" - sólo implementan una capa DHT.

Convertirse en un ruter floodfill

Al contrario que en Tor, donde los servidores están incluidos y son de confianza, y operados por identidades conocidas, los miembros de los pares floodfill de I2P no necesitas ser de confianza, y cambian con el tiempo.

Para incrementar la fiabilidad de la netDb, y minimizar el impacto del tráfico de la netDb en un ruter, floodfill solo está activo por defecto en los routers configurados para compartir un gran ancho de banda. Los routers con límites grandes de compartición de ancho de banda (lo que se puede configurar manualmente, ya que por defecto es mucho más bajo) presuntamente tienen conexiones de baja latencia, y es más probable que estén disponibles 24/7. El ancho de banda mínimo a compartir para convertirse en floodfill es de 128 KBytes/sec.

Además, un ruter debe pasar varios pruebas adiciones para comprobar su salud (tiempo de espera de los mensajes de salida, retraso de los trabajos, etc) antes de que se active automáticamente como un floodfill.

Con las reglas actuales para la aceptación automática, aproximadamente el 6% de los routers en la red son routers floodfill.

Mientras que algunos pares se configuran manualmente para ser floodfill, otros son simplemente ruters con gran ancho de banda que son automáticamente convertidos en floodfill cuando el número de pares floodfill baja de un límite. Esto evita el daño por un tiempo largo cuando se pierden la mayoría de los ruters floodfill a causa de un ataque. A su vez, estos pares dejarán de ser floodfill cuando ya haya suficientes floodfills activos.

El papel del ruter floodfill

Los únicos servicios que tienen de más los ruters floodfill que no tienen los ruters no floodfill es aceptar almacenamientos en la netDb y el responder a las solicitudes de la netDb. Ya que normalmente tienen un gran ancho de banda, es más usual que participen en un gran número de túneles (por ejemplo como un "relay" para otros), pero esto no está relacionado directamente con sus servicios distribuidos de la base de datos.

Medida de cercanía Kademlia

La base de datos de red (netDb) utiliza una métrica XOR estilo-Kademlia sencilla para determinar la cercanía. El identificador criptográfico (hash) SHA256 de la clave que se está buscando, o almacenando XOReada con el identificador criptográfico del router en cuestión para determinar la cercanía. Se ha realizado una modificación en este algoritmo para incrementar el coste de los ataques Sybil. En lugar del hash SHA256 de la clave que se está buscando o almacenando, el identificador criptográfico SHA256 se toma de la clave de búsqueda binaria de 32-bytes sufijada con la fecha UTC representada como una cadena ASCII de 8-bytes aaaaMMdd, es decir SHA256(clave + aaaaMMdd). A esto se le llama "clave de enrutado", y cambia cada día a la medianoche UTC. Sólo la clave de búsqueda es modificada de esta forma, no los identificadores criptográficos de los routers de inundación. A la transformación diaria de la DHT (tabla dinámica de hashes) a veces se le llama "rotación del espacio de claves" (keyspace rotation), aunque no es estrictamente una rotación.

Las claves de enrutado nunca se envían por-el-cable en ninguno de los mensajes I2NP, sólo se usan localmente para determinar la distancia.

Mecanismos de almacenaje, verificación y bloqueo

Almacenamiento del RouterInfo en los pares

Los mensajes I2NP DatabaseStoreMessages que contienen el RouterInfo local son intercambiados con pares como parte de la inicialización de una conexión de transporte NTCP o SSU.

Almacenamiento del LeaseSet en los pares

Los mensajes I2NP DatabaseStoreMessages que contienen el LeaseSet local son intercambiados periódicamente con pares agrupándolos en un mensaje garlic junto con el tráfico normal desde la Destinación relacionada. Esto permite enviar una respuesta inicial, y una respuesta posterior, al Lease apropiado, sin necesidad de hacer búsquedas de LeaseSet, o tener que comunicarse con las Destinaciones para publicar los LeaseSets.

Floodfill Selection

El DatabaseStoreMessage (mensaje de almacén de base de datos) debe enviarse al router de inundación (`floodfill`, extienden la red I2P al desplegarse en inundación portando la base de datos distribuida netDb) más cercano al lugar donde se esté guardando la clave de enrutado actual para el RouterInfo o el LeaseSet. Actualmente el router floodfill más cercano se obtiene mediante una búsqueda en la base de datos local. Incluso si ese router floodfill no es en realidad el más cercano, lo inundará "hacia si" enviándo el mensaje a otros múltiples routers de inundación. Esto proporciona un alto grado de tolerencia a fallos.

En el Kademlia tradicional, un par (`peer`) haría una búsqueda "find-closest" (encuentra al más cercano) antes de insertar un elemento en la DHT (tabla de hash dinámica) hacia el objetivo más cercano. Como la operación de verificación tenderá a descubrir los routers floodfills más cercanos si están presentes, un router mejorará rápidamente su conocimiento del "vecindario" de la DHT para el RouterInfo (información para contactar routers) y los LeaseSets (información para contactar destinos) que publica regularmente. Aunque I2NP no define un mensaje "find-closest", si fuera necesario un router simplemente podría hacer una búsqueda iterativa de la clave con el bit menos significativo invertido (es decir, la clave ^ 0x01) hasta que no se reciban pares más cercanos en los DatabaseSearchReplyMessages (mensajes de respuesta de búsqueda de la base de datos). Esto asegura que se encontrará al verdadero par más cercano incluso si un par más-distante tiene el elemento netDb.

Almacenamiento de RouterInfo en los Floodfills

Un ruter publica su propia RouterInfo conectándose directamente a un ruter Floodfill y enviando un I2NP DatabaseStoreMessage con un token de respuesta no vacío. Este mensaje está cifrado de fin a fin como Garlic, y es una conexión directa, con lo cual no hay ruters en medio (no se necesita ocultar ninguna información). El ruter floodfill responde con un I2NP DeliveryStatusMessage, con el ID del mensaje puesto en el valor del token de respuesta.

Almacenamiento de LeaseSet en los Floodfills

El almacenamiento de los LeaseSets es mucho más sensible que el de los RouterInfos, ya que un ruter debe de tener cuidad de que el LeaseSet no pueda ser asociado con el ruter.

Un ruter publica un LeaseSet local enviando un I2NP DatabaseStoreMessage con un token de respuesta no vacío sobre un túnel cliente de salida desde esa Destinación. Este mensaje es cifrado de fin a fin con Garlic usando el administrador de claves de la sesión de la Destinación, para ocultar el mensaje en el punto final del túnel de salida. El ruter floodfill responde con un I2NP DeliveryStatusMessage, con el ID del mensaje puesto como el token de respuesta. Este mensaje es enviado de vuelta a los túneles de entrada del cliente.

Inundación

Después de que un router floodfill (de inundación) reciba un DatabaseStoreMessage conteniendo un RouterInfo (información para contactar con un router) o LeaseSet (información para contactar con un Destino) que esté más actualizado que el guardado previamente en su NetDb local, lo "inunda". Para inundar una entrada NetDb, busca varios (actualmente 3) routers floodfill más próximos a la clave de enrutamiento de la entrada NetDb. (La clave de enrutamiento es el (identificador criptográfico) Hash SHA256 de la RouterIdentity o Destino con la fecha (aaaaMMdd) como sufijo). Mediante la inundación a aquellos más próximos a la clave, no los más próximos a si mismos, el router flloodfill asegura que el almacenamiento llega al lugar adecuado, incluso si el router almacenante no tenía un buen conocimiento del "vecindario" DHT (tabla de hash distribuida) de la clave de enrutamiento.

El router floodfill conecta entonces directamente a cada uno de esos pares y les envía un DatabaseStoreMessage I2NP con una credencial (`token`) de respueta cero. El mensaje no está cifrado extremo-a-extremo con garlic (ajo), ya que esta es una conexión directa, así que no hay routers intervinientes (y de todas formas no hay necesidad de esconder este dato). Los otros routers no responden ni re-inundan, ya que la credencial de respuesta es cero.

Búsquedas de RouterInfo y LeaseSet

El DatabaseLookupMessage (mensaje de consulta a la base de datos) de I2NP se usa para solicitar una entrada netDb desde un router floodfill. Las consultas se transmiten por uno de los túneles exploratorios de salida del router. Las respuestas están definidas para volver a través de uno de los túneles exploratorios de entrada del router.

Las consultas generalmente se envían a los dos routers floodfill "buenos" (en los que la conexión no falla) más próximos a la clave solicitada, en paralelo.

Si el router floodfill encuentra la clave localmente, responde con un DatabaseStoreMessage (mensaje de almacenaje en la base de datos) de I2NP. Si el router floodfill no encontró la clave localmente, responde con un DatabaseSearchReplyMessage (mensaje de respuesta a búsqueda en la base de datos) de I2NP conteniendo una lista de otros routers floodfill próximos a la clave.

Las consultas de LeaseSet (información para contactar destinos) están cifradas extremo-a-extremo con garlic (ajo) desde la versión 0.9.5. Las consultas de RouterInfo (información para contactar routers) no están cifradas y por tanto son vulnerables a espionaje por el extremo exterior (outbound endpoint, OBEP) del túnel cliente. Esto es debido a lo caro del cifrado ElGamal. El cifrado de la consulta RouterInfo puede que sea habilitado en una futura versión.

Desde la versión 0.9.7 las respuestas a una consulta de LeaseSet (un DatabaseStoreMessage o un DatabaseSearchReplyMessage) estarán cifradas mediante la inclusión de la clave de sesión y la etiqueta en la consulta. Esto esconde la respuesta desde la pasarela de entrada (inbound gateway, IBGW) del túnel de respuesta. Las respuestas a consultas a de RouterInfo serán cifradas si se habilita el cifrado de consultas.

(Referencia: Hashing it out in Public (Discutiéndolo en público [juego de palabras]) Secciones 2.2-2.3 para los términos en itálica de debajo)

Debido al relativamente pequeño tamaño de la red y la redundancia de la inundación por un factor 8x, las consultas son habitualmente O(1) más bien que O(log n) -- un router es altamente probable que conozca un router floodfill suficientemente cercano a la clave para obtener la respuesta en el primer intento. En versiones anteriores a la 0.8.9, los routers usaban una redundancia de consulta de dos (esto es, se realizaban dos consultas en paralelo a direferentes pares), y ni el enrutado recursivo ni el iterativo estaba implementado para las consultas. Las peticiones se enviaban a través de múltiples rutas simultáneamente para reducir la posibilidad de fallo de consulta.

Desede la versión 0.8.9 las consultas iterativas se implementaron sin redundancia en la consulta. Esta es una consulta más eficiente y fiable, que funcionará mucho mejor cuando no sean conocidos todos los pares de inundación (`floodfill peers`), y elimina una seria limitación al crecimiento de la red. Al crecer la red y que cada router conozca sólo un pequeño subconjunto de los pares de inundación, las consultas llegarán a ser O(log n). Incluso si los pares no devuelven referencias más cercanas a la clave, la consulta continúa con el par más-próximo-a-continuación, para añadir robustez, y para prevenir que un par de inundación malicioso acapare (`black-holing`) una parte del espacio de la clave. Las consultas continúan hasta que se alcance el total del tiempo límite de la consulta o se haya consultado al número de pares máximo.

Los identificadores (`IDs`) de nodos son verificables en aquellos [nodos] en los que usamos el identificador criptográfico del router (`hash`) directamente tanto como identificador (`ID`) de nodo y como clave Kademlia. Las respuestas incorrectas que no sean más cercanas a la clave de búsqueda son ignoradas por lo general. Dado el actual tamaño de la red, un router tiene conocimiento detallado del vecindario del espacio del identicador (`ID`) del destino.

Verificación del almacenamiento de la RouterInfo

Nota: La verificación del RouterInfo (información para contactar con un router) está deshabilitada desde la versión 0.9.7.1 para prevenir el ataque descrito en el ensayo (ataques prácticos contra la red I2P) Practical Attacks Against the I2P Network. No está claro si la verificación puede rediseñarse para ser realizada de forma segura.

Para verificar que un almacenamiento fue exitoso, un router simplemente espera cerca de 10 segundos, entonces envía una consulta a otro router de inundación (`floodfill`) cercano a la clave (pero no al que se envió el almacenamiento). Las consultas establecieron uno de los túneles exploratorios de salida del router. Las consultas están cifradas extremo-a-extremo con garlic (ajo) para prevenir la vigilancia en el extremo exterior (OutBound End Point, OBEP).

Verificación del almacenamiento del LeaseSet

Para verificar que el almacenamiento fue exitoso, un router simplemente espera cerca de 10 segundos, y luego envía una consulta a otro router de inundación (`floodfill`) cercano a la clave (pero no al que se envió el almacenamiento). Las consultas establecieron uno de los túneles de salida del cliente para el destino del LeaseSet (grupo de túneles para un destino) que se está verificando. Para prevenir la vigilancia en el OBEP (extremo exterior) del túnel de salida, las consultas están cifradas extremo-a-extremo con garlic (ajo). Se especifica a las respuestas que vuelvan a través de uno de los túneles de entrada del cliente.

Desde la versión 0.9.7, las respuestas tanto para las consultas de RouterInfo como de LeaseSet (un DatabaseStoreMessage o un DatabaseSearchReplyMessage) estarán cifradas para ocultar la respuesta desde la pasarela de entrada (`inbound gateway`, IBGW) del túnel de respuesta.

Exploración

La exploración es una forma especial de consulta netDb, donde un router intenta aprender sobre nuevos routers. Esto lo hace enviando a un router de inundación (`floodfill`) un DatabaseLookupMessage I2NP, en busca de una clave aleatoria. Como esta consulta fallará, el router de inundación normalmente respondería con un DatabaseSearchReplyMessage I2NP conteniendo los identificacadores criptográficos (`hashes`) de routers de inundación cercanos a la clave. Esto no sería de ayuda ya que el router solicitante probablemente ya conoce esos routers de inundación, y no sería práctico añadirlos a TODOS al campo "no incluir" de la consulta. Para una petición de exploración, el router solicitante añade un identificador criptográfico (`hash`) de router, con todo ceros, al campo "no incluir" del DatabaseLookupMessage de la consulta. El router de inundación entonces responderá sólo con routers no-de-inundación cercanos a la clave solicitada.

Notas sobre las respuestas a consultas

La respuesta a una solicitud de consulta es o bien (si tiene éxito) un mensaje de alcemacenamiento en la base de datos (DSM), o (si falla) un mensaje de respuesta de búsqueda en la base de datos (DSRM). El DSRM contiene un campo 'from' (desde) en el hash del router para indicar la fuente de la respueta; el DSM no. El campo 'from' (desde) del DSRM no está autentificado y pude ser vigilado o inválido. No hay otras etiquetas de respuesta. Por lo tanto, cuando se hacen múltiples solicitudes en paralelo, es difícill monitorizar el rendimiento de los diferentes routers de inundación.

MultiHospedaje (MultiHoming)

Los destinos I2P pueden ser alojados simultáneamente en múltiples routers I2P, usando las mismas claves pública y privada (tradicionalmente almacenadas en los ficheros eepPriv.dat). Como ambas ambas instancias publicarán periódicamente sus LeaseSets hacia los pares de inundación (floodfill peers), el LeaseSet (túneles al mismo destino I2P) publicado más recientemente será devuelto a un par como resultado de una búsqueda en la base de datos. Como los LeaseSets tienen (como mucho) 10 minutos de vida, si alguno de los routers I2P se cae, el corte será como mucho de 10 minutos, y normalmente mucho menos tiempo. La función de multihospedaje (multihoming) ha sido verificada y está en uso en varios servicios de la red.

Análisis de amenazas

También se debate en la web de los modelos de amenazas.

Un usuario hostil puede intentar dañar la red creando uno o más ruters floodfill y configurándolos para ofrecer respuestas malas, lentas o incluso no ofrecerlas. Algunos escenarios se discuten más abajo.

Mitigación general a través del crecimiento

Actualmente hay alrededor de 600 routers floodfill (de inundación) en la red. La mayoría de los ataques siguientes se harán más difíciles, o tendrán menos impacto, al incrementarse el tamaño de la red e incrementarse el número de routers floodfill.

Mitigación general a través de la redundancia

Mediante la inundación, todas las entradas NetDb se almacenan en los 3 routers floodfill (de inundación ) más próximos a la clave.

Falsificaciones

Todas las entradas de la netdb están firmadas por sus creadores, por lo que ningún ruter puede crear un RouterInfo o un LeaseSet.

Lento o sin respuestas

Cada ruter mantiene un dilatado conjunto de estadísticas en el perfil del par por cada ruter floodfill, con información sobre varias medidas de calidad de ese par. Este conjunto incluye:

  • Tiempo medio de respuesta
  • Porcentaje de consultas respondidas con los datos solicitados
  • Porcentaje de los almacenamientos que fueron verificados satisfactoriamente
  • El último almacenaje exitoso
  • La última búsqueda exitosa
  • Última respuesta

Cada vez que un ruter necesita determinar cual ruter floodfill está más cercano a cierta clave, utiliza estas medidas para determinar que floodfills son "buenos". Estos métodos, y umbrales, usados para determinar "lo bueno que es" son relativamente nuevos, y pueden ser revisados y mejorados. Mientras que un ruter que no responda será identificado y evitado rápidamente, los ruters que sólo son maliciosos a veces pueden ser mucho más difíciles de manejar.

Ataque Sybil (espacio de claves completo)

Un atacante puede crear un ataque Sybil creando un gran número de ruters floodfill repartidos a través del espacio de claves, keyspace.

(Como ejemplo relacionado, recientemente un investigador creó un gran número de relays Tor.) Si es exitoso, podría ser un ataque DOS efectivo en toda la red.

Si los floodfills no se comportan suficientemente mal para ser marcados como "malos" usando las medidas del perfil del par descritas antes, sería un escenario muy difícil de manejar. Las respuestas de la red Tor pueden ser mucho más ágiles en el caso de los relays, ya que los relays maliciosos pueden ser eliminados manualmente del consenso. Algunas respuestas factibles para la red I2P son listadas debajo, aunque ninguna de ellas es totalmente satisfactoria:

  • Crear una lista de hashes de ruters malos o IPs, y anunciar la lista de varias formas (novedades de consola, web, forums, etc.); los usuarios tendrían que descargar la lista manualmente y añadirla a "lista negra" local.
  • Pedir a todos los usuarios de la red el activar el floodfill manualmente (luchar contra Sybil con más Sybil)
  • Liberar una nueva versión del software que incluya la lista "mala" inscrustada en el código
  • Liberar una versión del software nueva que mejore los umbrales y las medidas del perfil de los pares, para intentar identificar los pares "malos" automáticamente.
  • Añadir una ampliación que descalifique floodfills si hay demasiados de ellos en un único bloque de IPs
  • Implementar una lista negra automática basada en suscripciones controlada por un único grupo individual. Esto esencialmente implementaría una parte del modelo de "consenso" de Tor. Desafortunadamente le daría a un solo grupo el poder de bloquear la participación de cualquier ruter o IP en la red, o incluso apagar o destruir la red entera.

Este ataque se hace más difícil cuanto más grande es la red.

Ataque Sybil (espacio de claves parcial)

Un atacante puede montar un ataque Sybil creando un pequeño número de ruters floodfill (8-15) cercanos en el espacio de claves, y distribuir los RouterInfos de esos ruters extensamente. Entonces, todas las búsquedas y almacenamientos de una clave en ese espacio de claves serán dirigidod a uno de los ruters del atacante. Si ha tenido éxito, esto podía provocar un ataque DOS efectivo sobre un eepsite en particular, por ejemplo.

Ya que el espacio de claves está indexado por el hash criptográfico (SHA256) de la clave, un atacante tiene que usar la fuerza bruta para generar repetidamente hashes de routers hasta que tenga suficientes que estén suficientemente cerca de la clave. La cantidad de potencia de cálculo requerida para esto, la cual depende del tamaño de la red, es desconocida.

Como una defensa parcial contra este ataque, el algoritmo usado para determinar la "cercanía" Kademlia varía con el tiempo. En vez de usar el hash de la clave (por ejemplo H(k)) para determinar la cercanía, usamos el Hash de la clave añadido a la cadena de datos actuales, por ejemplo H(k + YYYYMMDD). En otras palabras, el espacio de claves completo de la netdb "rota" cada día a la media noche UTC. Cualquier ataque parcial al espacio de claves tendría que regenerarse cada día, después de cada rotación los ruters atacantes no estarán ya cerca de la clave del objetivo.

Este ataque se hace más difícil según crece la red. Aunque estudios recientes han demostrado que la rotación del espacio de claves no es particularmente efectiva. Un atacante podría pre-calcular numerosos hashes de ruters de antemano, y sólo son necesarios unos pocos ruters para "eclipsar" una parte del espacio de claves en sólo media hora después de la rotación.

Una de las consecuencias de la rotación diaria del espacio de claves es que la base de datos de la red distribuida se vuelve no fiable durante unos minutos tras la rotación -- las búsquedas fallarán porque los nuevos routers "más cercanos" no han recibido aún un almacenamiento. El alcance del problema, y los métodos para mitigarlo (por ejemplo con "handoffs, manos fuera" de la netdb a media noche) es un tema para futuros estudios.

Ataques Bootstrap, de arranque

Un atacante podría intentar arrancar nuevos ruters dentro de una red aislada o controlada en su mayoría por él tomando control de una web de resiembra, o engañando a los desarrolladores para que añadan su web de resembrado dentro del código del ruter.

Existen varias defensas posibles, y la mayoría ya están planeadas:

  • Desautoriza recurrir a HTTP desde HTTPS para el resembrado. Un atacante mediante un ataque de hombre-en-el-medio (MitM) podría simplemente bloquear HTTPS, y responder al HTTP.
  • Incluyendo los datos de resiembra en el instalador

Defensas que están implementadas:

  • Cambiar la tarea de resembrado para obtener un subconjunto de RouterInfos desde varias webs de resiembra en vez de usar una única web.
  • Creando un servicio de monitoreo de resiembras fuera de la red, que periódicamente pregunte a las webs de resiembra y verifique que los datos no están corruptos o son inconsistentes con otras vistas de la red.
  • Desde la versión 0.9.14, los datos de resembrado están empaquetados en un fichero zip firmado, y la firma se verifica cuando es descargado. See the su3 specification for details.

Captura de peticiones

Vea también búsquedas (Referencia: Hashing it out in Public Secciones 2.2-2.3 para los términos en cursiva de abajo)

Similar a un ataque bootstrap, un atacante usando un ruter floodfill podría intentar "dirigir" a los pares a un subconjunto de ruters controlados por él devolviendo sus referencias.

Esto es raro que funcione vía exploración, porque la exploración es una tarea de baja frecuencia. Los ruters obtienen la mayoría de sus referencias sobre los pares cuando crean los túneles normales. Los resultados de exploración están generalmente limitados a unos pocos hashes de ruters, y cada petición de exploración es dirigida a un ruter floodfill aleatorio.

A partir de la versión 0.8.9, se han implementado las búsquedas iterativas. Las referencias de los ruters floodfill devueltas en una respuesta de búsqueda I2NP DatabaseSearchReplyMessage, son seguidas si están más cerca (o la siguiente más cerca) a la clave de búsqueda. El ruter que hace la petición no confía en que las referencias estén más cerca a la clave (por ejemplo, son verificablemente correctas). Además la búsqueda no termina cuando la clave más cercana es encontrada, continúa haciendo peticiones al siguiente nodo más cercano, hasta que termine su tiempo o el número de peticiones. Esto previene que un floodfill malicioso haga un 'agujero negro' a una parte del espacio de claves. Además, la rotación diaria del espacio de claves requiere que el atacante regenere la información de un ruter dentro de la región del espacio de claves deseada. Este diseño asegura que el ataque de captura de peticiones descrito en Hashing it out in Public sea mucho más difícil.

Selección del Relay basado en DHT

(Referencia: Hashing it out in Public Sección 3)

Esto no tiene mucho que ver con los floodfill, pero vea la página de selección de pares para ver una discusión de las vulnerabilidades de la selección de los pares para los túneles.

Fugas de información

(Referencia: In Search of an Anonymous and Secure Lookup Sección 3)

Este estudio soluciona la debilidad en las búsquedas DHT "Finger Table" usadas por Torks y NISAN. A primera vista, estos parecen que no se apliquen a I2P. Primero, el uso que hacen Torks y NISAN del DHT es bastante diferente que su uso en I2P. Segundo, las búsquedas en la base de datos de red de I2P sólo están un poco relacionadas con los procesos de selección de pares y de construcción de túneles; sólo los pares previamente conocidos son usados para los túneles. Además, la selección de pares no tiene relación con la noción de cercanía de claves DHT.

Algunos de estos serán más interesantes cuando la red I2P sea mucho más grande. Ahora mismo, cada ruter conoce una gran porción de la red, con lo que mirando por un RouterInfo en particular en la base de datos de la red no indica que ese ruter se vaya a usar en un túnel. Quizás cuando la red sea 100 veces más grande, la búsqueda sea correlativa. Por supuesto, una red más grande hace que un ataque Sybil sea mucho más difícil.

Sin embargo, el problema general de la filtración de información DHT (tabla de identificadores criptográficos (hash) dinámica) en I2P necesita posterior investigación. Los routers de inundacion (`floodfill`) están en posición de observar peticiones y reunir información. Ciertamente, a un nivel de f = 0.2 (20% nodos maliciosos, tal como detalla la especificación) esperamos que muchas de las amenazas Sybil que describimos (aquí, aquí y aquí) se volverán problemáticas por varios motivos.

Historia

Movido a la página de discusión de la netdb.

Trabajo futuro

Cifrado de fin a fin de las búsquedas y respuestas adicionales en la netDb.

Mejores métodos de seguimiento de las respuestas de las búsquedas.