Resumo

  • O RFC 2411 distribuiu as regras do IPsec entre arquitetura, ESP, AH, documentos de algoritmo, DOI e gestão de chaves para reduzir duplicação e contradições futuras.
  • A folha de rota era informativa: indicava a fonte competente, mas não provava a revisão implementada, a proposta negociada, a SA instalada nem o resultado do tráfego.

Imagine uma oficina em que cada manual explica a máquina inteira antes de descrever uma única peça. No começo, a redundância parece útil. Depois, um manual conserva o torque antigo, outro altera a sequência de montagem e um terceiro omite o alerta que todos julgavam conhecido. A máquina deixa de ter uma instrução comum.

Esse era o problema editorial que o RFC 2411 enxergava no IPsec de 1998.

A arquitetura de segurança, ESP, AH, os algoritmos de criptografia e autenticação, o domínio de interpretação e a gestão de chaves já formavam um conjunto. Novos algoritmos continuariam chegando depois da publicação dos documentos-base. Reabrir a arquitetura para cada um tornaria o centro instável. Repetir o centro em cada especificação criaria versões concorrentes da mesma regra.

O texto chamou o segundo risco de “draft explosion”. Sua resposta foi atribuir responsabilidade.

A arquitetura guardaria conceitos gerais, requisitos de segurança e os mecanismos comuns. ESP e AH guardariam seus formatos de pacote e o processamento geral. Um documento de criptografia explicaria apenas como um algoritmo específico funciona com ESP. Um documento de autenticação poderia atender ESP e AH quando o comportamento fosse comum. O DOI manteria valores conhecidos e parâmetros de negociação. Os documentos de gestão de chaves cuidariam da criação e administração do material criptográfico.

Não era uma cadeia de comando. O DOI podia nomear uma transformação sem recomendá-la. O roteiro podia apontar para ESP sem substituir o texto de ESP. Cada caixa possuía uma decisão limitada.

O tratamento das chaves mostra a utilidade da divisão. O mecanismo de gestão precisava gerar material suficiente e forte para os algoritmos escolhidos. Mas tamanho de chave, ordem de componentes, bits de paridade e tratamento de chaves fracas pertenciam ao documento do algoritmo. Colocar tudo na gestão de chaves criaria dependência de detalhes que mudariam a cada nova transformação.

A arquitetura dizia como extrair várias chaves de um bloco quando ESP combinava confidencialidade e autenticação. O RFC 2411, porém, não determinava onde o corte ocorreria. O processo de gestão podia dividir o material antes de entregá-lo ao kernel, ou o kernel podia receber o bloco completo e fazer o “slicing and dicing”.

O contrato compartilhado precisava coincidir. A organização interna não.

Essa é uma fronteira de decisão local bem desenhada. Ela não permite resultados incompatíveis; apenas recusa padronizar uma escolha invisível aos pares.

Para parâmetros opcionais, o roteiro recomendava parcimônia. Quando uma escolha fixa fosse tecnicamente razoável, deveria ser fixada. Cada opção negociável aumenta o número de propostas e caminhos de código. Duas implementações podem cumprir listas extensas e ainda assim não compartilhar uma combinação útil.

Se a opção precisasse permanecer, seu documento deveria explicar por quê, definir valores padrão ou intervalos e descrever o impacto no formato e no processamento. Flexibilidade sem contorno não produz interoperabilidade.

O conteúdo recomendado aos autores também aproximava a documentação da verificação: tamanhos mínimos e recomendados de chave, geração aleatória, chaves fracas, renovação, desempenho, formato, padding, interação com outros algoritmos, ataques, armadilhas de implementação, procedimentos de validação e vetores de teste.

O roteiro não executava teste algum. Ele colocava a obrigação de tornar o mecanismo testável no documento que conhecia o mecanismo.

Daí vem uma distinção decisiva. Uma caixa no RFC 2411 prova apenas que uma responsabilidade foi mapeada. Um número da IANA prova que existe um nome comum. Uma declaração de produto prova que alguém fez uma alegação. Uma negociação mostra uma escolha entre pares. Nenhuma dessas coisas, sozinha, prova que os dois lados instalaram SAs corretas ou que um pacote chegou ao aplicativo.

O recibo do mapa, o recibo da regra-fonte, o recibo da implementação, o recibo da negociação, o recibo da instalação e o recibo do resultado não são intercambiáveis.

O próprio RFC 2411 limitava sua força. Era Informational e dizia não especificar um padrão da Internet. Nas considerações de segurança, remetia o leitor à arquitetura, a ESP, AH e aos documentos de algoritmo. Até o alerta de que muitos métodos de criptografia não são seguros sem autenticação era uma orientação de leitura, não uma certificação de implantação.

Em 2011, o RFC 6071 tornou o primeiro roteiro obsoleto. O universo de IPsec e IKE havia se espalhado pelo grupo original, por grupos derivados e por protocolos que usavam IPsec. O sucessor se definiu como uma fotografia. Declarou a data de seus níveis de requisitos, avisou que RFCs posteriores poderiam alterá-los e afirmou que, em caso de conflito, a outra RFC prevaleceria.

O resumo conservou valor porque reconheceu que não era a fonte final.

O RFC 6071 também distinguiu sucessão documental de realidade operacional. O IPsec novo havia substituído o antigo, mas o antigo continuava comum nas implementações. IKEv2 havia substituído IKEv1, mas IKEv1 ainda rodava. Tornar uma especificação obsoleta muda o grafo de documentos; não remove software. Encontrar software antigo em produção descreve um ativo; não restaura sua recomendação.

O próprio diagrama evoluiu. Algoritmos de modo combinado ganharam uma família. Os requisitos obrigatórios foram separados dos formatos para mudar em ritmo próprio. IKEv2 reuniu matérias que IKEv1 distribuía por ISAKMP, Oakley e DOI, inclusive trechos por vezes contraditórios.

Separar demais pode transformar o leitor no integrador de documentos. Unir demais prende componentes com velocidades de mudança distintas. A fronteira correta segue a cadência e a responsabilidade, não uma preferência abstrata por modularidade.

O RFC 8221 mantém esse raciocínio. Requisitos e orientações criptográficas precisam mudar conforme surgem ataques, algoritmos e plataformas. O registro da IANA deve preservar identificadores inequívocos, mas o identificador não promete segurança, disponibilidade nem uso. O RFC 9395 pôde depreciar IKEv1 e algoritmos antigos sem apagar a história que explica por que ainda aparecem em inventários.

O mérito histórico do RFC 2411 foi perceber que a documentação também pode quebrar a interoperabilidade. Ele colocou a regra comum na camada comum, a particular junto do mecanismo e a decisão interna dentro da implementação. Assim, uma transformação nova podia entrar sem reescrever o IPsec inteiro.

Mas nenhum desenho instalou uma SA. A publicação ofereceu uma possibilidade. O código precisou adotá-la; dois pares precisaram encontrar uma escolha; os kernels precisaram receber estado; os pacotes precisaram confirmar o caminho.

O RFC 2411 organizou a oficina. A máquina só começou a existir quando alguém a ligou.

Fontes