Resumo

  • A RFC 2402 calculava o ICV de AH sobre uma visão preparada: campos imutáveis permaneciam, campos mutáveis previsíveis recebiam o valor esperado na chegada e conteúdos mutáveis imprevisíveis eram substituídos por zero.
  • Um ICV válido não provava que todos os bits observados permaneceram iguais. Fragmentação vinha depois de AH e remontagem antes da verificação; antirrepetição podia estar desativada e política ou aplicativo decidiam depois.

O TTL diminuía a cada salto. A soma de verificação IPv4 mudava junto. Autenticar literalmente esses valores faria uma passagem normal parecer adulteração. Ignorá-los por completo apagaria posição e tamanho. A RFC 2402 escolheu manter os octetos na estrutura, mas usar zero em seu lugar na entrada do Integrity Check Value.

Publicado em novembro de 1998, o IP Authentication Header oferecia integridade sem conexão e autenticação da origem, além de suporte a antirrepetição escolhida pelo receptor para cada associação. Não oferecia confidencialidade. Protegia dados superiores e tanto do cabeçalho IP quanto fosse possível, embora chamasse essa cobertura de fragmentária devido aos campos que mudavam em trânsito.

AH carregava Next Header, comprimento, reservados, SPI, Sequence Number e Authentication Data. SPI, destino e protocolo AH selecionavam a associação unidirecional, de onde vinham algoritmo e chave. O número de sequência era sempre enviado e incrementado pelo emissor mesmo quando o receptor não o verificava contra repetição.

O ICV combinava três classes. Campos imutáveis e dados superiores entravam com os valores reais. Campos mutáveis cujo estado final fosse previsível eram preparados como apareceriam ao receptor. Conteúdo mutável imprevisível era preenchido com zero. Authentication Data também era zerado durante o cálculo do valor que depois seria inserido ali.

Zerar não era remover. Manter os octetos preservava alinhamento e mantinha o comprimento no formato autenticado, embora o conteúdo ficasse fora da proteção. A visão preparada tinha o mesmo esqueleto do pacote, não todos os mesmos valores. “Normalização” ajuda a explicar; a RFC falava em imutável, mutável mas previsível e mutável.

No IPv4, Version, IHL, Total Length, Identification, protocolo AH, Source Address e destino ordinário eram cobertos. Destino sob source routing era mutável mas previsível. TOS, Flags, Fragment Offset, TTL e Header Checksum eram zerados. A especificação reconhecia que roteadores alteravam TOS, podiam marcar DF, reduziam TTL e recalculavam a soma.

Portanto, um ICV válido podia coexistir com TTL menor. Ele provava a igualdade da visão preparada sob uma associação, chave e algoritmo, não a imobilidade de toda a imagem transmitida. Os campos excluídos continuavam no pacote, apenas não estavam dentro da alegação de AH sobre seus valores.

O IPv6 aplicava a mesma regra. Class, Flow Label e Hop Limit eram zerados no modelo de 1998. Um destino sob Routing Header era previsível. Opções Hop-by-Hop e Destination indicavam se Option Data podia mudar; dados mutáveis viravam zeros para o ICV, enquanto tipo e comprimento permaneciam cobertos. Cada opção futura precisava declarar seu tratamento.

Padding também separava cálculo e fio. Padding explícito em Authentication Data era transmitido e autenticado. Alguns algoritmos exigiam padding implícito com zeros até uma fronteira de bloco; esses octetos entravam no cálculo, mas não viajavam. A visão autenticada podia conter valores substituídos e bytes ausentes da rede.

A fragmentação definia a unidade de validação. No modo transporte, AH era aplicado ao datagrama completo antes de fragmentar. Roteadores podiam dividi-lo, mas o receptor remontava antes de AH. Algo ainda apresentado como fragmento nessa etapa era descartado e auditado. No modo túnel, um pacote exterior protegido podia transportar um pacote interior já fragmentado, uma camada diferente.

Na entrada, a implementação escolhia a associação, guardava o ICV recebido, zerava Authentication Data e campos imprevisíveis, acrescentava padding implícito e comparava. Com antirrepetição ativa, um candidato podia ser triado antes, mas a janela só avançava após o ICV. Com ela desativada, a mera presença do número não demonstrava decisão contra repetição.

A RFC 2402 chamava o datagrama de válido nesse estágio de AH. A arquitetura RFC 2401 ainda exigia política de entrada antes de entrega ou encaminhamento, e o aplicativo decidia depois. Associação, visão do emissor, ICV, fragmentos, remontagem, visão do receptor, comparação, replay opcional, política e resultado eram recibos separados.

A especificação é histórica. Substituiu a RFC 1826 e foi substituída pelas RFCs 4302 e 4305. HMAC-MD5 e HMAC-SHA-1 não são recomendações atuais. A RFC 4302 preservou a cobertura parcial, revisando associação, números estendidos e requisitos de algoritmo.

Os textos posteriores de Lu Heng sobre código em execução e camadas da realidade servem como lente, não linguagem da RFC. “Autenticado” ganha força somente na visão efetivamente construída e comparada; não pode absorver campos excluídos, controles opcionais e resultados ainda posteriores.

Fontes