El blog de los empleados
de Telefónica I+D

Autor: Primitivo Matas 

Normalmente FMC (Fixed Mobile Convergence), término que describe las tecnologías que permitan una convergencia entre comunicaciones cableadas y las no cableadas o wireless, se asocia con dos tecnologías diferentes: Wi-FI FMC y Femtonodo FMC. La primera de ellas parte de terminales que utilizan tecnologías Wi-Fi y que , por tanto, exige unos dispositivos nuevos adaptados, mientras que la segunda hace uso de terminales “normales” de telefonía móvil que se conectan a través de nodos específicos denominados Femtonodos, tanto en el hogar como en otros entornos de interiores descongestionando la red móvil y mejorando la cobertura.

Los Femtonodos(o Home Enhanced Node B, en terminología 3GPP)  son estaciones base de telefonía móvil muy pequeñas, de muy poca potencia y coste reducido que se conectan con el resto de la red utilizando la conexión a internet del hogar (ADSL o similar) o de cualquier empresa y que son capaces de realizar, con menos capacidad (menos usuarios con llamadas activas a la vez), las misma funciones de una estación base en entornos de interior limitados. Además, al tener un enlace directo con el resto de dispositivos conectados a internet, nos va a permitir la conexión con otros sistemas como centralitas telefónicas (PBX ), dispositivos del hogar (televisión, vídeo…) o entre Femtonodos que trabajen de manera coordinada en entornos empresariales.

Existe un mundo de diferentes capacidades ofrecidas por este enlace convergente:

Integración con la red de transmisión de datos o “local breakout”. Permite a los sistemas de Femtonodos desviar su tráfico de voz y dato sobre Internet sin necesidad de utilizar la arquitectura de red propia del operador móvil.

Interconexión entre Femtonodos. Permitiría, entre otras cosas la coordinación entre grupos de Femtonodos para permitir traspasos entre ellas, de forma análoga a los traspasos que se realizan entre las diferentes estaciones base en el exterior.

 Interconexión PBX. Permitiría activar la conexión entre dispositivos móviles con una centralita analógica tradicional, utilizando los servicios que la misma ofreciera en una empresa, como marcación por extensión, conexiones entre diferentes sedes de la misma empresa…

En un mundo en búsqueda continua de mayor rapidez, eficacia y calidad de las comunicaciones móviles los Femtonodos, son sin duda alguna un paso adelante. No solo consiguen mejorar, con un coste muy bajo, la cobertura en áreas sensiblemente problemáticas, sino que nos abre un Nuevo Mundo de posibilidades de utilización del terminal móvil como un dispositivo multi-servicio tanto en el hogar cómo en entornos empresariales.

Los Femtonodos, podrían cambiar, a corto plazo la industria de telefonía móvil. Los operadores pueden pensar en construir una nueva generación de redes con un coste inferior y una arquitectura de red que permitiera la utilización de internet como medio de comunicación, abriendo un mundo de posibilidades y servicios novedosos para el usuario final basados en las transacciones hacia la red local, la integración con sistemas de telefonía fijas o las comunicaciones entre los Femtonodos.

Autor: Carlos Juan Díaz

El Consejo de la Unión Europea (Consejo de Ministros) ha propuesto un conjunto de nuevas normas que establecen penas más severas para los denominados delitos cibernéticos (los ataques masivos de denegación de servicio están de moda y grupos como Anonymous, cada día están más presentes en los medios de comunicación). Estas normas están pendientes de ser ratificadas por el Parlamento Europeo para convertirse en oficiales.

Aunque no queda muy claro cómo se procederá a identificar y luego procesar a los atacantes (se pretende crear, a nivel europeo, una unidad especializada en cibercrimen dependiente de la Europol), las sanciones ya están definidas:

• Todo aquello que pueda considerarse delito cibernético tendría una pena de prisión de al menos dos años (incluso en grado de tentativa).
• Se introducen sanciones específicas para los desarrolladores y distribuidores de malware, al igual que para aquellos que se dediquen al robo de contraseñas.
• Los creadores/administradores de botnets se enfrentarán a penas superiores a 3 años (ataques cometidos utilizando un número significativo de los sistemas).
• Para ataques organizados que causen daños graves a sistemas de terceros, se proponen penas a partir de 5 años (aquí encajarían a la perfección las acciones de protesta (ataques) perpetradas por Anonymous).
• Del mismo modo la intercepción ilegal de comunicaciones se convertirá en un delito penal. 

