Comprender las deficiencias de Wehe en la detección de tráfico HTTPS

Tabla de enlaces

Resumen e introducción

Trabajo relacionado y antecedentes

Desafíos en el desarrollo de la configuración de medición de detección de TD

Estudio de caso: Wehe: herramienta de detección de TD para entornos móviles

Deficiencia de Wehe en el tráfico HTTPS

Detección TD de tráfico HTTPS

Conclusión y referencias

V. DEFICIENCIAS DE WEHE EN EL TRÁFICO HTTPS

Nuestro estudio se centra en validar las respuestas de la red para los flujos de tráfico reproducidos, la detección de TD y la viabilidad operativa en varias configuraciones de red. Si bien la viabilidad operativa se valida utilizando la aplicación de Android "Wehe" disponible públicamente en Google Playstore, los escenarios de detección de TD se validan utilizando argumentos teóricos. La validación de las respuestas de la red requiere un análisis del ancho de banda del flujo de tráfico recibido. Este análisis requiere los registros de red para la reproducción específica realizada según el escenario de validación. La reproducción realizada en el dispositivo y muchas otras transmisiones.

Fig. 6. Clasificación del tráfico reproducido de YouTube

los servicios que se ejecutan en paralelo es uno de esos escenarios. La aplicación Wehe no proporciona inmediatamente dichos registros de red para las repeticiones una vez finalizadas las pruebas. Entonces, implementamos el usuario-cliente y el servidor que imita el comportamiento de la herramienta Wehe.

Usamos una configuración cliente-servidor similar a la configuración que se muestra en la Fig. 3 para validar Wehe. En la configuración actual, reemplazamos el servidor del servicio original con un servidor de reproducción. El cliente de usuario y el servidor de reproducción están conectados a través de un modelador de tráfico comercial. Además, nuestra configuración tiene la posibilidad de realizar múltiples repeticiones en paralelo. Nuestra configuración de validación no necesita canales administrativos ni gastos generales, por ejemplo, canales laterales. Nuestro servidor siempre necesita admitir un cliente de un solo usuario. La validación de escenarios con múltiples clientes utiliza la Wehe App directamente debido a que no requiere análisis de tráfico asociado.

El recordatorio de esta sección describe los resultados de la validación.

A. Emulación del tráfico del servicio original.

Las respuestas de la red dependen de la aplicación de políticas de red basadas en la clasificación correcta del tráfico de sondeo mediante cajas intermedias de red como se menciona en la Sección III-A. Validamos la clasificación del tráfico emulado de Wehe utilizando un modelador de tráfico comercial. La clasificación del tráfico emulado se observa utilizando la interfaz de usuario del modelador de tráfico comercial.

Para realizar el experimento, los datos de la aplicación YouTube se reproducen desde el servidor de reproducción al usuario-cliente a través del modelador de tráfico comercial. Durante la transferencia de datos, se observa la ventana de la interfaz de usuario del modelador de tráfico comercial para detectar la presencia de tráfico de YouTube. También accedimos al tráfico de YouTube mediante un navegador de Internet y observamos el resultado de la clasificación del modelador de tráfico para establecer una base para nuestras observaciones de clasificación del tráfico.

La Fig. 6 muestra el resultado de la clasificación del tráfico tal como se muestra en la ventana de interfaz de usuario del modelador de tráfico comercial para el tráfico al que se accede directamente mediante un navegador de Internet desde un servidor de YouTube. Muestra la actividad de Internet en la ventana izquierda y la clasificación del tráfico correspondiente en la ventana derecha.

La figura 6 (a) muestra que el tráfico al que se accede mediante el navegador de Internet se clasifica correctamente como YouTube. Esto está en línea con el comportamiento previsto del modelador de tráfico comercial.

La figura 6 (b) muestra el resultado de la clasificación del tráfico al que se accede mediante usuario-cliente. Muestra evidencia de que no se transfirió tráfico de YouTube a través del enlace de comunicación. Además, clasifica el mismo tráfico que el tráfico HTTPS. El resultado de este experimento muestra que no todos los middleboxes de red pueden clasificar correctamente el tráfico repetido de Wehe.

B. Efecto de la velocidad de datos en el script de reproducción

La generación de tráfico de sondeo afecta la respuesta de la red como lo espera el algoritmo de detección de TD. Wehe utiliza el seguimiento de tráfico del servicio original para generar scripts de reproducción que preservan los datos de la aplicación y su relación de tiempo. Este script de reproducción se utiliza en la red original y también en redes que están ubicadas geográficamente de manera diferente. Como la tasa de configuración del tráfico varía entre redes para el mismo servicio (como se menciona en [32]), la tasa de tráfico conservada en el script de reproducción puede ser diferente de la tasa de configuración del tráfico de la red considerada actualmente. La tasa de tráfico de repetición puede ser menor que la tasa de configuración del tráfico.

La metodología Wehe no detecta la diferenciación del tráfico si la tasa de tráfico del script de reproducción es menor que la tasa de configuración de la red, ya que no afecta el flujo de tráfico. Estos scripts de reproducción nunca pueden detectar la configuración del tráfico en dichas redes. Por lo tanto, la capacidad de detección de TD de la herramienta Wehe está limitada por la tasa de tráfico de sondeo del script de reproducción.

C. Uso del puerto número 80

