IP-VPNs IPsec

IP-VPNs con IPSec
Pablo Lutenberg
pel@pel.name

AGENDA
 Conceptos generales de Redes Privadas Virtuales
 Tipos existentes
 VPNs sobre Internet
 IPSec para VPNs
 Nociones básicas de encripción
 Arquitectura IPSec
 Modos IPSec
 Security Asociations (SA)
 Authentication Header (AH)
 Encapsulating Security Payload (ESP)
 Internet Key Exchange (IKE)
 NAT & IPSec

VPNs: Conceptos
 ¿Qué es una VPN?
Red privada que utiliza la
infraestructura de
telecomunicaciones pública
manteniendo la privacidad a
través de protocolos de túneles
y procedimientos de seguridad

Tipos existentes de VPNs
 Protocolos Disponibles
 PPTP
 L2TP
 IPSec
 MPLS VPNs
 Escenarios más comunes
 Acceso Remoto
 Site to site
 Extranet

 Acceso Remoto
(VPDNs)
 Individuos Remotos
 Empleados
 Partners de
confianza
Red Propia
de la
Empresa
(Intranet)
Concentrador
VPN
Teletrabajo
Hogar

Headquarters
(Casa Central)
Sucursal 1
Sucursal 2
Sucursal 3
INTERNET
 Site to Site
 Entre redes propias
 Reemplaza líneas
dedicadas (más caras)

 Extranet
 Similar a Site to
Site
 Diferencias en
cuanto a la
“confianza”
INTERNET
Empresa 2
Empresa 1

IPSec para VPNs
 ¿Cómo saben los servidores VPN
que cada uno es auténtico y no un
impostor?
 Uno de los protocolos que más se
implementan hoy para VPNs: IPSec
 Conjunto de mecanismos
(protocolos) para dar seguridad a
las comunicaciones entre sitios
sobre Internet.

Nociones básicas de encripción
 Seguridad  Privacidad  “guardar
secretos”
 Crece el número de personas que
comparten nuestro secreto.
 Se hace “más público” el ambiente
donde quiero comunicar mi secreto.
 Se hace más difícil guardar un
secreto.

 Para esto existen las tecnologías de
encripción.
 El conjunto IPSec se basa en ellas
para funcionar
 Vamos a conocer las más usadas
por IPSec

 ¿Qué es encriptar o cifrar?
 Dada una entrada “plana” o “plain”
se obtiene una salida “cifrada” o
“cipher”
 Esto resulta de aplicar algún
algoritmo de encripción a la entrada
plana más una clave (key)
 Si quiero descifrar el texto necesito
la clave

Texto Plano Texto Cifrado
Algoritmo
de
Encripción
Clave

 Criptografía Simétrica
 Modo stream o modo Block
 Modo stream aplica la encripción bit a
bit o byte a byte.
 Modo block aplica un algoritmo de
encripción por bloques de datos de 64
bits (estructura atómica)
 Ejemplos: DES, CAST, Blowfish
 IPSec usa exclusivamente modo Block

 Diferentes modos de los Block
 Electronic Code Book (ECB): Basado en
conocer todos los posibles cifrados para un
mismo plain text
 Cipher Block Chaining (CBC): Aplica XOR entre
el bloque “cipher text” previo y el próximo
bloque “plain text” antes de encriptar
nuevamente
 El primer bloque usa un Inicialization Vector
(IV) para aplicar XOR
 El IV es un número “pseudo-random”
(aleatorio)

+ ++ +
E E E E
IV
Texto Plano
Texto Cifrado
Encripción
Encripción CBC

+
D
IV
Texto Plano
Texto Cifrado
Desencripción D D D
+ + +
Desencripción CBC

 Criptografía Asimétrica
 También llamada de clave pública
 Existen dos Claves: Pública y Privada
 Una encripta y la otra desencripta
 Dada una clave publica es
computacionalmente imposible
determinar la privada
 RSA: Basado en la dificultad de
factorizar el producto de dos números
primos muy grandes

 Autenticación
 La Criptografía de Clave Pública puede usarse
para AUTENTICAR.
 Se trata de las famosas “Firmas Digitales”
 Deben ser difícil su Falseo y Repudio
 Se debe garantizar integridad y unicidad del
mensaje.
 Se debe prevenir que una firma digital se
extraiga de un documento auténticamente
firmado y se agregue a otros

 ¿Cómo Funciona la Autenticación?
 Lo que la clave privada encripta la clave pública
desencripta.
 Quien tenga la clave pública correspondiente a la
privada usada puede acceder a la información.
 Mediante un Hash se reduce el documento a un
“digest” (“resumen”) de tamaño fijo.
 Este “digest” es el que se encripta.
 Recordar: La función de Hash produce idénticos
“digest” a idénticas entradas.
 Se agrega el digest encriptado al documento
enviado
 El receptor hace un “hash” temporal del mensaje y
desencripta el hash cifrado.
 Si los “digest” son iguales  Firma válida

Documento
Documento
Hash
Hash
Cifrado
C. Privada
Documento
Hash Hash
C. Pública
Emisor Receptor
Canal
Inseguro
IGUALES
VÁLIDA!!
Autenticación
mediante Firma
Digital

 Con este método nos aseguramos
