ANÁLISIS DE SEGURIDAD EN REDES SDN (REDES DEFINIDAS POR SOFTWARE)
CESAR LEANDRO VELEZ MEJIA
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA “UNAD” ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERIA
ESPECIALIZACIÓN EN SEGURIDAD INFORMATICA MEDELLIN, ANTIOQUIA
ANÁLISIS DE SEGURIDAD EN REDES SDN (REDES DEFINIDAS POR SOFTWARE)
CESAR LEANDRO VELEZ MEJIA
Monografía para optar al título de Especialista en seguridad informática
Director
EDGAR ALONSO BOJACA G Ingeniero Electrónico
Especialista en Seguridad Informatica
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA “UNAD” ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERIA
ESPECIALIZACIÓN EN SEGURIDAD INFORMATICA MEDELLIN, ANTIOQUIA
Nota de aceptación:
__________________________________
__________________________________
__________________________________
__________________________________
Jurado
Jurado
4 A mi compañera de Vida
Por aguantar todo este tiempo que invierto en prepararme como profesional y
5
AGRADECIMIENTOS
A mi abogada hermosa, Luisa Fernanda Herrera por creer que los sueños se
6 CONTENIDO
pág.
INTRODUCCIÓN ... 12
1. RESUMEN ... 13
2. PLANTEAMIENTO DEL PROBLEMA ... 14
3. JUSTIFICACIÓN ... 16
4. OBJETIVOS ... 18
4.1 OBJETIVO GENERAL ... 18
4.2 OBJETIVOS ESPECIFICOS ... 18
5. MARCO DE REFERENCIA ... 19
5.1 MARCO TEORICO ... 19
5.2 MARCO CONCEPTUAL... 21
6. ARQUITECTURA DEL SDN ... 26
6.1 ARQUITECTURA DE RED CONVENCIONAL ... 29
6.2 ARQUITECTURA DEFINIDA POR SOFTWARE ... 32
6.3 PLANO DE DATOS ... 34
6.4 PLANO DE CONTROL ... 35
6.5 PLANO DE APLICACIÓN ... 37
6.6 CARACTERÍSTICAS DE LAS REDES SDN ... 39
6.7 BENEFICIOS DE LAS REDES (SDN) ... 40
6.8 LIMITANTES ... 41
6.9 DIFERENCIAS ENTRE SDN Y REDES CONVENCIONALES CON RESPECTO A LA SEGURIDAD ... 43
6.10 CARACTERÍSTICAS QUE SE DEBEN TENER EN CUENTA AL VALORAR LA IMPLEMENTACIÓN DEL CONTROLADOR SDN. ... 46
6.10.1 CARACTERÍSTICAS A NIVEL DE SEGURIDAD ... 50
7. OPENFLOW Y EL MODELO SDN. ... 53
7.1 OPENFLOW ... 53
7
7.3 CONTROLADORES OPENFLOW ... 58
7.4 APLICACIONES UTILIZADAS EN OPENFLOW ... 60
8. CONSIDERACIONES QUE SE DEBEN TENER EN CUENTA PARA IDENTIFICAR PROBLEMAS DE SEGURIDAD EN REDES DEFINIDAS POR SOFTWARE... 61
8.1 SEGURIDAD EN LAS NUEVAS TECNOLOGÍAS ... 62
8.2 UTILIZACION DE HERRAMIENTAS PARA COMBATIR VULNERABILIDADES EN LAS REDES SDN ... 62
8.3 DETECCIÓN Y MITIGACIÓN DE ATAQUES POR MEDIO DE API ... 65
8.4 DETECCIÓN Y MITIGACIÓN DE ATAQUES A TRAVÉS DE VIGILANTES DE RED ... 67
9. ANALISIS ... 77
9.1 HALLAZGOS OPENDAYLIGHT ... 80
10. RESULTADOS ... 91
10.1 RESULTADO DE ATAQUES QUE SE PUEDEN GENERAR AL PLANO DE DATOS ... 93
10.2 RESULTADO DE ATAQUES QUE SE PUEDEN GENERAR AL PLANO DE CONTROL ... 95
10.3 RESULTADO DE ATAQUES QUE SE PUEDEN GENERAR EN LA CAPA DE APLICACIÓN ... 96
10.4 SEGURIDAD A NIVEL DEL SO ... 96
10.5 SEGURIDAD A NIVEL DE APLICACIÓN ... 98
11. CONCLUSIONES ... 101
12. RECOMENDACIONES ... 103
13. BIBLIOGRAFÍA ... 108
8
LISTA DE FIGURAS
pág.
Figura 1. Comparación de la arquitectura ... 31
Figura 2. Arquitectura SDN ... 32
Figura 3. Plano de datos ... 35
Figura 4. Plano De aplicación SDN ... 38
Figura 5. El Switch virtual libre y el protocolo OpenFlow ... 53
Figura 6. Administrador OpenVas ... 66
Figura 7. Mapa de clasificación IDS ... 71
Figura 8. Mapa fuente de datos ... 72
Figura 9. Mapa de Componentes, Capacidad, Tipos ... 73
Figura 10. Consola de administración IDS e IPS Snort ... 74
Figura 11. Consola de administración Suricata ... 75
Figura 12. Consola de administración BRO ... 76
Figura 13. La encriptación TLS mejora la protección de datos ... 77
Figura 14. Diagrama HTTP Y HTTPS ... 79
Figura 15. Denegación de servicios en OpenDayLight 3.3 y 4 ... 81
Figura 16. Numero de subprocesos durante un ataque de denegación de servicios, causante del choque del controlador ... 83
Figura 17. Denegación de servicios en la adición de flujos para OpenDayLight 4.0 ... 84
Figura 18. Denegación de servicios en la adición de flujos para OpenDayLight 4.0 ... 85
Figura 19. Uso de CPU durante un ataque DOS a los Flujos ... 87
9
Figura 21. Denegación de servicios OpenDayLight odl-mdsal-xsql ... 88 Figura 22. Uso de CPU durante un ataque de denegación de servicio XSQL ... 89 Figura 23. StreamCorruptedException and NullPointerException in
Opendaylight odl-mdsal-xsql ... 90 Figura 24. Vectores de ataque SDN ... 93 Figura 25. Metodología de seguridad según Benson ... 113 Figura 26. Diagrama HTTP Y HTTPSFigura 27. Metodología de seguridad
según Benson ... 113 Figura 28. Metodología de seguridad según BensonAnexo 3. Metodología
de seguridad según Benson ... 113 Figura 29. Metodología de seguridad según Benson ... 113 Figura 30. Diagrama HTTP Y HTTPSFigura 31. Metodología de seguridad
según Benson ... 113 Figura 32. Metodología de seguridad según BensonAnexo 5. Metodología
10
LISTA DE TABLAS
pág.
11
LISTA DE ANEXOS
pág.
12
INTRODUCCIÓN
Durante la fusión del plano de control centralizado, con el canal de control, actividad encaminada en lograr el intercambio de información con los dispositivos de red, se generan inquietudes a nivel de seguridad las cuales se deben despejar analizando tanto el enfoque del atacante, y del controlador de red, esto debido a su relevancia en la arquitectura. Se debe además tener en cuenta la importancia del análisis a los diferentes protocolos, ya que las soluciones de seguridad para las redes SDN (Redes Definidas Por Software), suelen ser más un tipo de aspecto de aplicación que no dependen tanto del hardware. Cabe aclarar que todos estos conceptos y escenarios de red concretos de aplicación en la actualidad, requieren de mucha más investigación para poder comprenderlos desde el ámbito de la seguridad.
La seguridad en un factor importante en todos los tipos de red existentes incluyendo las redes definidas por software (SDN), ya que por este medio se abordan temas de protección, disponibilidad, integridad y la privacidad de la información que se transmite. Es bueno entender adicional que la seguridad en este tipo de redes, aunque ya tienen un buen enfoque, aún se encuentra en definición, dado que los enfoques no logran hacer convergencia en un tipo de idea común.
13
1. RESUMEN
Las Redes Definidas por Software es una nueva perspectiva que busca solucionar problemas de seguridad, flexibilidad y optimización de las redes tradicionales, esta perspectiva reforma las redes para impulsar el desarrollo de las tecnologías de telecomunicaciones. El presente proyecto tiene por objeto analizar la seguridad las redes SDN mediante el modelo OpenFlow, para ello se parte de una descripción detallada de dichas redes, verificando si sus principales arquitecturas garantizan autenticidad, integridad, confidencialidad y disponibilidad de la información, además de realizar la descripción clara de los conceptos claves para la arquitectura de Redes Definidas por Software SDN y los parámetros adecuados para validar el modelo con una red OpenFlow.
Se identifica también la seguridad en la protección de datos, dispositivos y activos tecnológicos de las compañías que operan bajo dichas infraestructuras, evidenciando que estas se encuentren protegidas y blindadas de forma eficiente, por último se realiza un análisis comparativo entre los protocolos anteriores y los actuales, con el fin de determinar posibles anomalías, amenazas, o vulnerabilidades que se hayan presentado, a partir de ahí obtener unos resultados que mejoren de manera eficiente la seguridad en las redes SDN y por ende lograr una trasformación de las arquitecturas de red.
14
2. PLANTEAMIENTO DEL PROBLEMA
Actualmente las redes de datos están en creciente desarrollo y despliegue alrededor del mundo, generando un intercambio constante de grandes cantidades de información y de la creación de sistemas más complejos y difíciles de operar. Debido a esto surgen varios interrogantes en relación a la seguridad de las redes definidas por software en el modelo Openflow. Y a partir de las problemáticas aprendidas en las redes tradicionales ya que los dispositivos no pueden ser gestionados a través de las tecnologías propietarias debido a que no se encuentran abiertas a los desarrolladores ni a los administradores de red, esto asociado a la necesidad de integrar plataformas que soporten nuevos servicios de monitorización convergente que cuenten con sensores en diferentes ámbitos, incluyendo la seguridad perimetral, y es aquí donde surge el impulso para una evolución de las telecomunicaciones, tecnologías de nueva generación que buscan crear, mejorar y establecer características tales como virtualización, ingeniería de tráfico, control de acceso, procesamiento intermedio, aislamiento, seguridad, entre otros, para apoyar servicios emergentes como lo son la nube y la arquitectura SDN.
Además, se cuestiona sobre la administración centralizada y la monitorización de la misma, si es realmente fácil de controlar, ya que existen probabilidades de tener errores en la seguridad por cuenta de las topologías y protocolos de red que aún no estén firmados o por algunos errores en la implementación que nos pueden hacer pesar si las redes definidas por software son realmente seguras.1
15
16
3. JUSTIFICACIÓN
Este trabajo busca entender como las redes definidas por software SDN, han incursionado en el ámbito de las redes de datos debido a su forma intuitiva y fácil administración centralizada, desplazando las redes convencionales ya que estas requieren de equipos alternos y software para poder integrarlos. Los sistemas centralizados son fáciles de coordinar debido a su facilidad, pero a su vez también generan algunas dudas e inquietudes, sobre si existe la probabilidad de tener vulnerabilidades o errores en la implementación y en el funcionamiento adecuado de las topologías y por ende en los protocolos de red con los cuales trabajan estas nuevas tecnologías.
Análisis que se realiza partiendo de una identificación en la estructura de las redes definidas por software (SDN) de una manera teórica, buscando lograr un mejor entendimiento a nivel de seguridad, analizando si pueden ser o no vulneradas fácilmente y si existe la posibilidad de alguna afectación, si se realiza una mala implementación desde el inicio, ya sea por desconocimiento a nivel de protocolos o por falta de experticia, esto debido que muchos casos no se validan parámetros importantes al momento de la configuración inicial por parte de los integradores. Y es entonces que con la investigación se pretende concluir si la instalación de las redes SDN puedan afectar en parte la seguridad de la infraestructura donde se instale.
17
18
4. OBJETIVOS
4.1 OBJETIVO GENERAL
Identificar los atributos que intervienen en el flujo de información de los bloques que componen el modelo de las redes SDN, y validar los parámetros adecuados que se deben tener en cuenta a la hora de realizar una implementación.
4.2 OBJETIVOS ESPECIFICOS
• Identificar los beneficios al realizar una implementación de redes SDN, realizando un estudio a nivel teórico mediante el modelo OpenFlow.
• Revisar la seguridad del modelo SDN en sus diferentes protocolos, mediante un análisis de requisitos técnicos, limitantes y ventajas.
• Analizar cómo actúan las capas que prestan el servicio en las plataformas actuales integradas en el modelo.
19
5. MARCO DE REFERENCIA
5.1 MARCO TEORICO
En la actualidad las Redes Definidas Por Software se están moviendo rápidamente de la visión a la realidad con una serie de dispositivos habilitados en desarrollo y producción, un tipo de combinación que busca realizar cambios de control separado y funcionalidad del plano de datos y la programabilidad de la red 2, lo anterior se ha venido debatiendo durante mucho tiempo y han encontrado su aplicación comercial en la computación en la nube y las tecnologías de virtualización.
El concepto de SDN fue introducido por Mckeown 3, profesor de la Universidad de Stanford. El objetivo de este nuevo paradigma era el de poder trasladar las decisiones de los dispositivos de red a un elemento central, llamado controlador, buscando reducir la complejidad de la administración de las redes y mejorando de manera simultánea el rendimiento de las mismas.
Las redes de datos tradicionales están diseñadas para que los equipos tengan propósitos específicos y además que puedan implementar protocolos, control de acceso y monitoreo de forma independiente. Estos equipos tienen integrado el plano de control y el plano de datos, el administrador de la red debe configurar políticas específicas en cada uno de los equipos de la red 4, haciendo la administración
2 R. Ramiro, Seguridad en las redes definidas por Software (SDN). [en línea]. Ciberseguridad. Blog. (6 de
diciembre 2017). [Consultado: 3 de junio de 2018]. Disponible en internet: https://ciberseguridad.blog/seguridad-en-las-redes-definidas-por-software-sdn/
3NICK, Mckeown. Software Defined Networking and OpenFlow [en línea]. OFC Short Course (9 de Marzo
de 2014). [Consultado: 4 de junio de 2018]. Disponible en internet: http://yuba.stanford.edu/~sd2/OF_SDN_Short_Course_2014.pdf
4 NATE. Foster, A. Guha, M. Reitblatt, A. Story, M. J. Freedman, N. P. KATTA, C. Monsanto, J. Reich, J.
20
compleja y el rendimiento limitado a cada equipo sin permitir una visibilidad completa de la red.
SDN ha ganado terreno en las aplicaciones de ámbito empresarial y comercial gracias a la adopción de las nuevas tecnologías en la nube y el concepto de redes virtuales 5, permitiendo que grandes fabricantes se interesen en crear compatibilidad de sus equipos con esta nueva tecnología para el desarrollo de controladores con características innovadoras.
La Universidad de California Berkeley y la Universidad de Standford iniciaron a partir de 2005 estudios acerca de una tecnología que permitiera el acercamiento de las redes al paradigma de programación 6 7 8, ya que tradicionalmente el sistema de dispositivos de red cuenta con funcionamiento cerrado y autónomo delegando el desarrollo a estándares internacionales y aportes de los fabricantes. Es entonces la importancia de entender que las redes definidas por software surgieron debido a la necesidad de simplificar la administración, automatizar procesos, mejorar la seguridad, separarlo del plano de operación y de desarrollar una tecnología de
[en línea]. Freneticlang.org (5 de Febrero de 2013). [Consultado: 3 de junio de 2018]. Disponible en internet: http://frenetic-lang.org/publications/overview-ieeecoms13.pdf
5 M. Jarschel, S. Oechsner, D. Schlosser, R. Pries, S. Goll, and P. Tran-gia, Modeling and Performance
Evaluation of an OpenFlow Architecture [en línea] Itc23.com (23 de Marzo de 2013). [Consultado: 8 de junio de 2018]. Disponible en internet: http://www.itc23.com/fileadmin/ITC23_files/papers/1569411505.pdf
6 M. Casado, T. Garfinkel, A. Akella, M. J. Freedman, D. Boneh, N. McKeown y S. Shenker, Protection
architecture for enterprise networks [en línea] Standford.edu (10 de febrero de 2006). [Consultado: 15 de junio de 2018]. Disponible en internet: http://yuba.stanford.edu/~casado/sane.pdf
7L. Jianying, J. Pettit, M. Casado, J. Lockwood y N. McKeown, Prototyping Fast, Simple, Secure Switches for
Ethane [en línea] Standford.edu (26 de Marzo de 2007). [Consultado: 16 de junio de 2018]. Disponible en internet: http://yuba.stanford.edu/~nickm/papers/ethane-hoti07.pdf
8N. Feamster, J. Rexford y E. Zegura, The Road to SDN, [en línea] Standford.edu (30 de Diciembre de 2013).
21 nueva generación 9.
Empresas tan importantes como Facebook y Google han implementado este nuevo paradigma en sus Data Center 10. ya que SDN ofrece menos complejidad que el enfoque de virtualización convencional que existe en el mercado, adicional varias soluciones centralizadas demuestran el fortalecimiento de esta tecnología de nueva generación.
Las redes SDN (Redes definidas por software) permiten definir el flujo de información, y personalización de la infraestructura de red, de acuerdo a los requisitos del usuario. Partiendo de enfoques que permite separar el plano de los datos, del plano de control para así lograr la implementación del control por medio del software.
En la actualidad existen algunos tipos de enfoques sobre la seguridad SDN, de los cuales sobresalen las mejoras en la seguridad de red logrando explotar simultáneamente la forma que se programa y las vistas de red centralizadas que son introducidas. Como también los atributos nombrados que exponen la red a un rango de nuevos ataques diferentes y que busca ser material de análisis en él trabajo.
5.2 MARCO CONCEPTUAL
Según IETF (Internet Engineering Task Force) y IRTF (Internet Research Task
9OPEN NETWORKING FUNDATION, Member Listing, ONF, [En línea] opennetworking.org (11 de Marzo
de 2015). [Consultado: 23 de junio de 2018]. Disponible en internet: https://www.opennetworking.org/our-members
10 P. Donadio y G. Parladori, Network virtualization in the cloud computing era de Telecommunications
22
Force) ´´las redes definidas por software son un paradigma relacionado con las redes programables y se refiera a la capacidad con la cual el software pueda programar y ademas controlar el comportamiento del a red en todo su conjunto´´ 11
Dando crecimiento a una variedad de conceptos que van desde la alta disponibilidad, virtualización, programación de API,s, y protocolos entre otros, conceptos descritos a continuación y que son de vital importancia en antes, durante y después de una implementación.
Alta disponibilidad (High Availability): Es una característica del sistema, cuyo objeto busca garantizar la disponibilidad operacional para un periodo dado, generalmente continuo, que debe cumplir tres aspectos: eliminación de los puntos de fallo únicos, fiabilidad en el proceso de datos y la detección de los daños que se produzcan.12
APIs (Application Programming Interface): Es un conjunto de funciones y procedimientos los cuales cumplen una o muchas funciones con el fin de poder utilizarlas por algún otro software.13
Controlador: Arquitectura que nos permite tener una centralización del plano de control ya que SDN nos obliga a tener esto centralizado.14
11 Datacenter Dinamico, La evolución que necesitaba la red, [En línea] tools.ietf.org (4 de Marzo de 2014).
[Consultado: 31 de Octubre de 2018]. Disponible en internet: https://tools.ietf.org/html/rfc7149
12C. Caballero, J. A. Clavero, Sistemas de almacenamiento UF1466, [En línea] Paraninfo.es (23 de Mayo de
2016). [Consultado: 30 de junio de 2018]. Disponible en internet: https://www.paraninfo.es/catalogo/9788428396608/uf1466---sistemas-de-almacenamiento
13 Andrearrs,¿Qué es una API?. [En línea] Hypertextual (15 de Mayo de 2014). [Consultado: 4 de julio de
2018]. Disponible en internet: https://hipertextual.com/archivo/2014/05/que-es-api/
14SDXCENTRAL, What are SDN Controllers (or SDN Controllers Platforms)? [En línea] Sdxcentral (25 de
23
Conmutadores: es un dispositivo de tipo digital o lógico de interconexión de equipos que opera en la capa de enlace de datos del modelo OSI. 15
Framework: Es un entorno de trabajo tecnológico y conceptual que cuenta con artefacto o módulos concretos de software. 16
Hypervisor: Es un tipo de plataforma que permite aplicar diversas técnicas de control de la virtualización con la idea de poder utilizar al mismo tiempo diferentes sistemas operativos.17
Network Virtualization: Es una combinación de recursos de red del hardware fusionado con los de red del software logrando así una unidad administrativa.18
NOS (Network Operating System): Es un sistema operativo de computadora el cual está diseñado para soportar computadoras que están conectadas a la red (LAN). 19
OpenFlow: Es el primer protocolo implementado para la arquitectura SDN, esta
15 IESCURAVALERA, Conmutador (dispositivo de red). [En línea] Iescuravalera.es (15 de Septiembre de
2014). [Consultado: 7 de julio de 2018]. Disponible en internet: http://informatica.iescuravalera.es/iflica/gtfinal/libro/c326.html
16 MARTINEZ, Oscar, ACOSTA, David, Julio César; E, Mata, E, L. Aprendizaje combinado, aprendizaje
electrónico centrado en el alumno y nuevas tecnologías [En línea] Sedici.unpl.edu.ar (1 de Enero de 2012). [Consultado: 9 de julio de 2018]. Disponible en internet: http://sedici.unlp.edu.ar/bitstream/handle/10915/19306/Documento_completo.pdf?sequence=1
17 M. Tim Jones. (2009) La anatomía de un hipervisor Linux, [En línea] IBM.com (26 de marzo de 2009).
[Consultado: 17 de julio de 2018]. Disponible en internet: https://www.ibm.com/developerworks/ssa/library/l-hypervisor/index.html
18La virtualización de redes y las redes virtuales. [En línea] Oracle (18 de marzo de 2011). [Consultado: 18 de
julio de 2018]. Disponible en internet: https://docs.oracle.com/cd/E26921_01/html/E25833/gfkbw.html
19 R. Margaret, Sistema operativo de red (NOS), [En línea] searchdatacenter (22 de Febrero de 2016).
24
tecnología usa el concepto de flujo para identificar el tráfico de red y tablas de flujos para determinar el comportamiento de ese tráfico a través de los dispositivos de red controlados externamente por un controller. 20
Protocolo: Es un término utilizado para hablar del conjunto de normas las cuales nos sirven para describir las normativas y criterios que fijan como se deben comunicar los componentes de una red de comunicaciones.21.
Protocolo IP: Es un conjunto de normas que nos rigen todo el funcionamiento de las cosas en una determinada tecnología, es parte de la capa de internet del conjunto que nos permite el desarrollo y transporte de los datagramas IP. 21
Plano de control (Control Plane): Es el encargado de automatizar las funcionalidades dentro de una red, algunas de las actividades van desde poder añadir y eliminar los circuitos ópticos y las mallas, logrando abarcar protocolos de señalización internodos y sus intercomponentes. 22
Plano de datos (Data Plane): El plano de los datos nos representa los datos reales de los usuarios, para citar un ejemplo más claro estaría los bits de información los cuales están contenidos en los flujos de datos de un circuito de tipo óptico que
20 A. Bianco, R. Birke, L. Giraudo y M. Palacin, OpenFlow Switching: Data Plane Performance de
Communications, [En línea] Telematica Polito IT (13 de Febrero de 2010). [Consultado: 28 de julio de 2018]. Disponible en internet: https://www.telematica.polito.it/~bianco/Papers_pdf/2010/icc_openflow.pdf
21J. Pérez, A. Gardey. Protocolo de red. [En línea] Definición.de (27 de septiembre de 2013). [Consultado: 4
de agosto de 2018]. Disponible en internet: https://definicion.de/protocolo-de-red/
22 INTERNAUTA SIN PAUTA, El papel del Plano de Control en Redes de ROADM [En línea]
25 contiene los servicios. 23
SDN: (Software-Defined Networking) Redes definidas por software: SDN es un nuevo paradigma que desacopla el plano de control y el plano de datos, extrayendo el control de los conmutadores a un servidor externo (controller) para unificarlo y simplificarlo (abstracción) permitiendo a las redes manejarse como un una entidad lógica o virtual. 24
Southbound (SBI): Interfaz que tiene como principal función la de proporcionar gestión entre el controlador SDN de la red y los nodos físico y virtuales, logrando descubrir la topología de red y su flujo. 25
Stride análisis de amenazas: Es un acrónimo que resume 6 categorías, suplantación, manipulación, repudio, revelación de información, denegación de servicio, elevación de privilegios, que pretende tener un conjunto específico de medidas de seguridad para poderlas evitar. 26
23 INTERNAUTA SIN PAUTA, Plano de transporte [En línea] Filotecnologa.Wordpress (29 de Agosto de
2011). [Consultado: 7 de agosto de 2018]. Disponible en internet: https://filotecnologa.wordpress.com/2011/08/29/el-papel-del-plano-de-control-en-redes-de-roadm/
24A. C. Risdianto y E. Mulyana, Implementation and Analysis of Control and forwarding plane for SDN, [En
línea] Researchgate (10 de Octubre de 2012). [Consultado: 10 de agosto de 2018]. Disponible en internet: https://www.researchgate.net/publication/261085931_Implementation_and_analysis_of_control_and_forward ing_plane_for_SDN
25R. Margaret, northbound interface / southbound interface [En línea] Techtarget (16 de Noviembre de 2012).
[Consultado: 18 de Agosto de 2018]. Disponible en internet: https://whatis.techtarget.com/definition/northbound-interface-southbound-interface
26SEGU.INFO ¿Que es stride? [En línea] Segu.Info (20 de Marzo de 2010). [Consultado: 21 de Agosto de
26
6. ARQUITECTURA DEL SDN
SDN se define como una arquitectura de red con algunos pilares fundamentales como lo son el plano de control que se encuentran desacoplados y la funcionalidad de control se elimina de todos los dispositivos de red, con la idea de dar paso a convertirla en simples elementos de reenvió para los paquetes, estos reenvíos de paquetes se conocen como objetos que se basan en flujos y no en análisis del destino para cada uno de los datagramas. Es entonces que se puede definir que un flujo se basa de esta forma y no en el análisis de cada datagrama, adicional también se pueden visualizar de la siguiente forma:
✓ Puertos donde se reciben los paquetes
✓ Etiquetas de las VLAN
✓ Mac de origen y destinos
✓ Protocolos entre otros
Así mismo estos criterios actúan como un tipo de filtro que nos permitirá ejecutar un conjunto de acciones sobre el tráfico, vemos que en el contexto de SDN / Openflow el flujo es una secuencia de paquetes entre el origen y un destino, es entonces que todos los paquetes del flujo pueden recibir las políticas de servicios iguales en todos los dispositivos de reenvió. Y la abstracción nos permite unificar todo el comportamiento en los diferentes dispositivos de la red incluso al mismo enrutador, cortafuegos, firewall o los dispositivos intermedios.
Vemos al mismo tiempo que la programación del flujo de trabajo permite tener flexibilidad y que solo se limita a los tipos de capacidades de las tablas en los dispositivos que se mencionaron.
27
que es una plataforma se logra ejecutar en la tecnología de los servidores, este puede proporcionar los recursos de tipo esenciales y la abstracción para de esta manera lograr facilitar la programación adecuada de los dispositivos y la conmutación de paquetes que esté basada en la abstracción lógica centralizada. Este propósito se asemeja al de un sistema operativo tradicional conocido.
Estas redes se pueden programar a través de aplicaciones que se están ejecutando que se están ejecutando en la parte superior del NOS o sistema operativo que a su vez interactúa con todos los dispositivos del plano subyacente, este tipo de característica es bastante fundamental en las redes SDN y lo cual es considerado como la principal propuesta de valor que trae la tecnología.
SDN permite además simplificar todos los dispositivos de red ya que estos no requieren entender ni procesar varios tipos de protocolos de tipo estándar, pero si aceptar las instrucciones de los controladores de tipo SDN. Es por esto que la arquitectura SDN nos permite a los administradores de red lograr un control central de tipo programable para el tráfico de toda la red, esto sin necesidad de acceso físico a todos los dispositivos de hardware para toda la red de datos.
28
elementos de la red de una manera más dinámica y es por esto que ya la red no es de tipo determinista si no por el contrario dinámica. 27
SDN logra sustituir el nivel de control para el hardware de red esto por una capa de software abstraído por medio de técnicas de virtualización logrando que esta sea más programable.
Estas se concentran en diferentes tipos de aproximaciones la cuales son:
✓ Proporcionar el acceso al hardware por medio de la programación del protocolo OpenFlow.
✓ Tener arquitecturas que puedan ser construidas sobre un nivel de control que se base en el software.
✓ Lograr la creación de varios tipos de redes virtuales las cuales estén por encima del hardware y que a su vez pueden dirigirse a través de las redes físicas.
Es entonces que el enfoque del siguiente trabajo nos da un foco en muchos de los conceptos que ya se mencionaron y que el primero está en que las redes definidas por software nos permiten un tipo de separación entre el plano de control que es el software y el plano de los datos que sería toda la maquinaria que se encarga de enrutar los paquetes de una red de datos, facilitando que este control se pueda gestionar mediante el acceso basado en programación. Así de este modo la infraestructura que se está generando adquiere un control sobre toda la red de manera independiente del proveedor. Logrando simplificar con SDN todos los dispositivos de red, esto debido a que ya no van a necesitar entender y procesar la
27Datacenter Dinamico, La evolución que necesitaba la red, [En línea] datacenterdynamics.es (29 de septiembre
29
cantidad de protocolos. Si no que solo aceptan todas las instrucciones para los controles SDN.
También debemos entender otros conceptos como lo son la virtualización que ya se nombró con anterioridad ya que esta es una de las aplicaciones más importantes de las redes SDN, ya que con esto se logra independizar de la infraestructura subyacente y también crear redes de tipo lógico con el objetivo de poder cumplir con los requisitos de rendimiento indispensables y de escalabilidad y agilidad de tipo necesarios en los modelos de la computación clown.
Esta nueva forma de pensar las redes permite el aprovisionamiento pragmático de las redes de tipo virtuales necesarias para poder asumir las cargas de trabajo de forma dinámica, además de las migraciones en máquinas virtuales y relaciones con la escalabilidad de los CPD centros de procesamiento de datos, incluso en los que están dispersos.
6.1 ARQUITECTURA DE RED CONVENCIONAL
Actualmente las arquitecturas tradicionales poseen algunas limitaciones que no dejan aprovechar las características de una manera fácil y además no están diseñadas para poder cubrir los requerimientos de los usuarios actuales. Algunas de las principales limitantes están en la dificultad y gran cantidad de tiempo que se debe invertir a la hora de poder introducir o reconfigurar un tipo de elemento del sistema. Un ejemplo seria algún dispositivo nuevo en la red o algún tipo de servicio personalizado.
30
o el Big data vemos que se requiere una respuesta ágil en demanda de los servicios, lo cual hace que la gestión de los sistemas sea una tarea bastante compleja. Para el caso específicamente de Big data se necesitaría un gran ancho de banda para transmitir grandes cantidades de información por la red.
31 Fuente: El Autor
Podemos observar que en los dispositivos de redes tradicionales el plano de los datos y el
de control se encuentran internos en el dispositivo, pero en las redes SDN el plano de control
se encuentra en un dispositivo exterior que se conoce como controlador.
32
6.2 ARQUITECTURA DEFINIDA POR SOFTWARE
En la arquitectura de la red definida por software podemos encontrar que esta facilita la separación entre los dispositivos de la red, las funciones del control y las aplicaciones del sistema como podemos observar en la siguiente imagen.
Fuente: El Autor
Las Redes Definidas Por Software establecen en su arquitectura 3 tipos a nivel general y 2 intermedias las cuales se definen de la siguiente manera
- Capa de control: Esta capa es responsable de establecer el trato de los flujos de los datos, con la ayuda del controlador SDN. Aunque existen varios protocolos, se utiliza OpenFlow.
33
- Capa de infraestructura: Se encuentra conformada por enrutadores y conmutadores físicos, encargados de la administración de las tablas de flujo mediante el controlador, encargada de cambiar o agregar dispositivos. Capa enlazada con el plano de datos.
Las solicitudes que se ejecutan entre la capa de infraestructura y la capa de control son realizadas mediante la Interfaz Southbound. La comunicación entre la capa de control y las aplicaciones es realizada con la Interfaz NorthBound.
- Capa de administración y aplicaciones: Admite establecer aplicaciones para de forma automática ejecutar las configuraciones, abastecimiento y extender los nuevos servicios en la red.
Las capas de aplicación y control se comunican mediante una API, para conocer el estado general de la red, actividad que se recomienda desplegar por medio de los nodos, buscando mejorar la transferencia de los datos ya que con ellos se podrá administrar el tráfico de flujos de las redes individuales para aplicaciones específicas, como es el ejemplo de las plataformas de control distribuidas.
La capa de aplicaciones permite relacionar las funciones de los centros de datos para obtener seguridad en la red mientras se está trabajando, además mejora de forma constante la automatización. A continuación, se observa la descripción para Northbound API y Southbound API, capas intermedias que son importantes en la comunicación de las aplicaciones.
34
controladores con la idea de poder realizar configuraciones de tipo red con las solicitudes de las aplicaciones. Esto si se requiere tener algún nivel de seguridad más alto, allí el administrador puede lograr controlar todas las peticiones que se desean realizar mediante las reglas de tráfico y sobre premisos en los accesos.
- Southbound API (SB API): Aquí en el plano de control es el lugar donde se realizan las configuraciones de los controladores mediante los SB API aquí son enviadas las reglas de los flujos para el tráfico a todos los dispositivos de la red.
Además, es posible la instalación de capas intermedias a manera del proxy entre el controlador y los dispositivos de la red, para poder utilizarlos en la administración de distintos controladores o NB API.
6.3 PLANO DE DATOS
Aquí el desacoplamiento del plano de control se realiza con el propósito que los dispositivos de la red puedan ser programados y a su vez controlados por un tipo de agente externo. Para que de esta forma se pueda proporcionar flexibilidad y escalabilidad a la hora de requerir nuevas funcionalidades.
35
El controlador puede utilizar además el algoritmo programado previamente en el plano de control y de esta forma se podrán definir de una forma clara y sencilla una cantidad de funcionalidades nuevas que en una red tradicional sería difícil o hasta imposible de realizar la implementación. Como ejemplo sería una programación en el reenvió de los paquetes, o desarrollar un control de acceso, marcar o poder inspeccionar los datagramas o monitorización en el tráfico de la red para su posterior tratamiento.
Fuente: El Autor
6.4 PLANO DE CONTROL
36
El controlador o planos de control es entonces el encargado de la toda la configuración de cada uno de los nodos y de la programación para el reenvió de los flujos de una forma automática, tomando así muy en cuenta la situación actual de toda la red. Es entonces que si se compara la red tradicional el administrador de TI tendría que efectuar algunas de las modificaciones o ajustes de la configuración en cada uno de los dispositivos de forma manual.
También se le conoce al controlador como sistema operático de red NOS, logrando ser este centralizado y distribuido, es entonces que al ser el controlador el cerebro de toda la red un tipo de falla del mismo produciría un impacto fuerte en todo el sistema. Es entonces que se recomienda que exista un tipo de configuración de forma distribuida con el fin de poder asegurar el libre funcionamiento continúo de toda la red. Para la comunicación entre la capa de control y la capa de aplicación y la de infraestructura. Aquí se definen además dos tipos de interfaces las cuales son la conocida y nombradas más arriba y que se ven en las imágenes Northbound y Southbound. Donde la interface Northbound permite todo el desarrollo de la aplicación de alto nivel que sería la provisión de sistemas de seguridad e integración de middlebox recursos destinados para la administración y el control entre otros.
37
A su vez existen diferentes tipos de controladores los cuales se pueden clasificar según el tipo de lenguaje de programación que fueron diseñados, en la siguiente tabla se listan algunos:
Tabla 1. Clasificación de controladores SDN
Fuente: El Autor
6.5 PLANO DE APLICACIÓN
Este plano tiene como gran objetivo poder desarrollar aplicaciones de alto nivel que puedan ser muy utilizadas por los clientes para así gestionar los servicios, para el caso están las aplicaciones de video, audio y seguridad además de la optimización y toda la gestión de la información, aquí la capa de aplicación y como se habló durante todo el documento de monografía la capa de aplicación se debe comunicar con el controlador a través de la interfaz Northbound API.
Lenguaje Controladores
C++ NOX
Java maestro , Floodlight, Opendaylight,
38
Fuente: El Autor
Para dar algunos de los ejemplos de aplicaciones vemos los siguientes:
FlowVisor que nos permite una virtualización de la red SDN, donde todo el plano de los datos es compartido por diferentes tipos de redes virtuales.
ElasticTree que se caracteriza el consumo de la energía de un CPD.
OpenPipes que es una plataforma que logra permitir la implementación de los sistemas de hardware de tipo distribuidos comunicándolos por medio del protocolo OpenFlow.
Esta capa de aplicación busca entonces poder automatizar la configuración y gestión de los servicios permitiendo el despliegue de los nuevos servicios de la red y aportar en la mejora de tomas de decisiones.
39 6.6 CARACTERÍSTICAS DE LAS REDES SDN
• Directamente programable: para el control de la red vemos que es directamente programable ya que esta desacoplado de todas las funciones del reenvió. 28
• Ágil: aquí el control de abstracción del reenvió les permite a los administradores poder ajustar de una forma dinámica el flujo de tráfico que pasa por toda la red para así poder satisfacer las necesidades cambiantes.29
• Gestión centralizada: Toda la inteligencia de la red está centralizada en controladores SDN que se basan en software y que a su vez pueden mantener una vista completa de toda la red y que operan de frente a las aplicaciones y motores de políticas como un solo conmutador de tipo lógico. 29
Configuración programática: Permite la a los administradores de red lograr configurar, gestionar, asegurar y optimizar los recursos de red de manera más rápida a través de los SDN dinámicos y automatizados, estos pueden
28 OPEN NETWORKING FUNDATION, Member Listing, ONF, [En línea] opennetworking.org (11 de Marzo de 2015). [Consultado: 23 de junio de 2018]. Disponible en internet: https://www.opennetworking.org/our-members
29 DatacenterdynamicsDinamico, SDN la evolución, [En línea] datacenterdynamics.es (29 de Septiembre de 2016). [Consultado: 9 de Dic de 2018]. Disponible en internet:
40
ser escritos por ellos mismos ya que estos programas no dependen del software propietario. 29
• Basados en estándares abiertos y proveedor neutral: Como se implementa a través de estándares abiertos, SDN simplifica el diseño de la red de operación. 29
6.7 BENEFICIOS DE LAS REDES (SDN)
Las redes definidas por software nos proporcionan una serie de beneficios que van desde la independencia del fabricante ya que logran que los elementos de conmutación ya no requieran incorporan ningún software para esta gestión. En la actualidad también las redes definidas por software tienen la facilidad de combinar appliance de diferentes fabricantes, sin contar con problemas de incompatibilidad ya que uno de los beneficios más grandes de estas redes es el no tener que estar sometido a Hardware de tipo propietario ni dispositivos dedicados. También se cuenta con una mejora en la seguridad ya que pasa a ser manejada por el controlador, impidiendo en cierto modo los huecos de seguridad en la configuración de los Switches y enrutadores.
Otro de los beneficios más relevantes está en la facilidad de innovación que se puede tener ya que la implementación puede ser más flexible y fácil de configurar, dando la posibilidad de realizar integraciones con nuevas aplicaciones.
41
convencionales evitando procedimientos por separado y dando agilidad y velocidad en el aprovisionamiento de todos los servicios y recursos, traduciendo todo esto en reducción de costos por reproceso o lentitud en el servicio prestado por TI a las compañías que cuentan con estas tecnologías SDN ya que el ahorro en equipos de conmutación es bastante amplio debido al paso de equipos propietarios a equipos Fabric, a continuación se describen otros beneficios con los cuales se cuenta al implementar redes SDN.
✓ Visión unificada de la estructura de la red
✓ Enrutamiento mejorado
✓ Monitorización y alertas centralizadas
✓ Ingeniería de tráfico centralizada TE
✓ Manejo rápido de fallos
✓ Entorno de pruebas de alta fidelidad
✓ Actualizaciones sin impacto
✓ Reducción de la complejidad por medio de automatización
✓ Control centralizado de entornos para múltiples proveedores
✓ Más innovación
✓ Aumento de la fiabilidad y seguridad de la red
✓ Mejor experiencia de usuario
6.8 LIMITANTES
42
✓ Seguridad: en la separación del plano de los daros y control convierte los datos en objeticos algo vulnerables a ataques maliciosos algún ejemplo claro podría ser la denegación de servicio en el controlador, para este tipo de ataque si nuestro controlador se ve comprometido se nos perdería el control total de la red. además se necesitarían mecanismos de autenticación y algunos diferentes niveles de acceso para tener un uso adecuado de todos los recursos de la red.
✓ Rendimiento y modelado de la red SDN: en la actualidad no existe algún acuerdo en la ubicación, el tipo de NOS o el número de controladores que se deben desplegar en la red SDN.
✓ Integración con redes tradicionales: si requerimos de una implementación con redes SDN los dispositivos deberán tener soporte para esta tecnología. es entonces la importancia de crear mecanismos, protocolos e interfaces que nos permitan la transacción o coordinación entre los equipos SDN y los dispositivos de redes actuales.
✓ Monitorización: Surge la necesidad de una herramienta de monitorización con la idea de poder conocer todo lo que ocurre en el sistema ya sea en algún momento concreto o en intervalos de tiempo específicos, para llevar a cabo la labor de monitorear existen algunos procedimientos y técnicas que se centran en la utilización de los sistemas de software como del establecimiento de los dispositivos y destinados a este fin. Es bueno tener muy en cuenta que debido al costo de la implementación de estos sistemas existen algunos tipos de alternativas que propone SDN.
43
técnica del envío de paquetes adicionales para poder conocer lo que está ocurriendo en la red. El otro método se basa en la monitorización de tipo pasiva en la cual se analiza solamente el tipo de tráfico que circula por la red.
✓ Análisis: Cuando se detecta las métricas de la monitorización estas se pueden analizar con el objetivo de poder proporcionar la información agregada o que se correlacione de todo el estado de la red, alguno de los casos es el de los valores máximos y mínimos en el retardo de un tipo de enlace específico en un intervalo de tiempo. Además SDN permite la implementación de las técnicas de análisis tradiciones
✓ Visualización: Luego de realizar el análisis de las métricas y estadísticas se adquiere la importancia en la presentación de las mismas al usuario final. Para esto existe el framework que permite la visualización del estado de la red en tiempo real y en una gran cantidad de formatos gráficos y tablas, estas herramientas en su mayoría son de costo.
6.9 DIFERENCIAS ENTRE SDN Y REDES CONVENCIONALES CON RESPECTO A LA SEGURIDAD
En la mayoría de tecnologías hay tanto beneficios como problemas y es el caso de algunas que podemos ver entre algunos de los beneficios son:
✓ El administrador puede realizar modificaciones en la estructura de una manera rápida y con un entorno de alto nivel.
44
✓ Si se tiene algún virus o malware dentro de la red SDN o OpenFlow se puede limitar de una forma más rápida ya que se cuenta con un punto centralizado y que detiene este tráfico sin la necesidad de acceder a diferentes router o switches.
✓ Se tiene la posibilidad de cambiar de una manera rápida configuraciones de la red, dando la posibilidad de administrar mucho mejor el tráfico dando forma al QoS de paquetes de una forma segura, esta habilidad esta hoy en día en las redes tradicionales, pero no trabaja igual que con las redes SDN.
Algunas de las contras que se encuentran con respecto a las redes SDN en temas de seguridad estarían:
En las implementaciones nuevas los aspectos de seguridad es muy fácil que se den por alto. Muchas de las preocupaciones de SDN se centran en el controlador ya que aquí se considera el cerebro de toda la red, permitiéndonos que esta se trabaje de una forma centralizada, este tipo de elemento debe ser mucho más blindado y seguro aplicando:
Validando y auditando quienes tienen el acceso y donde se ubican en la red, ya que esto es importante para poder recordar el acceso al mismo y que se así no se pueda otorgar al atacante el control completo y por eso es la importancia que se dé la seguridad.
45
ser mucho más compleja y costosa. Debemos asegurarnos que la seguridad entre el controlador y el nodo este configurada correctamente.
Validar si los controladores tienen alta disponibilidad, se debe crear una alta disponibilidad de los mismo ya que es importante porque si esta se pierde la capacidad de gestionarlos y de la red se perdería además de las redes SDN Y OpenFlow
Validar que todo lo que se realice en el sistema quede registrado, es importante desde que se comience a tener control que todo quede registrado en el sistema.
Luego de la implementación de SDN se debe valida que el IPS e IDS, FIREWALL y las tecnologías de filtrado que puedan bloquear que estas estén actualizas, además se debe seguir los eventos desde el Security Información Event Manager, revisar fallas de acceso y cambios en las políticas que nos puedan ayudar a mejorar la seguridad de todo el sistema.
Revisar si el IPS no está logrando identificar todo el tráfico del controlador como malicioso y configurar las reglas de filtrado así el controlador se pueda hablar cuando lo necesite y al mismo tiempo comunicarse.
46
Una de las herramientas que se utiliza en las redes definidas por software es el OpenVas (Open Vulnerability Assessment System) y que es denominado GNessus y que cuenta con una suite de software y que ofrece un tipo de marco para trabajo donde se pueden integrar servicios y herramientas especializadas en el escaneo y gestión de las vulnerabilidades de seguridad para los sistemas informáticos, este escáner se correo desde el Virtual Appliance.
6.10 CARACTERÍSTICAS QUE SE DEBEN TENER EN CUENTA AL VALORAR LA IMPLEMENTACIÓN DEL CONTROLADOR SDN.
Al momento de definir la planeación y configuración de las redes definidas por software se deben contemplar diferentes aspectos como lo son soporte IPv6, OpenFlow, virtualización funcionalidades entre otros que se describen en el documento:
Soporte OpenFlow: aquí la persona que quiere implementar deberá conocer cuáles serían las especificaciones de tipo técnicas para las versiones que tiene OpenFlow, se identificara que controlador puede soportar. logrando saber las opciones que entregan los proveedores de la migración a nuevas versiones, es entonces necesario conocer las características para cada una de las versiones, ya que no todas tienen las mismas opciones como es el caso de IPV6.
47
usuarios y otros, permitiendo a los desarrolladores de APP ejecutarlas en entornos de trabajo sin tener afectaciones en el tráfico de red.
Es entonces que para poder mantener estos requisitos de una forma óptima en los controladores SDN, se deben poder configurar las redes virtuales en una forma centralizada y aislar las unas de las otras y que las configuraciones estén automatizadas.
Funcionalidades de la red: en el aumento de la flexibilidad hablando de términos como se enrutan los flujos, es importante que el controlador SDN logre decidir el mismo el enrutamiento basado en los múltiples campos de la cabecera OpenFlow antes nombrada. Siendo primordial que el controlador nos determine parámetros del QoS uno a uno.
Otra significativa funcionalidad que debe tener el controlador es la capacidad para poder encontrar diferentes rutas desde su origen del flujo al destino logrando dividir el tipo de tráfico de un flujo que se da a través de diferentes enlaces. Estas capacidades pueden excluir la necesidad del STP logrando aumentar el rendimiento y la escalabilidad de toda la red permitiendo eliminar toda la necesidad de una red difícil nuevos protocolos como lo son el GTRILL y el SPB.
48
Po otro lado también la escalabilidad también tiene un aspecto bastante importante y el cual es la capacidad que tiene el controlado para poder crear una SDN la cual pueda abarcar múltiples sitios, siendo una capacidad que nos permite el movimiento de las máquinas de tipo virtuales y todo el almacenamiento virtual entre los sitios, para así maximizar el beneficio de esta capacidad, aquí el controlador debe permitir que las políticas que se tienen en la red en el enrutamiento y reenvió se logren aplicar automáticamente para la migración de los servidores y el almacenamiento.
Rendimiento: entre una de las principales funciones de los controladores SDN es la de establecer los flujos y para ello dos de los indicadores claves del rendimiento y que se encuentran asociados con un controlador SDN son el tiempo de confirmación de flujo y el número de flujo por segundo que se pueden establecer en el controlador.
Este tipo de métricas de desempeño logran influir en una medida muy alta cuando se agregan controladores. Un ejemplo puede ser cuando los controladores inician más flujos de los que se esperan o soportan por el controlador o los controladores SDN que ya existen.
Programabilidad de la red: la programabilidad es una de las características más grandes y fundamentales de las redes SDN, ya que hay mucha cantidad de interfaces para la programación del controlador, algo que nos posibilita que esto ofrezca muchas funcionalidades. Un controlador SDN también puede soportar la programabilidad proporcionando todas las plantillas que permiten la creación de secuencias en los comandos CLI que hace posible la programación de tipo dinámica para la red.
49
importante saber que como alternativa el controlador SDN solo establece una sola ruta del origen al destino cundo ocurre un tipo de fallo en el enlace, aquí el controlador debe ser capaz de redirigir todo el tráfico rápidamente a un enlace activo. El cual esta relativo a la disponibilidad de las conexiones externas y es importante que aquí el controlador pueda soportar tecnologías alternativas de diseño como lo son VRRP y MC LAG que tienen como objetivo poder aumentar la fiabilidad de la red.
Respecto a la disponibilidad del controlador en sí mismo es también es importante que el mismo se pueda construir utilizando la redundancia tanto para las características del hardware como para las redes de software. También se debe tener en cuenta que el controlador permita agrupaciones Cluster.
Seguridad en la red: para poder entregar seguridad a la red, es importante que el controlador SDN pueda tolerar la autenticación y la autorización, como se habla en todo el trabajo realizado los controladores son bastante propensos a tener ataques malintencionados, lo que puede generar que las conexiones de control sean algo limitadas y que sean aptas para poder detectar los posibles ataques que se puedan llegar a generar.
50
Fabricantes de los controladores SDN: muchos de los fabricantes cuando vieron la progresiva tendencia de SDN ingresaron al mercado, muchos otros manifestaron sus ganas de ingresar o incursionar en el mercado. Es entonces que otros opinan que por la inestabilidad de SDN y del controlador en el marcado primero buscan que las características llenen las expectativas a nivel técnico y comercial para que los vendedores están más apoyados. Uno de los retos que existen van desde los técnico y financiero para los proveedores que no permiten ampliar la red SDN sin desfavorecer la consecución de controladores que deben permanecer actualizadas según la evolución de las redes SDN.
Soporte para las plataformas: en el caso que los sistemas operativos que utilizan los controladores deben ser de tipo multiplataforma para que se pueda ofrecer flexibilidad e independencia cuando se instauren. Hay algunas empresas que les gusta que los controladores puedan trabajar con software abierto.
Procesamiento: al momento de valorar un controlador se debe tomar en cuentan si esto se soporta de forma simultánea a los diferentes procesos debido a que es posible que nos afecte los núcleos. Los controladores cuando son mono procesos estos se deberán corres en el hardware de una solo CPU, por lo general son utilizados en pequeñas redes; esto al igual que los controladores que soportan múltiples procesos deben operar con múltiples CPU aplica para los utilizados en empresas.
6.10.1 CARACTERÍSTICAS A NIVEL DE SEGURIDAD
51
- Plano de datos: Donde uno de los problemas de este plano de control está en que utilizan protocolos bastante nuevos y es por esto mismo que pueden no ser configurados correctamente al momento de realizar la implementación. En uno de los ámbitos de utilización de las redes SDN que son los CPD se tienen protocolos específicos como lo son DCI, STT, NVGRE. Estos pueden carecer de encriptación los cuales lo pueden volver vulnerables.
- Capa de control: Esta parte es la más delicada ya que si algún tipo de atacante logra comprometerlo puede tomar el control de toda la red, esta es una de las desventajas más fuerte de las redes SDN, muchas de las veces los controladores pueden correr en algún tipo de Linux, y es aquí que las vulnerabilidades del SO se pueden volver vulnerabilidades del controlador y por lo tanto de la misma red.
- Vulnerabilidades del controlador: Las vulnerabilidades del puerto 9390 y que se deben tener muy en cuenta y que son de fácil solución para la seguridad, aquí se debe cambiar el protocolo por versiones mucho más nuevas, como un ejemplo sería el SSLv3 por el TLSv, también se pueden ver vulnerabilidades sobre el TCP que pueden ser corregidas a tiempo al inicio de la implementación con cambios en la configuración del protocolo.
52
- Vulnerabilidades del Switch: Durante la revisión de los Switch se pueden encontrar amenazas de bajo nivel, donde los Timestamps que se envían en el protocolo TCP pueden ser deshabilitados, también se pueden encontrar los ICMP que están activos y por medio de este se pueden entonces obtener la versión del sistema, por lo que es bastante conveniente deshabilitarlos y para el caso del controlador evitar el trace Route. Estos casos demuestran que ante la solicitud de los archivos no existe lugar de enviar 404 NotFound esto puede responder enviando información disponible de todo el equipo. Este también nos logra mostrar la conexión del telnet esta se debe a la computadora conectada al Switch utilizado para configurarlos.
53
7. OPENFLOW Y EL MODELO SDN.
Actualmente existen 3 tipos de protocolos para la comunicación en las redes SDN como es el caso de OpenFlow, protocolo importante durante el desarrollo del análisis y pieza fundamental en la seguridad, adicional existen otros 2 protocolos que solo son mencionados, ya que no son objeto de la investigación, es el caso de OpenStack y Neftconf.
7.1 OPENFLOW
Cuando nos referimos a Openflow encontramos que este es un tipo de tecnología o más bien un protocolo de conmutación abierto que se crea en el año 2008 y que se deriva de un proyecto de investigación de la universidad de Standford que pretendía buscar una solución para no afectar el tráfico normal de las redes de datos, ya que se basaban en que una red de datos puede ser gestionada como un todo y no como una cantidad de dispositivos que estén individuales.
Fuente: POPE, Erick. Agetic [imagen]. SW Virtual Libre y el protocolo OpenFlow (consultado: Noviembre 18 de 2018) disponible en
https://blog.agetic.gob.bo/2017/12/investigacion-en-la-agetic-el-switch-virtual-libre-y-el-protocolo-openflow/
54
7.2 VERSIONES
Openflow cambia la forma de pensar en las redes SDN y en la actualidad cuenta con 5 versiones las cuales son:OpenFlow v1.1 (Febrero 2011)
Características:
• Agregación de múltiples tablas: esta versión contaba solo con una tabla lo cual restringía todas las capacidades del hardware, en la actualidad es posible poder implementar múltiples tablas y agruparlas de manera que el rendimiento pueda aumentar para así tener una buena escalabilidad.
• Grupos: Cuenta con la opción de agregar los grupos de puertos con la idea de poder realizar acciones de redundancia.
• Soporte para la Etiquetas MPLS y Vlan: En esta versión ya se contaba con capacidades donde se pueden adicionar facilidades en la programación para el plano de reenvió, esto ya que los paquetes proveen mucha más información para el controlador.
• Puertos de tipo virtuales: esta versión permite la virtualización a una gran escala para diferentes clientes.
• Fallos en la conexión del controlador: la revisión de esta versión muestra un flujo de emergencia difícil de implementar, ya para la versión final y posterior evolución se ve que agregan dos tipos de modos para la conexión de red que son los siguientes:
• Modo seguro: aquí el conmutador puede seguir conectado con el flujo que se tiene establecido.
55 OpenFlow v1.2 (Diciembre 2011)
• Soporte de coincidencia: se puede eliminar ya el tamaño fijo que tienen las coincidencias con la idea de poder agregar más campos.
• Soporte de tipo básico para el IPv6: luego de agregar los campos en la coincidencia se puede dar soporte al IPv6.
• Cambio en el mecanismo conexión del controlador: como novedad ya todos los conmutadores se pueden conectar a varios controladores.
OpenFlow v1.3 (Abril 2013)
• Expansión al soporte IPv6: adición de más campos de incidencia.
• Estadísticas agregadas a los flujos: en el momento que se establecen los flujos ya es posible agregar la opción de medición y control a la tasa de paquetes.
• Tunnel ID meta datos: se agrega un campo de coincidencia que expone al proceso de encolamiento a la meta data para un puerto lógico.
OpenFlow v1.4 (Agosto 2013)
56
• Bundle: Crean Bundle con la necesidad de una agrupación en las modificaciones en las transacciones. También estas se generan con la idea de una utilización en la restauración y pre validación de los mensajes OpenFlow que se aplican a varios tipos de conmutadores.
• Cambios del puerto TCP por defecto al 6653: La IANA logra asignar a ONF el número de puerto como lo es el TCP 6653 con la idea que pueda ser utilizado por el protocolo de conmutador OpenFlow.
• Estabilidad adicional al protocolo: En esta opción ya se permite poder agregar de una forma más sencilla nuevas características al protocolo con la idea de integrarlas en el futuro y donde se amplía también la API de extensión de prueba.
✓ Estructura de puertos: se agregan propiedades de descripción mod y de stats de puertos.
✓ Estructuras de tablas: agregación de propiedades mod, descripción en la tabla multipart que añade mensajes asincrónicos para el estado de la tabla.
✓ Estructura de encolados: migración de la descripción en el encolamiento para varias partes y que convierte propiedades de la descripción en el encolamiento TLV estandarizados, que agrega propiedades de encolamiento a las estadísticas.
✓ Estructuras Set-async: se convierte set-async en una configuración TLVs y se agrega la propiedad de tipo experimental set-async.
✓ Estructuras de instrucción: agregación de instrucciones clasificadas como TLVs.
✓ Estructuras de acciones: Clasificar las acciones TLVs.
57
✓ Errores en las propiedades: Agregación conjunto de códigos de error que se unifican a todas las propiedades.
OpenFlow v1.5 (Diciembre 2014)
• Tabla de salida: en esta versión se logra introducir las tablas para el todo el procesamiento se pueda realizar en el contexto del puerto, y donde se puede procesar en la primera tabla de salida para lograr definir y redirigir el paquete a otros tipos de tablas.
• Campo OMX: se habilita las entradas de flujo y de salida para que pueda coincidir con el puerto saliente OXM_OF_ACTSET_OUTPUT.
✓ Donde el paquete que se envía a un puerto de salida logra ser procesado por la primera tabla de la salida.
✓ Aquí ya el procesamiento de grupo y la situación de puertos reservados ocurren mucho antes de las tablas de salida.
✓ Se logra definir el comportamiento que tienen las entradas de todas las tablas de salida y egreso esto de manera que sean similares a las entradas.
✓ Con el nuevo campo de incidencia (OXM_OF_ACTSET_OUTPUT) se utiliza para poder coincidir el valor de la salida y del conjunto de acciones esto de manera obligatoria para la salida y opcional en el ingreso.
✓ Prohibiciones en la agregación o acciones de grupo en el conjunto de acciones en la salida evitando que se cambie el puerto de salida.
58
✓ En todo el encolamiento ya se puede transportar desde el ingreso y hasta la salida.
✓ Las características de las tablas ya sirven para lograr identificar la tabla para usar (ingreso o salida)
✓ Introducción de comandos y solicitud de las características para la actualización de características en las tablas más sencillas.
7.3 CONTROLADORES OPENFLOW
Es bastante importante aclarar que un controlador es un tipo de entidad centralizada en toda la red OpenFlow, la cual se encarga de indicar a el conmutador todos los parámetros que van a definir cada uno de los flujos además de como los paquetes que van coincidiendo con el flujo deberían ser procesados.
La centralización del controlador mantiene en un tiempo real toda la información de la red con la idea de poder definir las rutas que deben de seguir todos los flujos en los conmutadores y enrutadores de una manera individual. Es entonces que con la información ya el controlador puede organizar todo él envió de los datos por medio de los tipos de dispositivos en la red, permitiendo toda la automatización y el aprovisionamiento de tipo dinámico para así lograr una buena distribución para los entornos virtualizados y de nube.
Esto nos dice que el controlador SDN se puede describir como un software o una biblioteca de sistemas que nos pueden brindar:
59
✓ Cuenta con su modelo de datos de alto nivel que puede capturar las relaciones entre los recursos que se gestionan los servicios prestados por el controlador y políticas, estos modelos de datos suelen construirse utilizando el modelado yang.
✓ El mecanismo de descubrimiento de los dispositivos, servicio y topología, además de un sistema de cálculo y ruta entre otros servicios de información centrados en la red o en los tipos de recursos.
✓ También cuenta con un tipo se sesión de control sobre el protocolo TCP que va entre en controlador y todos los agentes que están asociados a los elementos de la red.
✓ Además pueden obtener el estado de toda la red impulsado por todas las aplicaciones de los elementos que la incluyen.
✓ Cuenta con un conjunto de APIs, que nos exponen los servicios del controlador y las aplicaciones de la gestión, esto con la idea de poder facilitar la mayor parte de la interacción de este controlador y las aplicaciones, toda la interface se puede representar a través de un modelo de los datos que puede describir los servicios y las funciones del controlador. Pero muchas de las veces el controlador y la API suelen ser parte de un entorno en desarrollo y que genera código a partir del modelo de datos.
