[GTER] Hijack de prefixo em IRR

Gustavo Santos gustkiller at gmail.com
Tue Sep 10 17:14:46 -03 2019 

Rodrigo,

Este seria o ideal, para Provedores de trânsito, isto é um "inferno". Como
a maioria dos clientes não tem ideia do que é um IRR e boa parte
dos "consultores" não fazem ideia, o ideal seria "forçar" o cliente a fazer
o registro dele e com isto, o Trânsito associaria o ASN do cliente no
AS-SET.

Porém se for depender disto, o cliente prefere "cancelar" o link ao invés
de fazer o cadastro. Então o workload vai todo para o fornecedor de
trânsito com registros Proxy.



On Tue, Sep 10, 2019 at 5:08 PM Rodrigo Meireles <rodmeireles at gmail.com>
wrote:

> Existem casos em que ao registrar "cada cliente" com o seu próprio cadastro
> do IRR ele consta como se o cadastro tivesse sido registrado no upstream.
> O correto não seria cada ASN ter o seu próprio cadastro individual?
>
> Em ter, 10 de set de 2019 às 16:53, Douglas Fischer <
> fischerdouglas at gmail.com> escreveu:
>
> > 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
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

More information about the gter mailing list