¿Cómo detectan y bloquean los ISP el tráfico de intercambio de archivos P2P?

Existen varias técnicas de detección y, por razones obvias, los ISP no son muy transparentes al respecto, pero en general BitTorrent tiene patrones de uso bastante obvios: tiene muchas conexiones abiertas a la vez y envía regularmente paquetes de tamaños muy específicos (los que contienen los keepalives ), transfiriendo gran cantidad de datos en ambas direcciones simultáneamente, etc.

Eso es solo para BitTorrent basado en TCP. Para el nuevo BitTorrent basado en UDP, que es la mayor parte en estos días, es aún más fácil de detectar ya que casi todo el tráfico UDP es BitTorrent. Dicho esto, el protocolo uTP (nuestro reemplazo basado en UDP intercambiable para TCP) es intencionalmente muy bueno para retroceder cuando el ISP está en peligro de sobrecargarse, por lo que los ISP probablemente no se preocupen demasiado por obligar a ese tráfico a retroceder , aunque nunca dejan muy claras sus opiniones o políticas sobre estas cosas.

La forma en que los ISP fuerzan la desaceleración de los protocolos p2p es * probablemente * aumentando la tasa de pérdida de paquetes en el tráfico p2p lo suficiente como para que el rendimiento disminuya, ya sea dándole una cola separada o algo mucho más crudo. Comcast aprendió por las malas que la falsificación restablece los resultados en muy, muy, malas relaciones públicas, por lo que probablemente no se haga mucho. Existen técnicas específicas de uTP que tienen que ver con la demora de paquetes que también podrían usar, pero sospecho que los aspectos técnicos de las mismas hacen que sea demasiado difícil de hacer, y uTP es tan autolimitante que no lo hace. Realmente causa algún problema. (Esto no quiere decir que uTP no use toda la capacidad que se le da. Es bastante bueno en eso. Simplemente no usará la capacidad si hay demanda de un protocolo basado en TCP).

Los grandes proveedores de servicios no bloquean P2P a través del bloqueo de puertos, o bloquean dominios, usan dispositivos en línea muy específicos como Sandvine (Ver http://www.sandvine.com/products …) o Arbor Networks (Ver http: //www.arbornetworks.com/arb …) y otros proveedores relacionados y utilizan sus técnicas de detección de DPI ( Inspección profunda de paquetes ) para ver el paquete de carga útil en tiempo real e intentar determinar el tipo de tráfico. Si es P2P (tráfico torrente), pueden bloquearlo, ralentizarlo, acelerarlo, etc.

Los dispositivos avanzados de administración de tráfico pueden observar varios tipos de tipos de tráfico y ser capaces de distinguirlos con mucha precisión, incluso si están haciendo túneles bajo la apariencia de algún otro protocolo.

Bram Cohen mencionó el modelado de comportamiento (no lo llamó así, pero eso es lo que es) en su párrafo inicial, pero quería hablar un poco más sobre eso. Hacer una inspección profunda de paquetes (DPI) es increíblemente difícil de hacer a escala. Mantenerse al día con un gigabit por segundo es una cosa. Mantenerse al día con 10 Gb o más es difícil. El modelado de comportamiento es una alternativa confiable para detectar tipos de tráfico independientemente del protocolo o los puertos de la capa 4.

Cuando el DPI se asoma en la carga útil del paquete TCP / UDP en busca de encabezados, palabras clave o patrones específicos, el modelado del comportamiento examina cómo una aplicación (más adecuadamente un flujo) está actuando en la red. Piense en lo que sucede cuando se conecta a un servidor web. Su navegador envía varias conexiones TCP al servidor web (o un puñado de otros servidores), todo en un corto período de tiempo. Estas solicitudes son pequeñas. Las respuestas son mucho mayores, ya que reciben mucho texto, imágenes, video, etc., en unos pocos cientos de milisegundos o segundos, las conexiones se cierran. Dado que el puerto TCP 80 es el puerto más común utilizado, podemos suponer que, según el comportamiento de la conexión y el uso del puerto, la solicitud es para una página web y todos los medios asociados (imágenes, Flash, etc.).

¿Qué sucede si el puerto del servidor web no es el puerto 80. Digamos que era 45328? El comportamiento de conexión sería similar y el patrón generalizado es bastante único. Podemos decir con bastante certeza que es HTTP en un puerto alto. ¿Qué pasa si, en cambio, alguien hizo un túnel SSH sobre el puerto 80? Esa conexión se ve muy diferente. Es una conexión única que tiene una larga vida. Las conexiones HTTP tienden a ser de corta duración. Podemos decir que una conexión de larga duración a través del puerto 80 probablemente no sea HTTP.

Cuando observamos el tráfico P2P, los comportamientos (vistos desde el lado del cliente) son cosas como conexiones salientes a muchos hosts que son pequeños salientes y grandes entrantes de larga duración (es decir, transferencia de datos), muchas conexiones entrantes que son pequeñas entrantes con grandes respuestas salientes Por lo general, los números de puerto serán puertos altos no utilizados por otros protocolos. En las redes P2P con supernodos, habrá muchas conexiones a una sola IP (o un subconjunto de IP). Es realmente fácil elegir este tipo de tráfico.

Estoy pasando por alto muchos detalles y de ninguna manera el modelado de comportamiento es perfecto, pero puedes clasificar fácilmente el tráfico en función de los comportamientos. También es más fácil recopilar la información necesaria de los datos de flujo (IP de origen, puerto de origen, IP de destino, puerto de destino, bytes de entrada y salida, marcas de tiempo) que capturar y analizar cada paquete.