Las respuestas de la red están impulsadas por la percepción de las cajas intermedias de la red sobre el tráfico de sondeo (consulte la Sección III-A). El script de reproducción conserva los datos en el seguimiento de red original de las aplicaciones. Los servidores de aplicaciones originales utilizan el puerto 80 para los datos de texto sin formato y el puerto 443 para la transferencia de datos cifrados. El script de reproducción de Wehe utiliza directamente los datos cifrados del rastreo de red de la aplicación y los transmite en el puerto 80. En tales casos, Wehe espera que los dispositivos de red clasifiquen correctamente su flujo de tráfico de reproducción original utilizando datos de aplicación cifrados. Es imposible que dichos datos estén en el puerto 80, ya que los datos de tráfico cifrados no pueden exponer su identificación al dispositivo de red. Por lo tanto, la herramienta Wehe no puede generar los flujos de tráfico necesarios para los servicios que se ejecutan en el puerto número 443 debido al uso predeterminado del puerto 80 para la ejecución de reproducción.

D. La carga de tráfico gobernaba el comportamiento de la red

Tenga en cuenta que la escasez de recursos incita a las redes a aplicar cierta gestión del tráfico de red, especialmente en escenarios de carga de red pesada, que son beneficiosas para todos los servicios activos en su red, por ejemplo, gestión de tráfico basada en QoS (consulte la Sección III-A). Validamos el efecto de dicha gestión del tráfico.

Fig. 7. Efecto de la carga de la red en el rendimiento del flujo de tráfico de Wehe

sobre las actuaciones tanto de control como de repeticiones originales. La validación utiliza los siguientes tres escenarios para la validación,

• Reproducir sólo los dos flujos de tráfico de Wehe sin ninguna carga en la red (Fig. 7(a))

• Reproducir los tres flujos de tráfico de Wehe con un servicio de transmisión adicional ejecutándose en paralelo (Fig. 7(b))

• Reproducción de los tres flujos de tráfico de Wehe con 2 servicios de transmisión adicionales ejecutándose en paralelo (Fig. 7(c))

El rendimiento en la Fig. 7 (a) muestra que el rendimiento de los flujos de tráfico generados por la herramienta Wehe es el mismo sin condiciones de carga de red adicionales. A medida que aumenta la carga de la red, el rendimiento de la reproducción de control se desvía del de la reproducción original y en un nivel superior (Fig. 7 (b)). Si bien el rendimiento de la repetición de control se desvía aún más de la reproducción original en el lado inferior, dos repeticiones originales aún muestran rendimientos similares, como se muestra en la Fig. 7 (c). Invalida la expectativa de la herramienta Wehe de que la reproducción de control no se diferencie. También invalida la afirmación de la herramienta de detectar el TD debido al ancho de banda total.

E. Wehe prueba desde múltiples dispositivos dentro de la misma subred

Los canales laterales se introducen en el diseño de Wehe para admitir múltiples clientes usuarios simultáneamente. Los canales laterales también ayudan a identificar la asignación entre usuario-cliente y una combinación de direcciones IP y puertos. Es útil en el caso de redes que utilizan NAT [33]. Validamos el soporte de Wehe para múltiples clientes y redes habilitadas para NAT mediante dos pruebas diferentes. Primero, conectamos dos usuarios-clientes desde la misma subred, es decir, clientes que comparten la misma dirección IP pública. En una prueba, la herramienta Wehe prueba el mismo servicio en ambos dispositivos; por ejemplo, la aplicación Wehe en ambos dispositivos prueba YouTube. El resultado muestra que la prueba de Wehe se completó en un solo dispositivo, mientras que la aplicación Wehe se cerró abruptamente en otro dispositivo. Repetimos el mismo escenario, pero esta vez Wehe prueba diferentes servicios, por ejemplo, Wehe prueba YouTube en un dispositivo y Netflix en otro. Descubrimos que la prueba Wehe en un dispositivo se completa correctamente mientras que la prueba Wehe en otro dispositivo arroja un error en la pantalla, informando al usuario que otro cliente ya está realizando la prueba, como se muestra en la Fig. 9. Estas pruebas muestran que Wehe no No admite varios dispositivos si comparten la misma dirección IP. Si bien un canal lateral es útil para identificar cada repetición de un usuario-cliente conectado directamente al servidor de reproducción de Wehe, no es útil en la red que utiliza dispositivos NAT. Varios usuarios comparten la misma dirección IP en el caso de NAT. En tales casos, el canal lateral no puede asignar de forma única cada ejecución de repetición a un cliente. Limita el uso de Wehe a un solo cliente activo por servidor de reproducción, ISP y aplicación. Esta limitación también está documentada por los desarrolladores de Wehe.

F. Efecto de la carga de la red del dispositivo en la detección de TD

El servidor de reproducción de Wehe utiliza los mismos tiempos entre la transferencia de datos de la aplicación que el tráfico de la aplicación original. Se espera que dicha estrategia de transmisión no agote el ancho de banda disponible. Por lo tanto, el efecto de la modulación de la tasa de fuente debido al exceso de la tasa de tráfico por encima del ancho de banda disponible es poco probable. Hace que las repeticiones originales y de control muestren rendimientos de tráfico similares a menos que las políticas de red las modifiquen deliberadamente, es decir, TD.

Sin embargo, esta expectativa no siempre se cumple ya que la velocidad de datos del tráfico es modulada por la carga de la red en el dispositivo del usuario mientras se realizan las pruebas Wehe. Tales perturbaciones crean discrepancia ya que el efecto de la carga actual de la red que varía en el tiempo sobre el tráfico de sondeo también varía en el tiempo y puede no ser siempre el mismo. La estrategia de reproducción consecutiva de Wehe garantiza que ambos flujos de tráfico de sondeo (original y de control) se vean afectados de manera diferente por la carga actual de la red. Bajo tal carga de red en el lado del dispositivo, la noción de que los servicios no agoten el ancho de banda disponible deja de existir junto con sus beneficios para la detección de TD. Es necesario normalizar dichos factores de confusión (consulte la Sección III-B) antes de la detección de TD.