Vazamento de rota da Telekom Malaysia em 2015 e

Resumo

O monitoramento independente situa o início de uma grande explosão de anúncios BGP do AS4788 da Telekom Malaysia por volta das 08:43 UTC de 12 de junho de 2015. O BGPMon relatou aproximadamente 179.000 prefixos anunciados, enquanto o RFC 7908 posteriormente citou o evento como um exemplo importante de vazamento de rota no qual a Level 3 aceitou e propagou cerca de 179.000 prefixos. [2][10]
Diferentes análises relatam contagens de rotas distintas porque usam coletores, janelas de tempo e definições diferentes. A análise de Geoff Huston discutiu aproximadamente 2.500 rotas recém-visíveis e examinou um conjunto de 22.577 rotas afetadas. Esses números não podem ser combinados em uma falsa precisão. [1][2]
O AS3549 da Level 3 não apenas observou os anúncios do AS4788. Ele os aceitou e propagou, estendendo o raio de explosão através de uma grande rede de trânsito global. A ThousandEyes mediu perda severa de pacotes e caminhos terminais em vários pontos de presença da Level 3. [2][3]
As evidências suportam um vazamento de política de relacionamento: rotas aprendidas de pares parecem ter sido reanunciadas para provedores de trânsito upstream. A configuração exata do roteador, mapa de rota, comando, software e cadeia de aprovação da Telekom Malaysia não são públicos neste pacote. [1]
A responsabilidade é dividida pelo controle. O AS4788 controlava sua política de exportação e ciclo de vida do mapa de rota. O AS3549 controlava o que aceitava de um cliente, os checks de volume e caminho aplicados e se as rotas aceitas eram propagadas. As redes downstream controlavam sua própria política de importação e monitoramento.
A validação de origem RPKI comum não é uma resposta completa para este evento. A maioria dos caminhos vazados manteve origens legítimas. A autorização de origem pode ser válida enquanto um caminho viola a intenção de exportação do cliente, par ou provedor. [1][15][16]
Padrões posteriores esclarecem controles possíveis. O RFC 8212 torna a política explícita de importação e exportação o requisito padrão para eBGP, enquanto o RFC 9234 adiciona Funções BGP sensíveis ao relacionamento e o atributo Only to Customer. São orientações de controle retrospectivas, não prova de violação de conformidade de 2015. [11][12]
Uma reivindicação de reparo confiável requer mais do que restauração. Precisa de uma reconstrução congelada do conjunto de anúncios, da política de sessão pretendida, evidências de configuração antes e depois, testes contra a mesma classe de vazamento, observação independente de rota e prova de que tanto o lado exportador quanto o receptor podem conter a recorrência.

Um anúncio de rota se tornou autoridade sobre o tráfego de outras pessoas

O BGP é frequentemente apresentado como o protocolo que diz à Internet onde as redes estão. Essa descrição é precisa, mas incompleta. Um anúncio BGP é também uma reivindicação de autoridade operacional.

Quando um sistema autônomo diz a outro que um prefixo é alcançável através dele, o destinatário pode preferir esse caminho e anunciá-lo adiante. Outras redes podem então direcionar o tráfego para o caminho anunciado. A rota não traz garantia de que a rede anunciante tem capacidade suficiente, de que o caminho está em conformidade com relacionamentos comerciais ou de que cada operador intermediário pretendia fornecer trânsito. O BGP distribui informações de alcance e dados de caminho AS; a política determina quais reivindicações uma rede aceita e repete. [8]

Essa camada de política é onde o evento de 2015 da Telekom Malaysia se tornou globalmente consequente.

Fontes independentes dizem que uma grande explosão de anúncios começou por volta das 08:43 UTC de 12 de junho. O AS4788 da Telekom Malaysia anunciou um enorme conjunto de rotas para o AS3549 da Level 3. A Level 3 aceitou essas rotas e as propagou para pares e clientes. O tráfego seguiu os caminhos alterados. O caminho através do AS3549 e AS4788 poderia parecer atraente sob a política de roteamento, mesmo que as interconexões não pudessem transportar com segurança o volume resultante. Perda de pacotes e latência aumentaram, e serviços muito além da própria base de clientes da Telekom Malaysia se tornaram difíceis ou impossíveis de alcançar.

[2][3]

O evento não foi um certificado forjado, um comprometimento de um nome de domínio ou uma origem de rota fabricada no sentido mais simples. Muitos prefixos afetados ainda terminavam em seus sistemas autônomos de origem legítimos. A mudança prejudicial foi que o AS4788 se inseriu como trânsito para rotas que não se esperava que exportasse nessa direção. Um caminho pode ser sintaticamente válido, livre de loops e com origem válida, enquanto viola a relação econômica e operacional sob a qual foi aprendido.

Essa distinção é importante para a responsabilidade. Se o problema é descrito apenas como "a Telekom Malaysia vazou rotas", a responsabilidade parece terminar na rede exportadora. Mas a propagação BGP é bilateral em cada sessão. Um lado anuncia; o outro lado decide o que aceitar, preferir e anunciar adiante. Uma grande rede de trânsito tem maior poder de propagação do que um cliente isolado. Esse poder cria um dever de filtragem e evidência correspondente.

A questão central não é qual operador cometeu o erro primeiro. É quantos controles independentes tinham a capacidade prática de parar o erro antes que ele se tornasse a interrupção de outras redes.

A cronologia é clara nas bordas e incompleta dentro das redes

O BGPMon relatou que o AS4788 começou a anunciar um conjunto massivo de rotas às 08:43 UTC. Seu monitoramento viu um aumento acentuado nas mensagens de atualização BGP ao mesmo tempo em que a perda de pacotes começou. A análise descreveu aproximadamente 179.000 prefixos anunciados e deu um prefixo do Facebook afetado como exemplo de um caminho que passava pelo AS3549 e AS4788 antes de chegar à origem legítima. [2]

A ThousandEyes descreveu independentemente a mesma sequência ampla. Observou novos caminhos através da Telekom Malaysia e Level 3, perda severa de pacotes e rotas terminais em locais como Amsterdã, Chicago, Frankfurt, Londres, Los Angeles, Seattle e Washington. Disse que a Level 3 parou de aceitar as rotas por volta das 10:45 UTC e o serviço começou a voltar ao normal. [3]

