Introdução

O que é o RPKI

A Internet funciona como um grande sistema de confiança entre redes autônomas (ASNs). Quando uma rede anuncia prefixos IP via BGP, os demais participantes precisam acreditar que ela tem direito legítimo de anunciar esses recursos. Sem mecanismos de validação, erros de configuração ou ataques maliciosos (hijacks) podem provocar indisponibilidade, perda de tráfego e até sequestro de rotas.

O RPKI (Resource Public Key Infrastructure) surgiu justamente para reduzir esses riscos, trazendo criptografia e certificação digital para a camada de roteamento. Ele permite que os detentores de blocos de IP associem seus recursos a certificados emitidos pelos Registros Regionais da Internet (RIRs), como LACNIC, RIPE NCC, ARIN, AFRINIC e APNIC.

Em outras palavras, o RPKI é um sistema que permite a criação e gestão de certificados digitais que atestam que um determinado prefixo de rede pertence, de fato, a um Sistema Autônomo (ASN) específico.

Esses certificados seguem uma hierarquia de delegação (como ilustrado na imagem acima):

• No topo, estão os Registros Regionais da Internet (RIRs), como LACNIC, RIPE NCC, ARIN, entre outros.

• Cada RIR emite certificados para os detentores de blocos de endereços IP (provedores, operadoras, empresas).

• Esses, por sua vez, podem emitir certificados para blocos menores, criando uma “cadeia de confiança” que vai da alocação mais ampla até os prefixos mais específicos.

Dentro dessa lógica, o certificado mais específico prevalece. Isso significa que, se houver sobreposição entre certificados, a versão que aponta para o prefixo mais detalhado é a que será considerada válida e reconhecida na Internet.

Essa estrutura garante que todos saibam, de maneira inequívoca, quem é o legítimo “dono” de um anúncio BGP.

Benefícios da adoção do RPKI

Adotar o RPKI e manter uma boa cobertura de ROAs traz impactos diretos na segurança, confiabilidade e eficiência da sua rede. Entre os principais benefícios estão:

1. Segurança reforçada
   O RPKI é a defesa mais eficaz contra o sequestro de rotas (route hijacking) e contra anúncios inválidos, sejam eles causados por erro humano ou por ataques intencionais. Ao publicar ROAs válidos, você garante que apenas o seu ASN poderá anunciar seus prefixos, protegendo sua rede contra uso indevido.

2. Maior confiabilidade no ecossistema
   Redes que utilizam RPKI transmitem confiança para peers e upstreams. Muitos provedores já priorizam ou exigem que anúncios estejam validados. Isso significa menor risco de rejeição dos seus prefixos, mais estabilidade no roteamento e uma imagem mais profissional diante da comunidade técnica.

3. Compliance com padrões globais
   Cada vez mais IXPs, operadoras e grupos técnicos — como o MANRS (Mutually Agreed Norms for Routing Security) — incentivam ou exigem o uso do RPKI. Estar em conformidade evita barreiras para estabelecer novas conexões, amplia as possibilidades de peering e demonstra compromisso com as boas práticas internacionais.

4. Eficiência operacional
   A validação automática de origem reduz drasticamente incidentes relacionados a anúncios incorretos. Isso significa menos tempo gasto pela equipe de engenharia em troubleshooting e mais recursos disponíveis para evoluir a rede. Além disso, incidentes de segurança no BGP tendem a ser complexos e de alto impacto — preveni-los gera economia significativa.

RPKI x IRR

Muitos operadores já utilizam registros em bases IRR (Internet Routing Registry) para documentar seus prefixos. Embora importantes, os IRRs dependem de confiança manual e podem conter dados desatualizados ou conflitantes. Já o RPKI fornece uma validação criptográfica, impossível de falsificar sem acesso às chaves de certificação. Por isso, diversos IXPs e provedores de trânsito já exigem cobertura RPKI para aceitar sessões de peering ou anúncios BGP.

O que é um ROA

Se o RPKI estabelece a infraestrutura de certificação para comprovar a posse de um prefixo, o ROA (Route Origin Authorization) é o documento que transforma essa posse em uma autorização explícita de anúncio. 

