BGP Stream: un año de análisis sobre incidentes BGP

04/03/2024

Por Alejandro Acosta, Coordinador de I+D en LACNIC

LACNIC presenta la primera página on line que muestra los incidentes y el análisis de datos de medición del Border Gateway Protocol (BGP) en América Latina y el Caribe.

PRINCIPALES SUCESOS. Además de sumarizar la información se aprecian los tres principales sucesos, los cuales son: posibles secuestros de red, interrupciones BGP y fugas de rutas.

Posibles secuestros de red es la adquisición ilegítima de grupos de direcciones IP al corromper las tablas de enrutamiento de Internet. Tradicionalmente ocurre cuando el Sistema Autónomo anuncia un prefijo que no le pertenece.

Interrupciones (outages) se refiere a la pérdida de visibilidad de prefijos de red por un grupo mayoritario de sensores[1] .

Fugas de rutas como su nombre lo indica, se refiere al anuncio -posiblemente- no intencional de algún prefijo de red vía BGP. Por ejemplo, un peering privado de intercambio de tráfico, alguno de los participantes anuncia el prefijo del peer a Internet. Este caso es el más difícil de detectar por los algoritmos y no consigue identificar algunas de éstas incidencias.

¿Cómo se obtienen los datos?

Esta iniciativa utiliza BGP Stream de Cisco, un proceso automatizado que selecciona los incidentes más grandes e importantes, qué tipo de situación es y cuáles ASNs están involucrados.

Leer también:

Un necesario RFC sobre BGP: AS Path Prepending

La información se publica de forma abierta ya que LACNIC considera que se trata de información importante para que ingenieros, responsables de redes y organizaciones puedan conocer los incidentes más comunes de la región y crear conciencia sobre la situación.

Ello permite la investigación eficiente de eventos, creación rápida de prototipos y de herramientas complejas y aplicaciones de monitoreo a gran escala (por ejemplo, detección de interrupciones de conectividad, ataques o secuestros de BGP).

En base a un sistema desarrollado por el área de I+D de LACNIC, se obtienen los datos de forma cruda, los parcela, identifica, limpia y almacena en una base de datos para posteriormente generar estadísticas y gráficas. Lo anterior ocurre cada 24 horas de forma automatizada.

RESULTADOS. Durante el período de tiempo estudiado -febrero 2023 a febrero 2024- nos encontramos con los siguientes resultados que se muestran en la siguiente gráfica comparando eventos BGP mundiales vs eventos BGP de nuestra región.

Comparando la gráfica mundial versus la gráfica de la región vemos que el orden de incidentes es similar (el mayor es outages, seguido por posibles secuestros de red y finalizando en fugas de prefijos).  Adicionalmente hay que destacar que en nuestra región las interrupciones (outages) son más frecuentes en comparación con el total mundial de eventos BGP. 

Al analizar la tabla resultados mostrando eventos BGP Mundiales vs eventos BGP de nuestra región, nos encontramos con los siguientes fatos.

TOP 5 países de nuestra región con Interrupciones BGP (Outages)

Outages
CC	Events
BR	781
AR	99
HT	24
MX	22
CL	17

TOP 5 países de nuestra región con secuestros de prefijos (Possible Hijacks)

Expected CC	Detected CC	Events
BR	BR	67
BR	none	35
PY	BR	24
BR	US	22
BR	CN	9

TOP 3 países de nuestra región con fugas de rutas (Route Leaks)

Origin CC	Leaker CC	Events
VE	VE	7
MX	MX	5
CL	PA	2

El impacto

En este primer año de funcionamiento desde LACNIC hemos observado una disminución de los incidentes BGP, entre los motivos de estos resultados podemos identificar: a) el despliegue y la adopción de Sistema de Certificación de Recursos (RPKI), b) el Registro de Enrutamiento de Internet de LACNIC (IRR) y la adopción del RFC 9234 (Roles en BGP).

La adopción de dichas herramientas se está dando por mejores prácticas de los operadores y el impulso de MANRS por ISOC.

Conclusiones

Los posibles secuestros de red (BGP Hijacks), interrupciones BGP (Outages) y fugas de rutas son los incidentes BGP más comunes. Durante el primer año de recopilación de datos, se observa una disminución de estos casos; sin embargo, en el futuro cercano no desaparecerán por completo. Es crucial implementar medidas robustas de redundancia y resiliencia en las redes, así como detectar y prevenir tempranamente posibles secuestros para garantizar la integridad y confiabilidad de las rutas de Internet.

En LACNIC, buscamos crear conciencia y motivar a los ISPs y organizaciones a estar preparados para abordar estos incidentes de manera eficiente cuando ocurran.

Referencias

https://stats.labs.lacnic.net/BGP/bgpstream-lac-region.html

https://stats.labs.lacnic.net/BGP/bgpstream.html

