Fuentes:

• An illustrated guide to IPsec (utilizado y traducido con la aprobación de Steve Friedl)
• IPsec (Wikipedia)

IPsec (abreviatura de Internet Protocol security) es un conjunto de protocolos cuya función es asegurar las comunicaciones sobre el Protocolo de Internet (IP) autenticando y/o cifrando cada paquete IP en un flujo de datos. IPsec también incluye protocolos para el establecimiento de claves de cifrado.

Los protocolos de IPsec actúan en la capa de red, la capa 3 del modelo OSI.Otros protocolos de seguridad para Internet de uso extendido, como SSL, TLS y SSH operan de la capa de transporte (capas OSI 4 a 7) hacia arriba. Esto hace que IPsec sea más flexible, ya que puede ser utilizado para proteger protocolos de la capa 4, incluyendo TCP y UDP, los protocolos de capa de transporte más usados. IPsec tiene una ventaja sobre SSL y otros métodos que operan en capas superiores. Para que una aplicación pueda usar IPsec no hay que hacer ningún cambio, mientras que para usar SSL y otros protocolos de niveles superiores, las aplicaciones tienen que modificar su código.

IPsec está implementado por un conjunto de protocolos criptográficos para (1) asegurar el flujo de paquetes, (2) garantizar la autenticación mutua y (3) establecer parámetros criptográficos.

La arquitectura de seguridad IP utiliza el concepto de asociación de seguridad (SA) como base para construir funciones de seguridad en IP. Una asociación de seguridad es simplemente el paquete de algoritmos y parámetros (tales como las claves) que se está usando para cifrar y autenticar un flujo particular en una dirección. Por lo tanto, en el tráfico normal bidireccional, los flujos son asegurados por un par de asociaciones de seguridad. La decisión final de los algoritmos de cifrado y autenticación (de una lista definida) le corresponde al administrador de IPsec.

Para decidir qué protección se va a proporcionar a un paquete saliente, IPsec utiliza el índice de parámetro de seguridad (SPI), un índice a la base de datos de asociaciones de seguridad (SADB), junto con la dirección de destino de la cabecera del paquete, que juntos identifican de forma única una asociación de seguridad para dicho paquete. Para un paquete entrante se realiza un procedimiento similar; en este caso IPsec coge las claves de verificación y descifrado de la base de datos de asociaciones de seguridad.

En el caso de multicast, se proporciona una asociación de seguridad al grupo, y se duplica para todos los receptores autorizados del grupo. Puede haber más de una asociación de seguridad para un grupo, utilizando diferentes SPIs, y por ello permitiendo múltiples niveles y conjuntos de seguridad dentro de un grupo. De hecho, cada remitente puede tener múltiples asociaciones de seguridad, permitiendo autenticación, ya que un receptor sólo puede saber que alguien que conoce las claves ha enviado los datos. Hay que observar que el estándar pertinente no describe cómo se elige y duplica la asociación a través del grupo; se asume que un interesado responsable habrá hecho la elección.

En modo transporte, sólo la carga útil (los datos que se transfieren) del paquete IP es cifrada y/o autenticada. El enrutamiento permanece intacto, ya que no se modifica ni se cifra la cabecera IP; sin embargo, cuando se utiliza la cabecera de autenticación (AH), las direcciones IP no pueden ser traducidas, ya que eso invalidaría el hash. Las capas de transporte y aplicación están siempre aseguradas por un hash, de forma que no pueden ser modificadas de ninguna manera (por ejemplo traduciendo los números de puerto TCP y UDP). El modo transporte se utiliza para comunicaciones ordenador a ordenador.

Una forma de encapsular mensajes IPsec para atravesar NAT ha sido definido por RFCs que describen el mecanismo de NAT-T

El propósito de este modo es establecer una comunicación segura punto a punto, entre dos hosts y sobre un canal inseguro. Este ejemplo ilustra esto:

En el modo túnel, todo el paquete IP (datos más cabeceras del mensaje) es cifrado y/o autenticado. Debe ser entonces encapsulado en un nuevo paquete IP para que funcione el enrutamiento. El modo túnel se utiliza para comunicaciones red a red (túneles seguros entre routers, p.e. para VPNs) o comunicaciones ordenador a red u ordenador a ordenador sobre Internet. El propósito de este modo es establecer una comunicación segura entre dos redes remotas sobre un canal inseguro. Este ejemplo ilustra esto:

