IPsec

IPsec no es un protocolo, es una familia de protocolos que protegen el tráfico IP, autenticándolo y cifrándolo. Su rasgo diferencial frente a todo lo demás es la capa: trabaja en el nivel de red, así que protege el datagrama IP entero y las aplicaciones no se enteran de nada ni hay que modificarlas. Cualquier cosa que use IP queda protegida de golpe, y no solo la que se haya programado para ello.

Esa es la diferencia de fondo con TLS, que protege una conexión concreta de una aplicación concreta que ha pedido protegerse. Con IPsec la decisión la toma el administrador en la configuración de la red; con TLS la toma la aplicación.

La familia tiene tres piezas y conviene tenerlas separadas desde el principio: AH y ESP son los dos protocolos que protegen el tráfico, e IKE es el que acuerda de antemano con qué claves y con qué algoritmos van a hacerlo.

Dos datos de encaje que se preguntan y que el material de partida no marca. Primero, IPsec es NATIVO en IPv6, donde forma parte de la especificación desde el diseño, y en cambio en IPv4 es un añadido opcional que hay que desplegar aparte. Segundo, AH y ESP no van sobre TCP ni sobre UDP: son protocolos de nivel de red por derecho propio y se identifican por su número de protocolo IP, 51 el primero y 50 el segundo. IKE sí necesita un transporte y usa el puerto UDP 500, más el UDP 4500 cuando hay que atravesar una traducción de direcciones. (Ampliación de esta plataforma.)

IPsec protege en la capa de red, así que es transparente para las aplicaciones. AH es el protocolo IP 51, ESP el 50 e IKE va en UDP 500.

AH, cabecera de autenticación, inserta una cabecera adicional dentro del datagrama con la que el receptor puede comprobar tres cosas: que el paquete viene de quien dice venir, que nadie lo ha modificado por el camino y que no es la repetición de un paquete antiguo capturado antes. Lo que NO hace, y es la primera pregunta del punto, es cifrar: el contenido sigue viajando legible para cualquiera que lo capture.

Sus campos importantes son tres y se preguntan por su función.

El HMAC es un código de autenticación de mensaje: un resumen calculado con una clave secreta, de modo que solo quien la tenga puede generarlo y comprobarlo. Cómo funcionan por dentro las funciones de resumen se estudia en el tema de administración electrónica del bloque de legislación.

Hay un detalle de cálculo que cae con frecuencia. AH protege también la cabecera IP exterior, pero no puede incluir en el cálculo todos sus campos, porque algunos cambian legítimamente por el camino: el tiempo de vida se decrementa en cada salto, y la suma de comprobación se recalcula. A esos campos se les llama mutables y quedan fuera del hash. Si entraran, el paquete llegaría siempre marcado como alterado.

Sobre las claves conviene una precisión, porque circula mal explicado: los dos extremos comparten una clave preconfigurada solo cuando el despliegue se hace con clave precompartida. En un despliegue normal la clave la negocia IKE, y ni siquiera es una sola, porque cada asociación de seguridad protege un único sentido de la comunicación.

AH da integridad, autenticación de origen y protección frente a repetición. Confidencialidad, ninguna. Es el único protocolo de la familia que no cifra.

ESP, carga de seguridad encapsulada, es el protocolo que se usa en la práctica totalidad de los despliegues, porque hace lo mismo que AH y además cifra. Aporta confidencialidad, integridad y autenticación de origen, y también protección frente a repetición.

De los dos algoritmos de cifrado, el que se usa hoy es AES: 3DES es el heredado, es mucho más lento y arrastra debilidades conocidas. Cuando un enunciado pida elegir entre los dos, la respuesta es AES.

ESP admite configurarse sin cifrado, usándolo solo para autenticar, lo que lo dejaría prestando el mismo servicio que AH. Es posible y está desaconsejado: si no se va a cifrar, no hay razón para elegir ESP, y si se elige ESP es precisamente por el cifrado.

Una diferencia de alcance que conviene fijar frente a AH: la protección de integridad de ESP no cubre la cabecera IP exterior, solo lo que va dentro de la envoltura. Parece un detalle y tiene una consecuencia enorme, que se ve en el punto siguiente.

ESP es el que cifra, y por eso es el que se usa. Sus campos son SPI, número de secuencia, carga cifrada y datos de autenticación.

Los dos protocolos se preguntan enfrentados, así que conviene tener el cuadro completo en una sola vista.

