I2P Client Protocol (I2CP)

Descripción general

Esta es la especificación del I2CP (Protocolo de Control I2P), la interfaz de bajo nivel entre los clientes y el router. Los clientes Java utilizarán la API de cliente I2CP, que implementa este protocolo.

No existen implementaciones conocidas que no sean en Java de una biblioteca del lado del cliente que implemente I2CP. Además, las aplicaciones orientadas a sockets (streaming) necesitarían una implementación del protocolo de streaming, pero tampoco existen bibliotecas que no sean en Java para eso. Por lo tanto, los clientes que no usan Java deberían utilizar en su lugar el protocolo de capa superior SAM SAMv3 , para el cual existen bibliotecas en varios lenguajes.

Este es un protocolo de bajo nivel soportado tanto interna como externamente por el router I2P de Java. El protocolo solo se serializa si el cliente y el router no están en la misma JVM; de lo contrario, los objetos Java de mensajes I2CP se pasan a través de una interfaz JVM interna. I2CP también es soportado externamente por el router de C++ i2pd.

Más información está disponible en la página de Resumen de I2CP I2CP .

Sesiones

El protocolo fue diseñado para manejar múltiples “sesiones”, cada una con un ID de sesión de 2 bytes, sobre una única conexión TCP; sin embargo, las sesiones múltiples no fueron implementadas hasta la versión 0.9.21. Consulta la sección de multisesión más abajo . No intentes usar múltiples sesiones en una única conexión I2CP con routers anteriores a la versión 0.9.21.

También parece que hay algunas disposiciones para que un solo cliente se comunique con múltiples routers a través de conexiones separadas. Esto también está sin probar y probablemente no sea útil.

No hay forma de mantener una sesión después de una desconexión, o de recuperarla en una conexión I2CP diferente. Cuando se cierra el socket, la sesión se destruye.

Secuencias de Mensajes de Ejemplo

Nota: Los ejemplos a continuación no muestran el Byte de Protocolo (0x2a) que debe ser enviado desde el cliente al router al conectarse por primera vez. Más información sobre la inicialización de conexión está en la página de Descripción General de I2CP I2CP .

Establecimiento de Sesión Estándar

  Client                                           Router

                           --------------------->  Get Date Message
        Set Date Message  <---------------------
                           --------------------->  Create Session Message
  Session Status Message  <---------------------
Request LeaseSet Message  <---------------------
                           --------------------->  Create LeaseSet Message

Obtener Límites de Ancho de Banda (Sesión Simple)

  Client                                           Router

                           --------------------->  Get Bandwidth Limits Message
Bandwidth Limits Message  <---------------------

Búsqueda de Destino (Sesión Simple)

  Client                                           Router

                           --------------------->  Dest Lookup Message
      Dest Reply Message  <---------------------

Mensaje Saliente

Sesión existente, con i2cp.messageReliability=none

  Client                                           Router

                           --------------------->  Send Message Message

Sesión existente, con i2cp.messageReliability=none y nonce diferente de cero

  Client                                           Router

                           --------------------->  Send Message Message
  Message Status Message  <---------------------
  (succeeded)

Sesión existente, con i2cp.messageReliability=BestEffort

  Client                                           Router

                           --------------------->  Send Message Message
  Message Status Message  <---------------------
  (accepted)
  Message Status Message  <---------------------
  (succeeded)

Mensaje Entrante

Sesión existente, con i2cp.fastReceive=true (a partir de 0.9.4)

  Client                                           Router

 Message Payload Message  <---------------------

Sesión existente, con i2cp.fastReceive=false (OBSOLETO)

  Client                                           Router

  Message Status Message  <---------------------
  (available)
                           --------------------->  Receive Message Begin Message
 Message Payload Message  <---------------------
                           --------------------->  Receive Message End Message

Notas sobre Multisesión

Se admiten múltiples sesiones en una sola conexión I2CP a partir de la versión 0.9.21 del router. La primera sesión que se crea es la “sesión principal”. Las sesiones adicionales son “subsesiones”. Las subsesiones se utilizan para admitir múltiples destinos que comparten un conjunto común de túneles. La aplicación inicial es que la sesión principal use claves de firma ECDSA, mientras que la subsesión use claves de firma DSA para la comunicación con eepsites antiguos.

Las subsesiones comparten los mismos pools de túneles de entrada y salida que la sesión primaria. Las subsesiones deben usar las mismas claves de cifrado que la sesión primaria. Esto se aplica tanto a las claves de cifrado del leaseSet como a las claves de cifrado del Destination (no utilizadas). Las subsesiones deben usar diferentes claves de firma en el destination, por lo que el hash del destination es diferente al de la sesión primaria. Como las subsesiones usan las mismas claves de cifrado y túneles que la sesión primaria, es evidente para todos que los Destinations están ejecutándose en el mismo router, por lo que las garantías usuales de anonimato anti-correlación no se aplican.

