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 tneles o cifrado a otro anfitrin. En el caso de no
residir en el firewall, se debe configurar este para que permita la comunicacin 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 adquisicin, pero puede ser necesario
tener personal capacitado o realizar un contrato anual para tener soporte con algn
proveedor.

2.11.2. Basadas en la Implementacin

Dependen de quien es el responsable de la implementacin de la VPN y su
administracin. Existen dos categoras y una tercera que es una combinacin de las
otras dos.
Dependiente
El proveedor del servicio es el responsable de proveer una solucin llave en mano. La
principal ventaja es que la organizacin no debe cambiar su infraestructura y no necesita
personal con conocimientos en administracin de VPN para su gestin.
La mayor desventaja surge en el mbito de la seguridad. Es recomendable que la
organizacin use una infraestructura AAA y firewall y estar a cargo de su
administracin.
Independiente
En esta categora toda la responsabilidad de la implementacin es de la organizacin. La
encriptacin, autenticacin y autorizacin 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 tecnologas
Hbrida
Esta categora es una combinacin de las categoras anteriormente Mencionadas. Una
parte de la administracin es realizada por la organizacin 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 administracin.

Figura 2: Basada en la Implementacin (Hibrida)

2.11.3. Basada en Seguridad
Se podran mencionar cuatro categoras:

Router a Router

Firewall a firewall

Tneles bajo demanda

Tneles Multiprotocolo bajo demanda

Router a Router
Tneles bajo demanda: El tnel es establecido entre dos routers que se
encuentran en la conexin en el lado del cliente y en el lado del servidor. Puede soportar
mltiples conexiones simultneamente y persisten hasta que la ltima conexin es
terminada. Los routers deben soportar intercambio de claves y algoritmos de
encriptacin. La Figura 2-5 muestra cmo se relacionan los componentes bajo esta
arquitectura.

Figura 2: Tneles bajo demanda (Router a Router)

Tneles multiprotocolo bajo demanda: Es similar a routers bajo demanda con la
particularidad que los routers soportan varios protocolos de tnel. Tiene la particularidad
de que pueden transferir datos no-IP a travs de la red pblica.
Sesiones encriptadas bajo demanda: Cada sesin es encriptada en forma individual.
Tiene un tnel 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 tneles bajo demanda y tneles multiprotocolo bajo demanda. A continuacin
daremos un breve detalle.
Tneles bajo demanda
Es similar a router a router con tnel bajo demanda, con la particularidad que se
reemplazan los routers por firewalls. Es ms seguro y permite que se puedan implementar
auditorias ms complejas.

Figura 2-7 Tneles bajo demanda (Firewall a Firewall)

Tneles multiprotocolo bajo demanda
Generalmente se utilizan L2TP asegurado con IPSec gracias a su caracterstica
multiprotocolo.
2.11.4.

. Iniciadas por el cliente

Cliente a Firewall/Router
Se negocia la sesin entre el cliente y el firewall/router. ste debe soportar el pedido
del cliente de inicio de sesin. El cliente debe poder comunicarse con el sistema
operativo correspondiente.
Cliente a Server
El servidor VPN se encuentra dentro de la intranet corporativa, en vez de cumplir las
funciones de servidor VPN y firewall/Router.
Es ms seguro que el anterior porque el proveedor de servicios ignora la existencia
del tnel.

2.11.5.

Dirigidas
Los datos son encriptados en el capa 5 del Modelo OSI. Es decir en la capa de sesin.
El protocolo ms utilizado en socks 5. Los tneles son unidireccionales. El control de
acceso puede utilizar el identificador del usuario, hora, aplicacin y hasta el contenido del
paquete.
La capa de sesin soporta una mayor variedad de mecanismos de encriptacin. La Figura
2 muestra la distribucin de los componentes.

2.11.6.

Basado en la capa
Depende en que capa del modelo OSI se encuentra configurada la Red
Privada Virtual. Puede ser en la capa de red o la capa de enlace.

Figura 2: Dirigida
Capa de Enlace

Se pueden dividir en:

Conexin 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 Clasificacin de
VPNs en el captulo 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. Tambin se puede
utilizar IPSec.

2.11.7. Basada en Clases

Estas arquitecturas se basan en la complejidad de la configuracin de la VPN y del
tamao. 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 caractersticas.

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 tneles ms rpidos
bajo demanda y ejecutan el proceso de cifrado con mayor rapidez. Ofrecen una
administracin centralizada.
Es aconsejable que soporten los protocolos para establecimiento de tneles PPTP, L2TP
e IPSec. En general este dispositivo se encuentra detrs 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 conexin a travs de una red pblica con un tnel cifrado al servidor
interno de la organizacin o de una lnea de acceso telefnica hacia un servidor de
autenticacin. El servidor puede ser un router, un firewall, una caja negra o un
servidor de autenticacin independiente.

2.11.10.

VPN mltiple servicios

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

CLASE
N

SOFTWARE

PROTOCOLOS
UTILIZADOS

SEGURIDAD

ACCESO

CARACTER

Como mnimo
sistema
operativo
Windows

Soft de
marcacin y
de acceso
remoto.

Soft de
marcacin y
de acceso
remoto

Soft
de
marcaci
n y de
acceso
remoto

PPTP

Filtrado de paquetes ofrecido por

un Gateway, firewall o router

IPSec
DES IKE

Algn
mecanismo
de
Autenticacin de Usuarios, 1
Gateway

IPSec
3DES
IKE

Utiliza Token
5 VPN Gateway o 1
gateway que soporte
500
usuarios
concurrentes
AAA,RADIUS,TACACS, NAT y
firewall
Token y smartcards, 20 VPN
Gateway o 1 gateway que soporte
1000 sesiones simultneas.
AAA,RADIUS,TACACS,
NAT y firewall Servicio de
certificados propio

X.500
LDAP
IPSec
3DES
IKE
LDAP
IPSec
3DES
IKE

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

Tabla 2, VPNs basadas en clases

DSL T1

T1
T3

No soporta

Soporta:
20 sucursal
Soporta siti
Para poder
esta debe so

Soporta:
10 a 100 sit
remotos siti

