Nesta postagem, os especialistas em BGP Doug Madory da Kentik e Job Snijders da Fastly analisam as métricas mais recentes de implantação de validação de origem (ROV) RPKI à luz de um marco importante.
A partir de hoje, 1º de maio de 2024, a segurança do roteamento da Internet ultrapassou um marco importante. Pela primeira vez na história do RPKI (infraestrutura de chave pública de recursos), a maioria das rotas IPv4 na tabela de roteamento global são cobertas por autorizações de origem de rota (ROA), de acordo com o monitor de RPKI do NIST. O IPv6 ultrapassou esse marco no final do ano passado.
À luz deste marco, vamos aproveitar para atualizar os números de adoção da validação de origem de rotas (ROV) com RPKI que temos publicado nos últimos anos.
Como vocês já devem saber, a validação de origem de rotas com RPKI continua a ser a melhor defesa contra os sequestros de BGP acidentais e os vazamentos de origem. Para que o ROV faça seu trabalho (rejeitar rotas inválidas para RPKI), duas etapas devem ser executadas:
(Acesso livre, não requer assinatura)
As ROA devem ser criadas.
Os AS devem rejeitar as rotas que não sejam consistentes com as ROA.
A primeira parte desta análise começou quando exploramos a primeira etapa de ROV: a criação de ROA. Há dois anos, na NANOG 84, Doug apresentou a sua análise que mostrava que estávamos, de fato, mais avançados na criação de ROA do que se podia determinar analisando apenas o BGP. Usando o NetFlow agregado de Kentik, ele mostrou que a maior parte do tráfego (medido em bits/s) estava indo para rotas com ROA, apesar de apenas um terço das rotas BGP terem ROA.
Esta discrepância aconteceu devido ao fato de os principais fornecedores de conteúdo e redes “eyeball” terem concluído implantado RPKI nos últimos anos e serem responsáveis por uma parte desproporcional do volume de tráfego da Internet. É claro que o volume de tráfego não é o único critério para alcançar esse objetivo: há muito tráfego que é crítico, mas não volumoso (por exemplo, DNS). A ideia era simplesmente fornecer outra dimensão para considerar nossos avanços na implantação da validação de origem de rotas com RPKI.
Para medir a segunda etapa de ROV (rejeitar as rotas inválidas), observamos as diferenças na propagação baseada na avaliação de uma rota com RPKI. A conclusão na época foi que as rotas inválidas poderiam alcançar uma propagação não superior a 50% das fontes BGP no RouteViews repositório público de BGP da Universidade de Oregon. Muitas vezes, as rotas inválidas se propagam muito menos que 50% — tudo depende dos upstreams envolvidos.
As ROA devem ser criadas.
Os AS devem rejeitar as rotas que não sejam consistentes com as ROA.
A primeira parte desta análise começou quando exploramos a primeira etapa de ROV: a criação de ROA. Há dois anos, na NANOG 84, Doug apresentou a sua análise que mostrava que estávamos, de fato, mais avançados na criação de ROA do que se podia determinar analisando apenas o BGP. Usando o NetFlow agregado de Kentik, ele mostrou que a maior parte do tráfego (medido em bits/s) estava indo para rotas com ROA, apesar de apenas um terço das rotas BGP terem ROA.
Esta discrepância aconteceu devido ao fato de os principais fornecedores de conteúdo e redes “eyeball” terem concluído implantado RPKI nos últimos anos e serem responsáveis por uma parte desproporcional do volume de tráfego da Internet. É claro que o volume de tráfego não é o único critério para alcançar esse objetivo: há muito tráfego que é crítico, mas não volumoso (por exemplo, DNS). A ideia era simplesmente fornecer outra dimensão para considerar nossos avanços na implantação da validação de origem de rotas com RPKI.
Para medir a segunda etapa de ROV (rejeitar as rotas inválidas), observamos as diferenças na propagação baseada na avaliação de uma rota com RPKI. A conclusão na época foi que as rotas inválidas poderiam alcançar uma propagação não superior a 50% das fontes BGP no RouteViews repositório público de BGP da Universidade de Oregon. Muitas vezes, as rotas inválidas se propagam muito menos que 50% — tudo depende dos upstreams envolvidos.
A redução drástica na propagação de rotas inválidas para RPKI pode ser atribuída principalmente aos provedores de backbone Tier 1 que as rejeitam. Esses provedores têm uma influência descomunal no roteamento da Internet. Independentemente disso, a redução na propagação significa que a ROV com RPKI está fazendo o seu trabalho: suprimir as rotas problemáticas para que não causem interrupções.
Atualização da criação de ROA (autorização de origem de rotas)
Conforme mencionado acima, mais de 50% das rotas IPv4 na tabela de roteamento global agora têm ROA e são avaliadas como válidas (52% no caso das rotas IPv6). Vamos verificar o que isso significa para o NetFlow agregado de Kentik.
De acordo com nossa análise de dois anos atrás, tinham cerca de um terço das rotas com ROA e pouco mais de 50% do tráfego da Internet como “válido” (tráfego para rotas avaliadas como válidas em bits/s). Agora, com mais da metade das rotas IPv4 com ROA, nosso NetFlow adicionado atual revela que 70,3% do tráfego da Internet é válido.
Quanto mais pode aumentar esta métrica? Resta saber. Conforme mostrado abaixo em outro diagrama do NIST, a inclinação ascendente da percentagem de rotas com ROA se manteve estável nos últimos quatro anos. É lógico que com o tempo vejamos que a inclinação se estabiliza à medida que o número de vitórias fáceis começa a diminuir. No entanto, é importante reconhecer os progressos alcançados até à data.
Atualização sobre a propagação de rotas inválidas
O progresso acima mencionado em relação à criação de ROA é inútil se as redes não rejeitarem as rotas BGP inválidas para RPKI. Portanto, o próximo passo para entender onde estamos com a adoção de ROV com RPKI é compreender melhor até que ponto a Internet rejeita rotas inválidas para RPKI.
Entre os maiores provedores de tráfego da Internet (ou seja, provedores sem tráfego), praticamente todos rejeitavam as rotas inválidas para RPKI quando publicamos nosso artigo How much does RPKI ROV reduce the propagation of invalid routes? Como resultado, concluímos que “a avaliação de uma rota como inválida reduz sua propagação entre 50% e dois terços”.
Agora, dois anos depois, podemos explorar como esta métrica evoluiu ao longo deste período. Usando dados históricos de RPKI disponibilizados através do RPKIviews site de Job e dados de roteamento BGP de RouteViews, avaliamos a tabela de roteamento global IPv4 todos os meses desde o início de 2022, para determinar como a propagação de rotas inválidas para RPKI mudou ao longo do tempo.
Lembre-se de que nesta metodologia medimos a propagação de uma rota contando quantos pontos de observação do RouteViews possuem a rota em suas tabelas. Mais pontos de observação significa maior propagação. Para saber mais sobre esta abordagem, consulte nossa análise de propagação de rotas inválidas.
O gráfico abaixo mostra o número médio de pontos de observação do RouteViews para cada rota inválida para RPKI ao longo do tempo. Para evitar as rotas internas compartilhadas com os pontos de observação do RouteViews, incluímos apenas as rotas vistas por pelo menos 10 pontos de observação. Ao início do gráfico, identificamos 4978 rotas inválidas para RPKI que foram visualizadas, em média, desde 82,5 pontos de observação. Os últimos dados de 1º de abril de 2024 indicam 4211 rotas inválidas para RPKI vistas desde 62,5 pontos estratégicos. É importante levar em conta que usamos um prefixo roteado globalmente conhecido (8.8.8.0/24 do Google) como prefixo de controle para ver os efeitos das mudanças temporárias no número de pontos de observação do RouteViews.
O principal desafio deste tipo de análise é que há bastante “barulho”. O conjunto de rotas persistentemente inválidas para RPKI não permanece constante e a propagação é fortemente influenciada pelos provedores que transitam uma rota. Deixando esses desafios de lado, a análise acima mostra um declínio de 24% na propagação de rotas inválidas para RPKI desde o início de 2022.
Para explorar ainda mais esse fenômeno, podemos dar uma olhada no roteamento de rotas intencionalmente inválidas para RPKI ao longo do tempo e ver que elas também experimentam um declínio semelhante na propagação.
RIPE NCC anuncia várias “beacons de roteamento” (routing beacons) para fins de medição. Estas incluem rotas que são intencionalmente inválidas para RPKI (e válidas para RPKI a modo de controle). Para não ficar para trás, Job também anuncia rotas inválidas para RPKI junto com uma rota de controle desde sua rede AS15562.
O gráfico abaixo mostra o número de pontos de observação do RouteViews para cada uma dessas rotas de medição ao longo do tempo. Os gráficos correspondentes às rotas inválidas para RPKI aparecem na parte inferior dos gráficos, o que é consistente com nossa observação de que as rotas inválidas para RPKI se propagam significativamente menos.
Os três gráficos nesta figura mostram um declínio apreciável no número de pontos que observam as diferentes rotas inválidas para RPKI. Esta diminuição coincide com a queda no número médio de pontos que observam uma determinada rota RPKI da figura anterior.
Há uma última observação que emerge desta análise. No painel à direita (“Job’s Beacons”), existem duas rotas inválidas para RPKI com graus de propagação ligeiramente diferentes.
O ROA de 209.24.0.0/24 (verde) está publicado através do TAL do ARIN, enquanto o de 194.32.71.0/24 (laranja) é acessível através do TAL de RIPE. Um TAL é um arquivo com uma chave pública que é usado pelas partes confiantes para recuperar dados RPKI de um repositório.
O problema provável é que para usar o TAL do ARIN seja necessário aceitar um longo acordo de parte confiante, coisa que alguns provedores se recusam a fazer. Como resultado, os ROA publicados pelo ARIN são vistos por um número ligeiramente menor de redes que rejeitam rotas inválidas para RPKI, diminuindo a eficácia do RPKI para o espaço IP gerenciado pelo ARIN.
A forte cláusula de indenização do ARIN vem da preocupação de serem processados com possíveis ações judiciais em decorrência dos dados que publicam no RPKI. Esta barreira para a adoção de ROV com RPKI foi discutida em um artigo acadêmico publicado em 2019, Reduzindo as barreiras legais para a adoção de RPKI, pelos professores Christopher S. Yoo e David A. Wishnick da Universidade de Pensilvânia.
Mas, voltemos para o progresso que estamos vendo na rejeição das rotas inválidas para RPKI.
No início desta seção, mencionamos como todos os provedores sem trânsito, exceto dois, estavam rejeitando as rotas inválidas para RPKI. Bem, o outro marco que aconteceu no mês passado é que esse número caiu para apenas um, quando a operadora de telecomunicações dos EUA Zayo (AS6461) começou a rejeitar rotas inválidas para RPKI de seus clientes.
Em 2022, Zayo anunciou que tinha começado a rejeitar as rotas inválidas para RPKI de aqueles que não tinham um acordo de peering igualitário gratuito. No entanto, uma vez que quase todos os “grandes” com quem faziam peering já estavam rejeitando essas rotas, o impacto foi relativamente menor.
Mas em 1° de abril começamos a ver que o AS6461 começava a rejeitar as rotas inválidas para RPKI dos clientes pela primeira vez. No gráfico de Kentik abaixo, a rota inválida para RPKI 103.36.106.0/24 parou de ser transitada pelo AS6461 às 16h24 UTC.
Zayo implementou a rejeição das rotas inválidas para RPKI por etapas e em algumas semanas começamos a ver que outras partes de sua rede global também as rejeitavam. Às 18h54 UTC de 12 de abril, observamos que o AS6461 começava a rejeitar os beacons inválidos para RPKI do RIPE, 93.175.147.0/24 e 2001:7fb:fd03::/48, pela primeira vez.
Depois de concluído, esperamos que a rejeição de rotas inválidas para RPKI de sua base de clientes por parte de Zayo continue reduzindo a propagação dessas rotas problemáticas, o que, por sua vez, diminuirá o risco de interrupção ou desvio do tráfego devido a diferentes tipos de contratempos no roteamento.
E, finalmente, para quem ainda está cético sobre o grau de rejeição das rotas inválidas, recomendamos ler sobre a caída do serviço que sofreu Orange España no mês de janeiro. Eu resumi este incidente em um artigo publicado no dia seguinte ao ataque.
Usando uma senha encontrada em um vazamento público de credenciais roubadas, um hacker conseguiu fazer login no portal de RIPE NCC como Orange España usando a senha “ripeadmin”. Uau! Uma vez dentro do sistema, o hacker começou a alterar a configuração de RPKI da Orange España, tornando muitas de suas rotas BGP inválidas para RPKI.
O uso de RPKI como ferramenta para a denegação de serviço só foi possível graças à rejeição generalizada das rotas inválidas para RPKI por parte dos ASN.
A propagação de uma rota da Orange España caiu para menos de 20% durante o ataque.
Conclusão: Benefícios da implantação do RPKI
Em um artigo de um ano atrás, fomos ousados e previmos o seguinte:
Se assumirmos um crescimento constante da proporção de rotas BGP com ROA, este deveria se tornar o caso majoritário daqui a cerca de um ano (maio de 2024). Marque em seus calendários!
Em dezembro, entrevistamos colegas nerds de BGP no Twitter/X e Linkedln quando acreditaram que atingiríamos esse marco, e eles foram decididamente mais pessimistas do que a previsão anterior:
O avanço detalhado neste artigo levou anos para ser feito e envolveu os esforços dedicados de centenas de engenheiros em dezenas de empresas. Melhorar a segurança do sistema global de roteamento da Internet não é uma tarefa fácil e é um esforço que durará muitos mais anos.
Cada uma das duas linhas de análise desta publicação deveria servir como motivação para que redes adicionais implementem a validação de origem de rotas com RPKI.
Rejeitar rotas BGP inválidas para RPKI nas sessões EBGP. Dado que a maioria das rotas da Internet são cobertas por ROA (incluindo uma grande maioria do tráfego), os operadores de redes devem rejeitar as rotas inválidas para RPKI a fim de evitar que o tráfego dos clientes saia por engano para rotas mal originadas.
Criar ROA. Dada a grande proporção de rotas inválidas para RPKI que são suprimidas, seria benéfico para os titulares de recursos criar ROA para seus intervalos de endereços, a fim de permitir que as redes do mundo todo rejeitem automaticamente as rotas mal originadas.
As redes que fazem isso desfrutam de benefícios imediatos!
Mas a validação de origem de rotas com RPKI não resolve todos os problemas relacionados à segurança do roteamento da Internet. De fato, isto é apenas um começo para abordar os diferentes cenários de “adversário determinado”, melhor caracterizados pelos recentes ataques contra os serviços de criptomoedas. Estes ataques aproveitam as fragilidades existentes na segurança da Internet que deveremos limitar aproveitando os progressos alcançados com a ajuda de mecanismos de segurança do roteamento como ROV com RPKI.
As opiniões expressas pelos autores deste blog são próprias e não refletem necessariamente as opiniões de LACNIC.