Las subsesiones se crean enviando un mensaje CreateSession y recibiendo un mensaje SessionStatus como respuesta, como es habitual. Las subsesiones deben crearse después de que se haya creado la sesión principal. La respuesta SessionStatus contendrá, en caso de éxito, un ID de sesión único, distinto del ID de la sesión principal. Aunque los mensajes CreateSession deberían procesarse en orden, no hay una forma segura de correlacionar un mensaje CreateSession con la respuesta, por lo que un cliente no debería tener múltiples mensajes CreateSession pendientes simultáneamente. Las opciones de SessionConfig para la subsesión pueden no ser respetadas cuando difieren de la sesión principal. En particular, dado que las subsesiones usan el mismo conjunto de túneles que la sesión principal, las opciones de túnel pueden ser ignoradas.

El router enviará mensajes RequestVariableLeaseSet separados para cada Destination al cliente, y el cliente debe responder con un mensaje CreateLeaseSet para cada uno. Los leases para los dos Destinations no serán necesariamente idénticos, aunque sean seleccionados del mismo pool de túneles.

Una subsesión puede ser destruida con el mensaje DestroySession como es habitual. Esto no destruirá la sesión principal ni detendrá la conexión I2CP. Sin embargo, destruir la sesión principal sí destruirá todas las subsesiones y detendrá la conexión I2CP. Un mensaje Disconnect destruye todas las sesiones.

Tenga en cuenta que la mayoría, pero no todos, los mensajes I2CP contienen un Session ID. Para aquellos que no lo tienen, los clientes pueden necesitar lógica adicional para manejar adecuadamente las respuestas del router. DestLookup y DestReply no contienen Session IDs; use en su lugar los más recientes HostLookup y HostReply. GetBandwidthLimts y BandwidthLimits no contienen session IDs, sin embargo la respuesta no es específica de la sesión.

Notas de Versión

El byte inicial de versión del protocolo (0x2a) enviado por el cliente no se espera que cambie. Antes de la versión 0.8.7, la información de versión del router no estaba disponible para el cliente, lo que impedía que los nuevos clientes funcionaran con routers antiguos. A partir de la versión 0.8.7, las cadenas de versión del protocolo de ambas partes se intercambian en los mensajes Get/Set Date. En adelante, los clientes pueden usar esta información para comunicarse correctamente con routers antiguos. Los clientes y routers no deben enviar mensajes que no sean compatibles con la otra parte, ya que generalmente desconectan la sesión al recibir un mensaje no compatible.

La información de versión intercambiada es la versión de la API “core” o la versión del protocolo I2CP, y no es necesariamente la versión del router.

Un resumen básico de las versiones del protocolo I2CP es el siguiente. Para más detalles, ver abajo.

Encabezado de mensaje I2CP

Descripción

Encabezado común para todos los mensajes I2CP, que contiene la longitud del mensaje y el tipo de mensaje.

Contenidos

1. 4 bytes Integer especificando la longitud del cuerpo del mensaje
2. 1 byte Integer especificando el tipo de mensaje.
3. El cuerpo del mensaje I2CP, 0 o más bytes

Notas

El límite real de longitud de mensaje es de aproximadamente 64 KB.

ID del Mensaje

Descripción

Identifica de manera única un mensaje esperando en un router particular en un momento determinado. Esto siempre es generado por el router y NO es lo mismo que el nonce generado por el cliente.

Contenidos

1. 4 bytes Integer

Notas

Los IDs de mensaje son únicos solo dentro de una sesión; no son globalmente únicos.

Payload

Descripción

Esta estructura es el contenido de un mensaje que se está entregando de un Destination a otro.

Contenido

1. 4 bytes Integer longitud
2. Esa cantidad de bytes

Notas

La carga útil está en formato gzip como se especifica en la página de Resumen de I2CP I2CP-FORMAT .

El límite real de longitud de mensaje es de aproximadamente 64 KB.

Configuración de Sesión

Descripción

Define las opciones de configuración para una sesión de cliente particular.

Contenidos

1. Destination
2. Mapping de opciones
3. Date de creación
4. Signature de los 3 campos anteriores, firmada por la SigningPrivateKey

Notas

• Las opciones se especifican en la página de Descripción General de I2CP I2CP-OPTIONS .
• El Mapping debe estar ordenado por clave para que la firma sea validada correctamente en el router.
• La fecha de creación debe estar dentro de +/- 30 segundos de la hora actual cuando sea procesada por el router, o la configuración será rechazada.

Firmas sin conexión

• Si el Destination está firmado offline, el Mapping debe contener las tres opciones i2cp.leaseSetOfflineExpiration, i2cp.leaseSetTransientPublicKey, y i2cp.leaseSetOfflineSignature. La Signature se genera entonces por la SigningPrivateKey transitoria y se verifica con la SigningPublicKey especificada en i2cp.leaseSetTransientPublicKey. Ver I2CP-OPTIONS para detalles.

ID de Sesión

Descripción

Identifica de manera única una sesión en un router particular en un momento determinado.

Contenidos

1. 2 bytes Integer

Notas

El ID de sesión 0xffff se usa para indicar “sin sesión”, por ejemplo para búsquedas de nombres de host.

Mensajes

Consulta también la documentación de I2CP Javadocs .

Tipos de Mensaje

Descripción

Informar al cliente cuáles son los límites de ancho de banda.

Enviado desde el Router al Cliente en respuesta a un GetBandwidthLimitsMessage .

