COMO ESCOGER E IMPLEMENTAR UNA VPNCONCEPTOS TEÓRICOS Y PRACTICOS

AutorFERNANDO ANDRES ARÉVALO JIMÉNEZ

UNIVERSIDAD DEL VALLEFACULTAD DE INGENIERIA

ESCUELA DE INGENIERIA ELECTRICA Y ELECTRÓNICAINGENIERIA ELECTRÓNICA

SANTIAGO DE CALI2003

COMO ESCOGER E IMPLEMENTAR UNA VPNCONCEPTOS TEÓRICOS Y PRACTICOS

AutorFERNANDO ANDRES ARÉVALO JIMÉNEZ

Trabajo de grado para optaral título de Ingeniero Electrónico

DirectorING. FABIO GUERRERO MSc.

Profesor Asistente

UNIVERSIDAD DEL VALLEFACULTAD DE INGENIERIA

ESCUELA DE INGENIERIA ELECTRICA Y ELECTRÓNICAINGENIERIA ELECTRÓNICA

SANTIAGO DE CALI2003

ii

Nota de aceptación

_______________________________________

_______________________________________

_______________________________________

___________________________________DirectorProf. Ing. Fabio Guerrero MSc.

____________________________________JuradoProf. Ing. Oscar Polanco

_____________________________________JuradoIng. Fabio Ramírez

iii

AGRADECIMIENTOS

A Dios por permitirme ser,a mis padres por su amor, comprensión y por inculcarme la importancia deestudiar,a mi familia por toda su ayuda y comprensión,a mi novia por su apoyo y ayuda,a la Universidad del Valle y a todos los profesores de la EIEE por la formaciónacadémica recibida,a Telesat S.A. por facilitarme el tiempo, espacio y recursos para terminar estetrabajo.

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

tecnología y brindar las pautas necesarias, apoyandose en conceptos técnicos

y prácticos, para una adecuada implementación de la misma sin alejarse del

medio colombiano del sector de las telecomunicaciones.

Los siguientes capítulos componen el presente trabajo:

Capitulo 1 - Los enlaces privados antes de la aparición de las Redes Privadas

Virtuales: Presenta un breve enfoque de las tecnologías WAN

tradicionalmente implementadas, tanto dedicadas como conmutadas, entre

las que se encuentran Clear Channel, Frame Relay, ATM, líneas análogas y

líneas digitales RDSI.

Capitulo 2 – Redes Privadas Virtuales – VPNs: Presenta una descripción de la

tecnología, asi como sus diferentes escenarios y sus componentes básicos.

Capitulo 3 – Arquitecturas VPN: Amplia cada una de las diferentes soluciones

que se pueden implementar con las VPNs, tales como Acceso Remoto, LAN-

to-LAN y Extranets.

v

Capitulo 4 – Autenticación y Cifrado: Presenta los conceptos de seguridad

sobre los cuales se basan todas las tecnologías existentes que sirven para

implementar una VPN.

Capitulo 5 – Tecnologías VPN: Es la esencia del trabajo. Comprende las

tecnologías existentes mas usadas para crear túneles y enlaces encriptados

sobre redes públicas. Comprende temas como PPTP, L2TP, IPSec y MPLS.

Capitulo 6 – Montajes prácticos: Presenta la implementación tres tecnologías

diferentes VPN: Microsoft PPTP (acceso remoto VPN), Cisco IPSec (LAN-to-

LAN VPN) y Linux/FreesWAN (LAN-to-LAN VPN).

Capitulo 7 – Conclusiones: Presenta una serie de conclusiones resultantes del

tratamiento teórico del capitulo 5, los montajes prácticos del Capitulo 6 y

conocimientos del mercado colombiano de la tecnología de la información.

Capitulo 8 – Recomendaciones: Se sugieren ciertos trabajos y proyectos que

podrían resultar del interés que despierte la tecnología de las VPNs entre la

comunidad académica.

vi

TABLA DE CONTENIDO

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

1.1. INTRODUCCIÓN 11.2. ENLACES PRIVADOS 11.3. TIPOS DE ENLACES PRIVADOS 21.3.1. ENLACES DEDICADOS 21.3.1.1. Clear Channel 31.3.1.2. Frame Relay 51.3.1.2.1. Estandarización 61.3.1.2.2. Dispositivos Frame Relay 71.3.1.2.3. Conexiones virtuales Frame Relay 81.3.1.2.4. Identificadores de conexión de enlace de datos (DLCI) 101.3.1.3. ATM (Asynchronus Transfer Mode) 101.3.1.3.1. Estandarización 111.3.1.3.2. Funcionamiento de las redes ATM 111.3.1.3.3. Formato de una celda ATM 121.3.1.3.4. Dispositivos ATM 121.3.1.3.5. Formato de una cabecera ATM 131.3.1.3.6. Conexiones Virtuales ATM 151.3.1.3.7. Conmutación ATM 151.3.2. ENLACES CONMUTADOS 161.3.2.1. Enlaces conmutados análogos 161.3.2.2. Enlaces conmutados digitales – RDSI 19

2. REDES PRIVADAS VIRTUALES – VPNs 222.1. INTRODUCCIÓN 222.2. QUE SON LAS REDES PRIVADAS VIRTUALES – VPNs?

23

3. ARQUITECTURAS VPN 293.1. INTRANET VPN LAN-to-LAN 303.2. ACCESO REMOTO VPN 363.3. EXTRANET VPN 393.4. MODELOS DE ENTUNELAMIENTO 41

4. AUTENTICACIÓN Y CIFRADO 454.1. AUTENTICACIÓN 454.1.1. LAS AMENAZAS DE SEGURIDAD EN LAS REDES DE DATOS 464.1.1.1. Spoofing 474.1.1.2. Hijacking 48

vii

4.1.1.3. Sniffing 494.1.1.4. Ataque del hombre-en-la-mitad 504.1.2. SISTEMAS DE AUTENTICACIÓN 514.1.2.1. Passwords tradicionales 514.1.2.2. Passwords únicos 524.1.2.3. PAP (Password Authentication Protocol) 534.1.2.4. CHAP (Challenge Handshake Authentication Protocol) 544.1.2.5. RADIUS (Remote Authentication Dial-In User Service) 554.2. CIFRADO 584.2.1. CRIPTOGRAFIA DE LLAVES PUBLICAS 604.2.2. DOS ALGORITMOS IMPORTANTES DE LLAVES PÚBLICAS 634.2.2.1. Diffie-Hellman 634.2.2.2. RSA 674.3. INFRAESTRUCTURA DE LLAVES PÚBLICAS 694.3.1. ARQUITECTURA DE UNA INFRAESTRUCTURA DE LLAVES

PUBLICAS 714.3.2. CERTIFICACIÓN

724.3.3. VALIDACIÓN 734.3.4. REVOCACIÓN DEL CERTIFICADO 744.3.5. FORMATOS DE CERTIFICADOS DIGITALES

754.3.5.1. Certificado X.509 754.3.5.2. Certificados PGP

794.3.6. SISTEMAS DE ADMINISTRACIÓN DE CERTIFICADOS 824.3.6.1. Autoridad de certificación (CA) 824.3.6.2. Autoridad de registro (RA) 834.3.6.3. Depósitos de certificados y de CRLs 834.4. CONTROL DE ACCESO 844.4.1. POLÍTICAS DE CONTROL DE ACCESO 854.4.2. REGLAS DE CONTROL DE ACCESO 864.4.3. MECANISMOS DE CONTROL DE ACCESO 874.4.3.1. Listas de control de acceso 884.4.3.2. Listas de capacidades 904.4.4. ADMINISTRACIÓN DE LAS POLÍTICAS DE CONTROL DE

ACCESO90

4.4.4.1. Administración de políticas distribuidas 914.4.4.2. Administración centralizada de políticas 92

5. TECNOLOGÍAS VPN 955.1. PPTP (Point-to-Point Tunneling Protocol) 955.1.1. RELACION ENTRE PPP Y PPTP 975.1.2. TUNELES 1005.1.3. ENTUNELAMIENT LAN-to-LAN

103

viii

5.1.4. COMPONENTES DE UNA VPN PPTP 1055.1.4.1. Servidores PPTP

1055.1.4.2. Software cliente PPTP 1065.1.4.3. Servidores de acceso a la Red

1065.1.4.4. Estructura del protocolo 1085.1.4.5. Conexión de control 1085.1.4.6. Operación del túnel 1105.1.4.6.1. Cabecera mejorada GRE 1115.2. L2TP (Layer 2 Tunneling Protocol) 1125.2.1. COMPONENTES BASICOS DE UN TUNEL L2TP 1135.2.1.1. Concentrador de acceso L2TP (LAC) 1135.2.1.2. Servidor de Red L2TP (LNS) 1135.2.1.3. túnel 1145.2.2. TOPOLOGÍA DE L2TP 1145.2.3. ESTRUCTURA DEL PROTOCOLO L2TP 1155.2.3.1. Formato de una cabecera L2TP 1165.2.3.2. Tipos de mensajes de control 1185.2.4. OPERACIÓN DEL PROTOCOLO 1195.2.4.1. Establecimiento de la Conexión de Control 1205.2.4.2. Autenticación del túnel 1215.2.4.3. Establecimiento de la Sesión 1215.2.4.3.1. Establecimiento de una Llamada Entrante 1225.2.4.3.2. Establecimiento de una Llamada Saliente 1225.2.4.4. Reenvío de tramas PPP

1235.2.4.5. Uso de números de secuencia en el Canal de Datos 1235.2.4.6. Keepalive (Hello) 1245.2.4.7. Terminación de la Sesión 1255.2.4.8. Terminación de la Conexión de Control 1255.3. IPSEC 1265.3.1. COMPONENTES DE IPSEC 1275.3.1.1. Protocolos de Seguridad 1275.3.1.2. Asociaciones de Seguridad (SAs) 1285.3.1.3. Bases de Datos de Seguridad 1315.3.1.3.1. Bases de Datos de Asociaciones de Seguridad (SAD) 1315.3.1.3.2. Bases de Datos de Políticas de Seguridad 1325.3.2. AUTHENTICATION HEADER 1355.3.2.1. Modo Transporte 1385.3.2.2. Modo túnel 1395.3.3. ENCAPSULATION SECURITY PAYLOAD – ESP 1405.3.3.1. Modo Transporte 1425.3.3.2. Modo Túnel 1435.3.4. INTERNET KEY EXCHANGE 1445.3.4.1. Fase 1 IKE 1485.3.4.2. Fase 2 IKE 1505.3.4.3. Generación de Llaves en IKE 151

ix

5.4. MPLS152

5.4.1. DIFERENCIACIÓN DE PAQUETES POR SERVICIO 1565.4.2. INDEPENDENCIA Y CONTROL DEL REENVIO 1575.4.3. PROPAGACIÓN DE INFORMACIÓN EXTRA DE ENRUTAMIENTO 1585.4.4. QUE ES MPLS? 1585.4.5. COMPONENTES DE UNA RED MPLS 1625.4.6. MECANISMO DE IMPOSICIÓN DE ETIQUETAS EN MPLS 1635.4.7. REENVIO DE PAQUETES MPLS 164

6. MONTAJES PRACTICOS 1676.1. ACCESO REMOTO CON PPTP 1676.1.1. ESCENARIO MONTADO6.1.2. INSTALACIÓN Y CONFIGURACIÓN DEL SERVIDOR PPTP

1686.1.3. INSTALACIÓN Y CONFIGURACIÓN DE UN CLIENTE PPTP

EN WINDOWS XP 1786.2. LAN-to-LAN IPSEC USANDO EQUIPOS CISCO 1886.2.1. ESCENARIO MONTADO 1886.2.2. INSTALACION Y CONFIGURACION 1886.3. LAN-to-LAN IPSEC USANDO LINUX Y FreeS/WAN 1986.3.1. ESCENARIO MONTADO 1986.3.2. INSTALACION Y CONFIGURACIÓN 198

7. CONCLUSIONES 207

8. RECOMENDACIONES 220

9. BIBLIOGRAFIA 221

x

LISTA DE FIGURAS

Figura 1.1 Enlace típico Clear Channel. Esquema Básico 4Figura 1.2 Enlace típico Clear Channel. Esquema detallado 5Figura 1.3 Diferentes dispositivos que intervienen en una red

Frame Relay. Esquema básico. 7Figura 1.4 Ejemplo de asignación de valores DLCI en una red

Frame Relay.10

Figura 1.5 Formato básico de una celda ATM 12Figura 1.6 Dispositivos que intervienen en una red ATM 13Figura 1.7 Formato de las diferentes cabeceras de una celda

ATM. A la izquierda el formato general, en el centrouna celda UNI, y a la derecha una celda NNI 14

Figura 1.8. Canales Virtuales (VC) dentro de caminos virtuales (VP) 15Figura 1.9. Ancho de banda de un canal convencional de voz humana 17Figura 1.10 Escenario típico de una conexión análoga de datos

sobre la RTPC. 18Figura 1.11 Escenario típico de una conexión análoga donde

los enlaces de último kilómetro en ambos lados sonanálogos. 19

Figura 1.12 Diagrama de Interfaces y equipos en una conexiónRDSI BRI. 20

Figura 2.1 Distintas maneras de crear una VPN 24Figura 2.2 Elementos básicos de un túnel VPN 25Figura 2.3 Una topología más compleja y detallada de una VPN 26

Figura 3.1 Enlace Punto-a-punto 30Figura 3.2 Topología en estrella 30Figura 3.3 Topología de malla parcial 31Figura 3.4. Topología de malla completa 31Figura 3.5. Detalle de 4 nodos en estrella con 2 PVCs 32Figura 3.6 Esquema de una solución Intranet VPN

(LAN-to-LAN VPN) 33Figura 3.7 Tráfico total consolidado mes a mes que se ha

cruzado por el NAP Colombia desde Julio de 2001hasta Abril de 2003. [Fuente: http://www.nap.com.co] 36

Figura 3.8 Escenario de Acceso remoto VPN 38Figura 3.9 Dos montajes típicos de un acceso remoto VPN 39Figura 3.10 Arquitectura Extranet VPN, clasificando el acceso

según privilegios de los clientes VPNs remotos 40

xi

Figura 3.11 Modelos de entunelamiento VPN 41

Figura 4.1 Autenticación RADIUS usando un servidor proxy 57Figura 4.2 Esquema de cifrado con llaves públicas 61Figura 4.3 Arquitectura de una infraestructura de llaves públicas

71Figura 4.4 Formato de un certificado X.509v3 77Figura 4.5 Un certificado digital X.509 tal como lo muestra

Netscape 79Figura 4.6 Certificado PGP en su versión ASCII 80Figura 4.7 Estructura de un certificado PGP 81Figura 4.8 Control de acceso en un modelo cliente-servidor 85Figura 4.9 Manejo de políticas distribuidas 92Figura 4.10 Manejo de políticas centralizado 94

Figura 5.1 Conexión PPP típica entre un host y un RAS 96Figura 5.2 Estructura de un túnel PPTP 100Figura 5.3 Túneles Voluntarios

101Figura 5.4 Túneles Permanentes 102Figura 5.5 Topología LAN-to-LAN usando un túnel PPTP 104Figura 5.6 Estructura general de un paquete IP encapsulado

PPTP 111Figura 5.7 Distintos escenarios de túneles L2TP 114Figura 5.8 Estructura del protocolo L2TP 116Figura 5.9 Formato de una cabecera L2TP 116Figura 5.10 Entunelamiento de tramas PPP usando L2TP 120Figura 5.11 Establecimiento de una conexión de control 121Figura 5.12 Establecimiento de una llamada entrante 122Figura 5.13 Establecimiento de una llamada saliente

122Figura 5.14 Terminación de la sesión 125Figura 5.15 Terminación de la conexión de control 126Figura 5.16 Estructura del paquete IP en modo de Transporte

y Túnel 129Figura 5.17 Ejemplos de entradas en una base de datos

de políticas de seguridad 134Figura 5.18 Formato de la cabecera de autenticación 136Figura 5.19 Modo Transporte AH 138Figura 5.20 Modo Túnel AH 139Figura 5.21 Nuevo paquete IP procesado con ESP 141Figura 5.22 Modo transporte ESP 143Figura 5.23 Modo túnel ESP 144Figura 5.24 Formato de un mensaje y una cabecera ISAKMP 145Figura 5.25 Intercambio de mensajes en la fase 1 IKE usando

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

modo agresivo 150

xii

Figura 5.27 Intercambio de mensajes en la fase 2 IKE usandomodo rápido 150

Figura 5.28 Red IP basada en un backbone ATM 154Figura 5.29 Backbone IP sin políticas de control de tráfico 156Figura 5.30. Arquitectura de un nodo MPLS 161Figura 5.31 Mecanismos de imposición y de extracción de

etiquetas MPLS y reenvío de paquetes etiquetados 166

Figura 6.1 Escenario PPTP implementado en Windows 2000Server167

Figura 6.2 Escenario IPSec LAN-to-LAN implementado conequipos Cisco 188

Figura 6.3 Escenario IPSec LAN-to-LAN implementadoen Linux con la aplicación FreeS/WAN 198

Figura 7.1. Escenario implementado con tecnologías tradicionales 216Figura 7.2. Escenario implementado con VPN 218

xiii

LISTA DE TABLAS

Tabla 1.1. Equivalencia entre sistemas SONET y SDH 3

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

Tabla 4.1 Comparación de tiempo y dinero necesarios para romper llaves de diferente longitud 59

xiv

1. LOS ENLACES PRIVADOS ANTES DE LA APARICION

DE LAS REDES PRIVADAS VIRTUALES

1.1. INTRODUCCIÓN

Desde el principio de los tiempos, la humanidad ha tenido la necesidad de

comunicarse. Paralelamente también 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 implementación de enlaces

privados para transportar de forma segura toda su información confidencial.

Este capítulo trata sobre la manera en que se realizan los enlaces privados, y

las diferentes tecnologías que los soportan.

1.2. ENLACES PRIVADOS

Los enlaces privados se caracterizan por brindar seguridad en la transmisión

de datos de extremo a extremo. Se valen siempre de una red de transmisión

(en algunos casos también existe una red de conmutación) para conectar las

partes. Estos enlaces pueden ir desde los 9600bps (en el caso de una

conexión conmutada usando un modem análogo de 9600bps) hasta el orden

1

de los Gigabps (usando redes ópticas, con equipos de transporte de última

generación o multiplexores DWDM).

1.3. TIPOS DE ENLACES PRIVADOS

Las redes de computadores se han valido de los enlaces privados para

interconectarse a través de grandes distancias geográficas. Antes de la

aparición de las VPN habían existido solo dos tecnologías de enlaces WAN, los

enlaces dedicados, y los enlaces conmutados.

Dentro de los enlaces dedicados caben topologías tales como Clear Channel,

Frame Relay y ATM. Aunque se sabe que Frame Relay usa conmutación de

paquetes y ATM usa conmutación de celdas, en este trabajo se clasifican

como enlaces dedicados, porque en últimas para el usuario la conmutación es

transparente.

Dentro de los enlaces conmutados están los análogos 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 conmutación

(Capa 1 y 2). Los primeros son comúnmente llamados enlaces Clear

Channel y los segundos son enlaces Frame Relay o ATM.

2

1.3.1.1. Clear Channel

Son enlaces donde solo interviene la red de transporte del proveedor

de servicios. Para el mercado corporativo comúnmente 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 transmisión desde

OC-1 hasta OC-768 así como su correspondencia entre redes SONET y

SDH.

SONET SDH MbpsOC-1 --- 51.84OC-3 STM-1 155.52OC-12 STM-4 622.08OC-48 STM-16 2455.32 (2.5 Gbps)OC-192 STM-64 9953.28 (10 Gbps)OC-768 STM-256 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 ningún tipo de encapsulación de nivel 2, es

decir, no hay presentes cabeceras de ningún 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 compañía (o cliente en general) debe tener un puerto

disponible DTE que cumpla con las especificaciones técnicas del equipo

de comunicaciones entregado por el proveedor. Típicamente la

mayoría de los equipos que se usan para recibir los enlaces Clear

3

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 topologías de los enlaces Clear Channel son robustas

pero a su vez estáticas. 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

tecnología WAN que se adoptó usando la infraestructura de voz PCM

de los distintos operadores de telefonía locales, nacionales e

internacionales. Como era de esperarse, por provenir de una

tecnología que no había sido pensada para transmitir datos fue

superada rápidamente por otros tipos de tecnologías como Frame

Relay y ATM, aunque aun muchas empresas siguen teniendo enlaces

Clear Channel. La figura 1.1 muestra un esquema básico, donde se

observa la transparencia para una organización del enlace Clear

Channel contratado.

Redde

Transporte

Sitio1 Sitio2

nx64nxE1

STM-n

nx64nxE1

STM-n

Figura 1.1 Enlace típico Clear Channel. Esquema Básico

1 En la actualidad existen enrutadores y switches que manejan incluso protocolos a nivel 4. Estos equipos seusan para balancear tráfico entre varios servidores, redireccionamiento de tráfico, políticas de calidad deservicio y accounting (toda aquella información que sirve para tarifar transacciones o servicios) .

4

La figura 1.2 muestra un esquema detallado de los equipos usados en

una topología de transporte de datos Clear Channel. También muestra

los límites 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 físico a utilizar: cobre, fibra óptica o espectro

electromagnético.

BACKBONEen anilloFO+RF

CSU/DSU CSU/DSUTerminalOpticoSTM-1

TerminalOpticoSTM-1

Servidor deAplicaciones

Estacionde Trabajo

Enrutador Enrutador

BACKBONEÚLTIMOKILOMETRO

RED CORPORATIVASitio1

RED CORPORATIVASitio2

Base deDatos

ÚLTIMOKILOMETRO

Figura 1.2 Enlace típico Clear Channel. Esquema detallado

1.3.1.2. Frame Relay

Frame Relay es un protocolo WAN de alto rendimiento que trabaja en

la capa física y de enlace de datos del modelo de referencia OSI.

Frame Relay fue diseñado originalmente para trabajar con redes ISDN.

Frame Relay es una tecnología de conmutación de paquetes, que

permite compartir dinámicamente el medio y por ende el ancho de

banda disponible. La longitud de los paquetes es variable para hacer

más 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 conmutación de

paquetes es controlado usando técnicas de multiplexación estadística,

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 más usados,

también usan conmutación de paquetes y técnicas de difusión.

Frame Relay es una evolución de las redes X.25, no hace retransmisión

de paquetes perdidos ni windowing2, características que si ofrecía su

antecesor ya que en los años 70 (época en la que aparece X.25) los

medios físicos no eran tan confiables como los de hoy día, y por tanto

se necesitaba mayor robustez. Todas las ventajas que ofrecen los

medios de hoy día, han posibilitado a Frame Relay ofrecer un alto

desempeño y una gran eficiencia de transmisión. [REF1.1.]

1.3.1.2.1. Estandarización

Los propósitos iniciales para estandarizar Frame Relay fueron

presentados al Comité Consultivo Internacional para la Telefonía y

la Telegrafía (CCITT) pero no tuvieron mucha acogida. Solo hasta

1990 cuando Cisco, Digital Equipment, Nortel Networks (en ese

tiempo todavía 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 organización junto

con la americana ANSI se interesaran de nuevo en Frame Relay y

finalmente se publicara un estándar, que fue apoyado por la ITU-T.

Esta estandarización le dio tal fuerza a Frame Relay que

prácticamente todos los fabricantes de equipos de comunicaciones

2 Windowing es un esquema de control de flujo en el cual el dispositivo fuente requiere un reconocimientodel destino después que un cierto número de paquetes han sido transmitidos. Por ejemplo con un tamaño deventana de tres, la fuente requiere de un mensaje de reconocimiento después que ha enviado tres paquetespara poder continuar con la transferencia.

6

de datos desarrollaron dispositivos que soportaron la creciente

tecnología.

1.3.1.2.2. Dispositivos Frame Relay

Los equipos que se usan en una red Frame Relay se pueden dividir

en dos categorías: Equipos Terminales de Datos (DTEs) y Equipos

Terminales de Circuitos de Datos (DCEs). La figura 1.3 ilustra la

ubicación de los DTEs y los DCEs en un red Frame Relay.

Los DTEs son generalmente considerados equipos terminales de

una red especifica y típicamente son enrutadores, computadores

personales, terminales o bridges. Estos equipos se localizan en las

premisas del cliente y en la mayoría de los casos son propiedad de

los mismos.

Los DCEs son dispositivos normalmente propiedad del carrier. El

propósito de los equipos DCEs es proveer o generar señales de

reloj y conmutar los paquetes de la red. Por lo general, son

llamados packet switchs o conmutadores de paquetes.

PacketSwitch

DCE

RedFrame Relay

DTE

Terminal

DTE

Enrutador

DTE

Brigde

Figura 1.3 Diferentes dispositivos que intervienen en una red Frame Relay. Esquema básico.

7

En la conexión entre los dispositivos DCE y DTE intervienen dos

componentes, uno de nivel físico y otro de nivel de enlace de

datos. En el nivel físico se definen todas las características físicas,

eléctricas y mecánicas entre los dos, y el nivel de enlace de datos

define todas las especificaciones Frame Relay o Frame Relay LMI

según sea el caso.

1.3.1.2.3. Circuitos virtuales Frame Relay

Frame Relay es una tecnología WAN que usa enlaces orientados a

conexión, esto significa que una comunicación 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

lógicas creadas entre dos dispositivos DTE a través de la red

conmutada de paquetes Frame Relay. Sobra decir que este circuito

es bidireccional.

Un circuito lógico puede crearse a través de múltiples dispositivos

intermediarios DCE dentro de la red Frame Relay.

Los circuitos virtuales Frame Relay se pueden dividir en dos

categorías: 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

esporádica a través de la red Frame Relay. Los SVCs tienen 4

estados operacionales:

8

Call Setup: Cuando se realiza la negociación 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 conexión entre los dos DTEs está todavía activa,

pero no hay tráfico de datos. Si por cierto periodo de tiempo el

circuito se encuentra en este estado, se procede a terminar la

conexión.

Call Termination: Cuando el circuito virtual entre los dos DTEs

es terminado.

Si después de terminado el circuito los dispositivos DTEs necesitan

transmitir más 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 característica 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 configuración ni de terminación como en los SVCs. De

hecho los PVCs siempre operan en uno de los siguientes dos

estados:

Data transfer: Cuando los DTEs están intercambiando tráfico.

Idle: Cuando no hay transferencia de datos, pero la conexión

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 conexión 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. Nótese que en la figura 1.4 existen valores

repetidos de DLCIs pero no en un mismo DCE. Además, los dos

extremos del PVC pueden tener valores diferentes.

DCE

RedFrame Relay

DTE

Terminal

DTE

Enrutador

DTE

BrigdeDTE

DLCI12

DLCI23

DLCI18

DLCI23

DLCI12

DLCI41

PacketSwitch

Figura 1.4 Ejemplo de asignación de valores DLCI en una red Frame Relay.

1.3.1.3. ATM (Asynchronous Transfer Mode)

El Modo de Transferencia Asíncrono (ATM) es un estándar desarrollado

por la Unión Internacional de Telecomunicaciones (ITU-T) para

transmitir múltiples tipos de servicios, tales como voz, video y datos

10

usando técnicas de conmutación de celdas pequeñas de tamaño fijo.

Las redes ATM son, al igual que las redes Frame Relay, orientadas a

conexión. [REF1.2]

1.3.1.3.1. Estandarización

ATM está basado en esfuerzos hechos por el grupo de trabajo

BISDN (Broadband Integrated Services Digital Network) de la ITU-

T. Fue originalmente concebido como una tecnología de

transferencia de voz, video y datos de alta velocidad sobre redes

públicas. Luego el Foro ATM extendió la visión pública 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)

1.3.1.3.2. Funcionamiento de las redes ATM

ATM es una tecnología de multiplexación y de conmutación de

celdas que combina los beneficios de una red de conmutación de

circuitos (capacidad garantizada, retardos constantes) y de una red

de conmutación de paquetes (flexibilidad y eficiencia para tráfico

intermitente). Permite transmisiones desde unos pocos megabits

por segundo hasta cientos de gigabits por segundo.

Su naturaleza asíncrona, hace de ATM una tecnología más eficiente

que las síncronas tales como TDM. En TDM a los usuarios se les

11

asigna un timeslot, y ningún 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 están

disponibles y se asignan por demanda basándose en la información

que está contenida en las cabeceras de cada celda.

1.3.1.3.3. Formato de una celda ATM

ATM transmite información en unidades de tamaño fijo llamadas

celdas. Cada celda contiene 53 octetos o bytes. Los primeros 5

bytes conforman la cabecera y los restantes 48 contiene la

información del usuario o payload tal como se ve en la figura 1.5.

El tamaño pequeño de cada celda hace que las transmisiones de

voz y video gocen de una buena calidad ya que esta clase de

tráfico no tolera retardos producidos por esperar paquetes de gran

tamaño.

Header Payload

5 48

Figura 1.5 Formato básico 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

están provistos de un adaptador de interfaz de red ATM, por lo

general están 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).

