Vazamento de rota da Rostelecom (2020): limites da validação de

Resumo

O monitoramento da Qrator coloca o início do incidente em torno de 19:28 UTC em 1º de abril de 2020 e descreve uma observação com duração aproximada de uma hora. Trata-se de uma janela de observação externa atribuída, não de uma cronologia interna completa da Rostelecom ou de prova de início e fim exatos em todas as redes afetadas.[1]
A Qrator reportou 8.870 prefixos afetados pertencentes a quase 200 sistemas autônomos. A CERT-EU resumiu separadamente mais de 8.800 rotas de mais de 200 redes. As cifras descrevem a escala visível por diferentes perspectivas de relatório; nenhuma fonte estabelece todos os caminhos de dados, todos os usuários afetados ou o impacto comercial total.[1][2]
A Qrator observou anúncios AS12389 propagando-se por meio de Rascom AS20764, Cogent AS174 e Level 3 AS3356. Essa cadeia mostra que o evento atravessou domínios de roteamento controlados de forma independente, mas não revela os filtros de importação, contratos, estado de validação ou configuração de roteador exatos em nenhuma rede mencionada.[1]
As evidências de roteamento exigem manter várias categorias separadas: uma rota aprendida exportada além do escopo de política pretendido; um anúncio com origem não autorizada; uma reoriginação com prefixo mais específico; e uma rota cuja origem autorizada permanece intacta, mesmo que o caminho viole uma relação comercial esperada. Essas categorias interagem de forma diferente com filtros, importação e validação.[4][17]
Ocorreu um incidente separado no RIPE NCC no plano de controle RPKI. Após uma atualização do software de registro, 2.669 Autorizações de Origem de Rota foram excluídas depois que algumas atribuições independentes de provedor foram classificadas como não certificáveis. O RIPE NCC restaurou as ROAs ausentes em 2 de abril.[3][5]
Contemporaneidade não estabeleceu causalidade. A análise retrospectiva do RIPE NCC e uma análise independente do Routing Working Group não encontraram relacionamento direto entre a exclusão de ROA e o incidente de roteamento da Rostelecom.[4][5]
A interseção medida entre os incidentes foi restrita: três detentores de recursos independentes e 12 prefixos. Essa sobreposição não pode ser extrapolada para todos os 8.870 prefixos, e o registro público não sustenta descrever todas as rotas afetadas como RPKI Invalid.[4][5]
A validação de origem de rota pode comparar um prefixo e seu ASN de origem com dados de ROA validados e classificar o resultado como Válido, Invalid ou NotFound. Ela não valida o caminho AS completo, determina se toda exportação respeitou uma relação comercial, reconstrói uma mudança de configuração ou estabelece intenção.[13]-[15]
O controle prático era distribuído. A Rostelecom controlava seus anúncios e política de exportação; redes aceitando rotas controlavam suas decisões de importação, exportação e validação; titulares de prefixo controlavam seus registros e ROAs; o RIPE NCC controlava certificação e serviço de gestão de ROA; entidades dependentes controlavam atualidade de cache e aplicação; provedores de monitoramento controlavam observação e sistemas de alerta.
Fatos importantes permanecem desconhecidos: a sequência interna inicial, a divisão exata entre vazamentos de rota aprendida e reoriginações mais específicas, o estado RPKI de cada entidade dependente, os filtros aplicados em cada salto, a cronologia completa de resposta, o efeito completo no plano de dados e se o incidente começou por acidente ou intencionalmente.
Por isso, a conclusão de responsabilização é operacional, não acusatória. Registros de cadastro e ROAs forneceram evidências sobre recursos e autorização de origem, enquanto configurações ativas, caches atuais, políticas de vizinhos, monitoramento e recuperação coordenada determinaram se essa evidência mudou o comportamento de roteamento ao vivo.

A questão da responsabilização

O incidente de 1º de abril de 2020 importa porque expôs uma divisão entre autoridade registrada e controle em execução. O RIPE Database podia identificar o objeto administrativo associado ao AS12389, e a RPKI podia expressar algumas autorizações de origem de titulares de prefixo.[8][10] Nenhum sistema, por si, determinava o que cada roteador aceitaria, preferiria ou propagaria. Dispositivos BGP trocaram mensagens UPDATE, selecionaram rotas por política local e anunciaram resultados permitidos aos seus vizinhos.[12] Quando anúncios inesperados cruzaram uma fronteira de rede, cada operador receptor tomou outra decisão sob controle local.

Essa estrutura descarta uma explicação simples em que um único registro, um único mecanismo de segurança ou uma única organização governava o resultado completo. A propagação reportada pela Qrator por meio de AS20764, AS174 e AS3356 colocou vários planos de controle operacional na cadeia observada.[1] O comportamento da Rostelecom foi central porque o AS12389 apareceu nos anúncios sob exame. O alcance desses anúncios, porém, também dependia de quais vizinhos os aceitaram, quais rotas esses vizinhos exportaram em seguida e quais redes a jusante selecionaram.

É por isso que o evento tornou-se um teste dos limites da validação de origem. Se um anúncio usa origem não autorizada ou um comprimento de prefixo não permitido por uma ROA, um operador com dados atuais validados e política de aplicação poderia potencialmente classificá-lo e rejeitá-lo como Inválido. Se uma rota manteve uma origem autorizada, mas foi carregada por um caminho AS inadequado, a mesma checagem de origem pode retornar Válido. Se nenhuma ROA de cobertura existia, o resultado seria normalmente NotFound, não Inválido. Os controles técnicos, portanto, têm alavancagem diferente sobre partes distintas do evento observado.

