2.11. ARQUITECTURAS

Existen muchas formas de combinar los distintos elementos que componen una VPN. Esto origina que existan distintas arquitecturas que se clasifican de la siguiente manera:

2.11.1. Basadas en software

Es un programa para establecer túneles o cifrado a otro anfitrión. En el caso de no residir en el firewall, se debe configurar este para que permita la comunicación hacia y desde el exterior al equipo en que resida el software.

Este software puede ser abierto (Open Source) o propietario. La desventaja que posee el propietario es que el proveedor puede desaparecer o ser adquirido por otra empresa y se deja de producir actualizaciones de seguridad o de agregado de funcionalidad.

El Open Source tiene la ventaja de su costo de adquisición, pero puede ser necesario tener personal capacitado o realizar un contrato anual para tener soporte con algún proveedor.

2.11.2. Basadas en la Implementación

Dependen de quien es el responsable de la implementación de la VPN y su administración. Existen dos categorías y una tercera que es una combinación de las otras dos.

DependienteEl proveedor del servicio es el responsable de proveer una solución llave en mano. La principal ventaja es que la organización no debe cambiar su infraestructura y no necesita personal con conocimientos en administración de VPN para su gestión.La mayor desventaja surge en el ámbito de la seguridad. Es recomendable que la organización use una infraestructura AAA y firewall y estar a cargo de su administración.

Independiente

En esta categoría toda la responsabilidad de la implementación es de la organización. La encriptación, autenticación y autorización está dada por elementos de la propia Intranet. El proveedor puede dar el servicio de Internet. Como desventaja se puede mencionar que se debe poseer personal capacitado en estas tecnologías

HíbridaEsta categoría es una combinación de las categorías anteriormente Mencionadas. Una parte de la administración es realizada por la organización y otra por el proveedor. Una arquitectura que se puede tener en cuenta es la que muestra la Figura 2-4 en la que se puede observar que existen varios proveedores de servicios. La ventaja es que si existe problemas con un proveedor se puede seguir conectado a los sitios que sean administrados por los otros proveedores. Provee una mejor disponibilidad.Este acercamiento tiene la desventaja de que es compleja la administración.

Figura 2: Basada en la Implementación (Hibrida)

2.11.3. Basada en Seguridad

Se podrían mencionar cuatro categorías:

Router a Router

Firewall a firewall

Túneles bajo demanda

Túneles Multiprotocolo bajo demanda

Router a Router

Túneles bajo demanda: El túnel es establecido entre dos routers que se encuentran en la conexión en el lado del cliente y en el lado del servidor. Puede soportar múltiples conexiones simultáneamente y persisten hasta que la última conexión es terminada. Los routers deben soportar intercambio de claves y algoritmos de encriptación. La Figura 2-5 muestra cómo se relacionan los componentes bajo esta arquitectura.

Figura 2: Túneles bajo demanda (Router a Router)

Túneles multiprotocolo bajo demanda: Es similar a routers bajo demanda con la particularidad que los routers soportan varios protocolos de túnel. Tiene la particularidad de que pueden transferir datos no-IP a través de la red pública.

Sesiones encriptadas bajo demanda: Cada sesión es encriptada en forma individual. Tiene un túnel distinto para cada pedido entre los routers como grafica la Figura 2-6. La desventaja es que esto genera una gran sobrecarga.

Figura 2: Sesiones encriptadas bajo demanda

Firewall a Firewall

Consta de túneles bajo demanda y túneles multiprotocolo bajo demanda. A continuación daremos un breve detalle.

Túneles bajo demanda

Es similar a router a router con túnel bajo demanda, con la particularidad que se reemplazan los routers por firewalls. Es más seguro y permite que se puedan implementar auditorias más complejas.

Figura 2-7 Túneles bajo demanda (Firewall a Firewall)

Túneles multiprotocolo bajo demanda

Generalmente se utilizan L2TP asegurado con IPSec gracias a su característica multiprotocolo.

2.11.4. .. Iniciadas por el cliente

Cliente a Firewall/Router

Se negocia la sesión entre el cliente y el firewall/router. Éste debe soportar el pedido del cliente de inicio de sesión. El cliente debe poder comunicarse con el sistema operativo correspondiente.

Cliente a ServerEl servidor VPN se encuentra dentro de la intranet corporativa, en vez de cumplir las funciones de servidor VPN y firewall/Router.Es más seguro que el anterior porque el proveedor de servicios ignora la existencia del túnel.

2.11.5. Dirigidas

Los datos son encriptados en el capa 5 del Modelo OSI. Es decir en la capa de sesión. El protocolo más utilizado en socks 5. Los túneles son unidireccionales. El control de acceso puede utilizar el identificador del usuario, hora, aplicación y hasta el contenido del paquete.La capa de sesión soporta una mayor variedad de mecanismos de encriptación. La Figura 2 muestra la distribución de los componentes.

2.11.6. Basado en la capaDepende en que capa del modelo OSI se encuentra configurada la RedPrivada Virtual. Puede ser en la capa de red o la capa de enlace.

Figura 2: Dirigida

Capa de Enlace

Se pueden dividir en:

Conexión Frame Relay: La principal ventaja es que provee el CIR (Committed Information Rate).

Conexiones virtuales ATM.

MultiProtocolo sobre ATM (MPOA)

MPLS

Capa de Red

Estos modelos ya fueron explicados cuando se desarrollo el tema de la Clasificación de VPNs en el capítulo anterior. Por lo tanto solo las mencionaremos. Un tipo son las Redes Privadas tipo Peer y el otro son las Redes Privadas tipo Overlay.En este nivel se pueden usar los protocolos de capa 2 PPTP y L2TP. También se puede utilizar IPSec.

2.11.7. Basada en ClasesEstas arquitecturas se basan en la complejidad de la configuración de la VPN y del tamaño. Existen 5 clases que van de la 0 a la 4. Fue propuesta por VPN Technologies.

En la Tabla 2:1, podremos observar las clases y sus características.

2.11.8. Basada en Caja Negra

Consiste en un dispositivo que contiene software de cifrado que se ejecuta en un equipo del cliente. Se presupone que estos dispositivos de hardware crean túneles más rápidos bajo demanda y ejecutan el proceso de cifrado con mayor rapidez. Ofrecen una administración centralizada.

Es aconsejable que soporten los protocolos para establecimiento de túneles PPTP, L2TP e IPSec. En general este dispositivo se encuentra detrás del firewall.

2.11.9. Basada en Acceso Remoto

En esta arquitectura existe un software que se ejecuta en un equipo remoto que quiere establecer una conexión a través de una red pública con un túnel cifrado al servidor interno de la organización o de una línea de acceso telefónica hacia un servidor de autenticación. El servidor puede ser un router, un firewall, una caja negra o un servidor de autenticación independiente.

2.11.10. VPN múltiple servicios

Son aplicaciones multiservicios que son generadas por proveedores. Por ejemplo pueden dar el servicio de filtrado de contenido web y la revisión antivirus. El primero se suele añadir a un firewall para que pueda utilizar reglas para el acceso basado en el contenido.

CLASE Nº

SOFTWARE PROTOCOLOSUTILIZADOS

SEGURIDAD ACCESO CARACTERÍSTICAS

0 Como mínimo sistema operativo Windows

PPTP Filtrado de paquetes ofrecido por un Gateway, firewall o router

DSL T1 No soporta sitio a sitio

1 IPSec DES IKE

Algún mecanismo de Autenticación de Usuarios, 1 Gateway

T1T3

Soporta:20 sucursales, 250 usuarios remotos Soporta sitio a sitio y acceso remoto Para poder implementar una extranet esta debe soportar IPSec.

2 Soft de marcación y de acceso remoto.

IPSec3DES IKE

Utiliza Token5 VPN Gateway o 1gateway que soporte500 usuarios concurrentes AAA,RADIUS,TACACS, NAT y firewall

Soporta:10 a 100 sitios remotos, 500 usuarios remotos sitio a sitio y acceso remoto

3 Soft de marcación y de acceso remoto

X.500LDAPIPSec3DESIKE

Token y smartcards, 20 VPN Gateway o 1 gateway que soporte1000 sesiones simultáneas. AAA,RADIUS,TACACS, NAT y firewall Servicio de certificados propio

Es necesario calidad de servicio en cuanto a retardo

ISDN Xdsl T1T3

Soporta: Cientos de sitios remotos y miles de usuarios remotos Extranet, usuarios remotos y sitio a sitio Videoconferencia Tiene la desventaja que es compleja la administración, configuración e implementación

4 Soft de marcación y de acceso remoto

LDAP IPSec3DESIKE

