O BGP clássico aceita qualquer anúncio: se um roteador diz "o prefixo X passa por aqui", os vizinhos acreditam. Sequestros e vazamentos de rota, do erro de digitação à fraude deliberada, nascem dessa confiança. O RPKI (infraestrutura de chaves públicas para recursos de numeração) fecha parte do buraco: o dono de um prefixo publica um ROA, um objeto assinado que declara qual ASN pode originá-lo. Quem valida (ROV, route origin validation) classifica cada anúncio como válido, inválido ou não-encontrado, e descarta os inválidos.
Em 2026 isso deixou de ser assunto de conferência. Os grandes trânsitos internacionais descartam inválidos há anos, os route servers do IX.br fazem o mesmo, e a validação virou critério em edital e em contrato de atacado. A pergunta prática mudou de "devo assinar?" para "o que exatamente acontece comigo se eu não assinar?".
O estado não-encontrado
Prefixo sem ROA fica como não-encontrado, e hoje ainda é aceito pela maioria das redes. O custo aparece na desproteção: qualquer ASN pode originar o seu prefixo, por engano ou não, e a rota falsa disputa em pé de igualdade com a sua. Se o anúncio falso for mais específico, ele ganha. Com ROA assinado e o mundo validando, o anúncio do ASN errado nasce inválido e morre na borda de quem valida.
Há também o efeito comercial silencioso: operadoras e órgãos públicos passaram a checar a higiene de roteamento do fornecedor (o relatório do MANRS e o bgp.tools mostram isso em segundos). Prefixo sem ROA em 2026 sinaliza operação desatualizada, ainda que a rede funcione.
O maxLength errado quebra dos dois lados
O erro mais comum está no maxLength, o campo que define até que tamanho de sub-rede o ROA cobre. Configurado errado, ele causa mais indisponibilidade do que a ausência de ROA:
ROA: 203.0.113.0/22 · origem AS64511 · maxLength /22
anúncio 203.0.113.0/22 pelo AS64511 → válido
anúncio 203.0.113.0/24 pelo AS64511 → INVÁLIDO (excede o maxLength)
anúncio 203.0.113.0/22 pelo AS64500 → inválido (origem errada) ✓ era o objetivo
Quem assina o agregado com maxLength justo e depois anuncia um /24 para engenharia de tráfego derruba a própria rota nas redes que validam. No sentido oposto, maxLength largo demais (/24 para tudo) reabre a porta que o ROA deveria fechar: um atacante que consiga anunciar com o seu ASN no as-path forja um mais específico válido. A regra que funciona é um ROA por anúncio que de fato existe, com maxLength igual ao tamanho anunciado, e nada além.
Antes de assinar, inventarie o que sua rede realmente anuncia, inclusive aqueles /24 antigos de desagregação que todo mundo esqueceu. ROA assinado sobre inventário errado gera indisponibilidade instantânea nas redes que validam.
O caminho curto passa pelo Registro.br
Para ASNs brasileiros com blocos do Registro.br, o modo hospedado resolve sem infraestrutura própria: no painel, seção de números, cria-se o ROA por prefixo em minutos, e a publicação global leva menos de uma hora. Verifique o resultado de fora:
$ whois -h whois.bgpmon.net " --roa 64511 203.0.113.0/22"
0 - Valid
Operações maiores, com múltiplos blocos ou automação de anúncios, podem preferir uma CA delegada (Krill é a implementação usual), que emite ROAs via API sob a árvore do NIC.br. Vale quando existe processo de mudança que justifique automatizar; para a maioria dos ISPs, o hospedado basta.
Validar o que você aceita
Assinar ROA protege os seus prefixos quando eles circulam pelas redes dos outros. Falta proteger os seus clientes das rotas falsas de terceiros, e isso exige validar o que a sua borda aceita: um validador (Routinator ou rpki-client) alimentando os roteadores de borda via RTR, com política de descarte de inválidos. Comece em modo observação, medindo quantos inválidos chegam hoje, e só então ative o descarte.
Um ROA no modo hospedado é trabalho de uma tarde, incluindo o inventário. Se a sua dúvida está justamente no inventário, no que a rede anuncia hoje contra o que deveria anunciar, é por aí que começamos: contato@castelapi.com.br.