A evidência pública sustenta análise de responsabilização apenas se essas distinções forem preservadas. Remover os anúncios BGP, a evidência AS12389, observações de propagação, estado de ROA, decisões de aceitação a montante, monitoramento e coordenação de incidente deixaria uma discussão genérica de segurança, não a explicação deste incidente. Da mesma forma, tratar toda rota como a mesma falha atribuiria capacidades à RPKI que ela não foi projetada para ter.

A responsabilização aqui significa identificar quem tinha controle prático sobre uma decisão mensurável e quais evidências podem demonstrar essa decisão. Não significa inferir negligência, criminalidade, culpa individual, violação legal ou intenção de interceptação a partir de observações de roteamento externas. A CERT-EU disse que não ficou claro se o evento foi acidental.[2] O registro disponível não resolve essa incerteza, portanto a análise não pode resolvê-la por assertividade.

Linha do tempo forense

Uma reconstrução forense deve distinguir observações diretamente reportadas de inferências e eventos internos não resolvidos. Coletores de rota públicos e plataformas de monitoramento revelam visões específicas do plano de controle em vez de uma transcrição universal. A documentação do RIPEstat enquadra os dados de roteamento como observação de fontes disponíveis, com limites impostos por pontos de vista e cobertura de dados.[9] A cronologia a seguir, portanto, identifica o que foi reportado, o que é separado e o que permanece desconhecido.

Horário	Evento com evidência
Antes de 19:28 UTC, 1º de abril	O registro público não identifica a mudança de configuração inicial da Rostelecom, o roteador, o comando, o funcionário ou a sequência interna de aprovação que teria iniciado o incidente. Também não estabelece com precisão o estado de filtro pré-incidente e o estado RPKI em toda rede que aceitou mais tarde um anúncio.
Por volta de 19:28 UTC	O monitoramento da Qrator coloca o início da observação em torno de 19:28 UTC. Foi reportado que o AS12389 anunciava rotas associadas a um grande conjunto de outras redes.[1] Esse carimbo de tempo pertence ao registro de monitoramento da Qrator; não é prova de que todo roteador afetado recebeu sua primeira atualização nesse instante.
Durante a propagação subsequente	A Qrator reportou que os anúncios propagaram-se por Rascom AS20764, Cogent AS174 e Level 3 AS3356.[1] A observação estabelece a propagação visível subsequente por essas redes autônomas, mas não cada decisão de sessão, avaliação de route-map ou relação comercial por trás disso.
Durante a janela de aproximadamente uma hora	A Qrator contabilizou 8.870 prefixos afetados em quase 200 sistemas autônomos.[1] A CERT-EU resumiu posteriormente mais de 8.800 rotas de mais de 200 redes.[2] Essas são medições atribuídas, não prova de que toda rota tinha o mesmo estado de validação de origem ou a mesma consequência no plano de dados.
Durante a resposta ao incidente	A Qrator afirmou que a Rostelecom recebeu um alerta em tempo real e trabalhou com a Qrator na solução e restauração.[1] A CERT-EU também registrou cooperação com a empresa de monitoramento.[2] A sequência exata de escalonamento, mitigação e reversão da Rostelecom não é pública.
Por volta de uma hora após a primeira observação	A Qrator descreveu o evento como com duração de aproximadamente uma hora.[1] O relato público sustenta restauração dentro desse intervalo observado, mas não estabelece qual configuração ou retirada encerrou cada rota afetada nem se a convergência terminou simultaneamente em todos os pontos.
Incidente RPKI simultâneo	Separadamente, uma atualização de software de registro do RIPE NCC fez com que certas atribuições independentes de provedor fossem classificadas como não certificáveis, levando à exclusão de 2.669 ROAs.[3][5] Esse foi um erro de gestão de registros no plano de controle, distinto do comportamento de roteamento do AS12389.
2 de abril	O RIPE NCC restaurou as ROAs ausentes.[3][5] Essa restauração pertence à cronologia independente de recuperação do serviço RPKI e não deve ser apresentada como o mecanismo que encerrou o incidente da Rostelecom.
Análises subsequentes	Uma análise do Routing Working Group e uma retrospectiva posterior do RIPE NCC não encontraram relação direta entre os dois incidentes. Elas identificaram sobreposição envolvendo três detentores PI e 12 prefixos.[4][5]

Essa cronologia contém duas sequências simultâneas, porém analiticamente separadas. Uma ocorreu nos anúncios BGP e em sua aceitação entre fronteiras de rede. A outra ocorreu na produção e disponibilidade de registros de autorização de origem. A primeira dependeu de política de roteamento ativa; a segunda afetou quais dados de ROA validados ficaram disponíveis para as entidades dependentes da validação. A interseção limitada torna legítimo perguntar se os registros ausentes alteraram o tratamento de 12 prefixos. Não torna a exclusão de ROA a causa do evento de 8.870 prefixos.

A cronologia também separa tempo de detecção de tempo de gatilho. A observação aproximada de 19:28 da Qrator é evidência de quando o evento se tornou visível em seus pontos de observação. Não identifica quando uma mudança interna foi registrada, confirmada ou distribuída. Da mesma forma, a duração aproximada de uma hora descreve a observação externa. Não consegue estabelecer o período exato em que cada rota individual esteve presente em cada base de informação de roteamento.

A ausência de uma cronologia roteador a roteador é consequente. Sem ela, não se pode tirar conclusão confiável sobre o primeiro vizinho aceitante, a sequência de avaliações de política, quais rotas foram retiradas ou corrigidas primeiro, ou se algumas redes continham partes do evento enquanto outras ainda o propagavam. Uma reconstrução responsável preserva essas lacunas em vez de transformar um traço de monitoramento de rotas em um log interno imaginado.

