Reconfiguración automática de la red ante eventos de seguridad

RECONFIGURACIÓN AUTOMÁTICA DE LA RED ANTE EVENTOS DE SEGURIDAD

Juan Sebastian Silva Delgado

David Javier Enrique Méndez Peñuela

UNIVERSIDAD DE LOS ANDES

FACULTAD DE INGENIERÍA

DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN

RECONFIGURACIÓN AUTOMÁTICA DE LA RED ANTE EVENTOS DE SEGURIDAD

Juan Sebastian Silva Delgado

David Javier Enrique Méndez Peñuela

Asesor

Sandra Julieta Rueda Rodríguez, Ph. D.

Profesora Asistente

UNIVERSIDAD DE LOS ANDES

FACULTAD DE INGENIERÍA

DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN

TABLA DE CONTENIDO

ÍNDICE DE TABLAS

ÍNDICE DE ILUSTRACIONES

RESUMEN ... 7

INTRODUCCIÓN ... 9

1

CONTEXTO DEL PROBLEMA ... 10

1.1

Software Defined Networking (SDN) ... 10

1.1.1

Plano de Control y Plano de Datos ... 11

1.2

Precursores de las redes definidas por software ... 12

1.2.1

NCP ... 12

1.2.2

Active Networks... 13

1.2.3

Virtualización De Redes ... 14

1.3

Protocolos ... 17

1.4

Objetivos y Beneficios de SDN ... 18

1.5

Retos y Desafíos ... 20

1.5.1

Escalabilidad ... 21

1.5.2

Desempeño ... 21

1.5.3

Seguridad y Confiabilidad ... 23

1.5.4

Interoperabilidad ... 23

2

EL PROBLEMA ... 25

2.1

Seguridad en SDN ... 25

2.2

Enfoque del Proyecto ... 26

2.2.1

Ataques de Denegación de Servicio (DoS) ... 27

2.2.2

Sistemas de Detección de Intrusos (IDS) ... 30

3

PROPUESTA DE SOLUCIÓN ... 33

3.1

Herramientas ... 33

3.1.1

Pyretic ... 33

3.1.2

Resonance... 34

3.2

Diseño de la Solución ... 36

3.3

Implementación ... 37

3.3.1

Ataques DoS... 37

4

RESULTADOS ... 42

4.1

Mininet ... 42

4.2

Ambiente de Prueba ... 42

4.2.1

Escenario de Pruebas para Ataques DoS ... 42

4.2.2

Escenario de Pruebas para Ataques de Intrusión ... 43

4.3

Resultados ... 44

4.3.1

Resultados de Ataques DoS ... 45

4.3.2

Resultados de Ataques de Intrusión ... 45

5

DISCUSIÓN Y TRABAJO FUTURO ... 50

5.1

Discusión ... 50

5.2

Trabajo futuro ... 51

5.3

Conclusiones ... 53

ÍNDICE

DE

TABLAS

ÍNDICE

DE

ILUSTRACIONES

Figura 1. Arquitectura SDN incluye la separación del plano de datos del plano de control y la comunicación entre planos con el controlador [2] ... 11 Figura 2. Desempeño (eje y) vs. Programabilidad (eje x). Se muestra el trade-off existente entre la programabilidad y la capacidad de procesamiento de los dispositivos. [2] ... 22 Figura 3. Three-way Handshake en TCP/IP. Se ilustra el intercambio de mensajes de control que se lleva a cabo al iniciar una conexión TCP/IP. ... 28 Figura 4. Composición de Módulos en Pyretic. Se presenta de manera ilustrativa la forma en que funciona la composición de módulos en Pyretic. ... 34 Figura 5. Arquitectura Propuesta. Esta figura ilustra la arquitectura usada en este proyecto de grado y el flujo de información entre las entidades involucradas. ... 36 Figura 6. Escenario de Prueba para Ataque DoS. Presenta la topología creada para la simulación de ataques DoS, también se muestran los hosts que participaran en el ataque como atacante, víctima y cliente. ... 43 Figura 7: Escenario de Prueba para Ataque De Intrusión. Presenta la topología creada para la simulación del ataque de intrusión, también se muestran los hosts que participaran en el ataque como atacante, víctima y cliente. ... 44 Figura 8: Respuesta ante un ataque de intrusión. Muestra el mensaje JSON asociado al evento, el registro del evento y la notificación de cambio ... 46 Figura 9: Host Atacante. Ejecución del ataque con nmap. ... 47 Figura 10: Host Victima. Muestra la interrupción de la comunicación desde el host victima hacia el host cliente. ... 48 Figura 11: Host Cliente. Muestra la interrupción de la comunicación desde el host cliente hacia el host víctima. ... 49

RESUMEN

Durante los últimos años, los requerimientos de infraestructura de las organizaciones han cambiado, pasando de un enfoque que solo medía y planeaba en torno a la capacidad de procesamiento, almacenamiento y transmisión de datos, a un enfoque que incluye la facilidad de administración y reconfiguración de las redes. Este movimiento se debe parcialmente al crecimiento y evolución continua de los centros de datos actuales y a las demandas de infraestructura y administrativas que dicho crecimiento genera en capacidades de almacenaje, procesamiento y transmisión de datos.

Como respuesta al constante crecimiento, en cuanto a tamaño y complejidad, de las redes de las organizaciones surgen las arquitecturas de red definidas por software, Software-Defined Networks (SDN). Estas arquitecturas proponen una separación de la red en dos planos: un plano de control (lógico) y un plano de datos (físico). El plano de control se encargaría de tomar las decisiones de configuración y reconfiguración de la red, mientras el plano de datos se encargaría del enrutamiento real de los paquetes a nivel de los dispositivos de red. El enfoque SDN busca, entre otras cosas, reducir la complejidad de las tareas administrativas de la red, proveer al administrador de la red un punto de control centralizado para toma de decisiones e introducir control dinámico sobre la configuración de la red.

Sin embargo, al momento de implementar una arquitectura SDN, hay que tener en cuenta las ventajas y desventajas de este esquema en aspectos como la escalabilidad, el desempeño, la interoperabilidad y la seguridad. Este proyecto se enfoca en el último ítem mencionado: la seguridad. En particular, este proyecto propone aprovechar las características de SDN, para reconfigurar la red de forma automática como respuesta a eventos de seguridad. En este contexto, se propone una arquitectura basada en las herramientas Pyretic [22] y PyResonance [28], que permiten a una red SDN responder ante un ataque de intrusión o de denegación de servicio con la reconfiguración automática de las políticas de la red, de acuerdo con las características del evento generado, como la creación de segmentos de red aislados o en cuarentena o la desconexión de equipos. Se tomó la decisión de evaluar la arquitectura SDN, solamente ante dos ataques representativos, por el límite de tiempo establecido para el desarrollo del proyecto.

La solución propuesta sigue una arquitectura en la que se definen dos elementos fundamentales: un controlador SDN y un conjunto de fuentes de eventos. En el controlador se definen las políticas que especifican cómo reconfigurar la red, o más exactamente los dispositivos que controlan el enrutamiento de los paquetes, si un evento de seguridad ocurre. Las fuentes de eventos son los módulos encargados de analizar el tráfico que fluye por la red para identificar eventos de seguridad.

Para evaluar la arquitectura propuesta, se definieron varios escenarios de prueba compuestos por topologías de red virtuales creadas mediante la herramienta Mininet [29]. La idea es configurar escenarios de pruebas por cada evento de seguridad que estamos considerando. En nuestro contexto, fue necesario configurar dos topologías distintas para poder probar la implementación realizada, debido a las diferentes características de cada evento de seguridad. Encontramos que en los escenarios de evaluación el controlador responde de la forma esperada cuando los eventos de seguridad se generaban. Sin embargo, también encontramos que las fuentes de eventos no se

