Resumo
- A RFC 2406 não cifrava tudo o que circulava. No modo transporte, o cabeçalho IP original permanecia fora de ESP; no modo túnel, o datagrama interno era protegido, mas um novo cabeçalho externo continuava visível. SPI e Sequence Number também viajavam em claro.
- Confidencialidade, autenticação e antirrepetição eram escolhas distintas. O receptor podia ignorar o contador obrigatório, e o preenchimento apenas limitava algumas inferências de tamanho. Carga protegida não comprovava fluxo oculto, replay rejeitado nem entrega ao aplicativo.
Uma captura pode esconder a porta TCP e ainda revelar duas pontas de túnel conversando em intervalos regulares. Pode mostrar pacotes de comprimentos parecidos após cada evento de um sistema. Pode exibir um contador crescente e não dizer se alguém o verificou. A criptografia retira conteúdo de vista; os metadados restantes continuam capazes de descrever comportamento.
A RFC 2406, publicada em novembro de 1998, organizou essa diferença no segundo formato básico de Encapsulating Security Payload. O texto não tratou ESP como sinônimo de “pacote inteiro cifrado”. Listou confidencialidade, autenticação da origem, integridade sem conexão, antirrepetição e confidencialidade limitada de fluxo. A Security Association e a posição do sistema decidiam a combinação.
O primeiro desenho, na RFC 1827 de 1995, era um invólucro. O SPI era o único campo obrigatório que não dependia do transform. Documentos separados definiam algoritmos e outros campos. Três anos depois, a RFC 2406 atribuiu à multiplicação dessas combinações a necessidade de um formato comum mais completo, incluindo Sequence Number, Padding, Next Header, Authentication Data opcional e ordem de processamento.
O formato comum não transformou serviços diferentes em uma única propriedade. A confidencialidade podia existir sem autenticação ESP. A autenticação podia operar com cifra NULL, sem confidencialidade. Pelo menos uma precisava ser escolhida. Antirrepetição só fazia sentido com autenticação e era ativada ou desativada pelo receptor.
No fio, um cabeçalho IPv4 ou IPv6 externo vinha primeiro e anunciava protocolo 50. ESP começava com SPI de 32 bits e Sequence Number de 32 bits. Depois apareciam Payload Data, Padding, Pad Length, Next Header e, quando selecionado, Authentication Data.
No caso comum de algoritmos separados, a cifra cobria Payload Data, preenchimento, seu comprimento e Next Header. Ficavam fora o cabeçalho IP externo, SPI, número de sequência e o ICV final. Um IV explícito podia ocupar o início de Payload Data; a RFC observava que, embora chamado parte do ciphertext, ele em geral não era cifrado em si.
A autenticação cobria outra área. Seu ICV incluía SPI, Sequence Number, Payload Data, Padding, Pad Length e Next Header, mas excluía Authentication Data. Como a cifra vinha primeiro, os campos da carga entravam no cálculo em forma cifrada. O cabeçalho IP externo continuava fora da autenticação ESP.
No modo transporte, ESP ficava entre o cabeçalho IP original e o protocolo superior. Os endereços originais permaneciam visíveis. Em IPv6, cabeçalhos de extensão antes de ESP também ficavam de fora; opções colocadas depois podiam ser protegidas. A ordem dos cabeçalhos definia a fronteira, não apenas a sintaxe.
No modo túnel, o datagrama IP original inteiro entrava na carga protegida, inclusive seus endereços. Mas um novo cabeçalho IP era necessário para levar o resultado entre as pontas do túnel. O observador podia perder os correspondentes finais e continuar vendo gateways, tamanhos, horários e volume. Uma relação ficava escondida atrás de outra.
Por isso a confidencialidade de fluxo era chamada limitada. Ela dependia de modo túnel e funcionava melhor em um gateway onde vários fluxos fossem agregados. Preenchimento extra podia reduzir a precisão da inferência de comprimento, consumindo banda. Não escondia sozinho tempo, quantidade de pacotes ou o par de endereços externos.
O contador mostrava uma fronteira diferente. O emissor tinha de transmiti-lo e incrementá-lo sempre. Ainda assim, o receptor podia desativar antirrepetição por SA. A existência do campo comprovava transmissão de um valor, não execução de uma janela.
Se antirrepetição estivesse ativa, autenticação também precisava estar, pois um contador sem integridade poderia ser adulterado. O receptor podia rejeitar preliminarmente um valor antigo, mas só atualizava a janela depois de validar o ICV. A evidência completa ligava SA correta, contador autenticado e decisão local. O pacote observado não carregava toda essa história.
A sequência de processamento separava ainda a política. Antes de ESP, a implementação decidia, pelas regras da RFC 2401, que o tráfego pertencia a uma SA que exigia esse tratamento. Depois vinham encapsulamento, preenchimento, cifra e autenticação opcional. Fragmentação ocorria após ESP. Na entrada, remontagem vinha antes; um fragmento ainda entregue a ESP deveria ser descartado como evento auditável.
O receptor procurava uma SA unidirecional usando destino, protocolo ESP e SPI. A associação definia chaves, algoritmos e verificações. Sem SA válida, havia descarte. Com autenticação, o ICV deveria ser confirmado antes de liberar material decifrado. A validação de ESP não substituía a política de entrada nem a decisão do aplicativo.
O próprio texto reconhecia que, sem autenticação, uma SA errada ou ciphertext corrompido poderia produzir saída inválida que IPsec não detectaria, deixando a falha para protocolos posteriores. Se decifração e autenticação ocorressem em paralelo, nada poderia seguir adiante antes da conclusão da verificação.
Eventos auditáveis também não significavam registros garantidos. Um sistema que oferecesse auditoria deveria integrar ESP, mas nem todo sistema precisava ter essa capacidade, e a granularidade era local. SA ausente, fragmento indevido, estouro de sequência e ICV inválido podiam ser registrados. Retenção continuava sendo trabalho do operador.
A RFC 4303 substituiu a RFC 2406 em 2005. Manteve a separação entre campos claros, região cifrada, integridade, modos e decisão de replay, acrescentando sequência estendida, algoritmos combinados e preenchimento TFC explícito. A especificação de 1998 pertence à história do desenho, não à recomendação criptográfica atual.
Pelo critério de Lu Heng, o rótulo vale menos que o efeito executado. “ESP ligado” não informa modo, serviços, SA, janela do receptor, metadados externos nem destino do plaintext. A disciplina editorial é narrar essas diferenças sem vender a cifra como invisibilidade total nem tratar uma capacidade da norma como fato observado na rede.
Fontes
- Histórico da RFC 2406 no IETF Datatracker
- Lu Heng — Especificação inicial mínima e decisão local
- Lu Heng — O problema de agência
- Lu Heng — Por que realidade, não defesa, é o produto
- Lu Heng — Primazia do código em execução
- Registro de erratas da RFC 2406
- Ficha da RFC 2406
- RFC 1827 — IP Encapsulating Security Payload
- RFC 2401 — Arquitetura de segurança para IP
- RFC 2405 — ESP DES-CBC com IV explícito
- RFC 2406 — IP Encapsulating Security Payload
- RFC 4303 — IP Encapsulating Security Payload
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