Contenidos

1. 4 bytes Integer Límite de entrada del cliente (KBps)
2. 4 bytes Integer Límite de salida del cliente (KBps)
3. 4 bytes Integer Límite de entrada del router (KBps)
4. 4 bytes Integer Límite de ráfaga de entrada del router (KBps)
5. 4 bytes Integer Límite de salida del router (KBps)
6. 4 bytes Integer Límite de ráfaga de salida del router (KBps)
7. 4 bytes Integer Tiempo de ráfaga del router (segundos)
8. Nueve Integer de 4 bytes (indefinido)

Notas

Los límites del cliente pueden ser los únicos valores establecidos, y pueden ser los límites reales del router, o un porcentaje de los límites del router, o específicos para el cliente en particular, dependiendo de la implementación. Todos los valores etiquetados como límites del router pueden ser 0, dependiendo de la implementación. A partir de la versión 0.7.2.

BlindingInfoMessage

Descripción

Advierte al router que un Destino está oculto, con contraseña de búsqueda opcional y clave privada opcional para descifrado. Consulta las propuestas 123 y 149 para más detalles.

El router necesita saber si un destino está cegado. Si está cegado y utiliza una autenticación secreta o por cliente, también necesita tener esa información.

Un Host Lookup de una dirección b32 de nuevo formato (“b33”) le dice al router que la dirección está ciega, pero no hay un mecanismo para pasar la clave secreta o privada al router en el mensaje Host Lookup. Aunque podríamos extender el mensaje Host Lookup para agregar esa información, es más limpio definir un nuevo mensaje.

Este mensaje proporciona una forma programática para que el cliente le diga al router. De lo contrario, el usuario tendría que configurar manualmente cada destino.

Uso

Antes de que un cliente envíe un mensaje a un destino cegado, debe buscar el “b33” en un mensaje de Host Lookup, o enviar un mensaje de Blinding Info. Si el destino cegado requiere un secreto o autenticación por cliente, el cliente debe enviar un mensaje de Blinding Info.

El router no envía una respuesta a este mensaje. Enviado del Cliente al Router.

Contenidos

1. ID de Sesión
2. 1 byte Integer Flags

• Orden de bits: 76543210 > - Bit 0: 0 para todos, 1 para por-cliente > - Bits 3-1: Esquema de autenticación, si el bit 0 está establecido en 1 para > por-cliente, de lo contrario 000 > - 000: Autenticación de cliente DH (o sin autenticación por-cliente) > - 001: Autenticación de cliente PSK > - Bit 4: 1 si se requiere secreto, 0 si no se requiere secreto > - Bits 7-5: Sin usar, establecer en 0 para compatibilidad futura

3. 1 byte Integer Tipo de endpoint

• Tipo 0 es un Hash > - Tipo 1 es un nombre de host String > - Tipo 2 es un Destination > - Tipo 3 es un Sig Type y > SigningPublicKey

4. Integer de 2 bytes Tipo de Firma Ciega
5. Integer de 4 bytes Segundos de Expiración desde época
6. Endpoint: Datos como se especifica, uno de

• Tipo 0: 32 bytes Hash > > - Tipo 1: nombre de host String > > - Tipo 2: Destination binario > > > > - Tipo 3: 2 bytes Integer tipo de firma, seguido de > > - SigningPublicKey (longitud como > implica el tipo de firma)

7. PrivateKey Clave de descifrado Solo presente si el bit de bandera 0 está establecido en 1. Una clave privada ECIES_X25519 de 32 bytes, little-endian
8. String Contraseña de búsqueda Solo presente si el bit de bandera 4 está establecido en 1.

Notas

• A partir de la versión 0.9.43.
• El tipo de endpoint Hash probablemente no es útil a menos que el router pueda hacer una búsqueda inversa en la libreta de direcciones para obtener el Destination.
• El tipo de endpoint hostname probablemente no es útil a menos que el router pueda hacer una búsqueda en la libreta de direcciones para obtener el Destination.

CreateLeaseSetMessage

OBSOLETO. No se puede usar para LeaseSet2, claves fuera de línea, tipos de cifrado que no sean ElGamal, múltiples tipos de cifrado, o LeaseSets cifrados. Use CreateLeaseSet2Message con todos los routers 0.9.39 o superior.

Descripción

Este mensaje se envía en respuesta a un RequestLeaseSetMessage o RequestVariableLeaseSetMessage y contiene todas las estructuras Lease que deben publicarse en la Base de Datos de Red I2NP.

Enviado del Cliente al Router.

Contenidos

1. Session ID
2. DSA SigningPrivateKey o 20 bytes ignorados
3. PrivateKey
4. LeaseSet

Notas

La SigningPrivateKey coincide con la SigningPublicKey del leaseSet, solo si el tipo de clave de firma es DSA. Esto es para la revocación de leaseSet, que no está implementada y es poco probable que se implemente alguna vez. Si el tipo de clave de firma no es DSA, este campo contiene 20 bytes de datos aleatorios. La longitud de este campo es siempre de 20 bytes, nunca es igual a la longitud de una clave privada de firma que no sea DSA.