Token y smartcards 10 a 20 gateway o 1 que soporte 5000 conexiones simultaneas AAA,RADIUS,TACACS, NAT y firewall Servicio de certificados propio.

ISDN Xdls T3OC3

Soporta: Miles de sitios remotos,10000 usuarios remotos Extranet, sitio a sitio, usuarios remotos Comercio electrónico Audio y video en tiempo real Posee la desventaja que necesita profesionales altamente capacitados

Tabla 2, VPNs basadas en clases

2.12. PROTOCOLOS DE TÚNEL

Un protocolo de túnel es un mecanismo para encapsular un PDU9 denominado de carga o nativo. Se agrega un encabezado al PDU de carga propio del protocolo de túnel. Finalmente este nuevo PDU se debe entregar a su destino final mediante un protocolo de transporte o envío, por lo que es necesario agregar el encabezado correspondiente a este último.

Esta clase de protocolos se utilizan para el envío de datos de un determinado protocolo a través de una red que soporta uno diferente o incompatible. También se usan cuando es necesario asegurar los datos de carga mediante algún método de encriptación. Otro uso extendido es resolver problemas de espacio de direcciones para los datos a transmitir, por ejemplo cuando mediante el uso de un espacio de direccionamiento público se envían paquetes con direcciones privadas.

Figura 2-9 Funcionamiento de un Túnel

Un túnel es un medio para reenviar datos a través de una red desde un nodo a otro, como si ambos estuvieran conectados en forma directa. Luego de los encapsulamientos, el PDU resultante es reenviado por nodos intermedios basados en la información del encabezado externo sin tener en cuenta el contenido original del paquete.

La Figura 2-9, muestra dos nodos A y B que se comunican mediante el túnel entre los nodos W y Z. Estos últimos se denominan nodos de ingreso y de egreso respectivamente. Los datos originales entre A y B son modificados agregándoles un encabezado que permite reenviarlos a través del túnel. Los nodos intermedios X e Y solo participan del proceso de transporte, pero no tienen acceso a la información original propia de la comunicación entre A y B. Cuando el paquete llega al extremo final o nodo de egreso Z, del túnel, este le saca el encabezado exterior y reenvía el paquete al destino real, el nodo B.

La utilización de túneles permite la separación del tráfico de datos de varias VPNs y del tráfico correspondiente a la red del proveedor o de Internet. Esto significa que el espacio de direcciones utilizado por los dispositivos involucrados en la VPN forma parte de los datos que se envían por los túneles sin modificación, aún si se usa Internet para su transporte.

2.12.1. Requerimientos de un TúnelExisten requerimientos deseables en los mecanismos de túnel, pero no todos los protocolos existentes cumplen con todos ellos. Estos son10:

Multiplexación

Protocolo de señalización

Seguridad de los datos

Transporte multiprotocolo

Secuenciación de tramas

Mantenimiento

Manejo de grandes MTU

Sobrecarga mínima

Control de congestión y flujo

Manejo de tráfico y Calidad de servicio (QoS)

Multiplexación

Esto permite el anidamiento de túneles, es decir que puedan existir múltiples túneles VPN entre dos extremos que han establecido un único túnel principal, esto implica que cada extremo del mismo puede soportar varios clientes o VPNs. El tráfico de cada uno se mantendrá separado del otro a través de la existencia de un campo de multiplexión en los paquetes transmitidos para distinguir la pertenencia a un determinado túnel.

Compartir un túnel de esta forma, disminuye la demora y el procesamiento asociado al establecimiento del mismo. Esta característica representa una ventaja ante los problemas de escalabilidad para un proveedor de servicios VPN ya que solo tiene que mantener una estructura de túneles de menor envergadura.

Figura 2-10 Multiplexación de Túneles

Protocolo de señalización

Previo al establecimiento de un túnel, se deben configurar una serie de parámetros que deben ser acordados por los extremos participantes, por ejemplo la dirección de los extremos, el nivel de seguridad requerido, etc. Finalmente el túnel se puede establecer. Todo esto es posible por vía manual o en forma dinámica mediante el uso de un protocolo de señalización.

La utilización de un protocolo de señalización, facilita la tarea de administración del túnel, tanto su creación, distribución y manejo de parámetros o atributos asociados al mismo, más aún cuando la VPN a la cual pertenecen el o los túneles abarca más de un dominio administrativo. En este caso simplifica la coordinación de la administración.

También permite que los túneles puedan ser creados bajo demanda, cuando los nodos que los constituyen son móviles o requieren estar interconectados en forma transitoria. Es importante que el protocolo permita el transporte de un identificador VPN para asociar esta con el túnel resultante.El rol de este protocolo debería ser negociar los atributos del túnel y no transportar información acerca de cómo utilizar el mismo.

Seguridad de los datos

Un protocolo de túnel debe soportar mecanismos que permitan varios niveles de seguridad. Esto significa incluir métodos de encriptación y autenticación de diversas fortalezas.

La seguridad de los datos de la VPN en general no depende únicamente de las capacidades requeridas del túnel recién mencionadas. Es importante considerar otros mecanismos, como por ejemplo el manejo de varias instancias virtuales de tablas de enrutamiento y reenvío. Cada par (enrutamiento y reenvío) estarán asociadas a una VPN. Un mismo dispositivo en el extremo de un túnel, podrá manejar varias instancias por lo tanto varias VPNs. Esto evita el enrutamiento por error del tráfico de una VPN hacia otra, asegurando de esta manera la separación de los flujos de datos. Otra medida de seguridad puede ser la autenticación de los extremos del túnel mediante el uso del protocolo de señalización previo a su creación.

Transporte Multiprotocolo

Muchas aplicaciones de VPN requieren la transmisión de tráfico multiprotocolo, por lo tanto el protocolo de túnel debería soportar su transporte. Debe existir alguna forma de identificar el tipo de protocolo que esta siendo enviado por el túnel.

No todos los protocolos de túnel soportan esta característica, para estos existen extensiones que lo posibilitan. Otros poseen campos específicos para esta señalización.

Secuenciación de Tramas

La secuenciación podría ser necesaria para una operación extremo a extremo eficiente de algún protocolo de túnel o aplicación en particular. Para esto es necesario un campo de secuencia en el diseño del protocolo, para garantizar la entrega en orden de los

paquetes.

Mantenimiento

Este requerimiento implica que los extremos monitoreen el estado del túnel para determinar si se pierde o no la conectividad y tomar las medidas adecuadas en caso de corte o falla de la misma.

Las formas de realizar este monitoreo pueden ser dos: a través del protocolo en si, ejecutando un chequeo en banda en forma periódica y en caso de pérdida de conexión indicar explícitamente el problema. La otra forma es mediante mecanismos fuera de banda, por ejemplo el uso de protocolos de enrutamiento aplicados a una malla de túneles (RIP, OSPF), lo cual permite detectar cualquier falla en forma automática. Otra herramienta es el uso del protocolo ICMP a través de mensajes de solicitud de eco para monitorear el estado del túnel.

Manejo de Grandes MTU

Teniendo en cuenta los dispositivos intermedios que reenvían el tráfico del túnel, es posible que alguno de ellos maneje un valor de Máxima Unidad de Transferencia o MTU menor al valor manejado desde el extremo de ingreso al túnel. En este caso, es necesaria alguna clase de fragmentación. Esto traería inconvenientes de performance en el nodo donde sucede la fragmentación, disminuyendo la eficacia general.Para evitar este inconveniente, el protocolo de túnel puede incorporar capacidad de segmentación y ensamblado haciendo uso del número de secuencia y alguna clase de marcador de fin de mensaje.

Sobrecarga Mínima

Es importante este aspecto y más cuando se transporta tráfico de datos sensible a la demora o al desfasaje temporal, como lo es el tráfico de voz y video. Lo que se persigue con este requerimiento es evitar el procesamiento innecesario en los dispositivos que establecen el túnel.

Los mecanismos de cifrado y encriptación imponen una sobrecarga. Por lo tanto se debería minimizar la sobrecarga u overhead tomando en cuenta la necesidad de aplicar seguridad a los datos. En general el objetivo debería ser minimizar el overhead alrededor de la necesidad de seguridad del tráfico de datos.

Cuando se implementan las VPN dial-up, o de acceso remoto discado, mediante el uso de túneles voluntarios, existe la posibilidad de sobrecarga significante si se utilizan enlaces de poco ancho de banda.

Control de Congestión y Flujo

Existen protocolos de túnel, como L2TP, que incorporan procedimientos para el control de flujo y congestión. Estos fueron pensados para mejorar la performance de la transmisión cuando se utilizaban redes que podían generar pérdidas de paquetes con la compresión PPP. Otra razón era crear un buffer al momento de utilizar líneas con menor capacidad de transferencia. Finalmente estos esquemas se aplicaron a los canales de control en lugar de aplicarlos al tráfico de datos.

