Resumen

  • RFC 2401 distinguió la base ordenada de políticas de seguridad de la base de asociaciones activas: una decidía descartar, omitir IPsec o proteger el tráfico; la otra conservaba los parámetros de conexiones lógicas unidireccionales.
  • Una regla y una asociación no demostraban el recorrido de un paquete. La salida debía aplicar AH o ESP; la entrada debía superar el proceso criptográfico y comprobar además que las asociaciones utilizadas, en su orden, cumplían una política aplicable.

El detalle más importante de RFC 2401 era una lista. La Security Policy Database no reunía recomendaciones sueltas: sus entradas estaban ordenadas, y ese orden participaba en la decisión. Un selector comparaba direcciones y campos de capas superiores; la primera política aplicable asignaba uno de tres destinos. El paquete se descartaba, evitaba IPsec o debía recibir protección IPsec.

Publicado en noviembre de 1998, el documento articuló la primera arquitectura consolidada de seguridad para el Protocolo de Internet. Su alcance incluía IPv4 e IPv6 y servicios como control de acceso, integridad sin conexión, autenticación del origen, protección contra repetición, confidencialidad y cierta protección del flujo. No prometía que todos esos servicios aparecieran siempre juntos. AH, ESP, los modos de transporte o túnel, los algoritmos y la gestión de claves se combinaban según la necesidad.

La política debía gobernar todo el tráfico entrante y saliente, incluso el que no usaría IPsec. Una entrada de protección especificaba además el protocolo o conjunto de protocolos, el modo, los algoritmos y el anidamiento requerido. Por eso una regla amplia colocada antes que una excepción estrecha podía alterar el resultado sin cambiar una sola clave. El sentido también formaba parte de la evidencia: seleccionar una acción de salida y validar una entrada eran operaciones distintas.

La segunda estructura era la Security Association Database. Cada Security Association era simplex, una conexión lógica para un solo sentido. La protección bidireccional normalmente requería dos. Una asociación se identificaba mediante el Security Parameters Index, la dirección de destino y el identificador de AH o ESP. Su registro podía incluir claves y algoritmos, secuencias y estado contra repetición, tiempo de vida, modo y estado de MTU de ruta.

Ese registro era necesario, pero no era el paquete. Indicaba que existía un estado operativo con determinados parámetros; no decía qué paquete lo había seleccionado ni si se había usado. Tampoco acreditaba recepción por el par, autorización de la aplicación o resultado del servicio. RFC 2367 había expuesto la administración de claves y asociaciones mediante PF_KEY. RFC 2401 mostró que esa interfaz ocupaba solo una parte de un contrato más largo.

En la salida, el contrato se volvía ejecución. El sistema comparaba el paquete con la SPD. Una decisión de descarte terminaba la ruta. El bypass permitía continuar sin IPsec. Una decisión de protección buscaba una asociación adecuada o iniciaba la creación de la asociación o conjunto requerido. Solo después se aplicaban AH o ESP, en el orden previsto, antes de reenviar o transmitir. La configuración y el estado se encontraban aguas arriba de la transformación.

La entrada añadía una verificación independiente. La dirección de destino, el protocolo de seguridad y el SPI localizaban una asociación. El proceso de AH o ESP podía autenticar origen e integridad, gestionar la repetición y descifrar cuando correspondiera. Que la operación criptográfica tuviera éxito no cerraba la decisión.

Una vez retirados o procesados los encabezados IPsec, el paquete resultante debía coincidir con una política de entrada. La implementación comprobaba entonces que las asociaciones realmente usadas, y su orden, satisfacían esa política. Si una candidata no coincidía, era necesario considerar otras entradas aplicables. Solo tras esa comparación el paquete podía llegar al transporte o continuar su reenvío. Validación bajo una asociación y autorización bajo una política eran hechos diferentes.

La diferencia entre AH y ESP impedía otro atajo. El Authentication Header de 1998 proporcionaba integridad y autenticación del origen, y podía ofrecer protección contra repetición, pero no confidencialidad. ESP podía ofrecer confidencialidad y opcionalmente autenticación e integridad; además protegía campos distintos. Decir que «IPsec cifró el paquete» borraría rutas legítimas de solo autenticación y el caso explícito del bypass.

La arquitectura también reconocía límites externos. La calidad de la implementación, la seguridad del sistema operativo, las fuentes aleatorias y la administración condicionaban el resultado. RFC 3168 actualizó después el tratamiento de ECN. RFC 4301 sustituyó a RFC 2401 en 2005, afinando las bases de políticas, los selectores, los fragmentos y la autorización de pares. El texto de 1998 es historia arquitectónica, no recomendación criptográfica presente.

Lo que conserva valor es la separación probatoria. La política declarada, el estado instalado y la ejecución sobre el paquete pertenecen a capas distintas. Los ensayos de Lu Heng sobre código en funcionamiento, decisión local y capas de realidad permiten leer esa separación con un vocabulario posterior; no son palabras del RFC.

La consecuencia práctica es una cadena de once escalones: fuente y versión, carga de la política, coincidencia ordenada, protección requerida, asociación vigente, operación efectuada, comparación de entrada, entrega a la frontera de red o transporte, recepción remota, procesamiento de la aplicación y resultado del servicio. Ningún escalón temprano autoriza a afirmar uno posterior.

Fuentes