La PrivateKey coincide con la PublicKey del LeaseSet. La PrivateKey es necesaria para descifrar mensajes enrutados con garlic encryption.

La revocación no está implementada. La conexión a múltiples routers no está implementada en ninguna biblioteca de cliente.

CreateLeaseSet2Message

Descripción

Este mensaje se envía en respuesta a un RequestLeaseSetMessage o RequestVariableLeaseSetMessage y contiene todas las estructuras Lease que deberían publicarse en la Network Database de I2NP.

Enviado del Cliente al Router. Desde la versión 0.9.39. Autenticación por cliente para EncryptedLeaseSet compatible desde la 0.9.41. MetaLeaseSet aún no es compatible a través de I2CP. Ver propuesta 123 para más información.

Contenidos

1. ID de Sesión
2. Un byte tipo de leaseSet a seguir.

• Tipo 1 es un LeaseSet (obsoleto) > - Tipo 3 es un LeaseSet2 > - Tipo 5 es un EncryptedLeaseSet > - Tipo 7 es un MetaLeaseSet

3. LeaseSet o LeaseSet2 o EncryptedLeaseSet o MetaLeaseSet
4. Un byte con el número de claves privadas a continuación.
5. Lista de PrivateKey . Una para cada clave pública en el lease set, en el mismo orden. (No presente para Meta LS2)

• Tipo de cifrado (2 bytes Integer ) > - Longitud de clave de cifrado (2 bytes Integer ) > - PrivateKey de cifrado (número de bytes > especificado)

Notas

Las PrivateKeys coinciden con cada una de las PublicKey del LeaseSet. Las PrivateKeys son necesarias para descifrar los mensajes enrutados con garlic encryption.

Ver la propuesta 123 para más información sobre LeaseSets cifrados.

El contenido y formato para MetaLeaseSet son preliminares y están sujetos a cambios. No hay un protocolo especificado para la administración de múltiples routers. Consulta la propuesta 123 para más información.

La clave privada de firma, previamente definida para revocación y sin usar, no está presente en LS2.

La versión preliminar con tipo de mensaje 40 estaba en 0.9.38 pero el formato fue cambiado. El tipo 40 está abandonado y no es compatible. El tipo 41 no es válido hasta 0.9.39.

CreateSessionMessage

Descripción

Este mensaje es enviado desde un cliente para iniciar una sesión, donde una sesión se define como la conexión de un solo Destination a la red, a la cual todos los mensajes para ese Destination serán entregados y desde la cual todos los mensajes que ese Destination envía a cualquier otro Destination serán enviados.

Enviado del Cliente al Router. El router responde con un SessionStatusMessage .

Contenidos

1. Configuración de Sesión

Notas

• Este es el segundo mensaje enviado por el cliente. Previamente el cliente envió un GetDateMessage y recibió una respuesta SetDateMessage .
• Si la Fecha en la Configuración de Sesión está demasiado alejada (más de +/- 30 segundos) de la hora actual del router, la sesión será rechazada.
• Si ya existe una sesión en el router para este Destination, la sesión será rechazada.
• El Mapping en la Configuración de Sesión debe estar ordenado por clave para que la firma sea validada correctamente en el router.

DestLookupMessage

Descripción

Enviado del Cliente al Router. El router responde con un DestReplyMessage .

Contenido

1. SHA-256 Hash

Notas

A partir de la versión 0.7.

A partir de la versión 0.8.3, se admiten múltiples búsquedas pendientes, y las búsquedas son compatibles tanto en I2PSimpleSession como en sesiones estándar.

HostLookupMessage es preferido a partir de la versión 0.9.11.

DestReplyMessage

Descripción

Enviado desde el Router al Cliente en respuesta a un DestLookupMessage .

Contenidos

1. Destination en caso de éxito, o Hash en caso de fallo

Notas

A partir de la versión 0.7.

A partir del lanzamiento 0.8.3, se devuelve el Hash solicitado si la búsqueda falló, para que el cliente pueda tener múltiples búsquedas pendientes y correlacionar las respuestas con las búsquedas. Para correlacionar una respuesta de Destination con una solicitud, toma el Hash del Destination. Antes del lanzamiento 0.8.3, la respuesta estaba vacía en caso de fallo.

DestroySessionMessage

Descripción

Este mensaje es enviado desde un cliente para destruir una sesión.

Enviado desde Cliente a Router. El router debería responder con un SessionStatusMessage (Destroyed). Sin embargo, consulta las notas importantes a continuación.

Contenidos

1. ID de Sesión

Notas

En este punto, el router debería liberar todos los recursos relacionados con la sesión.

Hasta la API 0.9.66, el router I2P de Java y las bibliotecas cliente se desvían sustancialmente de esta especificación. El router nunca envía una respuesta SessionStatus(Destroyed). Si no quedan sesiones, envía un DisconnectMessage . Si hay subsesiones o la sesión primaria permanece, no responde.

La biblioteca cliente de Java responde a un mensaje SessionStatus destruyendo todas las sesiones y reconectándose.

Destruir subsesiones individuales en una conexión con múltiples sesiones puede no estar completamente probado o funcionando en varias implementaciones de router y cliente. Úselo con precaución.

