Resumo

  • O projeto RPKI/BGP Intelligence aceito pela ARIN em 2024 prevê anúncios observados, estados de validade e orientação sobre discrepâncias antes da confirmação de um ROA em ARIN Online; o mesmo texto diz que usuários da API precisarão buscar essas informações em ferramentas de terceiros.
  • A API REST atual de RPKI cria, altera e exclui ROAs numa transação unificada, que também pode incluir mudanças de ASPA de forma atômica. Trata-se de um canal de escrita de alto impacto, não de uma interface secundária.
  • A correção adequada é um preflight opcional e legível por máquina, calculado pelo mesmo modelo de aconselhamento da tela. Ele deve registrar entradas, fontes, horário e validade sem virar autorização de publicação nem alegação de visibilidade global.

O aviso existe antes do efeito

Um alerta de ROA é mais valioso antes da assinatura. Nesse ponto, prefixo, ASN de origem e maxLength já expressam uma intenção, mas a mudança ainda pode ser cancelada. A comparação com anúncios visíveis pode mostrar que uma rota passaria a Invalid, que outra continuaria NotFound ou que o objeto proposto não corresponde ao desenho operacional esperado.

Foi exatamente esse o problema descrito pela ARIN na consulta aberta em janeiro de 2024. Na época, quem criava um ROA em ARIN Online via apenas os dados do próprio objeto e precisava recorrer a terceiros para estimar o impacto na tabela global. O novo painel reuniria anúncios quase em tempo real, estado atual de validação, incompatibilidades entre BGP e ROAs e sugestões antes da confirmação.

A frase seguinte definiu o alcance. A funcionalidade seria oferecida a clientes que usam ARIN Online; usuários da API continuariam precisando de ferramentas externas para coletar a mesma informação. O resultado aceito em 11 de março manteve essa divisão. Acrescentou criação expressa de ROA para anúncios NotFound e Invalid e prometeu transparência sobre fontes e frequência de atualização.

Não há duas permissões. Em qualquer interface, a organização autenticada precisa controlar os recursos cobertos por seu certificado. O que muda é o ambiente de decisão. A pessoa na web recebe uma última leitura integrada pela ARIN. O sistema que escreve pela API precisa escolher coletores, definir frescor, implementar o cálculo e conservar uma prova própria.

A força da API torna essa diferença material. A documentação atual permite criar, modificar e apagar vários ROAs numa única operação. Ela pode ser combinada a alterações de ASPA para que todas sejam aceitas ou rejeitadas juntas. Na ARIN 57, Reg-RWS foi descrita como a API de provisionamento para transações de alto volume. Automatizar multiplica consistência e escala; uma proteção estruturada é especialmente útil nesse caminho.

As fontes não sustentam uma acusação de incidente. Não há registro, neste conjunto, de uma queda causada por um ROA enviado via API. Tampouco se pode afirmar que a API não faça validação alguma. A questão é mais precisa: o plano público coloca a análise de impacto numa via de escrita e a deixa fora da outra.

A defesa do caminho web primeiro

Há razões razoáveis para priorizar ARIN Online. A maior parte das organizações com RPKI hospedado provavelmente usa o portal. Uma tabela visual ensina uma relação difícil sem exigir de imediato um novo esquema de API, versionamento, disponibilidade e suporte. O benefício chega rapidamente a um conjunto grande de usuários.

Também é plausível que operadores que automatizam ROAs já mantenham um validador, RIPEstat, RouteViews, serviços comerciais ou feeds BGP próprios. A ARIN não precisa substituir essa visão ampla. Em 2026, explicou que Routing Intelligence seria uma ajuda dentro de ARIN Online, limitada aos recursos da organização, e não uma tentativa de reproduzir todo o panorama oferecido por terceiros.

O limite técnico é ainda mais importante. Na ARIN 56, a organização disse que obteria dados de RIPE RIS e Route Views e chamou o resultado de um snapshot relativamente recente. Esses serviços observam rotas recebidas por coletores e peers específicos. Não conhecem todos os anúncios privados, uma mudança futura de engenharia de tráfego, o estado simultâneo dos caches nem a política de cada rede.

Transformar essa fotografia em bloqueio daria à observação um poder que ela não possui. A ARIN pode decidir se o cliente está autorizado a publicar para os recursos do certificado. Um coletor só relata o que certos pontos viram em certos horários. Uma migração planejada ou uma emergência pode divergir da foto por motivos legítimos.

Por isso, a resposta não é tornar o aviso obrigatório. É torná-lo portável.

Cinco etapas que não devem virar uma só

Primeiro vem a autoridade do detentor do recurso para pedir o objeto. Depois, um preflight compara a transação proposta com rotas e VRPs observados. A escrita altera a configuração hospedada. A publicação disponibiliza objetos assinados no repositório. Por fim, cada relying party sincroniza seu cache e aplica sua política de roteamento.