Es necesario calidad de
servicio en cuanto a
retardo
ISDN Xdsl T1
T3
ISDN Xdls T3
OC3

Soporta: Ci
de usuarios
remotos y s
Tiene la de
administrac
implementa

Soporta: M
10000 usua
sitio, usu
electrnico
real Posee
profesional

2.12. PROTOCOLOS DE TNEL

Un protocolo de tnel es un mecanismo para encapsular un PDU9 denominado de carga o
nativo. Se agrega un encabezado al PDU de carga propio del protocolo de tnel.
Finalmente este nuevo PDU se debe entregar a su destino final mediante un protocolo
de transporte o envo, por lo que es necesario agregar el encabezado correspondiente a
este ltimo.
Esta clase de protocolos se utilizan para el envo de datos de un determinado protocolo a
travs de una red que soporta uno diferente o incompatible. Tambin se usan cuando es
necesario asegurar los datos de carga mediante algn mtodo de encriptacin. 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
pblico se envan paquetes con direcciones privadas.

Figura 2-9 Funcionamiento de un Tnel

Un tnel es un medio para reenviar datos a travs 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 informacin 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 tnel 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 agregndoles un encabezado que
permite reenviarlos a travs del tnel. Los nodos intermedios X e Y solo participan del
proceso de transporte, pero no tienen acceso a la informacin original propia de la
comunicacin entre A y B. Cuando el paquete llega al extremo final o nodo de egreso
Z, del tnel, este le saca el encabezado exterior y reenva el paquete al destino real, el
nodo B.
La utilizacin de tneles permite la separacin del trfico de datos de varias VPNs y del
trfico 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 envan por los tneles sin modificacin, an si se usa Internet para su
transporte.

2.12.1.
Requerimientos de un Tnel
Existen requerimientos deseables en los mecanismos10 de tnel, pero no todos los
protocolos existentes cumplen con todos ellos. Estos son :

Multiplexacin

Protocolo de sealizacin

Seguridad de los datos

Transporte multiprotocolo

Secuenciacin de tramas

Mantenimiento

Manejo de grandes MTU

Sobrecarga mnima

Control de congestin y flujo

Manejo de trfico y Calidad de servicio (QoS)

Multiplexacin
Esto permite el anidamiento de tneles, es decir que puedan existir mltiples tneles
VPN entre dos extremos que han establecido un nico tnel principal, esto implica que
cada extremo del mismo puede soportar varios clientes o VPNs. El trfico de cada
uno se mantendr separado del otro a travs de la existencia de un campo de
multiplexin en los paquetes transmitidos para distinguir la pertenencia a un determinado
tnel.
Compartir un tnel de esta forma, disminuye la demora y el procesamiento asociado al
establecimiento del mismo. Esta caracterstica representa una ventaja ante los problemas
de escalabilidad para un proveedor de servicios VPN ya que solo tiene que mantener una
estructura de tneles de menor envergadura.

Figura 2-10 Multiplexacin de Tneles

Protocolo de sealizacin
Previo al establecimiento de un tnel, se deben configurar una serie de parmetros que
deben ser acordados por los extremos participantes, por ejemplo la direccin de los
extremos, el nivel de seguridad requerido, etc. Finalmente el tnel se puede establecer.
Todo esto es posible por va manual o en forma dinmica mediante el uso de un protocolo
de sealizacin.
La utilizacin de un protocolo de sealizacin, facilita la tarea de administracin del
tnel, tanto su creacin, distribucin y manejo de parmetros o atributos asociados al
mismo, ms an cuando la VPN a la cual pertenecen el o los tneles abarca ms de un
dominio administrativo. En este caso simplifica la coordinacin de la administracin.
Tambin permite que los tneles puedan ser creados bajo demanda, cuando los nodos
que los constituyen son mviles o requieren estar interconectados en forma transitoria. Es
importante que el protocolo permita el transporte de un identificador VPN para asociar
esta con el tnel resultante.
El rol de este protocolo debera ser negociar los atributos del tnel y no transportar
informacin acerca de cmo utilizar el mismo.
Seguridad de los datos
Un protocolo de tnel debe soportar mecanismos que permitan varios niveles de
seguridad. Esto significa incluir mtodos de encriptacin y autenticacin de diversas
fortalezas.
La seguridad de los datos de la VPN en general no depende nicamente de las
capacidades requeridas del tnel recin mencionadas. Es importante considerar otros
mecanismos, como por ejemplo el manejo de varias instancias virtuales de tablas de
enrutamiento y reenvo. Cada par (enrutamiento y reenvo) estarn asociadas a una VPN.
Un mismo dispositivo en el extremo de un tnel, podr manejar varias instancias por
lo tanto varias VPNs. Esto evita el enrutamiento por error del trfico de una VPN hacia
otra, asegurando de esta manera la separacin de los flujos de datos. Otra medida de
seguridad puede ser la autenticacin de los extremos del tnel mediante el uso del
protocolo de sealizacin previo a su creacin.
Transporte Multiprotocolo
Muchas aplicaciones de VPN requieren la transmisin de trfico multiprotocolo, por lo
tanto el protocolo de tnel debera soportar su transporte. Debe existir alguna forma de
identificar el tipo de protocolo que esta siendo enviado por el tnel.
No todos los protocolos de tnel soportan esta caracterstica, para estos existen
extensiones que lo posibilitan. Otros poseen campos especficos para esta sealizacin.
Secuenciacin de Tramas
La secuenciacin podra ser necesaria para una operacin extremo a extremo eficiente
de algn protocolo de tnel o aplicacin en particular. Para esto es necesario un
campo de secuencia en el diseo del protocolo, para garantizar la entrega en orden de los

paquetes.

