]> Huawei

China zhangli344@huawei.com

Huawei

China jie.dong@huawei.com

Huawei

China zhangshiji@huawei.com

Routing Area LSR Working Group IGP Quantum Key Distribution (QKD) provides a method for generating shared symmetric keys between two QKD systems. Large-scale QKD networks commonly use trusted relay nodes to deliver key material across multiple QKD links. to steer key-relay traffic through a sequence of trusted relay nodes. A critical prerequisite for this approach is the ability of collecting the QKD capability of the nodes and links in the network. This document extends IS-IS by defining a new Application ID for QKD relay information within the GENINFO TLV . This extension allows nodes to advertise their QKD relay informations and then collected by the QKD controller for QKD relay path calculation.

Introduction Quantum Key Distribution (QKD) provides a method for generating shared symmetric keys between two QKD systems. The physical distance of a single QKD link is limited by optical attenuation, noise, equipment capability, and deployment conditions. Large-scale QKD networks therefore commonly use trusted relay nodes to deliver key material across multiple QKD links. Trusted relay requires a network path that selects the correct relay nodes in the correct order. provides an Segment Routing over IPv6 (SRv6) based QKD trusted relay framework, which leverages SRv6 to steer key-relay traffic through a sequence of trusted relay nodes. It uses a QKD controller to calculate the trusted relay paths upon receiving a request. A critical prerequisite for this approach is the ability for the QKD controller to efficiently and dynamically collect the QKD capability of the nodes and links in the network. The IS-IS routing protocol, widely deployed in live networks, offers a robust and scalable foundation for the collection of QKD related information. extends IS-IS to advertise generic application information that are not directly related to the operation of the IS-IS protocol. This document extends IS-IS by defining a new Application ID for QKD relay information within the GENINFO TLV . This extension allows nodes to advertise their QKD relay informations and then collected by the QKD controller for QKD relay path calculation.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology This document uses terminology from and .

SRv6-Based QKD Trusted Relay Framework Overview

Functional Components and Information Flow The framework specified in is illustrated in , consists of the following logical components:

• QKD Relay Node: A network node containing, or connected to, QKD key-generation and key-management functions, and are authorized to receive, process, and forward relayed key information.
• QKD Link: A communication relationship between two directly connected QKD nodes that can generate shared key material.
• QKD Controller: A control function that collects QKD topology information, receives service requirements, computes a trusted relay path, and installs the corresponding SRv6 path.
• Application or KME: A trusted entity that sends QKD relay service request to QKD Controller.

Source/Destination QKD KME: The endpoints of the key-relay service.

SRv6-Based QKD Trusted Relay Framework | QKD |<-------->| QKD |<-------->| QKD | | Node | QKD Link | Node | QKD Link | Node | QKD Link | Node | | (Dst) | | | | | | (Src) | +-------+ +-------+ +-------+ +-------+ <------------SRv6 Based Key Relay --------------------- ]]>

The general information flow in this framework is as follows:

1. QKC Resource Collection: QKD links provides their Quantum Key Generation Rate (QKGR) to the QKD controller, and QKD nodes provides their Node and relay capabilities to the QKD controller.
2. Service Request: An application or KME sends a key-relay service request (e.g., source, destination, required key rate) to the QKD Controller.
3. Path Computation: The QKD controller combines the collected QKD topology information (from step 1) with the service requirements (from step 2). It runs a path-computation algorithm to select an ordered sequence of trusted relay nodes that meets the requirements.
4. Path Translation and Installation: The controller translates the selected relay-node sequence into an SRv6 segment list and installs the SRv6 path to the source node.
5. Key Relay: The source sends a UDP key-relay packet along the SRv6 path. Each trusted relay node processes the key-relay information, performs the required relay operation, and forwards the packet toward the next hop as dictated by the SRv6 path.

Role of IS-IS Extensions in the Framework Since IS-IS has been widely deployed in live networks, and existing extensions allow it to advertise generic application information that are not directly related to the operation of the IS-IS protocol. Therefore, IS-IS can be extended for the collection of QKD related information from the QKD links and QKD relay nodes. The detailed QKD related information that need to be collected includes:

• Router's QKD relay capability: including their Key Manager Identifier (KM-ID) which uniqualy identifies a router with QKD relay capability.
• Key Manager IP addresses(KM-IP) of routers support QKD relay capability, which are used as the input for the QKD controller to calculate the QKD relay paths, and forms QKD relay paths.
• QKGR of QKD links: QKGR is a value generated by a QKD-enabled router through the negotiation with its QKD relay neighbors. The QKD controller uses the QKGR as a path selection constraint to calculate the QKD relay path.