O BGPMon relatou melhora por volta das 10:40 e limpeza mais ampla por volta das 11:15. Esses horários devem permanecer atribuídos. Um coletor de rotas, plataforma de medição ativa, operador de trânsito e usuário final não observam o mesmo evento no mesmo instante. Um filtro pode parar novos anúncios enquanto caminhos obsoletos permanecem selecionados em outro lugar. As retiradas podem se propagar de forma desigual. O congestionamento pode persistir após a remoção do gatilho do plano de controle. A recuperação é, portanto, uma sequência, não um timestamp universal.

A análise do RIPE Atlas posteriormente usou o evento para examinar como grandes falhas na infraestrutura principal afetam a conectividade de ponta a ponta. Encontrou evidências tanto de roteamento de tráfego contornando a infraestrutura sob estresse quanto de falhas de ponta a ponta. Os autores foram explícitos sobre a representatividade: mesmo um sistema de medição global diverso observa apenas um conjunto finito de caminhos e destinos. [4]

A cronologia pública tem um forte registro externo e um registro interno fraco.

Observadores externos podem identificar o início aproximado, os caminhos que mudaram, o volume de atualizações de rota, perda de pacotes, latência e recuperação ampla. Eles não podem ver o mapa de rota privado, o terminal do operador, a mudança aprovada, o limite de prefixo configurado, a fila de alertas ou a conversa de decisão entre a Telekom Malaysia e a Level 3.

Essa lacuna deve moldar a linguagem do artigo.

É defensável dizer que o AS4788 emitiu as rotas, o AS3549 as aceitou e propagou, e a alcance global sofreu. É defensável dizer que o padrão é consistente com rotas aprendidas de pares sendo exportadas para um provedor upstream. Não é defensável identificar o comando exato, roteador, funcionário, ticket de mudança ou defeito de software sem um registro de operador autenticado.

A análise de Geoff Huston usa linguagem probabilística sobre uma falha de política de rota e contém aparentes variantes tipográficas de número AS em algumas passagens. A rede da Telekom Malaysia é AS4788. O artigo não deve transformar aparentes referências AS4877 ou AS4778 em atores adicionais ou usá-las para fabricar certeza sobre um dispositivo interno. [1]

Um registro completo de responsabilidade conectaría a linha do tempo externa à evidência interna:

a última política de exportação conhecida como boa;
a mudança proposta e normalizada;
o momento em que cada roteador ou sessão a recebeu;
o número e tipo de prefixos selecionados para exportação;
alertas para volume de rota e violações de relacionamento;
estado de aceitação e máximo de prefixo no AS3549;
contatos de escalação e mensagens;
o comando ou ação automatizada que parou a propagação;
evidência de coletor mostrando retirada e convergência;
testes provando que a política reparada rejeita a mesma classe de rota.

Sem essa cadeia, a restauração é visível, mas o aprendizado institucional permanece difícil de verificar.

As contagens de prefixo descrevem diferentes visões, não um fato disputado

Grandes incidentes da Internet atraem um único número memorável. Aqui, esse instinto pode tornar o registro menos preciso.

O BGPMon escreveu que o AS4788 começou a anunciar cerca de 179.000 prefixos e depois se referiu a aproximadamente 176.000 prefixos vazados. O RFC 7908 cita o "vazamento massivo de rota da Telekom Malaysia" de cerca de 179.000 prefixos. A ThousandEyes descreveu uma grande porção da tabela de roteamento global. [2][3][10]

A análise de Huston usou diferentes visões do evento. Mostrou uma mudança líquida na tabela de roteamento envolvendo milhares de rotas recém-visíveis e retiradas, então examinou 22.577 rotas em um conjunto afetado específico. [1]

Esses números podem coexistir porque um evento BGP não tem apenas uma unidade natural.

Um observador pode contar cada mensagem UPDATE, cada prefixo único anunciado através de um caminho inesperado, cada prefixo recém-visível em um coletor, cada melhor caminho alterado, cada rota mais específica, cada rota ainda presente em um horário selecionado ou cada origem afetada. Os coletores recebem diferentes feeds. Uma rota pode ser anunciada, retirada e reanunciada. Alguns caminhos são visíveis em um coletor e não em outro. Uma tabela completa e um conjunto afetado filtrado respondem a diferentes perguntas.

A escolha editorial responsável é preservar a definição da medição.

O artigo pode dizer que o BGPMon e o RFC 7908 descreveram cerca de 179.000 anúncios ou prefixos vazados em suas reconstruções. Pode dizer que a análise separada de Huston examinou um conjunto de 22.577 rotas e observou milhares de adições e retiradas de tabela. Não deve fazer a média dos valores, escolher o maior para drama ou apresentar um como um censo completo do impacto no usuário.

A mesma disciplina se aplica aos serviços afetados. O BGPMon e a ThousandEyes identificaram exemplos envolvendo grandes plataformas e serviços financeiros. Esses exemplos demonstram escopo e efeitos colaterais. Eles não estabelecem que cada prefixo experimentou a mesma perda de pacotes, que cada serviço ficou indisponível ou que cada usuário foi roteado através do AS4788.

As contagens se tornam evidência de responsabilidade quando suas definições são retidas:

contagem de anúnciostesta se o volume de exportação era anômalo;
contagem de prefixos únicostesta a amplitude da autoridade de roteamento reivindicada;
contagem de melhores caminhos alteradostesta quantas redes selecionaram o vazamento;
visibilidade do coletortesta a propagação;
volume de tráfego e perda de pacotestesta o dano operacional;
contagem de clientes e aplicativos afetadostesta o impacto nos negócios;
duração da retiradatesta a contenção.

Cada medida deve ter um proprietário, limite e registro retido. Um provedor de trânsito pode aceitar o conjunto normal de alguns milhares de prefixos de um cliente, mas colocar em quarentena uma mudança repentina de ordem de magnitude. Um sistema de monitoramento de rotas pode detectar caminhos que violam as expectativas do cone do cliente, mesmo quando o volume bruto de prefixos permanece abaixo de um limite estático. Uma análise post-mortem pública pode explicar ambas as medidas em vez de oferecer um total manchete.