Mantenimiento
Este requerimiento implica que los extremos monitoreen el estado del tnel 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 travs del protocolo en si,
ejecutando un chequeo en banda en forma peridica y en caso de prdida de conexin
indicar explcitamente el problema. La otra forma es mediante mecanismos fuera de
banda, por ejemplo el uso de protocolos de enrutamiento aplicados a una malla de tneles
(RIP, OSPF), lo cual permite detectar cualquier falla en forma automtica. Otra
herramienta es el uso del protocolo ICMP a travs de mensajes de solicitud de eco para
monitorear el estado del tnel.
Manejo de Grandes MTU
Teniendo en cuenta los dispositivos intermedios que reenvan el trfico del tnel, es
posible que alguno de ellos maneje un valor de Mxima Unidad de Transferencia o
MTU menor al valor manejado desde el extremo de ingreso al tnel. En este caso, es
necesaria alguna clase de fragmentacin. Esto traera inconvenientes de performance en
el nodo donde sucede la fragmentacin, disminuyendo la eficacia general.
Para evitar este inconveniente, el protocolo de tnel puede incorporar capacidad de
segmentacin y ensamblado haciendo uso del nmero de secuencia y alguna clase de
marcador de fin de mensaje.
Sobrecarga Mnima
Es importante este aspecto y ms cuando se transporta trfico de datos sensible a la
demora o al desfasaje temporal, como lo es el trfico de voz y video. Lo que se persigue
con este requerimiento es evitar el procesamiento innecesario en los dispositivos que
establecen el tnel.
Los mecanismos de cifrado y encriptacin imponen una sobrecarga. Por lo tanto se
debera minimizar la sobrecarga u overhead tomando en cuenta la necesidad de aplicar
seguridad a los datos. En general el objetivo debera ser minimizar el overhead
alrededor de la necesidad de seguridad del trfico de datos.
Cuando se implementan las VPN dial-up, o de acceso remoto discado, mediante el uso de
tneles voluntarios, existe la posibilidad de sobrecarga significante si se utilizan enlaces
de poco ancho de banda.
Control de Congestin y Flujo
Existen protocolos de tnel, como L2TP, que incorporan procedimientos para
el control de flujo y congestin. Estos fueron pensados para mejorar la performance de la
transmisin cuando se utilizaban redes que podan generar prdidas de paquetes con la
compresin PPP. Otra razn era crear un buffer al momento de utilizar lneas con menor
capacidad de transferencia. Finalmente estos esquemas se aplicaron a los canales
de control en lugar de aplicarlos al trfico de datos.

En general no est claro si es conveniente incorporar estas caractersticas en el diseo de

los protocolos de tnel, en gran medida por el hecho de la predominancia del trfico
TCP y el hecho de que TCP posee sus propios y eficientes mecanismos extremos a
extremo de control de flujo y congestin.
Manejo de Trfico y QoS
Los usuarios de un servicio de VPN, podran desear caractersticas de Calidad de
Servicio como sucede con los dems servicios WAN. Para el caso de las VPN, lograr
aplicar QoS va a depender de las caractersticas de manejo de trfico que puedan efectuar
los nodos involucrados en la VPN y de la red de acceso o backbone donde se
implemente.
2.13. PROTOCOLOS DE TNEL CAPA 2
Los tneles 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 travs de una lnea serie. Este
requiere una conexin full-duplex y puede ser sincrnico o asincrnico. Puede
encapsular IP o no IP a travs de lneas series.
Las funciones que realiza son administrar las direcciones IP del trfico no IP. Configura
y realiza las pruebas necesarias para establecer el enlace, encapsula los datagramas y
realiza la deteccin de errores durante la transmisin. Tambin realiza la multiplexacin
de los protocolos de capa 2 y renegocia parmetros como la compresin 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 transmisin.
Funciones de LCP
Realiza las siguientes funciones:

Ayudan a establecer el enlace PPP.

Configura y establece el enlace para satisfacer los requerimientos de comunicacin 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 tnel al servidor de la organizacin. Permite realizar una
conexin por marcacin y soporta protocolos que no sean IP.
PPTP es una extensin de PPP y por lo tanto no soporta mltiples conexiones. PPTP es
el encargado de establecer y terminar las conexiones fsicas entre las partes,
autenticar los clientes PPTP, encriptar datagramas de protocolos no IP e IP para crear
datagramas PPP y asegurar el intercambio de informacin 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 transaccin PPTP. Existe un
cliente, el cual es el que inicia la transaccin a travs de una conexin realizada con un
modem a travs de una marcacin. Si el NAS del proveedor acepta la comunicacin
entonces se puede establecer el tnel con el dispositivo VPN a travs de la red pblica.
En la Figura 2-12 podemos observar la relacin entre PPP y PPTP.

Figura 2-12 Componentes en una conexin PPTP

El dispositivo NAS debe poder soportar mltiples 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 prdida la conexin realiza una
transmisin peridica de echo entre el cliente y el servidor utilizando la conexin
TCP establecida. Brevemente resumiremos como es el proceso de transmisin los
datos basndonos 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 direccin IP de cliente

PPTP y la del servidor destino.

La capa de enlace suma un encabezamiento y una cola, el cual viaja a travs del tnel
establecido.
Esto es encapsulado dentro del protocolo de transmisin 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 encriptacin y compresin se utiliza los servicios brindados por PPP. En
cuanto a la autenticacin 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 ao 1996. El objetivo era permitir que
protocolos no IP pudieran utilizarse sobre Internet. El usuario hace una conexin PPP
al proveedor de marcacin y se conectan a sus organizaciones a travs de L2F.

Figura 2-14 Componentes en el Protocolo L2F

L2F provee la encriptacin de datos y la autenticacin utilizando CHAP, EAP
(Extensible Authentication Protocol) y SPAP (Shiva Password Authentication Protocol).
Tambin puede emplear RADIUS y TACACS como servicios adicionales.
Como desventajas se puede mencionar que esta solucin requiere un mantenimiento
costoso y son dependientes del proveedor que debe implementar L2F. No provee control
de flujo, lo que resulta en retransmisin de trfico y provoca una comunicacin ms
lenta. Es ms lento que PPTP debido al proceso de autenticacin y encriptacin.

2.13.4.

Layer 2 Tunneling Protocolo (L2TP)

En 1998 las compaas que desarrollaron PPTP y Cisco que trabaj con L2F acordaron
una nueva especificacin para el establecimiento de tneles 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 configuracin para proteger el trafico L2TP a travs de redes IP y no IP.
Las ventajas que tiene es que soporta multiprotocolo y tecnologas como por ejemplo IP,
ATM, Frame Relay y PPP. No requiere implementacin de software especfico como
15