Las implementaciones deberían tratar una destrucción para una sesión primaria como una destrucción para todas las subsesiones, pero permitir una destrucción para una sola subsesión y mantener la conexión abierta, pero Java I2P no hace eso actualmente. Si el comportamiento de Java I2P cambia en versiones posteriores, se documentará aquí.

DisconnectMessage

Descripción

Informa a la otra parte que hay problemas y que la conexión actual está a punto de ser destruida. Esto termina todas las sesiones en esa conexión. El socket se cerrará en breve. Enviado ya sea del router al cliente o del cliente al router.

Contenidos

1. Razón String

Notas

Solo implementado en la dirección del router al cliente, al menos en Java I2P.

GetBandwidthLimitsMessage

Descripción

Solicitar que el router indique cuáles son sus límites de ancho de banda actuales.

Enviado del Cliente al Router. El router responde con un BandwidthLimitsMessage .

Contenidos

Ninguno

Notas

A partir de la versión 0.7.2.

A partir de la versión 0.8.3, compatible tanto en I2PSimpleSession como en sesiones estándar.

GetDateMessage

Descripción

Enviado del Cliente al Router. El router responde con un SetDateMessage .

Contenidos

1. Versión de la API I2CP String
2. Autenticación Mapping (opcional, a partir de la versión 0.9.11)

Notas

• Generalmente el primer mensaje enviado por el cliente después de enviar el byte de versión del protocolo.
• La cadena de versión se incluye a partir de la versión 0.8.7. Esto solo es útil si el cliente y el router no están en la misma JVM. Si no está presente, el cliente es versión 0.8.6 o anterior.
• A partir de la versión 0.9.11, la autenticación Mapping puede incluirse, con las claves i2cp.username e i2cp.password. El Mapping no necesita estar ordenado ya que este mensaje no está firmado. Antes y hasta la versión 0.9.10 inclusive, la autenticación se incluye en el Session Config Mapping, y no se aplica autenticación para GetDateMessage , GetBandwidthLimitsMessage , o DestLookupMessage . Cuando está habilitada, la autenticación vía GetDateMessage es requerida antes que cualquier otro mensaje a partir de la versión 0.9.16. Esto solo es útil fuera del contexto del router. Este es un cambio incompatible, pero solo afectará sesiones fuera del contexto del router con autenticación, lo cual debería ser raro.

HostLookupMessage

Descripción

Enviado del Cliente al Router. El router responde con un HostReplyMessage .

Esto reemplaza el DestLookupMessage y añade un ID de solicitud, un tiempo de espera y soporte para búsqueda de nombres de host. Como también soporta búsquedas Hash, puede utilizarse para todas las búsquedas si el router lo admite. Para búsquedas de nombres de host, el router consultará el servicio de nombres de su contexto. Esto solo es útil si el cliente está fuera del contexto del router. Dentro del contexto del router, el cliente debería consultar el servicio de nombres directamente, lo cual es mucho más eficiente.

Contenidos

1. Session ID
2. Integer de 4 bytes ID de solicitud
3. Integer de 4 bytes timeout (ms)
4. Integer de 1 byte tipo de solicitud
5. Hash SHA-256 o nombre de host String o Destination

Tipos de solicitud:

Notas

• A partir de la versión 0.9.11. Usar DestLookupMessage para routers más antiguos.
• El ID de sesión y el ID de solicitud se devolverán en el HostReplyMessage . Usar 0xFFFF para el ID de sesión si no hay sesión.
• El timeout es útil para búsquedas de Hash. Mínimo recomendado 10,000 (10 seg.). En el futuro también puede ser útil para búsquedas de servicio de nombres remotos. El valor puede no ser respetado para búsquedas de nombres de host locales, que deberían ser rápidas.
• Se admite la búsqueda de nombres de host en Base 32 pero es preferible convertirlo a un Hash primero.

HostReplyMessage

Descripción

Enviado desde el Router al Cliente como respuesta a un HostLookupMessage .

Contenidos

1. Session ID
2. 4 bytes Integer ID de solicitud
3. 1 byte Integer código de resultado

• 0: Éxito > - 1: Fallo > - 2: Contraseña de búsqueda requerida (a partir de 0.9.43) > - 3: Clave privada requerida (a partir de 0.9.43) > - 4: Contraseña de búsqueda y clave privada requeridas (a partir de 0.9.43) > - 5: Fallo de descifrado del leaseSet (a partir de 0.9.43) > - 6: Fallo de búsqueda del leaseSet (a partir de 0.9.66) > - 7: Tipo de búsqueda no compatible (a partir de 0.9.66)

4. Destination , solo presente si el código de resultado es cero, excepto que también puede ser devuelto para los tipos de búsqueda 2-4. Ver abajo.
5. Mapping , solo presente si el código de resultado es cero, solo devuelto para los tipos de búsqueda 2-4. A partir de 0.9.66. Ver abajo.

Respuestas para tipos de búsqueda 2-4

La Propuesta 167 define tipos de búsqueda adicionales que devuelven todas las opciones del leaseSet, si están presentes. Para los tipos de búsqueda 2-4, el router debe obtener el leaseSet, incluso si la clave de búsqueda está en la libreta de direcciones.

