RPKI e ROA no provedor: o passo a passo para validar roteamento

Sequestro de prefixo e route leak não são ameaça teórica: acontecem com frequência na Internet global, às vezes por ataque, mas na maioria das vezes por erro de digitação de quem anunciou um prefixo errado no BGP. O RPKI (Resource Public Key Infrastructure) é hoje uma das defesas mais baratas e efetivas contra isso, e os route servers do IX.br já descartam rotas inválidas. Se você é provedor e ainda não publicou seus ROAs nem ativou validação de origem, está anunciando seu espaço de endereçamento sem assinatura e aceitando rotas que outras redes já descartam. Este guia mostra o caminho completo, na ordem certa, sem derrubar tráfego legítimo.

O que são ROA, RPKI e ROV

• RPKI é a infraestrutura de chaves que liga um recurso de número (prefixo IP, ASN) a um certificado emitido pela autoridade que o alocou. Na nossa região, a âncora de confiança é o LACNIC, e a delegação chega via registro.br para quem tem ASN e bloco próprios.
• ROA (Route Origin Authorization) é o objeto assinado que diz: "o ASN X está autorizado a originar o prefixo Y, até o comprimento máximo Z (maxLength)". É a sua declaração pública e criptograficamente verificável de quem pode anunciar o quê.
• ROV (Route Origin Validation) é o processo no roteador: ele compara cada rota BGP recebida com a base de ROAs e a classifica como Valid, Invalid ou NotFound (sem ROA). A política mais comum é aceitar Valid e NotFound e rejeitar Invalid.

O RPKI valida apenas a origem do anúncio. Ele não verifica o caminho inteiro do AS_PATH — isso é tema de ASPA e BGPsec, ainda em adoção. Mas barrar Invalids já elimina boa parte dos incidentes reais.

Passo 1 — Inventário antes de assinar qualquer coisa

Não publique ROA de memória. Levante a verdade da sua rede primeiro:

• Liste todos os prefixos IPv4 e IPv6 que você realmente origina, incluindo blocos de cliente que você anuncia em nome deles.
• Confirme o ASN de origem correto de cada prefixo. Em cenários de multihoming ou de cliente com ASN próprio, a origem pode não ser a sua.
• Mapeie desagregações legítimas. Se você anuncia um /22 e também /24 mais específicos para traffic engineering, o maxLength precisa cobrir isso.

Um ROA com maxLength errado é a causa número um de self-hijack: você assina o /22 com maxLength /22, mas anuncia /24 mais específicos, e seus próprios anúncios viram Invalid. Documente esse inventário em algo versionado e auditável — é exatamente o tipo de mapa (prefixos, ASNs, blocos por cliente) que mantemos estruturado no NetPulse, no IPAM e no inventário, para o ROA não divergir da realidade da rede.

Passo 2 — Publicar os ROAs no registro.br / LACNIC

Para quem tem recursos diretos do NIC.br, o caminho prático é o RPKI hospedado do registro.br: você não opera a CA, o registro.br guarda a chave e assina por você. No painel de RPKI, para cada prefixo você cria um ROA informando:

• O prefixo (ex.: 203.0.113.0/22).
• O ASN de origem autorizado.
• O maxLength, definindo até qual tamanho de máscara mais específica está autorizado.

Regra de ouro do maxLength: defina-o exatamente igual ao mais específico que você realmente anuncia, nunca o máximo teórico. Assinar um /22 com maxLength /24 "por garantia" abre espaço para um sequestrador anunciar um /24 dentro do seu bloco e ainda passar como Valid. Mínimo necessário, nada além.

Provedores maiores podem optar pela CA delegada (operando o próprio Krill, por exemplo), mas para a maioria o RPKI hospedado é mais seguro operacionalmente — uma chave a menos para você guardar e proteger.

Passo 3 — Esperar propagar e verificar a validade

ROA não é instantâneo. Os repositórios RPKI são consultados periodicamente pelos validadores espalhados pelo mundo; conte com algumas horas até a propagação completa. Antes de tocar em qualquer roteador, verifique de fora:

• Use um validador público ou ferramenta de consulta de ROA para confirmar que cada prefixo seu aparece como Valid com o ASN correto.
• Cheque um looking glass externo para garantir que seus anúncios atuais batem com os ROAs publicados.

Se algum prefixo legítimo seu já aparece como Invalid nessa fase, pare. O problema está no ROA (origem ou maxLength errados), não no roteador. Corrija o ROA primeiro. Ativar ROV com Invalids legítimos pendentes é a receita para tirar seu próprio tráfego do ar.

Passo 4 — Montar a validação (RTR e validador)

O roteador não fala com os repositórios RPKI diretamente. Ele consome uma base já validada via protocolo RTR (RPKI-to-Router), servida por um validador/cache. Opções consolidadas: Routinator (NLnet Labs), rpki-client com um servidor RTR, ou OctoRPKI/StayRTR.

Boas práticas de operação:

• Rode pelo menos dois caches RTR redundantes. Se o cache cai e a sessão RTR some, dependendo da configuração o roteador passa a tratar tudo como NotFound — você perde a proteção silenciosamente.
• Posicione os caches perto dos roteadores de borda, com baixa latência e firewall liberando a porta RTR.
• Monitore o cache: idade do último fetch, número de VRPs carregados e estado da sessão RTR. Cache velho é validação cega.

Passo 5 — Configurar ROV nos roteadores de borda

Configure a sessão RTR e a política conforme o fabricante:

• MikroTik (RouterOS 7): o módulo /routing/rpki aponta para o cache; nos filtros de BGP você testa o estado valid/invalid/unknown e descarta os Invalids.
• Cisco IOS XR / Juniper / Huawei: define-se o servidor RTR e route-policies que casam o estado de validação, rejeitam Invalid e aceitam Valid e NotFound.

A política recomendada para começar: rejeitar Invalid, aceitar Valid e NotFound. Não tente exigir Valid de tudo — a maior parte da Internet ainda é NotFound, e bloquear NotFound desconectaria você de boa parte da rede.

Passo 6 — Rollout em fases (sem derrubar tráfego)

Esta é a parte que separa quem já operou de quem só leu tutorial:

1. Modo observação: ative ROV marcando o estado das rotas em comunidades BGP internas, sem descartar nada. Veja na prática quantos Invalids chegam e de onde.
2. Audite os Invalids: confirme que nenhum Invalid corresponde a tráfego legítimo seu ou de cliente importante. Quase sempre Invalid é erro de ROA de terceiro — mas valide.
3. Enforce gradual: comece descartando Invalid em uma sessão (um upstream ou um peering no IX.br), observe e só então estenda para todas as bordas.
4. Continue monitorando depois de ativo. ROAs de terceiros mudam, e um peer pode publicar um ROA novo que torne uma rota antiga Invalid.

Esse modelo de observar antes de bloquear é o que evita o pior cenário: ROV ligado de uma vez, em produção, descartando uma rota legítima por causa de um maxLength mal configurado lá na ponta.

Publicar ROA e ativar ROV é barato e tem retorno alto, mas o trabalho de verdade está em manter o inventário de prefixos e ASNs sempre em dia, validar antes de virar a chave e fazer o rollout em fases sem susto. A CloudFace atua exatamente aí: consultoria e NOC para desenhar a política de ROV, operar os caches RTR e conduzir o enforce com segurança — e o NetPulse mantém seu IPAM e inventário organizados para o ROA nunca divergir da rede real. Se quiser um diagnóstico inicial do seu roteamento sem compromisso, fale com a gente no WhatsApp.