NAT Meter: un poco de historia
06/07/2021
Por Alejandro Acosta, Coordinador de I+D en LACNIC y Agustín Formoso, Colaborador
Desde hace algunos años que desde LACNIC Labs corremos un experimento para estimar la adopción de NAT en la región LAC. En el último año el mecanismo por el cual medíamos NAT ha quedado sin soporte por las diferentes plataformas, y amenaza la viabilidad de la medición. En este artículo les mostramos qué hemos podido medir hasta ahora y algunos posibles siguientes pasos.
¿Qué es NAT, y por qué medirlo?
El término NAT proviene de la sigla del inglés Network Address Translation – sería traducido al español a algo como traducción de dirección de red. Es un mecanismo que permite, entre dos redes, traducir direcciones IP entre una y otra. La tecnología de NAT se puede implementar en diferentes formas, no es el objetivo de este artículo explorarlas, pero sí es importante saber que la implementación de NAT 4-4 es un factor importante a la hora de evaluar los factores detrás de la adopción de IPv6.
A grandes razgos, el uso de NAT 4-4 nos permite reciclar un mismo bloque de direcciones IPv4 entre un grupo cada vez más grande de dispositivos. Si bien a primera vista podría parecer que el uso de NAT 4-4 es conveniente desde un punto de vista estratégico, termina siendo una mala opción si se lo compara con una estrategia a largo plazo como lo es implementar IPv6 en la red (y por ende contar con un espacio de numeración más que suficiente).
¿Cómo medirlo?
El mecanismo que usamos en LACNIC Labs es relativamente simple, consiste en disparar solicitudes WebRTC desde un script en JavaScript hacia determinados endpoints que tienen algunas propiedades específicas. Estos endpoints son tres, de los cuales el primero es el propio cliente (localhost), y los otros dos son servidores STUN operados por LACNIC (uno IPv4-only y uno IPv6-only). Lo importante de las consultas WebRTC es que brindan información de red acerca del cliente, en particular las direcciones IP que tiene. En el mundo de las aplicaciones web esta información es necesaria para que las aplicaciones basadas en WebRTC puedan establecer una sesión entre peers; nuestro script simplemente usa esta funcionalidad para descubrir esas direcciones. Una nota importante es que estas consultas WebRTC son diferentes de un servicio típico de descubrimiento de direcciones (como what-is-my-ip), el mecanismo a través de WebRTC nos brinda la información de las direcciones que están siendo utilizadas detrás de “cajas intermedias” (como NATs), situación en la cual los servicios típicos fallan.
El diagrama a continuación explica el mecanismo detrás del experimento, de principio a fin. Los endpoint mencionados anteriormente son consultados en el paso 2. Analicemos un poco más qué sucede dentro de ese paso:
2.a – Se establece una sesión WebRTC RTCPeerConnection entre el navegador y él mismo. Se obtiene información acerca de las direcciones IP utilizadas por el navegador.
2.b – Se hace lo mismo entre el navegador y los servidores STUN operados por LACNIC.
2.c – Si hay alguna diferencia entre lo que perciben los servidores remotos (2.b) y lo que percibe el navegador acerca de él mismo (2.a), entonces se marca el resultado con un flag. Este flag es nuestra “señal” indicando si el cliente se encuentra o no detrás de NAT.
Resultados
Mirando en retrospectiva, los resultados se encuentran alineados con nuestras expectativas: hay un alto uso de NAT ne la región. Esto no debería ser una sorpresa para nadie.
A continuación se muestra una línea del tiempo con el porcentaje de mediciones que tuvieron flag de NAT, agrupados por día (burbujas celestes) y en una ventana móvil de los últimos 30 días (linea azul):1 dia30 díasSeptember2018November2018January 2019March 2019May 2019July 2019September2019November2019January 2020050100
Para ese período de tiempo la media es de 86%, donde hay intervalos mayores a 95% para la ventana de 30 días.
Medir NAT desde un navegador se hace difícil
Pero como dice el dicho, “there ain’t no such thing as a free lunch”, que en castellano se traduciría a “no hay tal cosa como un almuerzo gratis”, o también “nada es gratis”. La conveniencia de correr experimentos desde un navegador trae por contrapartida depender del navegador donde uno corre el experimento. Y los navegadores son plataformas vivas, que sufren cambios cada mes, muchas veces sin consentimiento de usuarios, desarrolladores, u operadores de los diferentes servicios de infraestructura: la industria acompaña los cambios impuestos por la plataforma, o cambia de plataforma. Un ejemplo es el tráfico que se generó hacia los root servers a partir de un feature dentro de Chromium (proyecto base de varios navegadores populares), pueden leer más en este post en el blog de APNIC (en inglés).
El market share que percibimos de Google Chrome es alto: más de un 70% de los experimentos que corremos se estan ejecutando dentro de Chrome. Un cambio dentro de las políticas de Chrome puede tener un gran impacto en el experimento. Y de hecho ese cambio de políticas llegó en Chrome versión 78. En el gráfico siguiente comparamos el release de sucesivas versiones de Chrome con los resultados exitosos del experimento. Nótese que el market share, o adopción de una versión de Chrome comienza a bajar al mismo tiempo que la sigueinte versión comienza a subir, naturalmente ya que un navegador se actualiza y comienza a reportarse con su nueva versión. Al momento del release de Chrome v78 la cantidad de experimentos exitosos baja a la mitad, y al momento del release de v80 pasa a practicamente 0.Experimentos exitososv76v77v78v79v80v81November2019December2019January 2020February 2020March 2020April 2020May 20207141816161825050100
¿Qué sucedió en esos releases? El mecanismo por el cual obtenemos las direcciones IP del navegador fue catalogado como un exceso de privilegios para las aplicaciones que corren dentro de navegadores, y en agosto 2019 los vendors de navegadores comenzaron a trabajar sobre ello. En agosto 2019 ya existía un timeline para eliminar esos provilegios a las aplicaciones que corren Javascript, y para setiembre ya se prevía que el update iría a salir en la versión 78.El Internet-Draft Using Multicast DNS to protect privacy when exposing ICE candidates describe el problema:
WebRTC applications collect ICE candidates as part of the process of
creating peer-to-peer connections. To maximize the probability of a
direct peer-to-peer connection, client private IP addresses are
included in this candidate collection. However, disclosure of these
addresses has privacy implications. This document describes a way to
share local IP addresses with other clients while preserving client
privacy. This is achieved by concealing IP addresses with
dynamically generated Multicast DNS (mDNS) names.
Básicamente el cambio propuesto por ese draft es el siguiente: en vez de exponer mi dirección IP, se expondrá un nombre especial que representará a mi host dentro de la red. Este nombre especial es un UUID seguido de la zona .local. Por ejemplo, mi dirección de red 192.168.1.13, se expondrá bajo el nombre 2c0d14bb-4c17-46ac-a6fc-0bbcf30af0e5.local. A los efectos de nuestro experimento de detección de NAT este es un cambio de altísimo impacto!
También se puede leer más en detalle en el RFC8828, donde indica que el mayor problema de este mecanismo es en el caso de usuarios que, estando detrás de VPNs, sus direcciones de origen se verían expuestas. Esto iría completamente en contra del propio uso de una VPN para proveer de anonimidad a un usuario y es considerado una vulerabilidad de privacidad.
Corriendo el experimento de forma manual
Algunos navegadores le permiten al usuario deshabilitar la configuración de mDNS y permitir a las aplicaciones acceder a las direcciones IP utilizadas por el navegador. En el caso de Chrome existe un flag llamado “Anonymize local IPs exposed by WebRTC”, y se puede acceder visitando las configuraciones en chrome://flags/#enable-webrtc-hide-local-ips-with-mdns.
También se abrió la posibilidad a que el usuario permita el acceso a sus direcciones IP para aquellas aplicaciones que solicitan audio o video. Por ejemplo, una aplicación que se le permite el uso de micrófono o cámara también tendrá acceso a las direcciones IP del navegador. Si bien esto parece ser una solución a nuestro problema, no lo es, ya que deberíamos solicitar consentimiento de audio o video en sitios que realmente no lo necesitan (ni siquiera nuestro experimento necesita utilizar esas funcionalidades). Lo adecuado sería solicitar el acceso únicamente a direcciones IP del navegador, ni más ni menos.
La otra cara de la moneda
A los efectos del experimento este cambio fue un obstáculo que no pudimos sortear, y comprometió el mecanismo por el cual detectábamos NAT. Sin embargo, el lado positivo de esta funcionalidad es que las direcciones IP de los usuarios ya no están al alcance de cualquier aplicación web, haciendo más difícil que se haga fingerprinting de dispositivos.
Una nota relevante es que las direcciones IP recolectadas se encuentran únicamente alojadas en servicios de LACNIC, y se anonimizan antes de ser expuestas en los datos públicos del experimento.
El futuro
El futuro de este mecanismo es incierto. Por el momento no es posible medir NAT de la forma que lo hemos estado haciendo; existe la posibilidad de medirlo si se le solicita al usuario el uso de audio o video, pero es un mecanismo muy molesto para el usuario y además solicita recursos que el experimento no necesita.