Key request management

Abstract

Embodiments of the present disclosure relate to key request management. In some implementations, a network device may transmit a key request and a proposed key request rate associated with the key request. The network device may receive a response to the key request based on the proposed key request rate. In some implementations, a network device may transmit a key request. The network device may receive a response to the key request, the response including an indication of a key derived key or a time associated with another key request.

Description

Technical Field

[0001] Embodiments of the present disclosure relate to the field of computer networks, and more particularly, to key request management. Background Art

[0002] Network devices can communicate securely with each other using one or more keys (e.g., random or pseudo-random numbers). For example, network devices can use keys to apply data to an encryption process to encode or decode data. For example, a first network device can use a key to convert plaintext into ciphertext and transmit the ciphertext to a second network device. Once the ciphertext is received, the second network device can use the key to convert the ciphertext data back into plaintext data. Summary of the Invention

[0003] Some implementations described herein relate to methods. The method may include transmitting, by a network device, a key request and a proposed key request rate associated with the key request. The method may include receiving, by the network device, a response to the key request based on the proposed key request rate.

[0004] Some implementations described herein relate to network devices. The network device may include one or more memories and one or more processors. The one or more processors may be configured to transmit a key request. The one or more processors may be configured to receive a response to the key request, the key request including an indication of a key derivation key or a time associated with another key request.

[0005] Some implementations described herein relate to a non-transitory computer-readable medium storing a set of instructions. When the set of instructions is executed by one or more processors of a network device, the network device may be caused to transmit a quantum key distribution (QKD) key request and a proposed QKD key request rate associated with the QKD key request. When the set of instructions is executed by one or more processors of a network device, the network device may be caused to receive a response to the QKD key request based on the proposed QKD key request rate.

[0006] One aspect of the present disclosure provides a method, including: transmitting, by a network device, a key request and a proposed key request rate associated with the key request; and receiving, by the network device, a response to the key request based on the proposed key request rate.

[0007] According to one or more embodiments of the present disclosure, it further includes: receiving, by the network device, an indication of a supported key request rate.

[0008] According to one or more embodiments of the present disclosure, wherein the response to the key request is a rejection of the key request, and wherein the rejection of the key request is associated with an alert.

[0009] According to one or more embodiments of the present disclosure, where the response to the key request is a rejection of the key request, the method further includes: transmitting, by the network device, another proposed key request rate, the another proposed key request rate being less than or equal to the supported key request rate.

[0010] According to one or more embodiments of the present disclosure, where the response to the key request is an acceptance of the key request, the method further includes: transmitting, by the network device, another key request associated with the key request and another proposed key request rate associated with the another key request.

[0011] According to one or more embodiments of the present disclosure, where the response to the key request is an acceptance of the key request, the method further includes: transmitting, by the network device, another key request associated with the key request; and suppressing, by the network device, the transmission of another proposed key request rate associated with the another key request.

[0012] According to one or more embodiments of the present disclosure, where the proposed key request rate is a proposed key request pace.

[0013] According to one or more embodiments of the present disclosure, where the response to the key request is a rejection of the key request, where the rejection of the key request indicates that the rejection of the key request is based on the proposed key request pace.

[0014] Another aspect of the present disclosure provides a network device, including: one or more memories; and one or more processors configured to: transmit a key request; and receive a response to the key request, the response including a key-derived key or an indication of a time associated with another key request.

[0015] According to one or more embodiments of the present disclosure, where the one or more processors configured to receive the key-derived key or the indication of the time associated with the another key request are further configured to: receive the key-derived key.

[0016] According to one or more embodiments of the present disclosure, where the one or more processors are further configured to: receive an indication that the key-derived key is key-derived.

[0017] According to one or more embodiments of the present disclosure, where the one or more processors configured to receive the key-derived key or the indication of the time associated with the another key request are configured to: receive the indication of the time associated with the another key request.

[0018] According to one or more embodiments of the present disclosure, the time associated with the other key request is a predicted time at which the non-key-derived key will be available.

[0019] Another aspect of the present disclosure provides a non-transitory computer-readable medium storing a set of instructions, the set of instructions including: one or more instructions that, when executed by one or more processors of a network device, cause a security application entity (SAE) of the network device to: transmit a quantum key distribution (QKD) key request and a proposed QKD key request rate associated with the QKD key request; and receive a response to the QKD key request based on the proposed QKD key request rate.

[0020] According to one or more embodiments of the present disclosure, the one or more instructions further cause the SAE of the network device to: receive an indication of a supported QKD key request rate.

[0021] According to one or more embodiments of the present disclosure, the response to the QKD key request is a rejection of the QKD key request, and the rejection of the QKD key request is associated with an alert.

[0022] According to one or more embodiments of the present disclosure, the response to the QKD key request is a rejection of the QKD key request, and the one or more instructions further cause the SAE of the network device to: transmit another proposed QKD key request rate that is less than or equal to the supported QKD key request rate.

[0023] According to one or more embodiments of the present disclosure, the response to the key request is an acceptance of the key request, and the one or more instructions further cause the SAE of the network device to: transmit another QKD key request associated with the QKD key request and another proposed QKD key request rate associated with the other QKD key request.

[0024] According to one or more embodiments of the present disclosure, the response to the key request is an acceptance of the key request, the one or more instructions further cause the SAE of the network device to: transmit another QKD key request associated with the QKD key request; and suppress transmission of another proposed QKD key request rate associated with the other QKD key request.

[0025] According to one or more embodiments of the present disclosure, the proposed QKD key request rate is a proposed QKD key request pace. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 It is a diagram of an example implementation associated with the transmission of a proposed key request rate.

[0027] Figure 2 It is a diagram of an example process associated with message exchange (including pacing information) during a slow key generation phase.

[0028] Figure 3 It is a diagram of an example implementation associated with the transmission of a key derivation key or an indication of the time associated with a key request.

[0029] Figure 4 It is a diagram of an example process associated with message exchange (involving key derivation) during a slow key generation phase.

[0030] Figure 5 It is a diagram of an example environment in which the systems and / or methods described herein can be implemented.

[0031] Figure 6 It is a diagram of example components of a device associated with key request management.

[0032] Figure 7 It is a diagram of example components of a device associated with key request management.

[0033] Figure 8 It is a flowchart of an example process associated with key request management. Detailed Description of the Specific Embodiments

[0034] The following detailed description of the example implementation refers to the accompanying drawings. The same reference numerals in different drawings may identify the same or similar elements.

[0035] A network device (e.g., a router, a firewall, or other consumer of key material) can include a key requester component that requests a key from a key manager. In response to the request, the key manager can generate a key based on key material (e.g., one or more numbers) and provide the key to the key requester. The network device can use the generated key to communicate securely with another network device. In some examples, the network device can use QKD to determine the same key at both ends of a quantum link, which is considered information secure because the key is never transmitted over the quantum link. In QKD, the key requester can be referred to as a security application entity (SAE), and the key manager can be a key management entity (KME). The SAE can be an entity that requests one or more keys from the KME for one or more applications operating in cooperation with one or more other SAEs. The KME can be an entity that manages keys in a network in cooperation with one or more other KMEs. The KME can serve one or more SAEs.