En general no está claro si es conveniente incorporar estas características en el diseño de los protocolos de túnel, en gran medida por el hecho de la predominancia del tráfico TCP y el hecho de que TCP posee sus propios y eficientes mecanismos extremos a extremo de control de flujo y congestión.

Manejo de Tráfico y QoS

Los usuarios de un servicio de VPN, podrían desear características de Calidad de Servicio como sucede con los demás servicios WAN. Para el caso de las VPN, lograr aplicar QoS va a depender de las características de manejo de tráfico que puedan efectuar los nodos involucrados en la VPN y de la red de acceso o backbone donde se implemente.

2.13. PROTOCOLOS DE TÚNEL CAPA 2

Los túneles mas usuales son los implementados en la capa 2 o capa enlace del modelo OSI. Entre ellos podemos mencionar Point to Point Tunneling Protocol (PPTP), Layer 2 Forwarding (L2F) y Layer 2 Tunneling Protocol (L2TP). Los protocolos de esta capa se basan en otro protocolo denominado Point to Point Protocol (PPP), por lo que comenzaremos explicando este protocolo.

2.13.1. Point to Point Protocol (PPP)Es un protocolo para encapsular que permite transmitir a través de una línea serie. Este requiere una conexión full-duplex y puede ser sincrónico o asincrónico. Puede encapsular IP o no IP a través de líneas series.

Las funciones que realiza son administrar las direcciones IP del tráfico no IP. Configura y realiza las pruebas necesarias para establecer el enlace, encapsula los datagramas y realiza la detección de errores durante la transmisión. También realiza la multiplexación de los protocolos de capa 2 y renegocia parámetros como la compresión de los datos transmitidos.

Para realizar estas funciones se basa en LCP (Link Control Protocol) para establecer, configurar y probar las conexiones punto a punto y NCP (Network Control Protocol) para establecer y configurar varios protocolos de la capa de red y para detectar errores durante la transmisión.

Funciones de LCP

Realiza las siguientes funciones:

Ayudan a establecer el enlace PPP.

Configura y establece el enlace para satisfacer los requerimientos de comunicación de las partes.

Realiza las tareas necesarias para mantener el enlace.

Da por finalizado el enlace cuando se termina el intercambio de datos entre las partes.

2.13.2. Point to Point Tunneling Protocol (PPTP)

El protocolo punto a punto (PPTP) se creó para permitir a usuarios remotos conectarse a su proveedor y establecer un túnel al servidor de la organización. Permite realizar una conexión por marcación y soporta protocolos que no sean IP.

PPTP es una extensión de PPP y por lo tanto no soporta múltiples conexiones. PPTP es el encargado de establecer y terminar las conexiones físicas entre las partes, autenticar los clientes PPTP, encriptar datagramas de protocolos no IP e IP para crear datagramas PPP y asegurar el intercambio de información entre las partes. Esto se puede observar en la Figura 2-11.

Figura 2-11 Funciones del Protocolo PPP en PPTP

En la figura podemos ver los elementos involucrados en una transacción PPTP. Existe un cliente, el cual es el que inicia la transacción a través de una conexión realizada con un modem a través de una marcación. Si el NAS del proveedor acepta la comunicación entonces se puede establecer el túnel con el dispositivo VPN a través de la red pública. En la Figura 2-12 podemos observar la relación entre PPP y PPTP.

Figura 2-12 Componentes en una conexión PPTP

El dispositivo NAS debe poder soportar múltiples clientes concurrentemente y distintos tipos de cliente, como por ejemplo cliente WINDOWS, LINUX, Apple, etc. Si se realiza dentro de una red local no es necesario el dispositivo NAS. El servidor PPTP debe tener capacidad de enrutamiento.PPTP utiliza el puerto 1723. Para detectar la pérdida la conexión realiza una transmisión periódica de echo entre el cliente y el servidor utilizando la conexión TCP establecida. Brevemente resumiremos como es el proceso de transmisión los datos basándonos en la Figura 2-13.

Figura 2-13 Encapsulamiento PPTP

Se encapsula y se encripta los datos en un datagrama PPP

Se encapsula dentro de un paquete GRE

Se encapsula de un paquete IP. El encabezamiento contiene la dirección IP de cliente PPTP y la del servidor destino.

La capa de enlace suma un encabezamiento y una cola, el cual viaja a través del túnel establecido.

Esto es encapsulado dentro del protocolo de transmisión que puede ser por ejemplo ethernet o un protocolo de WAN.

El servidor extrae en orden inverso y termina desencriptando los datos.

Para realizar la encriptación y compresión se utiliza los servicios brindados por PPP. En cuanto a la autenticación se utiliza MS-CHAP (Microsoft Challenge-Handshake Authentication Protocol) o PAP (Password Authenticaction Protocol). PPTP permite realizar un filtrado en el servidor aceptando solamente los clientes que fueron aprobados para acceder a la red.

2.13.3. Layer 2 Forwarding Protocolo (L2F)

Es un protocolo desarrollado por Cisco en el año 1996. El objetivo era permitir que protocolos no IP pudieran utilizarse sobre Internet. El usuario hace una conexión PPP al proveedor de marcación y se conectan a sus organizaciones a través de L2F.

Figura 2-14 Componentes en el Protocolo L2F

L2F provee la encriptación de datos y la autenticación utilizando CHAP, EAP (Extensible Authentication Protocol) y SPAP (Shiva Password Authentication Protocol). También puede emplear RADIUS y TACACS como servicios adicionales.

Como desventajas se puede mencionar que esta solución requiere un mantenimiento costoso y son dependientes del proveedor que debe implementar L2F. No provee control de flujo, lo que resulta en retransmisión de tráfico y provoca una comunicación más lenta. Es más lento que PPTP debido al proceso de autenticación y encriptación.

2.13.4. Layer 2 Tunneling Protocolo (L2TP)En 1998 las compañías que desarrollaron PPTP y Cisco que trabajó con L2F acordaron una nueva especificación para el establecimiento de túneles de nivel 2 (L2TP). Por lo tanto L2TP combina PPTP y L2F en una sola norma.

IPSec se puede utilizar con L2TP para poder brindar una mayor seguridad. Se recomienda implementar esta configuración para proteger el trafico L2TP a través de redes IP y no IP.

Las ventajas que tiene es que soporta multiprotocolo y tecnologías como por ejemplo IP, ATM, Frame Relay y PPP. No requiere implementación de software específico como

15

drivers o soporte en el sistema operativo. Permite que clientes con IP privadas se comuniquen a través de redes públicas con sitios remotos. Y por último se puede mencionar que la autorización y autenticación se realizan en un gateway por lo tanto el proveedor no necesita implementar y mantener una base de datos de los usuarios remotos y sus derechos de acceso.

Es necesario definir antes, dos componentes principales en el funcionamiento de L2TP: LAC (L2TP Access Concentrator) y LNS (L2TP Network Server). Un LAC es un dispositivo que es uno de los extremos del túnel L2TP y siendo el LNS el otro extremo. De hecho un LAC se ubica entre un cliente remoto y el LNS reenviando los paquetes entre ellos. La conexión entre el LAC y el sistema remoto es mediante un enlace PPP. Un LNS es el otro extremo del túnel L2TP y representa la terminación lógica de la sesión PPP que es enviada por el túnel.

Modos de túnel

L2TP soporta los modos de túnel obligatorio y voluntario. En el modo obligatorio Figura 2-15, el proveedor es el encargado de establecer entre el LAC y el LNS el túnel y de validar el usuario. Para comunicarse con Internet es necesario pasar por gateway de la intranet corporativa, brindando una mayor seguridad.

Figura 2-15 L2TP Túnel obligatorioEn el túnel voluntario Figura 2-16, el usuario remoto actúa de LAC. El túnel

es transparente para el proveedor como ocurre con los túneles basados en PPTP.

Entre las ventajas que podemos mencionar esta que es una solución genérica, independiente de la plataforma. Puede soportar la transmisión a través de enlaces WAN no IP sin la necesidad de IP. No se requiere configuración en el proveedor y en el cliente. Permite que la autenticación sea realizada por la organización y no por el proveedor. Provee control de flujo. Es más rápida que L2F. Permite que clientes remotos con IP privada puedan conectarse a su organización a través de redes públicas. Se puede utilizar IPSec para poder brindar una mayor seguridad.

Como desventajas podemos mencionar que es más lento que PPTP o L2F cuando se utiliza IPSec para autenticación de cada paquete y es más complejo de