Las normas también tienen como objetivo mejorar la cooperación entre los países de la UE, mecanismos de comunicación de incidentes entre sus miembros (soporte 24/7 y capacidad de respuesta urgente a consultas). Del mismo modo los Estados miembros estarán obligados a recoger datos estadísticos ‘básicos’ sobre los delitos cibernéticos.

Las nuevas normas actualizarán la legislación vigente, (basada en los acuerdos adoptados a finales de 2004 en la Convención de Budapest). 

El documento completo podéis encontrarlo en:

http://www.consilium.europa.eu/uedocs/cms_data/docs/pressdata/en/jha/122516.pdf (Cybercrime – Attacks against IT systems)

Autor: Luis Cucala

Después de tanto tiempo hablando del llamado “Wi-Fi offloading”, parece que está tomando fuerza una nueva tendencia que podríamos llamar “femto offloading”; que consiste en descargar la capa macro de 3G mediante femtonodos.

En 2010 O2 UK puso en marcha una iniciativa que se ha traducido en una oferta comercial llamada “O2 Wifi”.

Básicamente consiste en que se instalan femtonodos que incluyen Wi-Fi en sitios públicos, como restaurantes de comida rápida, bancos, centros comerciales. El atractivo para el pequeño negocio donde se instala el equipo es la posibilidad de ofrecer Wi-Fi gratuito a sus clientes, y para los operadores la ventaja está en disponer de emplazamientos gratuitos donde dar cobertura 3G en interiores, descargando además a la capa macro.

Esto supone una ventaja considerable con respecto a la situación anterior, donde O2 UK pagaba a operadores de red Wi-Fi, como por ejemplo The Cloud, por permitir que nuestros clientes se conectaran a sus puntos de acceso, y además tenía que pagar al dueño de cada local donde se instalaba un femtonodo o una micro. Con la nueva estrategia, el dueño del local no cobra porque le instalemos un equipo que de cobertura 3G, porque a cambio ofrecemos la conectividad Wi-Fi que quiere para sus clientes. Todos contentos.

La tendencia se generaliza. El operador coreano SK Telecom planea instalar este año 10.000 femtos HSPA+ con Wi-Fi en lugares públicos. La noticia está aquí. El despliegue recibe el nombre de Data Femto, está orientado solo a datos, y se basa en equipos de un fabricante coreano llamado Contela, que emplea chipsets de IP Wireless. El despliegue que proponen es en este caso para entornos de alto tráfico, de modo que cada femtonodo puede soportar hasta 16 conexiones simultáneas, y la conectividad Wi-Fi se incorpora para complementar la capacidad del femtonodo.

De esta forma, la red de femtonodos descarga de tráfico a la capa macro 3G, y Wi-Fi se emplea para descargar a los femtonodos del tráfico menos crítico.

Autor: Marcos Reyes

Nodejs surge como una forma de sacar valor a la experiencia actual en lenguajes de scripting (en este caso javascript) en el lado servidor. Los perfiles de los desarrolladores Web suelen estar alejados de los problemas típicos que aparecen en los servicios de backend (sobre todo en cuanto a concurrencia y mejores practicas para el acceso a recursos compartidos y/o de entrada salida). Y por otra parte han incrementado la experiencia en programación asíncrona y orientada a eventos.Nodejs simplifica hasta el extremo este tipo de tareas, proponiendo un modelo de ejecución y programación “cerrado” y fácilmente inteligible que potencia la realización de servicios “eficientes” sin necesidad de tener en cuenta la complejidad habitual de este tipo de sistemas. Podría decirse que con Nodejs es difícil hacer las cosas mal.