Falsa precisão não é apenas um problema de escrita. Pode esconder qual controle falhou.

A política de relacionamento é a estrutura invisível por trás da alcance BGP

A Internet não é uma malha plana na qual cada sistema autônomo oferece trânsito gratuito a todos os outros. As redes compram trânsito, vendem trânsito e fazem peering sob relacionamentos que moldam a política de rotas.

Uma regra operacional simplificada funciona assim:

rotas aprendidas de clientes podem ser anunciadas para clientes, pares e provedores;
rotas aprendidas de pares podem ser anunciadas para clientes, mas normalmente não para outro par ou provedor;
rotas aprendidas de provedores podem ser anunciadas para clientes, mas normalmente não para outro provedor ou par.

Essas regras produzem o familiar modelo "livre de vale". Um caminho pode subir de clientes para provedores, cruzar no máximo uma relação de peering e descer em direção aos clientes. Um caminho que desce e depois sobe novamente pode indicar que uma rede está fornecendo trânsito não intencional. [1][10]

Relacionamentos comerciais reais são mais complicados. Duas redes podem ter papéis diferentes em lugares, famílias de endereços ou serviços diferentes. Trânsito parcial, peering pago, servidores de rotas e arranjos regionais nem sempre se encaixam em um único rótulo. Essa complexidade é uma razão para documentar e testar a política, não uma razão para omiti-la.

A reconstrução de Huston diz que o AS4788 parecia coletar rotas de pares de pontos de troca e reanunciá-las para redes de trânsito upstream. Nesse modelo, rotas aprendidas lateralmente foram exportadas "ladeira acima". A Level 3 então aceitou e propagou os caminhos. [1]

O protocolo em si não pode inferir todos os relacionamentos comerciais privados do caminho AS. Uma sequência de números AS legítimos não diz se uma rota era contratual e operacionalmente permitida para viajar através deles. Esse conhecimento deve ser codificado em política local, objetos de roteamento publicados, papéis negociados, comunidades, dados de cone de cliente ou outro sistema de validação.

É por isso que os vazamentos de rota permanecem difíceis. Um roteador pode receber um UPDATE BGP válido de um vizinho autenticado, ver uma origem legítima, construir um caminho AS sem loop e ainda aceitar uma rota que viola o relacionamento pretendido.

A responsabilidade operacional, portanto, exige que as redes tornem suas expectativas verificáveis por máquina sempre que possível:

classifique cada sessão eBGP e cada política excepcional;
defina os prefixos e caminhos de cliente esperados do vizinho;
restrinja as exportações de acordo com como as rotas foram aprendidas;
compare uma política proposta com o relacionamento pretendido;
rejeite ou coloque em quarentena expansão inexplicada;
retenha uma explicação legível por humanos para exceções;
teste a política contra condições representativas de tabela completa.

O evento público mostra o que acontece quando a intenção do relacionamento permanece implícita ou a aplicação é ineficaz. Uma rota pode cruzar uma sessão e se tornar uma reivindicação global antes que qualquer humano leia um ticket.

O AS4788 controlou a exportação, mas o AS3549 controlou a aceitação e propagação

A Telekom Malaysia tinha o controle mais direto sobre o conjunto de anúncios que saiu do AS4788. Uma rede exportadora deve saber quais rotas originou, quais aprendeu de clientes, quais aprendeu de pares ou provedores e quais classes podem ser enviadas para cada vizinho.

Esse controle começa antes da ativação da configuração.

Uma mudança deve ser compilada na política real de prefixo e caminho AS que um roteador aplicará. Uma revisão deve comparar o resultado com cones de cliente esperados, contagens de rotas e regras de relacionamento. Um ambiente de teste ou avaliador offline deve alimentar rotas representativas através da política e mostrar o que seria exportado. Uma verificação independente deve sinalizar rotas aprendidas de pares ou provedores selecionadas para outra sessão não cliente.

O registro público não estabelece se tais controles existiam no AS4788, se uma configuração de rotina mudou ou se um estado latente foi acionado. Ele estabelece a saída: um grande conjunto de rotas inseguras foi exportado.

O limite de controle da Level 3 é separado e igualmente importante para a propagação global.

O AS3549 escolheu se as rotas recebidas do AS4788 eram elegíveis, como eram preferidas e para onde eram anunciadas. Um grande provedor de trânsito tem conhecimento específico do cliente que terceiros arbitrários não têm. Pode saber a contagem de prefixos esperada, rotas de cliente registradas, histórico observado, relacionamentos de cone de cliente e propósito da sessão. Pode aplicar:

política de importação explícita;
listas de prefixo derivadas de dados de roteamento autenticados;
restrições de caminho AS e cone de cliente;
limites de máximo de prefixo;
verificações de comprimento de rota e bogon;
detecção de vazamento sensível ao relacionamento;
política de quarentena ou preferência reduzida para anomalias;
aprovação humana para expansão excepcional.

O relato do BGPMon diz que a Level 3 aceitou os anúncios e os anunciou para pares e clientes. As rotas então atraíram tráfego e contribuíram para o congestionamento na Level 3 e nos principais locais de peering. [2]

Isso não significa que um upstream pode garantir que toda rota de cliente está correta. Filtros estáticos podem ficar desatualizados. Clientes multi-homed podem legitimamente alterar anúncios. Roteamento de emergência pode expandir um conjunto. Política complexa pode tornar os cones de cliente difíceis de calcular. Um filtro muito restritivo pode causar uma interrupção por si só.

Mas esses custos não apagam a agência do provedor. Eles definem o problema de engenharia.

Um provedor de trânsito com poder de propagação global deve ser capaz de responder:

Qual era a faixa normal de contagem de rotas e forma de caminho para este cliente?
Quais mudanças exigiam pré-coordenação?
O conjunto aceito incluía rotas com outros grandes pares ou provedores atrás do cliente?
Existia um limite de máximo de prefixo e foi definido contra uma linha de base realista?
A sessão tinha uma exceção que desabilitava ou enfraquecia verificações?
Qual alerta disparou primeiro?
Quem poderia suprimir as rotas sem esperar pelo cliente?
Como o tráfego colateral foi protegido durante a investigação?

