Criação de ROAs: guia prático para provedores

O que é um ROA e o que ele autoriza

ROA é a sigla em inglês para autorização de origem de rota, um registro assinado que liga um prefixo a um ASN e a um tamanho máximo. Ele não muda nada no seu roteador e só publica para o mundo quem tem direito de anunciar o bloco.

Um ROA típico diz que o prefixo 198.51.100.0/22 pode ser anunciado pelo AS 64500 com tamanho máximo /22. Quando outra rede recebe esse prefixo via BGP com outra origem, ou fatiado em /24, ela sabe que o anúncio não foi autorizado pelo titular do bloco.

O ROA é a peça de publicação do RPKI, a infraestrutura de chaves públicas que amarra cada bloco de IP ao seu titular. A implantação de RPKI para provedores começa por ele, porque sem ROA as redes que validam não conseguem separar o seu anúncio de um anúncio falso.

Criar ROA protege os seus blocos, mas não filtra nada

O ROA só produz efeito nas redes que validam as rotas que recebem. Parte das operadoras de trânsito e dos pontos de troca, como o IX.br, já descarta anúncios inválidos [CONFIRMAR política atual do IX.br], e é nelas que o seu ROA passa a contar.

Para a sua própria rede recusar prefixos sequestrados de terceiros, o trabalho é outro e acontece no roteador, com validadores e política de entrada. Esse lado está no guia de validação de origem de rotas, que parte do princípio de que os seus ROAs já existem.

Como funciona a criação de ROAs?

O provedor recebe um certificado de recursos ligado aos blocos que tem e usa esse certificado para assinar cada ROA. Os ROAs ficam num repositório público, de onde os validadores do mundo inteiro os baixam e conferem.

Na prática, a criação de ROAs exige três coisas: acesso de administrador aos recursos de numeração no portal, um ASN já alocado e a lista exata do que a borda anuncia. Sem a lista, o ROA vira palpite, e palpite errado transforma uma rota legítima em inválida.

Modo hospedado ou delegado: qual usar?

No modo hospedado, o certificado e as chaves ficam no sistema do registro, e o provedor só cria e apaga ROAs pela tela. No delegado, o provedor roda a própria autoridade certificadora e o repositório, com mais trabalho.

Para um provedor regional, o hospedado costuma ser a escolha sensata, porque não há servidor a manter nem chave a proteger. O delegado só se justifica para quem tem muitos blocos, várias equipes mexendo neles ou automação própria [CONFIRMAR se o Registro.br oferece o modo delegado].

Inventário dos anúncios antes do primeiro ROA

Antes de criar qualquer ROA, liste tudo o que a sua borda anuncia, com prefixo, tamanho e ASN de origem. Anúncio que fica de fora do inventário corre o risco de virar inválido logo depois da publicação.

O erro mais caro nessa tarefa é publicar uma autorização que não bate com a rede real. Um ROA para o /22 com tamanho máximo 22 torna inválidos os /24 que o provedor anuncia para dividir tráfego entre operadoras, e quem valida passa a descartá-los.

1. Liste os blocos: todos os blocos IPv4 e IPv6 em nome do provedor, inclusive os que ainda não estão em uso.
2. Liste os anúncios: os prefixos que cada roteador de borda anuncia hoje, incluindo os /24 usados para dividir tráfego.
3. Liste quem anuncia: o ASN de origem de cada anúncio, inclusive blocos anunciados por clientes com ASN próprio.
4. Compare: todo anúncio precisa caber num ROA com o ASN certo e o tamanho certo.

show bgp ipv4 unicast regexp ^$
show bgp ipv6 unicast regexp ^$
show bgp ipv4 unicast neighbors 192.0.2.1 advertised-routes

A saída desses comandos em cada roteador de borda, somada aos anúncios feitos por clientes, forma a lista que vai virar ROAs. Confira também o que sai para cada operadora, porque filtros de saída diferentes por sessão às vezes escondem um prefixo que só vai por um link; a configuração de prefix-lists ajuda a deixar esses filtros legíveis.

Blocos cedidos a clientes com ASN próprio

Quando o provedor cede parte do bloco a um cliente corporativo ou a um provedor menor que anuncia com o próprio ASN, o ROA desse pedaço precisa autorizar o ASN do cliente. Se o ROA do agregado tiver tamanho máximo curto e não existir esse segundo ROA, o anúncio do cliente nasce inválido.

Se você também anuncia o mesmo pedaço como reserva, com o seu ASN, crie dois ROAs para o prefixo, um para cada origem. O RPKI aceita várias autorizações para o mesmo bloco, e a rota é válida quando bate com qualquer uma delas.

Qual tamanho máximo usar em cada ROA?

Use o tamanho máximo igual ao prefixo que você realmente anuncia e crie ROAs separados para os mais específicos que vão ao ar. A RFC 9319 recomenda evitar folga nesse campo justamente por segurança.