16

implementar que PPTP.

Figura 2-16 L2TP Túnel voluntario

Característica PPTP L2F L2TPSoporta multiprotocolo Si Si SiSoporta múltiples

conexionesNo Si Si

Soporta múltiples conexiones por túnel

No Si Si

Modos de Túnel Voluntario Voluntario yObligatorio

Voluntario yObligatorio

Protocolo de Entrega IP/GREIP/UDP IP/FR IP/ATM IP/UDP IP/FR IP/ATM

Protocolo de ControlTCP Puerto1723

UDP Puerto 1701 UDP Puerto 1701

Autenticación MS-CHAP PAP

CHAP PAP SPAP RADIUS TACACS

CHAP PAP SPAP EAP IPSec TACACS

Encriptación MPPEMPPE IPSec MPPE IPSec ECP

Tabla 2-2 Comparativa protocolos Capa 2

2.14. PROTOCOLOS DE TÚNEL CAPA 3

En la siguiente sección se describirá los principales protocolos de túnel de capa 3, empezando con IPSec, GRE y finalmente MPLS. Si bien este último no es en si un protocolo de capa 3, su funcionamiento esta muy ligado al protocolo de red IP.

17

2.14.1. IP Security Protocol (IPSec)

IPSec es una extensión del protocolo IP que brinda seguridad a IP y a los protocolos de capa superior. Fue desarrollado para el nuevo estándar de IP versión 6 (IPv6) y luego adaptado para implementarlo en la versión 4 (IPv4).

Figura 2-17 Paquete/Datagrama usando IPSec

La Figura 2-17 muestra un paquete con los encabezados de capa 2 que encapsulan un datagrama IP procesado mediante IPSec. Se puede observar el encabezamiento IPSec posterior al encabezado IP y un campo Datos de Autenticación (HMAC) como cola del datagrama. Como resultado surge un nuevo datagrama IP con nuevos encabezados.

IPSec utiliza dos protocolos diferentes para asegurar la autenticidad, integridad y confidencialidad, estos son el protocolo de Autenticación de Encabezado AH (Authentication Header) y el protocolo de Encapsulado de Seguridad de Datos o ESP (Encapsulated Security Payload).

IPSec puede proteger todo el datagrama IP o solamente los protocolos de capa superior mediante los modos túnel y transporte. En el primer caso el datagrama IP es encapsulado en forma completa en otro. En el modo transporte solo los datos del datagrama IP original es procesada por IPSec, insertando el encabezado AH o ESP entre el encabezado IP y los datos.

Para asegurar la integridad del datagrama IP, IPSec utiliza HMAC14 (Hash Message Authentication Code) o Código de autenticación de mensajes basados en hash, mediante algoritmos como MD5 y SHA. Lo calcula basado en una clave secreta y en el contenido del datagrama. El HMAC se incluye en el encabezado IPSec. El receptor verifica este HMAC si tiene acceso a la clave secreta.

IPSec utiliza algoritmos de encriptación simétricos estándar de elevada fortaleza como 3DES, AES o Blowfish para asegurar la confidencialidad del tráfico transportado. IPSec protege la comunicación respecto de ataques de denegación de servicio o ataques de repetición, mediante el mecanismo de ventana deslizante. Los números de secuencia de los paquetes deben estar dentro del rango aceptado por la ventana, sino son descartados.

18

Para encapsular y desencapsular los paquetes IPSec, los extremos participantes necesitan un mecanismo para mantener información como claves secretas, algoritmos, direcciones IP utilizadas en la conexión etc. Estos parámetros se guardan en Asociaciones de Seguridad o SA (Security Association). Estas a su vez se almacenan en una Base de Datos o SAD. Cada SA define los siguientes parámetros:

Direcciones IP origen y destino del encabezado IPSec resultante (direcciones que coinciden con las de los pares que establecen la comunicación segura).

El protocolo IPSec a utilizar (AH o ESP).

Algoritmo y claves secretas a utilizar.

SPI (Security Parameter Index) de la SA. Es un número de 32 bits que identifica la SA.Algunas implementaciones de bases de datos de SA permiten, además,

almacenar estos parámetros:

Modo IPSec (túnel o transporte).

Tamaño de la ventana deslizante.

Tiempo de duración de la SA.

Una SA representa una conexión unidireccional. IPSec requiere que se definan dos SA para una comunicación bidireccional o full duplex. Las asociaciones solo determinan como proteger el tráfico. Las Políticas de Seguridad o SP establecen que tráfico proteger y cuándo. Las SP se almacenan a su vez en una SPD o base de datos de políticas de seguridad. Una SP define los siguientes parámetros:

Direcciones IP Origen y destino de cada paquete. En modo transporte estas direcciones coinciden con las IP almacenadas en la SA. En modo túnel estas podrían diferir.

Puerto y protocolo a proteger. Algunas implementaciones de IPSec no permiten estos parámetros, en estos casos se aseguran todos los paquetes.

La SA a utilizar.

La SPD discrimina el tráfico entrante o saliente, de forma tal que puede descartar el paquete en tránsito, ignorarlo o aplicar el servicio de seguridad de acuerdo a la asociación de seguridad relacionada con esa entrada de la SPD.

La SPD debe ser consultada durante el procesamiento de todo el tráfico, entrante y saliente. Por esta razón esta contendrá entradas diferentes para uno y otro. Además cada interfaz de red que es protegida por IPSec tendrá asociada sendas bases, de políticas y de asociaciones, para el tráfico entrante y saliente.

Cada implementación IPSec debe tener una interfase administrativa que permita a un administrador manejar la SPD. Dado que cada paquete entrante o saliente es procesado por IPSec y donde la SPD especifica la acción a ser tomada en cada caso, esta interfaz debe permitir al administrador establecer el procesamiento de seguridad que se aplicará a cada paquete, mediante la creación de entradas y la definición de los filtros selectores, además deberá permitir el ordenamiento de las mismas.

Si los valores de un paquete IP corresponden con los selectores de una entrada en la SPD, entonces se determina que un paquete IP está relacionado con la misma y

19

esto dispara un proceso IPSec. A continuación se determina si existe una Asociación de Seguridad (SA) para la entrada de la SPD. Si existe, entonces esta indicará el protocolo de seguridad a utilizar, el modo, el algoritmo de autenticación de encriptación y las claves a utilizar.

Cuando varios nodos participan de una VPN que utiliza IPSec para crear los túneles, surge un inconveniente al momento de compartir información para la comunicación dentro de la VPN. Durante la creación de las Asociaciones de Seguridad, se deben difundir las claves secretas y los algoritmos de encriptación a utilizar.

El intercambio de claves es un proceso crítico ya que en esta etapa aún no hay un medio seguro establecido para transmitir esta información. Para resolver este problema se diseñó el protocolo de intercambio de claves o IKE (Internet Key Exchange).

IKE autentica, en una primera fase, a los pares o nodos que participan en la VPN. En una segunda fase se negocian las SA y se eligen las claves secretas para la encriptación simétrica mediante el algoritmo Diffie Hellman de intercambio de claves. Una vez compartidos en forma segura los datos necesarios, IKE se encarga en forma periódica de regenerar claves que protegen la confidencialidad de las claves para encriptación simétrica.

Protocolo AH

Este protocolo se encarga de autenticar los datagramas asegurando la integridad de los datos incluyendo la dirección IP de origen, brindando además protección contra ataques de repetición de datagramas (replay attacks). Para establecer la integridad de los datos calcula un código de autenticación basado en hash o HMAC. Este se realiza utilizando una clave secreta, los datos del datagrama y el encabezado IP original. El valor resultante del procedimiento se coloca en el campo Datos de Autenticación del encabezado AH.

Figura 2-18 Encabezado AH

20

Los campos del encabezado AH son:

Próximo Encabezamiento: identifica el tipo de datos de la carga útil, es decir el protocolo de capa superior. Utiliza 1 byte.

Longitud del encabezamiento: identifica el tamaño del encabezado, utiliza 1 byte.

Reservado: utiliza 2 bytes.

SPI: Identifica la SA a utilizar. Utiliza 4 bytes.

Número de Secuencia: Previene los ataques de repetición (replay) en forma opcional y además sirve para mantener una recepción ordenada de paquetes. Este campo almacena un número que se incrementa en uno cuando un paquete es enviado en forma consecutiva a la misma dirección y con el mismo SPI. Utiliza 4 bytes.

Datos de Autenticación: Compendio (Digest) calculado mediante el HMAC, utilizado por el receptor para comparar lo recibido luego de aplicar la misma operación al datagrama.

