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/ 

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/ 

Bar chart race - Despliegue IPv6 en LAC desde Mayo 2014 a Junio 2023

 

Análisis de 7 variables BGP en la región durante el 2022

Contexto de este análisis: Un poco de historia

Internet es un ambiente que cambia, incluso minuto a minuto, segundo a segundo. Cambian las rutas, cambian los sistemas autónomos. Todo esto hace al ecosistema de Internet más divertido e interesante.

Muchos de los que leemos diferentes listas de correo probablemente estemos acostumbrados a recibir un email los viernes llamado: “Weekly Global IPv4 Routing Table Report”, generado por Phillips Smith de NSRC (Network Startup Research Center). Lo cierto es que en ese correo envían datos muy valiosos sobre BGP y el mundo IPv4. Desde LACNIC nos preguntamos ¿qué podemos hacer con esa información? Y la respuesta fue: ¡vamos a procesarla!

Con todo esto en mente, construimos un parser para rescatar diferentes variables en el mundo de BGP de la lista de correo de LACNOG [1] con la intención de construir un histórico de diferentes variables en el mundo BGP que abarque varios años. Con esta información nos preguntamos ¿Cuánto cambiaron las estadísticas de BGP en nuestra región durante el 2022? Aquí te damos la respuesta.

Los datos utilizados

Los datos utilizados para el presente análisis son tomados exclusivamente de la lista de correo de LACNOG en: https://mail.lacnic.net/mailman/listinfo/lacnog, filtrado por los emails con el título: “Weekly Global IPv4 Routing Table Report”

Alcance

Este análisis abarca únicamente el área de cobertura de LACNIC durante el periodo que comprende desde el 1 de enero al 31 de diciembre de 2022. Es importante destacar que los datos son exclusivamente en el ámbito de IPv4.

Las variables estudiadas fueron:

•     Prefijo anunciado por los AS de la región de LACNIC
•     AS de origen de la región de LACNIC presentes en la tabla de enrutamiento de Internet
•     AS de origen de la región de LACNIC que anuncian un solo prefijo
•     AS de la región de LACNIC que brindan tránsito y que están presentes en la tabla de enrutamiento de Internet
•     Número de direcciones de LACNIC anunciadas a Internet
•     Factor de desagregación de LACNIC
•     Prefijos de LACNIC por ASN

¿Por qué estas variables?

Las variables expresadas anteriormente son las que consideramos principales debido a que representan el estado de BGP en algún momento determinado, con las mismas y colocándolas en una línea de tiempo podemos conocer con precisión cambios importantes en nuestra región y a su vez, muchas de las otras variables mencionadas en el informe semanal son una sencilla matemática de las que ya tenemos.

Ejemplo de los datos procesados (tomado [2])

Resumen de datos de la región de LACNIC

——————————

Prefixes being announced by LACNIC Region ASes: 117404

Total LACNIC prefixes after maximum aggregation: 28499

LACNIC Deaggregation factor: 4.12

Prefixes being announced from the LACNIC address blocks: 116794

Unique aggregates announced from the LACNIC address blocks: 48887

LACNIC Region origin ASes present in the Internet Routing Table:  10986

LACNIC Prefixes per ASN: 10.63

LACNIC Region origin ASes announcing only one prefix: 2672

LACNIC Region transit ASes present in the Internet Routing Table:  2278

Average LACNIC Region AS path length visible: 4.9

Max LACNIC Region AS path length visible: 55

Number of LACNIC region 32-bit ASNs visible in the Routing Table:  8784

Number of LACNIC addresses announced to Internet: 176436224

Equivalent to 10 /8s, 132 /16s and 52 /24s

LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-273820 + ERX transfers

LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8,

Procesamiento de los datos 

Los datos fueron procesados en su totalidad utilizando Python3 sobre Linux. Particularmente la librería beautifulsoup [3] fue muy útil para realizar el scraping de la lista de correo. Las gráficas son generadas por Google Charts a través de su API.

Resultados:

•     Prefijo anunciado por los AS de la región de LACNIC

Este indicador expresa el número de prefijos anunciados a Internet por sistemas autónomos de LACNIC. Muestra un crecimiento ligero pero constante, el mismo tuvo un alza de 5%, aumentando 5.857 prefijos en un periodo de 364 días, comenzando el 1 de enero de 2022 con 111.641 y finalizando el 31 de diciembre del mismo año en 117.498 prefijos.

• AS de origen de la región de LACNIC presentes en la tabla de enrutamiento de Internet

