Вы находитесь на странице: 1из 237

COMO ESCOGER E IMPLEMENTAR UNA VPN CONCEPTOS TERICOS Y PRACTICOS

Autor FERNANDO ANDRES ARVALO JIMNEZ

UNIVERSIDAD DEL VALLE FACULTAD DE INGENIERIA ESCUELA DE INGENIERIA ELECTRICA Y ELECTRNICA INGENIERIA ELECTRNICA SANTIAGO DE CALI 2003

COMO ESCOGER E IMPLEMENTAR UNA VPN CONCEPTOS TERICOS Y PRACTICOS

Autor FERNANDO ANDRES ARVALO JIMNEZ

Trabajo de grado para optar al ttulo de Ingeniero Electrnico

Director ING. FABIO GUERRERO MSc. Profesor Asistente

UNIVERSIDAD DEL VALLE FACULTAD DE INGENIERIA ESCUELA DE INGENIERIA ELECTRICA Y ELECTRNICA INGENIERIA ELECTRNICA SANTIAGO DE CALI 2003 ii

Nota de aceptacin _______________________________________ _______________________________________ _______________________________________

___________________________________ Director Prof. Ing. Fabio Guerrero MSc.

____________________________________ Jurado Prof. Ing. Oscar Polanco

_____________________________________ Jurado Ing. Fabio Ramrez

iii

AGRADECIMIENTOS
A Dios por permitirme ser, a mis padres por su amor, comprensin y por inculcarme la importancia de estudiar, a mi familia por toda su ayuda y comprensin, a mi novia por su apoyo y ayuda, a la Universidad del Valle y a todos los profesores de la EIEE por la formacin acadmica recibida, a Telesat S.A. por facilitarme el tiempo, espacio y recursos para terminar este trabajo.

iv

RESUMEN

Las Redes Privadas Virtuales (VPNs) son una alternativa practica, segura y eficiente de los enlaces privados que en la actualidad son usados para interconectar redes corporativas y brindar acceso a trabajadores teleconmutados. Este trabajo de grado tiene como objetivo primario dar a conocer esta tecnologa y brindar las pautas necesarias, apoyandose en conceptos tcnicos y prcticos, para una adecuada implementacin de la misma sin alejarse del medio colombiano del sector de las telecomunicaciones. Los siguientes captulos componen el presente trabajo: Capitulo 1 - Los enlaces privados antes de la aparicin de las Redes Privadas Virtuales: Presenta un breve enfoque de las tecnologas WAN tradicionalmente implementadas, tanto dedicadas como conmutadas, entre las que se encuentran Clear Channel, Frame Relay, ATM, lneas anlogas y lneas digitales RDSI. Capitulo 2 Redes Privadas Virtuales VPNs: Presenta una descripcin de la tecnologa, asi como sus diferentes escenarios y sus componentes bsicos. Capitulo 3 Arquitecturas VPN: Amplia cada una de las diferentes soluciones que se pueden implementar con las VPNs, tales como Acceso Remoto, LANto-LAN y Extranets.

Capitulo 4 Autenticacin y Cifrado: Presenta los conceptos de seguridad sobre los cuales se basan todas las tecnologas existentes que sirven para implementar una VPN. Capitulo 5 Tecnologas VPN: Es la esencia del trabajo. Comprende las tecnologas existentes mas usadas para crear tneles y enlaces encriptados sobre redes pblicas. Comprende temas como PPTP, L2TP, IPSec y MPLS. Capitulo 6 Montajes prcticos: Presenta la implementacin tres tecnologas diferentes VPN: Microsoft PPTP (acceso remoto VPN), Cisco IPSec (LAN-toLAN VPN) y Linux/FreesWAN (LAN-to-LAN VPN). Capitulo 7 Conclusiones: Presenta una serie de conclusiones resultantes del tratamiento terico del capitulo 5, los montajes prcticos del Capitulo 6 y conocimientos del mercado colombiano de la tecnologa de la informacin. Capitulo 8 Recomendaciones: Se sugieren ciertos trabajos y proyectos que podran resultar del inters que despierte la tecnologa de las VPNs entre la comunidad acadmica.

vi

TABLA DE CONTENIDO 1. LOS ENLACES PRIVADOS ANTES DE LA APARICION DE LAS REDES PRIVADAS VIRTUALES 1
1.1. INTRODUCCIN 1.2. ENLACES PRIVADOS 1.3. TIPOS DE ENLACES PRIVADOS 1.3.1. ENLACES DEDICADOS 1.3.1.1. Clear Channel 1.3.1.2. Frame Relay 1.3.1.2.1. Estandarizacin 1.3.1.2.2. Dispositivos Frame Relay 1.3.1.2.3. Conexiones virtuales Frame Relay 1.3.1.2.4. Identificadores de conexin de enlace de datos (DLCI) 1.3.1.3. ATM (Asynchronus Transfer Mode) 1.3.1.3.1. Estandarizacin 1.3.1.3.2. Funcionamiento de las redes ATM 1.3.1.3.3. Formato de una celda ATM 1.3.1.3.4. Dispositivos ATM 1.3.1.3.5. Formato de una cabecera ATM 1.3.1.3.6. Conexiones Virtuales ATM 1.3.1.3.7. Conmutacin ATM 1.3.2. ENLACES CONMUTADOS 1.3.2.1. Enlaces conmutados anlogos 1.3.2.2. Enlaces conmutados digitales RDSI

1 1 2 2 3 5 6 7 8 10 10 11 11 12 12 13 15 15 16 16 19

2. REDES PRIVADAS VIRTUALES VPNs


2.1. 2.2.

INTRODUCCIN QUE SON LAS REDES PRIVADAS VIRTUALES VPNs? 23

22

22

3. ARQUITECTURAS VPN
3.1. 3.2. 3.3. 3.4.

INTRANET VPN LAN-to-LAN ACCESO REMOTO VPN EXTRANET VPN MODELOS DE ENTUNELAMIENTO

29

30 36 39 41

4. AUTENTICACIN Y CIFRADO

4.1. AUTENTICACIN 4.1.1. LAS AMENAZAS DE SEGURIDAD EN LAS REDES DE DATOS 4.1.1.1. Spoofing 4.1.1.2. Hijacking

45

45 46 47 48 vii

4.1.1.3. Sniffing 4.1.1.4. Ataque del hombre-en-la-mitad 4.1.2. SISTEMAS DE AUTENTICACIN 4.1.2.1. Passwords tradicionales 4.1.2.2. Passwords nicos 4.1.2.3. PAP (Password Authentication Protocol) 4.1.2.4. CHAP (Challenge Handshake Authentication Protocol) 4.1.2.5. RADIUS (Remote Authentication Dial-In User Service) 4.2. CIFRADO 4.2.1. CRIPTOGRAFIA DE LLAVES PUBLICAS 4.2.2. DOS ALGORITMOS IMPORTANTES DE LLAVES PBLICAS 4.2.2.1. Diffie-Hellman 4.2.2.2. RSA 4.3. INFRAESTRUCTURA DE LLAVES PBLICAS 4.3.1. ARQUITECTURA DE UNA INFRAESTRUCTURA DE LLAVES PUBLICAS 4.3.2. CERTIFICACIN 72 4.3.3. VALIDACIN 4.3.4. REVOCACIN DEL CERTIFICADO 4.3.5. FORMATOS DE CERTIFICADOS DIGITALES 75 4.3.5.1. Certificado X.509 4.3.5.2. Certificados PGP 79 4.3.6. SISTEMAS DE ADMINISTRACIN DE CERTIFICADOS 4.3.6.1. Autoridad de certificacin (CA) 4.3.6.2. Autoridad de registro (RA) 4.3.6.3. Depsitos de certificados y de CRLs 4.4. CONTROL DE ACCESO 4.4.1. POLTICAS DE CONTROL DE ACCESO 4.4.2. REGLAS DE CONTROL DE ACCESO 4.4.3. MECANISMOS DE CONTROL DE ACCESO 4.4.3.1. Listas de control de acceso 4.4.3.2. Listas de capacidades 4.4.4. ADMINISTRACIN DE LAS POLTICAS DE CONTROL DE ACCESO 90 4.4.4.1. Administracin de polticas distribuidas 4.4.4.2. Administracin centralizada de polticas

49 50 51 51 52 53 54 55 58 60 63 63 67 69 71 73 74 75 82 82 83 83 84 85 86 87 88 90

91 92

5. TECNOLOGAS VPN

5.1. PPTP (Point-to-Point Tunneling Protocol) 5.1.1. RELACION ENTRE PPP Y PPTP 5.1.2. TUNELES 5.1.3. ENTUNELAMIENT LAN-to-LAN 103

95

95 97 100

viii

5.1.4. 5.1.4.1.

COMPONENTES DE UNA VPN PPTP Servidores PPTP 105 5.1.4.2. Software cliente PPTP 5.1.4.3. Servidores de acceso a la Red 106 5.1.4.4. Estructura del protocolo 5.1.4.5. Conexin de control 5.1.4.6. Operacin del tnel 5.1.4.6.1. Cabecera mejorada GRE 5.2. L2TP (Layer 2 Tunneling Protocol) 5.2.1. COMPONENTES BASICOS DE UN TUNEL L2TP 5.2.1.1. Concentrador de acceso L2TP (LAC) 5.2.1.2. Servidor de Red L2TP (LNS) 5.2.1.3. tnel 5.2.2. TOPOLOGA DE L2TP 5.2.3. ESTRUCTURA DEL PROTOCOLO L2TP 5.2.3.1. Formato de una cabecera L2TP 5.2.3.2. Tipos de mensajes de control 5.2.4. OPERACIN DEL PROTOCOLO 5.2.4.1. Establecimiento de la Conexin de Control 5.2.4.2. Autenticacin del tnel 5.2.4.3. Establecimiento de la Sesin 5.2.4.3.1. Establecimiento de una Llamada Entrante 5.2.4.3.2. Establecimiento de una Llamada Saliente 5.2.4.4. Reenvo de tramas PPP 123 5.2.4.5. Uso de nmeros de secuencia en el Canal de Datos 5.2.4.6. Keepalive (Hello) 5.2.4.7. Terminacin de la Sesin 5.2.4.8. Terminacin de la Conexin de Control 5.3. IPSEC 5.3.1. COMPONENTES DE IPSEC 5.3.1.1. Protocolos de Seguridad 5.3.1.2. Asociaciones de Seguridad (SAs) 5.3.1.3. Bases de Datos de Seguridad 5.3.1.3.1. Bases de Datos de Asociaciones de Seguridad (SAD) 5.3.1.3.2. Bases de Datos de Polticas de Seguridad 5.3.2. AUTHENTICATION HEADER 5.3.2.1. Modo Transporte 5.3.2.2. Modo tnel 5.3.3. ENCAPSULATION SECURITY PAYLOAD ESP 5.3.3.1. Modo Transporte 5.3.3.2. Modo Tnel 5.3.4. INTERNET KEY EXCHANGE 5.3.4.1. Fase 1 IKE 5.3.4.2. Fase 2 IKE 5.3.4.3. Generacin de Llaves en IKE

105 106 108 108 110 111 112 113 113 113 114 114 115 116 118 119 120 121 121 122 122 123 124 125 125 126 127 127 128 131 131 132 135 138 139 140 142 143 144 148 150 151 ix

5.4. 5.4.1. 5.4.2. 5.4.3. 5.4.4. 5.4.5. 5.4.6. 5.4.7.

MPLS 152 DIFERENCIACIN DE PAQUETES POR SERVICIO INDEPENDENCIA Y CONTROL DEL REENVIO PROPAGACIN DE INFORMACIN EXTRA DE ENRUTAMIENTO QUE ES MPLS? COMPONENTES DE UNA RED MPLS MECANISMO DE IMPOSICIN DE ETIQUETAS EN MPLS REENVIO DE PAQUETES MPLS 156 157 158 158 162 163 164

6. MONTAJES PRACTICOS

6.1. ACCESO REMOTO CON PPTP 6.1.1. ESCENARIO MONTADO 6.1.2. INSTALACIN Y CONFIGURACIN DEL SERVIDOR PPTP 168 6.1.3. INSTALACIN Y CONFIGURACIN DE UN CLIENTE PPTP EN WINDOWS XP 6.2. LAN-to-LAN IPSEC USANDO EQUIPOS CISCO 6.2.1. ESCENARIO MONTADO 6.2.2. INSTALACION Y CONFIGURACION 6.3. LAN-to-LAN IPSEC USANDO LINUX Y FreeS/WAN 6.3.1. ESCENARIO MONTADO 6.3.2. INSTALACION Y CONFIGURACIN

167

167

178 188 188 188 198 198 198

7. CONCLUSIONES 8. RECOMENDACIONES 9. BIBLIOGRAFIA

207 220 221

LISTA DE FIGURAS
Figura 1.1 Figura 1.2 Figura 1.3 Enlace tpico Clear Channel. Esquema Bsico Enlace tpico Clear Channel. Esquema detallado Diferentes dispositivos que intervienen en una red Frame Relay. Esquema bsico. Figura 1.4 Ejemplo de asignacin de valores DLCI en una red Frame Relay. 10 Figura 1.5 Formato bsico de una celda ATM Figura 1.6 Dispositivos que intervienen en una red ATM Figura 1.7 Formato de las diferentes cabeceras de una celda ATM. A la izquierda el formato general, en el centro una celda UNI, y a la derecha una celda NNI Figura 1.8. Canales Virtuales (VC) dentro de caminos virtuales (VP) Figura 1.9. Ancho de banda de un canal convencional de voz humana Figura 1.10 Escenario tpico de una conexin anloga de datos sobre la RTPC. Figura 1.11 Escenario tpico de una conexin anloga donde los enlaces de ltimo kilmetro en ambos lados son anlogos. Figura 1.12 Diagrama de Interfaces y equipos en una conexin RDSI BRI. Figura 2.1 Figura 2.2 Figura 2.3 Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura 3.1 3.2 3.3 3.4. 3.5. 3.6 Distintas maneras de crear una VPN Elementos bsicos de un tnel VPN Una topologa ms compleja y detallada de una VPN 4 5 7

12 13 14 15 17 18 19 20 24 25 26 30 30 31 31 32 33 36 38 39 40