comportaban de la forma esperada debido a un error de implementación en el lenguaje Pyretic que ya fue reportado a los desarrolladores.

Las contribuciones de este trabajo incluyen:

 La evaluación empírica de las herramientas Pyretic y PyResonance para desarrollo de arquitecturas SDN y los correspondientes reportes de ventajas y limitaciones a sus desarrolladores.

 El diseño e implementación de una arquitectura con dos elementos fundamentales que responde a los objetivos planteados para este proyecto. Aunque la implementación actual de la arquitectura solo incluye componentes de respuesta a los dos eventos de seguridad que eran objetos de este estudio, la arquitectura está diseñada de tal manera que puede ser extendida para responder a otros eventos. Solo sería necesario diseñar e implementar las fuentes correspondientes y las políticas adecuadas en el controlador.

 Con base en la experiencia que adquirimos en el desarrollo de este trabajo, planteamos algunos caminos a seguir en trabajos futuros. Entre ellos están la evaluación del desempeño y la seguridad del controlador, pues este elemento se está convirtiendo en un punto crítico de las arquitecturas SDN y la integración de elementos para ofrecer calidad de servicio QoS.

INTRODUCCIÓN

Desde hace algunos años se han venido presentando ciertos eventos, como el creciente uso de servidores virtualizados o el aumento en la oferta y el uso de servicios basados en cloud, que han hecho necesario reconsiderar las arquitecturas de las redes de comunicaciones que, hasta ahora, se han venido usando. La necesidad de una nueva arquitectura de redes se hace evidente si se analizan las tendencias y los requerimientos de las aplicaciones actuales.

Los requerimientos en cuanto a infraestructura han cambiado debido a cambios en los patrones de tráfico (necesidad de comunicar un mayor número de servidores entre sí, al interior de los data center), el auge de los servicios en cloud (las empresas incrementaron su uso de cloud ampliamente, lo que hace que los proveedores de cloud refuercen su infraestructura en cuanto a seguridad y administración de uso de recursos), el manejo de enormes cantidades de datos (el procesamiento de tales cantidades de información requiere de varios servidores que a su vez, necesitan comunicarse entre sí), entre otros factores. Ante tales requerimientos, las arquitecturas actuales, generalmente jerárquicas, se ven limitadas. Al incrementar el tamaño de las redes generalmente surgen problemas administrativos sobre las mismas. En grandes data centers, en donde el número de hosts puede alcanzar el orden de miles, con arquitecturas tradicionales, las configuración de políticas de seguridad o de calidad de servicio pueden ser extremadamente complejas. Debido a esto y también al error humano se pueden generar estados con inconsistencias en las políticas y en el estado de la red en general. Las anteriores son solo algunas de las limitaciones que tienen las arquitecturas de red tradicionales.

Con el ánimo de hacer frente a los problemas mencionados y satisfacer las necesidades de las aplicaciones actuales surgen las arquitecturas de redes definidas por software, Software-Defined Networking (SDN). Las redes SDN separan los planos de control y datos y plantean un enfoque administrativo centralizado sobre el comportamiento de la red. El control centralizado facilita automatizar las tareas de configuración de la red y la implementación de políticas consistentes a través de toda la red. Las redes SDN también ofrecen la posibilidad de administrar de forma centralizada los dispositivos de red, independientemente de su fabricante, proveer un control más granular en las redes y reducir la complejidad de las tareas de mantenimiento de las redes, entre otros.

Las redes SDN también ofrecen la posibilidad de reconfigurar una red de forma dinámica ante ciertos eventos. Este proyecto de grado propone el estudio detallado de esta característica, desde el punto de vista de la seguridad de la información y las aplicaciones. Una red SDN puede responder de forma dinámica y ajustarse a eventos de seguridad, por ejemplo, una red SDN puede responder a la identificación de un ataque a nivel de red o a una alerta generada por un componente externo a la red misma.

Por la gran cantidad de ataques que pueden ocurrir, el proyecto se concentrará en la evaluación de las características de SDN en dos contextos particulares: ataques de denegación de servicios, DoS, e intrusiones. En el caso de detección de este tipo de eventos, la red debe generar las políticas necesarias para contener el ataque, es decir, debe reconfigurar “en caliente” los dispositivos de red para ejecutar respuestas como descartar los paquetes que corresponden a un ataque o aislar un segmento de red por protección.

Si bien este proyecto plantea el estudio de estos dos tipos de eventos, el objetivo es construir una arquitectura que se pueda extender fácilmente para responder a otros eventos de seguridad.

1

CONTEXTO

DEL

PROBLEMA

Este capítulo presenta una visión general de las arquitecturas definidas por software, SDN, sus componentes fundamentales, evolución y ventajas. Además, se mencionan y elaboran los retos generales que emergen en este contexto y en particular los que tienen que ver con la seguridad de los dispositivos de red y de las aplicaciones.

1.1

Software Defined Networking (SDN)

SDN (Software Defined Networking) es un tipo de arquitectura de red en la cual se lleva a cabo una separación del plano de la red de datos del plano de control. Mientras el plano de datos corresponde al conjunto de dispositivos de red mediante los cuales se realiza el reenvío del tráfico en la red, el plano de control corresponde a la lógica que administra y controla tanto el tráfico, como la manera mediante la cual este fluye a través de la red. A raíz de esta división entre el plano de datos y el plano de control se han planteado 2 aspectos diferenciadores con respecto a las arquitecturas de red actuales: (1) el plano de datos deberá ser programable y (2) la posibilidad de mejorar el desempeño y la administración de las operaciones a través de las diferentes aplicaciones que se podrán comunicar con el plano de control a través del Northbound API; el Northbound API determina la manera como son expresadas las diferentes tareas operacionales así como las políticas y las traduce para que el controlador pueda entenderlas [1]. La Figura 1 presenta algunos de los componentes con los que el controlador debería establecer comunicación, esquema de comunicaciones también conocido como Northbound API.

Figura 1. Arquitectura SDN incluye la separación del plano de datos del plano de control y la comunicación entre planos con el controlador [2]

1.1.1 Plano de Control y Plano de Datos

Los dos elementos más importantes en SDN corresponden al Plano De Control y al Plano De Datos.

El primero de ellos es considerado como el cerebro de SDN ya que computa y ejecuta toda la lógica que determina cómo fluirá el tráfico a través de la red con base en las políticas definidas de alto nivel. Como se ha mencionado previamente, el plano de control corre de manera independiente a toda la gama de elementos o dispositivos de red que se encuentren en la infraestructura. Por otra parte el plano de datos puede ser visto como todo el hardware programable que es administrado y controlado por el plano de control; es decir, corresponde a los diferentes nodos en la red que pueden enrutar o reenviar el tráfico de la misma con base en las reglas definidas en la lógica del plano de control.

Dicho diseño, plano de datos y plano de control independientes, garantiza separación; lo cual permite, entre otros, que el usuario controle la configuración y ejecución de tareas de red a través de un programa de alto nivel. Entre estos programas se incluye software que facilita el proceso de desarrollo, debug y check de la manera en la cual opera la red.

Entre los ejemplos que evidencian las facilidades y oportunidades que ofrece la separación de planos está Yahoo [9]. Yahoo lleva a cabo el proceso de migración de los data centers utilizando

tecnología SDN para reprogramar los Switches de la infraestructura y así desviar el tráfico que llega a los data centers sin afectar la sincronización en los dispositivos y la continuidad en el servicio que está prestando. Otro ejemplo es la reacción y respuesta que plantea AT&T IRSCP [10] para un ataque DoS; aquí lo que se hace es identificar los ataques, así como los puntos de entrada y la víctima a la cual va dirigido el ataque, con dicha información se aplican filtros sobre el tráfico del ataque en los puntos de entrada consiguiendo la mitigación o cancelación del ataque DoS.