Um ROA é, portanto, uma declaração assinada digitalmente que diz:

• Qual bloco de endereços (IPv4 ou IPv6) está sendo protegido;

• Qual ASN está autorizado a anunciar esse bloco;

• Até qual comprimento de máscara (MaxLength) o anúncio pode ser subdividido.

Na prática, o ROA funciona como uma regra oficial publicada no sistema RPKI que dão clareza e autoridade: eles não apenas confirmam quem é o dono de um recurso, mas também definem exatamente como esse recurso pode ser anunciado.

Classificações

Quando um prefixo é anunciado, os validadores comparam esse anúncio com os ROAs publicados. O resultado sempre se encaixa em uma das três classificações abaixo:

Cobertura

Chamamos de cobertura de ROA o percentual de prefixos de um ASN que estão protegidos por ROAs válidos. Exemplo: se um ASN anuncia 100 prefixos e 80 possuem ROA válido, sua cobertura é de 80%.

Esse indicador é fundamental para medir a maturidade de uma rede em termos de segurança no roteamento. Uma cobertura próxima a 100% significa menor risco de incidentes e maior confiança perante a comunidade global de Internet.

Nos próximos capítulos veremos como configurar o RPKI e, principalmente, como acompanhar a sua cobertura de forma contínua com o apoio do ASN Monitor.

Configuração

Publicar ROAs para seus prefixos é um processo relativamente simples, mas exige alguns cuidados para garantir que os certificados estejam sempre válidos e disponíveis. A seguir, apresentamos um guia de alto nível para a configuração do RPKI em qualquer ASN, com referências específicas ao Registro.br e ao LACNIC, mas aplicável também a outros Registros Regionais da Internet (RIRs).

Métodos

Existem três formas principais de implementar e manter o RPKI para o seu ASN:

1. Configuração manual
   É o caminho que vamos detalhar ao longo deste capítulo. O operador instala e mantém sua própria Autoridade Certificadora (como o Krill), cria os ROAs e acompanha sua publicação. É a forma que oferece maior autonomia, mas também exige mais responsabilidade na manutenção.

2. RPKI como serviço (com suporte da UPX)
   Neste modelo, a UPX realiza a configuração e manutenção técnica do ambiente RPKI em conjunto com sua equipe. Ainda assim, o contato administrativo com o RIR (ex.: Registro.br, LACNIC) continua sendo necessário, pois é a entidade que formaliza a habilitação do RPKI. Trata-se, portanto, de um trabalho colaborativo: você mantém a titularidade, e a UPX cuida da operação contínua.

3. Configuração via ASN Monitor
   Está em estudo a possibilidade de permitir a criação e gestão de ROAs diretamente pelo painel do ASN Monitor, tornando o processo ainda mais simples e integrado. Esse recurso ainda não está disponível, mas caso tenha interesse entre em contato para nos ajudar a priorizar essa funcionalidade.

As instruções abaixo dizem respeito a forma de configuração manual.

Pré-requisitos

Antes de iniciar, é importante garantir:

• Acesso administrativo ao seu ASN e blocos IP no portal do RIR (ex.: Registro.br, LACNIC, RIPE NCC, etc.).

• Escolha de onde hospedar seus certificados e ROAs:

  • Repositório do próprio RIR (mais simples, recomendado para a maioria).

  • Repositório local na sua infraestrutura (exige instalação e manutenção).

• Caso opte por repositório local, será necessário rodar um software de Autoridade Certificadora (CA), como o Krill, e mantê-lo acessível publicamente.

Visão Geral

O processo segue um padrão global, descrito nas RFCs, com o seguinte passo-a-passo:

1. Gerar requisição no seu CA (ex.: Krill)

   1. Esse passo cria um arquivo XML com os dados da sua organização, solicitando ao RIR o vínculo entre os blocos IP e a sua Autoridade Certificadora.

   2. No Registro.br, isso é chamado de Child Request.

