Resumo

  • Em 28 de agosto, o IESG abriu o Last Call de draft-ietf-sidrops-publication-server-bcp-10, destinado ao status de Best Current Practice; o Datatracker indica 11 de setembro como prazo final.
  • O projeto usa a linguagem BCP 14 em maiúsculas, porém avisa que ela serve para enfatizar a importância operacional e não constitui requisito formal de implementação.
  • Um BCP aprovado registraria prática revisada e consenso do IETF. Não demonstraria, por si só, que determinado operador implantou um controle, cumpriu-o durante um incidente ou recebeu certificação.
  • A lacuna pode ser preenchida por um comprovante versionado de implementação: seção exata, arquitetura, estado declarado, exceção, definição e janela de medição, restaurações, redefinições de sessão RRDP, avisos e ressincronização.
  • As fontes não autorizam classificar qualquer RIR, NIR, autoridade certificadora, provedor de publicação ou CDN como conforme ou não conforme.

O ponto de publicação é uma cadeia de estados

Uma autoridade certificadora cria material RPKI assinado. Um mecanismo de publicação recebe alterações pelo protocolo descrito no RFC 8181. Repositórios públicos disponibilizam o resultado por RRDP e rsync. Relying parties baixam e validam esse material, e cada rede decide como incorporar o resultado à sua política de roteamento. Entre a assinatura e a decisão local há, portanto, uma cadeia operacional com vários relógios, responsáveis e modos de falha.

O documento colocado em Last Call em 28 de agosto trata dessa cadeia. A versão 10 de Best Practices for Operating Resource Public Key Infrastructure (RPKI) Publication Services pretende tornar-se um Best Current Practice. Não propõe um novo formato de objeto. Organiza mais de uma década de experiência em separação de funções, disponibilidade, restauração, sincronização, DNS, dependências de roteamento, CDNs, balanceamento e coerência entre as visões entregues aos clientes.

Esse escopo impede que a assinatura seja confundida com o último estado do serviço. Um ROA pode estar corretamente assinado e ainda não ter chegado à superfície pública. O mecanismo voltado aos publicadores pode aceitar uma mudança enquanto um nó de leitura continua exibindo o conjunto anterior. Uma restauração pode reabrir um estado consistente, porém antigo. Um arquivo de notificação RRDP pode aparecer antes do snapshot ou dos deltas que referencia. Todos são problemas observáveis sem que a criptografia do objeto esteja errada.

Por isso, “RPKI disponível” é uma descrição curta demais. É preciso dizer qual superfície respondeu, qual conteúdo era esperado, quando ele apareceu, que visão foi comparada e como uma divergência foi encerrada.

A ressalva que deve acompanhar as maiúsculas

RFC 2119 define a força de palavras como MUST e SHOULD; RFC 8174 esclarece que o significado especial de BCP 14 se aplica quando elas aparecem em maiúsculas. A seção 2.1 do projeto de publicação invoca justamente esse vocabulário. Logo em seguida, porém, inclui uma nota própria: os termos são usados para salientar a importância operacional, e não são requeridos como exigências formais de implementação.

Não há contradição que deva ser “corrigida” por uma leitura seletiva. Ignorar as maiúsculas reduziria controles sérios a sugestões casuais. Ignorar a nota inventaria um regime de conformidade que o documento não estabelece. A leitura íntegra é mais exigente: as práticas merecem o peso máximo na operação, mas ninguém recebe automaticamente um selo porque o futuro RFC contém MUST.

O status de BCP, se o processo chegar a esse resultado, também terá peso real. O RFC 7841 distingue as categorias da série RFC e registra a proveniência de revisão e consenso de um documento do fluxo IETF. Essa proveniência explica por que a orientação merece atenção. Ela não informa qual serviço foi avaliado, em qual período, com quais testes ou por qual avaliador.

Consenso pode definir a referência. Só a evidência de implementação descreve uma instalação concreta.

Três disponibilidades em vez de um número confortável

