RPKI e ROV: uma camada concreta de proteção para o BGP
- Assunto
- BGP e RPKI
- Publicado
- Leitura
- 7 min de leitura
O BGP confia em anúncios trocados entre sistemas autônomos, mas essa confiança pode ser fortalecida. A RPKI cria uma base verificável para autorizar origens, e a validação de origem transforma essa informação em política de roteamento.
O que uma ROA realmente autoriza
A RFC 9582 define a Route Origin Authorization, ou ROA, como um objeto assinado que permite verificar se o detentor de um bloco IP autorizou determinado sistema autônomo a originar rotas para um ou mais prefixos. A autorização relaciona recursos de numeração, ASN e os comprimentos de prefixo aceitos.
Isso reduz ambiguidades na origem, mas exige cuidado na publicação. Um ASN incorreto ou um comprimento máximo permissivo demais pode produzir resultados diferentes do esperado. A ROA deve acompanhar o plano real de anúncios e o processo de mudança da rede.
Valid, Invalid e NotFound têm significados diferentes
A validação descrita na RFC 6811 compara o anúncio recebido com os dados validados da RPKI. O resultado é Valid quando existe uma autorização compatível, Invalid quando há cobertura por uma autorização, mas ASN ou comprimento não correspondem, e NotFound quando não existe informação que cubra o prefixo.
NotFound não equivale automaticamente a malicioso. Da mesma forma, a validação de origem não comprova todo o caminho AS_PATH. Ela verifica uma parte importante do problema: se a origem apresentada está autorizada pelo titular do recurso.
- Valid: prefixo, origem e comprimento estão de acordo com uma autorização aplicável.
- Invalid: existe autorização para o espaço, mas o anúncio não corresponde a ela.
- NotFound: não há uma autorização aplicável para classificar aquela origem.
A implantação deve ser progressiva e observável
A prática operacional reunida na RFC 7115 favorece uma adoção prudente. Antes de rejeitar rotas, a equipe precisa inventariar anúncios próprios, publicar ROAs coerentes, operar validadores com atualização confiável e observar como as três classes aparecem na borda.
Depois da fase de observação, a política pode evoluir de marcação e preferência para tratamento mais restritivo de rotas inválidas. Mudanças em anúncios, trânsito, contingência e clientes BGP precisam atualizar a RPKI dentro do mesmo fluxo de aprovação.
Transformar RPKI em rotina é o ganho duradouro
A proteção deixa de ser um projeto isolado quando a validade das ROAs entra no inventário, no monitoramento e na gestão de mudanças. Alertas de expiração, divergências entre prefixos anunciados e autorizados, além da redundância dos validadores, reduzem o risco de uma configuração correta envelhecer silenciosamente.
A RFC 8893 também chama atenção para a validação na exportação: alterações feitas por políticas de saída podem mudar a origem efetiva do anúncio. Por isso, entrada e saída devem ser analisadas como partes do mesmo sistema de roteamento.
Fontes consultadas
Conteúdo editorial da Zenit, elaborado a partir de fontes técnicas oficiais consultadas em 10 de setembro de 2026.