nuestros objetivos:
 Difícil de falsear: solo el que tiene la clave
privada puede generar la firma.
 No repudiable: Un documento firmado no
puede ser repudiado dada la dificultad de
falseo.
 Inalterable: Una vez firmado, un documento
no puede ser modificado.
 Intransferible: La firma no puede ser sacada
y adosada a otro documento.

 Integridad
 Las Firmas Digitales proveen integridad
 Pero pueden ser lentas para algunas
necesidades
 Existe un método Simétrico que garantiza
integridad
 Message Authentication Code (MAC)
 No son FD pero me garantizan Integridad
 También se los utiliza junto a los Hash
 Un hash solo es como un “Checksum”
 Un hash cifrado es un MAC
 Existe un MAC especial llamado HMAC (RFC
2104)
 Todas las autenticaciones en IPSec
utilizan HMAC

 Intercambio de claves Diffie-Hellman
 Método por el cual se puede establecer un
secreto compartido a través de un canal inseguro
(como es Internet)
 Mediante Diffie-Hellman, los esquemas de cifrado
e integridad se pueden utilizar de manera
“escalable”.
 Los participantes Alice (A) y Bob (B) acuerdan un
Grupo.
 El Grupo define: 1) Un N° primo p
2) Un generador g

 El intercambio:
 Cada participante elige un N° aleatorio
privado (a y b) y elevan g a ese N°
produciendo un valor público
Alice Bob
A= ga mod p B= gb mod p

 Luego intercambian esos valores
públicos. Alice le da “A” a Bob y Bob le
da “B” a Alice
 Cuando cada uno recibe el valor del
otro, lo elevan nuevamente pero
usando el valor recibido de la otra
parte como generador (base de la
exponenciación)  generando el
secreto compartido
Alice Bob
Ba mod p = gab mod p = Ab mod p

Arquitectura IPSec
 IPSec es un método para proteger
datagramas IP
 Dispone de mecanismos que proveen de
seguridad a IP y otros protocolos de
capas más altas (TCP,UDP)
 Hay definida una suite de algoritmos y
protocolos “default” que deben ser
implementados para asegurar
interoperabilidad entre entidades que
hablen IPSec.
 IPSec puede proteger paquetes:
 Entre hosts
 Entre Gateways de seguridad (routers o
firewalls)
 Entre hosts y Gateways de seguridad

Arquitectura IPSec
 Existen dos protocolos principales:
 AH (Authentication Header)
 ESP (Encapsulated Security Payload)
 Cada uno puede ser usado en dos
diferentes Modos:
 Modo Transporte
 Modo Túnel

Arquitectura IPSec
 Modo Transporte: Protege los
protocolos superiores (transporte).
 Modo Túnel: Protege el datagrama
IP entero.

Arquitectura IPSec
Header
IP
Header
TCP
Header
IPSec
Data
Data
Data
Header
TCP
Header
IP
Header
TCP
Header
IPSec
Header
IP
Header
IP
Paquete IP
Original
Modo
Transporte
Modo
Túnel

Arquitectura IPSec
 Modo Transporte: Cada punto de la
comunicación actúa también como
“endpoint criptográfico”.
 Modo Túnel: Puede ser usado en
lugar del Modo Transporte, pero
además puede ser usado por
Gateways de Seguridad para
proveer seguridad a otras entidades
pertenecientes a una red.

Arquitectura IPSec
 En el Modo Túnel los “endpoints” de
la comunicación son los que existen
en el Header IP INTERNO
 Los “endpoints” criptográficos son
los indicados en el Header IP
EXTERNO
Data
Header
TCP
Header
IPSec
Header
IP
Header
IP
Modo
Túnel
Direcciones de
endpoints
criptográficos
Direcciones de
endpoints de la
comunicación

Arquitectura IPSec
 Para encapsular o desencapsular los
paquetes IPSec es necesario definir los
servicios de seguridad asociados que
incluyen:
 Cómo proteger el tráfico
 Qué tráfico proteger
 Métodos, etc.
 Esas definiciones se incluyen en las
llamadas Security Asociations (SA)

Arquitectura IPSec
 Características de las SAs:
 Son UNIDIRECCIONALES
 Se identifican mediante:
 Un índice llamado “Security Parameter
Index (SPI)
 El protocol value de IPSec
 La dirección destino a la que se aplica la
SA (esto indicará el sentido)
 Cada SA reside en la “Security
Asociation Data Base” (SADB)

Arquitectura IPSec
 SA creada en forma MANUAL
 No tiene tiempo de vida
 Existe hasta que es borrada manualmente
 SA creada en forma DINÁMICA
 Debe tener un tiempo de vida asociado
 Es negociado entre las “puntas” IPSec
 El Tiempo de Vida es importante porque se
deben manejar con cuidado :
 La cantidad e tráfico protegida bajo una
misma clave
 El tiempo durante el cual esa clave permanece
activa
 El uso excesivo de una clave da a un atacante
mayores posibilidades de éxito.

Arquitectura IPSec
 En IPSec también se define la
granularidad que se quiere
especificar para una política
 Un nivel de seguridad para cierto