La última fila es la razón práctica de que AH esté hoy en desuso, y merece explicación porque es una pregunta de razonamiento. Traducir direcciones consiste precisamente en cambiar la dirección de la cabecera IP. Como AH incluye esa cabecera en el cálculo de integridad, cualquier traducción por el camino altera un campo protegido y el receptor concluye, correctamente, que el paquete ha sido manipulado. ESP no protege esa cabecera, así que le da igual que se traduzca. (Compatibilidad con la traducción de direcciones añadida como ampliación de esta plataforma.)

Con acceso remoto detrás de un router doméstico, que traduce siempre, AH sencillamente no funciona. La combinación viable es ESP, y cuando además hay que atravesar equipos que no entienden protocolos distintos de TCP y UDP se recurre al encapsulado sobre UDP 4500.

Si la pregunta enfrenta AH y ESP por la confidencialidad, la respuesta es que solo cifra ESP. Si los enfrenta por la traducción de direcciones, la respuesta es que solo la soporta ESP.

AH y ESP protegen paquetes, pero para hacerlo necesitan saber de antemano con qué algoritmo y con qué clave. Ponerse de acuerdo en eso es el trabajo de IKE, el intercambio de claves de internet, cuya versión vigente es IKEv2. En la literatura aparece junto a otros dos nombres que forman parte de su historia: ISAKMP, que aporta el marco general de negociación, y Oakley, que aporta el método de intercambio de claves.

IKE hace tres cosas y las tres se preguntan.

• Negocia las opciones criptográficas: qué protocolo se va a usar, con qué algoritmo de cifrado y con qué función de integridad, escogiendo entre lo que ambos extremos admiten.
• Intercambia las claves sin que lleguen a viajar por la red, mediante Diffie-Hellman.
• Autentica a los dos extremos entre sí, y admite dos formas de hacerlo: con certificados X.509 o con una clave precompartida.

El resultado de esa negociación es una asociación de seguridad, o SA: el conjunto de parámetros acordados (protocolo, algoritmos, claves y tiempo de vida) que describe cómo se va a proteger un flujo concreto. Cada una se identifica por su índice de parámetros de seguridad, que es el SPI que después viaja en cada paquete para que el receptor sepa cuál aplicar.

El detalle que más se pregunta es que una asociación de seguridad es UNIDIRECCIONAL: protege un solo sentido de la comunicación. Para que dos equipos se hablen en ambas direcciones hacen falta dos, una por sentido, con parámetros y claves distintos. Y si hay varios pares de equipos conversando, cada par tiene las suyas: el conjunto se guarda en una tabla donde cada entrada es una asociación.

La analogía que ayuda es el saludo de TLS: IKE cumple en IPsec el mismo papel que el saludo cumple en una conexión segura de la web, que es acordar antes de empezar cómo va a ir protegido todo lo que venga después. Ese saludo se explica en el tema de internet y HTTP de este mismo bloque. Diffie-Hellman y los certificados X.509, en el tema de administración electrónica del bloque de legislación.

IKE negocia, intercambia claves y autentica; su producto es la asociación de seguridad. Una SA por sentido: dos equipos hablando necesitan dos.

Tanto AH como ESP pueden funcionar de dos maneras, y la diferencia está en cuánto del paquete original se protege y quién es el extremo de la protección. Es, con diferencia, la pregunta más repetida de todo el apartado de IPsec.

El nombre de cada uno describe lo que hace, y con eso se resuelven casi todas las preguntas. En modo transporte se protege lo que se transporta, es decir, la carga, y el sobre exterior queda a la vista con las direcciones reales de origen y destino. En modo túnel se construye un túnel, es decir, se mete el paquete entero dentro de otro, y lo único visible desde fuera son las direcciones de las dos bocas del túnel.

De ahí sale la ventaja de privacidad del modo túnel, que también se pregunta: como la cabecera original queda dentro y cifrada, un observador no puede saber qué equipo interno habla con qué equipo interno, solo que dos pasarelas están intercambiando tráfico. El precio es la sobrecarga de llevar dos cabeceras IP en cada paquete.

Como productos comerciales de cortafuegos con terminación de VPN, los nombres que aparecen en los enunciados son SonicWall y Fortinet.

Modo transporte: de anfitrión a anfitrión, se protege solo la carga y no hay cabecera nueva. Modo túnel: de pasarela a pasarela, se protege el paquete entero y sí hay cabecera nueva. Una VPN siempre es modo túnel.