Enlace Punto-a-punto Topologa en estrella Topologa de malla parcial Topologa de malla completa Detalle de 4 nodos en estrella con 2 PVCs Esquema de una solucin Intranet VPN (LAN-to-LAN VPN) 3.7 Trfico total consolidado mes a mes que se ha cruzado por el NAP Colombia desde Julio de 2001 hasta Abril de 2003. [Fuente: http://www.nap.com.co] 3.8 Escenario de Acceso remoto VPN 3.9 Dos montajes tpicos de un acceso remoto VPN 3.10 Arquitectura Extranet VPN, clasificando el acceso segn privilegios de los clientes VPNs remotos

xi

Figura 3.11 Modelos de entunelamiento VPN Figura 4.1 Figura 4.2 Figura 4.3 71 Figura 4.4 Figura 4.5 Figura Figura Figura Figura Figura Autenticacin RADIUS usando un servidor proxy Esquema de cifrado con llaves pblicas Arquitectura de una infraestructura de llaves pblicas

41 57 61 77 79 80 81 85 92 94 96 100 102 104 111 114 116 116 120 121 122 125 126 129 134 136 138 139 141 143 144 145 149 150 xii

Formato de un certificado X.509v3 Un certificado digital X.509 tal como lo muestra Netscape 4.6 Certificado PGP en su versin ASCII 4.7 Estructura de un certificado PGP 4.8 Control de acceso en un modelo cliente-servidor 4.9 Manejo de polticas distribuidas 4.10 Manejo de polticas centralizado Conexin PPP tpica entre un host y un RAS Estructura de un tnel PPTP Tneles Voluntarios Tneles Permanentes Topologa LAN-to-LAN usando un tnel PPTP Estructura general de un paquete IP encapsulado PPTP Distintos escenarios de tneles L2TP Estructura del protocolo L2TP Formato de una cabecera L2TP Entunelamiento de tramas PPP usando L2TP Establecimiento de una conexin de control Establecimiento de una llamada entrante Establecimiento de una llamada saliente

Figura 5.1 Figura 5.2 Figura 5.3 101 Figura 5.4 Figura 5.5 Figura 5.6 Figura Figura Figura Figura Figura Figura Figura

5.7 5.8 5.9 5.10 5.11 5.12 5.13 122 Figura 5.14 Terminacin de la sesin Figura 5.15 Terminacin de la conexin de control Figura 5.16 Estructura del paquete IP en modo de Transporte y Tnel Figura 5.17 Ejemplos de entradas en una base de datos de polticas de seguridad Figura 5.18 Formato de la cabecera de autenticacin Figura 5.19 Modo Transporte AH Figura 5.20 Modo Tnel AH Figura 5.21 Nuevo paquete IP procesado con ESP Figura 5.22 Modo transporte ESP Figura 5.23 Modo tnel ESP Figura 5.24 Formato de un mensaje y una cabecera ISAKMP Figura 5.25 Intercambio de mensajes en la fase 1 IKE usando modo principal Figura 5.26 Intercambio de mensajes en la fase 1 IKE usando modo agresivo

Figura 5.27 Intercambio de mensajes en la fase 2 IKE usando modo rpido Figura 5.28 Red IP basada en un backbone ATM Figura 5.29 Backbone IP sin polticas de control de trfico Figura 5.30. Arquitectura de un nodo MPLS Figura 5.31 Mecanismos de imposicin y de extraccin de etiquetas MPLS y reenvo de paquetes etiquetados Figura 6.1 Figura 6.2 Figura 6.3 Figura 7.1. Figura 7.2. Escenario PPTP implementado en Windows 2000 Server 167 Escenario IPSec LAN-to-LAN implementado con equipos Cisco Escenario IPSec LAN-to-LAN implementado en Linux con la aplicacin FreeS/WAN Escenario implementado con tecnologas tradicionales Escenario implementado con VPN

150 154 156 161 166

188 198 216 218

xiii

LISTA DE TABLAS
Tabla 1.1. Tabla 3.1. Equivalencia entre sistemas SONET y SDH Cuadro comparativo costo E1 nacional y E1 Internet desde 1999 hasta la fecha. Fuente ETB-Datamundo. Comparacin de tiempo y dinero necesarios para romper llaves de diferente longitud 3

35 59

Tabla 4.1

xiv

1. LOS ENLACES PRIVADOS ANTES DE LA APARICION DE LAS REDES PRIVADAS VIRTUALES

1.1.

INTRODUCCIN

Desde el principio de los tiempos, la humanidad ha tenido la necesidad de comunicarse. Paralelamente tambin ha existido la necesidad de hacerlo de manera privada, es decir que el mensaje solo le llegue a determinados receptores. En las redes de comunicaciones pasa exactamente lo mismo. En especial el sector corporativo siempre ha requerido la implementacin de enlaces privados para transportar de forma segura toda su informacin confidencial. Este captulo trata sobre la manera en que se realizan los enlaces privados, y las diferentes tecnologas que los soportan.

1.2.

ENLACES PRIVADOS

Los enlaces privados se caracterizan por brindar seguridad en la transmisin de datos de extremo a extremo. Se valen siempre de una red de transmisin (en algunos casos tambin existe una red de conmutacin) para conectar las partes. Estos enlaces pueden ir desde los 9600bps (en el caso de una conexin conmutada usando un modem anlogo de 9600bps) hasta el orden 1

de los Gigabps (usando redes pticas, con equipos de transporte de ltima generacin o multiplexores DWDM).

1.3.

TIPOS DE ENLACES PRIVADOS

Las redes de computadores se han valido de los enlaces privados para interconectarse a travs de grandes distancias geogrficas. Antes de la aparicin de las VPN haban existido solo dos tecnologas de enlaces WAN, los enlaces dedicados, y los enlaces conmutados. Dentro de los enlaces dedicados caben topologas tales como Clear Channel, Frame Relay y ATM. Aunque se sabe que Frame Relay usa conmutacin de paquetes y ATM usa conmutacin de celdas, en este trabajo se clasifican como enlaces dedicados, porque en ltimas para el usuario la conmutacin es transparente. Dentro de los enlaces conmutados estn los anlogos que van desde 2400bit/s hasta los 56 kbit/s y los digitales RDSI de 64 kbit/s y 128 kbit/s

1.3.1.

ENLACES DEDICADOS

Los enlaces dedicados, como su nombre lo indica, son conexiones permanentes punto-punto, o punto-multipunto, que se valen de una infraestructura de transporte (Capa 1) o de transporte y conmutacin (Capa 1 y 2). Los primeros son comnmente llamados enlaces Clear Channel y los segundos son enlaces Frame Relay o ATM.

1.3.1.1.

Clear Channel

Son enlaces donde solo interviene la red de transporte del proveedor de servicios. Para el mercado corporativo comnmente van desde los 64 kbit/s hasta los 2048 kbit/s, en pasos nx64. Para el mercado de proveedores de servicio van desde ratas E1 hasta OC-3 y superiores inclusive. En la tabla 1.1 se observan las ratas de transmisin desde OC-1 hasta OC-768 as como su correspondencia entre redes SONET y SDH. SONET OC-1 OC-3 OC-12 OC-48 OC-192 OC-768 SDH --STM-1 STM-4 STM-16 STM-64 STM-256 Mbps 51.84 155.52 622.08 2455.32 (2.5 Gbps) 9953.28 (10 Gbps) 39813.12 (40 Gbps)

Tabla 1.1 Equivalencia entre sistemas SONET y SDH

Los enlaces Clear Channel ofrecen un throughput efectivo casi del 100% ya que no usan ningn tipo de encapsulacin de nivel 2, es decir, no hay presentes cabeceras de ningn tipo. Por lo general estos enlaces son entregados en interfaz E1 balanceada o desbalanceada con trama G.703, o en interfaz serial de datos V.35. Por lo general, la compaa (o cliente en general) debe tener un puerto disponible DTE que cumpla con las especificaciones tcnicas del equipo de comunicaciones entregado por el proveedor. Tpicamente la mayora de los equipos que se usan para recibir los enlaces Clear

Channel por parte del cliente son enrutadores o switches de nivel 3. Y son estos, los que se encargan de manejar los niveles 2 y3.1 En general, las topologas de los enlaces Clear Channel son robustas pero a su vez estticas. Esto significa que para aumentar o disminuir la rata del enlace es necesario cambiar equipos o manipularlos localmente. Lo que se transfiere al cliente en indisponibilidades del servicio no deseadas. Vale la pena aclarar, que los enlaces Clear Channel fueron la primera tecnologa WAN que se adopt usando la infraestructura de voz PCM de los distintos operadores de telefona locales, nacionales e internacionales. Como era de esperarse, por provenir de una tecnologa que no haba sido pensada para transmitir datos fue superada rpidamente por otros tipos de tecnologas como Frame Relay y ATM, aunque aun muchas empresas siguen teniendo enlaces Clear Channel. La figura 1.1 muestra un esquema bsico, donde se observa la transparencia para una organizacin del enlace Clear Channel contratado.

nx64 nxE1 STM-n

Red de Transporte

nx64 nxE1 STM-n

Sitio1

Sitio2

Figura 1.1 Enlace tpico Clear Channel. Esquema Bsico

En la actualidad existen enrutadores y switches que manejan incluso protocolos a nivel 4. Estos equipos se usan para balancear trfico entre varios servidores, redireccionamiento de trfico, polticas de calidad de servicio y accounting (toda aquella informacin que sirve para tarifar transacciones o servicios) .
1

La figura 1.2 muestra un esquema detallado de los equipos usados en una topologa de transporte de datos Clear Channel. Tambin muestra los lmites de la ltima milla y del backbone que se usa para transporte, estos tramos son generalmente responsabilidad del proveedor del servicio. Los equipos que se muestran pueden variar dependiendo del medio fsico a utilizar: cobre, fibra ptica o espectro electromagntico.

Servidor de Aplicaciones

Estacion de Trabajo

CSU/DSU Enrutador Base de Datos

Terminal Optico STM-1

BACKBONE en anillo FO+RF

Terminal Optico STM-1

CSU/DSU Enrutador

RED CORPORATIVA Sitio1

LTIMO KILOMETRO

BACKBONE

LTIMO KILOMETRO

RED CORPORATIVA Sitio2

Figura 1.2 Enlace tpico Clear Channel. Esquema detallado

1.3.1.2.

Frame Relay

Frame Relay es un protocolo WAN de alto rendimiento que trabaja en la capa fsica y de enlace de datos del modelo de referencia OSI. Frame Relay fue diseado originalmente para trabajar con redes ISDN. Frame Relay es una tecnologa de conmutacin de paquetes, que permite compartir dinmicamente el medio y por ende el ancho de banda disponible. La longitud de los paquetes es variable para hacer ms eficiente y flexible las transferencias de datos. Estos paquetes son conmutados por varios segmentos de la red hasta que llegan hasta el destino final. Todo el acceso al medio en una red de conmutacin de paquetes es controlado usando tcnicas de multiplexacin estadstica, 5

por medio de las cuales se minizan la cantidad de demoras y/o colisiones para acceder al medio. Ethernet y Token Ring, los protocolos de redes LAN ms usados, tambin usan conmutacin de paquetes y tcnicas de difusin. Frame Relay es una evolucin de las redes X.25, no hace retransmisin de paquetes perdidos ni windowing2, caractersticas que si ofreca su antecesor ya que en los aos 70 (poca en la que aparece X.25) los medios fsicos no eran tan confiables como los de hoy da, y por tanto se necesitaba mayor robustez. Todas las ventajas que ofrecen los medios de hoy da, han posibilitado a Frame Relay ofrecer un alto desempeo y una gran eficiencia de transmisin. [REF1.1.] 1.3.1.2.1. Estandarizacin

Los propsitos iniciales para estandarizar Frame Relay fueron presentados al Comit Consultivo Internacional para la Telefona y la Telegrafa (CCITT) pero no tuvieron mucha acogida. Solo hasta 1990 cuando Cisco, Digital Equipment, Nortel Networks (en ese tiempo todava Northern Telecom) y StrataCom conformaron un forum y desarrollaron un conjunto de normas llamadas LMI (Local Management Interface) que fueron adicionadas a la propuesta original que tenia la CCITT, fue que esta ltima organizacin junto con la americana ANSI se interesaran de nuevo en Frame Relay y finalmente se publicara un estndar, que fue apoyado por la ITU-T. Esta estandarizacin le dio tal fuerza a Frame Relay que prcticamente todos los fabricantes de equipos de comunicaciones
Windowing es un esquema de control de flujo en el cual el dispositivo fuente requiere un reconocimiento del destino despus que un cierto nmero de paquetes han sido transmitidos. Por ejemplo con un tamao de ventana de tres, la fuente requiere de un mensaje de reconocimiento despus que ha enviado tres paquetes para poder continuar con la transferencia.
2

de datos desarrollaron dispositivos que soportaron la creciente tecnologa. 1.3.1.2.2. Dispositivos Frame Relay

Los equipos que se usan en una red Frame Relay se pueden dividir en dos categoras: Equipos Terminales de Datos (DTEs) y Equipos Terminales de Circuitos de Datos (DCEs). La figura 1.3 ilustra la ubicacin de los DTEs y los DCEs en un red Frame Relay. Los DTEs son generalmente considerados equipos terminales de una red especifica y tpicamente son enrutadores, computadores personales, terminales o bridges. Estos equipos se localizan en las premisas del cliente y en la mayora de los casos son propiedad de los mismos. Los DCEs son dispositivos normalmente propiedad del carrier. El propsito de los equipos DCEs es proveer o generar seales de reloj y conmutar los paquetes de la red. Por lo general, son llamados packet switchs o conmutadores de paquetes.
Terminal Enrutador

DTE

Packet Switch

DTE

DCE

Red Frame Relay


Brigde

DTE

Figura 1.3 Diferentes dispositivos que intervienen en una red Frame Relay. Esquema bsico.

En la conexin entre los dispositivos DCE y DTE intervienen dos componentes, uno de nivel fsico y otro de nivel de enlace de datos. En el nivel fsico se definen todas las caractersticas fsicas, elctricas y mecnicas entre los dos, y el nivel de enlace de datos define todas las especificaciones Frame Relay o Frame Relay LMI segn sea el caso. 1.3.1.2.3. Circuitos virtuales Frame Relay

Frame Relay es una tecnologa WAN que usa enlaces orientados a conexin, esto significa que una comunicacin se define entre un par de dispositivos y que cada una de las conexiones existentes en la red tiene un identificador asociado particular. Este servicio es implementado usando circuitos virtuales, los cuales son conexiones lgicas creadas entre dos dispositivos DTE a travs de la red conmutada de paquetes Frame Relay. Sobra decir que este circuito es bidireccional. Un circuito lgico puede crearse a travs de mltiples dispositivos intermediarios DCE dentro de la red Frame Relay. Los circuitos virtuales Frame Relay se pueden dividir en dos categoras: circuitos virtuales conmutados (SVCs) y circuitos virtuales permanentes (PVCs). Circuitos Virtuales Conmutados (SVCs) Los SVCs son conexiones temporales y que se usan en situaciones donde la transferencia de datos entre un par de dispositivos DTE es espordica a travs de la red Frame Relay. Los SVCs tienen 4 estados operacionales: 8

Call Setup: Cuando se realiza la negociacin y el establecimiento de un circuito virtual entre dos DTEs. Data Transfer: Cuando los datos entre los dos DTEs son transmitidos sobre el circuito virtual. Idle: Cuando la conexin entre los dos DTEs est todava activa, pero no hay trfico de datos. Si por cierto periodo de tiempo el circuito se encuentra en este estado, se procede a terminar la conexin.

Call Termination: Cuando el circuito virtual entre los dos DTEs es terminado.

Si despus de terminado el circuito los dispositivos DTEs necesitan transmitir ms datos, se deber establecer un nuevo SVC, y as sucesivamente. Este tipo de circuitos virtuales no es muy usado, de hecho muchos fabricantes no incluyen esta caracterstica dentro de sus equipos Frame Relay. Circuitos Virtuales Permanentes (PVCs) Los PVCs son conexiones establecidas permanentemente y que se usan en donde la transferencia de datos es continua entre dos dispositivos DTE. Este tipo de conexiones no requieren hacer una llamada de configuracin ni de terminacin como en los SVCs. De hecho los PVCs siempre operan en uno de los siguientes dos estados: Data transfer: Cuando los DTEs estn intercambiando trfico. Idle: Cuando no hay transferencia de datos, pero la conexin sigue activa. A diferencia de los SVCs, un PVC puede estar indefinidamente en este estado y el enlace no es terminado. 9

1.3.1.2.4.

Identificadores

de

conexin

de

enlace de datos (DLCI) Los circuitos virtuales Frame Relay son identificados por DLCIs. Los valores de los DLCIs son asignados por el proveedor de servicio y tienen solo significado a nivel local, esto quiere decir que en una red Frame Relay pueden existir varios DLCIs con el mismo valor, pero no puede haber varios DTEs con un mismo DLCI conectados al mismo Packet Switch. Ntese que en la figura 1.4 existen valores repetidos de DLCIs pero no en un mismo DCE. Adems, los dos extremos del PVC pueden tener valores diferentes.

Terminal

Enrutador DLCI 12

DTE

Packet Switch

DLCI 12 DLCI 41

DTE

DCE

DLCI 18

DTE DLCI 23

Red Frame Relay

DLCI 23 Brigde

DTE

Figura 1.4 Ejemplo de asignacin de valores DLCI en una red Frame Relay.

1.3.1.3.

ATM (Asynchronous Transfer Mode)

El Modo de Transferencia Asncrono (ATM) es un estndar desarrollado por la Unin Internacional de Telecomunicaciones (ITU-T) para transmitir mltiples tipos de servicios, tales como voz, video y datos 10

usando tcnicas de conmutacin de celdas pequeas de tamao fijo. Las redes ATM son, al igual que las redes Frame Relay, orientadas a conexin. [REF1.2] 1.3.1.3.1. Estandarizacin

ATM est basado en esfuerzos hechos por el grupo de trabajo BISDN (Broadband Integrated Services Digital Network) de la ITUT. Fue originalmente concebido como una tecnologa de transferencia de voz, video y datos de alta velocidad sobre redes pblicas. Luego el Foro ATM extendi la visin pblica de la ITU-T a redes privadas. El foro ATM ha trabajo en el desarrollo de las siguientes especificaciones, que hacen parte de ATM: User-to-Network Interface (UNI) 2.0 UNI 3.0 UNI 3.1 Public-Network Node Interface (P-NNI) LAN Emulation (LANE) Funcionamiento de las redes ATM

1.3.1.3.2.

ATM es una tecnologa de multiplexacin y de conmutacin de celdas que combina los beneficios de una red de conmutacin de circuitos (capacidad garantizada, retardos constantes) y de una red de conmutacin de paquetes (flexibilidad y eficiencia para trfico intermitente). Permite transmisiones desde unos pocos megabits por segundo hasta cientos de gigabits por segundo. Su naturaleza asncrona, hace de ATM una tecnologa ms eficiente que las sncronas tales como TDM. En TDM a los usuarios se les 11

asigna un timeslot, y ningn otro cliente puede transmitir en ese timeslot as el propietario no este transmitiendo. Esto hace que la red no sea muy eficiente. En ATM los timeslots siempre estn disponibles y se asignan por demanda basndose en la informacin que est contenida en las cabeceras de cada celda. 1.3.1.3.3. Formato de una celda ATM

ATM transmite informacin en unidades de tamao fijo llamadas celdas. Cada celda contiene 53 octetos o bytes. Los primeros 5 bytes conforman la cabecera y los restantes 48 contiene la informacin del usuario o payload tal como se ve en la figura 1.5. El tamao pequeo de cada celda hace que las transmisiones de voz y video gocen de una buena calidad ya que esta clase de trfico no tolera retardos producidos por esperar paquetes de gran tamao.

48

Header

Payload

Figura 1.5 Formato bsico de una celda ATM

1.3.1.3.4.

Dispositivos ATM

Una red ATM est compuesta de dos tipos de dispositivos: los switches ATM y los terminadores ATM. Un switch ATM es el encargado de recibir las celdas entrantes provenientes de otro switch ATM, leer y actualizar las cabeceras de cada celda y de direccionar la celda hasta que llegue a su destino final.

12

Los terminadores ATM (o sistemas finales) son dispositivos que estn provistos de un adaptador de interfaz de red ATM, por lo general estn en las premisas del cliente. Ejemplos de terminadores ATM, como los que aparecen en la figura 1.6 son estaciones de trabajo, enrutadores, switches LAN, video CODECs (coder-decoders).

Switch LAN

ATM Switch Red ATM

Enrutador

Estacin de Trabajo

CSU/DSU

Terminadores ATM

Figura 1.6 Dispositivos que intervienen en una red ATM

En ATM se distingue dos tipos de interfaces: la UNI (user-network interface) que conecta un terminador con un switch ATM y la NNI (network-node interface) que conecta dos switches ATM. 1.3.1.3.5. Formato de una cabecera ATM

Una cabecera de una celda ATM puede tener dos tipos de formatos, dependiendo si se usa en interfaces UNI o NNI. La estructura de cada uno de estos formatos se detalla en la figura 1.7. La diferencia principal radica en que el campo VPI de una cabecera NNI ocupa los primeros 12 bits ya que tiene que manejar un gran numero de identificadores debido a que se usan para comunicacin entre switches ATM y en una red pueden haber muchos de ellos.

13

VPI Header (5 bytes) VPI VCI PT HEC CLP

VPI VCI PT HEC CLP

53 bytes Payload (48 bytes) Payload (48 bytes) Payload (48 bytes)

8 bits

ATM Cell

ATM UNI Cell

ATM NNI Cell

Figura 1.7 Formato de las diferentes cabeceras de una celda ATM. A la izquierda el formato general, en el centro una celda UNI, y a la derecha una celda NNI

Control de flujo genrico (GFC): Contiene funciones locales, tales como identificadores para mltiples estaciones que usan una misma interfaz ATM compartida. Casi no se usa, y siempre tiene un valor por defecto.

Identificador de camino virtual (VPI): Conjuntamente con el VCI, identifica el siguiente destino de una celda a travs de una red de switches ATM.

Identificador de canal virtual (VCI): Tiene la misma funcin que un VPI pero a nivel ms bajo. Un VP (Virtual Path) es la suma de varios VC (Virtual Channel).

Tipo de carga til (PT): Indica si la carga til de la celda contiene informacin de datos del usuario o de control. Prioridad para evitar congestin (CLP): Indica si la celda debe ser descartada o no. Si el bit CLP tiene como valor 1, la celda deber ser descartada prefiriendo as las celdas con el bit CLP en cero.

14

Control de error para la cabecera (HEC): Sirve para realizar checksum, pero solamente para la cabecera misma.

1.3.1.3.6.

Conexiones Virtuales ATM

Las redes ATM son bsicamente redes orientadas a conexin, esto significa que se tienen que configurar canales virtuales (VC) a travs de la red para la adecuada transferencia de datos. Haciendo la analoga con Frame Relay, un canal virtual equivale a un circuito virtual. En ATM existen dos tipos de conexiones: los caminos virtuales (Virtual Paths VPs), los cuales son identificados por medio de VPIs (Virtual Path Identifiers), y los canales virtuales, los cuales son identificados con una combinacin de VPIs y de VCIs (Virtual Channel Identifier). Un camino virtual es una suma de canales virtuales, cada uno de los cuales es conmutado transparentemente sobre la red ATM. La figura 1.8 muestra esta relacin entre VCs y VPs.

VC

VP

VP

VC

VC

VP Canal de Transmisin

VP

VC

Figura 1.8. Canales Virtuales (VC) dentro de caminos virtuales (VP)

1.3.1.3.7.

Conmutacin ATM

La funcin bsica de un switch ATM es la de reenviar. Una celda es recibida a travs de un enlace con un valor conocido VCI o VPI. El

15

switch mira en su tabla local de traslacin para determinar el puerto (o puertos) de salida para este trfico y les coloca un nuevo VPI o VCI, y as se repite este esquema hasta que el trfico es recibido por el punto terminal ATM. Como se puede ver, cada vez que una celda es retransmitida se le asigna un nuevo VPI o VCI, por esto se dice que estos valores solo tienen significado local y que se pueden reutilizar en otros puntos de la red cuando as se necesite.

1.3.2.

ENLACES CONMUTADOS

Los enlaces conmutados se dividen en dos tipos: los anlogos y los digitales. Los primeros llegan hasta ratas de 53 kbit/s para el downlink y hasta de 48 kbit/s para el uplink [REF1.3], los segundos transmiten y reciben a 64 kbit/s o 128 kbit/s. Estos ltimos son conocidos como enlaces RDSI (o ISDN, en ingls) que son las siglas de Red Digital de Servicios Integrados. 1.3.2.1. Enlaces Conmutados Anlogos

Fue quiz la primera tecnologa de transmisin de datos que us el hombre para construir redes privadas entre dos sitios remotos. Esto lo hizo aprovechando la Red de Telefona Pblica Conmutada - RTPC (PSTN, en ingls), dicha red ha tenido muchos desarrollos en los ltimos 20 aos. El servicio tradicional que la RTPC ha prestado ha sido comunicacin de voz, y solo recientemente se empez a usar para soportar un creciente mercado de transferencia de datos.

16

El rango de frecuencia de la voz humana va desde los 20Hz hasta los 20Khz, pero casi toda la energa espectral se encuentra entre los 300Hz y 3.4Khz, por ende, la ITU ha definido un canal de voz (speech channel) para telefona en esta banda [REF1.4]. Por cuestiones prcticas, y para evitar efectos aliasing se maneja el canal desde los 0Hz hasta los 4KHz, dejando unos pocos Hz como bandas de guarda. La figura 1.9 representa lo dicho anteriormente.

Canal de Voz

0Hz

300Hz

3400Hz

4000Hz

Figura 1.9. Ancho de banda de un canal convencional de voz humana

De este criterio parti todo el desarrollo que se ha hecho sobre las redes de telefona, todos los equipos fueron diseados para transmitir seales en este rango. Las investigaciones que se hicieron en el campo de las comunicaciones han demostrado que transportar cualquier seal, incluso la voz, en formato digital tiene inmensas ventajas comparado con una transmisin anloga, de all que nuestra voz sea convertida en una seal digital en las centrales telefnicas y transportada de la misma manera entre ellas. Apoyndose un poco en la teora, el criterio de muestreo de Nyquist [REF1.5] dice que para recuperar una seal anloga partiendo de ella misma pero digitalizada se tiene que muestrear al doble de la frecuencia mxima, es decir que para la voz humana la rata de 17

muestreo debe ser 8Khz. Si se usan conversores A/D D/A de 8 bits se necesita un canal de transporte de 64 kbit/s, de all proviene la rata bsica de transmisin de voz, y que hoy prcticamente ha sido una limitante para las comunicaciones de datos sobre redes telefnicas, que se pensaron inicialmente solo para voz. [REF1.6]. En un enlace conmutado de datos, intervienen varios equipos desde el usuario inicial hasta el punto o equipo destino. La figura 1.10 muestra los componentes de un enlace tpico de datos sobre la red telefnica pblica, se puede notar la necesidad de realizar una conversin A/D y otra D/A. La inercia que resulta de todo este proceso electrnico es la que en ltimas limita a 56 kbit/s3 una comunicacin anloga, que incluso puede llegar a 33.6 kbit/s cuando aparece una tercera y cuarta conversin entre la Central Telefonica 2 y el terminador de la llamada.

Enlace Anlogo

Enlace Digital

Conversin D/A

Conversin A/D

RTPC
Iniciador de la llamada

Central Telefnica 1

Central Telefnica 2

Terminador de la llamada

Figura 1.10 Escenario tpico de una conexin anloga de datos sobre la RTPC.

Se puede notar que la conexin entre el iniciador de la llamada y la central telefnica es anloga, y se lleva a cabo usando el mismo par de cobre de la lnea telefnica, para esto se usa un modem anlogo. Mientras que en el lado del sitio remoto la conexin es digital, y para esto se usan enlaces RDSI PRI o BRI. Por lo general los equipos que intervienen en este lado son servidores de acceso remoto (Remote
Este valor es terico, en la prctica no se obtienen velocidades superiores de 53 kbit/s para el downstream y de 48 kbit/s para el upstream.
3

18

Access Server RAS). Cuando este enlace es tambin anlogo, entonces se puede notar que en el proceso total de la conexin intervienen cuatro conversiones, dos A/D y dos D/A, esto hace que la rata de transmisin y de recepcin mximas sean apenas de 33.6 kbit/s. La figura 1.11 ilustra este escenario.

Enlace Anlogo

Enlace Digital

Enlace Anlogo

Conversin D/A

Conversin A/D

Conversin D/A

Conversin A/D

RTPC
Iniciador de la llamada

Central Telefnica 1

Central Telefnica 2

Terminador de la llamada

Figura 1.11 Escenario tpico de una conexin anloga donde los enlaces de ltimo kilmetro en ambos lados son anlogos.

1.3.2.2.

Enlaces Conmutados Digitales RDSI

RDSI o Red Digital de Servicios Integrados, es un sistema de telefona digital que se desarrollo hace ms de una dcada. Este sistema permite transmitir voz y datos simultneamente a nivel global usando 100% conectividad digital. En RDSI, la voz y los datos son transportados sobre canales B (del ingls Bearer) que poseen una velocidad de transmisin de datos de 64 kbit/s, aunque algunos switches ISDN limitan esta capacidad a solo 56 kbit/s. Los canales D (o canales de datos) se usan para sealizacin y tiene ratas de 16 kbit/s o 64 kbit/s dependiendo del tipo de servicio. Los dos tipos bsicos de servicio RDSI son: BRI (del ingls Basic Rate Interface) y PRI (del ingls Primary Rate Interface). Un enlace BRI consiste de dos canales B de 64 kbit/s y un canal D de 16 kbit/s para 19

un total de 144 kbit/s. Este servicio est orientado a brindar capacidad de conexin para usuarios residenciales. Un enlace PRI est orientado a usuarios que requieren un mayor ancho de banda. En Estados Unidos la estructura bsica de canales es 23 canales B y 1 canal D, todos de 64 kbit/s, para un total de 1536 kbit/s. En Colombia donde se ha adoptado el estndar internacional de la ITU-T, y que adems es el estndar ETSI europeo, un PRI consiste de 30 canales B y 2 canales D, todos de 64 kbit/s, para un total de 2048 kbit/s. Para accesar a un servicio BRI, es necesario tener una lnea RDSI. Si solo se desean comunicaciones de voz es necesario tener telfonos digitales RDSI, y para transmitir datos es necesario contar con un adaptador de Terminal TA (del ingls Terminal Adapter) o un enrutador RDSI. La norma RDSI Colombia trabaja con interfaces BRI S/T, a diferencia de la americana que entrega en las premisas del usuario en interfaz BRI U. La figura 1.12 ilustra los diferentes tipos de interfaz y equipos terminales RDSI.
Fax Digitales Telfonos Digitales

Dispositivos RDSI

Dispositivos RDSI

TE1

TE1

Switch RDSI
Central Telefnica

Interface U

NT-1
Terminal de Red

Interface S/T

TA
Adaptador de Terminal

Puerto POTS

TE2
Equipo Anlogo

Figura 1.12 Diagrama de Interfaces y equipos en una conexin RDSI BRI.

20

A diferencia de las conexiones conmutadas anlogas en una conexin RDSI el camino es 100% digital desde la central hasta el sitio del abonado, por lo cual no existe ningn tipo de conversiones A/D o viceversa, lo que facilita la obtencin de velocidades de 64 kbit/s o 128 kbit/s, lo cual se logra convirtiendo los dos canales B de 64 kbit/s o en un canal lgico de 128 kbit/s. Esta caracterstica es usada solo en transmisin de datos y depende de la facilidad que tenga el equipo terminal de realizar esto. Tpicamente esta caracterstica tiene el nombre de Multilink.

REFERENCIAS: [REF1.1] [REF1.2] Internetworking Technologies Handbook, Cisco Press. Ford, Kim Lew, Spanier and Stevenson. 1997. [REF1.3] http://www.v90.com [REF1.4] Recomendacin G.100, Definitions used in Recommendations on general characteristics of internacional telephone connections and circuits, ITU-T, 1993 [REF1.5] Digital Communications, Pag. 63. Bernard Sklar, 1998, Second Edition [REF1.6] Recomendacin G.711, Pulse Code Modulation (PCM) of voice frecuencies, ITU-T, 1988

21

2.

REDES PRIVADAS VIRTUALES VPNs

2.1.

INTRODUCCIN

Es comnmente aceptado el hecho que las tecnologas de informacin en Internet han cambiado la forma como las compaas se mantienen comunicadas con sus clientes, socios de negocios, empleados y proveedores. Inicialmente las compaas eran conservadoras con la informacin que publicaban en Internet, tal como, productos, disponibilidad de los mismos u otros tems comerciales. Pero recientemente, con el auge que ha tenido Internet, por el cada vez menor costo que la gente tiene que pagar para acceder a esta gran red y con el significado que esta ha adquirido como el principal medio mundial de comunicacin, las redes privadas virtuales han hecho su aparicin con ms fuerza que nunca y se han ganado un espacio dentro del tan cambiante mundo de las redes de informacin. [REF2.1]. Tradicionalmente, un enlace privado se ha hecho por medio de tecnologas WAN como X.25, Frame Relay, ATM, enlaces Clear Channel o enlaces conmutados (todas estas tecnologas WAN tratadas en el captulo 1). Ahora con el gran crecimiento de Internet, es posible usar un protocolo como IP, sin importar la tecnologa WAN que lo soporte, para disfrutar de los servicios y ventajas que ofrecen las redes privadas. Y mientras que las tradicionales redes privadas se han hecho fuertes en las conexiones LAN-to-LAN, no han

22

sido capaces de atacar el mercado de los usuarios individuales o pequeas oficinas sucursales, y es aqu principalmente donde han surgido con fuerza las soluciones basadas en VPNs sobre IP, pues su implementacin resulta sencilla y bastante econmica. Adems el hecho que las VPNs se construyan sobre infraestructuras pblicas ya creadas han hecho que las empresas ahorren ms del 50% del costo que antes tenan que pagar en llamadas de larga distancia y en equipos fsicos de acceso remoto o en alquiler de enlaces privados o dedicados.

2.2.

QUE SON LAS REDES PRIVADAS VIRTUALES VPNs

Una VPN es una conexin que tiene la apariencia y muchas de las ventajas de un enlace dedicado pero trabaja sobre una red pblica. Para este propsito usa una tcnica llamada entunelamiento (tunneling), los paquetes de datos son enrutados por la red pblica, tal como Internet o alguna otra red comercial, en un tnel privado que simula una conexin punto a punto. Este recurso hace que por la misma red puedan crearse muchos enlaces por diferentes tneles virtuales a travs de la misma infraestructura. Tambin hace universales para su transporte los diferentes protocolos LAN entre los que se encuentran IP, IPX, Appletalk y Netbeui, de all la caracterstica de multiprotocolo que hace sumamente universal la tecnologa de las redes virtuales privadas. La figura 2.1 muestra los distintos escenarios que se pueden manejar con la tecnologa de Redes Privadas Virtuales (Dial-Up, Intranet VPN y Extranet VPN). [REF2.2]

23

Terminador de Tneles

OFICINA PRINCIPAL

Firewal l

INTERNET

Dial-up VPN Extranet VPN


Usuario Teleconmutado

Intranet VPN

Usuario Teleconmutado IBM Compatible

Usuarios VPN Dial-up


IBM Compatible

Oficina Sucursal

Socios de Negocio/Clientes

Figura 2.1 Distintas maneras de crear una VPN

Las tcnicas de entunelamiento se tratan con mayor detenimiento en el captulo 5 de este documento, pero bsicamente se puede decir que consiste en encapsular los paquetes de datos que salen de una LAN o del equipo del usuario remoto dentro de protocolos que trabajan a nivel 2 de la torre OSI. Los componentes bsicos de un tnel, y que se muestran en la figura 2.2. son: Un iniciador del tnel Uno o varios dispositivos de enrutamiento Un conmutador de tneles (opcional) Uno o varios terminadores de tneles

El inicio y la terminacin del tnel pueden ser hechos por una amplia variedad de equipos o software. Un tnel puede ser empezado, por ejemplo, por un

24

usuario remoto con un computador porttil equipado con un modem anlogo y un software de conexin telefnica para hacer una VPN, tambin puede haber un enrutador de una extranet en una oficina remota o en una LAN pequea. Un tnel puede ser terminado por otro enrutador habilitado para tal fin, por un switch con esta caracterstica o por un software que haga tal fin.

Iniciadores de Tneles

Terminadores de Tneles

Servidor de acceso Gateway VPN

TNEL
Enrutador con software VPN

INTERNET
Servidor de Acceso

Computador con software cliente VPN

Figura 2.2 Elementos bsicos de un tnel VPN

Adicionalmente y para completar una solucin VPN deben existir uno o ms dispositivos o paquetes de software que brinden cifrado, autenticacin y autorizacin a los usuarios del tnel. Adems muchos de estos equipos brindan informacin sobre el ancho de banda, el estado del canal y muchos ms datos de gestin y de servicio. La figura 2.3 muestra un diagrama ms detallado de una VPN dial-up usando como protocolo de entunelamiento a PPTP. Se notan los trayectos en los cuales el protocolo que encapsula los datos es PPP y la parte del recorrido que es tunelizada usando PPTP.

25

TNEL

Proveedor de Servicios de Internet

Conexion dedicada a Internet

PC con PPTP*

Servidor de Acceso

INTERNET
Gateway VPN

OFICINA PRINCIPAL

Enlace PPP

Enlace PPTP*
*PPTP = (Point to Point Tunneling Protocol), Protocolo de entunelamiento punto. Se tratara con mas detalle en el capitulo 5.

Figura 2.3 Una topologa ms compleja y detallada de una VPN

En muchos casos las caractersticas que le permiten a los dispositivos ser iniciadores o terminadores del tnel se pueden adicionar con una simple actualizacin del sistema operativo o de sus tarjetas. Una buena solucin VPN requiere la combinacin de tres componentes tecnolgicos crticos: seguridad, control de trfico y manejo empresarial. Seguridad: Dentro de este punto se destacan: el control de acceso para garantizar la seguridad de las conexiones de la red, el cifrado para proteger la privacidad de los datos y la autenticacin para poder verificar acertadamente tanto la identidad de los usuarios como la integridad misma de la informacin. Control de trfico: el segundo componente crtico en la implementacin de una efectiva VPN es el control de trfico que garantice solidez, calidad del servicio y un desempeo veloz. Las comunicaciones en Internet pueden llegar a ser excesivamente lentas, lo que las convertiran en soluciones inadecuadas 26

en aplicaciones de negocios donde la rapidez es casi un imperativo. Aqu es donde entra a jugar parmetros como la prioridad de los datos y la garantizacin de ancho de banda. Manejo empresarial: El componente final crtico en una VPN es el manejo empresarial que esta tenga. Esto se mide en una adecuada integracin con la poltica de seguridad de la empresa, un manejo centralizado desde el punto inicial hasta el final, y la escalabilidad de la tecnologa. Las VPNs se caracterizan tambin por su flexibilidad. Pueden ser conexiones punto-punto o punto-multipunto. Reemplazando una red privada con muchos y costosos enlaces dedicados, por un solo enlace a una ISP que brinde un punto de presencia en la red (POP por sus siglas en ingls), una compaa puede tener fcilmente toda una infraestructura de acceso remoto, sin la necesidad de tener una gran cantidad de lneas telefnicas anlogas o digitales, y de tener costosos pools de mdems o servidores de acceso, o de pagar costosas facturas por llamadas de larga distancia. En algunos casos las ISP se hacen cargo del costo que les genera a los usuarios remotos su conexin a Internet local, pues ven en este tipo de negocio un mayor inters por los dividendos del acceso. El objetivo final de una VPN es brindarle una conexin al usuario remoto como si este estuviera disfrutando directamente de su red privada y de los beneficios y servicios que dentro de ella dispone, aunque esta conexin se realice sobre una infraestructura pblica. REFERENCIAS: [REF2.1] Revista Data Communications, Artculo Next-Gen VPNs: The Design Challenge, Pag. 83, Vol. 28, No. 12, Septiembre de 1999.

27

[REF2.2] Virtual Private Networking, An Overview, Microsoft, Septiembre de 2001 http://www.microsoft.com/windows2000/techinfo/howitworks/communications/r emoteaccess/vpnoverview.asp

28

3.

ARQUITECTURAS VPN

El xito de una VPN depende de una adecuada eleccin de la tecnologa y del escenario, siempre acordes a las necesidades que se tengan. La tecnologa implica: tcnicas de entunelamiento, autenticacin, control de acceso, y seguridad de los datos; y los escenarios que se pueden construir son: Intranet VPN (LAN-to-LAN VPN), Acceso Remoto VPN y Extranet VPN. Intranet VPN (LAN-to-LAN VPN): En este escenario, mltiples redes remotas de la misma compaa son conectadas entre si usando una red pblica, convirtindolas en una sola LAN corporativa lgica, y con todas las ventajas de la misma. Acceso Remoto VPN: En este caso, un host remoto crea un tnel para conectarse a la Intranet corporativa. El dispositivo remoto puede ser un computador personal con un software cliente para crear una VPN, y usar una conexin conmutada, o una conexin de banda ancha permanente. Extranet VPN: Esta arquitectura permite que ciertos recursos de la red corporativa sean accesados por redes de otras compaas, tales como clientes o proveedores. En este escenario es fundamental el control de acceso.

29

3.1.

INTRANET VPN LAN-TO-LAN

Tradicionalmente, para conectar dos o ms oficinas remotas de una misma compaa se han necesitado contratar enlaces dedicados Clear Channels o Circuitos Virtuales Permanentes (PVCs) Frame Relay. Las empresas adoptan diferentes topologas de red WAN para interconectar todos sus sitios remotos, entre estas se encuentran: Enlaces punto-a-punto, de estrella, de malla parcial y de malla completa. Las figuras 3.1, 3.2, 3.3 y 3.4 detallan cada una de las topologas anteriormente mencionadas.

LAN 1

ENLACE WAN

LAN 2

Figura 3.1 Enlace Punto-a-punto.

Figura 3.2 Topologa en estrella

30

Figura 3.3 Topologa de malla parcial

Figura 3.4. Topologa de malla completa

En general, cuando se necesita concentrar trfico en al menos un nodo, es preferible usar tecnologas como Frame Relay pues solo se necesita un ltimo kilmetro por el cual viajan todos los PVCs contratados con el proveedor de servicio; pero econmicamente sigue siendo igual de costosa porque las compaas que prestan el servicio de interconexin Frame Relay cobran por PVC activado, as usen la misma solucin de ltimo kilmetro. Si se observa 31

bien, la mayora de escenarios de enlaces WAN corporativos tienen ms de dos nodos interconectados, por tanto habr al menos un nodo donde existan al menos dos PVCs compartiendo un ltimo kilmetro, esto sera por ejemplo, en la topologa de estrella. Si cambiamos a malla completa o parcial, el nmero de PVCs aumentar considerablemente y con ellos los costos de la solucin de transporte de datos. En la figura 3.5. se observa con ms detalle una solucin Frame Relay usando topologa de estrella.

Sitio 1
RED FRAME RELAY

Sitio 3 Una sola ltima milla Dos PVCs

Sitio 2

Figura 3.5. Detalle de 4 nodos en estrella con 2 PVCs

A parte del alto precio que tiene una solucin Frame Relay o Clear Channel, hay otros factores a tener en cuenta para decidir cambiar este tipo de tecnologas a una solucin usando VPNs, y son entre otras, la disponibilidad, la seguridad, la eficiencia en el manejo del ancho de banda y la amplia cobertura que ha logrado Internet. La ventaja que han sustentado los tradicionales enlaces dedicados es la disponibilidad, sin embargo, estos enlaces tambin son susceptibles de cadas, y su montaje, en cuanto a hardware se refiere, es tan complejo que es prcticamente imposible cambiar a otro proveedor mientras el enlace se

32

reestablece. Con un escenario LAN-to-LAN VPN, cuando un enlace a Internet de la ISP que le presta el servicio a la empresa que tiene montada la VPN se cae, la conmutacin a otro proveedor es prcticamente transparente para la empresa, ya que el enrutador de frontera de la ISP (que sirve de gateway de toda la red) se encarga de seleccionar otro enlace que se encuentra arriba.4 La figura 3.6 ilustra la conexin de tres oficinas de una misma compaa usando una arquitectura LAN-to-LAN VPN. Ntese que los tneles VPN que aparecen sealados no son enlaces fsicos sino lgicos que viajan por Internet. El nico equipo que tiene que adquirir la compaa para cada oficina a conectar es un gateway VPN que tiene, por lo general, un puerto LAN (Ethernet o Fast Ethernet) para conectarse a la LAN Corporativa, y un puerto LAN o WAN para conectarse hacia la ISP. Muchos de estos gateways VPN trabajan como firewalls y tiene un switch 10/100 incorporado de 4 u 8 puertos, debido a esto son llamados dispositivos Todo en Uno. Solo se necesita un ltimo kilmetro por oficina, por ah viajan todos los tneles VPN que se necesiten.

Intranet 1

Sn i fe Se rv r f r e
mo n t r g / n a l s i i o i n a y s

Sni f e r Se r rve
mo n t r n g a n l s i i o i / a y s

Intranet 2

Internet
Tneles VPN Gateways VPN
Sn i f e r Se rver
mo n t r n g a n l s i i o i / a y s

Intranet 3

Figura 3.6 Esquema de una solucin Intranet VPN (LAN-to-LAN VPN).

Para esto es necesario que el enrutador de frontera de la ISP que provee de Internet a la compaa que establece la VPN sea capaz de trabajar con protocolos de enrutamiento dinmicos como BGP o EIGRP, y que la ISP tambin cuente con enlaces de respaldo a Internet
4

33

Si el enlace hacia Internet de la compaa no es dedicado sino conmutado, el mecanismo para cambiar de proveedor es mucho ms sencillo, basta con configurar el gateway dial-up VPN con el nmero telefnico de otra ISP. Si se cuenta con un servicio de cable mdem o ADSL solo se necesita conectar el cable de la otra ISP al CPE. Con una arquitectura Intranet VPN (o LAN-to-LAN VPN) se puede lograr el mismo objetivo de interconectar dos o ms sitios de una red corporativa y a un costo mucho menor. La economa se ve reflejada tanto en equipos que se tienen que adquirir o arrendar para el montaje inicial de la topologa, como en cargos fijos que se tienen que pagar mes a mes. Hace solo 2 aos era costoso y poco practico usar la tecnologa de VPNs para implementar una solucin LAN-to-LAN corporativa. La cobertura de Internet crecia vertiginosamente pero acceder a esta gran red publica a velocidades superiores a los 128 kbit/s, seguia teniendo unos costos muy altos para medianas y pequeas compaias. Solo hasta finales del 2001 las tarifas de Internet disminuyeron tanto (La tabla 3.1 muestra la evolucin en precios de las tarifas a Internet en Colombia) que se presentaron dos fenmenos que propiciaron el auge de las VPNs a nivel global [REF3.1], y Colombia no fue la excepcin, y fueron, primero, que los ISPs pudieron aumentar sus enlaces nacionales, de capacidades Nx64 a NxE1, y segundo que los precios bajos hicieron que se pudiera ofrecer ms ancho de banda por menor o igual costo. Hoy en da no es difcil encontrar empresas que tienen enlaces a Internet de 512 kbit/s, ratas que hasta hace pocos aos eran reservadas solo para ISPs.

34

Ao 1999 2000 2001 2002 2003

E1 Clear Channel Nacional5 N.D. $5500.000 $4020.000 $3800.000 $3738.600

E1 Internet (reuso 1:1) U$11.0006 U$8.000 U$6.500 U$4.000 U$3.300


N.D. No disponible

Tabla 3.1 Cuadro comparativo costo E1 nacional y E1 Internet desde 1999 hasta la fecha. Fuente ETB-Datamundo.

Otro factor decisivo que ha hecho que las empresas comiencen a ver en las VPNs otra opcin para el montaje de sus redes WAN usando esta tecnologa es la aparicin de los NAPs (o Puntos de acceso a la Red), que son lugares donde varias redes autnomas de sitios cercanos se conectan para intercambiar trfico a alta velocidad, y as evitar que paquetes de informacin que se cruzan entre sitios en un mismo lugar geogrfico tengan que ir hasta otros pases o continentes, disminuyendo as los costos. En Colombia, el NAP ms grande que existe es el NAP de la CCIT (Cmara Colombiana de Informtica y Telecomunicaciones), tambin llamado NAP Colombia. La aparicin de este NAP hizo que el trfico que tena como origen y destino nuestro pas usara solo canales locales o nacionales, evitando as a las ISPs conectadas a este, tener que adquirir ms ancho de banda internacional. El NAP Colombia comenz a funcionar a finales del ao 2000. La figura 3.7 muestra el crecimiento del trfico que ha tenido el NAP Colombia, lo que sin duda alguna representa de manera directamente proporcional el crecimiento del uso de Internet en Colombia.

5 6

No incluye ltima milla, solo transporte nacional E1 va satlite, correspondiente a 2048 kbit/s de recepcin y 2048 kbit/s de transmisin

35

Figura 3.7 Trfico total consolidado mes a mes que se ha cruzado por el NAP Colombia desde Julio de 2001 hasta Abril de 2003. [Fuente: http://www.nap.com.co]

3.2.

ACCESO REMOTO VPN

Fue la primera aplicacin que se le dio a la emergente tecnologa de las VPNs. Consiste en usar cualquier RAS que preste servicio de conexin a Internet como punto de acceso a una red corporativa tambin conectada a Internet por medio de un gateway VPN. Esta solucin naci de la necesidad de poder acceder a la red corporativa desde cualquier ubicacin, incluso a nivel mundial. Con el Acceso Remoto VPN, los RAS corporativos quedaron olvidados, pues su mantenimiento era costoso y adems las conexiones que tenan que hacer los trabajadores de planta externa, como vendedores y personal de soporte tcnico, cuando

36

viajaban fuera de la ciudad, y ms aun, a otros pases eran demasiado costosas. El acceso remoto VPN se vio claramente impulsado por el auge de la Internet que ha hecho que prcticamente en todas partes del mundo se obtenga fcil acceso a la misma. Con el acceso remoto VPN un trabajador que se haya desplazado a otro pas, por ejemplo, y que quiere acceder a la base de datos de su compaa, o al correo interno, o a cualquier otro recurso de su red corporativa, solo tiene que conectarse a Internet con una simple llamada local a la ISP de la ciudad en la que se encuentre, y ejecutar su cliente de marcacin VPN. A partir de la versin Windows98, Microsoft incluy un cliente de marcacin VPN que funciona con el protocolo de entunelamiento PPTP.7 Todos los gateways VPN vienen con software VPN clientes para ser instalados en los distintos sistemas operativos presentes en el mercado. La figura 3.8 muestra la creacin de un tnel conmutado VPN usando un cliente PPTP instalado en el computador del trabajador remoto. Ntese que se realizan dos conexiones, una PPP a la ISP, y una PPTP al gateway VPN de la compaa que se encuentra conectado a Internet. La conexin PPP puede ser anloga o digital RDSI.

En el captulo 5, Tecnologas VPN, se tratar en detalle el protocolo de entunelamiento PPTP.

37

LAN Corporativa Enlace conmutado RAS en ISP

INTERNET
Gateway VPN

Trabajador Teleconmutado 1ra Marcacin - Enlace PPP 2da Marcacin - Tnel VPN (Tpicamente PPTP)

Figura 3.8 Escenario de Acceso remoto VPN.

Otra de las grandes ventajas del acceso remoto VPN sobre el tradicional acceso remoto es poder usar tecnologas de acceso de banda ancha como xDSL y cable mdem. Para una empresa seria costoso e inconveniente tener un concentrador xDSL en sus instalaciones para permitirle a sus trabajadores teleconmutados el acceso a su red. Mientras que las VPNs usan la infraestructura existente de los proveedores del mercado para accesar a gran velocidad a la red corporativa. El mejor intento de una empresa por tener su propia infraestructura de acceso tradicional (no VPN) sera montar un RAS con capacidad para recibir conexiones RDSI-BRI, es decir velocidades de 64 kbit/s o 128 kbit/s, adems si la llamada la origina un trabajador en otra ciudad o pas se tienen que sumar los cargos de esas llamadas. La figura 3.9 ilustra dos tipos de accesos remotos VPN, uno de banda ancha, donde el usuario remoto que crea el tnel tiene una conexin cable mdem (tambin aplica xDSL) hacia la ISP; y otro acceso por medio de un mdem anlogo comn, en este caso el usuario remoto podra estar en otra ciudad o incluso en otro pas.

38

Usuario Remoto

M i ac

Cable Mdem
TAL / DAT K TA ALK RS CS T RD T CD R D

Tneles Encriptados

INTERNET

Gateway VPN
Sniffer Se rver
m n t o i o r g / na ys s n a l i i

Usuario Remoto
d i g i t a l

Red Corporativa

Servidor de acceso remoto conmutado

Figura 3.9 Dos montajes tpicos de un acceso remoto VPN

3.3.

EXTRANET VPN

Las empresas necesitan intercambiar informacin y realizar transacciones no solamente entre sitios de su misma organizacin sino tambin con otras compaas. Por ejemplo, una empresa manufacturera quisiera permitirle a los computadores de sus distribuidores accesar a su sistema de control de inventarios. Tambin dicha empresa quisiera poder accesar a la base de datos de sus proveedores y poder ordenar fcil y automticamente cuando ellos necesiten materia prima. Hoy en da todas las empresas estn haciendo presencia en la Internet y esto hace casi imperativo la comunicacin con las otras empresas por este medio. Ciertamente con una arquitectura de Extranet VPNs cada empresa tiene que controlar muy meticulosamente el acceso a los recursos de su red corporativa

39

y a los datos que van a intercambiar con sus socios de negocios. Implementar una topologa Extranet VPN implica incrementar la complejidad de los sistemas de control de acceso y de autenticacin. Adicionalmente la tendencia de los mercados hacen que un cambio en la topologa se pueda realizar fcilmente, para esto una Extranet VPN debe poder adicionar y eliminar dinmicamente acceso seguro a otras compaas. Tal reconfiguracin dinmica es difcil cuando se cuenta con circuitos cerrados dedicados. La presencia de una compaa en Internet y el uso de la arquitectura de Extranet VPN, hace posible crear conexiones dinmicas seguras a otras redes sin necesidad de cambiar la infraestructura fsica. Ejemplos de conexiones dinmicas seguras y que son conocidos como Extranet VPNs se muestran en la figura 3.10

iM ac

Cliente accediendo a la compaa para realizar una compra

Tneles Encriptados

INTERNET

Gateway VPN
Sniffe Server r
m n t r n o i o i g / n a y s s a l i

Acceso para clientes

Acceso para proveedores

S ni f er S er ve r f
mo i o i g a a l i n t r n / n s y s

Red Corporativa de un proveedor de la compaa actualizando en disponibilidad de artculos

Red Corporativa de la compaa

Figura 3.10 Arquitectura Extranet VPN, clasificando el acceso segn privilegios de los clientes VPNs remotos

40

Al igual que en una arquitectura LAN to LAN VPN es necesario un gateway VPN que se instala en la frontera de la red corporativa. Los tneles son creados a travs de Internet entre este gateway y el gateway VPN situado en la red de la otra empresa. De otro modo un cliente VPN en un computador independiente podra accesar a la red corporativa como un cliente usando cualquier acceso remoto. En la actualidad la mayora de los gateways VPN pueden establecer mltiples tneles seguros a mltiples empresas. Sin embargo, es importante que una empresa no sea capaz de obtener acceso a la informacin de otra compaa que est accediendo por medio de Extranet VPNs. Un nivel ms de seguridad puede ser adicionado ubicando recursos exclusivos a cada una de las compaas que va a acceder a la red de inters en diferentes servidores.

3.4.

MODELOS DE ENTUNELAMIENTO

En las VPN los sitios de terminacin (terminadores) de los tneles son aquellos donde se toman las decisiones de autenticacin y las polticas de control de acceso y donde los servicios de seguridad son negociados y otorgados. En la prctica hay tres tipos posibles de servicios de seguridad que dependen de la ubicacin de los terminadores. El primer caso es aquel donde el terminador est en el host mismo, donde los datos se originan y terminan. En el segundo caso el terminador est en el gateway de la LAN corporativa donde todo el trfico converge en un solo enlace. El tercer caso es aquel donde el terminador est localizado fuera de la red corporativa, es decir en un Punto de Presencia (POP) de la ISP.

41

Dado que un tnel VPN se compone de dos terminadores, se pueden obtener seis tipos de modelos de seguridad derivados de la posible combinacin de las diferentes localizaciones: End-to-End, End-to-LAN, End-to-POP, LAN-toLAN, LAN-to-POP y POP-to-POP, en la figura 3.11 se notan cada uno de ellos.

Sitio 1 LAN
M i a c

Gateway VPN

Gateway VPN

Sitio 2 LAN
i Ma c

POP

POP

INTERNET

End-to-End End-to-LAN End-to-POP LAN-to-LAN POP-to-POP LAN-to-POP

Figura 3.11 Modelos de entunelamiento VPN

En el modelo End-to-End el tnel va desde un extremo hasta el otro del sistema. Por lo tanto, los servicios de seguridad son negociados y obtenidos en la fuente y en el destino de la comunicacin. Este escenario presenta el ms alto nivel de seguridad dado que los datos siempre estn seguros en todos los segmentos de la red, bien sea pblica o privada. Sin embargo, el total de tneles que pueden haber en una empresa grande, dificulta el manejo de los servicios de seguridad requeridos por dichos host. Este modelo de seguridad es comnmente visto en implementaciones de capas superiores, como es el caso de SSL (Secure Sockets Layer). Tales implementaciones no son consideradas como modelos de entunelamiento. En el modelo End-to-LAN, el tnel comienza en un host y termina en el permetro de una LAN en la cual reside el host destino. Un dispositivo VPN 42

localizado en el permetro de la red es el responsable de la negociacin y obtencin de los servicios de seguridad de los host remotos. De esta manera, la seguridad de un gran nmero de dispositivos en una red corporativa puede ser manejada en un nico punto, facilitando as la escalabilidad del mismo. Dado que la red corporativa es considerada un sitio seguro, comnmente no hay necesidad de encriptar la informacin que transita dentro de ella. La mayora de implementaciones de acceso remoto VPN trabajan con este modelo. El modelo de entunelamiento End-to-POP es aquel en el cual un host remoto termina el tnel en un POP de la ISP. Un dispositivo VPN o un equipo con funciones de terminador VPN y que se encuentra en la red de la ISP es el responsable por la negociacin y concesin de los servicios de seguridad. La entrega de los datos desde el POP hasta el host destino es por lo general asegurada con infraestructura fsica, la cual separa el trfico del resto de la red pblica. Por lo general en este caso el ISP administra los permisos y controla el acceso segn las directivas de los administradores de red de las empresas clientes. La arquitectura de acceso remoto VPN tambin usa este modelo. En el modelo LAN-to-LAN ambos hosts usan dispositivos VPNs situados en la frontera de la red corporativa para negociar y conceder servicios de seguridad. De esta manera, las funciones de seguridad no necesitan ser implementadas en los hosts finales donde los datos son generados y recibidos. La implementacin de los servicios de seguridad es completamente transparente para los hosts. Esta implementacin reduce drsticamente la complejidad en el manejo de las polticas de seguridad. La arquitectura Intranet VPN encaja en este modelo.

43

En el caso de LAN-to-POP el tnel comienza en un dispositivo VPN localizado en la frontera de la red corporativa y termina en un dispositivo VPN el cual se encuentra en un POP de la ISP. En la actualidad prcticamente este modelo de entunelamiento no es aplicado. Finalmente, en el modelo POP-to-POP ambos dispositivos VPN son localizados en la propia red de la ISP. Por lo tanto los servicios de seguridad son completamente transparentes para los usuarios finales del tnel. Este modelo permite a los proveedores de servicio implementar valores agregados a los clientes sin que stos alteren la infraestructura de sus redes. De los seis modelos anteriores el End-to-LAN y el LAN-to-LAN son los ms extensamente usados en las soluciones VPN. Sin embargo, el POP-to-POP o modelo de seguridad basado en red, ha cobrado vigencia ltimamente dado que permite a las ISPs implementar servicios de valores agregados para sus clientes.

REFERENCIAS: [REF3.1] Revista Network Magazine, Artculo Internet-based VPNs: Business or Cattle Class?, Pag. 54, Julio de 2002.

44

4.

AUTENTICACIN Y CIFRADO

4.1.AUTENTICACIN
La autenticacin es el acto de verificar la identidad de alguien o algo en un contexto definido. En un mundo de seis billones de personas no es suficiente simplemente declarar que se es quien se dice ser, se debe probarlo. La autenticacin involucra usualmente la interaccin entre dos entidades: el objeto de la autenticacin (un usuario o un cliente) que afirma su identidad y un autenticador realizando la verificacin de la identidad. El usuario entrega informacin de autenticacin la cual incluye la identidad proclamada y la informacin que soporta dicha identidad al autenticador. En la labor de verificacin, el autenticador aplica una funcin de autenticacin F que le entrega informacin y luego compara el resultado de esta operacin con el resultado esperado. Si el resultado de la funcin F concuerda con el resultado esperado, la identidad del usuario se considera verificada. La informacin de autenticacin puede ir desde un simple password a un juego completo de parmetros y mensajes. De igual manera, la funcin F puede ser una simple funcin como en el caso de la comparacin de claves, o la aplicacin de complejos algoritmos criptogrficos, como en el caso de firmas digitales.

45

Si la informacin de autenticacin y la funcin de autenticacin F estn totalmente bajo el control de las dos entidades, el esquema de autenticacin es llamado Esquema de Autenticacin Compartido (two-party). Sin embargo, en muchos casos es ms seguro y escalable ayudarse de una tercera parte (o de ms) para la autenticacin. Esos esquemas son llamados de confianza en terceras partes (trusted third-party). Otro factor a tener en cuenta es la integridad y confidencialidad de la informacin de autenticacin. Es importante que la informacin usada para la autenticacin sea segura y no sea obtenida de participantes no autorizados. Esas medidas de seguridad no solo deben ser tomadas en el establecimiento del tnel, sino durante el transcurso del intercambio de datos. En el caso de las VPNs esto es muy importante ya que la informacin de autenticacin es transmitida a travs de Internet.

4.1.1. LAS AMENAZAS DE SEGURIDAD EN LAS REDES DE DATOS En ambientes de redes la seguridad de los datos y las comunicaciones dependen de tres cosas: Autenticacin, Confidencialidad e Integridad de Datos. La Autenticacin significa que la persona o entidad con la cual se est comunicando es realmente quien dice ser. La Confidencialidad es asegurarse que alguien no autorizado pueda escuchar las comunicaciones, es decir, que nadie pueda entender los datos que han sido interceptados. De igual manera, la garantizacin de la integridad de los datos significa que ningn dato ha sido alterado en ninguna parte de la transmisin. Desafortunadamente, el conjunto de protocolos TCP/IP no fueron diseados originalmente para brindar seguridad a los datos. A

46

continuacin se describirn las amenazas de seguridad ms comunes en redes pblicas como Internet. 4.1.1.1.Spoofing Las redes IP usan direcciones numricas para cada dispositivo conectado a la misma. Las direcciones del host fuente y destino son incluidas en cada paquete trasmitido en una red IP, spoofing aprovecha este hecho y as un intruso puede usar alguna de esas direcciones IP y pretender ser el destinatario. Despus de que un intruso identifica una pareja de computadores, A y B por ejemplo, que estn comunicndose uno con el otro como en una topologa cliente servidor, intenta establecer una conexin con el computador B de tal forma que B cree que est en una conexin con A, cuando en realidad la conexin se ha establecido con el computador del intruso. El establecimiento de una conexin entre A y B implica un intercambio de mensajes de control, en estos mensajes de control tanto A como B envan sus direcciones de origen. Cuando A recibe un mensaje de B, B tiene que responder con un mensaje de reconocimiento el cual incluye una secuencia de nmeros para garantizar el correcto orden en el recibo de los paquetes. Esas secuencias de nmeros son nicas entre las dos mquinas. Para completar la configuracin de la seccin entre A y B, B esperara de A un reconocimiento en la secuencia de nmeros de B antes de proceder con cualquier tipo de intercambio de operacin. Pero para que un atacante se haga pasar como A el tendra que detectar la 47

secuencia de nmeros que B usar. Sabiendo lo anterior, no es muy difcil identificar las secuencias de nmeros en una conexin entre dos hosts. De esta manera un atacante podra hacerse pasar como cualquiera de los dos hosts y as poder ganar privilegios no autorizados 4.1.1.2.Hijacking Hijacking es una amenaza de seguridad que se vale del spoofing, pero sta consiste en tomar una conexin existente entre dos computadores. El primer paso en este tipo de ataques es tomar el control de un dispositivo de red LAN como un firewall que pueda monitorear la conexin. Una vez monitoreando el enlace, el atacante puede determinar la secuencia de nmeros usadas por ambas partes. Despus de hecho esto, el atacante puede generar trfico que parezca venir de una de las partes envueltas en la comunicacin, robando la sesin de los individuos envueltos. Como en spoofing, el atacante podra sobrecargar uno de los dos computadores con exceso de paquetes que haga que la sesin se caiga. El hecho que un host haya identificado la persona con la cual se est comunicando no podra asegurar que desde ese mismo IP est el host autntico durante el resto de la sesin. Para esto se necesita de un esquema que autentique los datos durante toda la transmisin. Pero de igual forma, usando el mtodo de autenticacin ms poderoso no podramos prevenir 100% ataques por hijacking; en realidad la nica defensa contra tales ataques es la implementacin de mecanismos de encriptacin.

48

4.1.1.3.Sniffing Sniffing es un ataque que es posible hacer en redes donde el medio es compartido, tales como redes ethernet, donde generalmente, los paquetes estn disponibles para todos los nodos en la red. Lo normal es que cada NIC (Tarjeta de interfaz de Red) solamente escuche y responda los paquetes que van direccionados especficamente para este. Sin embargo, es relativamente fcil colocar una NIC en modo promiscuo, es decir, que ellas pueden recolectar cada paquete que pasa por el cable. Estas NIC en modo promiscuo, no pueden ser detectadas por algn otro computador en la red, porque cuando escuchan paquetes no cambian absolutamente nada en ellos, simplemente los guardan. Un tipo de software llamado sniffer puede aprovecharse de esta caracterstica de la tecnologa ethernet. Tal herramienta puede grabar todo el trfico que pasa por el nodo. Los sniffer son necesarios para diagnosticar problemas en redes ethernet. Sin embargo, en manos de alguien que quiera escuchar comunicaciones privadas, un sniffer es una poderosa herramienta de olfateo. Por ejemplo, un atacante podra usar un sniffer para grabar todos los paquetes que contienen nombres de usuarios y claves en una red y luego usar esa informacin para entrar a sistemas para los cuales l no est autorizado a acceder. Otro de los malos usos que se le puede dar a un sniffer es el de coleccionar datos y mensajes de una compaa para poder as identificar quien se comunica con quien, qu se est comunicado y poder usar esta informacin en labores de espionaje corporativos.

49

Encriptar datos es una forma de proteger contra sniffing, aunque el atacante podra tener los recursos para guardar los datos encriptados y luego tratar de descifrarlos cuando est desconectado. La inspeccin fsica de las redes es una buena forma de reducir los riesgos de sniffing. En algunos computadores como aquellos que corren sistema operativo Linux se puede chequear fcilmente si una NIC est en modo promiscuo. 4.1.1.4.Ataque del Hombre-en-la-Mitad Aunque se ha dicho que usar tecnologas de cifrado y autenticacin previenen en cierta medida de las amenazas en una red IP, el cifrado no es una solucin del todo confiable. Los ataques de el hombre-en-lamitad son tendientes a burlar los sistemas de cifrado. Para cifrar se debe primero intercambiar las llaves de cifrado. Pero es conveniente intercambiar dichas llaves con ciertas precauciones. Un intruso podra emplear tcnicas de spoofing, hijacking y sniffing para capturar las llaves de cifrado que se intercambian en un sistema. El podra introducir su propia llave anticipadamente en el proceso y la otra persona podra creer que se est comunicando con la llave de la otra parte cuando en realidad esa llave es la conocida por el invasor. Este ataque es conocido como el-hombre-en-la-mitad.

50

4.1.2. SISTEMAS DE AUTENTICACIN La autenticacin es parte vital dentro de la estructura de seguridad de una VPN. Sin ella no se podra controlar el acceso a los recursos de la red corporativa y mantener a los usuarios no autorizados fuera de la lnea. Los sistemas de autenticacin pueden estar basados en uno de los siguientes tres atributos: algo que el usuario tiene (por ejemplo la llave de una puerta); algo que el usuario sabe (por ejemplo una clave); algo que el usuario es (por ejemplo sistemas de reconocimiento de voz barrido de retinas). Es generalmente aceptado el uso de un mtodo sencillo de autenticacin tal como el password, pero no es adecuado para proteger sistemas. Los expertos recomiendan los llamados sistemas de autenticacin complejos, los cuales usan al menos dos de los atributos de autenticacin anteriores. A continuacin trataremos los sistemas de autenticacin ms comnmente usados en los ambientes de redes: passwords tradicionales, passwords nicos, PAP, CHAP y Radius. 4.1.2.1.Passwords Tradicionales Son la forma ms simple de autenticar pero es un mtodo inadecuado para garantizar la seguridad en el acceso a una red, dado que los passwords pueden ser adivinados e interceptados durante transmisiones en la red. Por ejemplo, servicios tales como FTP y Telnet transmiten los nombres y las claves en texto plano, hacindolos fcilmente interceptables.

51

4.1.2.2.Passwords nicos Una forma de prevenir el uso no autorizado de Passwords interceptados es evitar que sean reutilizados. Los sistemas de Passwords nicos restringen el uso de un password a una sola sesin de comunicacin, es decir que se requiere un password nuevo para cada nueva sesin. Estos sistemas, de los cuales S/KEY es el mejor ejemplo, facilitan al usuario la escogencia de un nuevo password para la siguiente sesin generando automticamente una lista de posibles passwords para el usuario8. S/KEY [REF4.1] usa un password secreto encriptado generado por el usuario, para crear la secuencia de passwords nicos. El password del usuario nunca atraviesa la red, por lo tanto dicho password no es sujeto de ataques. Con esto se logra que los passwords nicos que son generados por esta clave y que pudieron ser interceptados para luego ser utilizados no le sirvan al atacante. El primer password nico es producido aplicando al mensaje original una funcin HASH n veces, donde n es un nmero especificado por el usuario. El siguiente password nico es generado aplicando al mensaje original la misma funcin HASH n-1 veces y as sucesivamente hasta generar n passwords nicos. Cuando un usuario intenta entrar a la red el servidor de red en el cual est habilitado el S/KEY genera una respuesta que consiste de un nmero y una cadena de caracteres, la cual es llamada seed.

La IETF ha logrado estandarizar el S/KEY, las especificaciones para este sistema se pueden ver en la RFC 2289.
8

52

En respuesta al mensaje enviado por el servidor de red el usuario usa el nmero y el seed que le ha llegado ms su propio password secreto en un software generador S/KEY que corre en su computador. Este software se encarga de combinar los tres elementos y de iterarlos tantas veces como el nmero que le ha llegado en el mensaje de respuesta del servidor. El password nico resultante es enviado al servidor de autenticacin el cual tambin lo itera tantas veces como el se lo haya indicado al cliente en funciones HASH, luego lo compara con el password nico que tena almacenado. Si hay una concordancia entre los mismos al usuario se le permite el ingreso a la red, una vez esto pasa el nmero n es decrementado y el siguiente password nico es guardado para el siguiente intento de ingreso. Los sistemas de passwords nicos como el S/KEY requieren que el software del servidor sea modificado para realizar los clculos requeridos y que cada computador remoto tenga una copia de un software cliente. Estos sistemas no son muy escalables dado que se dificulta administrar listas de passwords para un gran nmero de usuarios. 4.1.2.3.PAP (Password Authentication Protocol) PAP [REF4.2] o Protocolo de Autenticacin de Passwords fue diseado originalmente como una manera sencilla para que un computador se autenticara en otro cuando los mismos usan un protocolo de comunicacin punto a punto como PPP. PAP es un protocolo de dos vas, el host que se est conectando enva un nombre de usuario y un password al sistema destino con el cual trata de establecer su 53

comunicacin, y el sistema destino (el autenticador) responde si es el caso, que el computador remoto est autenticado y aprueba su comunicacin. PAP es un protocolo de autenticacin que puede ser usado al comienzo del establecimiento de un enlace PPP, o bien durante el transcurso de la sesin PPP para reautenticar el enlace. PAP no es seguro porque la informacin de autenticacin es transmitida en texto plano, esto hace vulnerable a que atacantes obtengan informacin de nombres de usuario y claves de manera fcil. 4.1.2.4.CHAP (Challenge Handshake Authentication Protocol) CHAP [REF4.3] es muy similar a PAP pero es ms seguro para autenticar enlaces PPP. CHAP es un protocolo de tres vas y al igual que PAP, puede ser usado al comienzo de un enlace PPP y ser repetido cuando el enlace ya se haya establecido. CHAP incorpora tres pasos para la autenticacin de un enlace, que son: 1. El autenticador enva un mensaje al nodo remoto. 2. El nodo calcula un valor usando una funcin HASH y lo enva de regreso al autenticador. 3. El autenticador avala la conexin si la respuesta concuerda con el valor esperado.

54

El proceso puede repetirse en cualquier momento del enlace PPP para asegurarse que la conexin no ha sido tomada por otro nodo. A diferencia de PAP, en CHAP el servidor controla la reautenticacin. PAP y CHAP tienen algunas desventajas, en ninguno de los dos se pueden asignar diferentes privilegios para acceder a la red a diferentes usuarios remotos que usan el mismo computador. El siguiente protocolo (Radius) entrega ms flexibilidad para asignar privilegios de acceso. 4.1.2.5.RADIUS (Remote Authentication Dial-In User Service) RADIUS [REF4.4] fue desarrollado por Livingston Enterprise, ahora una divisin de Lucent Technologies. RADIUS usa una arquitectura cliente servidor e incluye dos componentes: un servidor de autenticacin y un protocolo cliente. El servidor es instalado en un computador central, el protocolo cliente es implementado en el servidor de acceso a la red (NAS). El proceso de autenticacin con RADIUS tiene los siguientes pasos: 1. Un usuario remoto marca a un RAS. Cuando la conexin al modem se completa, el RAS pregunta por un nombre de usuario y password. 2. Una vez recibido el nombre de usuario y el password, el RAS crea un paquete de datos llamado requerimiento de autenticacin. Este paquete incluye informacin tales como el nombre del usuario, el password, el modem de conexin, entre otros. Para evitar que un hacker escuche la informacin, el RAS acta como un cliente del

55

RADIUS,

cifrando

el

mensaje

con

una

clave

compartida

predeterminada entre el RAS y el servidor RADIUS. 3. El requerimiento de autenticacin es enviado por la red desde el cliente hasta el servidor RADIUS. Esta comunicacin puede ser hecha sobre una red de rea local o global. Si el servidor RADIUS no puede ser alcanzado, el cliente RADIUS puede rutear el requerimiento a un servidor alternativo. 4. Cuando un requerimiento de autenticacin es recibido, el servidor RADIUS valida el requerimiento y verifica la informacin del nombre de usuario y password. Esta informacin tambin puede ser transmitida a un sistema de seguridad apropiado que soporte los archivos de autenticacin, por lo general bases de datos. 5. Si el nombre de usuario y el password son correctos, el servidor enva un reconocimiento de autenticacin que puede incluir informacin del usuario en la red y los servicios que el requiere. Por ejemplo, el RADIUS le puede decir al NAS que el usuario requiere una direccin IP esttica o que obtiene su direccin IP de un rango dinmico de direcciones, tambin puede contener informacin sobre los filtros que pueden limitar al usuario a accesar ciertos recursos especficos de la red como por ejemplo el uso de un servidor proxy. 6. Si en este punto del proceso la autenticacin no se tiene xito, el RADIUS enva un mensaje de desconexin al RAS y al usuario se le niega el acceso a la red. RADIUS tambin puede emplear una arquitectura distribuida en el evento en que el NAS deba soportar autenticacin para mltiples dominios, para esto el RADIUS se configura en modo proxy. Esta funcin permite a las diferentes ISPs hacer roaming con sus similares, para esto el usuario que necesite hacer roaming escribe su nombre de 56

usuario en el formato nombredeusuario@sudominio.com de esta manera el servidor RADIUS de la ISP enva el requerimiento hacia el servidor RADIUS de la ISP remota para que ste ejerza las labores de autenticacin. De la misma manera que un RAS y un servidor RADIUS usan claves compartidas, dos servidores RADIUS en modo proxy usan otra clave compartida para proteger la comunicacin entre ellos. La figura 4.1 muestra un esquema de RADIUS en modo proxy, muy utilizado para hacer roaming entre distintas ISPs.

Servidor Radius actuando como proxy

Servidor Radius del usuario rem oto Servidor de acceso rem oto

INTERNET

Usuario Conexin conm utada

Figura 4.1 Autenticacin RADIUS usando un servidor proxy.

4.2.CIFRADO
En una tarea de cifrado, el emisor y el receptor, deben conocer el conjunto de reglas que rigen el mecanismo como tal. Las llaves son usadas para transformar la informacin original en una resultante llamada texto cifrado.

57

Como ambas partes conocen el cifrado, cualquiera de ellas puede reversar el proceso para abstraer el texto original. El cifrado se basa en dos componentes: un algoritmo y una llave. Un algoritmo criptogrfico es una funcin matemtica que combina texto plano o cualquier otra informacin inteligible con una cadena de dgitos llamada key (llave) para producir un texto cifrado o no inteligible. Tanto la llave como el algoritmo son cruciales en un proceso de cifrado. El cifrado basado en un sistema de llaves ofrece una gran ventaja, los algoritmos criptogrficos son difciles de idear por lo cual sera traumtico usar un nuevo algoritmo cada vez que una parte se quiera comunicar de manera privada con una nueva. Usando una llave, un usuario podra utilizar el mismo algoritmo para comunicarse con diferentes usuarios remotos; y todo lo que se debera hacer sera utilizar una diferente llave con cada uno de ellos. El nmero de llaves posibles que tiene cada algoritmo depende del nmero de bits de la llave. El nmero de posibles llaves viene dado por la frmula 2n, donde n es el nmero de bits de la llave. Por ejemplo, una llave de 64 bits permite 264 posibles combinaciones numricas o llaves. Es decir, 18446.744073.709551.616 claves. El gran nmero de posibles claves dificulta los ataques de fuerza bruta en donde se examinan todas las posibles combinaciones. Por lo tanto la fortaleza del cifrado depende de la longitud de la llave. En la tabla de la figura 4.2. se comparan el tiempo y el dinero necesario para romper claves originadas con llaves de 40, 56, 64, 80 y 128 bits de longitud. Para obtener estos resultados se calculo el costo de construir un sistema de computacin en 1995, y el tiempo que tomaria ese sistema en romper cada llave de diferente longitud. [REF4.5]. 58

Inversin (en dlares) $ 100 mil $ 1 millon $ 100 millones $ 1 billon $100 billones

40 2s 0.2 s 2 ms 0.2 ms 2 s

Longitud de la llave (en bits) 56 64 80 35 h 3.5 h 2m 13 s 0.1 s 1 ao 37 das 9h 1h 32 s 70.000 aos 7.000 aos 70 aos 7 aos 24 das

128 1019 aos 1018 aos 1016 aos 1015 aos 1013 aos

Tabla 4.1 Comparacin de tiempo y dinero necesarios para romper llaves de diferente longitud

El sistema basado en llaves es llamado de llaves secretas o cifrado simtrico. En este esquema tanto el emisor como el receptor poseen la misma llave para encriptar o desencriptar los datos. Pero con el tiempo el cifrado simtrico present algunos problemas, por ejemplo: ambas partes deberan de estar de acuerdo para usar la misma llave. Otro problema es que si una parte tena n receptores, entonces debera guardar registro de n llaves secretas, una por cada uno de los receptores. Otro gran problema del esquema de cifrado simtrico es con la autenticacin, dado que la identidad del emisor que envia el mensaje al emisor no puede ser probada. Esto se debe a que tanto el emisor como el receptor poseen la misma llave, es decir, cualquiera de ellos puede crear y encriptar un mensaje y decir que la otra persona se lo envi. La manera de resolver este inconveniente es usando un esquema llamado criptografa de llaves pblicas, el cual hace uso de algoritmos de cifrado asimtricos. 4.2.1. CRIPTOGRAFA DE LLAVES PBLICAS La criptografa de llaves pblicas se basa en el manejo de una pareja de llaves. Cada llave puede encriptar informacin que slo la otra puede desencriptar. La llave privada, nicamente es conocida por su propietario; la llave pblica, se pblica abiertamente, pero sigue asociada al

59

propietario. Los pares de llaves tienen una caracterstica nica: los datos encriptados con una llave slo pueden desencriptarse con la otra llave del par. En otras palabras, no tiene importancia que se use la llave privada o la pblica para encriptar un mensaje, ya que el receptor puede usar la otra llave para desencriptarlo. Las llaves se pueden usar de dos maneras diferentes: para garantizar confidencialidad al mensaje y para probar la autenticidad del emisor de un mensaje. En el primer caso, el emisor usa la llave pblica del receptor para encriptar un mensaje, de manera que el mensaje contine siendo confidencial hasta que sea decodificado por el receptor con la llave privada. En el segundo caso, el emisor encripta un mensaje usando la llave privada, una llave a la cual slo tiene acceso l. La llave pblica del receptor asegura la confidencialidad; la llave privada del emisor verifica la identidad del mismo. Por ejemplo, para crear un mensaje confidencial, una persona necesita conocer primero la llave pblica de su receptor, despus deber usar la misma para encriptar el mensaje y enviarlo. Como el mensaje se encript con la llave pblica del receptor, slo ste con su llave privada puede desencriptar el mensaje. Aunque una persona puede encriptar un mensaje con una llave pblica o con una llave secreta, usar la llave pblica presenta ciertas ventajas. Por ejemplo, la llave pblica de la pareja de llaves se puede distribuir en un servidor sin temor de que esto comprometa el uso de la llave privada. Por ello, no se necesita enviar una copia de la llave pblica a todos los receptores; ya que ellos la pueden obtener desde un servidor de llaves mantenido por la compaa, o a travs de un proveedor de servicio. La 60

figura 4.2 muestra el esquema con el cual un emisor encripta su mensaje por medio de la llave pblica del destinatario y como este ltimo con su llave privada desencripta el mensaje cifrado que le ha llegado.
Llave pblica del destinatario Encriptacin

asdhgdh xcb c zc as dhgd xc b cxnm cn c zc asdhgdh xc b cxnmcnm z xcn c zc asdhgdh xcb c c nm zxc n cz c as

000 1010 0 0001010 00001 01010 0010 000 1110101 01010 010101 010100111 000 1010 0 010 0111100

Mensaje Original (Texto plano) INTERNET

Mensaje encriptado (Texto cifrado)

000 1010 0 0001010 00001 01010 0010 000 1110101 01010 010101 010100111 000 1010 0 010 0111100

Llave privada del destinatario

Desencriptacin

as dhgdh xcb cz c as dhgd xcb cxnm cn cz c asdhgdh xcb cxnmc nm zxc n c zc as dhgdh xcb c cnm zxc n cz c as

Mensaje encriptado (Texto cifrado)

Mensaje Original (Texto plano)

Figura 4.2 Esquema de cifrado con llaves pblicas

Colocar una llave pblica en una red la vuelve fcilmente accesible, y no se pone en peligro la llave privada correspondiente. Otra ventaja de la criptografa con llave pblica es que permite que el receptor autentifique al originador del mensaje. La idea bsica es esta: ya que el emisor es la nica persona que puede encriptar algo con su llave privada, todo aquel que use la llave pblica del mismo para desencriptar el mensaje, puede estar seguro de que el mensaje proviene de l. As, el uso de su llave privada en un documento electrnico es similar a la firma en un documento de papel. Pero hay que recordar que aunque el receptor puede estar seguro de que el mensaje proviene del emisor, no hay forma de garantizar que alguien ms lo haya ledo con anterioridad.

61

Usar algoritmos criptogrficos de llaves pblicas para encriptar mensajes es computacionalmente lento, as que se ha descubierto una manera para generar con rapidez una representacin corta y nica del mensaje, llamada "resumen" (message digest), que se puede encriptar y despus usar como firma digital. Algunos algoritmos criptogrficos populares y veloces para generar resmenes se conocen como funciones de dispersin (hash) de un solo sentido. Una funcin de dispersin (hash) de un solo sentido no usa una llave; simplemente es una frmula para convertir un mensaje de cualquier longitud en una sola cadena de dgitos, llamada "resumen". Cuando se usa una funcin de dispersin (hash) de 16 bits, el texto procesado con dicha funcin producira 16 bits de salida (un mensaje podra dar como resultado la cadena CBBV235ndsAG3D67, por ejemplo). Cada mensaje produce un resumen de mensaje al azar. Para obtener una firma digital solo basta con encriptar dicho resumen con su llave privada. Por ejemplo, suponiendo que el emisor, A, calcula un resumen para un mensaje, y encripta dicho resumen con su llave privada, luego enva esa firma digital junto con un mensaje de texto simple a B. Despus de que B usa la llave pblica de A para desencriptar la firma digital, B tiene una copia del resumen del mensaje que A calcul. Dado que B pudo desencriptar la firma digital con la llave pblica de A, sabe que A lo cre, autentificando as al originador. B usa entonces la misma funcin de dispersin (que se acord de antemano) para calcular su propio resumen del mensaje de texto simple de A. Si su valor calculado y el que A envi son iguales, entonces B puede estar seguro de que la firma

62

digital es autntica, lo que significa que A no slo envi el mensaje, sino que el mensaje no fue alterado.

4.2.2. DOS ALGORITMOS IMPORTANTES DE LLAVES PBLICAS Existe un amplia variedad de algoritmos criptogrficos para llaves pblicas, pero quiz dos de los msimportantes han sido: Diffie-Hellman y RSA. 4.2.2.1.Diffie-Hellman El protocolo Diffie-Hellman [REF4.6], tambin llamado (protocolo de acuerdo de llaves exponenciales) fue desarrollado por Whitfield Diffie y Martin Hellman en 1976 y publicado en el magazn Nuevas directrices en Criptografa (aunque se tienen evidencias de haber sido previamente inventado por Malcom Williamson en 1974). El protocolo Diffie-Hellman permite a dos usuarios intercambiar una llave secreta sobre un medio inseguro sin tener acuerdos preestablecidos. Diffie-Hellman no se usa para encriptar datos, como se piensa generalmente. Se usa para intercambiar de forma segura las llaves que encriptan los datos. Esto lo logra generando un secreto compartido, tambin llamado llave de cifrado de la llave (key encryption key en ingls) entre las dos partes. Este secreto compartido luego encripta la llave simtrica (usando DES, 3DES, CAST, IDEA, Blowfish, etc.) que asegura la transmisin.

63

Los sistemas de llaves asimtricas (la base de la infraestructura de llaves pblicas) usan dos llaves la llave privada y la llave pblica-, desafortunadamente estos sistemas tornan lenta la transmisin de datos. Lo prctico hoy en da, es usar un sistema simtrico para encriptar los datos y un sistema asimtrico para cifrar las llaves a usar en el proceso de cifrado de los datos. Inicialmente, cada lado de la comunicacin tiene su llave privada y la llave pblica del otro lado. Diffie-Hellman tiene la capacidad de generar llaves compartidas idnticamente iguales en ambos lados de la comunicacin con la llave privada local y la llave pblica del lado remoto. As trabaja el criptosistema de intercambio de llaves Diffie-Hellman: 1. Se tienen dos parmetros pblicos q y p, tal que ambos son primos y p<q 2. Dos partes quieren iniciar el cifrado de sus datos, y por lo tanto necesitan tener primero un secreto compartido, las dos partes son A y B. 3. A genera una llave privada Xa, tal que Xa es un valor aleatorio, menor que q. 4. B genera una llave privada Xb, tal que Xb es un valor aleatorio, menor que q. 5. A genera su llave pblica, Ya, a partir de su llave privada Xa, con la siguiente frmula: Ya = pXa mod q

64

6. De igual manera, B genera su llave pblica, Yb, a partir de su llave privada Xb, con la siguiente frmula: Yb = pXb mod q 7. A y B intercambian sus llaves pblicas, Ya y Yb, entre s. 8. Con Yb en su poder, A est en capacidad de calcular el secreto compartido K, con la siguiente frmula: K = (Yb)Xa mod q 9. De igual manera, B puede calcular K, con Ya en su poder: K = (Ya)Xb mod q Observar el siguiente ejemplo: Carlos y Julin, necesitan un secreto compartido para iniciar su sesin de comunicacin encriptada usando un sistema asimtrico. Los valores iniciales son: q = 11 y p =5 Carlos escoge su llave privada Xc = 9 Julin escoge su llave privada Xj = 3 Carlos calcula su llave pblica Yc = pXc mod q Yc = 59 mod 11 = 9 Julin calcula su llave pblica Yj = pXj mod q Yj = 53 mod 11 = 4 Carlos le enva su llave pblica Yc a Julin, y Julin le enva su llave pblica Yj a Carlos. Ahora, Carlos calcula el secreto compartido K = (Yj)Xc mod q 65

K = 49 mod 11 K=3 Y Julin calcula el secreto compartido K = (Yc)Xj mod q K = 93 mod 11 K=3 Por tanto el secreto compartido es K = 3. Una vez, cada lado de la comunicacin tiene su secreto compartido idntico al remoto, se inicia un proceso de cifrado de datos simtrico que es mucho ms liviano que un mecanismo asimtrico, por tanto no disminuye sensitivamente la velocidad del enlace. Algunos algoritmos de cifrado simtricos son DES, 3DES, IDEA, CAST y Blowfish. Se tiene que hacer especial nfasis en el hecho que la llave compartida nunca se trasmite de un lado a otro, lo cual es muy importante. El intercambio de llaves usando Diffie-Hellman es vulnerable a ataques tipo El-hombre-en-la-mitad ya que el intruso podra interceptar la comunicacin, hacerse pasar por el lado remoto y enviarle al emisor su llave pblica hacindose pasar por el receptor. La solucin para evitar este problema es usar firmas digitales que aseguren que la persona con la cual se est estableciendo la comunicacin es efectivamente quien dice ser. 4.2.2.2.RSA RSA [REF4.7] es un sistema de cifrado de llaves pblicas que se usa tanto para cifrado de datos como para autenticacin de llaves pblicas. Fue inventado por Ronald Rivest, Adi Shamir y Leonard Adleman en 1977. De las iniciales del apellido de sus creadores RSA tom su nombre.

66

El algoritmo RSA trabaja de la siguiente manera: 1. Se toman dos nmeros primos de gran tamao, a los que se les llama p y q. 2. Se calcula su producto n=p*q y se le denomina mdulo. 3. Se escoge un nmero e, menor que n, y relativamente primo al producto (p-1)*(q-1). Este valor es llamado el exponente pblico. 4. Se encuentra otro nmero d tal que (ed-1) es divisible por (p-1)* (q-1). Este valor es llamado el exponente privado. 5. La llave pblica la conforman la pareja (n,e) 6. La llave privada la conformand la pareja (n,d). Los factores p y q pueden ser destruidos o guardados junto con la llave privada. 7. Una vez obtenidas las dos llaves se usan las siguientes frmulas para encriptar y desencriptar el mensaje original: Para encriptar: c = me mod n donde c es el mensaje encriptado y m el mensaje original. Para desencriptar: m = cd mod n

La dificultad para poder obtener la llave privada a partir de la pareja (n,e) radica en el tamao tan grande de los nmeros primos p y q, que en la actualidad son del orden de los 512 a 1024 bits de tamao. Cuanto ms grande se escojan estos nmeros mayor ser el tiempo que se tome un intruso en calcular las llaves privadas de las partes que se comunican.

67

Observar el siguiente ejemplo: Se escogen dos nmeros primos9, p=5 y q=11. Se calcula el mdulo n = p*q = 5*11 = 55. Se calcula e, tal que: a) e<n y, b) Relativamente primo10 a (p-1)*(q-1) = (5-1)*(11-1) = 4*10 = 40 Se escoge e=3, y se cumple que 3 es menor que n=55 y relativamente primo a 40. Se escoge d que cumpla con las condiciones dadas anteriormente es decir que ed-1 sea divisible por (p-1)*(q-1), para esto podemos aplicar la frmula: e*d mod [(p-1)*(q-1)] = 1 Se escoge entonces d=27, ya que: 3*27 mod [(5-1)*(11-1)]= 81 mod [(4)*(10)]= 81 mod [40]= 1 De lo anterior se concluye que la llave pblica, es decir el par (n,e) = (55,3) y la llave privada es el par (n,d) = (55,27). Ahora, asmase que A quiere enviar el mensaje 25 a B, para lo cual usa el par de la llave pblica y la frmula de cifrado dada anteriormente: c = me mod n c = 253 mod 55 = 5 c =5, es el nmero que se enva por el medio inseguro.