1.2

Precursores de las redes definidas por software

Las redes SDN surgieron a partir de una observación que se realizó sobre las redes distribuidas donde cada dispositivo de red estaba configurado de forma independiente a los demás, el ambiente era propenso a bugs y el comportamiento de los dispositivos era impredecible dada su configuración y programación a bajo nivel. A partir de esta observación se adelantaron tareas de análisis que tenían como objetivo predecir el comportamiento de la red basándose en los archivos de configuración; con este análisis sería posible desarrollar una herramienta que solucionara o por lo menos mitigara los problemas que emergía en dicho ambiente.

1.2.1 NCP

Lo anterior llevó al origen de BGP, Border Gateway Protocol, el actual protocolo de enrutamiento entre sistemas autónomos (grupo de routers que están bajo el mismo control administrativo). BGP le permite a cada sistema (1) conseguir información acerca del alcance que tienen las subredes de los sistemas autónomos vecinos; (2) enviar información sobre el alcance que tiene el sistema autónomo a todos sus routers y (3) determinar “buenas” rutas para llegar a una subred con base en el alcance que tiene el sistema autónomo y las políticas que este tiene definidas [23]. Por lo anterior BGP se caracteriza por ser una arquitectura con un router central denominado RCP; seguido de ella surgió 4D como posible solución a la dificultad que hay para administrar las redes IP; para ello las funciones de control de red se encuentra divididas en 4 planos: (1) El plano de decisión (Decision) crea la configuración de red; (2) El plano de diseminación (Dissemination) reúne la información sobre el estado de la red y actúa como canal de comunicación entre los routers y el plano de decisión; (3) el plano de descubrimiento (Discovery) brinda a los dispositivos la información sobre el estado de sus vecinos y (4) el plano de datos (Data) es el encargado de reenviar el tráfico en la red. [27]

Además, inicialmente la capa de control y la capa de datos operaban juntas en el mismo canal; en un esquema denominado in-band signaling. La forma por la cual se puede diferenciar los mensajes de diferentes planos en in-Band signaling es asignado frecuencias diferentes para cada capa. En principio este esquema de operación favoreció la simplicidad, en cuanto a administración y control, pues todo era enviado sobre un mismo medio, sin embargo, dicha decisión tiene un fuerte impacto sobre la seguridad pues si el canal está comprometido o falla entonces se pierde toda comunicación de control y datos.

Para los años 80’s AT&T tomó la decisión de separar el plano de datos del plano de control y denominó a este último Punto de Control de Red (NCP) [3]. Esta arquitectura en particular fue diseñada para la red de telefonía ya que les permitía a los operadores ofrecer nuevos servicios. Adicionalmente presentaba características como la implementación de la tarificación en la NCP

que le permitía a los operadores obtener información adicional acerca de los consumidores gracias a la comunicación que se llevaba a cabo entre la NCP y un base de datos de usuarios, la posibilidad de desplegar servicios de acuerdo con la demanda que se experimentara en un momento dado, así como la facilidad para introducir nuevos servicios de forma rápida y ágil. Claramente esta solución permitía eliminar por completo el modelo de in-band signaling que se venía manejando desde años anteriores, garantizando así una reducción en los gastos incurridos por parte de los proveedores pues con la nueva arquitectura era posible reducir el tiempo durante el cual se ocupaba una línea. Por otra parte dicho diseño facilitaba la implantación de nuevas funcionalidades por las cuales era posible determinar la congestión o el estado de un circuito antes de solicitarlo, garantizando así una ubicación eficiente y rápida de los recursos que iban a ser empleados. Esta arquitectura fue una primera aproximación a la evolución independiente entre la infraestructura y los servicios ofrecidos como resultado de la separación entre planos.

1.2.2 Active Networks

Tras el desarrollo de NCP por parte de AT&T [4] surgió un nuevo patrón de comunicación de redes denominado Active Networks. En dicho patrón se describen redes en las cuales los Switches presentan un desempeño personalizado y basado en la computación de paquetes. Active Networks comenzó a mediados de los 90’s cuando DARPA discutió acerca de la dificultad que existía en ese entonces para integrar las nuevas topologías en la red, así como para la introducción o adecuación para nuevos servicios, y adicionalmente el problema de repetición en las múltiples capas de las diferentes operaciones que debían realizarse para el procesamiento de los paquetes, lo cual conlleva un desempeño probe. Fue así como Active Networks basó su desarrollado en la motivación que existía por la innovación acelerada y el despliegue de nuevos prototipos.

Se concluyó que para lograr los objetivos establecidos para Active Networks se debía realizar un diseño tal que los paquetes llevaran tanto los datos como los procedimientos necesarios para poder operar dichos datos. Con ello se requería que cada Switch de la arquitectura pudiese desempeñar un proceso adicional a los que venía desempeñando anteriormente. En consecuencia se plantearon 2 posibles soluciones. La primera de ellas fue denominada Integración o Cápsulas [4]; el objetivo aquí era que cada paquete o mensaje en la red cargaba un programa el cual podía ser evaluado en cualquier punto de la red gracias al ambiente de ejecución que existía tanto en los routers como en los Switches. La segunda opción, llamada Discreta o con Switches programables [4], consistía en Switches los cuales se caracterizaban por ser programables; gracias a ello en estos elementos era posible instalar el código y habilitarle al Switch la posibilidad de realizar operaciones o funciones características en los paquetes dependiendo del encabezado que estos tuviesen.

1.2.2.1 Proyectos de Active Networks

Esta sección presenta una visión general de algunos de los proyectos que implementaron alguna de las 2 opciones antes descritas, cápsulas o switches.

 El proyecto ANTS [4], desarrollado por el MIT, plasmaba la implementación de la solución de capsulas de paquetes. Este proyecto fue desarrollado en Java de forma tal que los programas Java eran cargados y transportados en los paquetes. Debido a las

características de Java, la calidad de servicio (QoS) se vio afectada fuertemente; Java introdujo elementos que no permitían garantizarla, por ejemplo, el consumo excesivo de recursos como memoria o CPU que usa Java para sus operaciones restringe el tamaño de los recursos que pueden ser destinados para aplicar QoS [5].

 A causa de ello fue necesario implementar el Joust JVM, un ambiente que …, por medio del cual se consiguió mejorar el desempeño real-time [4].

 Por otra parte SwitchWare, implementado por Pennsilvania [4], y Tempest, diseñado por Cambridge [4], implementaban la opción de Switches programables. SwitchWare utilizó un lenguaje de scripts, mientras que Tempest además de la programación manejaba virtualización. Sin embargo, su implementación y desarrollo fue posible solo 20 años después de su diseño, por la ausencia de hardware con capacidad para ajustarse y soportar la red de la capa de datos, así como la falta de claridad que existía en ese entonces acerca de qué tipo de aplicaciones podrían aprovechar dicho diseño o qué tipo de aplicaciones se podría usar sobre la red; adicionalmente vale la pena recordar que para esa época se dio inicio a los data-centers y Cloud por lo que Tempest se encontraba en desventaja con respecto a los demás diseños.

 Finalmente tenemos el proyecto OpenFlow, desarrollado por la Open Networking Foundation (ONF) [4], que se caracteriza por haber desarrollado la actualización del firmware que permita soportar las diferentes operaciones básicas necesarias y que pueda ser usados en los Switches.

1.2.3 Virtualización De Redes

