MÉTODO Y SISTEMA PARA MONITORIZACIÓN DE TRÁFICO DE RED.

Método y sistema para monitorización de tráfico de red.

El método comprende las etapas de:

a) adquirir con un módulo de captura, datos de tráfico de una línea de entrada y reenviar dichos datos de tráfico a un módulo de detección; y

b) recibir, dicho módulo de detección, dichos datos de tráfico para realizar un análisis de inspección profunda de datos de dichos datos de tráfico recibidos para realizar una detección de los mismos,

en el que dicha etapa a) comprende, adquirir dichos datos de tráfico de al menos dos de dichas líneas de entrada y clasificarlos de modo que dicho reenvío a dicho módulo de detección se realice en un orden cronológico para aquellos paquetes pertenecientes a un flujo específico de dichos datos de tráfico procedentes de dichas al menos dos líneas de entrada.

El sistema de la invención está previsto para implementar el método de la invención.

Campo de la tecnica La presente invencion se refiere a la monitorizacion de redes y en general se refiere a un metodo y un sistema para monitorizacion de trafico de red. Estado de la tecnica anterior La monitorizacion de redes se ha convertido en una tarea importante en las redes IP modernas. Permite mantener la estabilidad, disponibilidad y seguridad del sistema de red y permite tomar decisiones acertadas con respecto a planificacion de red y capacidad. En la monitorizacion de redes, ademas de conocer la cantidad trafico, se requiere clasificarlo por tipo, es decir determinar el protocolo/servicio que lo provoca. Esta clasificacion de trafico se deduce usando patrones de trafico, siendo estos patrones diferentes para video, voz sobre IP, navegacion web, reproduccion en tiempo real,

etc. Existen muchos productos comerciales tales como Sandvine [1], iPoque [2] o Cisco SCE [3] que proporcionan una solucion basandose en analisis de inspeccion profunda de paquetes (DPI) y la deteccion de patrones de trafico. Estos sistemas inspeccionan el trafico que atraviesa un enlace y lo clasifican como perteneciente a una clase especifica de aplicacion o lo clasifican como desconocido. Esta informacion se usa para proporcionar informes de trafico que son el resultado final del sistema. Las soluciones DPI actuales realizan analisis de trafico en tiempo real basandose en firmas de trafico, es decir filtros y patrones predefinidos en el nivel de aplicacion de los paquetes. Una vez aplicada esta deteccion al trafico, estos dispositivos realizan una interpretacion en tiempo real cuyo proposito es obtener una interpretacion completa del trafico.

La figura 1 ilustra la arquitectura de las soluciones DPI actuales. Como puede observarse, estan implementadas como un sistema monolitico que detecta patrones, realiza una interpretacion en tiempo real y correlaciona la informacion obtenida. Una alternativa para estos sistemas DPI es la patente WO 2011051750 (PCT/EP2011/070875) , este metodo consiste en separar la captura de trafico del procesamiento de trafico, permitiendo el analisis y la interpretacion de la captura en una fase posterior. La captura de trafico comprende dos tipos de informacion:

1. Informacion util para la contabilidad de trafico (ACC) como el volumen de bytes y paquetes por flujo.

2. Informacion util para la clasificacion de trafico, o informacion META. Los paquetes clave se detectan y se guardan los campos literales de estos paquetes que contienen la informacion mas relevante. Por ejemplo, un paquete relevante podria ser una peticion HTTP y uno de sus campos clave, el nombre del host. Esta

informacion META contiene los datos comprendidos necesarios para clasificar el flujo en una aplicacion o servicio especifico y conserva toda la informacion interesante que puede usarse para analisis y estudios adicionales en la fase de posprocesamiento posterior. La informacion META es lo suficientemente general para permitir el uso de firmas en el posprocesamiento, pero al mismo tiempo, su volumen es significativamente inferior al trafico original. Debido al tamano reducido de la captura esta puede procesarse en linea o almacenarse para su analisis en un momento diferente. Como las firmas no se aplican en el momento de la captura sino en el posprocesamiento, es posible anadir firmas segun se requiera para analizar multiples veces una misma captura, garantizando de esta manera que no se pierda informacion por no tener una firma especifica instalada en el momento de la captura.

