Resumen

  • En transición, un nodo puede emitir HMAC-MD5 y no verificarlo al recibir. Otro que no implemente el mecanismo puede aceptar el PDU. La presencia del TLV no certifica el filtro de entrada.
  • El conjunto de contraseñas, la forma especial de purge y la recuperación de secuencia tras rollover son decisiones distintas. Autenticidad tampoco significa topología correcta, convergencia ni entrega.

El mismo PDU ante dos puertas

RFC 5304 asigna el tipo de autenticación 54 a HMAC-MD5 dentro del TLV tipo 10. El cálculo pone a cero el Authentication Value y, para LSP, también checksum y Remaining Lifetime. El procedimiento define cómo verificar. No afirma que todo receptor lo haga.

El modo de transición permite producir el HMAC en salida y omitir la comprobación en entrada. Es útil para desplegar por etapas, pero crea una apariencia prematura: todos los paquetes pueden llevar material criptográfico cuando todavía existe una vía de aceptación no verificada.

Además, una implementación que no realiza HMAC-MD5 puede aceptar un PDU con ese tipo. Un campo no otorga capacidad al receptor. Para quien sí implementa el mecanismo, en cambio, una Authentication Value incorrecta obliga a descartar. La diferencia entre ambos casos reside en configuración, capacidad y política local, no en la imagen del paquete.

El recibo útil debe incluir: algoritmo disponible, verificación activa, conjunto de claves cargado, resultado, decisión y cambio de estado. «TLV presente» ocupa solo la primera parte de esa cadena.

RFC 5304 es Standards Track de 2008 y sustituyó RFC 3567. Su análisis de HMAC-MD5 pertenece a esa fecha; no debe presentarse como recomendación actual para nuevas redes.

Varias contraseñas pueden producir un único verde

La clave aplicable depende del PDU: SNP de nivel 1 usan ámbito de área, SNP de nivel 2 ámbito de dominio e IIH una cadena de enlace potencialmente distinta. Una política global llamada “auth” puede esconder protecciones desiguales.

Durante una rotación, el verificador puede probar un conjunto de contraseñas. Se mantiene continuidad, pero el éxito no identifica la clave ganadora. El verde puede corresponder a la clave nueva, a la antigua o a cualquiera de varias candidatas. Sin telemetría de selección, no se demuestra que el secreto retirado dejó de tener autoridad.

La superposición debe tener propietario, ámbito, comienzo y final. Si no termina, el mecanismo de migración se convierte en ampliación permanente de confianza. RFC 5310 introdujo después Key IDs y asociaciones HMAC-SHA; mejora la expresividad, pero un identificador tampoco prueba por sí mismo que todos los receptores aplican la misma cadena.

Borrar estado requiere otra forma de autoridad

Una purge fija la vida restante de un LSP en cero y pretende retirar estado. RFC 5304 obliga al originador compatible a quitar el cuerpo, dejar el TLV de autenticación y nada más. El receptor no debe aceptar purge sin autenticación ni con otros TLV.

Así se evita que un atacante copie un LSP válido, cambie la vida a cero y lo inunde sin conocer la contraseña. El poder de repetir una publicación no se transforma automáticamente en poder de borrarla.

La observabilidad debe separar digest válido y purge válida. Registrar forma reducida, ausencia de TLV extra, clave aceptada y efecto de eliminación permite saber qué autoridad actuó. Rechazar una purge con cuerpo puede ser exactamente el resultado seguro.

La clave nueva puede perder frente a la secuencia vieja

Tras el rollover, un reinicio puede devolver la secuencia local a 1 bajo la contraseña nueva. Los vecinos conservan el LSP anterior con número mayor y rechazan la versión nueva. El router necesita aprender ese número alto de la copia que los vecinos le devuelven.

Pero esa copia lleva la contraseña antigua y ahora falla autenticación. El proceso no puede autenticar su propio estado histórico ni elevar la secuencia por el camino normal. Puede quedar bloqueado hasta que expire la copia vieja.

RFC 5304 propone mirar un caso limitado: LSP entrante fallido, System ID local y secuencia superior. El proceso puede adoptar la coordenada de secuencia y volver a originar bajo la clave actual. Como un adversario puede disparar la condición, se recomienda un contador.

No se acepta el contenido como verdadero. Se utiliza un número no confiable para reparar el espacio local y luego se publica de nuevo con autenticación. Precisamente por esa excepcionalidad, cada uso necesita evidencia.

Un router autenticado todavía puede equivocarse

La especificación eleva el esfuerzo frente a contraseñas en claro, pero no elimina replay ni denegación de servicio. Tampoco protege de routers comprometidos, averiados o mal configurados. Un participante con clave puede producir información falsa con un MAC correcto.

El HMAC acredita origen dentro del grupo que comparte la clave e integridad de los campos cubiertos. No acredita autorización semántica para cada anuncio, igualdad de LSDB, instalación de FIB o entrega de tráfico. Además depende del algoritmo, calidad de clave, implementación y confidencialidad en todos los miembros.

Límites

No afirmamos que una plataforma actual acepte sin verificar, que un operador use HMAC-MD5 o que exista una incidencia. Las decisiones actuales requieren RFC posteriores y guía criptográfica vigente. Las comprobaciones reales necesitan configuración, counters, clave seleccionada, tiempos de rollover, logs de purge, LSDB y plano de datos.

La tesis es de evidencia: material, capacidad, verificación, clave, regla de mensaje y resultado son estados separados. Auditar solo lo que circula deja sin auditar la puerta.

Fuentes