Resumen

  • draft-smyslov-ipsecme-ikev2-psp-02 coloca el intercambio de claves PSP después de autenticar a los pares: primero una IKE SA sin Child SA, después un CREATE_CHILD_SA modificado con una Key Download en cada dirección.
  • Cada receptor elige el SPI y entrega al otro extremo la clave con la que ese extremo deberá transmitirle. Recibir el mensaje prueba una entrega de control; no prueba instalación en la NIC, cifrado del primer paquete ni validación en el receptor.
  • PSP no ofrece revocación individual de claves derivadas ni control propio de replay. El cambio de SA, la doble rotación de claves maestras, el rechazo de duplicados y la entrega a la aplicación requieren recibos distintos.

La simetría del protocolo puede ocultar una avería unilateral

Dos pares IKEv2 terminan una negociación. La petición lleva una propuesta PSP, selectores de tráfico, un SPI y una Key Download. La respuesta devuelve el conjunto equivalente. En el registro central aparecen dos flechas y una transacción completa. Ese dibujo no muestra si ambos sistemas programaron la clave recibida.

Supongamos que el extremo A carga de inmediato la clave de B en su NIC. Los paquetes A→B salen con PSP, B deriva la clave a partir del SPI y autentica el ICV. En cambio, el extremo B deja la clave de A en una cola porque su tabla de transmisión está llena. El mismo CREATE_CHILD_SA ha producido un camino protegido y otro inexistente. El protocolo de control no está equivocado; la lectura del operador es demasiado amplia.

El borrador actual, draft-smyslov-ipsecme-ikev2-psp-02, especifica cómo suministrar claves PSP mediante IKEv2. Sus versiones HTML y XML no añaden una confirmación de instalación. La sección Security Considerations sigue pendiente. Por tanto, una afirmación de seguridad operativa necesita evidencia que el texto todavía no define.

En PSP, la clave nace del lado que recibirá

La arquitectura PSP evita guardar una clave de recepción por cada SA. La NIC receptora conserva dos claves maestras y deriva la clave de una asociación a partir de una de ellas y del SPI del paquete. El bit superior del SPI elige la clave maestra; el resto identifica la asociación dentro de ese periodo.

El receptor conoce qué maestra está activa y debe escoger el SPI. Después entrega la clave derivada al otro extremo, que la necesita para transmitir hacia él. Para tráfico bidireccional se repite el proceso al revés, porque una SA PSP es unidireccional.

Ese diseño cambia la pregunta de custodia. No basta con saber que «los pares comparten una clave». Cada dirección tiene un receptor que origina material, un emisor que debe instalarlo y una ruta de paquete que debe usarlo. Los registros deben conservar esa orientación. Si se guarda solo una pareja de nodos y un estado global, una dirección puede parecer sana por la prueba de la otra.

RFC 7296 deriva normalmente material de Child SA de SK_d, nonces y, cuando corresponde, un intercambio Diffie-Hellman. El borrador PSP reutiliza la capacidad de descargar material arbitrario definida en RFC 9838. Esa reutilización transporta la clave que el receptor controla; no confirma lo que el emisor hace con ella.

Una IKE SA sin Child SA protege el orden de confianza

En IKE_SA_INIT, los pares negocian un Key Wrap Algorithm. El respondedor anuncia CHILDLESS_IKEV2_SUPPORTED. La extensión de RFC 6023 permite terminar la autenticación de IKEv2 sin intentar todavía una Child SA.

El borrador exige ese orden porque la clave que entrega el iniciador es sensible. Si viajara durante IKE_AUTH, podría llegar a un respondedor que aún no ha sido autenticado. Primero se autentican los pares; después se intercambia el material PSP.

Esto prueba que la secuencia de confianza importa. También delimita el recibo. IKE_AUTH identifica al par de control según el método elegido, no a la cola física que cifrará. CHILDLESS_IKEV2_SUPPORTED anuncia una capacidad, no una SA PSP activa. El Key Wrap Algorithm puede coexistir en una IKE SA que más tarde cree SA ESP o PSP. Ninguna de esas señales aisladas equivale a un paquete protegido.

Un operador debería conservar tres estados: capacidad negociada, peer autenticado y material de Child SA aceptado. El cuarto estado, instalación local, debe venir del dispositivo que ejecutará la transmisión.

Los enlaces del mensaje son fuertes y aún insuficientes

El CREATE_CHILD_SA modificado incluye un identificador de protocolo PSP todavía <TBA>, parámetros PSP todavía <TBA>, Traffic Selectors y una Key Download por sentido. Un Key Bag relaciona su SPI con una propuesta, y SA_KEY contiene el material envuelto con SK_w = prf+(SK_d, "Key Wrap for PSP").

Ese conjunto permite reconstruir una decisión de control: quién estaba autenticado, qué tráfico se pretendía cubrir, qué algoritmo se ofreció y qué SPI acompañó a la clave. No especifica la API entre el proceso IKE y el plano de datos.

El repositorio público PSP, hoy archivado, contiene una implementación de referencia y describe distintas formas de gestionar claves de transmisión. Una NIC puede usar una tabla de flujo en chip, una base de SA en RAM o material asociado a descriptores. Cada modelo tiene límites y recibos diferentes. El repositorio prueba que existe código público, no que un producto o centro de datos use una variante ni que la instalación sea atómica.