Este indicador representa la cantidad de sistemas autónomos asignados por LACNIC que son visibles en la tabla global de Internet (DFZ – Default Free Zone). Se aprecia una gráfica muy constante, con un muy leve crecimiento de apenas 1%, aumentando 117 ASs en un periodo de 364 días, comenzando el 1 de enero de 2022 con 10.893 y finalizando el 31 de diciembre del mismo año en 11.010.

• AS de origen de la región de LACNIC que anuncian un solo prefijo

Esta variable indica la cantidad de sistemas autónomos asignados por LACNIC que anuncian sólo un prefijo a la tabla global de Internet (DFZ – Default Free Zone). A pesar de parecer senoidal, las variaciones en esta gráfica tampoco son tan marcadas (se puede apreciar observando el eje de las Y y su escala). Fue un valor muy estable durante todo el año y al final tuvo una pequeña alza de 0,2%, aumentando 6 ASs que anuncian sólo un prefijo en un periodo de 364 días, comenzando el 1 de enero de 2022 con 2662 y finalizando el 31 de diciembre del mismo año en 2668.

• AS de la región de LACNIC que brindan tránsito y que están presentes en la tabla de enrutamiento de Internet

Esta interesante variable expresa la cantidad de ASs en la región de LACNIC que realizan tránsito a otro AS;la misma tuvo un crecimiento de 4,2%, con una añadidura de 92 ASs de LACNIC que realizan tránsito a otro AS en un periodo de 364 días, comenzando el 1 de enero de 2022 con 2188 y finalizando el 31 de diciembre del mismo año en 2280.

• Número de direcciones de LACNIC anunciadas a Internet

Este valor indica la cantidad de direcciones IPv4 únicas asignadas por LACNIC que son visibles en la tabla global de enrutamiento (DFZ – Default Free Zone). La cantidad de direcciones IPv4 visibles tuvo un decrecimiento de 0,3% disminuyendo en 447488 direcciones. Para el 1 de enero de 2022 fueron visibles 176521472 direcciones y para el 31 de diciembre del mismo año 176073984.

• Factor de desagregación de LACNIC

El factor de desagregación puede sonar complicado, pero a su vez es un valor a tener muy en cuenta. Este es el típico caso donde menos quiere decir más.  En esta oportunidad la región de LACNIC termina el año (31/Dic/2022) con un factor de desagregación de 4.13 comenzando con 4.09 (1/Enero/2022), lo que significa que ocurrió un aumento de 0,04. Un factor de desagregación más alto implica que se están anunciando más prefijos específicos para la dirección de destino/padre, lo que puede proporcionar una granularidad y precisión mayores en las decisiones de enrutamiento. Sin embargo, un factor de desagregación más alto también puede llevar a un aumento en los requisitos de memoria y procesamiento para los routers. Lo ideal en este caso es que los operadores de red revisen sus anuncios y que no realizar anuncios sin necesidad, por ejemplo, minimizar el subnetting en el anuncio.

Para que veamos el impacto, una red con 10.000 anuncios y con un factor de 4 de desagregación, en el caso utópico que lleven el factor 1, tan solo tendría 2.500 anuncios.

• Prefijos de LACNIC por ASN

Este valor representa la cantidad de prefijos promedios que realizan los AS de la región de LACNIC, una variable sin mayores variaciones durante todo el año.  Tuvo un crecimiento de 0,48% aumentando de 10,32 a 10,8 prefijos promedio por ASs.

Conclusiones:

A continuación, se presentan las conclusiones principales:

•     Se observa un crecimiento constante de un 5% de los prefijos anunciados a Internet por sistemas autónomos de LACNIC durante 2022 (de 111.641 a 117.498)
•     El número de sistemas autónomos asignados por LACNIC que son visibles en la tabla global de Internet muestra una gráfica constante con un leve crecimiento del 1%. Durante el año, se incrementaron en 117, pasando de 10,893 a 11,010 ASes.
•     Estabilidad en los ASes de origen de LACNIC que anuncian solo un prefijo: La cantidad de sistemas autónomos asignados por LACNIC que anuncian únicamente un prefijo a la tabla global de Internet se mantuvo relativamente estable a lo largo del año. Hubo un aumento del 0.2%, pasando de 2,662 a 2,668 ASes que anuncian solo un prefijo.
•     Se aprecia un crecimiento del 4.2% en la cantidad de sistemas autónomos que realizan tránsito a otros sistemas autónomos. Durante el año, se agregaron 92 ASes de LACNIC que realizan tránsito, pasando de 2,188 a 2,280.
•     En cuanto a la cantidad de direcciones IP visibles en la DFZ y teniendo en cuenta que no son prefijos sino números de IP podríamos decir que se mantiene estable. La disminución es despreciable. Quizás la conclusión principal es que no han aumentado pese al agotamiento, lo que daría a entender que no hay nuevos bloques que se hayan comenzado a anunciar
•     El factor de desagregación se mantuvo sin casi variaciones, pero tuvimos al final un aumento pequeño, como se mencionó anteriormente esto no es positivo para el ecosistema de Internet.