AH puede usarse solo o junto con ESP cuando se usa el modo túnel. Cuando se utiliza el modo transporte, el encabezado AH se coloca justo detrás del encabezado IP y antes del encabezado ESP, en caso de funcionar en conjunto, u otro encabezado de protocolo de mayor nivel como UDP o TCP. Ver Figura 2-19.

Cuando se usa el modo túnel, se agrega un nuevo encabezado IP y el encabezado de AH se inserta luego de este y antes del encabezado IP del datagrama original. Si bien el proceso de autenticación abarca este nuevo encabezado IP, la norma especifica que no deberá afectar aquellos campos que puedan variar durante el transporte, por ejemplo el campo de Tiempo de vida o TTL (Time To Life), que es decrementado en uno cada vez que el datagrama atraviesa un router. Ver Figura 2-19.

El protocolo AH no es conveniente de utilizar cuando se considera el uso de traducción de direcciones de red o NAT, debido a que su protección de integridad abarca campos del encabezado IP como la dirección de origen. Es adecuado si lo único que se persigue es asegurar la integridad y autenticar el origen de los datos.

21

Figura 2-19 Modos con protocolo AH

Protocolo ESP

Este protocolo provee privacidad o confidencialidad a los datagramas IP por medio del encriptado de los datos correspondientes. Adicionalmente puede asegurar la integridad mediante un HMAC propio. ESP altera el datagrama IP original en más de un sitio: agrega un encabezado propio, una cola (CE en la Figura 2-20) y si es necesario rellena el campo de datos. La cola varía si además de la encriptación se usa autenticación (DA en la Figura 2-20).

En el modo transporte, de igual manera que AH, el encabezado de ESP se agrega luego del encabezado IP y antes de otro encabezado de protocolo de mayor nivel como UDP o TCP. En modo túnel el encabezado de ESP se inserta delante del encabezamiento IP original pero antes del nuevo encabezado IP propio de este modo. Esto se muestra en la Figura 2-20, modo túnel.

El proceso de encriptado incluye todos los campos posteriores al encabezado ESP, pero no este mismo. La autenticación se aplica a lo encriptado más el encabezado ESP. El encabezado IP externo no se autentica, es decir, el encabezado IP original en el modo transporte o el nuevo encabezamiento IP del modo túnel.

22

Figura 2-20 Modos en ESP

Figura 2-21 Encabezado y Cola ESP

De acuerdo a la Figura 2-21 los campos del encabezado ESP son:

SPI: Este indica que SA utilizar para desencapsular el paquete ESP, igual a AH. Utiliza 4 bytes.

Número de Secuencia: igual que en AH.

Campo de datos IP (payload)

23

Vector de Inicialización: Utilizado en el proceso de encriptación si este requiere datos de sincronización. Este vector sirve para que dos paquetes con la misma carga resulten en dos cargas encriptadas diferentes. Los algoritmos de encriptación simétrica son vulnerables a ataques de frecuencia si no se utilizaran los vectores de inicialización.

Encabezado TCP

Datos

Cola ESP

Relleno (Padding): Se usa en caso que el algoritmo de encriptado requiera que el texto a encriptar sea múltiplo de cierta cantidad de bytes (cifrado en bloques). También es necesario para lograr un múltiplo impar de 16 bits del encabezamiento hasta ese punto, de manera que los campos restantes, de 8 bits cada uno, logren que la longitud total, del encabezado, sea un número múltiplo par de 16 bits.

Longitud del relleno (Padding Length): identifica el campo anterior.

Siguiente Encabezado (Next Header): indica el tipo de datos de la carga útil. En Ipv4 identifica el protocolo de capa superior. Utiliza 1 byte.

Datos de autenticación: Es opcional y solo aparece si se utiliza ESP con autenticación. Su longitud varía según el algoritmo de Hash empleado: 16 bytes si es MD5 o 20 bytes si es SHA.ESP puede utilizarse solamente con encriptación o incluyendo además autenticación. Otra alternativa es con encriptado nulo, o sea sin encriptación pero con autenticación. ESP puede combinarse con AH.

Si bien ESP puede autenticar, no abarca al encabezamiento IP externo, es decir no lo protege de cualquier alteración en aquellos campos que no deberían cambiar. Por ejemplo, lo anterior podría derivar en la fragmentación del datagrama si se alterara el campo correspondiente. Esta operación podría permitir la inserción de datagramas de ataque.

Protocolo IKE

También conocido como ISAKMP/Oakley (Internet Security Association and Key Management Protocol), este protocolo resuelve el problema más importante relacionado con las comunicaciones seguras: la autenticación de los pares, el intercambio de claves simétricas, creación de las SA y actualización la Base de Datos que las contiene. IKE se implementa mediante un demonio en el espacio de usuario. Utiliza el puerto UDP 500.

Su funcionamiento se puede dividir en dos etapas o fases. En la primera fase IKE establece una Asociación de Seguridad ISAKMP (ISAKMP SA). En la segunda, esta SA es utilizada para negociar y establecer las SA propias de la comunicación IPSec (IPSec SA).

24

La autenticación de la primera fase puede estar basada en claves precompartidas (PSK), claves RSA y Certificados X.509. En esta etapa se pueden utilizar dos modos para la autenticación y establecimiento de la ISAKMP SA: modo principal o modo agresivo. Este último utiliza la mitad de los mensajes para lograrlo pero no brinda la protección de la identidad de los hosts intervenientes. Esto puede permitir un ataque del tipo “hombre del medio”.En la segunda fase el protocolo intercambia propuestas de SA y las negocia en base a la ISAKMP SA, la cual brinda la autenticación y protege la operación de ataques del tipo mencionado anteriormente. Las SA negociadas finalmente son al menos dos, una para cada dirección de la comunicación.

Rendimiento

La utilización de IPSec en las comunicaciones requiere capacidad de procesamiento. En particular con ESP esta necesidad se evidencia en la encriptación y desencriptación de los paquetes, considerando la complejidad de los algoritmos empleados y en la autenticación de su encabezado, el agregado de este y de la cola al datagrama original.

Inclusive con AH el proceso de calcular un compendio en un extremo y la posterior verificación en el otro, son tareas mucho más complejas que el enrutamiento o la traducción de direcciones.

Las principales limitaciones no se originan en Internet, debido a que por naturaleza es un ambiente heterogéneo donde el transporte y entrega de las tramas implica una operación con el mejor esfuerzo y no asegura confiabilidad ni alta velocidad. De todas formas utilizando compresión previa a la encriptación puede mejorar el rendimiento.

Es el dispositivo o gateway de seguridad donde se ejecuta IPSec, quien es sensible a limitaciones que afectan la perfomance. Es importante que un gateway maneje un ancho de banda mayor al de la red a la cual se conecta, caso contrario deberá descartar paquetes provocando interrupciones en el tráfico afectando directamente los paquetes transportados mediante UDP e inclusive el tráfico TCP.

Otro aspecto que afecta la perfomance en un dispositivo es el retardo, o tiempo adicional de procesamiento en el equipo, previo a la salida del paquete. En la práctica se considera como asociado al tiempo en que tardan los datos en viajar desde el origen a su destino. En un dispositivo que cumple más de una función, incluyendo el procesamiento de IPSec, su retardo será importante. Es muy diferente procesar solo el encabezado (firewall de filtrado de paquetes) que sobre todo el datagrama completo con mecanismos de encriptado, sumado la carga u overhead del tratamiento e intercambio de claves, que requiere un uso intensivo del CPU.

25

2.14.2. Generic Routing Encapsulation protocol (GRE)

El protocolo GRE o de encapsulación genérica de enrutamiento, es un estándar de facto desarrollado por Cisco. Está diseñado para encapsular protocolos de capa de red

arbitrarios dentro de otro protocolo de capa de red arbitrario15. Existen al menos tres RFCs referidas directamente con este protocolo, la RFC 1701 define en forma general el protocolo y el formato de su encabezado. La RFC 1702 refiere a su uso en conjunto con IP, tanto como protocolo de carga como de transporte. Finalmente la RFC 2784 es un memo que actualiza las anteriores, redefiniendo el formato del encabezado y definiendo como obsoletos a algunos de sus campos. Sin embargo deja establecido las operaciones con implementaciones anteriores. Esta sección se basa en la descripción del protocolo de acuerdo a esta última RFC pero con algunas referencias a las anteriores. En general GRE se ejecuta en la capa IP, utilizando datagramas IP como carga y como

transporte16.

GRE crea un vínculo punto-a-punto con routers en cada extremo sobre una red IP. Se diferencia de IPSec en que maneja tráfico multicast. De hecho GRE se utiliza en conjunto con este protocolo para esta tarea debido a la naturaleza unicast de IPSec. La estructura general de un paquete GRE encapsulado para el envío es la siguiente:

Figura 2-22 Paquete GRE encapsulado

Cuando se usa IP como protocolo de carga y de entrega, los campos TTL, TOS y opciones de seguridad IP pueden ser copiados desde el paquete de carga a los mismos campos en el encabezado del paquete de entrega. El campo TTL del paquete de carga se decrementa cuando se desencapsula.

Cuando el extremo de egreso del túnel desencapsula un paquete GRE, el cual contiene un datagrama IP como carga, la dirección destino en el encabezado IP debe ser utilizado para reenviar dicho datagrama y el campo TTL debe ser decrementado. Si la dirección IP destino resultara ser del extremo que encapsuló, entonces deberá descartarse el datagrama para evitar un bucle o loop.

Operaciones Conjuntas con otros protocolos

La utilización más común y simple de este protocolo, es la creación de túneles que permiten la utilización de un espacio de direcciones internas, a través de un espacio público de direccionamiento, para el tráfico de datos. Esto es posible por la capacidad de GRE de encapsular un datagrama IP y a su vez integrar la carga de otro datagrama IP que le permitirá atravesar una red IP hasta su destino.

La desventaja es que la carga que encapsula GRE no está en condiciones de atravesar una red insegura como Internet ya que los datos no están encriptados. Por lo tanto hace falta alguna medida de seguridad para poder utilizar GRE en un entorno VPN. Es en esta situación que se utiliza en conjunto con IPSec, el cual le suma la seguridad de sus mecanismos de encriptación y autenticación. Pero esta relación es bilateral, ya que IPSec falla en aquellos escenarios donde la naturaleza de las comunicaciones es del tipo multicast: propagación de la actualización de rutas en un entorno de enrutamiento dinámico, tráfico de voz y video, etc.

La manera de salvar este escollo es mediante la encapsulación del paquete multicast en un paquete GRE. A continuación este último, se encapsula en un paquete IPSec (Figura 2-23), para ser enviado a la red destino en forma segura, donde el extremo remoto del túnel IPSec, desencapsulará el paquete multicast y lo entregará a los dispositivos que integren el grupo multicast destino.

Utilizar GRE para crear túneles como mecanismo para una VPN, genera algunas desventajas principalmente asociadas a la carga en tareas de administración de la VPN, escalabilidad en cuanto al crecimiento del número de túneles, perfomance y QoS.

Debido a que los túneles GRE deben ser configurados en forma manual, existe una relación directa entre la cantidad de túneles a configurar y la cantidad de tarea administrativa necesaria para mantener dichos túneles. También la capacidad de procesamiento requerida para la encapsulación GRE, está en con el número de túneles configurados.

Figura 2-23 Encapsulamiento Multicast con GRE asegurado con IPSec

2.14.3. Multiprotocol Label Switching (MPLS)

MPLS se dice multiprocolo porque se aplica a cualquier protocolo de red, pero su uso más habitual es con el protocolo IP. La esencia de MPLS es la generación de pequeñas etiquetas (labels) de tamaño fijo que cumplen el rol de un encabezado IP pero con menos información. Esta etiqueta se usa para tomar las decisiones de enrutamiento del paquete. MPLS no es un protocolo de capa 2 ni de capa 3 específicamente, sino un protocolo que funciona en conjunto con estos.

En un mecanismo de enrutamiento convencional, cada router que recibe un paquete, verifica el encabezado IP (la dirección destino) para decidir el siguiente salto. Esta decisión es tomada en forma independiente por cada router basado en su análisis del encabezado del paquete y de los resultados de ejecutar algoritmos de enrutamiento. Esto se denomina enrutamiento salto a salto (hop by hop routing).

La selección del siguiente salto se compone de dos funciones. La primera consiste

en clasificar o particionar el conjunto completo de paquetes en clases de equivalencia, también denominadas FEC (Forwarding Equivalence Class). La segunda función mapea cada FEC con el siguiente salto. Los paquetes pertenecerán a una determinada FEC, si la dirección IP destino de cada uno de ellos coincide, en la manera más exacta, con algún prefijo de red existente en la tabla de enrutamiento de ese router. A medida que el paquete atraviesa la red, cada router en su camino lo reexamina y vuelve a realizar este proceso.

En MPLS, la asignación de un determinado paquete a una determinada FEC es realizado solo una vez, en el momento que el paquete ingresa a la red MPLS. La FEC es codificada como un valor de longitud fija denominada etiqueta. Cuando el paquete es reenviado se envía la etiqueta también la cual es utilizada para indexar una tabla donde figura el siguiente salto y una nueva etiqueta. Luego de reemplazarla, el paquete es reenviado al siguiente salto. Cuando el paquete alcanza el último router de la red MPLS, este se encarga de remover la etiqueta y enrutar a través de los algoritmos convencionales.

Los routers dentro de una red MPLS se denominan LSR (Label Switched Routers). Aquellos que se ubican en el ingreso a y egreso de la red, se denominan LER (Label Edge Router) o dispositivos de borde. Estos últimos son los encargados de encapsular el paquete, mientras que los routers pertenecientes al núcleo de la red MPLS, solo se encargan de reenviarlo hasta el router de borde de egreso de la red.

Este método de reenvío permite que, una vez que el paquete fue clasificado en una FEC, no se efectúe ningún análisis posterior del encabezado por parte de los routers que participarán en el transporte del paquete.

VPNS BGP/MPLS

Una de las aplicaciones mas utilizadas de MPLS es el servicio de VPN provisto por un proveedor. Esta es una alternativa viable respecto de los métodos de túneles habituales para implementar VPN.

No existe un modelo de servicio de VPN único ya que cada cliente tiene diversos requerimientos, por ejemplo, pueden diferir en los requisitos de seguridad, cantidad de sitios a interconectar, números de usuarios, complejidad en el esquema de enrutamiento, aplicaciones críticas, volúmenes de tráfico, patrones de tráfico, habilidad del propio personal de networking, etc.

Existen dos opciones: VPN MPLS de capa 3 o capa 2. Uno de los modelos de mayor aceptación por parte de los proveedores para poder manejar esta variabilidad de requerimientos, es el propuesto en la RFC 2547 y RFC2547bis VPN BGP/MPLS. Se trata de una VPN MPLS de capa 3.

Este modelo define un mecanismo que permite a los proveedores de servicios utilizar su red backbone IP para dar servicio VPN a sus clientes. El protocolo de enrutamiento de borde BGP (Border Gateway Protocol) es utilizado para distribuir información de enrutamiento de la VPN a través del backbone mientras que MPLS se encarga de reenviar el tráfico de la VPN entre los sitios que la componen.

Las VPN BGP/MPLS buscan cumplir con lo siguiente:

Facilidad de uso para los clientes

Escalabilidad y flexibilidad para facilitar implementaciones a gran escala.

Soporte de direcciones IP globalmente únicas en la red del cliente y solapamiento de direcciones privadas.

Soporte de solapamiento de VPN, es decir que un sitio puede pertenecer a más de una VPN.

Las VPNs BGP/MPLS toman un datagrama IP de la red del cliente, determinan la dirección IP destino buscando en una tabla de reenvío y luego envían ese datagrama hacia su destino a través de la red del proveedor mediante un LSP.

2.15. PROTOCOLOS DE TÚNEL CAPA 4

Además de los protocolos de capa 2 y capa 3, se pueden considerar, además, dos protocolos para crear túneles pero en las capas superiores. En particular entre la capa de transporte y de aplicación. Se describirán las generalidades de SSH (Secure Shell) y SSL/TLS (Secure SocketsLayer)/ (Transport Layer Security).

2.15.1. Secure Shell (SSH)

Secure Shell es un protocolo cliente-servidor que permite el servicio de login remoto seguro a través de una red insegura. Si bien su cometido principal es la creación de una sesión remota mediante un túnel a un equipo remoto, es posible la transmisión de otra clase de tráfico TCP mediante la redirección de puertos.

Este protocolo consiste de tres componentes principales:

Protocolo de capa de transporte: brinda autenticación del servidor, confidencialidad e integridad con PFS (Perfect Forward Secrecy) ejecutándose sobre la conexión TCP/IP.

El protocolo de autenticación del cliente: opera sobre el protocolo de transporte. Protocolo de conexión: multiplexa el túnel en varios canales lógicos y se ejecuta sobre

el protocolo anterior.

SSH utiliza, en un principio, autenticación basada en host para autenticar el servidor. Este procedimiento es llevado a cabo por la capa de transporte de SSH. Durante esta etapa se utilizan claves públicas de host (host key). Esta capa no realiza la autenticación basada en usuario, la cual es relegada a las capas superiores.

