Resource Public Key Infrastructure

A Resource Public Key Infrastructure (RPKI, em português, infraestrutura de chaves públicas de recursos), também conhecida como Resource Certification, é uma infraestrutura de chaves públicas destinada a melhorar a segurança do roteamento na Internet. Seus certificados digitais X.509 vinculam recursos de numeração, como blocos de endereços IP e números de sistemas autônomos, a chaves públicas. Sua arquitetura é descrita na RFC 6480, publicada pela Internet Engineering Task Force (IETF) em 2012.

Uma de suas aplicações é a publicação de autorizações de origem de rota, ou ROAs, pelas quais o detentor de um bloco de endereços autoriza um sistema autônomo a originar anúncios de determinados prefixos no Border Gateway Protocol (BGP). Esses dados permitem realizar a validação de origem de rota, conhecida pela sigla ROV, e aplicar políticas de rejeição de anúncios não autorizados. A medida ajuda a mitigar sequestros de BGP e erros de configuração, mas não verifica, por si só, todo o caminho percorrido pelo anúncio.

Estrutura hierárquica e certificados X.509

A estrutura de certificação da RPKI acompanha a distribuição dos recursos de numeração da Internet, cuja alocação global aos registros regionais é coordenada pela Autoridade para Atribuição de Números da Internet (IANA). Os certificados podem formar cadeias que passam por registros regionais, nacionais e locais até chegar aos titulares dos recursos, conforme a organização de cada alocação.

Na implantação operacional, os cinco registros regionais de Internet mantêm âncoras de confiança próprias: AfriNIC, APNIC, ARIN, LACNIC e RIPE NCC. A validação parte dessas âncoras, sem exigir que os certificados dos registros regionais sejam subordinados a um certificado da IANA. Os registros nacionais, como o Registro.br no Brasil, os registros locais e os demais titulares podem participar dos níveis subordinados dessa estrutura.

Cada âncora pode ser identificada por um Trust Anchor Locator (TAL), um arquivo com um ou mais endereços para obtenção do certificado da âncora e a chave pública esperada. O validador usa essa chave para verificar o certificado autoassinado obtido. A RFC 8630 define esse formato e substitui a RFC 7730.

Extensões da RFC 3779

Os certificados de recursos utilizam X.509 versão 3 com extensões definidas na RFC 3779. Essas extensões associam ao titular do certificado intervalos de endereços IPv4 e IPv6 ou identificadores de sistemas autônomos. Os certificados de autoridades certificadoras permitem a emissão de certificados subordinados, enquanto os certificados de entidade final são usados na validação de objetos assinados e não funcionam como autoridades certificadoras. A certificação atesta a alocação dos recursos, sem funcionar como comprovante da identidade civil ou jurídica de seu titular.

Repositórios e sincronização de dados

Os certificados, as listas de revogação, os manifestos e os objetos assinados são publicados em repositórios distribuídos. Os validadores consultam esses pontos de publicação e mantêm cópias locais dos dados necessários à verificação. Os repositórios podem ser mantidos pelos registros de Internet ou por outras organizações participantes da infraestrutura. A obtenção dos dados utiliza mecanismos como:

  • rsync: protocolo empregado para transferir e atualizar os arquivos publicados nos repositórios.
  • RPKI Repository Delta Protocol (RRDP): definido na RFC 8182, utiliza HTTPS para disponibilizar arquivos XML de notificação, de estado completo do repositório e de alterações incrementais. Foi concebido para permitir a distribuição por redes de entrega de conteúdo e outras infraestruturas de cache, reduzindo a necessidade de transferir novamente todo o conjunto de dados a cada atualização.

Autorização de origem de rota (ROA)

Uma autorização de origem de rota, ou ROA, é um objeto assinado digitalmente pelo qual o detentor de recursos de endereçamento autoriza um sistema autônomo a originar rotas para um ou mais prefixos. Seu formato é definido na RFC 9582, de maio de 2024, que substituiu a RFC 6482. O objeto utiliza a estrutura de assinatura da RPKI baseada em Cryptographic Message Syntax (CMS).

Cada ROA identifica um único número de sistema autônomo autorizado, ou ASN, e uma lista de prefixos. Para cada prefixo, pode incluir um limite de comprimento:

A RFC 9319, integrante da BCP 185, recomenda limitar as autorizações aos prefixos efetivamente anunciados, sempre que possível. Um maxLength excessivamente amplo pode autorizar subprefixos que não são anunciados legitimamente e ampliar a exposição a ataques que falsificam o ASN de origem. Como o encaminhamento favorece o prefixo mais específico, um anúncio desse tipo pode desviar tráfego mesmo quando passa pela validação de origem. Prefixos adicionais podem ser enumerados em um mesmo ROA, sem a obrigação de criar um objeto separado para cada um. A recomendação admite exceções operacionais e não constitui uma proibição absoluta do campo.

Validação de origem de rota (ROV)

A validação de origem de rota, ou ROV, compara os anúncios BGP com os dados obtidos de ROAs validados. Ela atua sobre as informações de roteamento usadas pelo roteador para selecionar caminhos. A RFC 6811 define o procedimento de classificação, e a RFC 8481 esclarece aspectos de sua aplicação e da política configurada pelo operador.

Servidores validadores e protocolo RTR

A verificação das cadeias de certificados e dos objetos assinados pode ser realizada por servidores validadores, que fornecem aos roteadores os resultados necessários à validação de origem. Essa separação evita que cada roteador precise executar todo o processo de obtenção e verificação criptográfica dos repositórios.

Os validadores partem das âncoras de confiança configuradas, obtêm os objetos publicados e verificam certificados, assinaturas, manifestos e listas de revogação. De cada ROA aceito são extraídos registros com prefixo, comprimento máximo e ASN autorizado, chamados Validated ROA Payloads (VRPs). Um ROA com vários prefixos pode produzir vários VRPs.

Entre os programas usados nesse processo estão:

  • rpki-client: validador desenvolvido como parte do projeto OpenBSD, capaz de exportar os dados validados em formatos como JSON.
  • Routinator: validador da NLnet Labs, escrito em Rust, que inclui um servidor RTR para fornecer os resultados aos roteadores.
  • FORT Validator: validador e servidor RTR oferecido pelo projeto FORT, uma iniciativa do NIC México e do LACNIC.
  • StayRTR: servidor RTR derivado do GoRTR, da Cloudflare, que recebe dados já validados em JSON e os distribui aos roteadores. Sua função é a distribuição dos resultados, e não a validação das cadeias de certificados.

O protocolo RPKI-to-Router (RTR) permite que um roteador receba os dados de um cache confiável e acompanhe suas atualizações. A versão 1 é especificada na RFC 8210, que atualiza a RFC 6810, referente à versão 0. A distribuição pode ser feita pelo próprio programa validador ou por um servidor separado, conforme a implantação.

Estados de validação no BGP

Para cada rota submetida à validação, o roteador compara o prefixo e o ASN de origem com a base de VRPs disponível. Um VRP cobre uma rota quando seu prefixo é igual ou menos específico e contém integralmente o prefixo anunciado. O resultado é um dos seguintes estados:

  • Valid (válido): existe pelo menos um VRP que cobre o prefixo, autoriza o ASN de origem e permite o comprimento do anúncio.
  • Invalid (inválido): existe pelo menos um VRP que cobre o prefixo, mas nenhum autoriza simultaneamente o ASN de origem e o comprimento anunciado.
  • NotFound (não encontrado): nenhum VRP disponível cobre o prefixo anunciado.

Se houver vários VRPs cobrindo a mesma rota, basta que um deles a autorize para que o resultado seja Valid. Um anúncio Invalid também pode decorrer de um erro de configuração, e não necessariamente de um ataque.

A rejeição de rotas inválidas é recomendada nas orientações operacionais da RFC 7115, mas depende da política configurada na rede. A RFC 8481 determina que ações baseadas no estado de validação não sejam aplicadas implicitamente, sem configuração do operador. A ausência de um VRP, expressa por NotFound, não equivale à constatação de que o anúncio é ilegítimo. A iniciativa MANRS também inclui o uso da RPKI entre as técnicas de filtragem de anúncios BGP apresentadas em seu guia para operadores de rede.

Adoção global e cenário no Brasil