Extensions for QKD As defined in , the GENINFO TLV (Type 251) is used to advertise application-specific information. This document requests to allocate a new Application ID (TBD1, 101 is recommended) for QKD-related information. The GENINFO TLV includes a Additional Application-Specific Information field, which can be used to carry application-specific sub-TLVs. This document defines two new sub-TLVs for QKD-specific information.

QKD Capability Sub-TLV This Sub-TLV identifies the advertising node as a QKD Key Manager (KM) and provides its unique identifier. The format of this sub-TLV is shown as follows:

Format of QKD Capability sub-TLV

where:

• Type: 1, 1 octet.
• Length: 1 octet. The value MUST be 10 plus the total length of included sub-sub-TLVs.
• Flags: 2 octets. No flags are currently defined. The sender MUST set this field to 0. The receiver MUST ignore this field.
• KM-ID: 8 octets. An identifier that MUST be unique within the IS-IS domain.

A router SHOULD originate at most one QKD Capabilities Sub-TLV. This Sub-TLV MAY be present in any LSP fragment. If multiple QKD Capabilities Sub-TLVs are received from the same router, only the first occurrence in the smallest fragment number is considered valid. Subsequent occurrences MUST be ignored.

QKD KM-IP Sub-sub-TLV This sub-sub-TLV carries the IP address of the Key Manager.

Format of QKD KM-IP sub-sub-TLV

where:

• Type: 1, 1 octet.
• Length: 1 octet. The value is 1 plus the length of the KM-IP address (4 for IPv4, 16 for IPv6).
• Flags: 1 octets. Only one flag is defined currently, the reserved bits in the Flags field MUST be set to 0 by the sender and ignored by the receiver. ~~~ 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Reserved |F| +-+-+-+-+-+-+-+-+ ~~~
• KM-IP: Variable length. 4 octets for IPv4, 16 octets for IPv6.

IS-IS do not performs validation on the KM-IP format, it just passes transparently to the QKD controller. At least one QKD KM-IP sub-sub-TLV SHOULD be included in the QKD Capability sub-TLV. If none is present, the entire QKD Capabilities Sub-TLV MUST be ignored.

QKD Link Capabilities Sub-TLV This Sub-TLV describes the QKD capabilities of a specific point-to-point (P2P) link, which is a key input for QKD relay path computation.

Format of QKD Link Capabilities Sub-TLV

where:

• Type: 1 octet, the value of it is 2.
• Length: 1 octet. The value MUST be 19 plus the total length of any included sub-sub-TLVs. If the Length does not satisfy this requirement, the receiver MUST ignore the Sub-TLV.
• System ID and Pseudonode Number: 7 octets. it identifies the neighbor node of the link.
• Link Local/Remote Identifiers Sub-TLV: 10 octets, as defined in , it is used to identify the physical interface.
• Flags: 2 octets. No flags are currently defined. The sender MUST set this field to 0. The receiver MUST ignore this field.

A single link MAY have multiple QKD Link Capabilities Sub-TLVs (e.g., due to fragmentation). When a router receives multiple QKD Link Capabilities Sub-TLVs, it SHOULD merge all the non-conflicting attributes.

QKD Generate Rate Sub-sub-TLV This optional sub-sub-TLV advertises the QKGR for a link.

Format of QKD Generate Rate Sub-sub-TLV

where:

• Type: 1 octet, the value of it is 1.
• Length: 1 octet, the value of it is 6.
• RESERVED: 2 octets. Must be set to 0 by the sender and ignored by the receiver.
• QKD Key Generate Rate: 4 octets. Unsigned integer. The unit is kilobits per second (kbps), representing the number of bits of QKD keys that can be generated per second.

A single link (identified by its local/remote identifiers) MUST have at most one QKD Generate Rate sub-sub-TLV across all fragments. If multiple QKD Generate Rate sub-sub-TLV are received from the same neighbor for the same link, only the first occurrence in the smallest fragment number is considered valid. To reduce flooding overhead, updates to the QKD Generate Rate MAY be suppressed by a local configured suppression period.