O projeto determina alta disponibilidade tanto para o conteúdo público quanto para o mecanismo de publicação. As consequências da indisponibilidade não são iguais. Se RRDP ou rsync deixa de responder, relying parties não recuperam normalmente o estado atual. Se o mecanismo que recebe alterações para, uma autoridade certificadora fica impedida de distribuir novas emissões ou revogações. Uma interrupção prolongada pode deixar manifests, listas de revogação e objetos assinados envelhecerem.

Um percentual agregado esconde essa diferença. Um registro útil separa pelo menos o mecanismo voltado ao publicador, RRDP e rsync, com denominadores, janelas e exclusões próprios. Também informa o tempo restante antes de dados válidos se tornarem obsoletos; uma resposta HTTP bem-sucedida não mede esse prazo.

O texto recomenda manter o mecanismo de publicação separado das máquinas que atendem à leitura pública. A separação reduz o risco de uma carga externa bloquear o canal de alteração. O comprovante pode descrever domínios de falha e fronteiras lógicas sem expor endereços, credenciais ou um mapa útil para ataque.

Outra recomendação é monitorar a volta completa: comparar o objeto reemitido que se espera encontrar com aquilo que aparece pela via pública. Para que o resultado seja comparável, a medição deve fixar evento inicial, observação final, classe do objeto, pontos de observação, período, percentis, falhas e exclusões. O estudo citado pelo projeto observou propagação de 15 a 95 minutos no conjunto analisado; não transformou essa faixa em objetivo universal de serviço.

A restauração revela quem controla cada etapa

O cenário de recuperação é a melhor demonstração da diferença entre regra e prova. Quando uma restauração causa regressão de conteúdo, o servidor deve redefinir a sessão RRDP. O operador também deve avisar as autoridades certificadoras dependentes para que possam iniciar uma ressincronização completa.

Um incidente verificável liga eventos: backup restaurado, antiguidade do estado, regressão detectada, novo identificador de sessão, publicadores avisados, lista comparada, conjunto republicado e observação pública reconciliada. Um painel de uptime não reconstrói essa sequência depois do fato.

O RFC 8181 permite que a autoridade consulte a lista reconhecida pelo servidor. O projeto recomenda essa consulta antes de enviar mudanças e aconselha reunir alterações relacionadas numa única solicitação com múltiplos elementos, reduzindo efeitos parciais inconsistentes. Também recomenda que a reconciliação regular não ocorra mais de uma vez a cada dez minutos, salvo acordo, porque o protocolo não oferece sinalização suficiente de limite ou recuo.

Cada ponto pode gerar evidência sem revelar o conteúdo privado de clientes. O registro público pode mostrar data, escopo, estado, duração, responsável pela declaração e resultado final. Identidades de publicadores, chaves e detalhes sensíveis continuam protegidos.

Serial, manifest e disponibilidade respondem a perguntas diferentes

RRDP usa identificador de sessão, número de série, deltas e snapshot. Uma série crescente mostra revisões posteriores dentro daquela sessão. Não prova, isoladamente, que o conjunto pretendido pelo publicador foi aceito, que todos os nós balanceados apresentam arquivos idênticos ou que cada relying party observou a mesma mudança.

O projeto exige que o arquivo de notificação não fique visível antes dos snapshots e deltas referenciados. Em uma arquitetura com vários backends, cada um precisa oferecer uma visão coerente. A ordem de visibilidade é parte da correção, não mero detalhe de entrega. Para CDNs, o texto limita a cache regular da notificação e recomenda servir conteúdo antigo quando o backend está indisponível; a alegação correspondente precisa declarar tanto a política quanto a observação.

O RFC 9286 oferece outra prova delimitada. Manifests relacionam nomes e hashes, permitindo detectar determinadas formas de substituição antiga, remoção ou modificação durante o trânsito. Eles não medem aviso de manutenção, idade do backup, consistência do balanceamento, alcance IPv4 e IPv6, regras de CDN ou apoio aos publicadores.

Somar essas evidências sob a expressão “conforme ao BCP” apaga as perguntas que cada uma realmente responde.

Consolidação operacional não é concessão de autoridade

