[lacnog] Hijack de prefixo em IRR

Mar 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
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20190910/e24bfc8c/attachment.html>