[0036] For example, a first SAE and a first KME can be connected and placed at a first location, and a second SAE and a second KME can be connected and placed at a second location. The first and second KMEs can be connected by a direct QKD link or a QKD network including multiple QKD links. Once generated, the key can be available at the first and second KMEs, and a unique key identifier (e.g., a Universally Unique Key Identifier) can be assigned to the key and shared among the first and second KMEs. The first SAE can transmit a request for the key and the corresponding key identifier to the first KME, and the first KME can provide the key and the key identifier to the first SAE. The first SAE can transmit the key identifier to the second SAE. The second SAE can request the key corresponding to the key identifier from the second KME, which can provide the key to the second SAE. In this way, the SAE can use the key identifier to identify a key pair (e.g., two independent instances of the same key) without explicitly sharing the key. The first and second SAEs can establish a secure communication (e.g., a secure channel) using the key identified by the key identifier.

[0037] The key requester can use an application programming interface (API) to retrieve the key and / or the key identifier from the key manager. For example, the KME and the SAE can make full use of the key delivery API based on QKD Representation State Transfer to exchange key-related communications. For example, the SAE can actively request the key from the KME using the key delivery API based on QKD Representation State Transfer.

[0038] The key requester can periodically request a new key from the key manager, which can help to ensure that the communication between network devices remains secure. However, in some cases, the key manager may not be able to serve and may reject the key request. For example, if the rate at which the key manager generates additional keys at this point exceeds the frequency of key requests, the key manager may not be able to serve the key requests. For example, the frequency of key requests may be affected by the amount of data that will use the keys supplied by the key manager, the nature of the optical fiber through which the keys are exchanged, a power outage, the amount of key requesters requesting keys from the key manager, etc. In some cases, the key manager may experience a key shortage and thus may not be able to deliver any keys (or key material) to the key requester. Such a key shortage may increase the latency in data delivery, result in insecure data exchange, and / or consume excessive bandwidth resources (e.g., due to message exchanges during a slow key generation phase).

[0039] For example, if the SAE transmits a request for a key and a key identifier to a KME that lacks sufficient key material to generate a key (e.g., during a slow key generation phase), the KME may return an error message. For example, the error message may have a Hypertext Transfer Protocol (HTTP) status code 503, which can indicate that the error is on the server side (e.g., on the KME side). The SAE may retransmit the request for the key and the key identifier repeatedly (and receive the error message repeatedly) until the KME obtains sufficient key material to generate a key. At that time, the KME may provide the key and the key identifier to the SAE, which can use the key and the key identifier to establish secure communication with another SAE, as described above.

[0040] For example, a measurement device independent QKD (MDI-QKD) system may deliver two Advanced Encryption Standard 256 (AES256) keys per minute. The amount of data that can be encrypted using a single key can be len(P) ≤ 2 39 -256 bits, where P is the plaintext and len(P) is the length of P. Since 2 39 bits is approximately equal to 68 gigabytes (GB), for a 300 Mbps connection, the key for the connection may need to be changed on average every thirty minutes to ensure the encrypted data remains secure. Thus, the MDI-QKD system in this example can only protect sixty connections simultaneously on average. During peak demand periods, the MDI-QKD system can protect fewer than 60 connections simultaneously. For example, a burst of key requests may leave the KME short of keys, causing the KME to be unable to serve the SAE, which results in the key request failing.

[0041] Thus, the SAE may perform an uncontrolled fallback to key material that is less secure than the new key (e.g., the SAE may re-use a previous insecure key). Alternatively, if the SAE does not use the less secure key material, the SAE may lose business due to lack of available suitable keys, causing the connection between the SAEs to be terminated. Alternatively, the SAE may use a key derivation function to generate a key, which reduces the security or integrity of the transmitted data.

[0042] For other types of keys (e.g., QKD keys, symmetric keys, etc.), a shortage of key material and the security and / or connection issues described above may occur. For example, a key delivery API based on QKD representation state transfer for key delivery, which can also be used for symmetric key delivery to the KME, may also experience a shortage of key material.

[0043] Some implementations described herein enable a key requester to selectively receive keys under the control of a key manager (e.g., a key management controller). In some aspects, the key requester may transmit a proposed key request rate to the key manager and receive a response (e.g., accept or reject) based on the proposed key request rate. For example, the proposed key request rate may allow for an uneven distribution of independent key requests over time. In some examples, the proposed key request rate may be a proposed key request pace. For example, the proposed key request pace may indicate a predicted length of time between independent key requests that a network device will transmit to the key manager. In some examples, the key requester may receive a key-derived key from the key manager in response to a key request. In some examples, in response to a key request, the key requester may receive an indication of a time associated with another key request from the key manager. For example, the key manager may indicate the time at which the key requester will transmit another key request here.

[0044] Accordingly, the implementations described herein may mitigate the impact of a lack of key material on the generation of new keys. For example, receiving a response based on a proposed key request rate can help to ensure that the key requester reliably receives keys in response to key requests (e.g., by avoiding a lack of key material at the key manager), enabling consistent, secure data exchange to be possible. Receiving a response based on a proposed key request pace can enable the key manager to schedule key delivery (e.g., by caching keys before the key requester sends a key request), thus helping to ensure that keys will be available for the key requester, even in the case of a change in keys at the key manager. Receiving a key-derived key from the key manager can enable the key manager to control the level of security of the keys used by the key requester, which can be more secure than relying on a particular implementation of the key requester to determine the security of the key-derived key. Receiving an indication of a time associated with other key requests can reduce overhead, such as the bandwidth resources that would be occupied by repeated key requests in the absence of a time associated with other key requests.

[0045] Figure 1 is a diagram of an example implementation 100 associated with the transmission of a proposed key request rate. As shown in Figure 1 below, the example implementation 100 includes two network devices, which will be described in more detail below in connection with Figures 5 - 7described in connection with. The network devices may be in respective locations (e.g., sites), namely Location A and Location B. The network devices may include respective key requesters, namely Key Requester A and Key Requester B. As shown, Locations A and B may also include respective key managers, namely Key Manager A and Key Manager B. In some examples, one or more of the key managers may be physical devices separate from the network devices. In some examples, one or more of the key managers may be logical devices (e.g., virtual machines) residing on one or more of the network devices (e.g., the key manager may run on the key requester). In some examples, the key requester may be an SAE, and the key manager may be a KME.

[0046] In some aspects, a network device (e.g., the SAE of the network device) may receive an indication of a supported key request rate (e.g., a supported QKD key request rate). For example, Key Requester A may receive an indication of the supported key request rate from Key Manager A. The supported key request rate may be the rate at which Key Manager A may generate keys for Key Requester A here (e.g., the maximum rate). In some examples, the supported key request rate may be referred to as the "supported key request cadence". One or more indications of the supported key request rate may be transmitted before or after any suitable operation described herein.