Referencias:

[1] https://mail.lacnic.net/mailman/listinfo/lacnog

[2] https://mail.lacnic.net/pipermail/lacnog/2023-March/009429.html

[3] https://pypi.org/project/beautifulsoup4/

[4] https://stats.labs.lacnic.net/BGP/ParserWeeklyBGPUpdate/ParserWeeklyBGPUpdate.html

[5} Github del parser: https://github.com/LACNIC/WeeklyParserForBGPStats

Una mirada a los miembros IPv6 Only de LACNIC

Introducción

El siguiente trabajo busca analizar la publicación de prefijos y el estado de los mismos, por parte de los miembros de LACNIC conocidos como IPv6 Only.

Se trata de organizaciones que han recibido prefijos IPv6, con o sin sistema autónomo (ASN), y no cuentan con prefijo IPv4 asignado por LACNIC. Los resultados de este análisis nos ayudarán a mejorar nuestra comprensión de los usos y necesidades de nuestros asociados en la región.

Fuentes de información utilizadas en este análisis

 La fuente de información utilizada en este análisis  fue el whois de LACNIC, con datos  obtenidos a lo largo del mes de enero de 2023. Esta información  incluye únicamente a aquellos miembros que posean IPv6 y no poseen IPv4 por parte de LACNIC. Pueden o no tener asignado un sistema autónomo.

Procesamiento de los datos

Python3 sobre un notebook Jupyter. Nos apoyamos en los API públicos de LACNIC y de RIPE NCC

            WHOIS de LACNIC

            RIPE NCC API

            APNIC Penetración IPv6 por ASN

            Delegated Extended de LACNIC:

Resultados

  Obtuvimos 483 miembros de LACNIC que se consideran IPv6 Only, a los que dividimos en:

            IPv6 Only con ASN: 343 miembros

            IPv6 Only sin ASN: 140 miembros

Resultados sobre los 483 miembros IPv6 Only (con y sin ASN):

 De los 483 miembros analizados obtuvimos la siguiente información:

-261 Anuncian el prefijo en su totalidad o parcialmente

-208 Anuncian el prefijo recibido por LACNIC en su totalidad

-53 Anuncian el prefijo recibido por LACNIC parcialmente

-222 No anuncian el prefijo

Resultados sobre los 343 miembros IPv6 Only con ASN:

De los 483 miembros IPv6 Only 343 tienen ASN (71%)

De los 343 con ASN:

                        163 anuncian el prefijo (47,52%)

120 Anuncian el prefijo IPv6 completo (73,61 %)

