Introdução ao RPKI
A sigla RPKI significa Resource Public Key Infrastructure (em português Infraestrutura de Chaves Públicas para Recursos de Numeração da Internet). Assim como o nome é grande, o problema que ele tenta resolver também é gigantesco. Sendo bem direto, o RPKI permite que o proprietário de um bloco IPv4, IPv6 ou ASN publique uma prova verificável de que aqueles recursos realmente pertencem a ele. Primeiro temos que entender o problema que o RPKI nasceu para resolver, para isso, temos que voltar ao BGP, que já foi falado aqui, mas farei uma breve introdução dele aqui.
Esta seção não será voltada apenas para ambientes de rede, protocolos e sistemas operacionais de roteadores/switches, mas também abordará serviços e aplicações utilizadas no ecossistema RPKI, como o Krill e o Routinator que devem ser instalados em servidores Linux.
O BGP foi criado para que diferentes redes da Internet consigam conversar entre si. Basicamente, um provedor anuncia para os outros quais redes ele consegue alcançar e por qual caminho aquele tráfego deve passar. O problema que eu quero abordar é que o BGP nasceu em uma época onde existia muito mais confiança entre as redes. Então, ele não verifica se quem está anunciando um bloco IP realmente é o dono dele.
Isso significa que, se alguém anunciar um prefixo que não pertence a ele, o restante da Internet pode aceitar aquele anúncio mesmo assim. É exatamente esse tipo de problema que o RPKI tenta resolver. A documentação da NLnet Labs descreve o RPKI como um sistema que permite que os donos de blocos IP e ASNs publiquem informações verificáveis sobre como aqueles recursos podem ser usados. Isso funciona através de uma cadeia de certificados digitais, ou seja, a confiança começa nos registros regionais (RIRs), como o LACNIC, e vai sendo delegada até chegar ao verdadeiro dono do recurso.
Na prática, o uso mais comum do RPKI hoje é validar se um AS realmente tem permissão para anunciar determinado bloco IP na Internet. Esse processo é chamado de Route Origin Validation (ROV). Quando um roteador BGP recebe um anúncio, ele pode consultar as informações publicadas no RPKI para verificar se existe uma autorização válida dizendo que o ASN que fez o anúncio realmente pode anunciar esse prefixo.
Se existir uma autorização válida, a rota pode ser marcada como válida. Se o RPKI disser que outro ASN deveria anunciar aquele prefixo, a rota pode ser marcada como inválida. E se não existir nenhuma informação no RPKI sobre aquele prefixo, a rota normalmente fica como not found. Portanto, o ROV apenas valida a origem da rota, tentando responder uma pergunta simples: Esse ASN realmente pode anunciar esse prefixo?.
Para deixar a explicação mais visual e fácil de entender, imagine o seguinte anúncio BGP:
Prefixo anunciado: 2001:db8::/32
ASN de origem: AS65538
AS-PATH: 65537 65538
Sem RPKI, um roteador BGP pode aplicar filtros, políticas, IRR, prefix-lists e regras locais, mas o protocolo em si não tem uma prova criptográfica de que o AS65538 pode mesmo publicar o prefixo 2001:db8::/32.
Com RPKI, o dono do prefixo publica um objeto assinado chamado ROA (Route Origin Authorization), dizendo algo como:
O prefixo 2001:db8::/32 pode ser originado pelo AS65538.
O validador RPKI baixa o objeto (ROA), verifica sua assinatura criptográfica e transforma essa informação em um VRP (Validated ROA Payload). Depois disso, o roteador consulta esse conjunto de VRPs através do protocolo RPKI-to-Router (RTR) e classifica a rota como Valid, Invalid ou NotFound.
O validador RPKI é o componente responsável por baixar, verificar e processar todas as informações publicadas na infraestrutura RPKI da Internet. Ele coleta objetos como certificados e ROAs, valida assinaturas criptográficas, verifica a cadeia de confiança dos RIRs e transforma essas informações em dados utilizáveis pelos roteadores, chamados de VRPs (Validated ROA Payloads).
Os validadores são softwares como:
- Routinator da NLnet Labs;
- rpki-client da OpenBSD Project;
- Fort do NIC México;
- OctoRPKI da Cloudflare.
Inicialmente, foque e entenda que o ROA é publicado pelo dono do recurso, como dono do ANS/IP. O validador apenas verifica criptograficamente o material publicado (ROA, Certificados, manifests e CRLs). O roteador usa o resultado do Validador para tomar decisões BGP.
Eu não costumo fazer esse tipo de coisas (acho que só fiz na de IPv6), mas queria deixar alguns exercícios ao longo dessa documentação para ir reforçando o aprendizado.
Para este exercício, você deve analisar três rotas BGP reais, identificando o prefixo anunciado, o ASN de origem e o AS-PATH. Depois, verifique se o ASN que originou cada rota possui um ROA válido para aquele prefixo.
Para obter esses anúncios você pode pegar da sua rede ou de um looking glass. Para padronizar o exercício, vou usar o Looking Glass da Hurricane Eletric. Depois de acessar, basta ir em terminal e digitar: show ip bgp summary. O resultado será algo parecido com a saída abaixo:
Neighbor IP AS# State Time ipv4 ipv6 Collector
------------------------------------ ---------- ------ ---------- ---------- ---------- ----------------------------
196.60.8.6 49544 UP 37w06d23h 1052229 0 route-views.napafrica
186.67.248.40 27986 UP 20w01d09h 1049587 0 route-views.chile
187.16.221.99 16509 UP 20w06d03h 873 0 route-views2.saopaulo
Tentei pegar endereços bem diferentes e com resultados distintos no Validador. Agora digite show ip bgp <Neighbor IP> (sempre colocando o IP), assim podemos ver os prefixos publicados e quem publicou, lembrando que o ASN de origem é o último ASN do AS-PATH.
$ show ip bgp 196.60.8.6
196.60.8.0/22 196.60.10.28 0 100 - 37105 36994 ? (route-views.napafrica)
$ show ip bgp 186.67.248.40
186.67.248.0/24 5.57.81.76 20 100 ✔ 36924 6762 27986 i (rrc01.ripe.net)
$ show ip bgp 187.16.221.99
187.16.208.0/20 45.168.64.18 0 100 ✖ 268138 264170 i (collector7.bgp.he.net)
187.16.208.0/20 45.181.104.1 0 100 ✖ 269180 263661 ? (route-views5)
187.16.208.0/20 170.245.8.0 0 100 ✖ 266519 262847 i (collector11.bgp.he.net)
187.16.208.0/20 191.7.136.255 0 100 ✖ 263321 265390 i (collector15.bgp.he.net)
187.16.208.0/20 138.59.226.1 0 100 ✖ 270052 61512 270735 i (collector9.bgp.he.net)
187.16.208.0/20 167.250.72.28 0 100 ✖ 265197 262503 270735 i (collector12.bgp.he.net)
Resultado para o prefixo 196.60.8.0/22
Como podemos ver no comando show ip bgp 196.60.8.6, o ASN de origem é o 36994. Agora vamos verificar usando o Validador do RIPE se ele pode anunciar o prefixo 196.60.8.0/22:
$ curl -ks 'https://rpki-validator.ripe.net/api/v1/validity/36994/196.60.8.0/22'
{
"validated_route": {
"route": {
"origin_asn": "AS36994",
"prefix": "196.60.8.0/22"
},
"validity": {
"state": "not-found",
"description": "No VRP Covers the Route Prefix",
"VRPs": {
"matched": [
],
"unmatched_as": [
],
"unmatched_length": [
]
}
}
},
"generatedTime": "2026-05-08T00:42:48Z"
}
Como podemos ver, o resultado é not-found, visível na linha "state": "not-found",. Isso significa que nenhum ROA foi emitido, então o validador não consegue informar, por isso a informação de not-found (não encontrado).
Resultado para o prefixo 186.67.248.0/24
Como já podemos ver no comando show ip bgp 186.67.248.40, o ASN de origem é o 27986. Agora vamos verificar usando o Validador do RIPE se ele pode anunciar o prefixo 186.67.248.0/24:
$ curl -ks 'https://rpki-validator.ripe.net/api/v1/validity/27986/186.67.248.0/24'
{
"validated_route": {
"route": {
"origin_asn": "AS27986",
"prefix": "186.67.248.0/24"
},
"validity": {
"state": "valid",
"description": "At least one VRP Matches the Route Prefix",
"VRPs": {
"matched": [
{
"asn": "AS27986",
"prefix": "186.67.248.0/24",
"max_length": "24"
}
],
"unmatched_as": [
{
"asn": "AS6471",
"prefix": "186.67.0.0/16",
"max_length": "24"
},
{
"asn": "AS27651",
"prefix": "186.67.0.0/16",
"max_length": "24"
}
],
"unmatched_length": [
]
}
}
},
"generatedTime": "2026-05-08T00:56:50Z"
}
Como podemos ver, o resultado é valid, visível na linha "state": "valid",. Isso significa que existe um ROA autorizando o AS27986 a anunciar o prefixo 186.67.248.0/24, por isso o validador classificou a rota como válida.
Resultado para o prefixo 187.16.208.0/20
Como podemos ver no comando show ip bgp 187.16.221.99, um dos ASN de origem encontrados foi o 270735 (esse aparece duas vezes). Agora vamos verificar usando o Validador do RIPE se ele pode anunciar o prefixo 187.16.208.0/20:
$ curl -ks 'https://rpki-validator.ripe.net/api/v1/validity/270735/187.16.208.0/20'
{
"validated_route": {
"route": {
"origin_asn": "AS270735",
"prefix": "187.16.208.0/20"
},
"validity": {
"state": "invalid",
"reason": "as",
"description": "At least one VRP Covers the Route Prefix, but no VRP ASN matches the route origin ASN",
"VRPs": {
"matched": [
],
"unmatched_as": [
{
"asn": "AS0",
"prefix": "187.16.192.0/19",
"max_length": "32"
}
],
"unmatched_length": [
]
}
}
},
"generatedTime": "2026-05-08T00:58:50Z"
}
Como podemos ver, o resultado é invalid, visível na linha "state": "invalid",. Isso significa que existe um ROA cobrindo esse prefixo, mas o ASN 270735 não está autorizado a anunciá-lo.
O caso fica ainda mais curioso por causa desta linha:
"asn": "AS0"
O AS0 é um ASN especial usado no RPKI para indicar que um prefixo não deve ser anunciado na Internet. Quando alguém publica um ROA apontando o bloco 187.16.192.0/19 para AS0, está basicamente dizendo: "esse prefixo não deve aparecer no BGP".
Como o AS0 não é utilizado para originar rotas reais, qualquer ASN que tentar anunciar esse bloco acabará sendo marcado como Invalid, desde que o anúncio esteja dentro do prefixo e do maxLength definidos no ROA.
Isso pode acontecer por alguns motivos, como quando o prefixo realmente não deveria estar sendo anunciado na tabela BGP global. Nesse caso, o dono do recurso pode publicar um ROA com AS0 para declarar que nenhum ASN real está autorizado a originar aquele bloco. Isso é usado para endereços IP reservados, não utilizados, retirados de operação ou prefixos que devem permanecer fora da tabela global.
Como
AS0não é usado como ASN de origem em anúncios BGP reais, qualquer anúncio coberto por esse ROA, vindo de outro ASN, será classificado comoInvalidpor redes que fazem validação RPKI/ROV.
Também existem casos em que o ROA foi configurado errado ou ficou desatualizado. Por exemplo, o bloco mudou de ASN, houve migração de provedor, trocaram o ASN de origem, esqueceram de atualizar o ROA, ou alguém publicou um ROA AS0 sem perceber que o prefixo ainda estava em produção. Nesses casos, uma rota operacionalmente legítima pode acabar ficando Invalid.
O caso do AS0 é interessante porque ele funciona como uma declaração explícita de que aquele prefixo não deve ser originado por nenhum ASN na Internet. Tecnicamente, o validador não tem como saber a intenção do operador ao publicar um ROA, ele apenas compara o anúncio BGP com os VRPs derivados dos ROAs. Se existe um ROA AS0 cobrindo o prefixo e aparece um anúncio originado por um ASN real, o resultado será inconsistente com a autorização publicada e a rota será marcada como Invalid.
Contextualizando
Como eu mancionei mais acima, o BGP funciona na base da confiança, se um AS anuncia por engano um prefixo que não deveria, outros AS podem aceitar. Se alguém anunciar de propósito um prefixo que não tenha autoridade sobre ele, os AS podem acabar aceitando. Essa prática tem um nome, ela é conhecida como hijacks.
Uma das formas de reduzir esse problema sem o usar o RPKI é através de filtros e políticas de roteamento aplicadas entre ASNs, como filtros de prefixos, IRR filtering e uso de communities para controle de propagação de rotas. O hijacking nem sempre é um sequestro intencional de tráfego, onde alguém anuncia um prefixo que não lhe pertence para receber o tráfego destinado àquela rede. Na maioria dos casos, ele ocorre por erro operacional, configurações incorretas ou falhas na aplicação de filtros e políticas de roteamento.
Antes do RPKI, a tecnologia mais usada para evitar hijacking era o IRR (Internet Routing Registry). Ele é usado para publicar informações de roteamento através de objetos como route e route6, associando prefixos aos ASNs autorizados a originar eles. Essas informações eram muito usadas para criar filtros e aplicar políticas BGP com o intuito de ajudar a evitar anúncios incorretos e a propagação indevida de rotas.
O IRR ainda continua sendo usado, mas ele possui algumas limitações. A qualidade das informações nem sempre se mantém os registries, existem objetos antigos e/ou desatualizados. Tradicionalmente ele não faz uma validação criptográfica forte baseada na cadeia de delegação dos recursos da Internet. Por causa desses problemas, confiar apenas nos dados publicados no IRR pode não ser suficiente para garantir que um ASN realmente esteja autorizado a originar determinado prefixo.
O RPKI nasceu justamente para resolver parte desses problemas, utilizando uma infraestrutura criptográfica baseada na hierarquia de alocação de prefixos IP e ASNs feita pelos RIRs. Isso permite que o detentor legítimo do recurso publique autorizações de origem de rota de forma que seja verificável através de ROAs.
A IANA delega blocos de endereços IP e ASNs para os RIRs, como LACNIC, ARIN, RIPE NCC, APNIC e AFRINIC (explicado em outras documentações aqui na seção de Redes). Em alguns países também existem NIRs (como o NIC.br aqui no Brasil), que atuam em conjunto com os RIRs na distribuição e administração desses recursos. O RPKI aproveita a existência dessa hierarquia de delegação para criar uma cadeia de confiança baseada em certificados digitais. Dessa forma, cada entidade consegue comprovar criptograficamente que recebeu determinados recursos IP e ASNs de uma autoridade superior, seguindo a mesma estrutura de distribuição usada pela Internet.
Isso significa que cada RIR precisa operar sua própria Trust Anchor, que funciona como o ponto inicial de confiança para validação das informações publicadas no RPKI. A partir dessa âncora de confiança, os validadores conseguem verificar a cadeia de certificados e confirmar se determinado recurso IP ou ASN foi realmente delegado dentro da hierarquia oficial de distribuição da Internet. Vamos entrar em detalhes sobre isso mais adiante.
Funcionamento interno
Internamente, o RPKI funciona de forma parecida com uma PKI (Public Key Infrastructure) tradicional, usando certificados digitais e uma cadeia de confiança. A principal diferença é que esses certificados não servem apenas para identificar uma entidade. No RPKI, os certificados carregam recursos de numeração da Internet, como prefixos IPv4, IPv6 e ASNs.
Isso permite que uma entidade consiga provar criptograficamente que recebeu autorização para utilizar determinados recursos dentro da hierarquia oficial de distribuição da Internet. Esses certificados são conhecidos como Resource Certificates e fazem parte da base do funcionamento do RPKI.
O LACNIC possui uma CA raiz e uma Trust Anchor própria. Essa Trust Anchor é o ponto inicial de confiança usado pelos validadores de recursos da região do LACNIC. A partir dela, cria-se uma cadeia de certificação RPKI. O fato de o LACNIC possuir sua própria Trust Anchor não significa que apenas redes da América Latina consigam confiar no LACNIC. Os validadores RPKI normalmente já vêm configurados para confiar nas Trust Anchors de todos os RIRs, como LACNIC, ARIN, RIPE NCC, APNIC e AFRINIC.
Essa confiança é estabelecida através dos TALs (Trust Anchor Locators), que veremos mais adiante.
Como o NIC.br atua como NIR aqui no Brasil, ele aparece abaixo do LACNIC nessa hierarquia, recebendo autoridade sobre determinados recursos de numeração. Para as organizações brasileiras que possuem recursos distribuídos pelo NIC.br, a autoridade operacional imediata na cadeia pode ser o NIC.br, e não diretamente o LACNIC. Dessa forma, os certificados e ROAs dessas organizações podem ser emitidos/publicados dentro de uma cadeia em que o NIC.br está entre o LACNIC e o detentor final do recurso.
A cadeia fica parecida com o exemplo abaixo:
O validador RPKI sempre começa a validação a partir de uma Trust Anchor. No caso dos recursos da região do LACNIC, essa Trust Anchor é a do próprio LACNIC, porque cada RIR mantém sua própria CA raiz e sua própria cadeia de confiança. Para o validador saber onde está essa CA-raiz e qual chave pública deve esperar, ele usa um arquivo chamado TAL Trust Anchor Locator.
O TAL contém uma ou mais URIs apontando para o certificado da Trust Anchor e também contém a chave pública esperada. Isso impede que o validador simplesmente baixe qualquer certificado da Internet e aceite como raiz válida. Ele só aceita aquela Trust Anchor se o certificado encontrado corresponder à chave pública indicada no TAL.
A partir da Trust Anchor do LACNIC, o validador percorre a cadeia de certificados. Como o NIC.br atua como NIR dentro da região do LACNIC, ele pode aparecer abaixo do LACNIC na hierarquia RPKI, isso significa que o NIC.br participa da cadeia como uma autoridade subordinada (ele recebe autoridade sobre determinados recursos) e pode atuar como parent para organizações brasileiras, ou seja, o NIC.br pode tanto emitir certificados de recursos para CAs filhas de LIRs, ISPs ou outras organizações brasileiras (no modelo de RPKI delegado), quanto assinar e publicar diretamente os objetos RPKI dessas organizações, como ROAs (quando uma organização não quer operar no modo delegado).
Nós como usuários e administradores de sistemas e redes não precisamos baixar manualmente os TALs dos RIRs para começar a validar RPKI. Os validadores como o Routinator, já vêm com os TALs dos cinco RIRs compilados no software. Isso significa que o validador já sabe quais Trust Anchors pode usar em produção, como LACNIC, ARIN, RIPE NCC, APNIC e AFRINIC.
Mas podemos escolher quais Trust Anchors habilitar ou desabilitar, adicionar TALs de teste ou incluir TALs próprios, mas o conjunto principal dos RIRs já vem embutido no software.
Como visto acima, o validador começa pela Trust Anchor do LACNIC e segue o caminho de validação dos certificados até chegar aos ROAs publicados pela organização. Enquanto ele está percorrendo o caminho de validação ele precisa baixar os arquivos RPKI publicados pelas autoridades. Esses arquivos ficam em repositórios públicos e podem ser acessados por dois métodos: RRDP (que usa HTTPS) e rsync (que é um método mais antigo mas ainda mantido por compatibilidade).
Depois de baixar esses arquivos (conhecidos como objetos), o validador verifica se os certificados são válidos, se as assinaturas digitais conferem, se os objetos ainda estão dentro do prazo de validade, se os arquivos esperados aparecem no manifest e se algum certificado foi revogado na CRL. O manifest é uma lista assinada dos arquivos que deveriam estar publicados em um determinado diretório do repositório RPKI daquela CA. Ele ajuda o validador a perceber se algum arquivo esperado está faltando, se existe arquivo faltando ou se a publicação está inconsistente.
A CRL é a lista de certificados revogados, ela informa quais certificados não devem mais ser aceitos, mesmo que ainda estejam dentro do prazo de validade. O validador também verifica se os objetos não estão stale, ou seja, vencidos em relação ao próximo horário esperado de atualização. Quando isso acontece, pode ser sinal de falha operacional no repositório ou de tentativa de reutilizar informação antiga.
Com exemplo, imagine o repositório RPKI da CA do ISP X:
ca.cer
prefixo.roa
manifest.mft
revogacoes.crl
Nesse exemplo, ca.cer seria o certificado da CA do ISP X, prefixo.roa seria o ROA publicado por essa CA, manifest.mft seria o manifest dizendo quais arquivos deveriam existir nesse local de publicação, e revogacoes.crl seria a lista de certificados revogados.
Quando o validador encontra um ROA válido, ele extrai as informações relevantes desse ROA e gera um VRP (Validated ROA Payload). O VRP é a forma simplificada e já validada da autorização de origem. Em vez de entregar o ROA completo ao roteador, o validador entrega algo muito mais direto, o VRP.
Prefixo: 203.0.113.0/24
ASN: AS64512
MaxLength: /24
Trust Anchor: LACNIC
Esse VRP significa que anúncios do prefixo 203.0.113.0/24, originados pelo AS64512, são autorizados até o tamanho máximo /24. Portanto, um anúncio BGP de 203.0.113.0/24 com origem no AS64512 será considerado Valid. Já um anúncio desse mesmo prefixo originado por outro ASN será Invalid, e um anúncio mais específico, como 203.0.113.0/25, também será Invalid, porque ultrapassa o MaxLength /24.
O roteador sempre recebe uma base simples de VRPs via RTR, isso simplifica o processo e melhora a performance das análises que serão feitas pelo roteador, dessa forma ele não precisa consultar o validador a cada rota BGP recebida. O funcionamento normal é o roteador manter uma cópia local da base de VRPs que recebeu do validador via RTR.
Componentes principais do RPKI
Deixe esse tópico para falar exclusivamente dos principais componentes envolvido no RPKI. A ideia é rever alguns conceitos que já vimos anteriormente e ver alguns outros. É sempre bom revisitar conceitos já vistos para reforçar o aprendizado.
Certificate Authority - CA
Uma Certificate Authority (CA), é um dos componentes centrais do RPKI, é quem faz toda a magia funcionar. Ela é basicamente uma entidade responsável por emitir certificados digitais dentro de uma infraestrutura de chave pública, também chamada de PKI.
De forma bem genérica, um certificado digital serve para ligar uma chave pública a alguma entidade. Essa entidade pode ser uma pessoa, uma organização, um servidor, um serviço ou algum outro tipo de recurso.
A CA existe porque na Internet, não é viável confiar diretamente em todo mundo, isso quebra o modelo de confiança, porque cada entidade teria que validar manualmente quem é confiável e quem não é.
A CA resolve esse problema atuando como uma entidade intermediária de confiança. Em vez de cada integrante precisar confiar individualmente em todos os outros, eles passam a confiar em uma autoridade comum. Essa autoridade emite certificados digitais dizendo que determinada chave pública pertence ou está associada a determinado sujeito.
Com isso, a confiança deixa de ser uma relação direta entre todas as partes e passa a ser organizada por meio de uma cadeia de confiança. Quem recebe ou valida um certificado não precisa conhecer diretamente o sujeito do certificado. Ele apenas precisa verificar se aquele certificado foi emitido por uma CA confiável e se essa CA tinha autoridade para emitir aquele certificado.
Vale reforçar que a CA deve ser confiável, se você não confiar na CA, nada que ela assina deve ser considerado confiável. Afinal, o certificado só tem valor porque existe confiança na autoridade que o emitiu e na cadeia que liga essa autoridade a uma raiz de confiança conhecida.
No RPKI, o conceito é o mesmo, mas aplicado aos recursos de numeração da Internet. Assim, podemos declarar autoridade sobre recursos como prefixos IP e ASNs.
Voltando para o RPKI, existem dois modelos principais de operação: o modelo hospedado e o modelo delegado. A diferença entre eles está em quem opera a CA responsável pelos recursos da organização.
Modelo Hospedado
No modelo hospedado (mais conhecido como hosted, em inglês), o dono do recurso não roda uma CA própria. A CA é operada pelo RIR ou NIR responsável pelo serviço. O dono do recurso acessa uma interface web, informa quais ROAs quer criar, e a infraestrutura do RIR ou NIR cuida da parte criptográfica, como: gerar e armazenar as chaves, emissão de certificados, assinatura dos objetos e publicação no repositório RPKI.
Esse é o modelo mais simples e fácil de operar, já que ele reduz a complexidade ao retirar dos LIRs e ISPs a responsabilidade de administrar uma autoridade certificadora própria. Vale reforçar que operar sua própria CA RPKI não transforma a organização em uma Trust Anchor nem dá autoridade ilimitada para criar novas CAs.
Modelo Delegado
No modelo delegado, o dono do recurso passa a operar sua própria CA RPKI, ou seja, o próprio LIR/ISP ou outra organização precisa manter uma autoridade certificadora (CA) subordinada dentro da hierarquia RPKI.
Esse modelo normalmente é usado quando a organização quer mais controle sobre a operação do RPKI, precisa automatizar a criação de ROAs, integrar isso com sistemas internos, administrar muitos recursos ou até delegar parte desses recursos para clientes ou unidades internas.
No caso do Brasil, pensando em uma organização que recebe seus recursos do NIC.br, o fluxo fica mais ou menos assim:
LACNIC
CA raiz / Trust Anchor da região
|
v
NIC.br
CA subordinada / NIR
|
v
LIR / ISP / organização brasileira
CA RPKI própria, no modelo delegado
|
v
Certificados EE
|
v
ROAs e manifests
A CA de um LIR/ISP é uma CA subordinada, ou seja, é válida apenas para os recursos que recebeu do seu parent RPKI (NIC.br no caso do Brasil). Em um modelo delegado, ela pode emitir certificados EE (End-Entity) para assinar objetos como ROAs e manifests. Em alguns casos, também pode delegar parte dos seus recursos para CAs filhas.
No caso da América Latina, olhando para a hierarquia, o LACNIC possui a CA raiz e a Trust Anchor da região. Em um cenário como o do Brasil, o NIC.br aparece abaixo do LACNIC como NIR, já que ele possui autoridade para distribuir recursos.
Aqui entra a diferença entre certificado CA e certificado EE.
No Brasil, o NIC.br/Registro.br opera no modelo delegado. Isso significa que a organização dona dos recursos (LIR ou ISP), mantém sua própria CA RPKI subordinada ao NIC.br. Já no LACNIC, o modelo oferecido aos membros é o modelo hospedado, em que a CA é operada pela própria infraestrutura do dono do registro.
Também é importante separar CA de publicação. Mesmo no modelo delegado, em que o LIR ou ISP opera sua própria CA, o NIC.br pode oferecer um servidor de publicação/repositório para seus membros. Nesse caso, a organização continua responsável pela sua CA e pelos objetos que ela assina, mas pode publicar seus certificados, ROAs e manifests no repositório do NIC.br, sem precisar manter um serviço público próprio de RRDP/rsync.
Certificado do tipo CA
Um certificado CA pode emitir outros certificados. Uma CA é composta por um certificado e um par de chaves (explicando de forma simplificada). A chave privada fica protegida pela CA e é usada para assinar certificados emitidos por ela e objetos próprios da CA, como CRLs.
Quando a CA precisa assinar um objeto final, como um ROA ou um manifest, o processo normalmente passa por um certificado End-Entity (EE). A CA emite esse certificado EE, assina ele com sua chave privada, depois a chave privada correspondente ao EE é usada para assinar exclusivamente o ROA ou manifest. Já a CRL é diferente, ela não é assinada por um certificado EE e sim pela própria CA emissora (que emitiu o EE), porque a CRL é justamente a lista em que essa CA declara quais certificados emitidos por ela foram revogados.
O certificado digital é usado para associar uma chave pública ao seu dono e a chave pública aparece dentro do certificado, ela é usada por terceiros para verificar as assinaturas.
Vamos pegar o caso do LACNIC, ele possui a CA raiz. Quando dizemos que confiamos na Trust Anchor do LACNIC, estamos dizendo principalmente que o validador conhece e confia na chave pública do LACNIC. É por causa dessa chave pública que o validador consegue verificar se o certificado raiz baixado realmente pertence ao LACNIC e se os certificados emitidos abaixo dessa raiz foram assinados por quem possui a chave privada correspondente.
O processo conceitual seria mais ou menos assim. O NIC.br tem seu próprio par de chaves, uma chave privada, que fica com o NIC.br, e uma chave pública, que será colocada dentro do certificado do NIC.br. O LACNIC então vai criar um certificado CA para o NIC.br contendo a chave pública do NIC.br, informações de validade, identificação técnica do emissor e do sujeito, permissões de CA e, no caso específico do RPKI, as extensões de recursos de numeração, como prefixos IP e ASNs sobre os quais o NIC.br tem autoridade.
Depois o LACNIC pega esse certificado (ainda não assinado) e calcula uma assinatura digital sobre o conteúdo dele usando a chave privada da CA do LACNIC. Essa assinatura passa a fazer parte do certificado emitido para o NIC.br. Então o certificado do NIC.br fica, de forma simplificada, assim:
Certificado CA do NIC.br
Sujeito: NIC.br
Chave pública: chave pública do NIC.br
Emissor: LACNIC
Recursos autorizados: prefixos/ASNs sob autoridade do NIC.br
Validade: data inicial e data final
Permissão: pode atuar como CA
Assinatura: assinatura feita com a chave privada do LACNIC
O validador, quando encontra esse certificado, faz o caminho inverso. Ele já conhece a Trust Anchor do LACNIC por meio do TAL, já que o TAL aponta para o certificado da Trust Anchor e contém a chave pública esperada, permitindo ao validador conferir se está começando pela raiz correta.
A partir desse ponto, o validador usa a chave pública do LACNIC para verificar a assinatura presente no certificado do NIC.br. Se a assinatura bater, significa que aquele certificado foi realmente emitido por quem possui a chave privada correspondente à CA do LACNIC. Depois, o validador também verifica se os recursos declarados no certificado do NIC.br estão dentro da autoridade do LACNIC e se o certificado ainda está válido, não foi revogado e segue o fluxo correto, que seria mais ou menos assim:
LACNIC
chave privada do LACNIC
assina o certificado CA do NIC.br
|
v
Certificado CA do NIC.br
contém a chave pública do NIC.br
contém os recursos autorizados
contém assinatura do LACNIC
|
v
Validador
usa a chave pública do LACNIC
verifica a assinatura no certificado do NIC.br
Vou resumir tudo porque acabei escrevendo demais. A CA do LACNIC emite e assina um certificado CA para o NIC.br (esse certificado possui a chave pública do NIC.br, os recursos de numeração autorizados, validade, emissor, sujeito e extensões RPKI). A assinatura é sempre feita com a chave privada (do LACNIC nesse caso) enquanto a chave pública (do LACNIC no caso) é usada depois pelos validadores para verificar essa assinatura.
Depois que o certificado CA do NIC.br é emitido pelo LACNIC, o NIC.br passa a poder atuar como uma CA subordinada dentro da hierarquia RPKI. A partir daí, ele pode emitir certificados para entidades abaixo dele, como LIRs e ISPs, ou emitir certificados End-Entity usados para assinar objetos específicos, como ROAs e manifests, quando o modelo for hosted.
Certificado do tipo EE
O certificado EE (End-Entity) é bem diferente, ele é usado exclusivamente para assinar e validar um objeto assinado, como um ROA ou um manifest. Ele não pode emitir outro certificado, não pode assinar uma CA filha e normalmente é usado para um único objeto.
Como eu comentei, para ROAs e manifests, cada certificado EE é usado para assinar um único objeto específico. Depois que esse objeto é assinado, a chave privada correspondente ao certificado EE não precisa ser reutilizada, ou seja, é de uso único. Isso também facilita a invalidação do objeto, se for necessário invalidar um ROA ou um manifest, basta revogar o certificado EE correspondente.
No modelo antigo (descrito na RFC 6486), existiam duas possibilidades para manifestos. A primeira era o modelo one-time-use EE certificate, em que a CA gerava uma nova chave privada e um novo certificado EE para cada nova versão do manifest. Nesse caso, a chave privada assinava um único manifest e depois podia ser descartada.
Mas existia um segundo modelo conhecido como sequential-use EE certificate, nele uma CA podia reutilizar a mesma chave privada e o mesmo certificado EE para assinar uma sequência de manifests, desde que apenas um manifest estivesse disponível e que as versões fossem publicadas usando o mesmo nome de arquivo.
Resumindo era assim:
# Modelo one-time-use:
Manifest v1 -> assinado com chave EE A
Manifest v2 -> assinado com chave EE B
Manifest v3 -> assinado com chave EE C
# Modelo sequential-use:
Manifest v1 -> assinado com chave EE A
Manifest v2 -> assinado com chave EE A
Manifest v3 -> assinado com chave EE A
Só que isso mudou com a RFC 9286 (substitui a RFC 6486), ela proibiu o uso de certificados EE em modo sequential-use para manifests e passou a exigir o modelo one-time-use. A RFC 9286 diz que a CA deve assinar apenas um manifest com cada chave privada gerada e deve gerar um novo par de chaves para cada nova versão do manifest. Ela também registra explicitamente, nas mudanças em relação à RFC 6486, que certificados EE de uso sequencial foram proibidos e certificados EE de uso único passaram a ser obrigatórios.
Route Origin Authorization - ROA
O ROA é o objeto mais conhecido. Ele diz: “este ASN pode originar este prefixo, até este maxLength”. A escolha do maxLength é crítica. A documentação alerta que uso liberal de maxLength abre espaço para forged origin attack e recomenda que ROAs sejam tão precisos quanto possível, idealmente correspondendo aos prefixos efetivamente anunciados no BGP.
O validador, como Routinator, rpki-client ou outros, baixa e valida tudo. O Routinator, segundo sua documentação, pode rodar como serviço, buscar periodicamente dados RPKI, verificar esse material e disponibilizar o resultado por HTTP e RTR. Quando instalado por pacote, os servidores HTTP e RTR vêm habilitados por padrão, mas escutando apenas em localhost por segurança, exigindo configuração explícita para atender outros dispositivos.
O roteador consome VRPs e aplica política BGP. A validação sozinha não derruba rotas magicamente em todos os ambientes. O operador decide a política. Em muitos ambientes modernos, rotas Invalid são rejeitadas em bordas de trânsito e peers. Rotas Valid podem receber preferência. Rotas NotFound geralmente continuam aceitas, porque ainda há prefixos legítimos sem ROA.
A tabela abaixo resume os componentes:
| Componente | Função | Onde roda | Observação operacional |
|---|---|---|---|
| CA RPKI | Emite certificados e assina objetos | RIR/NIR ou organização | Hosted simplifica; delegated dá controle |
| ROA | Autoriza ASN a originar prefixo | Publicado no repositório | Deve refletir anúncios reais |
| Repositório | Publica certificados, ROAs, manifests e CRLs | RIR/NIR ou organização | Precisa estar acessível via RRDP/rsync |
| Validador | Baixa, verifica e gera VRPs | Servidor do operador | Recomenda-se operar próprio |
| RTR | Entrega VRPs ao roteador | Validador para roteador | Porta comum: 3323 |
| Roteador BGP | Aplica política sobre rotas | Borda da rede | Decide aceitar, rejeitar ou preferir |
Obrigatório é publicar objetos consistentes e válidos se você está assinando seus recursos. Recomendado é rodar validadores próprios e redundantes. Legado é depender exclusivamente de IRR. Gambiarra comum é criar um único ROA largo, por exemplo /16 maxLength /24, só para “cobrir tudo”, mesmo quando só alguns /24 são anunciados.
Perguntas para validar aprendizado: qual componente faz criptografia pesada? Qual componente toma a decisão final de roteamento? Por que maxLength amplo demais pode ser perigoso?
Exercício sugerido: pegue um prefixo agregado e liste todos os anúncios mais específicos reais; depois proponha ROAs precisos para eles.
Laboratório sugerido: rode Routinator e consulte VRPs por ASN usando filtro.
O que estudar depois: modelos hosted e delegated, principalmente quando cada um faz sentido.
5. Fluxo completo do sistema
Vamos montar um cenário realista. Uma organização possui o ASN 64500 e o prefixo 203.0.113.0/24. Ela anuncia esse prefixo para dois provedores de trânsito.
Sem RPKI:
AS64500 anuncia 203.0.113.0/24
Provedor A aceita
Provedor B aceita
Internet propaga
Se outro AS, por erro ou ataque, anunciar o mesmo prefixo, parte da Internet pode aceitar dependendo de filtros, política e propagação.
Com RPKI:
Organização cria ROA:
203.0.113.0/24 maxLength 24 -> AS64500
ROA é assinado pela CA da organização ou pelo sistema hosted do RIR/NIR.
ROA é publicado no repositório.
Validadores globais baixam e validam.
Roteadores que usam ROV classificam anúncios BGP.
O fluxo fica assim:
[Detentor do prefixo]
|
| cria ROA
v
[CA RPKI]
|
| assina objeto
v
[Repositório RRDP/rsync]
|
| fetch periódico
v
[Validador RPKI]
|
| gera VRP
v
[Router via RTR]
|
| compara com BGP
v
[Política BGP]
Quando o roteador vê:
203.0.113.0/24 origin AS64500
ele encontra um VRP compatível e classifica como Valid.
Quando vê:
203.0.113.0/24 origin AS64599
ele encontra um VRP cobrindo o prefixo, mas com ASN diferente. Resultado: Invalid por ASN.
Quando vê:
203.0.113.0/25 origin AS64500
ele encontra o ASN correto, mas o prefixo anunciado é mais específico que o maxLength /24. Resultado: Invalid por length.
Quando vê:
198.51.100.0/24 origin AS64500
e não existe VRP cobrindo aquele prefixo, o resultado é NotFound.
A documentação de RPKI Securing BGP descreve exatamente esses estados definidos pela RFC 6811: Valid quando o anúncio é coberto por pelo menos um VRP; Invalid quando vem de AS não autorizado ou é mais específico que o maxLength; NotFound quando o prefixo não é coberto, ou só parcialmente coberto, por VRP.
Perguntas para validar aprendizado: uma rota NotFound é ruim? Uma rota Invalid deve sempre ser descartada? O que diferencia Invalid por ASN de Invalid por comprimento?
Exercício sugerido: classifique manualmente estes anúncios: 10.0.0.0/16 AS65000, 10.0.10.0/24 AS65000, 10.0.10.0/25 AS65000, 10.0.10.0/24 AS65001, considerando um VRP 10.0.0.0/16 maxLength 24 AS65000.
Laboratório sugerido: crie um arquivo de rotas e valide em lote com Routinator.
O que estudar depois: política BGP de importação e exportação com base em validation-state.
6. Exemplos reais
Com Routinator, você pode validar um anúncio diretamente:
routinator validate --asn 12654 --prefix 93.175.147.0/24
Linha por linha, o comando significa o seguinte. routinator chama o validador. validate pede validação de um anúncio BGP hipotético ou real. --asn 12654 informa o ASN de origem. --prefix 93.175.147.0/24 informa o prefixo anunciado.
A saída simples pode ser:
Invalid
Com JSON:
routinator validate --json --asn 12654 --prefix 93.175.147.0/24
A documentação do Routinator mostra que, em caso de Invalid, o JSON detalha se o motivo foi as, quando existe VRP cobrindo o prefixo mas nenhum com ASN correspondente, ou length, quando o anúncio é mais específico que o autorizado pelo maxLength. Ela também inclui os VRPs que causaram o resultado.
Exemplo simplificado de interpretação:
{
"route": {
"origin_asn": "AS12654",
"prefix": "93.175.147.0/24"
},
"validity": {
"state": "invalid",
"reason": "as"
}
}
origin_asn é o ASN que apareceu como origem no BGP. prefix é o NLRI anunciado. state é o resultado da validação. reason mostra a causa. Quando o motivo é as, o problema não está no tamanho do prefixo; está no ASN autorizado. Quando o motivo é length, o ASN pode até estar correto, mas o anúncio é mais específico do que o permitido.
Para listar VRPs:
routinator vrps
Para filtrar por ASN:
routinator vrps --format csv --filter-asn 22548
Para filtrar por prefixo:
routinator vrps --format json --filter-prefix 200.160.0.0/20
O material de treinamento anexado usa comandos similares para verificar a base baixada, filtrar por ASN, filtrar por prefixo e validar um par ASN/prefixo.
Um exemplo de ROA em formato operacional ficaria assim:
Prefixo: 200.160.0.0/20
ASN autorizado: AS22548
MaxLength: /24
Validade: intervalo definido pelo emissor
Trust Anchor: cadeia do RIR/NIR correspondente
Esse exemplo autoriza o AS22548 a originar 200.160.0.0/20 e mais específicos até /24, mas não /25.
Perguntas para validar aprendizado: por que --asn e --prefix são suficientes para testar validação de origem? O que o Routinator não está validando nesse comando?
Exercício sugerido: escolha um ASN conhecido e liste seus VRPs em CSV e JSON.
Laboratório sugerido: valide três prefixos válidos, três NotFound e três inválidos, registrando o motivo.
O que estudar depois: endpoints HTTP do Routinator e integração com automação.
7. Casos práticos
Um caso comum é a organização que possui um único ASN e anuncia poucos prefixos próprios. Para ela, o RPKI hosted do RIR ou NIR costuma ser o caminho mais simples. Entra no portal, cria ROAs, monitora se os anúncios BGP batem com os ROAs e pronto. É operacionalmente simples porque a CA, chaves, publicação, renovação e parte da automação ficam com o RIR/NIR. Esse modelo é recomendado para redes sem necessidade de delegar recursos para clientes ou unidades internas.
Outro caso é um provedor que delega blocos a clientes BGP. Aí o modelo fica mais sensível. Se o provedor cria ROAs cobrindo todos os clientes com maxLength amplo, pode reduzir incidentes simples, mas também pode criar risco de forged origin se o maxLength for largo demais. Se clientes originam blocos próprios ou delegados, é preciso alinhar ROAs com os anúncios reais. Em ambientes mais maduros, delegated RPKI com Krill pode fazer sentido, especialmente quando há necessidade de autonomia, integração via API, delegações para child CAs e controle próprio de publicação.
A documentação do Krill explica que, em quase todos os casos de delegated RPKI, a CA Krill roda abaixo de uma CA pai, normalmente o RIR ou NIR. O início envolve troca manual de dois XMLs, child request e parent response. Depois dessa troca inicial, as solicitações e respostas subsequentes são automatizadas, incluindo entitlement, emissão, renovação e revogação.
No contexto brasileiro, o material anexado mostra um fluxo com NIC.br: o operador gera o child_request, envia pelo sistema do Registro.br em Titularidade > RPKI, recebe o parent_response e configura isso no Krill com comando krillc parents add ... --rfc8183 <arquivo XML>, estabelecendo o canal UpDown com o servidor Krill do NIC.br.
Um terceiro caso é a rede que só quer validar rotas recebidas. Ela não precisa operar uma CA para começar a validar. Pode instalar dois validadores, conectá-los aos roteadores e aplicar política BGP. Mesmo que ainda não tenha criado ROAs para seus próprios recursos, já pode se proteger contra anúncios inválidos de terceiros.
Perguntas para validar aprendizado: quando hosted RPKI é suficiente? Quando delegated RPKI começa a fazer sentido? É possível validar rotas de terceiros sem publicar ROAs próprios?
Exercício sugerido: classifique sua organização em um dos três casos: rede simples, provedor com clientes, ou rede que inicialmente só validará terceiros.
Laboratório sugerido: desenhe o fluxo de delegated RPKI com Krill para seu RIR ou NIR.
O que estudar depois: Krill, protocolo UpDown, RFC 8183 e publicação via RFC 8181.
8. Problemas comuns
O erro mais comum em RPKI é criar ROA incompleto. A organização anuncia 203.0.113.0/24 pelo AS64500 e 203.0.113.128/25 por outro ASN em algum cenário especial, mas só cria ROA para o /24. Dependendo do maxLength e do ASN, o anúncio mais específico pode ficar Invalid.
Outro erro comum é maxLength largo demais. Muita gente cria algo como:
10.0.0.0/16 maxLength 24 AS65000
porque pensa: “assim estou coberto para qualquer /24 futuro”. Tecnicamente funciona, mas aumenta a superfície de ataque. A recomendação mais segura é criar ROAs que reflitam os anúncios reais. Se você anuncia só o /16 e um /24 específico, prefira ROAs específicos para esses anúncios, em vez de permitir qualquer /24 dentro do /16.
Também há problema de troca de ASN. Uma empresa muda trânsito, faz migração, passa a originar prefixos por um novo ASN ou por AS de terceiro, mas esquece de atualizar ROAs. O resultado pode ser Invalid globalmente para redes que rejeitam rotas inválidas.
Outro problema é confundir ROA criptograficamente inválido com rota RPKI Invalid. São coisas diferentes. Um ROA pode falhar na validação criptográfica e ser descartado pelo validador. A rota BGP, por sua vez, recebe estado Valid, Invalid ou NotFound com base nos VRPs resultantes. Se um ROA ruim é descartado, ele pode simplesmente não gerar VRP, e uma rota que você esperava ver como Valid pode aparecer como NotFound.
Também há falhas de repositório. Se RRDP ou rsync ficam indisponíveis, validadores podem manter dados por algum tempo, mas objetos podem se tornar stale. Em delegated RPKI, se você opera publicação própria, passa a ter responsabilidade real de disponibilidade. A documentação do Krill recomenda usar o servidor de publicação do parent CA quando disponível, porque isso evita a responsabilidade de manter rsync e web públicos disponíveis o tempo todo.
Perguntas para validar aprendizado: por que um ROA amplo pode ser pior que vários ROAs precisos? O que acontece quando um ROA não gera VRP? Qual é o risco operacional de publicar por conta própria?
Exercício sugerido: revise uma lista de prefixos anunciados e encontre quais ROAs faltariam.
Laboratório sugerido: simule uma rota inválida por ASN e outra inválida por length usando Routinator.
O que estudar depois: troubleshooting com logs do validador, manifests e stale objects.
9. Troubleshooting
O diagnóstico de RPKI deve seguir uma ordem. Primeiro, descubra qual rota está com problema. Depois, descubra o estado RPKI. Depois, identifique se o problema é ausência de VRP, ASN divergente, comprimento excedido, objeto stale, repositório indisponível ou política BGP local.
Comece pelo par prefixo e ASN:
routinator validate --json --asn 64500 --prefix 203.0.113.0/24
Se o resultado for valid, a base RPKI está coerente para aquele anúncio. Se o roteador ainda rejeita, o problema provavelmente está na política local, no route-map, policy-statement, prefix-list, community ou integração RTR.
Se o resultado for invalid com reason as, procure ROAs para o prefixo:
routinator vrps --format json --filter-prefix 203.0.113.0/24
Se aparecer outro ASN autorizado, o ROA está apontando para o ASN errado, ou a rota está sendo originada pelo ASN errado.
Se o resultado for invalid com reason length, compare o anúncio real com o maxLength. Exemplo:
VRP: 203.0.113.0/24 maxLength 24 AS64500
Anúncio: 203.0.113.0/25 origin AS64500
Estado: Invalid por length
Nesse caso, ou o anúncio /25 não deveria existir, ou o ROA precisa ser ajustado com cuidado. O ajuste correto não é necessariamente aumentar tudo para /32 ou /48; o correto é representar a política real de anúncios.
Se o resultado for notfound, veja se existe ROA para aquele recurso. Pode ser que o prefixo não esteja coberto, que o RIR/NIR ainda não tenha publicado, que a organização não tenha criado ROA, ou que o validador não tenha conseguido buscar o repositório.
Verifique o serviço do validador:
sudo systemctl status routinator
sudo journalctl --unit=routinator
A documentação de instalação do Routinator mostra esses comandos como forma básica de checar status e logs quando instalado por pacote.
Verifique se o RTR está escutando:
ss -lntp | grep 3323
Verifique conectividade do roteador até o validador:
telnet 192.0.2.13 3323
ou:
nc -vz 192.0.2.13 3323
Verifique firewall. O Routinator precisa sair para HTTPS e rsync, normalmente portas 443 e 873. A documentação do Routinator alerta que novos repositórios RPKI podem surgir em qualquer faixa IP ou domínio, então tráfego de saída não deve ser bloqueado por IP ou DNS de forma rígida; ele precisa estabelecer conexões HTTPS e rsync nas portas 443 e 873.
Perguntas para validar aprendizado: qual comando você usaria primeiro para diferenciar Invalid por ASN e por length? Por que olhar só o roteador pode não ser suficiente?
Exercício sugerido: monte uma árvore de decisão para diagnosticar Valid, Invalid e NotFound.
Laboratório sugerido: bloqueie temporariamente a saída rsync/HTTPS em um ambiente de teste e observe os logs do validador.
O que estudar depois: métricas Prometheus do validador e alarmes para stale, serial, VRPs e sessões RTR.
10. Boas práticas
A primeira boa prática é criar ROAs para todos os anúncios reais. A documentação de modelos de implementação é direta: depois que você começa a autorizar anúncios com RPKI, é imperativo criar ROAs para todas as origens de rota dos prefixos que você mantém, incluindo mais específicos anunciados por unidades de negócio ou clientes; RPKI deve virar parte padrão da operação, com equipe treinada e ROAs continuamente monitorados e mantidos.
A segunda é preferir ROAs precisos. Se você anuncia /24, crie ROA para /24 maxLength 24. Se você anuncia /20 e alguns /24, crie ROAs que reflitam isso. Evite transformar todo agregado em autorização para todos os mais específicos possíveis.
A terceira é rodar validadores próprios. A documentação de uso de dados RPKI enfatiza que o valor de assinar vem da validação e que a validação deve ser feita pela parte que depende dos dados; se você terceiriza a validação, não consegue ter certeza se os dados estão completos ou se foram adulterados.
A quarta é usar redundância. Em produção, use pelo menos dois validadores em locais diferentes, conectados aos roteadores. Não dependa de um único servidor. Também não dependa de um único fornecedor de software se sua escala justificar diversidade.
A quinta é começar com política conservadora. Em muitos ambientes, primeiro marque rotas com comunidades ou local-preference, monitore o impacto, gere relatório de Invalid, corrija exceções legítimas e depois passe a rejeitar Invalid nas bordas adequadas. Em trânsito e peering, rejeitar Invalid já é prática madura, mas a transição precisa ser operacionalmente controlada.
A sexta é monitorar mudanças. ROA não é “configurar uma vez e esquecer”. Mudanças de ASN, trânsito, engenharia de tráfego, desagregação de prefixos, clientes BGP e fusões de rede exigem revisão.
Perguntas para validar aprendizado: por que RPKI deve entrar no processo de mudança BGP? Por que validador próprio é melhor que consumir dados prontos de terceiros?
Exercício sugerido: escreva um checklist de mudança BGP que inclua revisão RPKI.
Laboratório sugerido: configure alertas para queda de sessão RTR e redução inesperada no número de VRPs.
O que estudar depois: governança operacional de RPKI e integração com NetBox, Peering Manager ou automação interna.
11. Segurança
RPKI melhora a segurança do roteamento, mas não resolve todos os problemas do BGP. Ele valida origem, não caminho completo. Se um atacante conseguir fazer forged origin, isto é, anunciar usando o ASN correto da vítima, o ROV pode não detectar apenas pela origem. É por isso que maxLength preciso importa tanto. Quanto mais você autoriza mais específicos genéricos, mais espaço dá para ataques que tentem parecer originados corretamente.
Path validation é o passo mais ambicioso. BGPSec foi padronizado, mas a própria documentação observa que, embora path validation via BGPSec seja desejável e padronizada na RFC 8205, a implantação real pode continuar limitada por bastante tempo. Ela também menciona ASPA como uma abordagem incremental e mais leve para validação relacionada a relacionamento provedor-cliente.
Do ponto de vista de segurança operacional, proteja a CA. Se você usa hosted, proteja a conta do portal do RIR/NIR com MFA e controle de permissões. Se usa delegated com Krill, proteja o servidor, tokens, backups e chaves. A documentação do Krill alerta que backups podem conter chaves privadas em texto claro no diretório data_dir/ssl, recomendando criptografar backups.
Proteja também o acesso ao RTR. RTR tradicional em TCP simples é comum em redes internas, mas não deve ser exposto sem controle. Use rede de gerência, ACL, firewall, ou transportes seguros quando necessário. Routinator suporta TLS para HTTP e RTR, com opções de certificado e chave para RTR-over-TLS.
O que é obrigatório em segurança: garantir que apenas pessoas autorizadas possam criar, alterar ou remover ROAs. O que é recomendado: MFA, logs, revisão por pares, backup criptografado, monitoramento e validadores redundantes. O que é legado: tratar RPKI como um detalhe manual separado da engenharia BGP. O que é gambiarra comum: compartilhar token de administração do Krill entre várias pessoas sem rastreabilidade.
Perguntas para validar aprendizado: RPKI impede qualquer hijack? Por que proteger o portal do RIR/NIR é tão importante quanto proteger um roteador?
Exercício sugerido: liste quem na sua organização deveria ter permissão para alterar ROAs.
Laboratório sugerido: teste acesso ao RTR apenas a partir de endereços de roteadores autorizados.
O que estudar depois: BGPSec, ASPA, SLURM, threat model de validadores RPKI.
12. Performance
Um ponto interessante do RPKI é que a criptografia pesada não fica no roteador. O validador faz download, verificação de certificados, manifests, CRLs e ROAs. O roteador recebe um conjunto compacto de VRPs via RTR. Isso reduz impacto em plano de controle.
A documentação do Krill afirma que os requisitos de sistema para a CA são mínimos e que operações criptográficas da CA têm impacto desprezível de CPU e memória em máquinas modernas. Ela também cita como referência uma VM de produção com 2 CPUs, 2 GB de RAM e 60 GB de disco servindo ROAs, embora isso dependa do papel operacional e do tamanho do repositório.
Para Routinator, a documentação fala em requisitos modestos, mas chama atenção para inodes. RPKI é composto por muitos arquivos pequenos, então o validador pode consumir muitos inodes. A recomendação documentada é acomodar pelo menos dois milhões de inodes para margem de crescimento.
A frequência de atualização também importa. No Routinator, a opção refresh define o intervalo entre validações em modo servidor, com padrão de 600 segundos. A opção expire informa por quanto tempo um cliente RTR pode usar um dataset se não conseguir atualização antes de descartá-lo, com padrão de 7200 segundos.
Impacto em BGP: RPKI não deve reduzir significativamente a convergência se bem implementado, porque o roteador não está baixando a Internet RPKI inteira nem fazendo validação X.509. Ele apenas consulta estados já derivados. O risco de performance costuma estar mais em política mal escrita, bugs de plataforma, excesso de churn, queda de cache RTR, ou infraestrutura de validação subdimensionada.
Perguntas para validar aprendizado: por que inodes importam em validador RPKI? Por que o roteador não deve ser responsável por baixar repositórios RPKI?
Exercício sugerido: verifique df -i no servidor onde você pretende rodar o validador.
Laboratório sugerido: rode dois validadores e compare tempo de validação, número de VRPs e logs de atualização.
O que estudar depois: métricas JSON e Prometheus do Routinator.
13. Comparações com tecnologias similares
RPKI e IRR têm objetivo parecido em uma parte do problema: declarar quem pode originar o quê. Mas a confiança é diferente. IRR usa objetos de registro, como route e route6, em bases que podem ter qualidade variável. RPKI usa certificados de recursos e objetos assinados seguindo a cadeia de alocação.
RPKI e prefix-list manual também são diferentes. Prefix-list é controle local, útil e necessário, mas exige manutenção manual ou automação própria. RPKI permite que o titular do recurso publique autorização de forma globalmente verificável.
RPKI e BGPSec também não são a mesma coisa. RPKI ROV valida a origem. BGPSec tenta validar o caminho AS-PATH. ROV é amplamente operacional; BGPSec, embora padronizado, tem adoção muito mais limitada. A documentação de Securing BGP afirma que origin validation é atualmente a funcionalidade operacionalmente usada, com suporte dos RIRs, software livre e grandes vendors, enquanto path validation ainda tem implantação real limitada.
RPKI e MANRS se relacionam, mas não são equivalentes. MANRS é um conjunto de práticas de segurança de roteamento; RPKI é uma tecnologia específica que ajuda a implementar parte dessas práticas.
| Tecnologia | Resolve | Limitação |
|---|---|---|
| IRR | Registro de autorização de origem | Qualidade desigual e ausência de cadeia criptográfica forte |
| Prefix-list | Controle local preciso | Manutenção manual e pouco escalável sem automação |
| RPKI ROV | Validação criptográfica da origem | Não valida caminho completo |
| BGPSec | Validação criptográfica do AS-PATH | Implantação operacional limitada |
| ASPA | Ajuda a validar relações provedor-cliente | Ainda em evolução operacional |
| MANRS | Boas práticas de roteamento | Não é protocolo, depende de implementação |
Perguntas para validar aprendizado: por que RPKI não elimina a necessidade de filtros locais? Por que BGPSec é mais difícil de implantar que ROV?
Exercício sugerido: compare seus objetos IRR com seus ROAs e encontre divergências.
Laboratório sugerido: gere uma lista de prefixos autorizados via IRR e compare com VRPs do validador.
O que estudar depois: RPSL, IRRd, PeeringDB, MANRS e ASPA.
14. Exercícios práticos
Considere este VRP:
Prefixo: 192.0.2.0/24
ASN: AS64500
MaxLength: 24
Classifique:
192.0.2.0/24 origin AS64500
192.0.2.0/25 origin AS64500
192.0.2.0/24 origin AS64501
192.0.2.128/25 origin AS64501
198.51.100.0/24 origin AS64500
A resposta esperada é: o primeiro é Valid; o segundo é Invalid por length; o terceiro é Invalid por ASN; o quarto também é Invalid se estiver coberto pelo VRP e exceder ou divergir; o quinto é NotFound se não houver VRP cobrindo 198.51.100.0/24.
Agora considere:
Prefixo: 192.0.2.0/24
ASN: AS64500
MaxLength: 25
Nesse caso, 192.0.2.0/25 origin AS64500 passa a ser Valid. Mas isso só deve ser feito se você realmente pretende anunciar /25, lembrando que IPv4 /25 normalmente não é aceito globalmente por filtros de tamanho mínimo em muitas redes. RPKI autorizar não significa que a Internet aceitará operacionalmente.
Perguntas para validar aprendizado: RPKI permite anunciar qualquer tamanho de prefixo? O fato de um anúncio ser Valid garante que ele será escolhido como melhor caminho?
Exercício sugerido: monte dez pares prefixo/ASN e classifique manualmente antes de usar Routinator.
Laboratório sugerido: crie um arquivo rotas.txt com entradas no formato prefixo => ASN e valide em lote.
O que estudar depois: filtros de prefix length em IPv4 e IPv6.
15. Laboratório passo a passo
Neste laboratório, o objetivo é rodar Routinator, consultar VRPs e validar rotas. Em Debian ou Ubuntu, a instalação por pacote segue a lógica documentada pela NLnet Labs: atualizar o índice, instalar dependências para repositório HTTPS, adicionar chave, configurar repositório, atualizar de novo e instalar o pacote. A documentação informa que, após a instalação, o Routinator roda como usuário routinator, inicia no boot, e por padrão usa RTR na porta 3323 e HTTP na porta 8323.
Comandos conceituais:
sudo apt update
sudo apt install ca-certificates curl gnupg lsb-release
sudo apt install routinator
sudo systemctl status routinator
Se você rodar via Docker:
sudo docker volume create rpki-cache
sudo docker run -d --restart=unless-stopped --name routinator \
-p 3323:3323 \
-p 8323:8323 \
-v rpki-cache:/home/routinator/.rpki-cache \
nlnetlabs/routinator
Linha por linha: docker volume create rpki-cache cria armazenamento persistente para o cache RPKI. docker run -d executa em background. --restart=unless-stopped reinicia automaticamente. --name routinator nomeia o container. -p 3323:3323 expõe RTR. -p 8323:8323 expõe HTTP. -v rpki-cache:... mantém o cache entre reinícios. nlnetlabs/routinator é a imagem.
Depois, valide:
routinator vrps --format csv | head
Teste um prefixo:
routinator validate --json --asn 22548 --prefix 200.160.0.0/22
Consulte via HTTP:
curl http://127.0.0.1:8323/json
Consulte um prefixo específico:
curl "http://127.0.0.1:8323/json?select-prefix=200.160.0.0/20"
A documentação do Routinator explica que consultas por prefixo retornam match exato e menos específicos, porque um VRP menos específico sobreposto também pode afetar a validade RPKI dependendo do maxLength. Também há opção para incluir mais específicos.
Para Krill em delegated RPKI, o fluxo básico é diferente. Você cria a CA local, gera XML child request, envia ao RIR/NIR, recebe parent response, configura o parent no Krill e depois cria ROAs. No material do NIC.br, aparece o comando:
krillc parents add --server <URL> --token <senha> --ca <nome> \
--parent <nome> --rfc8183 <arquivo XML>
Esse comando adiciona o parent da CA local. --server aponta para a API do Krill. --token autentica. --ca identifica sua CA local. --parent dá nome ao parent. --rfc8183 aponta para o XML de resposta do parent.
Perguntas para validar aprendizado: qual porta é usada para RTR no laboratório? Qual porta é usada para HTTP? Por que é importante persistir o cache no Docker?
Exercício sugerido: instale Routinator e gere três consultas por ASN, prefixo e validação.
Laboratório sugerido: conecte um roteador de laboratório ou FRR ao RTR do Routinator.
O que estudar depois: configuração de RPKI em FRR, BIRD, Junos, IOS XR ou RouterOS, conforme seu ambiente.
16. Conteúdo avançado
Em nível avançado, RPKI deixa de ser apenas “criar ROA” e vira uma disciplina operacional. Você começa a pensar em alta disponibilidade, delegação de CAs, publicação própria, chaves, HSM, migração de repositório, exceções locais, telemetria e automação.
Krill usa um modelo interno baseado em eventos. A documentação explica que mudanças de estado são rastreadas como eventos; CAs e servidores de publicação são versionados; o estado pode ser reconstruído aplicando eventos passados; comandos podem gerar eventos; snapshots são salvos periodicamente; e falhas de persistência fazem o Krill parar por design, para evitar divergência entre estado em memória e em disco.
Isso importa porque backup e restore não são detalhes. Em Krill, fazer backup do diretório de dados é essencial. Em ambientes com delegated RPKI, perder estado pode afetar sua capacidade de renovar ou publicar objetos corretamente. Também é preciso entender que Krill não suporta clustering ativo-ativo; alta disponibilidade é feita com failover para standby inativo usando os mesmos dados e configuração.
Outro tema avançado é Local Exceptions, frequentemente via SLURM. Isso permite aplicar exceções locais à validação, por exemplo para corrigir temporariamente uma situação conhecida. Mas isso deve ser tratado como exceção operacional, não como substituto de correção na fonte. A documentação do Routinator menciona formatos SLURM para assertions locais e também indica que saídas podem indicar se a origem de um dado veio de ROA, certificado de roteador ou exception file.
ASPA é outro avanço importante. Enquanto ROV valida origem, ASPA busca ajudar a detectar caminhos inconsistentes com relações provedor-cliente. Ainda não substitui BGPSec, mas tem potencial operacional por ser mais incremental.
Perguntas para validar aprendizado: por que active-active não é trivial em uma CA RPKI? Qual é o risco de usar exceções locais sem governança?
Exercício sugerido: desenhe uma arquitetura com dois validadores e uma CA Krill em standby.
Laboratório sugerido: teste backup e restore de uma instância Krill de laboratório.
O que estudar depois: event sourcing no Krill, SLURM, ASPA, HSM e migração de repositório.
17. Como isso é usado em produção
Em produção, operadores experientes tratam RPKI em dois lados: publicação e validação. Publicação protege seus próprios prefixos contra origem indevida por terceiros. Validação protege sua rede e seus clientes contra aceitar rotas inválidas.
Uma arquitetura comum é:
+-------------------+
| RPKI Validator 1 |
| Routinator |
+---------+---------+
|
| RTR
|
[Edge Router 1]---------------+
[Edge Router 2]---------------+
|
| RTR
+---------+---------+
| RPKI Validator 2 |
| outro site |
+-------------------+
Os roteadores apontam para dois validadores. Se um cair, o outro continua alimentando VRPs. A política BGP pode rejeitar Invalid em sessões eBGP, principalmente trânsito e peering. Para clientes, alguns provedores aplicam política mais gradual, porque cliente pode ter ROA incorreto e gerar chamado. Em qualquer caso, o ideal é monitorar antes de descartar em massa.
Na publicação, uma organização simples usa hosted RPKI. Um ISP maior pode usar delegated RPKI com Krill e, se possível, publicação no parent. A documentação do Krill recomenda publicar com o parent CA quando disponível, porque isso reduz a responsabilidade de manter serviço público de publicação.
Produção também exige processo. Antes de anunciar novo prefixo, cria-se ROA. Antes de mudar origem para outro ASN, altera-se ROA. Antes de desagregar prefixo, ajusta-se maxLength ou cria-se ROA específico. Depois da mudança, valida-se com ferramentas externas e internas.
Perguntas para validar aprendizado: por que publicar ROA e validar rotas são projetos relacionados, mas independentes? Por que dois validadores são melhores que um?
Exercício sugerido: desenhe a topologia RPKI ideal para sua rede atual.
Laboratório sugerido: configure dois validadores e faça failover de sessão RTR.
O que estudar depois: políticas BGP por vendor e observabilidade de RPKI.
18. Erros que iniciantes cometem
O primeiro erro é achar que RPKI é “só ligar no roteador”. Não é. Se você rejeitar Invalid sem olhar sua realidade, pode derrubar rotas de clientes ou rotas próprias mal cadastradas.
O segundo erro é criar ROA com maxLength exagerado. Isso parece facilitar a vida, mas enfraquece a proteção.
O terceiro erro é esquecer anúncios feitos por terceiros. Muitas empresas têm prefixos anunciados por CDN, scrubbing center, parceiro, provedor ou ambiente temporário. Se o ROA só autoriza o ASN próprio, esses anúncios podem ficar Invalid.
O quarto erro é tratar NotFound como Invalid. NotFound significa ausência de VRP cobrindo o prefixo. Em uma Internet com adoção gradual, rejeitar NotFound de forma geral ainda é agressivo demais para a maioria dos cenários.
O quinto erro é confiar em validador público sem entender a cadeia. Para produção, o correto é validar localmente.
O sexto erro é não monitorar expiração, stale, queda de RTR, mudanças de serial e variação de VRPs.
O sétimo erro é separar equipes. RPKI fica entre segurança, engenharia IP, BGP, governança de recursos e NOC. Quando cada grupo mexe em uma parte sem processo integrado, aparecem incidentes.
Perguntas para validar aprendizado: qual desses erros seria mais provável na sua rede? O que você mudaria no processo de mudança BGP para evitar isso?
Exercício sugerido: escreva uma política interna simples para criação e alteração de ROAs.
Laboratório sugerido: simule uma mudança de ASN de origem e veja como atualizar ROA antes do anúncio.
O que estudar depois: gestão operacional de mudanças e runbooks de incidentes RPKI.
19. Como evoluir profissionalmente nesse assunto
Para evoluir em RPKI, não basta decorar comandos. É preciso entender BGP de verdade, principalmente seleção de melhor caminho, filtros, políticas, comunidades, trânsito, peering, clientes e engenharia de tráfego. Depois, aprofunde em PKI: certificado, assinatura, cadeia de confiança, revogação, validade e trust anchor. Só então RPKI fica natural.
O caminho profissional mais sólido é este: primeiro, aprenda BGP e leia a RFC 4271 em partes. Depois, estude RPKI pela RFC 6480, validação de origem pela RFC 6811, RTR pela RFC 8210, RRDP pela RFC 8182 e TAL pela RFC 8630. Em paralelo, rode laboratório com Routinator, Krill e FRR ou BIRD. Depois, leve isso para um ambiente de homologação com seus prefixos reais. Por fim, implemente política gradual em produção.
O profissional experiente em RPKI sabe responder rapidamente a perguntas como: “este prefixo está inválido por ASN ou por length?”, “qual ROA gerou este VRP?”, “este NotFound é esperado?”, “meu validador está stale?”, “a queda de um repositório afetou meus VRPs?”, “minha política BGP rejeita Invalid antes ou depois de outras regras?”, “clientes com delegated RPKI estão publicando corretamente?”
Esse é o ponto em que RPKI deixa de ser uma tecnologia isolada e vira parte da higiene operacional da Internet.
Perguntas finais para validar aprendizado: você consegue explicar RPKI sem usar a palavra “segurança” de forma genérica? Você consegue desenhar o caminho de um ROA desde a criação até a decisão de um roteador? Você consegue diagnosticar Invalid por ASN e por length?
Exercício final: escolha um ASN real, liste os prefixos anunciados, consulte os VRPs, compare com a tabela BGP e identifique divergências.
Laboratório final: monte Routinator, conecte a um roteador FRR, aplique política que marque Valid, Invalid e NotFound com communities diferentes, monitore por alguns dias e só depois teste rejeição de Invalid em ambiente controlado.
O que estudar depois: Krill em delegated RPKI, Routinator em alta disponibilidade, políticas por vendor, SLURM, ASPA e automação de ROAs.
Fontes
https://datatracker.ietf.org/doc/html/rfc6480
https://www.rfc-editor.org/info/rfc6480
https://www.caida.org/catalog/papers/2022_irr_hygiene_rpki_era/irr_hygiene_rpki_era.pdf
https://manrs.org/specifications/MANRS-007/01/
https://blog.apnic.net/2018/08/01/treating-rpki-roas-as-irr-route6-objects/
https://blog.lacnic.net/en/rpki-and-irr-frequently-asked-questions/
Colocar em algum momento:
O padrão arquitetural central do RPKI é a RFC 6480, que descreve o uso do RPKI para roteamento seguro. A base dos certificados de recursos vem do perfil X.509 com extensões para recursos IP e ASN, relacionado à RFC 3779. O protocolo RTR aparece nas RFCs 6810 e 8210. A validação de origem de rota é descrita na RFC 6811. O TAL, Trust Anchor Locator, é especificado na RFC 8630. O RRDP, usado para buscar repositórios via HTTPS, é descrito na RFC 8182. A documentação do Routinator resume esses elementos: RPKI prova a associação entre blocos IP ou ASNs e seus detentores, ROA é um objeto assinado que autoriza um ASN a originar prefixos, ROV autentica anúncios como originados por um AS esperado, RRDP busca dados via HTTPS, RTR entrega dados de origem aos roteadores, e TAL localiza e verifica a trust anchor.
Aqui é importante separar o que é obrigatório, recomendado, legado e gambiarra comum. Obrigatório, para RPKI funcionar corretamente, é haver certificados de recursos válidos, ROAs publicados, repositórios acessíveis, validadores confiáveis e roteadores consumindo VRPs se você quer filtrar. Recomendado é operar validadores próprios, redundantes, com monitoramento, e criar ROAs precisos. Legado é depender só de IRR como fonte de autorização. Gambiarra comum é copiar lista de VRPs de terceiros sem validação própria, ou usar maxLength excessivamente amplo para “não precisar mexer depois”.
Perguntas para validar aprendizado: por que o IRR não substitui completamente o RPKI? Por que a hierarquia IANA, RIR e NIR combina naturalmente com uma PKI?
Exercício sugerido: desenhe a cadeia de alocação do seu ASN e dos seus blocos IP até o RIR ou NIR responsável.
Laboratório sugerido: consulte o portal do seu RIR ou NIR e veja se seus recursos possuem opção de RPKI hospedado ou delegado.
O que estudar depois: RFC 6480, RFC 6811, RFC 8210, RFC 8182 e RFC 8630.