AH ou ESP? Decida pelo que o pacote precisa proteger

Duas propostas IPsec podem nomear o mesmo algoritmo de integridade baseado em SHA e ainda assim pedir protocolos de proteção diferentes; AH e ESP não são duas grafias de uma mesma configuração de autenticação. Leia primeiro o protocolo, depois os algoritmos, depois o modo, e a maior parte da ambiguidade desaparece. AH autentica o pacote, incluindo os campos do cabeçalho IP que permanecem inalterados no percurso, enquanto ESP autentica e cifra o que encapsula e deixa o cabeçalho externo em paz. Essa diferença decide mais implantações do que qualquer nome de hash.

O que AH cobre e ESP não

AH fornece integridade, autenticação da origem dos dados e o serviço antirrepetição que define, e nenhuma confidencialidade. Sua cobertura inclui os dados da camada superior e os campos do cabeçalho IP que suas regras tratam como imutáveis, exatamente a parte que ESP no modo transporte deixa de fora. Quando um requisito diz que o próprio cabeçalho IP precisa ser autenticado, AH é o protocolo que responde.

Essa cobertura é também a razão de AH ser frágil na prática. Campos mutáveis como o TTL, a soma de verificação do cabeçalho e algumas opções não podem ser autenticados porque os roteadores podem reescrevê-los, então o protocolo os zera antes de calcular a verificação. Por isso, tudo que reescreve endereços quebra o cálculo, e não apenas a política.

O NAT transforma a escolha em restrição

A tradução de endereços reescreve a origem ou o destino no cabeçalho IP que AH acabou de autenticar, então a verificação de integridade falha no outro extremo, e falha como erro de protocolo e não como uma mensagem legível. ESP não autentica o cabeçalho externo, por isso ESP com travessia de NAT funciona e AH atrás de NAT não. Um túnel cujas duas pontas estão atrás de roteadores comuns é justamente onde isso aparece primeiro. Portanto, a primeira pergunta não é qual protocolo é mais forte, mas se há um tradutor entre as pontas.

Se houver, AH fica de fora, e a conversa passa para ESP e suas escolhas de algoritmo. É uma restrição e não uma preferência, por isso fica no início da decisão e não no fim.

O modo multiplica a pergunta

ESP no modo transporte protege a carga útil da camada superior e deixa o cabeçalho IP em paz; no modo túnel encapsula todo o pacote interno, incluindo o cabeçalho IP interno, e o protege. AH tem os mesmos dois modos, então AH ou ESP são na verdade quatro combinações antes de escolher qualquer algoritmo.

Os algoritmos ESP de modo combinado resolvem então a integridade sem um segundo protocolo. AES-GCM e ChaCha20-Poly1305 autenticam e cifram numa única construção, então acrescentar AH por cima não compra nada, mas custa outro cabeçalho e outra negociação. A arquitetura permite AH e ESP juntos, e a pergunta prática é se o seu gateway e a sua versão suportam a combinação e se alguém poderá mantê-la depois.

O substituto honesto para apenas AH

A variante ESP de apenas integridade mantém o algoritmo e abandona a pretensão de cifra em vez de falsificá-la, e passa pelo NAT. Se um desenho herdado usava AH porque precisava de autenticação sem confidencialidade, essa variante é a tradução direta, e não um túnel cifrado com uma nota anexada.

Ver ESP numa proposta também não é prova de cifra. Leia o algoritmo de cifra: uma entrada NULL significa apenas integridade, e uma entrada de modo combinado significa ambas.

Decida em três perguntas

Pergunte se a confidencialidade é necessária, se há um tradutor no caminho e quais campos do cabeçalho precisam ser autenticados. Essas três respostas apontam um protocolo e um modo, e escrevê-las leva menos tempo do que reler os RFC depois.

Depois verifique o que foi aceito e não o que foi proposto. ip xfrm state mostra o protocolo, o modo e os algoritmos da associação instalada, e uma divergência não instala nada, o que é uma falha mais limpa do que um túnel que sobe sem a proteção pretendida.

Mantenha as falhas de autenticação, a cobertura dos seletores e as falhas de roteamento separadas desta escolha. Elas produzem sintomas diferentes, e culpar o protocolo por um problema de seletor é uma forma segura de passar um dia trocando hashes sem motivo.