O que a propagação observada estabelece

As observações de caminho AS estabelecem que informação de alcançabilidade inesperada não ficou confinada a uma única rede. BGP é um protocolo distribuído: um UPDATE aceito por um sistema autônomo pode tornar-se entrada para o processo de decisão de outro sistema e, conforme política, um anúncio para vizinhos adicionais.[12] A cadeia de propagação AS12389–AS20764–AS174–AS3356 anunciada, portanto, marca uma sequência de decisões operacionais em domínios administrativos separados.[1]

Essa sequência não prova que toda rede nomeada aceitou todos os 8.870 prefixos ou que um caminho idêntico alcançou toda a Internet. Também não revela por que uma política de importação específica aceitou uma rota. Um operador pode ter se baseado em filtros de prefixo de cliente, dados de Internet Routing Registry, validação RPKI, exceções manualmente mantidas, limites amplos, premissas contratuais ou uma combinação disso. A evidência congelada não revela a configuração de abril de 2020 de nenhum upstream ou peer citado.

Apesar disso, a evidência de propagação é útil porque identifica onde existiram oportunidades de contenção. A AS12389 controlava se originava ou exportava os anúncios. Cada rede conectada diretamente controlava se os aceitava. Cada anunciante subsequente controlava outra decisão de exportação. Redes a jusante controlavam seleção de rota e qualquer política de validação local. Isso é controle compartilhado em sentido técnico preciso: múltiplos operadores possuíam mecanismos independentes capazes de alterar pelo menos parte dos resultados de roteamento.

Controle compartilhado não pode ser convertido automaticamente em culpa compartilhada. Um caminho AS visível sozinho não revela os termos de uma relação de roteamento, a precisão do inventário de prefixos de um operador, o estado de seus caches, ou se uma rota pertencia à parte de vazamento de rota aprendida ou reoriginação mais específica do evento. Ele identifica um ponto de decisão, não o significado jurídico ou moral dessa decisão.

Quatro categorias de roteamento que não devem ser fundidas

O termo “vazamento” costuma ser usado de forma ampla, mas este incidente não pode ser interpretado corretamente sem separar quatro condições de roteamento. A RFC 7908 define vazamentos de rota em torno da propagação de anúncios além de seu escopo intencional, especialmente quando o caminho resultante viola a ordem esperada de relações entre cliente, provedor e peer.[17] Esse conceito é diferente de autorização de origem.

Vazamento de política de rota aprendida.Uma rede aprende uma rota legítima de um vizinho e a exporta para outro vizinho fora do escopo de política pretendido para a rota. O detentor de prefixo pode manter origem autorizada no fim do caminho AS. O erro está no escopo de exportação: a rede intermediária age como trânsito onde a política não pretendia que ela fizesse isso. Como o ASN de origem e o comprimento de prefixo originais ainda podem coincidir com uma ROA, a Validação de Origem de Rota pode classificar a rota como Válido, embora o caminho seja comercial ou operacionalmente inadequado.
Anúncio de origem não autorizada.Um ASN origina um prefixo que o detentor de recurso relevante não autorizou. Se uma ROA de cobertura autoriza um ASN diferente e uma entidade dependente da validação possui dados atuais validados, o anúncio pode ser classificado como Inválido por incompatibilidade de origem.[13]-[15] O termo técnico “origin hijack” é às vezes aplicado a essa condição, mas o rótulo isolado não estabelece intenção, interceptação, conduta criminosa ou propriedade legal.
Reoriginação mais específica.Um ASN anuncia um prefixo mais específico dentro do agregado de outra rede e se apresenta como origem. Uma ROA de cobertura pode tornar o mais específico Inválido, seja porque o ASN de origem difere, seja porque o tamanho anunciado excede omaxLengthda ROA. Um mais específico pode atrair seleção porque o emparelhamento de prefixo mais longo ocorre antes da comparação de caminho padrão BGP. Mesmo assim, o registro público não estabelece o propósito de cada reoriginação ou o efeito no plano de dados de cada prefixo.
Vazamento de política com origem válida.O prefixo, ASN de origem e comprimento estão autorizados, mas o caminho AS ou a relação de exportação viola política pretendida. Esse é o exemplo mais claro do limite da ROV. A validação de origem responde se a origem está autorizada sob dados de ROA disponíveis. Não responde se um AS intermediário tinha autorização para fornecer trânsito, se o caminho seguiu uma relação permitida ou se a rota deveria ter sido exportada para aquele vizinho.

As análises públicas indicaram que as observações de abril de 2020 incluíam uma mistura de rotas aprendidas e reoriginações mais específicas.[4] A divisão exata é desconhecida. Seria, portanto, impreciso descrever todas as 8.870 rotas como origens não autorizadas, todas como vazamentos de política com origem autorizada ou todas como Inválidas por RPKI. Cada descrição substituiria uma distribuição não resolvida por uma categoria uniforme sem suporte na evidência.

NotFound também deve permanecer distinto. Quando não existe uma ROA de cobertura validada, a validação de origem normalmente retorna NotFound.[14] Esse estado é comum em um sistema de roteamento com cobertura incompleta. Não é evidência positiva de origem autorizada, mas também não é automaticamente um resultado Inválido e não identifica, por si só, má conduta. Uma rede pode escolher política local para rotas NotFound; esse estado apenas indica que o conjunto validado de ROAs disponíveis não trouxe autorização de cobertura contra a qual testar o anúncio.