A responsabilidade segue essa capacidade prática de limitar o dano. O erro de exportação do AS4788 e a aceitação do AS3549 não são explicações mutuamente exclusivas. São falhas de controle sucessivas na mesma cadeia de propagação.

A concentração de trânsito transformou erro de política em dano compartilhado

Nem todo vazamento de rota causa um incidente global. O raio de explosão depende de onde o vazamento é aceito, quão atraente o caminho se torna, quão amplamente é propagado e se as redes receptoras têm capacidade para transportar o tráfego redirecionado.

A Level 3 era um grande provedor de trânsito global. Uma vez que o AS3549 propagou os caminhos, redes e clientes longe da Malásia podiam selecioná-los. O tráfego que normalmente seguia caminhos diretos, regionais ou melhor provisionados foi puxado para um caminho através da Level 3 e AS4788. [2][3]

Dois mecanismos de dano se seguiram.

O primeiro foi o desvio direto de caminho. Um prefixo de destino poderia adquirir um caminho selecionado através do AS3549 e AS4788. Os pacotes então viajavam em direção à Telekom Malaysia, mesmo que ela não pretendesse fornecer trânsito global para esse destino. A interconexão poderia saturar, pacotes poderiam ser descartados e a latência aumentaria.

O segundo foi o congestionamento colateral. Um serviço não precisava selecionar um caminho vazado para sofrer. Se dependesse da capacidade da Level 3 ou de um ponto de presença congestionado, a carga de tráfego extraordinária poderia prejudicar sua rota normal. A ThousandEyes descreveu exemplos em que a própria rota de um serviço permaneceu inalterada, mas o congestionamento dentro da Level 3 reduziu a disponibilidade. [3]

Esse segundo mecanismo é importante porque amplia a lente de responsabilidade para além de uma lista de prefixos vazados. A infraestrutura de trânsito compartilhada pode transmitir dano a clientes cuja política de roteamento não está diretamente errada. Capacidade, isolamento e engenharia de tráfego tornam-se parte do problema de contenção.

As redes não podem provisionar todos os links para uma fração arbitrária da tabela global escolhendo-o repentinamente. Limites econômicos são reais. No entanto, um provedor de trânsito pode projetar controles para que um conjunto anômalo de rotas não adquira essa autoridade de tráfego em primeiro lugar.

O evento, portanto, conecta a segurança de roteamento com o risco de concentração. Uma rede de trânsito altamente conectada melhora a alcance em condições normais. A mesma conectividade amplifica uma falha de política quando rotas inseguras são aceitas e propagadas. A escala é tanto um ativo de resiliência quanto um multiplicador de raio de explosão.

A operação responsável deve tratar o alcance de propagação como uma variável de risco:

um anúncio pequeno de cliente local pode usar tratamento automatizado normal;
um anúncio repentino de cliente de rotas de muitas redes grandes não relacionadas deve exigir quarentena ou validação;
uma mudança que alteraria caminhos em muitas regiões deve desencadear medição de fora para dentro;
um provedor deve saber quais pontos de presença e interconexões receberiam tráfego redirecionado;
a contenção deve ser possível sem desabilitar desnecessariamente rotas saudáveis do cliente.

O objetivo não é eliminar a automação. É tornar a automação proporcional à autoridade que ela concede.

Controles de máximo de prefixo ajudam, mas não são uma política completa

Limites de máximo de prefixo são uma defesa intuitiva contra um grande vazamento. Se um cliente normalmente anuncia um conjunto limitado e de repente envia uma tabela enorme, o provedor pode avisar, rejeitar novas rotas ou encerrar a sessão.

O BGPMon sugeriu que o volume anormal de rotas também poderia fazer com que os limites de máximo de prefixo nas sessões da Level 3 com outras grandes redes disparassem, produzindo mais agitação e mudanças de caminho. [2]

Essa observação revela tanto o valor quanto o perigo de limites simples.

Na borda do cliente, um controle de máximo de prefixo bem calibrado pode parar uma expansão implausível antes da propagação ampla. Em sessões downstream, o mesmo mecanismo pode reagir depois que as rotas ruins já entraram em um grande provedor, potencialmente derrubando uma sessão inteira e deslocando o tráfego para outro lugar. Um limite pode conter um caminho enquanto desestabiliza outro.

Limites eficazes exigem contexto:

o agregado normal do cliente e prefixos mais específicos;
crescimento esperado;
cenários de manutenção e emergência;
comportamento separado de IPv4 e IPv6;
se as rotas rejeitadas falham fechadas ou mantêm o último conjunto conhecido como bom;
escalonamento de alerta antes de uma parada dura;
um processo de substituição seguro com expiração;
teste da resposta sob tráfego realista.

A contagem de rotas também não pode detectar todo vazamento. Um cliente pode vazar um pequeno número de rotas mais específicas altamente atraentes. Pode exportar rotas de um par poderoso sem aumentar muito o volume total. Pode substituir rotas legítimas de cliente por um conjunto não autorizado de tamanho semelhante.

O máximo de prefixo é, portanto, uma camada. Propriedade de prefixo, validação de cone de cliente, relacionamentos de caminho AS, tags de origem de rota e detecção de anomalias abordam diferentes formas de falha.

Um registro pós-incidente deve dizer quais camadas existiam, não apenas que "os filtros foram melhorados". Um limite de máximo de prefixo adicionado após o evento seria evidência significativa se o operador publicasse a linha de base, lógica de limite, modo de resposta e um teste usando o conjunto de anúncios reconstruído.

A validação de origem RPKI não teria resolvido a falha de política de caminho

Discussões de segurança de roteamento frequentemente usam RPKI como uma resposta geral para incidentes BGP. Essa abreviação é perigosa aqui.

A Infraestrutura de Chave Pública de Recursos permite que titulares de recursos numéricos da Internet criem declarações criptograficamente verificáveis. Uma Autorização de Origem de Rota identifica qual sistema autônomo está autorizado a originar um prefixo, sujeito às regras de comprimento de prefixo da autorização. A Validação de Origem de Rota pode classificar um anúncio recebido comparando seu prefixo e AS de origem com essas autorizações. [15][16]