La cabecera del paquete IP es la siguiente:

Donde:

• ver Es la versión del protocolo IP. IPsec se monta sobre IPv4.
• hlen Longitud de la cabecera, en palabras de 32 bits. Su valor mínimo es de 5 para una cabecera correcta, y el máximo de 15. El tamaño de la cabecera nunca incluye el tamaño del payload o de la cabecera siguiente.
• TOS Indica una serie de parámetros sobre la calidad de servicio deseada durante el tránsito por una red. Algunas redes ofrecen prioridades de servicios, considerando determinado tipo de paquetes “más importantes” que otros (en particular estas redes solo admiten los paquetes con prioridad alta en momentos de sobrecarga).
• pkt len Es el tamaño total, en octetos, del datagrama, incluyendo el tamaño de la cabecera y el de los datos. El tamaño máximo de los datagramas usados normalmente es de 576 octetos (64 de cabeceras y 512 de datos). Una máquina no debería envíar datagramas mayores a no ser que tenga la certeza de que van a ser aceptados por la máquina destino.

En caso de fragmentación este campo contendrá el tamaño del fragmento, no el del datagrama original.

• ID Indica el identificador del fragmento actual en caso de que el paquete estuviera fragmentado
• fgls Actualmente utilizado sólo para especificar valores relativos a la fragmentación de paquetes:

  bit 0: Reservado; debe ser 0
  bit 1: 0 = Divisible, 1 = No Divisible (DF)
  bit 2: 0 = Último Fragmento, 1 = Fragmento Intermedio (le siguen más fragmentos) (MF)

La indicación de que un paquete es indivisible debe ser tenida en cuenta bajo cualquier circunstancia. Si el paquete necesitara ser fragmentado, no se enviará.

• frag offset En paquetes fragmentados indica la posición, en unidades de 64 bits, que ocupa el paquete actual dentro del datagrama original. El primer paquete de una serie de fragmentos contendrá en este campo el valor 0.
• TTL Indica el máximo número de enrutadores que un paquete puede atravesar. Cada vez que algún nodo procesa este paquete disminuye su valor en uno por cada router que pase. Cuando llegue a ser 0, el paquete no será reenviado.
• proto Indica el protocolo de siguiente nivel utilizado en la parte de datos del datagrama. Los más utilizados son:

Otros códigos se encuentran en la web de IANA

AH está dirigido a garantizar integridad sin conexión y autenticación de los datos de origen de los datagramas IP. Para ello, calcula un Hash Message Authentication Code (HMAC) a través de algún algoritmo hash operando sobre una clave secreta, el contenido del paquete IP y las partes inmutables del datagrama. Este proceso restringe la posibilidad de emplear NAT, que puede ser implementada con NAT transversal. Por otro lado, AH puede proteger opcionalmente contra ataques de repetición utilizando la técnica de ventana deslizante y descartando paquetes viejos. AH protege la carga útil IP y todos los campos de la cabecera de un datagrama IP excepto los campos mutantes, es decir, aquellos que pueden ser alterados en el tránsito. En IPv4, los campos de la cabecera IP mutantes (y por lo tanto no autenticados) incluyen TOS, Flags, Offset de fragmentos, TTL y suma de verificación de la cabecera. AH opera directamente por encima de IP, utilizando el protocolo IP número 51. Un cabecera AH mide 32 bits, he aquí un diagrama de cómo se organizan:

* next hdr Identifica cuál es el siguiente protocolo, es decir, cual es el protocolo que será autentificado, cuál es el payload.

• AH len El tamaño del paquete AH.
• RESERVED Reservado para futuras aplicaciones. Debe estar a 0
• Security parameters index (SPI) Indica los parametros de seguridad, que en combinación con los parámetros IP, identifican la asociación de seguridad del paquete
• Sequence Number Es un número creciente usado para prevenir ataques por repetición. El número está incluido en los datos encriptados, así que cualquier alteración será detectada
• Authentication Data Contiene el valor de identificación de integridad. Puede contener relleno.Se calcula sobre el paquete entero, incluidas la mayoría de las cabeceras. El que recibe calcula otra vez el hash, y si este no coincide, el paquete se tira.