Essas categorias delimitam o alcance de controles potenciais. Filtros com inventário de prefixo por cliente podem conter tanto origens não autorizadas quanto aprendidos exportados incorretamente no limite de cliente. A ROV poderia identificar algumas origens não autorizadas ou anúncios de comprimento excessivo onde existam ROAs adequadas. Controles de relacionamento de caminho podem tratar vazamentos de política com origem válida. Nenhuma categoria única de filtro necessariamente cobre toda a mistura.

O que a validação de origem da RPKI pode demonstrar

A RPKI fornece uma estrutura suportada criptograficamente pela qual detentores de recursos podem criar Autorizações de Origem de Rota. Uma ROA expressa que um ASN específico está autorizado a originar um prefixo, sujeito a um comprimento máximo.[13] Uma entidade dependente da validação recupera e valida material RPKI, produz cargas de ROA validadas e disponibiliza essas informações a sistemas de roteamento ou motores de política. O RIPE NCC opera serviços de certificação e gestão de ROA para recursos em sua região, mas não programa centralmente os roteadores de toda rede participante.[10]

Para um conjunto específico validado, a validação de origem pode produzir três resultados relevantes. Uma rota éVálidaquando uma autorização de cobertura permite o ASN e o comprimento de prefixo observados. ÉInválidaquando autorizações de cobertura existem, mas nenhuma permite a combinação de origem e comprimento. ÉNotFoundquando não há autorização de cobertura disponível.[14] Essas são declarações relativas aos dados mantidos por uma entidade dependente da validação em um momento, não propriedades globais atemporais embutidas na própria rota.

Essa qualificação importa durante um incidente de gestão de registros. Duas redes dependentes podem ter visões validadas diferentes temporariamente porque seus tempos de sincronização de repositório, estados de cache, comportamento de expiração ou respostas operacionais divergem. A RFC 7115 discute a importância operacional do processamento por entidades dependentes e das informações validadas.[15] A evidência congelada não revela o conteúdo exato de cache visto por cada rede durante a observação de uma hora da Rostelecom.

A alegação de que uma rede “viu um Inválido” exigiria evidência sobre o estado de cache e política dessa rede no momento relevante.

A ROV fornece evidência de origem útil. Se um anúncio AS12389 para um prefixo com cobertura conflitar com o ASN autorizado, ou se um mais específico exceder ummaxLengthaplicável, um operador com aplicação poderia potencialmente rejeitar como Inválido. Essa condição depende da ROA relevante existir, estar corretamente expressa, chegar a cache atual, ser incorporada na política de roteamento e aplicada sem exceção superior. Retirar qualquer desses elementos pode alterar o resultado ao vivo.

Um resultado Válido prova muito menos que “rota segura”. Ele não valida a sequência AS intermediária. Não certifica relações de cliente-provedor ou de peer. Não mostra que uma rede intermediária estava autorizada a exportar uma rota aprendida. Não estabelece que o caminho de dados alcançou o destino pretendido, que não houve desvio de tráfego ou que contatos operacionais responderiam. Uma origem autorizada pode aparecer atrás de um caminho não pretendido.

Um resultado Inválido também tem significado delimitado. Ele mostra um conflito com autorizações de cobertura validadas disponíveis para aquela entidade dependente. Pode decorrer de origem não autorizada, comprimento excessivo, intenção operacional obsoleta ou uma ROA errada. Não prova, por si só, intenção, interceptação ou conduta criminosa. Os operadores ainda dependem de gestão de mudança, tratamento de exceção e investigação para distinguir ataque de erro de configuração ou de registro.

NotFound fornece a evidência menos específica de origem. Não há autorização de cobertura validada no olhar da entidade dependente, então a ROV não pode confirmar nem contradizer a origem por meio de uma ROA. Tratar toda rota NotFound como hostil seria uma escolha local de política separada, não implicação do estado de validação. Isso também arriscaria rejeitar rotas legítimas de espaço sem cobertura de ROA.

O episódio de exclusão de ROAs do RIPE NCC ilustra essa distinção. Excluir 2.669 ROAs pode mudar algumas rotas de Válido ou Inválido para NotFound nas visões de entidades dependentes após sincronização, dependendo das autorizações de cobertura remanescentes e do timing de cache.[3][5] Isso não criou anúncios BGP de AS12389, não causou a exportação desses anúncios por redes intermediárias nem alterou caminhos AS completos. Para o incidente Rostelecom, a interseção documentada foi de apenas três detentores PI e 12 prefixos, e análise posterior não encontrou relação direta entre os incidentes.[4][5]

Portanto, a ROV universal não pode ser considerada que tenha evitado todo este incidente. Ela poderia ter restringido o subconjunto envolvendo anúncios que estavam Inválidos sob dados de ROA atuais e política aplicável. Não rejeitaria automaticamente um vazamento de política com origem aprendida cuja origem autorizada permanecesse inalterada. Também não validaria o caminho AS completo. Esse limite não é fraqueza da evidência; é a descrição correta do que o mecanismo foi projetado para responder.

Causa raiz

A sequência interna inicial na Rostelecom é desconhecida. As fontes públicas não identificam uma mudança de configuração específica, comando, roteador, decisão de revisão ou falha de automação. Elas mostram o comportamento externo de anúncios AS12389 e propagação observada, não o mecanismo interno que o gerou. Assim, a causa raiz do incidente de roteamento não pode ser reduzida a uma ação ou indivíduo nomeado com base no material disponível.

No nível observável, o incidente começou com comportamento de origem ou exportação AS12389 que introduziu rotas inesperadas no BGP, incluindo evidência interpretada como vazamento de rota aprendida e reoriginações mais específicas.[1][4] A aceitação e exportação subsequente por outras redes ampliou o escopo visível. Este é um encadeamento de eventos apoiado por observações de roteamento; não é uma determinação completa de causa raiz.