Seguido de las Active Networks se dio paso a la Virtualización de redes. La virtualización de redes fue definida como el mecanismo o la manera mediante la cual era posible representar una o más topologías de red de forma lógica, con la particularidad de que dichas redes virtuales o lógicas se encontraban desplegadas sobre la misma infraestructura física sin que estas intervengan o se vean afectadas entre sí. Un ejemplo de este concepto son las redes locales virtuales, Virtual LANs, o las redes tipo TestBeds. La virtualización surgió con el deseo de diseñar, desarrollar e implementar una infraestructura que le permitiera a las diferentes tecnologías de red evolucionar de forma independiente a la infraestructura sobre la cual estaban desplegadas, esta independencia incentiva la innovación rápida; es decir, la posibilidad de entregar servicios en poco tiempo. También se favorecía el diseño y desarrollo de nuevas maneras de controlar la red ya que por medio de la virtualización se podían instanciar múltiples redes lógicas sobre la misma infraestructura física y en cada una de las redes lógicas es posible probar los diferentes tipos de control que se hayan creado. Por último, a nivel de mercado se abrió la posibilidad de que el operador, o el cliente, tuviera la oportunidad de escoger el vendedor que mejor se ajustara a sus necesidades, gracias al desacople que se logró entre la red y la infraestructura física.

Los beneficios principales obtenidos por la virtualización de redes son 2:

 Compartir la infraestructura. Los recursos, como CPU, memoria, y ancho de banda, deben ser administrados y reservados de acuerdo con los nodos lógicos que se encuentren instanciados sobre el mismo nodo físico, por ejemplo, teniendo 1 solo nodo físico que podría ser un router o un Switch y queriendo virtualizar 2 routers con capacidades específicas es necesario llevar a cabo un proceso de aislamiento y administración de los recursos del router de forma que los enrutadores virtualizados cuenten con las

capacidades definidas. Al final el aislamiento y repartición de los recursos de los nodos o elementos físicos permite mejorar la distribución y con ello mejorar la optimización en el uso de los mismos.

 Mejorar la caracterización que los usuarios pueden realizar sobre sus redes. Al tener la opción de ofrecer una vista de las unidades lógicas de la red propias al usuario entonces se podía llevar a cabo la definición del mecanismo de enrutamiento y reenvío propio a la red virtual. Vale la pena aclarar que la vista que tiene el usuario sobre su propia red implica, en el trasfondo, una separación entre las diferentes redes virtuales.

Entre los elementos que pueden ser virtualizados se encuentran los nodos o máquinas virtuales, los links; los cuales pueden llegar a ser virtualizados por medio de túneles; y finalmente el almacenamiento. Por otra parte las funciones que mencionamos previamente de administración y aislamiento de recursos son realizadas por la capa de virtualización que a su vez ofrece el soporte necesario para que las diferentes redes virtuales puedan coexistir y funcionar en paralelo sobre una misma red física compartida.

Para cumplir con los objetivos de la virtualización y alcanzar los beneficios asociados con la misma es necesario resolver algunos. A continuación presentamos los que consideramos los cinco más importantes. El primero de ellos, como toda infraestructura o arquitectura, es la flexibilidad; las redes virtuales deben soportar diferentes tipos de topologías, enrutamientos, y rutas, entre otros, que pueden llegar a ser configurados por el cliente o usuario de forma independiente a las demás redes. El segundo reto corresponde a la administración de las redes virtuales, debe ser posible administrar las diferentes redes lógicas, así como la separación de las políticas de cada una. Si bien lo que se quiere es la opción de desplegar múltiples redes lógicas sobre una misma red física, lo que menos se quiere es que las políticas de las diferentes redes se combinen entre sí e interfieran con el desempeño de las demás redes. El tercer reto es la escalabilidad que se debe alcanzar con la infraestructura física; la posibilidad de optimizar el uso de los recursos de los nodos físicos debe permitir maximizar el número total de redes virtuales que puedan ser desplegadas y soportadas por una misma red física. El cuarto reto está muy asociado con la administración de las redes virtuales y corresponde al aislamiento y seguridad de las mismas; es decir, no basta solo con administrar y proveer los recursos que necesita cada red sino que también es necesario llevar a cabo una separación o aislamiento tanto de redes como de recursos que permitan asegurarle a la red lógica la disponibilidad y uso de los mismos sin que llegue a existir interferencia alguna por parte de otras redes. El último reto corresponde a la posibilidad de programación de las diferentes redes virtuales; esto con el objetivo de brindarle al usuario la opción de caracterizarlas, como se dijo anteriormente, y, por otra parte, de conseguir el soporte para diferentes tecnologías.

1.2.3.1 Proyectos de Virtualización De Redes

Entre los proyectos de virtualización de redes que buscaban solucione para los retos mencionados encontramos Tempest, VINI y CABO. Tempest [5] [2], implementa un framework de control de Switches que además los puede virtualizar. Con ello se tiene la posibilidad de ofrecer múltiples Switches virtuales que recaen sobre un mismo Switch físico. El motivo por el cual incluyeron esta característica en Tempest es soportar y administrar múltiples arquitecturas, en particular, se buscaba el control de diferentes arquitecturas sobre la red ATM. El elemento fundamental en este proyecto es el Divisor, este elemento permite la separación entre el controlador del Switch y del dispositivo, ofrece al usuario una visión sobre los controladores del Switch lógico, y permite dividir y administrar los recursos que necesitan los diferentes controladores.

VINI [5], Virtual Network Infrastructure, como Tempest, busca proveer una infraestructura de red virtual que ejecuta software real de enrutamiento y cuenta con condiciones reales de red. Adicionalmente, con VINI es posible: (1) enviar tráfico simulado y (2) controlar los diferentes eventos que acontecen sobre la red. Estas características le permiten al usuario llevar a cabo diferentes experimentos sobre la misma infraestructura sin que alguno de ellos afecte el comportamiento de los demás. Lo que más llama la atención de VINI es su software de enrutador (XORP) que se encarga de instanciar la capa de control, XORP cuenta con diferentes protocolos de enrutamiento lo que permite a los usuarios extender aún más el escenario de pruebas y las condiciones de sus experimentos; con VINI tienen la posibilidad de experimentar el enrutamiento final con diferentes protocolos sobre las diferentes topologías.

El objetivo principal de CABO [5] es darle la oportunidad a los proveedores de servicio de operar de forma independiente a los operadores de infraestructura de red que se encuentran disponibles. Por ejemplo, se tiene el caso en el cual múltiples ISP pueden compartir enrutadores como puntos de intercambio y aun así siguen operando de forma normal sin ningún riesgo y amenaza que recaiga en la continuidad del servicio. Un caso en particular es FON [5] –un proveedor de servicio de internet- cuyo negocio se basa en comprar el UpStream de los diferentes proveedores de infraestructura y ofrecérselo como servicio de internet a los diferentes usuarios de conectividad wireless.

Otros proyectos buscan los mismos objetivos. Flow Visor [5] puede desplegar y poner en funcionamiento la infraestructura experimental junto con la red de producción, adicionalmente Flow Visor toma un subconjunto no crítico del tráfico real y lo reenruta a través de la infraestructura experimental lo que permite tener un ambiente real de pruebas. Nicira, Network Virtualization Platform, provee toda una capa abstracta, administrada por un controlador, entre el host y la red.

Cada uno de estos proyectos permitieron el avance hacia arquitecturas SDN. En particular, SDN adquirió y adecuo las ideas de: ofrecer funciones programables en la red de forma que se incentive a la innovación, hacer uso de la información que traen consigo los paquetes que viajan a través de la red para determinar el mecanismo o modo por el cual estos deben ser desmultiplexados, promover –de igual forma a como lo hace la virtualización de redes- la separación entre los proveedores de servicio y proveedores de infraestructura; y estructurar el diseño de SDN con la meta de poder exponer múltiples topologías lógicas de red que recaigan sobre una misma infraestructura física. Sin embargo, vale la pena resaltar que a pesar de que SDN tiene implementadas muchas de las ideas que emergieron en el contexto de la virtualización de redes, existe gran variedad de diferencias entre estos dos esquemas; la principal consiste en que la virtualización de red busca separar la red lógica de la red física, mientras que SDN separa el plano de datos del plano de control.

