Resumo

  • O cookie de RFC 2408 era um token antienchimento rápido, dependente das partes e de segredo local. Depois, o par de cookies identificava a SA ISAKMP. Nenhuma dessas funções autenticava por si só a identidade do par.
  • Message ID, cadeia de payloads, autenticação, política, escolha, instalação e tráfego ocupavam etapas separadas. Um recibo confiável precisava preservar o custo e a realidade de cada transição.

Antes de perguntar quem está na porta, um servidor precisa decidir quanto custa responder à batida. RFC 2408 tratou essa ordem como parte da segurança.

Operações de chave pública eram caras em 1998 e continuam assimetricamente mais caras que descartar um pacote. Um atacante podia inventar endereços de origem e induzir o servidor a gastar CPU. O cookie, chamado de anti-clogging token, permitia um teste barato antes do trabalho pesado.

A função de geração ficava com a implementação, mas tinha três obrigações. O valor devia depender das partes específicas. Só a entidade emissora poderia produzir cookies aceitos por ela, graças a segredo local. A função precisava ser rápida, para que a defesa não se tornasse o próprio alvo de exaustão.

RFC 2408 sugeriu hash de endereços, portas, segredo aleatório e tempo. Cada estabelecimento de SA exigia valor único para reduzir replay. O resultado de oito octetos seguia no cabeçalho como Initiator Cookie ou Responder Cookie.

O teste demonstrava algo útil: o token correspondia ao método e ao segredo do emissor, dentro de uma época. Não demonstrava que o remetente era uma empresa, pessoa, host autorizado ou dono de certificado. Endereço e porta eram insumos, não credenciais.

O RFC recusou a promessa de proteção absoluta contra negação de serviço. Pacotes falsos ainda podiam criar estado. Protocolos sem uma fase puramente anti-clogging deveriam usar coleta de lixo e gestão agressiva de memória. Uma taxa verde de cookies válidos poderia coexistir com tabela cheia e serviço indisponível.

Depois da primeira defesa, os dois cookies passaram a identificar uma SA ISAKMP. No início, o iniciador enviava seu cookie; o campo do respondedor e Message ID eram zero. A resposta acrescentava o segundo. Concluída a fase 1, o par acompanhava comunicações posteriores.

Esse era um índice de estado. RFC 2408 exigia autenticação forte em outra camada e alertava que, sem ela, a identificação declarada pela entidade não podia ser confiada. O servidor podia reconhecer o cookie que emitiu antes de saber quem devolveu o pacote.

Para operação segura, os recibos precisam separar custo e identidade. Primeiro: quanto estado e CPU foram gastos, qual token foi emitido, quando expirou e por que foi aceito. Segundo: qual método autenticou o par, qual credencial foi verificada e qual identidade foi vinculada.

Message ID tratava de concorrência. Na fase 1, era zero. Na fase 2, o iniciador gerava um valor para identificar o estado de uma negociação. Duas negociações sob o mesmo par de cookies poderiam avançar sem misturar respostas.

O par de cookies apontava para o contexto pai. Message ID apontava para o trabalho filho. SPI em Proposal apontava para a SA de protocolo proposta. O SPI depois presente em ESP ou AH apontava para estado efetivamente usado por pacotes. Um único “ID do túnel” não preserva essas diferenças.

O cabeçalho fixo também dizia ao parser o que fazer. Exchange Type escolhia a gramática. Next Payload indicava a primeira carga e cada cabeçalho genérico indicava a próxima. Version, Flags e Length impunham seus próprios testes.

O receptor verificava cookies, Next Payload, versão, tipo de troca, flags e Message ID antes de continuar pela cadeia. Passar em um teste não passava nos demais. Uma cadeia legível podia conter assinatura inválida; uma assinatura válida podia carregar proposta não autorizada; uma proposta aceita podia falhar na instalação.

