[GTER] Hijack de prefixo em IRR

Diego Canton de Brito diegocantondebrito at outlook.com
Fri Sep 13 01:18:23 -03 2019 

Muito obrigado senhores, a planilha me ajudou a identificar um objeto de rota que o cliente transferiu de um ASN para outro e que acabei não deletando, a ideia do Renato de verificar se existem objetos e remover os proxyed automaticamente foi muito interessante e vou avaliar implementar isso em nossa ferramenta.
________________________________
De: gter <gter-bounces at eng.registro.br> em nome de Douglas Fischer <fischerdouglas at gmail.com>
Enviado: terça-feira, 10 de setembro de 2019 16:37
Para: Grupo de Trabalho de Engenharia e Operacao de Redes <gter at eng.registro.br>; Latin America and Caribbean Region Network Operators Group <lacnog at lacnic.net>
Assunto: [GTER] Hijack de prefixo em IRR

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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdrive.google.com%2Ffile%2Fd%2F1KFUfptAnZsAmbSVvVFyHK8bPH7yrOOhr%2Fview%3Fusp%3Dsharing&data=02%7C01%7C%7Cdb05ec8179f1412fda7a08d736287bda%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637037419819707707&sdata=S9mO%2FZClzOFMw2Llwg3GRBcYThhGBw6QSczNmk4Z51s%3D&reserved=0
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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.radb.net%2Fquery%3Fadvanced_query%3D%26keywords%3D45.70.72.0%252F22%26-T%2Boption%3D%26ip_option%3D%26-i%2Boption&data=02%7C01%7C%7Cdb05ec8179f1412fda7a08d736287bda%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637037419819707707&sdata=h9LvuS5gDWqmLFpuYqXWYC6%2BSHGV0PWcoF7srCYNngA%3D&reserved=0=

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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpeering.google.com%2F&data=02%7C01%7C%7Cdb05ec8179f1412fda7a08d736287bda%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637037419819717712&sdata=PaAQ0yC%2BzPc2Q%2B8LpkRwxcmnO%2FMutzIcELeSkGtXoAY%3D&reserved=0 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.lacnic.net%2Finnovaportal%2Ffile%2F3635%2F1%2F26-route-filtering-at-the-edge-as15169.pdf&data=02%7C01%7C%7Cdb05ec8179f1412fda7a08d736287bda%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637037419819717712&sdata=lUSzonu%2Bq2UBZUprx1OqadjQvjqFOEDoJxRLkCESOT8%3D&reserved=0
[2] https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fyoutu.be%2FOT9at07N7qM&data=02%7C01%7C%7Cdb05ec8179f1412fda7a08d736287bda%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637037419819717712&sdata=4%2FrDc3hNt8eR00MRAMS9son5STHXhqoDC4QRTW17K60%3D&reserved=0

--
Douglas Fernando Fischer
Engº de Controle e Automação
--
gter list    https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Feng.registro.br%2Fmailman%2Flistinfo%2Fgter&data=02%7C01%7C%7Cdb05ec8179f1412fda7a08d736287bda%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637037419819717712&sdata=YcCB4U5WiPvpAScaVpoFHz1bOmRNaG0ng28P%2Bd3%2FtRU%3D&reserved=0

More information about the gter mailing list