Resumo

  • O looking glass da SEACOM mostrava o /16 legítimo da SingNet, mas não o /24 anunciado sem autorização pela Innove. Uma sondagem de rota a partir da SEACOM, porém, alcançou saltos atribuídos à Innove.
  • A validação de origem classifica e permite rejeitar um anúncio na rede que a executa. Não obriga a vizinha TISparkle a rejeitar o prefixo mais específico.
  • O BMP pode registrar etapas BGP no roteador monitorado; não observa automaticamente a decisão do vizinho nem substitui medição do encaminhamento de pacotes.

O resultado vazio que parecia encerrar o caso

Uma consulta ao looking glass da SEACOM (AS37100) por 203.127.225.0/24 retornou que a rede não estava na tabela. Já 203.127.0.0/16 aparecia como rota válida originada pela SingNet (AS3758). Os pesquisadores preservaram ambas as respostas no anexo de seu Internet-Draft. O /24 era anunciado pela Innove Communications (AS17894), sem autorização de origem. Na visão local, a política ROV da SEACOM parecia ter funcionado.

O mesmo anexo traz uma pergunta diferente, feita com traceroute de AS37100 a 203.127.225.1. Os saltos passaram pela TISparkle (AS6762), FLAG Telecom (AS15412) e Globe Telecom (AS4775), chegando a endereços no AS17894. A ausência de uma rota local para o /24 não impediu que um pacote entregue a AS6762 seguisse a rota mais específica conhecida ali. Essa é a discrepância observável, não uma alegação de que todos os pacotes dos clientes foram medidos. O teste não confirma a resposta da aplicação no destino.

Os autores disseram ter comunicado o caso à Globe em 10 de fevereiro de 2025 e observado o padrão pela última vez em 24 de abril. Consideraram plausível uma configuração equivocada e não comprovaram má-fé. O texto é um rascunho individual do IETF em andamento, não uma norma aprovada. Ao recuperá-lo na sessão técnica da APNIC 62, Ritesh Mukherjee, da Nokia, transformou a discrepância na pergunta do “bom vizinho”: quanto vale o seu filtro quando o trânsito adiante não toma a mesma decisão?

A autorização termina antes do próximo roteador

O /16 pertence à rota legítima da SingNet. O /24 tem origem não autorizada. A RFC 6811 define a classificação Valid, Invalid e NotFound com base em autorizações ROA validadas, mas deixa a ação sobre Invalid à política local. A SEACOM podia rejeitar o /24 e escolher o /16 em direção à TISparkle. Se esta aceitou o /24, o encaminhamento pelo prefixo mais longo passava a prevalecer dentro de sua rede. Um ROA não instala filtros na infraestrutura alheia e tampouco autentica todo o AS_PATH.

Mukherjee incluiu outros episódios nos slides, mas eles não autorizam um remédio único. Em 16 de junho de 2026, anúncios de prefixos Telegram apareceram com origem AS18101. A reconstrução do BGPHorizon registra 91.108.4.0/22 às 07:17:27 UTC, com AS62041 como origem autorizada, observação por quatro redes pares em cinco coletores e uma segunda onda de anúncios mais específicos. São provas de anúncios visíveis e de incompatibilidade de origem; não determinam a motivação nem a quantidade de usuários afetados. O caso Vodafone Idea de 2021 envolveu uma grande enxurrada de anúncios, para a qual um limite de prefixos por sessão tem função própria. Esse limite não julga sozinho a legitimidade de um único /24.

Visibilidade não é comando

O BMP da RFC 7854 permite transmitir vistas anteriores e posteriores à política de importação para pares configurados. Uma vista pré-política pode conservar o anúncio descartado, se ele chegou àquele roteador e o par estava sendo monitorado. A seleção de pares pode ser parcial; alterações intermediárias podem ser comprimidas e o carimbo de tempo pode não estar disponível. Mesmo uma coleta impecável na SEACOM não revelaria uma rota que só a TISparkle recebeu. E o BMP não lê por si só a FIB nem os pacotes da rede vizinha.

É necessário combinar registros de pontos de vista distintos e sondagens ativas, mantendo a identidade do roteador, do par, da família de endereços, da etapa RIB e das lacunas do coletor. O repositório RAVEN da Nokia anuncia correlação entre BMP, ROV e ASPA; o exemplo exibido nos slides é ilustrativo. Documentação de capacidade não demonstra implantação nos operadores do episódio, nem detecção em segundos, nem prevenção efetiva.

Também é preciso separar volume de validade. A RFC 7454 recomenda máximos de prefixos por sessão dimensionados para o tráfego esperado e sua expansão. Eles contêm aumentos anormais, não resolvem a rota isolada da Innove. A verificação ASPA trata de relações entre cliente e provedor no caminho AS e segue em desenvolvimento. Não há base para apresentá-la como proteção já operante nesse incidente.

O que as fontes permitem concluir

Os resultados decisivos estão na seção 4 e no anexo A do rascunho de Li e colegas. O relato da APNIC situa a apresentação, e o BGPHorizon fornece a verificação independente de parte do episódio Telegram. As RFCs 6811, 7854 e 7454 delimitam mecanismos diferentes. Não há aqui censo atual de adoção, medida completa de perda de tráfego ou prova de intenção e de eficácia do produto anunciado.