ISPs & Smart Cities

LogoSmartCitiy-2DPara los que seáis “millenials” y aquellos a quienes no les suene el término, los “ISPs” o “PSI” (Proveedores de Servicios Internet) fueron el germen del desarrollo masivo de internet en España y en el mundo, sin tener en cuenta la aportación en este ámbito de las redes académicas. En España lo fue “RedIRIS” (Red Académica e Investigación Española), que ya desde finales de los 80 (programa horizontal IRIS, 1988) conectaba las universidades y centros de investigación a Internet, cuyo desarrollo es anterior a esto que os quiero contar (si os interesa aquí podéis leer más al respecto).

Pues bien, a lo que iba… en los años 90, los ISPs, surgieron como setas en un día de otoño, ocurrió a nivel mundial, pero en especial en España. Recuerdo que en 1998 y 1999, no se daba abasto en el ES NIC (registro del dominio “.es” antes parte de RedIRIS y ahora gestionada por Red.ES) para poder registrar el dominio de cada proveedor (ISP) bajo el dominio “.es”. Tuve la suerte de estar por allí aquellos maravillosos años, si os interesa su historia, podéis consultarla aquí.

Para que os hagáis una idea, en EE.UU había 150 ISPs para 60 millones de usuarios, mientras que en España llegó a haber 1.000 ISPs para menos de 1,5 millones de internautas. Las cifras hablan por sí solas…  La “era .com” había comenzado, y en España nos habíamos vuelto locos por conectar a la gente a Internet. Al final sólo quedaron los grandes… por otra parte era de prever.

El caso es que todo esto nos dio trabajo a muchos; diseñando, construyendo y administrando los servicios del ISP, sus redes de acceso telefónico (redes “dial”) y sus propios servicios internet: DNS, email, ftp, news, listas de distribución de email, etc.  Un jefe que tuve en aquella época nos denominó “iesperos”…  me quedaré con lo positivo del término, porque mal… suena un rato :-).

Esto que escribo a continuación, son mis reflexiones sobre las soluciones de ciudad inteligente, acordándome de aquellos años en los que algunos participábamos en el diseño y puesta en marcha de los mencionados ISPs.

Entonces, lo primordial para todos aquellos ISPs era dar servicio, que los usuarios se conectaran y navegaran, algunos os acordaréis de los módems y su característica música al iniciar y negociar la velocidad de la conexión. Estábamos en la era de las redes de acceso telefónico o redes “dial”, no existía todavía ni el ADSL, ni el cable, ni por supuesto la fibra (en el hogar)… todo eso estaba por llegar…

Tampoco había mucho que elegir a la hora de navegar por internet: “Mosaic”, “Netscape” o las primeras versiones de “Internet Explorer”.

Todo se desarrolló muy rápido y con el cambio de siglo, quizás motivado en parte por circunstancias como “el bug del milenio”, la paranoia de la redundancia y la alta disponibilidad se contagió rápido en el mundo del ISP, hasta el punto en que se redundaba hasta lo que no tenía mucho sentido redundar: Desde las fuentes de alimentación, los sistemas de almacenamiento, pasando por servidores, conexiones entre almacenamiento y dichos servidores, conexiones de red de los servidores, conmutadores (switches) a los que éstos estaban conectados, los enrutadores (routers) a los que los conmutadores estaban conectados… y así cualquier otro elemento que estuviera conectado por el camino…   firewalls, etc.  Los servicios se acabaron balanceando, “clusterizando”, virtualizando…  y aun así, muchas veces, incluso hoy en día, quizás por lo complicado que se han vuelto algunas cosas, acabamos sin poder dar servicio ni cumplir con los famosos “Niveles de Acuerdo de Servicio” (o “SLAs”, “Service Level Agreements”, en inglés). A principios de los años 2000, se llegó a un punto en el que se cuestionaba el coste de toda esta redundancia multinivel.

Lo mismo ocurrió en el terreno de la seguridad. Hasta los años 90, la seguridad brillaba prácticamente por su ausencia en Internet. Fue a principios de aquella década, cuando aparecieron los primeros firewalls (checkpoint FW1), los antivirus ya existían, pero Internet los revolucionó para poder detectar nuevos ataques desde Internet, en especial los de tipo “gusano” (internet worms) y todos aquellos que explotaban “bugs” (fallos de programación) de distintos servicios de red existentes.

