[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