tráfico
 A otro tráfico identificado más
“finamente” le puedo aplicar otro nievel
de seguridad completamente distinto.

Arquitectura IPSec
DES con
HMAC MD5
3DES con
HMAC SHA
DES con
HMAC MD5
3DES con
HMAC SHA
FTP
TELNETResto del
Tráfico
Resto del
Tráfico
FTP
TELNET
INTERNET
Aplicación de Políticas

Arquitectura IPSec
 Las políticas IPSec se mantienen en la
“Security Policy Database” (SPD)
 Cada entrada de la SPD define:
 El tráfico a ser protegido
 Cómo protegerlo
 Con quién es compartida esa protección
 Cada vez que un paquete entra o deja el
IP stack, la SPD debe ser consultada
sobre la posible aplicación de seguridad.

Arquitectura IPSec
 Cada entrada de la SPD puede realizar 3
acciones:
 Descartar (discard)
 Bypass
 Proteger (protect)
 Si elige “protect” debe:
 Aplicar servicios de seguridad a los paquetes
salientes.
 Requerir que los paquetes entrantes tengan
aplicados servicios de seguridad.
 Las entradas SPD que definan “protect”,
apuntan a un SA o un bundle de SAs para
aplicar al paquete.

Arquitectura IPSec
 Si una entrada SPD define “protect”
y no apunta a ninguna SA dentro de
la SADB, la SA debe ser creada.
 Si el tráfico es entrante y la SA no
existe  Descarta el paquete.
 Si el tráfico es saliente y la SA no
existe  se debe crear una SA
dinámicamente invocando a IKE
(Internet Key Exchange).

Arquitectura IPSec
 La arquitectura IPSec define la
interacción entre la SPD y la SADB
 Lo que no define es cómo operan
los protocolos básicos de IPSec
 Esto se deja (como veremos) a los
dos diferentes protocolos existentes
para tal propósito en la “suite”
IPSec:
 Encapsulating Security Payload (ESP)
(RFC 2406)
 Authentication Header (AH) (RFC 2402)

Implementación IPSec
 Dijimos que IPSec puede ser
implementado:
 En “end hosts”
 En “gateways/routers”
 En ambos
 Existen méritos para cada caso
 Implementación en Hosts
 En este contexto se define “host” como
el dispositivo donde se origina el
paquete

 Ventajas
 Provee seguridad “end-to-end”
 Habilidad para implementar todos los
modos
 Provee seguridad “por flujo”.
 Habilidad para mantener un contexto
de usuario para la autenticación.
 Se clasifica en:
 Integrada en OS (Sistema Operativo)
 “Bump in the Stack” (BITS)

Integrada en OS
Aplicación
Transporte
Red + IPSec
Enlace
Transporte
Red
IPSec
Enlace
Aplicación
BITS

 Ventajas de Integrada en OS
 Facilita los servicios de la capa de Red como
fragmentación, PMTU, sockets de contexto de
usuario. Eficiencia.
 La capa de red se integra a IPSec “sin
enmiendos”
 Se soportan todos los modos
 BITS
 La desventaja de Integración en OS puede
darse para fabricantes propietarios de
soluciones de VPNs.
 Los host deben trabajar con las
funcionalidades provistas por el vendor del OS
 Puede limitar su capacidad de agregar
funcionalidades avanzadas propias.
 BITS permite al fabricante ofrecer una solución
completa.

 Pero…también tiene sus desventajas
 Requiere “doble esfuerzo”
 Implementar la mayoría de las
características de capa de Red
 Esta duplicación puede tener riesgos de
perjudicar la fragmentación, PMTU y
routing.
 De todas formas la mayoría de los
proveedores que ofrecen soluciones
integradas prefieren tener su propio
cliente e implementar sus propios
“features”

 Implementación en Router
 Provee seguridad sobre una parte de la
red.
 “Tunelea” los paquetes
 Ventajas
 Habilidad de dar seguridad a paquetes
entre dos redes sobre una red pública
(Internet)
 Habilidad de Autenticar y Autorizar
usuarios entrando a la red privada.
 Esto previamente era posible solo
discando a un MODEM dentro de la
empresa

 Desventajas
 Impacta en la capacidad de pase de paquetes
del Router
 Lo principal que se espera de un Router es
pasar paquetes tan rápido como pueda
 Existen routers de “core” con capacidades de
hasta 30 Mill. Pq/Seg!!
 Es un tema de especial cuidado mantener
demasiados contextos IPSec en la memoria del
Router (destinada principalmente a tablas).
 Conclusión
 IPSec no debe usarse en el “Core” de Internet
 No aplicar seguridad “de más”.
 Muchas implementaciones utilizan Chipsets
especiales para asistir al hardware en las
operaciones de seguridad.

Security Asociations (SA)
 Forman la BASE para IPSec
 Es un “contrato” entre dos entidades que
se comunican
 Determinan:
 Protocolos a utilizar para seguridad de
paquetes
 Algoritmos de encripción a utilizar
 Claves
 Duración de claves
 Toda implementación IPSec mantiene las
SAs en una SADB

 Las SAs son UNIDIRECCIONALES
 Ejemplo: Si se comunican dos hosts