https://bgpstream.crosswork.cisco.com/ 

Como instalar telnet en Alpine Linux (muy común en contenedores docker)

 Como instalar telnet en Alpine Linux (muy común en contenedores docker)

#apk update

#apk add busybox-extras

La verdadera solución para correr ContainerLAB en MAC m1, m2, m3 apple silicon

 

Paso 1: Instalar Multipass de Canonical

$brew install multipass

Paso 2: Instalar la VM llamada docker

$multipass launch docker --name mydocker

Paso 3: Conectarse a la nueva VM

$multipass shell mydocker

Paso 4: Dentro de la VM instalar ContainerLab

$sudo su

#bash -c "$(curl -sL https://get.containerlab.dev)"

Vamos a probar con esta sencilla topología back2back de dos equipos Linux con FRR

-- 2-frr-back2back.yml --

name: ipv6-ws

topology:

  kinds:

    linux:

      image: ghcr.io/hellt/network-multitool

  nodes:

  ROUTERS ###

    R1:

      kind: linux

      image: quay.io/frrouting/frr:8.4.1

      exec:

        - "sysctl -w net.ipv6.conf.all.forwarding=1"

        - "ip address add dev eth1 2001:db8:ffab::1/64"

    R2:

      kind: linux

      image: quay.io/frrouting/frr:8.4.1

      exec:

        - "ip address add dev eth1 2001:db8:ffab::2/64"

        - "sysctl -w net.ipv6.conf.all.forwarding=1"

  links:

    - endpoints: ["R1:eth1", "R2:eth1"]

--- yml --

Paso 5: Levantemos la topología con clab:

clab dep -t 2-frr-back2back.yml

Paso 6: finalmente vamos a conectarnos a una de las VMs dentro de ContainerLAB

docker exec -i -t clab-ipv6-ws-R2 bash

Inocentada: La verdad detrás del coqueteo de QUIC y BGP

Netland, 1707882300

Hoy tengo el honor de compartir con ustedes un secreto que he guardado celosamente durante mucho tiempo. Un secreto que, una vez revelado, cambiará nuestra percepción de la realidad y sacudirá los cimientos de nuestra sociedad. Permítanme llevarlos a un viaje a través de los pasillos oscuros de la red, celos, amor y el engaño, donde una verdad oculta ha estado esperando pacientemente para ser descubierta. Pasa en las películas, pasa en la vida, pasa en la red.

He esperado precisamente el día de los enamorados para contar sobre este  peculiar romance. Es muy duro y difícil de digerir para muchos profesionales de la red.  Relatar la historia de cómo TCP, el antiguo y confiable, conquistó el corazón de BGP, y cómo, tras décadas de lealtad, BGP ahora se encuentra coqueteando con.., correcto, con QUIC.

Acto I: Un poco de historia

Hace muchos años, en los albores de la red, TCP y BGP se cruzaron en un oscuro rincón de la topología. BGP, con su elegancia y sus enigmáticas tablas, cautivó a TCP. La conexión se estableció, y juntos construyeron una red resiliente. BGP admiraba la paciencia de TCP, su capacidad para esperar y retransmitir cuando las cosas se volvían difíciles.

Acto II: La famosa Rutina, ni en la red parece ser buena

Los años pasaron, y BGP y TCP se convirtieron en una pareja estable. La tabla de rutas de BGP creció, y TCP seguía transmitiendo sus paquetes con diligencia. Pero algo comenzó a cambiar. BGP miraba más allá de las fronteras de su dominio, de los firewalls y los IDPs. Había oído hablar de QUIC, un protocolo rápido y moderno que prometía una conexión más íntima y eficiente.

Acto III: El Coqueteo

BGP y QUIC comenzaron a encontrarse en conferencias y grupos de trabajo. Intercambiaban miradas furtivas en los paquetes de datos. QUIC, audaz y atrevido, le susurraba a BGP sobre su capacidad para sortear los problemas de latencia y congestionamiento. BGP, aunque leal a TCP, no podía evitar sentirse intrigado.

Acto IV: El secreto

Retomando el correo que les conté al comienzo que me llegó por error, me doy cuenta que  BGP le cuenta de todo a su tío, el viejo EGP

El texto decía lo siguiente: “QUIC es emocionante, ágil y tiene una forma de moverse que me resulta intrigante. Su naturaleza basada en UDP me hace sentir que puedo ser más libre y ágil, algo que no sucede con mi conexión tradicional a través de TCP.”,

Luego hay un pedazo que no se pudo recuperar y más adelante dice esto: “Tío, al principio, me resistí a los encantos de QUIC, aferrándome a la familiaridad y seguridad que me brinda TCP. Pero con el tiempo, no pude ignorar la energía y la emoción que QUIC aportaba a nuestra relación.”

Leer también:

