Explicación del cifrado de DNS

El sistema de nombres de dominio (DNS) es la libreta de direcciones de Internet. Cuando visitas cloudflare.com o cualquier otro sitio, tu navegador le solicitará a un resolutor de DNS la dirección IP para encontrar el sitio web. Lamentablemente, estas consultas y respuestas de DNS suelen estar desprotegidas. El cifrado de DNS mejoraría la privacidad y la seguridad del usuario. En esta publicación, analizaremos dos mecanismos para el cifrado de DNS: DNS mediante TLS (DoT) y DNS mediante HTTPS (DoH), y explicaremos cómo funcionan.

Las aplicaciones que desean resolver un nombre de dominio en una dirección IP suelen usar DNS. Esto, por lo general, no lo hace de manera explícita el programador que escribió la aplicación. El programador escribe algo como acceder a ("https://example.com/news") y espera que una biblioteca de software se encargue de la traducción de “example.com” a una dirección IP.

En segundo plano, la biblioteca de software debe descubrir el resolutor de DNS recurrente externo, conectarse a este y leer el protocolo de DNS (consulta la figura siguiente) para resolver el nombre solicitado por la aplicación. La elección del resolutor de DNS externo y si se proporciona privacidad y seguridad es ajena al control de la aplicación. Depende de la biblioteca de software que se usa y de las políticas del sistema operativo del dispositivo que ejecuta el software.

Descripción de la consulta y la respuesta de DNS

El sistema operativo, por lo general, aprende la dirección del resolutor de la red local mediante el protocolo de configuración dinámica de host (DHCP). En las redes domésticas y móviles, por lo general, se suele usar el resolutor del proveedor del servicios de Internet (ISP). En las redes corporativas, el resolutor seleccionado suele ser controlado por el administrador de red. Si lo desean, los usuarios con control de sus dispositivos pueden anular el resolutor con una dirección específica, como la dirección de un resolutor público como 8.8.8.8 de Google o 1.1.1.1 de Cloudflare, pero la mayoría de los usuarios probablemente no se molesten en cambiarlo cuando se conectan a un punto de acceso de wifi público en una cafetería o en un aeropuerto.

La elección del resolutor externo afecta de manera directa la experiencia del usuario final. La mayoría de los usuarios no cambia la configuración del resolutor y probablemente use el resolutor de DNS de su proveedor de red. La propiedad visible más obvia es la velocidad y precisión de la resolución de nombres. Es posible que las características que mejoran la privacidad o la seguridad no sean visibles de inmediato, pero ayudarán a evitar que otros generen perfiles o interfieran con tu actividad de navegación. Esto resulta especialmente importante en las redes wifi públicas donde cualquier persona que se encuentre físicamente próxima puede capturar y descifrar el tráfico de la red inalámbrica.

Desde que se creó el DNS en 1987, ha estado durante mucho tiempo sin cifrar. Cualquiera entre tu dispositivo y el resolutor puede espiar, o incluso modificar, tus consultas y respuestas de DNS. Esto incluye a cualquier persona de tu red wifi local, tu proveedor de servicios de Internet (ISP) y los proveedores de tránsito. Esto puede afectar tu privacidad, ya que puede revelar los nombres de dominio que estás visitando.

¿Qué pueden ver las demás personas? Bien, considera esta captura de paquetes de red tomada de una computadora portátil conectada a una red doméstica:

Se pueden plantear las siguientes observaciones:

• El puerto de origen UDP es 53, que es el número de puerto estándar para DNS sin cifrar. Por lo tanto, es probable que la carga útil UDP sea una respuesta de DNS.

• Esto sugiere que la dirección IP de origen 192.168.2.254 es un resolutor de DNS, mientras que la IP de destino 192.168.2.14 es el cliente DNS.

• La carga útil UDP se podría analizar como una respuesta de DNS, y revela que el usuario estaba tratando de visitar twitter.com.

• Si se establecen conexiones futuras a 104.244.42.129 o 104.244.42.1, lo más probable es que sea tráfico que se dirija a “twitter.com”.

• Si hay tráfico HTTPS con cifrado adicional a esta IP, realizado correctamente por más consultas de DNS, esto podría indicar que un navegador web cargó recursos adicionales desde esa página. Eso podría revelar las páginas que un usuario estaba mirando durante su visita a twitter.com.