drivers o soporte en el sistema operativo. Permite que clientes con IP privadas se

comuniquen a travs de redes pblicas con sitios remotos. Y por ltimo se puede
mencionar que la autorizacin y autenticacin 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 tnel 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 conexin entre el LAC y el sistema remoto es mediante un enlace PPP. Un
LNS es el otro extremo del tnel L2TP y representa la terminacin lgica de la sesin
PPP que es enviada por el tnel.
Modos de tnel
L2TP soporta los modos de tnel obligatorio y voluntario. En el modo obligatorio Figura
2-15, el proveedor es el encargado de establecer entre el LAC y el LNS el tnel 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 Tnel obligatorio

En el tnel voluntario Figura 2-16, el usuario remoto acta de LAC. El tnel
es transparente para el proveedor como ocurre con los tneles basados en PPTP.
Entre las ventajas que podemos mencionar esta que es una solucin genrica,
independiente de la plataforma. Puede soportar la transmisin a travs de enlaces
WAN no IP sin la necesidad de IP. No se requiere configuracin en el proveedor y en el
cliente. Permite que la autenticacin sea realizada por la organizacin y no por el
proveedor. Provee control de flujo. Es ms rpida que L2F. Permite que clientes remotos
con IP privada puedan conectarse a su organizacin a travs de redes pblicas. Se
puede utilizar IPSec para poder brindar una mayor seguridad.
Como desventajas podemos mencionar que es ms lento que PPTP o L2F
cuando se utiliza IPSec para autenticacin de cada paquete y es ms complejo de
16

implementar que PPTP.

Figura 2-16 L2TP Tnel voluntario

Caracterstica
Soporta multiprotocolo
Soporta
mltiples
conexiones
Soporta
mltiples
conexiones por
Modos de Tnel

PPTP
Si
No

L2F
Si
Si

L2TP
Si
Si

No

Si

Si

Voluntario

Voluntario y
Voluntario y
Obligatorio
Obligatorio
IP/UDP IP/FR IP/ATM IP/UDP IP/FR IP/ATM

Protocolo de Entrega

IP/GRE

Protocolo de Control

TCP Puerto
1723

Autenticacin

MS-CHAP PAP

Encriptacin

MPPE

UDP Puerto 1701

UDP Puerto 1701

CHAP PAP SPAP

RADIUS TACACS

CHAP PAP SPAP EAP IPSec

TACACS

MPPE IPSec

MPPE IPSec ECP

Tabla 2-2 Comparativa protocolos Capa 2

