Visão geral do I2CP

Visão geral

O Protocolo de Cliente I2P (I2CP) expõe uma forte separação de responsabilidades entre o roteador e qualquer cliente que deseje se comunicar pela rede. Ele permite mensagens seguras e assíncronas enviando e recebendo mensagens por meio de um único socket TCP. Com o I2CP, uma aplicação cliente informa ao roteador quem ela é (sua “destinação”), quais compensações de anonimato, confiabilidade e latência devem ser feitas, e para onde as mensagens devem ser enviadas. Por sua vez, o roteador utiliza o I2CP para informar ao cliente quando mensagens chegaram, e para solicitar autorização para que alguns túneis sejam utilizados.

O próprio protocolo é implementado em Java, para fornecer o SDK do cliente. Este SDK é exposto no pacote i2p.jar, que implementa o lado cliente do I2CP. Os clientes nunca deveriam precisar acessar o pacote router.jar, que contém o roteador em si e o lado do roteador do I2CP. Um cliente não Java também teria que implementar a biblioteca de streaming para conexões no estilo TCP.

Aplicativos podem aproveitar o I2CP básico mais as bibliotecas de streaming e datagrama utilizando o protocolo Simple Anonymous Messaging (SAM) , que não exige que os clientes lidem com qualquer tipo de criptografia. Além disso, os clientes podem acessar a rede por meio de diversos proxies – HTTP, CONNECT e SOCKS 4/4a/5. Alternativamente, clientes em Java podem acessar essas bibliotecas nos arquivos ministreaming.jar e streaming.jar. Assim, existem várias opções tanto para aplicações em Java quanto para aplicações não baseadas em Java.

A criptografia ponta a ponta no lado do cliente (criptografar os dados sobre a conexão I2CP) foi desativada na versão 0.6 do I2P, mantendo-se a criptografia ponta a ponta ElGamal/AES que é implementada no roteador. A única criptografia que as bibliotecas cliente ainda precisam implementar é a assinatura de chaves pública/privada DSA para LeaseSets e Configurações de Sessão , além da gestão dessas chaves.

Em uma instalação padrão do I2P, a porta 7654 é usada por clientes Java externos para se comunicar com o roteador local através do I2CP. Por padrão, o roteador vincula-se ao endereço 127.0.0.1. Para vincular-se ao 0.0.0.0, defina a opção avançada de configuração do roteador i2cp.tcp.bindAllInterfaces=true e reinicie. Clientes na mesma JVM que o roteador passam mensagens diretamente para o roteador através de uma interface interna da JVM.

Algumas implementações de roteador e cliente também podem suportar conexões externas por SSL, conforme configurado pela opção i2cp.SSL=true. Embora o SSL não seja o padrão, é fortemente recomendado para qualquer tráfego que possa ser exposto à Internet aberta. O usuário e senha de autorização (se houver), a Chave Privada e a Chave Privada de Assinatura para a Destinação são todos transmitidos em texto claro, a menos que o SSL esteja habilitado. Algumas implementações de roteador e cliente também podem suportar conexões externas por meio de sockets de domínio.

Especificação do Protocolo I2CP

Veja a página de Especificação I2CP para a especificação completa do protocolo.

Inicialização I2CP

Quando um cliente se conecta ao roteador, ele primeiro envia um único byte de versão do protocolo (0x2A). Em seguida, envia uma Mensagem GetDate e aguarda a resposta da Mensagem SetDate . Depois, envia uma Mensagem CreateSession contendo a configuração da sessão. Em seguida, aguarda uma Mensagem RequestLeaseSet do roteador, indicando que os túneis de entrada foram criados, e responde com uma CreateLeaseSetMessage contendo o LeaseSet assinado. O cliente agora pode iniciar ou receber conexões de outras destinações I2P.

Opções I2CP

Opções do lado do roteador

As seguintes opções são tradicionalmente passadas para o roteador por meio de um SessionConfig contido em uma Mensagem CreateSession ou em uma Mensagem ReconfigureSession .