O evento de 2015 do AS4788 foi em grande parte um vazamento de política de caminho, não uma simples origem não autorizada.

Para muitas rotas vazadas, a origem legítima permaneceu no final do caminho AS. O AS4788 se inseriu como trânsito e anunciou a rota para um relacionamento onde não era esperado. Um validador de origem poderia ver uma origem autorizada e classificá-la como válida, mesmo que a rota violasse a intenção de exportação do par/provedor.

A análise de Huston fez esse ponto diretamente. No conjunto de rotas que examinou, apenas uma pequena minoria envolvia o AS4788 aparecendo como a origem de uma forma que a filtragem ROA comum poderia abordar. A maior parte do problema envolvia informações de trânsito. [1]

Isso não torna o RPKI sem importância. A validação de origem pode parar origens não autorizadas, mis-originações acidentais e muitos sequestros. Pode reduzir uma classe de falsa alcance. Também fornece informações de recursos autenticadas que podem apoiar controles mais amplos.

Isso significa que a afirmação de controle deve ser precisa.

"Implantamos ROV" não prova proteção contra rotas que têm origens válidas, mas caminhos de relacionamento inválidos. Uma rede precisa de informações adicionais sobre quem pode fornecer trânsito para quem e quais caminhos são consistentes com a política. RPSL, dados de cone de cliente, comunidades, Funções BGP, o atributo Only to Customer, trabalhos relacionados a ASPA e filtros específicos do operador abordam partes desse problema em diferentes níveis de maturidade.

A mensagem responsável é em camadas:

RPKI valida autoridade de origem;
política explícita de importação e exportação restringe sessões;
controles sensíveis ao relacionamento restringem a propagação de caminho;
monitoramento detecta anomalias que dados estáticos perdem;
coordenação operacional contém o que a prevenção não para.

Confundir essas camadas produz falsa garantia e aprendizado pós-incidente fraco.

Registros de rota podem publicar intenção, mas intenção desatualizada não é controle

A Linguagem de Especificação de Política de Roteamento foi projetada para descrever políticas de roteamento nos Registros de Roteamento da Internet. RPSL e RPSLng podem expressar política de importação e exportação, conjuntos de sistemas autônomos, conjuntos de rotas e intenções relacionadas. [13][14]

Em princípio, um provedor pode usar dados de política autenticados e mantidos para gerar filtros para um cliente. Um cliente pode publicar os prefixos e relacionamentos AS que espera anunciar. Pares podem comparar rotas observadas com a intenção declarada.

A análise de Huston explica a atração e as limitações. Os dados do registro podem estar incompletos, desatualizados, duplicados em bancos de dados ou muito grossos para relacionamentos específicos de sessão. Política complexa pode ser difícil de expressar e manter. Alguns registros historicamente permitiam entradas de terceiros com autoridade fraca. [1]

A lição errada é que os registros de rota são inúteis. A lição certa é que um objeto de registro é evidência apenas quando sua propriedade, frescor, escopo e uso são verificáveis.

Um pipeline de filtragem maduro deve registrar:

o registro e objetos usados;
autenticação e autoridade de manutenção;
a última atualização bem-sucedida;
expansão de conjuntos AS em prefixos e caminhos concretos;
conflitos entre registros;
exceções locais;
o diff do filtro gerado;
o resultado da implantação no roteador;
monitoramento para divergência entre política publicada e observada.

O MANRS enquadra a segurança de roteamento como responsabilidade operacional coletiva. Suas ações de operador enfatizam filtrar anúncios, manter contatos de coordenação e publicar informações que outros possam validar. O guia de implementação atual discute granularidade de prefixo e caminho AS e recomenda controles que impeçam que rotas aprendidas de clientes ou intermediárias sejam exportadas para pares não clientes inadequados. [17][18]

Esses documentos atuais são posteriores ao evento de 2015 em sua forma atual. Devem ser usados como uma estrutura de controle, não como evidência legal retroativa.

O evento mostra por que a estrutura é importante. Uma política conhecida apenas por uma configuração de roteador é difícil de validar para outra rede. Uma política publicada, mas nunca compilada em filtros, é apenas documentação. Um filtro compilado a partir de dados desatualizados pode rejeitar rotas válidas ou aceitar inválidas. A responsabilidade exige a cadeia da intenção declarada ao comportamento implantado e às rotas observadas.

Rejeição padrão muda o modo de falha

O RFC 8212, publicado em 2017, atualiza o comportamento do BGP para que rotas em uma sessão eBGP não sejam importadas nem exportadas a menos que uma política explícita tenha sido configurada. [11]

Esta é uma escolha de design enganosamente importante.

Um padrão permissivo torna a alcance fácil durante a configuração inicial. Também significa que uma política ausente pode silenciosamente se tornar "aceitar tudo" ou "anunciar tudo". Um operador deve lembrar de adicionar toda regra protetora antes que a sessão transporte rotas.

Uma postura de rejeição padrão muda o modo de falha. Política ausente não produz troca de rotas, o que é visível e local, em vez de propagação global não intencional. Os operadores ainda podem escrever uma política explícita incorreta. O RFC 8212 diz isso. O controle não resolve erros semânticos, filtros desatualizados ou exceções intencionais.

No entanto, codifica um princípio sólido de responsabilidade: a alcance global deve exigir uma decisão de política afirmativa.

Para uma sessão cliente-trânsito, essa decisão deve ser revisável:

quais prefixos podem ser aceitos;
quais origens e caminhos de cliente são esperados;
quais rotas podem ser exportadas de volta;
como as exceções são aprovadas;
o que acontece quando os dados da política não estão disponíveis;
qual sistema possui o rollback;
que evidência prova a implantação.

Se toda borda eBGP relevante usasse um padrão estrito com política explícita correta, um filtro ausente teria falhado fechado. A evidência pública não pode mostrar se o comportamento semelhante ao RFC 8212 teria impedido este incidente exato porque não expõe as configurações reais de 2015. O RFC continua sendo um teste retrospectivo útil: a troca de rotas exigia autoridade explícita e limitada em ambos os lados?

