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

Lun Jun 10 07:03:39 -03 2019

Nico

Es leak.

AS21217 anuncio redes de peers que no debia (es un peer de ellos, no un
proveedor de transito.)

AS4134 no tenia los filtros apropiados y dejo pasar redes de un cliente las
cuales su cliente no tenia autorizacion de propagar.

Aqui los culpables son AS21217 por re-anunciar cosas que no debia, y AS4134
por aceptarlas.

Carlos

Del tema de las mas especificas es normal (IMO), ya que a tus peers les
anuncies o te anuncien mas especificas.

Saludos,
as

On Mon, Jun 10, 2019 at 11:24 AM Nicolas Antoniello <nantoniello en gmail.com>
wrote:

> Hola Carlos,
>
> Para mi no es ni leak ni hijack... pero bueno, cuando se sepa más sobre el
> caso (si se sabe) veremos.
>
> Saludos,
> Nico
>
>
> El El lun, 10 de jun. de 2019 a las 03:56, Carlos Marcelo Martinez
> Cagnazzo <carlosm3011 en gmail.com> escribió:
>
>> Es un leak/hijack mas o menos normal, salvo ¿De dónde salieron esas más
>> específicas que no están en los anuncios originales?
>>
>> Ahí está, me parece a mi, lo más interesante y "diferente" de este caso.
>>
>> /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 9:41pm, Jorge Villa <villa en reduniv.edu.cu> wrote:
>>
>> 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
>> <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
>>
>> _______________________________________________ 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/20190610/96b7f618/attachment-0001.html>