Em fevereiro de 2026, 60,3% das rotas IPv4 e 60,9% das rotas IPv6 observadas em um levantamento global publicado pelo APNIC eram classificadas como válidas pela validação de origem baseada em RPKI. A cobertura por ROAs e a aplicação de filtros são medidas distintas: a existência de uma autorização não garante que todas as redes rejeitem os anúncios inválidos. O monitor do NIST acompanha a implantação por meio da classificação de pares de prefixo e ASN de origem observados em dados de roteamento BGP, com análises separadas para IPv4 e IPv6.

No Brasil, o Registro.br, serviço do NIC.br, disponibilizou a RPKI aos titulares de recursos de numeração em dezembro de 2019. A implantação utiliza o modelo delegado, no qual a organização opera uma autoridade certificadora, por exemplo com o programa Krill, e pode utilizar o serviço de publicação do Registro.br para disponibilizar seus objetos.

Em fevereiro de 2019, o IX.br ativou filtros em seus servidores de rotas de São Paulo para descartar anúncios classificados como inválidos pela RPKI. Essa filtragem incide sobre os anúncios tratados por esses servidores e está sujeita às limitações da validação de origem, que não autentica todo o caminho de sistemas autônomos.

Limitações e evolução: ASPA e BGPsec

A validação de origem verifica a autorização para o ASN que aparece como origem da rota, mas não autentica os demais sistemas autônomos do atributo AS_PATH. Um atacante que insira o ASN autorizado como origem de um caminho forjado pode produzir um anúncio classificado como Valid, desde que o prefixo e seu comprimento também sejam autorizados. Vazamentos de rotas que preservam uma origem autorizada podem igualmente passar pela ROV.

Os mecanismos propostos ou especificados para ampliar a proteção do caminho incluem:

Ver também

