Resumo

  • A revisão 07 permite manter IKEv2 em TCP e transportar ESP diretamente em IP ou encapsulado em UDP, mas uma Child SA válida não comprova que o caminho de dados está disponível.
  • Mapeamento NAT, resposta ESP protegida, tráfego de aplicação e autorização de fallback precisam de recibos próprios; autenticação correta pode coexistir com indisponibilidade total.

O incidente começa com uma frase enganosa: “a VPN subiu”. Há uma conexão TCP, os pares IKEv2 se autenticaram, o material de chave atravessou a rede e a Child SA foi criada. A frase parece razoável porque descreve fatos reais. Só omite o fato que importa ao usuário: nenhum pacote protegido chegou ao destino útil.

TCP pode ter sido permitido onde ESP nativo é bloqueado. O NAT pode manter a sessão TCP de IKE e não possuir qualquer estado UDP para ESP. O plano de controle concluiu seu trabalho; o plano de dados nem sequer demonstrou que existe uma estrada.

O Internet-Draft Separate Transports for IKE and ESP trata essa lacuna sem retórica. A revisão 07 é trabalho ativo do IPsecME, no fluxo IETF, com intenção Standards Track e estado congelado “WG Consensus: Waiting for Write-Up”. Ainda não é RFC, implantação nem resultado de interoperabilidade.

O problema surge de uma combinação moderna. IKEv2 foi desenhado para UDP. RFC 9329 definiu como encapsular IKE e ESP em TCP quando UDP não passa. Agora, trocas pós-quânticas ampliam chaves e mensagens; TCP ajuda o controle volumoso, mas forçar ESP a usar o mesmo fluxo pode cobrar um preço de desempenho. O draft quer usar cada transporte onde ele faz mais sentido.

Os pares anunciam SEPARATE_TRANSPORTS. Com aceitação de ambos, as trocas IKE continuam em TCP, enquanto ESP tenta IP direto ou UDP 4500 quando há NAT. Sem a confirmação do respondedor, IKE e ESP ficam juntos em TCP sob RFC 9329.

Essa troca prova compatibilidade. Não prova passagem.

Se IKE_SA_INIT começou em UDP, sua ida e volta já demonstra alguma alcançabilidade UDP. Se começou em TCP, não há evidência implícita sobre ESP. Depois de criar a Child SA, o iniciador deve verificar ESP, salvo quando já dispõe de evidência equivalente, como tráfego protegido recebido.

O draft separa também o diagnóstico de segurança. Não confirmar ESP não reduz, por si só, a autenticidade de IKEv2 nem a proteção criptográfica da Child SA. As chaves podem estar certas e o serviço pode continuar indisponível. Tratar isso como falha de autenticação desloca a investigação; tratar a SA como prova de entrega encerra a investigação cedo demais.

NAT não é um detalhe. Equipamentos mantêm estado por transporte. A conexão TCP usada por IKE não mantém o mapeamento UDP de ESP; o caminho ESP precisa de keepalive próprio. Um pacote ESP autenticado vindo de novo endereço ou porta pode atualizar as SAs ESP correlatas sem alterar a extremidade IKE. Uma mensagem IKE protegida pode atualizar o controle sem autorizar inferência sobre ESP.

Uma identidade criptográfica pode operar sobre duas memórias de rede independentes.

Quando IKE começa em TCP, a revisão 07 organiza a prova. Com NAT detectado, testar ESP encapsulado em UDP 4500. Sem NAT, testar ESP direto e, após breve atraso sem resposta, testar também UDP, pois alguns middleboxes recusam tráfego IP que não tenha UDP ou TCP. O primeiro caminho responsivo vence, numa lógica semelhante a Happy Eyeballs.

Encrypted ESP Echo é uma forma possível de obter o recibo. A resposta prova que um pedido e uma resposta protegidos cruzaram aquele caminho sob aquela SA. Não prova todos os tamanhos, seletores, serviços nem o resultado final da aplicação. Um teste representativo de negócio continua necessário.

Se ESP não puder ser confirmado, o iniciador deve apagar a IKE SA atual e restabelecê-la em TCP sem propor separação. O fallback recoloca ESP em TCP conforme RFC 9329. A política local precisa dizer se isso é aceitável ou se a sessão deve ser abortada. Continuidade, latência, vazão e requisitos de auditoria podem levar a respostas diferentes.

MOBIKE invalida o recibo anterior quando muda o endereço. A nova rede traz novos filtros e, possivelmente, outro NAT. A continuidade de IKE em TCP não carrega consigo a validade de ESP. Retomada de sessão também não deve guardar a escolha de transporte: durante a inatividade, o cliente pode ter mudado completamente de ambiente.

Essa arquitetura combina com a disciplina de Heng Lu: especificar o mínimo comum e deixar a decisão futura para quem observa a realidade futura. “SA estabelecida” é um fato simbólico e criptográfico; pacotes protegidos em movimento são outro nível. Running code é a execução observada, não a intenção configurada.

O registro operacional deveria listar separadamente: transporte de IKE, aceitação da capacidade, detecção NAT, candidato ESP, mapeamento e keepalive, primeira resposta protegida, tráfego de aplicação, decisão de fallback e nova validação após mobilidade ou retomada. “VPN ativa” não contém informação suficiente para governar o risco.

Fontes