[0047] In some examples, the network device may receive an indication of the supported key request rate in a status response (e.g., sent via a key delivery API representing state transitions based on QKD). For example, the status response may be in response to a "get status" message transmitted by the network device (e.g., via a key delivery API representing state transitions based on QKD). The status response may include an item called "max_key_request_cadence" and has an integer data type, which indicates the maximum amount (e.g., number) of Key Requester A that Key Manager A can support per unit time (e.g., per minute).

[0048] As shown by reference numeral 110, a network device may transmit a key request (e.g., a QKD request) and a proposed key request rate associated with the key request (e.g., a proposed QKD request rate). For example, a key requester A (e.g., the SAE of the network device) may transmit the key request and the proposed key request rate to a key manager A. The network device may transmit the key request and the proposed key request rate in a single transmission or multiple transmissions. In some examples, the proposed key request rate may indicate a predicted average length of time between key requests (e.g., including key requests) transmitted by the network device to key manager A. For example, the proposed key request rate (e.g., as an average) may allow for uneven distribution of independent key requests. The proposed key request rate may also be referred to as the "proposed key request rhythm".

[0049] In some aspects, the proposed key request rate may be a proposed key request pace (e.g., a proposed QKD key request pace). In some examples, the proposed key request pace may indicate a predicted length of time between independent key requests (e.g., including key requests) transmitted by the network device to key manager A. For example, the proposed key request pace may indicate that the independent key requests are evenly distributed in time (within a given level of precision). For example, the SAE may predict that the SAE will regularly request paced keys (e.g., every 30 seconds), and may notify the KME of this prediction. For example, the key request may have a data format that includes extended parameters (e.g., optional extended parameters, such as KME key request optional extensions), as follows:

[0050]

[0051] In some examples, the proposed key request rate may be less than or equal to the supported key request rate. In some examples, the proposed key request rate may be greater than the supported key request rate. For example, if the network device does not receive an indication of the supported key request rate, or if the supported key request rate has changed since the network device received an indication of the supported key request rate, the network device may request a proposed key request rate that may be greater than the supported key request rate. In some examples, the network device may also receive an indication of the amount of future key requests and / or an indication of the time period during which the network device will transmit future key requests.

[0052] As indicated by reference numeral 120, the network device may receive a response to a key request based on a proposed key request rate. For example, key requester A may receive a response from key manager A, which may be based on the proposed key request rate, where key manager A may determine whether key manager A can support (e.g., meet) the proposed key request rate (e.g., whether key manager A can generate keys fast enough to at least match the proposed key request rate) and transmit a response accordingly.

[0053] In some examples, the response may be a rejection of the key request. For example, if the proposed key request rate is greater than the supported key request rate, key manager A may reject the key request. In some examples, the response may be an acceptance of the key request. For example, if the proposed key request rate is less than or equal to the supported key request rate, key manager A may accept the key request. If the response is an acceptance, the network device (e.g., key requester A) may receive a key and / or a corresponding key identifier from key manager A. For example, the response may include the key and / or the key identifier. The network device (e.g., key requester A) may use the key and key identifier to establish secure communication with another network device (e.g., key requester B). The key may be any suitable type of key, such as a QKD key, a symmetric key, etc.

[0054] In some aspects, the rejection of a key request may be associated with an alert. For example, if key manager A cannot support the requested pace (e.g., the proposed key request pace), the network device (e.g., key requester A) and / or key manager A may generate an alert. For example, the alert may notify the network operator that the key request has been rejected and / or that key manager A cannot support the proposed key request pace.

[0055] In response to the alert, the network operator may take an action that enables key manager A to support the key requirements of key requester A. In some examples, the network operator may reduce the key request rate of the network device (e.g., the network operator may extend the pace on key requester A). For example, the network operator may reduce the key request rate such that the key request rate is less than or equal to the supported key request rate. Additionally or alternatively, the network device may automatically reduce the proposed key request rate. In some examples, the network operator may upgrade and / or expand key manager A. In some examples, the network operator may adjust a license on key manager A that limits the amount of keys that can be delivered from key manager A per unit time. For example, the network operator may adjust the license to increase the amount of keys that can be delivered from key manager A per unit time.

[0056] In some aspects, when the response is a rejection of a key request, a network device (e.g., the SAE of the network device) may transmit another proposed key request rate (e.g., another QKD proposed key request rate) that is less than or equal to the supported key request rate. In some examples, the network device may also transmit another key request. For example, key requester A may transmit another key request and / or another proposed key request rate to key manager A.

[0057] In some cases, when the response is an acceptance of a key request, a network device (e.g., the SAE of the network device) may transmit another key request (e.g., another QKD key request) associated with the key request. In some aspects, the network device (e.g., the SAE of the network device) may also transmit another proposed key request rate (e.g., another proposed QKD key request rate) associated with the other key request. In some aspects, the network device (e.g., the SAE of the network device) may avoid transmitting the proposed key request rate. The other key request may be associated with the key request because the key request and the other key request may request keys for the same session. In some examples, the other proposed key request rate may include a predicted average length of time between key requests (e.g., including the other key request) that the network device is to transmit to key manager A. The value of the other proposed key request rate may be the same as or different from the proposed key request rate. For example, if the value of the other proposed key request rate is the same as the proposed key request rate, the network device may refrain from transmitting the proposed key request rate. If the other proposed key request rate is different from the proposed key request rate, the network device may transmit the proposed key request rate.

[0058] In the case where the proposed key request rate is the proposed key request pacing, key manager A may accept or reject the proposed key request pacing. For example, key requester A may receive an acceptance of the proposed key request pacing or a rejection of the proposed key request pacing. In some aspects (e.g., where the response is a rejection of the key request), the rejection of the key request may indicate that the rejection of the key request is based on the proposed key request pacing. For example, the rejection may be an error message indicating that the key request has been rejected (e.g., because key manager A cannot support the proposed key request pacing). The error message may include an attribute (e.g., in an array of objects) indicating the reason for the error. For example, the attribute may indicate that key manager A cannot support the proposed key request pacing (e.g., the error message may inform key requester A about the pacing limitations of key manager A).

[0059] Receiving a response to a key request based on a proposed key request rate can help protect the key requester from a situation where the key manager does not have an available key to provide a response to the key request (e.g., a subsequent key request). For example, the key manager can accept or reject the key request based on whether the key manager can support the proposed key request rate. Thus, the network device can participate in secure data exchange with another network device using the reliable and consistent keys provided by the key manager.

[0060] Receiving an indication of a supported key request rate can enable the network device to transmit to the key manager a proposed key request rate that the key manager can support. For example, the indication of the supported key request rate can enable the key requester to avoid receiving a rejection from the key manager, which can reduce the latency involved in receiving a key in response to a key request.

