¿Qué es un Flujo de Tráfico de Red?

Los flujos de tráfico de red (flujos) son útiles para construir una comprensión de grano grueso del tráfico en una red informática, proporcionando una unidad conveniente para la medición y/o el tratamiento del tráfico.Los flujos

se pueden medir para comprender qué hosts están hablando en la red, con detalles de direcciones, volúmenes y tipos de tráfico. Esta vista de la red puede ser útil para solucionar problemas, detectar incidentes de seguridad, planificar y facturar

, pero ¿qué es exactamente un flujo y cómo se define?

Esta pregunta suena trivial de responder, sin embargo, cuando profundizamos, encontramos matices y casos de esquina que hacen que los flujos sean interesantes y, en última instancia, difíciles de definir.

Fondo

Para entender realmente los flujos, necesitamos comenzar con algo de fondo.

Las redes comenzaron como circuitos conmutados. Cuando un host quería comunicarse con otro host preguntó a la red de un circuito. Una vez terminado el flujo de información, el circuito fue derribado.

Figura 1-Ejemplo de Red con conmutación de circuitos

Las redes con conmutación de circuitos tienen su herencia en las redes telefónicas. Tienen una serie de inconvenientes, como la escasa escalabilidad y la baja utilización de la capacidad.

Se necesitaba una alternativa para construir lo que finalmente se convirtió en las redes de conmutación de paquetes de Internet. Los mensajes se dividen en trozos de tamaño variable que se dirigen individualmente y se envían como paquetes a través de la red.

Figura 2-Ejemplo de Red conmutada de paquetes

El host receptor vuelve a ensamblar la carga útil de los paquetes en el mensaje. Nota: los paquetes también pueden contener información de control, como el control de flujo y las rutas no tienen que ser simétricas.

Definir flujos en una red de conmutación de circuitos es fácil, ya que el circuito es un flujo y sigue un protocolo para establecer y desactivar (circuito = flujo); sin embargo, en una red de conmutación de paquetes las cosas son menos obvias.

Imagine por un segundo que está en el punto de observación A en la red de conmutación de circuitos de la Figura 1, verá:

Figura 3-Zoom en la Red conmutada de circuitos

Se observarían dos flujos: circuitos entre hosts 3 & 4 y hosts 5 & 6. Observar los flujos en una red conmutada de circuitos es relativamente fácil porque la red está involucrada en la configuración de los circuitos, por lo que conoce su estado y los puntos finales.

Imagine que ahora que se encuentra en el punto de observación A en la red de conmutación de paquetes de la Figura 2, verá:

Figura 4-Zoom en la Red conmutada de paquetes

De repente las cosas son menos claras. Hay un paquete que viene del Host 5 destinado al Host 6. Suponiendo que observamos durante un período de tiempo, vemos que llegan y salen más paquetes. La observación de los flujos en una red conmutada de paquetes lleva tiempo y requiere registrar y analizar la información de los paquetes.

Primer Intento (Ingenuo) de Definir un Flujo

Utilizando nuestro conocimiento de redes conmutadas de paquetes, un primer intento de responder “qué es un flujo” podría ser:

Un flujo es una secuencia de paquetes que contenían información entre dos hosts

Esta definición parece:

Figura 5 – Primer Intento de Definir un Flujo

sin embargo, Hay un problema. ¿Qué sucede si hay más de un tipo de comunicación entre los hosts, por ejemplo, A tiene una conexión SSH y HTTPS con B? ¿Son los paquetes SSH y HTTPS parte del mismo flujo? Intuitivamente decimos que no, son sesiones diferentes, e incluso protocolos completamente diferentes. Podemos hacerlo mejor

Segundo intento de Definir

¿Qué tal si usamos la información de protocolo de las cabeceras de paquetes como propiedades comunes para identificar paquetes en flujos? Esto separará diferentes tipos de conexión en diferentes flujos.

Es probable que una gran proporción de paquetes en una red sean protocolo de capa 3 IP, con TCP o UDP como protocolo de transporte de capa 4. Por lo tanto, es razonable considerar el uso de parámetros TCP y UDP como claves de flujo desde las cabeceras de paquetes.

Usaremos 5 parámetros de las cabeceras de paquetes; IP de origen, IP de destino, protocolo, puerto de origen TCP o UDP y puerto de destino TCP o UDP como una lista ordenada, comúnmente conocida como la 5-tupla, como las propiedades comunes para asignar los paquetes a flujos.

Figura 6-Ejemplo 5-tupla

Aquí va el intento 2:

Un flujo es una secuencia de paquetes que transportan información entre dos hosts, donde los paquetes tienen propiedades comunes:

• Todos los paquetes del flujo comparten la misma tupla 5

