Resumen

  • RFC 2367 definió una API de socket privilegiada entre una aplicación de gestión de claves y el Key Engine local. Su respuesta no es un veredicto distribuido entre los dos extremos.
  • SADB_GET, SADB_DUMP y los estados LARVAL, MATURE, DYING y DEAD informan sobre registros locales; no demuestran identidad remota, política vigente ni uso por un paquete.
  • La conclusión segura exige unir autoridad del proceso, transacción PF_KEY, custodia de claves, negociación remota, decisión SPD, procesamiento AH/ESP, recepción y resultado de aplicación.

El valor histórico de PF_KEY está en su separación de funciones. El demonio de claves usa PF_KEY para hablar con el Key Engine del núcleo. Usa PF_INET o PF_INET6 para hablar con una entidad remota. IPsec consulta las asociaciones mediante otra interfaz interna. La primera conversación puede terminar bien aunque la segunda falle o la tercera nunca procese tráfico.

La API cubre un ciclo local completo. SADB_ADD instala una asociación; SADB_GETSPI reserva el índice y SADB_UPDATE completa los datos; SADB_GET recupera una copia. ACQUIRE solicita que un gestor intente crear estado, EXPIRE anuncia un límite, y DELETE o FLUSH retiran entradas. Son operaciones concretas, pero su autoridad termina en el sistema que las ejecuta.

La madurez no sale del host

Los nombres de estado pueden engañar. LARVAL sigue a la reserva del SPI. MATURE sigue a la adición o actualización. DYING y DEAD corresponden a los límites blando y duro. La palabra madura no informa si el otro extremo instaló su asociación direccional, si autenticó la identidad correcta, si la autorizó para esos selectores o si vio un solo paquete.

Tampoco basta con enumerar campos. El SPI sirve para localizar una SA; no es una credencial. El identificador de algoritmo describe una opción, no la protección real de la clave. El contador de vida es local. Una asociación puede incluso declarar cero para autenticación o cifrado. La semántica exacta de cada campo impide que “fila completa” se convierta en “túnel seguro”.

SADB_DUMP agrava la ilusión porque parece total. Devuelve la tabla local, una asociación por mensaje, y marca el final. Sin embargo, RFC 2367 lo reserva al diagnóstico y dice que una aplicación no debe depender de él para funcionar. Además, la entrega de mensajes PF_KEY no está garantizada cuando se llenan los búferes. Una captura puede ser íntegra como fotografía y defectuosa como historia.

El permiso para escribir también es seguridad

PF_KEY solo debía estar disponible para procesos fiables y privilegiados. La interfaz manual puede dominar las asociaciones del núcleo. El propio RFC advierte que, si un usuario sin privilegios puede crear, leer, modificar o borrar ese estado, el sistema operativo no puede prestar el servicio asociado.

Por eso la primera pregunta no es “¿existe la SA?”, sino “¿quién la escribió?”. El expediente debe fijar identidad del proceso, ejecutable, versión de configuración, decisión operativa y permisos. La custodia de la clave se documenta sin revelar el secreto. Que una respuesta UPDATE omita el material de clave porque algunos oyentes no pueden verlo demuestra la diferencia entre observar estado y poseer el secreto.

La ruta de prueba continúa fuera de la API

RFC 4301 hace que el SPD decida BYPASS, DISCARD o PROTECT. Una entrada SAD puede quedar después de cambiar o borrar su política, y una SA manual puede carecer de entrada SPD. Existencia no equivale a aplicabilidad.

RFC 7296 sitúa en IKEv2 la autenticación de identidades, la autorización PAD, los selectores y las Child SAs. Los extremos pueden discrepar temporalmente sobre el estado, sobre todo cuando se pierden mensajes. Nada de eso se deduce de una fila local.

RFC 4303 lleva ESP al paquete: selección de servicios, transformación de salida y verificación de entrada. Aún después hay reenvío, recepción, transporte y autorización de aplicación. Un contador es un testigo parcial, no el desenlace.

La evidencia útil forma una cadena: proceso autorizado; petición y respuesta PF_KEY; generación SAD y SPD; procedencia protegida de la clave; intercambio remoto autenticado y autorizado; coincidencia del flujo; resultado AH/ESP; observación en el receptor; y respuesta de la aplicación. Si falta un eslabón, el informe debe decirlo.

Fuentes