RPKI na América Latina: ultrapassamos 50% de cobertura e o que isso significa para sua rede
Durante anos, RPKI foi aquela tecnologia que todos os operadores de rede sabiam que deveriam implementar mas que sempre ficava relegada para “a próxima janela de manutenção”. O argumento implícito era que se ninguém fazia, não havia urgência em ser o primeiro.
Esse argumento já não se sustenta. No contexto do NANOG 96 e dos dados atuais do LACNIC, confirmamos que a cobertura RPKI global ultrapassou 50% do espaço de endereços IPv4. Na América Latina, a adoção vem acelerando impulsionada pelo LACNIC e pelos grandes operadores regionais. O momento de configurar RPKI na sua rede não é “quando todos fizerem”: é agora, enquanto você ainda tem margem para fazer nos seus próprios termos e não no meio de um incidente.
O que é RPKI e por que importa
RPKI (Resource Public Key Infrastructure) é uma infraestrutura de chave pública especificamente projetada para o sistema de roteamento da internet. Sua função central é simples: permite que o proprietário legítimo de um bloco de endereços IP assine criptograficamente uma declaração que diz “este prefixo só pode ser originado por este número de sistema autônomo (ASN)”.
Essa declaração assinada se chama ROA (Route Origin Authorization). Um ROA tem três campos-chave:
- O prefixo IP (por exemplo, 200.45.0.0/16)
- O ASN autorizado a originar esse prefixo
- O maxLength: a especificidade máxima considerada válida (por exemplo, se o maxLength é /24, o proprietário autoriza que sejam originadas sub-redes de até /24 do bloco, mas não /25 ou mais específicas)
Quando um roteador recebe um anúncio BGP, pode validá-lo contra a base de dados RPKI e determinar se a origem do prefixo está autorizada. Esse processo se chama Route Origin Validation (ROV) e tem três resultados possíveis:
- Valid: existe um ROA que cobre o prefixo e o ASN que o origina está autorizado
- Invalid: existe um ROA para esse prefixo mas o ASN que o origina não é o autorizado (isso é exatamente o que acontece em um hijacking)
- Not Found: não existe nenhum ROA para esse prefixo
Por que o hijacking de BGP continua sendo um problema real
O BGP tem mais de trinta anos como protocolo de roteamento da internet, e sua fraqueza estrutural nunca foi segredo: não tem mecanismo nativo para verificar que quem anuncia um prefixo é o proprietário legítimo. Qualquer roteador BGP pode anunciar qualquer prefixo, e se esse anúncio se propaga, o tráfego é desviado.
Os casos documentados são numerosos e variam em impacto:
Pakistan Telecom (2008): A Pakistan Telecom anunciou por engano o prefixo 208.65.153.0/24 do YouTube. O anúncio se propagou globalmente e o YouTube ficou inacessível por duas horas em grande parte do mundo.
Rostelecom (2020): A operadora russa Rostelecom originou prefixos de mais de 200 redes, incluindo grandes provedores de CDN e serviços financeiros. O incidente durou aproximadamente uma hora antes de ser mitigado.
Hijacking de IPs da Amazon (2018): Tráfego foi redirecionado para o serviço DNS da Amazon (Route 53) para roubar criptomoedas durante um período de duas horas.
Em todos esses casos, RPKI com ROV ativo teria bloqueado automaticamente a propagação das rotas inválidas nos roteadores com validação habilitada. O hijacking continua possível onde não há ROV ativo, e a cobertura de 50% que celebramos hoje significa que ainda há muito espaço de manobra para ataques.
O marco dos 50%: o que mudou e o que continua igual
A cobertura de 50% é um marco importante mas não significa que o problema está resolvido. Para entender o que mudou é preciso separar dois conceitos que às vezes se confundem:
Cobertura RPKI (ter ROAs): um prefixo tem cobertura se existe um ROA que o descreve. Ultrapassar 50% em cobertura de espaço de endereços significa que a maioria dos IPs da internet tem um ROA publicado que define quem pode originá-los.
ROV ativo (validar e filtrar): um roteador tem ROV ativo se, além de poder consultar a base de dados RPKI, toma decisões de roteamento baseadas nessa consulta. Em particular, se descarta rotas marcadas como Invalid.
Ter cobertura sem ROV ativo nos roteadores é como ter câmeras de segurança sem monitoramento: os dados estão disponíveis mas não há consequências para quem descumpre. A proteção real vem da combinação de ambos: ROAs publicados pelos donos dos prefixos, mais ROV ativo nos roteadores dos operadores.
A aceleração da cobertura nos últimos dois anos tem explicação: os grandes operadores de trânsito (Tier 1 e Tier 2 globais) habilitaram ROV ativo, o que cria um incentivo imediato para que seus clientes e peers publiquem ROAs. Se seu prefixo não tem ROA e seu uplink tem ROV ativo, seu tráfego pode ficar marcado como “Not Found” (o que hoje geralmente não se filtra) ou no pior caso alguém pode fazer um hijacking do seu prefixo sem que seja bloqueado.
América Latina e LACNIC: o contexto regional
LACNIC é o Registro Regional de Internet (RIR) para a América Latina e o Caribe. Além de administrar o espaço de endereços da região, o LACNIC opera uma das cinco Trust Anchors RPKI globais: o repositório raiz a partir do qual se encadeiam as assinaturas criptográficas de todos os ROAs da região.
O avanço do RPKI na América Latina tem sido consistente mas desigual:
Os grandes operadores (Claro, Movistar, TIM, NET Virtua, VTR, e outros tier 1 regionais) em sua maioria já têm ROAs publicados para seus blocos principais. A lacuna está nos ISPs médios e pequenos: operadores regionais, ISPs de cidade, provedores de acesso rural, que têm blocos atribuídos há anos mas nunca publicaram ROAs.
Para esse segmento, o processo de publicação de ROAs é mais simples do que parece.
Como publicar ROAs no portal do LACNIC
O processo tem dois passos: autenticar-se no sistema de gestão do LACNIC (WHOIS do LACNIC / portal de gestão de recursos) e criar os ROAs para os blocos que você administra.
Passo 1: Acessar o portal
O LACNIC oferece o sistema RPKI através de seu portal de gestão de recursos em lacnic.net. As organizações com recursos atribuídos diretamente pelo LACNIC têm acesso ao painel de RPKI a partir da mesma conta com que gerenciam suas atribuições. As organizações que receberam recursos através de um LIR (Local Internet Registry) devem contatar o LIR para gerenciar seus ROAs, ou podem solicitar acesso direto conforme o caso.
Passo 2: Criar um ROA
A interface permite criar ROAs especificando:
Prefixo: 200.45.0.0/16
ASN de origem: 65001
maxLength: /24
Período: 1 ano (renovável)
O maxLength é o campo que mais frequentemente é configurado de forma errada. Se você tem o bloco 200.45.0.0/16 e quer anunciar sub-prefixos mais específicos (por exemplo, 200.45.1.0/24 para um cliente), o maxLength deve ser /24. Se deixar em /16, os anúncios mais específicos aparecerão como Invalid nos roteadores com ROV ativo.
Recomendação de maxLength:
Não use maxLength excessivamente permissivo. Se sua política é anunciar até /24, coloque /24. Não coloque /32 “por precaução” porque isso anula boa parte da proteção: qualquer sub-prefixo até /32 ficaria marcado como Valid mesmo que esteja sendo anunciado por outro ASN, desde que use o mesmo bloco pai.
Passo 3: Verificar a publicação
A propagação de um ROA recém-criado na hierarquia RPKI leva entre alguns minutos e poucas horas. Para verificar que seu ROA está disponível você pode usar ferramentas online como o RPKI Validator do RIPE NCC ou o portal de validação do LACNIC, ou pela linha de comandos:
# Consultar o estado RPKI de um prefixo usando routinator
routinator validate --prefix 200.45.0.0/16 --asn 65001
# Alternativa com rpki-client (em sistemas BSD/Linux)
rpki-client -v
# Depois consultar a base local gerada
Habilitar ROV nos seus roteadores: guia por vendor
Publicar ROAs protege seus prefixos de que outros os anunciem sem autorização. Mas para que sua rede também rejeite hijackings de prefixos de terceiros, você precisa habilitar Route Origin Validation (ROV) nos seus roteadores de borda.
O processo tem duas partes: configurar um RPKI Cache Server (também chamado RTR server) que baixa e valida a base de dados RPKI, e depois conectar seus roteadores a esse cache para obter os dados de validação.
RPKI Cache Server: Routinator
A opção mais comum para operadores de rede na América Latina é o Routinator, um validador RPKI open source desenvolvido pelo NLnet Labs:
# Instalação em Ubuntu/Debian
apt install routinator
# Inicialização (aceita os TALs dos 5 RIRs)
routinator init --accept-arin-rpa
# Iniciar o serviço
systemctl enable routinator
systemctl start routinator
# Verificar que está servindo em RTR (porta 3323 por padrão) e HTTP (8323)
routinator server --rtr 0.0.0.0:3323 --http 0.0.0.0:8323
O Routinator baixa os repositórios RPKI dos cinco RIRs (LACNIC, ARIN, RIPE NCC, APNIC, AFRINIC), valida as cadeias de certificados, e serve a base de dados validada para os roteadores via protocolo RTR (RPKI-to-Router, RFC 8210).
Para produção, instale o Routinator em uma VM dedicada com acesso à internet (para baixar os repositórios) e com acesso a partir dos seus roteadores de borda na porta RTR (3323 por padrão).
Configuração no Huawei VRP
# Configurar o peer RTR (Routinator)
rpki
session 10.0.0.100 65535
tcp port 3323
connect-retry-interval 30
#
# Habilitar validação de rotas BGP
bgp 65001
ipv4-family unicast
bestroute routerid-prior rpki
rpki route-valid-import
rpki route-invalid accept # ou drop conforme sua política
#
# Verificar o estado do cache RTR
display rpki session all
display rpki routing-table
A política de o que fazer com as rotas Invalid é a decisão mais importante:
rpki route-invalid drop: descarta as rotas Invalid. Proteção máxima, mas se alguém publicar um ROA incorreto para seu próprio prefixo, as rotas legítimas dessa rede ficam bloqueadas no seu roteador.rpki route-invalid accept: aceita as rotas Invalid mas as marca com uma community. Permite monitorar sem impacto imediato.
Para operadores que estão começando com RPKI, a estratégia recomendada é iniciar com accept e monitorar durante 30-60 dias, depois migrar para drop quando tiver confiança de que o estado dos ROAs na região é suficientemente correto.
Configuração no MikroTik RouterOS 7.x
# Adicionar o servidor RTR
/routing rpki
add address=10.0.0.100 port=3323 name=routinator
# Verificar o estado
/routing rpki print
/ip route print where rpki-valid=yes
/ip route print where rpki-invalid=yes
# Configurar política de filtragem BGP
/routing filter rule
add chain=bgp-in comment="Drop RPKI Invalid" action=discard \
rpki-valid=no
O RouterOS 7.x suporta RPKI nativo desde a versão 7.1. Em versões anteriores (6.x), não há suporte nativo e seriam necessárias soluções externas.
Configuração no Cisco IOS-XR
! Configurar o servidor RTR
router bgp 65001
rpki server 10.0.0.100
transport tcp port 3323
refresh-time 300
!
!
! Habilitar validação na família de endereços
router bgp 65001
address-family ipv4 unicast
bgp bestpath origin-as allow invalid
bgp origin-as validation signal ibgp
!
!
! Verificar
show bgp rpki summary
show bgp rpki table
show bgp ipv4 unicast 200.45.0.0/16
Política de filtragem: o debate Valid-only vs. Invalid-drop
Uma pergunta frequente ao implementar RPKI: deve-se rejeitar todas as rotas Invalid, ou só as que vêm de prefixos com cobertura RPKI?
A resposta depende do nível de maturidade do ecossistema RPKI nos peers e trânsitos que você recebe. Com cobertura global de 50%, existe uma fração não trivial de operadores que têm ROAs publicados com erros (maxLength incorreto, ASN errado no ROA, ROA expirado). Se adotar uma política de Invalid-drop agressiva, pode acabar bloqueando rotas legítimas de redes com ROAs mal configurados.
A recomendação operacional atual para a maioria dos ISPs na LATAM é a seguinte:
- Etapa 1 (primeiras 4-8 semanas): Habilitar ROV com política de accept para Invalid. Monitorar o volume de rotas Invalid que chegam à sua rede e de quais peers.
- Etapa 2: Revisar as rotas Invalid recorrentes. Em muitos casos são ROAs mal configurados de peers com quem você pode entrar em contato para corrigir.
- Etapa 3: Migrar para Invalid-drop quando o ruído de falsos positivos for baixo e você tiver confiança nos dados.
Para o tráfego vindo de upstreams de trânsito, os grandes carriers já aplicam suas próprias políticas de ROV. O mais impactante que você pode fazer hoje como ISP de médio porte é publicar ROAs corretos para todos os seus blocos atribuídos e habilitar ROV nos seus roteadores de borda com política conservadora.
O que os 50% globais significam para quem ainda não fez
A cobertura de 50% cria um cenário de incentivos que piora para os retardatários:
Maior probabilidade de hijacking direcionado: Prefixos sem ROA são o alvo natural de qualquer ator que queira fazer route hijacking, porque são os que não podem ser bloqueados automaticamente. À medida que mais prefixos têm ROA, os sem ROA se destacam como alvos.
Pressão dos upstreams: Os operadores Tier 1 que habilitaram ROV ativo podem aplicar políticas mais rígidas com o tempo. Hoje a maioria aceita rotas Not Found. No futuro, alguns podem optar por marcá-las ou filtrá-las.
Reputação operacional: Na comunidade de operadores de rede (NANOG, LACNOG, fóruns do LACNIC), o status RPKI de um operador é cada vez mais visível. Os pares de peering verificam se seus blocos têm ROAs antes de aceitar ou priorizar acordos.
Nossa experiência com ISPs na LATAM
Na Ayuda.LA acompanhamos ISPs da América Latina na implementação de RPKI como parte de projetos mais amplos de segurança BGP e hardening de infraestrutura. O padrão mais frequente que encontramos é o de operadores que têm blocos atribuídos há anos (às vezes com numeração fragmentada de diferentes atribuições) e que nunca publicaram ROAs porque “não era urgente”.
O processo de auditar os blocos próprios, mapear os ASNs que os originam legitimamente, e publicar os ROAs corretos geralmente leva entre um e três dias de trabalho. Não é um projeto longo. O maior esforço costuma estar em documentar o estado real dos blocos (o que é anunciado, de qual ASN, com que granularidade) quando essa documentação não existe ou está desatualizada.
Conheça mais sobre nossos serviços de segurança e hardening de rede para ISPs.
Quer revisar o estado RPKI da sua rede?
Podemos auditar o estado atual dos seus blocos atribuídos, identificar os ROAs faltantes ou incorretos, e acompanhar você na configuração de ROV nos seus roteadores de borda.
Vamos conversar sobre sua rede →
Tem perguntas sobre RPKI, BGP ou segurança de roteamento? Escreva para [email protected] — respondemos todas as mensagens.