Resumo

  • Desde outubro de 2023, a ARIN notifica os POCs Admin, Tech e Routing quando um ROA é removido. Em junho de 2024, o limite de remoções permitido para uma organização subiu de 20 mil para 40 mil.
  • A sugestão ACSP 2025.6 pede um parâmetro que suprima todo o e-mail de uma chamada de remoção em massa. A ACSP 2026.6 registra que criação e alteração não notificam todos os POCs.
  • Reduzir mensagens repetidas é uma necessidade operacional legítima. Ainda assim, criar ou alterar um ROA também pode mudar as evidências usadas para classificar uma origem de rota.
  • O controle mínimo deveria ser um resumo durável por transação concluída, reunindo autoridade do ator, estado anterior e posterior, resultado atômico, observação da publicação e entrega a um canal independente.

O número de mensagens não mede o tamanho do risco

Em 3 de junho de 2024, a ARIN aumentou de 20 mil para 40 mil o máximo permitido de remoções de Route Origin Authorizations para uma organização. É um limite de produto, não a contagem de um incidente. A fonte não diz que uma organização tenha removido 40 mil ROAs, em uma única operação ou em qualquer outra, nem que 40 mil rotas tenham perdido alcance.

O número importa por outro motivo: mostra que a interface precisa lidar com conjuntos grandes. Se cada objeto removido gerar uma mensagem para cada integrante de uma lista extensa de POCs, o volume de e-mail passa a ser o produto de duas grandezas administrativas. Nem o número de objetos nem o número de destinatários revela, por si só, qual alteração é crítica.

Uma manutenção planejada pode produzir milhares de mensagens iguais. Uma única remoção, em contraste, pode exigir atenção imediata. Quando o canal não distingue as duas situações, o destinatário prepara filtros, ignora o lote ou entende a enxurrada como parte já conhecida da janela de mudança. A cobertura formal aumenta e a atenção disponível cai.

Esse é o melhor argumento da ACSP 2025.6. A proposta, apresentada em 11 de julho de 2025, descreve grandes gestores de endereços com muitos profissionais na lista de POC. Eles precisam avisar antecipadamente que os colegas receberão muito e-mail; os servidores da ARIN e as caixas de entrada também suportam o custo. A solução pedida é um parâmetro opcional na API de remoção. O padrão permaneceria falso; quando ativado, ele impediria toda geração de e-mail para aquela chamada.

A ARIN respondeu em 23 de julho que a funcionalidade seria benéfica e teria prioridade no calendário de desenvolvimento. A página continuava Open, aguardando implementação, no material congelado para esta análise. Isso confirma planejamento público, não entrega em produção.

O pedido não deve ser tratado como tentativa de esconder atividade. Ele identifica uma granularidade ruim. O problema é imaginar que milhares de cópias de um aviso equivalem a milhares de controles independentes.

Por que a remoção recebeu atenção primeiro

A regra de notificação não surgiu sem motivo. Em 9 de outubro de 2023, a ARIN anunciou avisos no ARIN Online para os POCs Admin, Tech e Routing sempre que um ROA fosse removido.

Um ROA é a declaração assinada pela qual o detentor de prefixos autoriza um Sistema Autônomo a originá-los. O RFC 8211 descreve o efeito da exclusão no ponto de publicação: a ligação verificável entre prefixo e AS deixa de existir. Se não houver outro ROA cobrindo o prefixo, uma rota antes amparada pode passar a NotFound. Se restar um ROA que autorize outro AS, pode passar a Invalid.

Isso não demonstra uma queda de serviço. Validadores atualizam em momentos distintos, e cada rede decide localmente o tratamento de uma rota Invalid. Mas o mecanismo justifica separar quem executa a alteração de quem a observa. A automação pode usar uma credencial; o POC Admin pode responder pela organização; o POC Routing pode estar em outra escala operacional. Um sinal fora da sessão do ator ajuda a detectar erro, credencial comprometida ou mudança não coordenada.

O valor está nessa independência, não na repetição objeto por objeto.

A criação também pode mudar a resposta do validador

A ACSP 2026.6, apresentada em 23 de abril de 2026, expôs a assimetria. Segundo a sugestão, todos os POCs recebem uma notificação da ARIN e um e-mail quando um ROA é removido, mas não quando ele é criado ou alterado. O autor pediu controles opcionais para os três tipos de mudança, talvez com uma preferência global por conta.

Em 27 de abril, a ARIN agrupou a solicitação com outras melhorias pendentes de notificação de ROA, encaminhou-a para priorização e planejamento internos e fechou a sugestão. Closed é o estado do expediente ACSP. Não prova que a funcionalidade tenha sido implantada.

O ponto técnico é decisivo. Adicionar um ROA não produz apenas “mais autorização”. Um novo ROA abrangente pode fazer um anúncio de outro AS, ou um anúncio mais específico que o maxLength permitido, mudar de NotFound para Invalid. Uma alteração pode reduzir o conjunto de prefixos, trocar o AS autorizado ou mudar o comprimento máximo. A ação gravada como adição pode restringir a classificação de outro anúncio.

