Summary

  • Un borrador individual del 2 de noviembre propone anunciar mediante IS-IS GENINFO el identificador y la dirección IP de un gestor de claves, además de la tasa de generación de claves de un enlace QKD. El controlador usaría esos datos para ordenar los relevos.
  • El texto dice que IS-IS pasa KM-IP al controlador sin validar su formato. La publicidad de una dirección ofrece un candidato; autorizarlo como custodio de claves exige otra decisión.

Una aplicación o entidad gestora pide claves e indica origen, destino y tasa necesaria. Según la arquitectura propuesta, el controlador reúne los datos de nodos y enlaces de IS-IS, elige una secuencia de relevos de confianza, instala una lista de segmentos SRv6 en el origen y envía paquetes UDP de relevo por ese camino. Un campo de dirección de un anuncio de routing pasa así a influir en el destino de material sensible. El documento describe un diseño, no un despliegue medido.

El campo de capacidad lleva un KM-ID de ocho octetos, único dentro del dominio IS-IS. KM-IP puede contener una dirección IPv4 o IPv6. Sin ninguna KM-IP, el receptor debe ignorar toda la capacidad QKD. Con ella presente, IS-IS no verifica el formato: la remite directamente al controlador. Otro campo identifica el vecino y la interfaz física del enlace. La tasa opcional de generación de claves ocupa 32 bits y se expresa en kilobits por segundo. El emisor puede suprimir actualizaciones de esa tasa durante un período configurado localmente, de modo que el valor anunciado puede quedar anticuado.

La autenticación criptográfica de IS-IS ayuda a comprobar quién originó un LSP y si se alteró. Por sí sola no demuestra que el gestor situado detrás de KM-IP tenga autorización para este servicio. La sección de seguridad admite que identificadores, direcciones o capacidades falsas podrían desviar material de claves o interrumpir el servicio y aconseja autenticar IS-IS. El borrador no define la verificación independiente que haría el controlador de la dirección y del permiso de relevo. Una prueba útil introduce una dirección válida pero perteneciente al gestor equivocado y registra la decisión.

RFC 6823 creó GENINFO TLV 251 para datos de aplicaciones y advirtió del coste de inundar y procesar cambios ajenos al routing. Exige una instancia IS-IS distinta de cero salvo que un RFC de estándares defina el uso de la instancia cero, y pide declarar la frecuencia esperada de los cambios. La nueva propuesta solicita un identificador QKD y sugiere 101; los routers antiguos pueden ignorar la aplicación desconocida. El rastreador IETF lo registra como borrador individual. En IANA, solo TRILL tiene asignado el identificador 1 y 2–65535 siguen libres. Faltan una asignación, una regla de autorización del controlador y una traza de entrega de claves para evaluar el resultado operativo.