<div dir="ltr">Olá,<div><br></div><div class="gmail_extra"><div class="gmail_quote">2015-12-21 14:20 GMT-02:00 Nicolas Antoniello <span dir="ltr"><<a href="mailto:nantoniello@gmail.com" target="_blank">nantoniello@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hola Carlos y todos,<div><br></div><div>Yo "casi" me paso al lado de Christian, excepto por un detalle no menor.</div><div><br></div><div>Primero, estoy de acuerdo con el razonamiento de Carlos y pienso exactamente lo mismo sobre que los bloqueos ante ataques que no saturan los enlaces de tránsito deben ser bloqueados dentro del mismo proveedor preferentemente (incluso cuando son distribuidos).</div><div><br></div><div>Por otro lado, L3 debería chequear que lo que publica Telefónica (o cualquiera) por RTBH sea del cliente o de un cliente del cliente... me explico?</div><div>Por ello es que mencioné varias veces la necesidad de que quien implementa RTBH haga un chequeo en algún IRR para confirmar que nadie ponga a NULL rutas que no son de el... y en este caso, no creo que las rutas de Facebook (o Whatsapp) sean de Telefónica.  :)</div><div>En resumen, creo que no me equivoco al decir que el error es compartido entre los 2. </div><div>O si me equivoco?</div></div></blockquote><div><br></div><div>Você está correto. Por isso mencionei o ASN 18881. Não podemos afirmar que foi uma RTBH a configuração escolhida para implementar o bloqueio. Por exemplo, se foi configurado uma rota /32 para null0 e o filtro para anúncio de RTBH não está corretamente configurado, então a rota RTBH será anunciada para upstreams como efeito colateral - de qualquer forma, vale deixar registrado aqui para referencias futuras os *dois casos*.</div><div><br></div><div>Um ASN não deveria aceitar um anúncio RTBH de um IP que não esteja alocado para o ASN que está originando o anúncio. Essa "regra" parece muito simples de implementar em redes >= tier 3. Em redes < tier 2 fica muito complicado quando o provedor não utiliza IRR (como parece ser o caso do ASN 3549 em nossa região).<br></div><div><br></div><div>Outro fato importante é que a rota /32 não foi anunciada pelo ASN 3549 para a tabela global (não encontrei nenhum anúncio no histórico da tabela global no routeviews ou no ripe database). Por isso o problema de acesso ao whatsapp ficou contido na região dos clientes diretos do ASN 3549 e não tivemos um caso pakistan "con estilo brasileño".</div><div><br></div><div>Abraços,</div><div>Gustavo.</div></div></div></div>