Por isso, create, modify e delete são nomes insuficientes para definir materialidade. A pergunta correta é: quais combinações de prefixo, AS de origem e maxLength eram aceitas antes, e quais são aceitas depois?

A transação da ARIN já preserva a intenção conjunta

O guia da API RESTful de RPKI descreve uma chamada unificada, por organização, para criar, alterar e remover ROAs. Ela pode ser combinada com mudanças de ASPA em uma única transação, e todas as ações têm sucesso ou falham juntas. O payload carrega uma lista de ROAs a remover e outra de ROAs a adicionar.

A atomicidade é uma proteção importante. Uma substituição não deve parar depois de remover o objeto antigo e antes de publicar o novo. Além disso, a transação fornece a unidade que falta ao aviso. A ARIN sabe que vários objetos pertencem à mesma intenção, foram enviados pelo mesmo ator e chegaram a um resultado comum.

Separá-los novamente em milhares de mensagens destrói contexto. Silenciar tudo preserva o contexto apenas para a conta que executou a chamada. Um resumo da transação pode manter a intenção conjunta e levá-la a um observador independente.

O Change Log é evidência real, mas exige iniciativa

Desde setembro de 2025, o ARIN Online oferece um ROA Change Log. A documentação atual descreve uma janela de 365 dias. O registro apresenta horário, operação Added ou Removed, origem Web User, API User ou ARIN System, Origin AS, prefixo, maxLength e o nome do usuário que fez a mudança. Listas com mais de 100 itens são paginadas. O CSV completo pode ser solicitado por ticket e disponibilizado depois da análise da ARIN.

É uma base forte para auditoria posterior. As fontes verificadas não mostram que o registro seja incorreto, alterável pelo usuário ou indisponível para quem tem permissão. A crítica responsável deve reconhecer essa capacidade.

Ainda assim, um log consultável e uma notificação enviada tratam falhas diferentes. O primeiro espera que alguém entre no sistema e procure. A segunda chama a atenção de outra pessoa ou ferramenta. Se a credencial que realizou a operação estiver comprometida, essa distância administrativa faz diferença. Se o canal independente receber dezenas de milhares de e-mails, ele preserva a distância e perde a síntese.

O desenho mais enxuto combina o registro detalhado com um aviso agregado.

Um resumo durável para a mudança líquida

Cada transação confirmada deveria gerar um único artefato operacional, disponível no ARIN Online e entregue a pelo menos um canal de segurança administrado independentemente do ator.

Campo Evidência produzida
ID e horário de conclusão Identifica a solicitação que realmente foi confirmada
Organização e classe protegida do ator Mostra sob qual capacidade a ação ocorreu sem expor dados pessoais
Combinação de ações Distingue criação, substituição, remoção e mudanças ROA/ASPA associadas
Conjunto antes e depois Expõe a diferença de prefixo, Origin AS e maxLength
Resultado atômico Registra sucesso integral, falha ou ausência de confirmação
Observação de publicação Separa aceite pela ARIN de aparição observada no repositório
Destino independente e entrega Mostra qual canal recebeu o resumo e se a entrega ocorreu
Ligação de correção Conecta reversão ou substituição posterior à mudança original

Não é necessário publicar o nome do operador nem a lista interna de contatos. O conteúdo autorizador do ROA é público; a trilha privada de contas é outro domínio. O resumo pode proteger a identidade pessoal e ainda provar à organização que uma capacidade válida foi exercida.

As preferências continuam úteis. Um POC pode escolher detalhe por objeto; outro, um e-mail por transação; um NOC, um webhook. Mudanças de baixo risco podem ser agrupadas por período. Uma correção urgente não deve depender da concordância de todos os destinatários. Notificar não é autorizar, e confirmar recebimento não concede veto.

O núcleo não negociável é menor: uma opção de conveniência pode retirar cópias redundantes, mas não deve apagar simultaneamente o registro persistente e todos os sinais independentes de uma mudança material.

O que não consta no registro público

Nenhuma fonte citada mostra uma remoção real de 40 mil ROAs, uma credencial comprometida, uma falha de entrega ou uma interrupção de rota. A ACSP 2025.6 ainda aguarda implementação; o fechamento da 2026.6 não comprova implantação. O Change Log está documentado e não foi demonstrado como defeituoso. A ARIN também não determina a política que cada rede aplica a Invalid.

O achado é mais contido. A ARIN já possui a fronteira atômica e grande parte dos campos de auditoria. A notificação empurrada, porém, acompanha a remoção, enquanto as propostas públicas oscilam entre ampliar preferências e extinguir o e-mail em massa. Mudar a unidade do objeto para a transação fecha essa lacuna sem ampliar o mandato da ARIN sobre o roteamento.

Fontes