Como los mensajes de DNS no están protegidos, es posible que haya otros ataques:

• Las consultas se pueden dirigir a un resolutor que lleve a cabo un secuestro de DNS. Por ejemplo, en el Reino Unido, Virgin Media y BT devuelven una respuesta falsa para dominios que no existen, y redireccionan a los usuarios a una página de búsqueda. Esta redirección es posible porque la computadorar/el teléfono confía ciegamente en el resolutor de DNS que el enrutador de puerta de enlace proporcionado por el ISP anunció mediante el protocolo de configuración dinámica de host (DHCP).

• Los firewalls pueden interceptar, bloquear o modificar con facilidad cualquier tráfico de DNS sin cifrar solo en función del número de puerto. Vale la pena señalar que la inspección de texto sin formato no es una solución mágica para lograr la visibilidad, ya que el resolutor de DNS se puede omitir.

El cifrado de DNS hace que sea más difícil espiar tus mensajes de DNS, o que sufran adulteraciones mientras están en tránsito. Al igual que la web evolucionó del HTTP sin cifrado al HTTPS cifrado, ahora existen actualizaciones para protocolo de DNS que cifran el DNS. El cifrado de la web posibilitó el crecimiento de las comunicaciones y el comercio privados y seguros. El cifrado de DNS mejorará aún más la privacidad del usuario.

Existen dos mecanismos estandarizados para garantizar el traslado de DNS entre tú y el resolutor, DNS mediante TLS (2016) y consultas de DNS mediante HTTPS (2018). Ambos se basan en la seguridad de la capa de transporte (TLS) que también se utiliza para proteger la comunicación entre tú y un sitio web mediante HTTPS. En TLS, el servidor (ya sea un servidor web o un resolutor de DNS) se autentica de manera automática al cliente (tu dispositivo) mediante un certificado. Esto garantiza que ninguna otra parte pueda hacerse pasar por el servidor (el resolutor).

Con DNS mediante TLS (DoT), el mensaje DNS original se integra directamente en el canal TLS seguro. Desde el exterior, uno no puede conocer el nombre que se consultaba ni modificarlo. La solicitud del cliente podrá descifrar TLS, y se ve de la siguiente manera:

En el seguimiento de paquetes para DNS sin cifrar, está claro que un cliente puede enviar directamente una solicitud de DNS, y que a esta le sigue una respuesta de DNS del resolutor. Sin embargo, en el caso de DoT cifrado, algunos mensajes del protocolo de enlace TLS se intercambian antes de enviar mensajes DNS cifrados:

• El cliente envía un mensaje Client Hello, anunciando su compatibilidad con TLS.

• El servidor responde con un mensaje Server Hello, aceptando los parámetros TLS que se utilizarán para proteger la conexión. El mensaje del certificado contiene la identidad del servidor, mientras que el mensaje de verificación de certificado contendrá una firma digital que el cliente puede verificar mediante el certificado del servidor. Por lo general, el cliente controla este certificado con su lista local de entidades de certificación de confianza, pero la especificación DoT menciona mecanismos de confianza alternativos como la asignación de claves públicas.

• Una vez que finaliza el protocolo de enlace TLS, el cliente y el servidor pueden comenzar a intercambiar mensajes cifrados.

• Si bien la imagen anterior contiene una consulta y una respuesta de DNS, en la práctica la conexión TLS segura permanecerá abierta y se reutilizará para futuras consultas de DNS.

La protección de protocolos no cifrados mediante la imposición de TLS en la parte superior de un puerto nuevo se ha hecho antes:

• Tráfico web: HTTP (tcp/80) -> HTTPS (tcp/443)

• Envío de correo electrónico: SMTP (tcp/25) -> SMTPS (tcp/465)

• Recepción de correo electrónico: IMAP (tcp/143) -> IMAPS (tcp/993)

• Ahora: DNS (tcp/53 o udp/53) -> DoT (tcp/853)

Un problema con la introducción de un puerto nuevo es que los firewalls actuales pueden bloquearlo. Ya sea porque aplican una lista blanca donde los nuevos servicios tienen que habilitarse de manera explícita, o una lista de bloqueo donde un administrador de red bloquea un servicio de manera explícita. Si es menos probable que esté disponible la opción segura (DoT) que la opción insegura, los usuarios y las aplicaciones podrían verse tentados a hacer una reversión al DNS sin cifrar. Esto posteriormente podría permitir que los atacantes fuercen a los usuarios a usar una versión insegura.

