[GTER] Hijack de prefixo em IRR
Douglas Fischer
fischerdouglas at gmail.com
Tue Sep 10 16:37:23 -03 2019
TL-DR;
------
- Vários ASNs registrando em IRRs prefixos de seus clientes como se fosse
de seus ASNs.
- Principalmente no RADB.
- Está gerando sujeira nas bases de IRR.
- Prefix-lists geradas automaticamente estão ficando muito longas,
consumindo recurso do routers.
- Impossibilita a validação de AS-Path.
Fizemos uma consulta nos IRR dos prefixos delegados pelo NIC.BR que estavam
registrados para outros ASNs.
Agrupamos esses prefixos pelo campo maintainer e contamos a quantidade.
Segue a lista dos mais significativos:
Quantidade - Maintainer
2686 - MAINT-AS8966
865 - MAINT-AS18678
604 - MAINT-AS28283
494 - MAINT-AS28329
453 - MAINT-AS20473
Este é o Link para a planilha com as informações.
https://drive.google.com/file/d/1KFUfptAnZsAmbSVvVFyHK8bPH7yrOOhr/view?usp=sharing
Lá consta uma planilha dinâmica, e também planilhas com o detalhado dos 5
Mantainers com mais registro errados.
Contando a historinha do problema
-----------------------------------
Há cerca de uns 4 meses, um amigo identificou que algumas empresas
brasileiras estavam fazendo registros ERRADOS nos IRRs.
Ele me passou a informação e eu fiquei bastante triste com o que vi.
O procedimento deles era:
- Listar todos os prefixos do cone de AS do cliente deles
- Registrar como sendo de seu próprio ASN.
Eu pessoalmente entrei em contato por telefone com algumas dessas empresas,
e questionei o porque de eles fazerem isso.
A resposta deles foi:
"Muitos desses prefixos já estão registrados como proxyed por outros ASNs,
e quando tentamos registrar esses prefixos, não conseguimos... Então
registramos como nossos."
- Eu expliquei a eles porque fazer esse registro como seu próprio ASN era
errado, que era uma solução grosseira e de força bruta.
- Mencionei que dependendo de como as empresas consultem as bases de IRR
isso iria fazer com que os as prefix-Lists geradas automaticamente ficassem
com entradas duplicadas, muito longas, aumentando os recursos de
processamento dos routers para processar as mensagens de anúncio de rotas.
- E expliquei também que isso iria prejudicar os próximos passos de
segurança de roteamento, que é a validação de caminho(além da de origem).
Felizmente por algumas empresas essa informação foi muito bem recebida.
Inclusive desenvolvi relação de amizade por conta disso com um técnico
dessas empresas.
Tive a oportunidade de sugerir que no script de automação deles
incluíssem o teste:
(Se prefixo já existe registrado, usa registro atual.
Se prefixo não existe registrado, cria registro como proxyed.)
Infelizmente, algumas poucas empresas encararam a crítica negativamente.
- Alguns me atenderam, fizeram mil elogios por telefone, se comprometeram a
corrigir, e não fizeram nada.
- Alguns se sentiram ofendidos com a crítica(se sentiram ofendidos, e me
ofenderam).
- Alguns nem se deram ao trabalho de responder.
O problema só está aumentando!
------------------------------
Observando a lista dos TOP-5, podemos ver que o MAINT-AS8966 - Emix -
Emirates Telecommunications - está no topo da lista, com mais do que 3
vezes mais prefixos errados que o segundo colocado.
Bom, eu confesso que não entendi direito qual é o objetivo desses
registros...
Mas a grande maioria(talvez até a totalidade) dos prefixos estão com a
"descr: ChinaTel via EMIX".
Outra coisa que só aumentou as minhas dúvidas é que existem casos em que o
MAINT-AS8966 registrou um prefixos para vários Origin.
Como é o caso do prefixo 45.70.72.0/22, que está registrado pela EMIX para
AS266319, AS52965, AS53144.
https://www.radb.net/query?advanced_query=&keywords=45.70.72.0%2F22&-T+option=&ip_option=&-i+option=
Segue uma lista dos Prefixos Brasileiros registrados pelo MAINT-AS8966.
Quantidade AS-Origin IRR
773 AS61832 RADB
475 AS53144 RADB
450 AS52965 RADB
313 AS52551 RADB
154 AS52720 RADB
Alguém conseguiu entender a lógica disso?
Isso está correto?
Se não está correto, quem deve ser acionado para corrigir?
Porque estou cutucando isso agora?
----------------------------------
O Google, em seus GGCs e PNIs, começou a fazer filtrar prefixos baseado em
registros de IRR.
Isso foi informado em maio [1][2] deste ano no Lacnic 31 pelo Sr. Arturo.
E os triangulozinhos de alerta nos prefixos mostrados em
https://peering.google.com/ estão gerando um alvoroço entre os ISPs.
E eu estou feliz por isso!
Depois de 20 anos de RPSL, os ASNs estão se preocupando em cadastrar seus
prefixos corretamente nos IRRs.
Eu acredito que o medo de ficar sem acesso ao ASN do Google é que está
desencadeando essas ações um pouco desesperadas...
P.S.1: Tenham calma!
Segundo informações do próprio Google, por enquanto esses prefixos estão
apenas sendo tageados.
Apenas no futuro, depois de ter uma melhor referência de qual o tamanho do
dragão com que terão que lutar, é que decidirão como esses prefixos serão
descartados.
P.S.2: Reitero meu agradecimento ao Google por isso!
E aproveito para provocar Facebook, Cloudflare, Netflix, e até o ICCAN, a
fazerem o mesmo.
[1]
https://www.lacnic.net/innovaportal/file/3635/1/26-route-filtering-at-the-edge-as15169.pdf
[2] https://youtu.be/OT9at07N7qM
--
Douglas Fernando Fischer
Engº de Controle e Automação
More information about the gter
mailing list