Este procedimiento requiere que el cliente confíe en la clave que le presenta el servidor. Para esto el cliente puede tener un conocimiento previo de la misma y efectuar una comparación, mediante algún mecanismo de firma o encriptación de un hash o certificando la validez de la misma a través de una Autoridad Certificante o CA.

Si bien la segunda alternativa facilita la administración del mapeo nombre de servidor/clave pública, requiere la presencia de una infraestructura PKI (Public Key Infraestructure), la cual no es simple de implementar e implica costos económicos importantes para la organización.

El protocolo de capa de transporte de SSH, es el encargado de autenticar el servidor y negociar el método de intercambio de clave, los algoritmos de encriptación simétrica, de clave pública, de autenticación de mensaje (HMAC) y de hash. El método de intercambio de claves es importante ya que define como generar las claves de sesión a utilizar en la conexión para encriptar y firmar digitalmente, además de establecer como autenticar al servidor.

El protocolo de capa de autenticación de SSH se encarga de efectuar la autenticación basada en usuario. SSH soporta autenticación basada en usuario mediante clave pública, passwords y basada en equipo. En el caso de usar passwords, estas son encriptadas cuando el paquete de autenticación es procesado por la capa inferior de transporte. La autenticación basada en equipo o host, consiste en verificar la identidad del host desde donde el usuario se conecta, junto con la existencia del nombre de usuario. El cliente firma un mensaje con su clave privada y el servidor la verifica con la clave pública del cliente. Luego se verifica que el nombre de usuario enviado por el cliente tenga autorización. Este método no es aconsejable en escenarios que requieran seguridad.

Finalmente el protocolo de capa de conexión se ejecuta por encima de los

protocolos de transporte y autenticación de SSH. Brinda sesiones interactivas de login, ejecución remota de comandos, reenvío de tráfico TCP/IP y de conexiones del servicio de manejo de ventanas X11. Todo estas conexiones son establecidas mediante canales que son multiplexados a través de un único túnel establecido por el protocolo de capa de transporte, a esto se lo denomina multiplexación ascendente(upward multiplexing).

2.15.2. Secure Sockets Layer/Transport Layer Security (SSL/TLS)

SSL fue creado originalmente para asegurar el tráfico web, pero se utiliza también para asegurar protocolos diferentes a HTTP. Brinda confidencialidad a la capa de transporte mediante el uso de criptografía simétrica mientras que la autenticación y manejo de claves se realiza mediante la criptografía de clave pública.

TLS está basado en la versión 3 de SSL, pero no es el mismo protocolo. Se trata de un estándar sobre el cual se basan implementaciones tantos comerciales como abiertas. Brinda privacidad e integridad a los datos transmitidos en una comunicación entre dos aplicaciones.

La interoperabilidad de SSL/TLS es muy alta, no es común los problemas en la interacción entre clientes y servidores de diferentes fabricantes. Dado que no se utiliza el encabezado IP para el procesamiento, sino la conexión autenticada y establecida, SSL/TLS no es afectado por la presencia de dispositivos que efectúen operaciones de traducción de direcciones o NAT.

SSL/TLS soporta una variedad de métodos de autenticación, siendo el más común el uso de certificados digitales para la autenticación tanto del servidor como del cliente (opcional).

Las VPNs SSL pueden transportar cualquier tráfico TCP inclusive tráfico UDP. Debido a que SSL/TLS es un servicio de la capa de transporte, una VPN SSL puede aplicar control de acceso a nivel de aplicación y por supuesto de transporte.

A diferencia de IPSec, el cual es un proceso que se ejecuta en modo kernel o privilegiado, SSL es un protocolo que se ejecuta como proceso a nivel de usuario. Esta característica hace que una solución VPN SSL sea más estable y robusta. Cuando existe una dependencia directa con el sistema operativo, cualquier falla del proceso puede generar inestabilidad a todo el sistema.

2.16. TOPOLOGÍAS

La topología aplicada a las redes de datos, describe las relaciones entre los componentes de una red. Su aplicación más simple define como se interconectan los dispositivos que integran una red. Además, el uso correcto de la terminología topológica evita confusiones cuando se hace referencia a esquemas de redes.

La clasificación más básica de las topologías está en función de la naturaleza de la relación de conectividad de los componentes de la red. Puede ser de naturaleza física como un medio de transmisión (cable tecnología ethernet, fibra óptica, enlace satelital etc.) o de naturaleza lógica, como la ruta que utiliza un flujo de bytes para

conectar dos host. En este caso se considerarán las topologías desde una perspectiva lógica, debido a que las redes privadas virtuales son un objeto lógico, tal como se las define en el primer capítulo.

Lo más importante al estudiar la topología de una red es el impacto de esta sobre otros aspectos que influyen en el desempeño de la misma. Uno de estos aspectos es la escalabilidad la cual es crítica cuando se trata de redes que tienden a crecer o que el número de nodos a interconectar es numeroso y variable. La escalabilidad de una

red se puede definir en función de tres características de su diseño22:

Capacidad de manejar mas conexiones

Facilidad de mantenimiento

Costo

En el caso particular de las VPN, existen otros aspectos que están influenciados por la topología: el mecanismo de distribución de claves para la autenticación de los nodos y la distribución de la información de enrutamiento necesaria para permitir la comunicación entre los componentes de una misma VPN.

2.16.1. Escenarios

En el terreno de las redes privadas virtuales existen básicamente tres escenarios que describen las relaciones entre los nodos de una VPN. Las conexiones entre sitios o redes, la conexión entre un host y una red y la conexión entre solo un par de hosts.

El escenario red a red (Figura 2-24) presenta la conexión de dos o más subredes mediante uno o más túneles. Cada subred consiste de un gateway y al menos un host. EL gateway posee dos interfaces de red, una para conectarse al túnel y la restante para conectarse con la subred interna. El gateway realiza el proceso de creación y eliminación del túnel, así como la aplicación de mecanismos de seguridad al tráfico que reenvía.

Figura 2-24 Escenario Red a Red

El escenario host a red (Figura 2-25) se puede considerar un caso especial del anterior donde una de las partes, en lugar de ser una red, es solo un host y no hay presencia de

un gateway. Este esquema se aprecia en las VPN de acceso remoto, donde los usuarios de una organización se encuentran físicamente alejados de su lugar de trabajo, pero pueden acceder remotamente a los recursos de la red de datos local.

Figura 2-25 Escenario Host a Red

Finalmente en el esquema host a host solo dos equipos podrán establecer una comunicación segura. Este escenario es una reducción del caso host a red. Si hubiera necesidad de comunicar más hosts, entonces serían más apropiados los escenarios anteriores.

Estas formas de relación determinan los esquemas topológicos más habituales en el mundo de las redes: punto a punto, punto multipunto, estrella (hub and spokes) y malla total o parcial (full or partial mesh), aunque también es posible combinar alguna de ellas e implementar una topología híbrida. Su aplicación a las VPNs posee sus ventajas y desventajas.

2.16.2. Topología Punto a Punto

Esta es la topología más simple, ya que es una conexión directa entre dos entidades. Esta relación de conectividad directa aún es válida si en un nivel inferior existen entidades cuya tarea es el reenvío de la comunicación hasta llegar al destino. Es decir, es una comunicación directa en la capa N aun cuando en la capa N-1 es necesario atravesar varios nodos hasta llegar al destino.

Esta topología se puede encontrar en VPNs, como casos particulares de otros esquemas más complejos, como en el caso de la estrella (hub and spoke), donde cada extremo (spoke) tiene un enlace punto a punto con el centro (hub) para poder comunicarse con los demás extremos.

Los ejemplos más simples de VPNs con esta topología son las tradicionales de capa de enlace basadas en servicios ATM o Frame Relay, ya que establecen una conexión punto a punto entre sitios de una organización. También se puede considerar los túneles de capa de red basados en IP que se crean con el mismo fin y conectan dos dispositivos CE, utilizando IPSec o GRE.

Un caso más específico es el servicio VPWS (Virtual Private Wire Service). Se trata de un tipo de VPN de capa 2 provista por el proveedor. Este brinda un servicio de conectividad punto a punto entre los sitios de un cliente. Este servicio emula enlaces dedicados entre los sitios mediante túneles IP dentro del backbone del proveedor,