Un necesario RFC sobre BGP: AS Path Prepending

Acto V: La Decisión

Y así, en esta temporada de enamorados, BGP se encuentra en una encrucijada. ¿Debería seguir con su relación estable con TCP, o debería aventurarse con QUIC? Las noches son largas mientras BGP reflexiona sobre su futuro. ¿Es posible amar a dos protocolos a la vez?

Acto VI: El pronóstico de los expertos

Algunos dicen que el amor no tiene edad ni fecha en el calendario, los expertos reconocen la historia de BGP y  TCP como profunda e intrigante. Todos concuerdan que  BGP es un protocolo caballeroso, muy serio y no creen que vaya a arriesgar su vida completa a su edad y con la gran responsabilidad que lleva consigo.

Acto VII: ¿Qué piensa TCP de estos rumores?

TCP con su gran experiencia no quiso expandir su respuesta, pero se limitó a decir:  “me siento dolida pero detrás de cada gran protocolo existe una gran acompañante, solo me queda decir que sería emocionante contemplar un futuro donde BGP pueda explorar nuevos horizontes con QUIC, por ello aquí estoy, la animaría a seguir adelante y darle una oportunidad al nuevo romance”

Att.

Rebif Citpo VI + Tniv Frec, Avaj, Cin, Pir, Lrep, Locotorp, Tan Tap, Lufetats

P.D. Es una inocentada, pero ojo, cuando el río suena, piedras trae: https://datatracker.ietf.org/doc/draft-retana-idr-bgp-quic/

Un necesario RFC sobre BGP: AS Path Prepending

Introducción

Border Gateway Protocol (BGP) desempeña un papel fundamental en la construcción y mantenimiento de las tablas de enrutamiento en Internet, a tal punto que es considerado como el “pegamento” de Internet. En este contexto, una técnica de muchos años atrás y ampliamente popular conocida como “AS Path Prepending” se ha concebido como una estrategia clave para influir en la selección de rutas y la optimización del tráfico tanto entrante como saliente de un AS.

En el presente documento navegaremos a través del draft IETF “AS Path Prepending” [1], el cual recoge varias ideas y conceptos muy valiosos para la comunidad.

Sobre el Draft draft-ietf-grow-as-path-prepending

El Draft se encuentra en discusión dentro del Working Group GROW (Global Routing Operation) desde el año 2020, y actualmente se encuentra en su versión 10.

El draft cuenta con 7 autores: M. McBride, D. Madory, J. Tantsura, R. Raszuk, H. Li., J. Heitz y G. Mishra. En la lista de discusión este draft ha tenido mayoritariamente apoyo (incluido este humilde servidor). Puedes leerlo aquí.

¿Qué AS Path Prepending?

El AS Path Prepending es una técnica que implica la adición repetitiva del identificador de sistema autónomo (ASN) propio a la lista de ASs en el camino de una ruta BGP (AS_PATH). Su objetivo es influir en la selección de rutas, haciendo que ciertos caminos sean menos atractivos para el tráfico entrante/saliente. En otras palabras, es agregar nuestro sistema autónomo en el AS_PATH y así artificialmente “alejar un prefijo” en Internet.

En el gráfico anterior sin prepends, Router A prefiere ir a C a través de B; sin embargo debido a 3 prepends agregados en B, router A decide alcanzar C a través de D.

¿Para qué y por qué se hace AS PATH Prepending?

Existen muchas razones por las cuales se hace AS PATH prepending. La principal razón indiscutiblemente sería por ingeniería de tráfico la cual a su vez recae en el deseo de influenciar el tráfico entrante y saliente al AS. Es muy probable que el AS desee lograr alguno de los siguientes objetivos:

• distribución de tráfico entre dos o más upstream providers
• tener algún upstream provider de backup
• Sea cual sea el caso, una vez más el objetivo es ingeniería de tráfico.

Hacer prepend o no hacer prepend, he ahí el dilema

Hacer prepend se parece un poco al NAT, es un mal muchas veces necesario.

Como explicaremos, su uso excesivo y a veces innecesario puede convertirse en una vulnerabilidad con implicaciones significativas para la estabilidad de las redes.

¿Qué tiene de malo hacer AS Path Prepending?

Todos sabemos que hacer AS Path Prepending es una técnica muy común para influenciar las decisiones de BGP, sin embargo, el excesivo/mal/ y a veces innecesario uso puede traer resultados negativos. Por ejemplo:

• crear un tráfico subóptimo, es decir, quizás en los enlaces inmediatos logremos nuestro objetivo de una distribución de tráfico, sin embargo, mas alla de tu upstream inmediato el tráfico no se encuentre optimizado para alcanzar nuestro sistema autónomo y viceversa;
• desagregación de prefijos, es muy normal que al momento de querer hacer una ingeniería de tráfico se proceda a desagregar prefijos afectando así el ecosistema de Internet;
• en caso de algun route-leak (fuga de ruta), en condiciones normales nuestras publicaciones tenderían a tener un as-path más corto que el leak, pero si alargamos artificialmente el path haciendo prepend es posible que las rutas fugadas tengan un as-path más corto que las que estamos anunciando legítimamente de nuestro prefijo -legítimo- tendrá menos preferencia en Internet trayendo consigo posibilidades de secuestro de rutas, ataques, y un largo etcétera;
• memoria: como es de esperarse, estos AS Path Prepends son aprendidos por los BGP Speakers consumiendo su memoria. A esto yo también le sumaría a cada prefijo un pequeño consumo de CPU adicional.

Si no recomiendan hacer AS Path Prepend, ¿qué puedo hacer?

Existen muchas técnicas para realizar ingeniería de tráfico en BGP.  menciono algunas que aparecen en el draft:

• considera aprovechar las comunidades BGP. Además de las comunidades BGP ampliamente reconocidas, te recomiendo que dialogues con tus pares BGP para optimizar el tráfico. Existen numerosas comunidades BGP implementadas por proveedores, las cuales seguramente podrían beneficiar tu configuración
• Puedes realizar anuncios más específicos hacia tus upstream principales
• Manipular el AS Origin Code; recordemos que este atributo también se encuentra en el algoritmo de selección de rutas de BGP
• Usar MED (Multi Exit Discriminator), un atributo no transitivo, excelente para manipular el tráfico entrante cuando tenemos varios enlaces hacia el mismo proveedor
• Local Preference, otro atributo no transitivo, perfecto para influenciar el tráfico que sale de nuestro sistema autónomo

Todo muy bien, pero aún necesito hacer AS Path Prepend, ¿alguna sugerencia?

El draft menciona las mejores prácticas al momento de realizar prepends, aquí te resumo las mismas:

• solo hacer AS Path Prepend cuando sea imprescindible;
• debido a algunas técnicas de manipulación de tráfico puede ocurrir que al hacer AS Path Prepend no veamos cambios significativos en la distribución del tráfico, por ello es importante conversar con nuestros pares y saber si ellos respetan los prepends;
• utilizar Local Preference en nuestra red;
• no realizar prepends con números de ASs que no son nuestros;
• no hacer prepend si eres single home (esta no está en el draft);
• si realizamos preprends de algún prefijo quizás no es necesario colocar ese prepend hacia todos mis peers;
• no hay necesidad de colocar más de 5 prepends. El motivo es que más del 90% de los destinos se encuentran a 5 o menos ASs de distancia.

(imagen tomada de: https://www.potaroo.net/ispcol/2019-10/prepending.pdf)

Consideraciones finales:

El uso de AS_PATH Prepending es una estrategia valiosa pero debe ser utilizada sólo cuando es necesario y de una manera precavida siguiendo las mejores prácticas. El uso excesivo de prepends puede ocasionar imprevistos a nuestro sistema autónomo desde la perspectiva de tráfico como de seguridad.

Te invitamos a leer el draft completo aquí, y sumarte a la discusión en la lista de LACNOG

Además, te animamos a dejarnos un comentario en este post, para contarnos si haces prepending de tu ASN, por qué y para qué lo usas.

Referencias:

[1] https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/ 

BGP: Ejemplo IPv6 Only entre FRR y OpenBGPD

FRR:

show run

frr# sh run 

Building configuration...

Current configuration:

!

frr version 8.1

frr defaults traditional

hostname frr

log syslog informational

service integrated-vtysh-config

!

interface l0

 ipv6 address 2001:db8::1/128

exit

!

router bgp 65001

 bgp router-id 1.1.1.1

 no bgp ebgp-requires-policy

 neighbor 2001:db8:12::2 remote-as 65002

 !

 address-family ipv6 unicast

  redistribute connected

  neighbor 2001:db8:12::2 activate

  neighbor 2001:db8:12::2 soft-reconfiguration inbound

 exit-address-family

exit

!

OpenBGPD

Archivo: /etc/bgpd.conf

# macros

ASN="65002"

fib-update yes

log updates

# global configuration

AS $ASN

router-id 2.2.2.2

network 2001:db8::2/128

network inet6 connected

neighbor 2001:db8:12::1 {

    descr "epa"

    remote-as 65001

    announce IPv6 unicast

}

deny from any

deny to any

allow from 2001:db8:12::1

allow to 2001:db8:12::1

#

(por favor notar el espacio en blanco entre la última línea y la antepenúltima línea)

Como crear una ruta IPv6 a null/blackhole en Linux

Caso:

   Como crear una ruta IPv6 a null/blackhole en Linux

Comando:

  ip -6 route add blackhole fd00:12:34::0/48

Espero sea útil