Resumo

  • Job Snijders e Ties de Kock, do RIPE NCC, assinaram a RFC 9697, publicada pelo IETF em dezembro de 2024.
  • O validador confronta números de série e hashes já vistos; se um delta antigo mudar, avisa e volta ao snapshot completo mais recente.

O arquivo 1774 voltou com outra cara

O exemplo da RFC 9697 começa com uma atualização normal: o repositório avança do número 1774 para o 1775. A estranheza está no número antigo. O hash ligado a 1774 mudou; o de 1773 permaneceu. A gaveta conserva a etiqueta, mas alguém trocou o que havia dentro. Os números ilustram a falha descrita no padrão, não uma ocorrência identificada em produção. Job Snijders e Ties de Kock, do RIPE NCC, escreveram como o software pode perceber a troca.

Os objetos assinados do RPKI ajudam redes a verificar a origem autorizada de anúncios de rota. O RRDP distribui esses objetos por arquivos incrementais, os deltas. Primeiro o validador baixa um snapshot completo; depois busca só as alterações que faltam. Um aviso central enumera sessão, séries e hashes. Arquivos estáticos e caches web tornam o processo leve. A economia depende de uma condição sem glamour: o delta antigo precisa continuar sendo o mesmo delta.

Dois validadores que consultam o repositório em horários diferentes podem guardar conteúdos distintos para 1774 e ainda exibir a mesma sessão e a mesma série mais recente. O painel que olha apenas esses rótulos verá concordância onde há bifurcação. A solução é manter as duplas de série e hash do último aviso obtido com sucesso. Ao receber outro aviso, o validador compara as séries presentes nos dois. Se uma impressão antiga mudou, emite alerta e carrega o snapshot completo mais recente.

Em um relato técnico de 2021 sobre o rpki-client, Snijders já tinha mostrado outra dor de distribuição. Servidores atrás de um balanceador estavam fora de compasso: um anunciava um delta que outro ainda não entregava. Aquela corrida entre servidores é diferente da alteração de um delta velho estudada na RFC 9697. As duas expõem o trabalho invisível entre a assinatura de um objeto e sua chegada confiável ao operador.

Esse trabalho afeta decisões de rota. A RFC explica que um cache dessincronizado pode manter dados validados que a autoridade certificadora pretendia retirar ou deixar de publicar outros. Uma rota que deveria aparecer válida pode virar desconhecida ou inválida por tempo indeterminado. Sessões podem durar meses. Guardar o hash de ontem passa a ser um bom hábito de hoje.