Hasta este punto ya hemos recorrido los puntos clave en la evolución hacia SDN ahora procedemos a dar una descripción de los puntos más importantes de SDN así como las aproximaciones o posibles soluciones que se le dan a los diferentes problemas que tiene que afrontar.

1.3

Protocolos

Una de las características más importantes de SDN radica en los protocolos a implementar. Como se dijo al inicio de este documento, en SDN es posible tener una vista amplia de la red permitiéndole al usuario analizar e inferir el comportamiento de la red. Además, SDN separa entre el plano de control y el plano de datos incentivando la innovación rápida; al no existir dependencias entre la lógica de control y el hardware, ambos pueden evolucionar de acuerdo a sus propias posibilidades. SDN debe implementar protocolos que soporten los objetivos planteados.

LA IETF, Internet Engineering Task Force, propone la creación de interfaces especializadas, llamadas FORCES, para administrar los switches y diferentes elementos de reenvío de paquetes [6] [7]. Las interfaces serían el canal de control estándar. Sin embargo, uno de los obstáculos que tiene FORCES para su implantación sobre SDN es que requiere la estandarización y adopción del protocolo por parte de los vendedores de forma tal que el nuevo hardware pueda ser desplegado con el soporte necesario.

La segunda opción es el ya conocido RCP, Routing Control Platform, cuyo objetivo es reusar los canales y protocolos que ya existen para realizar el envío de mensajes de control hacia los diferentes elementos o nodos de la red. Bajo este esquema, cada red operativa independiente cuenta con su propio RCP quien tiene como tarea el administrar las diferentes rutas y hacérselas saber a los enrutadores; para esta última tarea se puede hacer uso de BGP como canal de control con los enrutadores. Sin embargo, esto genera cierta dependencia hacia el canal que se use; es decir, con base en los protocolos que se utilicen se tiene o no, un control sobre todo el rango de comportamientos que hay en los protocolos utilizados.

La tercera opción es Ethane [6] [2]; gracias a este protocolo es posible garantizar de forma directa el cumplimiento de las políticas de red bien detalladas sobre SDN. Ethane cuenta con un controlador de dominio con la capacidad de computar el flujo de entradas de las tablas de los diferentes Switches en la red basado en las políticas de control de acceso que el administrador o usuario haya definido. No obstante, el despliegue de Ethane requiere switches propios para el protocolo lo cual se convierte en su principal problema.

La última opción que incluimos en esta parte es OpenFlow [1] [6] [7] [8]. Uno de los objetivos de OpenFlow es explotar las capacidades del hardware por medio del control del comportamiento de dicho hardware. Para cumplir este objetivo se incluyó en la definición y diseño de OpenFlow un controlador aparte que se encarga de comunicarse con un Switch y en particular con la tabla de flujo del Switch, a fin de administrarla, es decir, de instalar, modificar y eliminar entradas en la tabla de enrutamiento del Switch. Estas entradas controlan y definen las acciones a seguir para el reenvío de los paquetes. Para la implementación de este esquema sólo hizo falta convenir con los diferentes vendedores de Switches para abrir la interfaz que comunica al controlador con la tabla de flujo.

1.4

Objetivos y Beneficios de SDN

El desarrollo del paradigma que propone SDN, no se debe a un evento casual o esporádico. La idea de centralizar el control de una red responde a una serie de necesidades que han tenido y actualmente tienen los operadores de las grandes redes de telecomunicaciones. En particular, las principales necesidades de los operadores son en materia de administración de políticas en las redes, al igual que en la configuración de cambios dinámicos sobre la red. En este orden de ideas, la implementación de SDN tiene como objetivos o metas generales los siguientes:

· Separación de los Planos de Control y Datos en la infraestructura de red.

La separación de los planos de control y datos en la red es el elemento central de la arquitectura SDN. Al realizar esta separación, se permite un desarrollo independiente en cada plano de la red, generando nuevas oportunidades de innovación y desarrollo a diferentes ritmos en cada plano. De esta manera, el software de control de la red puede evolucionar independientemente de las restricciones de software que cada fabricante de dispositivos (Ej.: switches, routers, etc.) aplique.

El hecho de realizar esta separación también permite realizar un control centralizado y de alto nivel de la red. Esto permite la modificación del comportamiento de toda la red desde un punto central y a su vez facilita el monitoreo y la depuración de la red, en caso de que sea necesario.

· Disminuir Dificultad de Administración y Mantenimiento de la red.

Actualmente, la complejidad de algunas infraestructuras de red hace muy difícil y tedioso el hecho de reconfigurar parámetros de red o implementar nuevas políticas. La naturaleza distribuida de las redes actuales hace necesario que al momento de instalar una nueva política, los operadores de red tengan que configurar manualmente cada dispositivo de la red. Todo esto haciendo uso de un número limitado de instrucciones mediante consolas de línea de comando.

Al existir un punto central de administración de la red, el mantenimiento de grandes redes, al igual que la implementación de políticas de alto nivel se hace mucho más fácil para el operador. Con SDN los dispositivos de red se convierten en simples dispositivos de envío de paquetes, que conformarán el plano de datos de la red. De esta manera el control y manejo de la lógica de la red se ubican en el controlador, quién tiene una vista de la red en su totalidad, lo cual simplificaría los procesos de mantenimiento sobre la misma.

· Introducir un control dinámico de la topología de red.

Además de los problemas administrativos de las redes actuales, los operadores también se encuentran con algunos problemas a la hora de diseñar las políticas a implementar en la red. El estado actual de las redes de comunicaciones sólo permite implementar políticas que responden o que se ajustan a un estado estático de la red.

SDN pretende proveer un control dinámico de la topología de red. Esto quiere decir que debido a que el estado de la red varía con respecto al tiempo (tipos de tráfico, cantidad de paquetes, etc.), las políticas de la red deberían comportarse de igual manera. Este nuevo paradigma en el diseño de redes pretende permitirles a los operadores implementar políticas dinámicas, que reconfiguren el estado de la red como respuesta a cierto tipo de eventos.

Uno de los principios que proclama la ONF, organización que está en la tarea de la divulgación y estandarización del uso de tecnologías de SDN, es que la implementación de estas nuevas tecnologías trae varios beneficios tanto para las empresas como para los operadores de servicios. Con la idea de que la infraestructura de red pueda ser un factor diferenciador para sus negocios, más allá de un simple gasto; la ONF busca la que este tipo de organizaciones se interesen cada vez más en soluciones SDN [4]. Entre los beneficios que provee una arquitectura SDN se encuentran:

. Control Centralizado de Ambientes de Proveedores Diferentes.

El control de software que propone SDN permite controlar cualquier tipo de dispositivo de red independientemente del fabricante. Esto les da mayor libertad a los operadores y administradores de red de las organizaciones, al no tener que dedicar varios grupos de administración para los dispositivos de cada proveedor y en cambio aprovechar herramientas de configuración rápida para configurar y actualizar los equipos de toda la red.

. Complejidad reducida a través de automatización.

Algunas tareas de administración en las redes que son hechas a mano actualmente, pueden ser automatizadas gracias al framework que SDN ofrece. La automatización de este tipo de tareas busca reducir la sobrecarga operacional y eliminar el error humano a la hora de implementar políticas, lo cual puede ocasionar estados inestables en las redes de hoy. De igual manera, al hacer automáticas estas tareas se pretende, según la ONF, dar soporte a modelos de abastecimiento autosuficientes y ofrecer TI como servicio.

. Mayor tasa de innovación.

