Summary

  • Um relying party RPKI produz uma visão local e temporal a partir de repositórios distribuídos, âncoras configuradas, regras de validação, resultados de sincronização e eventuais controles locais.
  • draft-su-sidrops-rpki-rp-requirements-00 propõe exportação estável do cache, diagnóstico das rejeições e retenção de estados históricos para comparação, replay e análise posterior.
  • Daniel Kade propõe um recibo de estado de validação que una execução, entradas e falhas, digest do cache, transformações locais, entrega aos roteadores e retenção. A proposta é editorial, não uma exigência da IETF.

Entre o objeto assinado e a rota existe um sistema local

RPKI não entrega ao roteador uma resposta pronta do mundo. Autoridades publicam certificados, CRLs, manifests e objetos assinados. O software de relying party escolhe âncoras de confiança, encontra pontos de publicação, busca material, executa validação geral e específica, constrói um cache e pode aplicar filtros ou asserções SLURM. Só então outro protocolo oferece os payloads ao roteador, que ainda toma decisões conforme sua política BGP.

Cada camada responde a uma pergunta diferente. Uma assinatura válida não comprova que todos os repositórios responderam. Um manifest atual delimita os objetos correntes de um ponto, não toda a observação. Um payload recebido do cache não demonstra que uma rota foi instalada ou anunciada. Transformar tudo isso em “RPKI verde” facilita operação, mas elimina os limites da afirmação.

RFC 8210 mostra um exemplo concreto. O serial é uma versão lógica dentro de uma sessão de cache. Ele não é comparável entre caches ou versões de protocolo e pode não persistir após reset. Sem Protocol Version e Session ID, o número não identifica um estado global.

O draft atualiza o mapa de obrigações

O draft individual de 12 de junho de 2026 pretende atualizar a função de referência única de RFC 8897. Ele reúne mudanças relacionadas a chaves sucessoras de âncoras, sincronização RRDP, manifests, ROAs, ASPAs, RSCs, TAKs, certificados, CRLs, distribuição de cache e controle local.

O limite processual deve acompanhar cada menção. O Datatracker não mostra adoção por Working Group, RFC stream, AD responsável ou telechat. O cabeçalho indica status Informational pretendido e atualização de RFC 8897 somente se aprovado. Referências a outros drafts SIDROPS são provisórias. Não há base para dizer que virou padrão, produto ou prática implantada.

Sua contribuição mais reveladora está na operação. O texto diz que o RP deveria exportar o estado validado em formato estável e legível por máquina; disponibilizar status e diagnóstico para explicar falhas de busca, sincronização, parsing e validação; e preservar estados históricos ou registros equivalentes para comparação, replay e análise.

Exportar informa o resultado. Diagnosticar informa a fronteira do que ficou de fora. Reter informa quando essa fronteira mudou. Juntas, essas funções tornam a saída contestável e verificável.

Falhas também são entradas da decisão

Um cliente RRDP precisa aplicar a política de mesma origem de RFC 9674 e deveria detectar e recuperar a dessincronização descrita por RFC 9697. A recuperação pode envolver snapshot, mudança de caminho ou fallback. O conjunto final de payloads não revela sozinho qual opção ocorreu.

O processamento de manifests também produz evidência negativa. Manifest ausente, inválido ou stale; arquivo listado não recuperado; hash incorreto; ou objeto no ponto de publicação errado fazem o fetch falhar conforme as regras citadas. A CRL relevante precisa ser entendida em conjunto com manifest válido e atual.

Tempo amplia o problema. Certificados e objetos expiram; cache e roteador têm refresh, retry e expire interval; o relógio do servidor participa da validação. Duas execuções honestas podem divergir porque observaram janelas diferentes. Um refresh posterior não deve apagar a janela anterior.

O controle local precisa ser nomeado

SLURM permite que o ISP filtre ou acrescente informações localmente. Isso pode proteger continuidade durante uma falha conhecida ou implementar uma exceção estreita. Mas a asserção não altera o objeto publicado: altera a visão usada por aquela rede.

Quando a transformação fica invisível, atribui-se ao publicador uma decisão do operador. Quando recebe identificador, aprovação, período e digest, pode ser revisada, expirar e ser corrigida. Transparência aqui não significa revelar segredos; significa não confundir origem global com política local.

Dois caches verdes podem, portanto, ter versões, âncoras, caminhos de sincronização e regras locais diferentes. Igualdade de cor não prova equivalência de estado. Mesmo igualdade de payload pode ser coincidência se os caminhos de evidência não forem preservados.

O recibo de estado de validação

O draft não especifica esse recibo. Daniel Kade propõe uma junção compacta dos registros operacionais.

O bloco de execução identifica produto, versão, perfil, digest de configuração, famílias de objeto, conjunto de âncoras e condição do relógio. O bloco de aquisição lista pontos tentados, protocolo, última observação bem-sucedida, tentativa atual, recuperação e classe de falha.

O bloco de validação guarda estado de manifest e CRL, contagens aceitas e rejeitadas por tipo, razões, transição de âncora, perfil normativo e digest canônico do cache. O bloco local registra a política de filtro ou asserção, aprovação, vigência e digest da transformação.

Na entrega entram versão RPKI-to-Router, Session ID, serial, horário de exportação, escopo de consumidores e lacunas. Na retenção entram referência ao estado anterior, prazo, responsável e ligação de correção.

Chaves privadas, credenciais e topologia desnecessária ficam de fora. Detalhes podem permanecer em domínio restrito, enquanto digest, horários e classes são compartilhados. Não é preciso centralizar o histórico para torná-lo verificável.

Uma prova deliberadamente menor

O recibo não prova a correção material de cada publicação, a decisão posterior do roteador ou a motivação humana de uma exceção. Não transforma draft em norma nem arbitra automaticamente entre implementações. Seu valor está em conservar uma afirmação menor: qual visão local foi produzida e oferecida ao roteamento naquele intervalo.

Um RP é componente contínuo, não verificador de uma só execução. Ele sincroniza, falha, recupera, muda de versão e recebe novas políticas. Se sua saída afeta segurança de roteamento, a história dessas transições faz parte do controle. O cache pode continuar verde; a governança exige que também seja explicável.

Sources

  1. Lu Heng — The Policy Mirror
  2. Lu Heng — Minimum Initial Specification
  3. Lu Heng — Why BTW Media Exists
  4. Draft de requisitos RPKI RP, revisão 00
  5. Status no Datatracker
  6. Histórico no Datatracker
  7. Working Group SIDROPS
  8. RFC 8897 — Requisitos para relying parties RPKI
  9. RFC 6480 — Infraestrutura para roteamento seguro
  10. RFC 9286 — Manifests RPKI
  11. RFC 9674 — Política de mesma origem para RRDP
  12. RFC 9697 — Dessincronização de sessão RRDP
  13. RFC 9691 — Chaves de âncora de confiança RPKI
  14. RFC 8416 — SLURM
  15. RFC 8210 — Protocolo RPKI-to-Router v1
  16. RFC 9582 — Autorizações de origem de rota
  17. RFC 9829 — Extensões de número CRL RPKI