Resumo

  • RFC 2410 definiu NULL como a função identidade, com chave e vetor de inicialização de zero bit. “Não cifrar” deixou de ser uma omissão ambígua e passou a ser uma transformação negociável em ESP.
  • NULL não oferecia segurança sozinho. Uma transformação de integridade forte ainda era necessária, e o pacote ESP comum não permitia que um intermediário determinasse, por simples observação, se a carga estava cifrada ou apenas autenticada.

Há uma diferença importante entre não fazer algo e especificar, com precisão, que algo não deve ser feito. RFC 2410 ocupou esse espaço. Sua transformação recebia um bloco e devolvia exatamente o mesmo bloco: NULL(b) = I(b) = b.

O texto brincava com origens romanas do algoritmo, mas suas obrigações de interoperabilidade eram concretas. O tamanho da chave extraída por IKE tinha de ser zero. O IV tinha de ter zero bit. A transformação era sem estado e usava bloco nominal de um octeto. Implementações independentes sabiam exatamente como representar a escolha.

Sem uma transformação nomeada, a ausência poderia significar erro, campo omitido, padrão local ou decisão intencional. Com NULL, os pares podiam usar a mesma gramática de propostas e seleções de ESP para dizer: queremos autenticação e integridade, mas não confidencialidade.

O lugar ocupado por NULL não deve ser confundido com o serviço prestado. Ele era listado entre transformações de ciframento porque preenchia esse componente da associação. RFC 2410 afirmava que NULL não fornecia confidencialidade nem qualquer outro serviço de segurança por si só.

A proteção vinha do algoritmo de autenticação associado. Com ele, ESP_NULL podia detectar alteração e sustentar autenticação de origem sem esconder a carga. O documento aproximava esse serviço de AH, mas preservava uma diferença: ESP_NULL não incluía o cabeçalho IP no cálculo como AH fazia com as partes adequadas do cabeçalho.

Por isso, ausência de confidencialidade não era ausência de controle. Também não era prova de controle suficiente. O algoritmo de integridade, a chave, a política e o resultado da verificação continuavam essenciais. Um campo ENCR_NULL isolado só descrevia metade da configuração.

RFC 2406 exigia que uma SA ESP escolhesse pelo menos uma proteção criptográfica forte, de ciframento ou autenticação. RFC 4303 manteve a fronteira: confidencialidade e integridade poderiam ser opcionais separadamente, mas ambas não poderiam ser NULL ao mesmo tempo.

Essa regra impedia que o invólucro ESP fosse usado como símbolo vazio. Um pacote não ganhava proteção porque carregava SPI e número de sequência. A SA precisava apontar para um serviço real, e o receptor precisava executá-lo com sucesso.

No DOI de IPsec para IKEv1, ESP_NULL recebeu o identificador 11. O registro IKEv2 também mantém ENCR_NULL no número 11 para ESP, indicando que ele não é permitido para proteger o próprio IKEv2. O número só tem sentido quando acompanhado do tipo da transformação e do protocolo.

O registro cria vocabulário compartilhado. Não cria fatos de execução. Ele não mostra que uma proposta ocorreu, que foi escolhida, que chegou ao kernel ou que processou um pacote. A confusão entre registro e realidade é especialmente perigosa quando uma ferramenta de conformidade lê uma capacidade como se fosse uma implantação.

O mesmo vale para requisitos de implementação. RFC 8221 manteve ENCR_NULL como obrigatório de implementar para preservar ESP apenas autenticado, inclusive por sua convivência mais prática com NAT do que AH. Obrigatório de implementar não é obrigatório de usar. A política local ainda decide quando a opção é aceitável.

Também não basta chamar todo uso de NULL de rebaixamento. Se a política autorizava integridade sem confidencialidade, a seleção era correta. Se a política exigia sigilo e o negociador aceitou NULL, a evidência pode apontar falha ou ataque de downgrade. É preciso comparar a seleção com a versão de política vigente naquele instante.

Os pares tinham uma vantagem epistemológica: possuíam o estado da SA. Um intermediário via ESP e um SPI, mas não necessariamente tinha o mapa confiável que ligava aquele SPI aos algoritmos escolhidos. O pacote comum não carregava um sinal público determinista da ausência de ciframento.

Essa opacidade era problemática para redes empresariais que queriam inspecionar tráfego apenas autenticado. Uma ferramenta de detecção poderia analisar uma carga ESP_NULL, mas não uma carga realmente cifrada. Classificar errado em uma direção quebrava o parser; na outra, criava um caminho para escapar dos controles.

RFC 5840 introduziu WESP porque o formato ESP, sozinho, não oferecia distinção determinista entre carga cifrada e integridade apenas. A nova camada podia indicar o serviço e tornar a inspeção tecnicamente possível. Ela não alterava automaticamente a política nem provava adoção universal.

RFC 5879 documentou heurísticas para ambientes que não haviam modificado as pontas. O observador testava estruturas plausíveis, tamanhos e relações de protocolo para inferir ESP-NULL. O resultado podia ser útil, mas continuava sendo inferência, não declaração autenticada da SA.

O contexto administrativo era parte do desenho. A inspeção fazia sentido em domínio controlado, onde uma política comum poderia impedir que os hosts simplesmente escolhessem ciframento para contornar a análise. Fora dessa relação, a visibilidade dos bytes não criava obrigação de se tornar visível nem autoridade para ler.

Mesmo um sinal WESP determinista responde só a uma pergunta: há confidencialidade? Ele não define quem pode examinar a carga, para qual finalidade, por quanto tempo ou com qual prestação de contas. Legibilidade e autorização têm proprietários diferentes.

A cadeia do receptor também não termina na classificação. SA de entrada e SA de saída são estados independentes. Negociação não prova instalação. Integridade válida não prova aceitação pela janela antirreplay. Processamento IPsec não prova passagem pelo firewall interno. Chegada ao host não prova commit da aplicação.

Um registro operacional sério separa essas etapas: identidade do par, revisão da política, proposta, seleção, SPI por direção, algoritmos, origem das chaves, confirmação de instalação, sequência, contadores, método do observador, base da inspeção e resultado da aplicação.

O tempo regulatório também exige cuidado. RFC 9395 tornou IKEv1 histórico e fechou seus registros, ao mesmo tempo que depreciou algoritmos antigos. ENCR_NULL não estava nessa lista. O mecanismo de ESP apenas autenticado permaneceu na orientação posterior; o que mudou foi o ecossistema de negociação e manutenção.

Pelas camadas de realidade de Lu Heng, a sequência fica clara. O RFC e o registro definem símbolos. IKE registra um acordo. O kernel executa uma SA. O pacote oferece observação. O intermediário classifica. A política atribui autoridade. A aplicação registra o efeito. Um recibo não deve ser promovido ao papel do seguinte.

A especificação mínima fez sua parte ao padronizar somente os invariantes necessários para que o nada fosse igual em todos os lugares. As decisões futuras ficaram com quem operava: aceitar ou não o serviço, implantar sinalização, permitir inspeção, conservar provas. Publicação não substituiu adoção.

RFC 2410 transformou ausência em uma escolha inequívoca entre pares. A história posterior mostrou que uma escolha inequívoca ainda pode ser invisível para quem observa da posição errada.

Fontes