La separación de los planos de control y datos, permite una aceleración en la innovación del negocio ya que permite a los operadores de red programar y reconfigurar el estado de la red en tiempo real para responder a las necesidades del negocio. La posibilidad de abstraer la infraestructura de red para cada servicio, permite a los operadores realizar modificaciones sobre la red a la medida de los servicios e introducir nuevos servicios en tiempos muy cortos.

. Incremento de la confiabilidad y seguridad en la red.

Gracias a SDN, los operadores de red tienen la posibilidad de definir políticas de seguridad de alto nivel que aplican a toda la red. Esta característica de SDN elimina el esfuerzo manual de los operadores de configurar uno a uno todos los dispositivos de red para implementar las políticas de seguridad o para modificar una política ya existente. Al eliminar este factor, ser reduce también la probabilidad de una inconsistencia o fallas de configuración en los nodos. Además, ya que el controlador SDN debe tener una vista completa de la red, es posible implementar no solo políticas de seguridad, sino también de calidad de servicio o control de acceso y corroborar que efectivamente las políticas están siendo aplicadas correctamente.

. Control de la red más granular.

La alta programabilidad que ofrece el plano de control de SDN, permite a los operadores diseñar e implementar políticas de red incluso a nivel de sesión de usuario o de aplicación. Esta característica, en ambientes cloud, permite dar soporte al aislamiento de tráfico, seguridad y administración elástica de recursos cuando los clientes comparte la infraestructura física.

. Mejor experiencia del usuario.

El enfoque de control centralizado que ofrece SDN y el hecho de que en el controlador se tiene una vista completa de la red, hace que la infraestructura de red sea más dinámica y adaptable a las necesidades de los usuarios, en este caso, principalmente operadores de red. En el caso de un proveedor de servicios, la infraestructura puede adaptarse al tipo de servicio que se quiere ofrecer. Por ejemplo, en caso de que un operador decida transmitir video, el esquema de SDN, permitirá a la aplicación detectar el ancho de banda disponible en la red y ajustar la calidad del video para ser transmitido en estas condiciones.

1.5

Retos y Desafíos

SDN pretende cambiar para bien la forma en que se administran las redes actualmente. La adopción de este tipo de arquitecturas, busca reducir la complejidad y aumentar la efectividad de los procesos administrativos en las redes, en especial en las grandes infraestructuras de red que poseen algunos proveedores de servicios o grande multinacionales. Esto contribuiría a reducir significativamente los costos administrativos en redes empresariales y de proveedores de servicios. Estas metas pueden ser algo ambiciosas, y en el camino a cumplirlas las arquitecturas SDN deben lidiar con varios desafíos que se pueden presentar.

1.5.1 Escalabilidad

A partir de la separación de los planos de la red, surgen preguntas sobre SDN. La presencia de un controlador en la red hace necesario que al momento de recibir un paquete, el dispositivo de red busque en su tabla de flujo una entrada que corresponda con el nuevo paquete y realice la acción asociada a esta entrada. Si no se encuentra una entrada en la tabla de flujo, el paquete es enviado al controlador, y éste debe decidir qué acción debe realizar el dispositivo sobre el paquete en cuestión. Ahora, el controlador y los dispositivos no solo intercambiarán tráfico de la red, sino también, por medio de un canal seguro, se transmitirán mensajes de control y de información de la red. Este mecanismo puede funcionar bien a pequeña escala, pero al trasladarlo a grandes infraestructuras de red puede ocasionar problemas de latencia debido a la gran cantidad de nodos que pueden llegar a existir en la red.

El anterior es uno de los desafíos a los que se enfrentan las nuevas arquitecturas bajo el enfoque de SDN. Se han desarrollado diferentes propuestas para afrontar este desafío en particular. Una de ellas propone la creación de una infraestructura peer-to-peer (P2P) de controladores, para que de esta manera un grupo de ellos pueda encargarse de la comunicación con los nodos de la red. De hecho, esta propuesta introduce un nuevo problema en cuanto a escalabilidad para las arquitecturas SDN, y hace referencia a cómo ocurre la comunicación entre controladores, haciendo uso de east y westbound API’s. Lo anterior, teniendo en cuenta que cada controlador requiere de una vista completa de la red. [2]

Los problemas de escalabilidad mencionados antes no son nuevos. Varios grupos e instituciones han venido trabajando en posibles soluciones a este tipo de problemas. En este marco, se desarrolla HyperFlow [1]. HyperFlow es una aplicación para los controladores que permite implementar un plano de control distribuido. El funcionamiento de HyperFlow se basa en la propagación selectiva de eventos que cambian el estado de configuración en la red. Cada controlador reenvía los eventos publicados para reconstruir el estado de la red, logrando así que todos los controladores compartan un estado consistente de la red.

1.5.2 Desempeño

Otro tema a considerar es el manejo del desempeño en el procesamiento de paquetes. El procesamiento de flujos de información con altos requerimientos de seguridad y latencia debe ser manejado eficientemente. En este sentido, es necesario contemplar dos enfoques para evaluar el desempeño en procesamiento. Uno es el desempeño como tal a la hora de procesar el paquete, teniendo en cuenta throughput y la latencia asociada. Y el otro factor es la programabilidad de los dispositivos de red, lo cual se refiere a la capacidad de los dispositivos de modificar y aceptar conjuntos de instrucciones que modifiquen el comportamiento funcional de la red. Estos dos factores generalmente generan un trade-off, lo cual significa que si el desempeño o la capacidad de procesamiento de un dispositivo es muy bueno, la programabilidad de este tipo de dispositivos puede no ser muy amplia. De forma similar se espera que un dispositivo altamente programable no tenga una gran capacidad de procesamiento.

Un factor que impulsa a la mejora de la capacidad de procesamiento de los nodos de una red, es la gran velocidad de transmisión que los enlaces de la red están alcanzando. Con el objetivo de aprovechar estas capacidades de transmisión se hace necesario, que los nodos alcancen una

capacidad de procesamiento similar. Lo que quiere decir que se requieren capacidades de procesamiento del orden de 100Gb/s. [2]

Figura 2. Desempeño (eje y) vs. Programabilidad (eje x). Se muestra el trade-off existente entre la programabilidad y la capacidad de procesamiento de los dispositivos. [2]

En la figura 1 se muestran las tecnologías de procesamiento disponibles para los nodos de una infraestructura de red. Se ilustra el trade-off existente entre desempeño en procesamiento y programabilidad. A continuación, se describen brevemente estas tecnologías mostrando las diferencias entre ellas.

Tipo de Tecnología Desempeño Programabilidad

CPUs/GPPs (Procesadores de Propósito General)

Restringido por la arquitectura de propósito general. Bajo desempeño aunque es posible incrementar considerablemente su capacidad al hacer uso de varios núcleos.

Programables mediante lenguajes de alto nivel y herramientas de diseño.

NPUs/NFPs (Procesadores de Flujo de Red)

Arquitectura orientada al procesamiento en red. Tienen aceleradores de hardware dedicados e interfaces para reducir la disipación de potencia.

Reducida debido a que se requiere un conocimiento más profundo del dispositivo para configurar las reglas de flujo de paquetes.

PLDs/FPGAs (Dispositivos Lógicos Programables )

Ideal para implementar rutas de datos paralelas asociadas a funciones de procesamiento de red.

También son configurados usando herramientas de diseño de hardware.

ASSPs (Productos Estándar para Aplicaciones Específicas)

Son productos de capa 2 y 3 destinados y optimizados para aplicaciones altamente usadas y con gran volumen de datos.

Flexibilidad y Programabilidad limitadas.

ASICs (Circuitos Integrados para Aplicaciones Específicas)

Sistemas propietarios construidos a la medida por los proveedores, cuando opciones programables no satisfacen requerimientos de desempeño

Programabilidad más baja.

Tabla 1. Tecnologías de procesamiento en SDN [2]