Quizás por la experiencia adquirida diseñando, construyendo y operando aquellos  ISPs de hace ya más de 20 años, transitando a lo largo de mi carrera por el diseño de servicios y redes, hasta hoy en día, dedicado al mundo de las ciudades inteligentes, muchas veces veo que se plantean soluciones que carecen de la redundancia y/o robustez que desde mi punto de vista debieran ser necesarios para dar servicio. El foco de atención está, como lo estuvo entonces en el mundo de los ISPs, en dar servicio y no tanto en la robustez y garantía del mismo.

Por otra parte muchas soluciones “Smart” se basan en dar servicio sobre alguna de las infraestructuras ya existentes en la ciudad. Por ejemplo en los soportes del servicio de alumbrado, o los contenedores del servicio de residuos, como plataformas que den soporte a nuevos servicios, conectándolo todo a través de la red wifi municipal, o de la red móvil de un único proveedor de telecomunicaciones…   y pienso, ¿es eso suficiente?, ¿nos hemos parado a pensar en las implicaciones que tiene esto a nivel de garantía del servicio?, ¿las implicaciones técnicas que puede tener?.

Imaginad una solución de gestión de alumbrado municipal que depende de la red de un solo operador de telecomunicaciones. Antes o después fallará. No se trata de que dicho operador sea mejor o peor que otro, simplemente es estadísticamente seguro que en un momento dado, fallará la conexión.

Estoy convencido de que en menos de 10 años estaremos otra vez en ese punto en el que la redundancia de las soluciones de ciudad inteligente, su seguridad, los niveles de servicio (SLAs) y su monitorización 24×7 (i.e. 24 horas durante los 7 días de la semana), será una obsesión para los gestores municipales y por lo tanto para los desarrolladores, diseñadores y fabricantes de soluciones de ciudad inteligente. Por eso, si ya hemos pasado por ahí en otros ámbitos del desarrollo tecnológico, por qué no ponerle un poquito de sentido común y aplicar las lecciones aprendidas, sin volvernos paranoicos (i.e. sin que el coste de dichas redundancias acaben por hacerlo no rentable), pero asegurando los servicios críticos de una ciudad que queremos convertir en inteligente, sin hacerla también vulnerable a la vez.

Sería bueno que se calculara la probabilidad de indisponibilidad de un determinado servicio municipal que se quiera transformar en inteligente (“smartizar”), y sí, si es necesario dotarlo de un SLA etc, pero primero, calculemos, midamos y observemos cuales son los puntos singulares de fallo de estas soluciones, reforzándolos como se pueda técnicamente, redundando la posibilidad de transmitir datos, asegurando (si tiene sentido) la alimentación (eléctrica) y la conectividad de los dispositivos que tengamos desplegados en la ciudad, estableciendo y aplicando políticas, procedimientos y medidas de seguridad (v.g. impedir configuraciones por defecto, actualizar el SW y el Firmware de los dispositivos cuando sea preciso, aplicar parches y técnicas de encriptación cuando sea necesario, impedir el acceso físico no autorizado a los dispositivos) que impidan que los dispositivos y servicios de gestión de una ciudad inteligente sean vulnerables a un ataque malicioso.

En el plano normativo, se están desarrollando documentos relacionados con las infraestructuras de ciudad inteligente, que abordan estos conceptos, estableciendo y estandarizando métricas, niveles de servicio, y niveles de redundancia y recomendaciones que las distintas infraestructuras relacionadas con la ciudad inteligente debería observar. En concreto en España, el grupo de trabajo de AENOR CTN178/SC1 está centrado en esta tarea, a través de las distintas partes de las normas: 178101 (“Redes de Servicios Públicos), 178102 (Despliegue de Infraestructuras TIC), 178107 (Guía para las infraestructuras de ciudades inteligentes. Redes de acceso y transporte”), 178103 (Convergencia de los sistemas de Gestión-Control en una Ciudad inteligente), 178104 (Sistemas integrales de gestión en una ciudad inteligente), 178105 (Accesibilidad universal).

La realidad es tozuda, seguramente en el futuro seremos testigos de algunas situaciones de caos urbano (apagones, caos circulatorio, etc) en las ciudades más desarrolladas técnicamente, seguramente debidas a la falta de redundancia y robustez del diseño de alguna parte de un determinado servicio municipal.

Es probable que sólo estos “tropiezos” nos lleven hacia la adopción de soluciones más redundantes y seguras, basadas en estándares o no, como ocurriera en la era de los ISPs… y como sigue ocurriendo en el mundo de la tecnología habitualmente y con la humanidad en general. Quizás, como digo, con un poco de cautela y de sentido común logremos impedir alguna de esas situaciones en nuestras ciudades.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s