Resumen

  • RFC 2411 asignó las reglas de IPsec a siete familias documentales para evitar que cada nuevo algoritmo volviera a describir ESP, AH, números asignados y gestión de claves con pequeñas contradicciones.
  • La asignación señalaba dónde residía una regla, no qué versión ejecutaba un equipo, qué propuesta habían elegido dos pares, qué SA estaba instalada ni qué resultado había producido un paquete.

Una contradicción normativa rara vez llega al operador con el aspecto de una contradicción. Suele llegar como dos casillas compatibles por separado y una negociación que no encuentra terreno común.

Ese era el problema latente detrás de RFC 2411. En noviembre de 1998, IPsec ya dependía de una arquitectura, dos protocolos de protección, documentos de algoritmos, un dominio de interpretación y mecanismos de claves. La llegada de un cifrado nuevo no debía obligar a reabrir todo el sistema. Pero tampoco convenía que cada autor copiara una explicación abreviada de todo IPsec antes de añadir su transformación.

La copia ofrecía velocidad inmediata y divergencia futura.

RFC 2411 llamó “explosión de borradores” a la acumulación que quería evitar. Su remedio fue una arquitectura de responsabilidad. La arquitectura general poseía los conceptos y requisitos compartidos. ESP y AH poseían sus formatos y reglas de procesamiento. Un documento de cifrado explicaba cómo encajaba un algoritmo concreto en ESP. Un documento de autenticación podía servir a ESP y AH cuando el mecanismo era el mismo. El DOI mantenía los valores con los que unas piezas nombraban a otras. Los textos de gestión de claves se ocupaban de establecer y administrar material secreto.

No era una lista de lectura. Era una regla contra la duplicación de autoridad.

La diferencia aparece con nitidez en el material de claves. El gestor necesitaba producir suficiente material para la combinación elegida, pero no debía convertirse en enciclopedia de cada algoritmo. El documento específico poseía el tamaño, el orden, los bits de paridad, el tratamiento de claves débiles y otras propiedades. La arquitectura describía cómo extraer varias claves de un bloque común.

RFC 2411 dejaba abierta una decisión interna: el gestor podía cortar el bloque antes de entregarlo al núcleo, o el núcleo podía recibirlo entero y hacer allí el “slicing and dicing”. Los pares debían obtener la misma semántica criptográfica. No tenían que compartir la misma frontera de proceso.

Esa decisión local no debilitaba la norma. La afinaba. El estándar común terminaba donde terminaba la necesidad de coordinación.

Las opciones planteaban el problema inverso. Un parámetro que permanecía negociable ampliaba el espacio de combinaciones. Dos implementaciones podían cumplir cada una con una larga lista y aun así no compartir una elección útil. Por eso la hoja de ruta pedía fijar valores cuando fuera razonable. Menos libertad superficial podía producir más interoperabilidad efectiva.

Cuando una opción debía sobrevivir, el texto tenía que justificarla, acotar sus valores y explicar su efecto. La opcionalidad no era silencio. Era una decisión documentada sobre dónde conservar diversidad.

La plantilla propuesta para futuros algoritmos era notablemente concreta. Incluía tamaños de clave, fuentes de aleatoriedad, claves débiles, renovación, rendimiento, formato, relleno, ataques conocidos, interacciones, errores habituales, procedimientos de validación y vectores de prueba. La hoja de ruta no verificaba ninguna de esas cosas. Obligaba a que la especificación más cercana al mecanismo explicara cómo verificarlas.

Ahí se encuentra el límite que una lectura institucional suele borrar. RFC 2411 podía decir qué documento debía contener una exigencia. No podía certificar que la exigencia estuviera bien implementada. Una entrada IANA podía dar un identificador estable. No podía recomendar el algoritmo. Una ficha de producto podía declarar compatibilidad. No podía demostrar la propuesta seleccionada. El registro de IKE podía mostrar una selección. No podía demostrar que ambos extremos hubieran instalado sus estados. Un contador de SA podía mostrar actividad local. No podía demostrar el resultado de la aplicación.

Cada capa necesita su propio recibo.

El propio RFC limitaba su autoridad. Era Informativo y decía que no especificaba un estándar de Internet. Para las reglas de seguridad remitía a la arquitectura, a ESP, a AH y a los documentos de algoritmos. La advertencia de que muchos cifrados requieren autenticación era importante, pero no transformaba el mapa en un perfil de configuración.

La sustitución de la hoja de ruta confirmó esa modestia. RFC 6071 la dejó obsoleta en 2011, cuando los RFC relacionados con IPsec e IKE ya se habían multiplicado en varios grupos de trabajo y protocolos. La nueva hoja se definió como una instantánea. Fechó sus niveles de requisitos, admitió que otros RFC podían cambiarlos y estableció que, ante un conflicto, prevalecía el RFC fuente.

La síntesis era útil precisamente porque no reclamaba soberanía.

RFC 6071 también mostró que el estado documental no describe por sí solo el parque operativo. El nuevo IPsec había reemplazado al antiguo, pero el antiguo seguía siendo común. IKEv2 había reemplazado a IKEv1, pero IKEv1 continuaba desplegado. Declarar una especificación obsoleta modificaba la relación entre documentos. No borraba firmware ni renegociaba túneles.

Mientras tanto, la taxonomía había evolucionado. Los algoritmos combinados merecían una familia propia. Los requisitos obligatorios pasaron a documentos independientes para poder cambiar sin tocar el formato de paquete. IKEv2 reunió materias que IKEv1 distribuía entre ISAKMP, Oakley y el DOI. La separación había contenido la repetición; la proliferación había creado el riesgo de que el lector no encontrara la regla vigente.

No existe una cantidad universalmente correcta de documentos. La frontera adecuada depende del ritmo de cambio. Los formatos de ESP pueden permanecer mientras la evaluación criptográfica cambia. Los números registrados deben ser estables para que los mensajes sean inequívocos; las recomendaciones deben ser revisables para no convertir la estabilidad en aprobación perpetua.

RFC 8221 encarna ese reparto moderno. Actualiza requisitos y consejos de uso porque aparecen algoritmos nuevos, otros se debilitan y los dispositivos tienen capacidades distintas. También deja claro, por estructura, que estar registrado no equivale a ser obligatorio o aconsejable. RFC 9395 pudo deprecar IKEv1 y algoritmos antiguos sin destruir el archivo que explica cómo existieron.

La contribución histórica de RFC 2411 fue, por tanto, una tecnología de límites. Mantuvo lo común en el centro, lo específico cerca del mecanismo y lo interno dentro de la implementación cuando no afectaba al contrato entre pares. Hizo más difícil que un documento lateral reescribiera el sistema por repetición.

Pero la división documental no podía fabricar adopción. Una recomendación se vuelve real cuando una implementación la incorpora. Dos implementaciones forman un conjunto compatible cuando negocian. Una negociación llega al plano de datos cuando ambos lados instalan estado. Y sólo el paquete observado permite hablar del comportamiento que efectivamente ocurrió.

La hoja de ruta repartió la autoridad entre textos. La red conservó la última palabra sobre la realidad.

Fuentes