A valida\u00e7\u00e3o RPKI \u00e9 agora uma parte importante da seguran\u00e7a de roteamento BGP moderno. Ela ajuda os operadores de rede a determinar se um N\u00famero de Sistema Aut\u00f4nomo est\u00e1 autorizado a originar um prefixo IPv4 ou IPv6 espec\u00edfico. Quando um roteador recebe uma notifica\u00e7\u00e3o de rota, ele pode comparar a notifica\u00e7\u00e3o com a autoriza\u00e7\u00e3o RPKI publicada para esse intervalo de endere\u00e7os.<\/p>\n\n\n\n
O resultado \u00e9 normalmente mostrado como V\u00e1lido, Inv\u00e1lido ou N\u00e3o Encontrado. Estes tr\u00eas r\u00f3tulos s\u00e3o simples, mas muitas vezes s\u00e3o mal compreendidos. Um resultado V\u00e1lido n\u00e3o significa que cada parte da rota esteja perfeita. Um resultado Inv\u00e1lido n\u00e3o significa sempre que algu\u00e9m est\u00e1 atacando a rede. Um resultado N\u00e3o Encontrado n\u00e3o significa automaticamente que a divulga\u00e7\u00e3o seja insegura.<\/p>\n\n\n\n
As etiquetas descrevem apenas a rela\u00e7\u00e3o entre uma divulga\u00e7\u00e3o BGP e os dados de Autoriza\u00e7\u00e3o de Origem da Rota dispon\u00edveis. Para compreender corretamente o resultado, \u00e9 necess\u00e1rio comparar tr\u00eas detalhes: o prefixo IP anunciado, o ASN de origem e o comprimento m\u00e1ximo do prefixo permitido pela autoriza\u00e7\u00e3o.<\/p>\n\n\n\n
Este artigo explica cada status RPKI em termos pr\u00e1ticos, mostra por que rotas leg\u00edtimas podem se tornar Inv\u00e1lidas e fornece um processo de solu\u00e7\u00e3o de problemas para operadores de rede que gerenciam seu pr\u00f3prio ASN, recursos IPv4, aloca\u00e7\u00f5es IPv6 ou roteamento superior. Se voc\u00ea \u00e9 novo no assunto, comece com nosso guia para O que \u00e9 RPKI?<\/a> e depois ler O que \u00e9 um ROA no RPKI?<\/a> para uma explica\u00e7\u00e3o detalhada do pr\u00f3prio registro de autoriza\u00e7\u00e3o.<\/p>\n\n\n\n RPKI significa Infrastructure de Chaves P\u00fablicas para Recursos. Ela conecta recursos num\u00e9ricos da Internet com registros de autoriza\u00e7\u00e3o assinados criptograficamente. O titular ou gestor autorizado de um prefixo IP pode publicar um ROA indicando que uma determinada ASN \u00e9 permitida para originar esse prefixo no BGP.<\/p>\n\n\n\n Um validador coleta esses registros assinados, verifica sua autenticidade e cria um conjunto de dados validado para operadores de rede. Quando uma rota BGP \u00e9 recebida, o sistema de roteamento do operador compara a rota com esse conjunto de dados. A compara\u00e7\u00e3o faz tr\u00eas perguntas b\u00e1sicas: O prefixo anunciado est\u00e1 coberto por uma autoriza\u00e7\u00e3o? O ASN de origem \u00e9 o listado nessa autoriza\u00e7\u00e3o? O comprimento do prefixo anunciado est\u00e1 dentro do comprimento m\u00e1ximo permitido?<\/p>\n\n\n\n A resposta a essas perguntas produz o estado RPKI. O estado aplica-se \u00e0 autoriza\u00e7\u00e3o de origem de rota, e n\u00e3o a cada atributo do caminho BGP. O RPKI n\u00e3o comprova que todas as redes intermedi\u00e1rias s\u00e3o corretas, que o tr\u00e1fego seguir\u00e1 o melhor caminho ou que os recursos de endere\u00e7o est\u00e3o legalmente dispon\u00edveis para venda. \u00c9 um sinal de seguran\u00e7a focado que aumenta a confian\u00e7a na origem de uma rota.<\/p>\n\n\n\n Uma rota \u00e9 RPKI V\u00e1lido<\/strong> quando a publica\u00e7\u00e3o BGP \u00e9 coberta por pelo menos uma ROA aplic\u00e1vel, o ASN de origem coincide com o ASN autorizado e o comprimento da prefixo anunciado \u00e9 permitido pela ROA's comprimento m\u00e1ximo. Na pr\u00e1tica, a rota \u00e9 consistente com a autoriza\u00e7\u00e3o de roteamento publicada pelo detentor do recurso.<\/p>\n\n\n\n Por exemplo, suponha que uma empresa controle Um resultado v\u00e1lido \u00e9 um sinal positivo, mas n\u00e3o deve ser interpretado como uma garantia completa. O caminho pode ainda ter um percurso incorreto, uma m\u00e1 reputa\u00e7\u00e3o comercial, uma descri\u00e7\u00e3o de registo obsoleta ou um problema operacional fora da autoriza\u00e7\u00e3o de origem. Os operadores de rede normalmente combinam RPKI com monitoriza\u00e7\u00e3o BGP, filtragem de prefixos, verifica\u00e7\u00f5es de registo e procedimentos de resposta a incidentes.<\/p>\n\n\n\n Um estado v\u00e1lido tamb\u00e9m pode mudar quando a rede muda. Se uma empresa mover um prefixo para outro ASN, iniciar a an\u00fancia de uma rota mais espec\u00edfica ou alterar seu plano de endere\u00e7amento, o ROA existente pode j\u00e1 n\u00e3o corresponder \u00e0 nova an\u00fancia. O RPKI reflete os dados de autoriza\u00e7\u00e3o atuais, por isso deve ser mantido como parte das opera\u00e7\u00f5es normais da rede.<\/p>\n\n\n\n Uma rota \u00e9 RPKI Inv\u00e1lido<\/strong> quando existe uma autoriza\u00e7\u00e3o aplic\u00e1vel, mas a divulga\u00e7\u00e3o BGP entra em conflito com ela. O conflito normalmente envolve uma das duas coisas: o ASN de origem n\u00e3o est\u00e1 autorizado, ou o prefixo anunciado \u00e9 mais espec\u00edfico do que o comprimento m\u00e1ximo permitido pelo ROA.<\/p>\n\n\n\n Por exemplo, um ROA pode autorizar Inv\u00e1lido n\u00e3o significa necessariamente que um sequestro malicioso esteja a ocorrer. Muitas rotas inv\u00e1lidas s\u00e3o causadas por erros operacionais comuns. Um engenheiro pode esquecer-se de atualizar um ROA ap\u00f3s uma migra\u00e7\u00e3o de ASN, um provedor pode anunciar um prefixo de cliente com a origem errada, ou a rede pode come\u00e7ar a utilizar prefixos mais espec\u00edficos sem alterar o comprimento m\u00e1ximo.<\/p>\n\n\n\n Ao mesmo tempo, um resultado inv\u00e1lido n\u00e3o deve ser ignorado. Pode indicar uma divulga\u00e7\u00e3o n\u00e3o autorizada, uma fuga de rota envolvendo uma origem inesperada ou um erro de configura\u00e7\u00e3o que pode tornar o prefixo inacess\u00edvel por meio de redes que utilizam filtragem estrita RPKI. A resposta correta \u00e9 investigar o resultado rapidamente e compar\u00e1-lo com o projeto de roteamento pretendido.<\/p>\n\n\n\n Uma rota \u00e9 RPKI n\u00e3o encontrado<\/strong> quando o validador n\u00e3o consegue encontrar uma ROA aplic\u00e1vel para o prefixo anunciado. N\u00e3o h\u00e1 autoriza\u00e7\u00e3o publicada que possa confirmar ou negar o ASN de origem para essa rota.<\/p>\n\n\n\n N\u00e3o Encontrado \u00e9 \u00e0s vezes chamado de \"desconhecido\", porque o sistema de valida\u00e7\u00e3o n\u00e3o possui informa\u00e7\u00f5es suficientes de autoriza\u00e7\u00e3o para chegar a uma conclus\u00e3o. Isso n\u00e3o significa que a rota seja inv\u00e1lida, nem prova que a origem seja n\u00e3o autorizada. Muitos prefixos leg\u00edtimos na Internet ainda n\u00e3o possuem ROA, j\u00e1 que o titular dos recursos n\u00e3o criou um ou a autoriza\u00e7\u00e3o ainda n\u00e3o se tornou vis\u00edvel para o validador.<\/p>\n\n\n\n A aus\u00eancia de um ROA reduz a quantidade de informa\u00e7\u00e3o dispon\u00edvel para as redes que desejam validar a rota. Se um ASN n\u00e3o autorizado anunciar o mesmo prefixo, uma rede que veja ambas as an\u00fancios pode ter dificuldade em distinguir a rota leg\u00edtima da falsa utilizando apenas RPKI.<\/p>\n\n\n\n Os detentores de recursos devem normalmente publicar ROAs precisos para os prefixos que anunciam publicamente, especialmente quando os prefixos suportam servi\u00e7os importantes. No entanto, os operadores devem evitar criar uma autoriza\u00e7\u00e3o apressada ou excessivamente abrangente apenas para mudar \"N\u00e3o encontrado\" para \"V\u00e1lido\". Um ROA mal configurado pode transformar uma rota leg\u00edtima em \"Inv\u00e1lido\", o que pode ter um impacto operacional mais imediato.<\/p>\n\n\n\n A mais importante distin\u00e7\u00e3o \u00e9 que Inv\u00e1lido \u00e9 um conflito<\/strong>, enquanto N\u00e3o encontrado \u00e9 a aus\u00eancia de dados de autoriza\u00e7\u00e3o<\/strong>. Inv\u00e1lido significa que o validador encontrou um ROA relevante, mas a rota n\u00e3o est\u00e1 em conformidade com ele. N\u00e3o encontrado significa que nenhum ROA aplic\u00e1vel foi encontrado.<\/p>\n\n\n\n Considere dois exemplos. No primeiro, uma empresa publica um ROA autorizando Essa diferen\u00e7a importa quando criando pol\u00edticas de encaminhamento. Muitas redes tratam especialmente as rotas Inv\u00e1lidas porque uma autoriza\u00e7\u00e3o existente indica que o titular do recurso expressou uma expectativa espec\u00edfica. As rotas N\u00e3o Encontradas podem ser monitoradas, dadas menor prioridade ou aceites conforme a pol\u00edtica local. Cada rede decide como aplicar o resultado.<\/p>\n\n\n\n Operadores de rede tamb\u00e9m devem lembrar que os resultados da valida\u00e7\u00e3o podem variar temporariamente enquanto reposit\u00f3rios e validadores s\u00e3o atualizados. Se um ROA foi criado ou alterado h\u00e1 apenas alguns minutos, ferramentas diferentes podem mostrar estados diferentes at\u00e9 que a atualiza\u00e7\u00e3o seja propagada pelo sistema de valida\u00e7\u00e3o.<\/p>\n\n\n\n A causa mais comum \u00e9 uma mudan\u00e7a de ASN. Uma empresa pode originalmente anunciar um prefixo a partir de um ASN fornecido por uma organiza\u00e7\u00e3o upstream ou patrocinadora e, posteriormente, mover o prefixo para seu pr\u00f3prio ASN. Se a ROA ainda autorizar o antigo origem, o novo an\u00fancio torna-se Inv\u00e1lido.<\/p>\n\n\n\n Uma segunda causa \u00e9 um comprimento m\u00e1ximo de prefixo incorreto. Uma organiza\u00e7\u00e3o pode possuir um As transfer\u00eancias IPv4 podem criar problemas semelhantes. Durante uma transfer\u00eancia, o titular administrativo e a origem de encaminhamento podem mudar em momentos diferentes. Se a autoriza\u00e7\u00e3o do anterior titular permanecer ativa enquanto o novo titular anuncia o prefixo a partir de um ASN diferente, a transi\u00e7\u00e3o pode produzir um estado Inv\u00e1lido.<\/p>\n\n\n\n Registos obsoletos, limites de rede incorretos e mal-entendidos sobre o papel do provedor de transito s\u00e3o outras causas frequentes. Um provedor pode transportar uma rota de um cliente sem ser o ASN de origem. O ROA normalmente precisa autorizar o ASN que aparece como origem da rota, e n\u00e3o simplesmente o transportador que transporta o tr\u00e1fego.<\/p>\n\n\n\n Comece registrando o prefixo exato e o ASN de origem mostrados na notifica\u00e7\u00e3o BGP. N\u00e3o dependa de uma exibi\u00e7\u00e3o abreviada ou de um documento de configura\u00e7\u00e3o anterior. Confirme a fam\u00edlia de endere\u00e7os, o comprimento do prefixo e a origem observada por pelo menos um monitor de roteamento confi\u00e1vel.<\/p>\n\n\n\n Em seguida, inspecione os ROAs ativos para esse prefixo. Verifique o ASN autorizado e o comprimento m\u00e1ximo do prefixo. Se o ASN de origem n\u00e3o corresponder, determine se a rota ou a autoriza\u00e7\u00e3o est\u00e1 errada. Se o ASN estiver correto, verifique se o prefixo anunciado \u00e9 mais espec\u00edfico que o comprimento m\u00e1ximo permitido.<\/p>\n\n\n\n Revise as altera\u00e7\u00f5es recentes. Procure uma migra\u00e7\u00e3o de ASN, mudan\u00e7a no provedor upstream, transfer\u00eancia de IPv4, implanta\u00e7\u00e3o de IPv6, mudan\u00e7a de centro de dados, altera\u00e7\u00e3o na agrega\u00e7\u00e3o de rotas ou atualiza\u00e7\u00e3o de pol\u00edtica BGP. A maioria dos resultados Inv\u00e1lidos leg\u00edtimos pode estar relacionada a uma altera\u00e7\u00e3o recente que n\u00e3o foi refletida na gest\u00e3o RPKI.<\/p>\n\n\n\n Se a ROA estiver errada, atualize-a atrav\u00e9s do Registro Regional de Internet correspondente, LIR patrocinador ou sistema de gest\u00e3o RPKI. Se a publica\u00e7\u00e3o BGP estiver errada, corrija a pol\u00edtica de roteamento em vez disso. N\u00e3o resolva um erro de roteamento publicando uma ROA excessivamente ampla, pois isso pode autorizar publica\u00e7\u00f5es que nunca foram intencionadas.<\/p>\n\n\n\n Ap\u00f3s fazer a corre\u00e7\u00e3o, aguarde um tempo para que o reposit\u00f3rio e o validador sejam atualizados. Verifique os resultados novamente usando um servi\u00e7o de valida\u00e7\u00e3o externa e uma fonte de monitoramento BGP. A rota deve voltar a ser V\u00e1lida quando a origem e o comprimento do prefixo coincidirem com a autoriza\u00e7\u00e3o publicada.<\/p>\n\n\n\n A valida\u00e7\u00e3o RPKI n\u00e3o retira automaticamente uma rota da Internet. A rede receptora decide como utilizar o resultado na sua pol\u00edtica de encaminhamento. Alguns operadores rejeitam as rotas Inv\u00e1lidas, enquanto outros as marcam com uma prefer\u00eancia mais baixa, geram alertas ou continuam a aceit\u00e1-las sob condi\u00e7\u00f5es espec\u00edficas.<\/p>\n\n\n\n Uma rota v\u00e1lida pode receber tratamento normal, mas ainda compete com outras rotas de acordo com a prefer\u00eancia local, comprimento do caminho, regras de engenharia de tr\u00e1fego e pol\u00edtica do provedor. Uma rota \"N\u00e3o encontrada\" pode ser aceita por uma rede e tratada com mais cuidado por outra. Uma rota inv\u00e1lida pode permanecer vis\u00edvel por alguns provedores, enquanto se torna inacess\u00edvel por redes que aplicam filtragem r\u00edgida.<\/p>\n\n\n\n Essa diferen\u00e7a explica por que uma divulga\u00e7\u00e3o inv\u00e1lida pode causar conectividade parcial. Um servi\u00e7o pode funcionar de uma regi\u00e3o, mas falhar em outra, pois diferentes redes aplicam pol\u00edticas diferentes. Ao diagnosticar uma interrup\u00e7\u00e3o, \u00e9, portanto, \u00fatil comparar o estado de valida\u00e7\u00e3o com a visibilidade BGP de m\u00faltiplas localiza\u00e7\u00f5es.<\/p>\n\n\n\n O RPKI deve ser considerado como uma entrada para a pol\u00edtica de roteamento, em vez de uma substitui\u00e7\u00e3o universal para filtros de prefixo ou monitoramento de rota. Os melhores resultados operacionais geralmente v\u00eam da combina\u00e7\u00e3o de dados RPKI precisos com registos e registros de roteamento bem mantidos.<\/p>\n\n\n\n Os mesmos tr\u00eas estados aplicam-se tanto ao IPv4 como ao IPv6. Em cada fam\u00edlia de endere\u00e7os, o validador compara o prefixo anunciado, o ASN de origem e o comprimento de prefixo permitido com os ROAs dispon\u00edveis.<\/p>\n\n\n\n Opera\u00e7\u00f5es IPv4 frequentemente envolvem prefixos relativamente pequenos, transfer\u00eancias, arranjos de aluguel e m\u00faltiplos provedores. Uma mudan\u00e7a na ASN de origem ou o uso de an\u00fancios mais espec\u00edficos pode afetar rapidamente o resultado da valida\u00e7\u00e3o. Os detentores de recursos IPv4 devem revisar o RPKI sempre que um bloco for transferido, alugado, movido entre provedores ou anunciado a partir de uma nova localiza\u00e7\u00e3o.<\/p>\n\n\n\n Redes IPv6 recebem frequentemente aloca\u00e7\u00f5es maiores e podem anunciar um agregado enquanto usam sub-redes internas menores. O ROA p\u00fablico deve corresponder aos prefixos que s\u00e3o realmente anunciados para a Internet. Se um operador IPv6 autorizar apenas um agregado, mas posteriormente anunciar rotas mais espec\u00edficas, essas rotas podem tornar-se Inv\u00e1lidas, a menos que o comprimento m\u00e1ximo as permita.<\/p>\n\n\n\n A larger IPv6 address space does not remove the need for origin validation. IPv6 route hijacks and configuration mistakes can still interrupt services. Publishing precise ROAs during the initial IPv6 deployment makes future troubleshooting easier and gives upstream networks a clear authorization signal.<\/p>\n\n\n\n Antes de alterar um ASN, provedor upstream, plano de agrega\u00e7\u00e3o de rota ou titular de recurso de endere\u00e7o, registre o estado atual do RPKI. Confirme qual ASN origina atualmente o prefixo e se a divulga\u00e7\u00e3o \u00e9 V\u00e1lida, Inv\u00e1lida ou N\u00e3o Encontrada.<\/p>\n\n\n\n Ap\u00f3s preparar o novo design de roteamento, compare os comprimentos de origem e prefixo esperados com os ROAs planejados. Se a origem mudar, publique ou atualize a autoriza\u00e7\u00e3o antes de anunciar a nova rota sempre que a agenda operacional permitir. Durante uma migra\u00e7\u00e3o controlada, pode ser apropriado autorizar temporariamente ambas as origens, mas o arranjo deve ser documentado e a antiga autoriza\u00e7\u00e3o removida quando a transi\u00e7\u00e3o estiver completa.<\/p>\n\n\n\nO que \u00e9 Valida\u00e7\u00e3o RPKI?<\/h2>\n\n\n\n
O que Significa V\u00e1lido RPKI?<\/h2>\n\n\n\n
203.0.113.0\/24<\/code> e publica um ROA autorizando AS64500<\/code> originar esse \/24<\/code>. Se a empresa anunciar 203.0.113.0\/24<\/code> de AS64500<\/code>, a divulga\u00e7\u00e3o deve retornar V\u00e1lido. O mesmo \u00e9 verdadeiro para um exemplo de IPv6 como 2001:db8:1200::\/48<\/code> quando o ASN correto e o comprimento de prefixo permitido s\u00e3o usados.<\/p>\n\n\n\nO que significa RPKI Inv\u00e1lido?<\/h2>\n\n\n\n
AS64500<\/code> originar 198.51.100.0\/24<\/code>. Se AS64510<\/code> anuncia que mesmo prefixo, o ASN de origem n\u00e3o coincide e a rota torna-se Inv\u00e1lida. O resultado tamb\u00e9m pode ocorrer quando AS64500<\/code> \u00e9 autorizado para o \/24<\/code> mas anuncia 198.51.100.0\/25<\/code> enquanto a ROA n\u00e3o permite prefixos que espec\u00edficos.<\/p>\n\n\n\nO que significa \"RPKI N\u00e3o Encontrado\"?<\/h2>\n\n\n\n
A Diferen\u00e7a Entre Inv\u00e1lido e N\u00e3o Encontrado<\/h2>\n\n\n\n
AS64500<\/code> para 192.0.2.0\/24<\/code>, mas AS64510<\/code> anuncia o prefixo. A rota \u00e9 inv\u00e1lida porque a origem entra em conflito com a autoriza\u00e7\u00e3o. Na segunda, a empresa n\u00e3o publicou nenhum ROA, e AS64500<\/code> anuncia o prefixo. A rota n\u00e3o foi encontrada porque n\u00e3o h\u00e1 autoriza\u00e7\u00e3o para avaliar.<\/p>\n\n\n\nPor que uma rota leg\u00edtima pode se tornar inv\u00e1lida?<\/h2>\n\n\n\n
\/20<\/code>, publique um ROA com um comprimento m\u00e1ximo de \/20<\/code>, e posteriormente anunciar dois \/21<\/code> rotas para engenharia de tr\u00e1fego. Essas divulga\u00e7\u00f5es mais espec\u00edficas podem n\u00e3o estar cobertas pela autoriza\u00e7\u00e3o original. A configura\u00e7\u00e3o BGP pode ser intencional, mas a pol\u00edtica RPKI \u00e9 muito restritiva para o novo design.<\/p>\n\n\n\nComo solucionar um resultado inv\u00e1lido do RPKI<\/h2>\n\n\n\n
Como os Resultados RPKI Afetam o Roteamento BGP<\/h2>\n\n\n\n
RPKI Validation for IPv4 and IPv6<\/h2>\n\n\n\n
Como Verificar o Estado do RPKI Antes de uma Altera\u00e7\u00e3o na Rede<\/h2>\n\n\n\n