Si es exitoso, el HostReply contendrá las opciones Mapping del leaseset, y las incluye como elemento 5 después del destino. Si no hay opciones en el Mapping, o el leaseset era versión 1, aún se incluirá como un Mapping vacío (dos bytes: 0 0). Se incluirán todas las opciones del leaseset, no solo las opciones de registro de servicio. Por ejemplo, pueden estar presentes opciones para parámetros definidos en el futuro. El Mapping devuelto puede o no estar ordenado, dependiente de la implementación.

En caso de fallo en la búsqueda de leaseSet, la respuesta contendrá un nuevo código de error 6 (Fallo en la búsqueda de leaseSet) y no incluirá un mapeo. Cuando se devuelve el código de error 6, el campo Destination puede estar presente o no. Estará presente si una búsqueda de nombre de host en la libreta de direcciones fue exitosa, o si una búsqueda anterior fue exitosa y el resultado fue almacenado en caché, o si el Destination estaba presente en el mensaje de búsqueda (tipo de búsqueda 4).

Si un tipo de búsqueda no es compatible, la respuesta contendrá un nuevo código de error 7 (tipo de búsqueda no compatible).

Notas

• A partir de la versión 0.9.11. Ver notas de HostLookupMessage .
• El ID de sesión y el ID de solicitud son los del HostLookupMessage .
• El código de resultado es 0 para éxito, 1-255 para fallo. 1 indica un fallo genérico. A partir de la versión 0.9.43, se definieron los códigos de fallo adicionales 2-5 para soportar errores extendidos para búsquedas “b33”. Ver propuestas 123 y 149 para información adicional. A partir de la versión 0.9.66, se definieron los códigos de fallo adicionales 6-7 para soportar errores extendidos para búsquedas tipo 2-4. Ver propuesta 167 para información adicional.

MessagePayloadMessage

Descripción

Entregar la carga útil de un mensaje al cliente.

Enviado del Router al Cliente. Si i2cp.fastReceive=true, que no es el valor por defecto, el cliente responde con un ReceiveMessageEndMessage .

Contenidos

1. ID de Sesión
2. ID de Mensaje
3. Carga Útil

Notas

MessageStatusMessage

Descripción

Notifica al cliente sobre el estado de entrega de un mensaje entrante o saliente. Enviado del Router al Cliente. Si este mensaje indica que hay un mensaje entrante disponible, el cliente responde con un ReceiveMessageBeginMessage . Para un mensaje saliente, esta es una respuesta a un SendMessageMessage o SendMessageExpiresMessage .

Contenidos

1. Session ID
2. Message ID generado por el router
3. 1 byte Integer estado
4. 4 byte Integer tamaño
5. 4 byte Integer nonce generado previamente por el cliente

Notas

Hasta la versión 0.9.4, los valores de estado conocidos son 0 para mensaje disponible, 1 para aceptado, 2 para mejor esfuerzo exitoso, 3 para mejor esfuerzo fallido, 4 para garantizado exitoso, 5 para garantizado fallido. El Integer de tamaño especifica el tamaño del mensaje disponible y solo es relevante para status = 0. Aunque garantizado no está implementado (mejor esfuerzo es el único servicio), la implementación actual del router usa los códigos de estado garantizado, no los códigos de mejor esfuerzo.

A partir de la versión del router 0.9.5, se definen códigos de estado adicionales, sin embargo no están necesariamente implementados. Consulta los Javadocs de MessageStatusMessage para más detalles. Para mensajes salientes, los códigos 1, 2, 4 y 6 indican éxito; todos los demás son fallos. Los códigos de fallo devueltos pueden variar y son específicos de la implementación.

Todos los códigos de estado:

ReceiveMessageBeginMessage

OBSOLETO. No compatible con i2pd.

Descripción

Solicita al router que entregue un mensaje del cual fue previamente notificado. Enviado desde el Cliente al Router. El router responde con un MessagePayloadMessage .

Contenidos

1. ID de Sesión
2. ID de Mensaje

Notas

El ReceiveMessageBeginMessage se envía como respuesta a un MessageStatusMessage que indica que hay un nuevo mensaje disponible para recoger. Si el id del mensaje especificado en el ReceiveMessageBeginMessage es inválido o incorrecto, el router puede simplemente no responder, o puede enviar de vuelta un DisconnectMessage .

Esto no se utiliza en el modo “recepción rápida”, que es el predeterminado desde la versión 0.9.4.

ReceiveMessageEndMessage

OBSOLETO. No soportado por i2pd.

Descripción

Informar al router que la entrega de un mensaje se completó exitosamente y que el router puede descartar el mensaje.

Enviado del Cliente al Router.

Contenidos

1. ID de Sesión
2. ID de Mensaje

Notas

El ReceiveMessageEndMessage se envía después de que un MessagePayloadMessage entrega completamente la carga útil de un mensaje.

Esto no se utiliza en el modo “fast receive” (recepción rápida), que es el predeterminado desde la versión 0.9.4.

ReconfigureSessionMessage

Descripción

Enviado desde el Cliente al Router para actualizar la configuración de la sesión. El router responde con un SessionStatusMessage .

Contenidos

1. ID de Sesión
2. Configuración de Sesión