Compatibility This document defines new extensions that are fully backward compatible with existing IS-IS implementations. Per , routers that do not support the new GENINFO Application ID (TBA1) will silently ignore the entire GENINFO TLV containing it. No error messages or routing disruptions will occur. Therefore, these extensions are transparent to legacy routers. Operators can deploy QKD-capable nodes incrementally without affecting the stability of the existing IS-IS domain.

IANA Considerations This document requests allocation for the following values, sub-TLVs, and sub-sub-TLVs by updating the existing registries and defining new registries under the "IS-IS TLV Codepoints" grouping.

GENINFO Application ID IANA is requested to assign a value from the "GENINFO Application IDs" registry :

Value	Description	Reference
TBA1	Quantum Key Distribution (QKD)	This document

QKD Sub-TLV Registry IANA is requested to create a new registry called "QKD Sub-TLVs" under GENINFO Application ID TBA1 specified in this document ". The registration procedure is "Expert Review", as defined in . Guidance for the designated experts is provided in . The following assignments are made by this document:

Value	Description	Reference
1	QKD Capabilities	This document
2	QKD Link Capabilities	This document
3-255	Unassigned

QKD Sub-Sub-TLV Registy for QKD Capabilities Sub-TLV IAIA is requested to create a new registries under the "QKD Capability Sub-TLV registry. The registration procedure is "Expert Review", as defined in . Guidance for the designated experts is provided in . The following assignments are made by this document:

Value	Description	Reference
1	QKD KM-IP	This document
2-255	Unassigned

QKD Sub-Sub-TLV Registy for QKD Link Capabilities IAIA is requested to create a new registries under the "QKD Link Capability Sub-TLV registry. The registration procedure is "Expert Review", as defined in . Guidance for the designated experts is provided in . The following assignments are made by this document:

Value	Description	Reference
1	QKD Generate Rate	This document
2-3	Unassigned
4	Link Local/Remote Identifiers	RFC5307
2-255	Unassigned

Security Considerations The extensions defined in this document allow IS-IS to carry sensitive operational parameters about a QKD network, including KM identities, IP addresses, and key generation rates. The security of the underlying IS-IS routing protocol is paramount. Implementations SHOULD rely on existing IS-IS security mechanisms, such as the use of cryptographic authentication as defined in and , to ensure the integrity and authenticity of the advertised information. An attacker who can inject false LSPs could advertise incorrect KM-IDs, IP addresses, or link capabilities, potentially leading to denial of service, man-in-the-middle attacks, or misdirection of key material. Operators are strongly advised to deploy IS-IS authentication in any domain where these QKD extensions are used. Furthermore, as outlined in the SRv6-based QKD relay framework , the integrity of the path-computation inputs (the QKD information advertised via IS-IS) is critical. Compromised advertisements could lead the controller to select an insecure or ineffective relay path, undermining the security guarantees of the QKD network.

References Normative References This document describes the manner in which generic application information (i.e., information not directly related to the operation of the Intermediate System to Intermediate System (IS-IS) protocol) should be advertised in IS-IS Link State Protocol Data Units (LSPs) and defines guidelines that should be used when flooding such information. China Mobile China Mobile Huawei Technologies Quantum Key Distribution (QKD) links generate symmetric key material between directly connected QKD nodes. Trusted relay is commonly used to extend key delivery beyond the reach of a single QKD link. A complete trusted-relay service requires the network to collect QKD link capacity and node trust information, compute a relay path according to service requirements, translate the result into an SRv6 path, and carry the relayed key information in an IPv6/UDP packet steered by that SRv6 path. This document describes an architectural framework for such a service. Each QKD link provides its available quantum key rate capacity, and each relay node provides a trust level. A controller uses these inputs together with application requirements to calculate a relay path. The path-computation algorithm is not standardized and may be selected or defined by the user, operator, or implementation. The calculated relay sequence is represented as an SRv6 path, and UDP packets following that path carry the key-relay information. This document identifies the protocol extension points needed to support the framework. The detailed encodings, message formats, SRv6 behaviors, TLVs, and signaling procedures are left for future work and are marked as TBD. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document replaces RFC 3567. This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. [STANDARDS-TRACK] This document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC 5304. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. [STANDARDS-TRACK] Informative References This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK] Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. This document recommends some editorial changes to the IANA "IS-IS TLV Codepoints" registry to more accurately document the state of the protocol. It also sets out new guidelines for Designated Experts to apply when reviewing allocations from the registry.

Acknowledgements TBD