<div dir="auto"><div><div dir="ltr" style="font-family:sans-serif;font-size:12.8px">Que bom que a discussão da validação de origem volta à tona, e a necessidade de ajuste no IRR.</div><div dir="ltr" style="font-family:sans-serif;font-size:12.8px"><br></div><div dir="ltr" style="font-family:sans-serif;font-size:12.8px">Bom trabalho meu irmão Douglas .</div><div dir="ltr" style="font-family:sans-serif;font-size:12.8px"><br></div><div dir="ltr" style="font-family:sans-serif;font-size:12.8px">O que joga a discussão em um patamar mais alto, a validação de origem.<br><br>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.<br><br>O Route com falso origin só serve para depor contra que criou.<br><br>Esforço comunitário para o ajuste:</div><div dir="ltr" style="font-family:sans-serif;font-size:12.8px"><br></div><div dir="ltr" style="font-family:sans-serif;font-size:12.8px">Disseminar conhecimento , Shame-list, depeering , warning... vários caminhos. </div><div dir="ltr" style="font-family:sans-serif;font-size:12.8px"><br></div><div dir="ltr" style="font-family:sans-serif;font-size:12.8px">MAS, para melhor efetividade, deve (IMHO) ser 'institucional' e aqui no Brasil temos a posição do <a href="http://ix.br/" style="text-decoration-line:none;color:rgb(66,133,244)">IX.BR</a> que NÃO será adotado IRR por aqui. </div><div dir="ltr" style="font-family:sans-serif;font-size:12.8px">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.<br><br>De fato, é incompreensível algumas posturas de alguns AS´s.<br><br>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.<br><br>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.<br><br>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).<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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).<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em ter, 10 de set de 2019 20:34, <<a href="mailto:lacnog-request@lacnic.net">lacnog-request@lacnic.net</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Envíe los mensajes para la lista LACNOG a<br>
<a href="mailto:lacnog@lacnic.net" target="_blank" rel="noreferrer">lacnog@lacnic.net</a><br>
<br>
Para subscribirse o anular su subscripción a través de la WEB<br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
<br>
O por correo electrónico, enviando un mensaje con el texto "help" en<br>
el asunto (subject) o en el cuerpo a:<br>
<a href="mailto:lacnog-request@lacnic.net" target="_blank" rel="noreferrer">lacnog-request@lacnic.net</a><br>
<br>
Puede contactar con el responsable de la lista escribiendo a:<br>
<a href="mailto:lacnog-owner@lacnic.net" target="_blank" rel="noreferrer">lacnog-owner@lacnic.net</a><br>
<br>
Si responde a algún contenido de este mensaje, por favor, edite la<br>
linea del asunto (subject) para que el texto sea mas especifico que:<br>
"Re: Contents of LACNOG digest...". Además, por favor, incluya en la<br>
respuesta sólo aquellas partes del mensaje a las que está<br>
respondiendo.<br>
<br>
<br>
Asuntos del día:<br>
<br>
1. Re: Hijack de prefixo em IRR (Rubens Kuhl)<br>
2. Mozilla habilitará DoH por defecto<br>
(Carlos Marcelo Martinez Cagnazzo)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 10 Sep 2019 16:44:36 -0600<br>
From: Rubens Kuhl <<a href="mailto:rubensk@gmail.com" target="_blank" rel="noreferrer">rubensk@gmail.com</a>><br>
To: Latin America and Caribbean Region Network Operators Group<br>
<<a href="mailto:lacnog@lacnic.net" target="_blank" rel="noreferrer">lacnog@lacnic.net</a>><br>
Cc: Grupo de Trabalho de Engenharia e Operacao de Redes<br>
<<a href="mailto:gter@eng.registro.br" target="_blank" rel="noreferrer">gter@eng.registro.br</a>><br>
Subject: Re: [lacnog] Hijack de prefixo em IRR<br>
Message-ID:<br>
<CAGFn2k1Bq-r+cbeE=<a href="mailto:Yy%2BJhaWwzM1kBSn_4M1KPznwqwUw3zUYw@mail.gmail.com" target="_blank" rel="noreferrer">Yy+JhaWwzM1kBSn_4M1KPznwqwUw3zUYw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
O que eu achei curioso é que eu imaginava que só os upstreams estariam<br>
nessa shame-list de proxy, mas o maior deles parece ser um caso de peering.<br>
<br>
Algo a notar no caso de upstreams é que eles tinham a opção de cadastrar o<br>
AS do cliente sob sua administração, mas cadastram só os blocos do do<br>
cliente.<br>
Isso é um problema self-inflicted, e o ponto é como a comunidade pode<br>
amplificar essa dor para mudar esse comportamento.<br>
<br>
<br>
Rubens<br>
<br>
<br>
<br>
<br>
On Tue, Sep 10, 2019 at 1:37 PM Douglas Fischer <<a href="mailto:fischerdouglas@gmail.com" target="_blank" rel="noreferrer">fischerdouglas@gmail.com</a>><br>
wrote:<br>
<br>
> TL-DR;<br>
> ------<br>
> - Vários ASNs registrando em IRRs prefixos de seus clientes como se fosse<br>
> de seus ASNs.<br>
> - Principalmente no RADB.<br>
> - Está gerando sujeira nas bases de IRR.<br>
> - Prefix-lists geradas automaticamente estão ficando muito longas,<br>
> consumindo recurso do routers.<br>
> - Impossibilita a validação de AS-Path.<br>
><br>
> Fizemos uma consulta nos IRR dos prefixos delegados pelo <a href="http://NIC.BR" rel="noreferrer noreferrer" target="_blank">NIC.BR</a> que<br>
> estavam registrados para outros ASNs.<br>
> Agrupamos esses prefixos pelo campo maintainer e contamos a quantidade.<br>
> Segue a lista dos mais significativos:<br>
> Quantidade - Maintainer<br>
> 2686 - MAINT-AS8966<br>
> 865 - MAINT-AS18678<br>
> 604 - MAINT-AS28283<br>
> 494 - MAINT-AS28329<br>
> 453 - MAINT-AS20473<br>
><br>
> Este é o Link para a planilha com as informações.<br>
><br>
> <a href="https://drive.google.com/file/d/1KFUfptAnZsAmbSVvVFyHK8bPH7yrOOhr/view?usp=sharing" rel="noreferrer noreferrer" target="_blank">https://drive.google.com/file/d/1KFUfptAnZsAmbSVvVFyHK8bPH7yrOOhr/view?usp=sharing</a><br>
> Lá consta uma planilha dinâmica, e também planilhas com o detalhado dos 5<br>
> Mantainers com mais registro errados.<br>
><br>
><br>
> Contando a historinha do problema<br>
> -----------------------------------<br>
> Há cerca de uns 4 meses, um amigo identificou que algumas empresas<br>
> brasileiras estavam fazendo registros ERRADOS nos IRRs.<br>
> Ele me passou a informação e eu fiquei bastante triste com o que vi.<br>
><br>
> O procedimento deles era:<br>
> - Listar todos os prefixos do cone de AS do cliente deles<br>
> - Registrar como sendo de seu próprio ASN.<br>
><br>
> Eu pessoalmente entrei em contato por telefone com algumas dessas<br>
> empresas, e questionei o porque de eles fazerem isso.<br>
><br>
> A resposta deles foi:<br>
> "Muitos desses prefixos já estão registrados como proxyed por outros ASNs,<br>
> e quando tentamos registrar esses prefixos, não conseguimos... Então<br>
> registramos como nossos."<br>
> - Eu expliquei a eles porque fazer esse registro como seu próprio ASN era<br>
> errado, que era uma solução grosseira e de força bruta.<br>
> - Mencionei que dependendo de como as empresas consultem as bases de IRR<br>
> isso iria fazer com que os as prefix-Lists geradas automaticamente ficassem<br>
> com entradas duplicadas, muito longas, aumentando os recursos de<br>
> processamento dos routers para processar as mensagens de anúncio de rotas.<br>
> - E expliquei também que isso iria prejudicar os próximos passos de<br>
> segurança de roteamento, que é a validação de caminho(além da de origem).<br>
><br>
> Felizmente por algumas empresas essa informação foi muito bem recebida.<br>
> Inclusive desenvolvi relação de amizade por conta disso com um técnico<br>
> dessas empresas.<br>
> Tive a oportunidade de sugerir que no script de automação deles<br>
> incluíssem o teste:<br>
> (Se prefixo já existe registrado, usa registro atual.<br>
> Se prefixo não existe registrado, cria registro como proxyed.)<br>
><br>
> Infelizmente, algumas poucas empresas encararam a crítica negativamente.<br>
> - Alguns me atenderam, fizeram mil elogios por telefone, se comprometeram<br>
> a corrigir, e não fizeram nada.<br>
> - Alguns se sentiram ofendidos com a crítica(se sentiram ofendidos, e me<br>
> ofenderam).<br>
> - Alguns nem se deram ao trabalho de responder.<br>
><br>
><br>
> O problema só está aumentando!<br>
> ------------------------------<br>
> Observando a lista dos TOP-5, podemos ver que o MAINT-AS8966 - Emix -<br>
> Emirates Telecommunications - está no topo da lista, com mais do que 3<br>
> vezes mais prefixos errados que o segundo colocado.<br>
><br>
> Bom, eu confesso que não entendi direito qual é o objetivo desses<br>
> registros...<br>
> Mas a grande maioria(talvez até a totalidade) dos prefixos estão com a<br>
> "descr: ChinaTel via EMIX".<br>
><br>
> Outra coisa que só aumentou as minhas dúvidas é que existem casos em que o<br>
> MAINT-AS8966 registrou um prefixos para vários Origin.<br>
> Como é o caso do prefixo <a href="http://45.70.72.0/22" rel="noreferrer noreferrer" target="_blank">45.70.72.0/22</a>, que está registrado pela EMIX<br>
> para AS266319, AS52965, AS53144.<br>
><br>
> <a href="https://www.radb.net/query?advanced_query=&keywords=45.70.72.0%2F22&-T+option=&ip_option=&-i+option=" rel="noreferrer noreferrer" target="_blank">https://www.radb.net/query?advanced_query=&keywords=45.70.72.0%2F22&-T+option=&ip_option=&-i+option=</a><br>
><br>
> Segue uma lista dos Prefixos Brasileiros registrados pelo MAINT-AS8966.<br>
> Quantidade AS-Origin IRR<br>
> 773 AS61832 RADB<br>
> 475 AS53144 RADB<br>
> 450 AS52965 RADB<br>
> 313 AS52551 RADB<br>
> 154 AS52720 RADB<br>
><br>
> Alguém conseguiu entender a lógica disso?<br>
> Isso está correto?<br>
> Se não está correto, quem deve ser acionado para corrigir?<br>
><br>
> Porque estou cutucando isso agora?<br>
> ----------------------------------<br>
> O Google, em seus GGCs e PNIs, começou a fazer filtrar prefixos baseado em<br>
> registros de IRR.<br>
> Isso foi informado em maio [1][2] deste ano no Lacnic 31 pelo Sr. Arturo.<br>
> E os triangulozinhos de alerta nos prefixos mostrados em<br>
> <a href="https://peering.google.com/" rel="noreferrer noreferrer" target="_blank">https://peering.google.com/</a> estão gerando um alvoroço entre os ISPs.<br>
> E eu estou feliz por isso!<br>
> Depois de 20 anos de RPSL, os ASNs estão se preocupando em cadastrar seus<br>
> prefixos corretamente nos IRRs.<br>
><br>
> Eu acredito que o medo de ficar sem acesso ao ASN do Google é que está<br>
> desencadeando essas ações um pouco desesperadas...<br>
><br>
> P.S.1: Tenham calma!<br>
> Segundo informações do próprio Google, por enquanto esses prefixos estão<br>
> apenas sendo tageados.<br>
> Apenas no futuro, depois de ter uma melhor referência de qual o tamanho do<br>
> dragão com que terão que lutar, é que decidirão como esses prefixos serão<br>
> descartados.<br>
><br>
> P.S.2: Reitero meu agradecimento ao Google por isso!<br>
> E aproveito para provocar Facebook, Cloudflare, Netflix, e até o ICCAN, a<br>
> fazerem o mesmo.<br>
><br>
> [1]<br>
> <a href="https://www.lacnic.net/innovaportal/file/3635/1/26-route-filtering-at-the-edge-as15169.pdf" rel="noreferrer noreferrer" target="_blank">https://www.lacnic.net/innovaportal/file/3635/1/26-route-filtering-at-the-edge-as15169.pdf</a><br>
> [2] <a href="https://youtu.be/OT9at07N7qM" rel="noreferrer noreferrer" target="_blank">https://youtu.be/OT9at07N7qM</a><br>
><br>
> --<br>
> Douglas Fernando Fischer<br>
> Engº de Controle e Automação<br>
> _______________________________________________<br>
> LACNOG mailing list<br>
> <a href="mailto:LACNOG@lacnic.net" target="_blank" rel="noreferrer">LACNOG@lacnic.net</a><br>
> <a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
> Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer noreferrer" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
><br>
------------ próxima parte ------------<br>
Se ha borrado un adjunto en formato HTML...<br>
URL: <<a href="https://mail.lacnic.net/pipermail/lacnog/attachments/20190910/9bb5296b/attachment-0001.html" rel="noreferrer noreferrer" target="_blank">https://mail.lacnic.net/pipermail/lacnog/attachments/20190910/9bb5296b/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 10 Sep 2019 20:33:40 -0300<br>
From: Carlos Marcelo Martinez Cagnazzo <<a href="mailto:carlosm3011@gmail.com" target="_blank" rel="noreferrer">carlosm3011@gmail.com</a>><br>
To: Latin America and Caribbean Region Network Operators Group<br>
<<a href="mailto:lacnog@lacnic.net" target="_blank" rel="noreferrer">lacnog@lacnic.net</a>><br>
Subject: [lacnog] Mozilla habilitará DoH por defecto<br>
Message-ID: <<a href="mailto:ba2222c7-f34c-46c9-b3cb-3bd886b96fcf@gmail.com" target="_blank" rel="noreferrer">ba2222c7-f34c-46c9-b3cb-3bd886b96fcf@gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"<br>
<br>
Va link: <a href="https://www.theregister.co.uk/2019/09/09/mozilla_firefox_dns/" rel="noreferrer noreferrer" target="_blank">https://www.theregister.co.uk/2019/09/09/mozilla_firefox_dns/</a><br>
<br>
<br>
Opiniones? Comentarios?<br>
<br>
<br>
S2<br>
<br>
<br>
/Carlos<br>
<br>
<br>
<br>
<br>
via Newton Mail <br>
[<a href="https://cloudmagic.com/k/d/mailapp?ct=pa&cv=10.0.23&pv=9&source=email_footer_2" rel="noreferrer noreferrer" target="_blank">https://cloudmagic.com/k/d/mailapp?ct=pa&cv=10.0.23&pv=9&source=email_footer_2</a>]<br>
------------ próxima parte ------------<br>
Se ha borrado un adjunto en formato HTML...<br>
URL: <<a href="https://mail.lacnic.net/pipermail/lacnog/attachments/20190910/3f282076/attachment.html" rel="noreferrer noreferrer" target="_blank">https://mail.lacnic.net/pipermail/lacnog/attachments/20190910/3f282076/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Pié de página del digest<br>
<br>
_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" target="_blank" rel="noreferrer">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a href="mailto:lacnog-unsubscribe@lacnic.net" target="_blank" rel="noreferrer">lacnog-unsubscribe@lacnic.net</a><br>
<br>
<br>
------------------------------<br>
<br>
Fin de Resumen de LACNOG, Vol 141, Envío 8<br>
******************************************<br>
</blockquote></div></div></div>