Resumen

  • La revisión 08 de draft-nir-ipsecme-big-payload, subida el 10 de septiembre de 2026, mantiene el diseño de la 07. El diff oficial muestra mantenimiento editorial y de referencias, no una nueva negociación de recursos.
  • La propuesta reutiliza un bit reservado como indicador L para que la longitud de una carga pase de 16 a 32 bits, después de que el receptor anuncie LARGE_PAYLOAD_SUPPORTED en IKE_SA_INIT.
  • El aviso es booleano: no indica tamaño máximo, memoria, coste de procesamiento, ámbito por intercambio o tipo de carga, ni concurrencia. El propio texto permite límites razonables de implementación.
  • El registro actual lo muestra como candidato activo para IPSECME con llamada de adopción emitida, sin shepherd ni aprobación del IESG; el valor solicitado tampoco figura aún en IANA.

Una respuesta binaria para una pregunta cuantitativa

El anuncio propuesto sirve para evitar una ambigüedad concreta en el cable. Cuando llega una carga con el bit L, el receptor sabe que los dos octetos siguientes ya no completan la longitud corta: forman parte de un campo de cuatro octetos. Eso es suficiente para elegir el analizador correcto.

No es suficiente para reservar recursos. LARGE_PAYLOAD_SUPPORTED no dice si el techo local está en 128 kilobytes o en varios megabytes. No limita la promesa a certificados, borrados u otra clase de carga. No expresa memoria de reensamblado, tiempo de CPU, número de intercambios simultáneos ni una condición de presión. Convertir el aviso en permiso para enviar cualquier valor representable en 32 bits añadiría al protocolo una obligación que no contiene.

El punto de partida es una asimetría histórica en RFC 7296. El encabezado del mensaje IKE completo tiene cuatro octetos para Length, mientras que cada cabecera genérica de carga usa dos. Por eso el mensaje puede describir una longitud amplia y, al mismo tiempo, una sola carga queda limitada a menos de 65 536 octetos. El bit Large pretende retirar esa barrera interna.

Retirar una barrera de codificación no retira los límites físicos ni las decisiones de seguridad del receptor.

Lo que el mecanismo sí obliga a hacer

El par envía la notificación de estado sin datos durante IKE_SA_INIT. Sin embargo, no puede incluir una carga grande en ese mismo intercambio. Para material inicial de intercambio de claves que exceda el formato ordinario, el borrador remite al IKE Intermediate Exchange de RFC 9242.

La capacidad puede existir en una sola dirección. Quien anuncia soporte afirma que puede procesar el formato extendido. Si no recibió el mismo aviso, no está autorizado a enviarlo al otro lado. No hay, por tanto, un “modo grande” común que reserve automáticamente los mismos recursos en ambos extremos; hay permisos de formato por dirección.

También hay una regla para longitudes imposibles. El receptor compara el valor prometido con los octetos que quedan dentro del mensaje IKE. Si faltan octetos, responde con INVALID_SYNTAX. Si están presentes, debe tramitar la carga como las demás y no descartarla sólo porque su longitud habría cabido en la variante corta. La comprobación conserva una interpretación uniforme. No convierte todos los objetos bien formados en admisibles bajo cualquier carga del sistema.

Un DELETE grande no es un cheque en blanco

El ejemplo operativo del documento es una carga DELETE que enumera SPI de IPsec. Cada SPI ocupa cuatro octetos. El contador admite hasta 65 535 entradas, pero el campo corto de longitud no permite reunirlas en una sola carga. Con la nueva cabecera, la lista completa mediría 262 150 octetos.

La cifra prueba que existe un caso que el formato actual no representa. No prueba que todos los productos deban procesar la cifra máxima. El borrador deja expresamente que las implementaciones apliquen límites razonables al número de SPI. Un equipo puede aceptar cabeceras largas y, de forma correcta, poner un techo menor según memoria, coste o política de defensa.

Si ese techo queda implícito, la interoperabilidad se vuelve ensayo y error. Un remitente sólo aprende la frontera por esperas, fallos generales o degradación. Un equipo de operaciones tampoco puede distinguir de inmediato un rechazo deliberado de una implementación incompleta. La palabra “soportado” termina ocultando la información que más importa al administrar riesgo.

Fragmentar o usar TCP no declara capacidad

RFC 7383 permite fragmentar mensajes IKE cifrados para sortear problemas de tamaño a lo largo del camino. RFC 9329 describe IKEv2 e IPsec sobre TCP cuando UDP está bloqueado o deteriorado. Ambos pueden mejorar el transporte. Ninguno anuncia un presupuesto de memoria o de trabajo del receptor.

Los fragmentos siguen necesitando estado y reensamblado. Una corriente TCP fiable puede entregar una carga completa, pero no decide si procesarla sería prudente en ese instante. El sistema tiene tres planos distintos: el bit Large elige cómo se representa la longitud; la fragmentación o TCP ayudan a llevar los bytes; la política local decide qué cantidad entra.

La noticia es la continuidad, no un rediseño

El 10 de septiembre se publicó la revisión 08. La comparación oficial con la 07 cambia fechas y caducidad, corrige “than” por “that” y actualiza una referencia a Classic McEliece. No aparece una unidad nueva en la notificación ni un protocolo para descubrir límites. La arquitectura relevante ya estaba en la revisión anterior.

También conviene conservar la pluralidad del expediente de proceso. Datatracker califica el texto de candidato activo para IPSECME y muestra “Call For Adoption By WG Issued”. El historial registra que el 22 de julio se asignaron el grupo y el stream IETF y se emitió la llamada; el mensaje de la lista cerraba comentarios el 15 de agosto. El aviso automático de la revisión 08 dice que el documento “is a work item” de IPSECME.

Al mismo tiempo, la página vigente no muestra shepherd, mantiene el estado del IESG en “I-D Exists” y no asigna director de área ni telechat. El nombre draft-nir es compatible con un borrador individual, pero el nombre de archivo no decide la adopción. La conclusión responsable es exponer las dos capas del registro, no declarar adoptado ni rechazado el trabajo.

El cuerpo aspira a Standards Track y señala que actualizaría RFC 7296 si fuese aprobado. La metadata de Datatracker dice actualmente “(None)” en intended status. Es una discrepancia descriptiva. Además, el registro IANA de tipos de aviso IKEv2 no contiene LARGE_PAYLOAD_SUPPORTED: solicitar una asignación no equivale a recibirla. No hay prueba en las fuentes revisadas de consenso IETF, aprobación del IESG, RFC, implementación, prueba de interoperabilidad, despliegue o incidente.

Fuentes