[0061] Transmitting another proposed key request rate can enable the key requester to dynamically adjust the proposed key request rate. For example, if the future key request rate of the key requester is variable or unpredictable, the another proposed key request rate may be a different value from the (previous) proposed key request rate. Avoiding transmitting another proposed key request rate may reduce the bandwidth that would otherwise be occupied by carrying the another proposed key request rate. For example, if the future key request rate of the key requester is stable or predictable, the another proposed key request rate may be the same value as the (previous) proposed key request rate.

[0062] The proposed key request rate being the proposed key request pace can enable the key manager to prepare and / or schedule key delivery for the key requester. For example, the key manager can use the proposed key request pace to determine the approximate time at which the key manager will receive a key request. Thus, the key manager can cache the keys created at any appropriate time before the key manager is about to receive a key request, thereby helping to ensure that the keys will be immediately delivered to the key requester in response to the key request. For example, if the proposed key request pace is 30 seconds, the key manager can generate and cache the keys for the key requester at any time before the 30 seconds expire.

[0063] As previously described, Figure 1 is provided as an example. Other examples may be different from what is described with respect to Figure 1 In Figure 1 the number and arrangement of the devices shown are provided as an example. In practice, there may be additional devices, fewer devices, different devices, or differently arranged devices compared to what is shown in Figure 1 In addition, two or more of the devices shown in Figure 1 can be implemented within a single device, or inFigure 1 The single device shown in Figure 1 a set of devices (e.g., one or more devices) shown in Figure 1 can perform one or more functions described as being performed by another set of devices shown in

[0064] Figure 2 is a diagram of an example process 200 associated with message exchange (including pacing information) during a slow key generation phase. Operations 205 - 240 provide examples involving the rejection of a key request, and operations 245 - 270 provide examples not involving the rejection of a key request. The examples involving operations 205 - 240 are not necessarily before operations 245 - 270.

[0065] As described, operations 205 - 240 provide examples of the rejection of a key request. As indicated by reference numeral 205, SAE A (e.g., key requester A) can transmit, and KME A (e.g., key manager A) can receive a request for a key and a key identifier of the key, as well as an indication of a proposed key request pacing T1. T1 can be a proposed time period between key requests. KME A can determine that the proposed key request pacing exceeds the key generation rate of KME A and thus reject the key request.

[0066] As indicated by reference numeral 210, KME A can transmit, and SAE A can receive an error message indicating that the proposed key request pacing is too frequent for KME A to support. The error message can include an indication of the supported key request pacing. For example, the error message can indicate that the proposed key request pacing must be greater than or equal to T2 to be accepted.

[0067] As indicated by reference numeral 215, SAE A can transmit, and KME A can receive a request for a key and a key identifier and an indication of a proposed key request pacing T2. KME A can determine that the proposed key request pacing matches the key generation rate of KME A and thus accept the key request.

[0068] As shown by reference numeral 220, KME A may transmit, and SAE A may receive a key and a key identifier. As shown by reference numeral 225, SAE A may transmit, and SAE B may receive a key identifier. As shown by reference numeral 230, SAE B may transmit, and KME B may receive a request for a key. The request for a key may include a key identifier. As shown by reference numeral 235, KME B may transmit, and SAE B may receive a key. As shown by reference numeral 240, SAE A and SAE B may establish secure communication using the key.

[0069] As described, operations 245-270 provide examples of rejections that do not involve a key request. As shown by reference numeral 245, SAE A may transmit, and KME A may receive a request for a key, a key identifier, and an indication of a proposed key request rhythm T2. KME A may determine that the proposed key request rhythm matches KME A's key generation rate and thus accept the key request.

[0070] As shown by reference numeral 250, KME A may transmit, and SAE A may receive a key and a key identifier. As shown by reference numeral 255, SAE A may transmit, and SAE B may receive a key identifier. As shown by reference numeral 260, SAE B may transmit, and KME B may receive a request for a key. The request for a key may include a key identifier. As shown by reference numeral 265, KME B may transmit, and SAE B may receive a key. As shown by reference numeral 270, SAE A and SAE B may establish secure communication using the key.

[0071] As described above, Figure 2 is provided as an example. Other examples may differ from what is described with respect to Figure 2 In Figure 2 the number and arrangement of the devices shown are provided as an example. In practice, there may be additional devices, fewer devices, different devices, or differently arranged devices compared to those shown in Figure 2 In addition, two or more of the devices shown in Figure 2 may be implemented within a single device, or a single device shown in Figure 2 may be implemented as multiple distributed devices. Additionally or alternatively, a group of devices (e.g., one or more devices) shown in Figure 2 may perform one or more functions described as being performed by another group of devices shown in Figure 2

[0072] Figure 3 ​FIG. associated with an indication of the time associated with the transmission of a key - derived key or with a key request. As shown in Figure 3 shown, example implementation 300 includes two network devices, which may be the network devices shown in Figure 1 shown.

[0073] As indicated by reference numeral 310, a key requester A may transmit, and a key manager A may receive a key request (e.g., a QKD request). As indicated by reference numeral 320, the key manager A may transmit, and the key requester A may receive a response to the key request. The response to the key request may include a key - derived key or an indication of the time associated with another key request.

[0074] In some aspects, the response to the key request may include a key - derived key. For example, a configurable option may be provided such that if the key manager A lacks a key and / or raw material, the key manager A may use a cryptographic key - derivation function (KDF) to generate one or more keys (e.g., QKD keys) derived from other keys (e.g., other QKD keys). Thus, the key manager A may use the key instead of the raw material to generate additional keys. Once the key - derived key is received, a network device (e.g., key requester A) may use the key - derived key to establish secure communication with another network device (e.g., key requester B).

[0075] In some aspects, the key manager A may transmit, and a network device (e.g., key requester A) may receive an indication that a key - derived key is derived. For example, the key manager A may transmit a message that notifies the key requester A of the nature of the delivered key (e.g., the message may indicate whether the key is generated from raw (e.g., initial) material or a KDF). The network device may receive an indication as a key - expansion object in a key container.

[0076] In some aspects, the response to the key request may include an indication of the time associated with another key request. In some aspects, the time associated with another key request is a predicted time at which a non - key - derived key will be available. For example, the predicted time may be a time interval after the key requester A re - attempts the transmission of the key request (e.g., by transmitting another key request). After the predicted time, the key manager A may have sufficient raw material to generate a non - key - derived key. Once the non - key - derived key is received, a network device (e.g., key requester A) may use the non - key - derived key to establish secure communication with another network device (e.g., key requester B).

[0077] Receiving an indication of a key derivation key or a time associated with another key request can enhance the security of communications encrypted using the key derivation key and / or reduce the overhead due to key requests. For example, receiving a key derivation key from a key manager can enable the key manager to control the level of security of the key used by the key requester, which may be more secure than relying on a particular implementation of the key requester to determine the security of the key derivation key. The key derivation key can carry different entropy and can thus be considered weaker than a non-key derivation key (e.g., a key generated from raw material); the key manager can mitigate this weakness by controlling the key derivation key configuration. For example, the key manager (instead of the key requester) can determine whether to permit or prohibit the use and / or strength of the key derivation key, rather than allowing the key requester to fallback to a self-generated key.

