Resumo

  • A notificação RRDP da AFRINIC capturada em 14 de setembro de 2026 listava 32 deltas contíguos, do serial 96961 ao 96992.
  • Os cabeçalhos públicos Last-Modified nas pontas da sequência tinham 425 minutos de diferença, mas essa medida não promete sete horas de recuperação incremental.
  • Pelo RFC 8182, o validador só usa deltas quando toda a cadeia ausente está disponível; se faltar um elo ou ele for rejeitado, o caminho normal é processar o snapshot atual.
  • Um recibo público de continuidade pode juntar seriais, tempo, volume, mudanças de sessão e testes de fallback sem identificar validadores ou expor atividade de associados.

A retomada começa pelo estado que ficou para trás

Depois de uma manutenção, o validador RPKI não pergunta simplesmente se o repositório está “no ar”. Ele compara o identificador de sessão atual com o que guardou e calcula os seriais que ainda precisa processar. A notificação RRDP funciona como o mapa dessa retomada.

Quando todos os números intermediários continuam referenciados, o cliente baixa os deltas, confere formato e hash e aplica as alterações na ordem correta. Quando seu último serial está antes do trecho mantido, ou um arquivo indispensável não pode ser aceito, a sequência não pode ser reconstruída com segurança. O RFC 8182 manda então processar o snapshot atual, que representa o conteúdo completo do repositório naquele estado.

O fallback é parte do protocolo, não diagnóstico de incidente. Ainda assim, trocar alguns deltas por um snapshot altera consumo de rede, memória, armazenamento e tempo de convergência. Esse é o ponto em que uma lista suficiente para a máquina deixa uma pergunta em aberto para o profissional responsável por manutenção e redundância.

O que estava publicado na captura

Às 16h49 UTC de 14 de setembro, a notificação RRDP da AFRINIC mostrava a sessão 8fe3109e-2561-4627-8850-83ab94b9bb91 e o serial corrente 96992. Havia 32 referências de delta. Ordenadas, elas cobriam sem lacuna os seriais 96961 a 96992.

O arquivo de notificação veio com max-age=60 e permissão para servir conteúdo anterior em caso de erro. O RFC 8182 recomenda que esse arquivo mutável não fique em cache por mais de um minuto. O valor observado segue a recomendação; não é uma fragilidade apontada por esta análise.

Os metadados HTTP acrescentaram relógios públicos. O delta 96961 indicava última modificação às 07:40:05 UTC; o 96992, às 14:45:06 UTC. A diferença era de 425 minutos. O snapshot referenciado usava a mesma origem rrdp.afrinic.net e respondeu HTTP 200 na verificação limitada.

O registro mostra uma cadeia real e disponível naquele momento. Ele não garante que futuras 32 revisões cubram sete horas e cinco minutos.

Publicações chegam em rajadas, não em parcelas de uma hora

O serial avança quando o repositório publica uma nova versão. Certificados, CRLs, manifestos, ROAs e outros objetos podem mudar em ritmos diferentes. Uma rajada consome muitos números rapidamente; um período estável faz a mesma contagem atravessar mais horas. Quantidade de revisões e passagem do tempo são grandezas relacionadas, não intercambiáveis.

Existe ainda um limite econômico dentro do padrão. O RFC 8182 determina que deltas mais antigos sejam excluídos quando a soma deles com todos os mais novos ultrapassaria o tamanho do snapshot. Assim, o início da cadeia é escolhido para não transformar a rota incremental na opção mais pesada. Não é definido como promessa de retenção por dia.

A regra beneficia o cliente, mas impede que “32” seja usado como orçamento de recuperação. Faltam os bytes comprimidos e decodificados do snapshot, o volume agregado dos deltas, a velocidade com que o primeiro serial se desloca e o resultado de uma recuperação real em ambiente controlado.

Um recibo para ligar protocolo e operação

A Declaração de Práticas de Certificação RPKI da AFRINIC registra o suporte a RRDP e informa o endereço da notificação. É a camada normativa. A notificação oferece a camada corrente. Um recibo de continuidade pode unir as duas sem impor uma garantia que o protocolo não contém.

Esse recibo registraria horário de observação, sessão, serial atual e primeiro serial mantido, contagem e extensão temporal observada. Acrescentaria tamanho comprimido e expandido do snapshot, soma dos deltas retidos, mudanças recentes de sessão e ensaios em que tanto a aplicação incremental quanto o fallback completaram a verificação de hash.

O desenho precisa separar controles. Disponibilidade HTTPS não prova validade de todos os objetos assinados. Validade criptográfica não determina a política de roteamento. CDN, publicação do repositório, processamento do validador e decisão BGP merecem evidências próprias, ligadas por horário e versão.

Limites que preservam a conclusão

A captura não mostra cliente real fora da cadeia, falha de snapshot, erro de hash, dado de roteamento obsoleto nem dano a associado. Também não demonstra que 32 deltas sejam poucos ou contrariem o RFC. O padrão permite uma faixa dinâmica justamente para equilibrar deltas e snapshot.

A recomendação trata de explicabilidade operacional. O software já sabe quando mudar de caminho. A pessoa ainda não recebe um histórico que permita estimar o peso da mudança. Publicar esse histórico é diferente de monitorar quem consulta o repositório: não exige IP de cliente, atividade de associado ou topologia privada.

Fontes principais