43 Anuncian el prefijo IPv6 parcialmente (26,38 %

180 No anuncian el prefijo Pv6  (52,48%)

Resultados sobre los 140 miembros IPv6 Only Sin ASN

De los 483 miembros IPv6 Only 140 no tienen ASN (29%)

De los 140 sin ASN obtuvimos

98 Anuncian el prefijo (70%)

82 Anuncian el prefijo completo (83,67%)

16 Anuncian el prefijo parcialmente (16,32%)

42 No anuncian el prefijo (30%)

¿Qué podemos extraer de los gráficos anteriores?

Lo primero que me llama poderosamente la atención es que los miembros IPv6 Only sin ASN poseen 23 puntos porcentuales más anuncios que aquellos miembros de LACNIC que si poseen su ASN. Es decir, estos miembros han pedido a otra organización que anuncie su prefijo.

En ambos casos la cantidad de prefijos no anunciados es muy alta; puede ser interesante averiguar si existe algún motivo detrás de esta situación. 

Es particularmente llamativo que el porcentaje de anuncio parcial es casi idéntico (11% miembros con ASN y 12% miembros sin ASN)

Intentando identificar si los ASNs poseen tráfico IPv6

Conociendo que existen 343 ASNs con prefijos IPv6 asignados y pensando que además son IPv6 Only, se puede presumir que deben tener un tráfico IPv6 “medio alto”.  Por ello, evaluamos cada AS para conocer su tráfico IPv6 para el 23 de Enero 2023.

¿Cómo averiguamos si un ASN posee tráfico IPv6?

Como es conocido por varios de ustedes, APNIC lleva muchos años midiendo el tráfico IPv6 de cada ASN. Se puede conocer más de estos estudios aquí: https://stats.labs.apnic.net/ipv6

En base a lo anterior, con los ASNs conocidos de los miembros IPv6 Only de LACNIC quisimos averiguar si efectivamente poseen tráfico IPv6 (es decir, más allá de realizar el anuncio de su prefijo). 

Lastimosamente no se pudo conseguir información de 274 ASs (79,88 %) de los 343 evaluados, Sin embargo, es importante destacar que esto no necesariamente significa que no hayan desplegado IPv6, sino que el tráfico generado es muy bajo y no aparecen en las mediciones de APNIC. 32 ASN fueron reportados con 0% de tráfico IPv6 y 1 ASN con 88% de tráfico IPv6.

¿Nuestros miembros IPv6 Only son en realidad tan IPv6 Only?

Finalmente, quisimos averiguar si efectivamente nuestros miembros (IPv6 Only con ASN) son tan IPv6 Only como nosotros los llamamos.

Para este caso en particular nos apoyamos en el API de RIPE NCC para obtener la información presentada a continuación.

De los 343 miembros con ASNs obtuvimos:

-540 prefijos totales anunciados (entre v4 y v6)

                        Anuncios v4: 220

                        Anuncios v6: 320

                        La máscara media en los anuncios v4 es: 23,56

                        La longitud de prefijo media en los anuncios IPv6 es: 38,09

-66 miembros se “volvieron” DualStack, es decir el ASN anuncia IPv4 e IPv6

-90 miembros anuncian solo IPv6

-27 miembros anuncian solo IPv4

-160 no anuncian prefijo alguno

Y los prefijos IPv4 que anuncian los miembros IPv6 Only de LACNIC,  ¿a cuál RIR pertenecen?

LACNIC ARIN RIPE NCC AFRINIC APNIC

28 166 17 9 0

Diagrama Sankey – Mirada a los miembros IPv6 Only

Conclusiones

Los resultados sugieren que, aunque existe una cantidad significativa de miembros de LACNIC que se consideran IPv6 Only, pudimos notar que más del 50% de ellos no han comenzado con el anuncio de su prefijo v6. A su vez pudimos apreciar que muchos de los que han desplegado IPv6 continúan utilizando IPv4. Esto significa que, aunque la adopción de IPv6 en la región ha crecido en los últimos años, aún hay un largo camino por recorrer para alcanzar un despliegue generalizado de IPv6. En cualquier caso, es importante continuar monitoreando la adopción del nuevo protocolo.

Finalmente ser un miembro IPv6 Only de LACNIC igualmente permite a las organizaciones participar en el ecosistema de Internet.

 

Despliegue de DNSSEC en la región - Estadística y mediciones

 dnssec mediciones

Por: Hugo Salgado (@huguei) / Dario Gomez (@daro_ua) / Alejandro Acosta (@ITandNetworking)

Introducción

En el presente post queremos conversar sobre unas recientes investigaciones que hemos realizados 

sobre un tema que nos apasiona mucho: DNSSEC. Por favor notar que hablamos en plural: 

“investigaciones”, debido a que son dos estudios sobre DNSSEC que comenzamos a la vez… 

¡favor continua leyendo para que entiendas de que se tratan ambas dos!

Sobre DNSSEC

DNSSEC añade un plus de seguridad al protocolo DNS que permite comprobar la integridad

 y autenticidad de los datos, previniendo ataques de suplantación y falsificación, mediante

 el uso de criptografía asimétrica o mejor conocida como clave pública / privada. 

Mediante el uso de estas claves y las firmas generadas a partir de ellas, se puede saber 

si una consulta fue modificada, permitiendo garantizar la integridad y autenticidad del 

mensaje. Si al comprobar estas firmas no coinciden entre ellas, quiere decir que la cadena 

de confianza se ha roto y la consulta no puede ser validada como legítima.

Contar con DNSSEC depende del ISP o del proveedor de servicios de internet que tenga 

contratado, que es quien debe configurarlo. Para saber si cuenta con DNSSEC existen varias 

herramientas en Internet que lo permiten como:

https://dnssec-analyzer.verisignlabs.com/

https://dnsviz.net/

Como muchos saben DNSSEC es un protocolo que ha venido creciendo mucho en los 

últimos años. Dos aspectos han marcado su aumento del despliegue:

1) DNSSEC viene habilitado por defectos en algunos servidores recursivos (BIND) y