[0078] Receiving an indication of a time associated with another key request can reduce overhead, such as bandwidth resources consumed by repeated key requests that are rejected due to insufficient key material in the absence of an indication of a time associated with another key request. For example, an indication of time can inform a network device how long to wait before sending another key request, which can reduce the amount of key requests sent by the network device.

[0079] As previously described, Figure 3 is provided as an example. Other examples may differ from what is described with respect to Figure 3 what is described. The number and arrangement of devices shown in Figure 3 are provided as an example. In practice, there may be additional devices, fewer devices, different devices, or differently arranged devices compared to those shown in Figure 3 what is shown. Additionally, two or more devices shown in Figure 3 can be implemented within a single device, or a single device shown in Figure 3 can be implemented as multiple distributed devices. Additionally or alternatively, a set of devices (e.g., one or more devices) shown in Figure 3 can perform one or more functions described as being performed by another set of devices shown in Figure 3 what is shown.

[0080] Figure 4 is a diagram of an example process 400 associated with message exchange (involving key derivation) during a slow key generation phase.

[0081] As shown by reference numeral 405, SAE A (e.g., key requester A) can transmit, and KME A (e.g., key manager A) can receive a request for a key and a key identifier for the key. KME A can generate a key from raw material. Thus, the key can be a non-key derivation key.

[0082] As shown by reference numeral 410 provided, KME A can transmit, and SAE A can receive a key and a key identifier. As shown by reference numeral 415, SAE A can transmit, and SAE B can receive a key identifier. As shown by reference numeral 420, SAE B can transmit, and KME B can receive a request for a key. The request for a key can include a key identifier. As shown by reference numeral 425, KME B can transmit, and SAE B can receive a key. As shown by reference numeral 430, SAE A and SAE B can establish secure communication using the key.

[0083] As shown by reference numeral 435, SAE A can transmit, and KME A can receive a request for another key and another key identifier of another key. As shown by reference numeral 440, KME A can derive another key from a key (a non-key-derived key). Thus, the other key can be a key-derived key.

[0084] As shown by reference numeral 445, KME A can transmit, and SAE A can receive a key and a key identifier. As shown by reference numeral 450, SAE A can transmit, and SAE B can receive a key identifier. As shown by reference numeral 455, SAE B can transmit, and KME B can receive a request for a key-derived key. The request for a key-derived key can include a key identifier. As shown by reference numeral 460, KME B can transmit, and SAE B can receive a key-derived key. As shown by reference numeral 465, SAE A and SAE B can establish secure communication using the key-derived key.

[0085] As shown above, Figure 4 is provided as an example. Other examples may be different from what is described regarding Figure 4 what is described. In Figure 4 the number and arrangement of the devices shown in Figure 4 are provided as an example. In practice, there may be additional devices, fewer devices, different devices, or differently arranged devices compared to those shown in Figure 4 what is shown. Additionally, two or more devices shown in Figure 4 can be implemented within a single device, or a single device shown in Figure 4 can be implemented as multiple distributed devices. Additionally or alternatively, a group of devices (e.g., one or more devices) shown in Figure 4 can perform one or more functions described as being performed by another group of devices shown in

[0086] In some examples (e.g., example implementations 100 and / or 300), a key requester (e.g., SAE A) may indicate to a key manager (e.g., KME A) a target time length for the key requester to receive a key after transmitting a corresponding key request. For example, the target time length may be the length of time the key requester will wait for a response to the key request. When establishing a connection with the key manager and / or one or more key requests, the key requester may indicate the target time length. Additionally or alternatively, the key manager may indicate to the key requester an expected response time for the key manager or another key manager to provide a key in response to the key request. For example, upon receiving a key request, the key manager may indicate that another key manager is expected to use a given number of seconds to deliver the corresponding key.

[0087] In some examples, the key requester may request a key from the key manager, and the key manager may respond based on the target time length or the expected response time. For example, if the key manager cannot provide the key within the target time length and / or the expected response time, the key manager may respond with an error code. The key manager may be unable to provide the key within the target time length and / or the expected response time due to the time associated with the key manager checking whether one or more other devices involved in key generation (e.g., another key manager, an entropy source, etc.) can be reached, the time associated with an alternative key generation process (e.g., in the case of a check failure), etc. If the key manager can provide the key within the target time length and / or the expected response time, the key manager may respond with the key. If the key manager determines that another key manager will take more time than the target time length and / or the expected response time to create and deliver the key, the key manager may indicate to the key requester not to request the key from the other key manager before a given time window or the end of the day expires.

[0088] In some examples, the key manager may establish a policy that a key can only be requested from another key manager if the key does not exceed a length of time starting from when the key is requested from the key manager. If the key exceeds the length of time, the key may be discarded. For example, once requested, the key manager may deliver the key to the key requester, indicating that the key is valid for a given number of seconds and indicating that another key manager will receive the key request before the given number of seconds expires. For example, the key manager may indicate to the key requester that the key is only valid for a given number of seconds, and if another key requester does not obtain the key from another key manager before the given number of seconds expires (e.g., if the other key manager does not receive the key request before the given number of seconds expires), the key delivery may fail.

[0089] In some examples, a key manager may indicate to a key requester a waiting time, which may be the length of time until another key manager will be able to deliver a key. In this example, the key manager may create an exception to the policy that a key may be requested from another key manager only if the key is not older than the length of time since the key was requested from the key manager. For example, the key manager may add the waiting time to the length of time since the key was requested from the key manager. In some examples, the key requester may delay the transmission of a key identifier to another key requester and, once the key identifier is received, may request the key. In some examples, the key requester may convey to another key requester that the key corresponding to the key identifier should be retrieved at a specified time, within a specified delay, and / or before a specified time or specified delay has elapsed.

[0090] In some examples, a key manager may indicate to a key requester a shortest time and a longest time during which the key is valid, and the key requester may indicate to the key manager a target length of time for the key requester to receive the key after transmitting a corresponding key request. The indication may be used to fine-tune the rhythm associated with the key. For example, if the key manager determines that another key manager has experienced a problem (e.g., a reset), and the key manager receives a key request from the key requester, the key manager may wait for a period of time (e.g., thirty seconds) to respond to the key request by releasing the key. During this time, the other key manager may complete the reset. After this time, the key manager may release the key to the key requester. Additionally or alternatively, the key manager may respond to the key requester (e.g., without waiting for a period of time) and notify the key requester that another key requester will request the key after a period of time.

[0091] In some examples, a key manager (e.g., a KME) can receive raw material (e.g., random or pseudorandom numbers) from one or more entropy or key sources, and use the raw material to generate one or more keys for delivery to a key requester (e.g., an SAE). If the entropy or key source slows down or notifies the key manager of a possible key shortage, similar techniques as described herein can be applied between the entropy or key source and the KME. For example, a key manager (e.g., KME A) can receive a key request (e.g., from SAE A) and determine whether the entropy or key source (e.g., an entropy server) is reachable. In some examples, the key manager can use time to determine that the entropy or key source is unreachable, and the key manager will create keys without the help of the entropy or key source. The key manager can respond to the key request within a target time length and / or an expected response time, and / or delay a key request from another key requester (e.g., SAE B) to another key manager (e.g., KME B), which can provide sufficient time for the other key manager to respond to the key request in the case where the entropy or key source is unreachable.

