Mostrando entradas con la etiqueta lacnic. Mostrar todas las entradas
Mostrando entradas con la etiqueta lacnic. Mostrar todas las entradas
miércoles, 28 de junio de 2023
sábado, 10 de junio de 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
viernes, 17 de marzo de 2023
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.
lunes, 25 de julio de 2022
Despliegue de DNSSEC en la región - Estadística y mediciones
Despliegue de DNSSEC en la región - Estadística y 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/
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.
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:
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
lunes, 20 de junio de 2022
Despliegue de IPv6 en la región LACNIC - Bar Chart Race IPv6 a Junio 2022
El video muestra la adopción de IPv6 en la región atendida por LACNIC desde Mayo 20214 a Junio 2022. Hecho con https://flourish.studio/
miércoles, 29 de septiembre de 2021
viernes, 25 de junio de 2021
Despliegue de IPv6 - Región LACNIC
El video muestra la adopción de IPv6 en la región atendida por LACNIC desde Mayo 20214 a Junio 2021.
Made with https://flourish.studio/
miércoles, 23 de junio de 2021
ASNs con IPv6 vs ASNs sin IPv6
Tenemos el agrado de anunciar que hemos publicado una nueva estadística. En este post te damos todos los detalles. Si quieres ir directo al sitio web te dejamos la URL: https://stats.labs.lacnic.net/IPv6/ASNsConIPv6vsASNsSinIPv6.html
Objetivo
Conocer la evolución del despliegue de ASNs (sistemas autónomos) en nuestra región con y sin IPv6. En otras palabras: ¿Cada vez hay más ASNs publicando prefijos IPv6?
Un poco de historia
El área de I+D (Investigación y Desarrollo de LACNIC) recibió por parte del área de Cooperación una consulta sobre el número de ASNs en la región que estuviesen utilizando IPv6. Lastimosamente en ese momento no podíamos dar una respuesta inmediata.
Los datos
A pesar de que sacar el número mencionado arriba es un trabajo relativamente fácil debido que por varios años I+D ha venido recabando esos datos de APNIC [1] se decidió realizar dicho trabajo de manera automatizada y disponible para toda la comunidad.
¿A que se considera un ASN con IPv6?
A efectos de las estadísticas mostradas se considera un ASN con IPv6 aquellos que reporten más de un 1 por ciento (>1%) en su adopción (valor tomado por APNIC)
Un ejemplo de la gráfica
¿Que muestra la gráfica?
La gráfica es una serie de tiempo que comienza a finales del año 2014 hasta el día de hoy. Cada uno de los valores en el eje Y representa el % de Sistemas Autónomos para los países de cobertura de LACNIC con y sin IPv6. El eje X representa el instante en el tiempo. Importante destacar: Línea Azul= ASNs sin IPv6. Línea roja= ASNs con IPv6
Leyendo la gráfica
Los buenos estadistas son muy buenos leyendo e interpretando información de una gráfica. Entre muchas cosas podemos obtener:
Sobre la automatización
Los datos se actualizarán todos los días sábados a las 3:59 pm UTC -3
Recuerda el link de la nueva estadística quedó en: https://stats.labs.lacnic.net/IPv6/ASNsConIPv6vsASNsSinIPv6.html
¿Los datos se encuentran en opendata?
Si, desde hace muchos años en LACNIC venimos haciendo un esfuerzo por publicar nuestra información en opendata (CVS y/o JSON). Para este nuevo estudio se encuentra en: https://stats.labs.lacnic.net/IPv6/opendata/ASsConIPv6vsASNsSinIPv6-opendata.json
Referencias
[1] http://data1.labs.apnic.net/ipv6-measurement/AS/asns.nice.loadable.json
Objetivo
Conocer la evolución del despliegue de ASNs (sistemas autónomos) en nuestra región con y sin IPv6. En otras palabras: ¿Cada vez hay más ASNs publicando prefijos IPv6?
Un poco de historia
El área de I+D (Investigación y Desarrollo de LACNIC) recibió por parte del área de Cooperación una consulta sobre el número de ASNs en la región que estuviesen utilizando IPv6. Lastimosamente en ese momento no podíamos dar una respuesta inmediata.
Los datos
A pesar de que sacar el número mencionado arriba es un trabajo relativamente fácil debido que por varios años I+D ha venido recabando esos datos de APNIC [1] se decidió realizar dicho trabajo de manera automatizada y disponible para toda la comunidad.
¿A que se considera un ASN con IPv6?
A efectos de las estadísticas mostradas se considera un ASN con IPv6 aquellos que reporten más de un 1 por ciento (>1%) en su adopción (valor tomado por APNIC)
Un ejemplo de la gráfica
¿Que muestra la gráfica?
La gráfica es una serie de tiempo que comienza a finales del año 2014 hasta el día de hoy. Cada uno de los valores en el eje Y representa el % de Sistemas Autónomos para los países de cobertura de LACNIC con y sin IPv6. El eje X representa el instante en el tiempo. Importante destacar: Línea Azul= ASNs sin IPv6. Línea roja= ASNs con IPv6
Leyendo la gráfica
Los buenos estadistas son muy buenos leyendo e interpretando información de una gráfica. Entre muchas cosas podemos obtener:
- Existe un marcado crecimiento de ASNs con IPv6 en la región lo que a su vez incide en ASNs que no tengan aún IPv6
- Desde el año 2019 ha aumentado la velocidad de adopción de IPv6
- Actualmente ASNs con IPv6 se encuentran ligeramente sobre 30%
- El crecimiento interanual luego del 2019 supera el 50% !!
Sobre la automatización
Los datos se actualizarán todos los días sábados a las 3:59 pm UTC -3
Recuerda el link de la nueva estadística quedó en: https://stats.labs.lacnic.net/IPv6/ASNsConIPv6vsASNsSinIPv6.html
¿Los datos se encuentran en opendata?
Si, desde hace muchos años en LACNIC venimos haciendo un esfuerzo por publicar nuestra información en opendata (CVS y/o JSON). Para este nuevo estudio se encuentra en: https://stats.labs.lacnic.net/IPv6/opendata/ASsConIPv6vsASNsSinIPv6-opendata.json
Referencias
[1] http://data1.labs.apnic.net/ipv6-measurement/AS/asns.nice.loadable.json
martes, 23 de junio de 2020
Panorámica sobre secuestro de redes. Un mal que nos agobia
Introducción
El objetivo del presente post es exponer de una manera sencilla la realidad en
cuanto al secuestro de redes. Se verán estadísticas de lo que sucede en las
regiones de todos los RIRs, sin embargo siempre se brindará más detalle de lo
que acontece en la región de LAC.
cuanto al secuestro de redes. Se verán estadísticas de lo que sucede en las
regiones de todos los RIRs, sin embargo siempre se brindará más detalle de lo
que acontece en la región de LAC.
Terminología
Secuestro de red o Hijack
Es el apoderamiento ilegítimo de una red IP manipulando las tablas BGP
Evento
Para este documento, “evento” corresponde a cualquier actividad en torno al
secuestro de redes (pe, secuestrar / ser secuestrado)
secuestro de redes (pe, secuestrar / ser secuestrado)
Secuestrador
El actor que realiza el secuestro de una red.
Secuestrado
Es la organización dueña de los recursos que son víctima del secuestro.
Los datos
El origen de los datos corresponde a la cuenta de twitter @bgpstream ubicada
en: https://twitter.com/bgpstream la cual es mantenida por bgpmon (ahora parte
de Cisco). Se aprecia que incluso es un CSV donde podemos extraer mucha
información valiosa.
en: https://twitter.com/bgpstream la cual es mantenida por bgpmon (ahora parte
de Cisco). Se aprecia que incluso es un CSV donde podemos extraer mucha
información valiosa.
Un ejemplo de la información contenida en un tweet es:
BGP,HJ,hijacked prefix AS58065 196.196.120.0/24, PACKETEXCHANGE,
SE,-,By AS57858 AS57858, EU, http://bgpstream.com/event/240117
SE,-,By AS57858 AS57858, EU, http://bgpstream.com/event/240117
Veamos en detalle la información de los datos del ejemplo:
HJ = La info contentiva de este tweet que corresponde a un Hijack, un
secuestro de red (estos son los tipos de tweets que precisamos)
secuestro de red (estos son los tipos de tweets que precisamos)
AS58065 = AS Origen del prefijo de la red
SE = Código del país correspondiente al prefijo de la red
196.196.120.0/24 = Prefijo de red secuestrado
AS57858 = AS del secuestrador
http://bgpstream.com/event/240117 URL para obtener más detalles del
evento. Es importante destacar que luego de entrar al link, @bgpstream
define estos eventos como: “Possible BGP hijack”. En este sentido se
presume que en algunas oportunidades existirán falsos positivos.
evento. Es importante destacar que luego de entrar al link, @bgpstream
define estos eventos como: “Possible BGP hijack”. En este sentido se
presume que en algunas oportunidades existirán falsos positivos.
Para la geolocalización de los recursos de Sistemas Autónomos (AS) se utilizó el
API de RIPE NCC ubicado en:
https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-
documentation/how-to-query-the-ripe-database/14-3-restful-api-queries
API de RIPE NCC ubicado en:
https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-
documentation/how-to-query-the-ripe-database/14-3-restful-api-queries
Universo del estudio
Todos los tweets desde el 1 de Enero de 2016 al 31 de Mayo de 2020 de la
cuenta twitter @bgpstream siendo un total de 45.000 (todos los eventos)
cuenta twitter @bgpstream siendo un total de 45.000 (todos los eventos)
Muestra utilizada para el estudio
La muestra para el estudio se obtuvo mediante la selección de los tweets que
contenían en el texto siglas HJ (indicando Hijack). Resultaron un total de 6573
tweets que constituyen la muestra del estudio.
contenían en el texto siglas HJ (indicando Hijack). Resultaron un total de 6573
tweets que constituyen la muestra del estudio.
Procedimiento para el procesamiento de los datos
TweeterScraper fue la herramienta utilizada para extraer los tweets de la cuenta
@bgpstream y luego con scripts propios se procedió a filtrar solo aquellos
correspondientes a secuestro de prefijos (Hijacks).
@bgpstream y luego con scripts propios se procedió a filtrar solo aquellos
correspondientes a secuestro de prefijos (Hijacks).
Las herramientas utilizadas fueron:
- TweetScraper
- Python3
- Adicionalmente se utilizó el API de RIPE NCC para geolocalización de varios
https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-
database-documentation/how-to-query-the-ripe-database/14-3-restful-api-queries
uso de RPKI e IRR. Lastimosamente igualmente creemos que será sempiterno.
database-documentation/how-to-query-the-ripe-database/14-3-restful-api-queries
Resultados obtenidos
Cantidad de secuestros por año (1 de Enero 2016 hasta 31 de Mayo 2020)
En la tabla y gráfica siguientes se aprecian la cantidad de secuestros conseguidos
desde el 2016 a la fecha.
desde el 2016 a la fecha.
Si se realiza la matemática para un cálculo diario se puede apreciar que son
números alarmantes.
números alarmantes.
¿Cómo es el comportamiento por mes?
Se quiso determinar si este comportamiento estaba más o menos acentuado
según el mes del año.
según el mes del año.
Colocando la lupa al gráfico anterior quisimos averiguar cual mes del año es el que
más eventos posee. Para conseguir este valor se tomó la data desde el año 2016 al
2019 (6383 registros), no se procesó el año 2020 debido a ser el año en curso. Se
agruparon los eventos por mes y se hizo un desglose adicional según IPv4 e IPv6.
más eventos posee. Para conseguir este valor se tomó la data desde el año 2016 al
2019 (6383 registros), no se procesó el año 2020 debido a ser el año en curso. Se
agruparon los eventos por mes y se hizo un desglose adicional según IPv4 e IPv6.
A continuación se muestran las gráficas con los resultados.
Se puede distinguir para los totales que el mes con más actividad es Noviembre
Se puede distinguir para los totales que el mes con más actividad es Noviembre
y el mes con menos movimiento es Marzo. Sin embargo, es interesante destacar que
IPv6 aparece como segundo mayor cantidad de secuestros durante el mes de Marzo.
IPv6 aparece como segundo mayor cantidad de secuestros durante el mes de Marzo.
¿Alguna hora del día donde exista mayor cantidad de secuestros?
Adicionalmente tuvimos la curiosidad de conocer si quizás existían algunas horas del
día más propensas a observar secuestros de red. Para este estudio se utilizaron
todos los registros disponibles y se tomó únicamente el entero de la hora del
reporte (indicadas en UTC -4). Por ejemplo, un reporte donde el horario indica
14:23 se procesó únicamente el número 14.
día más propensas a observar secuestros de red. Para este estudio se utilizaron
todos los registros disponibles y se tomó únicamente el entero de la hora del
reporte (indicadas en UTC -4). Por ejemplo, un reporte donde el horario indica
14:23 se procesó únicamente el número 14.
Las horas de más pico son las 11 y 16 (UTC -4) y las horas menos ocupadas fueron
desde las 21 hasta la 01 (UTC -4). Una vez más se puede aprovechar el desglose
adicional de IPv4 e IPv6.
desde las 21 hasta la 01 (UTC -4). Una vez más se puede aprovechar el desglose
adicional de IPv4 e IPv6.
Cantidad de secuestro de rutas diferenciada por RIR
En la tabla inferior se muestra por día de la semana cuál es el RIR que más secuestros
recibe (según Sistema Autónomo del secuestrado)
recibe (según Sistema Autónomo del secuestrado)
Particularmente los prefijos correspondientes a LACNIC tienen su día de mayor
movimiento los Miércoles con 131 registros.
movimiento los Miércoles con 131 registros.
¿Desde cuál RIR se generan más secuestros de rutas?
La siguiente tabla muestra según el día de la semana cual es el RIR que realiza más
secuestros (según Sistema Autónomo del secuestrador)
secuestros (según Sistema Autónomo del secuestrador)
Y específicamente LACNIC comparte el mismo día Jueves como su mayor
movimiento en este rubro.
movimiento en este rubro.
¿Cuál es el día de la semana con menos secuestros por RIR?
Sin sorpresa podemos darnos cuenta que el día de menos actividad en cuanto a los
secuestros de red son los días de Domingo.
secuestros de red son los días de Domingo.
¿Cuáles prefijos son los más secuestrados?
Para esta sección creamos la siguiente tabla de frecuencias.
Mostramos únicamente los bloques secuestrados 4 o más veces.
En la tabla anterior es muy llamativo el valor de la moda, corresponde al prefijo
80.249.208.0/21, curiosamente supera en más del doble la frecuencia inmediata
anterior. En otro orden de ideas, en lo personal esperábamos observar los prefijo
1.1.1.0/24 o 1.0.0.0/24 sin embargo los mismos no aparecen.
80.249.208.0/21, curiosamente supera en más del doble la frecuencia inmediata
anterior. En otro orden de ideas, en lo personal esperábamos observar los prefijo
1.1.1.0/24 o 1.0.0.0/24 sin embargo los mismos no aparecen.
Por otro lado es llamativo que el prefijo 2.2.2.0/24 que no posee ROA si se
encuentra en la lista, ¿se deberá a la magia de RPKI?
encuentra en la lista, ¿se deberá a la magia de RPKI?
¿Cuál máscara de red se utiliza más frecuentemente para secuestrar prefijos?
Luego de obtener los prefijos con mayor frecuencia de secuestro se nos ocurrió
identificar qué máscara/longitud de prefijo eran los más utilizados. Para obtener este
valor utilizamos toda la muestra. Aquí la respuesta tanto para v4 como para v6.
identificar qué máscara/longitud de prefijo eran los más utilizados. Para obtener este
valor utilizamos toda la muestra. Aquí la respuesta tanto para v4 como para v6.
En el mundo IPv4
En el mundo IPv6
Lo anterior indiscutiblemente me recordó un antiguo post llamado: “BGP: Filtrar
por tamaño de la red en BGP, he ahí el dilema” que se puede conseguir en
https://blog.acostasite.com/2017/03/bgp-filtrar-por-tamano-de-la-red-en-bgp.html. En ese documento se realiza una recomendación
para aprender cierto tamaño de prefijos en caso de no poder recibir la tabla
completa BGP.
por tamaño de la red en BGP, he ahí el dilema” que se puede conseguir en
https://blog.acostasite.com/2017/03/bgp-filtrar-por-tamano-de-la-red-en-bgp.html. En ese documento se realiza una recomendación
para aprender cierto tamaño de prefijos en caso de no poder recibir la tabla
completa BGP.
TOP 10 de países más afectados por secuestro de prefijos
La siguiente tabla muestra el código de país y la cantidad de veces que fue afectado
por eventos.
por eventos.
Se puede observar que en la región de LACNIC, Brasil es el país que sufre la
mayor cantidad de secuestros de prefijos (y segundo en el mundo). Por otro lado,
no se aprecia en la tabla pero para la región de LAC le seguirían Argentina con 80,
Colombia con 59 y Chile con 58, secuestros de red respectivamente.
mayor cantidad de secuestros de prefijos (y segundo en el mundo). Por otro lado,
no se aprecia en la tabla pero para la región de LAC le seguirían Argentina con 80,
Colombia con 59 y Chile con 58, secuestros de red respectivamente.
¿Y cuales son los países que realizan más secuestros de red?
La siguiente tabla muestra el código de país desde el cual se han realizado más
secuestros de rutas y la cantidad de eventos detectados.
secuestros de rutas y la cantidad de eventos detectados.
Una vez más observamos a nuestros amigos de Brasil en segundo lugar. Ahora bien,
si seguimos en la lista, en nuestra región tenemos a Argentina en el puesto 17 con 85,
Colombia en el 28 con 42 y Venezuela en el 38 con 25 secuestros.
si seguimos en la lista, en nuestra región tenemos a Argentina en el puesto 17 con 85,
Colombia en el 28 con 42 y Venezuela en el 38 con 25 secuestros.
¿Alguna curiosidad?
Revisando ASs que hayan realizado secuestros conseguimos el AS2147483647 el
cual es reservado, el mismo realizó un total de 36 secuestros entre el año 2016 y el
2018, siendo el último evento el día 2 de Junio del 2018.
cual es reservado, el mismo realizó un total de 36 secuestros entre el año 2016 y el
2018, siendo el último evento el día 2 de Junio del 2018.
¿Algunas sumas no te cuadran?
- Nuestras disculpas, en algunas pocas oportunidades no ha sido posible obtener
Conclusiones
- Se puede apreciar que el secuestro de redes es una realidad y ninguna región
- Existe una disminución marcada de secuestros por año, gran parte debido a la
uso de RPKI e IRR. Lastimosamente igualmente creemos que será sempiterno.
- La región de LACNIC no escapa de esta problemática y por ello se hace
- A pesar de que la fuente de datos pueda tener algún margen de error pensamos
Futuros pasos
- Identificar la duración de un secuestro
- Obtener más fuentes de información
- Conocer el margen de error de los datos mostrados (recordemos que los datos
Referencias:
Suscribirse a:
Entradas (Atom)
Server DNS recursivo detrás de NAT64. Explicando IPv6-only Capable Resolvers Utilising NAT64
Parece loco, pero no lo es: Server DNS recursivo detrás de NAT64. Explicando IPv6-only Capable Resolvers Utilising NAT64
