[lacnog] Hijack de prefixo em IRR

Rubens Kuhl rubensk en gmail.com
Mar Sep 10 19:44:36 -03 2019 

O que eu achei curioso é que eu imaginava que só os upstreams estariam
nessa shame-list de proxy, mas o maior deles parece ser um caso de peering.

Algo a notar no caso de upstreams é que eles tinham a opção de cadastrar o
AS do cliente sob sua administração, mas cadastram só os blocos do do
cliente.
Isso é um problema self-inflicted, e o ponto é como a comunidade pode
amplificar essa dor para mudar esse comportamento.


Rubens




On Tue, Sep 10, 2019 at 1:37 PM Douglas Fischer <fischerdouglas en gmail.com>
wrote:

> 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
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20190910/9bb5296b/attachment.html>

Más información sobre la lista de distribución LACNOG