Resumo

  • O guia atual da ARIN admite um nome opcional no ROA, enquanto a busca no ARIN Online é descrita apenas por prefixo ou ASN.
  • A sugestão ACSP 2024.14 pediu busca por nome; a ARIN reconheceu a utilidade em agosto de 2024, colocou a ideia entre melhorias de RPKI a priorizar e o item continua Open.
  • A interface REST já recebe e devolve o nome, permitindo que uma equipe autorizada baixe a lista da organização e faça o filtro localmente.
  • O nome deve continuar privado e mutável. Para alterar ou excluir, o sistema precisa confirmar um identificador estável, além do prefixo e do ASN.

O campo lembra o projeto, mas não o localiza

Prefixo, comprimento máximo e Origin AS descrevem a autorização. O nome atende a uma necessidade diferente: conservar o contexto operacional. Pode marcar um cliente, uma migração, um produto ou um conjunto de mudanças que atravessa vários endereços e sistemas autônomos.

O guia de ROAs da ARIN incorpora essa camada humana ao listar o nome como elemento opcional. Na parte dedicada à consulta no ARIN Online, porém, informa que os ROAs de uma organização podem ser pesquisados por um prefixo ou ASN específico. O nome não aparece como chave de busca documentada. Ele tem uma porta de entrada, mas não uma rota de retorno na experiência pública do produto.

A ACSP 2024.14 transformou essa assimetria em uma solicitação precisa. Enviada em 23 de agosto de 2024, a sugestão pede a inclusão do nome ao lado de prefixo e ASN, para encontrar os ROAs ligados a um cliente ou projeto. A ARIN respondeu em 28 de agosto que a função ampliaria de forma útil as opções existentes. Disse que a colocaria na lista de melhorias de RPKI aguardando priorização e manteria a sugestão aberta até o desenvolvimento e a implantação.

As páginas congeladas para esta análise — a ficha individual e o índice atual de consultas e sugestões — ainda mostram 2024.14 como Open. Isso não prova que uma função recente ou não documentada esteja ausente de todas as contas autenticadas; nenhuma conta foi acessada neste trabalho. Também não há prazo perdido, pois a resposta não estabeleceu uma data. A evidência é mais estreita: o nome é aceito pelo modelo público, enquanto o contrato público de descoberta continua limitado a prefixo e ASN.

A API oferece uma alternativa respeitável

O melhor argumento contra a urgência de uma busca no site está na documentação da própria ARIN. O exemplo de criação da API RPKI contém name. O ROA Spec Payload devolve esse campo. A operação de listagem consulta os ROAs associados a um identificador de organização. Uma equipe com autorização pode baixar tudo e filtrar os nomes no próprio código.

Em muitos ambientes, isso basta. Prefixo e ASN são as coordenadas que realmente definem o que foi autorizado. São menos ambíguos do que um apelido de projeto e obrigam quem prepara uma mudança a rever o objeto técnico. Para uma operação já automatizada, filtrar a lista pode ser uma tarefa trivial.

Também existe um motivo forte para restringir o nome. Ele pode conter cliente, iniciativa interna ou geografia comercial. Indexá-lo fora da organização autenticada seria um vazamento desnecessário. Mesmo no perímetro correto, uma busca flexível precisa resolver nomes duplicados, mudanças de grafia, caixa, acentos e normalização Unicode. A busca por coordenadas não é defeituosa só porque evita essa semântica.

Mas uma saída programável não fecha o contrato da interface. A listagem é documentada para a organização inteira; não há parâmetro documentado de filtro de nome no servidor. Cada equipe que queira esse índice deve recriá-lo em script, planilha ou procedimento. A ARIN padroniza como o nome é armazenado, enquanto a recuperação por nome fica distribuída entre implementações locais.

O impacto é de seleção, não de validação. As fontes não registram exclusão errada, indisponibilidade, sequestro de rota, exposição de cliente ou ROA inválido. Quando um rótulo cobre vários prefixos ou ASN, ele existe justamente para expressar uma relação que as coordenadas não mostram. Sem a busca correspondente, o operador precisa memorizar as coordenadas, percorrer a lista ou manter outro mapa. Isso aumenta a possibilidade de omitir um registro relacionado ou abrir o objeto vizinho antes de uma mudança.

Um nome de gestão não integra a autoridade assinada

Há uma sequência que o termo “ROA” costuma esconder: o registro administrado no serviço da ARIN; o objeto assinado definido pelo padrão; a publicação no repositório RPKI; o estado visto por um validador; o anúncio BGP observado; e a decisão de uma rede sobre como usar esse estado.

O RouteOriginAttestation do RFC 6482 contém versão, identificador de AS e blocos de endereços IP. Não inclui nome descritivo. O guia da ARIN também orienta que a verificação do estado ativo depende de um validador RPKI e do repositório. Encontrar “migração-cliente-azul” numa tela de gestão não demonstra publicação, visibilidade no validador, anúncio correspondente nem aceitação da rota.

Essa separação permite melhorar a busca sem alterar a segurança de roteamento. O nome pode continuar privado, limitado à organização e sujeito a mudança. O registro deve ter um identificador durável. Prefixo e ASN permanecem visíveis e precisam ser revistos antes de qualquer ação.

A busca precisa terminar em um identificador estável

Uma implementação prudente começaria pelo escopo: somente os ROAs da organização que o usuário autenticado pode administrar. Depois definiria correspondência exata, por início ou por trecho; regras de caixa e Unicode; tratamento de vazio e duplicidade; e a relação entre nome antigo e histórico de auditoria.

Cada resultado deveria trazer, junto do rótulo, um identificador estável do ROA, Origin AS, prefixo, comprimento máximo e estado. Alteração ou exclusão exigiria confirmação desse identificador e das coordenadas. O nome reduz a lista de candidatos; não pode se tornar a identidade final do objeto.

Paginação também é parte da segurança. Se o inventário muda entre a primeira e a segunda página, itens podem desaparecer ou se repetir. Uma busca deveria estar vinculada a um retrato temporal e a um cursor. Um recibo compacto poderia registrar o escopo autenticado, o resumo criptográfico da consulta normalizada em vez do texto sensível, o modo de correspondência, o instante do retrato, a contagem, os identificadores devolvidos e o próximo cursor.

Esse recibo ficaria privado. Sua função seria reproduzir o conjunto apresentado antes de uma operação importante, sem expor nomes de clientes ou projetos. A ACSP 2024.14, portanto, não pede que o rótulo passe a validar rotas. Pede que um campo já aceito tenha vida operacional completa, da criação até a recuperação segura.

Fontes