[lacnog] Problemas para accesar a YouTube ayer por ruteo

Gustavo Lozano glozano en nic.mx
Mie Feb 27 18:16:14 BRT 2008 

At 08:34 p.m. 26/02/2008, Roque Gagliano wrote:
>Hola,
>
>Solo queria comentarles sobre una herramienta 
>desarrollada por RIPE que les avisa si alguno de 
>sus bloques esta siendo anunciado por algun ASN 
>que no deberia hacerlo (siempre que no sea 
>vuestro servidor de correo!). Seria bueno que 
>todo el mundo con un ASN se asociara.
>
><http://www.ris.ripe.net/myasn.html>http://www.ris.ripe.net/myasn.html
>
>Otra cosa, relacionada con esto. Alguno de 
>ustedes usan plaquetas para SMS para poder 
>mandar SMS de alarmas cuendo no tienen acceso al 
>mundo desde su correo electronico?

Nosotros (NIC Mexico) estamos usando (Siemens 
TC65T) para envio de mensajes de alerta SMS sobre 
nuestros servicios utilizando la red GSM..

Aqui (http://www.cellular.co.za/at_etsi.htm) 
puedes encontrar una explicacion de las 
extensiones de comandos AT de la ETSI para envio de mensajes SMS.

Aqui (http://www.gnokii.org/) puedes encontrar un 
software opensource que estamos usando para no 
tener que implementar la comunicacion serial con comandos AT.

Al utilizar esta tecnologia simplemente copiamos 
las alertas que ya enviamos via SMTP al servicio 
de envio SMS que no depende de Internet.

>Roque
>
>
>
>On Feb 26, 2008, at 6:52 PM, Nicolas Antoniello wrote:
>
>>Estimados,
>>
>>Es cierto que la versión actualmente más 
>>utilizada de BGP no es tan segura como al parecer
>>lo requiere el día de hoy... pero en este caso 
>>en particular (esto fue ampliamente
>>discutido en NANOG entre ayer y hoy), la 
>>solución más utilizada es la de filtrar los
>>prefijos recibidos de los ISP o clientes (esto no es algo nuevo).
>>
>>Nosotros lo hacemos y la mayoría de nuestros 
>>carriers también. A pesar de esto, es cierto
>>que en el mundo no todos lo hacen (de hecho, 
>>algunos de nuestros carriers, grandes
>>carriers, no realizan filtrados de prefijos 
>>sino que filtran solo por AS path), entonces,
>>es aquí donde surge el problema.
>>
>>Es cierto que en muchos casos, donde un carrier 
>>recibe cientos de prefijos de un cliente,
>>se vuelve muy difícil mantener un filtrado que no sea "automatizado".
>>
>>Creo que el filtrado por prefijo es algo 
>>indispensable, al menos en la versión actual de
>>BGP, no con la premisa de desconfiar de todos, 
>>sino por la premisa de que siempre existe
>>la posibilidad de equivocarse... y cualquiera 
>>de los que nos dedicamos a la administración
>>de redes, ya sea pequeñas o grandes, hemos 
>>tenido experiencias de esas... en las que nos
>>equivocamos y decimos: "por suerte estaba esto 
>>que evito que pasara aquello"...
>>
>>Hay que condenar al que se equivoca? No, hay 
>>que fomentar e impulsar ciertas prácticas que
>>en caso de errores o accidentes, eviten la propagación del desastre.
>>
>>Si bien creo que todo lo que se ha dicho es 
>>cierto, tengo dos reflexiones personales sobre
>>algunos puntos en particular:
>>* En este caso, si existe la posibilidad de en 
>>cierta manera "asegurar" el continuo de
>>funcionamiento en un caso como el que se dio 
>>que es el viejo y nunca bien ponderado
>>filtrado de prefijos recibidos.
>>* En cuanto a "hacer cosas mal por parte de 
>>administradores de ASN", creo que esto es
>>relativo, ya que estos acontecimientos pueden 
>>suceder no solo por "errores graves" por
>>parte de los administradores, sino por una suma 
>>de aspectos que por alguna razón no se
>>tuvieron en cuenta antes, que individualmente 
>>pueden parecer menores, pero que "alineados"
>>provocan un desastre.
>>Soy resistente a creer que CUALQUIER 
>>administrador de CUALQUIER red por mas titulos que
>>tenga o red mas grande que administre, nunca 
>>cometa errores que alguno puede catalogar de
>>"graves"... hagamos una reflexión personal a 
>>ver si NUNCA nos mandamos una grande !!  :)
>>Creo que eso no hace al "profesionalismo" o 
>>"calidad" del administrador, pero si el
>>reflexionar luego de lo sucedido, para que no 
>>se repita con el mismo patrón o secuencia de
>>eventos.
>>
>>Por cierto, la opción de filtrado, previene 
>>también un caso de "mala intención".
>>
>>La pregunta entonces, es: que mecanismos hay 
>>hoy en día, para verificar que los prefijos
>>que me pasan los clientes, son efectivamente de 
>>ellos y así armar el filtro? Bueno, la
>>respuesta es que existen varias formas (con 
>>pros y contras)... pero eso da para otra
>>discusión.  :)
>>
>>Saludos,
>>Nicolas.
>>
>>
>>
>>Ricardo Patara wrote:
>>>>Hugo,
>>>>
>>>>Estoy de acuerdo contigo, pero creo que lo 
>>>>quiso destacar Francisco es que el
>>>>sistema BGP por si tiene fragilidades de seguridad.
>>>>
>>>>Se verifica con eso como es fácil perjudicar 
>>>>un sitio (mismo que esa no haya
>>>>sido la intención de los de PCCW).
>>>>
>>>>uno con intención puede hacer lo mismo para 
>>>>secuestrar el trafico de un sitio,
>>>>pues el bgp actual no se garantiza que quien 
>>>>hace un anuncio tiene derecho de
>>>>hacerlo.
>>>>
>>>>saludos
>>>>Ricardo
>>>>
>>>>>>Yo creo que este tipo de problemas se van a
>>>>>>seguir presentando siempre que el 
>>>>>>adminstrador de un ASN haga las cosas mal.
>>>>>>
>>>>>>BGP tiene caracterisiticas que lo hacen
>>>>>>loop-free, pero no es inmune a errores graves en configuración.
>>>>>>
>>>>>>Saludos
>>>>>>
>>>>>>Hugo Zamora
>>>>>>
>>>>>>
>>>>>>At 12:57 p.m. 25/02/2008, Francisco Arias wrote:
>>>>>>
>>>>>>>>         Por si no han visto la noticia del
>>>>>>>>problema que tuvo ayer el sitio de YouTube por un
>>>>>>>>filtrado de ruteo mal hecho, les paso un par de ligas.
>>>>>>>>
>>>>>>>>         En español, la reseña de Arturo Servín:
>>>>>>>><http://arturo-servin.blogspot.com/2008/02/rutas-envenenadas-route-poisoning.html>http://arturo-servin.blogspot.com/2008/02/rutas-envenenadas-route-poisoning.html
>>>>>>>>
>>>>>>>>         En inglés con la explicación detallada de lo que sucedió:
>><http://arstechnica.com/news.ars/post/20080225-insecure-routing-redirects-youtube-to-pakistan.html>http://arstechnica.com/news.ars/post/20080225-insecure-routing-redirects-youtube-to-pakistan.html
>>>>>>>>
>>>>>>>>         Lo interesante es que se trata del
>>>>>>>>primer caso de un ataque (aunque al parecer
>>>>>>>>involuntario) en el sistema de ruteo a un portal
>>>>>>>>de primer nivel mostrando la fragilidad del
>>>>>>>>sistema ante la falta de una opción para
>>>>>>>>asegurarlo. Si esta noticia llega a los titulares
>>>>>>>>de los medios masivos, quizá podríamos tener
>>>>>>>>pronto apoyo verdadero a los trabajos 
>>>>>>>>para asegurar el ruteo en Internet.
>>>>>>>>
>>>>>>>>fjac
>>>>>>>>
>>>>>>>>
>>>>>>>>_______________________________________________
>>>>>>>>lacnog mailing list
>>>>>>>><mailto:lacnog en lacnic.net>lacnog en lacnic.net
>>>>>>>>https://mail.lacnic.net/mailman/listinfo/lacnog
>>>>>>
>>>>>>_______________________________________________
>>>>>>lacnog mailing list
>>>>>><mailto:lacnog en lacnic.net>lacnog en lacnic.net
>>>>>>https://mail.lacnic.net/mailman/listinfo/lacnog
>>>>_______________________________________________
>>>>lacnog mailing list
>>>><mailto:lacnog en lacnic.net>lacnog en lacnic.net
>>>>https://mail.lacnic.net/mailman/listinfo/lacnog
>>
>>
>>_______________________________________________
>>lacnog mailing list
>><mailto:lacnog en lacnic.net>lacnog en lacnic.net
>>https://mail.lacnic.net/mailman/listinfo/lacnog
>
>
>_______________________________________________
>lacnog mailing list
>lacnog en lacnic.net
>https://mail.lacnic.net/mailman/listinfo/lacnog

------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20080227/afed7b54/attachment.html>

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