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

Lun Jun 10 18:05:53 -03 2019

Ok, en ese escenario si sería un leak... ahora de allí a “culpar” a los
Chinos se pasaron como 10 pueblos (como decíamos acá).

Ojo que muchos de los que tienen filtros de entrada lo hacen poniendo el
ASN (los que tienen filtros de entrada que apuesto no son ni un 20%) y las
rutas específicas o sea que si ese cliente del ASN 21217 publicaba algo más
allá del ASN 21217 ni siquiera lo iban a evitar con los filtros.

En fin...

Saludos,
Nicolas

El El lun, 10 de jun. de 2019 a las 12:04, Arturo Servin <
arturo.servin en gmail.com> escribió:

> 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
>>
> _______________________________________________
> 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/19d2785e/attachment-0001.html>