Funções BGP e Only to Customer abordam informações de relacionamento

O RFC 9234, publicado em 2022, padroniza Funções BGP e o atributo Only to Customer. Vizinhos podem negociar funções como provedor, cliente, par, servidor de rotas e cliente de servidor de rotas. Rotas propagadas podem carregar informações que ajudam a aplicar a direção de relacionamento esperada e detectar vazamentos. [12]

Esse mecanismo visa a lacuna visível no evento AS4788. Uma origem legítima e caminho sem loop não revelam se uma rota aprendida de um par pode ser enviada a um provedor. Informações de relacionamento tornam essa política mais explícita na troca de protocolo.

O padrão ainda depende de configuração e implantação corretas. As redes devem atribuir funções com precisão. Relacionamentos complexos exigem cuidado. A adoção parcial limita a proteção. Rotas e equipamentos legados permanecem. Nenhuma característica do protocolo elimina a necessidade de monitoramento e coordenação operacional.

O valor é que ambos os lados podem comparar expectativas. Um rótulo local unilateral pode estar errado sem feedback imediato. Uma função negociada pode falhar o estabelecimento da sessão ou marcar um caminho quando as duas extremidades discordam. O atributo Only to Customer pode ajudar a identificar rotas que não devem viajar para outro provedor ou par.

Novamente, esta é uma orientação posterior. Seria historicamente impreciso dizer que o AS4788 ou AS3549 falhou em usar um padrão de 2022 em 2015.

O incidente fornece o caso de teste:

Uma rota aprendida de um par pode ser exportada para um upstream sem uma violação de política detectável?
O upstream pode identificar que o caminho do cliente inclui rotas fora do relacionamento de cliente esperado?
Algum dos lados pode parar a rota antes da propagação global?
A evidência distingue uma exceção de política de um vazamento acidental?

Mecanismos modernos sensíveis a funções devem ser avaliados contra um conjunto de rotas reconstruído semelhante ao AS4788, não apenas contra exemplos sintéticos que correspondem a uma topologia limpa.

O monitoramento deve comparar rotas com a intenção, não apenas disponibilidade

O monitoramento de disponibilidade detecta o dano depois que os usuários começam a perder alcance. O monitoramento de rotas pode identificar a anomalia do plano de controle mais cedo.

O registro público de 2015 foi preservado por várias formas de observação:

BGPMon processou fluxos de atualização e identificou a explosão de anúncios;
RouteViews e RIPE RIS mantiveram arquivos BGP brutos;
ThousandEyes combinou medições de rota e rede;
RIPE Atlas forneceu medições ativas de ponta a ponta;
analistas independentes compararam caminhos, contagens de prefixo e tempo. [2][3][4][5][6]

Esses sistemas viram fatias diferentes. Essa diversidade é uma força. A visão interna de um único provedor pode perder como suas rotas aparecem em outro lugar. Uma sonda ativa pode ver perda de pacotes, mas não a política que a causou. Um coletor de rotas pode ver um caminho AS, mas não todo caminho de tráfego ou sessão privada.

Sistemas de detecção modernos podem procurar vazamentos de rota usando topologia, relacionamentos AS, histórico de rotas e propagação anormal. A Cloudflare descreve a detecção pública de vazamentos de rota como uma forma de superfície de caminhos anômalos, enquanto a documentação do RIPE Atlas suporta medição reproduzível a partir de sondas distribuídas. [19][20]

A detecção deve ser vinculada à ação.

Um alerta que diz "a contagem de rotas aumentou" é fraco se ninguém possui o limite ou pode suprimir a rota. Um caminho de incidente útil define:

o relacionamento esperado e conjunto de rotas;
a condição de anomalia;
confiança e tratamento de falsos positivos;
o operador autorizado a colocar em quarentena;
uma ação de contenção segura;
confirmação externa;
retenção de evidência;
revisão pós-evento.

A primeira resposta nem sempre precisa derrubar a sessão inteira. Um provedor pode reduzir a preferência, colocar em quarentena rotas inesperadas, preservar o último conjunto aceito conhecido como bom ou rejeitar apenas caminhos fora do cone do cliente. A ação correta depende da capacidade do roteador e do design do cliente.

O monitoramento também deve distinguir prevenção de detecção. Publicar um alerta de vazamento de rota após a propagação global é uma evidência pública valiosa. Não prova que o provedor tinha um controle de pré-propagação. Relatórios de responsabilidade devem dizer qual estágio detectou o evento e qual estágio o parou.

Uma mudança segura de política de rota precisa de evidência de byte atual

A configuração de roteamento frequentemente passa por modelos, bancos de dados, automação, compiladores de política e sintaxe específica do fornecedor antes de chegar a um roteador. Um revisor humano pode aprovar uma representação enquanto o dispositivo recebe outra.

A cadeia de evidência deve vincular os bytes atuais em cada estágio:

política de origem ou solicitação de mudança;
dados de relacionamento e prefixo normalizados;
mapa de rota ou linguagem de política gerada;
configuração específica do dispositivo;
diff da configuração candidata;
hash da configuração confirmada;
conjunto de rotas anunciadas e aceitas resultante;
observação de coletor externo.

Isso é importante porque "a política foi revisada" é ambíguo. Qual versão foi revisada? Um trabalho de automação expandiu um conjunto AS após aprovação? Um instantâneo de registro desatualizado produziu o filtro? Um comando manual de emergência contornou o pipeline normal? Todos os roteadores receberam a mesma saída?

Um sistema de mudança responsável deve falhar se esses vínculos divergirem.

Antes da implantação, deve reproduzir rotas representativas através da política compilada. Para condições semelhantes ao AS4788, os testes devem incluir:

rotas originadas pelo cliente;
rotas do cone do cliente;
rotas aprendidas de pares;
rotas aprendidas de provedores;
rotas contendo grandes redes de trânsito;
mais específicos inesperados;
uma entrada súbita de escala de tabela completa;
anúncios mistos válidos e inválidos.