Estos ataques de reversión no son algo teórico. Previamente se ha utilizado la eliminación de SSL para generar cambios de los sitios web HTTPS a HTTP, lo que permite a los atacantes robar contraseñas o secuestrar cuentas.

Se diseñó otro enfoque, las consultas DNS mediante HTTPS (DoH), para admitir dos ejemplos de uso principales:

• Evitar el problema mencionado anteriormente donde los dispositivos en la ruta de acceso interfieren con el DNS. Esto incluye el problema de bloqueo de puertos anterior.

• Habilitar las aplicaciones web para acceder a DNS a través de las API del navegador existentes.El DoH es esencialmente el HTTPS, el mismo estándar cifrado que utiliza la web, y reutiliza el mismo número de puerto (tcp/443). Los navegadores web ya han dejado de usar los HTTP no seguros y ahora usan HTTPS. Esto hace que HTTPS sea una excelente opción para transportar mensajes de DNS de forma segura. Puedes encontrar aquí un ejemplo de esta solicitud de DoH.

DoH: Consulta y respuesta de DNS transportadas a través de una secuencia de HTTPS segura

A algunos usuarios les preocupa que el uso de HTTPS pueda comprometer la privacidad debido al uso potencial de cookies con fines de seguimiento. Los diseñadores del protocolo DoH consideraron varios aspectos de privacidad y desaconsejaron de manera explícita el uso de cookies HTTP para evitar el seguimiento, recomendación que es muy respetada. La reanudación de la sesión TLS mejora el rendimiento del protocolo de enlace TLS 1.2, pero se podría llegar a usar para correlacionar conexiones TLS. Afortunadamente, el uso de TLS 1.3 evita la necesidad de reanudar la sesión TLS, ya que reduce de manera predeterminada la cantidad de recorridos de ida y vuelta, lo que permite abordar de manera eficaz la preocupación relacionada con la privacidad.

El uso de HTTPS significa que las mejoras del protocolo HTTP también pueden resultar beneficiosas para DoH. Por ejemplo, el protocolo HTTP/3 en desarrollo, construido sobre QUIC, podría ofrecer mejoras adicionales en el rendimiento ante la pérdida de paquetes por la falta de bloqueo en el encabezado de línea. Esto significa que se podrían enviar varias consultas de DNS de manera simultánea por el canal seguro sin bloquearse entre sí cuando se pierde un paquete.

También hay un borrador para DNS a través de QUIC (DNS/QUIC), y es similar a DoT, pero sin el problema de bloqueo en el encabezado de línea debido al uso de QUIC. Sin embargo, tanto HTTP/3 como DNS/QUIC requieren un puerto UDP accesible. En teoría, ambos podrían hacer una reversión a DoH mediante HTTP/2 y DoT respectivamente.

Como DoT y DoH son relativamente nuevos, todavía no se implementan de manera universal. Por el lado del servidor, los principales resolutores públicos, como 1.1.1.1 de Cloudflare, y DNS de Google los admiten. Sin embargo, muchos resolutores de ISP aún no los admiten. Puedes encontrar una breve lista de resolutores públicos que admiten DoH en Orígenes de servidor DNS, y otra lista de resolutores públicos que admiten DoT y DoH en Resolutores públicos de privacidad de DNS

Existen dos métodos para habilitar el DoT o el DoH en los dispositivos del usuario final:

• Permite mayor compatibilidad con las aplicaciones, al omitir el servicio de resolución del sistema operativo.

• Permite mayor compatibilidad con el sistema operativo, al brindar soporte a las aplicaciones de manera transparente.

Por lo general, existen tres modos de configuración para el DoT o el DoH del lado del cliente:

• Desactivado: DNS no se cifrará.

• Modo oportunista: trata de utilizar un transporte seguro para DNS, pero haz una reversión a DNS sin cifrar si el anterior no está disponible. Este modo es vulnerable a los ataques que generan cambios a versiones anteriores donde un atacante puede forzar a un dispositivo a usar DNS sin cifrar. Su objetivo es ofrecer privacidad cuando no hay atacantes activos en la ruta.

• Modo estricto: intenta usar DNS mediante transporte seguro. Si no está disponible, se genera una falla y el usuario visualiza un mensaje de error.