Para propsitos ilustrativos, se han escogido dos nmeros primos bastante pequeos. En la realidad estos nmeros suelen ser mucho ms grandes. 10 Dos enteros son relativamente primos si no tienen factor comn diferente de 1.
9

68

En el otro lado B quiere recuperar el mensaje que le ha llegado, para lo cual usa la llave privada y la frmula de descifrado dada anteriormente: m = cd mod n m = 527 mod 55 = 25 m = 25, el mensaje original enviado por A. 4.3.INFRAESTRUCTURA DE LLAVES PBLICAS El comercio electrnico y la transmisin de datos privados sobre Internet ha crecido vertiginosamente, por tanto la autenticacin ha cobrado un papel crucial en este proceso. La criptografa de llaves pblicas ofrecen una gran herramienta matemtica para facilitar la autenticidad, pero surge un gran problema y es el cmo manejar y publicar dichas llaves para cada persona o entidad que las necesiten. Una infraestructura de llaves pblicas (Public Key Infrastructure - PKI) [REF4.8] es el conjunto de servicios y polticas que rigen el esquema de vinculacin de una identidad con una llave pblica y la posterior redistribucin de ese vnculo. Una PKI tiene tres procesos bsicos: certificacin, validacin y la revocacin de certificados. La certificacin es la vinculacin de una identidad a una llave pblica. La llave pblica y la identidad o atributos son puestos dentro de una documento digital llamado certificado. Un tercer participante confiable firma el certificado digitalmente, dando fe de la validez del contenido. El tercer participante en una PKI es llamado una Autoridad de Certificacin (CA).

69

La validacin es el proceso de comprobar la autenticidad del certificado, por tanto de asegurar que el contenido del mismo es confiable. Esto requiere la verificacin de la firma del CA usando la llave pblica del mismo y chequeando el certificado contra una lista de revocacin de certificados (CRL). Una CRL contiene una lista de certificados que han sido revocados anteriormente por la CA indicando que ese vnculo no es vlido. La validacin tambin involucra chequear el periodo de validez contenido en el certificado mismo. La revocacin de un certificado es el proceso de desconocer un certificado previamente emitido antes de su fecha de expiracin. Estos sucede cuando algunos aspectos de la informacin contenidos en el certificado cambian; quizs porque la identidad del usuario ha cambiado o porque la llave privada del usuario ha sido comprometida. El CA es responsable de emitir una CRL actualizada. Un aspecto fundamental de las PKI es el grado de confianza que deposita en las CAs. Sin tal confianza los certificados digitales emitidos por cada CA perderan valor.

4.3.1. ARQUITECTURA DE UNA INFRAESTRUCTURA DE LLAVES PBLICAS Una PKI incluye la autoridad certificadora (CA) y todos los otros componentes que permiten la certificacin, validacin y revocacin. La figura 4.3 muestra los principales componentes de una PKI: El usuario, el validador, la autoridad de registro RA, la autoridad de certificacin CA, el certificado y un depsito de CRLs. Todos estos componentes interactan para facilitar la adquisicin y uso de certificados digitales. 70

Busqueda de un certificado o CRL

Validador Entidades de usuario

Autenticacin Presentacin de un Certificado


Depsito de certificados y CRLs

Usuario Presentacin de Credenciales Publicacin del certificado RA Solicitud de un certificado Publicacin del certificado o CRL Presentacin de Credenciales y solicitud de un certificado Garantizacin de un certificado CA

Entidades de administracin

Solicitud o garantizacin de un certificado Publicacin del certificado o CRL CA

Figura 4.3 Arquitectura de una infraestructura de llaves pblicas

Las CAs, las RAs y el depsito de CRLs son entidades de manejo o administracin dado que ellos son responsables de la generacin, distribucin, almacenamiento y revocacin de certificados digitales. Los usuarios y los validadores son entidades de usuario dado que ellos usan los certificados y las funciones de la PKI para lograr sus propsitos. Las entidades de usuarios realizan requerimientos a las entidades de manejo, bien sea para adquirir un certificado o validar alguno que haya presentado otra entidad de usuario. Despus que las credenciales son certificadas y verificadas, un certificado es emitido al usuario y publicado en el depsito. Cuando un validador necesita autenticar un usuario, usa la llave pblica vlida contenida en el certificado para verificar un mensaje firmado por la llave privada del usuario. Las CAs tambin publican las CRLs en el depsito, por tanto el validador puede chequear si el certificado del usuario es todava vlido. Las CRLs tambin pueden ser recibidas peridicamente sin necesidad de 71

alguna peticin. Un conjunto de protocolos ha sido desarrollados y estandarizados para administrar las diferentes transacciones entre todas las entidades. 4.3.2. CERTIFICACIN La certificacin es el proceso de vincular un usuario con su informacin. Para asegurar la autenticidad e integridad de tal vnculo, la CA firma el documento usando su llave privada. El proceso de certificacin toma varios pasos. Primero, el CA debe verificar que la informacin contenida en el certificado digital es autntica y precisa. Esto implica un cierto nivel de seguridad en el canal que se usa para hacer este requerimiento y un especial cuidado del personal autorizado para insertar la informacin de la entidad dentro de un certificado. En algunas ocasiones la parte que entra la informacin no es el usuario a certificar. El siguiente paso es la generacin del par de llaves. La llave pblica del usuario deber ser incluida en el certificado. Algunas veces el usuario genera el par de llaves y pasa solamente la llave pblica a la CA, por tanto solo l conoce su llave privada. Despus, la CA firma el certificado con su llave privada. Esto tiene dos objetivos: Que el certificado sea garantizado por la CA y que la integridad del certificado sea protegida. Despus que el certificado digital es creado y firmado por la CA, el usuario puede recuperarlo desde ella. El proceso de recuperacin del certificado comienza con la presentacin de una credencial por una nica y primera vez a la CA, usualmente es un nmero de referencia y un cdigo de

72

autorizacin dado al usuario por otro medio (preferiblemente seguro). En algunos casos es tan simple como un e-mail que enva la CA al usuario. 4.3.3. VALIDACIN Un certificado debe ser validado antes de poder ser usado para brindar confiabilidad, la validacin del certificado comprende los siguientes pasos: 1. La integridad del certificado es chequeada verificando la firma digital por medio de la llave pblica de la CA. 2. El intervalo de validacin del certificado digital es chequeado. 3. La CRL de la CA es chequeada para asegurarse que el certificado no ha sido rechazado. 4.3.4. REVOCACIN DEL CERTIFICADO Un certificado puede ser revocado antes de su fecha de expiracin si pierde su validez de alguna manera, por ejemplo cuando la longitud de la informacin contenida en el no es vlida. As como con el proceso de certificacin, el requerimiento para revocar un certificado deber ser recibido por medio de un canal seguro y examinado detenidamente. La CA revoca un certificado incluyndolo en la lista de certificados revocados o CRL (Certificate Revocation List). Una CRL usualmente contiene solo los nmeros seriales de los certificados revocados. La inclusin de toda la informacin de los certificados revocados dentro de la CRL resultara innecesaria y de un tamao de archivo muy grande. La CA garantiza la integridad de la CRL firmando la misma con su propia llave privada. La CA da a conocer la CRL publicndola en su depsito. LA CRL es actualizada frecuentemente (por ejemplo cada ocho horas). La entidad de 73

