Esta página fue actualizada por última vez el Marzo de 2014 y es precisa con la versión 0.9.12 del router I2P.

Garlic Routing y terminología "Garlic"

Los términos "garlic routing, enrutado garlic" y "garlic encryption, cifrado garlic"son usados a menudo imprecisamente para designar la tecnología de I2P. Aquí vamos a explicar la historia de estos términos, su significados,y el uso de los métodos "garlic" en I2P.

"Garlic Routing" fue acuñado por Michael J. Freedman en la Master's thesis de Roger Dingledine en Free Haven. Sección 8.1.1 (Junio 2000), derivado de Onion Routing.

"Garlic" fue quizás usado por los desarrolladores originales de I2P porque implementa un forma de agrupación tal y como Freedman describió, o simplemente para enfatizar las diferencias con Tor. La razón exacta puede haberse perdido en el tiempo. Generalmente, cuando nos referimos al término "garlic", puede significar una de estas tres cosas:

  1. Cifrado por capas
  2. Agrupa varios mensajes juntos
  3. Cifrado ElGamal/AES

Desafortunadamente, el uso del término "garlic" por parte de I2P en los pasados siete años no ha sido siempre preciso; por lo tanto los usuarios están avisados para cuando se topen con el término. Esperemos que la siguiente explicación dejará las cosas más claras.

Cifrado por capas

El enrutado Onion es una técnica para construir caminos, o túneles, a través de una serie de pares, y después usar ese túnel. Los mensajes son repetidamente cifrados por el creador, y después descifrados por cada salto. Durante la fase de construcción sólo las instrucciones de enrutado para el siguiente salto son expuestas a cada par. Durante la fase de operación los mensajes se pasan a través del túnel, y el mensaje y sus instrucciones de enrutado sólo son mostradas en el punto final del túnel.

Esto es similar a como Mixmaster (ver comparación entre redes) envía mensajes - toma un mensaje, lo cifra con la clave pública del destinatario, toma ese mensaje cifrado y lo cifra (junto con instrucciones indicando el siguiente salto) de nuevo, y así sucesivamente hasta que tiene una capa de cifrado por salto a lo largo de todo el camino.

En este senido, "garlic routing" como concepto general es idéntico a "onion routing". Aunque tal y como se ha implementado en I2P tiene varias diferencias con la implementación de Tor; ver más abajo. Aun así, hay similitudes substanciales, como algunas de las que se beneficia I2P gracias al gran número de estudios académicos sobre la onion routing, Tor, y mixnets similares.

Construyendo múltiples mensajes

Michael Freedman definión "garlic routing" como una extensión de onion routing, en la cual varios mensajes son agrupados juntos. El llamó a cada mensaje "bulb, bulbo". Todos los mensajes, cada uno con sus instrucciones de envío, son expuestos en el punto final. Esto permite una agrupación eficiente del "bloque de respuesta" de una una ruta onion con el mensaje original.

Este concepto ha sido implementado en I2p como se describe más abajo. Nuestro término para "bulbs, bulbos" garlic es "cloves, dientes del ajo". Puede contener cualquier número de mensajes, en vez de un solo mensaje. Esta es una gran diferencia con la implementación de Tor. Aun así, es sólo una de las diferencias entre I2P y Tor; quizás por si misma no sea suficiente para justificar un cambio de terminología.

Otra diferencia con el método descrito por Freedman es que el camino es unidireccional - no existe un "punto de retorno" como en el enrutado onion o en los bloques de respuesta mixmaster, lo que simplifica mucho el algoritmo y permite una entrega fiable.

Cifrado ElGamal/AES

En algunos casos el "cifrado garlic" simplemente significa cifrado ElGamal/AES+SessionTag (sin múltiples capas).

Métodos "Garlic" en I2P

Ahora que hemos definido varios términos "garlic", podemos decir que I2P usa rutado garlic, agrupación y cifrado en tres partes:

  1. Para la construcción y enrutado a través de los túneles (cifrado por capas)
  2. Para determinar el éxito o fallo del envío de un mensaje de fin a fin (agrupamiento)
  3. Para publicar algunas entradas en la base de datos de la red (amortiguando la posibilidad de un ataque de análisis exitoso) (ElGamal/AES)

Hay muchas otras formas de usar esta técnica para mejorar el rendimiento de la red, aprovechando las compensaciones de la latencia del transporte, y derivando datos a través de caminos redundantes para incrementar la fiabilidad.

Rutado y construcción de los túneles

En I2P los túneles son unidireccionales. Cada parte construye dos túneles, uno para el tráfico de salida y otro para el de entrada. Por lo tanto se necesitan cuatro túneles para una vuelta completa de un mensaje y su respuesta.

Los túneles son usados y creados con un cifrado por capas. Esto se describe en página de implementación de los túneles. La construcción de los túneles es definida en esta página. Para el cifrado usamos ElGamal/AES+SessionTag

