Resumo

  • A Number Resource Society explica que um ROA vincula um prefixo ao ASN de origem autorizado, pode limitar anúncios mais específicos por meio de maxLength e deve ser alterado em um processo controlado.
  • O estado Valid, Invalid ou NotFound visto por um validador é uma observação. Sozinho, ele não prova quem pediu ou aprovou a mudança, quais valores eram pretendidos nem se a retirada terminou.
  • Um registro versionado de autorização e retirada pode conectar a decisão humana à publicação do RIR, às observações de validadores e às confirmações de roteamento sem confundir um sinal técnico com prova de intenção.

Uma rota válida não documenta toda a decisão

O guia de RPKI da Number Resource Society parte de uma função clara: a infraestrutura de chave pública de recursos vincula criptograficamente recursos numéricos da Internet aos seus titulares legítimos. Uma Route Origin Authorization indica qual sistema autônomo pode originar um prefixo. O campo opcional maxLength define até que comprimento anúncios mais específicos permanecem autorizados. A certificação e a publicação podem ser hospedadas pelo RIR ou operadas pelo titular em um modelo delegado.

Esse mecanismo permite verificar se a origem observada corresponde à autorização publicada. Ele não reconstitui automaticamente a decisão. O resultado atual não mostra quem propôs um novo ASN de origem, quem aceitou ampliar maxLength, qual janela foi acordada ou qual evidência justificou uma reversão de emergência.

O artigo de auditoria da NRS recomenda verificar se há ROA, se o ASN de origem e o prefixo estão corretos, se maxLength é adequado e se a rota está Valid, Invalid ou NotFound. Também pergunta quem pode criar, alterar ou remover ROAs. Um maxLength amplo demais pode autorizar rotas mais específicas do que o necessário; um valor restritivo demais pode tornar Invalid um anúncio legítimo.

Esses são fatos sustentados pelas fontes congeladas. O registro proposto é uma inferência editorial. Ele não afirma que a NRS já usa esse modelo nem que exista um ROA real defeituoso.

Autorize uma versão exata da mudança

Cada alteração deve ter identificador estável e valores anteriores e posteriores de prefixo, ASN de origem e maxLength. O registro acrescenta o titular responsável, solicitante, aprovador, horário, janela e motivo. Se um procedimento de emergência encurtar a aprovação normal, é preciso citar a regra usada e a pessoa responsável por invocá-la.

Autoridade e execução devem permanecer separadas. Quem solicita talvez não possa aprovar; quem aprova talvez não opere o portal do RIR; quem ativa o BGP talvez não possa editar o ROA. Um estado final correto não compensa a perda dessa separação.

O limite negativo também precisa ser expresso. Permissão para um prefixo não se estende silenciosamente a outro. Autorizar a troca do ASN de origem não autoriza ampliar maxLength. Uma permissão temporária de migração não deve sobreviver ao encerramento do caminho antigo.

O hash do objeto aprovado pode ligar a decisão aos valores enviados depois. Ele não prova que a decisão foi boa ou juridicamente eficaz. Prova apenas que o objeto observado pode ser comparado à versão apresentada ao aprovador.

Publicação, validação e ativação são etapas distintas

Depois da aprovação, o registro deve guardar a ação de publicação e uma referência autoritativa do RIR com horário de observação. A NRS recomenda conservar registros datados do RIR como evidência de auditoria. Isso é melhor do que lembrar que o portal estava verde, mas ainda é evidência do que foi visto, não do motivo da autorização.

Observações de validadores independentes devem ser armazenadas separadamente, com horário, ponto de observação e software ou serviço. Repositórios, caches e ciclos de atualização distintos podem gerar divergência temporária. Essa divergência pede investigação; não prova automaticamente falha de publicação ou erro do operador.

Estados úteis incluem solicitado, aprovado, enviado, publicação observada, validação observada, rota ativada, retirada solicitada, retirada observada, reversão concluída e versão substituída. Cada transição mantém seu ator ou observador e sua hora.

NotFound mostra a importância da distinção: significa que a visão do validador não encontrou um ROA cobrindo a rota. Não explica se a ausência foi intencional, atrasada, equivocada ou fora do escopo. Valid confirma uma correspondência naquela visão, mas não a continuidade da autoridade empresarial de quem iniciou a mudança.

A migração precisa de uma ordem de retirada

A NRS afirma que, em uma migração, a nova autorização normalmente deve ser estabelecida e validada antes que a rota antiga seja retirada ou o ROA anterior seja removido. Um registro converte essa sequência em evidência verificável.

Antes da execução, ele define qual novo ROA deve ser observado, em quais validadores e qual verificação de rota precisa passar. Depois identifica quem pode ativar a nova origem, retirar a rota antiga, reduzir ou remover o ROA anterior e confirmar cada etapa.

Retirar não significa apagar o histórico. A autorização anterior permanece, o evento final explica por que terminou e aponta para a substituição ou reversão. Se a mudança for desfeita, ainda será possível mostrar que a publicação inicial estava autorizada, quando o gatilho disparou e qual estado foi restaurado.

A reversão deve ser desenhada antes da janela. Os gatilhos podem incluir Invalid inesperado, falta de propagação além do prazo, perda de alcance, diferença entre valores aprovados e observados ou impossibilidade de confirmar o operador responsável. “Desfazer” não define uma ordem segura quando a publicação RPKI e a retirada BGP avançam em ritmos diferentes.

Preserve a fronteira entre fato, inferência e desconhecido

As duas fontes da NRS sustentam a mecânica de ROAs, maxLength, estados de validação, mudança controlada, auditoria e ordem de migração. Elas não identificam um operador negligente, uma conta comprometida, uma rota disputada ou um processo RIR com falha.

Os campos do registro são uma recomendação de governança. É razoável inferir que unir aprovação, publicação, validação e retirada melhora a reconstrução. Não é razoável concluir que a NRS ou outra organização não possui controles só porque uma página pública não os descreve.

Em um caso real, continuam desconhecidos o detentor efetivo da autoridade, a plataforma usada, o tempo de atualização de cada validador, o alcance do ato de roteamento e o efeito legal ou contratual. O registro deve assumir essas lacunas. Seu propósito é acompanhar a autorização criptográfica com responsabilidade humana e uma saída operacional segura.

Fontes