validacin puede realizar un requerimiento de la CRL actualizada cuando la misma en su posesin ha expirado. En algunas ocasiones la CA proactivamente entrega su CRL a las entidades de validacin ms grandes cuando una nueva revocacin ha sucedido, de esta manera el efecto se torna inmediato. 4.3.5. FORMATOS DE CERTIFICADOS DIGITALES Un certificado digital, como ya se haba dicho anteriormente, vincula la identidad de una entidad a su llave pblica. La autenticidad de la informacin es garantizada por la firma digital de la CA emisora. Varios estndares describen la informacin que debe estar contenida en el certificado, cmo debe ser organizada dentro del mismo y cmo se firma el certificado. Entre los formatos ms usados se encuentran el X.509 y el PGP. 4.3.5.1.Certificado X.509 La X.509 [REF4.9] define los lineamientos de los certificados de llaves pblicas, incluyen una especificacin de los certificados usados para vincular un nombre con una llave pblica, y una especificacin de revocacin para los certificados emitidos que no sean confiables. El estndar X.509 no especifica una infraestructura de llaves pblicas (PKI) en su totalidad, solo provee las bases sobre las cuales una PKI puede ser construida. X.509 define el formato de certificados de llaves pblicas ms ampliamente usado. La primera versin, X.509v1 fue publicada en 74

1988 y provee la estructura bsica del certificado. X.509v2 apareci en 1993 y le adicion a la primera versin dos campos opcionales para proveer de unicidad al certificado en cuanto a su emisor y sujeto. La tercera y actual versin, X.509v3 fue publicada en 1997 con extensiones opcionales que ayudan a personalizar el formato del certificado para varias aplicaciones. Un certificado digital X.509 es un documento firmado que garantiza el vnculo de un nombre y una llave pblica, por lo tanto, debe contener al menos un nombre y una llave pblica. En la figura 4.5. se muestra el formato de un certificado X.509v3, la sintaxis que se utiliza para la estructura de este certificado es la ASN.1 (Abstract Syntax Notation One). ASN.1 es la forma estndar de OSI para expresar notaciones abstractas sin una estrategia de implementacin previa. Vale la pena decir que tambin provee las estructuras en lenguajes de programacin como C y Pascal. El formato X.509v3 tiene 10 campos, los formatos X.509v1 y X.509v2 son un subconjunto de ste. El campo versin es un valor entero que indica cual de las tres versiones es la usada en dicho certificado. Los valores 0, 1 y 2, hacen alusin a las versiones 1, 2 y 3 respectivamente. El valor por defecto para este campo es cero, es decir X.509v1. Los certificados X.509v1 no contienen los 3 ltimos campos mostrados en la figura 4.4 El X.509v2 adiciona los campos issuerUniqueID y subjectUniqueID y X.509v3 adiciona el campo extensions.

75

Certificate ::= SIGNED {SEQUENCE { version [0] Version DEFAULT v1 (0) , serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo subjectPublicKeyInfo, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, extensions [3] Extensions OPTIONAL } } Version ::= INTEGER { v1 (0), v2 (1), v3 (2) } CertificateSerialNumber ::= INTEGER AlgorithmIdentifier ::= SEQUENCE { algorithm ALGORITHM.&id({SupportedAlgorithms}), parameters ALGORITHM.&Type({SupportedAlgorithms} {@algorithms}) OPTIONAL } Validity ::= SEQUENCE { notBefore Time, notAfter Time } Time ::= CHOICE { utcTime UTCTIME, generalizedTime GeneralizedTime } SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BITSTRING } UniqueIdentifier ::= BITSTRING Extensions ::= SEQUENCE OF Extension Extension ::= SEQUENCE { extnid EXTENSIN.&ide({ExtensionSet}),, critical BOLEAN DEFAULT FALSE, entnValue OCTETSTRING } ExtensionSet EXTENSIN ::= {...}

Figura 4.4 Formato de un certificado X.509v3

El campo serialNumber se usa para distinguir ese certificado entre los dems emitidos por la misma CA, por lo tanto es un valor nico dentro de la misma. Algunas implementaciones usan valores incrementados monotnicamente, otras usan nmeros pseudoaleatorios como la CA de Microsoft. El campo signature especifica el identificador del algoritmo usado para firmar el certificado. El campo issuer identifica la entidad que ha firmado el certificado. En el mundo X.500 (del cual hace parte X.509), este valor se refiere a un nombre distinguido (DN).

76

El campo validez especifica el intervalo de tiempo durante el cual el certificado es vlido. Esto significa que la CA emisora garantiza que mantendr esta informacin sobre este certificado durante todo este tiempo. El periodo de validez puede ser expresado en formato UTC (Universal Time Coordinated), el cual usa solo dos dgitos para el ao y por tanto asume que ningn certificado tendr una validez superior a un siglo. El campo subject identifica la entidad asociada con la llave pblica encontrada en el campo subjectPublicKeyInfo. Como con el caso del campo issuer el valor se refiere a un DN. El campo subjectPubicKeyInfo es usado para colocar la llave pblica y el algoritmo que ella usa pertenecientes a la entidad descrita en el campo subject. Los campos issuerUniqueID y subjectUniqueID fueron adicionados en la versin dos para identificar unvocamente un emisor y el sujeto en caso de que el nombre haya sido reusado. Aunque un sujeto es un nombre distinguido y por lo tanto es nico en un directorio X.509, ese nombre hubiera podido ser usado tiempo atrs. Evitar confusiones con los nombres reusados son los objetivos de estos dos campos. El campo extensions permite la adicin de nuevos campos a la estructura del certificado sin la necesidad de modificar la definicin del mismo. Este campo es particularmente usado cuando el certificado debe transportar informacin adicional propietaria del contexto en el cual la PKI est desarrollada. Un certificado puede tener uno o ms campos de extensiones.

77

La figura 4.5 muestra la representacin de un certificado de llaves pblicas X.509v3 en un navegador Netscape.

This Certificate belongs to: Ruixi Yuan ryuan@bbn.com GTEI Users Burlington, MA, US This Certificate was issued by: AWS Issuing CA VPN Advantage GTE Internetworking US Serial Number: 00:A1 This Certificate is valid from Wed Aug 25, 1999 to Fri Aug 25, 2000 Certificate Fingerprint: B4:43:20:82:09:99:69:34:E0:2D:2A:5D:18:4F:9C:E2

Figura 4.5 Un certificado digital X.509 tal como lo muestra Netscape

4.3.5.2.Certificados PGP

Otro formato de certificados ampliamente usados es el conocido como PGP (Pretty Good Privacy) [REF4.10]. Un certificado PGP incluye la siguiente informacin: Versin PGP: Este campo identifica que versin de PGP fue usada para crear la llave asociada con el certificado. La llave pblica del portador del certificado y su algoritmo: Esta es la parte pblica de la pareja de llaves con el algoritmo de la llave: RSA, DH (Diffie-Hellman) o DSA (Digital Signature Algorithm). Informacin del portador del certificado: Este consiste de la informacin sobre el usuario tal como su nombre, su identificacin (user ID), etc. La firma digital del propietario del certificado: Tambin llamada autofirma. Es la firma usando la correspondiente llave privada de la llave pblica asociada con el certificado.

78

El periodo de validez del certificado: Incluye la fecha y hora de inicio del certificado y la fecha y hora de expiracin del mismo. El algoritmo de cifrado simtrico preferido para la llave: Este indica el algoritmo de cifrado que el propietario del certificado prefiere para que su informacin sea encriptada. Los algoritmos soportados son CAST, IDEA y 3DES.11

Un certificado PGP es construido de un nmero de registros etiquetados llamados paquetes. La figura 4.6 es la versin ASCII de un certificado PGP. Este bloque apilado es una forma usual de enviarle a alguien un certificado PGP o para que alguien obtenga el certificado de otra persona desde un sitio web. En este ejemplo se muestra el contenido codificado de una llave.

-----BEGIN PGP PUBLIC KEY BLOCK----Version: GnuPG v1.0.0 (FreeBSD) Comment: For info see http://www.gnupg.org mQGiBDiQgiTRBADd7G5Di5ibmr2I03cU+QsZ/J02cAVc9z8VX/gwj3nxm81hvOHP 1GZuHZB/guDPID7J6b0Zj0zjOr+KQf71sMnXMSn1pl1HyvvYeCeaV+XjpkmGmYpI 8bWx85XO5XyqfWK0yhh51FtoE8UnboKTaJK8vsGX1bgZrQHKIUdG3zGzHwCg/2RV iDPMuBQ4f+nbTkX6cvb++cEAl8g411r5Dx6fKehxccMiuntdea8lWfov8Cxj3Uxm 101asg/bpdWVfu27oSZORcSqX1ZCSTRpjmXL14Tt7CiFJrz1hdrSE+uz95nRFD+0 jVSM3eh45xp3Q9rCq4OwrdpAIUs9FhOweoJu/Pu0wcoV8MdHMw+LxdjQPV3zfzDM JuJAA/9zEy+7b+uxayTO0zdPYdiSqQYzvmZCs+f1EaKOcZg+JgL5mM3qUBgv+cOx saNjXWJqtp11Y3TbYXcIl53bTFVJWZcAb7IxSsfec717dpoggF0SfqA/c7LW95gm 0izceLKCDQQ3kIIjEAgA9kJXtwh/CbdyorrWqULzBej4UxE5T7bxbr1LCcDOAadW oxTpj0BV89AhxstDqZSt00xkhikn4DIOZejX1KTUPj1WV/cd12JPPT2N286z4VeS Bm01Lmxx8/TD0auTYgi7GhvaXi7CcUJmBxIFrJzkN3/8xVsmjddezudEpTMaan3g IWLxF3xTz9NcetrXsRhluIjklloEhD2WeSW29X0/iMue1byHYTdybXNK/CT17rtg acQIn+ZUD7AHDcgbbEqpd3+tIisI9DSRb8q8QkxqubGupuqXqE1Nxzo=J30A3VOV klqn+vy5mC+DhyH3fqCo8p=omABrIJsmIUQv2firywEyWdaeei14m78x1yFAcq0o Nyctz8WjhgzVgIoeF9NqilytfmxdVv478+KU3ZPMDZQDOPvDz/f3Ilbv950VigBd qsZx95iHgbbGraGagbqi4agbqi3JiiJaOjCazntkbAWnyaNuYdiE41DmaP/XTEbg 7y/ycyUyAJDgIPywxWLSMTGS/ER1JDdJ/aa/Q== Figura 4.6 Certificado PGP en su versin ASCII =vTQH -----END PGP PUBLIC KEY BLOCK-----

11

La ltima versin de PGP disponible es la 8.0 y aun no soporta AES.

79

La figura 4.7 muestra la estructura de un certificado PGP.


