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/

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.

Nro de Servidores DNSs estudiados

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.

Nro de Servidores IPv6 DNSs estudiados

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:

Ranking DNSSEC por pais

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

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

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/



martes, 17 de mayo de 2022

Video: Retirada Implícita y Explícita de prefijos en BGP / BGP Explicit/Implicit Withdraw

En el video se explica con detalle los conceptos de Retirada Implícita y Retirada Explicita de prefijos en BGP. Se realiza un Demo con 5 enrutadores utilizando un prefijo IPv6. Finaliza con capturas de wireshark de los mensajes UPDATE.

Elder Law Attorney - Elder Law Lawyer Evergreen Elder Law Our goal is to help you put a flexible, thoughtful plan in place that protects as much of your estate as possible. We know you’ve worked hard to build up your estate and understand how hard it is to just let it go to pay for long-term care.
서민통합지원센터

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

Transcurre el año 2043, en un pequeño pueblo en Netland, justo antes de navidad, IPv6 se encuentra sentado en un pequeño microchip dentro de un router; como si fuese una chimenea sentía el calor de las compuertas lógicas y justo antes de ser inyectado en la red WiFi percibe una soledad y vienen muchos recuerdos, una imagen que ya hace mucho no se podría recuperar del caché del equipo, viene a su memoria un viejo compañero de guerra, un señor llamado IPv4 que casi nunca aparece en estos días. Lo primero que viene a su memoria eran las competencias que existían 20 años atrás, cuando su dueño les pedía hacer algo salían juntos lo más rápido con el objetivo de llegar primeros y darle respuesta lo más rápido posible. Siempre fue una carrera muy cerrada y el pronóstico del ganador era siempre reservado. Luego recuerda con dolor aquellos sufrimientos por los que pasaba IPv4 antes de llegar a su destino, era literalmente una mutación lo que ocurría, IPv6 nunca lo entendió pero sabe que no fueron momentos agradables, IPv4 a veces incluso ganaba la carrera pero el dueño no quedaba contento y no recibía su premio. Un recuerdo nada satisfactorio era la pérdida de algún compañero, sobre todo al comienzo de la misma, muy frecuentemente IPv4 sencillamente desaparecía en esos primeros 100 metros. Existía un recuerdo que siempre le sacaba una sonrisa a IPv6, rememoraba aquellos primeros momentos, cuando era aún un pequeño bebé en sus primeros años y no tenía buenos resultados en sus recorridos, comúnmente perdía. Hoy en día se llena de orgullo pensando que es un ganador que luchó innumerables batallas ante un gran guerrero. Nanosegundos antes sentir el viento dentro de la red WiFi, IPv6 toma ánimo, a pesar de que ya es un ganador no baja la guardia, lucha sus batallas y como deseo de año nuevo pide cosas sencillas: a) que no existan congestión de redes, b) adiós a las colisiones, c) que no haya pérdida de paquetes y que todo el planeta tenga Internet. Feliz navidad 2021 y feliz año 2022. Alejandro Acosta,

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

  Despliegue de DNSSEC en la región - Estadística y mediciones   dnssec   mediciones Por: Hugo Salgado (@huguei) / Dario Gomez (@daro_ua) / ...