[0092] Figure 5 is a diagram of an example environment 500 in which the systems and / or methods described herein can be implemented. As shown in Figure 5 the environment 500 can include one or more peer devices 510, a set of nodes 520 (shown as nodes 520-1 through nodes 520-N), and a network 530. The devices of the environment 500 can be interconnected via a wired connection, a wireless connection, or a combination of wired and wireless connections.

[0093] Peer devices 510 include one or more devices capable of receiving and / or providing network traffic. For example, peer devices 510 can include traffic transfer devices such as routers, gateways, switches, firewalls, hubs, bridges, reverse proxies, servers (e.g., proxy servers, servers executing virtual machines, etc.), security devices, intrusion detection devices, load balancers, or similar types of devices. In some implementations, peer devices 510 can include endpoint devices for a source or destination of network traffic. For example, peer devices 510 can include computers or similar types of devices. Peer devices 510 can receive from and / or provide network traffic (e.g., payload packets) to other peer devices 510 via the network 530 (e.g., by routing payload packets using nodes 520 as intermediate nodes). In some implementations, peer devices 510 can include edge devices located at the edge of one or more networks. For example, peer devices 510 can receive from and / or can provide network traffic (e.g., payload packets) to devices external to the network 530.

[0094] Node 520 includes one or more devices capable of receiving, processing, storing, routing, and / or providing traffic (e.g., payload packets, files, etc.) in the manner described herein. For example, node 520 may include a router, such as a label switching router (LSR), label edge router (LER), ingress router, egress router, provider router (e.g., provider edge router, provider core router, etc.), virtual router, or other types of routers. Additionally or alternatively, node 520 may include a gateway, switch, firewall, hub, bridge, reverse proxy, server (e.g., proxy server, cloud server, data center server, etc.), load balancer, and / or similar devices.

[0095] In some implementations, node 520 may be a physical device implemented within an enclosure (e.g., chassis). In some implementations, node 520 may be a virtual device implemented by one or more computer devices of a cloud computing environment or data center.

[0096] In some implementations, node 520 may be configured with one or more segment translation tables. In some implementations, node 520 may receive payload packets from peer device 510. In some implementations, node 520 may encapsulate payload packets using a compressed routing header (CRH) and may route Internet Protocol (IP) payload packets to another node 520 using one or more techniques described elsewhere herein. In some implementations, node 520 may be an edge node in network 530. In some implementations, node 520 may be an intermediate node in network 530 (i.e., a node between two or more edge nodes).

[0097] Network 530 includes one or more wired and / or wireless networks. For example, network 530 may include a cellular network (e.g., fifth generation (5G) network, fourth generation (4G) network, such as long term evolution (LTE) network, third generation (3G) network, code division multiple access (CDMA) network, public land mobile network (PLMN), local area network (LAN), wide area network (WAN), metropolitan area network (MAN), telephone network (e.g., public switched telephone network (PSTN)), private network, ad hoc network, intranet, Internet, fiber-based network, cloud computing network, etc., and / or a combination of these or other types of networks.

[0098] In Figure 5 the number and arrangement of the devices and networks shown are provided as one or more examples. In practice, there may be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or a different arrangement of devices and / or networks compared to what is shown in Figure 5 In addition, in Figure 5The two or more devices shown in can be implemented within a single device, or the Figure 5 single device shown in can be implemented as multiple distributed devices. Additionally or alternatively, a set of devices (e.g., one or more devices) of environment 500 can perform one or more functions described by another set of devices of environment 500.

[0099] Figure 6 is a diagram of example components of a device 600 related to key request management. The device 600 may correspond to the peer device 510 and / or the node 520. In some implementations, the peer device 510 and / or the node 520 may include one or more devices 600 and / or one or more components of the device 600. As shown in Figure 6 the device 600 may include a bus 610, a processor 620, a memory 630, an input component 640, an output component 650, and / or a communication component 660.

[0100] The bus 610 may include one or more components that enable wired and / or wireless communication among the components of the device 600. The bus 610 may couple Figure 6 two or more of the components together, e.g., via operative coupling, communication coupling, electrical coupling, and / or electro - coupling. For example, the bus 610 may include electrical connections (e.g., wires, leads, and / or traces) and / or a wireless bus. The processor 620 may include a central processing unit, a graphics processing unit, a microprocessor, a controller, a microcontroller, a digital signal processor, a field - programmable gate array, an application - specific integrated circuit, and / or other types of processing components. The processor 620 may be implemented in hardware, firmware, or a combination of hardware and software. In some implementations, the processor 620 may include one or more processors that can be programmed to perform one or more operations or processes described elsewhere herein.

[0101] The memory 630 may include volatile and / or non-volatile memory. For example, the memory 630 may include random access memory (RAM), read-only memory (ROM), hard disk drive, and / or other types of memory (e.g., flash memory, magnetic memory, and / or optical memory). The memory 630 may include internal memory (e.g., RAM, ROM, or hard disk drive) and / or removable memory (e.g., removable via a universal serial bus connection). The memory 630 may be a non-transitory computer-readable medium. The memory 630 may store information regarding the operation of the device 600, one or more instructions, and / or software (e.g., one or more software applications). In some implementations, the memory 630 may include one or more memories coupled (e.g., communicatively coupled) to one or more processors (e.g., the processor 620), such as via the bus 610. The communicative coupling between the processor 620 and the memory 630 may enable the processor 620 to read and / or process information stored in the memory 630 and / or store information in the memory 630.

[0102] The input component 640 may enable the device 600 to receive inputs, such as user inputs and / or sensed inputs. For example, the input component 640 may include a touch screen, keyboard, keypad, mouse, button, microphone, switch, sensor, global positioning system sensor, global navigation satellite system sensor, pedometer, gyroscope, and / or actuator. The output component 650 may enable the device 600 to provide outputs, such as via a display, speaker, and / or light-emitting diode. The communication component 660 may enable the device 600 to communicate with other devices via a wired connection and / or a wireless connection. For example, the communication component 660 may include a receiver, transmitter, transceiver, modem, network interface card, and / or antenna.

[0103] The device 600 may perform one or more of the operations or processes described herein. For example, a non-transitory computer-readable medium (e.g., the memory 630) may store a set of instructions (e.g., one or more instructions or code) for execution by the processor 620. The processor 620 may execute the set of instructions to perform one or more of the operations or processes described herein. In some implementations, the execution of a set of instructions by one or more processors 620 causes the one or more processors 620 and / or the device 600 to perform one or more of the operations or processes described herein. In some implementations, hardwired circuitry may be used instead of or in combination with the instructions to perform one or more of the operations or processes described herein. Additionally or alternatively, the processor 620 may be configured to perform one or more of the operations or processes described herein. Thus, the implementations described herein are not limited to any particular combination of hardware circuitry and software.

[0104] In Figure 6The number and arrangement of components shown are provided as an example. Compared to what is shown in Figure 6 Device 600 may include additional components, fewer components, different components, or components in a different arrangement. Additionally or alternatively, a set of components (e.g., one or more components) of device 600 may perform one or more functions described by another set of components of device 600.

[0105] Figure 7 FIG. is a diagram of example components of device 700 associated with key request management. Device 700 may correspond to peer device 510 and / or node 520. In some implementations, peer device 510 and / or node 520 may include one or more device 700 and / or one or more components of device 700. As shown in Figure 7 Device 700 may include one or more input components 710-1 through 710-B (B≥1) (collectively referred to hereinafter as input components 710 and individually as input component 710), a switching component 720, one or more output components 730-1 through 730-C (C≥1) (collectively referred to hereinafter as output components 730 and individually as output component 730), and a controller 740.

[0106] Input component 710 may be one or more points of attachment for a physical link and may be one or more points of entry for incoming traffic (e.g., packets). Input component 710 may process incoming traffic, such as by performing data link layer encapsulation or decapsulation. In some implementations, input component 710 may transmit and / or receive packets. In some implementations, input component 710 may include an input line card that includes one or more packet processing components (e.g., in the form of integrated circuits), such as one or more interface cards (IFCs), packet forwarding components, line card controller components, input ports, processors, memories, and / or input queues. In some implementations, device 700 may include one or more input components 710.

[0107] Switching component 720 may interconnect input component 710 and output component 730. In some implementations, switching component 720 may be implemented via one or more crossbars, via a bus, and / or with shared memory. Shared memory may act as a temporary buffer to store packets from input component 710 before the packets are finally scheduled for delivery to output component 730. In some implementations, switching component 720 may enable input component 710, output component 730, and / or controller 740 to communicate with each other.

[0108] The output component 730 can store packets and can schedule packets for transmission over output physical links. The output component 730 can support data link layer encapsulation or decapsulation, and / or various higher-level protocols. In some implementations, the output component 730 can transmit packets and / or receive packets. In some implementations, the output component 730 can include an output line card that includes one or more packet processing components (e.g., in the form of an integrated circuit), such as one or more IFCs, packet forwarding components, line card controller components, output ports, processors, memories, and / or output queues. In some implementations, the device 700 can include one or more output components 730. In some implementations, the input component 710 and the output component 730 can be implemented by the same set of components (e.g., and the input / output component can be a combination of the input component 710 and the output component 730).

[0109] The controller 740 includes a processor in the form of, for example, a processor, a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), and / or another type of processor. The processor is implemented in hardware, firmware, or a combination of hardware and software. In some implementations, the controller 740 can include one or more processors programmable to perform functions.