Dadas las características de las tecnologías mencionadas y la existencia del trade-off entre desempeño y programabilidad, se hace evidente que solo una arquitectura híbrida puede satisfacer los requerimientos de desempeño de SDN. Una propuesta es la división de funciones en subfunciones de manera que se tenga un cluster con las características tecnológicas necesarias para ofrecer el mejor desempeño en cada subfunción.

1.5.3 Seguridad y Confiabilidad

La seguridad en SDN es un campo que requiere mayor investigación. Entre los problemas de seguridad a enfrentar en SDN se encuentran la autenticación y autorización, las aplicaciones sensibles al estado de la red, la comunicación entre dispositivos de red y controladores, entre otros. Sin embargo, la seguridad en general, no solo en SDN, abarca muchos dominios y es un campo de acción bastante amplio y por explorar. En cuanto a SDN, la IETF, Internet Engineering Task Force, define una serie de requerimientos de seguridad para las arquitecturas de SDN [6]. Los requerimientos que la IETF define cubren gran parte de los problemas hasta ahora encontrados en SDN, los cuales incluyen: necesidad de aislamiento de aplicaciones, disponibilidad de interfaces y capacidades en los controladores, y autenticación y autorización para múltiples organizaciones. Otras consideraciones en cuanto a seguridad serán descritas más adelante, en la descripción de la problemática de interés en este trabajo.

1.5.4 Interoperabilidad

Los problemas en cuanto a interoperabilidad con SDN radican en cómo estas tecnologías pueden ser integradas con los sistemas ya existentes. El proceso de transición de una tecnología a otra no debe ser tomado a la ligera, y se debe proveer soporte tanto a los nuevos modelos SDN como a los modelos de red tradicionales. Un modelo de despliegue de SDN involucra empezar a implementar una infraestructura de red completamente nueva basada en SDN, pero eso claramente implica que la infraestructura actual sea simplemente cambiada por la nueva. En el mundo real, en donde existen redes enormes (campus universitarios, multinacionales, etc.), tal tipo de despliegue no es posible. Para una organización grande es impensable simplemente cambiar toda su infraestructura de un momento a otro, ya que muchos de los servicios soportados por esta infraestructura son críticos.

Por lo anterior, se hace necesario una especificación y estandarización de los protocolos a utilizar, de manera que se soporten simultáneamente los modelos tradicionales y los modelos SDN. En este sentido, diferentes organizaciones como la ONF, Open Networking Foundation), la IETF, Internet Engineering Task Force, y la ETSI, European Telecommunications Standards Institute, tienen grupos trabajando con este objetivo. Dentro de la ETSI, un grupo especializado (NFV) trabaja en la estandarización de los componentes del core de la red que pueden ser virtualizados para proveer escalabilidad eficiente y soporte adecuado a los servicios de las industrias. Por su

parte, en la IETF, el grupo ForCES ha estado trabajando en la estandarización de interfaces, mecanismos y protocolos para separar el plano de control del plano de enrutamiento en los routers IP. Finalmente la ONF, responsable del protocolo OpenFlow y de gran parte de las especificaciones de SDN, ha estado trabajando en nuevas especificaciones de OpenFlow y dirigiendo la estandarización de otros protocolos relacionados como el protocolo de administración y configuración de OpenFlow.

Como se muestra, varias instituciones están trabajando en especificaciones y estándares que permitan una transición hacia el modelo de red que propone SDN. Sin embargo, es necesario que estas instituciones trabajen coordinadamente con el objetivo de sacar el mayor provecho a estos esfuerzos.

2

EL

PROBLEMA

2.1

Seguridad en SDN

Como se menciona al final de la sección anterior, en el contexto de SDN surgen múltiples retos en cuanto a seguridad. Si se pretende que SDN sea adoptado ampliamente, es necesario prestar más atención al tema y dedicar más esfuerzos a reforzarlo. Aunque existe un grupo de seguridad dentro de la Open Networking Foundation (ONF) y se han encontrado ciertos puntos que merecen mayor investigación, estos descubrimientos no van más allá de identificar un problema que requiere mayor atención.

Son varios los tipos de vulnerabilidades que han sido encontrados en las arquitecturas SDN. Uno de ellos se refiere a la relación de las aplicaciones y los controladores, y tiene que ver con la autenticación y autorización en el uso de recursos de red. El problema radica en proveer a varias organizaciones acceso sobre los recursos de la red de manera segura. No todas las aplicaciones tienen los mismos privilegios sobre el uso de recursos y pueden aparecer ataques de suplantación de identidad y acceso no autorizado. Otro requerimiento para las aplicaciones, es que deben funcionar de manera que no interfieran con las acciones de otras aplicaciones que se estén ejecutando sobre la misma red. Una solución que se propone para este problema, es implementar mecanismos de autenticación basada en roles, como la que propone FortNox [3], la cual permite abordar el problema de prevalencia de instrucciones sobre un controlador que recibe políticas opuestas de distintas aplicaciones. No obstante, esta implementación no provee una solución completa a los problemas de autenticación y autorización de SDN. En particular no provee una solución de aislamiento del funcionamiento de las aplicaciones que funcionan sobre los controladores SDN.

Otro punto vulnerable en las arquitecturas SDN es el referente a la comunicación entre el controlador y los switches que administra, algunos problemas de autenticación y autorización pueden surgir. En el protocolo OpenFlow, se sugiere el uso de TLS para la autenticación mutua entre switch y controlador a la hora de comunicarse, con el objetivo de mitigar las amenazas antes mencionadas. Sin embargo, el uso del protocolo TLS no es estándar y su uso es opcional en OpenFlow. Por esto, se hace necesaria una especificación completa de la comunicación entre controlador y switch para asegurar la transmisión de mensajes entre ellos.

En cuanto a ataques específicos que pueden ocurrir sobre una arquitectura SDN, encontramos el conocido ataque de denegación de servicio (DoS). En este caso, debido a la manera en que SDN maneja el enrutamiento de paquetes, un ataque de esta naturaleza puede ser aplicado sobre el switch mismo o sobre el controlador. Como se menciona antes, un dispositivo capa 2 de SDN (switch) tiene que comparar la información de cada paquete que llega contra su tabla de flujo buscando una entrada que corresponda y realizar la acción asociada. De no encontrar tal entrada, el switch remite la decisión al controlador. Hay dos enfoques para realizar esta tarea. Uno de ellos en enviar el paquete completo al controlador mediante un canal de comunicación seguro, lo cual puede ocasionar problemas de escalabilidad, como se vio antes. El otro enfoque, es enviar solo el encabezado del paquete al controlador, lo que significa que el paquete debe almacenarse temporalmente en el cache del dispositivo de red, hasta que el controlador actualice la tabla de

flujo del switch. Esta última situación ofrece el escenario propicio para que un atacante inicie un ataques DoS, pues sería fácil para un atacante generar un gran número de flujos desconocidos, lo que podría llenar rápidamente la memoria del dispositivo, generando un cuello de botella.

Otro tipo de ataques que puede ocurrir en una arquitectura SDN son los Ataques de Intrusión. Una intrusión puede ser vista como una serie de acciones realizadas de forma secuencial o paralela por algún usuario, o usuarios en particular, cuyo objetivo final es obtener un acceso no autorizado sobre un equipo o un sistema completo. Este tipo de ataques son realizados en su mayoría por crackers; los motivos para llevar a cabo un ataque de intrusión pueden ser variados, desde obtener información confidencial del sistema hasta afectar la continuidad de uno.