Quando algo falhava, o pacote era descartado. Log e notificação muitas vezes eram opcionais e dependiam da política local. O padrão podia nomear INVALID-COOKIE ou INVALID-MESSAGE-ID, mas não obrigava todos os operadores a guardar a mesma trilha.

Isso muda a leitura de métricas. Contar notificações não conta todos os erros se alguns nós não notificam. Contar logs não mede impacto se a retenção difere. Medir CPU sem estado de memória ignora o segundo custo do ataque. A defesa precisa de denominadores compatíveis.

ISAKMP era separado do mecanismo concreto de troca de chaves. O quadro definia como estabelecer, negociar, modificar e remover SAs, transportando material de chave e autenticação sem escolher uma técnica única. A separação era uma força de interoperabilidade e uma advertência contra herdar garantias.

A fase 1 criava a SA ISAKMP que protegia atividades posteriores. A fase 2 criava SAs de outros protocolos. Várias fases 2 amortizavam o custo inicial. O sujeito autenticado também podia mudar: servidores ou hosts primeiro, usuários ou programas depois.

Portanto, o custo de autenticar o pai não autorizava automaticamente todos os filhos. Era necessário registrar sujeito, credencial, fase, política e Message ID. Caso contrário, o benefício econômico da reutilização virava uma expansão invisível de autoridade.

Na negociação, o iniciador podia oferecer uma única proposta ou várias em ordem. Com várias, o respondedor escolhia segundo sua política. A estrutura preservava agência local. A escolha não provava que o kernel instalou a SA nem que o fluxo desejado atingiu seus seletores.

Commit e CONNECTED tentavam sincronizar a fronteira. Quem não ativou Commit esperava um Informational Exchange protegido, correlacionado pelo Message ID original. Só então o tráfego cifrado deveria avançar.

Mesmo assim, a mensagem final podia sumir. RFC 2408 deixou alternativas: validar tráfego protegido posterior ou retransmitir a última mensagem. Implementações podiam mantê-la até obter certeza. O protocolo reduziu o risco sem inventar um canal infalível.

Delete mostrou outra assimetria. A carga dizia que o emissor já removeu a SA de sua própria base. Não era pedido para o receptor apagar. Não exigia confirmação. O receptor deveria limpar estado local, mas a continuação dependia de política.

Logo, um Delete recebido não prova limpeza remota. É preciso verificar proteção, decisão, mutação, SPI, seletores, pacotes posteriores e eventual reestabelecimento. Automatizar a partir da palavra “delete” sem esse recibo repete a mesma confusão do cookie: um campo limitado assume autoridade excessiva.

As camadas de realidade de Lu Heng se alinham ao custo. O cookie é evidência de um teste barato. Message ID é evidência de correlação. A cadeia é evidência de sintaxe. A credencial é evidência de vínculo. A política é permissão. A SA instalada é estado executável. O pacote e o serviço são resultado.

O problema de agência define quem paga cada falha. A equipe de protocolo pode provar parsing; identidade, credenciais; segurança, política; plataforma, instalação; produto, utilidade. Um indicador único recompensa quem concluiu primeiro e transfere o risco aos demais.

Priorizar running code significa unir as contas. Preserve época e segredo operacional do cookie sem expor o segredo, ocupação e coleta de estado, transcript de autenticação, fingerprint da credencial, versão da política, proposta escolhida, instalação, SPI ativo, seletores, contadores e observação do serviço.

RFC 2408 foi publicado em novembro de 1998. RFC 4306 substituiu 2407/2408/2409 por IKEv2 em 2005. Em 2023, IKEv1 passou a Historic e RFC 9395 fechou os registros relacionados. RFC 7296 tornou-se o Internet Standard de IKEv2. O interesse aqui é histórico, não recomendação de algoritmos antigos.

O cookie poupou CPU e deu ao servidor uma defesa limitada. A arquitetura ficou mais segura porque não chamou essa economia de identidade.

Fontes