Nuestro escenario ahora se ve así:

Figura 7 – Segundo Intento de Definir un Flujo

Perfecto que usted dice. La vida es buena. Tenemos una definición para un flujo, nada más que ver aquí hang Pero espera, ¿qué hay de la dirección de los paquetes?

Tercer intento-Bidireccional

Una 5 tupla es unidireccional (unidireccional). De forma predeterminada, solo coincidirá con los paquetes que viajan en una dirección, ya que los paquetes en la dirección inversa han transpuesto direcciones IP y números de puerto, y por lo tanto un hash de 5 tuplas diferente.

Hay buenas razones para considerar los flujos como bidireccionales en lugar de unidireccionales, incluida la capacidad de determinar el comportamiento del cliente/servidor y calcular los tiempos de ida y vuelta, así como mejorar la detección de incidentes de seguridad, como el escaneo.

Considere una conexión TCP simple en la Figura 8 donde los paquetes rebotan entre el host A & B:

Figura 8-Diagrama de escalera de un Flujo TCP Simple

Vemos un clásico apretón de manos TCP de 3 vías (SYN, SYN+ACK, ACK) seguido de intercambio de datos. El análisis de flujo unidireccional en un punto de observación en la red vería dos flujos separados, uno por dirección, según la Figura 9:

Figura 9-Escaleras unidireccionales para un flujo TCP simple

El problema con la medición de flujo unidireccional es que perdemos la oportunidad de capturar algunos metadatos importantes sobre el flujo. Claro, cada flujo unidireccional puede almacenar metadatos direccionales para bytes y paquetes en esa dirección. Esto puede incluir la sincronización entre paquetes (consulte puntos etiquetados en la Figura 9). Pero perdemos la oportunidad de recopilar metadatos que requieren medir parámetros de tráfico en ambas direcciones.

Considere la observación bidireccional en la Figura 10:

Figura 10-Escala de Observaciones Bidireccionales para Flujo TCP Simple

Ahora podemos observar y medir el apretón de manos TCP de 3 vías (puntos F1, B1, F2) y mirar otras métricas como los tiempos de respuesta.

Para flujos bidireccionales, necesitamos dos 5 tuplas, la segunda de las cuales invierte el orden de las tuplas tanto de las direcciones IP como de los números de puerto. A continuación se muestra un ejemplo de flujo SSH hacia adelante y hacia atrás 5 tuplas:

Figura 11-Revertir una 5-tupla

Derecha, eso no fue demasiado difícil. Pero espera, un pequeño detalle acecha que requiere más atención. ¿Cómo sabemos cuál es la dirección hacia adelante del flujo? Determinamos la dirección en función del primer paquete observado, que se supone que viaja en la dirección del cliente al servidor, pero esto no va a ser 100% confiable, ya que los paquetes podrían estar fuera de orden y/o la observación podría comenzar en parte a través de un flujo. Usaremos este método, pero debemos recordar cuando veamos los resultados que no es perfecto.

Un método alternativo es inspeccionar los campos del protocolo de transporte. En TCP, por ejemplo, la presencia de solo la bandera SYN es un indicador razonable de que el paquete es el primero en el flujo.

Nuestra definición para un flujo es ahora:

Un flujo es una secuencia de paquetes que transportan información entre dos hosts donde los paquetes tienen propiedades comunes:

• Todos los paquetes en el flujo comparten la misma 5-tupla o 5-tupla transpuesta

Cuarto intento-Incluyendo Tráfico IP no TCP

Hasta este punto hemos asumido que el protocolo de transporte es TCP. ¿Qué pasa con otros protocolos de transporte IP?

UDP es la opción obvia para el segundo protocolo de transporte más común, especialmente con el aumento del tráfico en tiempo real sobre UDP, así como nuevos protocolos como QUIC. UDP encaja fácilmente en el mismo modelo, ya que tiene números de puerto de origen y destino, según el siguiente ejemplo QUIC:

Figura 12-Revertir una 5-tupla UDP (igual que TCP)

El Protocolo de transmisión de Control de flujo (SCTP) es otro protocolo de transporte que utiliza números de puerto y, por lo tanto, funciona con una 5-tupla.

Pero, ¿qué pasa con otros protocolos, IPsec, por ejemplo?

IPsec ESP (Carga útil de seguridad Encapsulada) es un protocolo que no incluye números de puerto de origen/destino, por lo que necesitamos recurrir a una 3 tupla, ya que es poco probable que sea práctico comprender la carga útil del protocolo.

Figura 13-3-Tupla bidireccional

Nuestra definición para un flujo es ahora:

Un flujo es una secuencia de paquetes que transportan información entre dos hosts donde los paquetes tienen propiedades comunes:

• Para protocolos de transporte con números de puerto (por ejemplo, TCP / UDP / SCTP):

Todos los paquetes en el flujo comparten la misma 5-tupla o 5-tupla transpuesta

de lo contrario:

Todos los paquetes en el flujo comparten la misma 3-tupla o 3-tupla transpuesta

Sin embargo, hay otro factor a considerar: el tiempo.

Quinto intento: Caducidad del flujo

Un flujo solo existe durante un cierto período de tiempo. Es posible que la misma 5-tupla (o 3-tupla) pueda reutilizarse en un momento diferente, para un flujo diferente, entre los mismos hosts.

Considere dos hosts donde uno inicia muchas conexiones TCP nuevas con el otro. Cada nueva conexión TCP obtiene un nuevo puerto de origen, generalmente incrementado en 1 desde la asignación anterior. IANA asigna el rango 49152 a 65535 para estos puertos efímeros, dando 16384 puertos. Con el tiempo, el puerto de origen TCP recorrerá el rango y el puerto de origen original se reutilizará, y este flujo tendrá la misma tupla de 5 que el flujo original. Esto presenta un problema, ya que no es el mismo flujo!

Para resolver esto necesitamos flujos caducados donde no se vean paquetes durante más de un período de tiempo especificado. Aquí vamos de nuevo:

Un flujo es una secuencia de paquetes que transportan información entre dos hosts donde los paquetes tienen propiedades comunes:

• Para protocolos de transporte con números de puerto (por ejemplo, TCP / UDP / SCTP):

Todos los paquetes en el flujo comparten la misma 5-tupla o 5-tupla transpuesta

else:

Todos los paquetes en el flujo comparten la misma 3-tupla o 3-tupla transpuesta

• Todos los tiempos entre paquetes son menores que el valor de tiempo de espera de caducidad de flujo arbitrario

Sexto intento: Parámetros arbitrarios

A veces es posible que desee diferentes parámetros para identificar flujos, o que el tipo de hardware/software en la red lo obligue a hacerlo.

En un router Cisco, por ejemplo, los flujos se identifican mediante una tupla de 7 que agrega Tipo de Servicio (ToS) y subinterfaz de entrada a la tupla de 5 estándar. También puede haber situaciones en las que los campos de capa 2, como la dirección MAC de origen o destino, pueden tener sentido como claves de flujo (aunque tenga en cuenta que solo son significativos localmente).

Hay otros parámetros que podrían usarse como propiedades comunes para la identificación de flujos; en última instancia, depende del operador decidir y de las capacidades del equipo. En base a esto, refinamos aún más la definición:

Un flujo es una secuencia de paquetes que transportan información entre dos hosts donde los paquetes tienen propiedades comunes:

• Para protocolos de transporte con números de puerto (por ejemplo, TCP / UDP / SCTP):

Todos los paquetes en el flujo comparten la misma 5-tupla o 5-tupla transpuesta

else:

Todos los paquetes en el flujo comparten la misma 3-tupla o 3-tupla transpuesta

• Todos los tiempos entre paquetes son menores que el valor de tiempo de espera de caducidad de flujo arbitrario
• Puede usar cualquier parámetro arbitrario como claves de flujo, incluidos ToS, interfaz, etc.

Envolverlo todo

Hemos demostrado que producir una única definición de flujo que lo abarque todo es un problema difícil. La definición de flujo es específica de la implementación, depende de los requisitos del usuario, así como de las capacidades del equipo de red que mide los flujos.

En la parte 2 de esta entrada de blog, veremos más consideraciones para flujos como etiquetas de flujo IPv6, fragmentación (problema IPv4 e IPv6)..), cifrado, paquetes no IP y cómo se miden y utilizan los flujos en otros sistemas como SDN.

Véase: https://www.eecs.yorku.ca/course_archive/2015-16/W/3214/CSE3214_01_PacketCircuitSwitching_2016_posted_part2.pdf

Para algunos documentos relacionados, ver: https://www.researchgate.net/profile/Brian_Trammell/publication/245587221_Bidirectional_Flow_Measurement_IPFIX_and_Security_Analysis/links/0f3175331dd3b49103000000/Bidirectional-Flow-Measurement-IPFIX-and-Security-Analysis.pdf y https://is.muni.cz/th/hilnn/cse2009.pdf

Para RFC relevante, ver: https://tools.ietf.org/html/rfc5103

Para obtener más información sobre la estandarización de QUIC, consulte: https://datatracker.ietf.org/wg/quic/about/

Véase: https://www.cisco.com/en/US/tech/tk812/technologies_white_paper09186a008022bde8.shtml