En el lado negativo tenemos muchas funciones anidadas y clousures, así como una programación orientada a eventos que puede dificultar la inteligibilidad del código en algunos casos, pero que no dejan de ser buenas herramientas para definir el comportamiento de un servidor.Por supuesto NodeJs y su motor Javascript (V8) no son la opción más interesante para realizar procesamientos complejos de la información. No es tecnología para multiplicar matrices. Aunque el rendimiento de la V8 y sus mecanismos de optimización (JIT) proporcionan un rendimiento en ejecución más que aceptable para el dominio en el que NodeJs esta centrado: entornos en los que se necesita un intermediario que obtenga y proporcione datos presentes en otros sistemas (servir contenidos, acceder a una base de datos, hacer de proxy a servicios…). También se encuentra especialmente indicado para proporcionar datos en modo streaming sobre una misma conexión cliente. En realidad este es el escenario más común con el que nos encontramos en nuestros backend de servicios.

Modelo de ejecución

Desde el punto de vista del programador cada proceso servidor Nodejs cuenta con un único thread para servir todas las peticiones de los clientes (permitiendo N servidores diferentes asociados a dicho proceso). Todo se serializa en este punto, bajo un único bucle de eventos, evitando los problemas de la programación multithread. Ya no tenemos que preocuparnos de proteger memoria compartida o de problemas de carreras, minimizando tanto tiempos de desarrollo como la aparición de errores. Hay que tener en cuenta que servir una nueva petición supone muy poco esfuerzo para el proceso NodeJs, siendo una tarea mucho más ligera que crear un nuevo thread de petición tal y como harían gran parte los servidores multithread al uso.
Conviene remarcar que un fallo en la lógica de servicio de dicho thread (por ejemplo un memory-leak) puede hacer que el proceso NodeJs se “pare” dejando de servir todo tipo de peticiones. NodeJs ayuda a que esto no ocurra (gracias a su modelo de programación y a warnings que nos advierten de posibles problemas), pero conviene ser cuidadoso en este punto.
Respecto a los servidores que pre-crean sus threads de petición en el arranque (P. ej Cherokee) las diferencias no son tan obvias. Si se desea paralelismo a este nivel, deberían lanzarse N procesos -shared nothing- NodeJS junto con algún mecanismo de distribución de carga. Un mecanismo bastante versátil en la era Cloud y que puede considerarse muy interesante frente a un modelo multithread con memoria compartida.

Internamente NodeJs posee un pool de threads autogestionado. Sobre este pool, en general, se lanzan todas las tareas que requieren algún tipo de entrada salida (invocación a servicios, acceso al SO…) o todas aquellas que tareas que se consideren bloqueantes. Es decir NodeJs es monothread para el programador (y para el flujo de servicio principal), pero no lo es en ejecución. Todas las llamadas que impliquen una cierta espera son invocadas de forma asíncrona, proporcionando bien un manejador de callback, bien un patrón de suscripción a eventos. A partir de este punto es el pool de threads interno el que se encarga de la ejecución de la tarea, emitiendo el evento correspondiente cuando esta finalice (o ante cualquier otro supuesto que requiera nuestra intervención). Los bloqueos de espera en el thread principal son por tanto eliminados por construcción, tenemos solo un thread, pero en general siempre esta listo para servir trabajo (se supone que un proceso NodeJs puede servir sin problemas unos 10.000 clientes simultáneos), con una carga mínima en el sistema por cada nueva petición.

Fragmento Servidor

var http = require(’http’),

io = require(’socket.io’),

url = require(’url’);

console.log(’starting websocketserver’);

server = http.createServer().listen(8081);

var socket = io.listen(server);

socket.on(’connection‘, function(client){

console.log(’new client:’+client.sessionId);

client.broadcast(’New client connected:’+client.sessionId);

client.on(’message‘, function(msg){

switch(msg.type)

{

case ‘newuser’:

var err = createUser(msg.text, client.sessionId);

if (err==0) client.send(’Already registered’);

else client.send(msg.text+’ Is your new Nick Name’);

break;

default:

var userid = getUser(client.sessionId);

if (userid!=null){

//All but sender

client.broadcast(’<strong>’+userid+’</strong>->’+msg.text);

//Sender only

client.send(’<-’+msg.text);

}

else client.send(’<-YOU MUST STABLISH A NICK-NAME’);

}

});

client.on(’disconnect‘, function(){

console.log(’disconected:’+client.sessionId);

deleteUser(client.sessionId);

});

});

//(…) +=aux functions)

Fragmento CLIENTE

<script>

(…)

var socket = new io.Socket(SERVERADDR, SERVERPORT);

var nick=null;