O projeto observa que repositórios auto-hospedados tendem, na prática, a enfrentar mais problemas de disponibilidade do que serviços de organizações especializadas. Também lembra que muitos pontos de publicação aumentam o trabalho das relying parties. Por isso recomenda que CAs-mãe ofereçam publicação aos filhos e que estes usem o serviço disponível; quando isso não existe, um terceiro confiável pode ser preferível a um novo repositório isolado.

É um argumento de economia operacional, não uma franquia exclusiva para RIR, NIR ou fornecedor comercial. O próprio texto reconhece que pequenos repositórios com baixa mudança podem obter alta disponibilidade com infraestrutura modesta e descreve opções para CAs descendentes publicarem por meio do pai ou ao lado dele.

O comprovante deve preservar essa escolha. Primeiro identifica a arquitetura — própria, hospedada pelo pai, terceirizada ou intermediada — e depois aplica os controles pertinentes. Não aplicável é um estado válido quando vem acompanhado de motivo delimitado. O silêncio não é, pois convida o leitor a supor o caso mais favorável.

O comprovante de implementação

O primeiro bloco fixa identidade e versão: operador, serviço, arquitetura, identificadores públicos, classe de cliente e versão exata do projeto ou RFC. “Segue o BCP do IETF” perde significado assim que o texto muda.

O segundo bloco é um registro por seção. Cada prática material recebe um estado — implementado, não aplicável, planejado, exceção ou desconhecido —, a autoridade que fez a declaração, data de revisão e justificativa. Alterações criam nova versão em vez de apagar a anterior.

O terceiro bloco define a medição. Para o tempo de publicação, especifica começo, fim, objeto, pontos de observação, período, percentis e falhas. Para disponibilidade, separa mecanismo de publicação, RRDP e rsync. Para consistência, descreve um teste seguro de visões divergentes. Para manutenção, registra antecedência do aviso, impacto previsto e impacto observado.

O quarto bloco trata mudança e recuperação: regressão, redefinição RRDP, aviso, pedido de ressincronização, conclusão e divergências não resolvidas. O quinto limita a afirmação: declaração do operador, observação independente, auditoria contratada ou análise de incidente, sempre com sistema e período cobertos.

O resultado é menos vistoso do que um selo. Essa é a vantagem. Cada linha pode ser verificada, contestada ou atualizada sem emprestar ao IETF uma autoridade que ele não reivindicou.

O que ainda não pode ser concluído

O Last Call não prova que o texto será aprovado nem que permanecerá igual. O IESG pode receber comentários, solicitar mudanças, avaliar outra versão ou não publicá-la. Ainda não há número de RFC ou BCP.

As afiliações dos autores — entre elas RIPE NCC, ARIN, APNIC e BSD — não são amostra de auditoria das respectivas organizações. As fontes não identificam um operador que tenha falhado numa restauração, servido conteúdo inconsistente ou ocultado uma interrupção.

Nada indica que um eventual BCP substitua contrato, regra de contratação, decisão regulatória, ordem judicial ou política local de roteamento. RFC 8181 define a troca de publicação; RFC 8182, a distribuição RRDP; RFC 9286, manifests. São estados técnicos importantes, não certificados de desempenho de uma empresa.

A conclusão defensável é mais precisa. O IETF está revisando uma descrição detalhada de como serviços de publicação devem ser operados. Se ela virar BCP, ganhará autoridade documental. A prova de adoção por um operador continuará sendo uma obrigação separada.

Fontes

  1. IESG — Last Call do projeto sobre serviços de publicação RPKI
  2. IETF Datatracker — registro do projeto de BCP
  3. IETF Datatracker — versão 10 do projeto
  4. RFC 2119 — palavras de níveis de exigência
  5. RFC 8174 — esclarecimento sobre maiúsculas e minúsculas
  6. RFC 7841 — fluxos, categorias e textos da série RFC
  7. RFC 8181 — protocolo de publicação RPKI
  8. RFC 8182 — RPKI Repository Delta Protocol
  9. RFC 9286 — manifests RPKI
  10. RFC 7115 — operação da validação de origem baseada em RPKI