2.14. PROTOCOLOS DE TNEL CAPA 3
En la siguiente seccin se describir los principales protocolos de tnel 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 extensin del protocolo IP que brinda seguridad a IP y a los protocolos de
capa superior. Fue desarrollado para el nuevo estndar de IP versin 6 (IPv6) y luego
adaptado para implementarlo en la versin 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 Autenticacin (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 Autenticacin 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 tnel 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 HMAC 14 (Hash Message
Authentication Code) o Cdigo de autenticacin 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 encriptacin simtricos estndar de elevada fortaleza como
3DES, AES o Blowfish para asegurar la confidencialidad del trfico transportado. IPSec
protege la comunicacin respecto de ataques de denegacin de servicio o ataques de
repeticin, mediante el mecanismo de ventana deslizante. Los nmeros de secuencia
de los paquetes deben estar dentro del rango aceptado por la ventana, sino son
descartados.
Para encapsular y desencapsular los paquetes IPSec, los extremos participantes
18

necesitan un mecanismo para mantener informacin como claves secretas, algoritmos,

direcciones IP utilizadas en la conexin etc. Estos parmetros 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 parmetros:
Direcciones IP origen y destino del encabezado IPSec resultante (direcciones que
coinciden con las de los pares que establecen la comunicacin segura).

El protocolo IPSec a utilizar (AH o ESP).

Algoritmo y claves secretas a utilizar.

SPI (Security Parameter Index) de la SA. Es un nmero de 32 bits que identifica la SA.
Algunas implementaciones de bases de datos de SA permiten, adems,
almacenar estos parmetros:

Modo IPSec (tnel o transporte).

Tamao de la ventana deslizante.

Tiempo de duracin de la SA.

Una SA representa una conexin unidireccional. IPSec requiere que se definan
dos SA para una comunicacin bidireccional o full duplex. Las asociaciones solo
determinan como proteger el trfico. Las Polticas de Seguridad o SP establecen que
trfico proteger y cundo. Las SP se almacenan a su vez en una SPD o base de datos de
polticas de seguridad. Una SP define los siguientes parmetros:

Direcciones IP Origen y destino de cada paquete. En modo transporte estas

direcciones coinciden con las IP almacenadas en la SA. En modo tnel estas podran
diferir.
Puerto y protocolo a proteger. Algunas implementaciones de IPSec no permiten estos
parmetros, en estos casos se aseguran todos los paquetes.
La SA a utilizar.
La SPD discrimina el trfico entrante o saliente, de forma tal que puede
descartar el paquete en trnsito, ignorarlo o aplicar el servicio de seguridad de acuerdo a
la asociacin de seguridad relacionada con esa entrada de la SPD.
La SPD debe ser consultada durante el procesamiento de todo el trfico,
entrante y saliente. Por esta razn esta contendr entradas diferentes para uno y
otro. Adems cada interfaz de red que es protegida por IPSec tendr asociada sendas
bases, de polticas y de asociaciones, para el trfico entrante y saliente.
Cada implementacin 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 accin 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 creacin de entradas y la definicin de los filtros selectores,
adems 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 continuacin se determina si existe una Asociacin 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 autenticacin de encriptacin y
las claves a utilizar.
Cuando varios nodos participan de una VPN que utiliza IPSec para crear los tneles,
surge un inconveniente al momento de compartir informacin para la comunicacin
dentro de la VPN. Durante la creacin de las Asociaciones de Seguridad, se deben
difundir las claves secretas y los algoritmos de encriptacin a utilizar.
El intercambio de claves es un proceso crtico ya que en esta etapa an no hay un medio
seguro establecido para transmitir esta informacin. 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 encriptacin
simtrica mediante el algoritmo Diffie Hellman de intercambio de claves. Una vez
compartidos en forma segura los datos necesarios, IKE se encarga en forma peridica de
regenerar claves que protegen la confidencialidad de las claves para encriptacin
simtrica.
Protocolo AH
Este protocolo se encarga de autenticar los datagramas asegurando la integridad de los
datos incluyendo la direccin IP de origen, brindando adems proteccin contra
ataques de repeticin de datagramas (replay attacks). Para establecer la integridad de
los datos calcula un cdigo de autenticacin 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 Autenticacin del
encabezado AH.

Figura 2-18 Encabezado AH

20

Los campos del encabezado AH son:

Prximo Encabezamiento: identifica el tipo de datos de la carga til, es decir el

protocolo de capa superior. Utiliza 1 byte.

Longitud
byte.

Reservado: utiliza 2 bytes.

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

Nmero de Secuencia: Previene los ataques de repeticin (replay) en forma opcional y

adems sirve para mantener una recepcin ordenada de paquetes. Este campo almacena
un nmero que se incrementa en uno cuando un paquete es enviado en forma consecutiva
a la misma direccin y con el mismo SPI. Utiliza 4 bytes.

Datos de Autenticacin: Compendio (Digest) calculado mediante el HMAC, utilizado

por el receptor para comparar lo recibido luego de aplicar la misma operacin al
datagrama.

del

encabezamiento:

identifica

el

tamao

del encabezado, utiliza 1

AH puede usarse solo o junto con ESP cuando se usa el modo tnel. Cuando se utiliza el
modo transporte, el encabezado AH se coloca justo detrs 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 tnel, 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 autenticacin 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 traduccin de
direcciones de red o NAT, debido a que su proteccin de integridad abarca campos del
encabezado IP como la direccin 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 ms 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 vara si adems de la encriptacin se usa autenticacin (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 tnel 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 tnel.
El proceso de encriptado incluye todos los campos posteriores al encabezado ESP,
pero no este mismo. La autenticacin se aplica a lo encriptado ms 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 tnel.

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.

Nmero de Secuencia: igual que en AH.

Campo de datos IP (payload)

23

Vector de Inicializacin: Utilizado

requiere datos de sincronizacin. Este
misma carga resulten en dos cargas
encriptacin simtrica son vulnerables a
vectores de inicializacin.

Encabezado TCP

Datos

Cola ESP

Relleno (Padding): Se usa en caso que el algoritmo de encriptado requiera que el

texto a encriptar sea mltiplo de cierta cantidad de bytes (cifrado en bloques).
Tambin es necesario para lograr un mltiplo 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 nmero mltiplo 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 autenticacin: Es opcional y solo aparece si se utiliza ESP con autenticacin.

Su longitud vara segn el algoritmo de Hash empleado: 16 bytes si es MD5 o 20 bytes si
es SHA.
ESP puede utilizarse solamente con encriptacin o incluyendo adems autenticacin.
Otra alternativa es con encriptado nulo, o sea sin encriptacin pero con
autenticacin. ESP puede combinarse con AH.

en el proceso de encriptacin si este

vector sirve para que dos paquetes con la
encriptadas diferentes. Los algoritmos de
ataques de frecuencia si no se utilizaran los

Si bien ESP puede autenticar, no abarca al encabezamiento IP externo, es decir

no lo protege de cualquier alteracin en aquellos campos que no deberan cambiar. Por
ejemplo, lo anterior podra derivar en la fragmentacin del datagrama si se alterara el
campo correspondiente. Esta operacin podra permitir la insercin de datagramas de
ataque.
Protocolo IKE
Tambin conocido como ISAKMP/Oakley (Internet Security Association and Key
Management Protocol), este protocolo resuelve el problema ms importante relacionado
con las comunicaciones seguras: la autenticacin de los pares, el intercambio de claves
simtricas, creacin de las SA y actualizacin 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 Asociacin de Seguridad ISAKMP (ISAKMP SA). En la segunda, esta SA
es utilizada para negociar y establecer las SA propias de la comunicacin IPSec (IPSec
SA).

24

La autenticacin 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 autenticacin 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
proteccin 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 autenticacin y protege la operacin de ataques del tipo
mencionado anteriormente. Las SA negociadas finalmente son al menos dos, una para
cada direccin de la comunicacin.
Rendimiento
La utilizacin de IPSec en las comunicaciones requiere capacidad de procesamiento. En
particular con ESP esta necesidad se evidencia en la encriptacin y desencriptacin de
los paquetes, considerando la complejidad de los algoritmos empleados y en la
autenticacin 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
verificacin en el otro, son tareas mucho ms complejas que el enrutamiento o la
traduccin de direcciones.
Las principales limitaciones no se originan en Internet, debido a que por naturaleza es
un ambiente heterogneo donde el transporte y entrega de las tramas implica una
operacin con el mejor esfuerzo y no asegura confiabilidad ni alta velocidad. De
todas formas utilizando compresin previa a la encriptacin 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 trfico afectando directamente los paquetes transportados
mediante UDP e inclusive el trfico 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 prctica se
considera como asociado al tiempo en que tardan los datos en viajar desde el origen
a su destino. En un dispositivo que cumple ms de una funcin, 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 encapsulacin genrica de enrutamiento, es un estndar de facto
desarrollado por Cisco. Est diseado 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 seccin se basa en la descripcin 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 vnculo punto-a-punto con routers en cada extremo sobre una red IP. Se
diferencia de IPSec en que maneja trfico 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 envo 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 tnel desencapsula un paquete GRE, el cual contiene
un datagrama IP como carga, la direccin destino en el encabezado IP debe ser
utilizado para reenviar dicho datagrama y el campo TTL debe ser decrementado. Si la
direccin 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 utilizacin ms comn y simple de este protocolo, es la creacin de tneles que
permiten la utilizacin de un espacio de direcciones internas, a travs de un espacio
pblico de direccionamiento, para el trfico 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 estn encriptados. Por lo tanto hace
falta alguna medida de seguridad para poder utilizar GRE en un entorno VPN. Es en esta
situacin que se utiliza en conjunto con IPSec, el cual le suma la seguridad de sus
mecanismos de encriptacin y autenticacin. Pero esta relacin es bilateral, ya que IPSec
falla en aquellos escenarios donde la naturaleza de las comunicaciones es del tipo
multicast: propagacin de la actualizacin de rutas en un entorno de enrutamiento
dinmico, trfico de voz y video, etc.
La manera de salvar este escollo es mediante la encapsulacin del paquete multicast en
un paquete GRE. A continuacin este ltimo, se encapsula en un paquete IPSec (Figura 223), para ser enviado a la red destino en forma segura, donde el extremo remoto del tnel
IPSec, desencapsular el paquete multicast y lo entregar a los dispositivos que integren
el grupo multicast destino.
Utilizar GRE para crear tneles como mecanismo para una VPN, genera algunas
desventajas principalmente asociadas a la carga en tareas de administracin de la VPN,
escalabilidad en cuanto al crecimiento del nmero de tneles, perfomance y QoS.
Debido a que los tneles GRE deben ser configurados en forma manual, existe una
relacin directa entre la cantidad de tneles a configurar y la cantidad de tarea
administrativa necesaria para mantener dichos tneles. Tambin la capacidad de
procesamiento requerida para la encapsulacin GRE, est en con el nmero de
tneles 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
ms habitual es con el protocolo IP. La esencia de MPLS es la generacin de pequeas
etiquetas (labels) de tamao fijo que cumplen el rol de un encabezado IP pero con
menos informacin. Esta etiqueta se usa para tomar las decisiones de enrutamiento
del paquete. MPLS no es un protocolo de capa 2 ni de capa 3 especficamente,
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 direccin destino) para decidir el siguiente salto. Esta
decisin es tomada en forma independiente por cada router basado en su anlisis 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 seleccin del siguiente salto se compone de dos funciones. La primera consiste
en
clasificar o particionar el conjunto completo de paquetes en clases de

equivalencia, tambin denominadas FEC (Forwarding Equivalence Class). La segunda

funcin mapea cada FEC con el siguiente salto. Los paquetes pertenecern a una
determinada FEC, si la direccin IP destino de cada uno de ellos coincide, en la manera
ms exacta, con algn 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 asignacin 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 enva la etiqueta tambin 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 travs 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 ncleo de la red MPLS,
solo se encargan de reenviarlo hasta el router de borde de egreso de la red.
Este mtodo de reenvo permite que, una vez que el paquete fue
clasificado en una FEC, no se efecte ningn anlisis posterior del encabezado
por parte de los routers que participarn 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 mtodos de tneles
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, nmeros de usuarios, complejidad en el esquema de
enrutamiento, aplicaciones crticas, volmenes de trfico, patrones de trfico, habilidad
del propio personal de networking, etc.
Existen dos opciones: VPN MPLS de capa 3 o capa 2. Uno de los
modelos de mayor aceptacin por parte de los proveedores para poder manejar esta
variabilidad de requerimientos, es el propuesto en la RFC 2547 y RFC
2547bis 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
informacin de enrutamiento de la VPN a travs del backbone mientras que MPLS se
encarga de reenviar el trfico 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 ms de

una VPN.
Las VPNs BGP/MPLS toman un datagrama IP de la red del cliente,
determinan la direccin IP destino buscando en una tabla de reenvo y luego envan ese
datagrama hacia su destino a travs de la red del proveedor mediante un LSP.

2.15. PROTOCOLOS DE TNEL CAPA 4

Adems de los protocolos de capa 2 y capa 3, se pueden considerar, adems,
dos protocolos para crear tneles pero en las capas superiores. En particular entre la capa
de transporte y de aplicacin. Se describirn 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 travs de una red insegura. Si bien su cometido principal es la creacin
de una sesin remota mediante un tnel a un equipo remoto, es posible la transmisin
de otra clase de trfico TCP mediante la redireccin de puertos.

Este protocolo consiste de tres componentes principales:

Protocolo de capa de transporte: brinda autenticacin del servidor,

confidencialidad e integridad con PFS (Perfect Forward Secrecy) ejecutndose sobre la
conexin TCP/IP.

El protocolo de autenticacin del cliente: opera sobre el protocolo de transporte.

Protocolo de conexin: multiplexa el tnel en varios canales lgicos y se ejecuta sobre

el protocolo anterior.
SSH utiliza, en un principio, autenticacin 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 pblicas de host (host key). Esta capa no realiza la
autenticacin basada en usuario, la cual es relegada a las capas superiores.
Este procedimiento requiere que el cliente confe en la clave que le presenta el
servidor. Para esto el cliente puede tener un conocimiento previo de la misma y efectuar
una comparacin, mediante algn mecanismo de firma o encriptacin de un hash o
certificando la validez de la misma a travs de una Autoridad Certificante o CA.
Si bien la segunda alternativa facilita la administracin del mapeo nombre de
servidor/clave pblica, requiere la presencia de una infraestructura PKI (Public
Key Infraestructure), la cual no es simple de implementar e implica costos econmicos
importantes para la organizacin.
El protocolo de capa de transporte de SSH, es el encargado de autenticar el
servidor y negociar el mtodo de intercambio de clave, los algoritmos de encriptacin
simtrica, de clave pblica, de autenticacin de mensaje (HMAC) y de hash. El mtodo
de intercambio de claves es importante ya que define como generar las claves de sesin a
utilizar en la conexin para encriptar y firmar digitalmente, adems de establecer como
autenticar al servidor.
El protocolo de capa de autenticacin de SSH se encarga de efectuar la
autenticacin basada en usuario. SSH soporta autenticacin basada en usuario
mediante clave pblica, passwords y basada en equipo. En el caso de usar passwords,
estas son encriptadas cuando el paquete de autenticacin es procesado por la capa
inferior de transporte. La autenticacin 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 pblica del cliente. Luego se verifica que el nombre de usuario
enviado por el cliente tenga autorizacin. Este mtodo no es aconsejable en escenarios
que requieran seguridad.

Finalmente el protocolo de capa de conexin se ejecuta por encima de los

protocolos de transporte y autenticacin de SSH. Brinda sesiones interactivas de login,
ejecucin remota de comandos, reenvo de trfico TCP/IP y de conexiones del
servicio de manejo de ventanas X11. Todo estas conexiones son establecidas mediante
canales que son multiplexados a travs de un nico tnel establecido por el protocolo de
capa de transporte, a esto se lo denomina multiplexacin ascendente(upward
multiplexing).
2.15.2. Secure Sockets Layer/Transport Layer Security (SSL/TLS)
SSL fue creado originalmente para asegurar el trfico web, pero se utiliza
tambin para asegurar protocolos diferentes a HTTP. Brinda confidencialidad a la capa
de transporte mediante el uso de criptografa simtrica mientras que la autenticacin
y manejo de claves se realiza mediante la criptografa de clave pblica.
TLS est basado en la versin 3 de SSL, pero no es el mismo protocolo. Se
trata de un estndar sobre el cual se basan implementaciones tantos comerciales como
abiertas. Brinda privacidad e integridad a los datos transmitidos en una comunicacin
entre dos aplicaciones.
La interoperabilidad de SSL/TLS es muy alta, no es comn los problemas en
la interaccin entre clientes y servidores de diferentes fabricantes. Dado que no se
utiliza el encabezado IP para el procesamiento, sino la conexin autenticada y
establecida, SSL/TLS no es afectado por la presencia de dispositivos que efecten
operaciones de traduccin de direcciones o NAT.
SSL/TLS soporta una variedad de mtodos de autenticacin, siendo el ms
comn el uso de certificados digitales para la autenticacin tanto del servidor como del
cliente (opcional).
Las VPNs SSL pueden transportar cualquier trfico TCP inclusive trfico
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 aplicacin 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 caracterstica hace que una solucin VPN SSL sea ms 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. TOPOLOGAS
La topologa aplicada a las redes de datos, describe las relaciones entre los componentes
de una red. Su aplicacin ms simple define como se interconectan los dispositivos que
integran una red. Adems, el uso correcto de la terminologa topolgica evita confusiones
cuando se hace referencia a esquemas de redes.
La clasificacin ms bsica de las topologas est en funcin de la naturaleza de la
relacin de conectividad de los componentes de la red. Puede ser de naturaleza fsica
como un medio
de transmisin (cable tecnologa ethernet, fibra ptica, enlace
satelital etc.) o de naturaleza lgica, como la ruta que utiliza un flujo de bytes para

conectar dos host. En este caso se considerarn las topologas desde una perspectiva
lgica, debido a que las redes privadas virtuales son un objeto lgico, tal como se las
define en el primer captulo.
Lo ms importante al estudiar la topologa de una red es el impacto de esta sobre otros
aspectos que influyen en el desempeo de la misma. Uno de estos aspectos es la
escalabilidad la cual es crtica cuando se trata de redes que tienden a crecer o que
el nmero de nodos a interconectar es numeroso y variable. La escalabilidad de una
red se puede definir en funcin de tres caractersticas de su diseo22:

Capacidad de manejar mas conexiones

Facilidad de mantenimiento

Costo

En el caso particular de las VPN, existen otros aspectos que estn influenciados por la
topologa: el mecanismo de distribucin de claves para la autenticacin de los nodos y
la distribucin de la informacin de enrutamiento necesaria para permitir la comunicacin
entre los componentes de una misma VPN.
2.16.1.

Escenarios
En el terreno de las redes privadas virtuales existen bsicamente tres escenarios que
describen las relaciones entre los nodos de una VPN. Las conexiones entre sitios o redes,
la conexin entre un host y una red y la conexin entre solo un par de hosts.
El escenario red a red (Figura 2-24) presenta la conexin de dos o ms subredes
mediante uno o ms tneles. Cada subred consiste de un gateway y al menos un host. EL
gateway posee dos interfaces de red, una para conectarse al tnel y la restante para
conectarse con la subred interna. El gateway realiza el proceso de creacin y
eliminacin del tnel, as como la aplicacin de mecanismos de seguridad al trfico
que reenva.

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 organizacin se encuentran fsicamente 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 podrn establecer una
comunicacin segura. Este escenario es una reduccin del caso host a red. Si hubiera
necesidad de comunicar ms hosts, entonces seran ms apropiados los escenarios
anteriores.
Estas formas de relacin determinan los esquemas topolgicos ms 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 tambin es posible combinar
alguna de ellas e implementar una topologa hbrida. Su aplicacin a las VPNs posee
sus ventajas y desventajas.
2.16.2.

Topologa Punto a Punto

Esta es la topologa ms simple, ya que es una conexin directa entre dos entidades.
Esta relacin de conectividad directa an es vlida si en un nivel inferior existen
entidades cuya tarea es el reenvo de la comunicacin hasta llegar al destino. Es decir,
es una comunicacin directa en la capa N aun cuando en la capa N-1 es necesario
atravesar varios nodos hasta llegar al destino.
Esta topologa se puede encontrar en VPNs, como casos particulares de otros esquemas
ms 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 dems extremos.
Los ejemplos ms simples de VPNs con esta topologa son las tradicionales de capa de
enlace basadas en servicios ATM o Frame Relay, ya que establecen una conexin
punto a punto entre sitios de una organizacin. Tambin se puede considerar los tneles
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 ms especfico 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 tneles 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 tneles MPLS (LSP)
establecidos a travs del backbone.
Esta solucin 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
administracin, adems el aumento de los tneles 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 ncleo del backbone (P).
Una mejora al enfoque anterior es el denominado PWE3 (Pseudowire Emulation Edgeto-Edge) VPWS, como lo muestra la Figura 2-26. En esta situacin se mejora la
escalabilidad utilizando un nmero fijo de LSP entre los dispositivos PE del backbone
del proveedor. Luego se crean conexiones emuladas punto a punto (pseudowires) entre
los PE mediante tneles 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 situacin cada dispositivo PE usa BGP multiprotocolo para anunciar
las VPN y dispositivos CE que este controla. Esta informacin acompaa las etiquetas
MPLS utilizadas por los PE para reenviarse datos entre s. De esta forma, cuando los CE
reciben esta informacin, poseen los datos necesarios para crear los pseudowires sobre
los PE.

2.16.3.

Topologa Punto a Multipunto

Esta topologa permite establecer ms de un camino desde un lugar a mltiples destinos.
Cualquier transmisin de datos, originados en un punto de conexin central es recibida
por todos los puntos de conexin perifricos, mientras que la comunicacin en el otro
sentido, desde la periferia, slo 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 configuracin de malla completa. Una VPLS es
establecida por un proveedor de servicios y emula una LAN tradicional. Permite conectar
varios segmentos de LAN, distantes geogrficamente, sobre una red de conmutacin de
paquetes de manera que las redes remotas se comporten como una nica LAN. En esta
situacin los equipos CE no deben seleccionar el pseudowire para reenviar los datos para
un destino determinado (topologa punto a punto); simplemente reenvan todo el trfico
al dispositivo PE del proveedor, quien se encarga de enviarlo al destino
correspondiente.
Esto es posible en redes MPLS donde se establece una topologa de malla completa de
pseudowires entre los dispositivos PE del proveedor que integran una determinada VPLS.
Gracias a este esquema los PE pueden realizar replicacin de paquetes (inundacin por
destino desconocido, broadcast, multicast) y aprendizaje de direcciones MACs tal como
lo hara un bridge o switch ethernet.
Para simplificar la configuracin de una VPLS, son necesarios mecanismos automticos
para obtener informacin de los integrantes de la VPLS, como llegar hacia ellos y
conectarse finalmente. Esto facilita tambin el agregado de nuevos nodos y la
administracin de las conexiones (manejo de pseudowires) entre ellos. De lo contrario el
manejo y escalabilidad de la VPN se vera afectada.

2.16.4. Topologa Estrella (Hub and Spokes)

Esta es la topologa ms comn en VPNs. Existe un gateway VPN o concentrador (hub)
y una serie de clientes (spokes) que establecen una conexin punto a punto con
este, un tnel de hecho. Para que pueda existir comunicacin entre los clientes remotos,
el trfico de datos deber ir desde el cliente emisor hasta el concentrador, luego este
retransmitir esos datos hacia el cliente receptor. No existe una conexin directa entre los
clientes, toda la comunicacin deber atravesar primero el concentrador.
Esta topologa afecta la escalabilidad en cuanto a que est limitada al desempeo y la
capacidad de procesamiento del concentrador. Este deber soportar conexiones
simultneas. Por esta razn el desempeo 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 geogrficamente cerca, igual
debern enviar su trfico al concentrador en lugar de utilizar una conexin directa entre
ellos.

Sin embargo, este esquema tiene la ventaja de una administracin centralizada,

respecto del monitoreo, mantenimiento, control de accesos, registro de eventos. Adems
el hecho de agregar un nuevo componente a la VPN es simple debido a que esta
operacin se centraliza en el hub.
Una forma de paliar la desventaja que significa un nico punto de falla, es una variacin
de la topologa donde exista ms de un concentrador, tanto para brindar redundancia
como para balancear la carga relacionada con las conexiones simultneas 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 trfico emitido desde el cliente a
travs de la duplicacin de la conexin con el concentrador. Si bien esta organizacin
brinda la mxima disponibilidad, es prohibitiva en trminos de costo en equipos y
en la poca conveniencia de invertir recursos en el extremo del cliente.
Esta topologa y sus variantes se aplican en los escenarios red a red, tanto para conectar
los sitios de una misma organizacin como as tambin cuando se implementan VPN
extranets con sitios de otras organizaciones.
Las VPN sitio a sitio utilizando IPSec son un ejemplo de la aplicacin de esta
topologa. Es comn considerar el uso del protocolo GRE para permitir el trfico
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 nmero de

asociaciones de seguridad activas a soportar, as como su deteccin, eliminacin 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 tneles IPSec: Las polticas de seguridad que se aplican pueden

impactar en la perfomance del concentrador. La seleccin de algoritmos
criptogrficos fuertes lleva a una sobrecarga de la capacidad de cmputo. Hay que
balancear el requerimiento de la poltica y la carga en el mantenimiento de los
tneles con un clculo apropiado de las necesidades futuras de agregaciones de nodos
clientes a la VPN.

Capacidad de procesamiento criptogrfico: este aspecto est relacionado

directamente con el anterior, en trminos del throughput de paquetes por segundo que
es capaz de procesar el mdulo de encriptacin.

Capacidad de mantenimiento de tneles GRE: Si bien la mayora de los

dispositivos VPN soportan los tneles GRE, no lo implementan a nivel de hardware.
Si se requiere esta encapsulacin, la misma no deber limitar el throughput o el
procesamiento en el concentrador.

2.16.5. Topologa
Mesh)

de

Malla

Completa

Parcial

(Full

or

Partial

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

directa con todos los dems. En el caso de malla parcial (partial mesh) solo ciertos
dispositivos tienen conexin directa entre s. La razn de ello radica en que no todos

requieren ms de una conexin. Solo aquellos que requieren alta disponibilidad y que la
interrupcin 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 comunicacin dentro de la VPN

La perfomance general no est limitada a un solo sistema.

Aquellos dispositivos que estn prximos geogrficamente, pueden comunicarse

directamente sin intermediario.

La
desventaja radica en
el
incremento del
mantenimiento en cuanto a la distribucin de las claves
para asegurar las comunicaciones o en la distribucin de
informacin de enrutamiento. En particular si se usa
IPSec,
la
creacin
de
asociaciones
de
seguridad
necesarias para cada nodo que se sume a la VPN
representa un costo en el mantenimiento. La situacin
puede mejorar si se utilizan mtodos automticos para la
distribucin de claves, o la transmisin dinmica de
rutas.
Nuevamente
los
escenarios
red
a
red
implementan esta topologa 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 topologa 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.

78