2. Registrar o vínculo no portal do RIR

   1. No painel administrativo (ex.: Registro.br), cole o XML gerado e habilite o RPKI para sua organização.

   2. O sistema retorna uma resposta de aprovação (Parent Response) que deve ser importada no seu CA.

3. Publicação dos certificados e ROAs

   1. Caso utilize o repositório do RIR, basta colar também a segunda mensagem XML (Publisher Request) e habilitar a publicação remota.

   2. Se optar por um repositório local, será necessário configurar o Krill para manter seus certificados publicados 24/7.

Passo-a-Passo

Passo 1: Preparação

O primeiro passo é estabelecer a comunicação segura entre a sua Autoridade Certificadora (CA, como o Krill) e o Registro Regional da Internet (ex.: Registro.br). Esse processo segue a RFC 8183 e gera um arquivo XML chamado Child Request, que contém as informações necessárias para que o RIR reconheça sua CA.

Para tal, siga o passo-a-passo de instalação do Krill e quando ele estiver rodando, execute o seguinte comando para criação da mensagem XML.

# Comando para criação do child request

$krillc parents request
  --server https://[ENDERECO-SERVIDOR-KRILL]:3000/
  --token [SENHA]
  --ca [NOME CA]

O resultado desse comando deve ser copiado em algum editor de texto ou gravado em arquivo, pois será necessário nos processos seguintes.

Passo 2: Utilização do repositório do Registro.br (opcional)

Depois de preparar a comunicação com o RIR (Child Request), é necessário decidir onde seus certificados e ROAs serão publicados. Você tem duas opções:

1. Repositório local – hospedado e mantido pela sua própria infraestrutura (maior autonomia, mas também maior responsabilidade de manter disponibilidade 24/7).

2. Repositório do Registro.br – hospedado pelo próprio RIR, que simplifica a operação e garante alta disponibilidade.

Se optar pelo repositório do Registro.br, a sua CA (Krill) precisa gerar um segundo arquivo XML chamado Publisher Request. Esse arquivo informa ao RIR que você deseja usar o repositório dele para armazenar seus certificados e ROAs.

# Comando para criação do publisher request

$krillc repo request
  --server https://[ENDERECO-SERVIDOR-KRILL]:3000/ 
  --token [SENHA]
  --ca [NOME CA]

O resultado será um arquivo XML denominado Publisher Request. Esse arquivo deve ser salvo, pois será usado no próximo passo, dentro do painel do Registro.br.

Passo 3: Configuração no Registro.br

Com os arquivos gerados no Krill (Child Request e, se aplicável, Publisher Request), o próximo passo acontece no portal do Registro.br.

1. Acesse o portal do Registro.br com o usuário administrativo (ID responsável pela titularidade da organização).

2. Vá até TITULARIDADE e selecione o nome da sua organização.

3. No final da página, clique em RPKI – Configurar RPKI.

Dentro dessa tela:

• Cole o arquivo Child Request (gerado no Passo 1).

• Clique em Habilitar RPKI.

• O sistema devolverá um arquivo XML chamado Parent Response, que precisa ser salvo para uso posterior na sua CA.

O sistema retorna o Parent Response (XML). Copiar ou gravar em um arquivo essa mensagem XML para inserção na C.A. da organização em um passo posterior.

Caso tenha realizado o passo 2 para utilizar o repositório do Registro.br, será necessário executar o seguinte passo ainda no sistema do Registro.br:

1. Na mesma página, clique em Configurar Publicação Remota.

2. Cole o Publisher Request (gerado no Passo 2).

3. O sistema devolverá outro arquivo XML, chamado Repository Response, que também precisa ser salvo.

O sistema do Registro.br apresentará um outro XML denominado "Repository Response". Copie ou grave em arquivo esse XML para uso em um passo posterior.

Passo 4: Configuração do CA 

Agora que você já possui os arquivos retornados pelo Registro.br (Parent Response e, se aplicável, Repository Response), é hora de integrá-los ao seu sistema CA (ex.: Krill).