La manera más fácil de entender el modo transporte es que protege el intercambio de información entre dos usuarios finales. La protección puede ser autentificación o encriptación (o las dos), pero no se hace usando un tunel (para eso está el modo túnel). No es una vpn, es una simple conexión segura entre dos usuarios finales.

En AH en Modo Transporte, el paquete IP es modificado ligeramente para incluir una nueva cabecera AH entre la cabecera IP y la información transmitida (TCP, UDP, etc) y después se requiere un proceso “de arrastre” que interconecta las distintas cabeceras entre ellas.

Este proceso “de arrastre” se necesita para que el paquete original IP sea reconstituido cuando llegue a su destino; cuando las cabeceras IPsec han sido validadas en el receptor, se despojan las cabeceras IPsec y la carga a transmitir (TCP, UDP, etc) es guardada nuevamente en la cabecera IP.

Cuando el paquete llega a su siguiente destino y pasa el test de autenticidad, la cabecera AH es quitada y el campo proto=AH es reemplazado con el siguiente protocolo de la carga transmitida (TCP, UDP, etc). Esto pone al datagrama es su estado original, y puede ser enviado al proceso original.

El modo túnel es el más común para dar una funcionalidad de VPN, donde un paquete IP es encapsulado dentro de otro y enviado a su destino.

Igual que en el modo transporte, el paquete es “sellado” con un ICV para autentificar al que envia la información para prevenir modificaciones durante el tránsito. Pero a diferencia del modo de transporte, el modo túnel encapsula todo el paquete IP, no sólo la carga util (TCP, UDP ,etc). Esto hace que el destinatario del paquete sea uno diferente al destinatario original. Esto ayuda a la formación de un túnel.

Cuando un paquete en modo túnel llega a su destino, pasa el mismo proceso de autentificación igual que cualquier paquete AH-IPsec. Este proceso hace que se despoje de sus cabeceras IP y AH, luego nos queda el datagrama original, que es enrutado mediante un proceso normal.

La mayoria de las implementaciones tratan el final del túnel como una interfaz de red virtual -exactamente igual que una Ethernet o localhost - y el tráfico entrante y saliente de él está sujeto a todas las decisiones normales de enrutamiento.

El paquete reconstituido puede ser entregado a la máquina local o enrutado donde sea (dependiendo de la dirección IP encontrada en el paquete encapsulado), pero de ninguna manera vuelve a estar sujeto a las protección de IPsec. Esta finaliza al final del túnel. A partir de allí es tratado como un datagrama IP normal.

Tal como el modo de transporte es usado estrictamente para asegurar conexiones de extremo a extremo entre dos ordenadores, el modo túnel es usado normalmente entre pasarelas (routers, firewalls o dispositivos VPN) para proveer una Red Privada Virtual (VPN)

Curiosamente, no hay un campo explícito “Modo” en IPsec que distinga entre el modo de transporte y el modo túnel. Lo que los distingue es el campo *siguiente cabecera (next head)* en la cabecera AH.