[0110] In some implementations, the controller 740 can include RAM, ROM, and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, optical memory, etc.) that stores information and / or instructions for use by the controller 740.

[0111] In some implementations, the controller 740 can communicate with other devices, networks, and / or systems connected to the device 700 to exchange information about the network topology. The controller 740 can create a routing table based on the network topology information, can create a forwarding table based on the routing table, and can forward the forwarding table to the input component 710 and / or the output component 730. The input component 710 and / or the output component 730 can use the forwarding table to perform routing lookups for incoming and / or outgoing packets.

[0112] The controller 740 can execute one or more of the processes described herein. In response to executing software instructions stored by a non-transitory computer-readable medium, the controller 740 can execute these processes. A computer-readable medium is defined herein as a non-transitory storage device. A storage device includes storage space within a single physical storage device or storage space distributed across multiple physical storage devices.

[0113] Software instructions can be read into the memory and / or storage components associated with controller 740 from another computer-readable medium or from another device via a communication interface. When executed, the software instructions stored in the memory and / or storage components associated with controller 740 may cause controller 740 to perform one or more of the processes described herein. Additionally or alternatively, hardwired circuitry may also be used to perform one or more of the processes described herein in place of or in combination with software instructions. Accordingly, the implementations described herein are not limited to any particular combination of hardware circuitry and software.

[0114] The number and arrangement of components shown Figure 7 are provided as an example. In practice, device 700 may include additional components, fewer components, different components, or differently arranged components than those shown Figure 7 in. Additionally or alternatively, a set of components of device 700 (e.g., one or more components) may perform one or more functions described by another set of components of device 700.

[0115] Figure 8 is a flowchart of an example process 800 associated with key request management. In some implementations, Figure 8 one or more of the process blocks of Figure 1 are performed by a network device (e.g., Figure 8 a network device of). In some implementations, Figure 8 one or more of the process blocks of Figure 8 are performed by another device or a set of devices separate from or including the network device, such as a peer device (e.g., peer device 510) and / or a node (e.g., node 520). Additionally or alternatively,

[0116] As shown in Figure 8 , process 800 may include transmitting a key request and a proposed key request rate associated with the key request (block 810). For example, a network device may transmit a key request and a proposed key request rate associated with the key request, as described above.

[0117] As shown in Figure 8As further shown in FIG. 800, the process 800 may include receiving a response to a key request based on a proposed key request rate (block 820). For example, a network device may receive a response to a key request based on a proposed key request rate, as described above.

[0118] The process 800 may include additional implementations, such as any single implementation or any combination of implementations described below, and / or related to one or more other processes described elsewhere herein.

[0119] In a first implementation, the process 800 includes receiving, by a network device, an indication of a supported key request rate.

[0120] In a second implementation, either alone or in combination with the first implementation, the response to the key request is a rejection of the key request, and the rejection of the key request is associated with an alert.

[0121] In a third implementation, either alone or in combination with one or more of the first and second implementations, the response to the key request is a rejection of the key request, and the process 800 includes transmitting another proposed key request rate having a transmission rate less than or equal to the supported key request rate.

[0122] In a fourth implementation, either alone or in combination with one or more of the first through third implementations, the response to the key request is an acceptance of the key request, and the process 800 includes transmitting another key request associated with the key request and another proposed key request rate associated with other key requests.

[0123] In a fifth implementation, either alone or in combination with one or more of the first through fourth implementations, the response to the key request is an acceptance of the key request, and the process 800 includes transmitting another key request associated with the key request and suppressing the transmission of another proposed key request rate associated with other key requests.

[0124] In a sixth implementation, either alone or in combination with one or more of the first through fifth implementations, the proposed key request rate is a proposed key request pacing.

[0125] In a seventh implementation, either alone or in combination with one or more of the first through sixth implementations, the response to the key request is a rejection of the key request, and the rejection of the key request indicates that the rejection of the key request is based on the proposed key request pacing.

[0126] Although Figure 8 example blocks of the process 800 are shown, in some implementations, the process 800 includes additional blocks, fewer blocks, different blocks, or Figure 8Those described boxes as compared to differently arranged ones. Additionally or alternatively, two or more of the boxes may be executed in parallel.