1. Importar o Repository Response

   1. Esse passo só é necessário se você optou pelo repositório do Registro.br (Passo 2).

   2. Ao importar esse arquivo, sua CA passa a publicar automaticamente os certificados e ROAs no repositório do RIR, sem precisar de infraestrutura própria para mantê-los disponíveis.

   3. Se você decidiu usar um repositório local, esse passo pode ser ignorado — mas lembre-se de que nesse caso a disponibilidade pública do repositório é sua responsabilidade.

# Comando para importar o Repository Response (se aplicável)

$krillc repo configure
  --response [ARQUIVO-XML-COM-REPOSITORY-RESPONSE].xml
  --server https://[ENDERECO-SERVIDOR-KRILL]:3000/
  --token [SENHA]
  --ca [NOME CA]

2. Importar o Parent Response

   1. Esse arquivo estabelece formalmente o vínculo entre a sua CA e o Registro.br.

   2. Ao importar o Parent Response, sua Autoridade Certificadora passa a ser reconhecida como legítima para gerenciar os blocos de IP atribuídos à sua organização.

# Comando para importar o Repository Response (se aplicável)

$krillc parents add
  --response [ARQUIVO-XML-COM-PARENT-RESPONSE].xml
  --parent nicbr_ca
  --server https://[ENDERECO-SERVIDOR-KRILL]:3000/
  --token [SENHA]
  --ca [NOME CA]

Após esses dois passos, sua CA já estará integrada ao Registro.br e pronta para criar e publicar ROAs.

Passo 5: Publicação de ROAs

Com a sua Autoridade Certificadora (CA) integrada ao Registro.br, já é possível criar e publicar os ROAs (Route Origin Authorizations). Esses documentos definem quais prefixos podem ser anunciados e por qual ASN.

O processo funciona assim:

1. Defina os parâmetros dos ROAs

   Para cada prefixo que sua rede anuncia, é preciso indicar:

   1. O bloco IP (IPv4 ou IPv6);

   2. O ASN autorizado a anunciar esse bloco;

   3. O comprimento máximo permitido (MaxLength), que define o nível de especificidade dos anúncios válidos.

2. Crie um arquivo de instruções

   O Krill permite preparar um arquivo simples em texto que lista prefixos e ASNs autorizados. Esse arquivo é usado para gerar os ROAs. Exemplo de conteúdo:

A: 201.157.198.0/22-24 => 270631
A: 2001:db8::/32  => 270631

3. Publique os ROAs

   Ao importar esse arquivo na sua CA, os ROAs são gerados e publicados automaticamente (seja no repositório do Registro.br, seja em um repositório local mantido por você).

# Comando para publicação do ROA

$krillc roas update
  --server https://[ENDERECO-SERVIDOR-KRILL]:3000/
  --token [SENHA] 
  --ca [NOME CA] 
  --delta [ARQUIVO-DE-INSTRUCOES].txt

A falha na publicação periódica de qualquer material parte do RPKI impactará a validação das rotas dos blocos dessa organização.

Passo 6: Validação de Rotas

Diversos roteadores já possuem suporte para aplicar políticas de filtros com base na validação RPKI. As validações são realizadas em sistemas externos aos roteadores, e o resultado dessas validações são repassados aos equipamentos através do protocolo RtR (RPKI to Router).

A NLNETLABS possui um validador de uso livre chamado de Routinator. As instruções de configuração podem ser obtidas através do tutorial ou nas documentações. A execução do Routinator se resume ao comando:

$routinator init --accept-arin-rpa

Isso fará com o que o validador percorra as hierarquias de cada um dos "Trust Anchors" e crie um cache com todos os certificados digitais e demais documentos, como ROAs, publicados. O que pode levar um certo tempo

Após a finalização do processo, será possível verificar as informações contidas no cache local e também configurar o RtR para as validações no roteador.

No Routinator, execute o comando:

$routinator server --rtr <IPv4>:<porta> --rtr [<IPv6>]:<porta>

Os endereços IPv4 e IPv6 mencionados são os do roteador no qual se deseja validar rotas via RPKI. Para configuração dos roteadores, recomenda-se verificar o manual específico.