En una arquitectura SDN hay diferentes factores que permiten a los atacantes conseguir un acceso no autorizado al sistema. Entre las razones principales se encuentra la división entre planos de control y planos de datos; es decir, el hecho de contar con un sistema de control centralizado para el tráfico de la red favorece que los controladores se conviertan en blancos primordiales para los atacantes. Si un usuario no autorizado consigue acceso al controlador podrá alterar el enrutamiento y algunas de las políticas de seguridad a su medida. Adicionalmente, obtiene información a gran escala de la topología y los diferentes dispositivos de la red ya que todos los enrutadores, switches, Access points, entre otros, mantienen una comunicación constante con el controlador, a fin de administrar y tomar decisiones del enrutamiento y las restricciones que tiene el tráfico en la red. Este tipo de ataques se pueden mitigar haciendo uso de Sistemas de Detección de Intrusos (IDS), tema del que hablaremos más adelante. [20]

Otro reto en seguridad, que introduce SDN, es generado por la misma filosofía de este paradigma. SDN propone que todas las interfaces y protocolos usados sean abiertos, con el objetivo de eliminar la dependencia del software de los proveedores de dispositivos. Este hecho puede ser una puerta de entrada para los atacantes. Al ser ampliamente conocidos, los atacantes adquieren un conocimiento completo de cómo son ejecutadas las funciones de red, permitiéndoles así, tomar ventajas para modificar el comportamiento de la red a su conveniencia.

Desde otro punto de vista, SDN ofrece mecanismos en pro de la seguridad de las redes, basados en las características de SDN, haciendo uso de monitoreo reactivo. Entre los mecanismos que se soportan se encuentran: el análisis forense de la red, la alteración dinámica de políticas de seguridad y la inserción de políticas de servicio.

2.2

Enfoque del Proyecto

La sección anterior describe, a grandes rasgos, la situación actual de seguridad en SDN. Sin embargo, podemos ver que no se han establecido requerimientos en cuanto a la capacidad “reactiva”, entendida como la capacidad de reconfigurar el estado de la red de acuerdo a ciertos eventos, que ofrece la arquitectura SDN. Este proyecto de grado propone aprovechar las características de SDN, para adaptar la red como respuesta a eventos de seguridad. Por ejemplo, como respuesta a identificación de ataques o generación de alertas y notificaciones. Por la gran cantidad de ataques que pueden ser realizados sobre una infraestructura de red, este proyecto de grado se concentrará en aprovechar las características de SDN y generar respuestas, a nivel de red, a dos situaciones en particular: los ataques de denegación de servicio y las intrusiones.

2.2.1 Ataques de Denegación de Servicio (DoS)

Los ataques de denegación de servicio (DoS) toman ventaja de las funcionalidades que ofrece Internet para deteriorar los servicios ofrecidos por un sitio víctima. Por lo general, estos ataques sobrecargan el sitio víctima con peticiones aparentemente normales, al punto que éste ya no pueda ofrecer sus servicios correctamente. Un ataque de denegación de servicio puede llevarse a cabo desde un solo host, o desde varios hosts, los cuales de manera coordinada envían peticiones al sistema víctima hasta saturarlo. Este último ataque es conocido como un ataque de denegación de servicio distribuido (DDoS).

Uno de los mayores problemas con este tipo de ataques es que hay herramientas que facilitan su acción disponibles en la red. Algunas de estas herramientas son altamente sofisticadas y proveen manuales de uso para que los usuarios puedan generar un ataque exitosamente, inclusive usuarios inexpertos en el tema. Los ataques DDoS pueden llegar a ser tan poderosos y perjudiciales que fácilmente pueden generar una gran cantidad de tráfico malicioso que termina agotando los recursos y el ancho de banda del sistema objetivo. Otro aspecto de estos ataques, a tener en cuenta, es que en ocasiones los daños generados por estos pueden traducirse en grandes costos financieros para las organizaciones que han sido víctimas.

Dadas las severas consecuencias que puede ocasionar este tipo de ataques en las organizaciones, se hace necesario desarrollar técnicas para detectar y mitigar los ataques DoS. El desarrollo de técnicas de respuesta efectivas frente a estos ataques requiere conocer en detalle la dinámica de los ataques, y tal información no se obtiene fácilmente. Otro factor que dificulta la correcta identificación de un ataque DoS es que el tráfico malicioso fluye sobre la misma infraestructura que el tráfico no-malicioso, haciendo su identificación más difícil.

Sin embargo, se han desarrollado varios esquemas para detectar ataques DoS [7]. En general, los esquemas desarrollados pueden ser divididos en dos grupos: los esquemas basados en volumen de datos y los esquemas basados en características del tráfico. De manera general, el esquema basado en volumen de datos busca identificar los ataques DoS al detectar cambios abruptos en el tráfico de la red. Aunque este esquema puede identificar ataques de magnitudes importantes, falla a la hora de detectar ataques de corta duración. Por su parte, el esquema basado en características busca detectar los ataques analizando las distribuciones de los cambios en los encabezados de los paquetes. Este esquema puede detectar tanto grandes ataques como los ataques de corta duración, sin embargo, el análisis del encabezado de cada paquete puede ser muy costoso. Existen esquemas alternativos para la detección de ataques DoS, como el análisis del tamaño de los paquetes [7], que no han sido ampliamente estudiados.

Uno de los inconvenientes que surge a la hora de dar solución al problema de los ataques DoS, es la misma variedad de ataques que pueden ser efectuados. Estos ataques pueden presentarse en diferentes capas del protocolo OSI, desde la capa de aplicación (HTTP o FTP) hasta la capa de red (IP) y su propósito puede variar ocasionando una detención temporal en la prestación de un servicio o la inhabilitación permanente del mismo. A continuación se presentan algunos de las técnicas de DoS que pueden usar los atacantes.

2.2.1.1 ICMP Flood

Este ataque tiene por objetivo saturar el canal de comunicación de un host, afectando la prestación de los servicios ofrecidos por el host, mediante el envío de mensajes ICMP (Ping) modificados. El enfoque de este ataque puede variar, pues es posible ejecutarlo incrementando la cantidad de mensajes Echo request enviados al host o aumentando el tamaño del paquete haciendo uso de las capacidades de configuración de los paquetes IP.

Sea cual sea la técnica utilizada para ejecutar el ataque, el resultado es generalmente el mismo. El ancho de banda de la víctima se ve reducido, y esto imposibilita la prestación adecuada de sus servicios. Adicionalmente, el ataque de ICMP flood también puede generar una sobrecarga en el tráfico de la red. Lo anterior, ocurre en el caso en el que el tamaño del paquete Echo request es modificado. Al incrementar el tamaño de los paquetes y aumentar la cantidad de mensajes Echo request enviados al host, se obliga a la víctima a responder con mensajes Echo reply de igual tamaño, aumentando considerablemente el tráfico que circula por la red.

Entre las técnicas utilizadas para mitigar estos ataques, se encuentra el manejo de una tasa máxima de mensajes ICMP. Esta técnica consiste en establecer una tasa máxima de mensajes ICMP por segundo en los hosts que pueden ser víctimas. Cuando el tope es sobrepasado, los paquetes ICMP que sigan llegando serán ignorados. [14]

2.2.1.2 SYN Flood

Los atacantes también pueden usar las características de los protocolos de comunicación y sacarles provecho para perjudicar a un tercero. Este es básicamente el principio del ataque SYN Flood, el cual aprovecha una vulnerabilidad del protocolo TCP/IP.

TCP/IP es un protocolo que pertenece a la capa de transporte en el modelo OSI. Es un protocolo orientado a conexión, lo que quiere decir que asegura, entre otras cosas, una transmisión de datos confiable (se controla la pérdida de paquetes), control de flujo y control de congestión. Al ser un protocolo orientado a conexión, requiere el intercambio de mensajes de control de la sesión, entre los hosts involucrados. En particular, para establecer una conexión TCP/IP se lleva a cabo un intercambio de mensajes de control conocido como el three-way handshake, como se ilustra en la Figura 3.