A y B:
 A tendrá su SAout que procesa Paquetes
salientes y su SAin que procesa paquetes
entrantes
 De igual forma lo hará B
 SAout de A y SAin de B compartirán los
mismos parámetros criptográficos (ej:claves)
 De la misma forma SAin de A y SAout de B
 Las SAin y las SAout se mantienen en
tablas separadas

SAin
SAout
SAout
SAin
Host A
Host B

 Además debe existir una SA para
cada protocolo IPSec utilizado (AH y
ESP)
 Recordar SPD: define características
de la comunicación segura entre
dos entidades.
 La SPD y la SADB trabajan en
conjunto para procesar paquetes

 Security Parameter Index (SPI)
 Elemento muy importante de la SA
 Identifica unívocamente a la SA en el
destino
 Se envía con cada paquete
 32 bit
 Se usa para indexar dentro de la SADB
destino y encontrar el SA a utilizar
 Se especifica que el par <spi, dirección
destino> identifican una SA
 El SPI es enviado como parte del
header AH o ESP.

 Creación
 Proceso en dos pasos:
 Negociación de parámetros
 Actualización de la SADB con la nueva SA
 Manual Keying:
 Debe ser soportado obligatoriamente
 Se negocian las SA “offline”
 Una vez que se crean nunca expiran hasta
que se borren
 En general se usa para tareas de
“debugging” ante fallas

 En un entorno de implementación
IPSec completo, las SA son creadas
mediante un protocolo destinado a tal
fin. (IKE)
 IKE es invocado por el núcleo de IPSec
cuando una política exige seguridad en
una conexión y no encuentra SA
 IKE negocia la SA con el host/router y
la agrega a la SADB
 Cuando la política requiere el
establecimiento de múltiples SAs (por
ejemplo se quiere usar AH y ESP), el
conjunto negociado se denomina SA
bundle

 Borrado
 Una SA se puede borrar por varias
razones:
 El tiempo de vida expiró
 Las claves fueron comprometidas
 El número de bytes
encriptados/desencriptados o
autenticados usando la misma SA excedió
un cierto número establecido en la política
 El otro extremo requiere el borrado de la
SA
 Se pueden borrar manualmente o
mediante IKE

 IPSec no provee la habilidad de
refresco de claves
 Se debe borrar la SA actual y crear una
nueva
 El SPI de una SA borrada se puede
reutilizar
 Se puede negociar una nueva SA antes
del borrado de la antigua.
 Por este corto período: ¿Cómo
conviven la nueva y la antigua?
 Es deseable que se use la SA más
nueva posible.

 Las SAs tienen campos:
 Genéricos
 Específicos de un protocolo
 Algunos se usan para proceso inbound, otro
para outbound y otros para ambos
 Parámetros
 Sequence Number:
 32 bits
 Usado en outbound
 Es parte de AH y de ESP
 Incrementado en un cada vez que la SA es
usada para procesar un paquete
 Cuando se establece la SA es seteado a cero
 La SA se renegocia antes de que este campo
de “overflow”

 Sequence Number Overflow:
 Usado en outbound
 Seteado cuando el sequence number da
overflow
 La política es la que decide si se puede seguir
usando
 Antireplay Window:
 Usado en inbound
 Para detectar ataques
 Lifetime:
 Se puede especificar en términos de:
 N° de bytes procesados por la SA
 Duración de la SA
 Ambos
 Soft y Hard Lifetimes

 Mode:
 Especifica Modo Túnel o Transporte
 Puede ser seteado también a una “wildcard”
 Wildcard se usa para dejar la decisión a otra
entidad (es como un comodín)
 Tunnel Destination:
 Se utiliza en modo Túnel
 Indica el destino del mismo
 Es decir, la dirección IP del Header externo
 PMTU Parameters:
 En modo Túnel
 Se usa para mantener información del PMTU

 Políticas de Seguridad
 Determinan los servicios de seguridad
proporcionados a un paquete
 Se consultan para procesos inbound y
outbound
 Se pueden mantener políticas
asimétricas (inbound y outbound)
 Generalmente un Túnel tiene políticas
simétricas
 Para el tráfico Outbound, la salida de
una búsqueda de una SA en la SADB es
un puntero a la SA o SA bundle
 ¿Qué pasa si no existe SA?

 Tráfico Inbound: Al paquete se le
proporciona procesos de seguridad
 La SPD reside en el núcleo de la
implementación (kernel)
 Es específico de cada implementación
la provisión de una interfase para su
manejo
 No hay estándar definido
 Pero se debe proveer la habilidad para
manejar los selectores que vemos a
continuación.

 Selectores
Son utilizados para determinar los servicios
de seguridad a proveer a un paquete.
 Dirección Origen. Puede ser:
 Un “wildcard”: Usado cuando la política es la
misma para todos los paquetes originados en
un host
 Un prefijo de red o rango de direcciones:
Usado por Gateways de seguridad que
proveen seguridad a hosts detrás de ellos y
para construir VPNs
 Host específico: Usado cuando los
requerimientos son específicos para un host
particular

 Dirección Destino. Puede ser:
 Wildcard, prefijo de red o rango de
