{"id":1102,"date":"2026-09-09T02:25:09","date_gmt":"2026-09-09T02:25:09","guid":{"rendered":"https:\/\/junglelabs.uk\/"},"modified":"2026-09-09T02:25:09","modified_gmt":"2026-09-09T02:25:09","slug":"what-is-a-roa-in-rpki","status":"publish","type":"post","link":"https:\/\/junglelabs.uk\/pt\/what-is-a-roa-in-rpki\/","title":{"rendered":"O que \u00e9 um ROA no RPKI? Como funciona a Autoriza\u00e7\u00e3o de Origem de Rotas"},"content":{"rendered":"

Uma Autoriza\u00e7\u00e3o de Origem de Rota \u00e9 um documento digitalmente assinado RPKI<\/a> um registo que identifica qual o ASN autorizado a originar um prefixo IP no BGP. \u00c9 criado pela organiza\u00e7\u00e3o que det\u00e9m os recursos de n\u00fameros da Internet relevantes, ou em seu nome. Uma ROA cont\u00e9m normalmente tr\u00eas elementos essenciais: o prefixo IP, o ASN de origem autorizado e o comprimento m\u00e1ximo do prefixo que o ASN pode anunciar. Por exemplo, uma organiza\u00e7\u00e3o 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\u00e7\u00e3o ao ecossistema de roteamento: \u201cEste ASN est\u00e1 autorizado a anunciar este prefixo.\u201d As redes que realizam valida\u00e7\u00e3o RPKI podem ent\u00e3o comparar o registo com o que observam no BGP. Uma ROA n\u00e3o transfere a propriedade de um bloco de endere\u00e7os IP. N\u00e3o substitui um contrato, uma entrada num registo, um registo de aloca\u00e7\u00e3o ou um acordo de transfer\u00eancia de IPv4. Apenas publica uma autoriza\u00e7\u00e3o relacionada com a origem de uma rota. O controlo legal e a autoriza\u00e7\u00e3o de roteamento est\u00e3o relacionados, mas n\u00e3o s\u00e3o a mesma coisa. As ROAs podem ser criadas para recursos IPv4 e IPv6. O formato \u00e9 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\u00e7\u00f5es como \/32, \/36, \/48 ou outro comprimento adequado \u00e0 sua aloca\u00e7\u00e3o e plano de roteamento.<\/p>\n\n\n\n

Por que \u00e9 necess\u00e1ria uma ROA?<\/h2>\n\n\n\n

Sem um ROA, outras redes n\u00e3o t\u00eam autoriza\u00e7\u00e3o baseada no RPKI para confirmar que um ASN de origem BGP est\u00e1 autorizado a anunciar um prefixo. A rota pode ainda ser leg\u00edtima, mas geralmente produzir\u00e1 um resultado \"Not Found\" durante a valida\u00e7\u00e3o do RPKI, pois n\u00e3o h\u00e1 autoriza\u00e7\u00e3o correspondente. Um resultado \"Not Found\" n\u00e3o \u00e9 automaticamente um problema de roteamento. Muitas rotas v\u00e1lidas na Internet n\u00e3o possuem ROAs. No entanto, quando uma organiza\u00e7\u00e3o publica um ROA preciso, fornece \u00e0s outras redes um sinal mais forte que pode ser utilizado para distinguir a origem esperada de uma origem n\u00e3o autorizada ou mal configurada. Um ROA torna-se especialmente \u00fatil quando um prefixo \u00e9 valioso, cr\u00edtico para o neg\u00f3cio ou amplamente anunciado. Uma empresa pode utilizar o seu pr\u00f3prio espa\u00e7o de endere\u00e7os para servi\u00e7os p\u00fablicos, uma plataforma em nuvem pode anunciar infraestruturas de clientes, ou um fornecedor de alojamento pode anunciar grandes intervalos de endere\u00e7os a partir de m\u00faltiplas localiza\u00e7\u00f5es. Nestas situa\u00e7\u00f5es, uma origem incorreta pode afetar muitos utilizadores e servi\u00e7os. Os ROAs tamb\u00e9m 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\u00fancio entra em conflito com a inten\u00e7\u00e3o publicada pelo detentor dos recursos. Isto n\u00e3o explica todos os detalhes do incidente, mas fornece um ponto de partida importante para a investiga\u00e7\u00e3o. Para organiza\u00e7\u00f5es que utilizam v\u00e1rios fornecedores de acesso, um ROA pode fornecer uma autoriza\u00e7\u00e3o 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\u00e3o precisa de ser alterado apenas porque o caminho de tr\u00e2nsito mudou.<\/p>\n\n\n\n

Como funciona um ROA com BGP?<\/h2>\n\n\n\n

O BGP distribui an\u00fancios de rotas entre sistemas aut\u00f3nomos. Um an\u00fancio de rota inclui geralmente um prefixo IP e um ASN de origem, juntamente com outras informa\u00e7\u00f5es de caminho e pol\u00edtica. O ASN de origem \u00e9 o sistema aut\u00f3nomo que se declara como a fonte da rota. A valida\u00e7\u00e3o RPKI opera em conjunto com o BGP. Um validador recupera dados de autoriza\u00e7\u00e3o assinados do sistema RPKI e verifica se os registos s\u00e3o aut\u00eanticos e atuais. Em seguida, cria um conjunto de dados validado que pode ser utilizado por routers, servidores de rotas ou sistemas de pol\u00edtica de roteamento. Quando uma rede recebe um an\u00fancio BGP, compara o prefixo anunciado e o ASN de origem com as informa\u00e7\u00f5es ROA validadas. Existem tr\u00eas resultados principais. O an\u00fancio pode ser V\u00e1lido, Inv\u00e1lido ou N\u00e3o Encontrado. Um resultado V\u00e1lido significa que o an\u00fancio est\u00e1 abrangido por uma ROA e que o ASN de origem est\u00e1 autorizado. Um resultado Inv\u00e1lido significa que existe uma ROA relevante, mas o an\u00fancio entra em conflito com ela. Um resultado N\u00e3o Encontrado significa que n\u00e3o foi encontrada nenhuma ROA aplic\u00e1vel. A rede que recebe decide o que fazer com estes resultados. Alguns operadores rejeitam rotas inv\u00e1lidas. Outros atribuem-lhes uma prefer\u00eancia mais baixa, geram alertas ou aplicam pol\u00edticas diferentes consoante a origem. N\u00e3o existe uma pol\u00edtica universal \u00fanica para todas as redes, mas muitos provedores tratam os an\u00fancios inv\u00e1lidos como um problema grave de seguran\u00e7a de roteamento. O ponto importante \u00e9 que a ROA n\u00e3o controla diretamente a Internet global. Publica informa\u00e7\u00f5es de autoriza\u00e7\u00e3o. O efeito pr\u00e1tico depende de outras redes recuperarem, validarem e utilizarem essas informa\u00e7\u00f5es nas suas decis\u00f5es de roteamento.<\/p>\n\n\n\n

As tr\u00eas partes principais de um ROA<\/h2>\n\n\n\n

A primeira parte de um ROA \u00e9 o prefixo IP que est\u00e1 autorizado, o qual identifica o intervalo de endere\u00e7os 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\u00e7\u00e3o est\u00e1 autorizada a gerir atrav\u00e9s do registo relevante ou da rela\u00e7\u00e3o de patroc\u00ednio. O prefixo deve ser introduzido com precis\u00e3o, pois um erro tipogr\u00e1fico, 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.<\/p>\n\n\n\n

A segunda parte \u00e9 o ASN de origem autorizado a originar o prefixo, correspondendo ao ASN que aparece como origem do an\u00fancio BGP. Se uma empresa possui um bloco de endere\u00e7os mas o anuncia atrav\u00e9s do ASN de um fornecedor de tr\u00e2nsito, a origem correta depende do desenho de roteamento efetivo. O ASN no ROA deve normalmente ser o ASN que origina a rota, e n\u00e3o simplesmente o ASN do transportador ascendente. Esta distin\u00e7\u00e3o \u00e9 importante porque um fornecedor de tr\u00e2nsito 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 \u00e9 geralmente o valor que necessita de ser autorizado.<\/p>\n\n\n\n

A terceira parte \u00e9 o comprimento m\u00e1ximo do prefixo, frequentemente designado maxLength, que define qu\u00e3o espec\u00edfico pode ser um an\u00fancio enquanto permanece coberto pela ROA. Suponha que uma ROA autorize 198.51.100.0\/24 com um comprimento m\u00e1ximo de \/24: a ASN autorizada pode anunciar o \/24 exato, mas n\u00e3o est\u00e1 autorizada a anunciar sub-prefixos mais espec\u00edficos, como \/25 ou \/26. Se o mesmo prefixo for autorizado com um comprimento m\u00e1ximo de \/26, os an\u00fancios para o \/24, \/25 e \/26 podem ser considerados cobertos, dependendo da rota exata e das regras de valida\u00e7\u00e3o. Isto proporciona flexibilidade, mas tamb\u00e9m permite an\u00fancios mais espec\u00edficos. O comprimento m\u00e1ximo deve, portanto, refletir o plano de roteamento real, pois defini-lo demasiado curto pode fazer com que rotas mais espec\u00edficas leg\u00edtimas se tornem Inv\u00e1lidas, enquanto defini-lo demasiado longo pode autorizar an\u00fancios que a organiza\u00e7\u00e3o nunca pretendeu permitir.<\/p>\n\n\n\n

Porque \u00e9 que o maxLength importa?<\/h2>\n\n\n\n

O comprimento m\u00e1ximo do prefixo \u00e9 uma das defini\u00e7\u00f5es ROA mais importantes e mais frequentemente mal compreendidas, controlando o n\u00edvel 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\u00e7\u00e3o pode deter um \/20 mas anunci\u00e1-lo como um \u00fanico agregado. Em alguns casos, a organiza\u00e7\u00e3o tamb\u00e9m pode precisar de anunciar prefixos mais espec\u00edficos para engenharia de tr\u00e1fego, conectividade regional ou separa\u00e7\u00e3o de servi\u00e7os. Se a ROA abranger apenas o agregado enquanto a rede anuncia rotas mais espec\u00edficas, essas rotas podem ser classificadas como Inv\u00e1lidas. O an\u00fancio BGP pode ser tecnicamente correto do ponto de vista da organiza\u00e7\u00e3o, mas n\u00e3o corresponde \u00e0 autoriza\u00e7\u00e3o publicada no RPKI. Por outro lado, autorizar todas as rotas mais espec\u00edficas poss\u00edveis pode enfraquecer a precis\u00e3o da pol\u00edtica, pois um \/20 autorizado com um comprimento m\u00e1ximo extremamente amplo permite que um sub-prefixo muito menor apare\u00e7a como autorizado, mesmo que esteja fora do planeamento previsto. Uma abordagem pr\u00e1tica consiste em autorizar apenas os comprimentos de prefixo que a rede espera genuinamente anunciar com base no seu plano de endere\u00e7amento, requisitos dos fornecedores, design de failover e estrat\u00e9gia de engenharia de tr\u00e1fego. As altera\u00e7\u00f5es ao comprimento m\u00e1ximo devem ser testadas cuidadosamente, confirmando que todos os an\u00fancios em produ\u00e7\u00e3o retornam o resultado de valida\u00e7\u00e3o esperado antes de aplicar filtragem estrita.<\/p>\n\n\n\n

ROAs for IPv4 and IPv6<\/h2>\n\n\n\n

As ROAs podem ser criadas para redes IPv4 e IPv6, sendo o princ\u00edpio de seguran\u00e7a subjacente o mesmo: associar um prefixo a uma ASN de origem autorizada. A principal diferen\u00e7a operacional reside na estrutura de endere\u00e7amento. Os recursos IPv4 s\u00e3o escassos e s\u00e3o frequentemente anunciados em prefixos relativamente pequenos, sendo \/24 um tamanho m\u00ednimo comum de an\u00fancio na Internet p\u00fablica. As redes IPv6 recebem geralmente aloca\u00e7\u00f5es mais amplas e podem dividi-las em segmentos de site, servi\u00e7o ou geogr\u00e1ficos, anunciando um agregado enquanto utilizam v\u00e1rios prefixos internos. A ROA deve estar alinhada com os prefixos anunciados publicamente. Os operadores IPv6 n\u00e3o devem assumir que um espa\u00e7o de endere\u00e7amento grande elimina riscos de roteamento, pois um an\u00fancio IPv6 n\u00e3o autorizado pode ainda causar problemas de alcan\u00e7abilidade, redirecionamento de tr\u00e1fego ou roteamento global inconsistente. O RPKI oferece aos operadores IPv6 a mesma oportunidade de publicar autoriza\u00e7\u00e3o de origem que aos operadores IPv4. Antes de criar ROAs IPv6, a equipa de rede deve documentar quais prefixos agregados ser\u00e3o anunciados, se s\u00e3o esperados an\u00fancios mais espec\u00edficos e qual ASN os originar\u00e1, evitando registos que sejam demasiado restritivos ou desnecessariamente abrangentes.<\/p>\n\n\n\n

Quando Deves Criar um ROA?<\/strong><\/h2>\n\n\n\n

Deve ser criada uma ROA antes de anunciar um prefixo em produ\u00e7\u00e3o sempre que o detentor dos recursos tenha um plano de roteamento claro, dando \u00e0s redes validadoras tempo para obter a informa\u00e7\u00e3o antes que a rota se torne amplamente vis\u00edvel. As organiza\u00e7\u00f5es devem tamb\u00e9m rever as ROAs quando receberem uma nova aloca\u00e7\u00e3o, adquirirem um bloco IPv4, conclu\u00edrem uma transfer\u00eancia de endere\u00e7os, alterarem o ASN de origem ou come\u00e7arem a utilizar uma nova aloca\u00e7\u00e3o IPv6, pois estes eventos alteram a rela\u00e7\u00e3o entre o prefixo e a rede de origem. Uma migra\u00e7\u00e3o de fornecedor \u00e9 outro gatilho comum: se a organiza\u00e7\u00e3o mantiver o mesmo ASN de origem e apenas alterar o operador upstream, a ROA pode permanecer v\u00e1lida; se a migra\u00e7\u00e3o alterar o ASN de origem, o registo deve ser atualizado antes ou simultaneamente \u00e0 altera\u00e7\u00e3o do roteamento. As ROAs devem ser revistas durante fus\u00f5es, aquisi\u00e7\u00f5es, mudan\u00e7as de data centers, altera\u00e7\u00f5es no patroc\u00ednio do ASN e grandes redesigns de rede, para garantir que a autoriza\u00e7\u00e3o p\u00fablica corresponde \u00e0 realidade operacional. Uma revis\u00e3o peri\u00f3dica \u00e9 \u00fatil mesmo quando n\u00e3o ocorreu nenhuma mudan\u00e7a conhecida, pois a documenta\u00e7\u00e3o da rede fica desatualizada, as responsabilidades do pessoal mudam e as autoriza\u00e7\u00f5es antigas podem permanecer ativas muito depois do projeto de roteamento original ter sido substitu\u00eddo.<\/p>\n\n\n\n

Erros Comuns na Configura\u00e7\u00e3o do ROA<\/h2>\n\n\n\n

Um dos erros mais comuns \u00e9 introduzir o ASN de origem errado, o que ocorre quando os engenheiros confundem o ASN do cliente com o ASN do provedor de tr\u00e2nsito ou quando um ASN antigo permanece na configura\u00e7\u00e3o ap\u00f3s uma migra\u00e7\u00e3o. Outro erro comum \u00e9 esquecer de atualizar a ROA ap\u00f3s uma transfer\u00eancia de IPv4, em que o novo detentor anuncia o prefixo a partir do seu pr\u00f3prio ASN, enquanto a autoriza\u00e7\u00e3o antiga ainda aponta para a origem anterior, fazendo com que a rota se torne Inv\u00e1lida. Um comprimento m\u00e1ximo incorreto cria problemas semelhantes quando uma organiza\u00e7\u00e3o autoriza apenas um \/24 mas mais tarde anuncia um \/25 para engenharia de tr\u00e1fego. Algumas organiza\u00e7\u00f5es criam m\u00faltiplas ROAs sobrepostas sem documentar o seu prop\u00f3sito; embora v\u00e1lidas em certos projetos, podem produzir resultados inesperados e complicar a resolu\u00e7\u00e3o de problemas. N\u00e3o remover registos obsoletos permite que um ASN origine um prefixo muito tempo depois de o projeto da rede ter mudado. Finalmente, algumas organiza\u00e7\u00f5es ativam a rejei\u00e7\u00e3o estrita de rotas Inv\u00e1lidas sem testar primeiro os seus pr\u00f3prios an\u00fancios; os prefixos de produ\u00e7\u00e3o, os comprimentos m\u00e1ximos e os ASNs de origem devem ser sempre verificados antes de confiar no filtragem automatizada.<\/p>\n\n\n\n

ROA and IPv4 Transfer Planning<\/h2>\n\n\n\n

As transfer\u00eancias de IPv4 exigem aten\u00e7\u00e3o especial porque o titular administrativo, o acordo de patroc\u00ednio e a origem do roteamento podem mudar em diferentes etapas do processo. Antes da transfer\u00eancia, o titular atual deve documentar as ROAs existentes e confirmar qual ASN origina atualmente o prefixo, enquanto o comprador prepara as informa\u00e7\u00f5es de origem pretendidas e coordena-se com os provedores de tr\u00e2nsito. Durante a transi\u00e7\u00e3o, ambas as partes precisam de um plano claro para atualizar ou substituir os registos de autoriza\u00e7\u00e3o: manter a ROA anterior ativa por tempo demais autoriza a origem antiga ap\u00f3s a transfer\u00eancia, enquanto a remover prematuramente faz com que a rota existente se torne Inv\u00e1lida antes que a nova rota esteja pronta. O processo exato depende do registo, tipo de recurso, contrato de transfer\u00eancia e desenho operacional, tornando a RPKI um item essencial de verifica\u00e7\u00e3o ao lado da verifica\u00e7\u00e3o do registo, revis\u00e3o contratual, an\u00fancios BGP, objetos de rota, DNS reverso e avalia\u00e7\u00e3o de reputa\u00e7\u00e3o. Um verificador p\u00fablico de prontid\u00e3o ajuda a identificar a ASN de origem atual, o estado da RPKI, as informa\u00e7\u00f5es do registo e a visibilidade BGP de um prefixo para pr\u00e9-verifica\u00e7\u00f5es t\u00e9cnicas, embora n\u00e3o confirme a propriedade legal nem garanta a elegibilidade para transfer\u00eancia.<\/p>\n\n\n\n

Altera\u00e7\u00f5es na ROA e ASN<\/h2>\n\n\n\n

Uma altera\u00e7\u00e3o de ASN impacta diretamente a valida\u00e7\u00e3o 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\u00fancio BGP possa ser aceite como V\u00e1lido. Isto \u00e9 particularmente importante quando uma organiza\u00e7\u00e3o transita de uma ASN gerida por um fornecedor para a sua pr\u00f3pria ASN ou altera o seu acordo com um LIR patrocinador, exigindo que a rela\u00e7\u00e3o no registo e a autoriza\u00e7\u00e3o de roteamento sejam revistos em conjunto. Uma transi\u00e7\u00e3o cuidadosamente planeada pode envolver a autoriza\u00e7\u00e3o tempor\u00e1ria das origens antiga e nova, criando uma janela de migra\u00e7\u00e3o controlada, desde que seja documentada e a autoriza\u00e7\u00e3o obsoleta seja removida ap\u00f3s a conclus\u00e3o. A equipa de rede deve testar a ordem das opera\u00e7\u00f5es antes de efetuar altera\u00e7\u00f5es em produ\u00e7\u00e3o, garantindo que a nova autoriza\u00e7\u00e3o \u00e9 publicada e validada antes de anunciar a nova rota BGP.<\/p>\n\n\n\n

Como Verificar se um ROA Est\u00e1 Funcionando?<\/h2>\n\n\n\n

A primeira verifica\u00e7\u00e3o consiste em confirmar que o ROA cont\u00e9m o prefixo pretendido, o ASN de origem e o comprimento m\u00e1ximo do prefixo, atrav\u00e9s do portal RIR relevante, da interface LIR patrocinadora ou do sistema de gest\u00e3o RPKI. Em seguida, compare a autoriza\u00e7\u00e3o com o an\u00fancio BGP real, verificando se o comprimento do prefixo anunciado est\u00e1 coberto e se o ASN de origem corresponde ao ROA. Um validador RPKI externo pode ent\u00e3o confirmar o estado p\u00fablico, onde um an\u00fancio corretamente configurado retorna como V\u00e1lido. Se o resultado for Inv\u00e1lido, inspecione primeiro o ASN de origem e o comprimento do prefixo; se for N\u00e3o Encontrado, verifique se o ROA foi publicado e se os validadores tiveram tempo para o recuperar. Os resultados n\u00e3o s\u00e3o atualizados instantaneamente porque os reposit\u00f3rios, validadores e sistemas de roteamento dependem de intervalos de atualiza\u00e7\u00e3o, tornando-se normais pequenos atrasos durante a propaga\u00e7\u00e3o. Comparar m\u00faltiplas fontes p\u00fablicas \u2014 incluindo dados de registo, resultados dos validadores e observa\u00e7\u00f5es BGP atuais \u2014 evita depender de informa\u00e7\u00f5es em cache e fornece uma vis\u00e3o completa.<\/p>\n\n\n\n

O que acontece quando um ROA \u00e9 inv\u00e1lido?<\/h2>\n\n\n\n

Quando um an\u00fancio BGP entra em conflito com uma ROA existente, os validadores RPKI classificam-no como Inv\u00e1lido. A rota n\u00e3o \u00e9 automaticamente removida da Internet global, mas as redes que aplicam pol\u00edticas baseadas em RPKI podem rejeit\u00e1-la ou atribuir-lhe uma prefer\u00eancia mais baixa. O impacto operacional depende da abrang\u00eancia da aplica\u00e7\u00e3o: algumas redes filtram estritamente, enquanto outras utilizam o estado para monitoriza\u00e7\u00e3o, o que significa que uma rota Inv\u00e1lida pode permanecer vis\u00edvel em partes da Internet, tornando-se inacess\u00edvel noutras. Se uma rota leg\u00edtima se tornar Inv\u00e1lida, a organiza\u00e7\u00e3o deve trat\u00e1-la como um problema de configura\u00e7\u00e3o urgente, priorizando a revis\u00e3o do ASN de origem, do comprimento do prefixo anunciado e do comprimento m\u00e1ximo da ROA. A rota n\u00e3o deve ser assumida como maliciosa, pois a maioria dos resultados Inv\u00e1lidos resulta de erros rotineiros, como migra\u00e7\u00f5es incompletas, registos desatualizados, detalhes incorretos do fornecedor ou an\u00fancios acidentais de prefixos mais espec\u00edficos. Ap\u00f3s a corre\u00e7\u00e3o, os sistemas necessitam de tempo para atualizar, e a equipa de rede deve monitorizar a rota at\u00e9 que esta se estabilize em todos os pontos de observa\u00e7\u00e3o.<\/p>\n\n\n\n

Como as organiza\u00e7\u00f5es devem gerir as ROAs?<\/h2>\n\n\n\n

A gest\u00e3o de ROA exige um propriet\u00e1rio claro, seja a equipa de engenharia de rede, a equipa de seguran\u00e7a, o LIR patrocinador, o fornecedor de servi\u00e7os geridos ou outro grupo respons\u00e1vel pelos recursos de n\u00fameros de Internet. A organiza\u00e7\u00e3o deve manter um invent\u00e1rio que detalhe cada prefixo, ASN de origem, comprimento m\u00e1ximo, locais de an\u00fancio e contactos respons\u00e1veis, para simplificar as revis\u00f5es de altera\u00e7\u00f5es e as respostas a incidentes. As altera\u00e7\u00f5es \u00e0s ROAs devem ser integradas nos procedimentos padr\u00e3o de altera\u00e7\u00e3o de rede, tratando o RPKI como um requisito expl\u00edcito durante migra\u00e7\u00f5es de ASN, mudan\u00e7as de provedor, transfer\u00eancias de IPv4 ou implementa\u00e7\u00f5es de IPv6. A monitoriza\u00e7\u00e3o e os alertas devem ser configurados para resultados Inv\u00e1lidos, origens inesperadas, autoriza\u00e7\u00f5es removidas ou varia\u00e7\u00f5es na visibilidade BGP. Crucialmente, as organiza\u00e7\u00f5es devem evitar autoriza\u00e7\u00f5es excessivamente amplas: as ROAs precisas s\u00e3o mais f\u00e1ceis de compreender, mais simples de auditar e muito menos propensas a permitir an\u00fancios n\u00e3o intencionais.<\/p>\n\n\n\n

Perguntas frequentes<\/h2>\n\n\n\n

Um ROA \u00e9 o mesmo que um documento de propriedade de IP?<\/strong> <\/p>\n\n\n\n

N\u00e3o. Uma ROA \u00e9 uma autoriza\u00e7\u00e3o de roteamento que indica qual ASN pode originar um prefixo no BGP. N\u00e3o substitui registos de registo, contratos, documentos de transfer\u00eancia ou provas de propriedade legal.<\/p>\n\n\n\n

\u00c9 poss\u00edvel que um prefixo tenha mais de um ROA?<\/strong> <\/p>\n\n\n\n

Sim. M\u00faltiplas ROAs podem ser adequadas quando um prefixo \u00e9 intencionalmente originado por mais do que uma ASN ou quando uma migra\u00e7\u00e3o controlada requer autoriza\u00e7\u00e3o tempor\u00e1ria para m\u00faltiplas origens, embora os registos sobrepostos devam ser cuidadosamente documentados.<\/p>\n\n\n\n

Um ROA anuncia o meu prefixo no BGP?<\/strong><\/p>\n\n\n\n

N\u00e3o. A cria\u00e7\u00e3o de um ROA n\u00e3o gera um an\u00fancio BGP; a rede deve ainda configurar o BGP atrav\u00e9s dos seus routers e fornecedores de acesso.<\/p>\n\n\n\n

\u00c9 necess\u00e1rio que um fornecedor de tr\u00e2nsito esteja listado no ROA?<\/strong><\/p>\n\n\n\n

Normalmente, o ROA deve identificar o ASN que origina a rota. Um fornecedor que apenas transporta a rota n\u00e3o \u00e9 necessariamente o ASN de origem, e o valor correto depende da arquitetura de roteamento real.<\/p>\n\n\n\n

Quanto tempo demora uma ROA para se tornar vis\u00edvel?<\/strong> <\/p>\n\n\n\n

O timing depende do sistema RIR, do reposit\u00f3rio de publica\u00e7\u00e3o, dos intervalos de atualiza\u00e7\u00e3o do validador e do cache. As atualiza\u00e7\u00f5es s\u00e3o frequentemente vis\u00edveis relativamente r\u00e1pido, mas as altera\u00e7\u00f5es em produ\u00e7\u00e3o devem permitir tempo suficiente para a valida\u00e7\u00e3o.<\/p>\n\n\n\n

Cada prefixo IPv4 e IPv6 deve ter uma ROA?<\/strong><\/p>\n\n\n\n

Recomenda-se fortemente a publica\u00e7\u00e3o de ROAs precisos para os prefixos anunciados no BGP. A organiza\u00e7\u00e3o deve primeiro confirmar o seu desenho de roteamento para que a autoriza\u00e7\u00e3o n\u00e3o torne inv\u00e1lidos, acidentalmente, an\u00fancios leg\u00edtimos.<\/p>\n\n\n\n

Um ROA pode proteger contra todos os ataques BGP?<\/strong> <\/p>\n\n\n\n

N\u00e3o. Uma ROA suporta principalmente a valida\u00e7\u00e3o de origem. N\u00e3o valida todas as partes do caminho BGP, n\u00e3o impede todos os vazamentos de rotas, n\u00e3o criptografa o tr\u00e1fego nem garante que o tr\u00e1fego siga uma rota f\u00edsica segura.<\/p>\n\n\n\n

Uma Autoriza\u00e7\u00e3o de Origem de Rota (ROA) \u00e9 um componente central do RPKI, estabelecendo uma rela\u00e7\u00e3o 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\u00e1ximo de prefixo \u2014 cada um dos quais desempenha um papel decisivo na identifica\u00e7\u00e3o do recurso, na permiss\u00e3o da origem e na defini\u00e7\u00e3o do qu\u00e3o espec\u00edfico pode ser o an\u00fancio. As ROAs precisas ajudam as redes a identificar an\u00fancios n\u00e3o autorizados ou mal configurados, sendo vitais durante transfer\u00eancias de IPv4, altera\u00e7\u00f5es de ASN, migra\u00e7\u00f5es de provedores, implementa\u00e7\u00f5es de IPv6 e opera\u00e7\u00f5es em redes multi-homed. Ao mesmo tempo, uma ROA n\u00e3o constitui prova de propriedade legal nem uma solu\u00e7\u00e3o aut\u00f3noma de seguran\u00e7a de roteamento; funciona melhor em conjunto com registos de base de dados precisos, configura\u00e7\u00f5es disciplinadas do BGP, dados IRR, monitoriza\u00e7\u00e3o de rotas e processos documentados de altera\u00e7\u00e3o. Para qualquer organiza\u00e7\u00e3o que anuncie espa\u00e7o p\u00fablico IPv4 ou IPv6, a regra pr\u00e1tica \u00e9 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\u00e7\u00f5es na rede. Isto mant\u00e9m os dados do RPKI alinhados com o ambiente real de roteamento e reduz a probabilidade de uma rota leg\u00edtima ser classificada como Inv\u00e1lida.<\/p>","protected":false},"excerpt":{"rendered":"

A Route Origin Authorization is a digitally signed RPKI record that identifies which ASN is allowed to originate an IP prefix in BGP. It is created by, or on behalf of, the organization that holds the relevant Internet number resource. A ROA normally contains three essential elements: the IP prefix, the authorized origin ASN, and […]<\/p>\n","protected":false},"author":1,"featured_media":1104,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"What Is a ROA in RPKI? How Route Origin Authorization Works","_seopress_titles_desc":"Learn what a ROA is in RPKI, how it authorizes an ASN to announce an IPv4 or IPv6 prefix, why maxLength matters, and how to avoid common routing errors.","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"","_seopress_social_fb_desc":"","_seopress_social_fb_img":"","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"","_seopress_social_twitter_desc":"","_seopress_social_twitter_img":"","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-1102","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-article"],"_links":{"self":[{"href":"https:\/\/junglelabs.uk\/pt\/wp-json\/wp\/v2\/posts\/1102","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/junglelabs.uk\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/junglelabs.uk\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/junglelabs.uk\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/junglelabs.uk\/pt\/wp-json\/wp\/v2\/comments?post=1102"}],"version-history":[{"count":2,"href":"https:\/\/junglelabs.uk\/pt\/wp-json\/wp\/v2\/posts\/1102\/revisions"}],"predecessor-version":[{"id":1105,"href":"https:\/\/junglelabs.uk\/pt\/wp-json\/wp\/v2\/posts\/1102\/revisions\/1105"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/junglelabs.uk\/pt\/wp-json\/wp\/v2\/media\/1104"}],"wp:attachment":[{"href":"https:\/\/junglelabs.uk\/pt\/wp-json\/wp\/v2\/media?parent=1102"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/junglelabs.uk\/pt\/wp-json\/wp\/v2\/categories?post=1102"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/junglelabs.uk\/pt\/wp-json\/wp\/v2\/tags?post=1102"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}