:public key packet: version 4, algo 17, created 948994594, expires 0 pkey [0 : [1024 bits pkey [1 : [160 bits pkey [2 : [1024 bits pkey [3 : [1023 bits :user ID packet: Tim Strayer <strayer@bbn.com> :signature packet: algo 17, keyid 319C64D4D20E405A version 4, created 948994594, md5len 0, sigclass 10 digest algo 2, begin of digest dc 29 hashed subpkt 2 len 5 (sig created 2000-01-27) hashed subpkt 11 len 4 (pref-sym-algos: 3 2 1) hashed subpkt 25 len 2 (primary user ID) subpkt 16 len 9 (issuer key ID 319C64D4D20E405A) data: [160 bits data: [156 bits :public sub key packet: version 4, algo 16, created 948994595, expires 0 pkey [0 : [2048 bits pkey [1 : [2 bits pkey [2 : [2024 bits :signature packet: algo 17, keyid 319C64D4D20E405A version 4, created 948994595, md5len 0, sigclass 18 digest algo 2, begin of digest c0 c6 hashed subpkt 2 len 5 (sig created 2000-01-27) subpkt 16 len 9 (issuer key ID 319C64D4D20E405A) data: [159 bits data: [160 bits

Figura 4.7 Estructura de un certificado PGP

Este certificado PGP consiste de cinco paquetes: un paquete de llave pblica, un paquete de identificacin de usuario, un paquete de firma, un paquete de subllave pblica y otro paquete de firma. Cada uno de estos paquetes est constituido de varios campos, como por ejemplo el algoritmo que se us para encriptar la llave (algo), la fecha de creacin del certificado (created, en formato UTC, es decir el nmero de segundos transcurridos desde el 1 de Enero de 1970), la fecha en la que el certificado expira (expires), etc. 12

Para una descripcin detallada de cada uno de los campos presentes en el formato de un certificado PGP se puede consultar la RFC2440 de la IETF en http://www.ietf.org/rfc/rfc2440.txt.
12

80

4.3.6. SISTEMAS DE ADMINISTRACIN DE CERTIFICADOS La interaccin de todos los componentes de una PKI que manejan la creacin, renovacin, mantenimiento y revocacin de certificados digitales es conocida como el Sistema de Administracin de Certificados (Certificate Management System). Esos componentes incluyen: Autoridad de certificacin Autoridad de registro Depsito de certificados y CRL Algunas veces todos los tres componentes residen en el mismo computador.

4.3.6.1.Autoridad De Certificacin (CA)

La CA es la entidad que emite y revoca los certificados, entre sus funciones estn: Creacin y administracin de las llaves pblicas y privadas de la propia CA Creacin de parejas de llaves pblicas y privadas para los usuarios que as las necesitan. Creacin de un certificado vinculando la llave pblica del usuario a la identidad del mismo. Revocacin de certificados. Creacin de la lista de certificados revocados.

81

Administracin de una base de datos de informacin segura donde reside la historia de los certificados emitidos y revocados. Manejo de un completo registro (log) de mensajes para propsitos de auditora.

4.3.6.2.Autoridad de Registro (RA)

Una CA es responsable de dos cosas: La verificacin de la informacin del usuario y la emisin del certificado. La emisin de un certificado requiere acceso a la llave privada de la CA para que ella misma lo firme. Lo ideal es mantener la llave privada de la CA en un pequeo nmero de sitios. La verificacin de la informacin de un usuario, el requerimiento de un certificado, la generacin de la llave y el almacenamiento de la misma, son aspectos que hace la CA sin requerir accesar la llave privada del usuario. Uno o ms autoridades de registro (RA) son empleadas para realizar estas funciones. Una CA puede tener muchas RAs estratgicamente localizadas para proveer una alta disponibilidad. Dado que la poblacin de usuarios crece continuamente, ms y ms RAs deben ser adicionadas para mantener estable el nivel de servicio. Una desventaja obvia de tener ms y ms RAs es que se incrementa la complejidad del mantenimiento de la seguridad; ya que cada RA debe ser certificada por la CA y debe comunicarse con la misma y con las otras RAs que tienen que ver con la verificacin y revocacin de los certificados que ella maneja. 4.3.6.3.Depsitos de Certificados y de CRLs

82

Cuando un certificado es emitido a un usuario, la CA puede tambin publicar una copia de dicho certificado en un depsito. De la misma manera cuando es necesario invalidar un certificado antes de su fecha de expiracin, la CA debe publicar la revocacin publicndola en su CRL. Lo ms conveniente es mantener la CRL en la lista de certificados en el mismo depsito. Un certificado no puede ser declarado vlido hasta no ser chequeado contra la CRL, por lo tanto, es vital que un depsito de CRLs tenga siempre un fcil acceso. Sin embargo, el facilitar este acceso tambin puede hacer que el depsito sea vulnerable a varios tipos de ataques DOS (Denial-Off- Service). Medidas de seguridad apropiadas deben ser tomadas para reducir este riesgo e incrementar la robustez de la PKI. Algunas veces es de utilidad tener mltiples depsitos redundantes.

4.4.CONTROL DE ACCESO
El control de acceso es un conjunto de polticas y mecanismos que permiten a las partes acceso autorizado a determinados recursos. De esta manera protege al recurso de accesos maliciosos o accidentales de usuarios que no estn autorizados a accederlos. La figura 4.8 muestra un control de acceso en un modelo cliente-servidor. Se considera usuario a cualquier entidad (usuario o aplicacin trabajando en nombre de ese usuario) que desee acceder al recurso. Se determina por recurso a cualquier objeto que puede ser manipulado de alguna manera, tales

83

como lectura, escritura o modificacin, causadas por la realizacin de alguna accin, tales como la ejecucin de un programa o el envo de un mensaje.

Polticas Servidor
Autenticacin

Control de Acceso

Usuario Cliente

Identidad Atributos Operacin

Recursos

Figura 4.8 Control de acceso en un modelo cliente-servidor

Un usuario tiene una identidad y un conjunto de atributos asociados. El cliente enva la identificacin del usuario, los atributos y el requerimiento de una operacin al servidor. El servidor puede autenticar la identidad del usuario y remitirlo junto con los atributos y el requerimiento solicitado a los mecanismos de control de acceso. Las polticas son preestablecidas en el mecanismo de control de acceso; la informacin del usuario es comparada con las reglas de las polticas para determinar los derechos de acceso del usuario a ese recurso.

4.4.1. POLTICAS DE CONTROL DE ACCESO Una poltica de control de acceso es el conjunto de reglas que definen la proteccin de uno o ms recursos. Esas reglas son generalmente expresadas en trminos de la informacin del usuario (atributos) y las

84

condiciones para el uso de un factores del entorno).

recurso (atributos del recurso y otros

En general hay dos tipos de polticas de control de acceso, las discrecionales y las mandatarias. El control de acceso discrecional permite al dueo del recurso determinar qu derechos de acceso son garantizados y a quienes. Un ejemplo son los permisos que se le pueden colocar a un archivo. Las empresas u organizaciones especifican control de acceso mandatario. Un ejemplo de este es el control de acceso que fijan las entidades militares.

4.4.2. REGLAS DE CONTROL DE ACCESO Las polticas de control de acceso representan los deseos de las entidades que dicen ser dueas o ejercen influencia sobre el recurso. En general, las polticas de control de acceso son reglas que comparan la informacin del usuario y las condiciones del entorno con las condiciones del recurso para ser usado. En general, las reglas de control de acceso son expresadas como un juego de condiciones de concordancia basadas en los atributos del usuario, los atributos del recurso y las condiciones del entorno. Un ejemplo general de una regla de control de acceso es el siguiente.
rule := if { match ({user attributes, {required values) and match ({resource attributes, {required values) and match ({environmental conditions, {required values) then grant else deny

85

La funcin match compara los atributos y condiciones con los valores requeridos para accesar el recurso. Por flexibilidad, cada comparacin soporta un rango de valores. Una poltica de control de acceso puede ser expresada como una sola regla compleja, o como un conjunto de reglas, un ejemplo es el siguiente:
Policy := {rule1, rule2, rule n}

Algunas veces hay una regla general llamada regla por defecto que se coloca al final de las reglas especficas, un ejemplo es el siguiente:
Policy := {rule1, rule2, rule n, default rule}

Una regla por defecto se usa para negar acceso diferente al que ha sido permitido por las reglas especficas. Por lo general el orden de las reglas no interesa, pero es recomendable organizarlas de la ms especfica a la ms general.

4.4.3. MECANISMOS DE CONTROL DE ACCESO Los mecanismos de control de acceso son las formas concretas para expresar una regla. Las listas de control de acceso y las listas de capacidades son dos de los mecanismos ms usados para especificar las reglas condicionales. 4.4.3.1.Listas De Control De Acceso

86

Una ACL (Access Control List) asocia cada recurso con una lista ordenada de qu usuarios pueden tener acceso al recurso y cmo esos usuarios pueden accederlo. Este mtodo es de recurso cntrico; dando el nombre del recurso, del usuario, los atributos del mismo y el tipo de operacin, el mecanismo de control de acceso puede buscar la ACL correspondiente a ese recurso y determinar si el usuario puede o no realizar la operacin. Los usuarios en algunas ocasiones son puestos en grupos o en clases equivalentes, las cuales tienen los mismos derechos. Esta prctica tiene como objetivo volver ms escalables las ACLs dependiendo del nmero de usuarios en el sistema. El sistema de archivos UNIX usa una forma de ACL para permitir o denegar las operaciones que pueden ser hechas en los archivos. Hay tres tipos de operaciones bsicas: lectura, escritura y ejecucin. Cada archivo tiene asociados tres juegos de permisos: uno para el propietario del archivo, uno para el grupo y uno para cualquier otra persona. Cada permiso contiene los tres derechos: lectura (R), escritura (W) y ejecucin (X); los derechos que no son garantizados se llenan con un guin (-). Los tres conjuntos con los tres privilegios forman una cadena de nueve dgitos (rwxrwxrwx). A continuacin se detalla la salida de un comando Unix ls la cual muestra los permisos de varios archivos dentro de ese directorio.
-rw------- 1 steve staff 383 Mar 13 23:32 history -rw-rw-r-- 1 steve staff 584 Mar 13 18:17 profile -rwxr-x--- 1 steve project 164 Mar 13 18:17 useful*

En el anterior ejemplo el archivo history tiene permisos de lectura y escritura para el propietario (steve); el archivo profile tienen permisos de lectura y escritura para propietario y para el grupo (staff), y de

87

lectura para cualquier otra persona; y el archivo useful tiene permisos de lectura, escritura y ejecucin para el propietario y de lectura y ejecucin para el grupo. El control de acceso en un firewall es otro ejemplo de como las ACLs son usadas. Generalmente un firewall es ubicado en los lmites entre una Intranet e Internet. El firewall, por lo tanto, tiene dos interfaces: una con una direccin IP externa generalmente pblica, y otra interfaz con una direccin interna (generalmente privada). El firewall implementa polticas de control de acceso para proteger los recursos de la Intranet de accesos maliciosos y mal intencionados. El siguiente es un ejemplo de las reglas que son aplicadas en un firewall IP en un sistema operativo FreeBSD que protege una LAN corporativa que se conecta a Internet por medio de un cablemodem
oif="rl0" # Nic card to cable modem public internet connection # Allow in www $cmd 00600 allow tcp from any to any 80 in via $oif setup keep-state limit src-addr 4 # Allow in ssh function $cmd 00610 allow log tcp from any to me 22 in via $oif setup keep-state limit src-addr 4 # Allow in Telnet $cmd 00620 allow tcp from any to me 23 in via $oif setup keep-state limit src-addr 4

La primera regla permite que desde Internet haya trfico hacia cualquier host de la Intranet usando el puerto 80 (trafico http), la segunda regla permite el trfico de protocolo ssh desde Internet usando el puerto 22, la tercera regla permite el trfico por el puerto 23, usado para conexiones telnet desde Internet. La primera linea del

88

ejemplo sirve para definir la variable

$oif usada por las reglas del

firewall y hace referencia a una tarjeta adaptadora de interfaz donde esta conectado un cablemodem que provee la conexin a Internet. 4.4.3.2.Listas de Capacidades Las listas de capacidades (C-list) son equivalentes a las ACLs pero son centradas en el usuario a diferencia de las ACLs que son centradas en el recurso. En una C-list cada usuario tiene una lista de recursos que puede acceder. Una C-list es usada si los recursos pueden ser agrupados en clases equivalentes, por ejemplo en la clasificacin de seguridad militar, donde un documento puede ser marcado como: no clasificado, secreto o supersecreto. La gran desventaja de usar una C-list es la dificultad de determinar todos los usuarios que tienen derechos de acceso a un recurso en particular. Como todos los usuarios tienen acceso al recurso, cada uno de ellos pueden hacer cambios sobre este, consecuentemente revocar o modificar los derechos de acceso en un recurso debiera requerir cambiar de rango a ese usuario o promover un rango superior a los dems.

4.4.4. ADMINISTRACIN DE LAS POLTICAS DE CONTROL DE ACCESO Las polticas de control de acceso usualmente son dinmicas, es decir que nuevas polticas deben ser aplicadas cada vez que nuevos recursos o 89

nuevos usuarios aparecen en la red. El proceso de crear, mantener y distribuir las polticas de control de acceso es llamado administracin de las polticas de control de acceso. Una administradora de polticas es la entidad que tiene el control sobre todas las polticas de acceso en un sistema. El manejador de las polticas es el servicio responsable de proveer a los administradores de una interfaz fcil de usar que defina, instale, modifique y despliegue polticas. El manejador de polticas tambin es el encargado de traducir las reglas del lenguaje abstracto que maneja el administrador a expresiones que son usadas en los mecanismos de control de acceso. Cuando mltiples puntos de control de acceso existen en una red, la administracin de las polticas puede ser hecha de una manera centralizada o de una manera distribuida.

4.4.4.1.Administracin de polticas distribuidas Una administracin de polticas distribuidas es mostrada en la figura 4.9, el administrador de polticas usa los manejadores de polticas que se encuentran cerca o en los puntos a asegurar. Cuando una poltica es creada, actualizada o borrada, el administrador contacta al manejador asociado con ese recurso, y son stos ltimos los encargados de almacenar las polticas internamente. Cuando una decisin de control de acceso debe ser tomada, el recurso asegurado le pregunta al respectivo manejador encargado de sus polticas. Este manejador est usualmente muy cercano, o inclusive localizado en el recurso mismo.

90

Manejador de polticas

Punto a asegurar

Administrador de polticas

Manejador de polticas

Punto a asegurar

Manejador de polticas

Punto a asegurar

Figura 4.9 Manejo de polticas distribuidas

La administracin de polticas distribuidas permite que las decisiones de control de acceso sean hechas de una manera ms rpida, ya que el manejador est cercano al punto asegurado. Dado que las polticas no viajan a travs de la red para cada decisin, son menos susceptibles de ataques tales como la introduccin de falsas polticas o la alteracin de las mismas. La desventaja de este sistema distribuido se centra en la consistencia. Dado que en un ambiente de redes los puntos a asegurar pueden interactuar con mltiples entidades, las polticas deberan ser creadas y mantenidas en varios manejadores. Si la seguridad de alguno de estos manejadores es violentada, el control de acceso del sistema global puede ser comprometido.

4.4.4.2.Administracin centralizada de polticas A diferencia de la administracin de poltica distribuida, la

administracin centralizada tiene solo un depsito central de polticas. 91

Cuando el administrador de polticas debe crear, actualizar o borrar una poltica, solo tiene que contactar a un solo manejador, el cual a su vez almacena la poltica en el depsito central. Dicho depsito central de polticas puede estar cerca o inclusive ser parte del mismo manejador de polticas. Cada punto a asegurar obtiene sus polticas de control de acceso desde el depsito central a travs de protocolos de intercambios de polticas estandarizados o propietarios. Una ventaja de este sistema es la facilidad de uso para el administrador de polticas ya que contacta solo a un manejador. Tambin es fcil mantener la consistencia de todos los recursos. La desventaja de este sistema es la latencia en la que se puede incurrir cuando los puntos a asegurar estn alejados del depsito central. Realizar un cach de stas polticas en sitios cercanos a los puntos a asegurar resuelve el problema de la latencia, pero puede crear potenciales problemas de inconsistencias dado que debe transcurrir un tiempo de actualizacin cuando en el depsito central es cambiada una poltica. Otro problema que se puede presentar es que stos caches multiplican la posibilidad de ser sujetos de ataques. En la figura 4.10 se muestran todos los componentes que intervienen en el manejo centralizado de polticas y la relacin entre cada uno de ellos.

92

Polticas

Punto de control de acceso (servidor)

Depsito central de polticas

Punto de control de acceso (servidor)

Administrador de polticas

Manejador de polticas
Figura 4.10 Manejo de polticas centralizado

Punto de control de acceso (servidor)

REFERENCIAS: [REF4.1] RFC1760 S-KEY One Time Password System, Febrero,1995 [REF4.2] RFC1334 PPP Authentication Protocols, Octubre, 1992 [REF4.3] RFC1994 PPP Challenge Handshake Authentication Protocol (CHAP), Agosto, 1996 [REF4.4] RFC2865 Remote Authentication Dial-in User Service (RADIUS), Junio, 2000 [REF4.5] Applied Cryptography. Schneier, Bruce. John Wiley & Sons. 1997 [REF4.6] Diffie-Hellman Key Agreement Method, Junio, 1999. [REF4.7] RSA, http://www.rsasecurity.com. Pagina oficial de los Laboratorios RSA. [REF4.8] RFC2459, 2587 y 3039. Internet X.509 Public Key Infraestructure Certificate and CRL Profile, Enero, 1999. [REF4.9] RFC2527. Internet X.509 Public Key Infraestructure Certificate Policy and Certification Practices Framework, Marzo, 1999. [REF4.10] PGP, http://www.pgpi.org. Pagina internacional de PGP.

93

5.

TECNOLOGAS VPN

Bsicamente, y desde el punto de vista de la torre OSI, se puede crear una VPN usando tecnologas de capa 2 (enlace de datos) y de capa 3 (red). Dentro de la primera categora estn PPTP y L2TP, y en la segunda se encuentra IPSec. MPLS tiene caractersticas de las dos al ser una red conmutada que usa etiquetas para enrutar paquetes. Este captulo comprende las tecnologas VPN ms conocidas, y que tcnicamente presentan las mejores caractersticas de seguridad, rendimiento, facilidad y economa.

5.1.

PPTP (Point-to-Point Tunneling Protocol)

Es quiz el protocolo ms sencillo de entunelamiento de paquetes. Es usado, en general, por pequeas empresas para realizar sus VPNs LAN-to-LAN, y en topologas de acceso remoto, para trabajadores teleconmutados (teleworkers), tales como vendedores externos o trabajadores que se mantienen en constante movimiento por fuera de sus oficinas. El protocolo PPTP [REF5.1] fue propuesto por el Foro PPTP (PPTP Forum), compuesto por 3Com, Ascend (ahora Lucent), Microsoft, ECI Telematics y USRobotics. Debido a la integracin que hizo Microsoft en sus sistemas operativos Windows NT, y luego en Windows98 y posteriores, PPTP tuvo gran acogida

94

en el mercado mundial, a tal punto que un protocolo de capa 2 lanzado por Cisco Systems al mismo tiempo, prcticamente no se conoci, L2F (Layer-2Forwarding) [REF5.2] . El protocolo ms comnmente usado para acceso conmutado a Internet es el protocolo punto-a-punto (PPP). PPTP se soporta sobre toda la funcionalidad que PPP le brinda a un acceso conmutado para construir sus tneles a travs de Internet. PPTP encapsula paquetes PPP usando una versin modificada del Protocolo de Encapsulamiento Ruteado Genrico (GRE Generic Routing Encapsulation) [REF5.3]. Dado lo anterior, PPTP no solo es capaz de encapsular paquetes IP, sino IPX y NETBEUI, los protocolos de red local ms usados. La figura 5.1 muestra una conexin PPP entre un host y un RAS. Como se puede ver, es una conexin sencilla punto a punto donde lo primero que se realiza es una autenticacin sencilla previa al envo y recibo de tramas PPP de datos.

Cliente Conectividad PPP

Servidor de Acceso Remoto

Usuarios autenticados Conectividad PPP Nombre de usuario y clave Autenticado

Datos transmitidos
Datos PPP Cabecera de protocolo Datos PPP

Cabecera de protocolo

Figura 5.1 Conexin PPP tpica entre un host y un RAS

95

PPTP utiliza los mecanismos de autenticacin que generalmente estn asociados a PPP tales como PAP y CHAP, una versin mejorada de CHAP llamada MS-CHAP y desarrollada por Microsoft se encuentra en sus sistemas operativos Windows NT, 2000 y XP13. Otra mejora que le ha hecho Microsoft al protocolo PPTP es la incorporacin del mtodo de cifrado MPPE (Microsoft Point-to-Point Encription). Una de las ventajas que tiene PPTP por ser un protocolo de nivel 2, es que puede transmitir protocolos diferentes a IP en sus tneles, a diferencia de IPSec que se restringe a trabajar solamente con paquetes IP.

5.1.1.

RELACION ENTRE PPP Y PPTP

PPP es el protocolo ms comnmente usado para acceso a Internet, prcticamente el nico14, adems es usado en algunos enlaces seriales punto a punto WAN. PPP trabaja en la capa 2 de la torre OSI, la capa de enlace de datos, e incluye mtodos para encapsular varios tipos de datagramas para ser transferidos sobre enlaces seriales. PPP tiene dos juegos de protocolos: el Protocolo de Control de Enlace (LCP) que se encarga de las labores de establecimiento, configuracin y prueba de la conexin y una serie de Protocolos de Control de Red (NCPs) para el establecimiento y configuracin de los diferentes protocolos de capa 3. PPP es capaz de encapsular paquetes IP, IPX y NETBEUI en tramas PPP y enviar estos paquetes encapsulados de extremo a extremo (entre dos computadores por ejemplo). Para el establecimiento de una comunicacin, cada extremo de un enlace PPP primero enva paquetes LCP para
Es comnmente usado en ambientes de acceso conmutados bajo tecnologa Microsoft basarse en la informacin del dominio para validar a los usuarios. 14 Otro protocolo de comunicacin serial es SLIP pero prcticamente ha desaparecido.
13

96

configurar y probar el enlace de datos; cuando un enlace PPP ha sido establecido, el usuario es usualmente autenticado15. La autenticacin es un paso previo para comenzar la fase de control de protocolos de red. En PPP, la autenticacin puede ser implementada con PAP o CHAP16. Cabe resaltar que PAP enva las claves a travs del enlace en texto plano, mientras que CHAP es un protocolo de autenticacin un poco ms robusto ya que el usuario interacta con el sistema autenticador respondiendo acertadamente a un requerimiento de desafo (challenge) al host remoto, estos sistemas de autenticacin son llamados de tres vas. Despus de que el enlace ha sido establecido y varias opciones han sido negociadas por el protocolo LCP, PPP enva paquetes LCP para escoger y configurar uno o ms protocolos de capa de red. Despus de que cada uno de los protocolos de capa de red han sido configurados, los datagramas de cada uno de ellos pueden ser enviados sobre el enlace. PPTP depende del protocolo PPP para crear la conexin conmutada entre el cliente y el servidor de acceso a la red. PPTP confa las siguientes funciones a PPP: Establecimiento y finalizacin de la conexin fsica Autenticacin de los usuarios Creacin de datagramas PPP

Luego que el enlace PPP es creado, el protocolo PPTP define dos diferentes tipos de paquetes: paquetes de control y paquetes de datos, cada uno de los cuales es asignado a diferentes canales lgicos. PPTP separa los canales de control y de datos usando un flujo de control que
La autenticacin es una fase opcional en PPP pero por lo general es implementada por todas las ISPs para verificar la informacin de sus usuarios conmutados. 16 Ms informacin de estos protocolos se encuentra en el captulo 4 que habla sobre los sistemas de autenticacin
15

97

corre sobre TCP y un flujo de datos que est encapsulado con cabeceras IP usando GRE. La conexin TCP es creada entre el cliente y el servidor PPTP. Esta conexin es usada para intercambiar mensajes de control. Los paquetes de datos contienen los datos del usuario, es decir, los datagramas del protocolo de capa de red usado. Los paquetes de control son enviados peridicamente para indagar sobre el estado del enlace y las seales de manejo entre el cliente y el servidor PPTP. Los paquetes de control tambin se usan para enviar informacin de manejo bsica del dispositivo y de configuracin. Los mensajes de control establecen, mantienen y finalizan un tnel PPTP. Despus de que el tnel PPTP se ha establecido, los datos del usuario son transmitidos entre el cliente y el servidor PPTP. Estos datos son transmitidos en datagramas IP contenidos dentro de los paquetes PPP. Los datagramas IP son creados usando una versin modificada del protocolo GRE (Generic Routing Encapsulation); esta modificacin consiste en incluir un identificador de los host que puede ser usado para controlar los privilegios de acceso y la capacidad de reconocimiento, la cual es usada para monitorear la rata de transferencia a la cual los paquetes estn transmitindose en el tnel. La cabecera GRE es usada para encapsular el paquete PPP dentro del datagrama IP. La informacin til del paquete (Payload) es esencialmente el paquete PPP original enviado por el cliente. Dado que PPTP opera con un protocolo de capa 2, debe incluir una cabecera que depende del medio en el cual el tnel est transmitiendo, esta puede ser Ethernet, Frame Relay o PPP. La figura 5.2 muestra la estructura en los diferentes sitios de un tnel de un paquete IP usando encapsulacion PPTP desde el sistema cliente hasta la LAN corporativa. 98

Red Privada Virtual

Internet Sistema Cliente Servidor de Acceso Remoto (ISP) RAS con PPTP nativo

Cabecera del medio de entrega (varios tipos) Cabecera IP Cabecera PPP Cabecera GRE mejorada Carga til de paquete PPP Datagramas IP, IPX y NETBEUI

LAN corporativa

Trama Ethernet

Figura 5.2 Estructura de un tnel PPTP

5.1.2.

TUNELES

PPTP permite a los usuarios y a las ISPs crear varios tipos de tneles, basados en la capacidad del computador del usuario final y en el soporte de la ISP para implementar PPTP. De esta manera, el computador del usuario final determina el lugar de terminacin del tnel, bien sea en su computador, si est corriendo un cliente PPTP, o en el servidor de acceso remoto de la ISP, si su computador solo soporta PPP y no PPTP. En este segundo caso el servidor de acceso de la ISP debe soportar PPTP, a diferencia del primer caso, donde la ISP no se involucra en ningun proceso de entunelamiento de datos. Dado lo anterior, los tneles se pueden dividir en dos clases, voluntarios y permanentes. Los tneles voluntarios son creados por requerimiento de un usuario y para un uso especfico. Los tneles permanentes son creados

99

automticamente sin la accin de un usuario y no le permite escoger ningn tipo de privilegio. En los tneles voluntarios, la configuracin del mismo depende del usuario final, cuando se usan tneles de este tipo, el usuario puede simultneamente acceder a Internet y abrir un tnel seguro hacia el servidor PPTP. En este caso el cliente PPTP reside en el computador del usuario. Los tneles voluntarios proveen ms privacidad e integridad de los datos que un tnel permanente. La figura 5.3 muestra un escenario de tneles voluntarios creados desde dos clientes distintos a un mismo servidor PPTP a travs de Internet.

Intranet

Servidor PPTP

Internet Cliente PPTP A

Tnel PPTP Cliente PPTP B

Figura 5.3 Tneles Voluntarios

Los tneles permanentes son creados sin el consentimiento del usuario, por lo tanto, son transparentes para el mismo. El cliente PPTP reside en el servidor de acceso remoto de la ISP al que se conectan los usuarios finales. Todo el trfico originado desde el computador del usuario final es reenviado por el RAS sobre el tnel PPTP. En este caso la conexin del usuario se limita solo a la utilizacin del tnel PPTP, no hay acceso a la red pblica (Internet) sobre la cual se establece el tnel. Un tnel permanente PPTP permite que mltiples conexiones sean transportadas sobre el mismo tnel. La figura 5.4 muestra un tnel permanente entre un RAS

100

con capacidad para encapsular sesiones PPP usando PPTP y por medio del cual van multiplexadas dos sesiones de clientes A y B.

Intranet

Internet Servidor PPTP

Tnel PPTP

RAS con PPTP nativo

Figura 5.4 Tneles Permanentes

Dado que los tneles permanentes tienen predeterminados sus puntos finales y que el usuario no puede acceder a Internet, estos tneles ofrecen mejor control de acceso que los tneles voluntarios. Otra ventaja de los tneles permanentes, es que reducen el ancho de banda utilizado, ya que mltiples sesiones pueden ser transportadas sobre un nico tnel, a diferencia de los tneles voluntarios donde cada sesin tiene que trabajar con cabeceras independientes que ocupan un ancho de banda. Una desventaja de los tneles permanentes es que la conexin inicial, es decir, entre el usuario final y el servidor de acceso que esta actuando como cliente PPTP, no hace parte del tnel, por lo tanto, puede ser vulnerable a un ataque. Los tneles permanentes se dividen en estticos y dinmicos. Los tneles estticos son aquellos que requieren equipos dedicados y su configuracin es manual. En este tipo de tneles el usuario final tiene a su disposicin varios RAS, los cuales tienen establecidos diferentes tneles a diferentes 101

servidores PPTP. Por ejemplo, si un usuario necesita hacer una VPN a su oficina regional ubicada en la ciudad A tiene que marcar un nmero X, pero si ese mismo usuario quiere hacer una VPN con su oficina en una ciudad B, tiene que marcar un nmero Y. Los tneles permanentes dinmicos usan el nombre del usuario para determinar el tnel asociado con l, es decir que se encargan de aprovechar mejor los recursos y el usuario puede marcar al mismo nmero para establecer tneles a diferentes sitios. La informacin asociada con cada usuario puede residir en el servidor Radius en el cual ese servidor de acceso esta autenticando todas las conexiones. Claramente se observa que los tneles permanentes estticos son ms costosos que los dinmicos, ya que involucran un servidor de acceso por cada destino que un cliente VPN quiera alcanzar.

5.1.3.

ENTUNELAMIENTO LAN-to-LAN

Originalmente PPTP fue desarrollado pensando en brindar soluciones de acceso remoto VPN, es decir, proveer acceso conmutado seguro a redes locales corporativas va Internet. Los tneles LAN-to-LAN no fueron soportados en un comienzo. Solo hasta el ao 1997 cuando Microsoft introdujo su servicio de enrutamiento de acceso remoto (RRAS) para servidores NT 4.0, se pudieron implementar topologas LAN-to-LAN usando PPTP como protocolo de entunelamiento. La implementacin de Microsoft para entunelamiento LAN-to-LAN exige la presencia de dos servidores PPTP que tienen la funcin de hacer de gateways seguros de las dos redes locales. Sin embargo, la gran 102

desventaja de usar PPTP en topologas LAN-to-LAN es la inseguridad inherente a la arquitectura del protocolo. En efecto, la autenticacin y el cifrado son controlados por protocolos que ofrecen un nivel muy bajo de confiabilidad, como CHAP o MS-CHAP. La figura 5.5 muestra una topologa de red LAN-to-LAN entre una pareja de servidores PPTP usando un tnel PPTP sobre Internet, para los usuarios tanto de la LAN corporativa A como de la B el tnel es transparente, y a nivel lgico se trabaja como en una nica red local.

Internet
PAC LAN corporativa A Servidor de Acceso Remoto (ISP)

TNEL PPTP
PNS LAN corporativa B

Figura 5.5 Topologa LAN-to-LAN usando un tnel PPTP

Para crear un tnel entre dos sitios, un servidor PPTP es autenticado por el otro usando passwords simples, algo similar a un usuario conmutado. En este caso, uno de los sitios acta como el servidor PPTP y el otro como un cliente PPTP, de esta manera, un tnel voluntario es creado entre los dos extremos y por el mismo pueden existir varias sesiones. Dado que un tnel PPTP puede encapsular varios protocolos de capa de red, los usuarios no tendrn acceso a los recursos, que cada protocolo le provee hasta que sus privilegios sean validados por el correspondiente protocolo. Detalles prcticos para configurar una topologa LAN-to-LAN usando PPTP se vern en el captulo 6.

103

5.1.4. 5.1.4.1.

COMPONENTES DE UNA VPN PPTP Servidores PPTP

Un servidor PPTP tiene dos funciones bsicas: actuar como el punto final del tnel PPTP y reenviar los paquetes a y desde el computador en la red privada. Para reenviar los paquetes al computador destino, el servidor desencapsula el paquete PPTP obteniendo el nombre del computador o la direccin IP privada que se encuentra dentro de este. Una de las caractersticas de los servidores PPTP es la de poder filtrar nicamente el trfico PPTP dependiendo de si esta condicin aparece o no en el perfil del usuario, de esta manera, se puede restringir a un usuario para que se conecte a la red local o se conecte a Internet. Por lo general los servidores PPTP estn en las premisas de la red corporativa, en algunos casos el servidor PPTP est ubicado dentro de la red privada y est protegido por el firewall (zona militarizada). Cuando esto ocurre, es necesario abrir el puerto TCP 1723, o si el firewall permite filtrar no por puerto sino por protocolo, se deber permitir el protocolo GRE. 5.1.4.2. Software cliente PPTP

Como se dijo anteriormente, si el NAS de la ISP soporta PPTP no se necesita ningn software o hardware adicional en el extremo final del cliente, solamente que ste pueda establecer una conexin PPP. Por otro lado, si la ISP no soporta PPTP, el cliente deber utilizar un 104

software cliente PPTP en su computador para poder crear el tnel. Para esto primero deber establecer una conexin PPP marcando va modem a la ISP, y una vez sta est establecida, deber realizar una segunda conexin PPTP usando un puerto virtual provedo por el software cliente PPTP. Todos los sistemas operativos Windows 9517, Windows 98, Windows NT, Windows 2000 y Windows XP cuenta con un cliente PPTP nativo. Tambin existen clientes PPTP para Linux18 5.1.4.3. Servidores de Acceso de Red

Los servidores de acceso a la red tambin llamados servidores de acceso remoto o concentradores de acceso, son los encargados de soportar las conexiones PPP de una gran cantidad de clientes que se conectan a este por medio de enlaces telefnicos conmutados. Sus funciones van desde el establecimiento de la conexin fsica (modulacin, demodulacin, compresin de datos, correccin de errores, etc.) hasta labores de enrutamiento presentes en la capa 3 de la torre OSI. Dentro de un tnel PPTP se pueden encontrar NAS actuando como clientes PPTP o simplemente como un concentrador de acceso PPP.

En Windows 95 se requiere actualizar el acceso telefnico a redes a la versin 1.3, dicho software se encuentra disponible en el sitio de actualizaciones de Microsoft, http://www.microsoft.com/windows95/downloads/contents/WURecommended/S_WUNetworking/dun13wi n95/Default.asp 18 En http://pptpclient.sourceforge.net/ se encuentran versiones GNU de clientes PPTP para diferentes distribuciones de Linux
17

105

PPTP permite que las funciones realizadas por un servidor de acceso a la red (NAS) sean separadas usando una arquitectura cliente-servidor. Comnmente, las siguientes funciones son implementadas por un NAS: 1. Brindar una interfaz fsica entre la red telefnica pblica conmutada y los mdems. Esto incluye conversiones A/D y D/A, conversiones sncronas a asncronas y manipulaciones de flujos de datos. 2. Terminacin lgica de enlaces PPP. 3. Autenticacin de enlaces PPP. 4. Sumarizacin de canales (protocolo multilink PPP). 5. Terminacin lgica de protocolos de control de red (NCP). 6. Enrutamiento multiprotocolo y bridging. 7. PPTP divide estas funciones entre los dos componentes que se definen en el protocolo, a saber PAC y PNS. El PAC o concetrador de acceso PPTP es el responsable de las funciones 1, 2 y algunas veces 3. El PNS o servidor de red PPTP, es el responsable de las funciones 3, 4, 5 y 6. El protocolo PPTP es nica y exclusivamente implementado entre el PAC y el PNS. Un PAC puede atender muchos PNSs. Un nico PNS puede ser asociado a muchos PACs. 5.1.4.4. Estructura del Protocolo

PPTP define una conexin de control entre cada pareja PAC-PNS la cual opera sobre TCP; y un tnel IP operando sobre la misma pareja PAC-PNS el cual es usado para transportar paquetes PPP con encapsulamiento GRE. 5.1.4.5. Conexin de control 106

Antes que el entunelamiento PPP ocurra entre un PAC y un PNS, una conexin de control debe ser establecida entre ellos. La conexin de control es una sesin TCP que mantiene control sobre la llamada e intercambia mensajes de informacin. Por cada pareja PAC-PNS debe existir una conexin de control y un tnel. La conexin de control es la responsable por el establecimiento, el manejo y la liberacin de las sesiones que existen en el tnel. El PNS y el PAC establecen la conexin de control usando mensajes Start-Control-Connection-Request y Start-Control-Connection-Reply. Esos mensajes son tambin usados para intercambiar informacin bsica entre los dos extremos del tnel. La conexin de control puede comunicar cambios entre las dos partes con un mensaje Set-Link-Info. Una sesin puede ser liberada por el PAC o por el PNS. La conexin de control es mantenida a s misma por mensajes de eco keep-alive. Esto asegura que una falla en la conectividad entre el PNS y el PAC pueda ser detectada tempranamente. Otras fallas pueden ser reportadas por mensajes Wan-Error-Notify. PPTP define un conjunto de mensajes enviados como datos TCP en la conexin de control entre un PNS y un PAC. La sesin TCP es establecida hacia el puerto 1723. El puerto origen es asignado a cualquier nmero de puerto que no est siendo usado en el momento del establecimiento del tnel. Cada mensaje en la conexin de control PPTP comienza con una cabecera fija de ocho octetos, sta cabecera contiene la longitud total

107

del mensaje, un indicador del tipo de mensaje PPTP y una magic cookie. Los tipos de mensajes de control de conexin definidos por el protocolo PPTP son: mensajes de control y mensajes de gestin; stos ltimos an no se encuentran definidos y se han reservado para aplicaciones futuras. La magic cookie es la constante 0x1A2B3C4D. Su funcin bsica es asegurarle al receptor que est sincronizado con el flujo de datos TCP. La prdida de sincronizacin no conlleva a una resincronizacin, sino a un cierre inmediato de la sesin TCP de la conexin de control. Los mensajes de control definidos por el protocolo PPTP son: Gestin de la conexin de control Start-Control-Connection-Request Start-Control-Connection-Reply Stop-Control-Connection-Request Stop-Control-Connection-Reply Echo-Request Echo-Reply Gestin de la llamada Outgoing-Call-Request Outgoing-Call-Reply Incoming-Call-Request Incoming-Call-Reply Incoming-Call-Connected Call-Clear-Request 108

Call-Disconnect-Notify Reporte de errores WAN-Error-Notify Control de la sesin PPP Set-Link-Info

5.1.4.6.

Operacin del Tnel

PPTP necesita el establecimiento de un tnel por cada pareja PNS-PAC. Este tnel se utiliza para transportar todos los paquetes PPP de las diferentes sesiones involucradas en la pareja PNS-PAC. Una clave que se encuentra presente en la cabecera GRE indica qu paquetes PPP pertenecen a qu sesin. De sta manera, los paquetes PPP son multiplexados y

desmultiplexados sobre un nico tnel existente entre una pareja PNSPAC. El valor del campo Clave es definido dentro del proceso de establecimiento de la llamada. La cabecera GRE tambin contiene informacin de reconocimiento y de secuencializacin con la cual se realiza control de congestin y deteccin de errores en el tnel. Los datos del usuario transportados por el protocolo PPTP son esencialmente paquetes de datos PPP. Los paquetes PPP son transportados entre el PAC y el PNS, encapsulados en paquetes GRE los cuales a su vez son transportados sobre IP. Los paquetes 109

encapsulados PPP son esencialmente paquetes de datos PPP sin ningn elemento de tramado de medio especfico. Los paquetes IP transmitidos sobre los tneles entre un PAC y un PNS tienen la estructura general que se muestra en la figura 5.6

Medio

IP

GRE

PPP

Carga til PPP

Figura 5.6 Estructura general de un paquete IP encapsulado PPTP

5.1.4.6.1.

Cabecera Mejorada GRE

La cabecera GRE usada por PPTP es una versin ligeramente mejorada de la especificacin estndar del protocolo GRE. La principal diferencia es la definicin de un nuevo campo de reconocimiento de nmero (Acknowledgment Number), usado para determinar si un paquete particular GRE o un conjunto de paquetes ha arribado al lado remoto del tnel. Esta capacidad de reconocimiento no es usada en conjunto con ningn tipo de retransmisin, en vez de eso, se usa para determinar la rata de transferencia a la cual los paquetes de datos del usuario son transmitidos sobre el tnel.

5.2.

L2TP (Layer 2 Tunneling Protocol)

L2TP [REF5.4] fue creado como el sucesor de PPTP y L2F. Las dos compaas abanderadas de cada uno de estos protocolos, Microsoft por PPTP y Cisco por L2F, acordaron trabajar en conjunto para la creacin de un nico protocolo de capa 2 y as lograr su estandarizacin por parte de la IETF.

110

Como PPTP, L2F fue diseado como un protocolo de entunelamiento usando para ello encapsulamiento de cabeceras. Una de las grandes diferencias entre PPTP y L2F, es que el entunelamiento de ste ltimo no depende de IP y GRE, permitindole trabajar con otros medios fsicos por ejemplo Frame Relay. Paralelamente al diseo de PPTP, L2F utiliz PPP para autenticacin de usuarios accesando va telefnica conmutada, pero tambin incluy soporte para TACACS+ y Radius. Otra gran diferencia de L2F con respecto a PPTP es que permite que un nico tnel soporte ms de una conexin. Hay dos niveles de autenticacin del usuario: primero, por la ISP antes de crear el tnel; segundo, cuando la conexin est configurada y la autenticacin la realiza el gateway corporativo. Todas las anteriores caractersticas de L2F han sido transportadas a L2TP. Como PPTP, L2TP utiliza la funcionalidad de PPP para proveer acceso conmutado que puede ser tunelizado a travs de Internet a un sitio destino. Sin embargo, como se ha mencionado anteriormente, L2TP define su propio protocolo de entunelamiento basado en L2F permitiendo transporte sobre una amplia variedad de medios de empaquetamiento tales como X.25, Frame Relay y ATM.

Dado que L2TP es un protocolo de capa 2, ofrece a los usuarios la misma flexibilidad de PPTP de soportar otros protocolos aparte de IP, tales como IPX y NETBEUI. Puesto que L2TP usa PPTP en enlaces conmutados, incluye mecanismos de autenticacin nativos de PPP como PAP y CHAP.

111

Microsoft incluye L2TP a partir del sistema operativo Windows 2000, ya que las mejoras de L2TP con respecto a PPTP saltan a la vista.

5.2.1. 5.2.1.1.

COMPONENTES BSICOS DE UN TNEL L2TP Concentrador de acceso L2TP (LAC)

Un LAC es un nodo que se encuentra en un punto extremo de un tnel L2TP. El LAC se encuentra entre un LNS y un sistema remoto y reenva los paquetes a y desde cada uno. Los paquetes enviados desde el LAC hasta el LNS van tunelizados. En algunas ocasiones el sistema remoto acta como un LAC, esto se presenta cuando se cuenta con un software cliente LAC.

5.2.1.2.

Servidor de Red L2TP (LNS)

Un LNS es un nodo que se encuentra en un punto extremo de un tnel L2TP y que interacta con el LAC, o punto final opuesto. El LNS es el punto lgico de terminacin de una sesin PPP que est siendo tunelizada desde un sistema remoto por el LAC.

5.2.1.3.

Tnel

Un Tnel existe entre una pareja LAC-LNS. El tnel consiste de una conexin de control y de ninguna o ms sesiones L2TP. El tnel transporta datagramas PPP encapsulados y mensajes de control entre el LAC y el LNS.

112

5.2.2.

TOPOLOGA DE L2TP

La figura 5.7 describe un escenario tpico L2TP. El objetivo es tunelizar tramas PPTP entre un sistema remoto o un cliente LAC y un LNS localizado en la LAN corporativa.

Cliente LAC

LAN CORPORATIVA Host

LAC

INTERNET

LNS

Sistema Remoto

Red Telefnica Conmutada Pblica

LAN CORPORATIVA Host

LAC

Nube Frame Relay o ATM

LNS

Figura 5.7 Distintos escenarios de tneles L2TP

El sistema remoto inicia una conexin PPP a travs de la red de telefona pblica conmutada a un LAC. El LAC luego tuneliza la conexin PPP a travs de Internet o una nube Frame Relay o ATM a un LNS por donde accesa a la LAN remota corporativa. La direccin del sistema remoto es dada desde la LAN corporativa por medio de una negociacin PPP NCP. La autenticacin, autorizacin y acounting puede ser provista por el dominio de la red corporativa remota como si el usuario estuviera conectado a un servidor de acceso de la red directamente.

113

Un cliente LAC (un host que corre L2TP nativo) puede tambin crear un tnel hasta la LAN corporativa sin usar un LAC externo. En este caso, el host tiene un software cliente LAC y previamente ha estado conectado a la red pblica, tal como Internet. Una conexin PPP virtual es luego creada y el software cliente LAC hace un tnel hasta el cliente LNS. Como en el caso anterior, el direccionamiento, la autenticacin, la autorizacin y el acounting pueden ser provistos por el dominio de la LAN corporativa remota.

5.2.3.

ESTRUCTURA DEL PROTOCOLO L2TP

L2TP utiliza dos tipos de mensajes, Los mensajes de control y los mensajes de datos. Los mensajes de control son usados en el establecimiento, mantenimiento y finalizacin de tneles y llamadas. Los mensajes de datos son usados para encapsular tramas PPP que est siendo transportadas sobre el tnel. Los mensajes de control utilizan un canal de control confiable con el cual L2TP garantiza la entrega. Los mensajes de datos no son retransmitidos cuando ocurren prdidas de paquetes. La figura 5.8 muestra la relacin de las tramas PPP y los mensajes de control con los canales de datos y control L2TP respectivamente. Las tramas PPP son transportadas sobre un canal de datos no confiable y son encapsuladas primero por una cabecera L2TP y luego por una cabecera de transporte de paquetes que pueden ser UDP, Frame Relay o ATM. Los mensajes de control son enviados sobre un canal de control L2TP confiable, el cual transmite paquetes en banda sobre el mismo transporte de paquetes. Para esto se requiere que nmeros de secuencia estn presentes en todos los mensajes de control. Los mensajes de datos 114

pueden usar esos nmeros de secuencia para reordenar paquetes y detectar prdidas de los mismos.
Tramas PPP Mensajes de datos L2TP Canal de datos L2TP (no

Mensajes de control L2TP Canal de control L2TP

confiable) (confiable) Transporte de paquetes (UDP, Frame Relay, ATM, etc.)


Figura 5.8 Estructura del protocolo L2TP

5.2.3.1.

Formato De Una Cabecera L2TP

Los paquetes L2TP para el canal de control y el canal de datos comparten un formato de cabecera comn. La figura 5.9 muestra el formato de una cabecera L2TP.
T L x x S c O P x x x x Ver Tunnel ID Ns (Opc) Offset Size(Opc) Length (Opc) Session ID Nr (Opc) Offset padding (Opc)

Figura 5.9 Formato de una cabecera L2TP

El bit T (type), indica el tipo de mensaje, es 0 para un mensaje de datos y 1 para un mensaje de control. Si el bit L (length) es 1, el campo Longitud est presente. Este bit debe estar puesto en 1 para los mensajes de control. Los bits x son reservados para futuras extensiones. Todos los bits reservados deben ser puestos en 0 para los mensajes salientes y deben ser ignorados por el receptor.

115

Si el bit S (sequence) de Secuencia (S) esta puesto en 0, el Ns y Nr estn presentes. El bit S debe estar puesto en 1 para los mensajes de control. Si el bit O (Offset) es 1, el campo de tamao Offset est presente. El bit O debe ser puesto en 0 para los mensajes de control. Si el bit P (Priority) es 1, los mensajes de datos deben recibir un trato preferencial en las colas locales y en la transmisin. Los requerimientos echo LCP usados como keepalive para el enlace deben generalmente ser enviados con este bit puesto en 1 dado que un intervalo de tiempo grande originado por una conexin local puede originar una demora en los mensajes keepalive ocasionando una prdida innecesaria del enlace. Esta caracterstica es solamente usada por los mensajes de datos. El bit P debe ser puesto en 0 para todos los mensajes de control. El campo Ver debe ser 2 e indicar la versin de la cabecera L2TP de los mensajes de datos. Los paquetes recibidos con un campo Ver desconocido deben ser descartados. El campo Length indica la longitud total del mensaje en octetos. El campo Tunnel ID sirve como identificador para el control de conexin. Los tneles L2TP son nombrados por identificadores que tienen significado local nicamente. Es decir, el mismo tnel. El campo Session ID indica el identificador para una sesin dentro del tnel. Al igual que los identificadores de tnel, las sesiones L2TP son nombradas por identificadores que tienen nicamente significado local. 116

El campo Ns indica el nmero de secuencia para los mensaje de datos y de control. El campo Nr indica el nmero de secuencia esperado en el siguiente mensaje de control a ser recibido. En los mensajes de datos el campo Nr es reservado, y si es presente debe ser ignorado. Si el campo Offset Size est presente, especifica el nmero de octetos despus de la cabecera L2TP, a partir de los cuales la carga til de datos es esperada a que inicie o a que se encuentre.

5.2.3.2.

TIPOS DE MENSAJES DE CONTROL

El protocolo L2TP define los siguientes tipos de mensajes de control para la creacin, mantenimiento y finalizacin del tnel. Manejo de la conexin de control 0 1 2 3 4 5 6 (reserved) (SCCRQ) (SCCRP) (SCCCN) (StopCCN) (reserved) (HELLO) Hello Start-Control-Connection-Request Start-Control-Connection-Reply Start-Control-Connection-Connected Stop-Control-Connection-Notification

Manejo de la llamada 7 8 (OCRQ) (OCRP) Outgoing-Call-Request Outgoing-Call-Reply 117

9 10 11 12 13 14

(OCCN) (ICRQ) (ICRP) (ICCN) (reserved)

Outgoing-Call-Connected Incoming-Call-Request Incoming-Call-Reply Incoming-Call-Connected

(CDN) Call-Disconnect-Notify

Reporte de errores 15 (WEN) WAN-Error-Notify

Control de la sesin PPP 16 (SLI) Set-Link-Info

5.2.4.

OPERACIN DEL PROTOCOLO

Para tunelizar una sesin PPP con L2TP se necesita llevar a cabo dos pasos, el primero, el establecimiento de una conexin de control para el tnel y el segundo, el establecimiento de una sesin respondiendo al requerimiento de una llamada entrante o saliente. El tnel y su correspondiente conexin de control deben ser establecidos antes que una llamada entrante o saliente sea iniciada. Una sesin L2TP debe ser establecida antes que L2TP pueda empezar a tunelizar tramas PPP. Mltiples sesiones pueden existir a travs de un tnel nico y mltiples tneles pueden existir entre el mismo LAC y LNS. La figura 5.10 ilustra la relacin que puede existir entre un LAC y un LNS, claramente se notan los puntos terminales de un enlace PPP de una sesin L2TP, de una conexin de control L2TP y del tnel en s.

118

TNEL L2TP
Conexin de Control L2TP Llamada telefnica

LAC
Sesin L2TP Enlace PPP

LNS

Sistema Remoto

Llamada telefnica Enlace PPP

Sesin L2TP

Sistema Remoto

Figura 5.10 Entunelamiento de tramas PPP usando L2TP

5.2.4.1.

Establecimiento de la Conexin de Control

La conexin de control es la conexin inicial que debe llevarse a cabo entre un LAC y un LNS antes que puedan crearse sesiones a travs de sta. El establecimiento de la conexin de control incluye la verificacin de la identidad del extremo remoto entre otros. Un intercambio de tres mensajes como se muestra en la figura 5.11 es utilizado para configurar la conexin de control.

SCC RQ

LAC o LNS

R SCC

SCC CN
ACK ZLB

LAC o LNS

Figura 5.11 Establecimiento de una conexin de control

El ZLB ACK es enviado si no hay ms mensajes esperando en cola para ese extremo.

119

5.2.4.2.

Autenticacin del Tnel

L2TP incorpora un sistema de autenticacin simple y opcional parecido a CHAP durante el establecimiento de la conexin de control. Si un LAC o LNS desea autenticar la identidad de su pareja, ste le enva un challenge en el mensaje SCCRQ o SCCRP, a lo cual su pareja responde con un challenge response, el cual debe ser enviado en el SCCRP o SCCCN respectivamente. Si la respuesta enviada y la respuesta recibida de su pareja no concuerdan, el establecimiento del tnel no debe ser permitido.

5.2.4.3.

Establecimiento de la Sesin

Despus del establecimiento exitoso de la conexin de control, sesiones individuales pueden ser creadas. Cada sesin corresponde a un nico stream PPP entre el LAC y el LNS. A diferencia del establecimiento de la conexin de control, el establecimiento de la sesin es direccional con respecto al LAC y al LNS. El LAC solicita al LNS aceptar una sesin para una llamada entrante, y el LNS solicita a el LAC aceptar una sesin para una llamada saliente. 5.2.4.3.1. Establecimiento de una Llamada Entrante

La figura 5.12 muestra la secuencia tpica de intercambio de tres mensajes para configurar la sesin.

120

Llamada Entrante

ICRQ
ICRP

LAC

IC C N
ACK ZLB

LNS

Figura 5.12 Establecimiento de una llamada entrante

El ZLB ACK es enviado si no hay ms mensajes esperando en cola para la pareja remota. 5.2.4.3.2. Establecimiento de una Llamada Saliente

La figura 5.13 muestra la secuencia tpica de intercambio de tres mensajes para configurar la sesin.

Q OCR

OCR P OCC N
ACK ZLB

LAC

LNS

Figura 5.13 Establecimiento de una llamada saliente

El ZLB ACK es enviado si no hay ms mensajes esperando en cola para la pareja remota.

5.2.4.4.

Reenvo de Tramas PPP

Una vez el establecimiento del tnel se ha completado, las tramas PPP desde el sistema remoto son recibidas en el LAC, encapsuladas en

121

L2TP y reenviadas sobre el tnel apropiado. El LNS recibe el paquete L2TP y procesa la trama PPP encapsulada como si fuera recibida en una interfaz PPP local. El emisor de un mensaje asociado con una sesin y un tnel particular, coloca el identificador de sesin y de tnel en los campos Session ID y Tunnel ID de la cabecera para todos los mensajes salientes. De sta manera, las tramas PPP son multiplexadas y desmultiplexadas sobre un nico tnel entre una pareja LNS-LAC. El valor de 0 para el Session ID y Tunnel ID es especial y no debe ser usado. Para los casos donde el Session ID no ha sido an asignado (por ejemplo durante el establecimiento de una nueva sesin o tnel), el campo Session ID debe ser enviado como 0, igualmente, para los casos donde el Tunnel ID an no ha sido asignado desde el nodo remoto.

5.2.4.5.

Uso de Nmeros de Secuencia en el Canal de Datos

Los nmero de secuencias son definidos en la cabecera L2TP para los mensajes de control y opcionalmente para los mensajes de datos. Estos son usados para proveer un transporte confiable para los mensajes de control y una secuencializacin opcional para los mensajes de datos. Cada nodo mantiene una secuencia de nmeros diferentes para la conexin de control y para cada sesin de datos individual dentro del tnel.

122

A diferencia del canal de control L2TP, el canal de datos no usa nmeros de secuencia para retransmitir mensajes de datos perdidos, en vez de stos, los mensajes de datos pueden usar nmeros de secuencia para detectar paquetes perdidos y/o restaurar la secuencia original de paquetes que se ha perdido durante el transporte. El LAC, le puede solicitar al LNS que la secuencia de nmeros est presente en los mensajes de datos. El LNS controla el envo o no de la secuencia de nmeros, si el LAC recibe mensajes de datos sin la secuencia de nmeros presente, ste deber parar cualquier secuencia de datos futura. Si el LAC recibe mensajes de datos con una secuencia de nmeros presente, este deber comenzar a enviar nmeros de secuencia en todos los mensajes de datos salientes futuros. Estos procesos de habilitar o deshabilitar la secuencia de nmeros puede ocurrir en cualquier momento de la transferencia de paquetes. Es recomendable activar esta caractersticas en todos los LNS para asegurar un correcto ordenamiento de todos los paquetes entrantes.

5.2.4.6.

Keepalive (Hello)

Un mecanismo de keepalive es empleado por L2TP para diferenciar periodos de tiempo fuera de periodos extensos de no control o inactividad de datos en el tnel. Esto se realiza enviando mensajes de control Hello despus de que un periodo de tiempo especfico ha transcurrido desde que el ltimo mensaje de control o de datos fue recibido en el tnel. Como con cualquier otro mensaje de control, si el mensajes Hello no es recibido oportunamente el tnel es declarado down y es reconfigurado. Con este mecanismo se asegura que cualquier falla de conectividad entre el LNS y el LAC sea detectada oportunamente por ambos lados del tnel. 123

5.2.4.7.

Terminacin de la Sesin

Tanto el LAC como el LNS pueden terminar una sesin, esto se logra por medio de un mensaje de control CDN, la figura 5.14 es un ejemplo tpico del intercambio de mensajes de control para terminar una sesin.

CDN ( Clea n Up )

LAC o LNS

ACK ZLB ) n Up ( Clea

LAC o LNS

Figura 5.14 Terminacin de la sesin

5.2.4.8.

Terminacin de la Conexin de Control

Al igual que con una sesin, la conexin de control puede ser finalizada por el LAC o por el LNS, esto se logra enviando un mensaje de control StopCCN. La figura 5.15 ilustra el intercambio de mensajes de control entre un LAC y un LNS necesarios para terminar una conexin de control.

124

Stop C ( Clea CN n Up )

LAC o LNS

ACK ZLB er a) (Esp Up) lean (C

LAC o LNS

Figura 5.15 Terminacin de la conexin de control

Para terminar el tnel y todas las sesiones en l, es necesario solamente en envo de un StopCCN, no se necesita bajar sesin por sesin individualmente.

5.3.

IPSEC

En IPv4 no se desarrollaron mecanismos de seguridad inherentes al protocolo, por tanto, protocolos y procedimientos adicionales a IPv4 fueron necesarios para brindar servicios de seguridad a los datos. IPSec [REF5.5] es un conjunto de protocolos diseados para proveer una seguridad basada en criptografa robusta para IPv4 e IPv6, de hecho IPSec est incluido en IPv6. Entre los servicios de seguridad definidos en IPSec se encuentran, control de acceso, integridad de datos, autenticacin del origen de los datos, proteccin antirepeticin y confidencialidad en los datos. Entre las ventajas de IPSec estn la modularidad del protocolo, ya que no depende de un algoritmo criptogrfico especfico.

125

5.3.1.

COMPONENTES DE IPSEC

IPSec est compuesto por tres componentes bsicos: los protocolos de seguridad (AH y ESP), las asociaciones de seguridad (SAs) y las bases de datos de seguridad; cada uno de los cuales, trabaja de la mano con los dems y ninguno le resta importancia al otro. 5.3.1.1. Protocolos de Seguridad

IPSec es un conjunto de protocolos que provee varios servicios de seguridad. Esos servicios de seguridad trabajan gracias a dos protocolos, el Authentication Header (AH) [REF5.6] y el Encapsulating Security Payload (ESP) [REF5.7], y tambin al uso de protocolos y procedimientos para el manejo de llaves criptogrficas tales como IKE (Internet Key Exchange Protocol) [REF5.8]. El xito de una implementacin IPSec depende en gran medida de una adecuada escogencia del protocolo de seguridad y de la forma como se intercambian las llaves criptogrficas. AH es un protocolo que aade una nueva cabecera justo despus de la cabecera IP original. AH provee autenticacin del origen de los datos e integridad de los mismos, tambin provee integridad parcial para prevenir ataques de repeticin. Este protocolo es apropiado cuando se requiere autenticacin en vez de confidencialidad. ESP provee confidencialidad para el trfico IP, al igual que autenticacin tal cual como lo hace AH, pero solo uno de estos servicios puede ser proporcionado por ESP al mismo tiempo.

126

IKE es un protocolo que permite a dos entidades IPSec negociar dinmicamente sus servicios de seguridad y sus llaves de cifrado al igual que la autenticacin de la sesin misma 5.3.1.2. Asociaciones de Seguridad (SAs)

El concepto de asociacin de seguridad (SA) es clave en IPSec. Una SA define las medidas de seguridad que deberan ser aplicadas a los paquetes IP basados en quin los enva, hacia donde van y qu tipo de carga til ellos transportan. El conjunto de servicios de seguridad ofrecidos por una SA dependen de los protocolos de seguridad y del modo en el cual ellos operan definidos por la SA misma. La figura 5.16 muestra los dos modos en los cuales un protocolo de seguridad puede operar: transporte y tnel; la diferencia radica en la manera como cada uno de ellos altera el paquete IP original. El modo de transporte es diseado para proteger los protocolos de capas superiores tales como TCP y UDP. En modo tnel, el paquete IP original se convierte en la carga til de un nuevo paquete IP. Esto le permite al paquete IP inicial, ocultar su cabecera IP para que sea encriptada, considerando que el paquete IP externo sirve de gua a los datos a travs de la red.
Paquete IP Modo Transporte Cabecera IP original Carga til

Cabecera IP original

Cabecera de Seguridad Paquete IP

Carga til

Modo Tnel

Cabecera IP original

Carga til

Nueva Cabecera IP

Cabecera de Seguridad

Cabecera IP original Paquete IP

Carga til

Encapsulacin

Figura 5.16 Estructura del paquete IP en modo de Transporte y Tnel

127

Las

SAs

pueden

ser

negociadas

entre

dos

entidades

IPSec

dinmicamente, para lo cual se basan en polticas de seguridad dadas por el administrador del sistema o estticamente especificadas por el administrador directamente. Una SA es nicamente identificada por tres parmetros: una direccin IP de destino, un identificador del protocolo de seguridad y un ndice del parmetro de seguridad (SPI). La direccin IP de destino es aquella por la cual se identifica el punto final de la SA, el SPI es un nmero de 32 bits usualmente escogido por el punto final de destino de la SA y que solo tiene significado local dentro de ese punto destino. El identificador del protocolo de seguridad es un nmero con el cual se define cada uno de ellos, 51 para AH o 50 para ESP. Como se nota, la direccin IP del origen no se usa para definir una SA, esto dado que una SA se define entre dos host o gateways para datos enviados en una sola direccin, de aqu que, si dos dispositivos necesitan intercambiar informacin en ambas direcciones usando IPSec, requerirn de dos SAs, una para cada sentido. En modo de transporte, la cabecera IP original se mantiene intacta y una cabecera de seguridad es colocada entre la cabecera IP misma y su carga til. La cabecera IP original es modificada para que el receptor del paquete entienda que antes de la carga til se encuentra una cabecera de seguridad. En modo tnel, el paquete IP original se convierte en la carga til de un paquete IP encapsulado. La cabecera IP nueva le indica al receptor del paquete que una cabecera de seguridad se encuentra a continuacin de ella. 128

Varias SAs pueden ser aplicadas en serie para incrementar los servicios de seguridad del trfico IP. En estas situaciones una SA es encerrada por otra. El protocolo IPSec define dos formas: transporte adyacente y tneles iterados. En transporte adyacente se usan tanto AH como ESP y ellos son aplicados por el mismo host. Es de anotar que trabajar con adyacencias de transporte AH sobre AH o ESP sobre ESP no trae beneficios adicionales. Lo deseable en este caso es aplicar AH despus de ESP. En tneles iterados, se puede combina cualquier cantidad de tneles con lo cual se logra proveer de capas anidadas de seguridad. Los puntos finales del tnel pueden ser en la misma o en diferentes locaciones. Por ejemplo, un tnel host-to-host puede ser entunelado por un tnel gateway-to-gateway; y un tnel gateway-to-gateway puede de nuevo ser entunelado por otro tnel gateway-to-gateway. 5.3.1.3. Bases de Datos de Seguridad

IPSec trabaja con dos bases de datos de seguridad, en una se encuentran las polticas de seguridad y en la otra las asociaciones de seguridad, SPD (Security Policy Database) y SAD (Security Association Database) respectivamente. El administrador de polticas define un conjunto de servicios de seguridad para ser aplicados al trfico IP tanto entrante como saliente. Esas polticas son guardadas en las SPDs y son usadas por las SAs cuando stas se crean. Todas las SAs son registradas en la SAD.

129

5.3.1.3.1.

Bases de Datos de Asociaciones de Seguridad (SAD)

La base de datos de asociaciones de seguridad almacena todos los parmetros concernientes a las SAs, cada una de ellas tiene una entrada en la SAD donde se especifican todos los parmetros necesarios para que IPSec realice el procesamiento de paquetes IP que son gobernados por esa SA. Entre los parmetros que se encuentran en una SAD se tienen: El ndice de parmetro de seguridad. El protocolo a ser usado por la SA (ESP o AH). El modo en el cual el protocolo es operado (tnel o transporte). Un contador numrico secuencial. La direccin IP fuente y destino de la SA. El algoritmo de autenticacin y la llave de autenticacin usadas. El algoritmo de cifrado y su llave. El tiempo de vida de las llaves de autenticacin y de cifrado. El tiempo de vida de la SA.

Para el procesamiento de los paquetes IP entrantes una SA apropiada es encontrada en la SAD tal que concuerde con los siguientes tres valores: la direccin IP destino, el tipo de protocolo IPSec y el SPI. La direccin IP de destino y el tipo de protocolo IPSec son obtenidos de la cabecera IP y el SPI se obtiene de la cabecera AH o ESP. Si una SA es encontrada para el paquete IP entrante en mencin, ste es procesado de acuerdo a los servicios de seguridad especificados. Luego se aplican al paquete todas las reglas descritas en la SPD para la SA que lo gobierna. 130

Para el procesamiento de paquetes IP salientes, primero se aplica el procesamiento relacionado con la SPD. Si se encuentra una poltica para el paquete de salida que especifique que un procesamiento IPSec es necesario, la SAD es buscada para determinar si una asociacin de seguridad ha sido previamente establecida. Si una entrada es encontrada, el paquete es procesado de acuerdo a la SA. Si por lo contrario no se encuentra ninguna entrada para este paquete una nueva SA es negociada y luego guardada en la SAD. 5.3.1.3.2. Base de datos de Polticas de

Seguridad Una base de datos de polticas de seguridad es una lista ordenada de polticas de seguridad a ser aplicadas a los paquetes IP. Dichas polticas son en general reglas que especifican como los paquetes IP deben ser procesados. La SPD es mantenida por el administrador del dispositivo IPSec. Una entrada SPD tiene dos componentes: un juego de selectores y una accin. Los selectores clasifican un paquete IP sobre una accin. Un selector es un parmetro y el valor o rango de valores para ste parmetro. Los parmetros generalmente se encuentran dentro de una de stas dos categoras: Aquellos que se encuentran dentro de un paquete IP, tales como, la direccin IP, nmero de protocolo y nmeros de puertos de capas superiores. Aquellos que se derivan de la credencial de autenticacin de una entidad de comunicacin, tales como, una direccin de 131

correo o un nombre distinguido DN (Distinguished Names) en certificados digitales Diferentes operadores lgicos como AND, OR y NOT pueden ser aplicados a las polticas para combinar ms de un selector. Cuando un paquete IP contiene valores que concuerdan con los especificados por algn selector de una entrada, la accin que se especifica en dicha entrada es aplicada al paquete. Hay tres opciones: aplicar el servicio de seguridad IPSec, descartar el paquete IP o permitir que el paquete IP omita el procesamiento IPSec. La figura 5.17 muestra una entrada en una base de datos de polticas de seguridad para un paquete entrante y saliente, claramente se notan las partes que componen un selector como lo son los parmetros y su correspondiente valor, al frente se encuentra la accin que IPSec tomara si los paquetes IP concuerdan con los valores de los selectores.

Entrantes

Selectores
direccin_IP fuente = 10.0.0.92 AND direccin de e-mail fuente = financiera@telesat.com.co nombre_distinguido fuente = Andrs Gmez direccin_IP destino = 192.89.0.169

Accin
IPSec (ESP, 3DES, HMAC-SHA-1) IPSec (ESP, 3DES, HMAC-MD5) Omitir

Salientes

Selectores
direccin_IP destino = 10.0.0.92 nombre_distinguido destino = Andrs Gmez direccin_IP fuente = 192.89.0.169

Accin
IPSec (ESP, 3DES, HMAC-SHA-1) IPSec (ESP, 3DES, HMAC-MD5) Omitir

Figura 5.17 Ejemplos de entradas en una base de datos de polticas de seguridad

132

Es posible que un paquete IP concuerde con ms de una entrada en la SPD. Por esto, se debe tener en cuenta el orden de las entradas en una SPD, ya que la primera concordancia ser la poltica seleccionada. En adicin, una poltica por defecto debe ser aplicada para el nodo y sta se aplica cuando el paquete IP no concuerda con ninguna de las entradas de una SPD. Usualmente, esta poltica por defecto es descartar el paquete IP. La SPD trata al trfico saliente y entrante de manera separada, esto es, que se deben aplicar polticas de seguridad distintivas de entrada y de salida por cada interfaz de red. Cuando un paquete IP llega a una interfaz de red, IPSec primero busca en la SAD la apropiada SA, cuando la encuentra, el sistema inicia los procesos SAD y SPD. Despus del procesamiento SPD, el sistema reenva el paquete al siguiente salto o le aplica procedimientos adicionales tales como las reglas de algn firewall. El procesamiento PSD se realiza primero en paquetes salientes. Si la entrada SPD que concuerda especifica que un procesamiento IPSec es necesario, la SAD es consultada para determinar si una SA ha sido previamente establecida, en caso contrario se negocia una nueva SA para el paquete. Dado que los procesos SPD son realizados tanto para los paquetes IP salientes como entrantes, este procedimiento puede alterar negativamente el desempeo de un dispositivo IPSec. De hecho, el procesamiento SPD es el cuello de botella ms representativo en una implementacin IPSec.

133

5.3.2.

AUTHENTICATION HEADER (AH)

El protocolo de cabecera de autenticacin AH es usado para propsitos de autenticacin de la carga til IP a nivel de paquete por paquete, esto es autenticacin de la integridad de los datos y de la fuente de los mismos. Como el trmino autenticacin indica, el protocolo AH se asegura que los datos entregados dentro del paquete IP son autnticos, es decir, que han arribado a su destino sin ninguna modificacin. AH tambin provee de un mecanismo de proteccin opcional antirepeticin de paquetes IP. Sin embargo, AH no protege la confidencialidad de los datos, es decir, no recurre a ningn tipo de cifrado de los mismos. El protocolo AH define como un paquete IP sin proteccin es convertido en uno nuevo que contiene informacin adicional y que brinda autenticacin. El elemento fundamental usado por AH es una cabecera de autenticacin como se muestra en la figura 5.18. El nuevo paquete IP es formado insertando la cabecera de autenticacin, bien sea, despus de la nueva cabecera IP o despus de la cabecera IP original modificada segn sea el modo en el cual trabaje la SA, ms adelante se tratara con mayor detalle cada uno de estos dos modos: transporte y tunel. Cuando la cabecera de autenticacin es insertada, la cabecera IP que la precede deber indicar que la prxima cabecera que se encuentra es la cabecera de autenticacin y no la carga til del paquete original. La cabecera IP realiza esta accin colocando el campo Protocolo en el valor 51 (valor de protocolo para AH).

134

Next Header (8 bits)

Payload Len (8 bits) Reserved (16 bits) Security Parameter Index (SPI) (32 bits) Sequence Number (32 bits) Authentication Data (variable)

32 bits
Figura 5.18 Formato de la cabecera de autenticacin

La cabecera de autenticacin contiene seis campos: a. Next Header: El campo Next Header es un campo de ocho bits que identifica el tipo de protocolo de la carga util del paquete IP original. b. Payload Len: El campo Payload Len es un campo de ocho bits que especifica la longitud de la cabecera de autenticacin (no confundir con la cabecera original del paquete IP). c. Reserved: El campo Reserved se encuentra reservado para uso futuro, actualmente debe ser puesto en 0. d. Security Parameter Index: El campo Security Parameter Index es un nmero arbitrario de 32 bits. Este valor es usado junto con la direccin IP de destino y el tipo de protocolo IPSec (en este caso, AH) nicamente para identificar la SA para este paquete IP. El valor SPI es escogido por el sistema destino cuando la SA es establecida. e. Sequence Number: El campo Sequence Number es un campo de 32 bits que mantiene un incremento monotnico de la secuencia de paquetes IPSec. Comienza en 0 cuando la SA es establecida y se incrementa por cada paquete IP saliente que usa esta SA. Este campo se usa como un mecanismo de proteccin antirepeticin. f. Authentication Data: El campo Authentication Data es un campo de longitud variable que contiene el valor de chequeo de integridad ICV (Integrity Check Value) para este paquete IP. El ICV es calculado con el algoritmo seleccionado por la SA y es usado por el recepto para verificar la integridad del paquete IP entrante. Los 135

algoritmos por defecto requeridos por AH para trabajar son HMAC con MD5 y SHA-1. Hay que tener en cuenta, que la autenticacin no puede ser aplicada sobre la cabecera entera del paquete IP, ya que algunos campos de la cabecera IP original cambian durante el transito por Internet. Esos campos son llamados Campos Mutables, y son: Type of service (TOS) Fragment offset Fragmentation flags Time to live (TTL) Header checksum

Para consultar ms sobre estos campos de una cabecera de un paquete IP puede consultarse la RFC2402. Para realizar el proceso de autenticacin, el emisor calcula el ICV y lo ubica en el campo Authentication Data. El ICV es un valor hash computado sobre todos los campos que la autenticacin incluye. La llave secreta es negociada durante el establecimiento de la SA. La autenticacin de un paquete recibido es verificada cuando el receptor calcula el valor hash y lo compara con el ICV del paquete entrante. Si el paquete IP no es autenticando exitosamente entonces es descartado.

5.3.2.1.

Modo Transporte

En modo transporte, la cabecera del paquete IP original es conservada como la cabecera del nuevo paquete IP, y la cabecera de autenticacin 136

es insertada entre la cabecera IP y la carga til original, como se muestra en la figura 5.19. El nico cambio que se realiza en la cabecera IP es el del campo Protocolo que cambia a 51, valor para el protocolo AH. El valor reemplazado en el campo Protocolo pasa a ser el valor del campo Next Header en la cabecera de autenticacin. Finalmente el ICV es calculado sobre la totalidad del nuevo paquete IP excluyendo los campos mutables mencionados previamente.

Carga til Cabecera IP original Cabecera de protocolo superior Datos de capa superior

Cabecera IP original

Cabecera de Autenticacin

Cabecera de protocolo superior Autenticado

Datos de capa superior

Figura 5.19 Modo Transporte AH

La ventaja del modo Transporte es que solo adiciona unos pocos bytes extra a el paquete IP original. Sin embargo, por conservarse la cabecera IP original como la misma cabecera del nuevo paquete IP, solamente puede ser usado por hosts finales, esta es una limitacin grande cuando los dispositivos que estn gobernados por esta SA IPSec actan como gateways de otros hosts que se encuentran detrs de ellos.

5.3.2.2.

Modo Tnel

En modo Tnel, una nueva cabecera es creada para el nuevo paquete IP y la cabecera de autenticacin es insertada entre las cabeceras nueva y original, tal como se muestra en la figura 5.20. El paquete IP

137

original permanece intacto y es encapsulado dentro del nuevo paquete IP. De esta manera, la autenticacin se aplica sobre el paquete IP original entero (incluyendo los campos mutables de la cabecera IP original).

Carga til Cabecera IP original Cabecera de protocolo superior Datos de capa superior

Nueva Cabecera IP

Cabecera de Autenticacin

Cabecera IP original

Cabecera de protocolo superior

Datos de capa superior

Autenticado

Figura 5.20 Modo Tnel AH

La cabecera IP original permanece completamente inalterada y contiene las direcciones IP tanto de destino como fuente de los dispositivos que emiten y reciben el trfico IP original. La nueva cabecera IP contiene la direccin IP fuente y de destino de los dispositivos IPSec entre los cuales viaja el nuevo paquete. De esta manera el modo Tnel puede ser usado si los puntos finales de la SA son un host o gateway de seguridad. A diferencia del modo Transporte, el modo Tnel tiene como desventaja adicionar mas bytes extra por lo cual el throughput efectivo del enlace disminuye al igual que el desempeo de los dispositivos se torna mas lento por el doble procesamiento de cabecera que se necesita. El valor del campo Protocolo en la nueva cabecera IP es 51 (como en el modo Transporte) y el campo Next Header en la cabecera de autenticacin contiene el valor 4, que especifica que la siguiente cabecera es de 1 paquete de tipo IPv4.

138

5.3.3.

ENCAPSULATING SECURITY PAYLOAD - ESP

El protocolo ESP IPSec provee autenticacin, confidencialidad de los datos por medio de cifrado y una proteccin opcional antirepeticin para los paquetes IP. La autenticacin y el cifrado son tambin opcionales, pero al menos una de ellas debe ser empleada; de lo contrario, este protocolo carecera de fundamento. La confidencialidad es lograda por medio de tcnicas de cifrado. Los algoritmos de cifrado empleados a los paquetes IP son definidos por la SA sobre la cual los paquetes son enviados. El algoritmo de cifrado Null en el cual el cifrado no es aplicado, es tambin un algoritmo vlido en este protocolo. En este caso, ESP solamente presta el servicio de autenticacin para el trfico. Al igual que con AH varios campos adicionales son insertados en el paquete IP para que presten los servicios mencionados anteriormente. Muchos de esos campos tienen el mismo significado que en AH, pero la diferencia es que stos se encuentran a lo largo del paquete IP, algunos en la cabecera ESP, otros en el trailer ESP y otro esta en el segmento de autenticacin ESP. La figura 5.21 muestra la conformacin de un paquete IP despus que se ha procesado con el protocolo IPSec ESP, se observan la ubicacin de los campos dentro de cada uno de los segmentos del nuevo paquete.

139

Authentication Data (variable)

Cabecera IP

Cabecera ESP

Carga til

Trailer ESP

Autenticacin ESP

Security Parameter Index (SPI) (32 bits) Nmero de secuencia (32 bits) Padding (0-225 bytes) Pad Len (8 bits) Next Header (8 bits)

Figura 5.21 Nuevo paquete IP procesado con ESP

La cabecera ESP se encuentra despus de la nueva cabecera IP o despus de la cabecera IP original modificada, esto dependiendo del modo. El trailer ESP se encuentra al final del paquete IP original y el segmento de autenticacin ESP se encuentra despus de el trailer. Si la autenticacin no es aplicada, el segmento de autenticacin ESP no es aadido. Si el cifrado es aplicado, cada una de las partes desde el final de la cabecera ESP hasta el final de el trailer ESP son encriptadas. Al igual que en el protocolo AH, los campos SPI, Sequence Number, Next Header y Authentication Data, se encuentran definidos a lo largo del nuevo paquete IP. Tambin se encuentran otros dos campos, el campo Padding es usado para rellenar los datos a ser encriptados y completar un lmite de 4 bytes, por tanto este campo es de longitud variable. El campo Pad Len especifica la longitud del relleno para poder luego ser eliminado despus de que los datos son desencriptados. Existe un problema cuando la longitud del nuevo paquete IP, debido a la adicin de una cabecera ESP y de unos campos de relleno y de autenticacin, resulta ser mas grande que el tamao mximo definido para el paquete (MTU). Cuando esto pasa, los paquetes IP son fragmentados por el dispositivo emisor. Debido a que el procesamiento 140

ESP debe ser aplicado nicamente a paquetes IP enteros y no fragmentados, si un paquete IP entrante ha llegado fragmentado, el gateway de seguridad que lo recibe debe reensamblar los fragmentos para formar de nuevo el paquete IP antes de que sean procesados por ESP. 5.3.3.1. Modo Transporte

En el modo transporte, la cabecera ESP es insertada entre la cabecera IP y la carga til original, y los segmentos trailer y de autenticacin ESP son aadidos si son necesarios. Si el paquete est siendo sujeto de un segundo proceso de encapsulamiento ESP, la nueva cabecera ESP es puesta despus de la primera y los segmentos trailer y de autenticacin son aadidos despus de los primeros campos de su mismo tem. Dado que la cabecera IP original sigue sin alteraciones, el modo de transporte para el protocolo ESP, al igual que en AH, solamente puede ser usado entre hosts. El modo de transporte es el ms usado cuando no es necesario ocultar o autenticar las direcciones IP tanto de la fuente como del destino. En la grfica 5.22 se detalla la conformacin del nuevo paquete IP usando ESP en modo transporte, adems se muestra la parte del paquete que puede ser encriptada y la parte del paquete que puede ser autenticada.

141

Carga til Cabecera IP original Cabecera de protocolo superior Datos de capa superior

Cabecera IP original

Cabecera ESP

Cabecera de protocolo superior

Datos de capa superior Encriptado Autenticado

Trailer ESP

Autenticacin ESP

Figura 5.22 Modo transporte ESP

5.3.3.2.

Modo Tnel

En modo tnel, el paquete IP original enteramente es encapsulado dentro de un nuevo paquete IP. En la figura 5.23 se muestra como la nueva cabecera IP y la cabecera ESP son puestas al comienzo del paquete IP original, y los segmentos trailer y de autenticacin ESP son aadidos al final del mismo. Si el tnel se encuentra establecido entre hosts, las direcciones IP fuente y de destino, en la nueva cabecera IP pueden ser las mismas que en la cabecera original. Si el tnel se encuentra establecido entre dos gateways de seguridad, las direcciones en la nueva cabecera IP sern las direcciones de los gateways. Ejecutando ESP en modo tnel entre gateways de seguridad se puede lograr tanto confidencialidad como autenticacin del trfico en trnsito entre los dos gateways

Carga til Cabecera IP original Cabecera de protocolo superior Datos de capa superior

Nueva Cabecera IP

Cabecera ESP

Cabecera IP original

Cabecera de protocolo superior

Datos de capa superior Encriptado Autenticado

Trailer ESP

Autenticacin ESP

Figura 5.23 Modo tnel ESP

142

5.3.4.

INTERNET KEY EXCHANGE - IKE

Los protocolos ESP y AH no explican cmo las asociaciones de seguridad son negociadas, simplemente se refiere a cmo lo servicios de seguridad son aplicados a cada paquete IP de acuerdo con lo que le indica la SA. Las SAs pueden ser configuradas manualmente por el administrador del sistema o pueden ser negociadas dinmicamente por medio de un protocolo de manejo de llaves tal como IKE. Este ltimo tipo de negociacin es muy importante debido a que en una comunicacin de datos es imposible saber cuando una nueva SA se tiene que establecer y mas cuando los datos a asegurar provienen del exterior del sistema. La otra razn importante para usar negociacin dinmicas de SAs, es que por motivos de seguridad las SAs no pueden tener un tiempo de vida muy largo, dado que se expone a que algn atacante rompa los cdigos de seguridad. Para eliminar este riesgo, las SAs se renegocian peridicamente regenerando as todo el material asociado a las llaves mismas. IKE est basado en el protocolo de manejo de llaves y de asociaciones de seguridad en Internet ISAKMP (Internet Security Association And Key Management Protocol) [REF5.9], el cual implementa elementos de los mtodos de intercambio de llaves Oakley y SKEME (Secure Key Exchange Mechanism). ISAKMP define un conjunto de procedimientos por medio de los cuales se asegura el canal de comunicacin entre dos puntos. En otras palabras, es el protocolo encargado de preparar el canal de transporte seguro que luego ser usado por las SAs para ser negociadas.

143

Un mensaje ISAKMP consiste de una cabecera ISAKMP y de uno o ms campos de carga til encadenado uno al otro en un paquete UDP. Estos paquetes usan el puerto 500. La figura 5.24 muestra el formato de un mensaje ISAKMP el cual se compone de una cabecera UDP, una cabecera ISAKMP y uno o mas campos de carga til ISAKMP encadenados uno de tras del otro.

Cabecera UDP

Cabecera ISAKMP

ISAKMP Carga til 1

ISAKMP Carga til 2

...

ISAKMP Carga til n

Next Payload

Initiator Cookie (8 bytes) Responder Cookie (8 bytes) Major Version Next Payload Exchange Type Message ID Message Length

Flags

Figura 5.24 Formato de un mensaje y una cabecera ISAKMP

Dentro de la cabecera ISAKMP se distinguen los siguientes subcampos: Initiator Cookie: La cookie de la entidad que comienza el proceso de establecimiento de la SA. Responder Cookie: La cookie de la entidad que respondiendo a un requerimiento de establecimiento de SA. Next Payload: Indica el tipo del primer campo de carga til en el mensaje. Major Version: Indica el primer dgito de una versin de protocolo ISAKMP. Tiene valor de 1 cuando el protocolo ISAKMP con el cual se trabaja cumple con todas las caractersticas descritas en la RFC2408, y valor 0 cuando se trabaja con ISAKMP descrito en RFCs con fechas anteriores. Minor Versin: Indica el segundo dgito de una versin de protocolo ISAKMP. Tiene valor de 0 cuando el protocolo ISAKMP 144 esta

con el cual se trabaja cumple con todas las caractersticas descritas en la RFC2408, y valor 1 cuando se trabaja con ISAKMP descrito en RFCs con fechas anteriores. Por norma, un peer no debera aceptar paquetes con una Minor Versin mayor a la que el propio peer maneja. Exchange Type: Indica el tipo de intercambio que esta siendo usando en la negociacin del canal seguro, principal, agresivo o rpido. Este campo es importante porque le indica a cada entidad qu mensaje tiene que esperar a continuacin. Flags: Es un campo de 8 bits pero en la actualidad solo se usan los 3 primeros bits ms significativos, el resto son reservados para aplicaciones futuras y deben permanecer siempre en 0. Encryption Flag: Cuando el valor de este bit es 1, todos los campos de carga til que le siguen al encabezado son encriptados usando el algoritmo de cifrado definido en la ISAMKP SA. Si el valor del bit es 0 la carga til no viaja encriptada. Commit Flag: Este bit es usado como una seal para sincronizar el intercambio de llaves. Se utiliza para asegurar que los datos a encriptar no sean recibidos antes de completar el establecimiento de la SA. Si el valor del Commit Bit es 1, significa que la entidad que as lo ha configurado, le exige a la otra parte que debe esperar un informacin de intercambio contenida en el Notify Payload. A parte de ser usado para asegurar el intercambio de datos encriptados en el momento justo, el Commit Bit se usa para proteger los datos por perdidas de transmisin debidas a redes no confiables, y as evitar mltiples retransmisiones.

145

Authentication Flag: Este bit se usa para indicar a las partes que a la informacin util de los paquetes se les tiene que aplicar tcnicas de chequeo de integridad mas no de cifrado. Si su valor es de 1 significa que toda la carga util tiene que ser autenticada. Message ID (4 octetos): Es un numero unico usado para identificar el estado en el que se encuentra el protocolo durante las negociaciones de la fase 2. Es generado aleatoriamente por la parte que inicia la negociacin de la fase 2. Sirve para no crear confusiones cuando entre dos entidades se estan estableciendo SAs diferentes. Message Length (4 octetos): Indica la longitud total del mensaje (cabeceras + cargas utiles) en octetos. El cifrado se puede aplicar sobre el tamao total del mensaje ISAKMP. Hay dos fases en la negociacin ISAKMP de una asociacin de seguridad. La primera fase es la negociacin entre los dos nodos ISAKMP. En esta fase dos nodos se ponen de acuerdo en la forma de proteger las comunicaciones que se establecern luego entre ellos, se puede decir que en esta fase se crea una asociacin de seguridad ISAKMP. Es muy importante no confundir una ISAKMP SA con las SAs propias de IPSec tratadas anteriormente. Una ISAKMP SA es bidireccional y no trabaja sobre el trfico IPSec. En la segunda fase, las asociaciones de seguridad propias de IPSec son negociadas entre los dos nodos ISAKMP. Dado que el canal se ha asegurado en la primera fase, las negociaciones dentro de esta segunda fase se desarrollan de una manera mas sencilla. Una misma ISAKMP SA puede ser usada para negociar muchas SAs IPSec reduciendo el nmero de negociaciones. Lo anterior sucede en 146

aplicaciones IPSec LAN-to-LAN donde un gateway de seguridad acta como un nodo ISAKMP en nombre de los hosts que l protege. 5.3.4.1. Fase 1 IKE

IKE define dos modos de negociacin dentro de la fase 1: modo principal y modo agresivo. El intercambio de mensajes de un modo principal se muestra en la figura 5.25. Se pueden observar tres pasos en este modo. En el primero, un nodo ISAKMP (el que inicia) propone mltiples SAs al otro nodo (el que responde); este ltimo escoge una de las SAs propuestas y la retorna al emisor. En el segundo paso, cada nodo enva sus parmetros de intercambio de llaves y un nmero aleatorio llamado nonce; el uso de los nonces tiene como objetivo proteger a la negociacin contra ataques de repeticin. En el tercer paso, toda la informacin que se intercambia es autenticada usando uno de los siguientes tres mecanismos de autenticacin: secreto compartido, firmas digitales o cifrado de llaves pblicas19.
Nodo ISAKMP que inicia Ofrecimiento de potenciales SAs SA propuesta aceptada Paso 2 Informacin para intercambio de llaves y Nonce Informacin para intercambio de llaves y Nonce Nodo ISAKMP que responde

Paso 1

Paso 3 Identificador, informacin de autenticacin Identificador, informacin de autenticacin

Figura 5.25 Intercambio de mensajes en la fase 1 IKE usando modo principal


19

Informacin sobre estos mecanismos de autenticacin se ha tratado en el captulo 4.

147

Cuando se emplea el mecanismo de secreto compartido, los dos nodos usan una llave secreta derivada de un secreto compartido para crear la palabra hash. Esta palabra hash es luego intercambiada entre los dos nodos y sirve como autenticador. Si se emplea el mecanismo de firmas digitales, la autenticacin entre el iniciador y su corresponsal es llevada a cabo usando la firma digital de las entidades de negociacin. Los dos nodos intercambian sus identidades, los valores de sus llaves pblicas y las SAs propuestas usando mensajes hash firmados digitalmente. Con el tercer mecanismo, el de cifrado de llaves pblicas, los dos nodos intercambian sus IDs y nonces de manera encriptada usando sus llaves pblicas. En el modo agresivo, la SA propuesta, los parmetros de intercambio de llaves, el nonce y la informacin de su identidad, son intercambiadas todas en un nico mensaje, tal como se muestra en la figura 5.26. Adicionalmente, la informacin de autenticacin intercambiada no va encriptada.

Nodo ISAKMP que inicia Ofrecimiento de potenciales SAs, informacin de intercambio de llaves, Nonce e identificador

Nodo ISAKMP que responde

SA propuesta aceptada, informacin de intercambio de llaves, Nonce e identificador

Autenticador

Figura 5.26 Intercambio de mensajes en la fase 1 IKE usando modo agresivo

Una vez se completa la negociacin en la fase 1, la ISAKMP SA queda establecida. A partir de este momento todas las

148

negociaciones de las asociaciones de seguridad que se necesiten crear entre los dos nodos viajan en un canal asegurado. 5.3.4.2. Fase 2 IKE

Durante esta fase, se negocian las asociaciones de seguridad IPSec. Como se dijo anteriormente, la negociacin que se realiza en esta fase es mas rpida dado que el canal ya se ha asegurado, de aqu que el nombre que toma esta negociacin es el de modo rpido. Los mensajes que se intercambian en modo rpido son mostrados en la figura 5.27.

Nodo ISAKMP que inicia Ofrecimiento de potenciales SAs, informacin de intercambio de llaves, Nonce e identificador

Nodo ISAKMP que responde

SA propuesta aceptada, informacin de intercambio de llaves, Nonce, identificador y autenticador

Autenticador

Figura 5.27 Intercambio de mensajes en la fase 2 IKE usando modo rpido

En esta fase las identidades que se pasan de un lado a otro no son las identidades de los nodos IKE sino de los nodos IPSec y ms especficamente, de los selectores a ser usados en esta SA y que se encuentra en la base de datos de polticas de seguridad que rige esta comunicacin. Claramente se concluye que para que se lleve a cabo la fase 2 es necesario que haya concluido la fase 1, pero una vez la fase 2 se ha establecido, puede existir independientemente an si la fase 1 ha desaparecido.

149

5.3.4.3.

Generacin de Llaves en IKE

Las llaves son generadas una vez los parmetros necesarios se encuentran en los nodos ISAKMP. El algoritmo Diffie-Hellman juega un papel vital en la generacin de llaves en IKE. Como se trato en el captulo 4, el algoritmo DiffieHellman permite que dos partes generen una llave secreta a partir de parmetros pblicos, de tal manera que una tercera entidad que tenga la intencin de obtener la llave secreta escuchando la comunicacin de los dos nodos involucrados sea incapaz de hacerlo. Sin embargo, el protocolo Diffie-Hellman es vulnerable a ataques del hombre-en-la-mitad, en el cual alguien intercepta los mensajes que se intercambian y suplanta uno de los nodos. Por lo anterior, en el intercambio IKE, las dos partes involucradas deben ser autenticadas. La llave secreta Diffie-Hellman generada en la fase 1 es llamada la ISAKMP master key y la llave secreta Diffie-Hellman generada en la fase 2 es llamada la user master key. Oakley es un protocolo que se usa para determinar llaves y que se basa en el esquema Diffie-Hellman para intercambiar llaves secretas de una manera segura entre dos partes que se han autenticado previamente.

150

5.4.

MPLS

MPLS [REF5.1] es una tecnologa que modifica el reenvo tradicional de paquetes que analiza la direccin IP de destino contenida en la cabecera de la capa de red de cada paquete y por medio de la cual un paquete viaja desde la fuente hasta su destino final. En el anlisis tradicional para el reenvo de un paquete IP cada proceso de estos es realizado en cada punto de la red. Los protocolos de enrutamiento dinmicos o estticos construyen una base de datos necesaria, la cual se analiza para tomar una decisin hacia donde va el paquete IP segn direccin de destino, dicha tabla se conoce como tabla de enrutamiento. El reenvo tradicional de paquetes que realiza la capa de red, confa en la informacin que le proveen los protocolos de enrutamiento tales como OSPF (Open Shortest Path First) o BGP (Border Gateway Protocol) o a las rutas estticas configuradas en cada router, para tomar la decisin de reenvo entre los mismos. Es decir, que la decisin de reenvo est basada nica y exclusivamente en la direccin IP de destino. Todos los paquetes para el mismo destino siguen el mismo camino a travs de la red si no existen otros caminos de igual costo. Si un router tiene dos caminos de igual costo hacia un mismo destino, los paquetes podran tomar uno solo o ambos, trayendo como consecuencia una degradacin en la velocidad debido al proceso de balanceo de cargas. Los routers son dispositivos que trabajan a nivel de la capa de red, ellos se encargan de recolectar y distribuir la informacin de enrutamiento y de la conmutacin a nivel 3 basada en el contenido de la cabecera de la capa de red de cada paquete.

151

Los routers se pueden conectar directamente por medio de enlaces punto-apunto o redes de rea local. Tambin pueden ser conectados a travs de switches LAN o WAN. Esos switches LAN o WAN de Capa 2 no tienen la capacidad de mantener la informacin de enrutamiento de Capa 3 o de seleccionar el camino que debera de tomar un paquete partiendo del anlisis de su direccin de destino Capa 3. Es decir, los switches de Capa 2 no se pueden involucrar en el proceso de reenvo de paquetes a nivel de Capa 3. En el caso de una red WAN el diseador de la red tiene entonces que establecer trayectos a nivel 2 manualmente a travs de toda la red WAN. Por esos trayectos o paths es por donde los enrutadores que estn conectados fsicamente a la Capa 2, reenvan sus paquetes a nivel de la Capa 3. El establecimiento de un path en una red WAN de Capa 2 se realiza por medio de un enlace punto-a-punto, que en la mayora de redes WAN es llamado un circuito virtual y que se establece nicamente por medio de una configuracin manual. Cualquier dispositivo de enrutamiento que se encuentre conectado en los lmites de una red de Capa 2 y que quiera reenviar sus paquetes a nivel de Capa 3 a otro dispositivo de enrutamiento, necesita establecer una conexin directa a travs de la red. La figura 5.28 muestra una red WAN ATM y tres routers que se encuentran conectados a cada switch ATM en cada ciudad. Asumiendo que existen caminos o paths entre Cali y Bogot y entre Bogot y Medelln, todos los paquetes enviados desde Cali hasta Medelln, deben ser enviados hacia el router de Bogot, donde ellos son analizados y enviados a travs de su conexin ATM existente hasta Medelln. Este paso extra introduce un retardo en la red y una carga innecesaria de la CPU en el router de Bogot, al igual que el enlace existente entre el switch ATM de Bogot y el router de la misma ciudad. 152

Switch ATM Cali PVC ATM Router de core Cali Switch ATM Bogot

Switch ATM Medelln

Router de core Medelln

Backbone ATM

Router de core Bogot

Figura 5.28 Red IP basada en un backbone ATM

Si se quisiera implementar de mejor manera el reenvo de paquetes en la red mostrada en la figura 5.28, debera existir un circuito virtual ATM entre cada uno de los enrutadores que la componen, esto es, un VC entre Cali y Medelln, un VC entre Cali y Bogot y un VC entre Bogot y Medelln. Esto se torna fcil cuando la red es pequea como la que se est tratando, en la cual hay tres nodos, pero en redes mas grandes que se componen de decenas o cientos de enrutadores conectados a la misma red WAN, la creacin y la gestin de la red ATM pasa a ser un problema muy serio. Los problemas de escalabilidad que se pueden encontrar en redes de este tipo son: Cada vez que un nuevo router es conectado a la red WAN, un circuito virtual debe ser establecido entre este router y cada uno de los dems, si se busca un enrutamiento ptimo.

153

En la mayora de protocolos de enrutamiento, cada router conectado a la red WAN a nivel de Capa 2, necesita un circuito virtual dedicado a cada uno de los otros routers. Con esto se logra la redundancia deseada configurando una adyacencia a cada uno de los otros routers. Como resultado de esta necesidad, se obtienen enrutadores con mltiples vecinos y a su vez, cantidades de trfico de enrutamiento circulando entre ellos.

Otro problema frecuente es la dificultad que se tiene para hacer el aprovisionamiento de ancho de banda o de circuitos virtuales entre los routers de una red Capa 3, por cuanto es difcil predecir la cantidad exacta de trfico entre dos routers. Esto conlleva a que algunos proveedores de servicio no opten por ofrecer un servicio de calidad garantizada dado por su red, sino que se busca que el ancho de banda sea limitado por la capacidad de la ltima milla.

Los anteriores problemas, entre otros, han hecho que algunos proveedores de servicios de enlaces Capa 2 quieran implementar tecnologas IP usando la infraestructura WAN que ya tienen. Tambin, algunos proveedores de Internet se muestran interesados sobre alguna tecnologa que les permita garantizar una calidad en el servicio (QoS) como lo hacen los switches ATM. Adems el rpido crecimiento de ancho de banda ha acelerado la aparicin de interfaces pticas en los enrutadores y que poco a poco pueden reemplazar a tecnologas de alta velocidad como ATM. 5.4.1. DIFERENCIACIN DE PAQUETES POR SERVICIO

Como se dijo anteriormente, el reenvo de paquetes convencional usa solamente la direccin IP de destino contenida dentro de la cabecera de Capa 3 del paquete sobre el cual se esta tomando la decisin de reenvo. 154

En la figura 5.29, el enlace entre el router de Cali y el router de Bogot, transporta todo el trfico de las ciudades Pereira, Armenia y Manizales hasta el router de borde en la ciudad de Cartagena, esto lo hace sin importar que tan cargado est el enlace Cali Bogot, comparado con el trayecto Cali Medelln Bogot, que pudiera estar no saturado.

Enlace de Core POP Pereira

POP Armenia

Router de core Cali

Router de core Bogot

Gateway Cartagena

POP Manizales

Router de core Medelln

Figura 5.29 Backbone IP sin polticas de control de trfico

Aunque existen ciertas tcnicas para modificar el enrutamiento, estas tienen que ser desarrolladas en todos los enrutadores del backbone. Estas tcnicas llamadas PBR (Policy Based Routing) pueden reducir considerablemente el desempeo de los enrutadores sobre los cuales se aplica, ya que cada uno de ellos tienen que reanalizar los paquetes entrantes a cada uno de ellos y con base en parmetros tales como la ocupacin de sus posibles enlaces para reenvo, tomar la decisin del mejor path para mandar el paquete por el mismo. De lo anterior se concluye, que el mecanismo ideal a ser implementado en redes como la que se muestra en la figura 5.29 sera, que por ejemplo, el router de Manizales pudiera especificar por cual enlace dentro del 155

backbone sus paquetes debieran pasar y as garantizar el nivel de servicio de todos o de algunos de sus paquetes.

5.4.2.

INDEPENDENCIA Y CONTROL DEL REENVIO

En el reenvo de paquetes IP convencional, cualquier cambio en la informacin que controla el reenvo de paquetes es comunicado a todos los dispositivos que controlan el dominio de enrutamiento. Este cambio, siempre lleva consigo un periodo de convergencia mientras que la informacin es actualizada en toda la red. De lo anterior es claramente deseable, un mecanismo que pudiera cambiar el trayecto por el cual se reenva un paquete sin afectar los dems dispositivos que conforman la red. Para implementar este mecanismo, los dispositivos de enrutamiento no deberan depender de la informacin que se contiene en la cabecera IP, para lo cual se necesitara adjuntar una etiqueta adicional al paquete reenviado que indique el comportamiento que tome el mismo a lo largo de la red. Si las decisiones de reenvo se basan entonces en etiquetas adjuntadas a los paquetes IP originales, cualquier cambio en el proceso de decisin puede ser llevado a cabo nicamente adjuntado nuevas etiquetas y as no se impactaran ninguno de los otros dispositivos de enrutamiento que conforman la red. 5.4.3. PROPAGACIN ENRUTAMIENTO En una red que trabaja con el mecanismo de reenvo convencional de paquetes, todos los dispositivos de enrutamiento, conocen la informacin de enrutamiento para alcanzar determinado destino. Esto es necesario, 156 DE INFORMACIN EXTRA DE

dado que cada paquete es enrutado basado en la direccin destino que esta contenida en su cabecera de capa de red. En el ejemplo de la figura 5.29, tanto el router de Bogot como el router de Medelln y Cali tienen que conocer informacin de enrutamiento para que los paquetes que hacen trnsito entre los routers de Pereira, Armenia o Manizales a Cartagena lleguen correctamente. Este mtodo tiene implicacin de escalabilidad en trminos de

propagacin de rutas y de memoria y CPU utilizadas en los enrutadores del backbone, teniendo en cuenta que la nica accin que se necesitara sera reenviar un paquete desde el router de Cartagena hasta los routers del otro extremo sin involucrar de manera alguna la toma de decisiones a nivel 3 en los routers del backbone. Un mecanismo que permita a los dispositivos de enrutamiento conmutar los paquetes a travs de la red, desde un router destino hasta un router final, sin analizar la direccin destino sera un objetivo a perseguir.

5.4.4.

QUE ES MPLS?

MPLS quiere decir Conmutacin de Etiquetas Multiprotocolo (Multiprocol Label Switching). Es una tecnologa relativamente nueva que se desarroll para solucionar la mayora de los problemas que existen en la tcnica actual de reenvo de paquetes. La IETF cuenta con un grupo de trabajo MPLS que se ha unido esfuerzos en estandarizar esta tecnologa.20 Segn aparece en el documento draft-ietf-mpls-framework, el objetivo primario de MPLS, es estandarizar una tecnologa base que integre el intercambio de etiquetas durante el reenvo con el sistema de enrutamiento actual de
Para mas informacin se puede consultar el sitio en Internet http://www.ietf.org/html.chapters/mplscharter.html.
20

157

redes. Se espera que esta nueva tecnologa mejore la relacin precio/desempeo del enrutamiento que se realiza en la capa de red, que mejore la escalabilidad de la misma capa, y que provea una gran flexibilidad en la entrega de (nuevos) servicios de enrutamiento. La arquitectura MPLS describe cmo se realiza la conmutacin de etiquetas, la cual combina los beneficios del reenvo de paquetes a nivel de Capa 2 con los beneficios del enrutamiento a nivel 3. Similar a como se hace en las redes Capa 2, MPLS asigna etiquetas a los paquetes para que sean transportados a travs de redes basadas en paquetes o en celdas. Este mecanismo de reenvo a travs de dichas redes es conocido como intercambio de etiquetas (label swapping), lo cual permite que con una etiqueta pequea y de longitud fija que se aade al paquete original se pueda enrutar dicho paquete a lo largo de un camino determinado que se crea con la informacin que cada switch en la red tiene y sobre la que existe en cada etiqueta. Esta es la forma como se puede crear una VPN usando MPLS. En el reenvo de paquetes usando MPLS se puede apreciar una diferencia drstica con el reenvo original de paquetes, dado que en este ltimo entorno, cada paquete es analizado en cada uno de los saltos de la red, donde se chequea la cabecera Capa 3, y con base en la informacin de la misma se toma una decisin conforme a la tabla de enrutamiento de cada dispositivo de Capa 3. La arquitectura MPLS se divide en dos componentes: el componente de reenvo (tambin llamado data plane) y el componente de control (tambin llamado control plane).

158

El componente de reenvo, como su nombre lo indica, se encarga de reenviar los paquetes basado en las etiquetas que cada uno de ellos transporta, para esto usa una base de datos de reenvo de etiquetas que es mantenida por un switch de etiquetas (label switch). Haciendo la analoga con el esquema tradicional de reenvo de paquetes, esta base de datos es la tabla de enrutamiento. El componente de control es el responsable de crear y mantener toda la informacin de reenvo de etiquetas (tambin llamada Vnculos) entre un grupo de switches de etiquetas interconectados. De nuevo, haciendo la analoga con el esquema tradicional de enrutamiento, el componente de control es el protocolo de enrutamiento. La figura 5.30 muestra en un esquema la arquitectura de un nodo MPLS realizando el enrutamiento de un paquete IP. Se detalla la relacin entre cada uno de los bloques dentro del mismo nodo y tambin con nodos adyacentes.

Protocolos de enrutamiento IP Componente de control

Intercambio de informacin de enrutamiento con otros routers

Tabla de enrutamiento IP

Control de enrutamiento IP MPLS

Vnculo de intercambio de etiquetas con otros routers

Paquetes etiquetados entrantes

Tabla de reenvos de etiquetas

Paquetes etiquetados salientes

Componente de datos

Figura 5.30. Arquitectura de un nodo MPLS

159

Como se observa en la Figura 5.30, cada nodo MPLS tambin es router IP en el componente de control, ya que ejecuta uno o varios protocolos de enrutamiento (o depende de rutas estticas) para intercambiar informacin de enrutamiento con otros nodos MPLS en la red. Tal como en los routers tradicionales, los protocolos de enrutamiento IP son los encargados de mantener la tabla de enrutamiento, en la cual se basan los dispositivos de Capa 3 para tomar la decisin de reenvo del paquete. En un nodo MPLS, la tabla de enrutamiento es usada para determinar el intercambio de Vnculos de etiquetas, dicho intercambio es realizado por el Protocolo de Distribucin de Etiquetas o LDP (Label Distribution Protocol). El componente de control usa las etiquetas intercambiadas con los nodos MPLS adyacentes para construir la Tabla de Reenvo de Etiquetas o LFT (Label Forwarding Table), la cual usa el componente de datos para reenviar los paquetes etiquetados a travs de la red MPLS.

5.4.5.

COMPONENTES DE UNA RED MPLS

Se le llaman Enrutadores de Conmutacin de Etiquetas o LSR (Label Switch Router) a cualquier dispositivo que est involucrado en el proceso de distribucin de etiquetas y que pueda reenviar paquetes. La funcin bsica del proceso de distribucin de etiquetas es poder permitirle a cada LSR que distribuya sus vnculos de etiquetas a otros LSRs dentro de la red MPLS.

160

Existen varios tipos de LSRs que se diferencian por las funciones que cada uno de ellos desempea, entre ellos estn el Edge-LSR, ATM-LSR y ATM edge LSR. La diferencia es puramente a nivel de arquitectura, es decir el mismo dispositivo puede ser usado como cada tipo. El Edge-LSR es un router que realiza o la imposicin o la remocin de las etiquetas en los limites de la red MPLS. La labor de imposicin consiste en aadir al paquete original una etiqueta o un conjunto de etiquetas en el punto de ingreso a la red (en el sentido fuente-destino). La funcin de extraccin es lo contrario, y consiste en quitar la ultima etiqueta del paquete en el punto de egreso antes de ser reenviada al siguiente host externo a la red MPLS. Cualquier LSR que est contiguo a un nodo no MPLS es considerado un Edge-LSR. Sin embargo, si ese LSR tiene alguna interfaz conectada a un ATM-LSR, entonces toma el nombre de ATM edge-LSR. Los Edge-LSR usan la tabla de reenvo IP tradicional para etiquetar paquetes IP o para remover las etiquetas de los mismos antes de ser enviados a un nodo no MPLS. Un ATM-LSR es un switch ATM que puede actuar como un LSR, es decir, es un dispositivo que realiza enrutamiento IP y asignacin de etiquetas en el componente de control, y reenvo de paquetes de datos usando los mecanismos de conmutacin de paquetes propios de ATM, para esto usa su matriz de conmutacin ATM como su LFT.21

Un switch ATM tradicional puede ser convertido en un ATM-LSR por medio de una actualizacin de software de su componente de control.
21

161

5.4.6.

MECANISMO DE IMPOSICIN DE ETIQUETAS EN MPLS

Como se dijo anteriormente, la imposicin de etiquetas en MPLS es la accin de aadir una etiqueta a un paquete cuando ste entra a un dominio MPLS. Esta funcin se realiza siempre en los lmites de la red MPLS y es ejecutada por un Edge-LSR. En el reenvo tradicional de paquetes IP, cada salto en la red realiza una consulta en la tabla de reenvo IP, y con base en la direccin destino que se encuentra en la cabecera de red, selecciona el siguiente salto y reenva el paquete hacia ste. Esta iteracin se repite en cada salto de la red hasta que el paquete llega a su destino final. Escoger el siguiente salto para el paquete IP es la combinacin de dos funciones. La primera funcin clasifica todos los paquetes que llegan en determinado momento al router en varios grupos de prefijos IP destino; es decir, agrupa todos los paquetes que pertenecen a un misma subred y que por lo tanto tienen que ser reenviados al mismo destino. La segunda funcin asocia a cada grupo de paquetes creado en el primer paso a una direccin IP que es su siguiente salto. Dentro de la arquitectura MPLS, el resultado de la primera funcin, es decir, los grupos de paquetes con el mismo destino, es llamado un FEC (Forwarding Equivalence Classes). Cada paquete dentro un FEC es reenviado de la misma manera, por lo tanto atraviesan la red usando el mismo path. A diferencia del reenvo tradicional de paquetes, el proceso de asignar a un paquete un FEC es realizado solo una vez y no por cada salto, con lo 162

cual se reduce el procesamiento de cada router dentro de la red. El FEC a el cual el paquete es asignado, es luego codificado como un identificador de tamao fijo llamado etiqueta. Cuando el paquete etiquetado llega al siguiente salto dentro del dominio MPLS, el LSR que lo recibe, analiza su etiqueta y lo reenva al siguiente salto dependiendo de la informacin que aparece en LFT. Es muy importante anotar, que este anlisis se realiza primero que el de Capa 3, por tanto el proceso de toma de decisin a nivel 3 no se realiza. 5.4.7. REENVIO DE PAQUETES MPLS

Los paquetes MPLS entran a la red a travs de un LRS de entrada (ingress LSR) y salen de ella a travs de un LSR de salida (egress LSR). El camino que toma un paquete de un lado a otro se denomina LSP (Label Switched Path). Este path es construido a partir de la informacin que se toma de una FEC. Un LSP trabaja en un esquema orientado a conexin, es decir, que el path tiene que ser formado antes de que cualquier flujo de trfico empiece a circular por ste. Cuando un paquete atraviesa la red MPLS, cada LSR cambia la etiqueta entrante por una nueva etiqueta saliente, tal como el mecanismo usado por ATM, donde los VPI/VCI son cambiados por un par diferente cuando salen del switch ATM. Este proceso contina hasta que el ltimo LSR ha sido alcanzado. Cada LSR mantiene dos tablas que soportan toda la informacin relevante al componente de reenvo MPLS. La primera, conocida como LIB (Label 163

Information Base), donde se guardan todas las etiquetas asignadas por este LSR y las correspondencias de esas etiquetas a otras recibidas desde algn LSR vecino. Las correspondencias de estas etiquetas son distribuidas por medio de protocolos para este uso especfico. La segunda tabla conocida como LFIB (Label Forwarding Information Base) y en la cual son mantenidos nicamente las etiquetas que estn siendo actualmente usadas por el componente de reenvo. Las LFIB son el equivalente MPLS de una matriz de conmutacin en un switch ATM. La grfica 5.31 muestra como acta el mecanismo de reenvo en una red MPLS desde que entra al dominio hasta que sale del mismo. Se puede apreciar claramente como las etiquetas cambian entre los distintos LSRs, a la salida del ltimo LSR se obtiene el paquete IP original de entrada.

Paso 1- Paquete IP ingresando al router de Pereira

Paso 2 - El router de Pereira examina a nivel 3 el paquete, aade una etiqueta y reenva el paquete hacia el router de Cali

Paquete IP

Paso 4 - El router de Bogot examina la etiqueta, la renueva y reenvia el paquete hacia el gateway de Cartagena.

Paquete IP

L1

POP Pereira
Paquete IP L2 Paquete IP L3

POP Armenia

Router de core Cali

Router de core Bogot


Paquete IP

POP Manizales

Router de core Medelln

Gateway Cartagena

Paso 3 - El router de Cali examina la etiqueta, la renueva y reenvia el paquete hacia el router de Bogot.

Paso 5 - El gateway de Cartagena examina la etiqueta, la retira, analiza a nivel 3 el paquete y lo reenva hacia un router por fuera del dominio MPLS

Figura 5.31 Mecanismos de imposicin y de extraccin de etiquetas MPLS y reenvo de paquetes etiquetados.

164

REFERENCIAS: [REF5.1] RFC2637. Point-to-Point Tunneling Protocol, Julio,1999. [REF5.2] RFC2341. Cisco Layer Two Forwarding (Protocol) L2F, Mayo, 1998. [REF5.3] RFC1701, 1702. Generis Routing Encapsulation, Octubre, 1994. [REF5.4] RFC2661. Layer Two Tunneling Protocol L2TP, Agosto, 1999. [REF5.5] RFC2401. Security Architecture for the Internet Protocol, Noviembre, 1998 [REF5.6] RFC2402. IP Authentication Header, Noviembre, 1998. [REF5.7] RFC2406. IP Encapsulating Security Payload (ESP), Noviembre, 1998. [REF5.8] RFC2409. The Internet Key Exchange (IKE), Noviembre, 1998. [REF5.9] RFC2408. Internet Security Association and Key Management Protocol (ISAKMP), Noviembre, 1998. [REF5.10] MPLS and VPN Architectures. Pepelnjack, Guichard. Cisco Press. Marzo, 2001.

165

6.

MONTAJES PRACTICOS
6.1 ACCESO REMOTO CON PPTP
Topologa: Acceso Remoto Tecnologa de tunel: PPTP Plataforma: Por software usando Windows 2000 Server Equipos utilizados: Un computador Dell P4 1.8Ghz, 384MB RAM, 40GB. Actuando como servidor de dominio principal bajo Windows 2000 server, DHCP server, WINS server, PPTP server (PNS). Un computador generico, P2 350Mhz, 192MB RAM, 12GB, actuando como estacion de trabajo Windows2000 dentro del dominio principal. Un computador genrico Celeron 1.0GHz, 192MB, 40GB, con Windows XP Home Edition, actuando como cliente PPTP nativo. 6.1.1. ESCENARIO MONTADO

TUNEL PPTP A TRAVES DE INTERNET


Enlace PPP Servidor PPTP

INTERNET
Usuario remoto con cliente PPTP
IP dinamica asignada por la ISP IP dinamica asignada por el servidor DHCP de la LAN Corporativa

Enlace Dedicado
66.128.33.25

Servidor DHCP Servidor de Dominio Microsoft

ISP

ISP

192.168.200.1

LAN corporativa
192.168.200.21

Estacion de Trabajo

166

6.1.2.

INSTALACIN Y CONFIGURACIN DEL SERVIDOR PPTP

La configuracin de un servidor PPTP descrita en el presente trabajo parte del hecho de tener un servidor Windows2000 previamente instalado como servidor de dominio. Para un guia bsica de cmo instalar y configurar un servidor de dominio principal bajo Windows2000 por favor remitirse a la siguiente direccin URL: http://www.microsoft.com/windows2000/techinfo/planning/server/serv ersteps.asp. Tambien se incluye el procedimiento para crear usuarios en el dominio. El soporte para realizar tneles bajo Windows2000 est incluido como una caracterstica del Remote and Routing Access Server (RRAS). RRAS se instala por defecto con Windows2000 Server. Para configurar el RRAS se necesita abrir la consola del mismo, esto se hace siguiendo la ruta: Start | Programs | Administrative Tools | Routing and remote access. Para proceder a configurar el RRAS se da clic derecho en el nombre del servidor y se escoge la opcin Configure and Enable Routing and Remote Access

167

Luego aparece una ventana titulada Routing and Remote Access Server Setup Wizard. Clic en Next.

A continuacin aparece las posibles opciones de configuracin que vienen con el Wizard del RRAS. Microsoft ha encontrado bugs en este

168

Wizard22, por lo cual han recomendado escoger la opcin Manually configured server y luego dar clic en Next:

Luego aparece la ventana de finalizacin del Wizard para comenzar ahora la configuracin manual del RRAS.

22

Este problema ha sido documentado en el artculo Q243374 del Microsoft Knowledge Base.

169

Para comenzar con la configuracin del PPTP Server es necesario configurar algunas opciones generales del RRAS, para esto se selecciona el servidor (en este caso vpn-server-1) y se da clic derecho en el mismo:

Se selecciona la opcin Properties (Propiedades), se escoge la pestaa IP y se verifica que las opciones Enable IP routing y Allow IP-Based remote access and demand-dial connections estn habilitadas:

170

El RRAS puede asignar direcciones IP a los clientes remotos (dial-up y VPN) de un pool esttico propio de este o del pool del servidor DHCP que est corriendo.23 Es necesario adems escoger la interfaz de red por la cual el RRAS obtiene la direccin DHCP, DNS y WINS para los cliente remotos, esta interfaz por lo general es la que est conectada a la red interna, en este caso, tiene el nombre de Intranet. Es necesario aclarar que el servidor DNS que usa la maquina que actua como gateway VPN es el de la ISP. No hay configuracin alguna de el PPTP server para que actue como servidor DNS. Opcionalmente, y para realizar un mejor debug ante cualquier problema en el acceso, se puede dar clic en la pestaa Event Logging y seleccionar Log the maximum amount of information.
Una guia paso a paso para instalar el servicio DHCP en un servidor Windows2000 puede ser encontrada en la siguiente direccin URL http://support.microsoft.com/default.aspx?scid=kb;en-us;300429
23

171

A continuacin se procede a configurar los puertos PPTP. Para esto se selecciona la opcin Ports y en el panel derecho aparecen todos los puertos que por defecto vienen instalados con el RRAS.

172

En Ports se da clic derecho y se selecciona Properties (Propiedades), se despliega la siguiente ventana:

Para configurar los puertos PPTP, se selecciona WAN Miniport (PPTP) y clic en Configure. Dado que no se est configurando un escenario PPTP LAN-to-LAN, la opcin Demand-dial routing connections (inbound and outbound) no se selecciona. Se asegura que la opcin Remote access connections (inbound only) s aparezca seleccionada y se configura el numero mximo de puertos PPTP que se quieren activar, esto es, el nmero mximo de tneles simultneos que el servidor PPTP podr soportar (el mximo es 254). Por ultimo clic en OK.

173

Dado que no se estn implementando tneles usando L2TP, se selecciona WAN Miniport (L2TP) y se configura cero como numero mximo de puertos, por ultimo clic en OK.

A continuacin aparece una ventana de advertencia informando que configurar el cambio en el mximo numero de puertos traer como consecuencia la desconexin de conexiones activas si el nuevo nmero es menor que el anterior. Se selecciona Yes.

174

Una vez se retorne al dialogo Port Properties, se selecciona OK. En la ventana principal del RRAS aparecen la cantidad de puertos PPTP y L2TP que se escogieron (para este ltimo no aparecen dado que se introdujo cero como valor).

Para esta implementacin se configuraron solo 5 puertos PPTP. Por ltimo, se procede a configurar la opcin de registro de logs, para lo cual se selecciona la opcin Remote Access Logging, y en el panel de la derecha se da clic derecho en LocalFile y se selecciona la opcin de Properties (Propiedades):

175

Se despliega un cuadro de dialogo titulado Local File Properties, se asegura que est habilitada la opcin Log authentication requests y se da clic en OK. Opcionalmente, seleccionando la pestaa Local File se puede cambiar el path donde se guardan los logs y la frecuencia con la cual se renueva dicho archivo:

176

6.1.3.

INSTALACIN Y CONFIGURACIN DE UN CLIENTE PPTP EN WINDOWS XP

El procedimiento para instalar y configurar un cliente PPTP es similar en Windows XP y en Windows2000. En Windows98 es un poco diferente pero para propositos prcticos, considerando que hoy en da XP y 2000 representan mayora respecto a Windows98, se detalla el procedimiento de instalacion y configuracin en un cliente PPTP remoto en Windows XP Home Edition. Para crear una nueva conexin es necesario abrir la ventana donde aparecen las conexiones de red establecidas, para esto se sigue la ruta: Inicio | Conectar a | Mostrar todas las conexiones En la ventana de dilogo que se despliega, damos clic en: Archivo | Nueva conexin

177

Luego se despliega el cuadro de dilogo para iniciar el Wizard que crea la nueva conexin de tipo VPN:

Se da clic en Siguiente, y a continuacin se despliega una ventana donde se escoge el tipo de conexin nueva que se quiere crear, en nuestro caso Conectarse a la red de mi lugar de trabajo (que hace alusin a una red privada virtual).

178

Se da clic en Siguiente y aparece una ventana donde se selecciona Conexin de red privada virtual, y se da clic en Siguiente:

Aparece una ventana donde se escribe un nombre que identifique la red (compaa) remota a la que se quiere acceder por medio la VPN, en nuestro caso usamos e-net como nombre de una compaa ficticia, y se da clic en Siguiente.

179

A continuacin aparece un cuadro donde Windows le pregunta al usuario si quiere ejecutar una conexin telefnica antes de lanzar la conexin PPTP. En nuestro caso escogemos No usar la conexin inicial, ya que la primera conexin (PPP) se hara manualmente.

Luego aparece un cuadro donde se digita el nombre o el IP del servidor PPTP de la compaa remota. En nuestro caso 66.128.33.25, que es el IP que la ISP le ha dado al servidor PPTP.

180

Para terminar el Wizard, se da clic en Siguiente y en la ventana de finalizacion Finalizar:

En la ventana Conexiones de Red, aparece ahora la conexin VPN recien creada:

181

Antes de lanzar la conexin PPTP, se tienen que configurar ciertos parmetros que el Wizard deja por defecto, tales como la asignacin del gateway y del servidor WINS. Para que el PC que se va a conectar a la VPN no pierda su conexin a Internet es necesario especificar en las propiedades TCP/IP que no use la puerta de enlace predeterminada en la red remota, esto es necesario para que no se creen dos rutas por defecto distintas, la de la conexin PPP y la de la conexin PPTP. Para realizar este cambio, se da clic derecho en la conexin PPTP recien creada (en este caso E-net) y se selecciona Propiedades, luego se selecciona la pestaa Funciones de red y aparece el siguiente cuadro:

182

En el Tipo de red privada virtual (VPN) se puede dejar en Automtico o se puede escoger PPTP, la otra opcion es L2TP/IPSec pero esta no aplica para este escenario. El siguiente paso es seleccionar Protocolo Internet (TCP/IP) y dar clic en Propiedades. Aparece un cuadro de dialogo que se deja con la configuracin por defecto, es decir que la direccion IP y los servidores DNS sean asignados dinmicamente. Se da clic en Opciones Avanzadas, y aparece una ventana con tres pestaas: General, DNS y WINS. En General se desactiva la opcin Usar la puerta de enlace predeterminada en la red remota:

Luego se escoge la pestaa WINS y se adiciona manualmente el IP del servidor WINS, en este caso es el mismo IP del servidor de dominio el cual tambin hace las veces de servidor PPTP.

183

Por ultimo se da clic en Aceptar en todas las ventanas abiertas hasta este punto hasta llegar a la ventana de Conexiones de Red. Una vez conectados a Internet, bien sea por acceso telefnico o estando en una LAN, se da doble clic en el cono E-net, y a continuacin aparece un cuadro de dilogo con el nombre de usuario y la contrasea con el cual el usuario se va a autenticar en el servidor PPTP. Se da clic en Conectar.

184

Dando clic derecho en el icono E-Net podemos ver el estado de la conexin VPN:

Para verificar la conectividad a la red remota abrimos un ping al IP del servidor PPTP:

Tambien se puede observar por Entorno de Red los computadores conectados en la red remota:

185

y realizar transferencia de archivos a y desde las carpetas que estan compartidas, asi como acceder a las impresoras de la red:

186

6.2.

LAN-to-LAN IPSEC USANDO EQUIPOS CISCO


Topologa: LAN-to-LAN Tecnologa de tunel: IPSec Plataforma: Por hardware usando enrutadores Cisco1760 Equipos utilizados: Dos enrutadores Cisco 1760, con interfaces WIC-1B S/T (puerto ISDN BRI), e IOS C1700-K9SV3Y7-M, Version 12.2(11)T con cifrado DES. Un computador Dell P4 1.8Ghz, 384MB RAM, 40GB, actuando como estacin de trabajo en la LAN corporativa Sitio1. Un computador genrico Celeron 1.0GHz, 192MB, 40GB, actuando como estacin de trabajo en la LAN corporativa Sitio2.

6.2.1.

ESCENARIO MONTADO

TUNEL IPSEC A TRAVES DE INTERNET


Enlace PPP Enlace PPP

Si ti o1
192.168.200.2

66.128.33.136

INTERNET
ISP ISP

66.128.33.154

Si ti o2

192.168.200.1

192.168.100.1

Es tac ion de T rabajo

Es tac ion de T rabajo

192.168.100.2

6.2.2.

INSTALACION Y CONFIGURACION Se parte del hecho de tener operativas las dos redes de area local (sitio1 y sitio2). En Sitio1 la direccin de la red es 192.168.200.0 con mscara 255.255.255.0, y en Sitio2 la direccin de la red es 192.168.100.0 con mscara de 254 hosts tambin. El gateway en Sitio1, es decir el router Cisco1760 tiene como direccin IP 192.168.200.1, y en Sitio2, el gateway tiene como direccin IP 187

192.168.100.1. Las estaciones de trabajo con las que cuenta cada red estn conectadas back-to-back por medio de un cable cross over a la interfaz FastEthernet de cada router. En sitio1, la direccin IP de la estacin de trabajo es 192.168.200.2/24 y en sitio2, la direccin IP de la estacion de trabajo es 192.168.100.2/24. Por no contar con un servidor DNS en ninguna de las dos redes LAN, se configura cada estacion de trabajo con el IP del servidor DNS asignado por la ISP, en este caso 66.128.32.70 y 66.128.32.68, primario y secundario respectivamente. La configuracin de los routers se dividi en dos etapas: la conexin a Internet de cada LAN y posteriormente el establecimiento de la VPN IPSec entre las dos LANs. La conexin a Internet se hizo por medio de una linea RDSI BRI para lo cual cada router se equip con una tarjeta WIC 1B S/T. Tambin se configur el protocolo NAT24 para proveer de Internet a toda la red corporativa. Una vez se finaliz la conexin a Internet en ambos routers, se realizaron pruebas de navegacin desde las estaciones de trabajo que estaban detrs de cada uno de ellos y se verific que desde cada router se alcanzara al otro. Despus de la anterior verificacin, se procedi a configurar cada endpoint del tunel IPSec.

NAT es un protocolo de traslacin de direcciones, con el cual se logra que por medio de una sola direccion IP publica puedan acceder a un red como Internet un rango de direcciones IPs privadas.
24

188

La

configuracin de cada gateway IPSec se hace de la siguiente

manera: Sitio1: sitio1#sh run Building configuration... Current configuration : 1805 bytes ! version 12.2 service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname sitio1 #Nombre del router ! enable secret 5 $1$THDB$2VXKI4Xgz66uiO2b3QC061 enable password 7 121A0C041104 ! username HiPer #Clave compartida del RAS, necesaria para el handshake PAP ip subnet-zero ! ! ip name-server 66.128.32.70 #Servidor DNS de la ISP ip name-server 66.128.32.68 #Servidor DNS de la ISP ! ! isdn switch-type basic-net3 #Tipo de switch ISDN de la telefonica ! voice call carrier capacity active ! ! ! ! ! ! ! ! ! ! crypto isakmp policy 10 #Creacin de la politica IKE (definicin del intercambio de #llaves)

189

#Se define el metodo de autenticacin como pre-share. Es #decir que las mismas no se obtiene de ninguna CA, sino #que ya son conocidas por ambos routers. crypto isakmp key fervpn address 66.128.33.154 #Se define la palabra clave como #fervpn y se especifica que el peer #con el que se negociara esta clave #tiene el IP 66.128.33.154 ! ! crypto ipsec transform-set to_sitio2 esp-des esp-md5-hmac #Se define el algoritmo hash # (md5-hmac) y el tipo de encripcin # (des) ! crypto map vpn_prueba 10 ipsec-isakmp #Crea una entrada IPSec set peer 66.128.33.154 #Define el peer asociado a esta entrada set transform-set to_sitio2 #Define el transform-set asociado a esta entrada match address 101 #Define la lista de acceso asociada a esta entrada ! ! ! ! interface FastEthernet0/0 ip address 192.168.200.1 255.255.255.0 no ip proxy-arp ip nat inside #Define la interfaz interna asociada al NAT speed auto full-duplex ! interface BRI0/0 description Enlace a Internet ip address 66.128.33.136 255.255.255.128 ip nat outside #Define la interfaz externa asociada al NAT encapsulation ppp dialer idle-timeout 300 dialer enable-timeout 3 dialer string 3198181 dialer hold-queue 10 dialer-group 1 isdn switch-type basic-net3 fair-queue ppp authentication pap ppp pap sent-username fernando password 7 011503164D1B08 ppp multilink crypto map vpn_prueba #Le indica a la interfaz BRI 0/0 que por ella #trabajara una VPN llamada vpn_prueba ! ip nat inside source list 122 interface BRI0/0 overload 190

authentication pre-share

#Le indica al protocolo NAT #que solo podra trasladar las #direcciones IP relacionadas en la lista de acceso 122 ip classless ip route 0.0.0.0 0.0.0.0 BRI0/0 no ip http server ! ! access-list 101 permit ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255 access-list 101 deny ip 192.168.200.0 0.0.0.255 any #Los dos comandos anteriores sirven para permitir o denegar a #determinadas direcciones IP transitar dentro del tunel IPSec access-list 122 deny ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255 access-list 122 permit ip 192.168.200.0 0.0.0.255 any #Los dos comandos anteriores sirven para permitir o denegar a #determinadas direcciones IP ser trasladadas por el NAT dialer-list 1 protocol ip permit ! call rsvp-sync ! dial-peer cor custom ! ! ! ! line con 0 line aux 0 line vty 0 4 access-class 10 in password 7 14141B180F0B login line vty 5 15 password 7 11291A550502345A506B79 login ! no scheduler allocate end

Sitio2: sitio2#sh run Building configuration... Current configuration : 1767 bytes 191

! version 12.2 service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname sitio2 ! enable secret 5 $1$0TKt$xGRS7GEE/hMCR4U6PuL8C/ enable password 7 070C285F4D06 ! username HiPer ip subnet-zero ! ! ip name-server 66.128.32.70 ip name-server 66.128.32.68 ! ! isdn switch-type basic-net3 ! voice call carrier capacity active ! ! ! ! ! ! ! ! ! ! crypto isakmp policy 10 authentication pre-share crypto isakmp key fervpn address 66.128.33.136 ! ! crypto ipsec transform-set to_sitio2 esp-des esp-md5-hmac ! crypto map vpn_prueba 10 ipsec-isakmp set peer 66.128.33.136 set transform-set to_sitio2 match address 101 ! ! ! ! 192

interface FastEthernet0/0 ip address 192.168.100.1 255.255.255.0 no ip proxy-arp ip nat inside speed auto full-duplex ! interface BRI0/0 description Enlace a Internet ip address 66.128.33.154 255.255.255.128 ip nat outside encapsulation ppp dialer idle-timeout 300 dialer enable-timeout 3 dialer string 3198181 dialer hold-queue 10 dialer-group 1 isdn switch-type basic-net3 fair-queue ppp authentication pap ppp pap sent-username gacha password 7 06010E22444F1F090B ppp multilink crypto map vpn_prueba ! ip nat inside source list 175 interface BRI0/0 overload ip classless ip route 0.0.0.0 0.0.0.0 BRI0/0 no ip http server ! ! access-list 101 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255 access-list 175 deny ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255 access-list 175 permit ip 192.168.100.0 0.0.0.255 any dialer-list 1 protocol ip permit ! call rsvp-sync ! dial-peer cor custom ! ! ! ! line con 0 line aux 0 line vty 0 4 password 7 14141B180F0B login 193

line vty 5 15 password 7 094F471A1A0A login ! no scheduler allocate end Luego se realizaron pruebas de conectividad desde cada estacin de trabajo que consistan en alcanzar a la otra por medio del comando ping y luego ver los recursos compartidos que la otra provee. En la siguiente grfica se nota que se est en la estacion con IP 192.168.100.2. Primero aparece un ping a www.yahoo.com (est navegando), luego aparece un ping al IP del gateway remoto IPSec (66.128.33.136) y por ltimo aparece un ping al IP de la estacin de trabajo que esta detrs del gateway remoto (192.168.200.2).

194

La siguiente grfica es una captura hecha en la estacion de trabajo 192.168.100.2 que est en la red LAN sitio2, y muestra los recursos compartidos en la estacion de trabajo 192.168.200.2 que se encuentra en la red LAN sitio1.

195

196

6.3. LAN-to-LAN IPSEC USANDO LINUX Y FreeS/WAN


Topologa: LAN-to-LAN Tecnologa de tnel: IPSec Plataforma: Por software, usando servidores Linux y el paquete FreeS/WAN v2.0 Equipos utilizados: Un computador Dell P4 1.8Ghz, 384MB RAM, 40GB, actuando como gateway IPSec, con Linux RedHat 9.0. Un computador IBM 1.2GHz, 256MB, 40GB, actuando como gateway IPSec, con Linux Slackware 9.0.

6.3.1.

ESCENARIO MONTADO

sitio1 (Left) 192.168.200.0/24

TUNEL IPSEC A TRAVES DE INTERNET


Enlace Ethernet 66.128.47.2 Enlace Ethernet 66.128.32.207

Sitio2 (Right) 192.168.100.0/24

INTERNET
julrodrig
192.168.200.1 192.168.200.2 66.128.47.1

ISP

ISP

66.128.32.193

berkeley
192.168.100.1 192.168.100.2

6.3.2.

INSTALACION Y CONFIGURACION

FreeS/WAN25 es una implementacin Linux del protocolo IPSec que brinda servicios de cifrado y autenticacin a conexiones IP. En este escenario se instal la versin estable mas reciente de FreeS/WAN, la 2.0.

25

El sitio oficial de este aplicacin IPSec para Linux es http://www.freeswan.org

197

FreeS/WAN convierte una mquina Linux en un gateway seguro IPSec, permitiendo implementar topologas LAN-to-LAN (como la que se mont en este laboratorio) y de Acceso Remoto con un software cliente IPSec instalado en un PC.26 Para evitar exponer la comunicacin a ataques del tipo hombre-en-elmedio, FreeS/WAN maneja dos tipos de autenticacin para sus tneles: Manual Keying: donde las dos partes comparten un llave secreta para encriptar sus mensajes. FreeS/WAN almacena estas llaves en el archivo /etc/ipsec.conf. Es claro que si alguien obtiene acceso a este archivo la comunicacin ser vulnerable. Automatic keying: Aqu los dos sistemas se autentican el uno con el otro por medio de sus propias llaves secretas. Estas llaves son cambiadas automticamente de una manera peridica. Obviamente, este mtodo de autenticacin es mucho mas seguro, ya que si un intruso obtiene la llave, solo los mensajes entre la renegociacin anterior y la siguiente seran expuestos. Las fuentes de FreeS/WAN se pueden obtener de la siguiente direccin: ftp://ftp.xs4all.nl/pub/crypto/freeswan/ Si la distribucin es RedHat, se pueden descargar los RPMs de la siguiente direccin: ftp://ftp.xs4all.nl/pub/crypto/freeswan/binaries/RedHat-RPMs

26

FreeS/WAN llama a este tipo de topologia Road Warrior.

198

Antes de proceder a descargar el software es necesario determinar el kernel con el que se cuenta, para esto se ejecuta el comando: uname a Una vez hecho este paso se comienza la descarga de la respectiva RPM
27

(en este caso el kernel con el que se trabaja es 2.4.20-8). Los

archivos descargados fueron: freeswan-module-2.00_2.4.20_3-0.i386.rpm freeswan-userland-2.00_2.4.20_3-0.i386.rpm Es necesario tambin bajar la firma digital contenida en el archivo freeswan-rpmsign.asc que sirve para comprobar la autenticidad de los RPMs descargados. Para lo anterior se ejecuta el comando rpm --checksig freeswan*.rpm y la salida deber ser: freeswan-module-2.00_2.4.18_3-0.i386.rpm: pgp md5 OK freeswan-userland-2.00_2.4.18_3-0.i386.rpm: pgp md5 OK Para instalar las RPMs es necesario tener privilegios de administrador de la mquina. Para proceder con la instalacin se ejecuta el comando: rpm -ivh freeswan*.rpm Una vez finalizada la instalacin, se inicia el servicio con el comando: service ipsec start y para probar la instalacin se ejecuta el comando ipsec verify

Para otras distribuciones es necesario compilar el paquete. Las fuentes tienen como nombre freeswan2.00.tar.gz y se pueden descargar del sitio ftp://ftp.xs4all.nl/pub/crypto/freeswan
27

199

La salida deber ser OK para al menos las 4 primeras lineas, asi:


Checking your system to see if IPsec got installed and started correctly Version check and ipsec on-path [OK] Checking for KLIPS support in kernel [OK] Checking for RSA private key (/etc/ipsec.secrets) [OK] Checking that pluto is running [OK]

Una vez comprobada la adecuada instalacin del paquete, se procede a la configuracin de los archivos /etc/ipsec.conf y /etc/ipsec.secrets. Hay que aclarar que cada gateway debe tener un IP esttico dado por el ISP, bien sea en una interfaz ppp (por ejemplo ppp0) o en una interfaz ethernet (por ejemplo eth0). A cada gateway se le debe asignar por nomenclatura como right o left, indistintamente cual se escoja para cada nombre. En nuestro caso el gateway IPSec con IP pblico 66.128.47.2 es el left y el gateway IPSec con IP pblico 66.128.32.207 es el right. Lo importante es ser congruente con esta nomenclatura a lo largo del proceso de configuracin del archivo /etc/ipsec.conf. El archivo /etc/ipsec.conf se puede dividir en dos secciones: la primera donde se configuran las opciones generales de IPSec, llamada config setup; y la segunda donde se define cada pareja IPSec llamada conn <nombre que identifica el tunel> . En esta ltima seccin puede aparecer una llamada conn %default que es donde se definen las caractersticas que se aplican por defecto a cada pareja de gateways IPSec. La parte ms importante del archivo /etc/ipsec.conf es la que define cada conexin IPSec, de hecho todas las opciones en la seccin config

200

setup son opcionales. Los campos bsicos que define cada pareja IPSec son: left= leftsubnet= leftnexthop= leftrsasigkey= right= rightsubnet= rightnexthop= rightrsasigkey= auto= Los campos left y right son las direcciones IP pblicas de cada gateway. Los campos leftsubnet y rightsubnet son las subredes que se encuentran detrs de cada gateway (la red privada). Los campos leftnexthop y rightnexthop son las direcciones IP del equipo que recibe la conexin en el ISP. Es la puerta de enlace de cada mquina Linux. Los campos leftrsasigkey y rigthrsasigkey son las llaves pblicas de cada gateway IPSec, y se obtienen con los comandos: ipsec showhostkey --left (para la mquina llamada left), y ipsec showhostkey --right (para la mquina llamada right). En caso de no contar con estas llaves, se puede generar cada una de ellas con el comando: ipsec newhostkey --output /etc/ipsec.secrets hostname <hostname> Los archivos /etc/ipsec.conf28 con los cuales se trabaj en la implementacin realizada fueron:

Para informacin ms detallada de cada uno de los campos que conforman un archivo ipsec.conf puede revisarse este sitio: http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/manpage.d/ipsec.conf.5.html
28

201

[root@berkeley root]# more /etc/ipsec.conf version 2.0 config setup klipsdebug=all plutodebug=dns conn %default keyingtries=0 spi=0x200 esp=3des-md5-96 espenckey=0x01234567_89abcdef_02468ace_13579bdf_12345678_9abcdef0 espauthkey=0x12345678_9abcdef0_2468ace0_13579bdf keylife=8h conn berkeley-to-julrodrig left=66.128.47.2 leftsubnet=192.168.0.0/24 leftnexthop=66.128.47.1 leftrsasigkey=0sAQOHbmJjlOUboH6IEm9alDzc7fvV0xxGCZV2iNrOJ4yUfSok2Plvw8fCAERzZc mOy53tE1E71Qkuz6qVZpsFbW0GfyEiJyws9/gSD3khJtLK2/3tQxkOGN+d1vJYQdlbpf0+EMCX8HSp /9sCR86G7wuMYTbNtuRh1Sl6GTDGfuJ2Xn/lULIOOX1DmtdNzdFPrvKpC3bQWocE3MumV96Bkumutm 49UhLiOa3FGn0699HbcJLh1glMoOb+EJ8in8glfTTDU4adbq5Z0wvnOlAc46gAkWLffOeeWgUQtT/K A4wVLp5RYqXgX43ytSPF5oMLsXApVcTuClbXg+u+ctfEcbfCkNRr8Fvk0C1KgDicq4/LN2P9 right=66.128.32.207 rightsubnet=192.168.100.0/24 rightnexthop=66.128.32.193 rightrsasigkey=0sAQNj25OiRTaMkDn1S/SdzXeRD0zQfXUPnsBQaXDtkvqTcCVaefJ5DUGZM8Nli 796pDvsP0W9OMis25so1whsYygkzYsacrZIlwyr+GvRDIf8xarV2YqvGDs0wvyk22891h4twzGD9yf FwgfUBEysMmGpJnGrNxFEL9TDggp9A3UeCBx+qgYv9CCWjgPXYfzKomP3tHtiB7gUTgIBlpxTva1Gs 4rM9IJIUUNBwfpuNDglD23KMibWBQn1YTPsJ9mQccIBaHao43EkM2BHRG6KbNYGD8GQ7DGbd95QLXz jdASeCc0t9TrtOI7cwxGxs6LF3NQRZrCKH1sE1OsTIkacYHxIOQ/dN53CpPMKhNQR4tl7Jm8t auto=start root@julrodrig:~# more /etc/ipsec.conf version 2.0 config setup klipsdebug=all plutodebug=dns conn %default keyingtries=0 spi=0x200 esp=3des-md5-96 espenckey=0x01234567_89abcdef_02468ace_13579bdf_12345678_9abcdef0 espauthkey=0x12345678_9abcdef0_2468ace0_13579bdf keylife=8h conn berkeley-to-julrodrig left=66.128.47.2 leftsubnet=192.168.0.0/24 leftnexthop=66.128.47.1 leftrsasigkey=0sAQOHbmJjlOUboH6IEm9alDzc7fvV0xxGCZV2iNrOJ4yUfSok2Plvw8fCAERzZc mOy53tE1E71Qkuz6qVZpsFbW0GfyEiJyws9/gSD3khJtLK2/3tQxkOGN+d1vJYQdlbpf0+EMCX8HSp /9sCR86G7wuMYTbNtuRh1Sl6GTDGfuJ2Xn/lULIOOX1DmtdNzdFPrvKpC3bQWocE3MumV96Bkumutm 49UhLiOa3FGn0699HbcJLh1glMoOb+EJ8in8glfTTDU4adbq5Z0wvnOlAc46gAkWLffOeeWgUQtT/K A4wVLp5RYqXgX43ytSPF5oMLsXApVcTuClbXg+u+ctfEcbfCkNRr8Fvk0C1KgDicq4/LN2P9 right=66.128.32.207 rightsubnet=192.168.100.0/24 rightnexthop=66.128.32.193 rightrsasigkey=0sAQNj25OiRTaMkDn1S/SdzXeRD0zQfXUPnsBQaXDtkvqTcCVaefJ5DUGZM8Nli 796pDvsP0W9OMis25so1whsYygkzYsacrZIlwyr+GvRDIf8xarV2YqvGDs0wvyk22891h4twzGD9yf FwgfUBEysMmGpJnGrNxFEL9TDggp9A3UeCBx+qgYv9CCWjgPXYfzKomP3tHtiB7gUTgIBlpxTva1Gs 4rM9IJIUUNBwfpuNDglD23KMibWBQn1YTPsJ9mQccIBaHao43EkM2BHRG6KbNYGD8GQ7DGbd95QLXz jdASeCc0t9TrtOI7cwxGxs6LF3NQRZrCKH1sE1OsTIkacYHxIOQ/dN53CpPMKhNQR4tl7Jm8t auto=start

202

Es necesario agregar la lnea versin 2.0 en el inicio de cada archivo. La lnea auto=start hace que el tnel se establezca durante el proceso de boot de la mquina. Inicialmente, para propsitos de troubleshooting , se recomienda que la linea auto tenga el valor de add, lo cual obliga a que cada vez el administrador inicie el tnel de manera manual y as pueda detectar errores en el establecimiento de la SA. Una vez afinado este procedimiento, la linea auto debera quedar con el valor start (tal como aparece en el archivo ejemplo) para que el tnel se establezca automticamente cada vez que la mquina reinicia. El comando para establecer el tnel de manera manual es: ipsec auto --up berkeley-to-julrodrig donde berkeley-to-julrodrig es el nombre dado a la pareja IPSec en el archivo /etc/ipsec.conf, y auto indica que las llaves se negocian de forma automtica (no manual). No es necesario ejecutar este comando en las dos maquinas, en una es suficiente.

La salida de este comando deber mostrar algo como:


root@julrodrig:~# ipsec auto --up berkeley-to-julrodrig 104 "berkeley-to-julrodrig" #1: STATE_MAIN_I1: initiate 106 "berkeley-to-julrodrig" #1: STATE_MAIN_I2: sent MI2, expecting MR2 108 "berkeley-to-julrodrig" #1: STATE_MAIN_I3: sent MI3, expecting MR3 004 "berkeley-to-julrodrig" #1: STATE_MAIN_I4: ISAKMP SA established 112 "berkeley-to-julrodrig" #2: STATE_QUICK_I1: initiate 004 "berkeley-to-julrodrig" #2: STATE_QUICK_I2: sent QI2, IPsec SA established

Es de vital importancia la configuracin en cada gateway IPSec del protocolo NAT para que el mismo no enmascare los paquetes que tienen como origen la subred privada en el lado remoto. Si se trabaja con iptables para hacer NAT, los siguientes comandos excluyen a los paquetes que se dirigen a la red privada remota del masquerade:

203

Para berkeley: [root@berkeley root]# iptables -t nat -A POSTROUTING -o eth1 -s 192.168.100.0/24 -d \! 192.168.0.0/24 -j MASQUERADE Para julrodrig: root@julrodrig:~# iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/24 -d \! 192.168.100.0/24 -j MASQUERADE

Se vuelve a ejecutar el comando ipsec verify y se verifica la salida: Para berkeley:


[root@berkeley root]# ipsec verify Checking your system to see if IPsec got installed and started correctly Version check and ipsec on-path [OK] Checking for KLIPS support in kernel [OK] Checking for RSA private key (/etc/ipsec.secrets) [OK] Checking that pluto is running [OK] DNS checks. Looking for forward key for berkeley.telesat.com.co [NO KEY] Does the machine have at least one non-private address [OK] Two or more interfaces found, checking IP forwarding [OK] Checking NAT and MASQUERADING tun0x1002@66.128.47.2 [OK]

Para julrodrig:
root@julrodrig:~# ipsec verify Checking your system to see if IPsec got installed and started correctly Version check and ipsec on-path [OK] Checking for KLIPS support in kernel [OK] Checking for RSA private key (/etc/ipsec.secrets) [OK] Checking that pluto is running [OK] DNS checks. Looking for forward key for julrodrig [NO KEY] Does the machine have at least one non-private address [OK] Two or more interfaces found, checking IP forwarding [OK] Checking NAT and MASQUERADING tun0x100a@66.128.32.207 [OK]

Hay que poner especial atencin a la ltima lnea donde se chequea el NAT y el Masquerading. No basta con que aparezca OK. Es necesario que aparezca tun<tunel ID>@<gateway remoto> y en seguida OK.

204

Un comando para obtener ms informacin sobre las asociaciones de seguridad que estn establecidas en un gateway IPSec es: ipsec look

Por ejemplo, la salida de este comando en berkeley fue:


root@berkeley root]# ipsec look berkeley.telesat.com.co Mon Jun 30 20:47:58 COT 2003 0.0.0.0/0 -> 0.0.0.0/0 => %trap (1) 66.128.32.207/32 -> 0.0.0.0/0 => %trap (11) 66.128.32.207/32 -> 63.218.135.144/32 => %pass (3) 66.128.32.207/32 -> 64.113.210.197/32 => %pass (6) 66.128.32.207/32 -> 66.111.37.70/32 => %pass (3) 66.128.32.207/32 -> 66.128.32.68/32 => %pass (7) 66.128.32.207/32 -> 66.128.32.70/32 => %pass (7) 66.128.32.207/32 -> 66.128.47.2/32 => %pass (455) 66.128.32.207/32 -> 68.114.26.20/32 => %pass (2) 66.128.32.207/32 -> 80.16.174.148/32 => %pass (4) 66.128.32.207/32 -> 192.168.0.1/32 => %pass (23) 66.128.32.207/32 -> 192.168.0.2/32 => %pass (98) 66.128.32.207/32 -> 207.46.106.49/32 => %pass (1) 192.168.100.0/24 -> 192.168.0.0/24 => tun0x1002@66.128.47.2 esp0x46cb35cb@66.128.47.2 (0) 192.168.100.2/32 -> 200.14.106.59/32 => %pass (804) ipsec0->eth1 mtu=16260(1500)->1500 esp0x29db1619@66.128.32.207 ESP_3DES_HMAC_MD5: dir=in src=66.128.47.2 iv_bits=64bits iv=0xe6f70c7c992b16be ooowin=64 alen=128 aklen=128 eklen=192 life(c,s,h)=addtime(167,0,0) refcount=4 ref=32 reftable=0 refentry=32 esp0x46cb35cb@66.128.47.2 ESP_3DES_HMAC_MD5: dir=out src=66.128.32.207 iv_bits=64bits iv=0x07c405ba8997306e ooowin=64 alen=128 aklen=128 eklen=192 life(c,s,h)=addtime(167,0,0) refcount=4 ref=37 reftable=0 refentry=37 tun0x1001@66.128.32.207 IPIP: dir=in src=66.128.47.2 policy=192.168.0.0/24->192.168.100.0/24 flags=0x8<> life(c,s,h)=addtime(167,0,0) refcount=4 ref=33 reftable=0 refentry=33 tun0x1002@66.128.47.2 IPIP: dir=out src=66.128.32.207 life(c,s,h)=addtime(167,0,0) refcount=4 ref=38 reftable=0 refentry=38 Destination Gateway Genmask Flags MSS Window irtt 0.0.0.0 66.128.32.193 0.0.0.0 UG 0 0 0 0.0.0.0 66.128.32.193 128.0.0.0 UG 0 0 0 128.0.0.0 66.128.32.193 128.0.0.0 UG 0 0 0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 192.168.0.0 66.128.32.193 255.255.255.0 UG 0 0 0 66.128.32.192 0.0.0.0 255.255.255.224 U 0 0 0 66.128.32.192 0.0.0.0 255.255.255.224 U 0 0 0

Iface eth1 ipsec0 ipsec0 eth1 ipsec0 eth1 ipsec0

Dado que la implementacin FreeS/WAN no permite realizar ping desde los gateways IPSec hasta las mquinas de la red privada remota, las pruebas de conectividad IP se tienen que realizar desde las mquinas que se encuentran detrs de cada gateway IPSec. En el escenario montado, se realiz un ping desde el equipo con IP

205

192.168.100.2 hasta el equipo con IP 192.168.0.2 con resultados fueron satisfactorios.

206

7. CONCLUSIONES
Internet ha cambiado la forma como las personas se comunican, acortando distancias geogrficas y acelerando la globalizacin del planeta que se estaba gestando sobre todo en el aspecto comercial. Internet hizo por ejemplo, relativamente fcil y muy econmico enviar un correo desde Colombia hasta Rusia, chatear con algun familiar que estudia en Australia, hablar con la alguien que se encuentra en Francia o recibir las fotos de algun nio que acaba de nacer en Costa Rica. Pero que tienen en comn todas las cosas que se han dicho antes? Todas son comunicaciones personales, comunicaciones que no demandan determinado nivel de confidencialidad y seguridad. Para eso naci Internet, para que las personas estuvieran comunicadas en cualquier momento y lugar. Pero las empresas empezaron a demandar servicios de conectividad seguros. Por qu? Porque Internet estaba en todas partes, porque el comportamiento del mercado era, y seguir siendo, ms velocidad (entendindose como ancho de banda) por menos precio. Porque las empresas se dieron cuenta que por medio de Internet sus trabajadores podran acceder a sus redes corporativas desde casi cualquier parte del mundo al costo de una llamada local. Porque se dieron cuenta que podran mejor los tiempos de entrega y los costos de sus productos si mantenan su inventario en lnea, realizando pedidos en tiempo real a sus proveedores.

207

Pero Internet, mejor IPv4 (el protocolo que la soporta), no estaba diseado para soportar este tipo de conexiones que requeran un alto nivel de seguridad y confidencialidad. Hasta que surgieron protocolos como SSH (Secure Shell), SSL (Secure Socket Layer) y ms recientemente las Redes Privadas Virtuales sobre Internet, PPTP, L2TP e IPSec, que le agregaron a IPv4 las caractersticas de seguridad que careca desde un comienzo. Sin lugar a dudas, las dos cosas que propiciaron que las VPNs tuvieran el crecimiento que han tenido hasta ahora, sobre todo en los pases desarrollados, ha sido la cobertura que ha alcanzado Internet y la gran disminucin en los precios de acceso, todo esto propiciado por la demanda del mercado. Aqu en Colombia, las VPNs se han venido enfocando solo a reemplazar escenarios de acceso conmutado corporativo. Hace unos 6 aos era comn que una mediana o gran empresa tuviera su propio RAS corporativo para que sus empleados accedieran a la base de datos de la compaa desde cualquier lugar del pas realizando una llamada de larga distancia. Las VPNs vinieron a reemplazar este escenario. Ya muchas de estas empresas han optado por usar la infraestructura de acceso a Internet de los ISPs a nivel nacional y han instalado su servidor VPN conectado de manera permanente a Internet en la sede principal atendiendo los tneles que sus empleados crean desde el sitio donde se encuentran. No solo se han ahorrado los costos que implica una llamada de larga distancia, sino tambin todo el desgaste en tiempo y dinero que la administracin de un RAS corporativo involucra. Pero tal vez lo mejor, es que ahora no solo las medianas y grandes empresas se dan el lujo de ser capaces que sus empleados remotos accedan a los recursos de la compaa, tambin, las VPNs han puesto esta ventaja al alcance de las 208

PYMES que en Colombia representan la mayora de los sectores productivo y comercial. En cuanto al escenario VPN LAN-to-LAN, las empresas colombianas apenas desde el ao 2002 empezaron a desarrollar este tipo de soluciones. La razn fundamental, era el precio del acceso a Internet. Pero el panorama es alentador si se tiene en cuenta que este tem ha tenido una disminucin del 70% en apenas 4 aos, al pasar de 11.000 dlares por E1 en 1999 a solo 3.300 dlares en 2003. Los pronsticos indican que para el ao 2004 un enlace con capacidad E1 a Internet estara costando 2.000 dlares, es decir una disminucin del 40% en solo un ao. Esto sin lugar a dudas acelerar el desarrollo, no solo de las VPNs, sino tambin de la Voz sobre IP y la videoconferencia corporativa. Las VPNs estn haciendo que los proveedores de transporte de datos migren sus redes a un hbrido entre IP y las tecnologas tradicionales de conmutacin de paquetes. Por ejemplo, AT&T Latinoamrica, cuya red es IP apoyada en la tecnologa MPLS e Internexa (empresa de telecomunicaciones de ISA) que esta implementando entregar los enlaces de datos en tecnologas FastEthernet y Gibabit Ethernet. Sin lugar a dudas, los ISPs estn mejor parados que ninguna otra clase de empresa de telecomunicaciones para explotar este mercado, pues conocen IP desde hace ya varios aos y tienen la infraestructura para, con una mnima inversin, proveer este servicio sin mayores problemas. Lo ms probable es que en muy poco tiempo, 2 o 3 aos, una empresa tenga solamente un enlace a Internet de gran tamao, que reemplace sus enlaces de voz, datos y video. Con este solo enlace disfrutarn de Internet a alta velocidad, enlaces privados de datos, voz y video entre sedes haciendo LAN-to-LAN VPN y acceso remoto para sus trabajadores mviles 209

desde cualquier parte del mundo con Acceso Remoto VPN, todo apoyado en la seguridad que los mecanismos de cifrado y autenticacin que las VPNs ofrezcan. Sin lugar a dudas, la llegada de ADSL a nuestro pas, ser fundamental para que de una vez por todas muchas empresas que an no han migrado sus enlaces WAN a tecnologas VPN lo hagan. Porque tcnicamente el factor que ms frena el desarrollo de una VPN es la capacidad de la ltima milla. Ademas, hay diferencias radicales en precio cuando se pasa de RDSI 128K a un enlace de 192K, por ejemplo. No hay tecnologas de acceso conmutado mas all de los 128K. Pero esto ser resuelto por ADSL, quiz no en un comienzo porque es normal que una nueva tecnologa siempre debute con altos precios pero la disminucin en las tarifas llegar a medida que se masifique el mercado. Los siguientes son los principales factores a tener en cuenta para realizar una adecuada eleccin de la tecnologa VPN en una implementacin: Los principales aspectos que se deben evaluar son: o Se necesita acceso remoto y/o LAN-to-LAN? Cal es el presupuesto? Dependiendo de la respuesta se debe escoger qu tipo de implementacin realizar. Si solo se necesita acceso remoto, el presupuesto es bajo y la seguridad que se requiere es mnima lo recomendable es montar una solucin con un servidor PPTP bajo Windows NT Server, 2000 Server o 2003 Server. Ya que es muy sencilla, requiere poca administracin, es muy verstil dado que prcticamente todos los usuarios remotos tendrn PCs con ambientes Windows. Si se necesita mayor seguridad, bastara con cambiar los tipos de puertos de PPTP a L2TP en el servidor VPN y habilitar la opcin de IPSec. 210

Si solo se necesita LAN-to-LAN y el presupuesto es bajo, lo recomendable es montar un gateway seguro IPSec bajo Linux en cada sede. Ahora si se cuentan con los recursos se podra pensar en una solucin por hardware como routers o equipos diseados para hacer VPN como los de Netscreen. En LAN-to-LAN no se evala la seguridad necesaria, ya que se asume que esta debe ser alta, y bajo ese principio se parte. o Cuantos usuarios remotos se atendern? Con que frecuencia e intervalos de tiempo? Esta pregunta es necesaria para comparar qu tan rentable es implementar una solucin de acceso remoto VPN o seguir con el acceso remoto tradicional. Si los usuarios remotos son pocos, se podra habilitar el servicio de acceso remoto en un servidor Windows NT, 2000 o Linux y colocar un par de mdems. Si los empleados se conectan desde fuera de la oficina pero no salen de la ciudad, es decir no se incurre en cargos de larga distancia tampoco sale rentable montar un acceso remoto VPN. Si el tiempo de conexin de los trabajadores remotos es de unos pocos minutos, as estn fuera de la ciudad o incluso fuera del pas, se deber evaluar muy bien econmicamente ambos casos, es decir, VPN o el sistema tradicional. El ejemplo de anlisis econmico que se presenta ms adelante sirve como pauta para escoger la opcin ms acertada. o Las ciudades entre las cuales se desplazan los trabajadores que necesitan acceder a los recursos de la red corporativa tienen alguna ISP que ofrezca acceso a Internet conmutado? No se obtiene ningn beneficio si se monta una solucin de acceso remoto VPN donde los empleados remotos no pueden acceder a Internet. En este caso no queda otra opcin que seguir bajo el sistema de acceso remoto tradicional. De todas maneras es claro que Internet

211

ha tenido una penetracin muy fuerte en todos los lugares lo que hace pensar que este problema no sea significativo. o Cuntos usuarios hay en cada red LAN remota? Qu tipo de aplicaciones se manejarn entre ambas sedes? La respuesta a esta pregunta sirve para dimensionar la capacidad del ancho de banda a contratar o el aumento del canal que ya se tiene. De todas maneras este valor est influenciado por apreciaciones probabilsticas sobre el uso simultneo de los tneles por parte de los usuarios. En otras palabras es posible que se necesite el mismo ancho de banda para interconectar dos oficinas que tienen 5 usuarios cada una pero que acceden continuamente a una base de datos o intercambian archivos constantemente, que el necesario para unir dos oficinas con 30 usuarios cada una pero que rara vez acceden a los recursos remotos o que tienen aplicaciones en modo texto. o Las oficinas a conectar ya cuentan con enlace a Internet? A qu velocidad? Es dedicado o conmutado? Conocer esto, ayuda a dimensionar los costos iniciales de la solucin, que en muchos casos es un factor que influye mucho en la toma de una decisin, sobre todo cuando se trata de una empresa pequea que no tiene los recursos para invertir en una solucin dedicada a Internet. En el montaje de una solucin LAN-to-LAN lo ms probable es que se necesiten soluciones de banda ancha para conectar las oficinas a Internet. Cuando el trfico sea bajo o se est montando una solucin de acceso remoto VPN puede ser suficiente una conexin conmutada RDSI en el lado del servidor VPN. o Qu tan confidencial y sensitiva es la informacin que se intercambia? Con esta pregunta lo que se busca es escoger de manera adecuada los gateways VPN. Un algoritmo de cifrado fuerte como 3DES o AES es recomendable implementarlo con soluciones por hardware ya que estos equipos tienen circuitos integrados dedicados a la labor de 212

cifrado, por lo tanto no se sacrifica el desempeo del enlace de manera dramtica. Aqu tambin est involucrada la cantidad de trfico a encriptar obviamente. Definitivamente soluciones con software para este tipo de necesidades no son adecuadas. Si se necesita acceso remoto altamente seguro es necesario instalar clientes IPSec en los equipos porttiles y descartar de plano soluciones con PPTP o L2TP as se habilite el cifrado de datos de Windows, MPPE, el cual es muy pobre comparado con DES y mejores. o Qu tan criticas son las aplicaciones a ejecutar en la VPN para la compaa? Esto sobre todo sirve para escoger el proveedor de acceso a Internet que se va a escoger. Si las aplicaciones que transitan por la VPN son crticas, por ejemplo, un sistema de recaudo en lnea, se tendrn que realizar una serie de exigencias a la ISP tales como ofrecer backup en la ltima milla y el backbone a Internet, fijar una serie de clusulas de cumplimiento a travs de un SLA y garantizar calidad de servicio. El siguiente ejemplo ilustra cmo una solucin de acceso remoto y LAN-toLAN VPN es mucho ms econmica que un escenario de acceso remoto y enlaces privados tradicionales. Se parte de los siguientes supuestos: o Se necesita montar una solucin LAN-to-LAN entre tres oficinas a nivel nacional. o Se necesita tener al menos 20 puertos de acceso remoto para empleados que se desplazan por todo el pas y en determinados casos tienen que salir por fuera del pas. Se asume que al mes al menos un empleado se encuentra en el exterior y 9 se encuentran en otras ciudades diferentes a las tres donde se encuentra las sedes regionales de la compaa. Los otros 10 puertos son usados por los trabajadores que se encuentran visitando clientes en las 213

ciudades donde hay sedes pero no se sabe con certeza la distribucin de esos puertos entre las tres ciudades. o Ninguna sede tiene acceso a Internet y se quiere que cada una de ellas tenga un enlace a Internet de 64Kbit/s bien sea conmutado o dedicado. o En cada oficina hay 30 computadores y se necesita que la totalidad de los 90 computadores hagan parte de una misma red lgica. Se asume que la red LAN en cada sede ya est implementada con switches FastEthernet de 48 puertos.

SOLUCION TRADICIONAL
TRM $2840

COSTO INICIAL
ENLACES WAN Instalacin enlace 128K Cali-Bogota Instalacin enlace 128K Cali-Medelln Instalacin enlace 128K Bogota-Medelln Enrutador Cali Cisco3620 Enrutador Bogota Cisco3620 Enrutador Medelln Cisco3620 Dlares 750 750 750 2800 2800 2800 Pesos $ 2.130.000,00 $ 2.130.000,00 $ 2.130.000,00 $ 7.952.000,00 $ 7.952.000,00 $ 7.952.000,00 $ 30.246.000,00

ACCESO REMOTO Tarjeta de 4 puertos RDSI BRI para Cisco3620 en Cali Tarjeta de 4 puertos RDSI BRI para Cisco3620 en Bogota Tarjeta de 4 puertos RDSI BRI para Cisco3620 en Medelln Instalacin 3 lneas RDSI BRI en Cali Instalacin 3 lneas RDSI BRI en Bogota Instalacin 3 lneas RDSI BRI en Medelln

1100 $ 3.124.000,00 1100 $ 3.124.000,00 1100 $ 3.124.000,00 $ 2.400.000,00 $ 2.400.000,00 $ 2.400.000,00 $ 16.572.000,00

ACCESO A INTERNET Instalacin 1 lnea RDSI BRI en Cali Instalacin 1 lnea RDSI BRI en Bogota Instalacin 1 lnea RDSI BRI en Medelln TOTAL COSTO INICIAL

$ 800.000,00 $ 800.000,00 $ 800.000,00 $ 2.400.000,00 $ 49.218.000,00

COSTO MENSUAL
ENLACES WAN

214

Cargo fijo mensual enlace Cali-Bogota 128K Cargo fijo mensual enlace Cali-Medelln 128K Cargo fijo mensual enlace Bogota-Medelln 128K

600 $ 1.704.000,00 600 $ 1.704.000,00 600 $ 1.704.000,00 $ 5.112.000,00

ACCESO REMOTO LDN de 9 usuarios, durante 20 das hbiles, 3 horas por da LDI de 1 usuario, durante 5 das, 1 hora por da (desde USA) Cargo bsico por 3 lneas RDSI BRI para Cali Cargo bsico por 3 lneas RDSI BRI para Bogota Cargo bsico por 3 lneas RDSI BRI para Medelln La impulsacin local de cada usuario no se tiene en cuenta

$ 5.734.800,00 $ 360.000,00 $ 120.000,00 $ 120.000,00 $ 120.000,00 $ $ 6.454.800,00

ACCESO A INTERNET Cargo bsico por 1 lneas RDSI BRI para Cali Cargo bsico por 1 lneas RDSI BRI para Bogota Cargo bsico por 1 lneas RDSI BRI para Medelln Impulsacin local a Internet 8 horas por un canal de 64K Cali Impulsacin local a Internet 8 horas por un canal de 64K Bogota Impulsacin local a Internet 8 horas por un canal de 64K Medelln Acceso dedicado a Internet de 64K con reuso 1:1 para Cali Acceso dedicado a Internet de 64K con reuso 1:1 para Bogota Acceso dedicado a Internet de 64K con reuso 1:1 para Medelln TOTAL COSTO MENSUAL

$ $ $ $ $ $ 280 $ 300 $

40.000,00 40.000,00 40.000,00 64.000,00 64.000,00 64.000,00 795.200,00 852.000,00

300 $ 852.000,00 $ 2.811.200,00 $ 14.378.000,00

215

Internet 64Kbps CALI BOGOTA 64Kbps

Internet

128Kbps

Usuarios remotos Cali

128Kbps

128Kbps

Usuarios remotos Bogota

MEDELLIN 64Kbps Internet


Usuarios remotos Medellin

9 Empleados a nivel nacional accediendo indistintamente a cualquier RAS corporativo

Empleado en el exterior accediendo indistamente a cualquiera de los RAS corporativos

Figura 7.1. Escenario implementado con tecnologias tradicionales

SOLUCION VPN
TRM $ 2840

COSTO INICIAL
ENLACES A INTERNET Instalacin enlace 512K Cali-Internet Instalacin enlace 512K Bogota-Internet Instalacin enlace 512K Medelln-Internet Dlares 750 750 750 $ $ $ $ Pesos 2.130.000,00 2.130.000,00 2.130.000,00 6.390.000,00

HARDWARE Enrutador Cali Cisco1760 Enrutador Bogota Cisco1760 Enrutador Medelln Cisco1760

1500 1500 1500

$ 4.260.000,00 $ 4.260.000,00 $ 4.260.000,00 $ 12.780.000,00

SOFTWARE 3 Licencias VPN para Cisco1760

1500

$ 4.260.000,00

216

20 Licencias cliente IPSec Cisco (venden el paquete de 100 licencias)29

250

$ 710.000,00 $ 4.970.000,00 $ 24.140.000,00

TOTAL COSTO INICIAL

COSTO MENSUAL
ENLACES WAN Cargo fijo mensual enlace Cali-Internet 512K* Cargo fijo mensual enlace Bogota-Internet 512K* Cargo fijo mensual enlace Medelln-Internet 512K* 1100 1100 1100 $ $ $ $ 3.124.000,00 3.124.000,00 3.124.000,00 9.372.000,00

ACCESO REMOTO Roaming usuario internacional 5 das, 1 hora por da La impulsacin local no se tiene en cuenta

$ $ $

30.388,00 30.388,00

ACCESO A INTERNET 20 Cuentas de acceso conmutado a Internet TOTAL COSTO MENSUAL

$ 560.000,00 $ 560.000,00 $ 9.962.388,00

Cada licencia se instala en el PC de un usuario remoto, de esta manera queda habilitado para ser un cliente IPSec del gateway VPN Cisco. Por mas que IPSec es un estandar, Cisco recomienda instalar su software cliente propietario para una interoperabilidad del 100% con el gateway VPN.
29

217

Empleado en el exterior

Cisco1760 con IOS IPSEC 3DES

ISP Miami

CALI
512Kbps

BOGOTA
512Kbps

Cisco1760 con IOS IPSEC 3DES

ISP Cali Usuarios remotos Cali

Internet
ISP Medellin 512Kbps
Cisco1760 con IOS IPSEC 3DES

ISP Bogota

Usuarios remotos Bogota

MEDELLIN
9 Empleados a nivel nacional accediendo indistintamente a cualquier ISP en el pais Usuarios remotos Medellin

Figura 7.2. Escenario implementado con VPN

Sobre el anterior anlisis econmico hay que anotar que: Para ninguno de los dos escenarios se han tenido en cuenta gastos de instalacin y de configuracin de equipos, pero es claro que este item perjudicara an ms los costos iniciales para la solucion tradicional ya que esta supone ms infraestructura para la compaa. Estos precios son reales y actualizados al mercado colombiano. La diferencia a nivel econmico entre implementar el escenario descrito con las tecnologas tradicionales y con VPNs es muy notoria tanto en los costos iniciales como en los cargos fijos mensuales:

218

Implementacin Tradicional Costo Inicial Costo Mensual 49218.000 14378.000

Implementacin con VPN (IPSec Cisco) 24140.000 9962.388

Diferencia % 50.9% 30.%

El ahorro inicial sera de $25078.000 y mes a mes sera de $4415.612, lo que representa en un ao alrededor de $53000.000.

219

8. RECOMENDACIONES

Con el nimo de seguir incentivando el uso y estudio de las Redes Privadas Virtuales se presentan a continuacin una serie de recomendaciones para trabajos futuros y aplicaciones prcticas que pueden ser muy interesantes: Un trabajo interesante sera evaluar y proponer a una entidad cuya misin crtica sea la proteccin de su informacin para abandonar sus enlaces WAN tradicionales y migrar a una topologa con VPNs. Como resultado de este trabajo debera salir una solucin VPN estado del arte, que involucrara la implementacin de un sistema de llaves pblicas y los ms avanzados algoritmos de encriptacin y autenticacin. Otra recomendacin es realizar un estudio al interior de la Universidad del Valle para implementar Redes Privadas Virtuales entre las distintas sedes de la Universidad a nivel regional y que permita el acceso al cuerpo directivo y docente de la Universidad a la red privada de la misma. Este estudio debera incluir la implementacin de una solucin de Voz sobre IP y videoconferencia privada. Como resultado de este estudio debera salir un cuadro comparativo donde se demuestre el ahorro mensual que tendra la Universidad con la implementacin de VPNs. Un trabajo que se propone a raz de este, es la implementacin de VPNs para la interoperabilidad de los protocolos IPv4 e IPv6. Esto es poder encapsular paquetes IPv6 dentro de paquetes IPv4 para que puedan transitar por redes nativas IPv4 y desencapsularlos al final de un gateway detrs del cual exista una red con dispositivos IPv6.

220

9. BIBLIOGRAFIA
LIBROS [1] [2] [3] [4] [5] [6] [7] Ford, M., Lew, K., Spanier, S. y Stevenson, T.. Internetworking Technologies Handbook. Indianapolis: Cisco Press, 1997. Sklar, Bernard. Digital Communications, Fundamentals and Applications, Second Edition. New Jersey: Prentice Hall PTR, 2000. Kosiur, Dave. Building and Managing Virtual Private Networks. New York: John Wiley & Sons, Inc., 1998. Yuan, Ruixi y Strayer, Timothy. Virtual Private Networks. Technologies and Solutions. New Jersey: Adisson-Wesley, 2001. Pepelnjak, Ivan y Guichard, Jim. MPLS and VPN Architectures. Indianapolis: Cisco Press, 2001 Lee, Thomas y Davies, Joseph. Windows 2000 TCP/IP Protocols and Services. Technical Reference. Redmon: Microsoft Press, 1999. Man, Scott y Krell, Mitchel. Linux TCP/IP Network Administration. New Jersey: Prentice Hall PTR, 2002.

RFC 1334 Lloyd, B. y W. Simpson. PPP Authentication Protocols. Octubre 1992. 1701 Hanks, S., T. Li, D. Farinacci, y P. Traina. Generic Routing Encapsulation (GRE). Octubre 1994. 1760 Haller, N. The S/KEY On-Time Password System, Febrero 1995 1994 Simpson, W. PPP Challenge Handshake Authentication Protocol (CHAP). Agosto 1996.

221

2341 Valencia, A. Littlewood, y T. Kolar. Cisco Layer Two Forwarding (Protocol) L2F. Mayo 1998. 2401 Kent, S. y R. Atkinson. Security Architecture for the Internet Protocol. Noviembre 1998. 2402 Kent, S. y R. Atkinson. IP Authentication Header (AH). Noviembre 1998. 2406 Kent, S. y R. Atkinson. IP Encapsulation Security Payload (ESP). Noviembre 1998. 2408Maughan, D. M. Schertler, M. Schneider, y J. Turner. Internet Security Association and Key Management Protocol (ISAKMP). Noviembre 1998 2409Harkens, D. y D. Carrel. The Internet Key Exchange (IKE). Noviembre 1998. 2459 Housley, R., W. Ford, W. Polk y D. Solo. Internet X.509 Public Key Infrastructure Certificate and CRL Profile. Enero 1999. 2637 Hamzeh, K. G. Pall, W. Vertheing, J. Taarud, W.A. Little, y G. Zorn. Pointto-Point Tunneling Protocol (PPTP). Julio 1999. 2661 Townsley, W., A. Valencia, A. Rubens, G. Pall, G. Zorn, y B. Palter. Layer Two Tunneling Protocol (L2TP). Agosto 1999.

SITIOS WEB http://www.microsoft.com Pagina web oficial de Microsoft Corporation. Fuente de informacin sobre los protocolos PPTP y L2TP sobre computadores instalados con sistemas operativos Windows NT, Windows 2000 server, Windows XP y Windows 2003 Server. http://www.cisco.com Pagina web oficial de Cisco Systems. Compaa mundial lider en la fabricacin de equipos para Internetworking. Dentro de sus productos cuenta con equipos concentradores de tuneles L2F, L2TP y IPSec. Desarrolla sistemas operativos (IOS) para sus enrutadores y switches que capacitan a los mismos para crear y terminar tuneles. http://www.v90.com Pagina desarrollada por Copper Pair Communications Inc. que discute los antecedentes, y beneficios del estandar V.90 para transmisin de datos sobre lineas analogas conmutadas. Ademas ilustra de manera breve las caracteristicas de una red telefonica tradicional. http://www.freeswan.org 222

Pagina web oficial del proyecto FreeS/WAN. FreeS/WAN es una implementacion de IPSec e IKE bajo Linux. http://www.nap.com.co Pagina web oficial del NAP Colombia. El NAP Colombia fue creado e implementado por la Camara Colombiana de Informatica y Telecomunicaciones CCIT. En este sitio se encuentran entre otros los objetivos del NAP, los integrantes y las estadisticas semanales, mensuales, trimestrales, semestrales y anuales del trafico que cursa por este. http://www.rsasecurity.com Pagina web oficial de RSA Security Inc. Esta compaa esta enfocada a brindad soluciones para el establecimiento en linea de identidades, derechos de acceso, y privilegios de acceso para personas, aplicaciones y dispositivos. Sus fundadores desarrollaron el algoritmo de cifrado que lleva su nombre. http://www.pgpi.org Pagina web oficial del proyecto PGP Internacional. El proposito de este proyecto es promover el uso de PGP a nivel mundial a partir de un estandar abierto denominado OpenPGP. PGP es el sistema de cifrado de llaves publicas mas comnmente usado en la actualidad.

223

Вам также может понравиться