socket.on(’connect’, function(){

var board = document.getElementById(’board’);

board.innerHTML = board.innerHTML + ‘</br>You are connected to chat’;

});

socket.connect();

socket.on(’message’, onMessage);

var board = document.getElementById(’board’);

function onMessage(message){

board.innerHTML = board.innerHTML + ‘</br>’ + message.text;

}

function sendbroadcastmsg (text){

var msg = new Object(); msg.type=’broadcast’;

msg.text=text; socket.send(msg);

return false;

}

function sendnewuser(name){

var msg = new Object();

msg.type=’newuser’;

msg.text=name;

socket.send(msg);

nick = name;

}

</script>

 Autor: Rafael Valdavida

Como los medios de comunicación han dejado  patente a lo largo de los últimos meses es el momento del IPv6. El espacio de direccionamiento de IPv4 se acaba, hay que buscar una solución e IPv6 parece ser que es lo primero que se le viene a la cabeza a todo el mundo. De hecho los últimos (y no tan últimos) productos tecnológicos incorporan ya soporte para IPv6. Un claro ejemplo es el Windows 7. Su pila IPv6 está activada por defecto y de forma preferente. Es decir, si ha de elegir entre IPv4 e IPv6 elegirá esta última.

Desde el punto de vista tecnológico IPv6 no es simplemente una solución para la escasez de espacio de direccionamiento. Se trae bajo el brazo su correspondiente juego de particularidades y un buen conjunto de protocolos adicionales (cabeceras de extensión, ICMPv6, NDP,  MLD, IPSec, ….). Para un potencial atacante cada una de las particularidades y características de esos protocolos es un campo abonado para el florecimiento de nuevas vulnerabilidades que pueden permitir todo tipo de acción maliciosa.

Centrémonos en UNA funcionalidad de UNO de esos protocolos. Una que por su relevancia y cercanía al usuario puede tener un mayor peso en la implementación de la solución IPv6. El protocolo NDP (Neighbor Discovery Protocol) se encarga, mediante la utilización de cinco tipos de mensajes ICMPv6, de proporcionar una serie de funcionalidades básicas. Entre ellas se encuentra la resolución de direcciones (identificar para una dirección IP dada qué dirección MAC le corresponde). Parece algo bastante básico para el funcionamiento de todo el tinglado.

En su definición, el protocolo NDP no especifica la necesidad de autentificación por parte de los participantes, lo que viene a significar que:

• Cualquiera puede enviar cualquier mensaje (y estamos hablando de mensajes básicos para la configuración y el funcionamiento de la red).
• Es muy difícil (¿imposible?) distinguir si la información de un mensaje dado proviene de quien se supone que debe provenir.

De hecho existe una tabla resumen sobre los posibles ataques a los que resulta susceptible el discutido protocolo NDP:

Es posible que la tabla requiera un poco más de explicación (qué son todos esos acrónimos y ‘palabras raras’) pero de por sí resulta muy ilustrativa. Incluso se puede adivinar que algunos de los problemas presentados no tienen, de momento, una solución clara (última columna).

En general, a lo largo de toda la especificación de IPv6, cada vez que surgen cuestiones sobre la seguridad la solución se redirige al uso de IPSec. No es este lugar para discutir las bondades o deficiencias de IPSec. Baste con decir que para el entorno del NDP, a día de hoy, IPSec no es una solución viable. Requiere no solo configuraciones engorrosas de claves privadas y públicas si no también resolver cuestiones sobre intercambios de claves (IKE). Bajo estas circunstancias nos encontramos con situaciones de vulnerabilidad bastante comunes. Por ejemplo, cualquier Windows 7, en su instalación por defecto, está preparado para funcionar bajo IPv6 y por tanto soporta el protocolo NDP de forma automática. Sin embargo en el proceso de instalación del sistema operativo o de su conexión a la red no se realiza ningún tipo de activación y configuración de IPSec.

Llegados a este punto yo diría que un posible atacante no solo dispone de un campo abonado. El campo ha florecido. Veamos un ejemplo de cómo un usuario malicioso puede aprovecharse de la situación descrita.

‘Man In The Middle’ en IPv6

El entorno considerado consta de los siguientes elementos:

• Red local IPv6
• Equipos A y B legítimos
• Equipo Z malicioso