Notas

• A partir de la versión 0.7.1.
• Si la Fecha en la Configuración de Sesión está muy alejada (más de +/- 30 segundos) de la hora actual del router, la sesión será rechazada.
• El Mapping en la Configuración de Sesión debe estar ordenado por clave para que la firma sea validada correctamente en el router.
• Algunas opciones de configuración solo pueden establecerse en el CreateSessionMessage , y los cambios aquí no serán reconocidos por el router. Los cambios a las opciones de tunnel inbound.* y outbound.* siempre son reconocidos.
• En general, el router debe fusionar la configuración actualizada con la configuración actual, por lo que la configuración actualizada solo necesita contener las opciones nuevas o modificadas. Sin embargo, debido a la fusión, las opciones no pueden ser eliminadas de esta manera; deben establecerse explícitamente al valor predeterminado deseado.

ReportAbuseMessage

OBSOLETO, NO UTILIZADO, SIN SOPORTE

Descripción

Informar a la otra parte (cliente o router) que está siendo atacada, potencialmente con referencia a un MessageId particular. Si el router está siendo atacado, el cliente puede decidir migrar a otro router, y si un cliente está siendo atacado, el router puede reconstruir sus routers o incluir en la lista de bloqueo algunos de los peers que le enviaron mensajes transmitiendo el ataque.

Enviado ya sea del router al cliente o del cliente al router.

Contenidos

1. Session ID
2. 1 byte Integer severidad del abuso (0 es mínimamente abusivo, 255 siendo extremadamente abusivo)
3. Razón String
4. Message ID

Notas

Sin usar. No completamente implementado. Tanto el router como el cliente pueden generar un ReportAbuseMessage , pero ninguno tiene un controlador para el mensaje cuando se recibe.

RequestLeaseSetMessage

OBSOLETO. No soportado por i2pd. No enviado por Java I2P a clientes versión 0.9.7 o superior (2013-07). Usar RequestVariableLeaseSetMessage.

Descripción

Solicitar que un cliente autorice la inclusión de un conjunto particular de túneles de entrada. Enviado del Router al Cliente. El cliente responde con un CreateLeaseSetMessage .

El primero de estos mensajes enviados en una sesión es una señal al cliente de que los tunnels están construidos y listos para el tráfico. El router no debe enviar el primero de estos mensajes hasta que al menos un tunnel de entrada Y uno de salida hayan sido construidos. Los clientes deben agotar el tiempo de espera y destruir la sesión si el primero de estos mensajes no se recibe después de cierto tiempo (recomendado: 5 minutos o más).

Contenidos

1. Session ID
2. 1 byte Integer número de tunnels
3. Ese número de pares de:
   1. Hash
   2. TunnelId
4. Date de finalización

Notas

Esto solicita un LeaseSet con todas las entradas Lease configuradas para expirar al mismo tiempo. Para versiones de cliente 0.9.7 o superior, se utiliza RequestVariableLeaseSetMessage .

RequestVariableLeaseSetMessage

Descripción

Solicitar que un cliente autorice la inclusión de un conjunto particular de tunnels entrantes.

Enviado del Router al Cliente. El cliente responde con un CreateLeaseSetMessage o CreateLeaseSet2Message .

El primero de estos mensajes enviados en una sesión es una señal al cliente de que los tunnels están construidos y listos para el tráfico. El router no debe enviar el primero de estos mensajes hasta que al menos un tunnel de entrada Y uno de salida hayan sido construidos. Los clientes deben agotar el tiempo de espera y destruir la sesión si el primero de estos mensajes no se recibe después de cierto tiempo (recomendado: 5 minutos o más).

Contenidos

1. Session ID
2. 1 byte número Integer de túneles
3. Esa cantidad de entradas Lease

Notas

Esto solicita un LeaseSet con un tiempo de expiración individual para cada Lease .

A partir de la versión 0.9.7. Para clientes anteriores a esa versión, usa RequestLeaseSetMessage .

SendMessageMessage

Descripción

Así es como un cliente envía un mensaje (la carga útil) al Destination . El router utilizará una expiración predeterminada.

Enviado del Cliente al Router. El router responde con un MessageStatusMessage .

Contenidos

1. ID de Sesión
2. Destino
3. Carga útil
4. 4 bytes Integer nonce

Notas

Tan pronto como el SendMessageMessage llegue completamente intacto, el router debería devolver un MessageStatusMessage indicando que ha sido aceptado para entrega. Ese mensaje contendrá el mismo nonce enviado aquí. Más adelante, basándose en las garantías de entrega de la configuración de sesión, el router puede enviar adicionalmente otro MessageStatusMessage actualizando el estado.

A partir de la versión 0.8.1, el router no envía ningún MessageStatusMessage si i2cp.messageReliability=none.

Antes de la versión 0.9.4, no se permitía un valor de nonce de 0. A partir de la versión 0.9.4, se permite un valor de nonce de 0, y le dice al router que no debe enviar ningún MessageStatusMessage , es decir, actúa como si i2cp.messageReliability=none solo para este mensaje.