O incidente do RIPE NCC teve sequência técnica documentada distinta. A atualização de software de registro classificou algumas atribuições independentes de provedor como não certificáveis e excluiu 2.669 ROAs.[3][5] Esse problema de software e gestão de registros alterou os dados RPKI, enquanto o incidente da Rostelecom alterou anúncios BGP ao vivo. Análise posterior não encontrou relação causal direta entre eles.[4][5] Combinar os dois como causa única contrariaria o registro documentado.

Condições contribuintes

A primeira condição contributiva foi a dependência do BGP em política local em cada fronteira de rede. BGP distribui alcançabilidade, mas operadores definem o que aceitar, preferir e anunciar.[12] Uma rota que deveria ter permanecido dentro de uma relação de política única pode propagar-se quando configurações sucessivas a permitem. A passagem observada por AS20764, AS174 e AS3356 demonstra múltiplos pontos de aceitação e exportação, embora não revele a política específica de qualquer um deles.[1]

A segunda foi a relevância desigual da autorização de origem. Rotas com ROAs conflitantes, porém de cobertura, podem ser candidatas a rejeição por ROV. Vazamentos de política com origem válida não seriam. Rotas sem ROAs de cobertura seriam NotFound. A mistura desconhecida de categorias impede qualquer análise defensável que atribua um único remédio de validação ao conjunto completo.

A terceira foi a dependência de dados operacionais atuais. Uma ROA criada corretamente não tem efeito no roteamento se entidades dependentes não a recuperam e validam, caches não estiverem atualizados, roteadores não receberem o resultado e política local não atuar sobre ele. A exclusão do RIPE NCC afetou temporariamente a camada de registro; sincronização de cache e aplicação local determinaram quando ou se essa mudança afetou decisões de rede.[3][10][15]

A quarta foi filtragem distribuída. Filtros de prefixo de cliente, controle de máximo de prefixo, registros de rota, validação RPKI e controles de política de exportação podem se complementar.[11][16] O registro público não estabelece quais desses controles estavam presentes, ausentes, contornados ou com escopo incorreto na Rostelecom ou nas redes de propagação em abril de 2020. São categorias de controle relevantes, não conclusões sobre configurações não documentadas.

A quinta condição foi visibilidade fragmentada. Provedores de monitoramento podem ver anúncios anormais de pontos de observação selecionados e alertar operadores, mas não possuem Adj-RIB-In de todo roteador, tabela local de roteamento ou histórico de configuração. O alerta da Qrator ofereceu evidência externa acionável.[1] Ele não poderia reconstruir de forma independente a falha interna inicial nem garantir que toda rede afetada convergiu ao mesmo tempo.

Evento desencadeador

O gatilho imediato dentro da Rostelecom permanece sem identificação. Não foi possível atribuí-lo com responsabilidade a uma pessoa, comando, roteador, contrato ou motivo com base no registro público. O primeiro evento externo defensável é a aparição dos anúncios AS12389 relevantes nos pontos de observação da Qrator por volta de 19:28 UTC.[1]

“Gatilho” não deve ser confundido com “condição”. Política de vizinho permissiva, cobertura de ROA incompleta, dados desatualizados ou monitoramento limitado podem permitir que um evento se espalhe ou atrasar sua contenção, mas nenhuma dessas condições prova o que iniciou os anúncios. Da mesma forma, a exclusão separada de ROAs foi contemporânea, não o gatilho documental para o comportamento roteado de AS12389.[4][5]

Detecção

A Qrator informou que detectou o evento em tempo real e avisou a Rostelecom.[1] Suas medições forneceram início aproximado, duração, escala e cadeia de propagação visível que ancoram a reconstrução pública. A CERT-EU resumiu posteriormente o evento e destacou a incerteza sobre se houve acidente, além da cooperação da Rostelecom com a empresa de monitoramento.[2]

A detecção externa é um controle importante de continuidade porque a visão interna de um operador pode não mostrar como vizinhos ou redes distantes recebem suas rotas. Sua limitação é igualmente importante: um alerta de monitoramento prova visibilidade nos pontos da plataforma de monitoramento. Não revela o momento exato do gatilho interno, cada decisão de seleção a jusante ou o impacto completo no plano de dados. Uma detecção forte combina telemetria local de sessão e política com observações de rota independentes.

Resposta

A Qrator afirmou que a Rostelecom trabalhou com ela na solução de problemas e restauração após receber o alerta em tempo real.[1] Isso respalda uma conclusão de coordenação do incidente. Não revela a cadeia interna de escalonamento, a identidade dos respondentes, a configuração inspecionada, a ação corretiva selecionada ou o horário exato de cada etapa.

A resposta das redes de propagação não foi documentada com o mesmo nível de detalhe no registro disponível. As opções práticas poderiam incluir filtragem de anúncios, alteração de preferência de rota, contato com redes adjacentes ou espera por atualizações corrigidas, mas seria especulativo afirmar que uma rede específica usou certo método. Responsabilização exige separar os controles disponíveis de ações comprovadas.

A resposta do RIPE NCC seguiu sua própria cronologia. Investigou as ROAs ausentes, restaurou-as em 2 de abril e posteriormente descreveu melhorias no monitoramento.[3][5] Essa resposta tratou integridade e disponibilidade dos registros RPKI. Não foi o mecanismo de resposta de roteamento por meio do qual os anúncios AS12389 foram corrigidos.

Recuperação