Red ATM

Switch LAN

Enrutador

Estación de Trabajo

CSU/DSU

ATM Switch

TerminadoresATM

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 comunicación entre

switches ATM y en una red pueden haber muchos de ellos.

13

53bytes

CLP

8 bits

ATM Cell

Payload(48 bytes)

Header(5 bytes)

Payload(48 bytes)

Payload(48 bytes)

HEC

VPI

PTCLP

VCI VCI

VPI

HEC

PT

ATM UNI Cell ATM NNI Cell

VPI

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 genérico (GFC): Contiene funciones locales,

tales como identificadores para múltiples 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 través de una

red de switches ATM.

Identificador de canal virtual (VCI): Tiene la misma función que

un VPI pero a nivel más 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 información de datos del usuario o de control.

Prioridad para evitar congestión (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 básicamente redes orientadas a conexión, esto

significa que se tienen que configurar canales virtuales (VC) a

través de la red para la adecuada transferencia de datos. Haciendo

la analogía 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 combinación 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 relación entre VCs y VPs.

Canal de Transmisión

VP

VP

VP

VP

VC

VC

VC

VC

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

1.3.1.3.7. Conmutación ATM

La función básica de un switch ATM es la de reenviar. Una celda es

recibida a través de un enlace con un valor conocido VCI o VPI. El

15

switch mira en su tabla local de traslación para determinar el

puerto (o puertos) de salida para este tráfico y les coloca un nuevo

VPI o VCI, y así se repite este esquema hasta que el tráfico 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 análogos 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 inglés) que son las siglas de Red Digital de Servicios

Integrados.

1.3.2.1. Enlaces Conmutados Análogos

Fue quizá la primera tecnología de transmisión de datos que usó el

hombre para construir redes privadas entre dos sitios remotos. Esto lo

hizo aprovechando la Red de Telefonía Pública Conmutada - RTPC

(PSTN, en inglés), dicha red ha tenido muchos desarrollos en los

últimos 20 años. El servicio tradicional que la RTPC ha prestado ha sido

comunicación 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 energía espectral se encuentra entre los

300Hz y 3.4Khz, por ende, la ITU ha definido un canal de voz (speech

channel) para telefonía en esta banda [REF1.4]. Por cuestiones

prácticas, 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.

300Hz 3400Hz 4000Hz0Hz

Canal de Voz

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 telefonía, todos los equipos fueron diseñados para transmitir

señales en este rango. Las investigaciones que se hicieron en el campo

de las comunicaciones han demostrado que transportar cualquier

señal, incluso la voz, en formato digital tiene inmensas ventajas

comparado con una transmisión análoga, de allí que nuestra voz sea

convertida en una señal digital en las centrales telefónicas y

transportada de la misma manera entre ellas.

Apoyándose un poco en la teoría, el criterio de muestreo de Nyquist

[REF1.5] dice que para recuperar una señal análoga partiendo de ella

misma pero digitalizada se tiene que muestrear al doble de la

frecuencia máxima, 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

básica de transmisión de voz, y que hoy prácticamente ha sido una

limitante para las comunicaciones de datos sobre redes telefónicas,

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 típico de datos sobre la red telefónica

pública, se puede notar la necesidad de realizar una conversión A/D y

otra D/A. La inercia que resulta de todo este proceso electrónico es la

que en últimas limita a 56 kbit/s3 una comunicación análoga, que

incluso puede llegar a 33.6 kbit/s cuando aparece una tercera y cuarta

conversión entre la Central Telefonica 2 y el terminador de la llamada.

RTPCCentral

Telefónica 1Central

Telefónica 2Iniciador

de la llamada Terminadorde la llamada

ConversiónD/A

ConversiónA/D

Enlace DigitalEnlace Análogo

Figura 1.10 Escenario típico de una conexión análoga de datos sobre la RTPC.

Se puede notar que la conexión entre el iniciador de la llamada y la

central telefónica es análoga, y se lleva a cabo usando el mismo par de

cobre de la línea telefónica, para esto se usa un modem análogo.

Mientras que en el lado del sitio remoto la conexión 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

3 Este valor es teórico, en la práctica no se obtienen velocidades superiores de 53 kbit/s para el downstreamy de 48 kbit/s para el upstream.

18

Access Server – RAS). Cuando este enlace es también análogo,

entonces se puede notar que en el proceso total de la conexión

intervienen cuatro conversiones, dos A/D y dos D/A, esto hace que la

rata de transmisión y de recepción máximas sean apenas de 33.6

kbit/s. La figura 1.11 ilustra este escenario.

RTPCCentral

Telefónica 1Central

Telefónica 2Iniciadorde la llamada Terminador

de la llamada

ConversiónD/A

ConversiónA/D

Enlace DigitalEnlace Análogo Enlace Análogo

ConversiónD/A

ConversiónA/D

Figura 1.11 Escenario típico de una conexión análoga donde los enlaces de último kilómetro en

ambos lados son análogos.

1.3.2.2. Enlaces Conmutados Digitales – RDSI

RDSI o Red Digital de Servicios Integrados, es un sistema de telefonía

digital que se desarrollo hace más de una década. Este sistema

permite transmitir voz y datos simultáneamente a nivel global usando

100% conectividad digital.

En RDSI, la voz y los datos son transportados sobre canales B (del

inglés Bearer) que poseen una velocidad de transmisión 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 señalización

y tiene ratas de 16 kbit/s o 64 kbit/s dependiendo del tipo de servicio.

Los dos tipos básicos de servicio RDSI son: BRI (del inglés Basic Rate

Interface) y PRI (del inglés 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 conexión para usuarios residenciales.

Un enlace PRI está orientado a usuarios que requieren un mayor

ancho de banda. En Estados Unidos la estructura básica 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 estándar internacional de

la ITU-T, y que además es el estándar 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 línea RDSI. Si

solo se desean comunicaciones de voz es necesario tener teléfonos

digitales RDSI, y para transmitir datos es necesario contar con un

adaptador de Terminal – TA (del inglés 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.

NT-1SwitchRDSI

TA

TE1 TE1

TE2CentralTelefónica

InterfaceU

InterfaceS/T

Adaptador deTerminal

PuertoPOTS

EquipoAnálogo

DispositivosRDSI

DispositivosRDSI

Fax DigitalesTeléfonos Digitales

Terminalde Red

Figura 1.12 Diagrama de Interfaces y equipos en una conexión RDSI BRI.

20

A diferencia de las conexiones conmutadas análogas en una conexión

RDSI el camino es 100% digital desde la central hasta el sitio del

abonado, por lo cual no existe ningún tipo de conversiones A/D o

viceversa, lo que facilita la obtención 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 lógico de 128 kbit/s. Esta característica es usada solo en

transmisión de datos y depende de la facilidad que tenga el equipo

terminal de realizar esto. Típicamente esta característica 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] Recomendación G.100, Definitions used in Recommendations on

general characteristics of internacional telephone connections andcircuits, ITU-T, 1993

[REF1.5] Digital Communications, Pag. 63. Bernard Sklar, 1998, Second Edition[REF1.6] Recomendación G.711, Pulse Code Modulation (PCM) of voice

frecuencies, ITU-T, 1988

21

2. REDES PRIVADAS VIRTUALES – VPNs

2.1. INTRODUCCIÓN

Es comúnmente aceptado el hecho que las tecnologías de información en

Internet han cambiado la forma como las compañías se mantienen

comunicadas con sus clientes, socios de negocios, empleados y proveedores.

Inicialmente las compañías eran conservadoras con la información 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

comunicación, las redes privadas virtuales han hecho su aparición con más

fuerza que nunca y se han ganado un espacio dentro del tan cambiante

mundo de las redes de información. [REF2.1].

Tradicionalmente, un enlace privado se ha hecho por medio de tecnologías

WAN como X.25, Frame Relay, ATM, enlaces Clear Channel o enlaces

conmutados (todas estas tecnologías WAN tratadas en el capítulo 1). Ahora

con el gran crecimiento de Internet, es posible usar un protocolo como IP, sin

importar la tecnología 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 pequeñas

oficinas sucursales, y es aquí principalmente donde han surgido con fuerza

las soluciones basadas en VPNs sobre IP, pues su implementación resulta

sencilla y bastante económica.

Además el hecho que las VPNs se construyan sobre infraestructuras públicas

ya creadas han hecho que las empresas ahorren más del 50% del costo que

antes tenían que pagar en llamadas de larga distancia y en equipos físicos de

acceso remoto o en alquiler de enlaces privados o dedicados.

2.2. QUE SON LAS REDES PRIVADAS VIRTUALES -

VPNs

Una VPN es una conexión que tiene la apariencia y muchas de las ventajas de

un enlace dedicado pero trabaja sobre una red pública. Para este propósito

usa una técnica llamada entunelamiento (tunneling), los paquetes de datos

son enrutados por la red pública, tal como Internet o alguna otra red

comercial, en un túnel privado que simula una conexión punto a punto. Este

recurso hace que por la misma red puedan crearse muchos enlaces por

diferentes túneles virtuales a través de la misma infraestructura. También

hace universales para su transporte los diferentes protocolos LAN entre los

que se encuentran IP, IPX, Appletalk y Netbeui, de allí la característica de

multiprotocolo que hace sumamente universal la tecnología de las redes

virtuales privadas. La figura 2.1 muestra los distintos escenarios que se

pueden manejar con la tecnología de Redes Privadas Virtuales (Dial-Up,

Intranet VPN y Extranet VPN). [REF2.2]

23

Terminador deTúneles

Firewall

UsuarioTeleconmutado

UsuarioTeleconmutado

IBM Compatible

IBM Compatible

OFICINAPRINCIPAL

Usuarios VPNDial-up

Socios deNegocio/Clientes

OficinaSucursal

Dial-upVPN

ExtranetVPN

IntranetVPN

INTERNET

Figura 2.1 Distintas maneras de crear una VPN

Las técnicas de entunelamiento se tratan con mayor detenimiento en el

capítulo 5 de este documento, pero básicamente 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 básicos de un túnel, y que se muestran en la figura 2.2.

son:

Un iniciador del túnel

Uno o varios dispositivos de enrutamiento

Un conmutador de túneles (opcional)

Uno o varios terminadores de túneles

El inicio y la terminación del túnel pueden ser hechos por una amplia variedad

de equipos o software. Un túnel puede ser empezado, por ejemplo, por un

24

usuario remoto con un computador portátil equipado con un modem análogo

y un software de conexión telefónica para hacer una VPN, también puede

haber un enrutador de una extranet en una oficina remota o en una LAN

pequeña. Un túnel puede ser terminado por otro enrutador habilitado para tal

fin, por un switch con esta característica o por un software que haga tal fin.

Servidor deacceso

Computador consoftware cliente VPN

Servidor deAcceso

Gateway VPN

INTERNETTÚNEL

Enrutadorcon software VPN

Iniciadoresde Túneles

Terminadoresde Túneles

Figura 2.2 Elementos básicos de un túnel VPN

Adicionalmente y para completar una solución VPN deben existir uno o más

dispositivos o paquetes de software que brinden cifrado, autenticación y

autorización a los usuarios del túnel. Además muchos de estos equipos

brindan información sobre el ancho de banda, el estado del canal y muchos

más datos de gestión y de servicio.

La figura 2.3 muestra un diagrama más 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

GatewayVPN

PCcon PPTP*

Servidor deAcceso

OFICINAPRINCIPAL

INTERNET

Proveedorde Serviciosde Internet Conexion

dedicada a Internet

Enlace PPP

Enlace PPTP**PPTP = (Point to Point Tunneling Protocol), Protocolo de entunelamiento punto.

Se tratara con mas detalle en el capitulo 5.

T Ú N E L

Figura 2.3 Una topología más compleja y detallada de una VPN

En muchos casos las características que le permiten a los dispositivos ser

iniciadores o terminadores del túnel se pueden adicionar con una simple

actualización del sistema operativo o de sus tarjetas.

Una buena solución VPN requiere la combinación de tres componentes

tecnológicos críticos: seguridad, control de tráfico 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 autenticación para poder verificar acertadamente

tanto la identidad de los usuarios como la integridad misma de la información.

Control de tráfico: el segundo componente crítico en la implementación de

una efectiva VPN es el control de tráfico que garantice solidez, calidad del

servicio y un desempeño veloz. Las comunicaciones en Internet pueden llegar

a ser excesivamente lentas, lo que las convertirían en soluciones inadecuadas

26

en aplicaciones de negocios donde la rapidez es casi un imperativo. Aquí es

donde entra a jugar parámetros como la prioridad de los datos y la

garantización de ancho de banda.

Manejo empresarial: El componente final crítico en una VPN es el manejo

empresarial que esta tenga. Esto se mide en una adecuada integración con

la política de seguridad de la empresa, un manejo centralizado desde el punto

inicial hasta el final, y la escalabilidad de la tecnología.

Las VPNs se caracterizan también 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 inglés), una compañía

puede tener fácilmente toda una infraestructura de acceso remoto, sin la

necesidad de tener una gran cantidad de líneas telefónicas análogas o

digitales, y de tener costosos pools de módems 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

conexión a Internet local, pues ven en este tipo de negocio un mayor interés

por los dividendos del acceso.

El objetivo final de una VPN es brindarle una conexión 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 conexión se

realice sobre una infraestructura pública.

REFERENCIAS:

[REF2.1] Revista Data Communications, Artículo Next-Gen VPNs: The DesignChallenge, Pag. 83, Vol. 28, No. 12, Septiembre de 1999.

27

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

28

3. ARQUITECTURAS VPN

El éxito de una VPN depende de una adecuada elección de la tecnología y del

escenario, siempre acordes a las necesidades que se tengan.

La tecnología implica: técnicas de entunelamiento, autenticación, 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, múltiples redes remotas

de la misma compañía son conectadas entre si usando una red pública,

convirtiéndolas en una sola LAN corporativa lógica, y con todas las ventajas de la

misma.

Acceso Remoto VPN: En este caso, un host remoto crea un túnel 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

conexión conmutada, o una conexión de banda ancha permanente.

Extranet VPN: Esta arquitectura permite que ciertos recursos de la red

corporativa sean accesados por redes de otras compañías, 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 más oficinas remotas de una misma

compañía se han necesitado contratar enlaces dedicados Clear Channels o

Circuitos Virtuales Permanentes (PVCs) Frame Relay.

Las empresas adoptan diferentes topologías 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 topologías anteriormente mencionadas.

LAN 1 LAN 2ENLACE

WAN

Figura 3.1 Enlace Punto-a-punto.

Figura 3.2 Topología en estrella

30

Figura 3.3 Topología de malla parcial

Figura 3.4. Topología de malla completa

En general, cuando se necesita concentrar tráfico en al menos un nodo, es

preferible usar tecnologías como Frame Relay pues solo se necesita un último

kilómetro por el cual viajan todos los PVCs contratados con el proveedor de

servicio; pero económicamente sigue siendo igual de costosa porque las

compañías que prestan el servicio de interconexión Frame Relay cobran por

PVC activado, así usen la misma solución de último kilómetro. Si se observa

31

bien, la mayoría de escenarios de enlaces WAN corporativos tienen más de

dos nodos interconectados, por tanto habrá al menos un nodo donde existan

al menos dos PVCs compartiendo un último kilómetro, esto sería por ejemplo,

en la topología de estrella. Si cambiamos a malla completa o parcial, el

número de PVCs aumentará considerablemente y con ellos los costos de la

solución de transporte de datos. En la figura 3.5. se observa con más detalle

una solución Frame Relay usando topología de estrella.

Una sola última millaDos PVCs

RED FRAMERELAY

Sitio 1

Sitio 2

Sitio 3

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

A parte del alto precio que tiene una solución Frame Relay o Clear Channel,

hay otros factores a tener en cuenta para decidir cambiar este tipo de

tecnologías a una solución 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 también son susceptibles de

caídas, y su montaje, en cuanto a hardware se refiere, es tan complejo que

es prácticamente 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 conmutación a otro proveedor es prácticamente 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 conexión de tres oficinas de una misma compañía

usando una arquitectura LAN-to-LAN VPN. Nótese que los túneles VPN que

aparecen señalados no son enlaces físicos sino lógicos que viajan por

Internet. El único equipo que tiene que adquirir la compañía 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 kilómetro por oficina, por ahí viajan todos los

túneles VPN que se necesiten.

Sniffer Serverm o ni to rin g /a n a ly s is

Sni ffer Serverm o ni to ri n g/ a na ly s is

Sni ffer Serverm o ni to ri n g/ a na ly s is

TúnelesVPN

GatewaysVPN

Intranet 1

Internet

Intranet 2

Intranet 3

Figura 3.6 Esquema de una solución Intranet VPN (LAN-to-LAN VPN).

4 Para esto es necesario que el enrutador de frontera de la ISP que provee de Internet a la compañía queestablece la VPN sea capaz de trabajar con protocolos de enrutamiento dinámicos como BGP o EIGRP, yque la ISP también cuente con enlaces de respaldo a Internet

33

Si el enlace hacia Internet de la compañía no es dedicado sino conmutado, el

mecanismo para cambiar de proveedor es mucho más sencillo, basta con

configurar el gateway dial-up VPN con el número telefónico de otra ISP. Si se

cuenta con un servicio de cable módem 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 más sitios de una red corporativa y a

un costo mucho menor. La economía se ve reflejada tanto en equipos que se

tienen que adquirir o arrendar para el montaje inicial de la topología, como en

cargos fijos que se tienen que pagar mes a mes.

Hace solo 2 años era costoso y poco practico usar la tecnología de VPNs para

implementar una solución 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 pequeñas compañias.

Solo hasta finales del 2001 las tarifas de Internet disminuyeron tanto (La

tabla 3.1 muestra la evolución en precios de las tarifas a Internet en

Colombia) que se presentaron dos fenómenos que propiciaron el auge de las

VPNs a nivel global [REF3.1], y Colombia no fue la excepción, 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 más ancho de banda por menor o igual costo. Hoy en día no

es difícil encontrar empresas que tienen enlaces a Internet de 512 kbit/s,

ratas que hasta hace pocos años eran reservadas solo para ISPs.

34

Año E1 Clear Channel

Nacional5E1 Internet

(reuso 1:1)1999 N.D. U$11.0006

2000 $5’500.000 U$8.0002001 $4’020.000 U$6.5002002 $3’800.000 U$4.0002003 $3’738.600 U$3.300

N.D. No disponible

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

Otro factor decisivo que ha hecho que las empresas comiencen a ver en las

VPNs otra opción para el montaje de sus redes WAN usando esta tecnología

es la aparición de los NAPs (o Puntos de acceso a la Red), que son lugares

donde varias redes autónomas de sitios cercanos se conectan para

intercambiar tráfico a alta velocidad, y así evitar que paquetes de información

que se cruzan entre sitios en un mismo lugar geográfico tengan que ir hasta

otros países o continentes, disminuyendo así los costos. En Colombia, el NAP

más grande que existe es el NAP de la CCIT (Cámara Colombiana de

Informática y Telecomunicaciones), también llamado NAP Colombia. La

aparición de este NAP hizo que el tráfico que tenía como origen y destino

nuestro país usara solo canales locales o nacionales, evitando así a las ISPs

conectadas a este, tener que adquirir más ancho de banda internacional.

El NAP Colombia comenzó a funcionar a finales del año 2000. La figura 3.7

muestra el crecimiento del tráfico 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 No incluye última milla, solo transporte nacional6 E1 vía satélite, correspondiente a 2048 kbit/s de recepción y 2048 kbit/s de transmisión

35

Figura 3.7 Tráfico 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 aplicación que se le dio a la emergente tecnología de las VPNs.

Consiste en usar cualquier RAS que preste servicio de conexión a Internet

como punto de acceso a una red corporativa también conectada a Internet

por medio de un gateway VPN.

Esta solución nació de la necesidad de poder acceder a la red corporativa

desde cualquier ubicación, incluso a nivel mundial. Con el Acceso Remoto

VPN, los RAS corporativos quedaron olvidados, pues su mantenimiento era

costoso y además las conexiones que tenían que hacer los trabajadores de

planta externa, como vendedores y personal de soporte técnico, cuando

36

viajaban fuera de la ciudad, y más aun, a otros países eran demasiado

costosas.

El acceso remoto VPN se vio claramente impulsado por el auge de la Internet

que ha hecho que prácticamente en todas partes del mundo se obtenga fácil

acceso a la misma.

Con el acceso remoto VPN un trabajador que se haya desplazado a otro país,

por ejemplo, y que quiere acceder a la base de datos de su compañía, 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 marcación VPN. A partir de la

