Resumen

  • RFC 9611 permite varias Child SA con los mismos TSi/TSr para que recursos distintos mantengan claves y secuencias independientes, evitando que un contador compartido serialice el cifrado.
  • SA_RESOURCE_INFO expresa que las SA forman un grupo lógico. Su identificador opcional solo sirve para depuración; no ordena una CPU remota. TS_MAX_QUEUE limita ese par de selectores, no toda futura Child SA.
  • Negociar no demuestra capacidad: hay que comprobar cada dirección instalada, el vínculo local a recursos, la distribución de paquetes, los contadores de replay y pérdida, el rekey, la eliminación y el rendimiento de servicio.

Los dos equipos completan varias negociaciones. Los selectores de tráfico son idénticos y cada fila tiene su SPI. Sin embargo, un extremo puede recibir por todas las SA y transmitir solo por una; el otro puede tener ocho contextos instalados y un planificador que alimenta casi exclusivamente al primero. El protocolo ha cumplido. El paralelismo todavía no.

RFC 9611 se ocupa de un cuello de botella concreto. Una única Child SA obliga a coordinar estado criptográfico, contadores y números de secuencia entre recursos. El bloqueo puede convertir muchos núcleos en una cola. Crear miembros independientes con la misma política conserva antirreplay y ofrece un espacio de secuencia por recurso.

El mecanismo no intenta imponer la arquitectura de una máquina sobre la otra. IKEv2 comunica pertenencia al grupo y un rechazo preciso cuando el conjunto crece demasiado. La selección de CPU, cola o acelerador permanece bajo control del operador local.

Igual cobertura no significa igual trabajo

Las Child SA adicionales deben conservar algoritmos, Traffic Selectors, modo, compresión y demás propiedades del miembro inicial. Esa igualdad impide cambiar la seguridad bajo la etiqueta de expansión. Cada miembro sigue derivando sus propias claves y mantiene su propio SPI y contador.

La diferencia importa al observar dos direcciones. Un equipo con menos recursos puede omitir una copia saliente que nunca utilizará, pero debe instalar todas las SA entrantes negociadas porque prometió aceptar paquetes en ellas. El inventario visible desde IKE no revela esa asimetría permitida.

El Resource Identifier opcional tampoco la resuelve. Debe ser distinguible dentro del grupo, pero el par solo puede usarlo para depurar. Un número físico de CPU filtraría información del hardware y podría ayudar a correlacionar ataques. Además, una etiqueta local no tiene significado de programación en el otro extremo.

El contador explica el diseño

RFC 4303 sitúa la secuencia ESP en la defensa antirreplay, y RFC 6479 aporta contexto sobre la ventana de recepción. El paralelismo de RFC 9611 no elimina esos controles; crea varios dominios válidos para evitar un único punto de sincronización.

El ejemplo de 5 Gbit/s en una CPU frente a 40–60 Gbit/s en 25–30 CPU explica el incentivo, no constituye una promesa. Otro cifrado, NIC, tamaño de paquete, mezcla de flujos, kernel o acelerador producirá otro resultado. Un informe serio debe mostrar paquetes y bytes por SA, ocupación local, reordenamiento, fallos de integridad y replay, pérdida, latencia y caudal recibido.

Una media agregada puede esconder que un sentido sigue bloqueado o que una única SA transporta el flujo elefante. La capacidad solo existe donde el trabajo se reparte y el servicio lo confirma.

La demanda simultánea multiplica el estado

Las SA pueden crearse todas juntas o bajo demanda. Una SA genérica disponible para todas las CPU puede mantener tráfico durante la negociación, que suele costar una ida y vuelta. Reenviar el paquete a una CPU ya preparada también funciona, pero paga otra penalización.

Ambos pares pueden iniciar al mismo tiempo. El paquete que dispara la primera adquisición viaja por la SA existente y la respuesta dispara otra adquisición. En el rekey, las SA nuevas conviven temporalmente con las antiguas. Por eso RFC 9611 recomienda admitir al menos el doble del número de CPU, en vez de convertir el inventario físico en un techo rígido.

Cuando el límite de un TSi/TSr se alcanza, TS_MAX_QUEUE conserva el alcance exacto. Responder NO_ADDITIONAL_SAS podría impedir por interpretación una asociación con selectores distintos. Un error pequeño protege la libertad de evolución.

Borrar una SA no crea el camino de regreso

Una SA ociosa puede eliminarse. Si el sistema no incluye CPU o cola en su evento local de adquisición, quizá no sepa cuándo volver a crearla. La recreación inmediata puede entrar en bucle con un par que vuelve a borrarla. No recrearla deja a ambos lados detenidos en la primera SA.

El problema no está en el Delete Notify, sino en la falta de una política posterior. El disparador, su propietario, el backoff y la prueba de recuperación deben existir. RFC 2367 contextualiza SADB_ACQUIRE; RFC 9611 recomienda añadir localmente la identidad del recurso a ese camino.

También hay una consecuencia de claves. Mover una SA y reponer una mitad saliente omitida puede requerir material que el demonio IKE habría destruido. La política de borrado de claves, el movimiento de recursos y la continuidad forman una sola decisión local, aunque nada de ello aparezca en la notificación del par.

La confianza limita el caso de uso

El modelo encaja en pasarelas de gran volumen cuyos administradores confían entre sí. Cada SA adicional consume memoria y búsqueda SAD; cientos o miles pueden degradar el procesamiento. El receptor debe limitar miembros por combinación de selectores.

En acceso remoto, muchos clientes menos confiables podrían convertir la optimización en una solicitud de estado controlada desde fuera. RFC 9611 desaconseja el modo por CPU y su activación predeterminada en ese entorno. El hecho de que una extensión sea estándar no elimina la economía del abuso.

La cadena completa queda formada por política, negociación, dominio criptográfico, instalación entrante, instalación saliente, ubicación local, distribución, ciclo de vida y resultado. Solo el último permite hablar de capacidad entregada.

Fuentes