El Protocolo de Cliente de I2P (I2CP) presenta una fuerte compartimentalización de los asuntos entre el router I2P y cualquier cliente que quiera comunicarse a través de la red. Habilita mensajería segura y asíncrona mediante el envío y recepción de mensajes sobre un único socket TCP. Con I2CP una aplicación cliente le dice al router quiénes son ellos (sus "destinos"), qué anonimato, fiabilidad, y latencia tienen los intercambios a realizar, y a dónde enviar los mensajes. A la contra el router usa I2CP para decirle al cliente cuándo llega cualquier mensaje, y para pedirle autorización para que se usen algunos túneles.

El protocolo en si mismo está implementado en Java, para proporcionar el SDK del cliente. Este SDK (kit de desarrollo de software) se presenta en el paquete i2p.jar que implementa el lado-del-cliente de I2CP. Los clientes no deberían necesitar nunca acceder al paquete router.jar que contiene al propio router I2P y el lado-del-router de I2CP. También hay una implementación en librería C. Un cliente no-Java también tendría que implementar la librería de streaming para conexiones estilo-TCP.

Las aplicaciones pueden aprovecharse de la base I2CP además de las librerías streaming y datagram mediante el uso de los protocolos Mensajería Anónima Simple (SAM) o BOB, que no requieren clientes para tratar con cualquier clase de criptografía. Además, los clientes pueden acceder a la red por uno de los varios proxys - HTTP, CONNECT, y SOCKS 4/4a/5. A modo de alternativa, los clientes Java pueden acceder a esas librerías en ministreaming.jar y streaming.jar. Así que hay varias opciones para aplicaciones tanto Java como no-Java.

El cifrado extremo-a-extremo del lado-del-cliente (cifrando los datos sobre la conexión I2CP) fue deshabilitado en la versión 0.6 de I2P, dejando en su lugar un cifrado extremo-a-extremo ElGamal/AES que está implementado en el router. La única criptografía que las librerías del cliente todavía deben implementar es la firma de la clave publico/privada DSA (algoritmo de firma digital) para LeaseSets (grupo de túneles para un destino) y Configuraciones de sesión, y la gestión de esas claves.

En una instalación I2P estándar, el puerto 7654 es usado por clientes de Java externos para comunicarse con el router local vía I2CP. Por defecto, el router se liga a la dirección 127.0.0.1. Para ligarse a 0.0.0.0, establezca la opción de la configuración avanzada del router i2cp.tcp.bindAllInterfaces=true y reinicie. Los clientes en la misma JVM (Máquina Virtual Java), pasan los mensajes directamente al router a través de una interfaz JVM interna.

El router I2P también soporta conexiones externas sobre SSL. Aunque SSL no está habilitado por defecto, se recomienda encarecidamente para cualquier tráfico que pueda estar expuesto a la Internet abierta. La autorización usuario/contraseña (si la hay), la clave privada y la clave privada firmante para el destino, son todas transmitidas tal-cual a menos que SSL esté habilitado.

Especificación del protocolo I2CP

Ahora sobre la página de la Especificación I2CP.

Inicialización I2CP

Cuando un cliente conecta con el router, primero envía un único byte de versión de protocolo (0x2A). Entonces envía un mensaje GetDate (obtener fecha) y espera la respuesta del mensaje SetDate (configurar fecha). A continuación, envía un mensaje CreateSession (crear sesión) conteniendo la sesión de configuración. Seguidamente espera un RequestLeaseSet Message (mensaje de solicitud de LeaseSet) desde el router, indicando que los túneles de entrada han sido erigidos y responden con un CreateLeaseSetMessage (mensaje de creación de LeaseSet) conteniendo el LeaseSet firmado. El cliente puede ahora iniciar o recibir conexiones desde otros destinos I2P.

Opciones de I2CP

Opciones del lado-del-router

Las siguientes opciones se pasan tradicionalmente al router a través de un SessionConfig (configuración de la sesión) contenida en un mensaje CreateSession (crear sesión) o un Mensaje ReconfigureSession (reconfiguración de sesión).

Nota: Una gran cantidad de configuraciones, el tamaño o variaciones en las configuraciones pueden causar bastantes problemas en el rendimiento o fiabilidad.

