VPN
-
Upload
xerardo-pazos -
Category
Documents
-
view
71 -
download
5
Transcript of VPN
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 “[email protected] ” 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 [email protected] 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 <[email protected]>”: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 = [email protected]
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 [email protected] [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 [email protected] [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 => [email protected]@66.128.47.2 (0)192.168.100.2/32 -> 200.14.106.59/32 => %pass (804)ipsec0->eth1 mtu=16260(1500)->[email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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