Resumo

  • A eficiência do RRDP depende de uma relação estável entre local da notificação, sessão, serial, URL e hash. Reutilizar uma coordenada histórica para outros bytes quebra a capacidade de dois relying parties reproduzirem a mesma transição.
  • O cliente deve comparar hashes de deltas que aparecem em notificações sucessivas, preservar a evidência da mutação e buscar o snapshot mais recente. Esse reset corrige o histórico de transporte; manifests, certificados, CRLs, objetos assinados e a política local ainda decidem o que pode chegar às rotas.

Um CDN faz exatamente o que foi contratado: evita uma nova transferência ao entregar um objeto armazenado perto do validador. Outro edge atende uma segunda região com um objeto diferente, publicado depois sob a mesma URL histórica. Os dois validadores chegam à mesma sessão RRDP e ao mesmo serial atual. O painel comemora convergência. Um conjunto de Validated Payloads, porém, contém uma autorização que o outro não contém.

O cenário é ilustrativo. Seu ponto não é acusar o CDN. É mostrar que o cache só pode compartilhar trabalho quando a identidade do objeto continua significando os mesmos bytes.

RFC 9697 trata da desincronização causada por alteração inesperada de um delta. O relying party guarda pares de serial e hash da última notificação processada. Na notificação seguinte, compara os pares que ainda aparecem. Se um serial já observado passa a anunciar outro hash dentro da mesma sessão, há uma contradição histórica. O cliente alerta e processa o snapshot atual.

Imutabilidade é a contabilidade do cache

RFC 8182 organiza o RRDP em uma notificação estável, snapshots completos e deltas incrementais. O snapshot descreve a vista atual do repositório. Cada delta contém operações publish, replace e withdraw de um único incremento. Um validador pode aplicar uma cadeia apenas quando a sessão coincide, todos os seriais faltantes estão disponíveis em ordem contígua e cada arquivo corresponde ao hash anunciado.

Essas regras permitem produzir o artefato uma vez e entregá-lo muitas vezes. Armazenamento, banda e requisições são compartilhados. A URL histórica e o hash funcionam como um recibo: quem entrega o mesmo objeto permite que outro processo reproduza a transição sem confiar no momento exato da entrega.

Se o publicador troca os bytes, a economia continua aparente, mas sua contabilidade está errada. O edge antigo entrega a primeira versão; o edge atualizado entrega a segunda. Nenhum deles precisa corromper a transferência. O erro está em duas versões reivindicarem a mesma posição na história.

Por isso o monitoramento não pode reduzir saúde a session_id e serial máximo. RFC 8182 manda associar a sessão ao local da notificação; um UUID isolado não identifica universalmente um repositório. A evidência operacional inclui origem, localização, sessão, serial, hash do snapshot, janela de deltas e a memória dos hashes antes vistos.

RFC 6811 explica que a visão global da RPKI é normalmente fracamente consistente. Polling e processamento acontecem em horários diferentes. Um validador pode estar atrasado e ainda percorrer a mesma história legítima. Isso é diferente de dois conteúdos ocuparem a mesma coordenada. Atraso pede paciência; mutação pede descontinuidade controlada.

O reset cobra a economia de volta de uma vez

Ao detectar a mutação, continuar aplicando deltas seria escolher arbitrariamente uma das histórias. O snapshot atual fornece uma nova base completa e encerra a dependência daqueles incrementos. O cliente ainda precisa verificar hash, sessão, serial, formato e processamento do snapshot. Se ele falhar, o RRDP não entregou uma base confiável.

O custo muda de perfil. Em vez de pequenos deltas, cada relying party transfere a coleção completa. Um defeito comum pode disparar milhares de resets simultâneos contra origem e CDN, além de consumir CPU, memória e I/O dos validadores. Retentativas agressivas transformam recuperação em ataque involuntário.

A capacidade deve ser planejada como parte do protocolo em produção: tamanho e tempo de snapshot, limites de concorrência, backoff, jitter, escalonamento por região e um ponto de interrupção para intervenção humana. A promessa de cache imutável reduz o custo cotidiano; a disciplina de reset limita o custo excepcional.

Antes de substituir o estado local, o operador preserva a notificação antiga e a nova, pares conflitantes, timestamps, resposta de origem, redirects e resultado de cada fetch. Isso mantém aberta a investigação entre falha no publicador, propagação incoerente, bug do cliente e interferência. Recuperação sem prova apenas troca uma dúvida por outra.

RFC 9674 limita as URLs de snapshot e delta e seus redirects ao mesmo esquema, host e porta da notificação. A regra same-origin impede que um publicador transfira o custo de suas referências para outro servidor. Ela atribui responsabilidade pelo caminho HTTP, mas não valida o significado criptográfico dos arquivos.

O distribuidor não assina a verdade do objeto

A RPKI separa quem possui recursos, quem publica, quem distribui e quem valida. RFC 6480 descreve a infraestrutura e seus repositórios distribuídos. Disponibilidade é necessária, mas o repositório não se torna autoridade apenas por hospedar bytes.

RFC 8181 define o protocolo pelo qual uma CA solicita publish, replace ou withdraw ao serviço de publicação. A autenticação dessa relação usa uma PKI de negócio. Uma resposta bem-sucedida comprova a operação dentro dessa relação, não a validade pública do certificado, CRL ou produto assinado.

RFC 6481 descreve pontos de publicação e a necessidade de evitar estados intermediários inconsistentes. RRDP consegue transportar uma vista coerente apenas se a montagem dessa vista também foi coerente. Um mecanismo eficiente de leitura não corrige uma sequência de escrita mal coordenada.

No relying party, RFC 6488 exige validação da estrutura CMS, certificado end-entity, digest, assinatura e tipo de conteúdo, além das regras do objeto. Uma assinatura pode provar integridade e autoria dentro da cadeia; não prova que o arquivo é o mais novo nem que outros arquivos obrigatórios não foram omitidos.

RFC 9286 usa manifests assinados para enumerar arquivos e hashes de um ponto de publicação. Se um item listado falta, o cliente não deve tratar o subconjunto disponível como coleção completa. RFC 9981 atualiza as regras de número de manifest e replay, inclusive resets definidos. O número do manifest pertence à CA; não é o serial RRDP.

RFC 8897 reúne os deveres basilares de relying parties. Aquisição e validação podem estar em processos distintos, mas a prova deve ligar cada byte recebido ao manifest, às verificações e ao payload resultante. A separação torna o problema diagnosticável: transporte incoerente não é certificado inválido; certificado válido não é autorização eterna.

Um payload validado ainda não é uma decisão de encaminhamento

Depois do reset e da revalidação, o conjunto de mapeamentos prefixo-origem pode mudar. RFC 6811 determina revalidar as rotas afetadas e permite que a política local aja sobre os estados Valid, Invalid e NotFound. Não existe uma ordem RRDP para derrubar uma rota.

Uma rede pode rejeitar Invalid, reduzir preferência, marcar para análise ou aplicar uma exceção. RPKI trata da autorização de origem, não valida o caminho AS inteiro e não comprova que os pacotes chegam ao destino. A autoridade final sobre a rota continua no operador, sujeita à evidência e ao impacto.

O controle precisa acompanhar payloads adicionados e removidos, conclusão do RPKI-to-Router, rotas reavaliadas, caminho escolhido, Loc-RIB, FIB e canários de tráfego. Repositório reparado não significa validador convergido; validador convergido não significa router atualizado; router atualizado não significa serviço saudável.

Fontes