Actualidad de RedIRIS...5 tienen direccionamiento IPv6 asignado (del bloque asignado por RIPE a...

Durante estos últimos meses la red nacional hapermanecido muy estable en cuanto a cambiosen enlaces o equipamiento se refiere. Dichainfraestructura ha soportado varios proyectosque requerían unas necesidades especiales. Estees el caso de ATRIUM proyecto queinterconectaba Telefónica I+D en España conVTHD en Francia a través de la red GÉANT yRENATER (NREN francesa), utilizando una redprivada virtual de nivel 2 configurada con MPLS(http://www.alcatel.be/atrium).

También el proyecto Opera Oberta finalizó susegunda temporada con la transmisión de laúltima ópera el pasado 24 de marzo. Estastransmisiones se realizan sobre la red multicastnativa con una demanda de ancho de bandasuperior a los 11 Mbps. Esta temporada hansido 27 las universidades que han participadoen el proyecto (http://opera-oberta.liceubarcelona.com). Se han hecho pruebas detransmisión con la Universidad Nal. Autónomade Méjico con resultados satisfactorios.

En enero de este año tuvo lugar un evento enBruselas organizado por la Comisión Europeacon ocasión del lanzamiento del servicio IPv6(Global IPv6 Summit, http://www.global-ipv6.net/) Durante ese evento, como veremosmás adelante, una de las demostraciones de usode la red IPv6 nativa fue la transferencia devideo de alta definición desde la UPC hasta lasede de la conferencia.

En los próximos meses nos esperan cambiosimportantes. Además de alguna actualizaciónde hardware, el cambio más importante será lamigración de los routers centrales de la red aotra ubicación, aún pendiente de determinar yaque su decisión será fruto de un concursopúblico que se lanzará próximamente.Actualmente estamos elaborando el plan demigración de forma coordinada con losoperadores de los enlaces de todos los equiposde forma que se minimice el impacto en elservicio de la red y el tiempo de migración.

Seguiremos informando sobre este punto.

• GÉANT

La conectividad con GÉANT se modificósignificativamente mejorando tanto encapacidad como en fiabilidad. Así el pasado 7 deoctubre entró en operación una lambda (sinprotección) de 10 Gbps como enlace de conexióncon GÉANT. El enlace que hasta ese momentoteníamos de 2,5 Gbps (con protección óptica) semantiene como enlace de respaldo, aunqueeliminando la protección y proporcionando deesta forma no sólo una gran fiabilidad a nivel deenlace (ambas lambdas están configuradas porrutas físicas distintas) sino también a nivel depuerto físico en el router.

Este aumento de capacidad de conexión entreRedIRIS y GÈANT a 10 Gbps se soporta con laactualización de los dos enlaces de GÈANT quellegan a España; los enlaces Madrid-Milán yMadrid-París también se han visto aumentadosa 10 Gbps.

La conectividad de GÈANT con otras redesmundiales de investigación también se ha vistoincrementada. Anteriormente la red pan-europea proporcionaba tres enlaces de STM-64(2,5 Gbps) para la interconexión con las redesdel continente americano (ABILENE, CANARIE yEsnet) y desde finales del año pasado se puso enoperación una lambda de 10 Gbps financiadapor la National Science Foundation (NSF) de lasque un enlace de 2,5 Gbps + 2 enlaces GE seutilizan para tráfico en producción con estasredes. Esta conectividad global se veincrementada con el enlace 2,5 Gbps con SINETla red de investigación japonesa.

• Situación de la conectividad IPv6

Durante el segundo trimestre del año 2003 sediseñó, planificó e implementó el soporte IPv6nativo en la red. La conectividad con GÉANTsoporta IPv6 nativo. Las conexiones con laInternet comercial global también soportan IPv6pero a través de un túnel (por limitaciones deloperador) y –como se verá en el siguientepunto– son varios los operadores con los se haestablecido un peering IPv6 (a través de untúnel) en ESPANIX.

3Actualidad http://www.rediris.es/rediris/boletin/68-69/actualidad.pdf

Actualidad de Red

Actualidadde Red

Actualidadde RedIRIS

El rango de direccionamiento IPv6 del 6bone,debe ser liberado y devuelto sustituyéndose porel perteneciente a RIPE antes del 6/6/2006.Aunque por un acuerdo global entre las NRENseuropeas, por GÉANT ya no se enruta esterango desde enero 2004 (plazos anunciados envarias ocasiones por la lista IRIS-IP). Se puedesolicitar direccionamiento en: http://www.rediris.es/red/iris-ipv6/direccionamientoipv6.html

Una vez que las redes de ámbito nacional einternacional soportan el protocolo, el siguientepaso es en las instituciones –en caso de nohaberse dado ya–. Con el fin de obtenerinformación sobre el despliegue de IPv6 enellas, desde RedIRIS se lanzó una encuesta cuyoresultado fue el siguiente:

• 14 respuestas recibidas.• 3 tienen conexión nativa o a través de túnel.• 5 tienen direccionamiento IPv6 asignado (del

bloque asignado por RIPE a RedIRIS).• 9 no tienen nada.

En general de los que tienen conexión IPv6,entre el 0-6% de los usuarios tienen acceso a lared IPv6 (con una excepción, donde el 20% delos usuarios tienen acceso a la red IPv6)

Y si tomamos los datos reales del NOC encuanto a conexiones funcionando y peticionesde direccionamiento realizadas el resultado es:

• 13 asignaciones realizadas a instituciones(del bloque asignado a RedIRIS por RIPE)

• 2 asignaciones a proyectos.• 5 conexiones nativas (incluyendo dos redes

autonómicas)• 2 conexiones con túneles.

Estos resultados (tomando la referencia de lasmás de 250 instituciones a las que se da servicio)ponen de manifiesto que el despliegue en lasinstituciones en España es muy pequeñoaunque prácticamente igual al que se observaen otras redes europeas de nuestro entorno,por lo que aún queda mucho trabajo por haceren este campo.

• Multicast IPv6

Desde el pasado 15 de Junio, RedIRIS disponede conexión multicast IPv6. Esta conexión se harealizado a la red m6bone (www.m6bone.net),mediante un túnel, ya que en GÉANT no sedispone de IPv6 multicast nativo.

Los centros conectados a la red, que dispongande conexión IPv6 unicast, se pueden conectar ala red IPv6 multicast también mediante un túnela un router Cisco situado en Madrid.

De esta forma, se inicia la experimentación yfamiliarización con esta tecnología en la red,como paso previo a su puesta en producción.

Los centros interesados en la conexión puedenrealizar su petición a [email protected]

• Estado de la conectividad en PuntosNeutros: ESPANIX y CATNIX

Los peerings establecidos en ESPANIX son lossiguientes, ordenados según fecha deestablecimiento apareciendo en negrita los queademás tienen establecido un peering IPv6.

En CATNIX la situación es la siguiente:

• ALICE y EUMEDCONNECT

El proyecto ALICE, cofinanciado por la ComisiónEuropea cuyo objetivo es desarrollar unainfraestructura de comunicaciones para lainterconexión de los países de América Latinacon GÉANT, ha entrado en su Fase B, la deimplementación y operación que se extiendehasta mayo de 2006.

La selección de los operadores que soportaránla infraestructura de la red aún no es pública yestá en la última fase. La futura red estarásoportada por unos enlaces troncales contopología en anillo STM-1 (155 Mbps) quepasará a través de los Puntos de Presencia (PdPs)situados en Tijuana, Ciudad de Panamá,Santiago de Chile, Buenos Aires y Sao Paulo. Elresto de países se conectarán a ellos convelocidades inferiores.

La conectividad internacional con GÉANT vendrásoportada por un enlace STM-4 (622 Mbps.) entreSao Paulo y Madrid y se espera que conposterioridad esta red latinoamericana cuentecon conectividad con Abilene a través de Tijuana.

4

ACTUALIDADde RedIRIS

Actualidadde Red

Boletín de RedIRIS, nº 68-69, septiembre 2004

1.- COMUNITEL2.- INTELIDEAS3.- DATAGRAMA4.- SARENET5.- COLT6.- LAMBDANET7.- ONO8.- RETEVISIÓN9.- EASYNET10.- BT11.- TISCALI

12.- FLAGS13.- ARSYS14.- SERVICOM15.- NTT/VERIO16.- TELEGLOBE17.- TELEFÓNICA DATA18.- FUJITSU19.- JAZZTEL20.- YA.COM21.- INTEROUTE

1.- NEXICA2.- ADAM3.- ALTECOM4.- ACENS

Recientemente se ha realizado una llamada deinterés, entre las redes nacionales latino-americanas más avanzadas para hacerse cargode los grupos de: a) Ingeniería y planificaciónde la red y b) su operación respectivamenteganado por RNP (Brásil) y CUDI (Méjico).

EUMEDCONNECT también se trata de unproyecto cofinanciado por la CE y cuyo objetivoes desarrollar una infraestructura queinterconecte los países de la Ribera Sur delMediterráneo.

Se encuentra en una fase más avanzada queALICE y ya están entrando en operación algunosenlaces (p.e. Madrid). Dada la dificultad detener una infraestructura entre los países deesta zona la topología inicial se basará sobretodo en enlaces directos entre los Puntos dePresencia (PdPs) de estos países y algunos deGÈANT, por ejemplo habrá un enlace directocontra Madrid (PdP de GÉANT en España) yArgelia. De momento el único PdP de esta redestará ubicado en Catania (Italia) y ya se estámontando. El equipo que se va a utilizar es un7512 con tarjetas de STM-1 (155 Mbps) y T3 (45Mbps) que ha prestado GARR (NREN italiana) alproyecto.

• XIII TF-NGN en Madrid

Los pasados 22 y 23 de enero se celebró enMadrid la XIII reunión del grupo de trabajo TF-NGN (www.dante.net/tf-ngn) y las sesionestuvieron lugar en las instalaciones del Centro deProceso de Datos de la UCM. En este grupo setratan nuevas tecnologías de red con aplicacióninmediata en la red europea GÈANT.

El primer punto tratado fue el desarrollo de lasactividades para este año centrándose losesfuerzos en la implantación, de formadefinitiva, de una plataforma de monitorizaciónmulticast con acceso restringido por grupomonitorizable. El software utilizado es elbeacon server (ver noticia al respecto).

Respecto a IPv6 la línea de trabajo a seguir esprobar diferentes herramientas, desplegarlooking-glasses y definir una política deseguridad de filtros. También se trabajará endefinir e implementar multicast IPv6 en GÉANT.

En la actualidad se trabaja en la creación de ungrupo de monitorización del rendimiento de lared (PERT: Performance Response Team) paraGÉANT que será similar a un NOC.

Por último se continuarán realizando pruebasde equipos (equipamiento de Alcatel) y sepondrá en producción la posibilidad de realizarVPNs de nivel 2, a lo largo de toda la red.

Seguidamente se discutió (a propuesta de SimonLeinen, de SWITCH) la posibilidad de soportarMTUs de tamaño grande (suelen tener un valorde 1500 octetos, siempre en algún punto delcamino). Una MTU mayor proporciona mayorcapacidad de salida y menor consumo de CPU enlos hosts (según pruebas con Gigabit Ethernet)además de disminuir las interacciones con lamemoria virtual. Respecto a routing, paquetesde mayor tamaño implican menos paquetes queconmutar en el router y menos trabajo arealizar. La propuesta es empezar a utilizar unaMTU de 4470 bytes en los hosts conGigabitEthernet. Debe ser consistente y uninconveniente a tener en cuenta es que unaMTU tan grande puede producir sobrecargadebido al proceso de ‘MTU discovery’ en el casode caminos con MTU menor. Más informaciónsobre estas pruebas se puede encontrar enwww.abilene.iu.edu/jumboMTU.html

Respecto a la monitorización del rendimiento deuna red se está trabajando en estos momentosen la implementación de los primeros elementosde la infraestructura de monitorización,considerando la instalación de dos cajas demedidas de RIPE. Asimismo se tendrá una basede datos distribuida en la que se recogerán todotipo de medidas.

CESNET presentó su proyecto SCAMPI demonitorización de red donde se engloba laherramienta citada anteriormente. El proyectoconsiste en un adaptador Hardware, coninterfaces Gigabit Ethernet y 10 Gigabit Ethernety se realiza monitorización del rendimiento de lared mirando el ancho de banda disponible y lapérdida de paquetes, ‘jitter’ y ‘delay’. Todas lasmedidas se toman a velocidad de la línea.

Englobado en el área de monitorizacióntambién se presentó OpenIMP (www.ip-measurement.org/openimp); sistema distribuidode monitorización de Calidad de Servicio.

5


Actualidadde Red

Actualidad http://www.rediris.es/rediris/boletin/68-69/actualidad.pdf

EUMEDCONNECT

En IPv6 el siguiente paso es montar multicast enGÉANT. A Juniper se le han hecho diferentespeticiones para implementarlo en el JUNOS (susistema operativo) y poder ofrecer dichoservicio satisfactoriamente. Las pruebas yevolución del trabajo se pueden seguir en:www.uninett.no/geantmc6/.

Se hizo un repaso a la actualidad de losproyectos europeos de IPv6. En 6NET, ahoraestán trabajando en movilidad y herramientas demonitorización y concretamente en el M6NET setrabaja para montar multicast IPv6. En estesentido están experimentando con versiones derouters que permitan RP embebido y ‘scopedBSR’. Para usar multicast aunque un router nopermita PIM se puede utilizar el proxy MLD(existen implementaciones para Linux). Asímismo, se trabaja en ‘multicast fiable’, utilizandocódigos de error que se distribuyen para alcanzardicha fiabilidad en la red.

Respecto a las líneas de trabajo a seguir enGÉANT se van a centrar en herramientas demonitorización, en seguridad y en multicast, enla promoción del IPv6 y en el servicio de susoporte por parte de las redes nacionales deinvestigación, con técnicas de transición,servicios preparados para soportar IPv6, gestióny monitorización con dicho protocolo.

• Grupo de Trabajo ESPX-IPv6

A finales del año pasado se inauguraron losgrupos non-core de Espanix: correo, IPv6 yseguridad. En un primer momento RedIRIS sehace responsable de la coordinación de estosgrupos para pasar más tarde el relevo a otrosmiembros del Espanix, la información acerca delgrupo IPv6 está en: http://www.rediris.es/list/info/espx-Ipv6.es.html. Este grupo es lacontinuación natural del trabajo que se empezóa realizar con la interconexión IPv6 de susmiembros, aunque pretende ir más allá de lasimple interconexión. Trata de ser un grupo detrabajo dinámico en el que se involucren losdepartamentos de I+D de las diferentesempresas y sirva como punto de partida para eldespliegue total de IPv6 en la Internet española.

• Global IPv6 Service Launch Event

Los pasados 15 y 16 de enero se celebró enBruselas el ‘Global IPv6 Service Launch Event’(www.global-ipv6.net). El evento, patrocinadopor la Comisión Europea, tenía como principalobjetivo la promoción del IPv6 y dar unimportante empuje en sus países miembros paraacelerar su implantación. Durante el mismo

tuvo especial importancia el trabajo realizadopor las redes de investigación de los diferentespaíses y el realizado en GÉANT con soportenativo de IPv6. Partiendo de este trabajo desdela Comisión Europea se promulgó el comenzarcon el soporte de IPv6 en todo tipo de redes,teniendo en cuenta la importancia que va atener en el desarrollo de los futuros dispositivosmóviles (UMTS e incluso más allá).

Se contó con la asistencia de personalidadespolíticas de los diferentes países de la Unión,que comentaron las actividades llevadas a cabodentro de su país con dicho protocolo. En elcaso de España, Víctor Izquierdo (SubdirectorGral. de Empresas de la Sociedad de laInformación), destacó la labor realizada enRedIRIS y en el Grupo de trabajo español(http://www.spain.ipv6tf.org/html/index.php).

Se aprovechó la ocasión para lanzar iniciativasprivadas tales como el anuncio de Telefónica decomenzar a dar servicio IPv6.

• Multicast Beacon

Se acaba de poner en marcha una nuevaherramienta de monitorización en el área dered: Multicast Beacon (http://dast.nlanr.net/Projects/Beacon/ y http://www.rediris.es/red/stats/IPmcast/beacon). Se trata de una aplicacióncliente-servidor basada en perl que mide elfuncionamiento de la red multicast. Esta últimaversión es más ligera que la anterior (basada enjava) y el mismo software sirve tanto para elcliente como para el servidor. GÈANT utilizatambién esta aplicación para monitorizar eltráfico multicast.

Funciona de la siguiente forma: los clientesenvían tráfico basado en el protocolo RTP (RFC3550, Protocolo de Transporte en Tiempo Real)que lleva asociado un protocolo de control quepermite recoger información en tiempo realpara poder monitorizar el servicio (retardos,congestión, pérdidas ...). Este tráfico se envía aun grupo multicast definido y los clientes son a lavez emisores y receptores, con lo que en cadamomento cada uno de ellos obtiene datos acercade la calidad de recepción de lo que emite elresto. Esta información se envía a un servidor quepublica los datos.

• Looking Glass

Asimismo, el «looking glass» de RedIRIS(http://www.rediris.es/red/lg/) ha ganado enfuncionalidad. Actualmente, es posible realizaren cada router Juniper de la red comandos como

6


Actualidadde Red


traceroute, ping, listas de AS por ruta, lassesiones SDR activas y el estado del árbol PIM desesiones multicast existentes. Además, estasconsultas pueden efectuarse contra direccionestanto IPv4 como IPv6.

• Weather Map

RedIRIS ha desarrollado una herramienta parala monitorización de la red de característicassimilares a las ya existentes en otras redesacadémicas y denominada Weather Map.

Éste mapa, enlazable desde la página web dered: http://www.rediris.es/red, permite visualizarel estado de ocupación de los enlacesnacionales en ambos sentidos en tiempo real,queda aun pendiente la incorporación delestado de los enlaces externos.

Actualmente, aunque está operativo, se siguetrabajando en la mejora e incorporación denuevas utilidades que se consideran de interéspara los usuarios y esperamos que estén enproducción en breve plazo.

• Servicio de VPNs de nivel 2

Respecto a la puesta en producción de nuevosservicios, hay que destacar que recientemente ydebido a la realización de una demostracióncomo parte de un proyecto de colaboraciónentre la Universidad Politécnica de Cataluña yCanarie (red académica canadiense), se lesolicitó a RedIRIS la configuración de una VPN(Virtual Private Network) de nivel 2 entreBarcelona y Canarie.

Esta solicitud implicó la configuración de MPLS(Multiprotocol Label Switching Path) y ladefinición de un LSP (Label Switching Path)redundando a través de la red nacional desdeBarcelona hasta GEÁNT, permitiendo así, poneren producción el servicio de VPNs para elevento anteriormente citado y al mismo tiempopoder comprobar su comportamiento en unescenario real en producción. Actualmente el

servicio de VPNs se encuentra en fase depruebas para su puesta en producción.

• XLVII Reunión de RIPE

Durante la última semana de enero se celebróen Ámsterdam el cuadragésimo séptimoencuentro de RIPE (http://www.ripe.net/ripe/meetings/ripe47/presentations/index.html).Uno de los temas más interesantes presentadosallí fue la creación de CRISP (Cross-RegistryInternet Service Protocol) en el grupo detrabajo de base de datos. Se trata de unprotocolo que pretende sustituir a WHOIS,cuyos ficheros de datos son inmanejables apartir de un determinado tamaño. De estaforma se unificarían los formatos de las basesde datos de los diferentes RIRs y sería muchomás sencilla su consulta ya que actualmentecada registro regional almacena sus datos enun formato distinto. Este protocolo está basadoen XML y ya se ha presentado un draft en elIETF esperando que haya un piloto enfuncionamiento para el verano de 2004. Ahoramismo se está estudiando dónde ubicarlo.

En el grupo de trabajo de IPv6, se anunció queRIPE es el registro regional que más prefijos haasignado. En cuanto al grado de implantaciónen la red, cabe destacar que ya hay seis root-servers con dirección IPv6 asignada. Por último,se ha propuesto la elaboración de unasrecomendaciones para aplicación de filtros.

Se celebró la segunda reunión del grupo ENUM(todavía BoF), dirigido a coordinar laimplantación de este protocolo. Se presentaronvarias experiencias en Japón, Suecia, Polonia,Irlanda y Reino Unido.

En el grupo de routing, se presentaron variasherramientas de configuración remota derouters.

Finalmente, en el grupo de DNS se presentó elproyecto Reverse DNS (http://www.ripe.net/reverse/rdns-project/) que pretende definir unosprocedimientos más estables para la delegación

7


Actualidadde Red


Ottawa Barcelona

CRC

CA*net 4New York

GEÁNT

MPLS tunnel(set up manually)

RedIRIS

i2Cat

de zonas inversas que realiza RIPE. Hasta ahorase solicitaba la delegación y cambios sobre ellaa través del buzón [email protected], perotambién se permitían, modificaciones en elobjeto domain de la base de datos mediante elmétodo habitual, lo cuál creaba inconsistencias.Asimismo se está estudiando un nuevomecanismo de autorización específico para lasactuaciones sobre los objetos dominio.

Esther Robles([email protected])

Coordinadora del Área de RedMaribel Cosín

([email protected])Miguel Ángel Sotos

([email protected] Serrano

([email protected])Área de Red

Se está preparando el proyecto GN2 (el anteriorera GN1 y la red que se está utilizando GÈANT)que dará soporte a la nueva infraestructura dered europea y englobará una serie de servicios yactividades de investigación. Aunque está aúnbajo negociación podemos avanzar cuáles sonlas actividades de investigación que cubrirá(Joint Research Activity, JRA) y en las queRedIRIS participa:

• JRA1: Performance Measurement and Management

• JRA2: Security• JRA3: Bandwidth Reservation and Allocation• JRA4: Technology and Service Testing• JRA5: Ubiquity (Mobility) and Roaming

Access to Services

Esther Robles([email protected])

Coordinadora Área de Red

La X reunión del TF-CSIRT de TERENA(http://www.terena.nl/tech/task-forces/tf-csirt/),tuvo lugar en Ámsterdam el pasado mes deseptiembre y estuvo organizada por el Equipode Atención de Incidentes de Seguridad de laRed académica holandesa (Surfnet), CERT-NL.

Las presentaciones de la primera jornada secentraron fundamentalmente en dar a conocer

distintas iniciativas o desarrollos locales talescomo el sistema de análisis de tráfico basado enflujos para la detección de ataques (NERD:Network Emergency Response & Detection)desarrollado por una universidad holandesapara Surfnet. También tuvieron cabida variaspresentaciones de equipos de seguridadholandeses tales como la Agencia de PolicíaNacional holandesa, el CERT gubernamental(GOVCERT.NL) o el Equipo de Seguridad de laUniversidad Groningen. Todas las presenta-ciones están disponibles en la dirección:http:/ /www.terena.nl/tech/task-forces/tf-csirt/meeting10/programme.html

El resumen de la reunión del Task Force de lasegunda jornada, está disponible enhttp:/ /www.terena.nl/tech/task-forces/tf-csirt/meeting10/TSec_03_120.pdf. Como vienesiendo habitual, durante dicha reunión se hizoun repaso de los proyectos europeos en los queel Grupo está o ha colaborado (eCSIRt.net, EISPPy TRANSITS), así como a las diferentes iniciativasen materia de seguridad en las que el Grupo haestado participando durante los más de tresaños de vida del mismo con el fin de impulsar lacolaboración entre los CSIRTs europeos y laadquisición de estándares y normas para facilitarel intercambio de información entre ellos.

La XI reunión del TF-CSIRT se celebró en Madriden enero de 2004 y estuvo organizada por IRIS-CERT con la colaboración de la UniversidadComplutense de Madrid que desinteresa-damente nos permitió utilizar sus instalacionesen el Centro de Proceso de Datos. Desde aquí,nuestro más sincero agradecimiento.

Tanto las presentaciones de los seminarios delprimer día como el resumen de la reunión delTask Force propiamente dicha se puedenconsultar en: http://www.terena.nl/tech/task-forces/tf-csirt/previous-meetings.html.

Algo que echamos mucho en falta durante elprimer día de la reunión de Madrid fue laescasa participación de instituciones y equiposde seguridad españoles. Esta corrió a cargo deRicardo Marín, de Red.es y Matías Bevilacqua dela empresa CYBEX.

El segundo día se presentó la iniciativa del Grupode Trabajo del EGC (European GovermentCSIRTs). Este Grupo que se reúne cada cuatromeses y está compuesto por CSIRTs de ámbitogubernamental de seis países europeos, tienecomo finalidad tratar problemas e incidentesrelacionados con el ámbito de actuación queafectan a este tipo de equipos, así como el

8


X y XI TF-CSIRTde TERENA


X y XI TF-CSIRT de TERENA

GN2

GN2

Actualidad deRed

desarrollo de una serie de actividades paralelascomo la implantación de sistemas de alerta, lacooperación de este Grupo con la futura Agenciade Seguridad Europea (ENISA), etc..

Tanto en Ámsterdam como en Madrid secelebró, de forma adyacente a la reunión del TF-CSIRT, una reunión de los equipos acreditadosen el servicio de Trusted Introducer de TERENA(http://www.ti.terena.nl/). El acuerdo másimportante al que se llegó en estas reunionesfue la propuesta de redacción de un códigoético que deberán suscribir todos aquellosequipos que quieran llegar a obtener el gradode equipo acreditado en dicho servicio.

En Madrid, además, se celebraron el día anterior,y de forma paralela, dos reuniones: El AbuseFórum y un Workshop sobre la utilización de laherramienta Request Tracker/RT for IncidentResponse, desarrollada por Best Practical(http://www.bestpractical.com/), por la que estánapostando un gran número de Equipos deSeguridad como herramienta de gestión deincidentes. Como resultado de la reunión, se hacreado un Grupo de Trabajo entre los CERTsinteresados en esta herramienta con la intenciónde discutir e implementar posibles mejoras ymódulos adicionales a incluir en próximasversiones de la misma; por ejemplo un móduloPGP integrado en la propia herramienta o unoque permita el intercambio de incidentessiguiendo el estándar IODEF (Incident ObjectDescription and Exchange Format). Tras estaprimera reunión celebrada en Madrid la segundase celebró en Londres el pasado 10 de febrero.Os seguiremos informando en siguientesnúmeros de los progresos y conclusionesalcanzados por el Grupo.

Chelo Malagón([email protected])

Equipo de Seguridad, IRIS-CERT

En las páginas web del Equipo de Seguridad deRedIRIS se encuentra el informe de losincidentes de seguridad del año 2003(http://www.rediris.es/cert/doc/informes/2003/).

Se trata de un informe corto y fácil de leer en elque se presentan las estadísticas de losincidentes atendidos durante el 2003 por IRIS-CERT (http://www.rediris.es/cert) y que permite

tener una visión general de cuáles han sido losproblemas más importantes de seguridad quese han sufrido en la Red Académica y deInvestigación española, así como algunosenlaces de interés a los problemas máscomunes.

Chelo Malagón([email protected])

Equipo de Seguridad IRIS-CERT

El pasado 14 de enero se celebró en Madrid laprimera reunión del grupo de trabajo sobre elRTIR (Request Tracker for Incident Response,http://www.bestpractical.com/rtir), bajo elmarco del grupo de trabajo de TERENA TF-CSIRT (Coordination and Support of ComputerSecurity Incident Response Teams). El RTIR esun módulo de la herramienta RT (RequestTracker, http://www.bestpractical.com/rt) parala gestión y administración de incidentes deseguridad, desarrollada por Best Practical(http://www.bestpractical.com), dicho módulofue creado a petición del grupo de seguridadde la red académica del Reino Unido (JANET-CERT), para adaptar RT a su “workflow” deatención de incidentes. A lo largo del pasadoaño, IRIS-CERT tomó la decisión de migrar aesta herramienta de atención de incidentes yabandonar su actual sistema con el fin demejorar el servicio que se viene ofreciendo.

A la reunión asistieron algunos de los CSIRTseuropeos que están utilizando la herramienta(JANET-CERT, CERT-Polska, CERT.PT,...) o estánen vías de migrar a ella pronto (IRIS-CERT,SURFNet, CARNet, ACONet-IRT, ...), junto conresponsables de BestPractical. Los objetivosiniciales eran definir los requerimientos paranuevas funcionalidades a añadir en RTIR, laprioridad en la implementación; la búsqueda deun marco adecuado para la creación de unconsorcio, que bajo el paraguas -por ejemplo-de TERENA, tuviese como objetivo encontrar lafinanciación necesaria para afrontar dichodesarrollo y por último compartir los desarrollosque algunos CSIRTs habían estado realizando,de forma que se pudiese llegar a un gradoimportante de coordinación entre todos y evitarasí repetir implementaciones.

Todo esto trajo consigo una serie de discusionessobre las funcionalidades a añadir y se decidió

9

I reunión del Grupo deTrabajo sobre RTIR


Resumen deincidentes de

seguridad 2003

I reunión delGrupo de

Trabajo sobreRTIR


Resumen de incidentes deseguridad 2003

X y XI TF-CSIRTde TERENA

finalmente la implementación de un móduloPGP, para verificar la integridad y laautenticación de los mensajes que lleguen a lacuenta asociada al RTIR; integración de IODEF(Incident Object Description and ExchangeFormat) y módulo de contactos que permitabúsquedas sobre BBDD de contactos depersonas.

Carlos Fuentes([email protected])

En enero de 2001 arrancó el proyecto eCSIRT.Net(http://www.ecsirt.net) nacido en el seno delgrupo de trabajo de TERENA TF-CSIRT(Coordination and Support of Computer SecurityIncident Response Teams: http://www.terena.nl/tech/task-forces/tf-csirt/). Se creó con el objeto decumplir los siguientes objetivos:

• Definir un formato claro y estandarizadopara el intercambio de incidentes entre losequipos involucrados.

• Permitir la elaboración de estadísticas clarasy estandarizadas sobre incidentes y crear unacceso público a las mismas.

• Permitir la recopilación de información sobreincidentes, para posteriormente, generaruna serie de alertas que puedan ayudar a losequipos involucrados.

A lo largo de los dos últimos años se hanprobado una serie de técnicas y se han definidouna serie de formas de actuación para llegar a laconsecución de los objetivos del proyecto. Deesta forma se logró consensuar entre todos losequipos del proyecto un código de conducta(http://www.ecsirt.net/service/documents/code_of_conduct/coc.html) donde se establecían lasformas de cooperar y compartir información ycrear así una mayor confianza entre los equipos.Además se ha estado apoyando laestandarización y el uso del IODEF (IncidentObject Description and Exchange Format:http://www.iodef.org/), para ello se definió unlenguaje común en el que se describíaninequívocamente todos los campos del objetoasí como su utilización eliminando por tantocualquier ambigüedad que pudiera existir alutilizarlo. Además cada uno de los equiposadaptaron sus sistemas de gestión de incidentespara la recepción y envió de estos usando IODEF,probando de esta manera la tecnología que sehabía desarrollado para el objeto por parte delgrupo de trabajo INCH del IETF.

El proyecto generó tres diferentes tipos deestadísticas que reflejaban la carga de trabajo yrecursos gastados en la gestión de incidentes(Tipo 1), los incidentes gestionados por losequipos clasificados en base a la taxonomía dealto nivel definida en el proyecto (Tipo 2), y lasestadísticas sobre ataques realizados en la redde sensores IDS desplegada por el proyecto(Tipo 3). Cabe resaltar que la recopilación de lainformación de los IDSs se realiza automá-ticamente utilizando como protocolo deintercambio de información de los logs IDMEF(Intrusion Detection Message ExchangeFormat).

Por último, se definió la Alert Function(http://www.ecsirt.net/service/documents/wp5-alert-policy-v11.html) de forma que los equiposdispusiesen de un mecanismo eficaz para enviary recibir alertas sobre posibles nuevos incidentesdetectados por alguno de los equiposintegrantes. Para esto se definieron una serie demecanismos para enviar y recibir dichas alertas,teniendo en cuenta que los integrantes de losequipos pudiesen estar en horario de oficina (In-Bound) o fuera de él (Out-Bound) y utilizandoIODEF como formato para transmitir las alertas.

El proyecto acabó el 31 de diciembre y susresultados fueron evaluados por losinterventores de la Comisión Europea como muysatisfactorios. Se espera que todo el trabajollevado a cabo sirva como punto de partida parafuturos desarrollos en este campo.

En la actualidad y tras la conclusión delproyecto se están estudiando diferentes víaspara continuar con los resultados obtenidosdebido a la amplia aceptación que han tenidodentro del grupo de trabajo TF-CSIRT y de losbeneficios que se podrían obtener a partir deellos. El principal problema en estos momentospara poder seguir manteniendo lainfraestructura creada es el monetario. Una delas soluciones más factibles sería la integraciónde los resultados del proyecto como nuevosservicios del Trusted Introducer (http://ti.terena.nl)de TERENA, de forma que todos los integrantesdel mismo, la mayoría de los CERTs europeos seviesen beneficiados.

Durante el último semestre del pasado año secelebraron dos reuniones de coordinación delproyecto. En ellas se llevó a cabo el seguimientodel estado del mismo y el cumplimiento de lastareas que habían sido encomendadas a cadauno de los CSIRTs involucrados.

La primera se celebró el 18 de octubre enLondres. En ella cada uno de los CSIRTs presentó

10


ProyectoeCSIRT.Net


Proyecto eCSIRT.Net

I reunión delGrupo de

Trabajo sobreRTIR

el estado en el que se encontraba laimplantación de IODEF dentro de sus sistemasde gestión de incidentes, informando sobre lalibrería utilizada para dicha integración.Posteriormente se estableció un calendario parala realización de una serie de pruebas deintercambio de IODEF entre los CSIRTs de formaque se pudiese probar que todos los equipospodían intercambiar incidentes de seguridaddentro de sus BBDD de incidentes. Se informóque el sistema de alerta estaba prácticamenteoperativo a falta de poner en marcha la partede envío de alertas a través de mensajes SMS yse discutió sobre cómo se debían confirmar losdiferentes tipos de alertas y cuáles debían serlos tiempos de respuesta para cada una de ellas.

La última parte de la reunión se centró en lasestadísticas (http://www.ecsirt.net/service/documents/wp4-pub-userguide-v10.html) detipo 1 (Información sobre operación de losCSIRT) y 2 (Información sobre incidentes)–generadas manualmente rellenando una seriede formularios web–, ya que algunos equiposmostraron su desacuerdo con los actualesformularios al considerar no recogían losuficientemente bien la información requerida,además que no se ajustaba a la información quela mayoría de los CSIRTs almacenaban en susBBDD. Toda esta discusión nos llevó a lamodificación de la taxonomía de alto nivel(http://www.ecsirt.net/service/ documents/wp4-clearinghouse-policy-v12.html#HEAD6), deforma que se ajustase de mejor manera a lasutilizadas por cada unos de los integrantes delproyecto para clasificar sus incidentes.

La segunda reunión fue el 10 de diciembre enMadrid, en la oficinas de RedIRIS. El principalobjetivo fue evaluar el resultado de las primeraspruebas de intercambio realizadas con el IODEFunas semanas antes de la reunión así como verlos problemas que se habían planteado durantesu realización. Se acordaron una serie dedirectivas para subsanar los erroresencontrados, y para la implantación de la firmaGPG de los objetos IODEF en las posteriorespruebas que iban a ser realizadas la semanasiguiente a la reunión.

También por parte de Pre-Secure se mostrócómo quedarían los interfaces para cada uno delos diferentes tipos de estadísticas quedando asíesta parte prácticamente concluida a falta deque algunos equipos introdujesen sus datos delos últimos meses del año.

La última parte de la reunión se dedicó a lafunción de Alerta, última fase del proyecto. Pre-

Secure informó que todos los sistemas estabantotalmente operativos a falta sólo de realizarlos tests definitivos que confirmasen dichoestado. Para ello se estableció un calendario depruebas, tanto para la generación de alertas deseguridad a través del sistema, como para larecepción de las mismas en la modalidad In-Bound (en horas de oficina) y Out-Bound (fuerade horario laboral). Para estas pruebas elpersonal de Pre-Secure se comprometió arealizar una mini-guía how-to para larealización de las mismas.

Carlos Fuentes([email protected])

Con algo de retraso respecto a las fechasprevistas –inicialmente a finales del año 2003–se desarrolló un reto de análisis forenseorganizado por RedIRIS (http://www.rediris.es/cert/ped/reto). El reto consistía en analizar lainformación contenida en un equipopreviamente atacado para intentar obtenertoda la información posible sobre las accionesrealizadas por el atacante.

Este equipo formaba parte de una red demáquinas trampas (http://www.rediris.es/cert/ped) en una red dentro de RedIRIS, con unaconfiguración de sistema operativo y serviciossimilar a la de otros sistemas instalados eninstituciones afiliadas, y aunque externamenteparecía un equipo normal en realidad seencontraba monitorizado y controlado paradetectar cuándo se producía el ataque.

Como precedente de este reto se produjo en elaño 2001 el Honeynet Forensic Challenge(http://www.honeynet.org/challenge/index.html),presentado por el grupo del proyectoHoneyNet, aunque esta es la primera iniciativade este tipo que se realiza en castellano. El retose realizó con dos objetivos:

a) Fomentar el empleo de técnicas de análisisforense para analizar los ataques que seproducen en los equipos conectados aRedIRIS, de forma que los responsables de loscentros estén familiarizados con las técnicasde análisis forense y tengan informaciónsobre cómo actuar en estas situaciones.

b)Recopilar casos prácticos en castellano sobrecómo proceder a realizar un análisis forense,de forma que pudiera servir de guía práctica

11


ProyectoeCSIRT.Net

Resultados delreto de análisis

forense

Resultados del reto deanálisis forense


a todas aquellas personas interesadas en elanálisis forense.

El reto solicitaba el envío de tres documentos acada participante:

1.- Un fichero con la información de contactode los participantes ya que el resto dedocumentos enviados deberían seranónimos.

2.- Un resumen de tres a cinco páginas notécnico (informe ejecutivo) donde secomentasen los motivos de la intrusión, elanálisis realizado y recomendaciones(lecciones aprendidas) sobre este incidente:

3.- Un informe técnico de la intrusión con ladescripción en profundidad del análisisrealizado; la longitud máxima de esteinforme no debería exceder las 60 páginas.

El jurado encargado de evaluar este resultadoestuvo integrado por las siguientes personas:

• Rubén Aquino (UNAM-CERT,Universidad Nacional de México)

• David Barroso (S21Sec)• Javier Fernández-Sanguino (Germinus)• Jess García (LAEFF-INTA/ SANS Institute)• Jordi Linares (Cybex)• Borja Marcos (Sarenet)• Francisco Monserrat (IRIS-CERT, RedIRIS)• Jacomo Piccolini (CAIS/RNP, red brasileña)

Hay que destacar en primer lugar la calidad delos informes presentados por los participantes.Aunque al final ha habido algunos con unapuntuación más elevada que otros todos lostrabajos demuestran un profundo conocimientode las técnicas a aplicar a la hora de analizar unequipo atacado de estas características.

Es interesante resaltar las diversas aproxima-ciones realizadas para llevar a cabo el análisis deun equipo, así por ejemplo para localizar losbinarios instalados unos participantesemplearon los tiempos de modificación de losficheros, (para averiguar qué ficheros habíansido modificados tras la instalación) y otrosrealizaron comparaciones de los ficheros con lashuellas digitales (MD5) de sistemas con la mismadistribución de Linux o emplearon las utilidadesdel sistema (base de datos rpm) para este fin.

Para todos los interesados en las técnicas deanálisis forense la lectura de los documentospresentados aportará seguramente informaciónvaliosa a la hora de realizar un análisis.

Francisco Monserrat([email protected])Equipo de seguridad IRIS-CERT

Hace unos meses en colaboración con el CESGA yla UC3M iniciamos emisiones en pruebas envarios formatos, MPEG-1, MPEG-2, MPEG-4 ydivX, con distintos bitrates utilizando tecnologíamulticast. El objetivo es hacer un banco deensayo para probar nuevas posibilidades de lared. Como resultado hemos creado un canal enemisión continua que puede ser usada para quelos receptores puedan comprobar susconfiguraciones así como de demostracióntecnológica de las capacidades de la nueva red.

Tanto para la emisión como para las pruebas derecepción hemos utilizado las herramientas OpenSource (http://www.videolan.org) del proyectofrancés Videolan .

En la actualidad se emite en bucle un vídeo enMPEG-2 a 8.6 Mbps procedente de un DVDsobre la red europea Geànt producido porDante. Este vídeo ha sido doblado al castellanoy al gallego por el CESGA.

Para recibir esta emisión es necesario soportemulticast y el cliente vlc que se puede bajar dela página de videolan para varias plataformas.Activar SAP al lanzar el cliente (opción—extraintf sap) y en la lista de reproducción alcabo de unos instantes aparecerá una entradallamada RedIRIS-TV (http://www.rediris.es/mmedia/RedIRIS-TV.es.html).

En la lista de reproducción podremos ver otrasemisiones como el canal UC3M-TV con emisionescontinuas de vídeos grabados o en directo:cursos de humanidades del proyecto de docenciacompartida ADAMADRID, actos institucionales,... todo ello con calidad MPEG-2 a 3 Mbits.

Desde otras instituciones se ha mostrado interésen volcar sus canales de TV a la red y en brevepodremos verlos anunciados en la lista dereproducción de la herramienta vlc.

José Mª Fontanillo([email protected])

Servicios Multimedia

Global Dialing Scheme (GDS) es el plan denumeración utilizado para vídeo y audio sobreIP en la redes académicas y de I+D y en VideNet,una de las mayores redes de videoconferencia.Fue desarrollado por la organización europea

12


Resultados delreto de análisis

forense

Emisiones enalta calidad

Emisiones en alta calidad


Global Dialing Scheme

Global DialingScheme

TERENA y se asemeja al plan de numeracióninternacional usado en el sistema telefónico conalgunas diferencias. Si un terminal H.323 estáregistrado en un Gatekeeper conectado a lajerarquía GDS podrá alcanzar a cualquierterminal, MCU o gateway que use GDS encualquier punto del mundo.

Un número E.164 en GDS consta de lassiguientes partes:

1.- El Código de Acceso Internacional (CAI),también conocido como prefijo delgatekeeper mundial. Se define como 00.

2.- Un Código de País (CP). Éste se obtiene delsistema de códigos internacional definidopor la ITU (International TelecommunicationUnión). El prefijo para España es 34. Sepuede encontrar la lista completa en:http://www.itu.int/itudoc/itu-t/ob-lists/icc/e164_717.pdf

3.- Prefijo de la Organización (PO). GDS no dicecómo son asignados estos prefijos y existenvarias alternativas, más adelante veremoscuál ha sido el plan que hemos adoptado.

4.- Número de Terminal (NT) Puede pertenecera un terminal de videoconferencia, una MCUo un gateway. Éste se decide dentro de laorganización y no está fijado ni por GDS nipor el plan nacional, aunque se pueden darrecomendaciones como por ejemplo lalongitud del número.

El número completo queda así:<CAI><CP><PO><NT>

Por ejemplo: 00(CAI) 34 (CP) 1000 (PO) 001 (NT)GDS delega en cada país la utilización de supropio sistema de numeración, siempre que sigaalgunas reglas, de la misma forma que RedIRISdelega en cada institución la adopción del suyopropio siguiendo también algunas normas(http://www.rediris.es/mmedia/GDS/).

Los Prefijos de organización son asignadossecuencialmente por orden de llegada a lasinstituciones afiliadas a RedIRIS.

GDS se implementa como una jerarquía degatekeepers de una forma parecida al DNS:

• Hay un gatekeeper mundial; en realidad hayvarios por redundancia pero se comportancomo si sólo hubiera uno. En este gatekeeperno hay ningún elemento registrado (ni MCUs,ni terminales, ni gateways), funciona comodirectorio de gatekeepers reenviandomensajes de localización (LRQ, LCF y LRJ).Conoce sólo acerca de los gatekeepersnacionales.

• Un gatekeeper por cada país que suele seroperado por la red nacional de I+D. EnRedIRIS se ha puesto en funcionamiento elgatekeeper nacional para España. Estosfuncionan de forma análoga al mundial; enellos tampoco hay terminales registrados,reencaminan mensajes de localización y sabenacerca de los gatekeepers de instituciones.

• Gateepers de instituciones. En ellos losterminales están registrados y puedenimplementar la política local. Puedenfuncionar en varios modos: señalizacióndirecta entre terminales, con encaminamientodel tráfico H.225/H.245, y en modo proxy(todo el tráfico multimedia pasa por elgatekeeper). Estas distintas alternativasdependen de la política que quiera adoptar lainstitución, del grado de control y del tamañodel servicio, puesto que existen considera-ciones de escalabilidad según la solución.

La implementación que hemos realizado constade un router CISCO 2600 con MCM (que formaparte del IOS) como gatekeeper nacional ycomo gatekeeper de RedIRIS-institución ungnugk (www.gnugk.org)

GDS permite y hace fácil la utilización deservicios de videoconferencia o voz sobre IP(VoIP) constituyendo una infraestructura básicasobre la que se podrán desarrollar nuevosservicios avanzados.



Desde que en 1996 se inició un servicio demulticast –entonces piloto– hasta el momentoque se considera ya en producción, se ha vistoque la tecnología multicast es la más adecuadapara solventar los problemas de escalabilidad.No obstante, por varios factores, entre ellosconsideraciones de seguridad y en ocasiones

13


Global DialingScheme

Piloto RDV

Piloto RDV


desconocimiento de la tecnología, ocurre queeste soporte para IP multicast no alcanza alusuario final.

En el servicio de streaming existen momentospuntuales en que, debido a la emisión deeventos importantes en directo, la capacidad delos servidores y líneas de las organizaciones sonpuestas a prueba, mientras que en otros centrosexisten servidores ociosos, desde los cuales seríaviable enviar el stream a las IPs más cercanas.

Para la entrega de contenido de vídeo en directohace falta algún mecanismo que seamínimamente escalable, una propuesta quesurgió dentro del grupo IRIS-MMEDIA esdesarrollar un software en principio simple, perocon posibilidades de crecimiento, queimplementara ALM (Application Level Multicast).Los objetivos son:

• Desde el punto de vista de red: evitarcongestión en los enlaces más cercanos a losservidores (por ej. accesos de las instituciones)en eventos en directo que sean seguidosdesde el exterior.

• Desde el punto de vista de sistemas: balancearla distribución de vídeo entre distintosservidores, permitiendo la compartición derecursos ociosos entre instituciones.

• Extraer conocimiento que pueda ser usadopara implementar un servicio en producción.

Existen varios mecanismos para implementareste comportamiento:

• Redirecciones DNS• Información basada en distintas métricas

(saltos, retraso, etc.).• Mensajes de redirección: por ejemplo

mensajes 302 de RTSP, estos mensajes noson soportados por todos los protocolos destreaming.

• Decisión basada en tabla estática.

Teniendo en cuenta las características denuestra red y la facilidad de implementación seha optado por el último mecanismo. Sabemoscuales son las subredes que conecta cadainstitución y estas cambian relativamente poco,con lo cual podemos generar un archivo que escompartido por todos los reflectores de la red.

El software ha sido desarrollado en la UC3M yen un principio se han utilizado servidoresWindows Media, por ser lo más sencillo, noobstante sería simple adaptar a otros servidoresde streaming.

Esta iniciativa está abierta a nuevos miembrosdentro de la comunidad. (http://www.rediris.es/mmedia/rdv/)



El segundo seminario sobre tecnologías deautenticación y autorización (AA), auspiciadopor el grupo TF-AACE de TERENA, se celebró enla Universidad de Málaga los pasados días 20 y21 de noviembre. Reunió a unas 40 personas,provenientes de Europa y Estados Unidos.

El primer día, las presentaciones y discusiones seconcentraron en los escenarios de aplicación deestas tecnologías desde distintos puntos devista: proveedores de contenidos, bibliotecas,grids, usuarios móviles, integración de servicios,videoconferencia y servicios multimedia.También se presentaron nuevas propuestas detecnologías, en las áreas de modelos deautorización y de protocolos criptográficos.

El segundo día se dedicó a revisar el estadoactual de las infraestructuras de AA en Europa yel resto del mundo, analizando las opcionespara garantizar su interoperabilidad. Elconcepto de federación y su relación con lasinfraestructuras de clave pública fue consideradala clave para esta interoperabilidad. También sepresentaron las iniciativas de proyectoseuropeos (GN2 y GRANDE) que, de una manerau otra, planean incorporar el uso de tecnologíasde AA en el nivel de red.

Se puede encontrar más información al respectoen: http://www.terena.nl/tech/task-forces/tf-aace/AAworkshop/

Diego López([email protected])

Coordinador del Área de Aplicaciones

Con posterioridad al II seminario sobretecnologías de AA (ya reseñado) se celebrótambién en Málaga una reunión del grupo TF-AACE (Task Force on Authentication and

14


Piloto RDV

II Seminariosobre

tecnologías deautenticación y

autorización


II Seminario de tecnologías deautenticación y autorización

Reunión delgrupo TF-AACE

Reunión del grupo TF-AACE

Authorisation Coordination for Europe,http://www.terena.nl/tech/task-forces/tf-aace/).El trabajo del grupo se centró en los siguientespuntos:

• Aprobar la política del repositorio de CAsacadémicas de TERENA (TACAR, http://www.terena.nl/tech/task-forces/tf-aace/tacar/), unainiciativa que pretende facilitar elestablecimiento de relaciones de confianzaentre las diferentes PKIs académicas a nivelglobal. La política del TACAR se estáaplicando ya, y cinco PKIs académica(española, holandesa, checa, griega y la delos grids del Dpto. de Energía de los EEUU)forman parte del mismo. La iniciativa hadespertado un gran interés entre los gruposque utilizan PKIs en el entorno académico ycientífico y el TACAR es mencionado comouno de los pilares para construir políticascomunes de acceso a los recursos de e-cienciaen el borrador del libro blanco del eIRG (e-Infrastructre Reflection Group), un grupoencargado de definir las direcciones deldesarrollo de la e-ciencia y sus posiblesaplicaciones en la Unión Europea.

• Discutir el desarrollo del AA-RR (AARequester-Responder), un sistema para lavalidación de los requisitos de inter-operabilidad entre diferentes infraestructurasde AA que pretende ser el resultado final delgrupo, cuyo mandato finaliza en mayo deeste año. Una de las aplicaciones directas delAA-RR será la gestión de federaciones en elproyecto GN2 (http://www.terena.nl/tech/task-forces/tf-mobility/meetings/30-01-04/slides/JR-TF-Mob.pdf).

• Analizar las posibilidades de continuidad deltrabajo del grupo. Se acordó recomendar aTERENA la organización de un grupodedicado en general a la coordinación de lasactividades de middleware de sus miembros,de manera similar al MACE de Internet2(http://middleware.internet2.edu/MACE/).



A lo largo del pasado invierno, el desarrollo delsistema de autenticación y autorización PAPI haexperimentado un significativo impulso. Sedispone de un nuevo portal que ofrece acceso adatos y documentación relativa al mismo, asícomo a las distribuciones de software

(http://papi.rediris.es/). Además, y de maneramuy significativa, el portal está orientado afacilitar el intercambio de información entre lacreciente comunidad de usuarios del sistema.

El portal se estrenó con el anuncio de lareciente versión 1.3.0 de PAPI que incluye, entresus nuevas características más significativas lassiguientes:

• El soporte a la interacción directa entre unpunto de acceso y un servidor deautenticación, permitiendo nuevos modos(más flexibles) de aplicación del sistema.

• La posibilidad de usar un motor deautorización externo SPOCP (http://www.umu.se/it/projupp/spocp/), lo que proporcionauna mucho mayor riqueza a la hora deexpresar reglas de control de acceso.

• Una importante mejora de las interaccionesde PAPI con LDAP.

• Un conjunto más rico de operacionesdisponibles en modo proxy.

Precisamente, el módulo proxy de PAPI ya hasido empleado por la red académica suiza(SWITCH) para integrar en su infraestructura deautenticación y autorización el acceso a recursoscon otros controles de acceso. Esta integraciónpermitirá avanzar más rápido en lainteroperabilidad de ambas infraestructuras y,en general, en la construcción de una AAIglobal.



Anunciamos la creación de un nuevo grupo detrabajo sobre mensajería instantánea ypresencia en la Red, que llevará por nombreIRIS-XMPP (http://www.rediris.es/im).

XMPP son las siglas en inglés para eXtensibleMessaging and Presence Protocol, es decir,protocolo extensible para mensajería y presenciaen la Red. XMPP es conocido familiarmentecomo Jabber (http://www.jabber.org).

En el IETF existe un grupo (http://www.ietf.org/html.charters/xmpp-charter.html) trabajando enla edición de nuevos estándares para definir lascaracterísticas que habrán de tener este tipo deservicios. Fruto de este trabajo, se han aprobado

15


Actualidad sobrePAPI

Creación delGrupo de

Trabajo IRIS-XMPP


Actualidad sobre PAPI

Creación del Grupo deTrabajo IRIS-XMPP

Reunión delgrupo TF-AACE

recientemente –aunque aún se encuentranpendientes de recibir numeración–, lassiguientes RFCs:

• Extensible Messaging and Presence Protocol(XMPP): Core (ftp://ftp.rediris.es/mirror/internet-drafts/draft-ietf-xmpp-core-22.txt)

• Extensible Messaging and Presence Protocol(XMPP): Instant Messaging and Presence( f t p : / / f t p . r e d i r i s . e s / m i r r o r / i n t e r n e t -drafts/draft-ietf-xmpp-im-21.txt)

No obstante, existen varios textos más(http://www.jabber.org/ietf/) pendientes deaprobación.

Los objetivos que nos marcamos al crear estegrupo de trabajo son los siguientes:

• Intercambiar ideas y experienciasrelacionadas con la implantación yexplotación de sistemas de mensajeríainstantánea y presencia en la Red entre losmiembros de la red académica.

• Estudiar la interoperabilidad entre losdistintos servicios de mensajería instantáneadentro de la red académica, incidiendo encuestiones como la identidad, autenticación yautorización de usuarios inter-organización.

• Estudiar la posibilidad de crear unafederación de servicios de MI dentro de la redacadémica y/o a nivel nacional. Extensión delos servicios de MI para soportar tecnologíasde indentidad digital como PAPI.

• Integración de Jabber con servicios existentes(directorios LDAP, multimedia, aulas virtuales,entornos colaborativos,...)

• Experimentación con nuevos servicios comolos basados en localización location-aware ycontexto context-aware.

Aquellas instituciones afiliadas que deseenformar parte del Grupo de Trabajo deberíancomenzar por registrarse en la lista de correosque lleva el mismo nombre, enviando unmensaje a [email protected], especifi-cando en el cuerpo del mensaje:

subscribe IRIS-XMPP <Nombre y apellidos>

y devolvernos relleno el breve cuestionarioque recibirá. En la página del grupo(http://www.rediris.es/im) se puede encontrarmás información al respecto.

José Manuel Macias([email protected])

Servicios de Información

Dentro de los grupos de trabajo englobados enlas últimas Jornadas Técnicas de RedIRIS (2003)organizadas en Palma de Mallorca, se presentóel arranque de una iniciativa, cuyo nombre esMovIRIS, que coordinará la puesta en marcha deinfraestructuras orientas a dispositivos móvilesdentro de la comunidad RedIRIS. Su principalmotivación es proveer servicios a usuarios quese encuentran localizados en organizaciones olocalizaciones distintas a las de su organizaciónorigen, es decir, usuarios móviles que pordiversas circunstancias se encuentran fuera desu organización habitual y necesitan diferentesservicios telemáticos. Dentro de estos serviciosse puede pensar en conexión a Internet, accesoa servicios locales como impresión, etc.

Para conseguir este objetivo es necesaria unacoordinación entre las diversas organizacionesenglobadas en el proyecto a nivel decompatibilidad tecnológica en el equipamiento,sistemas de autenticación, autorización,registro, etc. de tal manera que se pueda darestos servicios móviles con la mayortransparencia para el usuario, minimizando elesfuerzo de gestión en las organizacionesvisitadas y maximizando el ámbito demovilidad. El objetivo último consistiría en quecualquier usuario móvil pudiera conseguir, deuna manera sencilla y segura, conexión encualquier otra organización dentro del ámbitonacional y europeo, así como acceso a una seriede servicios que le permitieran trabajar como sise encontrara en su organización origen.

Los objetivos del proyecto MovIRIS son:• Coordinar la puesta en marcha de

infraestructuras de movilidad en nuestracomunidad, sirviendo de punto de encuentrode problemas y soluciones.

• Homologar las soluciones tecnológicas aimplantar en las diferentes organizacionescon las acordadas a nivel europeo einternacional en este sentido.

• Informar de todos los temas relativos a lamovilidad: guías de apoyo, estándares,soluciones (tanto propietarias como de libredistribución), etc.

• Promocionar nuevas soluciones e iniciativasoriginadas en organizaciones de nuestracomunidad tanto dentro de nuestra red,como a nivel internacional.

A nivel de coordinación en el ámbito europeo,existe dentro de TERENA, el grupo de trabajoTF-Mobility (http://www.terena.nl/tech/task-

16


Creación delGrupo de

Trabajo IRIS-XMPP

Iniciativa demovilidad en la

red de I+D+I


Iniciativa de movilidad en lared de I+D+I

forces/tf-mobility/) que sirve de punto de apoyoa las diversas redes de investigación europeaspara llevar a cabo la idea de un único espaciode movilidad en toda Europa. Dentro de losdocumentos elaborados desde este grupo seencuentran algunos que explican solucionesactualmente en funcionamiento en diversasredes de investigación, otros orientados acoordinar las diferentes soluciones haciéndolascompatibles entre sí, recomendaciones,terminología, etc. Así mismo, este grupo haempezado a coordinarse con el grupo TF-AACE(orientado a soluciones de autenticación yautorización), para elaborar soluciones “SingleSign-on” que integren tanto el acceso deusuarios móviles a la red, como el acceso acualquier recurso de Internet. Como apuestafirme a las iniciativas tanto de movilidad comode sistemas de autenticación y autorización enEuropa, RedIRIS es uno de los principalesparticipantes en la actividad JRA5 dentro de lapropuesta para la próxima generación de la redacadémica europea, GN2 (http://www.terena.nl/tech/task-forces/tf-ngn/presentations/tf-ngn13/20040122_JR_GN2_JRA5.pdf).

Rodrigo Castro([email protected])

Técnico de Middleware

RedIRIS ha participado en la redacción de laúltima versión del “eIRG White Paper”,contribuyendo con la experiencia acumulada enel desarrollo de infraestructuras deautenticación y autorización como PAPI, y en eldespliegue de IRISGrid. En concreto, nuestracontribución se ha centrado en cuestiones dearquitectura, analizando el empleo de modelosde federación y la conexión entre las diferentesinfraestructuras que tanto los proyectos de gridcomo las redes académicas nacionales hanvenido implantando en los últimos años para lagestión de identidades y derechos de losusuarios.

El documento fue presentado y aprobado en laúltima reunión del grupo, bajo los auspicios dela presidencia de turno de la UE, en Dublín, elpasado 16 de abril (http://www.heanet.ie/einfrastructures/).



El repositorio de Autoridades de Certificaciónacadémicas de TERENA (TACAR: “TERENA CAAcademic Repository” http://www.terena.nl/tech/task-forces/tf-aace/tacar/) se encuentra yadisponible. Se trata de una iniciativa paraproporcionar una raíz común de confianza parala interconexión de Infraestructuras de ClavePública académicas (PKIs) en Europa (e inclusomás allá de nuestras fronteras).

La idea tras el TACAR es poner a disposición deusuarios y, principalmente administradores deredes y sistemas, una relación fiable decertificados y sus correspondientes políticas decertificación, de manera que sea posibleestablecer vínculos de confianza entre unadeterminada PKI y otra(s). La gestión de losvínculos de confianza está depositada en losoficiales de TERENA, que se encargan deverificar la información publicada a través delrepositorio por medio de encuentros personalescon los representantes de las organizacionesparticipantes y por medio de mensajes decorreo electrónico firmado (usando mediosexternos a los certificados gestionados por elrepositorio).

El TACAR cuenta, en el momento de escribiresta noticia, con dieciséis certificados raíz, tantode redes académicas nacionales (incluyendo aRedIRIS) como de proyectos transnacionales degrid. El repositorio ha sido oficialmenteapoyado por el eIRG como una infraestructurabásica para la e-ciencia en Europa, y es parteintegral de los procedimientos de la EUGridPMA(la entidad que agrupa y valida las PKIsaplicadas en los grids europeoshttp://www.eugridpma.org/). Existen en laactualidad propuestas para experimentar laaplicación de TACAR en diversos mecanismos degestión y uso de PKIs, en colaboración con lainiciativa “Evolvable PKI” de Internet2.



Ya se encuentra disponible la versión definitivadel XPS (X.509 Parsing Server), un front-endpara el acceso LDAP a certificados digitalesX.509, desarrollado por la Universidad deSalford con el soporte de TERENA y de variasredes académicas europeas: CESNET (República

17


Iniciativa demovilidad en la

red de I+D+I


eIRG White Paper

TACAR

XPS

eIRG WhitePaper

XPS

Checa), SURFnet (Holanda), SWITCH (Suiza),UNINETT (Noruega) y RedIRIS. El sistemapermite acceder a los certificados asociados auna determinada entrada en un directorioLDAP, obviando las limitaciones que el modelode acceso a través de atributos imponía a ladistribución de certificados por medio de LDAP.Está basado en las reglas definidas por el grupoPKIX del IETF y ya ha sido integrado en laversión 2.2 de OpenLDAP (http://www.terena.nl/tech/projects/AddingCertificateToOpenLDAP/).El equipo de middleware de RedIRIS estáevaluando el software y preparando posiblesaplicaciones del mismo, tanto en el entornonacional como en iniciativas de colaboracióninternacional.



A comienzo del mes de junio se celebró laTERENA Networking Conference 2004 en la islade Rodas (Grecia), junto con las habitualesreuniones de los grupos de trabajo que secelebran al mismo tiempo que la conferencia.Los aspectos más relevantes en lo que conciernea las infraestructuras de middleware fueron:

1) En la reunión de TF-AACE se presentaronlas conclusiones previas al informe final(que se redactará a lo largo del mes dejunio) y los últimos resultados, en concretoel desarrollo del AA-RR a cargo de RedIRIS(http://www.terena.nl/tech/task-forces/tf-aace/Meet06-06-04/presentations/AARR-DL-TFAACE-Rhodes.pdf), para el que hemosrecogido ofertas de colaboración de FUNET(Finlandia) y SURFnet (Holanda). Sepresentó también el estado final delTACAR, que incluye 16 organizaciones(http://www.terena.nl/tech/task-forces/tf-aace/tacar/). El interés despertado es alto yse han planeado nuevas iniciativas parahacer evolucionar los servicios delrepositorio, incluyendo su conexión con elproyecto XPS (http://www.terena.nl/tech/task-forces/tf-aace/).

2) Se presentó también la nueva propuestadel grupo EMCC (European MiddlewareCoordination Council), cuyos términosconcretos serán remitidos al Comité Técnicode TERENA en septiembre. La propuestaincluye que Diego López actúe comoChairman del nuevo grupo.

3) En el grupo TF-Mobility se presentaron losresultados finales del trabajo del mismo,incluyendo la jerarquía de servidoresRADIUS y los requisitos de interopera-bilidad (http://www.terena.nl/tech/task-forces/tf-mobility/). Se anunció laintegración de RedIRIS (a través de lainiciativa MovIRIS) en la jerarquía europeay se acordó proponer la prolongación delos trabajos del grupo por otros dos años.

4) En la conferencia propiamente dichaparticipamos directamente en:

a) La coordinación de la misma, dentro delComité de Programa.

b) La presentación de la ponencia titulada“Distributed MetainformationSearching”, elaborada por DavidFernández Barrero, de la Universidad deAlcalá de Henares, bajo la dirección deDiego López dentro de la iniciativaPTYOC.

5) Se establecieron contactos muy interesan-tes para la colaboración en las áreas de:

a) Diagnóstico de las capacidades de losservicios: NREN Detective de SURFnet.

b) Análisis de flujos de red y su aplicaciónen temas de seguridad.

c) Sistemas de recogida de datos deintrusiones basadas en “redes oscuras”.

d) La conexión de sistemas de AA (comoPAPI) con los sistemas de accesointegrado a la información (JISC-IE).

e) Taxonomías de sistemas de AA

6) Por último, tomamos parte activa(copresidiéndola) en la “MiddlewareAssembly” (http://www.terena.nl/conferences/tnc2004/meetings/#middleware), en la quese discutieron los aspectos comunes que lasdiferentes NREN encuentran en eldespliegue de infraestructuras demiddleware, y se tomaron algunosacuerdos con el objetivo de lanzariniciativas de coordinación en el área de lasautoridades de nombres, sistemas deautorización, esquemas de diagnóstico yaplicación de estas infraestructuras enservicios ya establecidos.

Se puede encontrar más información sobre lasponencias mencionadas en:

http://www.terena.nl/conferences/tnc2004/programme/presentations/



18


TNC2004 enRodas


TNC2004 en Rodas

XPS

Nunca deja de sorprendernos el impacto de losnuevos virus en la Red. Si con los del pasadoverano (Sobig.F, Mimail o Blaster) pensábamosque se había tocado fondo, la propagación delvirus MyDomm (enero-febrero 2003) hasuperado cualquier previsión y –lo que es peor–ha creado una gran desconfianza sobre laseguridad existente en la Red. Está claro queuno de los mayores problemas sigue siendo elusuario final que activa la propagación de losvirus abriendo los ficheros adjuntos, sobre todoen ese periodo crítico del comienzo de laepidemia, cuando los antivirus todavía no lodetectan. Increiblemente los usuarios siguenconfiando en esos mensajes desconocidos queabren por simple curiosidad y que, ya no sóloafectan negativamente a su propio PC, sinocada vez en mayor medida al resto de la Reddejando abiertos puertos traseros que sonutilizados para la distribución de spam o deataques a otros servidores. Es por lo tanto unrequisito muy importante para mejorar laseguridad aumentar el nivel de conocimientode los usuarios ofreciéndoles información fiablesobre estos temas.

RESACA (Red de Sensores Antivirus de laComunidad Académica) desde hace dos añosviene aportando una serie de datos con unafrecuencia diaria, semanal y mensual quepermiten estimar la incidencia, tendencia ypropagación de los virus en la Comunidad RedIRIS(http://listserv.rediris.es/resaca.html). Esos datosnos muestran que la propagación del MyDommha sido, aproximadamente, unas 10 vecessuperior a cualquiera de las mayores epidemiasvíricas del 2003. Si los niveles de dispersión de losvirus ya es un hecho preocupante no podemosolvidar los efectos ocasionados en la Red y en losservidores de correo con el aumento de lasconexiones SMTP, el tratamiento y análisis deltráfico de correo, etc.. A esto debemos añadir lospuertos abiertos que dejan las últimasgeneraciones de virus y que quedan a disposiciónde los spammers para la distribución masiva decorreo basura. Por último no podemos olvidar laenorme confusión y desconfianza que provocaentre los usuarios la falsificación de correosgenerados por los propios virus.

En un Servicio de Listas de distribución porcorreo electrónico los niveles de proteccióncontra los virus y el spam debe ser máximo puesserían extraordinarios canales de propagación.Este servicio, LISTSERV, que nació antes que lapropia Internet y que se diseñó para un entorno

científico de confianza y donde era sencillo irañadiendo mejoras y nuevas funcionalidades, seha ido acoplando de forma exitosa a unentorno cada vez más agresivo, aunque porotra parte el incremento de los niveles deseguridad en el Servicio ha ido reduciendoalgunas de sus funcionalidades.

El spam está golpeando duramente la únicapuerta abierta del Servicio de Listas de RedIRIS:la dirección genérica de contacto deladministrador de cada lista (-request@, owner-@...)que es una redirección a su buzón personal. Esadirección fue creada para gestionar una lista:recibir solicitudes de alta, de moderación,consultas, etc. pero igual que se recibe esainformación necesaria se recibe spam y suvolumen ya es muy superior. RedIRIS ha idoimplementando cambios en la forma de atenderestas direcciones y medidas parciales parareducir este problema, confiando en las medidasAntiSpam que se están implementando en lasinstituciones y en los propios usuarios paraclasificar este correo basura.

Por otro lado los virus distribuyen mensajesinfectados que de cara a un usuario sonidénticos a los que suele distribuir el Servidor deRedIRIS en una determinada lista. Los usuariosreciben avisos de mensajes infectados quenunca enviaron igual que el servidor de listas ysus múltiples direcciones asociadas. Estos lasresponden de nuevo a direcciones que puedenllegar a ser la propia lista o direcciones deusuarios que nunca enviaron nada. Losservidores de listas se diseñaron para responderpor correo-e a la dirección del emisor de todo loque les vaya llegando. Se han implementadofiltros de contenidos para evitar la distribuciónde mensajes procedentes de informes generadospor antivirus y que se envían a las propias listas.Los virus envían mensajes a direcciones públicasdel Servidor para intentar dar de alta o baja ladirección falsificada que lleva incorporada en elcampo From. En definitiva un pequeño caos queprovoca un aumento de tráfico y un trabajoadicional a los servidores y las personas que losadministran. Pero lo más preocupante es laenorme desconfianza que se está generandoentre los usuarios.

En definitiva, los virus y el spam estánreafirmando los problemas del diseño delprotocolo que regula el intercambio de correo(SMTP) que tanto afecta a un Servicio de listasde distribución. El problema más destacable esel uso ilegítimo que muchos spammers y virusestán haciendo de nuestras direcciones decorreo originando avalanchas de mensajes de

19


Incidencias devirus y spam enel Servicio de

Listas


Incidencia de virus y spam enel Servicio de Listas

error y advertencias sobre virus enviados apersonas inocentes. No podemos olvidar la faltade seguridad que implica que cualquier personapuede hacer uso de nuestras direcciones decorreo. El IETF está evaluando soluciones paraevitar el uso no autorizado del correoelectrónico para que cada dominio especifiquelos servidores (Estafetas) que están autorizadosa usarlo. Actualmente el sistema mejorposicionado es SPF (Sender Permited From) delque ya informaremos más adelante.

Jesús Sanz de las Heras([email protected])

Coordinador del Servicio de Listas

La iniciativa RACE (Red Académica de CorreoElectrónico, http://www.rediris.es/mail/race)arrancó en junio de 2003 con tres objetivosligados a la Coordinación del Servicio de CorreoElectrónico en la Comunidad RedIRIS. Estosobjetivos fueron: obtener calidad en el servicio,realizar auditorias interinstitucionales ydesplegar una infraestructura privada decorreo. La calidad del Servicio ha sido definida através de 22 indicadores que forman un nuevomodelo de diseño del Servicio para lasInstituciones, están agrupados en tres niveles:Básico, Medio y Avanzado. Estos indicadores seajustan a cualquier institución independiente-mente de su tamaño (tráfico, usuarios, etc.) ynos permitirá disponer de informacióncuantitativa del estado del servicio en laComunidad a través del Catálogo RACE.

RACE propone las líneas maestras para obtenerun servicio moderno, seguro y fiable. Sepretende que de una forma consensuada seestructure la evolución del Servicio, se evalúennuevas tecnologías, y se genere y compartadocumentación y desarrollos. Los criterios RACEson variados y atienden a valores como:

• Seguridad: control del tráfico SMTP, anti-relay, cifrado, antivirus,...

• Accesibilidad: webmail, autenticacióncentralizada, redundancia,...

• Usuario: Documento Correo Electrónico(DOCE), gestión de incidentes, servicios devalor añadido...

• Otros: conservación de logs, sincronizaciónNTP, criterios meritorios,...

• Experimentales: IPv6, etc.

El Nivel Básico de RACE es el inicial y másimportante, todos sus indicadores son

imprescindibles y de obligado cumplimiento. ElNivel Medio aporta criterios de valor añadidosiendo dos de ellos imprescindibles. El objetivodel nivel Avanzado es cifrar y autenticar todaslas transacciones entre el emisor y el receptor.Es evidente que estos niveles son consecutivos ypor poner un ejemplo no sería razonabledesplegar una PKI para el correo electrónico sinofrecer a los usuarios un servicio de acceso a sucorreo vía web (WebMail).

El segundo objetivo RACE es evaluar el estadodel servicio de correo electrónico en unaInstitución en función de los indicadores RACE.La evaluación la lleva a cabo de formavoluntaria el grupo de personas que gestiona elservicio de correo en sus instituciones. Estegrupo se renueva periódicamente y desde laúltima referencia hecha en el Boletín (Boletínde RedIRIS nº 65, septiembre 2003, pg. 11) se haincrementado la lista en 3 nuevas personas, deforma que actualmente está constituido por 11postmasters de otras tantas universidades. Lasincorporaciones más recientes han sido:

V. Giralt Universidad de MálagaJ. Benjumea Instituto de Microelectrónica

de Sevilla (CSIC)I. Bernal Universidad de Navarra

La evaluación facilita un enriquecedorintercambio de experiencias interinstitucionalesentre evaluadores y evaluados. Se genera uninforme técnico con el resultado final y unasrecomendaciones. RedIRIS, por su parte, envía alos responsables un certificado postal del nivelalcanzado y una serie de logotipos RACE paracolocarlos en su web institucional. Con estainformación se va creando un catálogo delestado del correo electrónico en la ComunidadRedIRIS (http://www.rediris.es/mail/race/cata.html).

En el periodo oct.-dic. 2003 se han producido lassiguientes novedades en el Catálogo:

• Univ. Polit. de Cartagena que se incorporó alNivel Básico en septiembre de 2003.

• Universidad de Navarra que se incorporó alNivel Avanzado en noviembre de 2003

• La Univ. Carlos III de Madrid que en juniode 2003 fue evaluada como Nivel Medio yen febrero de 2004 alcanzó el NivelAvanzado, claro ejemplo de la posibilidadde ir evolucionando de nivel.

El objetivo más ambicioso a largo plazo deRACE es la posibilidad de desplegar unainfraestructura privada y de calidad para elintercambio seguro y fiable de correoelectrónico entre las instituciones de RedIRIScon nivel avanzado RACE. Los objetivos serían:

20


Incidencias devirus y spam enel Servicio de

Listas

Actualidad deRACE


Actualidad de RACE

a) Establecer una Autoridad de Certificación(CA) entre las Estafetas que permita laposibilidad de cifrar el tránsito de correoentre usuarios de diferentes instituciones.

b) Permitir la movilidad de usuarios.c) Frenar la difusión de virus y spam interinsti-

tucional. Ofrecer la máxima fiabilidad,tolerancia a fallos y redundancia.

e) Facilitar el uso e información al usuario.

Por último destacar las palabras de Pedro R.Benito, responsable del Servicio de correoelectrónico de la Univ. de Burgos en la últimareunión del Grupo de coordinación IRIS-MAIL/19mantenido en Mallorca:

“La iniciativa RACE nos ha ayudado amontar un sistema de correo electrónicoque no solamente cubre todas nuestrasnecesidades, sino que también abre elcamino para nuevas posibilidades. Elesfuerzo merece la pena, ya que a partir deahora todo lo que se aumente o mejoreseguirá unos estándares, y se integrará conel resto de servicios gracias a nuestraexperiencia anterior. Se han reducidodrásticamente las incidencias en el servicio,y el nivel de satisfacción de los usuariosparece bueno, ya que incluso algunos hanmigrado sus cuentas de las estafetas dedepartamentos a las estafetas generales dela Universidad a petición propia, sobretodo por razones de movilidad”


Servicio de Correo Electrónico

A mediados del pasado año se formalizaron losobjetivos y organización del grupo de interés deEspanix sobre correo electrónico (ESPX-MAIL).Actualmente el grupo está formado por 45personas de 30 empresas proveedoras deservicio de correo electrónico (Wanadoo, Arsys,Sarenet, Telefónica, Ya.com, etc.). También hanmostrado interés por la iniciativa entidadescomo la Agencia de Protección de Datos, elInstituto Nacional de Consumo o la Secretaríade Estado de Telecomunicaciones y Sociedad dela Información. El grupo está moderado porJesús Sanz de las Heras de RedIRIS el objetivoprincipal es la creación de un clima de confianzaentre los técnicos de los diferentes proveedoresque permita abordar los diversos problemas queafectan al correo electrónico en la Red.

La primera reunión del grupo tuvo lugar elpasado 25 de febrero en las instalaciones deEspanix. Asistieron 15 personas pertenecientes a12 instituciones. Todos los representantes tienenun marcado perfil técnico, con menor o mayorpoder de actuación en el ámbito de su empresa,a excepción de la Agencia de Protección deDatos cuya función en el grupo es sancionar eluso indebido de cualquier comunicaciónelectrónica de carácter comercial.

Una de las primeras conclusiones obtenidas esque el spam es mucho mayor en clientesresidenciales que en corporativos dada lanaturaleza del uso de Internet. Mientras que enel caso de los primeros se puede estimar en un50% el spam respecto al total de correo, en losclientes corporativos se puede hablar cerca del20%. Esto se debe a que la gente no suele usarla cuenta de correo de empresa parasubscripciones, promociones, reenvío de correosen cadena y demás servicios susceptibles de serpunto de origen de spam. En las Universidadesespañolas el tráfico de spam se encuentra en unsegmento intermedio cercano al 40%.

La reunión estuvo dividida en dos secciones;autorregulación y temas técnicos. Respecto alprimer tema se consideró imprescindible acotar ydisponer de una definición clara de lo queconsideramos spam, denuncia, abusos, etc. Sedescartaron esfuerzos en el tema de lacoordinación de incidentes de spam debido a lafalta de una definición clara de lo que es un“incidente de spam” y a los problemasrelacionados con la protección de datos, etc.También se alcanzó consenso en definir unarelación de buenas prácticas para usuarios finalesy responsables del servicio de correo electrónico,incluidos los usuarios residenciales con ADSL ensu casas, que actúan como servidores de correocon todos los puertos SMTP habilitados.

Red.es comunicó que en colaboración conRedIRIS está preparando el lanzamiento de unobservatorio del correo electrónico donde sepodrá centralizar información sobre el temadesde varias perspectivas: ESPs, usuarios,legislación, postmasters, etc.

Como resultado se decidió elaborar tresdocumentos de buenas prácticas:

• BCP1: para delimitar y consensuar el significadode los términos que estamos tratando en estegrupo: spam, queja, denuncia, abuse, etc.

• BCP2: Documento de buenas prácticasorientado a gestores de Servicios de Correoelectrónico (postmasters).

21


Actualidad deRACE

I Reunión deproveedores de

correoelectrónico


I Reunión de proveedores decorreo electrónico

• BCP3: Documento orientado a usuarios deServicios de Correo electrónico

En los aspectos técnicos se abordó el tema deSPF (Sender Permited From) como unaalternativa para paliar el problema actual delspam, no va a acabar con ello pero cualquierherramienta para reducirlo es bienvenida y suimplantación no es en principio traumática yaque se puede comenzar a publicar registrosSPF que no filtren. El problema radica en que sino se generaliza el uso de SPF, su ámbito deacción se reduciría a relaciones de confianzaentre aquellos que lo usen. De las alternativasque se barajan SPF se muestra como la máscercana a adquirir status de RFC. Algunosasistentes se mostraron bastante reticentes aimplementarlo sin antes haber hecho pruebasy se acordó informar sobre SPF a la comunidadespañola.


Responsable de correo electrónico

Esta última convocatoria de IRIS-MAIL celebradael 18 de junio contó con la asistencia de unas 50personas y se dividió en cuatro áreas de interés(http://www.rediris.es/mail/gt/jn04/):

• Aspectos generales: SAUCE, MailBackup yLibro Blanco anti-spam

• Proyecto SAnet: Modelo de sensores para lageneración de estadísticas y gestión dedenuncias (http://sanet.unizar.es)

• Proyecto Appliance de UNIZAR• Presentación del Servicio de Correo

Electrónico de la Universidad de Navarra

En los aspectos generales de IRIS-MAIL seanalizaron los problemas que afectan a losServicios de Mailbackup (http://www.rediris.es/mail/mailbackup) y SAUCE (http://www.rediris.es/sauce). MailBackup es un servicio operativodesde 1997 que está viéndose muy afectado porlos graves problemas de incremento de tráfico yataques que está sufriendo el correo electrónicoen Internet. RedIRIS propuso una serie demedidas correctoras para mitigar estosproblemas y que se evolucionara hacia unnuevo modelo. Respecto a SAUCE, es un serviciode acceso al correo vía Web creado en el año2000 para ofrecer movilidad en el Servicio deCorreo a todos los usuarios de la Comunidad

RedIRIS y fomentar así progresivamente eldespliegue de servicios WebMail en susinstituciones. Desde hace un tiempo el servicioestá sufriendo una considerable carga en lossistemas de RedIRIS por parte de usuariosprocedentes de instituciones que disponen desu propio servicio WebMail. Por este motivo sehace un llamamiento a las instituciones paraque difundan entre sus usuarios sus servicios deWebMail y no necesiten utilizar el de RedIRIS.La evolución propuesta es ofrecer un modelo deSAUCE bajo demanda institucional para usoexclusivo de los usuarios de dichas instituciones.

También se hizo referencia a las actividadesexternas llevadas a cabo por los coordinadoresdel grupo IRIS-MAIL: la colaboración en el IIEuropean Forum Abuse; la coordinación delGrupo ESPX-MAIL de Espanix y la administracióndel Foro Nacional de Postmasters (MAIL-ES). Amediados de abril se llevó a cabo una sesión devideoconferencia con trece universidades de laRed académica chilena (REUNA) en la que seexpusieron las principales líneas de trabajo deIRIS-MAIL; se definieron los canales decoordinación entre ambas instituciones y seresumieron las tendencias internacionales de lasmúltiples soluciones que se están proponiendopara resolver el problema del spam.

Se expuso el estado actual de desarrollo de lasactividades englobadas en el “Libro Blancoanti-spam en RedIRIS” extraído de lasconclusiones de la anterior reunión mantenidaen Mallorca. A partir de los objetivosestratégicos de este documento se ha avanzadoen la comparativa de listas negras que tiene undocumento en revisión. La línea más avanzadacorresponde a la del desarrollo de un sistemade extracción de estadísticas y generación dedenuncias de spam que se ha formalizado en elProyecto SAnet (Red de Sensores AntiSpam)gestionado por el Servicio de Informática yComunicaciones de la Universidad de Zaragoza.Se hizo un llamamiento urgente para que lasinstituciones se dieran de alta como sensoresSAnet ya que el Proyecto y sus datos son muydependendientes del número de mensajesprocesados. Actualmente hay 10 sensores de 6instituciones (UNIZAR, UVIGO, UPV, UAM,UPCO y RedIRIS).

Pascual Pérez de UNIZAR expuso lascoordenadas de la política de correo en suUniversidad y los desarrollos que hanimplementado y puesto a disposición de CRIBA:desarrollo basado en librerías Milter desendmail que permite entre otras cosasgestionar flujos de tráfico SMTP e integrarlos

22



correoelectrónico

XX reunión deIRIS-MAIL

XX reunión de IRIS-MAIL


con productos anti-spam y anti-virus. Uno de losobjetivos proyectados es independizarlo desendmail para poder integrarlo en otro tipo deservidores de correo. También comentó lascoordenadas de un proyecto llamado Hermes(Mail Firewall Appliance): soluciónempaquetada y completa para Estafetas decorreo que facilita la implantación de unmodelo de calidad RACE, independiente ycompatible con cualquier software de servidorde buzones (MDA) y con mayor alcance que unasimple solución anti-spam.

Esta solución es la idónea para organizacionespequeñas o medianas ya que no requierepersonal experto en correo electrónico. Suinstalación permitiría de forma automáticaconvertirse en sensor antivirus de RESACA ysensor antispam de SAnet.

La sesión se cerró con la presentación que hizoIgnacio Bernal del Servicio de correo electrónicode la Universidad de Navarra. Esta universidadtiene certificado RACE de Nivel Avanzado ycomo tal expuso el diseño de sus líneasestratégicas: escalabilidad, alta disponibilidad,movilidad, monitorización y seguridad einteroperabilidad con otros clientes/servidores.

Entre otros aspectos interesantes hay quedestacar los escasos recursos empleados en supolítica anti-spam basada en listas negras,servicios de denuncias e implantación comocliente de correo electrónico de Mozilla. Estopermite desviar recursos a reforzar un potenteservicio de atención al usuario: manuales,cursos, helpdesk telefónico, etc..

La política anti-spam descansa en laimplantación de Mozilla que permite a cadausuario, de forma sencilla, utilizar su motor defiltros adaptativos anti-spam con un simplebotón (junk). Además, este cliente permitefuncionalidades interesantes tales como:Soporte POPs/IMAPs, SMTP+TLS+SMTPAUTH,LDAP, múltiples cuentas, etc.

Se puede encontrar más información sobre lascomunicaciones presentadas en la Zona deTrabajo IRIS_MAIL:

(http://cvu.rediris.es/bscw/bscw.cgi/0/525143).


Coordinador de correo electrónico

Después de una primera conferencia celebradaen Atenas en junio de 2003 bajo la Presidenciagriega, el 9 de diciembre se celebró otra enRoma con el objetivo principal de intercambiarideas sobre el concepto de eInfrastructure ycómo llevar a cabo su implementación enEuropa (http://www.einfrastructures.org).

Se trata de un entorno donde los actores másimportantes son los proyectos GRID, las redes deinvestigación y todo tipo de usos científicos, queempleando las redes de alta velocidad,elementos de almacenamiento y el middlewareadecuado puedan permitir cambiar de unaforma dramática los usos de las redes y suexplotación en el campo científico y porextrapolación a usos en otros entornosindustriales o domésticos.

En Roma se realizaron diversas presentacionessobre la actividades en eInfrastructure y proyectosGRID de iniciativas nacionales propuestas al VIPrograma Marco y la visión de la ComisiónEuropea al respecto. Todo ello con inclusiones dela cooperación internacional más allá de Europa:Japón, USA o Latinoamérica.

Lo que se constata en Roma es que existenproyectos en marcha, otros en preparación y ungran interés de cooperación de todos losimplicados, pero que hace un grupo quecoordine a nivel europeo estas actividades y quesea designado a nivel gubernamental por cadauno de los estados miembros (incluyendo los 10nuevos miembros). El grupo recibe el nombreoficial de eIRG (eInfrastructure ReflectionGroup) y se marca en una fase inicial lossiguientes objetivos:

• Identificación de los elementos, servicios yrecursos necesarios para permitir una e-Science pan-europea

• Recomendación de líneas para el estable-cimiento de políticas de compartición derecursos:

- Iniciativas de GRID nacionales

- Proyectos regionales y europeos deeInfrastructure

• Contribución al establecimiento de un forointernacional de política en esta línea

• Ofrecimiento de elementos de entrada a otrosforos de toma de decisión: ESFRI, NREN PC,....

23



correoelectrónico

eInfraestructurasConferencia de

Roma


eInfraestructurasConferencia de Roma

• Establecimiento de una primera actuaciónhacia investigadores mediante eScience, perotambién colaborar en su extensión a otrosentornos: eLearning, eGovernment, eHealth,eCulture, eBusiness, etc.)

• Identificación, información y promoción delconocimiento GRID entre aquellascomunidades que se puedan beneficiar de lacompartición de recursos.

• Control de aspectos administrativos en eldespliegue de GRIDS.

• Utilización de la experiencia de lacomunidad de las redes de investigación(estructura, operativa, Políticas de usoaceptable,…)

El eIRG estará formado por representantes delos estados miembros oficiales de la CE yapoyado por un grupo de técnicos queaportarán sus recursos desde los proyectos másemblemáticos: EGEE, DEISA y tal vez GN2.

En definitiva, se presenta una gran actividad eneste entorno con la existencia de foros en losque RedIRIS, el MCYT y otros agentes debenestar presentes de cara al desarrollo de todauna base estructural y de conocimiento, quepermita construir un sistema estable y operativoy que es deseable que esté disponible lo antesposible para que nuestros usuarios científicospuedan utilizarlo.

Más información en: https://cagraidsvr06.cs.tcd.ie/grid-event-2004/einfra/

Víctor Castelo([email protected])

24


eInfraestructurasConferencia de

Roma


Actualidad de RedIRIS...5 tienen direccionamiento IPv6 asignado (del bloque asignado por RIPE a...

Documents

Transcript of Actualidad de RedIRIS...5 tienen direccionamiento IPv6 asignado (del bloque asignado por RIPE a...