Resumo

  • Em 28 de agosto de 2026, a IETF abriu até 11 de setembro a última chamada para uma Best Current Practice sobre engines de publicação RPKI e repositórios RRDP e rsync. O documento ainda é uma proposta, não uma BCP aprovada.
  • Uma nova notificação RRDP não pode ficar visível antes de seus snapshots e deltas. Com vários backends, as solicitações precisam seguir uma visão coerente ou todos os nós devem receber o material antes que qualquer nó exponha o anúncio.
  • Receber session e serial novos comprova apenas uma resposta de índice. Não comprova bytes disponíveis em todos os caminhos, validação RPKI, mudança na saída do relying party, aplicação no roteador nem efeito sobre pacotes.

O relying party recebe um serial novo. Pede o delta indicado e cai em outro backend. A notificação já chegou ali; o delta, não. O servidor devolve 404. Mais tarde, uma conexão persistente ainda presa a um nó em manutenção apresenta um serial anterior.

A inconsistência surgiu antes de qualquer decisão criptográfica. O serviço publicou a afirmação de que os dados existiam antes de concluir a distribuição dos próprios dados.

A última chamada de 28 de agosto torna esse risco uma questão atual de coordenação. O rascunho de operações está aberto a comentários até 11 de setembro. Ele ainda não é consenso final e não acusa nenhum repositório específico de ter produzido esse cenário.

A referência só deve aparecer depois do referente

RFC 8182 separa a notificação dos arquivos de snapshot e delta. A notificação identifica session e serial e aponta para o material necessário à sincronização. Torná-la pública significa afirmar que o caminho de recuperação já funciona.

Num servidor único, a ordem pode ser uma troca simples. Em uma frota, o operador precisa manter as solicitações subsequentes no mesmo nó ou impor uma ordem global: distribuir todos os snapshots e deltas e somente depois liberar a notificação. O requisito não é que os discos acabem iguais em algum momento futuro. É que o cliente nunca possa combinar índice novo com armazenamento antigo.

CDN, caches e conexões fazem parte da superfície. Um 404 guardado antes da criação de uma rota pode bloquear um delta já publicado. Cache longo da notificação mantém uma visão antiga. Keepalive para um servidor retirado continua servindo outra session. Por isso o estado do orquestrador não basta; canários externos devem percorrer os caminhos realmente oferecidos.

Uma regressão de serial também não vem com interpretação universal. RFC 8182 não define a reação do RP. Certas implementações podem buscar o snapshot. Esse comportamento tenta recuperar coerência; não transforma o maior número em prova de frescor ou o menor em prova de falsidade.

O fallback converte uma falha pequena em tráfego grande

Se o delta falha, o cliente pode buscar o snapshot completo. Se o snapshot falha, passa a rsync. Na próxima rodada RRDP, talvez comece de novo pelo snapshot. Uma notificação prematura pode multiplicar transferências pesadas em toda a população de RPs.

O rascunho recomenda observar capacidade, memória, I/O e fallbacks inesperados por meio de um RP canário fora da rede. O volume só ganha sentido quando associado a session, serial, backend, URI, resposta HTTP e idade de cache. Sem isso, uma curva crescente mistura uso normal com recuperação repetida.

Snapshots e deltas antigos deveriam permanecer por duas horas depois de deixarem a notificação corrente. Essa margem ajuda clientes lentos e solicitações em andamento, mas protege o passado. Não cria o delta novo que deveria ter precedido a notificação.

Também se recomenda não produzir deltas mais de uma vez por minuto. Agregar alterações reduz arquivos e overhead; ainda assim, o conteúdo agregado precisa existir antes do índice agregado.

Há um recibo para cada fronteira

A CA assina material e o envia ao publication engine por RFC 8181. Uma consulta list antes da mudança revela diferenças. Várias PDUs em uma consulta multi-elemento ajudam uma alteração planejada como atômica a não terminar pela metade.

Depois disso, os recibos não se confundem. O inventário da CA expressa intenção. A resposta RFC 8181 expressa aceitação pelo engine. A notificação expressa o que um endpoint anunciou. O download registra os bytes entregues. O RP valida certificados, manifestos, CRLs e objetos. A alimentação do roteador, a política local, a FIB e o pacote observado permanecem fatos posteriores.

Um objeto disponível pode não constar do manifesto atual ou falhar em hash e cadeia. Um ROA válido limita uma autorização entre prefixo e AS de origem; não prova anúncio BGP atual. É a separação das camadas de realidade de Heng Lu aplicada ao repositório.

O mecanismo sugerido para rsync mostra a mesma disciplina. Atualizar arquivos enquanto um cliente lê pode produzir uma mistura fantasma. Preparar um diretório completo, ajustar timestamps e só então mudar um symlink oferece uma visão indivisível. RRDP usa notificação por último; rsync usa troca de snapshot. Ambos publicam somente o estado concluído.

Continuar contando pode esconder uma ruptura

Serial crescente ordena atualizações dentro de uma session. Não mede idade nem correção. Conteúdo atrasado pode receber números crescentes; conteúdo novo pode falhar na validação.

Se uma restauração faz o repositório regredir, a proposta exige reset da session RRDP e recomenda avisar as CAs dependentes para resincronização completa. O reset preserva a verdade de que a continuidade foi interrompida. Não recupera sozinho ROAs perdidos, publishers novos ou manifestos perto de vencer.

A primazia do código em execução pede testes pelo caminho público, não confiança no painel. A diferença entre controle formal e prático aparece em quem pode congelar a notificação, limpar caches, drenar conexões, resetar a session e guardar a visão anterior.

Publicar a notificação por último não encerra a validação RPKI. Apenas garante que o primeiro recibo público não promete bytes que o serviço ainda não consegue entregar.

Sources