direcciones: Se usa para hosts detrás de
Gateways de seguridad
 La dirección destino como selector es la
dirección del destino final, no la del gateway
de seguridad (recordar dirección de endpoints
criptográficos distinta a endpoints de la
comunicación)
 Nombre:
 Usado para identificar una política unida a un
nombre válido.
 Ej: DNS
 Este campo se usa únicamente durante la
negociación IKE
 No puede ser usado durante el procesado del
paquete

 Protocolo:
 Especifica el protocolo de transporte
cuando es accesible.
 Si no es accesible se usa un wildcard
 Upper-Layer Ports:
 Si hay claves orientadas a sesión, este
campo representa los ports origen y
destino a los cuales se debe aplicar la
política
 Si estos no son accesibles se usa un
wildcard

Procesado de IPSec
Se tiene procesado Inbound y
Outbound
 Proceso Outbound
 IP consulta a la SPD para determinar
servicios de seguridad.
 La entrada a la SPD incluye los
selectores vistos
 Las posibilidades de salida de la SPD
son:
 Descarte del paquete (drop)
 Bypass de seguridad
 Aplicar seguridad

Procesado de IPSec
 Si se requiere aplicar seguridad
 Existe SA  puntero a la SA
 No existe SA  invocar a IKE
 El puntero puede apuntar a una SA o a un
bundle dependiendo de la política
 Ningún paquete es transmitido hasta que
las SAs estén establecidas
 Se agregan los headers que
correspondan (AH o ESP)

Procesado de IPSec
SA1
SA2
Host
A
Host
B
Network
PayloadAH
IP
Header
ESP
IP
Header
RA RB
Or=HA
Dest=HB
Or=HA
Dest=RB
Ejemplo

Procesado de IPSec
 Es muy importante el ORDEN de
procesado IPSec en caso de existir un
SA bundle
 Proceso Inbound
 Paquete no contiene headers IPsec
 Se chequea la política en la SPD
 Descarte
 Bypass
 Aplicar
 Política Descartar  descarta
 Política Aplicar y No SA  descarta
 Resto de los casos  al siguiente nivel de
proceso

Procesado de IPSec
 Paquete contiene headers IPsec
 Se procesa el paquete en el IPSec layer
 Se extrae el SPI, Dir Origen, Dir Dest
 Se indexa dentro de la SADB <SPI, dst.
addr , protocol>
 Protocol es AH o ESP  se procesa por el
correspondiente
 Se consulta la política para validar
payload
 Direcciones en SA corresponden a Política
 La SA está protegiendo el protocolo de
transporte que corresponde
 IPSec valida política  quita IPSec header
 paquete al siguiente nivel

Procesado de IPSec
 Importante:
 IPSec NO Fragmenta ni Reensambla
paquetes
 Se debe considerar según el caso el
uso de ICMP

Encapsulating Security Payload (ESP)
 Es el protocolo destinado a proveer:
 Authentication (con un autenticador)
 Antireplay (opcional)
 Integridad
 CONFIDENCIALIDAD (con Encripción)
 Un N° de secuencia creciente es insertado
siempre por el origen ESP
 El destino puede leerlo o no
 En general las implementaciones lo leen

 El header ESP siempre viene luego
un header IP
 El campo protocolo del header IP se
setea a 50 (ESP)
 Lo que sigue a un header ESP
puede ser:
 Un protocolo superior (TCP, UDP,etc)
 Otro header IP

Security Parameter Index (SPI)
Sequence Number
IV
Protected Data
Pad Pad Length Next Header
Authentication Data
Header
y
Trailer
de ESP

 SPI
 Identifica a la SA
 El SPI va a ser AUTENTICADO pero NO
ENCRIPTADO
 Es usado para identificar el algoritmo de
encripción y claves usadas para desencriptar el
paquete
 ¿Qué pasaría si él mismo estuviese encriptado?
 Sequence Number
 Insertado por el emisor
 AUTENTICADO pero NO ENCRIPTADO
 Queremos determinar si el paquete es
duplicado
 Se podrá decidir si se descarta sin esfuerzos
de desencripción (más recursos)
 Además no lleva ninguna información
confidencial que requiera encripción

 Payload Data
 Contiene los datos protegidos
 Su tamaño depende del tamaño de los
datos
 Es usado para contener el IV que
pudiera necesitar el algoritmo de
encripción.
 Para el uso de cada algoritmo particular
se debe definir la ubicación del IV
 Para el algoritmo “mandatorio” de ESP
(DES-CBC) el IV son los primeros 8
bytes del campo Protected Data
 AUTENTICADO, NO ENCRIPTADO

 Padding
 Usado en ESP para mantener fronteras
 Depende del algoritmo de encripción
 Algunos algoritmos lo pueden requerir
para mantener el tamaño de bloque
 Pad length
 Indica cuanto padding se agregó para
tratar los datos correctamente
 Este campo es obligatorio
 Si no existe pad  vale cero

 Next Header
 Indica el tipo de datos que contiene el Payload
 Si ESP está en modo Túnel  valor 4 (IP-in-IP)
 Si ESP está en modo Transporte  indica el
número de protocolo del nivel superior . Ej:
TCP (6)
 Authentication Data
 Contiene el resultado del chequeo de
