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.

At the layer above tunnels, I2P delivers end-to-end messages between Destinations. Just as within a single tunnel, we use ElGamal/AES+SessionTag for the encryption. Each client message as delivered to the router through the I2CP interface becomes a single Garlic Clove with its own Delivery Instructions, inside a Garlic Message. Delivery Instructions may specify a Destination, Router, or Tunnel.

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. A Delivery Status Message, with Delivery Instructions specifying that it be sent back to the originating router as an acknowledgment. This is similar to the "reply block" or "reply onion" described in the references. It is used for determining the success or failure of end to end message delivery. The originating router may, upon failure to receive the Delivery Status Message within the expected time period, modify the routing to the far-end Destination, or take other actions.
  2. A Database Store Message, containing a LeaseSet for the originating Destination, with Delivery Instructions specifying the far-end destination's router. By periodically bundling a LeaseSet, the router ensures that the far-end will be able to maintain communications. Otherwise the far-end would have to query a floodfill router for the network database entry, and all LeaseSets would have to be published to the network database, as explained on the network database page.

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

The Garlic Message mechanism is very flexible and provides a structure for implementing many types of mixnet delivery methods. Together with the unused delay option in the tunnel message Delivery Instructions, a wide spectrum of batching, delay, mixing, and routing strategies are possible.

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