Resumen

  • RFC 9986 compara una Auth Key de 32 bits derivada de una secuencia ISAAC con clave. La coincidencia puede indicar conocimiento del material compartido y una posición aceptable, pero no autentica los demás campos del paquete.
  • La evidencia útil debe conservar versión, discriminators, época de clave, seed, ventana, estado de páginas ISAAC, resultado y posterior reautenticación MCI. No debe convertirse en una afirmación sobre ruta o servicio.

En una consola de laboratorio, dos números eran iguales y el caso aparecía en verde. En la minuta de cambio, aquella observación se convirtió en «tráfico BFD autenticado». Ya no era un resumen: era una afirmación distinta, porque el cálculo nunca había cubierto el paquete completo.

El caso es hipotético y no atribuye hechos a producto, operador ni incidente alguno. La frontera está en RFC 9986. Meticulous Keyed ISAAC ocupa el papel LCI de la optimización definida por RFC 9985. El propio documento advierte que esos paquetes no están firmados ni autenticados como paquetes y que no pueden señalar cambios de estado.

La prueba responde a algo más preciso: ¿puede el receptor reproducir el valor de 32 bits esperado a partir del secreto, los datos de la sesión BFD, el seed y una posición permitida de la secuencia? Si coincide, hay una señal de conocimiento del emisor y sincronía. No hay un vínculo criptográfico que cubra Diagnostic, State, flags, temporizadores, discriminators ni el resto del cuerpo.

Que el campo se llame Auth Key no amplía su alcance. La revisión debe enumerar qué entradas participan en la derivación y qué bytes quedan fuera, en vez de inferir una garantía por el nombre de la sección.

RFC 9986 define tipo y longitud, Key ID, seed, desplazamiento de secuencia y Auth Key de 32 bits. El receptor selecciona la clave, contrasta el seed, busca una posición en la ventana admitida y calcula el candidato. Una igualdad supera esa comprobación LCI; no verifica un MAC sobre el paquete.

RFC 8439 ofrece un contraste conceptual. En AEAD, el tag autentica ciphertext y datos asociados. No se propone trasladar ese algoritmo a BFD; se usa para no llamar equivalentes a la validación de contenido y a la comparación de una sola salida seudorrandom.

La máquina ISAAC introduce tiempo y memoria. Produce resultados por páginas y avanza de modo destructivo. Para tolerar pérdidas, demora o reordenación dentro de una ventana, el receptor puede calcular por adelantado. La RFC exige guardar y restaurar el estado cuando se genera una página prospectiva. Si una consulta desplaza el generador activo, el siguiente paquete correcto puede parecer incorrecto y la auditoría pierde la posibilidad de reconstruir la aceptación.

El seed separa épocas. Cada transición a Up requiere uno nuevo, que queda fijo durante esa época Up. Registrar únicamente «Key ID y match» elimina el contexto que hace interpretable la secuencia. Hay que conservar seed, época Up, posición y regla de ventana. El secreto permanece protegido; sí puede registrarse su ciclo de provisión y rotación.

La reutilización permitida de claves tampoco equivale a ausencia de riesgo. Las entradas de sesión diferencian las salidas, pero una clave que abarca muchas sesiones aumenta el radio de una filtración, una rotación desigual o un archivo incompleto. La unidad de control debe ser la población cubierta, las entradas de derivación, el dueño y la caducidad de la época.

La ficha del RFC Editor clasifica el documento como Experimental. Reduce coste a cambio de menor seguridad, considera ISAAC como mucho tolerable en este uso, reconoce criptoanálisis limitado y falta de prueba, y descarta su uso en otros protocolos IETF. El trabajo de IACR justifica cautela; no demuestra un ataque contra RFC 9986 ni contra una red real.

Tampoco existe una insignia automática de interoperabilidad. RFC 9986 sirve a la arquitectura concreta de RFC 9985, no a cualquier autenticación de RFC 5880. El registro IANA BFD Parameters asigna valores; no prueba implementación, adopción o funcionamiento.

RFC 5881 mantiene a BFD en el ámbito de un trayecto de reenvío de un salto. RFC 7419, RFC 8177 y RFC 9127 completan el contexto criptográfico. Ninguna convierte la aceptación LCI en evidencia de la ruta seleccionada, una transacción de aplicación o la experiencia del usuario.

La reautenticación MCI periódica de RFC 9985 es un control separado. Puede acotar el tiempo de un Up indebido según el intervalo configurado, pero no autentica retrospectivamente el contenido de cada paquete ISAAC intermedio. Conviene unir los eventos sin fundir sus significados.

Las capas de realidad de Heng Lu separan norma, capacidad, configuración, Auth Key observada, estado BFD, reacción del cliente y resultado de servicio. Running-Code Primacy da prioridad al comportamiento medido sobre la etiqueta. Minimum Initial Specification permite acordar un recibo estrecho y dejar la acción posterior a quien responde por ella.

Ese recibo incluye RFC y errata, build, discriminators, Key ID, época de provisión, seed y época Up, posiciones enviadas y aceptadas, ventana, página ISAAC y restauración, resultado, campos no protegidos, MCI, reacción, dueño de la decisión y rollback. Debe permitir reproducir la lógica sin revelar el secreto.

La coincidencia sirve, siempre que nadie la obligue a probar algo que nunca calculó.

Fuentes