Resumo

  • O Internet-Draft de 1º de outubro agora se refere expressamente a uma mensagem IKE protegida recebida em nova conexão TCP, com outro IP de origem e/ou porta. Essa conexão é usada apenas para a IKE SA; a origem das ESP SAs filhas não deve ser alterada por causa dela.
  • Em tráfego que deveria ser bidirecional, a falta de pacotes ESP de entrada passa a ser tratada como indicação de possível problema de conectividade. O ping ESP criptografado continua como alternativa. A falta de tráfego não é, sozinha, prova de falha.

Uma sessão IKE estabelecida pode coexistir com um fluxo de dados que não chega ao outro lado. IKEv2 negocia e conserva as associações de segurança; ESP transporta os pacotes protegidos. O grupo IPSECME propõe permitir que IKE utilize TCP quando trocas grandes o tornem útil, mantendo ESP em IP direto ou encapsulado em UDP quando a rede permitir. Essa opção evita impor a ESP as características do TCP, mas exige observar dois caminhos: intermediários podem filtrar, mapear ou expirar cada transporte de forma distinta.

A alteração substantiva da versão 08 está na precisão da regra NAT. A versão 07 mencionava mensagem IKE protegida vinda de novo endereço ou porta. A redação atual diz que a mensagem chega por uma nova conexão TCP, com IP de origem e/ou porta diferentes. O host fora do NAT deve usar essa conexão somente para a IKE SA e não modificar o IP nem a porta de origem de qualquer ESP SA criada por ela. Já um pacote ESP recebido de nova origem e validado quanto à integridade segue sua própria regra de atualização de estado ESP. Mudar o controle não equivale a autorizar a mudança do destino dos dados.

A arquitetura não foi criada em outubro. Versões anteriores já traziam a notificação SEPARATE_TRANSPORTS: o iniciador pode começar IKE_SA_INIT em UDP 4500 e, depois da confirmação do respondente, conduzir trocas posteriores por TCP. Também pode iniciar por TCP se a primeira troca for grande. No modo separado, ESP circula por IP ou UDP quando possível; se o respondente contatado inicialmente por TCP não confirmar a notificação, IKE e ESP usam TCP conforme RFC 9329. Esses modos explicam a proposta, mas não devem ser confundidos com a novidade específica da versão 08.

A segunda mudança afeta a detecção. Em uma comunicação que normalmente produz pacotes nos dois sentidos, não receber ESP sugere que a conectividade pode estar comprometida. O texto preserva o ping ESP criptografado como forma alternativa de checagem. Um aplicativo ocioso, uma política que só gera tráfego em um sentido ou um ponto de observação inadequado também produzem silêncio. Portanto, não se pode inferir automaticamente bloqueio por firewall, defeito de NAT ou ataque.

O restante do rascunho já obrigava a separar os estados NAT: o TCP de IKE não mantém aberto o mapeamento UDP de ESP, que precisa de keepalives próprios. Quando IKE começa em TCP, concluir a negociação não prova alcance do caminho ESP. Depois de criar a Child SA, o iniciador deve verificar ESP caso não disponha de outra evidência; se não puder confirmar o alcance, precisa excluir a IKE SA e recriá-la em TCP sem propor transporte separado para ESP. O retorno ao caminho comum é consequência de uma verificação específica, não de uma etiqueta genérica de túnel ativo.

No Datatracker, o documento segue como Internet-Draft ativo do grupo, submetido à publicação e com publicação solicitada. Não é uma RFC. O código da notificação ainda aparece como pendente no próprio texto. As fontes consultadas não demonstram implantação, falha de produto ou incidente. A notícia é a delimitação mais clara do evento que afeta IKE e do evento que pode afetar ESP.

Fontes