[lacnog] BGP event sends European mobile traffic through China Telecom for 2 hours
Alejandro Acosta
alejandroacostaalamo en gmail.com
Lun Jun 10 07:33:27 -03 2019
Hola,
Recordaba que había un RFC que tenía el concepto de BGP Leak, lo
conseguí, está muy bueno.
https://tools.ietf.org/html/rfc7908
Voy a intentar hacer un pequeño resumen:
En en punto 2 el RFC indica como "Working Definition of Route Leaks":
"A route leak is the propagation of routing announcement(s) beyond
their intended scope. That is, an announcement from an Autonomous
System (AS) of a learned BGP route to another AS is in violation of
the intended policies of the receiver, the sender, and/or one of the
ASes along the preceding AS path..."
[....]
"Route leaks can
be accidental or malicious but most often arise from accidental
misconfigurations."
Por otro lado, interesantemente hay una clasificación de Route Leaks.
Solo voy a mencionarlos:
3.1. Type 1: Hairpin Turn with Full Prefix
3.2. Type 2: Lateral ISP-ISP-ISP Leak
3.3. Type 3: Leak of Transit-Provider Prefixes to Peer
3.4. Type 4: Leak of Peer Prefixes to Transit Provider
3.5. Type 5: Prefix Re-origination with Data Path to Legitimate Origin
3.6. Type 6: Accidental Leak of Internal Prefixes and More-Specific
Prefixes
Revisando el artículo + peeringdb (no conseguí nada) + lo que puedo
apreciar en: https://bgp.he.net/AS21217#_graph4
indica que China Telecom no pareciera ser upstream provider de Safe Host
por ello cae en las categorías:
3.2. Type 2: Lateral ISP-ISP-ISP Leak. ----> Descartado (no parece
haber peering)
3.5. Type 5: Prefix Re-origination with Data Path to Legitimate Origin
3.6. Type 6: Accidental Leak of Internal Prefixes and More-Specific
Prefixes
IMHO, todo lo ocurrido parece caer en Type 5 y/o Type 6. Ahora bien,
por la gran cantidad de rutas me inclino que la situación fue un BGP
Leak: Type 5 Prefix Re-origination with Data Path to Legitimate Origin
Saludos,
Alejandro,
On 6/10/19 6:03 AM, Arturo Servin wrote:
> 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 <mailto: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 <mailto: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 <mailto: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
> <mailto:lacnog-bounces en lacnic.net>> en nombre de Nicolas
> Antoniello <nantoniello en gmail.com
> <mailto:nantoniello en gmail.com>>
> *Responder a: *Latin America and Caribbean Region Network
> Operators Group <lacnog en lacnic.net <mailto: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 <mailto: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 <mailto: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
> <mailto:lacnog-bounces en lacnic.net>> en nombre de
> Carlos Marcelo Martinez Cagnazzo
> <carlosm3011 en gmail.com <mailto:carlosm3011 en gmail.com>>
> *Responder a: *Latin America and Caribbean Region
> Network Operators Group <lacnog en lacnic.net
> <mailto: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
> <mailto: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 <mailto: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
> <mailto:lacnog-bounces en lacnic.net>> en nombre de
> Nicolas Antoniello <nantoniello en gmail.com
> <mailto:nantoniello en gmail.com>>
> *Responder a: *Latin America and Caribbean Region
> Network Operators Group <lacnog en lacnic.net
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto:lacnog-bounces en lacnic.net>> en nombre
> de Darwin Da Costa <dacostadarwin en gmail.com
> <mailto:dacostadarwin en gmail.com>>
> *Responder a: *Latin America and Caribbean
> Region Network Operators Group
> <lacnog en lacnic.net <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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 <mailto: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
> <mailto: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 <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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/0130b566/attachment-0001.html>
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 1782 bytes
Desc: no disponible
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20190610/0130b566/attachment-0001.key>
Más información sobre la lista de distribución LACNOG