Resumen

  • RFC 2410 definió NULL como la función identidad, con clave e IV de cero bits. De ese modo, no aplicar confidencialidad podía negociarse con precisión dentro de ESP.
  • La seguridad dependía de una transformación de integridad separada y de la política de la SA. Un observador intermedio no podía deducir de forma determinista el uso de NULL a partir de un paquete ESP ordinario, y poder leer bytes no otorgaba permiso para inspeccionarlos.

El documento incluye un vector de prueba memorable: la frase de entrada reaparece sin una sola modificación. No es una prueba de cifrado débil. Es la prueba correcta de un transformador que, por definición, no cifra.

La broma funciona porque la especificación no deja margen. NULL(b) = I(b) = b. La longitud de clave para IKE debe ser cero. La longitud del vector de inicialización debe ser cero. El algoritmo no guarda estado y su bloque nominal mide un byte. Dos implementaciones no tenían que adivinar cómo representar “ningún cifrado”.

Esa precisión resolvía una necesidad de diseño. ESP separaba confidencialidad de autenticación e integridad. Había escenarios en los que se quería proteger el origen y detectar modificaciones sin ocultar la carga. Colocar NULL en la ranura de cifrado permitía negociar esa combinación con el mismo lenguaje que las demás asociaciones de seguridad.

El nombre puede engañar. NULL era una transformación de cifrado por posición protocolaria, no porque aportara secreto. RFC 2410 dice que no ofrece confidencialidad ni otro servicio de seguridad. Su tarea era representar explícitamente que el servicio de confidencialidad no se aplicaba.

La integridad venía de otra transformación. Con un algoritmo de autenticación fuerte, ESP_NULL podía ofrecer autenticación del origen e integridad sin confidencialidad. RFC 2410 lo comparó con AH, aunque marcó una diferencia de cobertura: ESP_NULL no incluía el encabezado IP en el cálculo como lo hacía AH para sus partes protegibles.

Por eso “sin cifrado” no equivale a “sin protección”. Tampoco garantiza protección suficiente. Hace falta conocer el algoritmo de integridad, las claves, la política y el resultado de verificación. NULL no hereda mágicamente las propiedades del mecanismo que lo acompaña.

RFC 2406 exigía que una SA ESP especificara al menos un algoritmo criptográficamente fuerte de cifrado o autenticación. RFC 4303 conservó la regla: confidencialidad e integridad podían ser opcionales por separado, pero no podían ser NULL al mismo tiempo. El sobre ESP no podía quedar vacío por ambos lados.

La transformación recibió el identificador 11 en el registro IPsec DOI de IKEv1. El registro actual de IKEv2 también enumera ENCR_NULL como 11 para ESP y aclara que no se permite para proteger el propio IKEv2. El mismo número solo es comprensible dentro de su tabla y su tipo de transformación.

Un registro evita colisiones semánticas; no registra cada uso real. Ver el 11 en una lista no prueba que una negociación lo ofreciera. Verlo en una configuración no prueba que el núcleo lo instalara. Ver ESP en la red no prueba que el contenido estuviera cifrado. Cada afirmación necesita su propio recibo.

Esta disciplina cambia cómo se investiga una posible degradación. Si la política permitía ESP con solo integridad, seleccionar ENCR_NULL era cumplimiento. Si la política exigía confidencialidad y el par aceptó NULL, la selección puede ser una degradación o un fallo de configuración. Sin la versión de política y el transcript, el analista solo tiene una etiqueta.

RFC 8221 mantuvo ENCR_NULL como obligatorio de implementar para que ESP autenticado sin cifrado siguiera siendo interoperable, y señaló la ventaja práctica frente a AH en redes con NAT. Obligatorio de implementar no significaba obligatorio de activar. La capacidad común dejaba la decisión de uso a cada operador.

El punto más fértil de la historia aparece cuando un tercero intenta observar esa decisión. Los extremos tenían la SA y podían leer la transformación seleccionada. Un equipo intermedio veía el encabezado ESP y un SPI, pero no necesariamente tenía acceso al estado que daba sentido a esos campos.

En ESP ordinario no existía un bit público que dijera “esta carga usa NULL”. Los bytes visibles podían parecer estructura de un protocolo interno o texto aleatorio. Los datos cifrados también podían coincidir por azar con patrones plausibles. Clasificar requería información adicional.

La falta afectaba a equipos empresariales que querían inspeccionar tráfico con integridad pero sin confidencialidad. Un motor antimalware o de control de acceso necesitaba saber si podía interpretar la carga. Confundir texto cifrado con claro rompía el análisis; confundir claro con cifrado podía crear una vía de evasión.

RFC 5840 propuso WESP precisamente porque el formato ESP por sí solo no permitía una distinción determinista. La envoltura añadía una indicación explícita y podía permitir la inspección de tráfico de solo integridad. Era una nueva señal, negociada y verificable dentro de su propio diseño.

RFC 5879 documentó heurísticas para instalaciones que no habían cambiado sus extremos. Las reglas buscaban estructuras plausibles en la carga y evaluaban coherencia. Podían ser útiles durante una transición, pero no transformaban una inferencia en conocimiento de la SA.

El documento suponía además un dominio administrado donde una política común impedía evitar los controles mediante ESP cifrado. Esa condición no era un detalle jurídico añadido al final. Sin control de los extremos, el observador no podía tratar su clasificación como una garantía ni imponer que todos los pares revelaran el servicio elegido.

Incluso WESP resolvía solo la clasificación, no la autoridad. Saber de forma determinista que la carga no está cifrada no responde quién puede leerla, con qué finalidad, durante cuánto tiempo o bajo qué rendición de cuentas. La disponibilidad técnica de los datos y el mandato para procesarlos pertenecen a capas distintas.

También son distintas las pruebas del receptor. Una SA entrante puede estar instalada mientras la saliente falta. Una negociación puede concluir y fallar al programar un acelerador. La integridad puede pasar y la ventana antirrepetición rechazar el paquete. El cortafuegos interior o la aplicación pueden descartarlo después.

Un inventario útil debe enlazar intención y ejecución. Para cada dirección: identidad del par, revisión de política, propuesta, selección, SPI, algoritmo de cifrado, algoritmo de integridad, instalación, estado de secuencia, contadores y resultado de aplicación. La palabra ESP no sustituye esa cadena.

La evolución normativa exige la misma precisión. RFC 9395 llevó IKEv1 y sus documentos asociados al estado histórico y cerró los registros antiguos. También deprecó varios algoritmos envejecidos. No deprecó ENCR_NULL. La guía moderna de ESP siguió necesitando una forma de representar integridad sin confidencialidad.

La doctrina de Lu Heng ayuda a no confundir el plano común con el local. La especificación mínima fijó la función identidad y sus parámetros porque la interoperabilidad los requería. La política futura quedó en los participantes que ejecutaban el código. La adopción se volvió real al negociar, instalar y usar la transformación, no al publicar el RFC.

Las capas de realidad explican el resto. El registro define un símbolo. IKE registra un acuerdo. El núcleo mantiene estado. El paquete produce evidencia observable. El equipo intermedio clasifica. La política autoriza o prohíbe. La aplicación determina el resultado. Ninguna capa puede apropiarse del testimonio de todas las demás.

RFC 2410 no celebró la ausencia de seguridad. Estandarizó una ausencia concreta para que no fuese ambigua. La paradoja histórica es que la decisión más explícita para los pares siguió siendo opaca para quien solo miraba el paquete.

Fuentes