En IPv6, como en IPv4, cuando el equipo ”A” quiere comunicarse con el “B” necesita saber la dirección de capa de enlace (MAC) de dicho equipo “B”. Para obtenerla , “A” envía a la red un mensaje ICMPv6 del tipo “Neighbour Solicitation” a una dirección IPv6 multicast (dirección en la que escuchan todos los nodos de la red) con el formato “ff02::1:ffXX:YYZZ”. Donde XXYYZZ se corresponde con los últimos tres bytes de la dirección IPv6 con la que desea comunicarse. El elemento “B” contestaría hacia “A” con un mensaje ICMPv6 del tipo “Neighbour Advertisement” donde “B” envía toda la información de capa de enlace necesaria para que “A” se comunique con “B”.

Conociendo este comportamiento, y con todo lo anterior dicho sobre la carencia de autentificación, “Z” solo necesitaría enviar mensajes ICMPv6 de tipo “Neighbour Advertisement” indicando:

• a “A” que la dirección IPv6 de “B” se corresponde con la dirección MAC de “Z”
• a “B” que la dirección IPv6 de “A” se corresponde con la dirección MAC de “Z”

Nada impide que “Z” pueda enviar este tipo de mensajes (los mensajes “Neighbour Advertisement” pueden ser enviados espontáneamente para indicar cambios en la configuración local o nuevas incorporaciones) y tras la recepción de estos mensajes “A” y  “B” almacenarán la información fraudulenta en sus cachés y comenzarán a utilizarla. Como resultado toda la información enviada de “B” hacia “A” y de “A” hacia “B” pasará por “Z” que podrá:

1. Acceder a la información intercambiada
2. Modificar la información intercambiada
3. Interrumpir la comunicación

Acabamos de replicar el ataque de envenenamiento de caché, típico de la tecnología IPv4, en IPv6 y sin más complejidad que la generación de dos paquetes IPv6 manipulados. La herramienta scapy, de libre acceso, ofrece toda la funcionalidad requerida. La solución, hoy por hoy no es sencilla, la opción sería proporcionar mecanismos de autentificación. Estaríamos hablando de configurar IPSec o una segunda posibilidad de más fácil aplicación y desarrollada para este problema que es el SEND (SEcure Neighbour Discovery). Pero eso ya es tema para otro/os artículos.

Autor: Ignacio Berberana

Un paso más en la historia de Wi-Fi. Se ha iniciado ya la votación en IEEE de la versión 1.0 de la nueva modificación del estándar 802.11  (bueno, de una de las nuevas modificaciones), la denominada 802.11ac, que pretende soportar tasas binarias próximas a 1 Gbit/s en frecuencias menores de 6 GHz. Lo que se está votando es si la aprobación del estándar se pasa a una nueva fase que se denomina votación de los ‘espónsores’ (quizás sería más correcto hablar de promotores). Es decir, si el resultado de la votación es positivo, se da por concluido el trabajo inicial del grupo de trabajo, en el que pueden votar todas las personas que cumplan con los requisitos necesarios para hacerlo (relacionados con la asistencia a las reuniones y el hecho de haber ejercido le derecho al voto en votaciones anteriores), y se pasa a una fase en la que votan compañías que se comprometen a apoyar al estándar resultante (para estar incluido en la lista de ‘espónsores’ hay que pagar una cuota a IEEE). En esta ronda de votaciones, si se vota que no se aprueba el estándar, hay que indicar también qué es lo que habría que cambiar en el mismo para votar positivamente a su aprobación. Si el grupo de trabajo decidiera no aprobar remitir el borrador a los ‘espónsores’, debería seguir trabajando para producir una nueva versión aceptable. El plazo de votación, que hasta hace poco se realizaba mediante carta (cosas de IEEE), finaliza el 26 de junio.

¿Quiere esto decir que estamos próximos a la aprobación definitiva del estándar? No necesariamente. En el caso de 802.11n, por ejemplo, pasaron más de tres años desde que se aprobó la versión 1.0 en el grupo de trabaja TGn (mayo de 2006) hasta que se aprobó su publicación por un comité denominado RevCom (septiembre de 2009), último paso en el proceso de producción del estándar.

