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

Dom Jun 9 18:34:11 -03 2019

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
> <https://cloudmagic.com/k/d/mailapp?ct=pa&cv=10.0.23&pv=9&source=email_footer_2>
>
> 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
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20190609/96530d10/attachment.html>