Cinco razones para no invertir aún en SDN
Hablamos con un grupo de líderes de TI quienes explicaron por qué aún no pueden recomendar la inversión en SDN.
SDN se está convirtiendo poco a poco en una realidad en las empresas de gran tamaño que necesitan redes de alto rendimiento a cualquier precio, pero el paisaje es muy diferente entre las organizaciones grandes y medianas.
Si bien los proveedores están activamente produciendo soluciones SDN, y los analistas predicen una captación sólida para 2016, la mayoría de los ingenieros de red corporativos dicen que no van a estar listos para una inversión en SDN hasta que se aborden algunas preocupaciones clave.
Un grupo de líderes de TI entrevistados para este artículo citó preocupaciones que van desde un desempeño disminuido de la seguridad hasta la falta de estándares SDN, que les impedirá recomendar inversiones en SDN, por lo menos en el corto plazo.
Preocupación No. 1: Seguridad y desempeño del monitoreo
El personal de TI tiene, ante todo, temor de que el monitoreo de seguridad sufrirá cuando la pila de SDN se reúna conjuntamente con el hipervisor y la infraestructura física.
“Antes de que veamos la adopción SDN para entornos seguros y de misión crítica, los proveedores tienen que trabajar en cómo las interfaces de la pila de software de SDN con hipervisores en entornos de nubey en la capa de virtualización”, dijo George Magklaras, ingeniero de sistemas senior en el Centro de Biotecnología de Oslo.
Hoy en día, cuando TI envía una serie de bytes por un camino de red mediante un dispositivo Juniper, hay controles estáticos que hacen que sea difícil para los atacantes ejecutar malware para crear fugas de información. "Eso no es cierto cuando usted está hablando sobre el mismo escenario utilizando pilas en la nube e hipervisores”, dijo Magklaras.
¿Los IDS/IPS trabajarán en un entorno SDN?
Magklaras es también un jefe consultor en Steelcyber Scientific, donde implementó un piloto de SDN para una gran organización financiera, solo para ver sufrir el desempeño de seguridad, sobre todo cuando se trataba de IDS/IPS.
El equipo de Magklaras colocó un controlador SDN basado en OpenDaylight en un entorno con hardware de Cisco y HP. “Teníamos la responsabilidad de supervisar una migración piloto de unas 60 VLAN hacia [un control] OpenDayLight utilizando un modelo de nube privada OpenStack", dijo Magklaras.
Los problemas surgieron con la supervisión de la red de sistemas IDS/IPS de entrada y salida, dijo. IDS/IPS trabaja explorando una gama de puertos, o un puerto en particular, para replicar todo el tráfico de una VLAN o de un segmento de red para detección (sniffing). El hardware y software tradicionales de switch replican ese tráfico y lo sirven en el sistema IDS/IPS. En contraste, SDN utiliza un hipervisor y rutinas generales del sistema operativo para replicar el tráfico.
"Las pruebas que llevamos a cabo en una variedad de sistemas IDS/IPS mostraron que SDN pierde aproximadamente el 25% a 30% de los eventos y vectores de ataque. Atribuimos eso a que la pila de software SDN es más lenta para replicar el tráfico en los puertos y también que deja caer cuadros/tráfico de Ethernet", dijo Magklaras.
Problemas rastreando direcciones MAC
El equipo de Magklaras también encontró un problema en el seguimiento de las direcciones MAC de los dispositivos que estaban conectados a las redes cableadas e inalámbricas. "Muchas de las direcciones MAC registradas no eran correctas debido a fallas en el software SDN”, dijo Magklaras. "El software SDN estaba soltando las direcciones MAC en segmentos de red congestionados [debido a problemas con el arranque PXE], y SDN incluso corrompió las direcciones MAC en su registro de software", explicó.
El hipervisor como un punto débil de seguridad
Durante esta prueba, Magklaras encontró que, en algunas circunstancias, los atacantes podrían aprovechar los hipervisores para ver el tráfico de red que no debería haber estado expuesto.
Una vez que se elude la seguridad del hipervisor, un atacante no autorizado podría utilizar permisos de root para aprovechar las redes VLAN, explicó.
VMware y otros están trabajando para hacer frente a los problemas de seguridad, pero las "vulnerabilidades aún no están cerradas", explicó Magklaras. "Por eso nos resulta difícil recomendar las pilas de SDN a organizaciones financieras y otros clientes. Sabemos que con el tiempo les va a ahorrar dinero y será el camino a seguir, pero por ahora tenemos que ser cautelosos”.
Problema No. 2: Probar la automatización y el trabajo de DevOps
Gran parte de la emoción sobre SDN se ha centrado en su capacidad de tomar decisiones basadas en políticas sobre el tráfico, en función de su origen o de destino desde un punto de control centralizado.
No necesito whitepapers de los proveedores, webinars o simposios en el desayuno. Si mis colegas y compañeros juran por ella, no contra ella... esa es una fantástica manera de saber que una tecnología funciona.
Pero SDN también promete automatización y aprovisionamiento dinámico –y esto es mucho más que una preocupación para los profesionales de la red. En concreto, los ingenieros de red quieren ser capaces de usar SDN para DevOps y para crear un marco que una hardware de proveedores heterogéneos utilizando un motor para presentar automáticamente el servicio a los clientes. No es probable que inviertan en SDN hasta que puedan demostrar que esto es una realidad, según Christian Teeft, director de tecnología del proveedor de nube Latisys.
"Latisys ha aprovechado algunas de las capacidades de Arista Networks para hacer alguna orquestación de fase uno y automatización de aprovisionamiento. La razón por la cual más organizaciones no están haciendo eso se debe a que carecen de los recursos en DevOps para llevar sus sistemas de aprovisionamiento existentes a ese nivel”, dijo Teeft.
Desafío SDN No. 3: Falta de familiaridad
Los profesionales de redes leen mucho acerca de los beneficios de SDN, pero no han visto la infraestructura dinámica en acción. Mientras tanto, sus entornos existentes están bien definidos, y los ingenieros tienen sus propios métodos establecidos para realizar tareas de red. Esos métodos pueden consumir mucho tiempo, pero funcionan.
"Los ingenieros de red deben ser capaces de lograr las mismas cosas con SDN que las que están acostumbrados a hacer con las combinaciones de hardware y software conocidos," dijo Magklaras.
Hasta que no pongan sus manos en la tecnología SDN y hagan que funcione para sus necesidades individuales, los profesionales de redes no invertirán.
"Nuestros ingenieros de redes necesitan entender cómo SDN satisfacerá las necesidades específicas de sus clientes”, dijo Jason Parry, vicepresidente de Soluciones para Clientes en Force3 y anteriormente gerente de ingeniería de redes en SafeNet Inc.
"SDN es todavía nuevo. Es un cambio en la manera de implementar, administrar, soportar y configurar redes. La promesa de la SDN es la automatización de la red, la orquestación y nuevas eficiencias. Mis ingenieros de red necesitan ver que SDN se pruebe a sí mismo de esa forma", dijo.
Preocupación No. 4: No hay estándar de SDN o conjunto de habilidades
Para que los ingenieros conozcan SDN, necesitan nuevas habilidades, pero no están necesariamente seguros de por dónde empezar, ya que no está claro cuáles estrategias de SDN seguirán (siendo utilizadas).
"Los ingenieros de red quieren entender cómo afecta SDN sus conjuntos de habilidades existentes", dijo Parry.
A los ingenieros les gustaría ver alguna estandarización en cómo se implementa SDN, y luego entender cómo eso está vinculado a una claro conjunto de habilidades para que sepan cómo adaptarse. Hace apenas dos años, se suponía que OpenFlow sería fundamental para SDN, pero ahora está cayendo en desgracia entre muchos proveedores y organizaciones de la industria.
En este punto, "los ingenieros tendrían que aprender por lo menos un poco de todo lo que está pasando ahí fuera, incluyendo OpenFlow", dijo Parry.
Preocupación No. 5: Venderle SDN a los tomadores de decisiones
Incluso una vez que los profesionales de red y los administradores de TI se vuelvan íntimos con NEE y sus beneficios, aún tendrán que convencer a los de arriba para invertir, y eso no será fácil.
"SDN no ha despegado debido a que requiere una enorme cantidad de tiempo, dinero y hardware. Tratar de venderle a la junta directiva esta visión a largo plazo es algo que muchos directores de TI no están preparados para hacer", dijo Ben Rothke, gerente de seguridad de la información de una importante empresa internacional de hospitalidad.
SDN es un enorme esfuerzo de reingeniería de la infraestructura. "Muchos de los CIO simplemente no tienen el tiempo, personal y dinero para hacer que funcione", dijo. Hay un sentimiento de "otro enfoque de red" más con el cual hay que lidiar, lo cual asusta a la gente, añadió.
Si hubiera más casos de uso de SDN disponibles, la tecnología podría ser más fácil de vender.
"SDN se define como una arquitectura emergente. El término clave aquí es emergente. Está en desarrollo, maduración, y no parece tener un montón de grandes historias de éxito", dijo Rothke.
Rothke dijo que se sentirá cómodo recomendando inversiones en SDN cuando muchos de sus compañeros le digan que SDN funciona.
"Yo no necesito whitepapers de los proveedores, webinars o simposios en el desayuno. Si mis colegas y compañeros juran por ella, no contra ella... esa es una fantástica manera de saber que una tecnología funciona", dijo.