Previsiblemente en el caso de 11ac los plazos serán más reducidos. Después de todo, las modificaciones propuestas no son fundamentales: MIMO de mayor orden (hasta 8×8 – frente a 4×4 en 11n), agregación de canales (80 y 160 MHz – un máximo de 40 MHz en 11n) y modulaciones más complejas (hasta 256QAM, lo que permite transmitir 8 bits por hercio – 64 QAM en 11n). Es decir, más de lo mismo. Las principales novedades son el uso de los denominados códigos cortos (que pueden ser más efectivos para datos que requieren una latencia baja) y el soporte a MIMO multiusuario (que se basa en asignar los mismos recursos a dos usuarios espacialmente separados mediante el uso de antenas directivas).

En paralelo, se está desarrollando otra versión del estándar, la 802.11ad, que está diseñada para operar en la banda sin licencia de 60 GHz y que, por tanto, tiene un rango de cobertura más reducido (normalmente limitado a la habitación en la que esté instalado el punto de acceso) pero puede soportar hasta 7 Gbit/s (teóricamente). En este caso se está votando si se remite a los ‘espónsores’ la versión 3.0 del borrador de la misma.

Y sí, IEEE ha agotado todas las letras disponibles para numerar las modificaciones del estándar y por eso en las nuevas se utilizan dos. Por cierto, el uso de minúsculas indica que se trata de una modificación de un estándar existente, mientras que si la letra es mayúscula indica que se trata de un estándar independiente.

Autor: Valentín Alonso

Con los titulares tan llamativos que hemos visto durante estos últimos días cualquiera puede concluir que los móviles son nocivos para la salud, nada más lejos de la realidad. Es la historia de la botella medio llena o medio vacía.

Han aparecido durante estos días varias publicaciones al respecto con grandes titulares, como por ejemplo [1] “Cellphones ‘possibly carcinogenic,’ report suggests” que matiza en el subtítulo que se está revisando la relación entre un tipo de radiación electromagnética presente en los teléfonos, microondas y radares “International agency reviewed link between type of electromagnetic radiation found in phone, microwaves and radar”… como si fuera lo mismo un AWACS que un walki-talki

El origen de todo este revuelo está en la importante revista científica The Lancet Oncology en la que el prestigioso IARC Working Group ha presentado un estudio que resume las principales conclusiones de su trabajo sobre la evaluación del impacto para la salud de las exposiciones a campos electromagnéticos de RF (incluyendo el uso de teléfonos móviles)

Una lectura rápida del informe nos permite leer en su introducción:

“Based on the epidemiological evidence available now, the main public-health concern is clearly motor vehicle collisions,”

Es decir, en leguaje coloquial, el mayor riesgo para la salud cuando usas el móvil es utilizarlo cuando conduces un coche.

[1]http://www.msnbc.msn.com/id/43225917/ns/health-cancer/t/cellphones-possibly-carcinogenic-report-suggests/

Autor: Luis Miguel Campoy

Desde hacía algún tiempo, se ha venido comentando, en este y otros foros, que el sistema Wimax era una opción con ciertas desventajas tecnológicas para dar servicios de acceso radio celular, al ser una evolución de acceso radio fija. La balanza comparativa con sistemas actualmente en auge en el 3GPP como LTE o LTE-A, cuyo desarrollo está enfocado desde un principio a estos servicios, está siendo cada vez más desequilibrada.

Este enfoque evolutivo desde las actuales redes HSPA hace que LTE sea interoperable con ellas (algo no posible con redes WiMax), así como que parámetros básicos para ofrecer una QoS adecuada en aplicaciones más exigentes como la latencia de respuesta de la red, sean cinco veces mejor en LTE que en Wimax.

Uno de los últimos puntos de desequilibrio lo acaba de proporcionar Clearwire, uno de los operadores que más sistemas WiMAX ha desplegado, que ha llegado a un acuerdo de gestión de red con Ericsson, uno de los principales impulsores de LTE y LTE-A en el 3GPP, con lo que el rumor de que Clearwire abandonará en breve WiMAX para la cobertura celular está creciendo(véase este artículo).

Todo hace pensar que el futuro (ya presente en algunos países) de los sistemas LTE, LTE-A será algo más que prometedor, siendo la unión de Clearwire al masivo número de operadores y fabricantes que están apostando por la tecnología LTE una gota más en el constante aumento del ecosistema de actores implicados en esta tecnología.