integridad (Hash encriptado)
 Su longitud depende del algoritmo utilizado por
la SA para procesar el paquete
 Si no existe en la SA especificación de
autenticador  No existe este campo

Modo Transporte
IP Header
SPI
Sequence Number
IV
TCP Header
Data
Pad Length Next HeaderPad
Authentication Data
Encriptado
Autenticado

Modo Túnel
IP Header
SPI
Sequence Number
IV
IP Header
Data
Pad Length Next HeaderPad
Authentication Data
Encriptado
Autenticado
TCP Header

Procesado de ESP
 Recordar en ESP:
 El ciphertext es autenticado
 El plaintext autenticado no es encriptado
 Significa que:
 Para Outbound  Primero Encripto
 Luego Autentico
 Para Inbound  Primero Autentico
 Luego Desencripto
 Los algoritmos “mandatorios” de ESP son:
 DES-CBC con IV explícito para encripción
 Autenticadores: HMAC-MD5 y HMAC-SHA
 De todas maneras se recomienda fuertemente
utilizar 3DES y cuando sea posible AES

Procesado de ESP
 Modo Transporte
 Header ESP insertado inmediatamente
después del header IP
 Protocolo field del IP (copiado)  Next
Header del ESP
 Campo SPI  SPI de la SA (dentro de la
SADB) en particular usada para procesar
el paquete
 Se completa el Sequence Number con el
siguiente valor de la secuencia
 Se inserta el Pad
 Se completa el Path Length
 Al Campo “Protocolo” del Header IP se le
da el valor 50

Procesado de ESP
 Modo Túnel
 El Header ESP es agregado al paquete
antes del Header IP
 Next Field del ESP  valor 4 (IPv4)
 El resto se completa igual que en modo
transporte
 Se agrega el nuevo Header IP y se
completan sus campos
 Dirección Origen  del dispositivo que
aplica ESP
 Dirección Destino  se obtiene de la SA
usada para aplicar ESP
 Campo protocolo  50 = ESP
 El resto de los campos se completan de
acuerdo al procesado IP local

Procesado de ESP
 El resto es igual para los dos modos
 Desde el principio del payload hasta el
Next Header  Encriptado usando el
algoritmo en la SA correspondiente
 Desde el ESP Header pasando por la
porción encriptada, hasta el ESP Trailer 
Autenticado usando el autenticador en la
SA correspondiente
 Se recomputa el checksum del IP Header
que precede al ESP Header
 Sobre la Fragmentación
 Si el paquete resultante es mayor que la
MTU, simplemente se fragmenta
 Dejamos al Proceso Inbound encargarse
del tema

Procesado de ESP
 Proceso Inbound
 Sobre los modos
 Sin procesar el paquete el receptor no tiene
forma de saber en qué modo está.
 Basado en la SA puede saber en qué modo
tendría que estar.
 Pero hasta que no desencripta, no hay forma
práctica de saber qué está protegiendo ESP
 Esto es bueno dado que cualquiera que haga
análisis de tráfico tampoco puede saberlo!
 Se recibe el paquete
 Si es un fragmento, debe retenerse hasta
recibir el resto.
 Un fragmento IPSec NO DEBE PROCESARSE.
Fallaría el chequeo de integridad!!

Procesado de ESP
 ¿Existe SA para procesarlo?
 Si no existe debe ser DESCARTADO
 Los procesos Inbound trabajan solo con SAs
EXISTENTES
 Una vez encontrada la SA válida comienza el
proceso
 El Sequence Number se chequea primero
 Si no es duplicado o fuera de secuencia, sigue
el proceso
 Se autentica el paquete. Se pasa el paquete
ESP entero menos Authentication Data con la
clave apropiada al algoritmo de autenticación
 Si el resultado coincide con la data en el
Authentication Field  paquete autenticado

Procesado de ESP
 Paso siguiente Desencripción
 Desde el principio del payload hasta el Next Header
 Usando la clave y el algoritmo indicado en la SA
 Se chequea el Pad para verificar el éxito de la
desencripción
 Chequeo preliminar de validez. Verifica si la SA dice
procesar paquetes de un modo particular (Túnel o
Transporte)
 Se debe DESCARTAR un paquete que no
corresponda al modo indicado
 Ahora se puede reconstruir el paquete sin ESP
 Si Modo Transporte
 El Header del protocolo de transporte sync con el
IP Header
 Campo Next Header de ESP  Campo Protocol de
IP Header
 Nuevo Checksum de IP

Procesado de ESP
 Si modo Túnel
 Es Header IP Externo y el Header ESP se
descartan. Me importa el paquete IP
desencapsulado
 Si el paquete no corresponde a la dirección
y/o puerto y/o protocolo dictado por la SA, se
DESCARTA
 Ahora el paquete puede seguir con los
procesos que sigan
 Si era Modo Transporte  procesa TCP o UDP
 Si era modo Túnel  procesa IP
 Si el paquete reconstruido era un fragmento,
debe esperar que los restantes sean recibidos,
reconstruidos y validados para su reensamble

Authentication Header (AH)
 Es el protocolo destinado a proveer:
 Integridad
 Autenticación
 Antireplay (opcional, limitado)
 No provee confidencialidad. Por lo tanto