RFC 6811 define Valid, Invalid e NotFound pela relação entre uma rota e os VRPs disponíveis localmente. RFC 7115 deixa claro que a sincronização dos caches depende do operador. Uma previsão correta para as entradas declaradas pela ARIN não é garantia de estado idêntico em todas as redes.

A própria documentação da ARIN separa a sequência. O fluxo web contém Review ROA. O repositório é atualizado a cada poucos minutos e o operador deve usar um validador para confirmar a ativação. Uma remoção afeta imediatamente a base RPKI da ARIN e depois aparece no repositório público dentro da janela indicada. Revisar, escrever, publicar e usar são transições diferentes.

Um preflight de API deveria, portanto, ser uma chamada pura: recebe uma proposta e devolve uma comparação limitada. Não cria, reserva, aprova ou reescreve o ROA.

A menor resposta que ainda serve

O primeiro item é o digest da transação proposta. Uma unidade atômica pode remover um ROA, criar dois e mudar um ASPA. Sem vínculo com os bytes exatos, o alerta pode acabar associado a outra versão da mudança.

O segundo é uma referência ao estado do certificado de recursos usado no cálculo. Uma versão ou digest basta para fixar a cobertura, sem revelar credenciais ou material privado.

O terceiro é a identidade da observação. A resposta deve nomear as fontes, dar o horário de cada snapshot e informar o frescor. Para cada anúncio visto, pode apresentar prefixo, origem, estado atual, estado previsto e um código estável de alerta. A explicação humana cabe na tela; a automação precisa de semântica que sobreviva a uma mudança de redação.

O quarto é a expiração. Um retrato de minutos atrás não é aprovação perpétua. Se uma fonte estiver atrasada ou indisponível, o resultado deve dizer stale ou unavailable. Ausência de dados não equivale a permissão nem a proibição.

Um token opcional de correlação pode ligar o digest ao envio posterior. Sua função é mostrar que determinada previsão acompanhou determinada transação, não certificar que ela era segura nem obrigar o operador a aceitá-la.

A origem do canal já é preservada depois

O ROA Change Log da ARIN registra se a operação veio de Web User, API User ou ARIN System, além de horário, Added ou Removed, AS de origem, prefixo, maxLength e pessoa responsável. É um bom registro pós-mudança: responde quem alterou o quê e por qual caminho.

Ele não mostra o que estava disponível antes da decisão, nem precisa ser convertido em ferramenta de previsão. O log prova a linhagem da escrita. O preflight preservaria a evidência do instante ainda reversível. A ligação opcional entre digests permitiria reconstruir a sequência sem confundir prognóstico com decisão.

Há ainda um precedente explícito de paridade. Em 2023, a ARIN anunciou um novo endpoint REST que daria paridade às melhorias da interface web de ROA, inclusive a renovação automática. Isso não é uma promessa para Routing Intelligence. É uma demonstração de que paridade pode ser uma propriedade deliberada do produto.

O que a cronologia pública permite dizer

Em outubro de 2025, a ARIN informou que o desenvolvimento havia começado em 30 de setembro. Em abril de 2026, descreveu Routing Intelligence como algo próximo no horizonte e o recap oficial o incluiu entre os trabalhos em andamento. O histórico de funcionalidades implementadas até 28 de julho de 2026 não anuncia a entrega.

Essa ausência não prova que não exista versão interna, acesso limitado ou decisão posterior. Ela sustenta apenas a formulação prudente: a capacidade aparece como planejada no estado público mais recente deste conjunto.

Na ARIN 57 também se falou em futuras funções de API de modo geral, sem ligação explícita com Routing Intelligence. Não é possível prometer paridade, nem dizer que ela foi abandonada. O desenho específico aceito direciona a análise à web; a linguagem posterior deixa espaço para revisão.

Uma sugestão comunitária ainda aberta pede análise na web e exportação em CSV de prefixos e ASNs candidatos antes do commit. A ARIN respondeu que uma função semelhante estava em seu pipeline e que avaliaria o relatório para download. O CSV melhora o transporte de informação no fluxo humano. Não substitui um contrato reprodutível que avalia a transação exata de um cliente de software.

Um aviso honesto sobre seus limites

O resultado deve identificar de onde veio a observação e quantos minutos ela tem. “Não visto pelos coletores escolhidos” não significa “inexistente na Internet”. “Previsto como Valid” não significa “já publicado”. E publicação não garante a decisão de todos os roteadores.

Com esses limites explícitos, web e API podem oferecer a mesma classe de evidência sem oferecer a mesma apresentação. A pessoa lê uma tabela. O programa compara o resultado com sua intenção e seus feeds, pausa conforme sua própria política e chama um revisor quando necessário.

A ARIN continua emissora. O detentor continua responsável pela escolha. Coletores continuam observadores e redes continuam donas da política. A API não precisa de um novo veto. Precisa conseguir ler, de forma verificável, o aviso que a ARIN já planeja mostrar antes da mesma escrita.

Fontes