versión Windows98, Microsoft incluyó un cliente de marcación 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 creación de un túnel conmutado VPN usando un

cliente PPTP instalado en el computador del trabajador remoto. Nótese que se

realizan dos conexiones, una PPP a la ISP, y una PPTP al gateway VPN de la

compañía que se encuentra conectado a Internet. La conexión PPP puede

ser análoga o digital RDSI.

7 En el capítulo 5, Tecnologías VPN, se tratará en detalle el protocolo de entunelamiento PPTP.

37

TrabajadorTeleconmutado

INTERNET

RASen ISP

GatewayVPN

LANCorporativa

Enlaceconmutado

1ra Marcación - Enlace PPP

2da Marcación - Túnel VPN (Típicamente 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 tecnologías de acceso de banda ancha como

xDSL y cable módem. 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) sería montar un RAS con capacidad para recibir

conexiones RDSI-BRI, es decir velocidades de 64 kbit/s o 128 kbit/s, además

si la llamada la origina un trabajador en otra ciudad o país 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 túnel tiene una conexión cable módem

(también aplica xDSL) hacia la ISP; y otro acceso por medio de un módem

análogo común, en este caso el usuario remoto podría estar en otra ciudad o

incluso en otro país.

38

Sniffer Serverm on it o rin g /a n al y si s

latigid

iMac

RS CS TR RD TD CDTALK / DATATALK

TúnelesEncriptados

GatewayVPN

RedCorporativa

INTERNET

Servidor deacceso remoto

conmutado

UsuarioRemoto

UsuarioRemoto

CableMódem

Figura 3.9 Dos montajes típicos de un acceso remoto VPN

3.3. EXTRANET VPN

Las empresas necesitan intercambiar información y realizar transacciones no

solamente entre sitios de su misma organización sino también con otras

compañías. Por ejemplo, una empresa manufacturera quisiera permitirle a

los computadores de sus distribuidores accesar a su sistema de control de

inventarios. También dicha empresa quisiera poder accesar a la base de datos

de sus proveedores y poder ordenar fácil y automáticamente cuando ellos

necesiten materia prima. Hoy en día todas las empresas están haciendo

presencia en la Internet y esto hace casi imperativo la comunicación 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 topología Extranet VPN implica incrementar la complejidad de los

sistemas de control de acceso y de autenticación.

Adicionalmente la tendencia de los mercados hacen que un cambio en la

topología se pueda realizar fácilmente, para esto una Extranet VPN debe

poder adicionar y eliminar dinámicamente acceso seguro a otras compañías.

Tal reconfiguración dinámica es difícil cuando se cuenta con circuitos cerrados

dedicados.

La presencia de una compañía en Internet y el uso de la arquitectura de

Extranet VPN, hace posible crear conexiones dinámicas seguras a otras redes

sin necesidad de cambiar la infraestructura física. Ejemplos de conexiones

dinámicas seguras y que son conocidos como Extranet VPNs se muestran en

la figura 3.10

Sniffer Serverm on it or in g /a n al y si s

i Mac

TúnelesEncriptados

GatewayVPN

Red Corporativade la compañía

INTERNET

Cliente accediendoa la compañía pararealizar una compra

S nif f er S erve rm on it or in g/ an a lys is

Red Corporativa de unproveedor de la compañía

actualizando endisponibilidad de artículos

Acceso paraclientes

Acceso paraproveedores

Figura 3.10 Arquitectura Extranet VPN, clasificando el acceso según 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 túneles son

creados a través 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 podría accesar a la red corporativa como un cliente usando

cualquier acceso remoto.

En la actualidad la mayoría de los gateways VPN pueden establecer múltiples

túneles seguros a múltiples empresas. Sin embargo, es importante que una

empresa no sea capaz de obtener acceso a la información de otra compañía

que está accediendo por medio de Extranet VPNs. Un nivel más de seguridad

puede ser adicionado ubicando recursos exclusivos a cada una de las

compañías que va a acceder a la red de interés en diferentes servidores.

3.4. MODELOS DE ENTUNELAMIENTO

En las VPN los sitios de terminación (terminadores) de los túneles son

aquellos donde se toman las decisiones de autenticación y las políticas de

control de acceso y donde los servicios de seguridad son negociados y

otorgados. En la práctica hay tres tipos posibles de servicios de seguridad que

dependen de la ubicación 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 tráfico 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 túnel VPN se compone de dos terminadores, se pueden obtener

seis tipos de modelos de seguridad derivados de la posible combinación de

las diferentes localizaciones: End-to-End, End-to-LAN, End-to-POP, LAN-to-

LAN, LAN-to-POP y POP-to-POP, en la figura 3.11 se notan cada uno de ellos.

iMa c i Mac

Sitio 1 Sitio 2

LAN LANPOP POP

INTERNET

GatewayVPN

GatewayVPN

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 túnel 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 comunicación. Este escenario presenta el

más alto nivel de seguridad dado que los datos siempre están seguros en

todos los segmentos de la red, bien sea pública o privada. Sin embargo, el

total de túneles que pueden haber en una empresa grande, dificulta el

manejo de los servicios de seguridad requeridos por dichos host. Este modelo

de seguridad es comúnmente 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 túnel comienza en un host y termina en el

perímetro de una LAN en la cual reside el host destino. Un dispositivo VPN

42

localizado en el perímetro de la red es el responsable de la negociación y

obtención de los servicios de seguridad de los host remotos. De esta manera,

la seguridad de un gran número 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, comúnmente no

hay necesidad de encriptar la información que transita dentro de ella. La

mayoría 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 túnel 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 negociación y concesión de los servicios de seguridad. La

entrega de los datos desde el POP hasta el host destino es por lo general

asegurada con infraestructura física, la cual separa el tráfico del resto de la

red pública. Por lo general en este caso el ISP administra los permisos y

controla el acceso según las directivas de los administradores de red de las

empresas clientes. La arquitectura de acceso remoto VPN también 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 implementación de los servicios de seguridad es completamente

transparente para los hosts. Esta implementación reduce drásticamente la

complejidad en el manejo de las políticas de seguridad. La arquitectura

Intranet VPN encaja en este modelo.

43

En el caso de LAN-to-POP el túnel 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 prácticamente 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 túnel. 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 más

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, Artículo Internet-based VPNs: Business orCattle Class?, Pag. 54, Julio de 2002.

44

4. AUTENTICACIÓN Y CIFRADO

4.1.AUTENTICACIÓN

La autenticación 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 autenticación involucra usualmente la interacción entre dos entidades: el

objeto de la autenticación (un usuario o un cliente) que afirma su identidad y

un autenticador realizando la verificación de la identidad. El usuario entrega

información de autenticación la cual incluye la identidad proclamada y la

información que soporta dicha identidad al autenticador. En la labor de

verificación, el autenticador aplica una función de autenticación F que le

entrega información y luego compara el resultado de esta operación con el

resultado esperado.

Si el resultado de la función F concuerda con el resultado esperado, la

identidad del usuario se considera verificada.

La información de autenticación puede ir desde un simple password a un

juego completo de parámetros y mensajes. De igual manera, la función F

puede ser una simple función como en el caso de la comparación de claves, o

la aplicación de complejos algoritmos criptográficos, como en el caso de

firmas digitales.

45

Si la información de autenticación y la función de autenticación F están

totalmente bajo el control de las dos entidades, el esquema de autenticación

es llamado Esquema de Autenticación Compartido (two-party). Sin embargo,

en muchos casos es más seguro y escalable ayudarse de una tercera parte (o

de más) para la autenticación. 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

información de autenticación. Es importante que la información usada para la

autenticación sea segura y no sea obtenida de participantes no autorizados.

Esas medidas de seguridad no solo deben ser tomadas en el establecimiento

del túnel, sino durante el transcurso del intercambio de datos. En el caso de

las VPNs esto es muy importante ya que la información de autenticación es

transmitida a través 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: Autenticación, Confidencialidad e Integridad de

Datos. La Autenticación 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 garantización de la integridad de los datos significa

que ningún dato ha sido alterado en ninguna parte de la transmisión.

Desafortunadamente, el conjunto de protocolos TCP/IP no fueron

diseñados originalmente para brindar seguridad a los datos. A

46

continuación se describirán las amenazas de seguridad más comunes en

redes públicas como Internet.

4.1.1.1.Spoofing

Las redes IP usan direcciones numéricas 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.

Después de que un intruso identifica una pareja de computadores, A y

B por ejemplo, que están comunicándose uno con el otro como en una

topología cliente – servidor, intenta establecer una conexión con el

computador B de tal forma que B cree que está en una conexión con

A, cuando en realidad la conexión se ha establecido con el computador

del intruso.

El establecimiento de una conexión entre A y B implica un intercambio

de mensajes de control, en estos mensajes de control tanto A como B

envían 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 números para garantizar el correcto orden en el

recibo de los paquetes. Esas secuencias de números son únicas entre

las dos máquinas.

Para completar la configuración de la sección entre A y B, B esperaría

de A un reconocimiento en la secuencia de números de B antes de

proceder con cualquier tipo de intercambio de operación. Pero para

que un atacante se haga pasar como A el tendría que detectar la

47

secuencia de números que B usará. Sabiendo lo anterior, no es muy

difícil identificar las secuencias de números en una conexión entre dos

hosts. De esta manera un atacante podría 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 conexión 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

conexión. Una vez monitoreando el enlace, el atacante puede

determinar la secuencia de números usadas por ambas partes.

Después de hecho esto, el atacante puede generar tráfico que parezca

venir de una de las partes envueltas en la comunicación, robando la

sesión de los individuos envueltos. Como en spoofing, el atacante

podría sobrecargar uno de los dos computadores con exceso de

paquetes que haga que la sesión se caiga.

El hecho que un host haya identificado la persona con la cual se está

comunicando no podría asegurar que desde ese mismo IP esté el host

auténtico durante el resto de la sesión. Para esto se necesita de un

esquema que autentique los datos durante toda la transmisión. Pero

de igual forma, usando el método de autenticación más poderoso no

podríamos prevenir 100% ataques por hijacking; en realidad la única

defensa contra tales ataques es la implementación de mecanismos de

encriptación.

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 están 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 específicamente para

este. Sin embargo, es relativamente fácil 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 algún 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

característica de la tecnología ethernet. Tal herramienta puede grabar

todo el tráfico 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 podría

usar un sniffer para grabar todos los paquetes que contienen nombres

de usuarios y claves en una red y luego usar esa información 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 compañía para poder así

identificar quien se comunica con quien, qué se está comunicado y

poder usar esta información en labores de espionaje corporativos.

49

Encriptar datos es una forma de proteger contra sniffing, aunque el

atacante podría tener los recursos para guardar los datos encriptados y

luego tratar de descifrarlos cuando esté desconectado.

La inspección física 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 fácilmente si una

NIC está en modo promiscuo.

4.1.1.4.Ataque del Hombre-en-la-Mitad

Aunque se ha dicho que usar tecnologías de cifrado y autenticación

previenen en cierta medida de las amenazas en una red IP, el cifrado

no es una solución del todo confiable. Los ataques de el hombre-en-la-

mitad 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 podría emplear técnicas de spoofing, hijacking y sniffing

para capturar las llaves de cifrado que se intercambian en un sistema.

El podría introducir su propia llave anticipadamente en el proceso y la

otra persona podría 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 AUTENTICACIÓN

La autenticación es parte vital dentro de la estructura de seguridad de una

VPN. Sin ella no se podría controlar el acceso a los recursos de la red

corporativa y mantener a los usuarios no autorizados fuera de la línea.

Los sistemas de autenticación 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 método sencillo de

autenticación tal como el password, pero no es adecuado para proteger

sistemas. Los expertos recomiendan los llamados sistemas de

autenticación complejos, los cuales usan al menos dos de los atributos de

autenticación anteriores.

A continuación trataremos los sistemas de autenticación más comúnmente

usados en los ambientes de redes: passwords tradicionales, passwords

únicos, PAP, CHAP y Radius.

4.1.2.1.Passwords Tradicionales

Son la forma más simple de autenticar pero es un método 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, haciéndolos fácilmente 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 sesión

de comunicación, es decir que se requiere un password nuevo para

cada nueva sesión. Estos sistemas, de los cuales S/KEY es el mejor

ejemplo, facilitan al usuario la escogencia de un nuevo password para

la siguiente sesión generando automáticamente 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 función HASH n veces, donde n es un número especificado por el

usuario. El siguiente password único es generado aplicando al mensaje

original la misma función 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

número y una cadena de caracteres, la cual es llamada seed.

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

52

En respuesta al mensaje enviado por el servidor de red el usuario usa

el número y el seed que le ha llegado más 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 número que le ha llegado en el mensaje de

respuesta del servidor.

El password único resultante es enviado al servidor de autenticación el

cual también lo itera tantas veces como el se lo haya indicado al

cliente en funciones HASH, luego lo compara con el password único

que tenía almacenado. Si hay una concordancia entre los mismos al

usuario se le permite el ingreso a la red, una vez esto pasa el número

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 cálculos

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 número de

usuarios.

4.1.2.3.PAP (Password Authentication Protocol)

PAP [REF4.2] o Protocolo de Autenticación de Passwords fue diseñado

originalmente como una manera sencilla para que un computador se

autenticara en otro cuando los mismos usan un protocolo de

comunicación punto a punto como PPP. PAP es un protocolo de dos

vías, el host que se está conectando envía un nombre de usuario y un

password al sistema destino con el cual trata de establecer su

53

comunicación, y el sistema destino (el autenticador) responde si es el

caso, que el computador remoto está autenticado y aprueba su

comunicación.

PAP es un protocolo de autenticación que puede ser usado al comienzo

del establecimiento de un enlace PPP, o bien durante el transcurso de

la sesión PPP para reautenticar el enlace.

PAP no es seguro porque la información de autenticación es

transmitida en texto plano, esto hace vulnerable a que atacantes

obtengan información de nombres de usuario y claves de manera fácil.

4.1.2.4.CHAP (Challenge Handshake Authentication Protocol)

CHAP [REF4.3] es muy similar a PAP pero es más seguro para

autenticar enlaces PPP. CHAP es un protocolo de tres vías 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 autenticación de un enlace, que

son:

1. El autenticador envía un mensaje al nodo remoto.

2. El nodo calcula un valor usando una función HASH y lo envía de

regreso al autenticador.

3. El autenticador avala la conexión si la respuesta concuerda con el

valor esperado.

54

El proceso puede repetirse en cualquier momento del enlace PPP para

asegurarse que la conexión no ha sido tomada por otro nodo. A

diferencia de PAP, en CHAP el servidor controla la reautenticación.

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 más 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

división de Lucent Technologies. RADIUS usa una arquitectura cliente

– servidor e incluye dos componentes: un servidor de autenticación 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 autenticación con RADIUS tiene los siguientes pasos:

1. Un usuario remoto marca a un RAS. Cuando la conexión 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 autenticación. Este

paquete incluye información tales como el nombre del usuario, el

password, el modem de conexión, entre otros. Para evitar que un

hacker escuche la información, el RAS actúa 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 autenticación es enviado por la red desde el

cliente hasta el servidor RADIUS. Esta comunicación 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 autenticación es recibido, el servidor

RADIUS valida el requerimiento y verifica la información del nombre

de usuario y password. Esta información también puede ser

transmitida a un sistema de seguridad apropiado que soporte los

archivos de autenticación, por lo general bases de datos.

5. Si el nombre de usuario y el password son correctos, el servidor

envía un reconocimiento de autenticación que puede incluir

información 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 dirección IP estática o que obtiene su dirección IP de un rango

dinámico de direcciones, también puede contener información

sobre los filtros que pueden limitar al usuario a accesar ciertos

recursos específicos de la red como por ejemplo el uso de un

servidor proxy.

6. Si en este punto del proceso la autenticación no se tiene éxito, el

RADIUS envía un mensaje de desconexión al RAS y al usuario se le

niega el acceso a la red.

RADIUS también puede emplear una arquitectura distribuida en el

evento en que el NAS deba soportar autenticación para múltiples

dominios, para esto el RADIUS se configura en modo proxy. Esta

función 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 envía el requerimiento hacia el

servidor RADIUS de la ISP remota para que éste ejerza las labores de

autenticación.

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 comunicación entre ellos. La figura 4.1

muestra un esquema de RADIUS en modo proxy, muy utilizado para

hacer roaming entre distintas ISPs.

INTERNETServidor deacceso remoto

Servidor Radiusactuando como

proxy

Servidor Radiusdel usuario

remoto

Conexiónconmutada

Usuario

Figura 4.1 Autenticación 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 información 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 criptográfico es una función matemática que combina texto plano o

cualquier otra información inteligible con una cadena de dígitos 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 criptográficos son difíciles de idear por lo cual sería traumático

usar un nuevo algoritmo cada vez que una parte se quiera comunicar de

manera privada con una nueva. Usando una llave, un usuario podría utilizar el

mismo algoritmo para comunicarse con diferentes usuarios remotos; y todo lo

que se debería hacer sería utilizar una diferente llave con cada uno de ellos.

El número de llaves posibles que tiene cada algoritmo depende del número

de bits de la llave. El número de posibles llaves viene dado por la fórmula 2n,

donde n es el número de bits de la llave. Por ejemplo, una llave de 64 bits

permite 264 posibles combinaciones numéricas o llaves. Es decir,

18’446.744’073.709’551.616 claves. El gran número 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

computación en 1995, y el tiempo que tomaria ese sistema en romper cada

llave de diferente longitud. [REF4.5].

58

Inversión

(en dólares)

Longitud de la llave (en bits)40 56 64 80 128

$ 100 mil 2 s 35 h 1 año 70.000 años 1019 años$ 1 millon 0.2 s 3.5 h 37 días 7.000 años 1018 años

$ 100 millones 2 ms 2 m 9 h 70 años 1016 años$ 1 billon 0.2 ms 13 s 1 h 7 años 1015 años

$100 billones 2 s 0.1 s 32 s 24 días 1013 años

Tabla 4.1 Comparación de tiempo y dinero necesarios para romper llaves de diferente longitud

El sistema basado en llaves es llamado “de llaves secretas” o “cifrado

simétrico”. 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 simétrico presentó algunos problemas, por ejemplo: ambas partes

deberían de estar de acuerdo para usar la misma llave. Otro problema es que

si una parte tenía n receptores, entonces debería guardar registro de n llaves

secretas, una por cada uno de los receptores.

Otro gran problema del esquema de cifrado simétrico es con la autenticación,

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 “criptografía de llaves

públicas”, el cual hace uso de algoritmos de cifrado asimétricos.

4.2.1. CRIPTOGRAFÍA DE LLAVES PÚBLICAS

La criptografía de llaves públicas se basa en el manejo de una pareja de

llaves. Cada llave puede encriptar información que sólo la otra puede

desencriptar. La llave privada, únicamente es conocida por su propietario;

la llave pública, se pública abiertamente, pero sigue asociada al

59

propietario. Los pares de llaves tienen una característica única: los datos

encriptados con una llave sólo pueden desencriptarse con la otra llave del

par. En otras palabras, no tiene importancia que se use la llave privada o

la pública 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 pública del receptor

para encriptar un mensaje, de manera que el mensaje continúe 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 sólo tiene acceso él.

La llave pública 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 pública de su receptor, después deberá usar la

misma para encriptar el mensaje y enviarlo. Como el mensaje se encriptó

con la llave pública del receptor, sólo éste con su llave privada puede

desencriptar el mensaje.

Aunque una persona puede encriptar un mensaje con una llave pública o

con una llave secreta, usar la llave pública presenta ciertas ventajas. Por

ejemplo, la llave pública 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 pública a todos los

receptores; ya que ellos la pueden obtener desde un servidor de llaves

mantenido por la compañía, o a través 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 pública del destinatario y como este último con su

llave privada desencripta el mensaje cifrado que le ha llegado.

asdhgdh xcb czc as dhgdxcb cxnm cnczc asdhgdhxcb cxnmcnmzxcn czcasdhgdh xcb ccnm zxcn czcas

asdhgdh xcb czc as dhgdxcb cxnm cnczc asdhgdhxcb cxnmcnmzxcn czcasdhgdh xcb ccnm zxcn czcas

INTERNET

000 1010 00001010 0000101010 0010 0001110101 01010010101010100111 0001010 0 0100111100

000 1010 00001010 0000101010 0010 0001110101 01010010101010100111 0001010 0 0100111100

Llave públicadel destinatario

Encriptación

Mensaje Original(Texto plano)

Mensaje encriptado(Texto cifrado)

Llave privadadel destinatario

Mensaje encriptado(Texto cifrado)

Mensaje Original(Texto plano)

Desencriptación

Figura 4.2 Esquema de cifrado con llaves públicas

Colocar una llave pública en una red la vuelve fácilmente accesible, y no

se pone en peligro la llave privada correspondiente.

Otra ventaja de la criptografía con llave pública es que permite que el

receptor autentifique al originador del mensaje. La idea básica es esta: ya

que el emisor es la única persona que puede encriptar algo con su llave

privada, todo aquel que use la llave pública 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 electrónico 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 más lo haya leído con anterioridad.

61

Usar algoritmos criptográficos de llaves públicas para encriptar mensajes

es computacionalmente lento, así que se ha descubierto una manera para

generar con rapidez una representación corta y única del mensaje,

llamada "resumen" (message digest), que se puede encriptar y después

usar como firma digital.

Algunos algoritmos criptográficos populares y veloces para generar

resúmenes se conocen como funciones de dispersión (hash) de un solo

sentido. Una función de dispersión (hash) de un solo sentido no usa una

llave; simplemente es una fórmula para convertir un mensaje de cualquier

longitud en una sola cadena de dígitos, llamada "resumen". Cuando se

usa una función de dispersión (hash) de 16 bits, el texto procesado con

