Resumo

  • A RFC 3948 colocou IKE e ESP encapsulado em UDP no mesmo mapeamento NAT e marcou IKE com quatro octetos zero, pois um SPI ESP válido não podia ser zero.
  • O marcador só indicava qual mecanismo deveria olhar o pacote em seguida; busca de SA, antirrepetição, criptografia, política do endereço interno e entrega à aplicação continuavam separados.

A vantagem de manter um só caminho

O problema prático não era apenas proteger os dados. Um tradutor de endereços costumava reconhecer fluxos pelos campos de transporte, enquanto ESP nativo não oferecia a forma TCP ou UDP que esse equipamento esperava. Colocar ESP dentro de UDP criava uma forma atravessável, mas IKE, responsável por negociar o estado de segurança, precisava alcançar o mesmo par pelo mesmo ambiente traduzido.

A RFC 3948 adotou o compartilhamento deliberadamente. Um mapeamento NAT único escalava melhor, o próprio tráfego reduzia a necessidade de keepalives IKE separados, o firewall precisava de uma só abertura e a implementação mantinha menos caminhos externos. A RFC 3947 fornecia a negociação e a mudança do tráfego IKE de travessia NAT para a porta 4500.

O compartilhamento não unificou os significados. Depois do cabeçalho UDP, o receptor ainda precisava decidir se entregaria o conteúdo ao controle IKE ou ao processamento ESP. A porta já não resolvia essa pergunta.

Um valor proibido virou sinalização

O primeiro campo de ESP é o Security Parameters Index, SPI, com 32 bits. Ele ajuda o receptor a localizar a Security Association adequada. A RFC 2406 reserva o valor zero para uso local e impede seu emprego como SPI ESP normal no fio. A RFC 3948 exige explicitamente que o SPI encapsulado não seja zero.

Para uma mensagem IKE na UDP 4500, quatro octetos zero aparecem entre UDP e o cabeçalho IKE. São o Non-ESP Marker. Eles ocupam a posição em que estaria o SPI caso o pacote fosse ESP. Assim, zero leva ao caminho IKE; um primeiro valor diferente de zero pode seguir para ESP.

Esse “pode” preserva a fronteira. Um valor não zero não prova que o SA correspondente exista. O receptor ainda verifica sequência, janela antirrepetição, proteção criptográfica, seletores e política. Um SPI desconhecido ou uma falha de integridade encerra o pacote, mesmo quando a primeira classificação foi perfeita.

Os quatro zeros também não autenticam IKE. Não são segredo, assinatura, MAC, identidade do par nem autorização de troca. Eles apenas selecionam o analisador candidato. Formato, estado e autenticação são verificados depois, dentro de IKE.

O byte que conversava com o NAT

Há ainda um terceiro formato no mesmo mapeamento: um payload de exatamente um octeto 0xFF. Seu nome é NAT keepalive. O receptor deve ignorá-lo, pois a finalidade é apenas impedir que o tradutor apague o mapeamento durante um período ocioso.

A RFC 3948 é categórica: receber esse keepalive não pode servir para detectar se a conexão está viva. O NAT pode renovar seu temporizador sem que haja um IKE SA funcional, um ESP SA instalado, dados decifrados ou uma aplicação operante. A memória do intermediário e a saúde ponta a ponta são estados de donos diferentes.

Os padrões históricos de vinte segundos sem outro envio antes de um keepalive necessário e de até cinco minutos após a existência de um SA eram configuráveis. Não devem ser apresentados como comportamento universal atual. Eles mostram, porém, a separação dos relógios: o NAT expira mapeamento; o endpoint agenda o pulso; IKE e ESP expiram associações; a aplicação decide o que significa disponibilidade.

Passar pela porta não autoriza o endereço de dentro

UDP não substituiu ESP. O emissor fazia o processamento ESP normal e adicionava UDP; o receptor removia UDP e executava a decapsulação ESP normal. Só então enfrentava as consequências da tradução.

No modo túnel, uma política local podia verificar se a origem interna pertencia ao espaço permitido, comparar com o endereço atribuído ao par ou aplicar nova tradução. No modo transporte, a mudança dos endereços podia invalidar checksums TCP ou UDP; a RFC descrevia ajustes limitados, inclusive com informação de endereço original negociada por IKE. O marcador não escolhia nenhuma dessas políticas.

As colisões descritas na seção de segurança tornam isso concreto. Dois clientes atrás de NATs diferentes podiam usar o mesmo endereço privado, deixando um gateway com vários SAs aparentemente voltados ao mesmo destino interno. Clientes atrás de um único endereço público também podiam negociar descrições de tráfego sobrepostas, impossibilitando a escolha por um filtro simples. Era preciso atribuir endereços locais únicos, traduzir, rejeitar a colisão ou resolver explicitamente.

A RFC 3715 havia reunido os requisitos de compatibilidade IPsec–NAT. A RFC 3948 respondeu com um formato operacional, não com a ficção de que o endereço externo havia se tornado uma identidade única para todos os sistemas atrás dele.

Uma regra pequena atravessou gerações

O registro oficial informa que a RFC 3948 foi publicada em janeiro de 2005 no Standards Track. A errata aceita corrige uma referência de caso na introdução e não altera o marcador.

A RFC 7296 mantém a convenção no IKEv2: IKE sobre UDP 4500 começa com quatro zeros, enquanto ESP começa diretamente pelo SPI, que não pode ser zero. O iniciador também pode escolher 4500 desde o começo sem já ter provado a existência de NAT. Logo, a porta observada não é recibo de tradução.

A lição histórica é uma arquitetura de recibos. A porta coordena chegada. O primeiro campo escolhe um caminho de análise. IKE ou ESP produz seu próprio veredito. A política admite ou rejeita o tráfego interno. A aplicação demonstra o efeito. Os quatro zeros foram duráveis porque não tentaram governar o que vinha depois.

Fontes