A observação de aproximadamente uma hora da Qrator e seu relato de solução e restauração sustentam a conclusão de que o incidente de roteamento visível foi controlado dentro dessa janela ampla.[1] Eles não identificam se a recuperação resultou de retiradas, anúncios corrigidos, mudanças de política de exportação, filtragem por vizinho ou combinação. Também não provam convergência simultânea em toda rede.

A recuperação operacional tem pelo menos três camadas. A camada de anúncio exige parar ou corrigir rotas inesperadas. A camada de propagação exige que vizinhos e redes a jusante processem a mudança. A camada de evidência exige monitoramento para confirmar que os caminhos anômalos desapareceram em pontos úteis de observação. Uma declaração baseada apenas em um roteador local pode perder propagação residual; uma baseada apenas em coletores externos pode perder estado interno.

A recuperação do serviço RPKI foi separada: o RIPE NCC restaurou as ROAs ausentes em 2 de abril.[3][5] Em seguida, as entidades dependentes dependeram de seus próprios processos de sincronização e validação para receber o estado reparado. Restauração no repositório e convergência em cada entidade dependente estão relacionadas, mas não são eventos idênticos.

Alocação de controle prático

A responsabilização fica mais clara quando o controle é alocado por decisão, e não por rótulo institucional amplo.

Ator	Controle prático	Limite evidencial
Rostelecom / AS12389	Originação e política de exportação de rota, filtros específicos por vizinho, inventário de prefixos, revisão de configuração, rollout de mudança, escalonamento e rollback	A mudança inicial e a sequência interna de resposta não são públicas
Rascom AS20764, Cogent AS174, Level 3 AS3356 e outras redes de propagação	Seus próprios filtros de importação e exportação, política de relacionamento, limites de prefixo, uso de ROV, exceções, resposta a anomalias e anúncios subsequentes	As configurações de abril de 2020, estados de cache e contratos dessas redes são desconhecidos
Detentores de prefixo	Precisão de registros de recursos, criação de ROA, escolha de ASN de origem e`maxLength`, contatos operacionais e monitoramento independente de rotas	Suas decisões individuais não podem ser inferidas uniformemente em quase 200 sistemas autônomos afetados
RIPE NCC	Sistemas de certificação e gestão de ROA, testes de software, monitoramento de serviço, rollback, restauração e divulgação de incidente dentro de seu papel	Não selecionou nem impôs os caminhos usados por roteadores operados de forma independente
Operadores dependentes da validação	Sincronização de repositório, atualidade de cache, entrega de resultados de validação, políticas locais de Inválido/NotFound, exceções e decisões finais de roteamento	Sem observador global é impossível inferir a visão de validação de cada entidade em cada momento
Provedores de monitoramento de rotas	Coleta em pontos de observação, análise de anomalia, entrega de alertas, evidência de coordenação e relato pós-incidente	Observam visões de roteamento selecionadas e não controlam anúncios nem reconstruem cada ação interna

Essa alocação evita dois erros opostos. O primeiro concentra toda a responsabilização na rede de origem e ignora decisões independentes de aceitação que permitiram a propagação. O segundo dispersa o controle tão amplamente que nenhuma decisão tem responsável. A Rostelecom controlou o que o AS12389 anunciou ou exportou. Cada vizinho controlou sua própria aceitação. Cada rede subsequente controlou outra decisão de propagação. O operador de registro controlou a disponibilidade dos registros de origem. As entidades dependentes controlaram se esses registros influenciaram o roteamento.

Controle em uma camada não implica controle em outra. Um detentor de prefixo pode publicar uma ROA correta sem forçar que toda rede a recupere ou aplique. O RIPE NCC pode restaurar um registro removido, mas não pode retirar diretamente uma rota BGP de roteador de operador independente. Um provedor de monitoramento pode alertar a Rostelecom, mas não pode executar rollback. Um upstream pode rejeitar uma rota em sua borda, mas não reparar a configuração de origem. A continuidade operacional emerge quando esses controles funcionam em conjunto.

Essa alocação também limita a inferência. Um sistema autônomo que aparece em um caminho reportado é evidência de que seu identificador de rede apareceu na observação. Não é, por si, evidência do estado mental de um funcionário, de violação contratual ou de responsabilidade legal. Essas conclusões exigiriam registros além da evidência de roteamento considerada aqui.

Evidência de causa raiz versus evidência contributiva

Evidência de causa raiz identificaria o mecanismo interno que primeiro produziu o comportamento inesperado do AS12389: por exemplo, um delta de configuração, log de automação, histórico de commit, traço de sessão e carimbos de tempo compatíveis. Nenhum está presente no registro público. As observações externas de rota estabeleceram o evento e sua expansão, mas não preenchem essa lacuna interna evidencial.

Evidência contributiva tem função diferente. Uma rota aceita e exportada por redes sucessivas mostra que as políticas ativas no caminho observado não a bloquearam em fronteiras anteriores. Um anúncio Inválido visível além de uma rede validando poderia levantar questões sobre atualidade de dados, aplicação ou exceções, desde que o estado RPKI real dessa rede fosse conhecido. Uma fuga com origem válida que passa pela ROV mostraria, em vez disso, que autorização de origem era controle insuficiente para aquela parte.

Uma prova de gatilho conectaria uma ação interna ao primeiro anúncio inesperado. A prova de detecção mostraria quando sistemas de monitoramento identificaram a anomalia. A prova de resposta registraria contatos, decisões e mudanças. A prova de recuperação mostraria retirada ou correção nas visões locais e externas. Manter essas classes separadas torna uma análise pós-incidente testável e impede um carimbo de detecção funcionar como carimbo de gatilho.

Remediação mensurável