2) Grandes avances en facilitar habilitar DNSSEC en los diferentes dominios por los 

registradores más importantes.

3) Todos los grandes recursivos públicos hacen validación DNSSEC (google public dns, 

cloudflare, quad9, etc)

4) Apple acaba de mencionar que iOS16 y macOS Ventura permitirán hacer validación 

DNSSEC en el stub final.

DNSSEC ha sido un tema muy importante para LACNIC, hemos realizado gran cantidad 

de eventos y actividades en torno a este tema, sin embargo hasta la fecha no teníamos 

ningún estudio propio al respecto.

¿De qué trata el estudio?

Desde el área I+D de LACNIC quisimos realizar un estudio con el fin de conocer el estado 

y el avance respecto al despliegue de DNSSEC en la región.

Origen de la Data

Tenemos dos fuentes de datos muy confiables

• Utilizamos los probes ATLAS de RIPE https://atlas.ripe.net/

• Realizamos capturas (tcpdump) que posteriormente fueron anonimizadas en 

• servidores autoritativos

Fechas:

La obtención de la data comenzó en Noviembre de 2021, actualmente se lleva a cabo de 

una manera automatizada con reportes semanales y mensuales [1]

¿Cómo se identifica que un servidor realice DNSSEC?

Hay que verlo desde dos aspectos:

Sondas Atlas:

Se envían solicitudes de resolución DNS a todas las sondas disponibles en latinoamérica y el caribe, por un nombre de dominio que intencionalmente tiene sus firmas incorrectas y por lo tanto no valida según DNSSEC. Si la respuesta es error (SERVFAIL), quiere decir que el resolver que utiliza esa sonda sí utiliza correctamente DNSSEC. Si por el contrario se obtiene respuesta (NOERROR), quiere decir que dicho resolver no realiza ninguna validación. Nótese que interesantemente la idea es que la respuesta del servidor DNS sea negativa, *esto es la clave* para saber si el recursivo valida DNSSEC o no. 
Te dejamos este ejemplo: si visitas dnssec-failed.org y puedes abrir la página significa que tu DNS recursivo no hace DNSSEC, si no la puedes abrir es bueno! :-). 

Captura (tcpdump):

Antes de indicar que hacemos con la captura vamos a expandir un poco el concepto de DNSSEC. Así como existen los registros tradicionales en DNS (A, AAAA, MX, etc) para la utilización de DNSSEC se agregaron nuevos registros, estos mismos son DS, RRSIG, NSEC, NSEC3 y DNSKEY. Es decir, un servidor DNS recursivo puede consultar el registro AAAA para conocer la dirección IPv6 de un registro y puede consultar el registro DS (Delegation Signer) para verificar la autenticidad de las zonas hijas. La parte clave de este estudio es que los servidores que no hacen validaciones DNSSEC no consultan registros DNSSEC!. 

En base a lo anterior, al momento de realizar la captura se le pide a tcpdump que tome todo el paquete (flag -s 0),  de esa manera tenemos todo el contenido del mismo, desde capa 3 hasta capa 7, durante el procesamiento del paquete buscamos por los registros específicos de DNSSEC (nuevamente: DS, RRSIG, NSEC, NSEC3 y DNSKEY), si conseguimos alguno de ellos entonces el recursivo si hace DNSSEC, en caso contrario no hace. 

¿Donde se realiza la captura mencionada?

La captura se hace especificamente en una de las instancias del servidor DNS 

Reverso D (D.IP6-SERVERS.ARPA). El comando utilizado es: /usr/sbin/tcpdump 

-i $INTERFAZ -c $CANTIDAD -w findingdnssecresolvers-$TODAY.pcap -s 0 dst port 

$PORT and ( dst host $IP1 or dst host $IP2 )

Procesamiento de la información

Primero, el procesamiento de los datos consta de varias partes, todas realizadas 

completamente con software Open Source, específicamente con Bash, Perl y Python3 

sobre Linux.

Segundo, recordemos que existen dos fuentes de información: Captura de tráfico (PCAPs) 

y Probe Atlas. Aquí la metodología seguida en cada caso:
  a) Procesamiento de los PCAPs: Luego de obtener los PCAPs se realizan una serie de 