The current state for system-wide configuration of DNS over a secure transport:

• Android 9: supports DoT through its “Private DNS” feature. Modes:
  • Opportunistic mode (“Automatic”) is used by default. The resolver from network settings (typically DHCP) will be used.
  • Strict mode can be configured by setting an explicit hostname. No IP address is allowed, the hostname is resolved using the default resolver and is also used for validating the certificate. (Relevant source code)
• iOS and Android users can also install the 1.1.1.1 app to enable either DoH or DoT support in strict mode. Internally it uses the VPN programming interfaces to enable interception of unencrypted DNS traffic before it is forwarded over a secure channel.
• Linux with systemd-resolved from systemd 239: DoT through the DNSOverTLS option.
  • Off is the default.
  • Opportunistic mode can be configured, but no certificate validation is performed.
  • Strict mode is available since systemd 243. Any certificate signed by a trusted certificate authority is accepted. However, there is no hostname validation with the GnuTLS backend while the OpenSSL backend expects an IP address.
  • In any case, no Server Name Indication (SNI) is sent. The certificate name is not validated, making a on-path attacker rather trivial.
• Linux, macOS, and Windows can use a DoH client in strict mode. The cloudflared proxy-dns command uses the Cloudflare DNS resolver by default, but users can override it through the proxy-dns-upstream option.

Estado actual de la configuración de DNS para todo el sistema mediante transporte seguro:

• Android 9: es compatible con DoT mediante su función “Private DNS” (DNS privado). Modos:

• El modo oportunista (“Automático”) se utiliza de forma predeterminada. Se utilizará el resolutor de las configuraciones de red (habitualmente DHCP).

• El modo estricto se puede configurar al establecer un nombre de host explícito. No se permite ninguna dirección IP, el nombre de host se resuelve mediante el resolutor predeterminado y también se utiliza para validar el certificado. (Código fuente relevante)

• Los usuarios de iOS y Android también pueden instalar la aplicación 1.1.1.1 para habilitar la compatibilidad con DoH o DoT en modo estricto. Internamente, utiliza las interfaces de programación VPN para habilitar la interceptación del tráfico DNS sin cifrar antes de que se reenvíe a través de un canal seguro.

• Linux con systemd-resolved de systemd 239: DoT mediante la opción DNS mediante TLS.

• El valor por defecto es desactivado.

• Se puede configurar el modo oportunista, pero no se hace una validación de certificado.

• El modo estricto está disponible desde systemd 243. Se acepta cualquier certificado firmado por una autoridad de certificación de confianza. Sin embargo, no hay validación de nombre de host con el backend GnuTLS mientras el backend OpenSSL espera una dirección IP.

• En cualquier caso, no se envía ninguna indicación de nombre de servidor (SNI). El nombre del certificado no se valida, lo que hace que un ataque de intermediario sea bastante insignificante.

• Linux, macOS y Windows pueden usar un cliente DoH en modo estricto. El comando proxy-dns de cloudflare utiliza el resolutor DNS de Cloudflare de forma predeterminada, pero los usuarios pueden invalidarlo a través de la opción proxy de dns ascendente.

Los navegadores web admiten DoH en lugar de DoT:

• Firefox 62 es compatible con DoH y ofrece varias configuraciones de resolutores recursivos de confianza (TRR). De forma predeterminada, DoH está desactivado, pero Mozilla está ejecutando un experimento para habilitar DoH para algunos usuarios en EE. UU. Este experimento actualmente utiliza el resolutor 1.1.1.1 de Cloudflare, ya que somos el único proveedor que actualmente satisface la política estricta de resolutores que requiere Mozilla. Dado que muchos resolutores de DNS aún no admiten un transporte de DNS cifrado, el método de Mozilla garantizará que más usuarios estén protegidos mediante DoH.

• Cuando se habilite a través del experimento, o a través de la opción “Enable DNS over HTTPS” (Habilitar DNS mediante HTTPS) en Network Settings (Configuraciones de red), Firefox usará el modo oportunista (network.trr.mode=2 at about:config).

• El modo estricto se puede habilitar con network.trr.mode=3, pero requiere que se especifique una dirección IP explícita de resolutor (por ejemplo, network.trr.bootstrapAddress=1.1.1.1).