dicha función produciría 16 bits de salida (un mensaje podría 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 envía esa

firma digital junto con un mensaje de texto simple a B.

Después de que B usa la llave pública 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 pública de A, sabe que

A lo creó, autentificando así al originador. B usa entonces la misma

función de dispersión (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 auténtica, lo que significa que A no sólo envió el mensaje, sino

que el mensaje no fue alterado.

4.2.2. DOS ALGORITMOS IMPORTANTES DE LLAVES PÚBLICAS

Existe un amplia variedad de algoritmos criptográficos para llaves públicas,

pero quizá dos de los másimportantes han sido: Diffie-Hellman y RSA.

4.2.2.1.Diffie-Hellman

El protocolo Diffie-Hellman [REF4.6], también llamado (protocolo de

acuerdo de llaves exponenciales) fue desarrollado por Whitfield Diffie y

Martin Hellman en 1976 y publicado en el magazín “Nuevas directrices

en Criptografía” (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”,

también llamado “llave de cifrado de la llave” (key encryption key – en

inglés) entre las dos partes. Este secreto compartido luego encripta la

llave simétrica (usando DES, 3DES, CAST, IDEA, Blowfish, etc.) que

asegura la transmisión.

63

Los sistemas de llaves asimétricas (la base de la infraestructura de

llaves públicas) usan dos llaves –la llave privada y la llave pública-,

desafortunadamente estos sistemas tornan lenta la transmisión de

datos. Lo práctico hoy en día, es usar un sistema simétrico para

encriptar los datos y un sistema asimétrico para cifrar las llaves a usar

en el proceso de cifrado de los datos.

Inicialmente, cada lado de la comunicación tiene su llave privada y la

llave pública del otro lado. Diffie-Hellman tiene la capacidad de generar

llaves compartidas idénticamente iguales en ambos lados de la

comunicación con la llave privada local y la llave pública del lado

remoto.

Así trabaja el criptosistema de intercambio de llaves Diffie-Hellman:

1. Se tienen dos parámetros públicos 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 pública, Ya, a partir de su llave privada Xa, con

la siguiente fórmula:

Ya = pXa mod q

64

6. De igual manera, B genera su llave pública, Yb, a partir de su llave

privada Xb, con la siguiente fórmula:

Yb = pXb mod q

7. A y B intercambian sus llaves públicas, Ya y Yb, entre sí.

8. Con Yb en su poder, A está en capacidad de calcular el secreto

compartido K, con la siguiente fórmula:

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 Julián, necesitan un secreto compartido para iniciar su sesión

de comunicación encriptada usando un sistema asimétrico. Los valores

iniciales son:

q = 11 y p =5

Carlos escoge su llave privada Xc = 9

Julián escoge su llave privada Xj = 3

Carlos calcula su llave pública Yc = pXc mod q

Yc = 59 mod 11 = 9

Julián calcula su llave pública Yj = pXj mod q

Yj = 53 mod 11 = 4

Carlos le envía su llave pública Yc a Julián, y Julián le envía su llave

pública Yj a Carlos.

Ahora, Carlos calcula el secreto compartido K = (Yj)Xc mod q

65

K = 49 mod 11

K = 3

Y Julián 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 comunicación tiene su secreto compartido

idéntico al remoto, se inicia un proceso de cifrado de datos simétrico

que es mucho más liviano que un mecanismo asimétrico, por tanto no

disminuye sensitivamente la velocidad del enlace. Algunos algoritmos

de cifrado simétricos 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 podría interceptar la

comunicación, hacerse pasar por el lado remoto y enviarle al emisor su

llave pública haciéndose pasar por el receptor. La solución para evitar

este problema es usar firmas digitales que aseguren que la persona

con la cual se está estableciendo la comunicación es efectivamente

quien dice ser.

4.2.2.2.RSA

RSA [REF4.7] es un sistema de cifrado de llaves públicas que se usa

tanto para cifrado de datos como para autenticación de llaves públicas.

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 números primos de gran tamaño, a los que se les

llama p y q.

2. Se calcula su producto n=p*q y se le denomina módulo.

3. Se escoge un número e, menor que n, y relativamente primo al

producto (p-1)*(q-1). Este valor es llamado el exponente público.

4. Se encuentra otro número d tal que (ed-1) es divisible por (p-1)*

(q-1). Este valor es llamado el exponente privado.

5. La llave pública 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 fórmulas

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 tamaño tan grande de los números primos p y q, que

en la actualidad son del orden de los 512 a 1024 bits de tamaño.

Cuanto más grande se escojan estos números 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 números primos9, p=5 y q=11.

Se calcula el módulo 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 fórmula:

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 pública, es decir el par (n,e) =

(55,3) y la llave privada es el par (n,d) = (55,27).

Ahora, asúmase que A quiere enviar el mensaje “25” a B, para lo cual

usa el par de la llave pública y la fórmula de cifrado dada

anteriormente:

c = me mod n

c = 253 mod 55 = 5

c =5, es el número que se envía por el medio inseguro.

9 Para propósitos ilustrativos, se han escogido dos números primos bastante pequeños. En la realidad estosnúmeros suelen ser mucho más grandes.10 Dos enteros son relativamente primos si no tienen factor común diferente de 1.

68

En el otro lado B quiere recuperar el mensaje que le ha llegado, para

lo cual usa la llave privada y la fórmula 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 PÚBLICAS

El comercio electrónico y la transmisión de datos privados sobre Internet ha

crecido vertiginosamente, por tanto la autenticación ha cobrado un papel

crucial en este proceso. La criptografía de llaves públicas ofrecen una gran

herramienta matemática para facilitar la autenticidad, pero surge un gran

problema y es el cómo manejar y publicar dichas llaves para cada persona o

entidad que las necesiten.

Una infraestructura de llaves públicas (Public Key Infrastructure - PKI)

[REF4.8] es el conjunto de servicios y políticas que rigen el esquema de

vinculación de una identidad con una llave pública y la posterior redistribución

de ese vínculo.

Una PKI tiene tres procesos básicos: certificación, validación y la revocación

de certificados. La certificación es la vinculación de una identidad a una llave

pública. La llave pública 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 Certificación (CA).

69

La validación es el proceso de comprobar la autenticidad del certificado, por

tanto de asegurar que el contenido del mismo es confiable. Esto requiere la

verificación de la firma del CA usando la llave pública del mismo y

chequeando el certificado contra una lista de revocación de certificados

(CRL). Una CRL contiene una lista de certificados que han sido revocados

anteriormente por la CA indicando que ese vínculo no es válido. La validación

también involucra chequear el periodo de validez contenido en el certificado

mismo.

La revocación de un certificado es el proceso de desconocer un certificado

previamente emitido antes de su fecha de expiración. Estos sucede cuando

algunos aspectos de la información contenidos en el certificado cambian;

quizás 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

perderían valor.

4.3.1. ARQUITECTURA DE UNA INFRAESTRUCTURA DE LLAVES

PÚBLICAS

Una PKI incluye la autoridad certificadora (CA) y todos los otros

componentes que permiten la certificación, validación y revocación. La

figura 4.3 muestra los principales componentes de una PKI: El usuario, el

validador, la autoridad de registro RA, la autoridad de certificación CA, el

certificado y un depósito de CRLs. Todos estos componentes interactúan

para facilitar la adquisición y uso de certificados digitales.

70

Dep

ósito

de

certi

ficad

os y

CR

Ls

Validador

Usuario

RA

CA

CA

Autenticación Presentación deun Certificado

Presentación deCredenciales

Presentación de Credencialesy solicitud de un certificado

Garantización deun certificado

Solicitud o garantizaciónde un certificado

Solicitud deun certificado

Busqueda de un certificado o CRL

Publicación del certificado

Publicación del certificado o CRL

Entidades deusuario

Entidades deadministración

Publicación del certificado o CRL

Figura 4.3 Arquitectura de una infraestructura de llaves públicas

Las CAs, las RAs y el depósito de CRLs son entidades de manejo o

administración dado que ellos son responsables de la generación,

distribución, almacenamiento y revocación 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 propósitos. 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.

Después que las credenciales son certificadas y verificadas, un certificado

es emitido al usuario y publicado en el depósito. Cuando un validador

necesita autenticar un usuario, usa la llave pública válida contenida en el

certificado para verificar un mensaje firmado por la llave privada del

usuario. Las CAs también publican las CRLs en el depósito, por tanto el

validador puede chequear si el certificado del usuario es todavía válido.

Las CRLs también pueden ser recibidas periódicamente sin necesidad de

71

alguna petición. Un conjunto de protocolos ha sido desarrollados y

estandarizados para administrar las diferentes transacciones entre todas

las entidades.

4.3.2. CERTIFICACIÓN

La certificación es el proceso de vincular un usuario con su información.

Para asegurar la autenticidad e integridad de tal vínculo, la CA firma el

documento usando su llave privada. El proceso de certificación toma

varios pasos. Primero, el CA debe verificar que la información contenida

en el certificado digital es auténtica 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 información de la

entidad dentro de un certificado. En algunas ocasiones la parte que entra

la información no es el usuario a certificar.

El siguiente paso es la generación del par de llaves. La llave pública del

usuario deberá ser incluida en el certificado. Algunas veces el usuario

genera el par de llaves y pasa solamente la llave pública a la CA, por tanto

solo él conoce su llave privada.

Después, 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.

Después que el certificado digital es creado y firmado por la CA, el usuario

puede recuperarlo desde ella. El proceso de recuperación del certificado

comienza con la presentación de una credencial por una única y primera

vez a la CA, usualmente es un número de referencia y un código de

72

autorización dado al usuario por otro medio (preferiblemente seguro). En

algunos casos es tan simple como un e-mail que envía la CA al usuario.

4.3.3. VALIDACIÓN

Un certificado debe ser validado antes de poder ser usado para brindar

confiabilidad, la validación del certificado comprende los siguientes pasos:

1. La integridad del certificado es chequeada verificando la firma digital

por medio de la llave pública de la CA.

2. El intervalo de validación 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. REVOCACIÓN DEL CERTIFICADO

Un certificado puede ser revocado antes de su fecha de expiración si

pierde su validez de alguna manera, por ejemplo cuando la longitud de la

información contenida en el no es válida. Así como con el proceso de

certificación, el requerimiento para revocar un certificado deberá ser

recibido por medio de un canal seguro y examinado detenidamente.

La CA revoca un certificado incluyéndolo en la lista de certificados

revocados o CRL (Certificate Revocation List). Una CRL usualmente

contiene solo los números seriales de los certificados revocados. La

inclusión de toda la información de los certificados revocados dentro de la

CRL resultaría innecesaria y de un tamaño 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 publicándola en su depósito. LA CRL es

actualizada frecuentemente (por ejemplo cada ocho horas). La entidad de

73

validación puede realizar un requerimiento de la CRL actualizada cuando la

misma en su posesión ha expirado.

En algunas ocasiones la CA proactivamente entrega su CRL a las

entidades de validación más grandes cuando una nueva revocación ha

sucedido, de esta manera el efecto se torna inmediato.

4.3.5. FORMATOS DE CERTIFICADOS DIGITALES

Un certificado digital, como ya se había dicho anteriormente, vincula la

identidad de una entidad a su llave pública. La autenticidad de la

información es garantizada por la firma digital de la CA emisora.

Varios estándares describen la información que debe estar contenida en el

certificado, cómo debe ser organizada dentro del mismo y cómo se firma

el certificado. Entre los formatos más 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

públicas, incluyen una especificación de los certificados usados para

vincular un nombre con una llave pública, y una especificación de

revocación para los certificados emitidos que no sean confiables. El

estándar X.509 no especifica una infraestructura de llaves públicas

(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 públicas más

ampliamente usado. La primera versión, X.509v1 fue publicada en

74

1988 y provee la estructura básica del certificado. X.509v2 apareció en

1993 y le adicionó a la primera versión dos campos opcionales para

proveer de unicidad al certificado en cuanto a su emisor y sujeto. La

tercera y actual versión, 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

vínculo de un nombre y una llave pública, por lo tanto, debe contener

al menos un nombre y una llave pública.

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 estándar de OSI

para expresar notaciones abstractas sin una estrategia de

implementación previa. Vale la pena decir que también provee las

estructuras en lenguajes de programación 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 versión es un valor entero que

indica cual de las tres versiones es la usada en dicho certificado. Los

valores 0, 1 y 2, hacen alusión 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

Figura 4.4 Formato de un certificado X.509v3

El campo serialNumber se usa para distinguir ese certificado entre los

demás emitidos por la misma CA, por lo tanto es un valor único dentro

de la misma. Algunas implementaciones usan valores incrementados

monotónicamente, otras usan números 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).

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 ::= INTEGERAlgorithmIdentifier ::= 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 ::= BITSTRINGExtensions ::= SEQUENCE OF ExtensionExtension ::= SEQUENCE {

extnid EXTENSIÓN.&ide({ExtensionSet}),,critical BOLEAN DEFAULT FALSE,entnValue OCTETSTRING

}ExtensionSet EXTENSIÓN ::= {...}

76

El campo validez especifica el intervalo de tiempo durante el cual el

certificado es válido. Esto significa que la CA emisora garantiza que

mantendrá esta información 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 dígitos para el año y

por tanto asume que ningún certificado tendrá una validez superior a

un siglo.

El campo subject identifica la entidad asociada con la llave pública

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 pública y

el algoritmo que ella usa pertenecientes a la entidad descrita en el

campo subject.

Los campos issuerUniqueID y subjectUniqueID fueron adicionados en

la versión dos para identificar unívocamente 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 atrás. Evitar confusiones con

los nombres reusados son los objetivos de estos dos campos.

El campo extensions permite la adición de nuevos campos a la

estructura del certificado sin la necesidad de modificar la definición del

mismo. Este campo es particularmente usado cuando el certificado

debe transportar información adicional propietaria del contexto en el

cual la PKI está desarrollada. Un certificado puede tener uno o más

campos de extensiones.

77

La figura 4.5 muestra la representación de un certificado de llaves

públicas X.509v3 en un navegador Netscape.

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 información:

Versión PGP: Este campo identifica que versión de PGP fue usada

para crear la llave asociada con el certificado.

La llave pública del portador del certificado y su algoritmo: Esta es

la parte pública de la pareja de llaves con el algoritmo de la llave:

RSA, DH (Diffie-Hellman) o DSA (Digital Signature Algorithm).

Información del portador del certificado: Este consiste de la

información sobre el usuario tal como su nombre, su identificación

(user ID), etc.

La firma digital del propietario del certificado: También llamada

autofirma. Es la firma usando la correspondiente llave privada de la

llave pública asociada con el certificado.

This Certificate belongs to:Ruixi Yuanryuan@bbn.comGTEI UsersBurlington, MA, US

This Certificate was issued by:AWS Issuing CAVPN AdvantageGTE InternetworkingUS

Serial Number: 00:A1This Certificate is valid from Wed Aug 25, 1999 to Fri Aug 25, 2000Certificate Fingerprint:B4:43:20:82:09:99:69:34:E0:2D:2A:5D:18:4F:9C:E2

78

El periodo de validez del certificado: Incluye la fecha y hora de

inicio del certificado y la fecha y hora de expiración del mismo.

El algoritmo de cifrado simétrico preferido para la llave: Este indica

el algoritmo de cifrado que el propietario del certificado prefiere

para que su información sea encriptada. Los algoritmos soportados

son CAST, IDEA y 3DES.11

Un certificado PGP es construido de un número de registros

etiquetados llamados paquetes. La figura 4.6 es la versión 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.

Figura 4.6 Certificado PGP en su versión ASCII

11 La última versión de PGP disponible es la 8.0 y aun no soporta AES.

-----BEGIN PGP PUBLIC KEY BLOCK-----Version: GnuPG v1.0.0 (FreeBSD)Comment: For info see http://www.gnupg.org

mQGiBDiQgiTRBADd7G5Di5ibmr2I03cU+QsZ/J02cAVc9z8VX/gwj3nxm81hvOHP1GZuHZB/guDPID7J6b0Zj0zjOr+KQf71sMnXMSn1pl1HyvvYeCeaV+XjpkmGmYpI8bWx85XO5XyqfWK0yhh51FtoE8UnboKTaJK8vsGX1bgZrQHKIUdG3zGzHwCg/2RViDPMuBQ4f+nbTkX6cvb++cEAl8g411r5Dx6fKehxccMiuntdea8lWfov8Cxj3Uxm101asg/bpdWVfu27oSZORcSqX1ZCSTRpjmXL14Tt7CiFJrz1hdrSE+uz95nRFD+0jVSM3eh45xp3Q9rCq4OwrdpAIUs9FhOweoJu/Pu0wcoV8MdHMw+LxdjQPV3zfzDMJuJAA/9zEy+7b+uxayTO0zdPYdiSqQYzvmZCs+f1EaKOcZg+JgL5mM3qUBgv+cOxsaNjXWJqtp11Y3TbYXcIl53bTFVJWZcAb7IxSsfec717dpoggF0SfqA/c7LW95gm0izceLKCDQQ3kIIjEAgA9kJXtwh/CbdyorrWqULzBej4UxE5T7bxbr1LCcDOAadWoxTpj0BV89AhxstDqZSt00xkhikn4DIOZejX1KTUPj1WV/cd12JPPT2N286z4VeSBm01Lmxx8/TD0auTYgi7GhvaXi7CcUJmBxIFrJzkN3/8xVsmjddezudEpTMaan3gIWLxF3xTz9NcetrXsRhluIjklloEhD2WeSW29X0/iMue1byHYTdybXNK/CT17rtgacQIn+ZUD7AHDcgbbEqpd3+tIisI9DSRb8q8QkxqubGupuqXqE1Nxzo=J30A3VOVklqn+vy5mC+DhyH3fqCo8p=omABrIJsmIUQv2firywEyWdaeei14m78x1yFAcq0oNyctz8WjhgzVgIoeF9NqilytfmxdVv478+KU3ZPMDZQDOPvDz/f3Ilbv950VigBdqsZx95iHgbbGraGagbqi4agbqi3JiiJaOjCazntkbAWnyaNuYdiE41DmaP/XTEbg7y/ycyUyAJDgIPywxWLSMTGS/ER1JDdJ/aa/Q===vTQH-----END PGP PUBLIC KEY BLOCK-----

79

La figura 4.7 muestra la estructura de un certificado PGP.

Figura 4.7 Estructura de un certificado PGP

Este certificado PGP consiste de cinco paquetes: un paquete de llave

pública, un paquete de identificación de usuario, un paquete de firma,

un paquete de subllave pública 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 creación

del certificado (created, en formato UTC, es decir el número de

segundos transcurridos desde el 1 de Enero de 1970), la fecha en la

que el certificado expira (expires), etc. 12

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

: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

80

4.3.6. SISTEMAS DE ADMINISTRACIÓN DE CERTIFICADOS

La interacción de todos los componentes de una PKI que manejan la

creación, renovación, mantenimiento y revocación de certificados digitales

es conocida como el Sistema de Administración de Certificados (Certificate

Management System). Esos componentes incluyen:

Autoridad de certificación

Autoridad de registro

Depósito de certificados y CRL

Algunas veces todos los tres componentes residen en el mismo

computador.

4.3.6.1.Autoridad De Certificación (CA)

La CA es la entidad que emite y revoca los certificados, entre sus

funciones están:

Creación y administración de las llaves públicas y privadas de la

propia CA

Creación de parejas de llaves públicas y privadas para los usuarios

que así las necesitan.

Creación de un certificado vinculando la llave pública del usuario a

la identidad del mismo.

Revocación de certificados.

Creación de la lista de certificados revocados.

81

Administración de una base de datos de información segura donde

reside la historia de los certificados emitidos y revocados.

Manejo de un completo registro (log) de mensajes para propósitos

de auditoría.

4.3.6.2.Autoridad de Registro (RA)

Una CA es responsable de dos cosas: La verificación de la información

del usuario y la emisión del certificado. La emisión 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 pequeño

número de sitios. La verificación de la información de un usuario, el

requerimiento de un certificado, la generación 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 más autoridades de registro

(RA) son empleadas para realizar estas funciones.

Una CA puede tener muchas RAs estratégicamente localizadas para

proveer una alta disponibilidad. Dado que la población de usuarios

crece continuamente, más y más RAs deben ser adicionadas para

mantener estable el nivel de servicio.

Una desventaja obvia de tener más y más 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 verificación y revocación de los

certificados que ella maneja.

4.3.6.3.Depósitos de Certificados y de CRLs

82

Cuando un certificado es emitido a un usuario, la CA puede también

publicar una copia de dicho certificado en un depósito. De la misma

manera cuando es necesario invalidar un certificado antes de su fecha

de expiración, la CA debe publicar la revocación publicándola en su

CRL. Lo más conveniente es mantener la CRL en la lista de certificados

en el mismo depósito.

Un certificado no puede ser declarado válido hasta no ser chequeado

contra la CRL, por lo tanto, es vital que un depósito de CRLs tenga

siempre un fácil acceso. Sin embargo, el facilitar este acceso también

puede hacer que el depósito 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 múltiples depósitos redundantes.

4.4.CONTROL DE ACCESO

El control de acceso es un conjunto de políticas 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

están 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 aplicación 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 modificación, causadas por la realización de alguna

acción, tales como la ejecución de un programa o el envío de un mensaje.

Autenticación

Control de A

cceso Recursos

Servidor

Políticas

Identidad

Atributos

Operación

Cliente

Usuario

Figura 4.8 Control de acceso en un modelo cliente-servidor

Un usuario tiene una identidad y un conjunto de atributos asociados. El

cliente envía la identificación del usuario, los atributos y el requerimiento de

una operación 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 políticas son preestablecidas en el

mecanismo de control de acceso; la información del usuario es comparada

con las reglas de las políticas para determinar los derechos de acceso del

usuario a ese recurso.

4.4.1. POLÍTICAS DE CONTROL DE ACCESO

Una política de control de acceso es el conjunto de reglas que definen la

protección de uno o más recursos. Esas reglas son generalmente

expresadas en términos de la información del usuario (atributos) y las

84

condiciones para el uso de un recurso (atributos del recurso y otros

factores del entorno).

En general hay dos tipos de políticas de control de acceso, las

discrecionales y las mandatarias. El control de acceso discrecional permite

al dueño 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 políticas de control de acceso representan los deseos de las entidades

que dicen ser dueñas o ejercen influencia sobre el recurso. En general, las

políticas de control de acceso son reglas que comparan la información 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 función match compara los atributos y condiciones con los valores

requeridos para accesar el recurso. Por flexibilidad, cada comparación

soporta un rango de valores.

Una política 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 específicas, 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 específicas.

Por lo general el orden de las reglas no interesa, pero es recomendable

organizarlas de la más específica a la más 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 más 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 cómo esos

usuarios pueden accederlo. Este método es de recurso céntrico; dando

el nombre del recurso, del usuario, los atributos del mismo y el tipo de

operación, el mecanismo de control de acceso puede buscar la ACL

correspondiente a ese recurso y determinar si el usuario puede o no

realizar la operación. Los usuarios en algunas ocasiones son puestos

en grupos o en clases equivalentes, las cuales tienen los mismos

derechos. Esta práctica tiene como objetivo volver más escalables las

ACLs dependiendo del número 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 básicas: lectura, escritura y ejecución. 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 ejecución (X); los derechos que no son garantizados se

llenan con un guión (-). Los tres conjuntos con los tres privilegios

forman una cadena de nueve dígitos (rwxrwxrwx). A continuación 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 ejecución para el propietario y de lectura y

ejecución 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 límites entre

una Intranet e Internet. El firewall, por lo tanto, tiene dos interfaces:

una con una dirección IP externa generalmente pública, y otra interfaz

con una dirección interna (generalmente privada). El firewall

implementa políticas 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 internetconnection

# 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 tráfico hacia

cualquier host de la Intranet usando el puerto 80 (trafico http), la

segunda regla permite el tráfico de protocolo ssh desde Internet

usando el puerto 22, la tercera regla permite el tráfico 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 conexión 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 clasificación 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

demás.

4.4.4. ADMINISTRACIÓN DE LAS POLÍTICAS DE CONTROL DE

ACCESO

Las políticas de control de acceso usualmente son dinámicas, es decir que

nuevas políticas deben ser aplicadas cada vez que nuevos recursos o

89

nuevos usuarios aparecen en la red. El proceso de crear, mantener y

distribuir las políticas de control de acceso es llamado administración de

las políticas de control de acceso.

Una administradora de políticas es la entidad que tiene el control sobre

todas las políticas de acceso en un sistema. El manejador de las políticas

es el servicio responsable de proveer a los administradores de una interfaz

fácil de usar que defina, instale, modifique y despliegue políticas. El

manejador de políticas también 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 múltiples puntos de control de acceso existen en una red, la

administración de las políticas puede ser hecha de una manera

centralizada o de una manera distribuida.

4.4.4.1.Administración de políticas distribuidas

Una administración de políticas distribuidas es mostrada en la figura

4.9, el administrador de políticas usa los manejadores de políticas que

se encuentran cerca o en los puntos a asegurar. Cuando una política

es creada, actualizada o borrada, el administrador contacta al

manejador asociado con ese recurso, y son éstos últimos los

encargados de almacenar las políticas internamente. Cuando una

decisión de control de acceso debe ser tomada, el recurso asegurado

le pregunta al respectivo manejador encargado de sus políticas. Este

manejador está usualmente muy cercano, o inclusive localizado en el

recurso mismo.

90

Administradorde políticas

Manejadorde políticas

Manejadorde políticas

Manejadorde políticas

Punto a asegurar

Punto a asegurar

Punto a asegurar

Figura 4.9 Manejo de políticas distribuidas

La administración de políticas distribuidas permite que las decisiones

de control de acceso sean hechas de una manera más rápida, ya que

el manejador está cercano al punto asegurado. Dado que las políticas

no viajan a través de la red para cada decisión, son menos

susceptibles de ataques tales como la introducción de falsas políticas o

la alteración 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 múltiples entidades, las políticas deberían 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.Administración centralizada de políticas

A diferencia de la administración de política distribuida, la

administración centralizada tiene solo un depósito central de políticas.

91

Cuando el administrador de políticas debe crear, actualizar o borrar

una política, solo tiene que contactar a un solo manejador, el cual a su

vez almacena la política en el depósito central. Dicho depósito central

de políticas puede estar cerca o inclusive ser parte del mismo

manejador de políticas. Cada punto a asegurar obtiene sus políticas de

control de acceso desde el depósito central a través de protocolos de

intercambios de políticas estandarizados o propietarios.

Una ventaja de este sistema es la facilidad de uso para el

administrador de políticas ya que contacta solo a un manejador.

También es fácil 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 están alejados del depósito

central. Realizar un caché de éstas políticas 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 actualización cuando en el depósito central es

cambiada una política. 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 políticas y la relación entre cada uno de

ellos.

92

Depósito centralde políticas

Punto de control deacceso (servidor)

Punto de control deacceso (servidor)

Punto de control deacceso (servidor)Manejador

de políticasAdministradorde políticas

Políticas

Figura 4.10 Manejo de políticas centralizado

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. TECNOLOGÍAS VPN

Básicamente, y desde el punto de vista de la torre OSI, se puede crear una VPN

usando tecnologías de capa 2 (enlace de datos) y de capa 3 (red). Dentro de la

primera categoría están PPTP y L2TP, y en la segunda se encuentra IPSec. MPLS

tiene características de las dos al ser una red conmutada que usa etiquetas para

enrutar paquetes.

Este capítulo comprende las tecnologías VPN más conocidas, y que técnicamente

presentan las mejores características de seguridad, rendimiento, facilidad y

economía.

5.1. PPTP (Point-to-Point Tunneling Protocol)

Es quizá el protocolo más sencillo de entunelamiento de paquetes. Es usado,

en general, por pequeñas empresas para realizar sus VPNs LAN-to-LAN, y en

topologías 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 integración 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, prácticamente no se conoció, L2F (Layer-2-

Forwarding) [REF5.2] .

El protocolo más comúnmente 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 túneles a través

de Internet. PPTP encapsula paquetes PPP usando una versión modificada del

Protocolo de Encapsulamiento Ruteado Genérico (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 más

usados. La figura 5.1 muestra una conexión PPP entre un host y un RAS.

Como se puede ver, es una conexión sencilla punto a punto donde lo primero

que se realiza es una autenticación sencilla previa al envío y recibo de tramas

PPP de datos.

Conectividad PPP

Usuarios autenticados

Conectividad PPPNombre de usuario y clave

Autenticado

Datos transmitidos

Datos Cabecerade protocolo PPP

DatosCabecerade protocoloPPP

ClienteServidor de Acceso

Remoto

Figura 5.1 Conexión PPP típica entre un host y un RAS

95

PPTP utiliza los mecanismos de autenticación que generalmente están

asociados a PPP tales como PAP y CHAP, una versión 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 incorporación del método 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 túneles, 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 más comúnmente usado para acceso a Internet,

prácticamente el único14, además 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 métodos 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, configuración y prueba de la

conexión y una serie de Protocolos de Control de Red (NCPs) para el

establecimiento y configuración 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 comunicación,

cada extremo de un enlace PPP primero envía paquetes LCP para

13 Es comúnmente usado en ambientes de acceso conmutados bajo tecnología Microsoft basarse en lainformación del dominio para validar a los usuarios.14 Otro protocolo de comunicación serial es SLIP pero prácticamente ha desaparecido.

96

configurar y probar el enlace de datos; cuando un enlace PPP ha sido

establecido, el usuario es usualmente autenticado15. La autenticación es

un paso previo para comenzar la fase de control de protocolos de red. En

PPP, la autenticación puede ser implementada con PAP o CHAP16. Cabe

resaltar que PAP envía las claves a través del enlace en texto plano,

mientras que CHAP es un protocolo de autenticación un poco más robusto

ya que el usuario interactúa con el sistema autenticador respondiendo

acertadamente a un requerimiento de desafío (challenge) al host remoto,

estos sistemas de autenticación son llamados de tres vías.

Después de que el enlace ha sido establecido y varias opciones han sido

negociadas por el protocolo LCP, PPP envía paquetes LCP para escoger y

configurar uno o más protocolos de capa de red. Después 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 conexión conmutada entre

el cliente y el servidor de acceso a la red. PPTP confía las siguientes

funciones a PPP:

Establecimiento y finalización de la conexión física

Autenticación de los usuarios

Creación 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 lógicos. PPTP

separa los canales de control y de datos usando un flujo de control que

15 La autenticación es una fase opcional en PPP pero por lo general es implementada por todas las ISPs paraverificar la información de sus usuarios conmutados.16 Más información de estos protocolos se encuentra en el capítulo 4 que habla sobre los sistemas deautenticación

97

corre sobre TCP y un flujo de datos que está encapsulado con cabeceras

IP usando GRE. La conexión TCP es creada entre el cliente y el servidor

PPTP. Esta conexión 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 periódicamente para indagar sobre el estado del enlace y las

señales de manejo entre el cliente y el servidor PPTP. Los paquetes de

control también se usan para enviar información de manejo básica del

dispositivo y de configuración. Los mensajes de control establecen,

mantienen y finalizan un túnel PPTP.

Después de que el túnel 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 versión modificada del

protocolo GRE (Generic Routing Encapsulation); esta modificación 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

están transmitiéndose en el túnel.

La cabecera GRE es usada para encapsular el paquete PPP dentro del

datagrama IP. La información ú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 túnel está transmitiendo, esta puede ser Ethernet, Frame

Relay o PPP. La figura 5.2 muestra la estructura en los diferentes sitios de

un túnel de un paquete IP usando encapsulacion PPTP desde el sistema

cliente hasta la LAN corporativa.

98

Red Privada Virtual

SistemaCliente

InternetServidor de Acceso

Remoto (ISP) RAS conPPTP nativo

LANcorporativa

Cabecera del medio de entrega (varios tipos)

Cabecera IP

Cabecera GRE mejorada Carga útil de paquete PPP

Datagramas IP, IPX y NETBEUI

Trama EthernetCabecera PPP

Figura 5.2 Estructura de un túnel PPTP

5.1.2. TUNELES

PPTP permite a los usuarios y a las ISPs crear varios tipos de túneles,

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 terminación del túnel, 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 túneles se pueden dividir en dos clases, voluntarios y

permanentes.

Los túneles voluntarios son creados por requerimiento de un usuario y

para un uso específico. Los túneles permanentes son creados

99

automáticamente sin la acción de un usuario y no le permite escoger

ningún tipo de privilegio.

En los túneles voluntarios, la configuración del mismo depende del usuario

final, cuando se usan túneles de este tipo, el usuario puede

simultáneamente acceder a Internet y abrir un túnel seguro hacia el

servidor PPTP. En este caso el cliente PPTP reside en el computador del

usuario. Los túneles voluntarios proveen más privacidad e integridad de

los datos que un túnel permanente. La figura 5.3 muestra un escenario de

túneles voluntarios creados desde dos clientes distintos a un mismo

servidor PPTP a través de Internet.

Internet

Intranet

Servidor PPTPCliente PPTP A

Cliente PPTP B

Túnel PPTP

Figura 5.3 Túneles Voluntarios

Los túneles 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 tráfico originado desde el computador del usuario final es

reenviado por el RAS sobre el túnel PPTP. En este caso la conexión del

usuario se limita solo a la utilización del túnel PPTP, no hay acceso a la red

pública (Internet) sobre la cual se establece el túnel. Un túnel permanente

PPTP permite que múltiples conexiones sean transportadas sobre el

mismo túnel. La figura 5.4 muestra un túnel 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.

Internet

Intranet

Servidor PPTP

Túnel PPTP

RAS conPPTP nativo

A B

Figura 5.4 Túneles Permanentes

Dado que los túneles permanentes tienen predeterminados sus puntos

finales y que el usuario no puede acceder a Internet, estos túneles

ofrecen mejor control de acceso que los túneles voluntarios. Otra ventaja

de los túneles permanentes, es que reducen el ancho de banda utilizado,

ya que múltiples sesiones pueden ser transportadas sobre un único túnel,

a diferencia de los túneles voluntarios donde cada sesión tiene que

trabajar con cabeceras independientes que ocupan un ancho de banda.

Una desventaja de los túneles permanentes es que la conexión inicial, es

decir, entre el usuario final y el servidor de acceso que esta actuando

como cliente PPTP, no hace parte del túnel, por lo tanto, puede ser

vulnerable a un ataque.

Los túneles permanentes se dividen en estáticos y dinámicos. Los túneles

estáticos son aquellos que requieren equipos dedicados y su configuración

es manual. En este tipo de túneles el usuario final tiene a su disposición

varios RAS, los cuales tienen establecidos diferentes túneles 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 número X,

pero si ese mismo usuario quiere hacer una VPN con su oficina en una

ciudad B, tiene que marcar un número Y.

Los túneles permanentes dinámicos usan el nombre del usuario para

determinar el túnel asociado con él, es decir que se encargan de

aprovechar mejor los recursos y el usuario puede marcar al mismo

número para establecer túneles a diferentes sitios. La información

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 túneles permanentes estáticos son más

costosos que los dinámicos, 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 vía Internet. Los túneles LAN-to-LAN no fueron

soportados en un comienzo. Solo hasta el año 1997 cuando Microsoft

introdujo su servicio de enrutamiento de acceso remoto (RRAS) para

servidores NT 4.0, se pudieron implementar topologías LAN-to-LAN

usando PPTP como protocolo de entunelamiento.

La implementación de Microsoft para entunelamiento LAN-to-LAN exige la

presencia de dos servidores PPTP que tienen la función de hacer de

gateways seguros de las dos redes locales. Sin embargo, la gran

102

desventaja de usar PPTP en topologías LAN-to-LAN es la inseguridad

inherente a la arquitectura del protocolo. En efecto, la autenticación 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 topología

de red LAN-to-LAN entre una pareja de servidores PPTP usando un túnel

PPTP sobre Internet, para los usuarios tanto de la LAN corporativa A como

de la B el túnel es transparente, y a nivel lógico se trabaja como en una

única red local.

Internet

PAC Servidor de AccesoRemoto (ISP)

LANcorporativa B

LANcorporativa A

PNSTÚNEL PPTP

Figura 5.5 Topología LAN-to-LAN usando un túnel PPTP

Para crear un túnel 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 actúa como el servidor PPTP y el otro como

un cliente PPTP, de esta manera, un túnel voluntario es creado entre los

dos extremos y por el mismo pueden existir varias sesiones.

Dado que un túnel PPTP puede encapsular varios protocolos de capa de

red, los usuarios no tendrán acceso a los recursos, que cada protocolo le

provee hasta que sus privilegios sean validados por el correspondiente

protocolo.

Detalles prácticos para configurar una topología LAN-to-LAN usando PPTP

se verán en el capítulo 6.

103

5.1.4. COMPONENTES DE UNA VPN PPTP

5.1.4.1. Servidores PPTP

Un servidor PPTP tiene dos funciones básicas: actuar como el punto

final del túnel 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 dirección IP privada que se encuentra dentro de este.

Una de las características de los servidores PPTP es la de poder filtrar

únicamente el tráfico PPTP dependiendo de si esta condición 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 están 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 ningún software o hardware adicional en el extremo final del

cliente, solamente que éste pueda establecer una conexión 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 túnel.

Para esto primero deberá establecer una conexión PPP marcando vía

modem a la ISP, y una vez ésta esté establecida, deberá realizar una

segunda conexión PPTP usando un puerto virtual proveído 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.

También existen clientes PPTP para Linux18

5.1.4.3. Servidores de Acceso de Red

Los servidores de acceso a la red también 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 telefónicos conmutados. Sus

funciones van desde el establecimiento de la conexión física

(modulación, demodulación, compresión de datos, corrección de

errores, etc.) hasta labores de enrutamiento presentes en la capa 3 de

la torre OSI.

Dentro de un túnel PPTP se pueden encontrar NAS actuando como

clientes PPTP o simplemente como un concentrador de acceso PPP.

17 En Windows 95 se requiere actualizar el acceso telefónico a redes a la versión 1.3, dicho software seencuentra disponible en el sitio de actualizaciones de Microsoft,http://www.microsoft.com/windows95/downloads/contents/WURecommended/S_WUNetworking/dun13win95/Default.asp18 En http://pptpclient.sourceforge.net/ se encuentran versiones GNU de clientes PPTP para diferentesdistribuciones de Linux

105

PPTP permite que las funciones realizadas por un servidor de acceso a

la red (NAS) sean separadas usando una arquitectura cliente-servidor.

Comúnmente, las siguientes funciones son implementadas por un NAS:

1. Brindar una interfaz física entre la red telefónica pública

conmutada y los módems. Esto incluye conversiones A/D y D/A,

conversiones síncronas a asíncronas y manipulaciones de flujos

de datos.

2. Terminación lógica de enlaces PPP.

3. Autenticación de enlaces PPP.

4. Sumarización de canales (protocolo multilink PPP).

5. Terminación lógica 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 conexión de control entre cada pareja PAC-PNS la

cual opera sobre TCP; y un túnel IP operando sobre la misma pareja

PAC-PNS el cual es usado para transportar paquetes PPP con

encapsulamiento GRE.

5.1.4.5. Conexión de control

106

Antes que el entunelamiento PPP ocurra entre un PAC y un PNS, una

conexión de control debe ser establecida entre ellos. La conexión de

control es una sesión TCP que mantiene control sobre la llamada e

intercambia mensajes de información. Por cada pareja PAC-PNS debe

existir una conexión de control y un túnel. La conexión de control es la

responsable por el establecimiento, el manejo y la liberación de las

sesiones que existen en el túnel.

El PNS y el PAC establecen la conexión de control usando mensajes

Start-Control-Connection-Request y Start-Control-Connection-Reply.

Esos mensajes son también usados para intercambiar información

básica entre los dos extremos del túnel. La conexión de control puede

comunicar cambios entre las dos partes con un mensaje Set-Link-Info.

Una sesión puede ser liberada por el PAC o por el PNS.

La conexión 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

conexión de control entre un PNS y un PAC. La sesión TCP es

establecida hacia el puerto 1723. El puerto origen es asignado a

cualquier número de puerto que no esté siendo usado en el momento

del establecimiento del túnel.

Cada mensaje en la conexión 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 conexión definidos por el

protocolo PPTP son: mensajes de control y mensajes de gestión; éstos

últimos aún no se encuentran definidos y se han reservado para

aplicaciones futuras.

La “magic cookie” es la constante 0x1A2B3C4D. Su función básica es

asegurarle al receptor que está sincronizado con el flujo de datos TCP.

La pérdida de sincronización no conlleva a una resincronización, sino a

un cierre inmediato de la sesión TCP de la conexión de control.

Los mensajes de control definidos por el protocolo PPTP son:

Gestión de la conexión de control

Start-Control-Connection-Request

Start-Control-Connection-Reply

Stop-Control-Connection-Request

Stop-Control-Connection-Reply

Echo-Request

Echo-Reply

Gestión 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 sesión PPP

Set-Link-Info

5.1.4.6. Operación del Túnel

PPTP necesita el establecimiento de un túnel por cada pareja PNS-PAC.

Este túnel 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é sesión.

De ésta manera, los paquetes PPP son multiplexados y

desmultiplexados sobre un único túnel existente entre una pareja PNS-

PAC. El valor del campo Clave es definido dentro del proceso de

establecimiento de la llamada.

La cabecera GRE también contiene información de reconocimiento y de

secuencialización con la cual se realiza control de congestión y

detección de errores en el túnel.

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

ningún elemento de tramado de medio específico. Los paquetes IP

transmitidos sobre los túneles entre un PAC y un PNS tienen la

estructura general que se muestra en la figura 5.6

GREIPMedio 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 versión ligeramente

mejorada de la especificación estándar del protocolo GRE. La

principal diferencia es la definición de un nuevo campo de

reconocimiento de número (Acknowledgment Number), usado para

determinar si un paquete particular GRE o un conjunto de paquetes

ha arribado al lado remoto del túnel. Esta capacidad de

reconocimiento no es usada en conjunto con ningún tipo de

retransmisión, 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 túnel.

5.2. L2TP (Layer 2 Tunneling Protocol)

L2TP [REF5.4] fue creado como el sucesor de PPTP y L2F. Las dos compañías

abanderadas de cada uno de estos protocolos, Microsoft por PPTP y Cisco por

L2F, acordaron trabajar en conjunto para la creación de un único protocolo de

capa 2 y así lograr su estandarización por parte de la IETF.

110

Como PPTP, L2F fue diseñado 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, permitiéndole trabajar con otros medios físicos por ejemplo Frame

Relay. Paralelamente al diseño de PPTP, L2F utilizó PPP para autenticación de

usuarios accesando vía telefónica conmutada, pero también incluyó soporte

para TACACS+ y Radius. Otra gran diferencia de L2F con respecto a PPTP es

que permite que un único túnel soporte más de una conexión. Hay dos

niveles de autenticación del usuario: primero, por la ISP antes de crear el

túnel; segundo, cuando la conexión está configurada y la autenticación la

realiza el gateway corporativo.

Todas las anteriores características de L2F han sido transportadas a L2TP.

Como PPTP, L2TP utiliza la funcionalidad de PPP para proveer acceso

conmutado que puede ser tunelizado a través 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

autenticación 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. COMPONENTES BÁSICOS DE UN TÚNEL L2TP

5.2.1.1. Concentrador de acceso L2TP (LAC)

Un LAC es un nodo que se encuentra en un punto extremo de un túnel

L2TP. El LAC se encuentra entre un LNS y un sistema remoto y reenvía

los paquetes a y desde cada uno. Los paquetes enviados desde el LAC

hasta el LNS van tunelizados. En algunas ocasiones el sistema remoto

actúa 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 túnel

L2TP y que interactúa con el LAC, o punto final opuesto. El LNS es el

punto lógico de terminación de una sesión PPP que está siendo

tunelizada desde un sistema remoto por el LAC.

5.2.1.3. Túnel

Un Túnel existe entre una pareja LAC-LNS. El túnel consiste de una

conexión de control y de ninguna o más sesiones L2TP. El túnel

transporta datagramas PPP encapsulados y mensajes de control entre

el LAC y el LNS.

112

5.2.2. TOPOLOGÍA DE L2TP

La figura 5.7 describe un escenario típico L2TP. El objetivo es tunelizar

tramas PPTP entre un sistema remoto o un cliente LAC y un LNS localizado

en la LAN corporativa.

LAC

LAC

LNS

LNS

SistemaRemoto

LANCORPORATIVA

LANCORPORATIVA

Host

Host

ClienteLAC

INTERNET

Nube FrameRelay o ATM

RedTelefónicaConmutada

Pública

Figura 5.7 Distintos escenarios de túneles L2TP

El sistema remoto inicia una conexión PPP a través de la red de telefonía

pública conmutada a un LAC. El LAC luego tuneliza la conexión PPP a

través de Internet o una nube Frame Relay o ATM a un LNS por donde

accesa a la LAN remota corporativa. La dirección del sistema remoto es

dada desde la LAN corporativa por medio de una negociación PPP NCP. La

autenticación, autorización 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 también crear un

túnel 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 pública, tal como Internet. Una conexión PPP “virtual” es luego creada

y el software cliente LAC hace un túnel hasta el cliente LNS. Como en el

caso anterior, el direccionamiento, la autenticación, la autorización 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 finalización de túneles y llamadas. Los

mensajes de datos son usados para encapsular tramas PPP que está

siendo transportadas sobre el túnel. 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 pérdidas de

paquetes.

La figura 5.8 muestra la relación 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 números de secuencia estén

presentes en todos los mensajes de control. Los mensajes de datos

114

pueden usar esos números de secuencia para reordenar paquetes y

detectar pérdidas de los mismos.

Tramas PPPMensajes de datos L2TP Mensajes de control L2TPCanal de datos L2TP (no

confiable)

Canal de control L2TP

(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 común. La figura 5.9 muestra el

formato de una cabecera L2TP.

T L x x S c O P x x x x Ver Length (Opc)Tunnel ID Session IDNs (Opc) Nr (Opc)Offset Size(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

están presentes. El bit S debe estar puesto en 1 para los mensajes de

control.

Si el bit O (Offset) es 1, el campo de tamaño 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 transmisión. 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 conexión local puede

originar una demora en los mensajes keepalive ocasionando una

pérdida innecesaria del enlace. Esta característica 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 versión 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

conexión. Los túneles L2TP son nombrados por identificadores que

tienen significado local únicamente. Es decir, el mismo túnel.

El campo Session ID indica el identificador para una sesión dentro del

túnel. Al igual que los identificadores de túnel, las sesiones L2TP son

nombradas por identificadores que tienen únicamente significado local.

116

El campo Ns indica el número de secuencia para los mensaje de datos

y de control.

El campo Nr indica el número 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 número de octetos

después 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 creación, mantenimiento y finalización del túnel.

Manejo de la conexión de control

0 (reserved)

1 (SCCRQ) Start-Control-Connection-Request

2 (SCCRP) Start-Control-Connection-Reply

3 (SCCCN) Start-Control-Connection-Connected

4 (StopCCN) Stop-Control-Connection-Notification

5 (reserved)

6 (HELLO) Hello

Manejo de la llamada

7 (OCRQ) Outgoing-Call-Request

8 (OCRP) Outgoing-Call-Reply

117

9 (OCCN) Outgoing-Call-Connected

10 (ICRQ) Incoming-Call-Request

11 (ICRP) Incoming-Call-Reply

12 (ICCN) Incoming-Call-Connected

13 (reserved)

14 (CDN) Call-Disconnect-Notify

Reporte de errores

15 (WEN) WAN-Error-Notify

Control de la sesión PPP

16 (SLI) Set-Link-Info

5.2.4. OPERACIÓN DEL PROTOCOLO

Para tunelizar una sesión PPP con L2TP se necesita llevar a cabo dos

pasos, el primero, el establecimiento de una conexión de control para el

túnel y el segundo, el establecimiento de una sesión respondiendo al

requerimiento de una llamada entrante o saliente. El túnel y su

correspondiente conexión de control deben ser establecidos antes que una

llamada entrante o saliente sea iniciada. Una sesión L2TP debe ser

establecida antes que L2TP pueda empezar a tunelizar tramas PPP.

Múltiples sesiones pueden existir a través de un túnel único y múltiples

túneles pueden existir entre el mismo LAC y LNS.

La figura 5.10 ilustra la relación que puede existir entre un LAC y un LNS,

claramente se notan los puntos terminales de un enlace PPP de una sesión

L2TP, de una conexión de control L2TP y del túnel en sí.

118

SistemaRemoto

SistemaRemoto

Enlace PPP

Enlace PPP

Llamadatelefónica

Llamadatelefónica

LAC LNSConexión de Control L2TP

Sesión L2TP

Sesión L2TP

TÚNEL L2TP

Figura 5.10 Entunelamiento de tramas PPP usando L2TP

5.2.4.1. Establecimiento de la Conexión de Control

La conexión de control es la conexión inicial que debe llevarse a cabo

entre un LAC y un LNS antes que puedan crearse sesiones a través de

ésta.

El establecimiento de la conexión de control incluye la verificación 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 conexión de control.

LACo

LNS

LACo

LNS

SCCRQ

SCCCN

SCCR

ZLB ACK

Figura 5.11 Establecimiento de una conexión de control

El ZLB ACK es enviado si no hay más mensajes esperando en cola para

ese extremo.

119

5.2.4.2. Autenticación del Túnel

L2TP incorpora un sistema de autenticación simple y opcional parecido

a CHAP durante el establecimiento de la conexión de control. Si un LAC

o LNS desea autenticar la identidad de su pareja, éste le envía 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 túnel no

debe ser permitido.

5.2.4.3. Establecimiento de la Sesión

Después del establecimiento exitoso de la conexión de control,

sesiones individuales pueden ser creadas. Cada sesión corresponde a

un único stream PPP entre el LAC y el LNS. A diferencia del

establecimiento de la conexión de control, el establecimiento de la

sesión es direccional con respecto al LAC y al LNS. El LAC solicita al

LNS aceptar una sesión para una llamada entrante, y el LNS solicita a

el LAC aceptar una sesión para una llamada saliente.

5.2.4.3.1. Establecimiento de una Llamada Entrante

La figura 5.12 muestra la secuencia típica de intercambio de tres

mensajes para configurar la sesión.

120

LAC LNS

ICRQ

ICCN

ICRP

ZLB ACK

LlamadaEntrante

Figura 5.12 Establecimiento de una llamada entrante

El ZLB ACK es enviado si no hay más 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 típica de intercambio de tres

mensajes para configurar la sesión.

LAC LNS

OCRP

OCCN

OCRQ

ZLB ACK

Figura 5.13 Establecimiento de una llamada saliente

El ZLB ACK es enviado si no hay más mensajes esperando en cola

para la pareja remota.

5.2.4.4. Reenvío de Tramas PPP

Una vez el establecimiento del túnel se ha completado, las tramas PPP

desde el sistema remoto son recibidas en el LAC, encapsuladas en

121

L2TP y reenviadas sobre el túnel 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 sesión y un túnel particular,

coloca el identificador de sesión y de túnel 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 túnel 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 aún asignado

(por ejemplo durante el establecimiento de una nueva sesión o túnel),

el campo Session ID debe ser enviado como 0, igualmente, para los

casos donde el Tunnel ID aún no ha sido asignado desde el nodo

remoto.

5.2.4.5. Uso de Números de Secuencia en el Canal de

Datos

Los número 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 secuencialización opcional para los

mensajes de datos. Cada nodo mantiene una secuencia de números

diferentes para la conexión de control y para cada sesión de datos

individual dentro del túnel.

122

A diferencia del canal de control L2TP, el canal de datos no usa

números de secuencia para retransmitir mensajes de datos perdidos,

en vez de éstos, los mensajes de datos pueden usar números 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 números esté presente en

los mensajes de datos. El LNS controla el envío o no de la secuencia

de números, si el LAC recibe mensajes de datos sin la secuencia de

números presente, éste deberá parar cualquier secuencia de datos

futura. Si el LAC recibe mensajes de datos con una secuencia de

números presente, este deberá comenzar a enviar números de

secuencia en todos los mensajes de datos salientes futuros. Estos

procesos de habilitar o deshabilitar la secuencia de números puede

ocurrir en cualquier momento de la transferencia de paquetes. Es

recomendable activar esta características 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 túnel. Esto se realiza enviando mensajes de

control Hello después de que un periodo de tiempo específico ha

transcurrido desde que el último mensaje de control o de datos fue

recibido en el túnel. Como con cualquier otro mensaje de control, si el

mensajes Hello no es recibido oportunamente el túnel 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 túnel.

123

5.2.4.7. Terminación de la Sesión

Tanto el LAC como el LNS pueden terminar una sesión, esto se logra

por medio de un mensaje de control CDN, la figura 5.14 es un ejemplo

típico del intercambio de mensajes de control para terminar una

sesión.

LACo

LNS

LACo

LNS

CDN

ZLB ACK

(Clean Up)

(Clean Up)

Figura 5.14 Terminación de la sesión

5.2.4.8. Terminación de la Conexión de Control

Al igual que con una sesión, la conexión 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 conexión de

control.

124

LACo

LNS

LACo

LNS

StopCCN

ZLB ACK

(Clean Up)

(Espera)

(Clean Up)

Figura 5.15 Terminación de la conexión de control

Para terminar el túnel y todas las sesiones en él, es necesario

solamente en envío de un StopCCN, no se necesita bajar sesión por

sesión 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 diseñados para proveer una

seguridad basada en criptografía 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, autenticación del origen de los datos, protección

antirepetición y confidencialidad en los datos. Entre las ventajas de IPSec

están la modularidad del protocolo, ya que no depende de un algoritmo

criptográfico específico.

125

5.3.1. COMPONENTES DE IPSEC

IPSec está compuesto por tres componentes básicos: 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

demás 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 también al uso de protocolos y

procedimientos para el manejo de llaves criptográficas tales como IKE

(Internet Key Exchange Protocol) [REF5.8]. El éxito de una

implementación IPSec depende en gran medida de una adecuada

escogencia del protocolo de seguridad y de la forma como se

intercambian las llaves criptográficas.

AH es un protocolo que añade una nueva cabecera justo después de la

cabecera IP original. AH provee autenticación del origen de los datos e

integridad de los mismos, también provee integridad parcial para

prevenir ataques de repetición. Este protocolo es apropiado cuando se

requiere autenticación en vez de confidencialidad.

ESP provee confidencialidad para el tráfico IP, al igual que

autenticación 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

dinámicamente sus servicios de seguridad y sus llaves de cifrado al

igual que la autenticación de la sesión misma

5.3.1.2. Asociaciones de Seguridad (SAs)

El concepto de asociación de seguridad (SA) es clave en IPSec. Una SA

define las medidas de seguridad que deberían ser aplicadas a los

paquetes IP basados en quién los envía, 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 túnel; la diferencia radica en la manera como cada

uno de ellos altera el paquete IP original. El modo de transporte es

diseñado para proteger los protocolos de capas superiores tales como

TCP y UDP. En modo túnel, 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 guía a los datos a través de la red.

Cabecera IPoriginal Carga Útil

PaqueteIP

Cabecera deSeguridad Carga ÚtilCabecera IP

original

Modo Transporte

Cabecera IPoriginal Carga Útil

PaqueteIP

Cabecera deSeguridad Carga Útil

Cabecera IPoriginal

Modo Túnel

NuevaCabecera IP

PaqueteIPEncapsulación

Figura 5.16 Estructura del paquete IP en modo de Transporte y Túnel

127

Las SAs pueden ser negociadas entre dos entidades IPSec

dinámicamente, para lo cual se basan en políticas de seguridad dadas

por el administrador del sistema o estáticamente especificadas por el

administrador directamente.

Una SA es únicamente identificada por tres parámetros: una dirección

IP de destino, un identificador del protocolo de seguridad y un índice

del parámetro de seguridad (SPI). La dirección IP de destino es aquella

por la cual se identifica el punto final de la SA, el SPI es un número 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 número con el cual se

define cada uno de ellos, 51 para AH o 50 para ESP.

Como se nota, la dirección 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 dirección, de aquí que, si dos dispositivos

necesitan intercambiar información en ambas direcciones usando

IPSec, requerirán 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 túnel, 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 continuación de ella.

128

Varias SAs pueden ser aplicadas en serie para incrementar los servicios

de seguridad del tráfico IP. En estas situaciones una SA es encerrada

por otra. El protocolo IPSec define dos formas: transporte adyacente y

túneles 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 después

de ESP.

En túneles iterados, se puede combina cualquier cantidad de túneles

con lo cual se logra proveer de capas anidadas de seguridad. Los

puntos finales del túnel pueden ser en la misma o en diferentes

locaciones. Por ejemplo, un túnel host-to-host puede ser entunelado

por un túnel gateway-to-gateway; y un túnel gateway-to-gateway

puede de nuevo ser entunelado por otro túnel 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 políticas de seguridad y en la otra las asociaciones de

seguridad, SPD (Security Policy Database) y SAD (Security Association

Database) respectivamente. El administrador de políticas define un

conjunto de servicios de seguridad para ser aplicados al tráfico IP

tanto entrante como saliente. Esas políticas 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

parámetros concernientes a las SAs, cada una de ellas tiene una

entrada en la SAD donde se especifican todos los parámetros

necesarios para que IPSec realice el procesamiento de paquetes IP

que son gobernados por esa SA. Entre los parámetros que se

encuentran en una SAD se tienen:

El índice de parámetro de seguridad.

El protocolo a ser usado por la SA (ESP o AH).

El modo en el cual el protocolo es operado (túnel o

transporte).

Un contador numérico secuencial.

La dirección IP fuente y destino de la SA.

El algoritmo de autenticación y la llave de autenticación

usadas.

El algoritmo de cifrado y su llave.

El tiempo de vida de las llaves de autenticación 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 dirección IP destino, el tipo de protocolo

IPSec y el SPI. La dirección 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 mención, é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

política para el paquete de salida que especifique que un

procesamiento IPSec es necesario, la SAD es buscada para

determinar si una asociación 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 Políticas de

Seguridad

Una base de datos de políticas de seguridad es una lista ordenada

de políticas de seguridad a ser aplicadas a los paquetes IP. Dichas

políticas 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 acción. Los selectores clasifican un paquete IP sobre una

acción. Un selector es un parámetro y el valor o rango de valores

para éste parámetro. Los parámetros generalmente se encuentran

dentro de una de éstas dos categorías:

Aquellos que se encuentran dentro de un paquete IP, tales

como, la dirección IP, número de protocolo y números de

puertos de capas superiores.

Aquellos que se derivan de la credencial de autenticación de

una entidad de comunicación, tales como, una dirección de

131

correo o un nombre distinguido DN (Distinguished Names)

en certificados digitales

Diferentes operadores lógicos como AND, OR y NOT pueden ser

aplicados a las políticas para combinar más de un selector.

Cuando un paquete IP contiene valores que concuerdan con los

especificados por algún selector de una entrada, la acción 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

políticas de seguridad para un paquete entrante y saliente,

claramente se notan las partes que componen un selector como lo

son los parámetros y su correspondiente valor, al frente se

encuentra la acción que IPSec tomaría si los paquetes IP

concuerdan con los valores de los selectores.

Selectores Accióndirección_IP fuente = 10.0.0.92ANDdirección de e-mail fuente = financiera@telesat.com.co

Entrantes

nombre_distinguido fuente = Andrés Gómez

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

dirección_IP destino = 192.89.0.169 Omitir

Selectores Accióndirección_IP destino = 10.0.0.92

Salientes

nombre_distinguido destino = Andrés Gómez

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

dirección_IP fuente = 192.89.0.169 Omitir

Figura 5.17 Ejemplos de entradas en una base de datos de políticas de seguridad

132

Es posible que un paquete IP concuerde con más 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

política seleccionada. En adición, una política 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 política por defecto es descartar el paquete IP.

La SPD trata al tráfico saliente y entrante de manera separada, esto

es, que se deben aplicar políticas 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. Después del procesamiento SPD, el sistema reenvía el

paquete al siguiente salto o le aplica procedimientos adicionales

tales como las reglas de algún 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 desempeño de un dispositivo IPSec. De hecho, el

procesamiento SPD es el cuello de botella más representativo en

una implementación IPSec.

133

5.3.2. AUTHENTICATION HEADER (AH)

El protocolo de cabecera de autenticación AH es usado para propósitos de

autenticación de la carga útil IP a nivel de paquete por paquete, esto es

autenticación de la integridad de los datos y de la fuente de los mismos.

Como el término autenticación indica, el protocolo AH se asegura que los

datos entregados dentro del paquete IP son auténticos, es decir, que han

arribado a su destino sin ninguna modificación. AH también provee de un

mecanismo de protección opcional antirepetición de paquetes IP. Sin

embargo, AH no protege la confidencialidad de los datos, es decir, no

recurre a ningún tipo de cifrado de los mismos.

El protocolo AH define como un paquete IP sin protección es convertido

en uno nuevo que contiene información adicional y que brinda

autenticación. El elemento fundamental usado por AH es una cabecera de

autenticación como se muestra en la figura 5.18. El nuevo paquete IP es

formado insertando la cabecera de autenticación, bien sea, después de la

nueva cabecera IP o después de la cabecera IP original modificada según

sea el modo en el cual trabaje la SA, más adelante se tratara con mayor

detalle cada uno de estos dos modos: transporte y tunel.

Cuando la cabecera de autenticación es insertada, la cabecera IP que la

precede deberá indicar que la próxima cabecera que se encuentra es la

cabecera de autenticación y no la carga útil del paquete original. La

cabecera IP realiza esta acción 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 autenticación

La cabecera de autenticación 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 autenticación (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 número arbitrario de 32 bits. Este valor es usado junto con la

dirección 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 monotónico 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 protección antirepetición.

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 autenticación 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 más sobre estos campos de una cabecera de un paquete IP

puede consultarse la RFC2402.

Para realizar el proceso de autenticación, 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 autenticación incluye. La llave

secreta es negociada durante el establecimiento de la SA. La autenticación

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 autenticación

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 autenticación.

Finalmente el ICV es calculado sobre la totalidad del nuevo paquete IP

excluyendo los campos mutables mencionados previamente.

Cabecera IPoriginal

Cabecera deAutenticación

Cabecera IPoriginal

Cabecera deprotocolo superior

Cabecera deprotocolo superior

Datos de capa superior

Datos de capa superior

Carga útil

Autenticado

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 limitación

grande cuando los dispositivos que están gobernados por esta SA

IPSec actúan como gateways de otros hosts que se encuentran detrás

de ellos.

5.3.2.2. Modo Túnel

En modo Túnel, una nueva cabecera es creada para el nuevo paquete

IP y la cabecera de autenticación 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 autenticación se aplica sobre el paquete IP

original entero (incluyendo los campos mutables de la cabecera IP

original).

Cabecera IPoriginal

Cabecera deAutenticación

NuevaCabecera IP

Cabecera deprotocolo superior

Cabecera deprotocolo superior

Datos de capa superior

Datos de capa superiorCabecera IPoriginal

Carga útil

Autenticado

Figura 5.20 Modo Túnel 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 tráfico IP original. La nueva

cabecera IP contiene la dirección IP fuente y de destino de los

dispositivos IPSec entre los cuales viaja el nuevo paquete. De esta

manera el modo Túnel puede ser usado si los puntos finales de la SA

son un host o gateway de seguridad.

A diferencia del modo Transporte, el modo Túnel tiene como

desventaja adicionar mas bytes extra por lo cual el throughput efectivo

del enlace disminuye al igual que el desempeño 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

autenticación 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 autenticación, confidencialidad de los

datos por medio de cifrado y una protección opcional antirepetición

para los paquetes IP. La autenticación y el cifrado son también

opcionales, pero al menos una de ellas debe ser empleada; de lo

contrario, este protocolo carecería de fundamento.

La confidencialidad es lograda por medio de técnicas 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 también un algoritmo válido en

este protocolo. En este caso, ESP solamente presta el servicio de

autenticación para el tráfico.

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 autenticación ESP. La figura 5.21 muestra la

conformación de un paquete IP después que se ha procesado con el

protocolo IPSec ESP, se observan la ubicación de los campos dentro de

cada uno de los segmentos del nuevo paquete.

139

Cabecera IP Carga Útil TrailerESP

AutenticaciónESP

CabeceraESP

Security Parameter Index (SPI) (32 bits)Número de secuencia (32 bits)

Next Header (8 bits)Pad Len (8 bits)Padding (0-225 bytes)

Authentication Data (variable)

Figura 5.21 Nuevo paquete IP procesado con ESP

La cabecera ESP se encuentra después de la nueva cabecera IP o

después 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 autenticación ESP se encuentra después de el trailer. Si

la autenticación no es aplicada, el segmento de autenticación ESP no

es añadido. 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. También se encuentran otros dos campos, el

campo Padding es usado para rellenar los datos a ser encriptados y

completar un límite 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 después de que los datos son desencriptados.

Existe un problema cuando la longitud del nuevo paquete IP, debido a

la adición de una cabecera ESP y de unos campos de relleno y de

autenticación, resulta ser mas grande que el tamaño máximo 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

autenticación ESP son añadidos si son necesarios.

Si el paquete está siendo sujeto de un segundo proceso de

encapsulamiento ESP, la nueva cabecera ESP es puesta después de

la primera y los segmentos trailer y de autenticación son añadidos

después 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 más usado cuando no es necesario

ocultar o autenticar las direcciones IP tanto de la fuente como del

destino.

En la gráfica 5.22 se detalla la conformación del nuevo paquete IP

usando ESP en modo transporte, además se muestra la parte del

paquete que puede ser encriptada y la parte del paquete que

puede ser autenticada.

141

Cabecera IPoriginal

CabeceraESP

Cabecera deprotocolo superior

Cabecera deprotocolo superior

Datos de capa superior

Datos de capa superior

Carga útil

Cabecera IPoriginal

Encriptado

TrailerESP

AutenticaciónESP

Autenticado

Figura 5.22 Modo transporte ESP

5.3.3.2. Modo Túnel

En modo túnel, 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 autenticación ESP

son añadidos al final del mismo. Si el túnel 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 túnel se encuentra establecido entre dos gateways de

seguridad, las direcciones en la nueva cabecera IP serán las

direcciones de los gateways. Ejecutando ESP en modo túnel entre

gateways de seguridad se puede lograr tanto confidencialidad como

autenticación del tráfico en tránsito entre los dos gateways

Cabecera IPoriginal

Cabecera deprotocolo superior

Cabecera deprotocolo superior

Datos de capa superior

Datos de capa superior

Carga útil

Cabecera IPoriginal

Encriptado

TrailerESP

AutenticaciónESP

Autenticado

CabeceraESP

NuevaCabecera IP

Figura 5.23 Modo túnel ESP

142

5.3.4. INTERNET KEY EXCHANGE - IKE

Los protocolos ESP y AH no explican cómo las asociaciones de

seguridad son negociadas, simplemente se refiere a cómo 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 dinámicamente por

medio de un protocolo de manejo de llaves tal como IKE.

Este último tipo de negociación es muy importante debido a que en

una comunicación 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 razón importante para usar

negociación dinámicas 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 algún atacante rompa los códigos de seguridad. Para

eliminar este riesgo, las SAs se renegocian periódicamente

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 métodos 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 comunicación 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 más

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.

CabeceraUDP

ISAKMPCarga Útil 1

ISAKMPCarga Útil 2

ISAKMPCarga Útil n

CabeceraISAKMP

Initiator Cookie (8 bytes)Responder Cookie (8 bytes)

...

Message LengthMessage ID

Next Payload Major Version Next Payload Exchange Type 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 esta

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 dígito de una versión de

protocolo ISAKMP. Tiene valor de 1 cuando el protocolo ISAKMP

con el cual se trabaja cumple con todas las características

descritas en la RFC2408, y valor 0 cuando se trabaja con

ISAKMP descrito en RFCs con fechas anteriores.

Minor Versión: Indica el segundo dígito de una versión de

protocolo ISAKMP. Tiene valor de 0 cuando el protocolo ISAKMP

144

con el cual se trabaja cumple con todas las características

descritas en la RFC2408, y valor 1 cuando se trabaja con

ISAKMP descrito en RFCs con fechas anteriores. Por norma, un

peer no debería aceptar paquetes con una Minor Versión mayor

a la que el propio peer maneja.

Exchange Type: Indica el tipo de intercambio que esta siendo

usando en la negociación del canal seguro, principal, agresivo o

rápido. Este campo es importante porque le indica a cada

entidad qué mensaje tiene que esperar a continuación.

Flags: Es un campo de 8 bits pero en la actualidad solo se usan

los 3 primeros bits más 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 señal 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 información 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 transmisión debidas a redes no confiables, y así evitar

múltiples retransmisiones.

145

Authentication Flag: Este bit se usa para indicar a las

partes que a la información util de los paquetes se les

tiene que aplicar técnicas 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 negociación 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 tamaño total del mensaje ISAKMP.

Hay dos fases en la negociación ISAKMP de una asociación de

seguridad. La primera fase es la negociación entre los dos nodos

ISAKMP. En esta fase dos nodos se ponen de acuerdo en la forma de

proteger las comunicaciones que se establecerán luego entre ellos, se

puede decir que en esta fase se crea una asociación 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 tráfico 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 número de negociaciones. Lo anterior sucede en

146

aplicaciones IPSec LAN-to-LAN donde un gateway de seguridad actúa

como un nodo ISAKMP en nombre de los hosts que él protege.

5.3.4.1. Fase 1 IKE

IKE define dos modos de negociación 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 múltiples 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

envía sus parámetros de intercambio de llaves y un número

aleatorio llamado nonce; el uso de los nonces tiene como objetivo

proteger a la negociación contra ataques de repetición. En el tercer

paso, toda la información que se intercambia es autenticada

usando uno de los siguientes tres mecanismos de autenticación:

secreto compartido, firmas digitales o cifrado de llaves públicas19.

Identificador, información deautenticación

Nodo ISAKMP queinicia

Nodo ISAKMP queresponde

Ofrecimiento de potenciales SAs

SA propuesta aceptada

Información para intercambio dellaves y Nonce

Paso 1

Paso 2

Paso 3

Información para intercambio dellaves y Nonce

Identificador, información deautenticación

Figura 5.25 Intercambio de mensajes en la fase 1 IKE usando modo principal19 Información sobre estos mecanismos de autenticación se ha tratado en el capítulo 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 autenticación entre el

iniciador y su corresponsal es llevada a cabo usando la firma digital

de las entidades de negociación. Los dos nodos intercambian sus

identidades, los valores de sus llaves públicas y las SAs propuestas

usando mensajes hash firmados digitalmente. Con el tercer

mecanismo, el de cifrado de llaves públicas, los dos nodos

intercambian sus IDs y nonces de manera encriptada usando sus

llaves públicas.

En el modo agresivo, la SA propuesta, los parámetros de

intercambio de llaves, el nonce y la información de su identidad,

son intercambiadas todas en un único mensaje, tal como se

muestra en la figura 5.26. Adicionalmente, la información de

autenticación intercambiada no va encriptada.

Ofrecimiento de potenciales SAs,información de intercambio dellaves, Nonce e identificador

SA propuesta aceptada,información de intercambio dellaves, Nonce e identificador

Autenticador

Nodo ISAKMP queinicia

Nodo ISAKMP queresponde

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

Una vez se completa la negociación 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 negociación que se realiza en

esta fase es mas rápida dado que el canal ya se ha asegurado, de

aquí que el nombre que toma esta negociación es el de modo

rápido. Los mensajes que se intercambian en modo rápido son

mostrados en la figura 5.27.

Nodo ISAKMP queinicia

Nodo ISAKMP queresponde

Ofrecimiento de potenciales SAs,información de intercambio dellaves, Nonce e identificador SA propuesta aceptada,

información de intercambio dellaves, Nonce, identificador y

autenticador

Autenticador

Figura 5.27 Intercambio de mensajes en la fase 2 IKE usando modo rápido

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 más

específicamente, de los selectores a ser usados en esta SA y que se

encuentra en la base de datos de políticas de seguridad que rige

esta comunicación.

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 aún si la fase 1

ha desaparecido.

149

5.3.4.3. Generación de Llaves en IKE

Las llaves son generadas una vez los parámetros necesarios se

encuentran en los nodos ISAKMP.

El algoritmo Diffie-Hellman juega un papel vital en la generación de

llaves en IKE. Como se trato en el capítulo 4, el algoritmo Diffie-

Hellman permite que dos partes generen una llave secreta a partir

de parámetros públicos, de tal manera que una tercera entidad que

tenga la intención de obtener la llave secreta “escuchando” la

comunicación 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 tecnología que modifica el reenvío tradicional de

paquetes que analiza la dirección 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 análisis tradicional para el reenvío de un

paquete IP cada proceso de estos es realizado en cada punto de la red. Los

protocolos de enrutamiento dinámicos o estáticos construyen una base de

datos necesaria, la cual se analiza para tomar una decisión hacia donde va el

paquete IP según dirección de destino, dicha tabla se conoce como tabla de

enrutamiento.

El reenvío tradicional de paquetes que realiza la capa de red, confía en la

información que le proveen los protocolos de enrutamiento tales como OSPF

(Open Shortest Path First) o BGP (Border Gateway Protocol) o a las rutas

estáticas configuradas en cada router, para tomar la decisión de reenvío entre

los mismos. Es decir, que la decisión de reenvío está basada única y

exclusivamente en la dirección IP de destino. Todos los paquetes para el

mismo destino siguen el mismo camino a través 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 podrían tomar uno solo o ambos, trayendo

como consecuencia una degradación 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 información de enrutamiento y de la

conmutación 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-a-

punto o redes de área local. También pueden ser conectados a través de

switches LAN o WAN. Esos switches LAN o WAN de Capa 2 no tienen la

capacidad de mantener la información de enrutamiento de Capa 3 o de

seleccionar el camino que debería de tomar un paquete partiendo del análisis

de su dirección de destino Capa 3. Es decir, los switches de Capa 2 no se

pueden involucrar en el proceso de reenvío de paquetes a nivel de Capa 3.

En el caso de una red WAN el diseñador de la red tiene entonces que

establecer trayectos a nivel 2 manualmente a través de toda la red WAN. Por

esos trayectos o paths es por donde los enrutadores que están conectados

físicamente a la Capa 2, reenvían 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 mayoría de redes WAN es

llamado un circuito virtual y que se establece únicamente por medio de una

configuración manual. Cualquier dispositivo de enrutamiento que se

encuentre conectado en los límites 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 conexión directa a través 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 Medellín, todos los

paquetes enviados desde Cali hasta Medellín, deben ser enviados hacia el

router de Bogotá, donde ellos son analizados y enviados a través de su

conexión ATM existente hasta Medellín. 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

PVC ATM

Router de coreCali

Router de coreBogotá

Router de coreMedellín

Switch ATMCali

Switch ATMMedellín

Switch ATMBogotá

Backbone ATM

Figura 5.28 Red IP basada en un backbone ATM

Si se quisiera implementar de mejor manera el reenvío de paquetes en la red

mostrada en la figura 5.28, debería existir un circuito virtual ATM entre cada

uno de los enrutadores que la componen, esto es, un VC entre Cali y

Medellín, un VC entre Cali y Bogotá y un VC entre Bogotá y Medellín. Esto se

torna fácil cuando la red es pequeña 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 creación y la

gestión 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 demás,

si se busca un enrutamiento óptimo.

153

En la mayoría 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

múltiples vecinos y a su vez, cantidades de tráfico 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 difícil predecir la cantidad

exacta de tráfico 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 tecnologías IP usando la

infraestructura WAN que ya tienen. También, algunos proveedores de

Internet se muestran interesados sobre alguna tecnología que les permita

garantizar una calidad en el servicio (QoS) como lo hacen los switches ATM.

Además el rápido crecimiento de ancho de banda ha acelerado la aparición de

interfaces ópticas en los enrutadores y que poco a poco pueden reemplazar a

tecnologías de alta velocidad como ATM.

5.4.1. DIFERENCIACIÓN DE PAQUETES POR SERVICIO

Como se dijo anteriormente, el reenvío de paquetes convencional usa

solamente la dirección IP de destino contenida dentro de la cabecera de

Capa 3 del paquete sobre el cual se esta tomando la decisión de reenvío.

154

En la figura 5.29, el enlace entre el router de Cali y el router de Bogotá,

transporta todo el tráfico 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 – Medellín – Bogotá, que pudiera estar no saturado.

POP Pereira

POP Armenia

POP Manizales

Router de coreCali

Router de coreMedellín

Router de coreBogotá

Enlace deCore

GatewayCartagena

Figura 5.29 Backbone IP sin políticas de control de tráfico

Aunque existen ciertas técnicas para modificar el enrutamiento, estas

tienen que ser desarrolladas en todos los enrutadores del backbone. Estas

técnicas llamadas PBR (Policy Based Routing) pueden reducir

considerablemente el desempeño 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 parámetros tales como la

ocupación de sus posibles enlaces para reenvío, tomar la decisión 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 sería, 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 reenvío de paquetes IP convencional, cualquier cambio en la

información que controla el reenvío 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

información es actualizada en toda la red.

De lo anterior es claramente deseable, un mecanismo que pudiera

cambiar el trayecto por el cual se reenvía un paquete sin afectar los

demás dispositivos que conforman la red. Para implementar este

mecanismo, los dispositivos de enrutamiento no deberían depender de la

información que se contiene en la cabecera IP, para lo cual se necesitaría

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 reenvío se basan entonces en etiquetas adjuntadas a los paquetes IP

originales, cualquier cambio en el proceso de decisión puede ser llevado a

cabo únicamente adjuntado nuevas etiquetas y así no se impactarían

ninguno de los otros dispositivos de enrutamiento que conforman la red.

5.4.3. PROPAGACIÓN DE INFORMACIÓN EXTRA DE

ENRUTAMIENTO

En una red que trabaja con el mecanismo de reenvío convencional de

paquetes, todos los dispositivos de enrutamiento, conocen la información

de enrutamiento para alcanzar determinado destino. Esto es necesario,

156

dado que cada paquete es enrutado basado en la dirección 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 Medellín y Cali tienen

que conocer información de enrutamiento para que los paquetes que

hacen tránsito entre los routers de Pereira, Armenia o Manizales a

Cartagena lleguen correctamente.

Este método tiene implicación de escalabilidad en términos de

propagación de rutas y de memoria y CPU utilizadas en los enrutadores

del backbone, teniendo en cuenta que la única acción que se necesitaría

sería 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 través de la red,

desde un router destino hasta un router final, sin analizar la dirección

destino sería un objetivo a perseguir.

5.4.4. QUE ES MPLS?

MPLS quiere decir Conmutación de Etiquetas Multiprotocolo (Multiprocol

Label Switching). Es una tecnología relativamente nueva que se desarrolló

para solucionar la mayoría de los problemas que existen en la técnica

actual de reenvío de paquetes. La IETF cuenta con un grupo de trabajo

MPLS que se ha unido esfuerzos en estandarizar esta tecnología.20 Según

aparece en el documento draft-ietf-mpls-framework, “el objetivo primario

de MPLS, es estandarizar una tecnología base que integre el intercambio

de etiquetas durante el reenvío con el sistema de enrutamiento actual de

20 Para mas información se puede consultar el sitio en Internet http://www.ietf.org/html.chapters/mpls-charter.html.

157

redes. Se espera que esta nueva tecnología mejore la relación

precio/desempeño 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 cómo se realiza la conmutación de

etiquetas, la cual combina los beneficios del reenvío 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 través de redes basadas en paquetes o en celdas.

Este mecanismo de reenvío a través de dichas redes es conocido como

intercambio de etiquetas (label swapping), lo cual permite que con una

etiqueta pequeña y de longitud fija que se añade al paquete original se

pueda enrutar dicho paquete a lo largo de un camino determinado que se

crea con la información 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 reenvío de paquetes usando MPLS se puede apreciar una diferencia

drástica con el reenvío 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 información de la

misma se toma una decisión conforme a la tabla de enrutamiento de cada

dispositivo de Capa 3.

La arquitectura MPLS se divide en dos componentes: el componente de

reenvío (también llamado data plane) y el componente de control

(también llamado control plane).

158

El componente de reenvío, 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 reenvío de etiquetas que

es mantenida por un switch de etiquetas (label switch). Haciendo la

analogía con el esquema tradicional de reenvío de paquetes, esta base de

datos es la tabla de enrutamiento.

El componente de control es el responsable de crear y mantener toda la

información de reenvío de etiquetas (también llamada Vínculos) entre un

grupo de switches de etiquetas interconectados. De nuevo, haciendo la

analogía 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 relación entre

cada uno de los bloques dentro del mismo nodo y también con nodos

adyacentes.

Protocolos de enrutamiento IP

Control de enrutamiento IPMPLS

Tabla de enrutamiento IP

Tabla de reenvíos de etiquetas

Com

pone

nte

de c

ontr

ol

Componente de datos

Paquetes etiquetadosentrantes

Paquetesetiquetados salientes

Vínculo de intercambio deetiquetas con otros routers

Intercambio de información deenrutamiento con otros routers

Figura 5.30. Arquitectura de un nodo MPLS

159

Como se observa en la Figura 5.30, cada nodo MPLS también es router IP

en el componente de control, ya que ejecuta uno o varios protocolos de

enrutamiento (o depende de rutas estáticas) para intercambiar

información 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 decisión de reenvío del

paquete.

En un nodo MPLS, la tabla de enrutamiento es usada para determinar el

intercambio de Vínculos de etiquetas, dicho intercambio es realizado por el

Protocolo de Distribución 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 Reenvío de Etiquetas o LFT

(Label Forwarding Table), la cual usa el componente de datos para

reenviar los paquetes etiquetados a través de la red MPLS.

5.4.5. COMPONENTES DE UNA RED MPLS

Se le llaman Enrutadores de Conmutación de Etiquetas o LSR (Label

Switch Router) a cualquier dispositivo que esté involucrado en el proceso

de distribución de etiquetas y que pueda reenviar paquetes. La función

básica del proceso de distribución de etiquetas es poder permitirle a cada

LSR que distribuya sus vínculos 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 desempeña, entre ellos están 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 imposición o la remoción de las

etiquetas en los limites de la red MPLS. La labor de imposición consiste en

añadir al paquete original una etiqueta o un conjunto de etiquetas en el

punto de ingreso a la red (en el sentido fuente-destino). La función de

extracción 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 reenvío 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 asignación de etiquetas en

el componente de control, y reenvío de paquetes de datos usando los

mecanismos de conmutación de paquetes propios de ATM, para esto usa

su matriz de conmutación ATM como su LFT.21

21 Un switch ATM tradicional puede ser convertido en un ATM-LSR por medio de una actualización desoftware de su componente de control.

161

5.4.6. MECANISMO DE IMPOSICIÓN DE ETIQUETAS EN

MPLS

Como se dijo anteriormente, la imposición de etiquetas en MPLS es la

acción de añadir una etiqueta a un paquete cuando éste entra a un

dominio MPLS. Esta función se realiza siempre en los límites de la red

MPLS y es ejecutada por un Edge-LSR.

En el reenvío tradicional de paquetes IP, cada salto en la red realiza una

consulta en la tabla de reenvío IP, y con base en la dirección destino que

se encuentra en la cabecera de red, selecciona el siguiente salto y reenvía

el paquete hacia éste. Esta iteración 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 combinación de dos

funciones. La primera función 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

función asocia a cada grupo de paquetes creado en el primer paso a una

dirección IP que es su siguiente salto.

Dentro de la arquitectura MPLS, el resultado de la primera función, 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 reenvío 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 tamaño 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 reenvía al siguiente

salto dependiendo de la información que aparece en LFT. Es muy

importante anotar, que este análisis se realiza primero que el de Capa 3,

por tanto el proceso de toma de decisión a nivel 3 no se realiza.

5.4.7. REENVIO DE PAQUETES MPLS

Los paquetes MPLS entran a la red a través de un LRS de entrada (ingress

LSR) y salen de ella a través 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 información que se toma de

una FEC.

Un LSP trabaja en un esquema orientado a conexión, es decir, que el path

tiene que ser formado antes de que cualquier flujo de tráfico 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 continúa hasta que el último LSR ha

sido alcanzado.

Cada LSR mantiene dos tablas que soportan toda la información relevante

al componente de reenvío 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

algún LSR vecino. Las correspondencias de estas etiquetas son

distribuidas por medio de protocolos para este uso específico.

La segunda tabla conocida como LFIB (Label Forwarding Information

Base) y en la cual son mantenidos únicamente las etiquetas que están

siendo actualmente usadas por el componente de reenvío. Las LFIB son el

equivalente MPLS de una matriz de conmutación en un switch ATM.

La gráfica 5.31 muestra como actúa el mecanismo de reenvío 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.

POP Pereira

POP Armenia

POP Manizales

Router de coreCali

Router de coreMedellín

Router de coreBogotá

Paso 1- Paquete IP ingresandoal router de Pereira Paso 2 - El router de Pereira

examina a nivel 3 el paquete,añade una etiqueta y reenvía elpaquete hacia el router de Cali Paso 4 - El router de Bogotá

examina la etiqueta, la renueva yreenvia el paquete hacia el gateway

de Cartagena.

Paso 3 - El router de Cali examina laetiqueta, la renueva y reenvia el paquete

hacia el router de Bogotá.

Paso 5 - El gateway de Cartagenaexamina la etiqueta, la retira, analizaa nivel 3 el paquete y lo reenvía haciaun router por fuera del dominio MPLS

Paquete IP

Paquete IPPaquete IP L1

Paquete IP L2Paquete IP L3

GatewayCartagena

Figura 5.31 Mecanismos de imposición y de extracción de etiquetas MPLS

y reenvío 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

Topología: Acceso Remoto

Tecnología 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 genérico Celeron 1.0GHz, 192MB, 40GB, con

Windows XP Home Edition, actuando como cliente PPTP nativo.

6.1.1. ESCENARIO MONTADO

INTERNETUsuario remoto con

cliente PPTP

Estacion de Trabajo

ISPISP

EnlaceDedicado

Enlace PPP Servidor PPTP

TUNEL PPTP A TRAVES DE INTERNET

66.128.33.25

192.168.200.1

192.168.200.21IP dinamica asignadapor la ISP

IP dinamica asignada porel servidor DHCP

de la LAN Corporativa

Servidor DHCPServidor de Dominio Microsoft

LAN corporativa

166

6.1.2. INSTALACIÓN Y CONFIGURACIÓN DEL SERVIDOR

PPTP

La configuración 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 básica de cómo

instalar y configurar un servidor de dominio principal bajo

Windows2000 por favor remitirse a la siguiente dirección 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 túneles bajo Windows2000 está incluido como

una característica 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 opción Configure and Enable Routing

and Remote Access

167

Luego aparece una ventana titulada Routing and Remote Access

Server Setup Wizard. Clic en Next.

A continuación aparece las posibles opciones de configuración que

vienen con el Wizard del RRAS. Microsoft ha encontrado bugs en este

168

Wizard22, por lo cual han recomendado escoger la opción Manually

configured server y luego dar clic en Next:

Luego aparece la ventana de finalización del Wizard para comenzar

ahora la configuración manual del RRAS.

22 Este problema ha sido documentado en el artículo Q243374 del Microsoft Knowledge Base.

169

Para comenzar con la configuración 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 opción Properties (Propiedades), se escoge la

pestaña IP y se verifica que las opciones Enable IP routing y Allow

IP-Based remote access and demand-dial connections estén

habilitadas:

170

El RRAS puede asignar direcciones IP a los clientes remotos (dial-up y

VPN) de un pool estático propio de este o del pool del servidor DHCP

que está corriendo.23

Es necesario además escoger la interfaz de red por la cual el RRAS

obtiene la dirección 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 configuración 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 pestaña Event

Logging y seleccionar Log the maximum amount of information.

23 Una guia paso a paso para instalar el servicio DHCP en un servidor Windows2000 puede ser encontradaen la siguiente dirección URL http://support.microsoft.com/default.aspx?scid=kb;en-us;300429

171

A continuación se procede a configurar los puertos PPTP. Para esto se

selecciona la opción 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 opción Demand-dial routing

connections (inbound and outbound) no se selecciona. Se

asegura que la opción Remote access connections (inbound

only) sí aparezca seleccionada y se configura el numero máximo de

puertos PPTP que se quieren activar, esto es, el número máximo de

túneles simultáneos que el servidor PPTP podrá soportar (el máximo es

254). Por ultimo clic en OK.

173

Dado que no se están implementando túneles usando L2TP, se

selecciona WAN Miniport (L2TP) y se configura cero como numero

máximo de puertos, por ultimo clic en OK.

A continuación aparece una ventana de advertencia informando que

configurar el cambio en el máximo numero de puertos traerá como

consecuencia la desconexión de conexiones activas si el nuevo número

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 implementación se configuraron solo 5 puertos PPTP.

Por último, se procede a configurar la opción de registro de logs, para

lo cual se selecciona la opción Remote Access Logging, y en el

panel de la derecha se da clic derecho en LocalFile y se selecciona la

opción de Properties (Propiedades):

175

Se despliega un cuadro de dialogo titulado Local File Properties, se

asegura que esté habilitada la opción Log authentication requests

y se da clic en OK. Opcionalmente, seleccionando la pestaña 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. INSTALACIÓN Y CONFIGURACIÓN 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 prácticos, considerando que hoy en día

XP y 2000 representan mayoría respecto a Windows98, se detalla el

procedimiento de instalacion y configuración en un cliente PPTP

remoto en Windows XP Home Edition.

Para crear una nueva conexión 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 diálogo que se despliega, damos clic en:

Archivo | Nueva conexión

177

Luego se despliega el cuadro de diálogo para iniciar el Wizard que crea

la nueva conexión de tipo VPN:

Se da clic en Siguiente, y a continuación se despliega una ventana

donde se escoge el tipo de conexión nueva que se quiere crear, en

nuestro caso Conectarse a la red de mi lugar de trabajo (que

hace alusión a una red privada virtual).

178

Se da clic en Siguiente y aparece una ventana donde se selecciona

Conexión de red privada virtual, y se da clic en Siguiente:

Aparece una ventana donde se escribe un nombre que identifique la

red (compañía) remota a la que se quiere acceder por medio la VPN,

en nuestro caso usamos e-net como nombre de una compañía ficticia,

y se da clic en Siguiente.

179

A continuación aparece un cuadro donde Windows le pregunta al

usuario si quiere ejecutar una conexión telefónica antes de lanzar la

conexión PPTP. En nuestro caso escogemos No usar la conexión

inicial, ya que la primera conexión (PPP) se hara manualmente.

Luego aparece un cuadro donde se digita el nombre o el IP del

servidor PPTP de la compañía 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 conexión VPN

recien creada:

181

Antes de lanzar la conexión PPTP, se tienen que configurar ciertos

parámetros que el Wizard deja por defecto, tales como la asignación

del gateway y del servidor WINS.

Para que el PC que se va a conectar a la VPN no pierda su conexión 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

conexión PPP y la de la conexión PPTP.

Para realizar este cambio, se da clic derecho en la conexión PPTP

recien creada (en este caso E-net) y se selecciona Propiedades,

luego se selecciona la pestaña Funciones de red y aparece el

siguiente cuadro:

182

En el Tipo de red privada virtual (VPN) se puede dejar en Automático 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 configuración por defecto, es decir que la direccion IP y los

servidores DNS sean asignados dinámicamente. Se da clic en

Opciones Avanzadas, y aparece una ventana con tres pestañas:

General, DNS y WINS.

En General se desactiva la opción Usar la puerta de enlace

predeterminada en la red remota:

Luego se escoge la pestaña WINS y se adiciona manualmente el IP

del servidor WINS, en este caso es el mismo IP del servidor de

dominio el cual también 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 telefónico o

estando en una LAN, se da doble clic en el ícono E-net, y a

continuación aparece un cuadro de diálogo con el nombre de usuario y

la contraseña 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

conexión 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

Topología: LAN-to-LAN

Tecnología 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

estación de trabajo en la LAN corporativa Sitio1.

- Un computador genérico Celeron 1.0GHz, 192MB, 40GB, actuando

como estación de trabajo en la LAN corporativa Sitio2.

6.2.1. ESCENARIO MONTADO

Estac ionde T rabajo

192.168.200.1192.168.200.2

Si tio1INTERNET

Estac ionde Trabajo

ISPISP

Enlace PPP

TUNEL IPSEC A TRAVES DE INTERNET

192.168.100.1

192.168.100.2

Si tio2

Enlace PPP

66.128.33.136 66.128.33.154

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 dirección de la red es 192.168.200.0 con

máscara 255.255.255.0, y en Sitio2 la dirección de la red es

192.168.100.0 con máscara de 254 hosts también.

El gateway en Sitio1, es decir el router Cisco1760 tiene como dirección

IP 192.168.200.1, y en Sitio2, el gateway tiene como dirección IP

187

192.168.100.1. Las estaciones de trabajo con las que cuenta cada red

están conectadas back-to-back por medio de un cable cross over a la

interfaz FastEthernet de cada router. En sitio1, la dirección IP de la

estación de trabajo es 192.168.200.2/24 y en sitio2, la dirección 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 configuración de los routers se dividió en dos etapas: la conexión a

Internet de cada LAN y posteriormente el establecimiento de la VPN

IPSec entre las dos LANs.

La conexión 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. También se

configuró el protocolo NAT24 para proveer de Internet a toda la red

corporativa.

Una vez se finalizó la conexión a Internet en ambos routers, se

realizaron pruebas de navegación desde las estaciones de trabajo que

estaban detrás de cada uno de ellos y se verificó que desde cada

router se alcanzara al otro.

Después de la anterior verificación, se procedió a configurar cada end-

point del tunel IPSec.

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

188

La configuración de cada gateway IPSec se hace de la siguiente

manera:

Sitio1:

sitio1#sh runBuilding configuration...

Current configuration : 1805 bytes!version 12.2service timestamps debug uptimeservice timestamps log uptimeservice password-encryption!hostname sitio1 #Nombre del router!enable secret 5 $1$THDB$2VXKI4Xgz66uiO2b3QC061enable password 7 121A0C041104!username HiPer #Clave compartida del RAS, necesaria para el handshake PAPip subnet-zero!!ip name-server 66.128.32.70 #Servidor DNS de la ISPip 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 #Creación de la politica IKE (definición del intercambio de

#llaves)

189

authentication pre-share #Se define el metodo de autenticación 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 encripción # (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

#Le indica al protocolo NAT #que solo podra trasladar las#direcciones IP relacionadas en la lista de acceso 122

ip classlessip route 0.0.0.0 0.0.0.0 BRI0/0no ip http server!!access-list 101 permit ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255access-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.255access-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 0line aux 0line vty 0 4 access-class 10 in password 7 14141B180F0B loginline vty 5 15 password 7 11291A550502345A506B79 login!no scheduler allocateend

Sitio2:

sitio2#sh runBuilding configuration...

Current configuration : 1767 bytes

191

!version 12.2service timestamps debug uptimeservice timestamps log uptimeservice password-encryption!hostname sitio2!enable secret 5 $1$0TKt$xGRS7GEE/hMCR4U6PuL8C/enable password 7 070C285F4D06!username HiPerip subnet-zero!!ip name-server 66.128.32.70ip name-server 66.128.32.68!!isdn switch-type basic-net3! voice call carrier capacity active!!!!!!!!!!crypto isakmp policy 10 authentication pre-sharecrypto 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 overloadip classlessip route 0.0.0.0 0.0.0.0 BRI0/0no ip http server!!access-list 101 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255access-list 175 deny ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255access-list 175 permit ip 192.168.100.0 0.0.0.255 anydialer-list 1 protocol ip permit!call rsvp-sync!dial-peer cor custom!!!!line con 0line aux 0line vty 0 4 password 7 14141B180F0B login

193

line vty 5 15 password 7 094F471A1A0A login!no scheduler allocateend

Luego se realizaron pruebas de conectividad desde cada estación de

trabajo que consistían en alcanzar a la otra por medio del comando

ping y luego ver los recursos compartidos que la otra provee. En la

siguiente gráfica 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 estación de

trabajo que esta detrás del gateway remoto (192.168.200.2).

194

La siguiente gráfica 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

Topología: LAN-to-LAN

Tecnología de túnel: 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

192.168.200.1

192.168.200.2

sitio1(Left)

192.168.200.0/24

INTERNET

ISPISP

Enlace Ethernet

TUNEL IPSEC A TRAVES DE INTERNET

192.168.100.1192.168.100.2

Sitio2(Right)

192.168.100.0/24Enlace Ethernet66.128.47.2 66.128.32.207

julrodrig berkeley66.128.47.166.128.32.193

6.3.2. INSTALACION Y CONFIGURACION

FreeS/WAN25 es una implementación Linux del protocolo IPSec que

brinda servicios de cifrado y autenticación a conexiones IP. En este

escenario se instaló la versión estable mas reciente de FreeS/WAN, la

2.0.

25 El sitio oficial de este aplicación IPSec para Linux es http://www.freeswan.org

197

FreeS/WAN convierte una máquina Linux en un gateway seguro IPSec,

permitiendo implementar topologías 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 comunicación a ataques del tipo hombre-en-el-

medio, FreeS/WAN maneja dos tipos de autenticación para sus

túneles:

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 comunicación 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 automáticamente de una manera

periódica. Obviamente, este método de autenticación es mucho

mas seguro, ya que si un intruso obtiene la llave, solo los

mensajes entre la renegociación anterior y la siguiente seran

expuestos.

Las fuentes de FreeS/WAN se pueden obtener de la siguiente

dirección:

ftp://ftp.xs4all.nl/pub/crypto/freeswan/

Si la distribución es RedHat, se pueden descargar los RPMs de la

siguiente dirección:

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 RPM27 (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 también 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 máquina. Para proceder con la instalación se ejecuta el comando:

rpm -ivh freeswan*.rpm

Una vez finalizada la instalación, se inicia el servicio con el comando:

service ipsec start

y para probar la instalación se ejecuta el comando

ipsec verify

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

199

La salida deberá ser OK para al menos las 4 primeras lineas, asi:Checking your system to see if IPsec got installed and startedcorrectlyVersion 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 instalación del paquete, se procede

a la configuración de los archivos /etc/ipsec.conf y /etc/ipsec.secrets.

Hay que aclarar que cada gateway debe tener un IP estático 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 público 66.128.47.2 es el left y el gateway IPSec

con IP público 66.128.32.207 es el right. Lo importante es ser

congruente con esta nomenclatura a lo largo del proceso de

configuración 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 sección puede aparecer

una llamada conn %default que es donde se definen las características

que se aplican por defecto a cada pareja de gateways IPSec.

La parte más importante del archivo /etc/ipsec.conf es la que define

cada conexión IPSec, de hecho todas las opciones en la sección config

200

setup son opcionales. Los campos básicos que define cada pareja IPSec

son:

left=leftsubnet=leftnexthop=leftrsasigkey=right=rightsubnet=rightnexthop=rightrsasigkey=auto=

Los campos left y right son las direcciones IP públicas de cada

gateway.

Los campos leftsubnet y rightsubnet son las subredes que se encuentran

detrás de cada gateway (la red privada).

Los campos leftnexthop y rightnexthop son las direcciones IP del equipo

que recibe la conexión en el ISP. Es la puerta de enlace de cada

máquina Linux.

Los campos leftrsasigkey y rigthrsasigkey son las llaves públicas de cada

gateway IPSec, y se obtienen con los comandos:

ipsec showhostkey --left (para la máquina llamada left), y

ipsec showhostkey --right (para la máquina 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

implementación realizada fueron:

28 Para información más detallada de cada uno de los campos que conforman un archivo ipsec.conf puederevisarse este sitio: http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/manpage.d/ipsec.conf.5.html

201

[root@berkeley root]# more /etc/ipsec.confversion 2.0config setup klipsdebug=all plutodebug=dnsconn %default

keyingtries=0spi=0x200esp=3des-md5-96espenckey=0x01234567_89abcdef_02468ace_13579bdf_12345678_9abcdef0espauthkey=0x12345678_9abcdef0_2468ace0_13579bdfkeylife=8h

conn berkeley-to-julrodrigleft=66.128.47.2leftsubnet=192.168.0.0/24leftnexthop=66.128.47.1

leftrsasigkey=0sAQOHbmJjlOUboH6IEm9alDzc7fvV0xxGCZV2iNrOJ4yUfSok2Plvw8fCAERzZcmOy53tE1E71Qkuz6qVZpsFbW0GfyEiJyws9/gSD3khJtLK2/3tQxkOGN+d1vJYQdlbpf0+EMCX8HSp/9sCR86G7wuMYTbNtuRh1Sl6GTDGfuJ2Xn/lULIOOX1DmtdNzdFPrvKpC3bQWocE3MumV96Bkumutm49UhLiOa3FGn0699HbcJLh1glMoOb+EJ8in8glfTTDU4adbq5Z0wvnOlAc46gAkWLffOeeWgUQtT/KA4wVLp5RYqXgX43ytSPF5oMLsXApVcTuClbXg+u+ctfEcbfCkNRr8Fvk0C1KgDicq4/LN2P9

right=66.128.32.207rightsubnet=192.168.100.0/24rightnexthop=66.128.32.193

rightrsasigkey=0sAQNj25OiRTaMkDn1S/SdzXeRD0zQfXUPnsBQaXDtkvqTcCVaefJ5DUGZM8Nli796pDvsP0W9OMis25so1whsYygkzYsacrZIlwyr+GvRDIf8xarV2YqvGDs0wvyk22891h4twzGD9yfFwgfUBEysMmGpJnGrNxFEL9TDggp9A3UeCBx+qgYv9CCWjgPXYfzKomP3tHtiB7gUTgIBlpxTva1Gs4rM9IJIUUNBwfpuNDglD23KMibWBQn1YTPsJ9mQccIBaHao43EkM2BHRG6KbNYGD8GQ7DGbd95QLXzjdASeCc0t9TrtOI7cwxGxs6LF3NQRZrCKH1sE1OsTIkacYHxIOQ/dN53CpPMKhNQR4tl7Jm8t

auto=start

root@julrodrig:~# more /etc/ipsec.confversion 2.0config setup klipsdebug=all plutodebug=dnsconn %default keyingtries=0 spi=0x200 esp=3des-md5-96espenckey=0x01234567_89abcdef_02468ace_13579bdf_12345678_9abcdef0 espauthkey=0x12345678_9abcdef0_2468ace0_13579bdf keylife=8h

conn berkeley-to-julrodrigleft=66.128.47.2leftsubnet=192.168.0.0/24leftnexthop=66.128.47.1

leftrsasigkey=0sAQOHbmJjlOUboH6IEm9alDzc7fvV0xxGCZV2iNrOJ4yUfSok2Plvw8fCAERzZcmOy53tE1E71Qkuz6qVZpsFbW0GfyEiJyws9/gSD3khJtLK2/3tQxkOGN+d1vJYQdlbpf0+EMCX8HSp/9sCR86G7wuMYTbNtuRh1Sl6GTDGfuJ2Xn/lULIOOX1DmtdNzdFPrvKpC3bQWocE3MumV96Bkumutm49UhLiOa3FGn0699HbcJLh1glMoOb+EJ8in8glfTTDU4adbq5Z0wvnOlAc46gAkWLffOeeWgUQtT/KA4wVLp5RYqXgX43ytSPF5oMLsXApVcTuClbXg+u+ctfEcbfCkNRr8Fvk0C1KgDicq4/LN2P9

right=66.128.32.207rightsubnet=192.168.100.0/24rightnexthop=66.128.32.193

rightrsasigkey=0sAQNj25OiRTaMkDn1S/SdzXeRD0zQfXUPnsBQaXDtkvqTcCVaefJ5DUGZM8Nli796pDvsP0W9OMis25so1whsYygkzYsacrZIlwyr+GvRDIf8xarV2YqvGDs0wvyk22891h4twzGD9yfFwgfUBEysMmGpJnGrNxFEL9TDggp9A3UeCBx+qgYv9CCWjgPXYfzKomP3tHtiB7gUTgIBlpxTva1Gs4rM9IJIUUNBwfpuNDglD23KMibWBQn1YTPsJ9mQccIBaHao43EkM2BHRG6KbNYGD8GQ7DGbd95QLXzjdASeCc0t9TrtOI7cwxGxs6LF3NQRZrCKH1sE1OsTIkacYHxIOQ/dN53CpPMKhNQR4tl7Jm8t

auto=start

202

Es necesario agregar la línea versión 2.0 en el inicio de cada archivo. La

línea auto=start hace que el túnel se establezca durante el proceso de

boot de la máquina. Inicialmente, para propósitos de troubleshooting ,

se recomienda que la linea auto tenga el valor de add, lo cual obliga a

que cada vez el administrador inicie el túnel 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 túnel se establezca

automáticamente cada vez que la máquina reinicia.

El comando para establecer el túnel de manera manual es:

ipsec auto --up berkeley-to-julrodrig

donde berkeley-to-julrodrig es el nombre dado a la pareja IPSec en elarchivo /etc/ipsec.conf, y auto indica que las llaves se negocian deforma automática (no manual). No es necesario ejecutar este comandoen las dos maquinas, en una es suficiente.

La salida de este comando deberá mostrar algo como:

root@julrodrig:~# ipsec auto --up berkeley-to-julrodrig104 "berkeley-to-julrodrig" #1: STATE_MAIN_I1: initiate106 "berkeley-to-julrodrig" #1: STATE_MAIN_I2: sent MI2, expecting MR2108 "berkeley-to-julrodrig" #1: STATE_MAIN_I3: sent MI3, expecting MR3004 "berkeley-to-julrodrig" #1: STATE_MAIN_I4: ISAKMP SA established112 "berkeley-to-julrodrig" #2: STATE_QUICK_I1: initiate004 "berkeley-to-julrodrig" #2: STATE_QUICK_I2: sent QI2, IPsec SA established

Es de vital importancia la configuración 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 -s192.168.100.0/24 -d \! 192.168.0.0/24 -j MASQUERADE

Para julrodrig:root@julrodrig:~# iptables -t nat -A POSTROUTING -o eth0 -s192.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 verifyChecking your system to see if IPsec got installed and started correctlyVersion 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 verifyChecking your system to see if IPsec got installed and started correctlyVersion 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 atención a la última línea 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 más información sobre las asociaciones de

seguridad que están establecidas en un gateway IPSec es:

ipsec look

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

root@berkeley root]# ipsec lookberkeley.telesat.com.co Mon Jun 30 20:47:58 COT 20030.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.2esp0x46cb35cb@66.128.47.2 (0)192.168.100.2/32 -> 200.14.106.59/32 => %pass (804)ipsec0->eth1 mtu=16260(1500)->1500esp0x29db1619@66.128.32.207 ESP_3DES_HMAC_MD5: dir=in src=66.128.47.2iv_bits=64bits iv=0xe6f70c7c992b16be ooowin=64 alen=128 aklen=128eklen=192 life(c,s,h)=addtime(167,0,0) refcount=4 ref=32 reftable=0refentry=32esp0x46cb35cb@66.128.47.2 ESP_3DES_HMAC_MD5: dir=out src=66.128.32.207iv_bits=64bits iv=0x07c405ba8997306e ooowin=64 alen=128 aklen=128eklen=192 life(c,s,h)=addtime(167,0,0) refcount=4 ref=37 reftable=0refentry=37tun0x1001@66.128.32.207 IPIP: dir=in src=66.128.47.2policy=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=33tun0x1002@66.128.47.2 IPIP: dir=out src=66.128.32.207life(c,s,h)=addtime(167,0,0) refcount=4 ref=38 reftable=0 refentry=38Destination Gateway Genmask Flags MSS Window irtt Iface0.0.0.0 66.128.32.193 0.0.0.0 UG 0 0 0 eth10.0.0.0 66.128.32.193 128.0.0.0 UG 0 0 0 ipsec0128.0.0.0 66.128.32.193 128.0.0.0 UG 0 0 0 ipsec0169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1192.168.0.0 66.128.32.193 255.255.255.0 UG 0 0 0 ipsec066.128.32.192 0.0.0.0 255.255.255.224 U 0 0 0 eth166.128.32.192 0.0.0.0 255.255.255.224 U 0 0 0 ipsec0

Dado que la implementación FreeS/WAN no permite realizar ping

desde los gateways IPSec hasta las máquinas de la red privada

remota, las pruebas de conectividad IP se tienen que realizar desde las

máquinas que se encuentran detrás 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 geográficas y acelerando la globalización del planeta

que se estaba gestando sobre todo en el aspecto comercial. Internet hizo

por ejemplo, relativamente fácil y muy económico 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 niño que acaba de nacer en Costa Rica.

¿Pero que tienen en común 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, más

velocidad (entendiéndose como ancho de banda) por menos precio.

Porque las empresas se dieron cuenta que por medio de Internet sus

trabajadores podrían acceder a sus redes corporativas desde casi

cualquier parte del mundo al costo de una llamada local. Porque se dieron

cuenta que podrían mejor los tiempos de entrega y los costos de sus

productos si mantenían su inventario en línea, realizando pedidos en

tiempo real a sus proveedores.

207

Pero Internet, mejor IPv4 (el protocolo que la soporta), no estaba

diseñado para soportar este tipo de conexiones que requerían un alto

nivel de seguridad y confidencialidad. Hasta que surgieron protocolos

como SSH (Secure Shell), SSL (Secure Socket Layer) y más recientemente

las Redes Privadas Virtuales sobre Internet, PPTP, L2TP e IPSec, que le

agregaron a IPv4 las características de seguridad que carecía 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 países

desarrollados, ha sido la cobertura que ha alcanzado Internet y la gran

disminución 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 años era

común que una mediana o gran empresa tuviera su propio RAS

corporativo para que sus empleados accedieran a la base de datos de la

compañía desde cualquier lugar del país 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 túneles 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 también todo el desgaste en tiempo y dinero que

la administración 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

compañía, también, las VPNs han puesto esta ventaja al alcance de las

208

PYMES que en Colombia representan la mayoría de los sectores

productivo y comercial.

En cuanto al escenario VPN LAN-to-LAN, las empresas colombianas

apenas desde el año 2002 empezaron a desarrollar este tipo de

soluciones. La razón fundamental, era el precio del acceso a Internet.

Pero el panorama es alentador si se tiene en cuenta que este ítem ha

tenido una disminución del 70% en apenas 4 años, al pasar de 11.000

dólares por E1 en 1999 a solo 3.300 dólares en 2003. Los pronósticos

indican que para el año 2004 un enlace con capacidad E1 a Internet

estaría costando 2.000 dólares, es decir una disminución del 40% en solo

un año. Esto sin lugar a dudas acelerará el desarrollo, no solo de las

VPNs, sino también de la Voz sobre IP y la videoconferencia corporativa.

Las VPNs están haciendo que los proveedores de transporte de datos

migren sus redes a un híbrido entre IP y las tecnologías tradicionales de

conmutación de paquetes. Por ejemplo, AT&T Latinoamérica, cuya red es

IP apoyada en la tecnología MPLS e Internexa (empresa de

telecomunicaciones de ISA) que esta implementando entregar los enlaces

de datos en tecnologías FastEthernet y Gibabit Ethernet. Sin lugar a

dudas, los ISPs están mejor parados que ninguna otra clase de empresa

de telecomunicaciones para explotar este mercado, pues conocen IP

desde hace ya varios años y tienen la infraestructura para, con una

mínima inversión, proveer este servicio sin mayores problemas.

Lo más probable es que en muy poco tiempo, 2 o 3 años, una empresa

tenga solamente un enlace a Internet de gran tamaño, que reemplace sus

enlaces de voz, datos y video. Con este solo enlace disfrutarán 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 móviles

209

desde cualquier parte del mundo con Acceso Remoto VPN, todo apoyado

en la seguridad que los mecanismos de cifrado y autenticación que las

VPNs ofrezcan.

Sin lugar a dudas, la llegada de ADSL a nuestro país, será fundamental

para que de una vez por todas muchas empresas que aún no han migrado

sus enlaces WAN a tecnologías VPN lo hagan. Porque técnicamente el

factor que más 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 tecnologías 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

tecnología siempre debute con altos precios pero la disminución 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 elección de la tecnología VPN en una implementación:

Los principales aspectos que se deben evaluar son:

o Se necesita acceso remoto y/o LAN-to-LAN? Cúal es el presupuesto?

Dependiendo de la respuesta se debe escoger qué tipo de

implementación realizar.

Si solo se necesita acceso remoto, el presupuesto es bajo y la

seguridad que se requiere es mínima lo recomendable es montar una

solución con un servidor PPTP bajo Windows NT Server, 2000 Server o

2003 Server. Ya que es muy sencilla, requiere poca administración, es

muy versátil dado que prácticamente todos los usuarios remotos

tendrán PCs con ambientes Windows. Si se necesita mayor seguridad,

bastaría con cambiar los tipos de puertos de PPTP a L2TP en el

servidor VPN y habilitar la opción 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 podría pensar en una

solución por hardware como routers o equipos diseñados para hacer

VPN como los de Netscreen. En LAN-to-LAN no se evalúa la seguridad

necesaria, ya que se asume que esta debe ser alta, y bajo ese

principio se parte.

o Cuantos usuarios remotos se atenderán? Con que frecuencia e

intervalos de tiempo?

Esta pregunta es necesaria para comparar qué tan rentable es

implementar una solución de acceso remoto VPN o seguir con el

acceso remoto tradicional. Si los usuarios remotos son pocos, se podría

habilitar el servicio de acceso remoto en un servidor Windows NT,

2000 o Linux y colocar un par de módems. 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 conexión de los

trabajadores remotos es de unos pocos minutos, así estén fuera de la

ciudad o incluso fuera del país, se deberá evaluar muy bien

económicamente ambos casos, es decir, VPN o el sistema tradicional.

El ejemplo de análisis económico que se presenta más adelante sirve

como pauta para escoger la opción más 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 ningún beneficio si se monta una solución de acceso

remoto VPN donde los empleados remotos no pueden acceder a

Internet. En este caso no queda otra opción que seguir bajo el sistema

de acceso remoto tradicional. De todas maneras es claro que Internet

211

ha tenido una penetración muy fuerte en todos los lugares lo que hace

pensar que este problema no sea significativo.

o Cuántos usuarios hay en cada red LAN remota? Qué tipo de

aplicaciones se manejarán 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

probabilísticas sobre el uso simultáneo de los túneles 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 solución,

que en muchos casos es un factor que influye mucho en la toma de

una decisión, sobre todo cuando se trata de una empresa pequeña que

no tiene los recursos para invertir en una solución dedicada a Internet.

En el montaje de una solución LAN-to-LAN lo más probable es que se

necesiten soluciones de banda ancha para conectar las oficinas a

Internet. Cuando el tráfico sea bajo o se esté montando una solución

de acceso remoto VPN puede ser suficiente una conexión conmutada

RDSI en el lado del servidor VPN.

o Qué tan confidencial y sensitiva es la información 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 desempeño del enlace de

manera dramática. Aquí también está involucrada la cantidad de tráfico

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 portátiles 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

compañía?

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

críticas, por ejemplo, un sistema de recaudo en línea, se tendrán 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 cláusulas de

cumplimiento a través de un SLA y garantizar calidad de servicio.

El siguiente ejemplo ilustra cómo una solución de acceso remoto y LAN-to-

LAN VPN es mucho más económica que un escenario de acceso remoto y

enlaces privados tradicionales.

Se parte de los siguientes supuestos:

o Se necesita montar una solución 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 país y en determinados

casos tienen que salir por fuera del país. 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 compañía. 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

distribución 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 lógica. Se

asume que la red LAN en cada sede ya está implementada con

switches FastEthernet de 48 puertos.

SOLUCION TRADICIONALTRM $2840

COSTO INICIALENLACES WAN Dólares PesosInstalación enlace 128K Cali-Bogota 750 $ 2.130.000,00 Instalación enlace 128K Cali-Medellín 750 $ 2.130.000,00 Instalación enlace 128K Bogota-Medellín 750 $ 2.130.000,00 Enrutador Cali Cisco3620 2800 $ 7.952.000,00 Enrutador Bogota Cisco3620 2800 $ 7.952.000,00 Enrutador Medellín Cisco3620 2800 $ 7.952.000,00

$ 30.246.000,00

ACCESO REMOTOTarjeta de 4 puertos RDSI BRI para Cisco3620 en Cali 1100 $ 3.124.000,00 Tarjeta de 4 puertos RDSI BRI para Cisco3620 en Bogota 1100 $ 3.124.000,00 Tarjeta de 4 puertos RDSI BRI para Cisco3620 en Medellín 1100 $ 3.124.000,00 Instalación 3 líneas RDSI BRI en Cali $ 2.400.000,00 Instalación 3 líneas RDSI BRI en Bogota $ 2.400.000,00 Instalación 3 líneas RDSI BRI en Medellín $ 2.400.000,00

$ 16.572.000,00

ACCESO A INTERNETInstalación 1 línea RDSI BRI en Cali $ 800.000,00 Instalación 1 línea RDSI BRI en Bogota $ 800.000,00 Instalación 1 línea RDSI BRI en Medellín $ 800.000,00

$ 2.400.000,00 TOTAL COSTO INICIAL $ 49.218.000,00

COSTO MENSUALENLACES WAN

214

Cargo fijo mensual enlace Cali-Bogota 128K 600 $ 1.704.000,00 Cargo fijo mensual enlace Cali-Medellín 128K 600 $ 1.704.000,00 Cargo fijo mensual enlace Bogota-Medellín 128K 600 $ 1.704.000,00

$ 5.112.000,00

ACCESO REMOTOLDN de 9 usuarios, durante 20 días hábiles, 3 horas por día $ 5.734.800,00 LDI de 1 usuario, durante 5 días, 1 hora por día (desdeUSA) $ 360.000,00 Cargo básico por 3 líneas RDSI BRI para Cali $ 120.000,00 Cargo básico por 3 líneas RDSI BRI para Bogota $ 120.000,00 Cargo básico por 3 líneas RDSI BRI para Medellín $ 120.000,00 La impulsación local de cada usuario no se tiene en cuenta $ -

$ 6.454.800,00

ACCESO A INTERNETCargo básico por 1 líneas RDSI BRI para Cali $ 40.000,00 Cargo básico por 1 líneas RDSI BRI para Bogota $ 40.000,00 Cargo básico por 1 líneas RDSI BRI para Medellín $ 40.000,00 Impulsación local a Internet 8 horas por un canal de 64KCali $ 64.000,00 Impulsación local a Internet 8 horas por un canal de 64KBogota $ 64.000,00 Impulsación local a Internet 8 horas por un canal de 64KMedellín $ 64.000,00 Acceso dedicado a Internet de 64K con reuso 1:1 para Cali 280 $ 795.200,00 Acceso dedicado a Internet de 64K con reuso 1:1 paraBogota 300 $ 852.000,00 Acceso dedicado a Internet de 64K con reuso 1:1 paraMedellín 300 $ 852.000,00

$ 2.811.200,00 TOTAL COSTO MENSUAL $ 14.378.000,00

215

Empleado en el exterioraccediendo indistamente a cualquiera

de los RAS corporativos

9 Empleados a nivel nacionalaccediendo indistintamente a

cualquier RAS corporativo

CALI BOGOTA

MEDELLIN

Usuarios remotosCali

Usuarios remotosMedellin

Usuarios remotosBogota

Internet Internet

Internet

128Kbps

128Kbps 128Kbps

64Kbps 64Kbps

64Kbps

Figura 7.1. Escenario implementado con tecnologias tradicionales

SOLUCION VPNTRM $ 2840

COSTO INICIALENLACES A INTERNET Dólares PesosInstalación enlace 512K Cali-Internet 750 $ 2.130.000,00 Instalación enlace 512K Bogota-Internet 750 $ 2.130.000,00 Instalación enlace 512K Medellín-Internet 750 $ 2.130.000,00

$ 6.390.000,00

HARDWAREEnrutador Cali Cisco1760 1500 $ 4.260.000,00 Enrutador Bogota Cisco1760 1500 $ 4.260.000,00 Enrutador Medellín Cisco1760 1500 $ 4.260.000,00

$ 12.780.000,00

SOFTWARE3 Licencias VPN para Cisco1760 1500 $ 4.260.000,00

216

20 Licencias cliente IPSec Cisco (venden el paquete de100 licencias)29 250 $ 710.000,00

$ 4.970.000,00

TOTAL COSTO INICIAL $ 24.140.000,00

COSTO MENSUALENLACES WANCargo fijo mensual enlace Cali-Internet 512K* 1100 $ 3.124.000,00 Cargo fijo mensual enlace Bogota-Internet 512K* 1100 $ 3.124.000,00 Cargo fijo mensual enlace Medellín-Internet 512K* 1100 $ 3.124.000,00

$ 9.372.000,00

ACCESO REMOTORoaming usuario internacional 5 días, 1 hora por día $ 30.388,00 La impulsación local no se tiene en cuenta $ -

$ 30.388,00

ACCESO A INTERNET20 Cuentas de acceso conmutado a Internet $ 560.000,00

$ 560.000,00 TOTAL COSTO MENSUAL $ 9.962.388,00

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

217

9 Empleados a nivelnacional accediendo

indistintamente a cualquierISP en el pais

CALI BOGOTA

MEDELLIN

Usuarios remotosCali

Usuarios remotosMedellin

Usuarios remotosBogota

Internet

Empleado enel exterior

ISPMiami

ISPCali

ISPMedellin

ISPBogota

512Kbps

512Kbps 512Kbps

Cisco1760 con IOSIPSEC 3DES

Cisco1760 con IOSIPSEC 3DES

Cisco1760 con IOSIPSEC 3DES

Figura 7.2. Escenario implementado con VPN

Sobre el anterior análisis económico hay que anotar que:

Para ninguno de los dos escenarios se han tenido en cuenta

gastos de instalación y de configuración de equipos, pero es

claro que este item perjudicaría aún más los costos iniciales

para la solucion tradicional ya que esta supone más

infraestructura para la compañía.

Estos precios son reales y actualizados al mercado

colombiano.

La diferencia a nivel económico entre implementar el

escenario descrito con las tecnologías tradicionales y con

VPNs es muy notoria tanto en los costos iniciales como en

los cargos fijos mensuales:

218

ImplementaciónTradicional

Implementacióncon VPN (IPSec

Cisco)

Diferencia%

CostoInicial

49’218.000 24’140.000 50.9%

CostoMensual

14’378.000 9’962.388 30.%

El ahorro inicial sería de $25’078.000 y mes a mes sería de

$4’415.612, lo que representa en un año alrededor de

$53’000.000.

219

8. RECOMENDACIONES

Con el ánimo de seguir incentivando el uso y estudio de las Redes Privadas

Virtuales se presentan a continuación una serie de recomendaciones para

trabajos futuros y aplicaciones prácticas que pueden ser muy interesantes:

Un trabajo interesante sería evaluar y proponer a una entidad cuya misión

crítica sea la protección de su información para abandonar sus enlaces

WAN tradicionales y migrar a una topología con VPNs. Como resultado de

este trabajo debería salir una solución VPN estado del arte, que

involucrara la implementación de un sistema de llaves públicas y los más

avanzados algoritmos de encriptación y autenticación.

Otra recomendación 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 debería incluir la implementación de una solución de Voz sobre IP

y videoconferencia privada. Como resultado de este estudio debería salir

un cuadro comparativo donde se demuestre el ahorro mensual que

tendría la Universidad con la implementación de VPNs.

Un trabajo que se propone a raíz de este, es la implementación 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

detrás del cual exista una red con dispositivos IPv6.

220

9. BIBLIOGRAFIA

LIBROS

[1] Ford, M., Lew, K., Spanier, S. y Stevenson, T.. Internetworking

Technologies Handbook. Indianapolis: Cisco Press, 1997.

[2] Sklar, Bernard. Digital Communications, Fundamentals and

Applications, Second Edition. New Jersey: Prentice Hall PTR, 2000.

[3] Kosiur, Dave. Building and Managing Virtual Private Networks. New

York: John Wiley & Sons, Inc., 1998.

[4] Yuan, Ruixi y Strayer, Timothy. Virtual Private Networks.

Technologies and Solutions. New Jersey: Adisson-Wesley, 2001.

[5] Pepelnjak, Ivan y Guichard, Jim. MPLS and VPN Architectures.

Indianapolis: Cisco Press, 2001

[6] Lee, Thomas y Davies, Joseph. Windows 2000 TCP/IP Protocols

and Services. Technical Reference. Redmon: Microsoft Press, 1999.

[7] 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. Point-

to-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.comPagina web oficial de Microsoft Corporation. Fuente de información sobre losprotocolos PPTP y L2TP sobre computadores instalados con sistemas operativosWindows NT, Windows 2000 server, Windows XP y Windows 2003 Server.http://www.cisco.comPagina web oficial de Cisco Systems. Compañía mundial lider en la fabricación deequipos para Internetworking. Dentro de sus productos cuenta con equiposconcentradores de tuneles L2F, L2TP y IPSec. Desarrolla sistemas operativos(IOS) para sus enrutadores y switches que capacitan a los mismos para crear yterminar tuneles.http://www.v90.comPagina desarrollada por Copper Pair Communications Inc. que discute losantecedentes, y beneficios del estandar V.90 para transmisión de datos sobrelineas analogas conmutadas. Ademas ilustra de manera breve las caracteristicasde una red telefonica tradicional.http://www.freeswan.org

222

Pagina web oficial del proyecto FreeS/WAN. FreeS/WAN es una implementacionde IPSec e IKE bajo Linux.http://www.nap.com.coPagina web oficial del NAP Colombia. El NAP Colombia fue creado eimplementado por la Camara Colombiana de Informatica y TelecomunicacionesCCIT. En este sitio se encuentran entre otros los objetivos del NAP, losintegrantes y las estadisticas semanales, mensuales, trimestrales, semestrales yanuales del trafico que cursa por este.http://www.rsasecurity.comPagina web oficial de RSA Security Inc. Esta compañía esta enfocada a brindadsoluciones para el establecimiento en linea de identidades, derechos de acceso, yprivilegios de acceso para personas, aplicaciones y dispositivos. Sus fundadoresdesarrollaron el algoritmo de cifrado que lleva su nombre.http://www.pgpi.orgPagina web oficial del proyecto PGP Internacional. El proposito de este proyectoes promover el uso de PGP a nivel mundial a partir de un estandar abiertodenominado OpenPGP. PGP es el sistema de cifrado de llaves publicas mascomúnmente usado en la actualidad.

223