Monitoramento

ASN Monitor

Clientes UPX têm acesso ao recurso ASN Monitor, que permite acompanhar diversas informações do AS em tempo real, incluindo registros de IRR e RPKI de todos os blocos cadastrados na plataforma. Saiba mais sobre o ASN Monitor aqui em: https://upx.com/products/asn-monitor

Se você já é cliente você pode encontrará as opções de monitoramento de RPKI dentro da opção Resources no menu da plataforma de ASN

Nesta tela é possível visualizar informações detalhadas sobre o status de RPKI e IRR dos blocos. Ela apresenta de forma clara a quantidade total de prefixos, o percentual de prefixos com IRR configurado e a quantidade de prefixos com RPKI válido, inválido ou desconhecido.

Com o monitoramento em tempo real da plataforma, você pode habilitar notificações que te informam sobre quaisquer alterações relevantes, como detecções de hijack nos prefixos, falha na validação do RPKI, status do RPKI desconhecido, conteúdo da ROA alterado, ROA expirado, e varias outras.

Para habilitar ou alterar as notificações clique no item “Notification Center”, localizado no canto superior direito:

E navegue até “Event types” para customizar suas notificações:

Com a implementação do RPKI e o uso dos recursos de monitoramento e notificações em tempo real da plataforma, sua organização aumenta significativamente a segurança e a confiabilidade do roteamento BGP. Manter o Krill ativo, publicar ROAs corretamente e acompanhar os alertas no ASN Monitor garante que os anúncios de rotas estejam sempre atualizados, válidos e protegidos contra uso indevido.

Conclusão

A adoção do RPKI representa um marco importante na maturidade de qualquer ASN. Ao publicar ROAs válidos, sua rede passa a ser reconhecida como legítima no ecossistema global da Internet.

Com o ASN Monitor, você acompanha em tempo real sua cobertura, recebe alertas de expiração ou inconsistências e garante que seus anúncios estejam sempre confiáveis. Essa combinação de configuração correta + monitoramento contínuo é a melhor forma de reduzir riscos, atender requisitos de parceiros e reforçar a segurança do roteamento BGP.

FAQ

1. Preciso ter 100% de cobertura de ROA para estar seguro?

   Não necessariamente, mas quanto mais próxima de 100% estiver sua cobertura, menor será a superfície de risco. Prefixos sem ROA permanecem vulneráveis a anúncios indevidos.

2. Qual a diferença entre ROA inválido e prefixo sem ROA?

   • ROA inválido: significa que existe um ROA, mas o anúncio não corresponde ao que foi publicado (erro de configuração ou hijack).

   • Sem ROA (desconhecido): significa que não há proteção alguma para aquele prefixo.

3. O que acontece se meu ROA expirar?

   Um ROA expirado deixa de proteger seu prefixo, que passa a ser tratado como “desconhecido”. Isso pode afetar a aceitação dos seus anúncios por peers e upstreams.

4. Posso ter mais de um ROA para o mesmo prefixo?

   Sim. É comum em cenários de multihoming (quando um prefixo pode ser anunciado por diferentes ASNs autorizados). Porém, é importante revisar cuidadosamente para não criar sobreposição confusa ou inconsistências.

5. Quanto tempo leva para um ROA publicado ser reconhecido globalmente?

   Normalmente, em poucos minutos os validadores globais já atualizam seus caches. No entanto, o tempo pode variar dependendo do ciclo de atualização de cada validador (tipicamente até 1 hora).

6. Preciso de um validador local se já uso o ASN Monitor?

   Sim. O ASN Monitor é uma ferramenta de visibilidade e monitoramento, mas a aplicação de políticas de roteamento nos seus equipamentos depende de um validador local (como o Routinator).

7. A UPX pode cuidar de toda a configuração para mim?

   Atualmente, este documento descreve o caminho manual. No entanto, existe a possibilidade de contratar a UPX para apoio direto na configuração e manutenção, ou até de futuramente realizar essa gestão via ASN Monitor. Entre em contato com nossa equipe para entender as opções disponíveis.