Resumo

  • A RFC 2401 separou uma base ordenada de políticas de segurança da base de associações ativas: a primeira definia descarte, bypass ou proteção; a segunda guardava parâmetros de conexões lógicas unidirecionais.
  • Regra e associação não eram recibos do pacote. Na saída, AH ou ESP precisava ser aplicado; na entrada, o processamento criptográfico precisava ser seguido pela verificação de que as associações usadas, na ordem usada, atendiam a uma política aplicável.

Descartar, deixar passar, proteger. As três saídas previstas na Security Policy Database pareciam simples, mas obrigavam a arquitetura a declarar onde uma decisão começava e onde sua prova terminava. O pacote protegido não nascia da frase escrita na política. Entre a regra e o resultado havia seleção, estado, transformação e uma nova verificação no sentido oposto.

Publicada em novembro de 1998, a RFC 2401 reuniu a arquitetura de segurança do Protocolo Internet para IPv4 e IPv6. Ela tratava de controle de acesso na camada IP, integridade sem conexão, autenticação da origem, proteção contra repetição, confidencialidade e confidencialidade limitada do fluxo. Os serviços variavam conforme AH, ESP, modo de transporte ou túnel, algoritmos e procedimentos de gerenciamento de chaves. “Usar IPsec” não descrevia uma única garantia.

A SPD precisava governar todo tráfego IP de entrada e saída, inclusive o tráfego que não receberia IPsec. Seus itens eram totalmente ordenados e usavam endereços e campos de camadas superiores como seletores. O item aplicável levava a descarte, bypass ou aplicação de IPsec. No terceiro caso, ainda definia protocolo ou conjunto, modo, algoritmos e requisitos de encadeamento.

A ordem alterava a execução. Uma regra ampla antes de uma regra estreita podia decidir o pacote sem que a exceção fosse considerada. O sentido também fazia parte da alegação: escolher proteção na saída e comprovar conformidade na entrada não eram a mesma operação. Um registro sério precisava conservar versão, interface, direção, seletores e posição da regra efetivamente acionada.

O segundo repositório, a Security Association Database, tinha outra função. Uma Security Association era simplex, válida em um sentido; proteger uma comunicação nos dois sentidos normalmente exigia duas. SPI, endereço IP de destino e identificador de AH ou ESP formavam sua identidade. A entrada podia guardar chaves e algoritmos, sequência e estado antirrepetição, vida útil, modo e informações de MTU do caminho.

Esse estado era indispensável, mas não contava a história de um pacote. Uma associação existente não mostrava se um pacote a selecionou nem se foi processado por ela. Muito menos comprovava recebimento pelo par, autorização do aplicativo ou efeito no serviço. A RFC 2367 já havia dado ao software uma interface PF_KEY para gerenciar chaves e associações; a RFC 2401 situou esse estado em uma cadeia maior.

Na saída, o pacote era comparado à SPD. O descarte encerrava o percurso. O bypass seguia para transmissão comum sem IPsec. A proteção selecionava uma associação adequada ou iniciava a criação da associação ou conjunto exigido. Só então AH ou ESP era aplicado, na ordem determinada, antes do encaminhamento ou da transmissão. Política armazenada e associação ativa continuavam sendo antecedentes da transformação.

Na entrada, endereço de destino, protocolo de segurança e SPI selecionavam uma associação. O processamento de AH ou ESP podia verificar integridade e origem, controlar repetição e decifrar quando esse serviço estivesse presente. O êxito criptográfico ainda não encerrava a autorização.

Depois de processar os cabeçalhos IPsec, a implementação precisava encontrar uma política de entrada compatível com o pacote resultante. Em seguida, verificava se as associações realmente usadas, inclusive sua ordem, satisfaziam essa política. Se uma candidata falhasse, outras entradas aplicáveis eram consideradas. Apenas depois o pacote podia chegar à camada de transporte ou ser encaminhado. Validar sob uma associação e autorizar sob uma política eram recibos distintos.

AH e ESP tampouco sustentavam a expressão genérica “o pacote foi criptografado”. O Authentication Header de 1998 oferecia integridade e autenticação da origem, com proteção antirrepetição opcional, mas sem confidencialidade. ESP podia oferecer confidencialidade e, opcionalmente, autenticação e integridade, com cobertura diferente. O bypass, por definição, não oferecia proteção IPsec.

A própria arquitetura reconhecia dependências externas: qualidade da implementação, segurança do sistema operacional, fontes aleatórias e administração. A RFC 3168 alterou mais tarde o tratamento de ECN. Em 2005, a RFC 4301 substituiu a RFC 2401 e refinou bases de políticas, seletores, fragmentos e autorização de pares. A especificação de 1998 deve ser lida como história, não como orientação criptográfica atual.

Sua contribuição duradoura foi separar intenção, estado instalado e execução. Os textos de Lu Heng sobre primazia do código em funcionamento, decisão local e camadas de realidade fornecem uma lente posterior; não são a terminologia da RFC. A leitura produz onze degraus de evidência: fonte e versão, política carregada, correspondência ordenada, proteção exigida, associação vigente, operação executada, conferência de entrada, entrega à fronteira de rede ou transporte, recebimento pelo par, processamento do aplicativo e resultado do serviço. Nenhum degrau inicial prova o seguinte.

Fontes