Por eso el acuse local debe nombrar el objeto de ejecución: NIC, función virtual, cola, índice de SA o descriptor; también el SPI, la época y el resultado del controlador. No hace falta registrar la clave en claro. Sí hace falta demostrar que la referencia correcta llegó al lugar correcto.

“Sin estado” no elimina las decisiones de estado

PSP reduce el almacenamiento de claves por SA en recepción. Mantiene dos maestras, una marca de actividad, asignación de SPI, vidas útiles y rotación. El emisor conserva sus claves de transmisión. Las capas superiores pueden mantener listas de SPI admitidos. Una NIC expone contadores y errores.

RFC 4301 separa la administración de asociaciones de la política y del procesamiento de paquetes. RFC 4303 muestra la misma separación para ESP. PSP cambia la economía de memoria; no convierte el control en ejecución.

La palabra “stateless” tampoco es una medición de capacidad. La especificación habla de millones de SA y tasas altas de actualización como consideraciones de escala. No garantiza que una NIC concreta acepte la siguiente clave cuando su tabla, DMA o cola de órdenes está bajo presión. Un servicio de IKE puede seguir respondiendo a tiempo mientras el dispositivo acumula retraso.

Un canario PSP completa una proposición más pequeña

La arquitectura pide contadores de paquetes y bytes PSP TX/RX correctos, fallos de autenticación o cifrado, errores de formato y SPI con maestra inválida. También prevé una bandera de autenticación correcta y metadatos SPI para software superior.

Esas señales permiten diseñar un canario. Primero se conserva el intercambio IKE y el acuse de instalación. Se envía un paquete PSP limitado y reconocible. El emisor confirma el contador TX; el receptor registra el SPI, deriva con la época esperada, valida el ICV e incrementa RX. La capa superior confirma que recibió el contenido previsto.

El resultado prueba ese trayecto y ese momento. No demuestra que todo el flujo posterior esté protegido. Para eso se necesitan muestreo continuo, invariantes y alarmas. Pero el canario ya es mejor que usar la entrega de clave como test indirecto de una cadena que el control no observa.

La asimetría debe verse: A→B y B→A tienen recibos independientes. Un indicador global solo puede ponerse verde cuando ambas direcciones requeridas cumplen su propio contrato.

Rekey significa solapamiento antes que sustitución

REKEY_SA puede señalar la SA PSP que se pretende reemplazar. El patrón general de IKEv2 crea una nueva asociación y después mueve tráfico y elimina la antigua. La respuesta de creación no prueba el corte.

Los operadores necesitan tiempo y secuencia: primer paquete en el nuevo SPI, último en el antiguo, cambio de clasificación, eliminación en ambos extremos y cualquier pérdida o reordenamiento. Si una dirección cambia antes que la otra, el sistema puede funcionar parcialmente y ocultar la dependencia antigua.

La rotación maestra añade dos periodos. Al activar la segunda maestra, la anterior sigue derivando claves de asociaciones vivas. Solo otra rotación la expulsa. La especificación PSP indica además que no hay revocación individual de claves derivadas. Marcar una SA como revocada en una base administrativa no impide por sí solo que la NIC acepte un SPI mientras la maestra correspondiente sobreviva.

La prueba de retirada requiere migrar cada SA, observar el nuevo tráfico, cerrar el antiguo estado y finalmente verificar la época que ya no puede derivarse.

Replay es una obligación transferida, no resuelta

PSP no incorpora protección contra replay; espera que la capa 4 ofrezca una defensa equivalente. IKEv2 no añade ese veredicto al entregar la clave. Un paquete puede tener un ICV válido y aun necesitar una decisión sobre duplicación.

No se debe concluir que todo PSP desplegado carece de protección. Se debe exigir que el propietario de la afirmación nombre la capa que rechaza, su estado, el dato observado y el resultado. Un SPI o un IV visible no sustituye ese registro.

Esta separación evita usar la autenticidad criptográfica como autorización o resultado. Un paquete puede ser auténtico para una SA y ser descartado por lista de SPI, política, transporte o aplicación. Cada descarte tiene significado distinto.

La fecha nueva no implica texto técnico nuevo

La API de Datatracker muestra la revisión 02 del 30 de septiembre de 2026 y expiración el 3 de abril de 2027. La página del documento lo identifica como Internet-Draft individual activo; el historial registra tres revisiones.

La diferencia con la revisión 01 se limita a fecha, número, expiración y encabezados. La mecánica no cambió. El encabezado dice Experimental, pero Datatracker no registra stream, RFC, Area Director ni nivel de estándar. La sección de seguridad sigue vacía.

Las asignaciones solicitadas siguen como <TBA>. El registro IANA de IKEv2 es la referencia para valores efectivos. El borrador no debe presentarse como asignación, adopción, interop o despliegue.

Fuentes y límites

La base técnica comprende la revisión 02 en texto, HTML y XML; sus registros Datatracker; RFC 7296, RFC 6023, RFC 9838, RFC 4301, RFC 4303, IANA y el repositorio y arquitectura PSP. Ninguna fuente prueba un uso de producción, rendimiento, conformidad, vulnerabilidad, incidente ni resultado de servicio.