Cuando el valor de “siguiente cabecera” es IP, significa que este paquete encapsula un datagrama IP entero (incluyendo los campos de destino y origen IP que nos permiten saber donde va el paquete que va encapsulado después de la desencapsulación. Así se comporta el modo túnel.

Otro valor cualquiera (TCP, UDP, ICMP, etc) significa que estamos usando el modo transporte y se trata de una conexión segura extremo a extremo.

El nivel superior de un datagrama IP es estructurado de la misma manera, sin tener en cuenta el modo, y los routers inmediatos tratan todo tipo de tráfico IPsec/AH de la misma manera que el tráfico normal, sin una inspección más profunda.

Hay que darse cuenta que un host - en contraposición a una pasarela - es necesario que soporte los dos modos, de transporte y túnel, pero en una conexión host-to-host parece superfluo usar el modo túnel.

Además, una pasarela (router, firewall, etc.) tiene que tener soporte únicamente para modo túnel, sin embargo tener soporte para el modo transporte es útil sólo cuando la pasarela se considera como destino ella misma, como en caso de funciones de administración de red.

AH lleva un campo (Integrity Check Value) para comprobar la integridad del paquete y que nadie lo ha manipulado durante el trayecto. El valor de ese campo está dado por algoritmos de encriptación tales como MD5 o SHA-1.

Más que usar un checksum convencional, el cual podría no proveer una securidad real contra una manipulación intencional, este usa una Hashed Message Authentication Code (HMAC), que incorpora una clave secreta mienstras se crea el hash. Aunque un atacante puede recalcular un hash fácilmente, sin la clave secreta no sería capaz de crear el ICV apropiado.

HMAC esta descrito por el RCF 2104 y se ilustra en la siguiente imagen:

Huelga decir que IPsec no define ni obliga como debe hacerse la autentificación, simplemente ofrece un marco de seguridad en la que los dos hosts que realizan la comunicación se ponen de acuerdo sobre que sistema usar. Pueden usarse firmas digitales o funciones de encriptación, pero es obligatorio que ambos los conozcan y sepan como usarlos

AH da una protección muy fuerte a los paquetes porque cubre todas las partes que se consideran inmutables. Pero esta protección tiene un coste: AH es incompatible con NAT (Network Address Translation).

NAT se usa para trazar un rango de direcciones privadas (192.168.1.X) de una conjunto (normalmente más pequeño) de direcciones públicas, para reducir la demanda de direcciones IP públicas. En este proceso, la cabecera IP se modifica “al vuelo” por el dispositivo NAT para cambiar las direcciones IP de origen y destino.

Cuando es cambiada la dirección de origen de la cabecera IP, se fuerza a recalcular el checksum de la cabecera. Esto se tiene que hacer a parte, porque el dispositivo NAT es como un “agujero” en el camino del origen al destino, y esta situación requiere decrementar el campo TTL(Time to Live).

Dado que el campo TTL y el checksum de la cabecera siempre son modificados “al vuelo”, AH sabe que tiene que excluirlos de su protección, pero no tiene que excluir a las direcciones IP. Estas están incluidas en el constrol de integridad, y cualquier cambio en las direcciones ip de origen y destino va a hacer que el control de integridad falle cuando llegue al destinatario. Dado que el valor del control de integridad contiene una llave secreta que sólo la saben el host origen y el host destino, el dispositivo NAT no puede recalcular el ICV.

Las mismas se aplican también al PAT(Port Address Translation), el cual traza múltiples direcciones IP en una en una sola dirección IP externa. No solo se modifican las direcciones IP “al vuelo”, sino además los números de los puertos UDP y TCP (a veces hasta la carga úlil que se transfiere. Esto requiere una sistema más sofisticado por parte del dispositivo NAT, y unas modificaciones más extensas en todo el datagrama IP.

Por esta razón,AH - en el modo Túnel o Transporte - es totalmente incompatible con NAT y sólo se puede emplear AH cuando las redes de origen y destino son alcanzables sin traducción.

Hay que decir que esta dificultad no se aplica al ESP, ya que su autentificación y encriptación no incorpora la cabecera IP modificada por NAT. Aún asi, NAT también impone algunos desafíos incluso en ESP (explicado más adelante).

NAT traduce las direcciones IP al vuelo, pero también guarda un registro de que conexiones siguen el camino traducido y así poder enviar las respuestas al origen de manera correcta. Cuando se usa TCP o UDP, esto se hace mediante los números de los puertos (que pueden ser reescritos al vuelo o no), pero IPsec no da ninguna interfaz para hacer esto.

Añadir encriptacion hace que ESP sea un poco más complicado, ya que la encapsulación rodea a la carga útil es algo más que precederla con AH: ESP incluye cabecera y campos para dar soporte a la encriptacion y a una autentificación opcional. Además, provee los modos de transporte y túnel, los cuales nos son ya familiares.

Las RFCs de IPsec no insisten demasiado en un sistema particular de encriptación, pero normalmente se utiliza DES, triple-DES, AES o Blowfish para asegurar la carga útil de “ojos indiscretos”. El algoritmo usado para una conexión en particular es definido por la Security Association (SA), y esta SA incluye no sólo la el algoritmo, también la llave usada.

A diferencia de AH, que da una pequeña cabecera antes de la carga útil, ESP rodea la carga útil con su protección. Los parámetros de seguridad Index y Sequence Number tienen el mismo propósito que en AH, pero nos encontramos como relleno en la cola del paquete el campo “siguiente campo” y el opcional “Authentication data”.

Es posible usar ESP sin ninguna encriptación (usar el algoritmo NULL), sin embargo estructura el paquete de la misma forma. No nos da ninguna confidencialidad a los datos que estamos transmitiendo, y sólo tiene sentido usarlo con una la autentificación ESP. No tiene sentido usar ESP sin encriptación o autentificación (a no ser que estemos simplemente probando el protocolo).

El relleno sirve para poder usar algoritmos de encriptación orientados a bloques, dado que tenemos que crear una carga a encriptar que tenga un tamaño múltiplo de su tamaño de bloque. El tamaño del relleno viene dado por el campo pad len. El campo next hdr nos da el tipo (IP, TCP, UDP,etc) de la carga útil, aunque esto sea usado como un punto para volver hacia atras en el paquete para ver que hay en el AH.

Además de la encriptación, ESP puede proveer autentificación con la misma HMAC de AH. A diferencia de AH, esta autentifica sólo la cabecera ESP y la carca útil encriptada, no todo el paquete IP. Sorprendentemente, esto no hace que la seguridad de la autentificación más débil, pero nos da algunos beneficios importantes.

Cuando un forastero examina un paquete IP que contiene datos ESP, es prácticamente imposible adivinar que es lo que tiene dentro, excepto por los datos encontrados en la cabecera IP (siendo interesantes las direcciones IP de origen y destino). El atacante va a saber casi seguro que son datos ESP (está en la cabecera que son datos ESP), pero no va a saber de que tipo es la carga útil.

Incluso la presencia de Authentication Data no puede ser determina solamente con mirar al paquete. Esta resolucion está hecha por la Security Parameters Index, que hace referencia al conjunto de parámetros precompartidos para esta conexión.

Al igual que en AH, el modo transporte encapsula justamente la carga la carga útil del datagraya y está diseñado justamente para comunicaciones extremo-a-extremo. La cabecera IP original se deja (excepto por el campo cambiado Protocol), y esto hace - además de otras cosas - que las direcciones IP de origen y destino se quedan como están.

El ESP en modo Túnel encapsula el datagrama IP entero y lo encripta:

Proveer una conexión encriptada en modo túnel es dar una forma muy cercana a como se crea una VPN, y es lo que se nos viene a la cabeza a la mayoría cuando pensamos acerca de IPsec. Además de esto, tenemos que añadir autentificación. Esta parte se trata en la siguiente sección.

A diferencia de AH, donde un forastero puede ver fácilmente que es lo que sse transmite en modo Túnel o Transporte, usando ESP eso no ocurre; esa información no está disponible para el forastero. El caso es que en el modo túnel (poniendo next=IP), el datagrama IP entero original es parte de la carga útil encriptada, y no será visible para nadie que no pueda desencriptar el paquete.

Con la explicación de AH y ESP ahora somos capaces de habilitar la encriptación y la autentificación para construir una VPN real. El objetivo de la VPN es juntar dos redes seguras a través de una red insegura, tal como sería tirar un cable Ethernet muy grande entre las dos redes seguras. Es una tecnología muy usada para juntar por ejemplo filiales de compañias con la sede central de la compañia, dando a los usuarios acceso a recursos que no pueden caer en manos indebidas, tales como documentos secretos.

Claramente, una red VPN segura requiere las dos cosas: autentificación y encriptación. Sabemos que la única manera de conseguir encriptación es ESP, pero ESP y AH pueden proveer autentificacióN: ¿cuál de las dos usar?

La solución obvia de envolver ESP dentro de AH es tecnicamente posible, pero en la práctica no es muy usada por las limitaciones de AH respecto al NAT. Usar AH+ESP puede hacer que no podamos atravesar el dispositivo NAT.

En cambio, ESP+Auth es usado en modo Túnel para encapsular completamente el tráfico a traves de una red no segura, protegiendo este trafico con encriptación y autentificación.

El tráfico protegido de esta manera produce información inútil para un intruso, ya que los dos hosts que se comunican están conectados a través de una VPN. Esta información puede ayudar al atacante a entender que los dos hosts se comunican por un canal seguro, pero nunca revela el contenido del tráfico. Incluso el tipo de tráfico encapsulado en el protocolo (TCP, UDP o ICMP) está oculto para las personas de fuera.

Lo particularmente bonito de este modo de operación es que los usuarios finales no saben nada de la VPN o las medidas de seguridad tomadas. Desde que una VPN está implementada por una pasarela, este trata la VPN como otra interfaz, y enruta el traico que va a otra parte como normalmente lo haría.

Este paquete-en-paquete puede ser anidado a más niveles: Host A y Host B pueden establecer su propia conexión autenticada (via AH) y comunicarse sobre una VPN. Esto pondría un paquete AH dentro de un paquete con una cobertura ESP+Auth.

Es obvio que si los dos hosts o pasarelas van a establecer una conexión segura, se requiere algún tipo de clave secreta compartida para llevar a cabo la función de autentificación o la y/o la clave del algoritmo de encriptación. La cuestión es como esos “secretos” son establecidos a para poder ser dirigidos desde cualquier sitio, y para los propósitos de esta guía vamos a suponer que han llegado “mágicamente” a su lugar.

Cuando un datagrama IPsec - AH o ESP - llega a una una interfaz, ¿cómo sabe la interfaz que conjunto de parámetros usar (clave, algoritmo y políticas)? Un host puede tener varias conversaciones simultáneas, cada una con un diferente conjunto de claves y algoritmos, y tenemos que tener un gobernador que lleve todo este proceso.

Estos parámetros son especificados por la Security Association (SA), una colección de parametros específicos de conexión, y cada pareja pueden tener uno o más colecciones de parámetros específicos de conexión. Cuando llega el datagrama son usadas tres piezas de los datos para localizar dentro de la base de datos o Security Associations Database (SADB) la SA correcta.

• Dirección IP de la pareja (el usuario con el que nos estamos comunicando)
• Protocolo IPsec (AH o ESP)
• Security Parameter Index

Hay muchas maneras para asociar este triplete a un socket IP, el cual está denotado de forma única por la dirección IP, protocolo y el número del puerto

Una SA es de sentido único, así que una conexión en los dos sentidos (el caso típico) requiere al menos dos. Además, cada protocolo (ESP/AH) tiene su propia SA en cada dirección, por tanto una conexión completa AH+ESP VPN requiere 4 SAs. Todas ellas están en la Security Associations Database.

En la SADB tenemos una cantidad ingente de información, pero sólo podemos tocar una parte de esta:

• AH: algoritmo de autenticación
• AH: secreto de autenticación
• ESP: algoritmo de encriptación
• ESP: clave secreta de encriptación
• ESP: autenticación activada si/no
• Algunos parámetros de intercambio de llaves
• Restricciones de enrutamiento
• Política de filtración de IPs

Algunas implementaciones mantienen la SPD (Security Policy Database) con herramientas de tipo consola, otras con GUIs y otras proveen una interfaz basada en web sobre la red. El grado de detalle mantenido por cualquier implementación en particular depende de las facilidades ofrecidas, así como si está en modo Host o modo Pasarela (Gateway).

Finalmente, vamos a cubrir brevemente el asunto de la administración de claves. Este área incluye varios protocolos y muchas opciones,

IPsec sería casi inútil sin las facilidades criptográficas de autenticación y encriptación, y este hecho requiere que las llaves que se usan sólo las sepan los participantes en la comunicación y nadie más.

La forma más obvia y sencilla de establecer las directivas de securidad es de forma manual: un grupo genera ese conjunto de directivas de securidad y las hace llegar a los otros compañeros. Todas las personas implicadas en la comunicación segura instalan esas directivas como Security Association en la SPD.

Este proceso no es muy recomendado, ya que no es del todo seguro: el mero hecho de hacer llegar las directivas de seguridad a otro lado, a su SPD puede exponer esas directivas a personas ajenas a la comunicación en el tránsito. In instalaciones más grandes con más dispositivos usando una clave precompartidas, esas claves pueden transigir un despliegue perjudicial para las nuevas claves.

IKE - Internet Key Exchange - existe para que los puntos terminales del túnel puedan montar de manera apropiada sus Security Associations, incluyendo las directivas de seguridad que van a usar. IKE usa el ISAKMP (Internet Security Association Key Management Protocol) como un framework para dar soporte al establecimiento de una SA compatible con los dos extremos

Existe un soporte para múltiples protocolos de intercambio de claves, siendo Oakley el mas usado. Huelga decir que el intercambio de claves de IPSec tiene lugar normalmente en el puerto 500 de UDP