Problemas con las soluciones existentes Como las soluciones DPI comerciales actuales usan un enfoque de sistema monolitico, cualquier clase de trafico que no se interpreta con las firmas instaladas se pierde para siempre, puesto que la interpretacion DPI generada no proporciona informacion suficiente para realizar un analisis posterior. Por tanto existe una fuerte dependencia de la actualizacion de las firmas. Un problema adicional de esta DPI es que la correlacion con fuentes de datos externos se realiza en el momento de captura, de modo que estos datos externos deben estar disponibles para la DPI en tiempo real. Sin embargo, muchas veces estos datos externos no estan disponibles en el momento de captar el trafico. El metodo descrito en el documento WO 2011051750 evita la limitacion mencionada de la DPI comercial pero tiene una desventaja comun con la misma. Todos los sistemas DPI presentados incluyendo el del documento 55 WO 2011051750, con el fin de analizar el trafico de manera apropiada, necesitan procesar por separado la informacion por flujo analizando paquetes en un estricto orden cronologico. Mantener el orden de todos los paquetes dentro del mismo flujo es esencial para interpretar el trafico correctamente, por ejemplo, no tendria sentido analizar un paquete que contuviera una respuesta de un servidor antes de saber lo que se solicito. Si solo estan presentes algunos paquetes del flujo, las firmas no clasificaran el trafico de manera apropiada (en DPI

[1] [2] [3]) o no extraeran toda la informacion META (documento WO 2011051750) . La desventaja mencionada en ultimo lugar tiene un gran impacto en la aplicacion practica del analisis DPI para clasificar trafico puesto que es bastante comun que, debido a las condiciones de encaminamiento normales, los paquetes del mismo flujo viajen por diferentes lineas de transmision. La figura 3 ilustra un punto de presencia (PoP) con dos trayectos por direccion, donde los paquetes pueden encaminarse por una linea diferente

dependiendo de la carga de trafico de la red. En esa situacion no puede analizarse cada linea por separado por DPI independientes (figura 4) porque cada DPI capturara flujos incompletos. La unica manera de analizar apropiadamente el trafico dispersado en varias lineas es concentrar el trafico con el fin de tener flujos completos (solucion de la figura 5) . Sin embargo esto tiene la desventaja de que es necesario que la DPI procese una unica linea con una tasa de transmision de datos enorme. La solucion no puede escalarse cuando el numero de lineas para concentrar es grande y/o son lineas de alta capacidad. Un problema adicional de este enfoque es la necesidad de un concentrador hardware externo. Ejemplos de estos concentradores pueden encontrarse en las soluciones de Gigamon [5] o las tarjetas de Endace [6]. Para poder analizar elevadas tasas de transmision de trafico es necesario dividir este trafico en diferentes lineas de procesamiento. Esta division del trafico no es trivial porque, tal como se introdujo anteriormente, para una deteccion e interpretacion correctas del trafico es necesario que todos los paquetes de un mismo flujo lleguen al mismo punto de analisis y garantizar su orden cronologico. Este tipo de clasificacion puede implementarse como un equilibrio de carga basado en las cabeceras de los paquetes, aunque debe considerarse que para tasas de transmision de trafico elevadas esta simple operacion se convierte en el cuello de botella de todo el sistema puesto que todo el trafico pasa a traves de este unico punto. La figura 6 representa la implementacion deducida de la solucion presentada por el documento WO2011051750. Su esquema se basa en un unico trayecto de procesamiento, es decir el trafico se captura en un unico punto y todo el trafico se procesa en un unico modulo de deteccion. Como se indico anteriormente, el trafico no puede dividirse facilmente con el fin de replicar el modulo de "deteccion de trafico" y hacer que este sistema sea escalable. Esta arquitectura solo podria analizar mas de una linea de trafico anadiendo a la misma un concentrador, aunque de nuevo, hacer que todo el trafico pase a traves de un unico punto de analisis implica problemas de escalabilidad.

Sumario de la invencion Es necesario ofrecer una alternativa al estado de la tecnica que cubra los huecos hallados en el mismo, particularmente los relacionados con la falta de propuestas que permitan la monitorizacion de trafico solucionando el problema de la escalabilidad de los sistemas DPI actuales mientras que se permita el analisis de multiples trayectos de trafico. A diferencia de las propuestas conocidas, la presente invencion se refiere, en un primer aspecto, a un metodo para monitorizacion de trafico de red, comprendiendo el metodo las etapas de: a) adquirir con un modulo de captura, datos de trafico de una linea de entrada y reenviar dichos datos de trafico a un modulo de deteccion; y b) recibir, dicho modulo de deteccion, dichos datos de trafico para realizar un analisis de inspeccion profunda de datos de dichos datos de trafico recibidos para realizar una deteccion de los mismos, en el que dicha etapa a) comprende, adquirir dichos datos de trafico de al menos dos de dichas lineas de entrada y clasificarlos de modo que dicho reenvio a dicho modulo de deteccion se realice en un orden cronologico para aquellos paquetes pertenecientes a un flujo...

1. Método para monitorización de tráfico de red, que comprende las etapas de:

a) adquirir con un módulo de captura, datos de tráfico de una línea de entrada y reenviar dichos datos de tráfico a un módulo de detección; y

b) recibir, dicho módulo de detección, dichos datos de tráfico para realizar un análisis de inspección profunda de datos de dichos datos de tráfico recibidos para realizar una detección de los mismos,

estando caracterizado dicho método porque dicha etapa a) comprende, adquirir dichos datos de tráfico de al menos dos de dichas líneas de entrada y clasificarlos de modo que dicho reenvío a dicho módulo de detección se realice en un orden cronológico para aquellos paquetes pertenecientes a un flujo específico de dichos datos de tráfico procedentes de dichas al menos dos líneas de entrada siendo enviados al mismo módulo de detección, y porque la detección de dicha etapa b) se realiza por al menos dos módulos de detección para realizar tareas intensas de manera distribuida.