NO requiere de un algoritmo de cifrado
 Requiere algoritmo Autenticador
 AH no impone protección antireplay
 El emisor envía con servicios Antireplay
 Queda a discreción del receptor utilizarlos
 Se usa en modo Túnel o Transporte
 Un paquete protegido con AH es otro
paquete IP

 Puede ser utilizado solo o en conjunto con
ESP
 Puede proteger un protocolo de túnel
(L2TP) o ser usado para “tunelear”
paquetes por sí mismo
 La integridad que provee AH es diferente
de la provista por ESP
 AH autentica partes del Header IP Externo
 Protocolo N° 51
 Si AH y ESP están protegiendo los mismos
datos: El header AH se inserta después
del Header ESP
 El Header AH es mucho más simple
 No hay Trailer  no hace falta Padding
 No necesita IV

Sequence Number
Authentication Data
Next
Header
Payload
Length
Reservado
Header AH

 Next Header
 Indica que sigue al Header AH
 Modo Transporte  valor del protocolo de
Transporte protegido (TCP, UDP)
 Modo Túnel  valor 4 (IP-in-IP)
 Payload Length: Indica la longitud de del
Header en sí
 Reservado: Debe se cero
 SPI: Contiene el SPI que junto con la Dir.
destino del Header IP externo identifican
la SA utilizada para autenticar este
paquete
 Sequence Number: Idéntico al usado en
ESP. Contador monótonamente creciente.

 Authentication Data:
 Longitud Variable
 Contiene el resultado da la función de
chequeo de integridad
 AH no define autenticador pero existen
dos mandatorios de implementar
 HMAC-SHA-96
 HMAC-MD5-96
 Son MAC con salida truncada a 96 bits

Modo Transporte
IP Header
Next
Header
Payload
Length
Reservado
Sequence Number
TCP Header
Data
Autenticado

Modo Túnel
Next
Header
Payload
Length
Reservado
Sequence Number
Inner IP Header
Data
Autenticado
TCP Header
Outer IP Header

Procesado de AH
 Recordar:
 Si un paquete de salida aplica con
alguna entrada del la SPD y existe SA,
se aplica AH tal como dicta la entrada
en la SPD
 Si hay un Bundle de SPD (x ej: se
aplican las dos protecciones), tener en
cuenta que AH PROTEGE A ESP y no al
revés

Procesado de AH
 Cuando se crea una SA Outbound el contador
“Sequence Number” se inicializa en cero
 Previo a la construcción de un Header AH que
use esa SA, el contador se incrementa
 Esto garantiza que el SN de cada Header AH
será:
 Único
 No cero
 Monótonamente creciente
 Se completan los campos restantes del AH
Header:
 SPI
 Next Header
 Payload Length
 Authentication Data se setea a cero

Procesado de AH
 Distinto a ESP, AH extiende la
protección a los campos inmutables o
predecibles del Header IP externo
 Por lo tanto es necesario poner en cero
los campos mutables antes de
computar el Integrity Check Value
(ICV)
 Los campos mutables del IP Header no
incluidos en el ICV son los campos
“desprotegidos” (sombreados en la
figura)

Procesado de AH
Total Length
TTL
Payload
Length
Source IP address
Destination IP address
Ver TOS
Flags Fragment Offset
Header Checksum
Identification
IP Protocol
Campos mutables e inmutables del Header IP

Procesado de AH
 El Header AH debe ser múltiplo de 32 bits
 El ICV se calcula pasándole al algoritmo
“authenticator”:
 La clave (¿de donde se saca?)
 El paquete IP entero incluido el AH Header
 Recordar que los campos “mutables” o
“cambiantes” fueron llevados a cero, con lo
cual no se incluyen en el ICV
 El ICV se copia en el Campo “Authentication”
 Los campos “mutables” del Header IP se llenan
de acuerdo al proceso IP en desarrollo
 Proceso AH terminado  envio de paquete
 Puede ocurrir fragmentación previa a la salida
o durante el tránsito
 Esto no es problema: Se deja para el proceso
Inbound

Procesado de AH
 Proceso Inbound
 ¿Qué se hace primero?
 ¿Qué pasaría con el ICV si no se hiciera esto
primero?
 Se debe identificar la SA usada:
 Dirección destino del IP Header
 Protocolo (en este caso 51)
 SPI del header AH
 Si no se encuentra SA...ustedes saben!!
 Se chequea el Número de Secuencia
(determina si el paquete es nuevo o recibido
demasiado tarde)
 Si falla el chequeo…….adivinar!
 Se chequea el ICV de la siguiente manera:

Procesado de AH
 Se guarda el ICV dentro de “Authentication
Data” del header AH
 Ese campo se lleva a cero
 A los mismos campos mutables IP que se
llevaron a cero para calcular el ICV se les
vuelve a hacer lo mismo
 El algoritmo autenticador se aplica al paquete
entero
 Se compara su resultado con el ICV guardado
 Si coinciden  paquete autenticado
 Si no coinciden  paquete descartado
 ¿A que se parece esto?
 Una vez autenticado, el datagrama es pasado
a IP para su procesado