O teste deve afirmar comportamento positivo e negativo. Rotas válidas de cliente devem continuar passando. Rotas aprendidas de pares e provedores não devem escapar para um upstream. O provedor aceitador deve rejeitar independentemente caminhos inconsistentes com a função esperada do cliente.

Após a implantação, coletores de rotas ou looking glasses devem verificar o resultado observável. Um hash de configuração sozinho não prova que o roteador anunciou apenas as rotas pretendidas. Estado do plano de controle, bugs de dispositivo e interação com outra política podem alterar o comportamento efetivo.

Essa disciplina de byte atual não é burocracia por si só. É como uma organização prova que o código, a política e as rotas sendo discutidas são os mesmos objetos que produziram ou evitaram o dano.

Restauração não é o mesmo que reparo verificado

As fontes públicas mostram que as rotas foram retiradas ou pararam de ser aceitas e o serviço se recuperou nas horas seguintes. Isso é restauração operacional.

Reparo pergunta uma questão mais difícil: a mesma classe de rota poderia escapar novamente?

Um programa de remediação crível congelaria um conjunto de incidentes representativo do RouteViews, RIPE RIS e logs internos. Identificaria o relacionamento pretendido para cada rota e reproduziria as decisões de exportação e importação em um ambiente de teste.

Para o AS4788, o teste verificaria que rotas aprendidas de pares ou provedores não podem ser selecionadas para exportação para o AS3549 a menos que uma exceção explícita e revisada se aplique. Para o AS3549, verificaria que um cliente não pode anunciar caminhos fora do cone de cliente esperado ou exceder um volume justificado sem quarentena.

O programa então geraria evidência:

testes falhos antes da correção;
mudanças de política ou sistema;
testes aprovados após a correção;
versões de dispositivo e software;
cobertura de implantação;
exercícios de alerta e contenção;
observações de rota externa;
inventário de exceções e expiração;
propriedade do monitoramento contínuo.

O reparo também deve testar condições degradadas. O que acontece se os dados do registro não estiverem disponíveis? O sistema falha fechado, usa um último conjunto conhecido como bom ou aceita tudo? O que acontece se o detector de anomalias estiver inativo? Um operador pode isolar a sessão através de um caminho de gerenciamento independente? Uma parada de máximo de prefixo preserva rotas críticas do cliente ou as derruba todas?

A divulgação pública não precisa expor termos comerciais privados ou configuração explorável. Pode declarar a classe de falha, limite de política afetado, controles adicionados, método de teste, cobertura de implantação e data de verificação.

Sem essa evidência, "consertamos o filtro" é uma afirmação sobre intenção. Com ela, clientes e pares podem avaliar se o operador mudou o sistema que permitiu a propagação global.

A responsabilidade não deve colapsar em culpa pessoal

Um vazamento de rota da Internet frequentemente se torna uma história sobre um engenheiro digitando um comando errado. O registro público aqui não estabelece essa história. Mesmo que uma única ação tenha desencadeado o evento, o impacto global exigiu múltiplas decisões de sistemas e organizações.

Um operador projeta a interface de configuração. Escolhe se as mudanças são geradas ou escritas à mão. Define relacionamentos de par e provedor. Decide quais testes são obrigatórios, se um segundo revisor é necessário, quão rápido a política se propaga e se o rollback é independente.

Um provedor de trânsito decide quanta confiança depositar em um anúncio de cliente, quais filtros são econômica e operacionalmente viáveis e qual anomalia desencadeará contenção. A liderança decide se o trabalho de segurança de roteamento tem pessoal, janelas de manutenção e autoridade para interromper o tráfego de receita.

Culpa pessoal pode obscurecer esses controles. Também pode desencorajar a divulgação. Um modelo de responsabilidade melhor pergunta:

Quem tinha a capacidade de evitar que a rota saísse?
Quem tinha a capacidade de rejeitá-la?
Quem tinha a capacidade de limitar sua propagação?
Quem poderia detectar o dano de forma independente?
Quem poderia retirar ou colocar em quarentena?
Quem reteve evidência?
Quem tinha autoridade para financiar e verificar a remediação?

Essas perguntas podem identificar responsabilidade sem reivindicar intenção ou negligência que fontes públicas não provam.

Também evitam que a responsabilidade se dissolva em "a Internet é descentralizada". Descentralização significa que nenhum operador controla todos os caminhos. Não significa que cada operador carece de controle sobre seus próprios anúncios, sessões e decisões de propagação.

O que clientes e pares podem razoavelmente exigir

A maioria dos clientes não pode auditar os roteadores de um provedor de trânsito. Pares não podem ver todos os processos de mudança privados. Ainda assim, podem exigir evidência apropriada para a dependência.

Antes de um incidente, um operador pode publicar:

contatos de roteamento precisos;
prefixos e sistemas autônomos registrados;
conjuntos de rota e AS;
uma política de alto nível de peering e filtragem;
cobertura RPKI;
suporte para mecanismos relevantes de função e validação;
canais de status e incidente.

Durante um incidente, pode comunicar:

a classe de rota ou sessão afetada;
se os anúncios ainda estão se propagando;
ação de contenção;
regiões e serviços conhecidos;
incerteza de medição;
evidência de recuperação;
próximo horário de atualização.

Após um incidente, pode fornecer:

limites de origem e aceitação;
definições de contagem de rotas;
linha do tempo com proveniência;
controles que falharam;
controles que contiveram o dano;
remediação testável;
limitações restantes.

Os clientes também devem testar sua própria exposição. Multi-homing não garante independência se ambos os provedores dependem do mesmo upstream. Uma rota de backup pode existir, mas perder sob preferência local. Anúncios mais específicos podem sobrepor a diversidade pretendida. O tráfego pode evitar um caminho vazado, mas sofrer congestionamento em um provedor de trânsito compartilhado.

Monitoramento de rota independente, medições RIPE Atlas e verificações de looking glass podem revelar parte dessa exposição. [4][5][6][20]

O dever é proporcional. Um serviço público crítico ou plataforma financeira deve entender a concentração upstream mais profundamente do que um site pessoal de baixo impacto. Mas nenhum cliente pode compensar totalmente por um provedor de trânsito aceitar e espalhar um conjunto massivo de rotas inseguras.

