[lacnog] BGP event sends European mobile traffic through China Telecom for 2 hours

Dom Jun 9 21:40:49 -03 2019

Definitivamente Nico. La responsabilidad del incidente en realidad es mas de quien lo origina (empresa X) que de quien lo propaga (empresa J). Lo que sucede es que simplemente, la empresa J aparece manejando un tráfico que no tendría que manejar, y la empresa J es China, y ya sabemos como andan las cosas respecto a las empresas chinas de tecnología; así que el efecto noticioso de amplificación informativa, se va a producir SI o SI. Si los 70 000 prefijos que anunció la empresa X son legítimos, pues no hay forma de que la empresa J no los acepte; aunque tenga el filtrado correcto. Si hubiera prefijos que X no tendría que anunciarle a J, y la empresa J los acepta, ahí si habría problemas de filtros en J, en adición al problema original de la empresa X (que en cualquier caso, sigue siendo la principal responsable del incidente).

Del articulo tampoco queda claro quien bajó las rutas “malas” de la tabla global, para recuperar el tráfico a su estado normal, ni en que tiempo se comenzó el proceso; ni tampoco hay información sobre si todos los prefijos fueron corregidos de forma simultánea o si fue un proceso paulatino, donde los últimos prefijos terminaron de “limpiarse” en un tiempo de 2 horas.

Saludos,

Jorge

De: LACNOG <lacnog-bounces en lacnic.net> en nombre de Nicolas Antoniello <nantoniello en gmail.com>
Responder a: Latin America and Caribbean Region Network Operators Group <lacnog en lacnic.net>
Fecha: domingo, 9 de junio de 2019, 5:34 p. m.
Para: Latin America and Caribbean Region Network Operators Group <lacnog en lacnic.net>
Asunto: Re: [lacnog] BGP event sends European mobile traffic through China Telecom for 2 hours

Sige sin quedarme claro lo que pasó.

A ver: Empresa X tiene peering con empresa J y esa misma empresa X le publica a la empresa J un monton de sus propias rutas (las de X) desagregadas de forma que cuando J las propaga a Internet, si bien el AS Path es mayor, gana la especificidad de los prefijos... entoces tráfico que antes no pasaba por J ahora pasa por J.

Cual es el problema? Como yo lo veo, ninguno... la responsabilidad por eso es de X pues bien podría ser una maniobra operativa... lo que digo es que sigo sin ver la responsabilidad de J.

En todo caso, si X publicó prefijos que no eran de ellos, más responsabilidad de X... pero hasta donde se no se generaron agujeros negros sino que el tráfico pasó por J y antes no lo hacía.... Y?

J no tiene capacidad de provocar ese reenrutamiento sin hacer un hijack (y hasta donde sabemos no fue ese el caso). El único que puede provocar un reenrutamiento así es el propio X (a drede o por accidente).

Pensandolo bien si se puede pero se me ocurre que hay que hacer cosas muy raras utilizando por ejemplo MPLS o algo asi... en fin, no es el caso tampoco porque sabemos que los bloques se los publicó X a J.

Saludos,

Nico

El El dom, 9 de jun. de 2019 a las 20:39, Jorge Villa <villa en reduniv.edu.cu> escribió:

Pues si, Carlos, es un caso bastante curioso, sobretodo porque según el artículo, quienes en realidad crearon el problema (o sea, los de Safe Host), aparecen exonerados de toda responsabilidad, y solo hay que prender fuego a China Telecom por propagar el anuncio incorrecto. Estamos hablando de 70 mil rutas incorrectas; así que tampoco fue un error simple. No se las caracteristicas del acuerdo de peering entre Safe Host y China Telecom; pero al parecer, permiten full routing y no solo intercambio de los prefijos propios de cada una de las partes.

Saludos,

Jorge

De: LACNOG <lacnog-bounces en lacnic.net> en nombre de Carlos Marcelo Martinez Cagnazzo <carlosm3011 en gmail.com>
Responder a: Latin America and Caribbean Region Network Operators Group <lacnog en lacnic.net>
Fecha: domingo, 9 de junio de 2019, 11:00 a. m.
Para: Latin America and Caribbean Region Network Operators Group <lacnog en lacnic.net>
Asunto: Re: [lacnog] BGP event sends European mobile traffic through China Telecom for 2 hours

El hecho de que en el incidente aparecen prefijos más específicos que los que aparecen en los anuncios legítimos a mi juicio hace parecer que acá hubo algo más que un simple error. 

Un leak de rutas deja pasar los mismos prefijos pero con otro aspath. 

Salute

Carlos

via Newton Mail 

