Uma Autorização de Origem de Rota é um documento digitalmente assinado RPKI um registo que identifica qual o ASN autorizado a originar um prefixo IP no BGP. É criado pela organização que detém os recursos de números da Internet relevantes, ou em seu nome. Uma ROA contém normalmente três elementos essenciais: o prefixo IP, o ASN de origem autorizado e o comprimento máximo do prefixo que o ASN pode anunciar. Por exemplo, uma organização pode controlar o prefixo IPv4 203.0.113.0/24 e usar o AS64500 para o anunciar. Uma ROA correspondente pode autorizar o AS64500 a originar esse /24. Em termos simples, o registo comunica a seguinte instrução ao ecossistema de roteamento: “Este ASN está autorizado a anunciar este prefixo.” As redes que realizam validação RPKI podem então comparar o registo com o que observam no BGP. Uma ROA não transfere a propriedade de um bloco de endereços IP. Não substitui um contrato, uma entrada num registo, um registo de alocação ou um acordo de transferência de IPv4. Apenas publica uma autorização relacionada com a origem de uma rota. O controlo legal e a autorização de roteamento estão relacionados, mas não são a mesma coisa. As ROAs podem ser criadas para recursos IPv4 e IPv6. O formato é semelhante, embora os comprimentos dos prefixos e o desenho operacional possam diferir. As redes IPv4 trabalham frequentemente com prefixos como /24, enquanto as redes IPv6 anunciam comumente agregações como /32, /36, /48 ou outro comprimento adequado à sua alocação e plano de roteamento.
Por que é necessária uma ROA?
Sem um ROA, outras redes não têm autorização baseada no RPKI para confirmar que um ASN de origem BGP está autorizado a anunciar um prefixo. A rota pode ainda ser legítima, mas geralmente produzirá um resultado "Not Found" durante a validação do RPKI, pois não há autorização correspondente. Um resultado "Not Found" não é automaticamente um problema de roteamento. Muitas rotas válidas na Internet não possuem ROAs. No entanto, quando uma organização publica um ROA preciso, fornece às outras redes um sinal mais forte que pode ser utilizado para distinguir a origem esperada de uma origem não autorizada ou mal configurada. Um ROA torna-se especialmente útil quando um prefixo é valioso, crítico para o negócio ou amplamente anunciado. Uma empresa pode utilizar o seu próprio espaço de endereços para serviços públicos, uma plataforma em nuvem pode anunciar infraestruturas de clientes, ou um fornecedor de alojamento pode anunciar grandes intervalos de endereços a partir de múltiplas localizações. Nestas situações, uma origem incorreta pode afetar muitos utilizadores e serviços. Os ROAs também ajudam durante a resposta a incidentes. Se um prefixo aparecer subitamente a partir de um ASN inesperado, um operador de rede pode verificar o estado do RPKI e determinar rapidamente se o anúncio entra em conflito com a intenção publicada pelo detentor dos recursos. Isto não explica todos os detalhes do incidente, mas fornece um ponto de partida importante para a investigação. Para organizações que utilizam vários fornecedores de acesso, um ROA pode fornecer uma autorização consistente, independentemente do fornecedor que transporta a rota. O fornecedor pode mudar, mas o ASN de origem pode permanecer o mesmo. Nesse caso, o ROA geralmente não precisa de ser alterado apenas porque o caminho de trânsito mudou.
Como funciona um ROA com BGP?
O BGP distribui anúncios de rotas entre sistemas autónomos. Um anúncio de rota inclui geralmente um prefixo IP e um ASN de origem, juntamente com outras informações de caminho e política. O ASN de origem é o sistema autónomo que se declara como a fonte da rota. A validação RPKI opera em conjunto com o BGP. Um validador recupera dados de autorização assinados do sistema RPKI e verifica se os registos são autênticos e atuais. Em seguida, cria um conjunto de dados validado que pode ser utilizado por routers, servidores de rotas ou sistemas de política de roteamento. Quando uma rede recebe um anúncio BGP, compara o prefixo anunciado e o ASN de origem com as informações ROA validadas. Existem três resultados principais. O anúncio pode ser Válido, Inválido ou Não Encontrado. Um resultado Válido significa que o anúncio está abrangido por uma ROA e que o ASN de origem está autorizado. Um resultado Inválido significa que existe uma ROA relevante, mas o anúncio entra em conflito com ela. Um resultado Não Encontrado significa que não foi encontrada nenhuma ROA aplicável. A rede que recebe decide o que fazer com estes resultados. Alguns operadores rejeitam rotas inválidas. Outros atribuem-lhes uma preferência mais baixa, geram alertas ou aplicam políticas diferentes consoante a origem. Não existe uma política universal única para todas as redes, mas muitos provedores tratam os anúncios inválidos como um problema grave de segurança de roteamento. O ponto importante é que a ROA não controla diretamente a Internet global. Publica informações de autorização. O efeito prático depende de outras redes recuperarem, validarem e utilizarem essas informações nas suas decisões de roteamento.
As três partes principais de um ROA
A primeira parte de um ROA é o prefixo IP que está autorizado, o qual identifica o intervalo de endereços que o ASN de origem pode anunciar. Para IPv4, um prefixo pode ser 198.51.100.0/24; para IPv6, pode ser 2001:db8:1234::/48. O prefixo deve corresponder a um recurso que a organização está autorizada a gerir através do registo relevante ou da relação de patrocínio. O prefixo deve ser introduzido com precisão, pois um erro tipográfico, um limite de rede incorreto ou um comprimento de prefixo errado podem tornar o ROA ineficaz ou autorizar um intervalo diferente daquele que se pretende.
A segunda parte é o ASN de origem autorizado a originar o prefixo, correspondendo ao ASN que aparece como origem do anúncio BGP. Se uma empresa possui um bloco de endereços mas o anuncia através do ASN de um fornecedor de trânsito, a origem correta depende do desenho de roteamento efetivo. O ASN no ROA deve normalmente ser o ASN que origina a rota, e não simplesmente o ASN do transportador ascendente. Esta distinção é importante porque um fornecedor de trânsito pode transportar uma rota sem ser a sua origem; se o ASN do cliente origina o prefixo e o fornecedor apenas o transporta, o ASN do cliente é geralmente o valor que necessita de ser autorizado.
A terceira parte é o comprimento máximo do prefixo, frequentemente designado maxLength, que define quão específico pode ser um anúncio enquanto permanece coberto pela ROA. Suponha que uma ROA autorize 198.51.100.0/24 com um comprimento máximo de /24: a ASN autorizada pode anunciar o /24 exato, mas não está autorizada a anunciar sub-prefixos mais específicos, como /25 ou /26. Se o mesmo prefixo for autorizado com um comprimento máximo de /26, os anúncios para o /24, /25 e /26 podem ser considerados cobertos, dependendo da rota exata e das regras de validação. Isto proporciona flexibilidade, mas também permite anúncios mais específicos. O comprimento máximo deve, portanto, refletir o plano de roteamento real, pois defini-lo demasiado curto pode fazer com que rotas mais específicas legítimas se tornem Inválidas, enquanto defini-lo demasiado longo pode autorizar anúncios que a organização nunca pretendeu permitir.
Porque é que o maxLength importa?
O comprimento máximo do prefixo é uma das definições ROA mais importantes e mais frequentemente mal compreendidas, controlando o nível de especificidade que a ASN autorizada pode utilizar ao anunciar o recurso. Muitos operadores de rede anunciam um prefixo agregado para reduzir o crescimento da tabela de roteamento; por exemplo, uma organização pode deter um /20 mas anunciá-lo como um único agregado. Em alguns casos, a organização também pode precisar de anunciar prefixos mais específicos para engenharia de tráfego, conectividade regional ou separação de serviços. Se a ROA abranger apenas o agregado enquanto a rede anuncia rotas mais específicas, essas rotas podem ser classificadas como Inválidas. O anúncio BGP pode ser tecnicamente correto do ponto de vista da organização, mas não corresponde à autorização publicada no RPKI. Por outro lado, autorizar todas as rotas mais específicas possíveis pode enfraquecer a precisão da política, pois um /20 autorizado com um comprimento máximo extremamente amplo permite que um sub-prefixo muito menor apareça como autorizado, mesmo que esteja fora do planeamento previsto. Uma abordagem prática consiste em autorizar apenas os comprimentos de prefixo que a rede espera genuinamente anunciar com base no seu plano de endereçamento, requisitos dos fornecedores, design de failover e estratégia de engenharia de tráfego. As alterações ao comprimento máximo devem ser testadas cuidadosamente, confirmando que todos os anúncios em produção retornam o resultado de validação esperado antes de aplicar filtragem estrita.
ROAs for IPv4 and IPv6
As ROAs podem ser criadas para redes IPv4 e IPv6, sendo o princípio de segurança subjacente o mesmo: associar um prefixo a uma ASN de origem autorizada. A principal diferença operacional reside na estrutura de endereçamento. Os recursos IPv4 são escassos e são frequentemente anunciados em prefixos relativamente pequenos, sendo /24 um tamanho mínimo comum de anúncio na Internet pública. As redes IPv6 recebem geralmente alocações mais amplas e podem dividi-las em segmentos de site, serviço ou geográficos, anunciando um agregado enquanto utilizam vários prefixos internos. A ROA deve estar alinhada com os prefixos anunciados publicamente. Os operadores IPv6 não devem assumir que um espaço de endereçamento grande elimina riscos de roteamento, pois um anúncio IPv6 não autorizado pode ainda causar problemas de alcançabilidade, redirecionamento de tráfego ou roteamento global inconsistente. O RPKI oferece aos operadores IPv6 a mesma oportunidade de publicar autorização de origem que aos operadores IPv4. Antes de criar ROAs IPv6, a equipa de rede deve documentar quais prefixos agregados serão anunciados, se são esperados anúncios mais específicos e qual ASN os originará, evitando registos que sejam demasiado restritivos ou desnecessariamente abrangentes.
Quando Deves Criar um ROA?
Deve ser criada uma ROA antes de anunciar um prefixo em produção sempre que o detentor dos recursos tenha um plano de roteamento claro, dando às redes validadoras tempo para obter a informação antes que a rota se torne amplamente visível. As organizações devem também rever as ROAs quando receberem uma nova alocação, adquirirem um bloco IPv4, concluírem uma transferência de endereços, alterarem o ASN de origem ou começarem a utilizar uma nova alocação IPv6, pois estes eventos alteram a relação entre o prefixo e a rede de origem. Uma migração de fornecedor é outro gatilho comum: se a organização mantiver o mesmo ASN de origem e apenas alterar o operador upstream, a ROA pode permanecer válida; se a migração alterar o ASN de origem, o registo deve ser atualizado antes ou simultaneamente à alteração do roteamento. As ROAs devem ser revistas durante fusões, aquisições, mudanças de data centers, alterações no patrocínio do ASN e grandes redesigns de rede, para garantir que a autorização pública corresponde à realidade operacional. Uma revisão periódica é útil mesmo quando não ocorreu nenhuma mudança conhecida, pois a documentação da rede fica desatualizada, as responsabilidades do pessoal mudam e as autorizações antigas podem permanecer ativas muito depois do projeto de roteamento original ter sido substituído.
Erros Comuns na Configuração do ROA
Um dos erros mais comuns é introduzir o ASN de origem errado, o que ocorre quando os engenheiros confundem o ASN do cliente com o ASN do provedor de trânsito ou quando um ASN antigo permanece na configuração após uma migração. Outro erro comum é esquecer de atualizar a ROA após uma transferência de IPv4, em que o novo detentor anuncia o prefixo a partir do seu próprio ASN, enquanto a autorização antiga ainda aponta para a origem anterior, fazendo com que a rota se torne Inválida. Um comprimento máximo incorreto cria problemas semelhantes quando uma organização autoriza apenas um /24 mas mais tarde anuncia um /25 para engenharia de tráfego. Algumas organizações criam múltiplas ROAs sobrepostas sem documentar o seu propósito; embora válidas em certos projetos, podem produzir resultados inesperados e complicar a resolução de problemas. Não remover registos obsoletos permite que um ASN origine um prefixo muito tempo depois de o projeto da rede ter mudado. Finalmente, algumas organizações ativam a rejeição estrita de rotas Inválidas sem testar primeiro os seus próprios anúncios; os prefixos de produção, os comprimentos máximos e os ASNs de origem devem ser sempre verificados antes de confiar no filtragem automatizada.
ROA and IPv4 Transfer Planning
As transferências de IPv4 exigem atenção especial porque o titular administrativo, o acordo de patrocínio e a origem do roteamento podem mudar em diferentes etapas do processo. Antes da transferência, o titular atual deve documentar as ROAs existentes e confirmar qual ASN origina atualmente o prefixo, enquanto o comprador prepara as informações de origem pretendidas e coordena-se com os provedores de trânsito. Durante a transição, ambas as partes precisam de um plano claro para atualizar ou substituir os registos de autorização: manter a ROA anterior ativa por tempo demais autoriza a origem antiga após a transferência, enquanto a remover prematuramente faz com que a rota existente se torne Inválida antes que a nova rota esteja pronta. O processo exato depende do registo, tipo de recurso, contrato de transferência e desenho operacional, tornando a RPKI um item essencial de verificação ao lado da verificação do registo, revisão contratual, anúncios BGP, objetos de rota, DNS reverso e avaliação de reputação. Um verificador público de prontidão ajuda a identificar a ASN de origem atual, o estado da RPKI, as informações do registo e a visibilidade BGP de um prefixo para pré-verificações técnicas, embora não confirme a propriedade legal nem garanta a elegibilidade para transferência.
Alterações na ROA e ASN
Uma alteração de ASN impacta diretamente a validação RPKI. Se um prefixo anteriormente anunciado pela AS64500 passar a ser anunciado pela AS64510, o ROA deve autorizar a nova origem antes que o anúncio BGP possa ser aceite como Válido. Isto é particularmente importante quando uma organização transita de uma ASN gerida por um fornecedor para a sua própria ASN ou altera o seu acordo com um LIR patrocinador, exigindo que a relação no registo e a autorização de roteamento sejam revistos em conjunto. Uma transição cuidadosamente planeada pode envolver a autorização temporária das origens antiga e nova, criando uma janela de migração controlada, desde que seja documentada e a autorização obsoleta seja removida após a conclusão. A equipa de rede deve testar a ordem das operações antes de efetuar alterações em produção, garantindo que a nova autorização é publicada e validada antes de anunciar a nova rota BGP.
Como Verificar se um ROA Está Funcionando?
A primeira verificação consiste em confirmar que o ROA contém o prefixo pretendido, o ASN de origem e o comprimento máximo do prefixo, através do portal RIR relevante, da interface LIR patrocinadora ou do sistema de gestão RPKI. Em seguida, compare a autorização com o anúncio BGP real, verificando se o comprimento do prefixo anunciado está coberto e se o ASN de origem corresponde ao ROA. Um validador RPKI externo pode então confirmar o estado público, onde um anúncio corretamente configurado retorna como Válido. Se o resultado for Inválido, inspecione primeiro o ASN de origem e o comprimento do prefixo; se for Não Encontrado, verifique se o ROA foi publicado e se os validadores tiveram tempo para o recuperar. Os resultados não são atualizados instantaneamente porque os repositórios, validadores e sistemas de roteamento dependem de intervalos de atualização, tornando-se normais pequenos atrasos durante a propagação. Comparar múltiplas fontes públicas — incluindo dados de registo, resultados dos validadores e observações BGP atuais — evita depender de informações em cache e fornece uma visão completa.
O que acontece quando um ROA é inválido?
Quando um anúncio BGP entra em conflito com uma ROA existente, os validadores RPKI classificam-no como Inválido. A rota não é automaticamente removida da Internet global, mas as redes que aplicam políticas baseadas em RPKI podem rejeitá-la ou atribuir-lhe uma preferência mais baixa. O impacto operacional depende da abrangência da aplicação: algumas redes filtram estritamente, enquanto outras utilizam o estado para monitorização, o que significa que uma rota Inválida pode permanecer visível em partes da Internet, tornando-se inacessível noutras. Se uma rota legítima se tornar Inválida, a organização deve tratá-la como um problema de configuração urgente, priorizando a revisão do ASN de origem, do comprimento do prefixo anunciado e do comprimento máximo da ROA. A rota não deve ser assumida como maliciosa, pois a maioria dos resultados Inválidos resulta de erros rotineiros, como migrações incompletas, registos desatualizados, detalhes incorretos do fornecedor ou anúncios acidentais de prefixos mais específicos. Após a correção, os sistemas necessitam de tempo para atualizar, e a equipa de rede deve monitorizar a rota até que esta se estabilize em todos os pontos de observação.
Como as organizações devem gerir as ROAs?
A gestão de ROA exige um proprietário claro, seja a equipa de engenharia de rede, a equipa de segurança, o LIR patrocinador, o fornecedor de serviços geridos ou outro grupo responsável pelos recursos de números de Internet. A organização deve manter um inventário que detalhe cada prefixo, ASN de origem, comprimento máximo, locais de anúncio e contactos responsáveis, para simplificar as revisões de alterações e as respostas a incidentes. As alterações às ROAs devem ser integradas nos procedimentos padrão de alteração de rede, tratando o RPKI como um requisito explícito durante migrações de ASN, mudanças de provedor, transferências de IPv4 ou implementações de IPv6. A monitorização e os alertas devem ser configurados para resultados Inválidos, origens inesperadas, autorizações removidas ou variações na visibilidade BGP. Crucialmente, as organizações devem evitar autorizações excessivamente amplas: as ROAs precisas são mais fáceis de compreender, mais simples de auditar e muito menos propensas a permitir anúncios não intencionais.
Perguntas frequentes
Um ROA é o mesmo que um documento de propriedade de IP?
Não. Uma ROA é uma autorização de roteamento que indica qual ASN pode originar um prefixo no BGP. Não substitui registos de registo, contratos, documentos de transferência ou provas de propriedade legal.
É possível que um prefixo tenha mais de um ROA?
Sim. Múltiplas ROAs podem ser adequadas quando um prefixo é intencionalmente originado por mais do que uma ASN ou quando uma migração controlada requer autorização temporária para múltiplas origens, embora os registos sobrepostos devam ser cuidadosamente documentados.
Um ROA anuncia o meu prefixo no BGP?
Não. A criação de um ROA não gera um anúncio BGP; a rede deve ainda configurar o BGP através dos seus routers e fornecedores de acesso.
É necessário que um fornecedor de trânsito esteja listado no ROA?
Normalmente, o ROA deve identificar o ASN que origina a rota. Um fornecedor que apenas transporta a rota não é necessariamente o ASN de origem, e o valor correto depende da arquitetura de roteamento real.
Quanto tempo demora uma ROA para se tornar visível?
O timing depende do sistema RIR, do repositório de publicação, dos intervalos de atualização do validador e do cache. As atualizações são frequentemente visíveis relativamente rápido, mas as alterações em produção devem permitir tempo suficiente para a validação.
Cada prefixo IPv4 e IPv6 deve ter uma ROA?
Recomenda-se fortemente a publicação de ROAs precisos para os prefixos anunciados no BGP. A organização deve primeiro confirmar o seu desenho de roteamento para que a autorização não torne inválidos, acidentalmente, anúncios legítimos.
Um ROA pode proteger contra todos os ataques BGP?
Não. Uma ROA suporta principalmente a validação de origem. Não valida todas as partes do caminho BGP, não impede todos os vazamentos de rotas, não criptografa o tráfego nem garante que o tráfego siga uma rota física segura.
Uma Autorização de Origem de Rota (ROA) é um componente central do RPKI, estabelecendo uma relação criptograficamente assinada entre um prefixo IP e o ASN autorizado a originar esse prefixo no BGP. O registo inclui normalmente o prefixo, o ASN de origem e um comprimento máximo de prefixo — cada um dos quais desempenha um papel decisivo na identificação do recurso, na permissão da origem e na definição do quão específico pode ser o anúncio. As ROAs precisas ajudam as redes a identificar anúncios não autorizados ou mal configurados, sendo vitais durante transferências de IPv4, alterações de ASN, migrações de provedores, implementações de IPv6 e operações em redes multi-homed. Ao mesmo tempo, uma ROA não constitui prova de propriedade legal nem uma solução autónoma de segurança de roteamento; funciona melhor em conjunto com registos de base de dados precisos, configurações disciplinadas do BGP, dados IRR, monitorização de rotas e processos documentados de alteração. Para qualquer organização que anuncie espaço público IPv4 ou IPv6, a regra prática é simples: publicar apenas as origens que se pretende utilizar, autorizar apenas os comprimentos de prefixo que realmente se planeia anunciar e rever os registos sempre que ocorram alterações na rede. Isto mantém os dados do RPKI alinhados com o ambiente real de roteamento e reduz a probabilidade de uma rota legítima ser classificada como Inválida.