Resumo

  • A RFC 2407 organizou um vocabulário comum para DOI, Situation, identidades, protocolos, transforms, atributos e mensagens. O vocabulário tornava a negociação legível; a política do host e o estado executado continuavam locais.
  • Prazo efetivo, antirrepetição, aceitação de identidade, instalação da SA e tratamento do tráfego eram decisões distintas. Uma auditoria confiável precisava preservar cada resultado, não apenas a proposta inicial.

Uma proposta pode pedir oito horas. O respondedor pode escolher menos. Um emissor pode numerar pacotes. O respondedor pode não manter uma janela antirrepetição. A RFC 2407 ofereceu mensagens específicas justamente porque o valor pedido e o valor executado não eram a mesma coisa.

Publicada em novembro de 1998, a RFC instanciou o ISAKMP para IPsec. O framework geral definia exchanges e payloads; o Domain of Interpretation definia os nomes e a leitura dos campos específicos. O DOI IPsec recebeu o número 1.

Isso permitiu que produtos independentes reconhecessem protocol IDs, transforms de AH, ESP e IPComp, atributos de SA, tipos de identidade, domínios de rótulo e notificações. Faixas privadas continuavam disponíveis para sistemas que cooperavam fora do registro público.

O registro resolveu ambiguidade numérica, não autorização. Um identificador de ESP não dizia sozinho quais atributos de autenticação, chave, grupo, modo e prazo o acompanhavam. A própria RFC marcou certas combinações como indefinidas. O nome do transform precisava da lista de atributos para formar uma proposta válida.

A sintaxe comportava várias suites de Phase II na mesma negociação. Quais protocolos podiam ser combinados era decisão da política do host. O DOI tornava as alternativas comparáveis; não determinava qual risco a organização aceitaria.

Essa reserva aparecia de modo explícito: o DOI IPsec não impunha política específica, e questões de host policy ficavam fora do escopo. A implementação podia usar uma lista simples de endereços, máscaras e flags ou regras mais flexíveis com nomes, direção e firewall intermediário.

A Situation trazia SIT_IDENTITY_ONLY, SIT_SECRECY e SIT_INTEGRITY. A identidade era obrigatória e a falta total de Identification Payload exigia abortar. Rótulos de segredo ou integridade acrescentavam domínio, nível e categorias. O número do domínio apenas indicava o namespace onde os valores eram interpretados.

O processo de registro desse domínio não exigia documentação pública. Era uma escolha coerente para unicidade, mas revelava o limite: o número não comprovava que o receptor conhecia a política, concordava com ela ou a aplicava ao tráfego.

Os tipos de identidade incluíam endereços, sub-redes, intervalos, FQDN, user FQDN, nomes ASN.1 e Key ID. O respondedor podia usar a identidade do iniciador na política local. Quando certificados autenticavam a exchange, a identidade usada na decisão deveria constar do certificado. Era a ligação entre claim e credential.

ID_KEY_ID podia ser um fluxo opaco e específico de fornecedor para escolher uma chave pré-compartilhada. O tipo era interoperável; a semântica dos bytes podia continuar privada. Ver “ID presente” não bastava para dizer “principal universalmente identificado”.

Depois vinha a seleção. Uma negociação concluída comprovava que os pares chegaram a uma representação comum. Ainda faltavam a instalação no kernel, os selectors, o estado de sequência, a vida útil em execução e os pacotes reais. A aplicação continuava livre para rejeitar o resultado.

RESPONDER-LIFETIME fechava parte dessa lacuna ao comunicar a duração escolhida pelo respondedor. Uma operação séria deveria guardar o valor proposto, o escolhido, o instante inicial e a renovação. Sem os quatro, “SA válida” vira um estado sem relógio confiável.

REPLAY-STATUS podia confirmar se o respondedor decidiu ativar ou desativar replay detection. O contador obrigatório de ESP era evidência do envio de um número, não do uso de uma janela no receptor. A notificação preservava a agência de quem realmente executava a decisão.

INITIAL-CONTACT continha outro tipo de agência. Um lado dizia que aquela era sua primeira SA com o sistema remoto. O receptor podia supor reboot e apagar SAs antigas. Uma fala autenticada não era um sensor de reboot. A remoção precisava de regra, inventário, responsável e rollback próprios.

A proteção do aviso também variava. Status messages não podiam ir em Aggressive Mode porque faltava vínculo suficiente. Main Mode podia oferecer proteção parcial; Quick Mode incluía todo o payload no hash. O código não carregava sozinho a força probatória.

Pela lente de Lu Heng, a especificação mínima coordenava o vocabulário e deixava a decisão futura a quem arcava com a consequência. A agency problem surgia quando o daemon negociador parecia responder pelo certificado, pela política, pelo kernel e pelo aplicativo. Não respondia.

As camadas de realidade ajudam a desenhar o painel correto: registro, mensagem, autenticação, regra, seleção, instalação, pacote e resultado. Running-code primacy manda observar as últimas camadas antes de afirmar que as primeiras produziram o efeito.

Em 2005, a RFC 4306 reuniu e substituiu as RFCs 2407, 2408 e 2409 em IKEv2. Em 2023, o IESG moveu o conjunto IKEv1 para Historic, citando a substituição ampla e problemas do protocolo antigo. A RFC 7296 representa o padrão IKEv2 posterior.

O legado útil da RFC 2407 não é seu conjunto de algoritmos. É o cuidado de não chamar pedido de escolha nem nome de execução. O respondedor escolheu prazo e replay. O kernel e o tráfego ainda precisavam provar o resto.

Fontes