Resumo

  • O RFC 2385 autenticava cada segmento protegido com um segredo compartilhado e mandava descartar silenciosamente qualquer falha.
  • A economia de espaço eliminou identificadores de algoritmo e chave; um digest correto comprovava um segmento sob a configuração local, não a legitimidade da rota nem a época criptográfica.

Proteger a conexão, não todo o BGP

BGP usava TCP para obter entrega ordenada. Um invasor fora do caminho, porém, podia tentar acertar os dados de uma conexão e injetar um RST. O fechamento do transporte podia levar o roteador a reconstruir a sessão e retirar temporariamente rotas.

A opção Kind 19 levava tipo, comprimento e 16 bytes de MD5. O cálculo abrangia o pseudo-cabeçalho IPv4, o cabeçalho TCP sem opções e com checksum zero, os dados e uma senha previamente conhecida nas duas pontas. Se o valor não coincidisse, o receptor descartava o segmento sem responder.

Essa prova tinha fronteira. Ela não identificava o operador, não autorizava um AS a originar prefixos e não mostrava que um UPDATE passou pela política, entrou na FIB ou entregou tráfego. O digest dizia que os bytes correspondiam a um segredo selecionado localmente.

O acordo ficava fora do fio

O RFC não negociava o uso da opção. A política do site decidia. Um SYN/ACK sem assinatura não provocava downgrade; era ignorado e a conexão não se estabelecia. O par remoto não ganhava poder para desligar a exigência local.

Em compensação, as duas pontas precisavam combinar a mesma senha e o mesmo instante de ativação por outro canal. Não havia KeyID. Uma mudança durante a sessão era permitida se sincronizada, mas retransmissões podiam chegar depois da troca e ser testadas contra o segredo errado. O segmento não indicava a qual época pertencia.

Assim, emissão, presença da opção, escolha de chave, validação, aceitação TCP, continuidade BGP, aceitação de rota, instalação e entrega são recibos separados. A assinatura cobria apenas os primeiros.

O orçamento de 40 bytes

O cabeçalho TCP completo tem no máximo 60 bytes; sobram 40 para opções. A opção MD5 ocupava 18. No exemplo do RFC, MSS, escala de janela, timestamps, MD5 e preenchimento consumiam todo o espaço do SYN.

Já existiam dúvidas sobre MD5, mas o formato implantado não tinha campo de algoritmo. Um byte novo levaria a opção a 19 e provavelmente a 20 por alinhamento. Economizar esse espaço favoreceu adoção imediata. Também impediu que Kind 19 nomeasse uma alternativa.

Uma troca de algoritmo passou a exigir outra opção. A Errata 4432 corrigiu “palavras de 32 bytes” para “32 bits”. O RFC 6691 corrigiu a orientação sobre MSS: o emissor reduz os dados conforme as opções reais. A limitação de 40 bytes e o seletor ausente permaneceram.

O ciclo de vida reapareceu na operação

O RFC 3562 recomendou chaves de 12 a 24 bytes, pouco compartilhadas e trocadas ao menos a cada 90 dias. Era o custo que o formato não expressava. Senhas fracas podiam ser adivinhadas, reutilização ampliava vazamentos e uma rotação fora de sincronia derrubava BGP.

O RFC 5925 substituiu TCP MD5 por TCP-AO, acrescentando algoritmos extensíveis, KeyID, indicação da próxima chave, derivação por conexão e proteção contra replay. Mesmo assim, TCP-AO não distribui o segredo mestre e não autoriza rotas.

Já existe no acervo um artigo sobre épocas de chave TCP-AO. Este texto não o repete. Seu objeto é o formato anterior, capaz de validar um segmento, mas incapaz de dizer qual estado substituível produziu a validação.

O valor histórico do limite

O RFC 2385 resolveu um problema real com equipamento e espaço de 1998. Sua falha não foi deixar de ser uma arquitetura completa; ele nunca alegou isso. A lição é mais precisa: uma camada mínima deve ser pequena, mas não pode esconder o estado necessário para que implementações independentes a substituam.

Um segmento válido não torna a sessão eterna. Uma sessão ativa não torna a rota legítima. A rota selecionada não comprova entrega. Preservar essas camadas de realidade evita que uma defesa útil seja promovida a autoridade que ela nunca teve.

Fontes