Summary

  • A 2 November individual draft proposes putting a key manager's identifier and IP address, plus a QKD link's key-generation rate, into IS-IS GENINFO advertisements. A controller would use them to choose an ordered relay path for key material.
  • The draft says IS-IS passes the KM-IP address to that controller without validating its format. The routing advertisement can carry a claim about a relay; the controller must still decide which advertised endpoint and rate it will trust for an actual key path.

Follow one request. An application or key-management entity names a source, destination and required key rate. The proposed controller collects QKD node and link data from IS-IS, selects a sequence of trusted relay nodes, installs an SRv6 segment list at the source, and sends UDP key-relay traffic along that path. In the draft's own architecture, an address field in a routing advertisement becomes input to the decision about where key material travels. This is a proposed workflow, not a trace of a running deployment.

The draft gives a QKD-capable node an eight-octet KM-ID, unique inside its IS-IS domain. A nested KM-IP field carries an IPv4 or IPv6 address. Without any KM-IP, the receiving router must discard that QKD capability advertisement. With an address, IS-IS does not validate the address format; the text says it passes the value transparently to the controller. A separate link advertisement identifies the neighbor and physical interface. Its optional 32-bit rate field states how many kilobits of QKD key material a link can generate per second. The originator may suppress rate updates for a locally configured period, making the rate a dated claim whenever conditions move faster than the suppression interval.

That division of labour matters. Cryptographic IS-IS authentication can help a receiver establish who sent an LSP and whether the advertisement was altered. It does not, by itself, prove that a KM-IP is the right endpoint for the requested key service or that its operator is authorized as a relay. The draft's security section warns that false KM identifiers, addresses or link capabilities could misdirect key material or disrupt service. It recommends authentication. The document does not specify the controller's separate validation and relay-authorization test. A deployment review should ask for that test at the handoff, with an address deliberately inconsistent with the intended key manager.

The transport has its own price. RFC 6823 established GENINFO TLV 251 for application data and warned that non-routing updates consume flooding and processing capacity. It calls for a separate non-zero IS-IS instance unless a Standards Track RFC defines use of the zero instance, and for an expected rate of change in the application specification. The new proposal requests a QKD Application ID, suggests 101, and lets older routers ignore the unfamiliar GENINFO application. The IETF tracker still lists an individual Internet-Draft. The IANA registry lists only TRILL at Application ID 1 and leaves 2–65535 unassigned. An allocation, a controller authorization rule, and a measured key-delivery trace would turn the proposed path into something an operator can actually assess.