REDES PRIVADAS VIRTUALES · Capítulo 05
blog.carreralinux.com.ar 1
REDES PRIVADAS VIRTUALES · Capítulo 05
Capítulo 05 - IPSEC - TEORÍA
ÍNDICE
Introducción a IPSec 3
Modos IPSec 4
MODO TRANSPORTE 4
MODO TÚNEL 6
Protocolos 6
6
ESP ENCAPSULATING SECURITY PAYLOAD
AH AUTHENTICATION HEADER 10
IKE: Internet Key Exchange 12
Security associations 13
Algunas conclusiones 14
Suscribite a nuestro Facebook:
www.facebook.com/carreralinuxar
Suscribite a nuestro Twitter:
twitter.com/CarreraLinuxAr
Suscribite a nuestro Blog:
blog.carreralinux.com.ar
blog.carreralinux.com.ar 2
REDES PRIVADAS VIRTUALES · Capítulo 05
Capítulo 05 - IPSEC - TEORÍA
Introducción a IPSec
Dentro del mundo de soluciones VPN, existen diferentes tipos; pero podemos dividir-
las en dos tipos: IPSec y SSL. La mayoría de las tecnologías de VPN encapsulan sus
paquetes en capa de transporte o superior (tipo SSL). Ahora vamos a ver un conjunto
de VPNs seguras colectivamente llamadas IPSec, que encapsulan sus paquetes en
la capa de red.
IPSec es el estándar de VPN del IETF para
el stack TCP/IP, y es obligatoria su imple-
mentación desde la versión 6 del protocolo
IP (IPv6).
IPSec es complicado comparado con las demás tecnologías de VPN, es complejo;
pero le permite una gran flexibilidad a la hora de configurarlo y adaptarlo a las nece-
sidades particulares, y al ser el estándar incluido con TCP/IP, IPSec corre en el kernel
del sistema operativo, lo que además le da un mejor rendimiento comparado con
otras formas de VPN a nivel de capa de aplicación.
IPSec coincide con la definición de VPN: la encriptación, in-
tegridad, no repudio y la autenticación aplicada a un túnel
para crear la ilusión de una red privada.
Suscribite a nuestro Facebook:
www.facebook.com/carreralinuxar
Suscribite a nuestro Twitter:
twitter.com/CarreraLinuxAr
blog.carreralinux.com.ar 3
REDES PRIVADAS VIRTUALES · Capítulo 05
Modos IPSec
Dependiendo del modo en el que actúe podemos establecer de 2 tipos:
Transporte Modo
Transporte Tùnel
MODO TRANSPORTE
En modo transporte, sólo la carga útil (los datos que se transfieren) del paquete IP es
cifrada o autenticada, por lo que provee seguridad a los datagramas superiores
del protocolo IP.
Se usa entre dos host fijos cuando los endpoints son los des-
tinatarios finales del tráfico.
El enrutamiento permanece intacto, ya que no se va a modificar ni cifrar la cabecera
IP; pero, cuando se utiliza la cabecera de autenticación (AH), que vamos a ver más
adelante, las direcciones IP no pueden ser traducidas o nateadas porque eso invali-
daría el hash, ya que usa cierta información de la cabecera para esto que si se altera
entre el origen y el destino, como cuando se natea, habría inconveniente.
blog.carreralinux.com.ar 4
REDES PRIVADAS VIRTUALES · Capítulo 05
Las capas de transporte y aplicación están siempre aseguradas por un hash, de for-
ma que no pueden ser modificadas de ninguna manera. Por ejemplo traduciendo los
números de puerto TCP y UDP, o PAT. ¿En qué casos utilizo el modo transporte? El
modo transporte se utiliza para comunicaciones host a host.
No sirve para conectar 2 redes, o una red y un host y por eso
IPSec la veremos implementada generalmente para unir sitios
remotos.
Aunque el término transporte viene de que una VPN, está orientado a proteger los
datos de la capa de transporte; en verdad está protegiendo todo lo que corra por
sobre la capa IP. Solamente el end-point del datagrama puede desencriptarlo y/o
autenticarlo, nadie más tiene la información necesaria.
Como se ve, solamente tenemos un header IP, de modo que el datagrama solamente
puede ser dirigido desde un end-point a otro, no se pueden comunicar dos redes de
esta forma.
Para que pueda comunicar dos redes, debería encapsular el da-
tagrama IP del end-point interno de la red de origen, en otro
datagrama IP, para que pueda ser routeado hacia el end-point
destino, en la red remota.
Y si, eso es lo que viene ahora.
Suscribite a nuestro Twitter:
twitter.com/CarreraLinuxAr
Suscribite a nuestro Blog:
blog.carreralinux.com.ar
blog.carreralinux.com.ar 5
REDES PRIVADAS VIRTUALES · Capítulo 05
MODO TÚNEL
En el modo túnel, todo el paquete IP (datos más cabeceras del mensaje) vamos a
cifrarlo o autenticarlo. Para esto va a ser encapsulado en un nuevo paquete IP para
que funcione el enrutamiento.
El modo túnel se utiliza para comunicaciones red a red (túne-
les seguros entre routers, p.e. para VPNs) o comunicaciones
equipo a red como por ejemplo un road-warrior.
De esta manera le brindamos seguridad al datagrama IP completo. Es más flexible
que el modo transporte; pero requiere más ancho de banda. Porque como vemos
en la imagen, no solamente debo encriptar y autenticar el dato de transporte, sino
que a eso hay que agregarle toda la información del header IP interno, que también
va a ser encriptado y autenticado.
Protocolos
IPSec contiene a otros tres protocolos. Primero veremos dos que modifican el en-
cabezado IP que son Authentication Header y Encapsulating Security Payload
y que, a su vez, trabajarán diferentes dependiendo si están en modo túnel o modo
transporte.
ESP ENCAPSULATING SECURITY PAYLOAD
Al ESP provee autenticación, integridad de datos y protección
de ataques antireplay, y además incorpora privacidad encrip-
tando datos IPSec.
Esto hace que el protocolo de autenticación Authentication Header sea casi ob-
soleto. De cualquier manera lo veremos más adelante porque forma parte del stack
IPSec.
blog.carreralinux.com.ar 6
REDES PRIVADAS VIRTUALES · Capítulo 05
Y la pregunta es, ¿por qué ESP requiere de autenticar los paquetes, si éstos van en-
criptados y nadie podría modificarlos en el camino?
Los datos también se autentican para evitar ataques del tipo cut-and-paste, en el que
el atacante toma una parte del texto cifrado, la modifica, y la reinserta, de modo que
el algoritmo de desencriptación lo pueda desencriptar sin problemas, pero el texto
plano resultante no sea el original.
Es por eso que ESP requiere su propio algoritmo de autenticación, y para ello utiliza
asociaciones de seguridad o security asociations que veremos más adelante lo que
es; pero es una parte fundamental de IPSec, y de esta forma mantiene información de
autenticación de los hosts con los que está intercambiando información securizada.
Protocol TCP TCP
6 Header Segment Data
IPv4 Header IP Data
Original IPv4 Datagram Format
Protocol TCP TCP Next Header
50 Header Data 6
IPv4 Header ESP Header Encrypted IP Data ESP Trailer ESP Auth Data
Encrypted Fields
Authenticated Fields
IPv4 ESP Datagram Format - IPSec Transport Mode
Suscribite a nuestro Twitter:
twitter.com/CarreraLinuxAr
blog.carreralinux.com.ar 7
REDES PRIVADAS VIRTUALES · Capítulo 05
ESP no autentica el header IP como lo hace AH. Si la seguridad lo requiere, se puede
utilizar ESP para encriptar, y AH para agregar además autenticación al header IP
exterior. De todos modos, el header exterior solamente se usa para rutear el paquete
desde un origen a un destino. Como veremos toda la información valiosa va encap-
sulada y encriptada con ESP, por lo que autenticar además el header IP exterior no
agrega más seguridad.
La parte encriptada del payload depende del modo que estemos usando ESP. Vean
que ESP puede hacer todo lo que hace AH, excepto autenticar algunos campos
del header IP, y además provee confidencialidad. Por esto, la mayoría de las VPNs
usan solamente ESP para proveer autenticación y privacidad, y no utilizan AH para
autenticar.
Veamos primero como funciona ESP en modo transporte que es básicamente la
imagen que tenemos arriba. Recordemos un poco lo que significaba el modo trans-
porte. Habíamos comentado que se utilizaba para unir un host con otro (esto significa
que IP de origen y destino son los emisores y destinatarios de la VPN) y que solo
protegía los datos que transportaba por lo que no necesita proteger el encabezado
IP. Por este motivo verán que solamente el payload está protegido.
Como pueden observar, el campo de “próximo protocolo” es el número 50. Esto le
indica que el próximo protocolo a trabajar es ESP y no TCP o UDP. La información
para autenticar la pueden encontrar en el ESP Auth Data.
Los campus que usa para autenticar son encabezado ESP, TCP,
Payload TCP (o el protocolo de transporte en cuestión) y Trai-
ler. Todos los campos permanecen sin alterar y es por eso que
se puede utilizar un hash para autenticar.
Por el lado de lo que es encripción, protege el contenido encriptando el trailer ESP y
el payload. Lo importante que debemos notar acá es que como comentamos antes,
IPSec es flexible y puede transportar cualquier protocolo por encima de la capa
de red. Entonces en el campo next header dice 6, ya que es el protocolo de transpor-
te TCP. Pero podría ser cualquier otro.
blog.carreralinux.com.ar 8
REDES PRIVADAS VIRTUALES · Capítulo 05
Veamos ahora el ESP en modo túnel.
Protocol TCP TCP
6 Header Segment Data
IPv4 Header IP Data
Original IPv4 Datagram Format
Protocol TCP TCP
6 Header Data
Protocol IPv4 IP Next Header
50 Header Data 4
New IPv4 ESP Header Original IPv4 Datagram ESP Trailer ESP Auth Data
Header (Encapsulated and Encrupted)
Encrypted Fields
Authenticated Fields
IPv4 ESP Datagram Format - IPSec Tunnel Mode
Para entender la diferencia, debemos de volver a la explicación del modo túnel, espe-
cialmente cuando decíamos que aquí se protegía la integridad del paquete. Como
mencionamos antes también, el modo túnel se utiliza para unir sitios remotos.
Por lo que lo que se protege es la totalidad del paquete ge-
nerado en la LAN cuando pasa por el gateway VPN.
El header IP externo es el del gateway VPN; pero el header IP interno es el generado
en la estación de trabajo de nuestra LAN que contiene la IP de origen de dicha work-
station; pero la IP de destino será la del equipo de la LAN en la sede destino.
Suscribite a nuestro Facebook:
www.facebook.com/carreralinuxar
blog.carreralinux.com.ar 9
REDES PRIVADAS VIRTUALES · Capítulo 05
AH AUTHENTICATION HEADER
Pueden existir situaciones en las cuales no es necesario encriptar todos los datos
transmitidos, ni usar tiempo de procesamiento para esto. Si este llegara a ser el caso,
IPSec nos proporciona un protocolo para autenticar los datagramas en los endpoints.
De esta forma se autentican los datos; es decir, en el destino sabemos quien envió el
paquete es quien dice ser, que no fue cifrado; pero el contenido no va cifrado por el
medio de comunicación.
AH calcula un MAC con clave, llamado ICV (integrity check
value).
Este valor se calcula sobre:
· Partes del header IP (version, header/total lenght, id, protocol, source/destination
addresses).
· El payload completo.
Este ICV se agrega al header AH, y todo el conjunto se adosa al datagrama IP
saliente. Pero, ¿Por qué no autentica todos los campos del header IP, y solamente
algunos?
Algunos campos del header IP son modificados por los routers intermedios.
Estos routers cambian, por ejemplo, los valores de los campos TOS (type of service),
los flags de DF (Don’t fragment) y MF (Morefragments), el flag de OFFSET (desplaza-
miento del fragmento dentro del datagrama original), el TTL (timeto live), y recalculan
el checksum del header IP.
Suscribite a nuestro Twitter:
twitter.com/CarreraLinuxAr
Suscribite a nuestro Blog:
blog.carreralinux.com.ar
blog.carreralinux.com.ar 10
REDES PRIVADAS VIRTUALES · Capítulo 05
Al modificar estos campos, no pueden re-autenticar el paquete o
re-calcular el hash por falta de información que solo posee el
host originante, ya que justamente es la idea de autenticación.
Que el paquete no fue modificado en el camino, y si lo modificaran, el destino ya no
va a poder asegurar que el datagrama viene de un host origen válido. AH, también
variará dependiendo si es modo transporte o túnel:
AH
Transport Mode
IP Header AH Header Data
Authenticated except mutable fields
Tunnel Mode
New IP Header AH Header IP Header Data
Authenticated except mutable fields
ESP
Por último, si así lo deseamos podremos combinar ESP y AH. Pero como explicamos
antes, es raro ver esto ya que ESP tiene su método de autenticación:
AH & ESP
Transport Mode
IP AH ESP ESP ESP
Data
Header Header Header Trailer Auth
Encrypted
Authenticated except mutable fields
Tunnel Mode
New IP AH ESP IP ESP ESP
Data
Header Header Header Header Trailer Auth
Encrypted
Authenticated
Suscribite a nuestro Facebook:
www.facebook.com/carreralinuxar
blog.carreralinux.com.ar 11
REDES PRIVADAS VIRTUALES · Capítulo 05
IKE: Internet Key Exchange
Se encarga del intercambio de claves de IPSec
automáticamente.
Los pares ejecutan un intercambio Diffie-Hellman para obtener una clave secreta
compartida que ellos usan para generar la clave de encriptación y la del algoritmo de
autenticación que protegen la VPN.
Recuerden que IPSec utiliza HMAC que requie-
re una clave.
IKE es un protocolo híbrido pues deriva de otros tres protocolos:
· ISAKMP: Internet Security Assosciation an Key Management Protocol
Es un protocolo que le permite a IKE establecer las asociaciones de seguridad. Es
independiente del mecanismo particular de intercambio de claves, es decir, no
solamente puede servir a IKE como “transporte”. Es un framework que contiene a
los dos protocolos que indicamos a continuación:
· OAKLEY: Oakley Key Determination Protocol
Es un protocolo que especifica una serie de modos de utilizar Diffie-Hellman para lo-
grar el intercambio seguro, la verificación e identidad de los pares, la autenticación, etc.
IKE utiliza a OAKLEY para determinar el modo de utilizar el algoritmo Diffie-Hellman.
· SKEME
Es un protocolo que le permite a IKE negociar entre los pares las primitivas de cripto-
grafía, los métodos y claves de encriptación y autenticación.
En conclusión, el intercambio seguro de cla-
ves se lleva a cabo combinando a IKE con
OAKLEY y SKEME, todo corriendo sobre el
transporte ISAKMP.
blog.carreralinux.com.ar 12
REDES PRIVADAS VIRTUALES · Capítulo 05
Security associations
Los datos de un túnel o VPN son llevados
en datagramas IP convencionales. Un túnel o
VPN consiste en sincronizar el estado de los
end-points. En IPSec esta sincronización se
llama SA: Security Association.
Las SAs se almacenan en una estructura de datos llamada SA también. Es la entidad
de control de las VPNs IPSec.
La SA incluye todos los datos que un end-point necesita para
mantener la VPN IPSec.
Esta información incluye el algoritmo de encriptación y sus claves, los algoritmos de
autenticación y sus claves, el número de secuencia actual, la ventana de anti-replay,
el tiempo de vida de la SA, el número de identificación de la SA, y el índice de pará-
metros de seguridad, o SPI (security parameter index).
Las SA son sencillas, solamente incluyen el control de tráfico
en una dirección, y es por este motivo que cada end-point debe
poseer dos SA’s, una para el tráfico saliente, y otra para el
tráfico entrante.
Además cada end-point debe tener un par de SAs por cada protocolo de autentica-
ción y/o encriptación de IPSec. Es decir, si se usan simultáneamente AH y ESP,
cada end-point tendrá 4 SA’s. El caso normal es que solamente tengan dos SA’s
utilizando ESP.
Suscribite a nuestro Twitter:
twitter.com/CarreraLinuxAr
blog.carreralinux.com.ar 13
REDES PRIVADAS VIRTUALES · Capítulo 05
Si tenemos varias SA’s en un host que se comunica por VPN IPSec con varios des-
tinos, ¿cómo determina cuál SA aplicar al tráfico entrante y saliente a cada destino?
Las SA’s en un host determinado se identifican por la siguiente información:
· SPI (Security parameter index, índice de parámetros de seguridad) que es asignado
a la SA por el host destino .
· Dirección IP destino.
· El protocolo de seguridad utilizado, ESP o AH.
Algunas conclusiones
Una de las grandes ventajas, como se pudo observar es que para las aplicaciones
es transparente. Como IPSec opera a nivel de capa 3, tiene esencialmente un nulo
impacto en las capas de aplicación y superiores. Esto deriva inmediatamente en que
para las diferentes aplicaciones sea totalmente transparente si salen por VPN o no.
Otra ventaja de IPSec es que no depende de terceras aplicaciones que garanticen
la seguridad, ya que la misma está intrínseca dentro de la capa de red como vimos
anteriormente.
Suscribite a nuestro Facebook:
www.facebook.com/carreralinuxar
Suscribite a nuestro Twitter:
twitter.com/CarreraLinuxAr
Suscribite a nuestro Blog:
blog.carreralinux.com.ar
blog.carreralinux.com.ar 14