• Aunque Firefox ignora el resolutor predeterminado del sistema, se puede configurar con resolutores alternativos. Además, las implementaciones a nivel de empresa que usan un resolutor que no admite DoH tienen la opción de deshabilitar DoH.

• Chrome 78 habilita DoH en el modo oportunista si la dirección del resolutor del sistema coincide con uno de losproveedores de DoH con codificación fija (cambio de código fuente). Este experimento está habilitado para todas las plataformas, salvo para Linux e iOS, y excluye de forma predeterminada las implementaciones de las empresas.

• Opera 65 agrega una opción para habilitar DoH mediante el resolutor 1.1.1.1 de Cloudflare. Esta función está desactivada de forma predeterminada. Una vez que se activa, utiliza el modo oportunista: si 1.1.1.1:443 (sin SNI) es accesible, se utilizará. De lo contrario, recurre al resolutor predeterminado de una versión anterior, sin cifrar.

La página deDNS mediante HTTPS del proyecto curl incluye una lista completa de proveedores de DoH e implementaciones adicionales.

Como alternativa al cifrado de toda la ruta de red entre el dispositivo y el resolutor DNS externo, se puede tomar un punto intermedio: utilizar DNS sin cifrar entre los dispositivos y la puerta de enlace de la red local, pero cifrar todo el tráfico DNS entre el enrutador de la puerta de enlace y el resolutor de DNS externo. Una red por cable o inalámbrica segura protegería todos los dispositivos en la red local contra un proveedor de Internet (ISP) que realiza actividades de espionaje u otros adversarios en Internet. Como los puntos de acceso de wifi públicos no se consideran seguros, este método no sería seguro en redes de wifi abiertas. Incluso si está protegido por contraseña con WPA2-PSK, otros aún podrán espiar y modificar un DNS sin cifrar.

En las secciones anteriores se describen los transportes de DNS seguros, DoH y DoT. Estos solo asegurarán que tu cliente reciba la respuesta sin interferencias del resolutor de DNS. Sin embargo, no protege al cliente si el resolutor devuelve la respuesta incorrecta (a través del secuestro de DNS o ataques de envenenamiento de caché de DNS). La respuesta “verdadera” la determina el propietario de un dominio o zona según lo informado por el servidor de nombres autorizado. DNSSEC permite a los clientes verificar la integridad de la respuesta DNS devuelta y detectar cualquier alteración no autorizada en la ruta de acceso entre el cliente y el servidor de nombres autorizado.

Sin embargo, la implementación de DNSSEC se ve obstaculizada por dispositivos intermedios de seguridad que de manera incorrecta reenvían mensajes DNS, e incluso si la información está disponible, es posible que los resolutores auxiliares utilizados por las aplicaciones ni siquiera validen los resultados. Un informe de 2016 detectó que solo el 26 % de los usuarios usan resolutores de validación de DNSSEC.

DoH y DoT protegen el transporte entre el cliente y el resolutor público. Es posible que el resolutor público tenga que ponerse en contacto con servidores de nombres autorizados adicionales para resolver un nombre. Tradicionalmente, la ruta de acceso entre los resolutores y el servidor de nombres autorizado utiliza DNS sin cifrar. Para proteger estos mensajes de DNS, también hicimos un experimento con Facebook, mediante el uso de DoT entre 1.1.1.1 y los servidores de nombres autorizados de Facebook. Al configurar un canal seguro mediante TLS aumenta la latencia, se puede amortizar después de muchas consultas.

El cifrado de transporte garantiza que los resultados y metadatos del resolutor estén protegidos. Por ejemplo, la información de la subred de cliente EDNS (ECS) que se incluye con las consultas DNS podría revelar la dirección original del cliente que inició la consulta de DNS. Ocultar esa información en la ruta de acceso mejora la privacidad. También evitará que los dispositivos intermedios de seguridad causen inconvenientes en DNSSEC debido a problemas en el reenvío de DNS.

El cifrado de DNS puede traer inconvenientes a los individuos o las organizaciones que dependen del monitoreo o la modificación del tráfico de DNS. Los dispositivos de seguridad que dependen del monitoreo pasivo supervisan todo el tráfico de red entrante y saliente en una máquina o en el perímetro de una red. En función de las consultas de DNS no cifradas, podrían, por ejemplo, identificar las máquinas que están infectadas con malware. Si la consulta de DNS está cifrada, las soluciones de monitoreo pasivo no podrán supervisar los nombres de dominio.

