Qual o ciclo de vida dos dados da infraestrutura de chave pública dos recursos (RPKI, Resource Public Key Infrastructure) utilizada para proteger o roteamento da Internet? Mais especificamente: Quanto tempo demora para divulgar-se uma autorização de origem de rota (ROA, Route Origin Authorization) e como isso pode atingir o roteamento e a acessibilidade da Internet?
Estas são as perguntas às quais as operadoras de redes gostariam de ter as respostas, já que as alterações no plano de gestão do RPKI podem afetar a forma em que o tráfego flui das redes e para as redes. Há pouco tempo colaborei com um projeto chamado Tempo de voo em RPKI: análise das delongas nos âmbitos de gestão, controle e dados, cujo objetivo era responder a estas perguntas, analisando cada uma das etapas da vida dos dados do RPKI.
A seguir, apresentamos um resumo do ciclo de vida do RPKI e nossas descobertas.
Pontos chaves: O tempo de criação varia significativamente entre os diferentes Registros Regionais de Internet (RIR). O tempo que demora para que os novos ROA cheguem até os pontos de publicação varia entre alguns minutos e mais de uma hora.Devido a um problema com as zonas horárias, no ARIN e no LACNIC são observadas, inicialmente, delongas na publicação. Este problema foi reportado e já foi resolvido. As demoras observadas costumam ser inferiores a 20 minutos.Foi observado que o atraso da parte que confia (RP, Relying Party) é o passo que leva mais tempo no processamento dos ROA.A eliminação do ROA demora mais para se espelhar no BGP, já que os roteadores exploram rotas alternativas que ainda não foram validadas.
Cadeia de suprimentos da validação de origem.
Publicar os ROA é complexo. O processo implica a participação de vários atores, não é instantâneo e costuma estar comandado por decisões administrativas ad hoc.
Começa quando um titular de recursos consulta a um RIR para criar ou atualizar a informação do RPKI para seus prefixos. Depois, os ROA e outros metarquivo (manifestos, CRL) são colocados em repositórios públicos chamados pontos de publicação.
(Acesso livre, não requer assinatura)
As RP recuperam e validam periodicamente todos os objetos dos repositórios de RPKI globais e depois produzem uma lista de VRP (Validated ROA Payloads) validadas que os roteadores usam para verificar os anúncios BGP entrantes. As operadoras que realizam validação de origem (sistemas autônomos que implementam ROV, em cor verde na Figura 1) recuperam estas alterações e utilizam esta nova informação para atualizar seus roteadores. Só assim começamos a ver mudanças no plano de dados quando os AS que implementam ROV aceitam ou eliminam os anúncios de roteamento.
Figura 1. O fluxo de dados é registrado nos coletores de rotas (RIS/RouteViews), a partir do momento em que o titular do prefixo cria um ROA para as correspondentes atualizações do BGP. As etiquetas vermelhas da esquerda indicam os pontos nos quais o tempo foi medido.
O tempo para eliminação ou criação dos ROV varia
Os passos anteriores são comuns a todos os RIR e a todos os sistemas autônomos implementados pelos ROV, porém cada um realiza (ou pode realizar) estes passos em diferentes intervalos de tempo e em diferentes frequências.
Nosso estudo descobriu que os RIR geralmente publicam a informação nova sobre o RPKI em cinco minutos ou até em menos tempo, com exceção do APNIC, que em média foi dez minutos mais lento (Tabela 1, coluna 3). Também observamos disparidades significativas no tempo de reação dos ISP para a nova informação do RPKI, que variou entre uns poucos minutos e uma hora.
As RP recuperam e validam periodicamente todos os objetos dos repositórios de RPKI globais e depois produzem uma lista de VRP (Validated ROA Payloads) validadas que os roteadores usam para verificar os anúncios BGP entrantes. As operadoras que realizam validação de origem (sistemas autônomos que implementam ROV, em cor verde na Figura 1) recuperam estas alterações e utilizam esta nova informação para atualizar seus roteadores. Só assim começamos a ver mudanças no plano de dados quando os AS que implementam ROV aceitam ou eliminam os anúncios de roteamento.
Figura 1. O fluxo de dados é registrado nos coletores de rotas (RIS/RouteViews), a partir do momento em que o titular do prefixo cria um ROA para as correspondentes atualizações do BGP. As etiquetas vermelhas da esquerda indicam os pontos nos quais o tempo foi medido.
O tempo para eliminação ou criação dos ROV varia
Os passos anteriores são comuns a todos os RIR e a todos os sistemas autônomos implementados pelos ROV, porém cada um realiza (ou pode realizar) estes passos em diferentes intervalos de tempo e em diferentes frequências.
Nosso estudo descobriu que os RIR geralmente publicam a informação nova sobre o RPKI em cinco minutos ou até em menos tempo, com exceção do APNIC, que em média foi dez minutos mais lento (Tabela 1, coluna 3). Também observamos disparidades significativas no tempo de reação dos ISP para a nova informação do RPKI, que variou entre uns poucos minutos e uma hora.
Sign(min)
NotBefore(min)
Publicación(min)
Parte que confia (min)
BGP(min)
AFRINIC
0 (0)
0 (0)
3 (2)
14 (13)
15 (16)
APNIC
10 (13)
14 (16)
10 (13)
34 (38)
26 (28)
ARIN
– (-)
– (-)
69 (97)
81 (109)
95 (143)
LACNIC
0 (0)
– (-)
54 (32)
66 (42)
51 (34)
RIPE
0 (0)
0 (0)
4 (4)
14 (13)
18 (18)
Depois da alteração
ARIN
(-)
(-)
8 (9)
21 (22)
28 (23)
Tabela 1. Média das delongas na criação das ROA (IPv6 entre parêntese).
Percebemos que o atraso é significativamente maior ao excluir os ROA (Tabela 2, coluna 4), com exceção para o ARIN e o LACNIC (em seguida vou explicar a razão desta diferença).
Revogação(min)
Parte que confia(min)
BGP(min)
AFRINIC
0 (0)
13 (14)
34 (38)
APNIC
10 (12)
31 (36)
51 (56)
ARIN
0 (0)
14 (16)
45 (51)
LACNIC
0 (0)
18 (20)
48 (49)
RIPE
0 (0)
14 (13)
41 (50)
Tabela 2. Média das delongas na eliminação dos ROA (IPv6 entre parêntese).
Para a revogação do ROA, observamos que o tempo entre a eliminação de um ROA e sua acessibilidade varia conforme a topologia. Mais uma vez, as demoras no BGP são significativamente maiores para a eliminação do que para a criação do ROA. Provavelmente isto se deva a que todos os vizinhos devem retirar o ROA. Por exemplo, a demora no BGP por falta de acessibilidade aumentou 51 minutos para o IPv4 e 56 minutos para o IPv6, e, rara vez, percebemos demoras curtas no BGP.
Para isso propomos duas possíveis razões:
O uso de múltiplos caches (para redundância) provavelmente fará com que a eliminação do ROA seja mais lenta que a criação.
A busca por caminhos BGP (Figura 3): em alguns casos, observamos que o AS Path entre a sonda da RIPE Atlas e o destino mudou antes de que este ficasse inatingível.
Problemas do ARIN e do LACNIC com as zonas horárias
Antes de abril de 2022, as publicações do ARIN e do LACNIC podiam demorar várias horas devido a um problema de conversão das zonas horárias.
Figura 2. Diferença entre a criação e a eliminação de ROA entre RIR.
Ambos os RIR tinham a intenção de configurar valores NotBefore das ROA à meia-noite. No entanto, ARIN vinha configurando este valor às 04:00 ou às 05:00 UTC (correspondente à 00:00 EDT e EST) e o LACNIC às 03:00 UTC (correspondente à 00:00 hora padrão do Uruguai).
Por exemplo, uma consulta feita à 01:00 UTC para criar um ROA no LACNIC, criava um ROA com um valor NotBefore de 03:00 UTC. Portanto, o ROA era inválido durante as duas horas seguintes à sua criação. Nosso experimento revelou que o ponto de publicação sabiamente não publica o ROA “ainda não validado” no repositório, demorando assim sua disponibilidade para as partes que confiam. Isto também era assim no caso de ARIN.
Quando cientificamos o ARIN e o LACNIC sobre este problema, rapidamente o resolveram e solucionaram.
Medições no plano de dados
À medida que são criados mais ROA para proteger os prefixos contra origens erradas, a gente se pergunta quanto tempo demoram as mudanças no RPKI para aparecer no plano de dados.
Para respondermos a esta pregunta, usamos um mecanismo de “alternância do ROA”, “invalidante” com AS666 para manter o estado de validez do RPKI de nossos prefixos anunciados como “inválidos”. Depois, mudamos para o estado de validez do RPKI ‘válido <-> inválido’ dos prefixos de teste, quer seja criando um ROA “de validação” com um AS de origem devidamente autorizado ou bem eliminando o ROAPara provar a acessibilidade a nível de plano de dados e a demora dos prefixos com a alternância do ROA, executamos traceroutes a cada 15 minutos desde o RIPE Atlas com sondas em seis sistemas autônomos diferentes. Ao criar um “ROA de validação”, a demora entre a consulta do usuário e a acessibilidade do plano de dados é semelhante ao BGP. Observamos que a média da demora era entre 23 minutos (RIPE) e 50 minutos (APNIC).
Para a revogação dos ROA, observamos que o tempo entre a eliminação de um ROA e sua inacessibilidade varia conforme a topologia. Mais uma vez as demoras no BGP são significativamente maiores para a eliminação do ROA do que para a sua criação. Por exemplo, o atraso do BGP em razão da inacessibilidade aumenta para 51 minutos no IPv4 e 56 minutos no IPv6, e, rara vez observamos demoras curtas no BGP. Para isso, propomos duas causas possíveis:
O uso de múltiplos caches (para redundância) provavelmente fará com que a eliminação do ROA seja significativamente mais lenta que a sua criação.
A busca por caminhos BGP (Figura 3): em alguns casos, observamos que o AS Path entre a sonda da RIPE Atlas e o destino mudou antes de que este ficasse inatingível.
Figura 3. Efeitos da criação/eliminação do ROA no plano de dados. Percebemos a busca por caminhos BGP com alterações no AS Path.
Delongas nas RP: Um possível efeito gargalo?
As partes que confiam obtêm periodicamente dados sobre o RPKI dos pontos de publicação.
Descobrimos que as demoras nas RP representam o passo que mais tempo consome no processamento dos ROA. A demora entre a criação de um ROA e o momento no qual uma RP valida o novo ROA, era em geral menor a 15 minutos para a maioria dos RIR. Isto representava 10 minutos a mais que a demora na publicação e consistia principalmente em:
Intervalo de medição (em média 5 minutos de demora).
Tempo de descarga de todas as Autoridades de Certificação (4 minutos).
Tempo de processamento do ROA (1 minuto).
Outros fatores que podem afetar as demoras nas RP incluem o tempo de descarga variável devido às condições da rede, o tempo de espera dos pontos de publicação e a falta de operação em paralelo (multi-threading) em algumas das implementações das RP.
Se deseja obter mais informação sobre a nossa metodologia e nossas descobertas, consulte os nossos paper e GitHub.
Este estudo foi financiado em parte pelo programa de bolsas MANRS e foi uma colaboração entre IIJ Research Lab, Internet Society, UCLouvain, LAAS-CNRS e Arrcus Inc.
Colaborador: Romain Fontugne.
As opiniões expressas pelos autores deste blog são próprias e não refletem necessariamente as opiniões de LACNIC.