manteniendo a la vez la infraestructura ATM o Frame Relay existente del cliente. Una forma de realizarlo es utilizando los circuitos virtuales (CV) Frame Relay o ATM entre los dispositivos CE del cliente y PE del proveedor y mapearlos a túneles MPLS (LSP) establecidos a través del backbone.Esta solución presenta problemas de escalabilidad cuando el proveedor tiene que servir varias VPNs, ya que cada LSP deberá ser configurado individualmente y mapeado a cada CV de los clientes. Esto conlleva un gran esfuerzo de administración, además el aumento de los túneles LSP para satisfacer nuevas demandas impactará en la capacidad del manejo de estos en los routers y switchs del proveedor, tanto los equipos de borde (PE) como los pertenecientes al núcleo del backbone (P).

Una mejora al enfoque anterior es el denominado PWE3 (Pseudowire Emulation Edge-to-Edge) VPWS, como lo muestra la Figura 2-26. En esta situación se mejora la escalabilidad utilizando un número fijo de LSP entre los dispositivos PE del backbone del proveedor. Luego se crean conexiones emuladas punto a punto (pseudowires) entre los PE mediante túneles basados en los LSP ya establecidos. Estas conexiones simuladas son encapsulaciones de protocolos de capa 2 (ATM, Frame Relay, Ethernet, etc.) en tramas MPLS. Nuevamente es necesario que cada pseudowire sea configurado en forma individual, afectando la escalabilidad cuando el proveedor sirve varias VPNs. Sin embargo se reduce la carga de procesamiento a solo los routers de borde ya que únicamente en estos se definen los pseudowires.

Figura 2-26 Punto a Punto en VPN VPWS

Para mejorar la escalabilidad, se requiere que las conexiones punto a punto se establezcan mediante un mecanismo automatizado, como por ejemplo el protocolo BGP. En esta situación cada dispositivo PE usa BGP multiprotocolo para anunciar las VPN y dispositivos CE que este controla. Esta información acompaña las etiquetas MPLS utilizadas por los PE para reenviarse datos entre sí. De esta forma, cuando los CE

reciben esta información, poseen los datos necesarios para crear los pseudowires sobre

los PE.

2.16.3. Topología Punto a Multipunto

Esta topología permite establecer más de un camino desde un lugar a múltiples destinos. Cualquier transmisión de datos, originados en un punto de conexión central es recibida por todos los puntos de conexión periféricos, mientras que la comunicación en el otro sentido, desde la periferia, sólo es recibida por el extremo central.

El servicio de VPN de capa de enlace VPLS (Virtual Private LAN Service) brinda un servicio multipunto mediante una configuración de malla completa. Una VPLS es establecida por un proveedor de servicios y emula una LAN tradicional. Permite conectar varios segmentos de LAN, distantes geográficamente, sobre una red de conmutación de paquetes de manera que las redes remotas se comporten como una única LAN. En esta situación los equipos CE no deben seleccionar el pseudowire para reenviar los datos para un destino determinado (topología punto a punto); simplemente reenvían todo el tráfico al dispositivo PE del proveedor, quien se encarga de enviarlo al destino correspondiente.

Esto es posible en redes MPLS donde se establece una topología de malla completa de pseudowires entre los dispositivos PE del proveedor que integran una determinada VPLS. Gracias a este esquema los PE pueden realizar replicación de paquetes (inundación por destino desconocido, broadcast, multicast) y aprendizaje de direcciones MACs tal como lo haría un bridge o switch ethernet.

Para simplificar la configuración de una VPLS, son necesarios mecanismos automáticos para obtener información de los integrantes de la VPLS, como llegar hacia ellos y conectarse finalmente. Esto facilita también el agregado de nuevos nodos y la administración de las conexiones (manejo de pseudowires) entre ellos. De lo contrario el manejo y escalabilidad de la VPN se vería afectada.

2.16.4. Topología Estrella (Hub and Spokes)

Esta es la topología más común en VPNs. Existe un gateway VPN o concentrador (hub) y una serie de clientes (spokes) que establecen una conexión punto a punto con este, un túnel de hecho. Para que pueda existir comunicación entre los clientes remotos, el tráfico de datos deberá ir desde el cliente emisor hasta el concentrador, luego este retransmitirá esos datos hacia el cliente receptor. No existe una conexión directa entre los clientes, toda la comunicación deberá atravesar primero el concentrador.

Esta topología afecta la escalabilidad en cuanto a que está limitada al desempeño y la capacidad de procesamiento del concentrador. Este deberá soportar conexiones simultáneas. Por esta razón el desempeño general de la VPN dependerá fundamentalmente de la capacidad del concentrador. Por otro lado este esquema presenta un único punto de falla en el concentrador mismo. La disponibilidad de la VPN dependerá de la falla de solo uno de sus componentes. Otra desventaja que presenta es que si dos clientes remotos se encuentran geográficamente cerca, igual

deberán enviar su tráfico al concentrador en lugar de utilizar una conexión directa entre ellos.

Sin embargo, este esquema tiene la ventaja de una administración centralizada, respecto del monitoreo, mantenimiento, control de accesos, registro de eventos. Además el hecho de agregar un nuevo componente a la VPN es simple debido a que esta operación se centraliza en el hub.

Una forma de paliar la desventaja que significa un único punto de falla, es una variación de la topología donde exista más de un concentrador, tanto para brindar redundancia como para balancear la carga relacionada con las conexiones simultáneas de los clientes. Existe un esquema donde se busca la redundancia pero en el lado del cliente, duplicando el componente spoke. Esto permite el balanceo del tráfico emitido desde el cliente a través de la duplicación de la conexión con el concentrador. Si bien esta organización brinda la máxima disponibilidad, es prohibitiva en términos de costo en equipos y en la poca conveniencia de invertir recursos en el extremo del cliente.

Esta topología y sus variantes se aplican en los escenarios red a red, tanto para conectar los sitios de una misma organización como así también cuando se implementan VPN extranets con sitios de otras organizaciones.

Las VPN sitio a sitio utilizando IPSec son un ejemplo de la aplicación de esta topología. Es común considerar el uso del protocolo GRE para permitir el tráfico multicast entre los sitios de la VPN. En este caso particular, existen una serie de aspectos relacionados con la escalabilidad debido al protocolo IPSec:

Escalabilidad SA (Asociaciones de Seguridad): se refiere al número de asociaciones de seguridad activas a soportar, así como su detección, eliminación y manejo. Esto es un aspecto importante en el concentrador y no en el cliente. El primero debe mantener una base de datos de SA relacionadas con la conectividad de todos los clientes.

Capacidad de túneles IPSec: Las políticas de seguridad que se aplican pueden impactar en la perfomance del concentrador. La selección de algoritmos criptográficos fuertes lleva a una sobrecarga de la capacidad de cómputo. Hay que balancear el requerimiento de la política y la carga en el mantenimiento de los túneles con un cálculo apropiado de las necesidades futuras de agregaciones de nodos clientes a la VPN.

Capacidad de procesamiento criptográfico: este aspecto está relacionado directamente con el anterior, en términos del throughput de paquetes por segundo que es capaz de procesar el módulo de encriptación.

Capacidad de mantenimiento de túneles GRE: Si bien la mayoría de los dispositivos VPN soportan los túneles GRE, no lo implementan a nivel de hardware. Si se requiere esta encapsulación, la misma no deberá limitar el throughput o el procesamiento en el concentrador.

2.16.5. Topología de Malla Completa o Parcial (Full or PartialMesh)

En un diseño de malla completa (full mesh), cada dispositivo se comunica en forma

directa con todos los demás. En el caso de malla parcial (partial mesh) solo ciertos dispositivos tienen conexión directa entre sí. La razón de ello radica en que no todos requieren más de una conexión. Solo aquellos que requieren alta disponibilidad y que la interrupción de una de sus conexiones no deje al sitio incomunicado con el resto.

Este modelo tiene varios beneficios y una gran desventaja. Los beneficios son:

No existe un único punto de falla, los dispositivos no dependen de un concentrador para la comunicación dentro de la VPN

La perfomance general no está limitada a un solo sistema.

Aquellos dispositivos que están próximos geográficamente, pueden comunicarse directamente sin intermediario.

78

La desventaja radica en el incremento del mantenimiento en cuanto a la distribución de las claves para asegurar las comunicaciones o en la distribución de información de enrutamiento. En particular si se usa IPSec, la creación de asociaciones de seguridad necesarias para cada nodo que se sume a la VPN representa un costo en el mantenimiento. La situación puede mejorar si se utilizan métodos automáticos para la distribución de claves, o la transmisión dinámica de rutas.

Nuevamente los escenarios red a red implementan esta topología cuando hay un requerimiento de alta disponibilidad o bien sea necesario un servicio multipunto como en el caso de las VPLS, donde se crea una topología de malla completa de pseudowires entre los dispositivos PE del proveedor y así los dispositivos del cliente pueden llegar mediante multicast o broadcast hacia las otras redes integrantes de la misma VPLS.