O que o registro público não pode provar

O conjunto de fontes suporta uma forte análise de responsabilidade de rede, mas não suporta uma post-mortem interna completa.

Não pode provar:

o roteador ou local exato da Telekom Malaysia;
o comando ou modelo de configuração exato;
se o gatilho foi uma mudança planejada, estado obsoleto, falha de automação ou erro manual;
a versão do software ou hardware;
os termos de relacionamento privados entre AS4788 e AS3549;
as configurações exatas de importação, exportação e máximo de prefixo em ambos os lados;
o primeiro alerta interno e resposta do operador;
mensagens privadas de coordenação;
uma contagem de prefixos reconciliada em todos os coletores;
um censo completo de usuários afetados ou perdas financeiras;
responsabilidade legal ou violação contratual;
a remediação durável implantada por qualquer operador.

O pacote também não deve transformar controles posteriores em requisitos históricos. O RFC 8212 foi publicado em 2017, o RFC 9234 em 2022, e o guia de implementação atual do MANRS reflete trabalho operacional posterior. Eles definem testes úteis atuais. Não provam quais configurações ou obrigações existiam em 2015. [11][12][18]

Da mesma forma, os dados atuais do RIPEstat são contexto atual de recursos de rede, não um instantâneo congelado do registro de 2015. [7]

Esses limites tornam a conclusão mais crível. A falha observável é suficiente para identificar controle dividido. O registro interno ausente é em si uma lacuna de responsabilidade, mas não é permissão para inventar um.

Um teste reutilizável de responsabilidade de filtragem upstream

O evento suporta um teste prático para qualquer cliente, provedor de trânsito ou par operando BGP em escala significativa.

1. Defina o relacionamento para cada sessão.
Registre provedor, cliente, par, servidor de rotas e funções excepcionais na granularidade onde a política difere.

2. Vincule rotas pretendidas a evidência autenticada.
Mantenha prefixos, origens, cones de cliente, conjuntos AS e exceções com propriedade, frescor e proveniência.

3. Compile a política antes da implantação.
Mostre as rotas e caminhos concretos que a política de importação e exportação aceitará. Revise o comportamento efetivo, não apenas o texto do modelo.

4. Falhe fechado quando a política explícita estiver ausente.
Nenhuma rota eBGP deve ganhar autoridade global porque um filtro estava ausente ou a recuperação de dados falhou.

5. Teste violações de relacionamento.
Reproduza rotas aprendidas de pares e provedores contra sessões de cliente e upstream. Verifique se a direção inválida é rejeitada tanto no exportador quanto no receptor.

6. Calibre controles de volume.
Defina limites de máximo de prefixo e anomalia contra comportamento normal, crescimento justificado e casos de emergência. Defina contenção segura em vez de depender apenas do desligamento completo da sessão.

7. Separe validação de origem e caminho.
Use RPKI para autoridade de origem, mas não descreva ROV como prova de propagação válida de relacionamento. Adicione controles de caminho e cone de cliente.

8. Monitore de fora.
Use coletores independentes e medições ativas para comparar rotas observadas e alcance com a política pretendida.

9. Dê à contenção um proprietário.
Identifique quem pode colocar rotas em quarentena, reduzir preferência, restaurar um último conjunto conhecido como bom ou redefinir uma sessão, inclusive fora das janelas normais de mudança.

10. Preserve evidência de byte atual.
Vincule política aprovada, configuração gerada, bytes implantados, estado de rota, alertas, decisões e observações externas.

11. Prove reparo com a classe de evento original.
Execute o vazamento reconstruído através de ambos os lados da sessão e mostre onde ele para. Teste variantes semânticas, não apenas uma lista de prefixos salva.

12. Publique o suficiente para que redes dependentes verifiquem.
Explique o limite de controle, definições de contagem de rotas, remediação e incerteza restante sem expor termos privados sensíveis.

Este teste não promete que vazamentos de rota desapareçam. Torna os deveres de prevenção, contenção e evidência explícitos em cada rede que pode conceder maior autoridade à rota.

Conclusão

O vazamento de rota da Telekom Malaysia em 12 de junho de 2015 demonstrou como uma política de roteamento local pode rapidamente se tornar dano à infraestrutura global.

O AS4788 emitiu um conjunto muito grande de rotas. O AS3549 as aceitou e propagou. O tráfego mudou para caminhos através da Level 3 e Telekom Malaysia. Perda de pacotes, latência e falhas de alcance se espalharam entre regiões e afetaram tanto serviços diretamente rerroteados quanto usuários expostos ao congestionamento em uma rede de trânsito compartilhada. Coletores de rotas independentes e plataformas de medição preservaram o contorno público. [1][2][3][4]

O evento não pode ser explicado responsavelmente como um mau anúncio por uma rede. Exportação e importação são controles separados. Um cliente tem o dever de anunciar apenas rotas autorizadas. Um provedor de trânsito tem um dever proporcional ao seu poder de aceitar e espalhar essas rotas. Pares e redes downstream têm monitoramento adicional e controles de importação. Nenhuma camada pode garantir perfeição, mas cada uma pode evitar que um erro adquira mais alcance.

A validação de origem RPKI é valiosa e insuficiente para esta falha de política de caminho. Os registros de rota podem publicar intenção e ainda assim ficar desatualizados. Os controles de máximo de prefixo podem conter volume e ainda assim perder vazamentos menores. Padrões posteriores de rejeição padrão e sensíveis ao relacionamento melhoram o modelo de controle, mas não provam retroativamente uma violação de 2015. A resposta durável é em camadas: política explícita, dados de rota autenticados, verificações de relacionamento, limites calibrados, monitoramento independente, contenção rápida e reparo reproduzível.

O risco segue o alcance que um anúncio pode adquirir. A responsabilidade segue quem poderia ter restringido esse alcance, quem escolheu propagá-lo e quem pode provar que a mesma classe de falha agora parará antes que o tráfego de outras pessoas se torne o teste.

Vazamento de rota da Telekom Malaysia em 2015 fez da filtragem upstream um teste de responsabilidade de trânsito