O incidente apoia remediação em camadas, mas as medidas devem ser expressas como controles observáveis, não como alegações de culpa.

Primeiro, uma rede de origem ou trânsito pode manter inventário de prefixos por vizinho e testar política de importação e exportação antes de implantação. Medidas úteis incluem o número de prefixos permitidos por vizinho, mudanças em relação à linha de base aprovada, ASNs de origem inesperados, anúncios mais específicos e rotas cuja classificação de relacionamento muda durante atualização proposta. Um teste deve distinguir rotas originadas localmente de rotas aprendidas de terceiros.

Segundo, operadores podem medir contenção em fronteiras externas. Sessões de clientes e peers podem ser verificadas para comportamento padrão de negação, allowlists explícitas, limites de máximo de prefixos e regras de exportação que impeçam rotas aprendidas de provedor ou peer serem enviadas para outra relação inadequada. Práticas gerais de filtragem e validação descritas em guias operacionais oferecem um modelo em camadas em vez de uma checagem universal única.[11][16]

Terceiro, as operações RPKI podem ser medidas ponta a ponta. Indicadores relevantes incluem idade de sincronização de repositório, progresso de série de cache, disponibilidade de feed validado, contagem de rotas Válidas, Inválidas e NotFound por sessão, exceções de política e alarmes para mudanças abruptas de cobertura de ROA. Um registro existente no sistema emissor é insuficiente se um cache obsoleto ou engine de política desconectado impede que ele influencie decisões ao vivo.[10][15]

Quarto, detentores de prefixo podem revisar se as ROAs refletem origens atuais e se omaxLengthnão é mais amplo do que o necessário para o plano operacional. Autorização mais restrita pode tornar alguns mais específicos não autorizados Inválidos, mas um valor excessivamente restritivo também pode invalidar anúncios legítimos de engenharia de tráfego. O ajuste correto depende dos planos reais de roteamento, e a análise posterior demaxLengthe exposição a subprefixos forjados reforça a necessidade de tratá-lo como decisão operacional precisa.[20]

Quinto, a resposta a incidentes pode ser avaliada por medidas de tempo: intervalo da primeira atualização anômala ao alerta interno; tempo até observação corroborada externa; tempo até contato do vizinho relevante; tempo para identificar a política afetada; tempo para parar nova propagação; e tempo para confirmar recuperação em múltiplos pontos de observação. O relato da Qrator demonstra o valor do alerta em tempo real e coordenação sem revelar todos esses intervalos.[1]

Um registro pós-incidente útil preservaria o primeiro anúncio observado, o estado de configuração, resultados de avaliação de política de rota, estado de cache RPKI, contatos de operadores, mudança correta e verificação externa final. Essa evidência permitiria que revisão posterior distinguisse falha de origem, falha de exportação, falha de aceitação, dados RPKI obsoletos e coordenação atrasada. Sem ela, os investigadores são forçados a inferir causas internas de observações globais parciais.

Essas medidas permanecem neutras sobre intenção e responsabilidade. Elas perguntam se um controle existia, se ele operou, se sua saída foi observada e quão rapidamente o sistema se recuperou. Isso é um método de responsabilização mais sólido do que assumir que anomalia de rota prova automaticamente malícia ou que uma tecnologia única deveria ter impedido todas as categorias de rota.

Evidências de registro e realidade operacional

Objetos de registro e ROAs são evidências essenciais. Um registro de banco associa informação administrativa a um recurso de rede, enquanto uma ROA expressa a autorização de origem de um detentor de recurso.[8][13] Precisão, unicidade e metadados de segurança atualizados tornam esses registros úteis para operadores e investigadores. Eles ajudam a responder quem é registrado para um recurso e qual ASN foi autorizado a originar um prefixo.

Registros não operam a Internet por decreto. Um roteador BGP aplica sua política ativa aos updates recebidos. Uma entidade dependente deve obter dados RPKI atuais. Um roteador deve receber os resultados de validação. Um operador decide o que rejeitar, preferir ou investigar. Filtros de exportação devem codificar relações pretendidas, e monitoramento deve revelar quando a propagação real diverge dessas intenções. Recuperação coordenada então transforma evidência em ação corretiva.

A exclusão separada de ROA pelo RIPE NCC reforça esse arranjo em dois lados. O registro e o serviço RPKI importam porque remover autorizações podia alterar a evidência de origem disponível às entidades dependentes. Ainda assim, a exclusão não reescreveu caminhos AS centralmente nem forçou redes a aceitar anúncios AS12389. A continuidade operacional dependia de restauração de registros, caches atuais, política de roteamento local, filtros ativos e coordenação de resposta atuando em cadeia.

Essa visão de camada operacional evita tratar o registro como autoridade soberana de imposição de caminho. Também evita descartar registros como irrelevantes apenas porque a aplicação é local. ROAs podem fornecer evidência verificável por máquina que torna certos conflitos de origem acionáveis. Seu valor é máximo quando precisão de registro, distribuição, saúde de cache e política local do operador são mensuráveis.

Contexto de design posterior, não requisitos retroativos

A RFC 8212 descreve uma postura padrão de rejeição para sessões BGP externas quando política de importação ou exportação não foi explicitamente configurada.[18] Como contexto de design, essa abordagem reduz o risco de uma relação incompletamente especificada trocar rotas por padrão. Ela é relevante para disciplina de configuração futura, mas não é evidência de que toda rede citada aplicou esse comportamento em abril de 2020 nem mecanismo de responsabilidade retroativa do incidente.

