domingo, 28 de agosto de 2022
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
jueves, 14 de julio de 2022
Solución "Unable to parse package file " luego de apt
Problema:
Obtenemos un error después de ejecutar cualquier comando apt en Linux
Solución:
La solución es muy fácil, les comento que pasé muchas horas arreglándolo.
Solo tiene que eliminar el archivo mencionado en el error, en mi caso obtuve: "E: Unable to parse package file /var/lib/apt/extended_states (1)"
Acabo de borrar el archivo /var/lib/apt/extended_states
Ejemplo:
#sudo rm /var/lib/apt/extended_states
Eso es todo, suerte!
lunes, 20 de junio de 2022
Despliegue de IPv6 en la región LACNIC - Bar Chart Race IPv6 a Junio 2022
martes, 17 de mayo de 2022
Video: Retirada Implícita y Explícita de prefijos en BGP / BGP Explicit/Implicit Withdraw
martes, 8 de febrero de 2022
El Metaverso será posible gracias al IPv6
El Metaverso promete ser uno de los desarrollos tecnológicos que mayor impacto traerá en el futuro las formas de uso y consumo en Internet[1].
Aunque por ahora la promesa de Mark Zuckerberg sigue siendo un poco gaseosa y el uso práctico en la actualidad se reduce a la comunidad de los denominados “GAMERS”, el desarrollo, masificación y despliegue del denominado “Metaverso” será posible gracias a la tecnología que soporta el protocolo IPv6[1].
¿Por qué el IPV6 es tan importante para el Desarrollo del Metaverso?
Por: Gabriel E. Levy B. y Alejandro Acosta
www.galevy.com – blog.acostasite.com
En su casi medio siglo de vida los protocolos TCP/IP han servido para conectar a miles de millones de personas.
Desde la creación de Internet, han sido los estándares universales sobre los cuales se transmite la información por la red, haciendo posible que Internet funcione[3].
La sigla IP puede referirse a dos conceptos vinculados entre ellos; El primero es un protocolo (Internet Protocol – Protocolo de Internet en Español) y su principal función es el uso bidireccional (origen y destino) de transmisión de datos basado en la norma OSI (Open System Interconnection)[4].
La segunda posible referencia cuando se habla de IP, está vinculada a una asignación numérica de direcciones físicas conocida como Dirección IP, un identificativo lógico y jerárquico asignado a una interfaz de un dispositivo dentro de una red que utilice el protocolo de Internet (Internet Protocol – IP), la cual corresponde al nivel de red o nivel 3 del modelo de referencia OSI.
IPv4 hace referencia al Protocolo de Internet en su cuarta versión (en inglés, Internet Protocol version 4, IPv4), un estándar de interconexión de redes basados en Internet, y que fue implementado en 1983 para el funcionamiento de ARPANET y la posterior migración a Internet[5].
El IPv4 usa direcciones de 32 bits, equivalentes a 4.2 mil millones de bloques de numeración únicas, una cifra que, para la década de los años 80 parecía sencillamente inagotable, no obstante, y por el crecimiento enorme e inesperado de Internet, para el año 2011 pasó lo que nunca se creyó que fuera a ocurrir, todas las direcciones se agotaron[6].
IPv6 como solución al Cuello de botella
Para solucionar la falta de direcciones disponibles, conocido como “RECURSOS”, los grupos de ingeniería responsables de Internet, han recurrido a múltiples soluciones que van desde la creación de subredes privadas, de tal forma que con una misma dirección se puedan conectar múltiples usuarios, hasta la creación de un nuevo protocolo denominado IPv6 que promete ser la solución definitiva del problema y el cual fue lanzado oficialmente el 6 de junio de 2012[7]:
“Previendo el agotamiento de la dirección disponibles en IPv4 y como una solución de largo plazo, el organismo que se encarga de la estandarización de los protocolos de Internet (IETF, Internet Engineering Task Force), diseñó una nueva versión del Protocolo de Internet, concretamente la versión 6 (IPv6), con una casi inagotable disponibilidad, a partir de una nueva longitud de 128 bits, es decir alrededor 340 sextillones de direcciones”[8].
Es importante aclarar que la creación del protocolo IPv6, no implica una migración, es decir un cambio de un protocolo a otro como si fuera un proceso de remplazo, sino que se diseñó un mecanismo que permite por un tiempo la coexistencia articulada de ambos protocolos.
Para garantizar una transición transparente para los usuarios y que garantice un tiempo prudencial para que los fabricantes incorporen la nueva tecnología y los proveedores de Internet la implementen en sus propias redes, la organización encargada de la estandarización de los protocolos de Internet (IETF, Internet Engineering Task Force), diseñó junto con el mismo protocolo IPV6, una serie de mecanismos que se denominan de transición y coexistencia.
“Es como una balanza, en la que hoy en día el lado con el mayor peso representa el tráfico IPv4, pero poco a poco, gracias a esta coexistencia, conforme más contenidos y servicios estén disponibles con IPv6, el peso de la báscula irá hacia el otro lado, hasta que IPv6 sea predominante. Esto es lo que llamamos la transición”[9].
El diseño del protocolo IPv6 da preferencia a IPv6 frente a IPv4, si ambos están disponibles (IPv4 e IPv6). De ahí que se produzca ese desplazamiento del peso en “nuestra balanza”, de una forma natural, en función de múltiples factores, y sin que podamos determinar durante cuánto tiempo seguirá existiendo IPv4 en la Red y en qué proporciones. Posiblemente podamos pensar, intentando mirar en la bola de cristal, que IPv6 llegará a ser predominante en 3-4 años, y en ese mismo entorno de tiempo, IPv4 desaparecerá de Internet, al menos en muchas partes de ella” [10].
Sin IPv6 quizás no haya metaverso
Cómo lo analizamos en pasados artículos, los Metaversos o Metauniversos, son entornos donde los humanos interactúan social y económicamente como iconos, a través de un soporte lógico en un ciberespacio, como una metáfora amplificada del mundo real, pero sin las limitaciones físicas o económicas[11].
“Puedes pensar en el Metauniversos como una Internet encarnada.
En lugar de ver contenido, estás en él y te sientes presente con otras personas como si estuvieras en otros lugares teniendo diferentes experiencias que no podrías tener en una aplicación 2D o página web“. Mark Zuckerberg Ceo de Facebook[12].
El Metaverso necesariamente “corre” o se “Ejecuta” sobre Internet, que a su vez utiliza el IP o (Internet Protocol) para funcionar.
El Metaverso es un tipo de simulación que mediante “Avatares” permite a los usuarios tener conexiones mucho más inmersivas y realistas, desplegando un universo virtual que corre en línea, razón por la cual se hace necesario garantizar que el Metaverso sea Inmersivo, multisensorial, Interactivo, que corran en tiempo real, que permitan diferenciar de manera precisa a cada usuario, que despliegue herramientas gráficas simultáneas y complejas, entre muchos otros elementos, que simplemente sería imposible de garantizar sobre el Protocolo IPv4, puesto que ni existen suficientes “Recursos IP” para cada conexión, ni es posible garantizar que con tecnologías como el NAT pueda correr adecuadamente.
Los elementos claves:
- El IPV6 es el único protocolo puede garantizar la cantidad suficiente de “Recursos IP” para soportar el Metaverso.
- El IPV6 evita el mecanismo de NAT en las redes que complicaría tecnológicamente el despliegue del Metaverso.
- El RTT/Delay de los enlaces de IPv6 es mucho menor que el de IPv4, permitiendo que las representaciones gráficas de los “avatares”, incluyendo los hologramas puedan desplegarse de forma sincrónica.
- Teniendo en cuenta la alta cantidad de datos que implica el despliegue del Metaverso, es necesario garantizar la menor perdida de datos posible, razón por la cual el IPv6 se convierte en la mejor opción pues la evidencia muestra que la pérdida de datos es un 20% menor que la de IPv4[13].
El Rol de los Pequeños ISP
Teniendo en cuenta que los pequeños ISP son los grandes responsables de la conectividad de millones de personas en las regiones más apartadas de todo Latinoamérica y como lo hemos analizado anteriormente, son los grandes responsables de la disminución de la Brecha Digital[14], es muy importante que estos operadores aceleren el proceso de migración hacia IPV6, no solamente para ser más competitivos frente a sus grandes competidores, sino para que puedan garantizarle a sus usuarios que tecnologías como El Metaverso funcionarán en sus dispositivos sin mayores traumatismos tecnológicos.
En Conclusión, si bien aún es incierto el alcance real que tendrá El Metaverso, su despliegue, implementación y masificación será posible gracias al Protocolo IPv6, una tecnología que ha dado solución a la disponibilidad de los recursos IP, evitando el engorroso procedimiento de la traducción de NAT, mejorando los tiempos de respuesta, disminuyendo el RTT o Delay y evitando la perdida de muchos paquetes, al tiempo que facilitará la simultaneidad de usuarios.
Todo lo anterior nos permite afirmar que El Metaverso sin IPv6, no sería posible.
Descargo de Responsabilidades: Este artículo corresponde a una revisión y análisis en el contexto de la transformación digital en la sociedad de la información, y está debidamente soportado en fuentes académicas y/o periodísticas confiables y verificadas, las cuales han sido demarcadas y publicadas.
La información que contienen este artículo periodístico y de opinión, no necesariamente representa la postura de Andinalink, o las entidades con las que desarrolla sus relaciones comerciales.
[1] Artículo Andinalink: Metaversos y el Internet del Futuro
[2] Artículo Andinalink: Metaversos: Expactativas VS Realidad
[3] En el artículo: El agotamiento del protocolo IP explicamos las características del protocolo TCP: El Agotamiento del Protocolo IP
[4] Documento estándar de referencia sobre el Modelo de conectividad OSI
[5] En el artículo: ¿Fue creada Arpanet para soportar una guerra nuclear?, se detalla las características e historia de Arpanet.:
[6] Documento de Lacnic sobre las fases del agotamiento de IPV4
[7] Documento de IETF sobre el lanzamiento oficial de IPV6 en su sexto aniversario
[8] Guía de referencia de Transición de IPV6 de Mintic Colombia
[9] Guía de referencia de Transición de IPV6 de Mintic Colombia
[10] Guía de referencia de Transición de IPV6 de Mintic Colombia
[11] Artículo Andinalink sobre los Metaversos
[12] MARK IN THE METAVERSE: Facebook’s CEO on why the social network is becoming ‘a metaverse company: The Verge Podcast
[13] Análisis de Alejandro Acosta de LACNIC, sobre el impacto del IPV6 en sistemas táctiles.
[14] Artículo Andinalink: Los Wisp disminuyen la brecha digital
sábado, 1 de enero de 2022
Microcuento de navidad de IPv4 e IPv6
BGP Stream: un año de análisis sobre incidentes BGP
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 prim...
