[GTER] Hijack de prefixo em IRR
Francisco J. Badaró Valente Neto
fjbvneto at gmail.com
Wed Sep 11 04:18:55 -03 2019
Que bom que a discussão da validação de origem volta à tona, e a
necessidade de ajuste no IRR.
O que joga a discussão em um patamar mais alto, a validação de origem.
Na verdade, "esta solução" , de desformidade em IRR , adotada por alguns
(muitos) AS´s tem efeito só de sujeira da base de IRR e ser um shame para
quem o fez.
O Route com falso origin só serve para depor contra que criou.
Esforço comunitário para o ajuste:
Disseminar conhecimento , Shame-list, depeering , warning... vários
caminhos.
MAS, para melhor efetividade, deve (IMHO) ser 'institucional' e aqui no
Brasil temos a posição do IX.BR que NÃO será adotado IRR por aqui.
Logo, não teríamos 'um braço forte , uma mão amiga' para forçar quem está
errado a se ajustar, por livre e espontânea pressão.
De fato, é incompreensível algumas posturas de alguns AS´s.
Do ponto de vista do protocolo, O problema é a falta de validação dos dados
imputados nas bases de IRR o que acaba comprometendo sua confiabilidade.
O origin poderia ser validado, consultando o LIR/RIR correlato e impedindo
que inputs inválidos na base sejam feitos, com rotas com as-origin desforme
a alocação registrada no LIR/RIR.
Precisamos fomentar o bom e correto uso do IRR e isto passa em conhecer
RPSL. Sobre IRR, há mais além do AS-SET e ROUTE que também deveriam ser
configurados corretamente. Existe na RPSL uma gama de registros possíveis,
que são informacionais interessantes (como por exemplo as informações sobre
alguns aspectos da política de roteamento do AS).
Infelizmente brodher Douglas e demais colegas, o que está ocorrendo "é uma
corrida do ouro", é o "fazer por demanda" , ai o que, pelos anos aprendi
com a observação lateral, é que, corridas de ouro, ações por pressão de
demanda em sua maioria são feitas desforme normas e padrões técnicos, ai
neste diapasão RFCs, conformidades protocolares, viram 'elemento
dispensável' infelizmente.
E vamos estender a recomendação da adoção da validação de origem por IRR
(Até mesmo para fomentar 'a futura' adoção de RPKI/ROA que seria a solução
'de melhor design' para este problema, já que a aberração de 'rotas com
origem inválida' um "Hijack de IRR" não seria possível), não só para estes
players, MAS PARA TODAS AS CDNs E TODOS OS IX´S.
QUE FAÇAM COMO O DECIX, SÓ PERMITAM SUBIR TRÁFEGO COM O IRR DEVIDAMENTE
CONFIGURADO, E, FAÇAM UMA VALIDAÇÃO MÍNIMA E EXPONHAM O RESULTADO DA
VALIDAÇÃO EM SEU LOOKING GLASS. NOVAMENTE , O DECIX COM O ALICE NOS MOSTRA
UM BOM EXEMPLO DE COMO FAZER.
Sim, o cenário ideal seria, CADA AS CONFIGURAR , NA DEVIDA FORMA , SEUS
OBJETOS EM IRR. E, IMHO, NÃO APENAS AS-SET E ROUTE.
Em teoria, o que o AS de Trânsito deveria se preocupar seria apenas com a
atualização do seu AS-SET , e os ROUTE deveriam ser criados, pelas suas
respectivas origens. Este seria, IMHO, o cenário ideal.
A validação cadastral de IRR (confirmação dos dados imputados, como a
validação do origin confirmando com o RIR, seria ideal), o RIR manter base
referência de IRR seria também , e as bases, serem íntegras neste sentido
seria a coroação.
Mas, acredito que os esforços serão em direção da maturidade e adoção de
RPKI/ROA, entretanto, pensar e agir no sentido de deixar "o IRR
redondinho", seria uma prática, um exercício para o fazer correto e repetir
isto, em RPKI e ROA, e o ecossistema (peers, CDNs, OTTs) validar origem por
RPKI/ROA.
Uma pesquisa em um LG como o Alice do DECIX , pelos prefixos filtrados ,
vai produzir um volume de dados interessante, mais interessante ainda é ver
as falhas de validação que Alice/DECIX pegou x os AS´s envolvidos
(inclusive TIER-1, que 'em teoria' deveriam dar o exemplo).
Em ter, 10 de set de 2019 às 19:45, <gter-request at eng.registro.br> escreveu:
> Send gter mailing list submissions to
> gter at eng.registro.br
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://eng.registro.br/mailman/listinfo/gter
> or, via email, send a message with subject or body 'help' to
> gter-request at eng.registro.br
>
> You can reach the person managing the list at
> gter-owner at eng.registro.br
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of gter digest..."
>
>
> Today's Topics:
>
> 1. Re: Hijack de prefixo em IRR (Rodrigo Meireles)
> 2. Re: Hijack de prefixo em IRR (Gustavo Santos)
> 3. Re: [lacnog] Hijack de prefixo em IRR (Rubens Kuhl)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 10 Sep 2019 16:57:53 -0300
> From: Rodrigo Meireles <rodmeireles at gmail.com>
> To: Grupo de Trabalho de Engenharia e Operacao de Redes
> <gter at eng.registro.br>
> Subject: Re: [GTER] Hijack de prefixo em IRR
> Message-ID:
> <
> CAATS19pM4Y6rTcz47PkfOpZLSN_piFs_qCwxkA3PWGvKB4_a3w at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> 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
> >
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 10 Sep 2019 17:14:46 -0300
> From: Gustavo Santos <gustkiller at gmail.com>
> To: Grupo de Trabalho de Engenharia e Operacao de Redes
> <gter at eng.registro.br>
> Subject: Re: [GTER] Hijack de prefixo em IRR
> Message-ID:
> <CAOXUNqmOLWeOYF24_HrS4hXFMdW4HJ=
> EHCBWg1P_vE_PEdR1hg at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> 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
> >
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 10 Sep 2019 16:44:36 -0600
> From: Rubens Kuhl <rubensk at gmail.com>
> To: Latin America and Caribbean Region Network Operators Group
> <lacnog at lacnic.net>
> Cc: Grupo de Trabalho de Engenharia e Operacao de Redes
> <gter at eng.registro.br>
> Subject: Re: [GTER] [lacnog] Hijack de prefixo em IRR
> Message-ID:
> <CAGFn2k1Bq-r+cbeE=
> Yy+JhaWwzM1kBSn_4M1KPznwqwUw3zUYw at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> 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 at 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 at lacnic.net
> > https://mail.lacnic.net/mailman/listinfo/lacnog
> > Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
> >
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> --
> gter digest list https://eng.registro.br/mailman/listinfo/gter
>
>
> ------------------------------
>
> End of gter Digest, Vol 198, Issue 17
> *************************************
>
--
Prof. Francisco J. Badaró Valente Neto
Network and Computer Specialist/Engineer and Researcher | MBA Project
Management
http://lattes.cnpq.br/0008999030113038
https://www.linkedin.com/in/franciscobadaro/
https://www.researchgate.net/profile/Francisco_Neto24
More information about the gter
mailing list