Estaba dándole vueltas, por enésima vez, al famoso asunto de la implementación masiva de IPv6.
Me han venido a la cabeza las charlas de #irc-dev, en las que jcea siempre insistía en que IPv6 era algo que iba a tardar en llegar, cuando se le preguntaba por dar soporte IPv6 en el ircd. En marzo de 2004 surgió en la lista un hilo sobre un despliege en Japón y China. No era la primera vez, pero todo apuntaba a que 2005 iba a ser el gran año de IPv6, y prueba de ello eran los análisis que se hacían sobre el estado de IPv6 allá por 2004. Jesús tenía más razón que un santo.
Pues bien, estamos en casi los albores de 2007, y yo no sé vosotros, pero sigo conectando a mi ISP mediante IPv4.
IPv4 funciona, y funciona bien. De no haber sido así tened por seguro que se habría migrado masivamente a IPv6, y eso no ha sucedido. De todos modos IPv4 es un protocolo muy antiguo, y que tiene bastantes operativos ligados a su arquitectura:
- Ataques de denegación (distribuída) de servicios, DoS y DDoS. Las inundaciones de información en broadcasting y los ataques Smurf siguen estando ahí.
- La distribución de código malicioso automatizado, ya que el espacio IPv4 es corto y está saturado (más de dos terceras partes del espacio IPv4 está ya asignado), con lo que dar en la diana tirando el dardo sin mirar es de lo más sencillo.
- Los ataques Man in the Middle, ya que IPv4 no tiene características propias para proporcionar autenticación fuerte por sí mismo.
- Ataques de fragmentación, en los que se aprovecha lo mal que gestionan a veces las pilas de protocolo de algunos sistemas operativos la información fragmentada. Los más veteranos seguro que recuerdan los Nukes OOB (Out Of Band) y la legendaria pantalla azul de Windows.
- Ataques de reconocimiento y de escaneo de servicios. Escanear una clase C entera puede llevar bastante poco tiempo.
- Envenenamiento ARP y redirección de eco ICMP, o cómo desviar el tráfico a una dirección maliciosa.
IPv6 puede proporcionar mejoras no sólo para la seguridad, sino para el funcionamiento global de las comunicaciones. ¿Cómo?
- Proporcionando un espacio mayor. Pasamos de 2^32 a 2^128.
- Direccionamiento jerárquico. Desde el unicast (asignadas a un sólo nodo IPv6) al anycast (envíos segmentados a ciertos integrantes de un grupo determinado) (, pasando por el multicast (un grupo de nodos, la información llega a todos los integrantes). ¿En qué resulta esto? Tablas de enrutado mucho menores. Comunicaciones más optimizadas.
- Comunicaciones DHCPv6 que permiten configuraciones stateless y statefull.
- Calidad de servicio, QoS. Las cabeceras IPv6 contienen información específica que facilita la gestión del Quality of Service tanto para servicios diferenciados como integrados.
- Más rendimiento. Mejoran la gestión de paquetes y los tiempos de proceso.
- Pensado para la seguridad. IPSec en IPv6 es obligatorio, no opcional como sucede en IPv4.
- Extensibilidad. Las cabeceras IPv6 doblan en tamaño a las IPv4, pero sin embargo, las direcciones IPv6 son cuatro veces más largas. Las cabeceras IPv6 no contienen campos opcionales, lo que queramos enviar como opcional se hace vía cabeceras auxiliares. Esto reduce cómputo y tiempos, y simplifica la gestión.
- Movilidad. Trasladar nodos sin perder tiempo de operación es algo asumible en IPv6, mucho más fácil de lograr que en IPv4.
Una de las grandes ventajas de IPv6 es contemplar IPSec como algo obligatorio. Convertir IPSec en mandato obligatorio es harto interesante. Es una necesidad, diría yo. Mediante IPSec en IPv6 es posible reforzar la seguridad de las comunicaciones al menos desde las siguientes ópticas:
- Cabeceras y autenticación, que previenen la adulteración de las mismas (authentication header)
- Encapsulating Security Payload y la enorme ventaja que acarrea este encapsulado.
- Modo transporte (comunicaciones seguras entre extremos asegurando el payload de la comunicación) y modo túnel (no del todo necesario, ya que la autenticación de cabeceras y el Encapsulating Security Payload son suficientes para asegurar la comunicación)
- Negociación y gestion del intercambio de llaves, que se basa en que IPSec cumple con IKE.
Bueno, ¿dónde están los problemas de seguridad en IPv6?
La lista de posibles problemas podría ser:
- La coexistencia de IPv4 e IPv6. Mientras se traslada lo que hay en IPv4 a IPv6, es posible hallar problemas relacionados con la dualidad de pilas (dos infraestructuras, cada una con sus problemas propios)
- Manipulación de cabeceras. Pese a su diseño contra este tipo de actividad, no existe seguridad al 100%, como bien sabemos. No son descartables acciones futuras que burlen parte o la totalidad de los mecanismos de autenticación, especialmente en la fase de dualidad durante la migración.
- Ataques de inundación. El flood sólo se puede capear procesando la inundación y el tráfico, con lo que este tipo de ataques siempre estará ahí, si bien será más complicado para los atacantes.
- Movilidad. Al no existir este concepto en IPv4, nadie sabe a ciencia cierta cómo responderá realmente en IPv6. Todo un misterio pendiente de resolver.
¿Cómo está el panorama actualmente?
Como podéis imaginar, bastante verde. En pequeñas escalas y en redes locales se emplea bastante IPv6, ya que sistemas como Linux posibilitan su despliegue de una manera cómoda, rápida y segura, para servicios Intranet como SSH. Otros sistemas menos dados a innovar, como las plataformas Microsoft, admiten también IPv6, pero no gozan de la misma operatividad de servicios, muy poco consolidada en estos productos.
Tal y como dice la Wikipedia, ICANN anunció el 20 de julio de 2004 que los registros AAAA de IPv6 para Japón (.jp) y Corea (.kr) de código de país ya son visibles en los servidores raíz de DNS. El registro IPv6 para Francia fue añadido poco después. Poco esfuerzo adicional se ha hecho desde entonces.
Toda la información sobre IPv6 podéis encontrarla en The IPv6 Portal, un excelente servidor de noticias y documentación sobre el protocolo. En este extenso informe podéis ver en qué situación se encuentran los despliegues. En este otro documento se muestra el estado del soporte IPv6 de las aplicaciones de trabajo en red según grupos de actividad.
Todo está listo. ¿Por qué no lo están los ISPs, que son los que podrían dar el impulso definitivo?
PD: Como fuente principal, he empleado el documento original IPv6 Security Issues, escrito por Samuel Sotillo.
Hola
Me ha gustado tu artículo. Como estoy de acuerdo en tu análisis, voy a intentar contestar la pregunta que haces al final: ¿Por qué no está ya?
Para mí, la respuesta es: Porque el que apuesta por cambiarlo, sólo ve un coste añadido a algo que funciona y ningún beneficio. Es una cuestión de pasta. ¿Para qué cambiar algo que funciona (ipv4) si no hay nada que me obligue (la demanda) a hacer ese cambio?
Así que me temo, que en vez de un período de transición, que sería lo recomendable, pasaremos por uno de revolución, en la que de repente todo el mundo se volverá loco con ipv6 y sólo querrán cambiarse a IPv6.
Todo el mundo está de acuerdo en que un cambio a Ipv6 es beneficioso para todo el mundo en general, pero los agentes (usuarios, ISP, empresas, operadores) no ven claro que sea beneficioso para ellos.
Hasta pronto.
Curro
Aclarando el tema de anycast, decir que anycast es más complicado que «envíos segmentados a ciertos integrantes de un grupo determinado».
Lo que ocurre realmente con anycast es que el tráfico enviado a una dirección anycast llega únicamente a un destinatorio. Sin embargo, el propio protocolo IPv6 selecciona, de entre múltiples posibles destinatarios, el más conveniente.
Ejemplo: una empresa pone varios puntos de entrada a su red distribuidos geográficamente (por ejemplo, en España, Francia, Inglaterra e Italia). La idea es que, cuando un usuario de Internet acceda al servicio, lo haga entrando por el punto más cercano. Por ejemplo, si un usuario está en Londres, lo más lógico sería entrar por el nodo de Inglaterra.
Con anycast es posible conseguir esto. La idea es que los puntos de entrada tienen asignada la misma dirección IP. En IPv4, mediante el uso de BGP, es posible que cada ISP regional disponga de una ruta a dicha dirección IPv4 apuntando al punto de entrada más próximo. Por ejemplo, un ISP de Londres tendría una ruta para la IP correspondiente hacia el nodo de Londres, mientras que en España, un ISP de Madrid tendría otra ruta diferente encaminando esa IP hacia el punto de entrada de España.
Con respecto a DHCPv6, comentar que «stateless address configuration» no es una funcionalidad propia de DHCPv6, sino de IPv6 en sí mismo.
«Stateless address configuration» permite a un nodo generar automáticamente, normalmente a partir de su dirección MAC IEEEE, una dirección IPv6 link-local sin intervención de la red (excepto para la detección de dirección duplicada mediante DAD). Adicionalmente, el nodo IPv6 puede solicitar mediante ICMPv6 información adicional para generar una dirección IPv6 de ámbito global, normalmente mediante la solicitud de encaminador por la cual, un encaminador suministra información al solicitante como el prefijo IPv6 /64 que debe añadir a los 64 bits derivados de la dirección MAC para obtener una dirección IPv6 autoconfigurada.
Adicionalmente, el nodo puede solicitar información adicional utilizando DHCPv6, como un servidor de hora, servidor DNS, etc., pero configurar las direcciones IPv6 mediante «stateless address configuration», o bien, el nodo puede utilizar DHCPv6 para obtener también una dirección IPv6, sin utilizar «stateless address configuration».
Así pues, tenemos:
– Stateless address configuration (DHCPv6 _no_ suminstrar direcciones IPv6, pero puede suministrar información adicional como servidores DNS, NTP, etc.)
– Manual address configuration
– Stateful address configuration (DHCPv6 suministra la dirección IPv6, el prefijo de red e información adicional)
!Ah! Y ya que estoy contestón, decir que el que IPSec sea mandatorio en IPv6 no significa que esté habilitado por defecto. Por ello, no supone ningún cambio con respecto a IPv4: la mayoría de las implementaciones de IPv4 soportan IPSec en la actualidad, pero otra cosa muy diferente es que pueda usarse IPSec para cualquier tipo de comunicación.
El principal problema de IPSec es que necesita un «acuerdo» entre las dos entidades que participan en una comunicación unicast. Esto suele significar el uso de certificados digitales (o claves pre-compartidas, que es aún menos escalable), lo que complica el problema. Las PKIs distan mucho de ser usables a nivel global. Además, IPSec no está soportado para comunicaciones como multicast, o broadcast, lo que limita en parte su usabilidad en redes globales.
Curro,
Estoy contigo, es principalmente un problema de costes. De todos modos, todo se andará, y el día menos pensado tendremos migraciones masivas. Tiempo al tiempo :)
Felipe,
Mil gracias por tus excelentes aclaraciones. Sin duda, muy reveladoras :)
Perdona que los mensajes se hayan quedado atrapados en la cola de hipotético spam durantes unas horillas, y es que Akismet es un tanto puñetero a veces :P
Un saludo,