Internet Key Exchange (IKE)
 Port UDP 500
 Negocia las SA y completa la SADB
 Especificado en el RFC 2409
 Protocolo Híbrido
 ISAKMP (Internet Security Asociation
and Key Management Protocol)
 SKEME
 Oakley

SKEME
Mecanismo para utilizar
encripción de clave pública
para Autenticación
Oakley
Mecanismo mediante el que
se llega a claves de
encripción entre dos puntas
ISAKMP
Arquitectura de Intercambio
de Mensajes complejos entre
dos extremos

 Utiliza dos fases
 Fase 1: Establecimiento de la IKE SA
 Usa certificados o Pre-Shared Secrets
 MAIN MODE o AGGRESSIVE MODE
 Fase 2: Establecimiento de la IPSec SA
 AH, ESP, Túnel, Transporte
 Para esta fase usa QUICK MODE

IP IP
IKE
ISAKMP
IKE
ISAKMP
UDP UDP
IPSec IPSec
(1) ISAKMP SA
(2) IPSec SA
Tunnel IKE bi-direccional

Main Mode
(6 Mensajes)
Aggressive Mode
(3 Mensajes)
SA Fase 1
SA Fase 2 SA Fase 2
Quick Mode Quick Mode
A Datos Protegidos B C Datos Protegidos D
………

 Objetivo de intercambio Fase 1:
 Establecer un canal de comunicación
SEGURO y AUTENTICADO con claves
autenticadas para proveer:
 Confidencialidad
 Integridad
 Autenticación del origen
 Todo otro intercambio definido en
IKE tiene como prerrequisito el
establecimiento de la IKE SA

 Los extremos deben definir una forma de
encriptar y autenticar mensajes
 La IKE SA define varios parámetros que
debe negociar
 Se reúnen en la denominada “Protection
Suite”:
 Algoritmo de encripción
 Algoritmo de Hash
 Método de autenticación
 Grupo Diffie-Hellman
 Para estos parámetros IKE define
atributos y rangos de valores que los
mismos pueden tener

 Algoritmo de Hash
 Se puede negociar
 Pero generalmente es usado el HMAC
 IKE utiliza también utiliza HMAC como PRF (Pseudo
Random Function)
 Grupo Diffie-Hellman
 Determina los parámetros a usar en un intercambio
(recordar g y p)
 Define cinco grupos preestablecidos de tal modo
que al pasar como parámetro “grupo2”, el otro
extremo sabrá qué parámetros usar
 Método de Autenticación
 Preshared Keys
 Firmas Digitales (DSA)
 Firmas Digitales (RSA)

 Estos atributos son negociados en
los primeros mensajes que
intercambian
 Son las características EXTERNAS y
VISIBLES de la IKE SA
 Pero cada uno también mantiene
información SECRETA que no podrá
ser vista por un potencial atacante
 Esta es la información que servirá
para proteger los mensajes IKE y
los servicios de seguridad derivados

 Las puntas generan 4 secretos:
 SKEYID: El resto se basa él
 SKEYID_d: Usado para derivar material
de claves para las IPSec SAs
 SKEYID_a: Usado para proveer
integridad y autenticación de la fuente
 SKEYID_e: Usado para encriptar
mensajes IKE

Main Mode
(Primeros 4 mensajes)
Autenticación con Preshared Keys
(2 últimos mensajes de Main Mode)
Autenticación con Firma Digital
(2 últimos mensajes de Main Mode)
Quick Mode (3 Mensajes)

Main Mode
Se negocian los parámetros a incluir en la
IKE SA
DH Completado. Se crean las SKEYID
(Secreto Compartido)
Genera su
valor público
de DH y un
NONCE (valor
aleatorio)
Genera su
valor público
de DH y un
NONCE (valor
aleatorio)
DES
MD5
DH 1
Pre-Share
DES
SHA
DH 2
Pre-Share
DES
MD5
DH 1
Pre-Share
HASHI
IDI = Host name o
IP Addr. HASHR
IDR = Host name o
IP Addr.
Se intercambian IDs y HASH. ID y HASH
son encriptados por el secreto compartido

Aggressive Mode
DH public, SAProposal ,
NonceI, IDI
DH public, SAChoice ,
NonceR , IDR , HASHR
HASHI
 3 mensajes (Comparado con los 6 de Main Mode)
 No provee protección de identidad
 El Iniciador no puede ofrecer distintos grupos DH
 Decididamente más limitado
 Se usa cuando:
 Se conocen mejor las políticas a priori y se quieren crear las
IKE SA más rápido
 Si un empleado quiere acceder a su empresa conociendo las
políticas bajo las que tiene acceso garantizado, la negociación
“full” de IKE no es necesaria

Quick Mode
ESP
DES
SHA
ESP
DES
SHA
HASH1, SAProposal ,
NonceI
HASH2, SAChoice ,
NonceR , IDR , HASHR
HASH3
 Más simple que Fase 1
 Estoy intercambiando datos sobre un canal seguro

IP-VPNs IPsec

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Destacado

Destacado (7)

Similar a IP-VPNs IPsec

Similar a IP-VPNs IPsec (20)

Último

Último (6)

IP-VPNs IPsec