On Sun, Jun 09, 2019 at 11:57am, Jorge Villa <villa en reduniv.edu.cu> wrote:

Según el escrito, los suizos al parecer introdujeron mal un grupo de prefijos en su sesion BGP, y les propagaron esos errores a China Telecom, con quien hacen peering, y a su vez China Telecom debe haberlos propagado, y al tener prefijos mas especificos para un grupo de bloques, el trafico empezo a ir hacia alla.

Saludos,

Jorge

De: LACNOG <lacnog-bounces en lacnic.net> en nombre de Nicolas Antoniello <nantoniello en gmail.com>
Responder a: Latin America and Caribbean Region Network Operators Group <lacnog en lacnic.net>
Fecha: domingo, 9 de junio de 2019, 10:49 a. m.
Para: Latin America and Caribbean Region Network Operators Group <lacnog en lacnic.net>
Asunto: Re: [lacnog] BGP event sends European mobile traffic through China Telecom for 2 hours

Pero que fue lo que configuraron para enrrutar tráfico al ASN de China... no me doy cuenta que hicieron.

Saludos,

Nico

El El dom, 9 de jun. de 2019 a las 15:50, Jorge Villa <villa en reduniv.edu.cu> escribió:

En efecto Nico, no estamos en presencia de hickjack. Se trata de una especie de “fat fingers” dentro del proveedor suizo Safe Host; quien fue realmente el origen del tema. Como quiera que andan los chinos “de moda” a partir de los enredos con Huawei, todo lo que pueda incluir a China se puede vender facilmente como noticia. El problema que veo, es que China Telecom es un proveedor de mucha envergadura como para no tener buenas politicas de filtrado en BGP (como comenta Darwin); que pienso, es el principal aprendizade de esta historia. Hoy les sucedió a ellos, mañana nos puede suceder a cualquiera de nosotros, así que habría que estar revisando en nuestras redes, cuan bien o mal tenemos todo configurado. 

Saludos,

Jorge

De: LACNOG <lacnog-bounces en lacnic.net> en nombre de Darwin Da Costa <dacostadarwin en gmail.com>
Responder a: Latin America and Caribbean Region Network Operators Group <lacnog en lacnic.net>
Fecha: domingo, 9 de junio de 2019, 4:43 a. m.
Para: Latin America and Caribbean Region Network Operators Group <lacnog en lacnic.net>
Asunto: Re: [lacnog] BGP event sends European mobile traffic through China Telecom for 2 hours

Aunque sea una posible mal configuración, la verdade es que las reglas básicas de “filtering” no se han respetado por ninguna de las partes.

“Hello filtering”….

Saludos,

Darwin.

On 9 Jun 2019, at 06:14, Nicolas Antoniello <nantoniello en gmail.com> wrote:

Ojo que hasta donde se esto no fue hijack... sino que quienes configuraron mal algo (o les ganaron acceso a equipamiento de operaciones) fueron los propios Europeos.

Habría que quitar la nube de incertidumbre que hay en las noticias sobre esto y saber bien que fue lo que pasó.

Saludos,

Nico

El El dom, 9 de jun. de 2019 a las 06:23, Alejandro Acosta <alejandroacostaalamo en gmail.com> escribió:

https://arstechnica.com/information-technology/2019/06/bgp-mishap-sends-european-mobile-traffic-through-china-telecom-for-2-hours/

_______________________________________________
LACNOG mailing list
LACNOG en lacnic.net
https://mail.lacnic.net/mailman/listinfo/lacnog
Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog

_______________________________________________
LACNOG mailing list
LACNOG en lacnic.net
https://mail.lacnic.net/mailman/listinfo/lacnog
Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog

_______________________________________________ LACNOG mailing list LACNOG en lacnic.net https://mail.lacnic.net/mailman/listinfo/lacnog Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog 

_______________________________________________
LACNOG mailing list
LACNOG en lacnic.net
https://mail.lacnic.net/mailman/listinfo/lacnog
Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog

_______________________________________________ LACNOG mailing list LACNOG en lacnic.net https://mail.lacnic.net/mailman/listinfo/lacnog Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog 

_______________________________________________ LACNOG mailing list LACNOG en lacnic.net https://mail.lacnic.net/mailman/listinfo/lacnog Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog 

_______________________________________________ LACNOG mailing list LACNOG en lacnic.net https://mail.lacnic.net/mailman/listinfo/lacnog Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog 

_______________________________________________
LACNOG mailing list
LACNOG en lacnic.net
https://mail.lacnic.net/mailman/listinfo/lacnog
Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog

_______________________________________________ LACNOG mailing list LACNOG en lacnic.net https://mail.lacnic.net/mailman/listinfo/lacnog Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog 

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