Referências

  1. 1 2 3 4 M. Lepinski; S. Kent (fevereiro de 2012). «RFC 6480: An Infrastructure to Support Secure Internet Routing». RFC Editor (em inglês). Consultado em 29 de outubro de 2026
  2. 1 2 3 4 5 J. Snijders; B. Maddison; M. Lepinski; D. Kong; S. Kent (maio de 2024). «RFC 9582: A Profile for Route Origin Authorizations (ROAs)». RFC Editor (em inglês). Consultado em 29 de outubro de 2026
  3. ↑ NIC.br. «RPKI». Boas Práticas para a Internet no Brasil. Consultado em 29 de outubro de 2026. Cópia arquivada em 12 de junho de 2026
  4. ↑ NLnet Labs. «Introduction». RPKI documentation (em inglês). Consultado em 29 de outubro de 2026. Cópia arquivada em 29 de setembro de 2026
  5. ↑ G. Huston; S. Weiler; G. Michaelson; S. Kent; T. Bruijnzeels (agosto de 2019). «RFC 8630: Resource Public Key Infrastructure (RPKI) Trust Anchor Locator». RFC Editor (em inglês). Consultado em 29 de outubro de 2026. Cópia arquivada em 25 de abril de 2026
  6. ↑ C. Lynn; S. Kent; K. Seo (junho de 2004). «RFC 3779: X.509 Extensions for IP Addresses and AS Identifiers». RFC Editor (em inglês). Consultado em 29 de outubro de 2026. Cópia arquivada em 25 de abril de 2026
  7. ↑ G. Huston; G. Michaelson; R. Loomans (fevereiro de 2012). «RFC 6487: A Profile for X.509 PKIX Resource Certificates». RFC Editor (em inglês). Consultado em 29 de outubro de 2026. Cópia arquivada em 20 de outubro de 2026
  8. 1 2 G. Huston; R. Loomans; G. Michaelson (fevereiro de 2012). «RFC 6481: A Profile for Resource Certificate Repository Structure». RFC Editor (em inglês). Consultado em 29 de outubro de 2026. Cópia arquivada em 20 de outubro de 2026
  9. ↑ T. Bruijnzeels; O. Muravskiy; B. Weber; R. Austein (julho de 2017). «RFC 8182: The RPKI Repository Delta Protocol (RRDP)». RFC Editor (em inglês). Consultado em 29 de outubro de 2026. Cópia arquivada em 20 de outubro de 2026
  10. 1 2 Y. Gilad; S. Goldberg; K. Sriram; J. Snijders; B. Maddison (outubro de 2022). «RFC 9319: The Use of maxLength in the Resource Public Key Infrastructure (RPKI)». RFC Editor (em inglês). Consultado em 29 de outubro de 2026. Cópia arquivada em 20 de outubro de 2026
  11. 1 2 3 4 5 P. Mohapatra; J. Scudder; D. Ward; R. Bush; R. Austein (janeiro de 2013). «RFC 6811: BGP Prefix Origin Validation». RFC Editor (em inglês). Consultado em 29 de outubro de 2026. Cópia arquivada em 17 de agosto de 2026
  12. 1 2 R. Bush (setembro de 2018). «RFC 8481: Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI)». RFC Editor (em inglês). Consultado em 29 de outubro de 2026. Cópia arquivada em 6 de janeiro de 2026
  13. 1 2 R. Bush; R. Austein (setembro de 2017). «RFC 8210: The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1». RFC Editor (em inglês). Consultado em 29 de outubro de 2026. Cópia arquivada em 8 de outubro de 2026
  14. 1 2 3 NLnet Labs. «Routinator» (em inglês). Consultado em 29 de outubro de 2026. Cópia arquivada em 16 de outubro de 2026
  15. ↑ Projeto OpenBSD. «rpki-client» (em inglês). Consultado em 29 de outubro de 2026. Cópia arquivada em 1 de setembro de 2026
  16. ↑ NIC México. «FORT Validator: RPKI Relying Party» (em inglês). Consultado em 29 de outubro de 2026
  17. ↑ NIC México; LACNIC. «FORT Validator». FORT Project (em inglês). Consultado em 29 de outubro de 2026. Cópia arquivada em 24 de setembro de 2026
  18. ↑ «StayRTR». GitHub (em inglês). Consultado em 29 de outubro de 2026. Cópia arquivada em 28 de agosto de 2026
  19. ↑ R. Bush (janeiro de 2014). «RFC 7115: Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)». RFC Editor (em inglês). Consultado em 29 de outubro de 2026. Cópia arquivada em 30 de setembro de 2026
  20. ↑ MANRS. «MANRS Implementation Guide for Network Operators» (em inglês). Consultado em 29 de outubro de 2026. Cópia arquivada em 1 de outubro de 2026
  21. ↑ Sheryl Hermoso (24 de março de 2026). «Routing security in APAC: Trends from the APNIC region». APNIC Blog (em inglês). Consultado em 29 de outubro de 2026. Cópia arquivada em 19 de abril de 2026
  22. ↑ National Institute of Standards and Technology. «NIST RPKI Monitor: Methodology» (em inglês). Consultado em 29 de outubro de 2026. Cópia arquivada em 24 de janeiro de 2026
  23. 1 2 NIC.br. «Relatório de atividades 2019» (PDF). pp. 27, 38. Consultado em 29 de outubro de 2026. Cópia arquivada (PDF) em 12 de abril de 2026
  24. ↑ LACNIC. «Laboratório de RPKI delegado: instruções» (PDF). pp. 1–3. Consultado em 29 de outubro de 2026. Cópia arquivada (PDF) em 27 de junho de 2024
  25. 1 2 Alexander Azimov; Eugene Bogomazov; Randy Bush; Keyur Patel; Job Snijders; Kotikalapudi Sriram (16 de outubro de 2026). «BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects: draft-ietf-sidrops-aspa-verification-29». Internet Engineering Task Force (em inglês). Consultado em 29 de outubro de 2026
  26. ↑ Job Snijders; Alexander Azimov; Eugene Uskov; Randy Bush; Russ Housley; Ben Maddison (29 de outubro de 2026). «A Profile for Autonomous System Provider Authorization: draft-ietf-sidrops-aspa-profile-30». Internet Engineering Task Force (em inglês). Consultado em 29 de outubro de 2026
  27. ↑ M. Lepinski; K. Sriram (setembro de 2017). «RFC 8205: BGPsec Protocol Specification». RFC Editor (em inglês). Consultado em 29 de outubro de 2026. Cópia arquivada em 28 de fevereiro de 2026
  28. ↑ K. Sriram (abril de 2018). «RFC 8374: BGPsec Design Choices and Summary of Supporting Discussions». RFC Editor (em inglês). Consultado em 29 de outubro de 2026. Cópia arquivada em 20 de setembro de 2025