A RFC 9234 especificou posteriormente BGP Roles e o mecanismo Only-to-Customer, fornecendo sinais de protocolo para ajudar a identificar e prevenir certos vazamentos de rota com base em estrutura de relacionamento.[19] Esse trabalho trata de informação que a ROV não cobre: se a propagação de um caminho é consistente com papéis declarados. Não deve ser descrito como requisito de 2020, prova da causa do evento ou mecanismo comprovadamente disponível nas sessões observadas.

A RFC 9319 analisou posteriormente considerações operacionais demaxLengthe exposição de subprefixo de origem forjada.[20] Ela ajuda a explicar como uma autorização de cobertura pode ou não conter um anúncio mais específico. Não estabelece a configuração de ROA exata vista para cada prefixo afetado em 2020, e não pode transformar a contagem de 8.870 prefixos em contagem de rotas Inválidas.

Juntas, essas normas posteriores mostram por que o desenho em camadas é necessário. Política padrão de rejeição pode tratar ausência de configuração de relacionamento. BGP Roles e sinais de caminho podem tratar alguns vazamentos de escopo de política. RPKI pode tratar alguns conflitos de origem e violações de comprimento. Monitoramento e coordenação permanecem necessários porque nenhum mecanismo valida cada propriedade de uma rota.

O que este artigo não mistura

O evento de 2020 é distinto da anomalia financeira de rota de 2017 da Rostelecom. O episódio anterior envolveu tempo diferente, conjunto de rotas afetadas, duração e pergunta de atribuição distintos. Ele não é recontado aqui, e evidências daquele episódio não podem ser usadas para inferir intenção, causalidade recorrente ou responsabilidade pelo incidente de 1º de abril de 2020. Esta análise limita-se à cadeia de propagação AS12389 observada, sua janela de aproximadamente uma hora e os controles relevantes para esse evento específico.

O artigo também é distinto de uma análise genérica de má configuração de ROA e falha em modo comum. A exclusão do RIPE NCC importa aqui apenas como incidente contemporâneo separado com sobreposição medida de três detentores PI e 12 prefixos.[4][5] Uma teoria mais ampla de erros de criação de ROA obscureceria a pergunta concreta: quais partes desse evento roteado misto a validação de origem podia identificar e quais exigiam política de caminho e filtragem de fronteira.

Essa distinção preserva o centro de evidência do evento. A avaliação de responsabilização de 2020 depende de anúncios AS12389, propagação por AS20764, AS174 e AS3356, categorias de rota diferenciadas, estado de ROA dependente de tempo e decisões de roteamento independentes ao longo da cadeia. Sem esses elementos, a análise vira ou releitura de outro incidente da Rostelecom ou ensaio abstrato sobre RPKI.

Incertezas essenciais

A sequência interna de falha inicial permanece desconhecida. A divisão exata entre vazamentos de rota aprendida e reoriginações mais específicas permanece desconhecida. O conjunto completo de caminhos de encaminhamento e sintomas de usuário final permanece desconhecido. O estado RPKI visível para cada entidade dependente em cada momento permanece desconhecido. Os filtros de importação e exportação configurados por cada rede de propagação permanecem desconhecidos.

A cronologia completa de resposta também não está disponível. A Qrator documentou alerta em tempo real, cooperação, troubleshooting e restauração, mas não cada decisão interna.[1] A evidência não estabelece um responsável individual, interceptação intencional, ato criminoso, negligência ou responsabilidade legal. Também não mede uma indisponibilidade em todos os serviços que podem ter usado rotas no conjunto afetado.

Essas não são advertências menores. Elas delimitam a fronteira entre comportamento infraestrutural observado e especulação. Uma conta precisa pode identificar titulares de controle e oportunidades de contenção deixando intenção e conclusões legais sem resolução.

Conclusão

O incidente de roteamento da Rostelecom em 1º de abril de 2020 demonstrou que evidência de origem e evidência de política de rota respondem perguntas diferentes. A Qrator observou um evento AS12389 amplo iniciando por volta de 19:28 UTC, com duração aproximada de uma hora, propagando-se por Rascom, Cogent e Level 3. Ela contou 8.870 prefixos associados a quase 200 sistemas autônomos e relatou coordenação em tempo real com a Rostelecom.[1] Essas observações estabelecem escala, propagação e resposta, não a causa interna completa.

A exclusão simultânea de 2.669 ROAs do RIPE NCC foi uma falha operacional separada. Análises posteriores não encontraram relação causal direta com o vazamento da Rostelecom e identificaram apenas três detentores PI e 12 prefixos em interseção.[3]-[5] Essa evidência impede tanto a fusão causal quanto a alegação de que todas as rotas afetadas eram Inválidas.

A ROV poderia ter fornecido evidência acionável para algumas origens não autorizadas ou mais específicos de comprimento excessivo onde existiam ROAs de cobertura atuais e políticas aplicadas. Ela não podia validar caminhos AS completos nem rejeitar todo vazamento de política com origem válida. A responsabilidade operacional remanescente ficou em política de importação e exportação em execução, filtragem consciente de relacionamento, caches atuais, monitoramento independente e recuperação coordenada.

O resultado de responsabilização é, portanto, distribuído porém concreto. A Rostelecom detinha suas decisões de anúncio e exportação. Redes de propagação detinham decisões de fronteira. Detentores de prefixo detinham precisão de suas autorizações e contatos. O RIPE NCC detinha a confiabilidade de sua certificação e gestão de ROA. As entidades dependentes detinham atualização de dados e aplicação. Provedores de monitoramento detinham qualidade e velocidade de observações e alertas. Nenhum controlava o sistema inteiro, mas cada um controlava parte identificável da continuidade operacional.

O vazamento de rota da Rostelecom em 2020 definiu os limites da validação de origem como teste de responsabilização