Nota: Desde la versión 0.7.7, los nombre y valores de las opciones deben usar codificación UTF-8. Esto es útil principalmente para los nicknames ('apodos'). Con anterioridad a esta versión, la opciones con caracteres multi-byte estaban corruptas. Como estas opicones están codificadas en un mapeado, los nombres de todas las opciones y valores están limitados a un máximo de 255 bytes (no caracteres).

Opciones de la parte cliente

Las siguientes opciones son interpretadas por la parte cliente, y serán interpretadas si pasan a la I2PSession a través de la llamada I2PClient.createSession(). La librería de streaming también debería pasar estas opciones a través de I2CP. Otras implementaciones pueden tener otros valores por defecto.

Nota: todos los argumentos, incluyendo los números, son cadenas de caracteres. Los valores True/false son cadenas de caracteres y son sensibles a las mayúsculas o minúsculas. Cualquier otro que no sea "true" en minúsculas será interpretado como falso. Todas los nombres de opciones son sensibles a las mayúsculas/minúsculas.

Formato de los datos del payload I2CP y de Multiplexing

El mensaje de fin a fin manejado por I2CP (por ejemplo los dato enviados por el cliente en el SendMessageMessage y recibido por el cliente en un MessagePayloadMessage) están comprimidos con gzip con una cabecera de inicio de 10 bytes con 0x1F 0x8B 0x08 como se especifica en el RFC 1952. A partir de la versión 0.7.1, I2P usa partes ignoradas de la cabecera gzip para incluir el protocolo, el puerto desde, y la información del puerto hacia, con lo que se soporta streamings y datagramas en la misma destinación, y permite peticiones/respuestas usando datagramas para trabajar fiable en presencia de múltiples canales.

La función gzip puede apagarse completamente, aunque si se pone la opción i2cp.gzip=false, se cambia el valor de esfuerzo de gzip a 0, lo que puede ahorrar un poco de CPU. Implementations may select different gzip efforts on a per-socket or per-message basis, depending on an assessment of the compressibility of the contents. Due to the compressibility of destination padding implemented in API 0.9.57 (proposal 161), compression of the streaming SYN packets in each direction, and of repliable datagrams, is recommended even if the payload is not compressible. Implementations may wish to write a trivial gzip/gunzip function for a gzip effort of 0, which will provide large efficiency gains over a gzip library for this case.

Note: I2P protocol numbers 224-254 are reserved for experimental protocols. I2P protocol number 255 is reserved for future expansion.

La integridad de los datos es verificada con el estándar gzip CRC-32 como es especificado por el RFC 1952.

Important Differences from Standard IP

I2CP ports are for I2P sockets and datagrams. They are unrelated to your local sockets or ports. Because I2P did not support ports and protocol numbers prior to release 0.7.1, ports and protocol numbers are somewhat different from that in standard IP, for backward compatibility:

• Port 0 is valid and has special meaning.
• Ports 1-1023 are not special or privileged.
• Servers listen on port 0 by default, which means "all ports".
• Clients send to port 0 by default, which means "any port".
• Clients send from port 0 by default, which means "unspecified".
• Servers may have a service listening on port 0 and other services listening on higher ports. If so, the port 0 service is the default, and will be connected to if the incoming socket or datagram port does not match another service.
• Most I2P destinations only have one service running on them, so you may use the defaults, and ignore I2CP port configuration.
• Protocol 0 is valid and means "any protocol". However, this is not recommended, and probably will not work. Streaming requires that the protocol number is set to 6.
• Streaming sockets are tracked by an internal connection ID. Therefore, there is no requirement that the 5-tuple of dest:port:dest:port:protocol be unique. For example, there may be multiple sockets with the same ports between two destinations. Clients do not need to pick a "free port" for an outbound connection.

Trabajo futuro

• El mecanismo actual de autorización puede modificarse para usar contraseñas 'hashed'.
• Las claves privadas firmantes están incluidas en el mensaje de Crear Lease Set (grupo de túneles al mismo destino), no son requeridas. La revocación no está implementada. Deben ser reemplazadas con datos aleatorios o eliminadas.
• Algunas mejoras pueden ser capaces de usar los mensajes previamente definidos pero no implementados. Para más referencias, aquí está la especificación del protocolo 2CP versión 0.9 (PDF), del 28 de Agosto del 2003. Este documento también hace referencia al Especificación de las estructuras de datos comunes , Common Data Structures Specification, Versión 0.9.

See Also