Observação: A partir da versão 0.7.7, os nomes e valores das opções devem usar codificação UTF-8. Isso é principalmente útil para apelidos. Antes dessa versão, opções com caracteres multibyte eram corrompidas. Como as opções são codificadas em um Mapping , todos os nomes e valores de opções são limitados a no máximo 255 bytes (não caracteres).

Opções do lado do cliente

As seguintes opções são interpretadas no lado do cliente e serão interpretadas se passadas para a I2PSession através da chamada I2PClient.createSession(). A biblioteca de streaming também deve repassar essas opções ao I2CP. Outras implementações podem ter padrões diferentes.

Formato dos Dados de Carga I2CP e Multiplexação

As mensagens de ponta a ponta manipuladas pelo I2CP (ou seja, os dados enviados pelo cliente em uma SendMessageMessage e recebidos pelo cliente em uma MessagePayloadMessage ) são compactados com um cabeçalho gzip padrão de 10 bytes que começa com 0x1F 0x8B 0x08 conforme especificado pela RFC 1952 . A partir da versão 0.7.1, o I2P utiliza partes ignoradas do cabeçalho gzip para incluir informações de protocolo, porta de origem e porta de destino, permitindo assim o uso de streaming e datagramas no mesmo destino, e possibilitando que consultas/respostas usando datagramas funcionem de forma confiável na presença de múltiplos canais.

A função gzip não pode ser completamente desativada, no entanto, definir i2cp.gzip=false ajusta o nível de esforço do gzip para 0, o que pode economizar um pouco de CPU. As implementações podem escolher diferentes níveis de esforço do gzip por socket ou por mensagem, dependendo da avaliação da compressibilidade do conteúdo. Devido à compressibilidade do preenchimento do destino implementado na API 0.9.57 (proposta 161), recomenda-se a compressão dos pacotes SYN de streaming em ambas as direções e dos datagramas com resposta, mesmo que a carga útil não seja compressível. As implementações podem desejar escrever uma função trivial de gzip/descompactação para um esforço de gzip igual a 0, o que proporcionará grandes ganhos de eficiência em comparação com uma biblioteca gzip neste caso.

A integridade dos dados é verificada com o CRC-32 padrão gzip conforme especificado em RFC 1952 .

Diferenças Importantes em Relação ao IP Padrão

As portas I2CP são para sockets e datagramas I2P. Elas não têm relação com seus sockets ou portas locais. Como o I2P não suportava portas e números de protocolo antes da versão 0.7.1, as portas e números de protocolo são um pouco diferentes das usadas em IP padrão, por compatibilidade com versões anteriores:

• A porta 0 é válida e possui significado especial.
• As portas 1-1023 não são especiais nem privilegiadas.
• Servidores escutam na porta 0 por padrão, o que significa “todas as portas”.
• Clientes enviam para a porta 0 por padrão, o que significa “qualquer porta”.
• Clientes enviam da porta 0 por padrão, o que significa “não especificado”.
• Servidores podem ter um serviço escutando na porta 0 e outros serviços escutando em portas superiores. Nesse caso, o serviço na porta 0 é o padrão e será usado se a porta do socket ou datagrama de entrada não corresponder a outro serviço.
• A maioria dos destinos I2P executa apenas um serviço, portanto você pode usar os valores padrão e ignorar a configuração de porta I2CP.
• O protocolo 0 é válido e significa “qualquer protocolo”. No entanto, isso não é recomendado e provavelmente não funcionará. O streaming exige que o número do protocolo seja definido como 6.
• Os sockets de streaming são rastreados por um ID interno de conexão. Portanto, não é necessário que a 5-tupla de dest:porta:dest:porta:protocolo seja única. Por exemplo, pode haver vários sockets com as mesmas portas entre dois destinos. Os clientes não precisam escolher uma “porta livre” para uma conexão de saída.

Trabalhos Futuros

• O mecanismo atual de autorização poderia ser modificado para usar senhas com hash.
• A Chave Privada de Assinatura está incluída na mensagem Criar Conjunto de Arrendamento (Create Lease Set), mas não é necessária. A revogação não está implementada. Ela deveria ser substituída por dados aleatórios ou removida.
• Algumas melhorias podem ser capazes de usar mensagens previamente definidas, mas não implementadas.