2. Método según la reivindicación 1, en el que dichos datos de tráfico procedentes de dichas al menos dos líneas de entrada se adquieren en dicha etapa a) por al menos dos módulos de captura para realizar tareas intensas de manera distribuida.

3. Método según la reivindicación 1 ó 2, que comprende trabajar en al menos dos niveles diferentes para dicho módulo de captura y dicho módulo de detección.

4. Método según la reivindicación 1, que comprende además equilibrar por igual dicho flujo de dichos datos de tráfico entre dichos al menos dos módulos de detección.

5. Método según la reivindicación 2, en el que cada uno de dichos módulos de captura trabaja independientemente del otro.

6. Método según la reivindicación 1, 4 ó 5, en el que cada uno de dichos módulos de detección trabaja independientemente del otro.

7. Método según la reivindicación 1, que comprende, con el fin de realizar dicha clasificación, analizar la cabecera de dichos paquetes pertenecientes a un flujo específico de dichos datos de tráfico.

8. Método según la reivindicación 7 cuando depende de la reivindicación 6, que comprende determinar a cuál de dichos módulos de detección dicho módulo de captura reenvía dicho paquete perteneciente a un flujo específico de dichos datos de tráfico según la siguiente función:

Módulo de salida = función (encapsulación L2, IP_version, IP_addr_source, IP_addr_dest, layer_4_protocol, port_source, port_dest, output_modules_number)

en la que encapsulación L2 es dicha cabecera; IP_version es la versión de protocolo IP (no IP, v4 o v6) ; IP_addr_source, IP_addr_dest son las IP de origen y destino (en caso de que dicho paquete sea IP) ; layer_4_protocol es el tipo de protocolo (TCP, UDP) ; port_source, port_dest son los puertos TCP o UDP de origen y destino, donde dicho paquete es TCP o UDP, y output_modules_number es el número de módulos en la siguiente fase.

9. Método según la reivindicación 8, que comprende además calcular, sobre el resultado de dicha función, una función hash simétrica con el fin de determinar a cuál de dichos módulos de detección debe enviarse dicho paquete perteneciente a un flujo específico de dichos datos de tráfico, dicha función hash simétrica produce el mismo resultado para paquetes que se desplazan en cualquier dirección.

10. Método según la reivindicación 9, que comprende procesar, cada uno de dichos módulos de detección, dicho paquete recibido y añadir, a dicho paquete, información relevante obtenida como resultado de dicho procesamiento.

11. Método según la reivindicación 1, que comprende dividir la funcionalidad entre diferentes máquinas de hardware para realizar las tareas de dichas etapas a) y b) .

12. Sistema para monitorización de tráfico de red, que comprende:

- un módulo de captura (RX1, RX2, RX3) dispuesto para adquirir datos de tráfico de una línea de entrada (I1, I2, I3) y para reenviar dichos datos de tráfico a un módulo de detección (D1, D2, D3, D4, D5) ; y

- un módulo de detección (D1, D2, D3, D4, D5) dispuesto para recibir dichos datos de tráfico y para realizar un análisis de inspección profunda de datos de dichos datos de tráfico recibidos,

en el que dicho sistema está caracterizado porque dicho módulo de captura (RX1, RX2, RX3) está configurado y dispuesto para adquirir dichos datos de tráfico de al menos dos líneas de entrada (I1, I2, I3) y para clasificarlos de modo que dicho reenvío a dicho módulo de detección (D1, D2, D3, D4, D5) se realiza en un orden cronológico para aquellos paquetes pertenecientes a un flujo específico de dichos datos de tráfico procedentes de dichas al menos dos líneas de entrada (I1, I2, I3) .

13. Sistema según la reivindicación 12, que comprende una estructura modular formada por al menos dos niveles diferentes, un nivel que contiene al menos dos módulos de captura (RX1, RX2, RX3) y otro nivel que contiene al menos dos módulos de detección (D1, D2, D3, D4, D5) .

14. Sistema según la reivindicación 13, en el que el número de dichos módulos de captura (RX1,

RX2, RX3) es independiente del número de dichos módulos de detección (D1, D2, D3, D4, D5) siendo dicho/s módulo/s de captura (RX1, RX2, RX3) y dicho/s módulo/s de detección (D1, D2, D3, D4, D5) configurados, respectivamente, para realizar las etapas a) y b) del método según cualquiera de las reivindicaciones 1 a 13.

15. Sistema según la reivindicación 12, estando implementado dicho sistema en una única 15 máquina.

16. Sistema según la reivindicación 12, estando implementado dicho sistema en un sistema distribuido.

Figura 6 Figura 7

Figura 8 Figura 9

Figura 10 Figura 11

Figura 1º