Antes de la versión 0.9.14, una sesión con i2cp.messageReliability=none no podía ser anulada por mensaje individual. A partir de la versión 0.9.14, en una sesión con i2cp.messageReliability=none, el cliente puede solicitar la entrega de un MessageStatusMessage con el éxito o fallo de la entrega estableciendo el nonce a un valor distinto de cero. El router no enviará el MessageStatusMessage “aceptado” pero posteriormente enviará al cliente un MessageStatusMessage con el mismo nonce, y un valor de éxito o fallo.

SendMessageExpiresMessage

Descripción

Enviado del Cliente al Router. Igual que SendMessageMessage , excepto que incluye una expiración y opciones.

Contenidos

1. Session ID
2. Destination
3. Payload
4. 4 bytes Integer nonce
5. 2 bytes de flags (opciones)
6. Date de expiración truncada de 8 bytes a 6 bytes

Notas

A partir de la versión 0.7.1.

En modo “mejor esfuerzo”, tan pronto como el SendMessageExpiresMessage llegue completamente intacto, el router debería devolver un MessageStatusMessage indicando que ha sido aceptado para entrega. Ese mensaje contendrá el mismo nonce enviado aquí. Más adelante, basándose en las garantías de entrega de la configuración de la sesión, el router puede enviar adicionalmente otro MessageStatusMessage actualizando el estado.

A partir de la versión 0.8.1, el router no envía ningún Message Status Message si i2cp.messageReliability=none.

Antes de la versión 0.9.4, no se permitía un valor de nonce de 0. A partir de la versión 0.9.4, se permite un valor de nonce de 0, e indica al router que no debe enviar ningún Message Status Message, es decir, actúa como si i2cp.messageReliability=none solo para este mensaje.

Antes de la versión 0.9.14, una sesión con i2cp.messageReliability=none no podía ser anulada por mensaje individual. A partir de la versión 0.9.14, en una sesión con i2cp.messageReliability=none, el cliente puede solicitar la entrega de un Message Status Message con el éxito o falla de la entrega estableciendo el nonce a un valor distinto de cero. El router no enviará el Message Status Message “accepted” pero posteriormente enviará al cliente un Message Status Message con el mismo nonce, y un valor de éxito o falla.

Campo de Flags

A partir de la versión 0.8.4, los dos bytes superiores del Date se redefinen para contener flags. Los flags deben tener por defecto todos ceros para compatibilidad hacia atrás. El Date no invadirá el campo de flags hasta el año 10889. Los flags pueden ser utilizados por la aplicación para proporcionar pistas al router sobre si un LeaseSet y/o ElGamal/AES Session Tags deben ser entregados con el mensaje. La configuración afectará significativamente la cantidad de overhead del protocolo y la confiabilidad de la entrega de mensajes. Los bits de flag individuales se definen como sigue, a partir de la versión 0.9.2. Las definiciones están sujetas a cambios. Usa la clase SendMessageOptions para construir los flags.

Orden de bits: 15…0

Bits 15-11

Sin usar, debe ser cero

Bits 10-9

Anulación de Confiabilidad de Mensajes (No implementado, a ser eliminado).

: Si es 1, no incluyas un lease set en el garlic con este mensaje. Si

0, the router may bundle a lease set at its discretion.

Bits 7-4

Umbral bajo de etiquetas. Si hay menos etiquetas disponibles que este número,

send more. This is advisory and does not force tags to be delivered. For ElGamal only. Ignored for ECIES-Ratchet.

: Número de etiquetas a enviar si es requerido. Esto es consultivo y no

force tags to be delivered. For ElGamal only. Ignored for
ECIES-Ratchet.

Descripción

Instruir al cliente sobre el estado de su sesión.

Enviado desde el router al cliente, en respuesta a un CreateSessionMessage , ReconfigureSessionMessage , o DestroySessionMessage . En todos los casos, incluyendo en respuesta a CreateSessionMessage , el router debe responder inmediatamente (no esperar a que se construyan los tunnels).

Contenidos

1. ID de Sesión
2. 1 byte Entero estado

Los valores de estado se definen arriba. Si el estado es Created, el ID de sesión es el identificador que se debe usar para el resto de la sesión.

SetDateMessage

Descripción

La fecha y hora actuales. Enviada desde el Router al Cliente como parte del handshake inicial. A partir de la versión 0.9.20, también puede enviarse en cualquier momento después del handshake para notificar al cliente de un cambio de reloj.

Contenidos

1. Fecha
2. Versión de API I2CP String

Notas

Este es generalmente el primer mensaje enviado por el router. La cadena de versión se incluye a partir de la versión 0.8.7. Esto solo es útil si el cliente y el router no están en la misma JVM. Si no está presente, el router es de la versión 0.8.6 o anterior.

No se enviarán mensajes SetDate adicionales a los clientes en la misma JVM.

Referencias

• Date
• Destination
• EncryptedLeaseSet
• Hash
• Resumen de I2CP
• Javadocs de I2CP
• Integer
• Lease
• LeaseSet
• LeaseSet2
• Mapping
• MetaLeaseSet
• Javadocs de MessageStatusMessage
• PrivateKey
• PublicKey
• RouterIdentity
• SAMv3
• Signature
• SigningPrivateKey
• SigningPublicKey
• String
• TunnelId