Algunas partes esperan que los resolutores de DNS apliquen el filtrado de contenido para fines como los siguientes:

• Bloqueo de dominios que se utilizan para la distribución de malware.

• Bloqueo de anuncios.

• Filtrado de control parental mediante el bloqueo de dominios relacionados con contenido para adultos.

• Bloqueo del acceso a dominios que ofrecen contenido ilegal de acuerdo con las regulaciones locales.

• Oferta de un DNS de horizonte divididopara brindar diferentes respuestas en función de la red de origen.

Una ventaja de bloquear el acceso a los dominios a través del resolutor de DNS es que se puede hacer de forma centralizada, sin volver a implementarlo en cada aplicación. Lamentablemente, esto tampoco es muy seguro. Supongamos que un sitio web aloja contenido para múltiples usuarios en example.com/videos/for-kids/ y example.com/videos/for-adults/. El resolutor de DNS solo podrá ver “example.com” y puede optar por bloquearlo o no. En este caso, los controles específicos de la aplicación, como las extensiones del navegador, serían más eficaces, ya que en realidad pueden examinar los URL e impedir de manera selectiva el acceso al contenido.

El monitoreo de DNS no es integral. El malware podría omitir el DNS y las direcciones IP predefinidas en el código, o usar métodos alternativos para consultar una dirección IP. Sin embargo, no todo el malware es tan complicado, por lo que el monitoreo de DNS todavía puede servir como una herramienta de seguridad adicional.

Todos estos casos de monitoreo no pasivo o el uso de bloqueo de DNS requieren compatibilidad con el resolutor de DNS. Las implementaciones que se basan en actualizaciones DoH/DoT oportunistas del resolutor actual mantendrán las mismas características que se brindan habitualmente a través de DNS sin cifrar. Lamentablemente, como se mencionó anteriormente, esto es vulnerable a los cambios a versiones anteriores Para resolver esto, los administradores del sistema pueden indicar puntos de conexión a un resolutor DoH/DoT en modo estricto. Lo ideal es hacerlo a través de soluciones de administración de dispositivos seguros (MDM, política de grupo en Windows, etc.).

Uno de los fundamentos de Internet es la asignación de nombres a una dirección mediante DNS. DNS tradicionalmente ha utilizado transportes inseguros y sin cifrar. Los ISP abusaron de esto en el pasado para insertar anuncios, pero también genera pérdida de privacidad. Los visitantes curiosos en la cafetería pueden usar DNS sin cifrar para seguir tu actividad. Todos estos problemas se pueden resolver con el uso de DNS mediante TLS (DoT) o DNS mediante HTTPS (DoH). Estas técnicas para proteger al usuario son relativamente nuevas y se observa un crecimiento en su adopción.

Desde una perspectiva técnica, DoH es muy similar a HTTPS y sigue la tendencia general de la industria de dejar de usar opciones no seguras. DoT es un modo de transporte más simple que DoH, ya que se elimina el nivel HTTP, pero eso también facilita los bloqueos deliberados o accidentales.

Luego de habilitar un transporte seguro es necesario elegir un resolutor de DNS. Algunos proveedores usarán el resolutor de DNS configurado a nivel local, pero intentarán actualizar según la conveniencia el transporte sin cifrar a un transporte más seguro (DoT o DoH). Lamentablemente, el resolutor de DNS, por lo general, tiene un valor predeterminado del ISP que puede no ser compatible con transportes seguros.

Mozilla ha adoptado un enfoque diferente. En lugar de depender de resolutores locales que ni siquiera admiten DoH, permiten al usuario seleccionar un resolutor de manera explícita. Los resolutores recomendados por Mozilla deben satisfacer altos estándares para proteger la privacidad del usuario. Para garantizar que las funciones de control parental en función de DNS sigan siendo funcionales, y para admitir el caso práctico de horizonte dividido, Mozilla ha agregado un mecanismo que permite a los resolutores deshabilitar DoH.

Los protocolos de transporte de DoT y DoH están listos para que avancemos hacia una Internet más segura. Como se puede ver en los recorridos previos de los paquetes, estos protocolos son similares a los mecanismos actuales para garantizar el tráfico de la aplicación. Una vez solucionado este problema de seguridad y privacidad, habrá muchos más por resolver.