paso, entre ellos:

    1) El procesamiento de los .pcap se realiza en Python3 utilizando la librería pyshark.
    2) Limpieza de los datos improcesables (paquetes malformados, dañados, no-procesables, etc)
    3) Remoción de direcciones duplicadas
    4) Anonimización de datos
    5) Generación de resultados
    6) Generación de las gráficas y open data

  b) Procesamiento de la información obtenida en RIPE Atlas:
La captura de datos se realiza con mediciones mensuales en la plataforma RIPE Atlas, 

utilizando su API por línea de comandos. Luego se recogen y procesan en una serie de 

scripts utilizando lenguaje Perl, para finalmente graficar utilizando la API de Google Charts 

y adicionalmente dejamos los datos disponibles siempre en Open Data.
Favor recordemos que para detectar si una sonda está utilizando un resolver con validación, 

se utiliza un nombre de dominio que intencionalmente tiene sus firmas incorrectas. De 

esta forma, al intentar resolver ese nombre, una sonda que valide debe responder con error, 

porque el nombre no es válido según DNSSEC. Por el contrario, si se obtiene una respuesta 

positiva frente al nombre, quiere decir que el resolver no está validando, ya que ignoró la 

firma incorrecta.

Resultados obtenidos

Esta gráfica muestra la cantidad de servidores estudiados que utilizan DNSSEC y cuáles no 

lo usan. Las líneas azules determinan los servidores con DNSSEC activo, las rojas los que 

no lo tienen.

Grafico 1

Se puede apreciar que para el 2 de Junio 2022 existen más servidores recursivos sin realizar 

DNSSEC que los que lo hacen. Se analizaron entre 33.000 a 55.000 direcciones IP cada semana. 

En líneas generales, se mantiene un promedio aproximado de un 55% de servidores que no utilizan 

el protocolo y un 45% de muestras positivas.

Grafico #2

En el gráfico #2 podemos apreciar el histórico de consultas DNSSEC en IPv6. Un dato no menor 

que llama mucho la atención es que en varios periodos de muestreo, existen más cantidad de 

consultas DNSSEC sobre v6 que en v4. Indiscutiblemente la intención es que la línea roja 

disminuya y la azul aumente de forma gradual.

Ranking de países con mayor validación DNSSEC

Utilizando la plataforma de mediciones de RIPE Atlas, es posible medir en cada una de ellas su 

capacidad de validar DNSSEC o no. Cada medición se puede agrupar por país, creando un ranking:

Grafico #3

Ranking ordenado con el porcentaje de validación DNSSEC promedio desde redes de países 

en Latinoamérica y el Caribe correspondiente a mayo de 2022.

Los números dentro de las barras indican la cantidad de ASs participantes por cada país. Se 

descartan países donde medimos un solo ASs.

Resumen

Desde el estudio basado en captura de tráfico, con los datos obtenidos en un lapso de 8 

meses la gráfica sugiere una disminución lenta de número de servidores NO-DNSSEC; 

adicionalmente parece existir un mayor despliegue de DNSSEC en servidores IPv6 que en IPv4.

En el caso del análisis de sondas Atlas, es esperable un mayor despliegue de validación que 

con otras fuentes de datos más genéricas, considerando que las sondas generalmente son 

hospedadas en redes más avanzadas o por usuarios que podrían activar deliberadamente 

DNSSEC. Pero representa de alguna manera el “límite superior” de penetración, y también 

es un indicador importante de la evolución a través del tiempo.

OpenData

Como es habitual en LACNIC siempre deseamos dejar nuestra información disponible para su 

trabajo por quien así lo desee:

https://stats.labs.lacnic.net/DNSSEC/opendata/

https://mvuy27.labs.lacnic.net/datos/

Estos datos que estamos dejando disponibles también poseen el espíritu de “Time Series 

Data”. Es decir, estamos dejando los datos recolectados durante el tiempo lo que hará muy 

sencillo tener fluctuaciones de nuestras estadísitcas en el tiempo y saber si el despliegue de 

DNSSEC aumenta y/o disminuye por país, región, etc.

Como siempre cuando realizamos este tipo de proyectos, son bienvenidas sugerencias de 

mejora tanto en la implementación como en la visualización de la información obtenida.

Referencias:

[1] https://stats.labs.lacnic.net/DNSSEC/dnssecstats.html

https://mvuy27.labs.lacnic.net/datos/dnssec-ranking-latest.html