[0127] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementation to the precise forms disclosed. Modifications and variations can be made in light of the above disclosure, or can be obtained from the practice of the implementation.

[0128] As used herein, a service or content may include a set of packets. A packet may refer to a communication structure for communicating information, such as a protocol data unit (PDU), a service data unit (SDU), a network packet, a datagram, a segment, a message, a block, a frame (e.g., an Ethernet frame), a portion of any of the foregoing, and / or a formatted or unformatted unit of another type of data capable of being transmitted via a network.

[0129] As used herein, the term "component" is intended to be broadly interpreted as hardware, firmware, or a combination of hardware and software. It is evident that the systems and / or methods described herein can be implemented in different forms of hardware, firmware, and / or combinations of hardware and software. The actual specific control hardware or software code used to implement these systems and / or methods is not a limitation of the implementation. Thus, the operation and behavior of the systems and / or methods described herein do not involve specific software code - it is understood that based on the description herein, software and hardware can be used to implement the systems and / or methods.

[0130] Even if particular combinations of features are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of each implementation. In fact, many of these features may be combined in ways not recited in the claims and / or not disclosed in the specification. Although each dependent claim listed below may directly depend on one claim, the disclosure of each implementation includes each dependent claim combined with every other claim in the claim set. As used herein, the phrase referring to a list of items "at least one of" refers to any combination of those items, including a single member. For example, "at least one of a, b, or c" is intended to cover a, b, c, a - b, a - c, b - c, and a - b - c, as well as multiple combinations of the same items.

[0131] When a "processor" or "one or more processors" (or another device or component, such as a "controller" or "one or more controllers") is described or recited (within a single claim or across multiple claims) as performing multiple operations or being configured to perform multiple operations, this language is intended to broadly cover a variety of processor architectures and environments. For example, unless otherwise expressly recited (e.g., via the use of "a first processor" and "a second processor" or other language differentiating processors in the claims), this language is intended to cover a single processor that performs or is configured to perform all of the operations, a group of processors that uniformly perform or are configured to perform all of the operations, a first processor that performs or is configured to perform a first operation and a second processor that performs or is configured to perform a second operation, or any combination of processors that perform or are configured to perform the operations. For example, when a claim has the form "one or more processors to: perform X; perform Y; and perform Z," this claim should be interpreted to mean "one or more processors to perform X; one or more (possibly different) processors to perform Y; and one or more (also possibly different) processors to perform Z."

[0132] Unless so expressly stated, no element, act, or instruction used herein shall be construed as critical or essential. Further, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." Further, as used herein, the article "the" is intended to include one or more items associated with the article "the" and may be used interchangeably with "the one or more." Further, as used herein, the term "set" is intended to include one or more items (e.g., related items, unrelated items, or a combination of related and unrelated items) and may be used interchangeably with "one or more." If only one item is intended, the phrase "only one" or similar language is used. Further, as used herein, the terms "has," "have," "having," or similar terms are all intended to be open-ended terms. Further, the phrase "based on" is intended to mean "at least partially based on" unless otherwise expressly stated. Further, as used herein, the term "or" is intended to be inclusive when used in a series and may be used interchangeably with "and / or" unless otherwise expressly stated (e.g., if used in combination with "one of" or "among other things").

Claims

1. A method comprising: transmitting, by a network device, key requests and a proposed key request rate associated with the key requests; as well as Responses to the key requests are received by the network device based on the proposed key request rate.

2. The method according to claim 1, further comprising: An indication of a supported key request rate is received by the network device. 3 . The method of claim 1 , wherein the response to the key request is a denial of the key request, and wherein the denial of the key request is associated with an alert.

4. The method of claim 1 , wherein the response to the key request is a rejection of the key request, the method further comprising: Another proposed key request rate is transmitted by the network device, the another proposed key request rate being less than or equal to the supported key request rate.

5. The method of claim 1 , wherein the response to the key request is an acceptance of the key request, the method further comprising: Another key request associated with the key request and another proposed key request rate associated with the another key request are transmitted by the network device.

6. The method of claim 1 , wherein the response to the key request is an acceptance of the key request, the method further comprising: transmitting, by the network device, another key request associated with the key request; as well as A rate of transmitting another proposed key request associated with the another key request is suppressed by the network device.

7. The method of claim 1, wherein the proposed key request rate is a proposed key request cadence.

8. The method of claim 7, wherein the response to the key request is a rejection of the key request, wherein the rejection of the key request indicates that the rejection of the key request is based on the proposed key request pacing.

9. A network device comprising: one or more memories; as well as One or more processors to: Transmission key request; as well as A response to the key request is received, the response including a key derivation key or an indication of a time associated with another key request.

10. The network device of claim 9, wherein the one or more processors to receive the key derivation key or the indication of the time associated with the another key request are further to: receive the key derivation key.

11. The network device of claim 10, wherein the one or more processors are further configured to: An indication is received that the key derivation key is a key derivation.

12. The network device of claim 9, wherein the one or more processors configured to receive the key derivation key or the indication of the time associated with the further key request are configured to: receive the indication of the time associated with the further key request.

13. The network device of claim 12, wherein the time associated with the another key request is a predicted time at which a non-key derivation key will be available.

14. A non-transitory computer readable medium storing a set of instructions, the set of instructions comprising: One or more instructions, which, when executed by one or more processors of a network device, cause a security application entity SAE of the network device to: transmitting a quantum key distribution (QKD) key request and a proposed QKD key request rate associated with the QKD key request; as well as Responses to the QKD key requests are received based on the proposed QKD key request rate.

15. The non-transitory computer readable medium of claim 14, wherein the one or more instructions further cause the SAE of the network device to: Receive an indication of a supported QKD key request rate.

16. The non-transitory computer-readable medium of claim 14, wherein the response to the QKD key request is a rejection of the QKD key request, and wherein the rejection of the QKD key request is associated with an alert.

17. The non-transitory computer-readable medium of claim 14, wherein the response to the QKD key request is a denial of the QKD key request, and wherein the one or more instructions further cause the SAE of the network device to: Another proposed QKD key request rate is transmitted, wherein the other proposed QKD key request rate is less than or equal to the supported QKD key request rate.

18. The non-transitory computer-readable medium of claim 14, wherein the response to the key request is an acceptance of the key request, and wherein the one or more instructions further cause the SAE of the network device to: Another QKD key request associated with the QKD key request and another proposed QKD key request rate associated with the another QKD key request are transmitted.

19. The non-transitory computer-readable medium of claim 14, wherein the response to the key request is an acceptance of the key request, wherein the one or more instructions further cause the SAE of the network device to: transmitting another QKD key request associated with the QKD key request; and A rate at which another proposed QKD key request associated with the another QKD key request is transmitted is suppressed.

20. The non-transitory computer-readable medium of claim 14, wherein the proposed QKD key request rate is a proposed QKD key request cadence.

Images