Folga no tamanho máximo abre espaço para um ataque simples: alguém anuncia um /24 do seu bloco colocando o seu ASN como origem forjada. O ROA aceita, porque ASN e tamanho batem, e o prefixo mais específico vence a disputa de rota em toda a internet.

A terceira linha é a exceção aceitável: se todos os /24 vão ao ar, a folga não deixa nenhum pedaço livre para o atacante. Basta que um /24 saia do ar para a recomendação mudar, e aí o certo é trocar por ROAs individuais.

Quando o AS0 protege e quando atrapalha

Um ROA com origem AS0 diz que ninguém deve anunciar aquele bloco, o que protege faixas guardadas para expansão contra uso indevido enquanto estão paradas.

O problema aparece no dia em que o bloco entra em uso. Crie o ROA com o seu ASN antes do primeiro anúncio e só então apague o AS0, ou o prefixo nasce inválido e é descartado por quem valida, sem nenhum alarme no seu roteador.

Como criar ROA no Registro.br, passo a passo

Com o inventário pronto, o trabalho no portal segue sempre a mesma ordem: ativar o RPKI, criar um ROA por linha da lista e conferir de fora. As telas mudam com o tempo, mas as etapas continuam as mesmas.

Os nomes de menu abaixo descrevem o caminho mais comum e podem mudar entre versões. [CONFIRMAR na versão atual do painel]

1. Entre no Registro.br: faça login com o usuário que administra os recursos de numeração e escolha a entidade titular do bloco. [CONFIRMAR na versão atual do painel]
2. Abra a numeração: no painel da entidade, vá à área de blocos IP e ASN e, dentro dela, à opção de RPKI. [CONFIRMAR na versão atual do painel]
3. Ative o RPKI: na primeira vez, aceite o termo e ative o certificado do provedor no modo hospedado; isso se faz uma vez por entidade.
4. Cadastre cada ROA: informe prefixo, ASN de origem e tamanho máximo, uma linha do inventário por vez, e confirme.
5. Revise a lista: confira na tela de ROAs se prefixo, ASN e tamanho batem com o inventário antes de sair.
6. Espere a publicação: os validadores do mundo leem os ROAs em ciclos de minutos a poucas horas.
7. Confira o estado: consulte um validador público e veja se cada anúncio aparece como válido.

Depois de publicar, a próxima etapa é ligar a validação nos seus roteadores. Para conter ataques volumétricos sem descartar todo o tráfego de um destino, veja também a configuração de FlowSpec.

Exemplo: provedor com um /22 IPv4 e um /32 IPv6

Imagine um provedor com o AS 64500, o bloco 198.51.100.0/22 e o bloco 2001:db8::/32. Ele anuncia o /22, três /24 para dividir tráfego entre duas operadoras e o /32 IPv6, e cedeu o 198.51.103.0/24 a um cliente com o AS 64510.

São seis ROAs para dois blocos, e nenhum deles usa folga no tamanho máximo. Se amanhã o provedor quiser anunciar um /48 IPv6 para um cliente, cria o ROA daquele /48 no mesmo dia em que o anúncio entra.

Erros comuns na criação de ROAs

Quase todos os erros vêm de ROA que não acompanha a rede, seja por anúncio esquecido, folga no tamanho ou mudança sem atualização. O efeito aparece fora da sua rede, por isso costuma demorar a ser notado.

O sintoma típico é o assinante dizer que um site ou um jogo específico não abre, enquanto o resto funciona: as redes que validam descartam a sua rota, e as que não validam seguem normais.

ROA esquecido depois de uma mudança na rede

Troca de ASN, fusão com outro provedor, bloco novo ou cliente que sai levando o ASN dele: cada uma dessas mudanças altera a origem de algum anúncio. A regra é atualizar o ROA antes da mudança entrar no ar, nunca depois.

Para isso funcionar, criar e revisar ROAs precisa constar no procedimento de mudança da borda, junto com filtros e anúncios. A gestão de BGP inclui essa revisão periódica para quem prefere não depender da memória da equipe.

Checklist depois de publicar os ROAs

Confira o resultado em fontes externas, e não só no portal onde os ROAs foram criados. O que importa é como o resto da internet enxerga os seus anúncios.

Se o provedor troca tráfego no IX.br, confira também se os prefixos continuam chegando pelas sessões com os servidores de rotas depois da publicação. O guia de sessões com route servers mostra onde olhar.

A Táquion Tech faz o inventário dos anúncios, cria os ROAs no portal com tamanho justo e confere cada prefixo de fora antes de ativar a validação nas bordas.

Perguntas frequentes sobre criação de ROAs

Thiago Manoel

Responsável técnico da Táquion Tech · Registro profissional [PREENCHER]

Mais de 15 anos em operações de rede, com gestão de infraestruturas de TI, administração de data centers e condução de equipes em migrações de TI e telecomunicações, com foco em alta disponibilidade e segurança.

A Táquion Tech é uma empresa de engenharia de redes de Balneário Camboriú (SC) que projeta, opera e dá suporte a redes de provedores de internet e de empresas.

Conheça a equipe da Táquion Tech