Los túneles son un mecanismo de propósito general para transportar todos los mensajes I2NP, y los mensajes Garlic no se usan para construir túneles. No agrupamos múltiples mensajes I2NP dentro de un solo mensaje Garlic para desenvolver en el punto funal del túnel de salida, el cifrado del túnel es suficiente.

Agrupación de mensajes de fin a fin.

En la capa por encima de los túneles, I2P entrega mensajes extremo-a-extremo entre Destinos. De igual modo que dentro de un único túnel, para el cifrado usamos ElGamal/AES+SessionTag (etiqueta de sesión). Cada mensaje de cliente tal como se entrega al router I2P mediante la interfaz I2CP (protocolo cliente de I2P) se convierte en un único Diente de Ajo (garlic clove) con sus propias Instrucciones de Entrega, dentro de un Mensaje Ajo (garlic message). Las Instrucciones de Entrega pueden especificar un Destino, Router I2P, o Túnel.

Generalmente, un mensaje Garlic sólo contiene un clove. Aun así, el ruter agrupa periódicamente dos dientes adicionales en el mensaje Garlic:

Cloves, dientes, de los mensajes Garlic, ajo
  1. Un Mensaje de Estado de Entrega, con Instrucciones de Entrega que especifican que se enviará de vuelta al router I2P originario como un acuse de recibo. Esto es similar al "reply block" (bloque de respuesta) o "reply onion" (cebolla de respuesta) descritos en las referencias. Se usa para determinar el éxito o fracaso de la entrega del mensaje extremo-a-extremo. El router I2P originario puede, tras no recibir el Mensaje de Estado de Entrega dentro del periodo de tiempo de espera, modificar el enrutamiento hacia el Destino del extremo distante, o tomar otras acciones.
  2. Un Mensaje del Almacenamiento de la Base de Datos, conteniendo un LeaseSet para el Destino originario, con Instrucciones de Entrega que especifican el router I2P del destino del extremo remoto. Al empaquetar periódicamente un LeaseSet, el router I2P se asegura de que el extremo remoto podrá mantener las comunicaciones. De otro modo el extremo remoto tendría que preguntar por la entrada en la base de datos de red a un router I2P de inundación (floodfill), y todos los LeaseSets tendrían que ser publicados en la base de datos de red, como se explicó en la página de la base de datos de red.

Por defecto, los mensajes de estado de entrega (Delivery Status) y almacenado en base de datos (Database Store) son empaquetados cuando el LeaseSet local (conjunto de túneles al destino local) cambia, cuando se entregan etiquetas de sesión (Session Tags) adicionales, o si los mensajes no han sido empaquetados en el minuto anterior. Desde la versión 0.9.2, el cliente puede configurar el número de etiquetas de sesión predeterminado a enviar y el umbral de bajo número de etiquetas para la sesión actual. Vea la especificación de opciones I2CP para más detalles. Las preferencias de sesión también pueden ser sustituidas para cada mensaje. Vea la especificación de Expiración de envio de mensaje I2CP para más detalles.

Obviamente, los mensajes adicionales son agrupados por un propósito específico, y no son parte del esquema general de rutado.

Desde la versión 0.9.12, el mensaje de estado de entrega está encapsulado en otro mensaje ajo (garlic) por el originador, así que los contenidos están cifrados y no son visibles para los routers I2P en la ruta de retorno.

Almacenamiento en la base de datos de un FloodFill

Como se ha explicado en la página de la base de datos de la red, los LeaseSets locales son enviados a los ruters FloodFill en un mensaje de almacenamiento de la base de datos envuelto en un mensaje Garlic, con lo cual no es visible para la puerta de salida del túnel de salida.

Trabajo futuro

El mecanismo del mensaje garlic (ajo) es muy flexible y proporciona una estructura que implementa muchos tipos de métodos de entrega mixnet (red interpuesta que desliga emisor y receptor mezclando transmisiones). Junto con la opción de retardo en desuso presente en las Instrucciones de Entrega de mensaje por túnel, es posible un amplio espectro de estrategias con lotes, retardo, mezclado, y enrutado.

En particular, hay potencial para mucha más flexibilidad en el punto final del túnel de salida. Los mensajes podrían ser rutados desde ahí a uno o varios túneles (con lo cual se minimizarían las conexiones de punto a punto), o enviar a varios túneles para hacerlo redundante, o hacer streming de audio o vídeo.

Estos experimentos pudrían entrar en conflicto con la necesidad de seguridad y anonimato, ya sea limitando ciertos caminos de enrutado, restringiendo los mensajes I2NP que puedan ser enviados a través de varios caminos, e imponiendo ciertos tiempos de espiración a los mensajes.

Como parte de un cifrado ElGamal/AES, un mensaje Garlic contiene una cantidad especificada de datos de relleno, que permiten al transmisor tomar ciertas contramedidas activas contra el análisis de tráfico. Esto no se usa actualmente, mas allá de la necesidad de rellenar a un múltiplo de 16 bytes.

El cifrado de mensajes adicionales hacia y desde los ruters floodfill.

Referencias