EP3883205A1 - Poursuite d'une session d'accord de clé (mka) de sécurité de contrôle d'accès aux médias (macsec) sur un dispositif de réseau devenant temporairement indisponible - Google Patents
Poursuite d'une session d'accord de clé (mka) de sécurité de contrôle d'accès aux médias (macsec) sur un dispositif de réseau devenant temporairement indisponible Download PDFInfo
- Publication number
- EP3883205A1 EP3883205A1 EP20174112.1A EP20174112A EP3883205A1 EP 3883205 A1 EP3883205 A1 EP 3883205A1 EP 20174112 A EP20174112 A EP 20174112A EP 3883205 A1 EP3883205 A1 EP 3883205A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- network device
- mka
- session
- state
- packet
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000004891 communication Methods 0.000 claims abstract description 98
- 238000000034 method Methods 0.000 claims description 107
- 230000008569 process Effects 0.000 claims description 82
- 230000015654 memory Effects 0.000 claims description 45
- 238000012545 processing Methods 0.000 claims description 16
- 230000009471 action Effects 0.000 claims description 9
- 230000005540 biological transmission Effects 0.000 claims description 5
- 238000010586 diagram Methods 0.000 description 7
- 230000006870 function Effects 0.000 description 6
- 230000003287 optical effect Effects 0.000 description 4
- 239000002699 waste material Substances 0.000 description 3
- 230000001413 cellular effect Effects 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 238000005538 encapsulation Methods 0.000 description 2
- 230000002085 persistent effect Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 230000006399 behavior Effects 0.000 description 1
- 239000000872 buffer Substances 0.000 description 1
- 230000001010 compromised effect Effects 0.000 description 1
- 230000007613 environmental effect Effects 0.000 description 1
- 230000003203 everyday effect Effects 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/141—Setup of application sessions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/162—Implementing security features at a particular protocol layer at the data link layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0659—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities
- H04L41/0661—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities by reconfiguring faulty entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/065—Network architectures or network communication protocols for network security for supporting key management in a packet data network for group communications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/142—Managing session states for stateless protocols; Signalling session states; State transitions; Keeping-state mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/143—Termination or inactivation of sessions, e.g. event-controlled end of session
- H04L67/145—Termination or inactivation of sessions, e.g. event-controlled end of session avoiding end of session, e.g. keep-alive, heartbeats, resumption message or wake-up for inactive or interrupted session
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/54—Presence management, e.g. monitoring or registration for receipt of user log-on information, or the connection status of the users
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/28—Timers or timing mechanisms used in protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
Definitions
- MACsec Media access control security
- IEEE 802.1AE Institute of Electrical and Electronics Engineers
- the MACsec standard specifies a set of protocols to meet security requirements for protecting data traversing Ethernet local area networks (LANs).
- LANs Ethernet local area networks
- MACsec allows unauthorized LAN connections to be identified and excluded from communication within a network, and defines a security infrastructure to provide data confidentiality, data integrity, and data origin authentication.
- a method may include communicating, by a network device, with another network device via a media access control security (MACsec) key agreement (MKA) communication link, wherein an MKA session has been established between the network device and the other network device; determining, by the network device, that the other network device is unavailable; causing, by the network device and based on determining that the other network device is unavailable, an MKA state of the network device to be placed in a paused state; receiving, by the network device and after causing the MKA state of the network device to be placed in the paused state, a packet from the other network device via the MKA communication link; determining, by the network device and based on the packet, that the MKA session has not ended; and continuing, by the network device and based on the MKA session having not ended, the MKA session by reactivating the MKA state.
- MKA media access control security
- a network device may include one or more memories; and one or more processors to: communicate with another network device via a media access control security (MACsec) key agreement (MKA) communication link, wherein an MKA session has been established between the network device and the other network device; cause, based on communicating with the other network device, information associated with an MKA state of the network device and information associated with the MKA session to be stored in a data structure, determine that the network device is to become unavailable at a particular time; send, to the other network device and based on determining that the network device is to become unavailable at the particular time, an MKA packet indicating that the network device is to become unavailable; determine, after the particular time, that the network device has become available; and cause, after determining that the network device has become available, the network device to be updated based on the information associated with the MKA state of the network device and the information associated with the MKA session stored in the data structure.
- MKA media access control security
- a computer-readable medium may store one or more instructions.
- the one or more instructions when executed by one or more processors of a network device, may cause the one or more processors to: communicate with another network device via a media access control security (MACsec) key agreement (MKA) communication link, wherein an MKA session has been established between the network device and the other network device; cause, based on communicating with the other network device, information associated with an MKA state of the network device and information associated with the MKA session to be stored in a data structure, determine, after causing the information associated with the MKA state of the network device and information associated with the MKA session to be stored in the data structure, that the network device has become available after being temporarily unavailable; cause, after determining that the network device has become available, the network device to be updated based on the information associated with the MKA state of the network device and the information associated with the MKA session stored in the data structure; send, after causing the network device to be updated, an MKA packet to the other network device via the MKA communication link;
- MKA
- a network device may establish a media access control security (MACsec) key agreement (MKA) session (e.g., a secure session) with another network device.
- MKA media access control security
- the MKA session is destroyed.
- the network device that went offline comes back online
- a new MKA session is to be be established between the network devices.
- computing resources e.g., processing resources, memory resources, communication resources, and/or the like
- network resources e.g., processing resources, memory resources, communication resources, and/or the like
- destroying an MKA session when one of the network devices goes offline and establishing a new MKA session when the network device comes back online may waste computing resources and/or network resources associated with a delay in a communication of traffic between the network devices waiting for the MKA session to be reestablished.
- destroying an MKA session when one of the network devices goes offline and establishing a new MKA session when the network device comes back online may cause a delay in overall network service resumption that may waste computing resources and/or network resources associated with the delay.
- a network device may continue an MKA session upon another network device becoming temporarily unavailable (e.g., rebooting, going offline, failing, and/or the like).
- the network device may communicate with another network device via an MKA communication link, establishing an MKA session.
- the network device may determine that the other network device is unavailable (e.g., rebooting, going offline, failing, and/or the like).
- the network device may cause an MKA state of the network device to be placed in a paused state.
- the network device may receive a packet from the other network device via the MKA communication link.
- the network device may determine, based on the packet, that the MKA session has not ended.
- the network device may continue, based on the MKA session having not ended, the MKA session with the other network device by reactivating the MKA state.
- the network device may conserve computing resources and/or network resources that would have otherwise been used to destroy the MKA session when the other network device became unavailable and reestablish the MKA session when the other network device became available again. Furthermore, the network device may quickly resume MKA sessions and may conserve computing resources and/or network resources that would have otherwise been used waiting to communicate traffic while the MKA session is reestablished after the other network device becomes available again.
- Figs. 1A-1F are diagrams of one or more example implementations 100 described herein.
- a network device A and a network device B may be in communication via a MACsec communication link (e.g., an MKA communication link).
- network device A and network device B may include an MKA stack.
- the MKA stacks of network device A and/or network device B may include an MKA daemon, a kernel, a packet processing component, an interface, and/or a MACsec network interface controller (NIC).
- the MKA daemon may include a process or program operating in the background of the network device (e.g., network device A and/or network device B) to exchange MKA communications (e.g., packets) with MKA enabled devices.
- the kernel may include a program that operates to translate packet data between the packet processing component and the MKA daemon.
- the packet processing component may perform packet switching and/or routing of MKA packet data, such as extensive authentication protocol over local area network (EAPoL) packets.
- the interface may serve as a software interface between the MACsec NIC and the network device/packet processing component.
- the MACsec NIC may serve as the hardware interface between the network device (e.g., network device A and/or network device B) and a network (e.g., a network of the MACsec communication link).
- the MACsec NIC may be a software interface between the network device and the network.
- data may be exchanged via an MKA session path.
- the MKA session path may be between MKA daemons of network device A and network device B.
- the MKA session path may travel through each element in the MKA stacks (e.g., the MACsec NIC, the interface, the packet processing component, and the kernel) of network device A and/or network device B.
- an MKA session may be established between network device A and network device B, as described in more detail below.
- MKA packet data e.g., peer liveness messages
- MKA session path e.g., according to a standard.
- network device A and network device B may share MKA keys (e.g., encryption keys, decryption keys, and/or the like).
- the MKA keys may be verified by network device A and/or network device B to establish the MKA session (e.g., if network device A and/or network device B is unable to verify an MKA key received from the other network device, then the MKA session may not be established).
- the MKA keys may be configured by a user associated with network device A and/or network device B.
- the MKA keys may be generated dynamically by network device A, network device B, a device (such as a server device, a cloud computing platform, and/or the like) associated with network device A and/or associated with network device B, and/or the like.
- a device such as a server device, a cloud computing platform, and/or the like
- the MKA keys may include a connectivity association key (CAK), a secure association key (SAK), a master key, and/or the like.
- CAK connectivity association key
- SAK secure association key
- CKN connectivity association name
- the pre-shared keys may be configured by a user associated with network device A and/or network device B, and may be stored by network device A and/or by network device B.
- Network device A may share the pre-shared keys associated with network device A with network device B and network device B may share the pre-shared keys associated with network device B with network device A. If the pre-shared keys match (e.g., network device A verifies the pre-shared keys received from network device B and/or network device B verifies the pre-shared keys received from network device A), then the MKA session may be established.
- network device A and network device B may negotiate (e.g., enable and/or configure) whether the MKA session will resume if one of the network devices becomes temporarily unavailable (e.g., temporarily goes offline, reboots, fails, and/or the like). As such, network device A and network device B may enable, disable, configure, and/or the like, the processes described herein associated with continuing an MKA session upon network device A and/or network device B becoming temporarily unavailable. In some implementations, this negotiation may only occur when network device A and network device B establish an MKA session for the first time.
- network device A and/or network device B may be required to agree to continue the MKA session upon network device A and/or network device B becoming available after being temporarily unavailable.
- network device A and/or network device B may not store information related to the MKA session when network device A and/or network device B becomes unavailable (as described below in more detail) unless network device A and/or network device B agree to continue the MKA session when network device A and/or network device B become available again. This may improve security of network device A and/or network device B and conserve computing resources and/or network resources that would have otherwise been used to store information related to the MKA session.
- network device A and network device B may communicate via the MACsec communication link.
- network device A may communicate traffic from network device A to network device B via the MACsec communication link (and vice versa).
- the traffic communicated via the MACsec communication link may be secured using a key shared between network device A and network device B, such as the SAK.
- the SAK may be a randomly generated key.
- the SAK may be generated by network device A, network device B, and/or a device associated with network device A and/or associated with network device B.
- the SAK may be generated based on establishing the MKA session between network device A and network device B. Additionally, or alternatively, the SAK may be generated periodically such that a new SAK is shared between network device A and network device B each time a SAK is generated while the MKA session is active.
- the SAK may be shared from one network device to the other (e.g., from network device A to network device B or from network device B to network device A) and/or received by network device A and/or network device B from a device associated with network device A and/or associated with network device B.
- the SAK may be shared after the MKA session is established.
- Network device A and/or network device B may use the SAK to secure all traffic sent via the MACsec communication link.
- traffic communicated via the MACsec communication link between network device A and network device B may be associated with a message identifier.
- Traffic communicated via the MACsec communication link may be assigned a message identifier to ensure that the traffic is not received by a network device (e.g., network device A or network device B) out of sequence (e.g., out of order, associated with unrelated traffic, and/or the like).
- the message identifier may be assigned such that the message identifier is associated with the most recent previously assigned message identifier (e.g., such that the message identifiers are assigned in an order).
- network device A may store information associated with an MKA state of network device A and/or information associated with the MKA session with network device B. Additionally, or alternatively, network device B may store information associated with an MKA state of network device B and/or information associated with the MKA session. Network device A and/or network device B may store the information associated with an MKA state and/or the information associated with the MKA session in a persistent storage (e.g., a storage that retains data after the network device becomes unavailable).
- the information associated with the MKA state of one network device may reference information associated other network device (e.g., the information associated with an MKA state of network device A may reference information associated with network device B and vice versa).
- Network device A may store information associated with the MKA state of network device A and the information associated with the MKA session in a similar manner.
- the information associated with the MKA state and the information associated with the MKA session, for network device B may include one or more MKA keys, a control plane MKA state associated with network device B, one or more message identifiers associated with the MKA session, a MAC address associated with network device A and/or a MAC address associated with network device B, a port identifier associated with the MKA session, an identifier associated with network device A, and/or the like.
- Network device B may store the information associated with the MKA state and the information associated with the MKA session periodically (e.g., once every 30 minutes, once every hour, once every day, and/or the like). Additionally, or alternatively, network device B may store the information associated with the MKA state and the information associated with the MKA session when network device B determines that network device B is going to become temporarily unavailable, such as by receiving an input directing network device B to go offline or reboot, by detecting a loss of power to network device B, by detecting a failure condition associated with network device B, and/or the like.
- Network device B may store the information associated with the MKA state and the information associated with the MKA session in a data structure (e.g., a list, a table, a mapping, and/or the like) that network device B may access.
- the data structure may be stored in network device B, in a device associated with network device B, in a cloud computing environment associated with network device B, and/or the like.
- the data structure may be stored in a persistent storage.
- the information associated with the MKA state and the information associated with the MKA session may be stored in the data structure with an identifier that identifies the MKA session, such that network device B may access the information associated with the MKA state and the information associated with the MKA session by searching the data structure for the identifier that identifies the MKA session.
- network device B may be involved in a plurality of MKA sessions with different network devices.
- Network device B may store the MKA state and the information associated with the MKA session for each of the plurality of MKA sessions.
- Network device B may distinguish between each of the plurality of MKA sessions based on the identifier associated with each MKA session.
- network device B may replace and/or delete any previously stored information associated with a different MKA state and/or information associated with a different MKA session in the data structure when network device B stores the information associated with the MKA state and the information associated with the MKA session (e.g., such that the information stored in the data structure is associated with the most recent MKA session established by network device B).
- network device B may determine that network device B is to become temporarily unavailable. For example, network device B may receive an input directing network device B to reboot and/or go offline, detect a loss of power to network device B, determine that network device B is scheduled to reboot and/or go offline, detect a failure condition associated with network device B, and/or the like.
- network device B may send a packet (e.g., the packet may be any packet, such as an MKA packet, a packet associated with network traffic, a packet associated with a last gasp message, and/or the like) to network device A indicating that network device B is to become temporarily unavailable.
- the packet may indicate that network device A and network device B have previously negotiated (e.g., enabled and/or configured) continuing the MKA session when network device B becomes available again.
- network device B may send a dying gasp message (e.g., a message indicating that network device B has lost power, is about to reboot, is about to go offline, has experienced a particular failure condition, and/or the like) to network device A when network device B determines that network device B is to become temporarily unavailable.
- a dying gasp message e.g., a message indicating that network device B has lost power, is about to reboot, is about to go offline, has experienced a particular failure condition, and/or the like
- network device B may become unavailable.
- Network device B may become unavailable by rebooting network device B, by going offline, by losing power and restarting, and/or the like.
- Network device B becoming unavailable may cause the MACsec communication link between network device A and network device B to be broken.
- network device A may determine that network device B is unavailable (e.g., is rebooting, is offline, has failed, and/or the like).
- Network device A may determine that network device B is unavailable based on the packet received from network device B, based on the dying gasp message received from network device B, based on the MACsec communication link between network device A and network device B being broken, based on not receiving an MKA packet from network device B for a length of time, and/or the like.
- network device A may cause an MKA state of network device A to be placed in a paused state.
- the MKA protocol of the MKA session may be paused between network device A and network device B.
- network device A or network device B may pause MKA daemons or processes of the MKA session (e.g., by pausing one or more state machines associated with the MKA daemons).
- the MKA daemon of network device A and/or of network device B
- Network device A may pause a timeout timer associated with the MKA session.
- network device A may suspend or pause a timeout timer associated with sending liveness messages for the MKA session to network device B. Accordingly, because the MKA packet data (which serve as liveness messages) of the MKA session are not to be transmitted and/or monitored for receipt, while the MKA session is in the paused state, the MKA session will not be destroyed.
- Network device A may store information associated with the MKA state of network device A and/or information associated with the MKA session.
- the information associated with the MKA state of network device A and/or information associated with the MKA session may be similar to (or the same as) the information stored by network device B, as described above.
- Network device A may store the information associated with the MKA state of network device A and/or the information associated with the MKA session in a data structure in a similar (or the same) manner as described above with respect to network device B.
- Network device A may initiate a resume timer associated with the paused state.
- the resume timer may relate to an amount of time that the MKA state of network device A may remain in the paused state. For example, if the resume timer expires (e.g., if the amount of time associated with the resume time passes), network device A may destroy the MKA session between network device A and network device B to end, such as by deleting the information associated with the MKA state of network device A and/or the information associated with the MKA session stored by network device A.
- the amount of time associated with the resume timer may be preconfigured by network device A. Additionally, or alternatively, the amount of time associated with the resume timer may be configured when network device A and network device B negotiate (e.g., enable and/or configure) the continuation of the MKA session upon network device A and/or network device B becoming available again, as described above.
- the amount of time associated with the resume timer may be related to an amount of time network device A and/or network device B need to become available after becoming unavailable, such as an amount of time to reboot, an amount of time to recover from a failure condition, an amount of time to address an offline condition, and/or the like.
- the amount of time associated with the resume timer may be set (e.g., configured) by a user associated with network device A and/or associated with network device B. In some implementations, the amount of time associated with the resume timer may be negotiated between network device 1 and network device 2 using a network protocol (e.g., an MKA protocol and/or the like).
- a network protocol e.g., an MKA protocol and/or the like.
- network device B may determine that network device B has become available again (e.g., by completing a reboot process, by coming online, by recovering from a failure condition, and/or the like).
- Network device B may determine that network device B has become available based on network device B completing a reboot process, coming online, recovering from a failure condition, and/or the like.
- network device B may update network device B based on the information associated with the MKA state and the information associated with the MKA session stored by network device B. For example, network device B may access the data structure to obtain the information associated with the MKA state and the information associated with the MKA session. Network device B may restore the MKA state of network device B based on the information associated with the MKA state and the information associated with the MKA session stored by network device B.
- Network device B may restore the MKA state of network device B by obtaining the information associated with the MKA state and the information associated with the MKA session stored by network device B and storing the information within network device B for operation (e.g., in the MKA Daemon, in the packet procession component, and/or the like).
- Network device B may restore one or more MKA keys associated with the MKA session. As such, network device B may return to the same MKA state as was present before network device B became unavailable.
- network device B may send a packet (e.g., the packet may be any packet, such as an MKA packet, a packet associated with network traffic, and/or the like) to network device A indicating that network device B has become available.
- the packet may identify information associated with the MKA state of network device B and/or information associated with the MKA session.
- the packet may be associated with a message identifier related to the last message identifier stored by network device B (e.g., network device B may associate the packet with a message identifier that is next in a sequence based on the last message identifier stored by network device B).
- the packet indicating that network device B has become available may identify one or more MKA keys associated with the MKA session.
- network device A may determine that the MKA session has not ended.
- Network device A may determine that the MKA session has not ended based on the resume timer. For example, network device A may determine an amount of time between causing the MKA state of network device A to be placed in a paused state and receiving the packet from network device B indicating that network device B has become available. Network device A may determine if the amount of time between causing the MKA state of network device A to be placed in a paused state and receiving the packet from network device B indicating that network device B has become available satisfies a threshold amount of time.
- the threshold amount of time may be related to the amount of time associated with the resume timer.
- network device A may determine that the amount of time associated with the resume timer has expired (e.g., the resume timer may be a countdown timer or a count up timer such that when the resume timer reaches (e.g., by counting down from the amount of time or counting up to the amount of time) the amount of time associated with the resume timer, the resume timer indicates that the MKA session has expired).
- Network device A may determine that the MKA session has not ended based on network device A obtaining the information associated with the MKA state of network device A and/or the information associated with the MKA session stored by network device A. For example, if the amount of time associated with the resume timer passes, network device A may delete the information associated with the MKA state of network device A and/or the information associated with the MKA session stored by network device A. As such, if network device A is able to obtain the information associated with the MKA state of network device A and/or the information associated with the MKA session then network device A may determine that the MKA session has not ended.
- Network device A may determine that the MKA session has not ended based on identifying the message identifier associated with the packet that indicates network device B has become available.
- Network device A may identify the message identifier and determine that the message identifier corresponds to a message identifier of the MKA session at the time when the MKA state of network device A was placed in the paused state. Additionally, or alternatively, network device A may identify one or more MKA keys identified in the packet that indicates network device B has become available.
- Network device A may compare the one or more MKA keys to the MKA keys stored by network device A at the time when the MKA state of network device A was placed in the paused state. If the one or more MKA keys match the MKA keys stored by network device A, then network device A may determine that the MKA session has not ended.
- network device A may cause, based on determining that the MKA session has not ended, the MKA session of network device A to be placed into an active state.
- Network device A may cause, based on the MKA session of network device A being placed into the active state, the MKA protocol associated with the MKA session to resume.
- Network device A may continue the MKA session when network device B becomes available by reactivating the MKA state associated with network device A.
- network device A may resume sending MKA packet data (e.g., peer liveness messages) periodically (e.g., every 2 seconds or more) between the MKA daemon of network device A and the MKA daemon of network device B via the MKA session path (e.g., according to a standard).
- MKA packet data e.g., peer liveness messages
- MKA session path e.g., according to a standard
- network device A and/or network device B may, based on the MKA session of network device A being placed into the active state, communicate traffic via the MACsec communication link.
- Network device A and network device B may communicate traffic in a similar manner as described above with respect to the communication of traffic before network device B became unavailable.
- network device A and/or network device B may cause a rekey process to be performed for the MKA session after the MKA session is placed in the active state.
- the rekey process may be requested by network device A and/or network device B.
- Network device A and/or network device B may identify the rekey request in a rekey request MKA packed received from the other network device.
- the rekey process may cause the MKA keys associated with the MKA session to be changed, replaced, updated, altered, and/or the like.
- the rekey process may provide improved security as the MKA keys may have been stored for a period of time by network device A and/or network device B during the time network device B was unavailable. As such, the MKA keys may have been accessed or compromised during the time network device B was unavailable. As such, the rekey process provides the additional security of providing one or more new MKA keys.
- network device A and/or network device B may not cause the rekey process to be performed. In this situation, the MKA session may continue with the same MKA keys that were used prior to the MKA session being placed in a paused state.
- network device A may determine, based on receiving the packet that indicates network device B has become available, that the MKA session has ended. For example, network device A may determine that the MKA session has ended based on determining that the amount of time between causing the MKA state of network device A to be placed in a paused state and receiving the packet from network device B indicating that network device B has become available does not satisfy a threshold amount of time (e.g., related to the amount of time associated with the resume timer), determining that the resume timer has expired, determining that network device A is unable to access the information associated with the MKA state of network device A and/or the information associated with the MKA session stored by network device A, determining that the message identifier identified in the packet that indicates network device B has become available does not correspond to the message identifier of the MKA session at the time when the MKA session was placed in the paused state, determining that one or more MKA keys identified in the packet that indicates network device B
- Network device A may, based on network device A determining that the MKA session has ended, delete any information related to the MKA session stored by network device A.
- network device B may, based on network device B determining that the MKA session has ended (e.g., by network device B independently determining the MKA session has ended (e.g., by not receiving a response to the packet indicating network device B has become available, by determining the MKA session has not been reestablished, and/or the like), by receiving a message from network device A indicating that the MKA session has ended, and/or the like), delete any information related to the MKA session stored by network device B.
- network device A may delete the information associated with the MKA state of network device A and/or the information associated with the MKA session stored by network device A.
- Network device B may delete the information associated with the MKA state of network device B and/or the information associated with the MKA session stored by network device B. Deleting the information associated with the MKA state of network device A and/or network device B and/or the information associated with the MKA session may improve security by ensuring that sensitive information (such as the MKA keys) cannot be accessed after the MKA session has ended.
- network device A may, based on network device A determining that the MKA session has ended, cause a new MKA session to be established between network device A and network device B.
- network device B may, based on network device B determining that the MKA session has ended, cause a new MKA session to be established between network device B and network device A.
- the new MKA session may be established in a similar (or the same) manner as described above with respect to initially establishing the MKA session between network device A and network device B.
- Network device A and network device B may, based on establishing the new MKA session, communicate traffic via a new MACsec communication link in a similar (or the same) manner as described above.
- Some implementations described herein may enable network device A and/or network device B to conserve computing resources and/or network resources that would have otherwise been used to destroy the MKA session when the other network device became unavailable and reestablish the MKA session when the other network device became available again. Furthermore, some implementations described herein may conserve computing resources and/or network resources that would have otherwise been used waiting to communicate traffic while the MKA session is reestablished after the other network device becomes available again.
- Figs. 1A-1F are provided merely as one or more examples. Other examples may differ from what is described with regard to Figs. 1A-1F .
- the number and arrangement of devices shown in Figs. 1A-1F are provided as one or more examples. In practice, there may be additional devices, fewer devices, different devices, or differently arranged devices than those shown in Figs. 1A-1F .
- two or more devices shown in Figs. 1A-1F may be implemented within a single device, or a single device shown in Figs. 1A-1F may be implemented as multiple, distributed devices.
- a set of devices (e.g., one or more devices) of Figs. 1A-1F may perform one or more functions described as being performed by another set of devices of Figs. 1A-1F .
- Fig. 2 is a diagram of an example environment 200 in which systems and/or methods described herein may be implemented.
- environment 200 may include a group of network devices 210 (shown as network device 210-1 through network device 210-N), and a network 220.
- Devices of environment 200 may interconnect via wired connections, wireless connections, or a combination of wired and wireless connections.
- Network device 210 includes one or more devices capable of receiving, processing, storing, routing, and/or providing traffic (e.g., a packet, other information or metadata, and/or the like) in a manner described herein.
- network device 210 may include a router, such as a label switching router (LSR), a label edge router (LER), an ingress router, an egress router, a provider router (e.g., a provider edge router, a provider core router, and/or the like), a virtual router, and/or the like.
- LSR label switching router
- LER label edge router
- provider router e.g., a provider edge router, a provider core router, and/or the like
- virtual router e.g., a virtual router, and/or the like.
- network device 210 may include a gateway, a switch, a firewall, a hub, a bridge, a reverse proxy, a server (e.g., a proxy server, a cloud server, a data center server, and/or the like), a load balancer, and/or a similar device.
- network device 210 may be a physical device implemented within a housing, such as a chassis.
- network device 210 may be a virtual device implemented by one or more computer devices of a cloud computing environment or a data center.
- a group of network devices 210 may be a group of data center nodes that are used to route traffic flow through network 220.
- Network 220 includes one or more wired and/or wireless networks.
- network 220 may include a packet switched network, a cellular network (e.g., a fifth generation (5G) network, a fourth generation (4G) network, such as a long-term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the Public Switched Telephone Network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber optic-based network, a cloud computing network, or the like, and/or a combination of these or other types of networks.
- 5G fifth generation
- 4G fourth generation
- LTE long-term evolution
- 3G third generation
- CDMA code division multiple access
- PLMN public land mobile network
- LAN local area network
- the number and arrangement of devices and networks shown in Fig. 2 are provided as an example. In practice, there may be additional devices and/or networks, fewer devices and/or networks, different devices and/or networks, or differently arranged devices and/or networks than those shown in Fig. 2 . Furthermore, two or more devices shown in Fig. 2 may be implemented within a single device, or a single device shown in Fig. 2 may be implemented as multiple, distributed devices. Additionally, or alternatively, a set of devices (e.g., one or more devices) of environment 200 may perform one or more functions described as being performed by another set of devices of environment 200.
- Figs. 3A is a diagram of example components of a device 300.
- Device 300 may correspond to network device 210.
- network device 210 may include one or more devices 300 and/or one or more components of device 300.
- device 300 may include a bus 305, a processor 310, a memory 315, a storage component 320, an input component 325, an output component 330, and a communication interface 335.
- Bus 305 includes a component that permits communication among multiple components of device 300.
- Processor 310 is implemented in hardware, firmware, and/or a combination of hardware and software.
- Processor 310 takes the form of 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), or another type of processing component.
- processor 310 includes one or more processors capable of being programmed to perform a function.
- Memory 315 includes a random access memory (RAM), a read only memory (ROM), and/or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, and/or an optical memory) that stores information and/or instructions for use by processor 310.
- RAM random access memory
- ROM read only memory
- static storage device e.g., a flash memory, a magnetic memory, and/or an optical memory
- Storage component 320 stores information and/or software related to the operation and use of device 300.
- storage component 320 may include a hard disk (e.g., a magnetic disk, an optical disk, and/or a magneto-optic disk), a solid state drive (SSD), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and/or another type of computer-readable medium, along with a corresponding drive.
- Input component 325 includes a component that permits device 300 to receive information, such as via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and/or a microphone). Additionally, or alternatively, input component 325 may include a component for determining location (e.g., a global positioning system (GPS) component) and/or a sensor (e.g., an accelerometer, a gyroscope, an actuator, another type of positional or environmental sensor, and/or the like).
- Output component 330 includes a component that provides output information from device 300 (via, e.g., a display, a speaker, a haptic feedback component, an audio or visual indicator, and/or the like).
- Communication interface 335 includes a transceiver-like component (e.g., a transceiver, a separate receiver, a separate transmitter, and/or the like) that enables device 300 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections.
- Communication interface 335 may permit device 300 to receive information from another device and/or provide information to another device.
- communication interface 335 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, and/or the like.
- RF radio frequency
- USB universal serial bus
- Device 300 may perform one or more processes described herein. Device 300 may perform these processes based on processor 310 executing software instructions stored by a non-transitory computer-readable medium, such as memory 315 and/or storage component 320.
- a memory device includes memory space within a single physical storage device or memory space spread across multiple physical storage devices.
- the software instructions may be contained within a transitory medium, such as a carrier signal or transmission medium.
- Software instructions may be read into memory 315 and/or storage component 320 from another computer-readable medium or from another device via communication interface 335. When executed, software instructions stored in memory 315 and/or storage component 320 may cause processor 310 to perform one or more processes described herein. Additionally, or alternatively, hardware circuitry may be used in place of or in combination with software instructions to perform one or more processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.
- device 300 may include additional components, fewer components, different components, or differently arranged components than those shown in Fig. 3A . Additionally, or alternatively, a set of components (e.g., one or more components) of device 300 may perform one or more functions described as being performed by another set of components of device 300.
- a set of components e.g., one or more components
- Fig. 3B is a diagram of example components of a device 350.
- Device 350 may correspond to network device 210, and/or the like.
- network device 210, and/or the like may include one or more devices 350 and/or one or more components of device 350.
- device 350 may include one or more input components 355-1 through 355-B (B ⁇ 1) (hereinafter referred to collectively as input components 355, and individually as input component 355), a switching component 360, one or more output components 365-1 through 365-C (C ⁇ 1) (hereinafter referred to collectively as output components 365, and individually as output component 365), and a controller 370.
- Input component 355 may be one or more points of attachment for physical links and may be one or more points of entry for incoming traffic, such as packets. Input component 355 may process incoming traffic, such as by performing data link layer encapsulation or decapsulation. In some implementations, input component 355 may transmit and/or receive packets. In some implementations, input component 355 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 350 may include one or more input components 355.
- packet processing components e.g., in the form of integrated circuits
- IFCs interface cards
- packet forwarding components line card controller components
- input ports e.g., processors, memories, and/or input queues.
- device 350 may include one or more input components 355.
- Switching component 360 may interconnect input components 355 with output components 365.
- switching component 360 may be implemented via one or more crossbars, via busses, and/or with shared memories.
- the shared memories may act as temporary buffers to store packets from input components 355 before the packets are eventually scheduled for delivery to output components 365.
- switching component 360 may enable input components 355, output components 365, and/or controller 370 to communicate with one another.
- Output component 365 may store packets and may schedule packets for transmission on output physical links. Output component 365 may support data link layer encapsulation or decapsulation, and/or a variety of higher-level protocols. In some implementations, output component 365 may transmit packets and/or receive packets. In some implementations, output component 365 may include an output line card that includes one or more packet processing components (e.g., in the form of integrated circuits), such as one or more IFCs, packet forwarding components, line card controller components, output ports, processors, memories, and/or output queues. In some implementations, device 350 may include one or more output components 365. In some implementations, input component 355 and output component 365 may be implemented by the same set of components (e.g., and input/output component may be a combination of input component 355 and output component 365).
- Controller 370 includes a processor in the form of, for example, a CPU, a GPU, an APU, a microprocessor, a microcontroller, a DSP, an FPGA, an ASIC, and/or another type of processor.
- the processor is implemented in hardware, firmware, or a combination of hardware and software.
- controller 370 may include one or more processors that can be programmed to perform a function.
- controller 370 may include a RAM, a ROM, and/or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, an optical memory, etc.) that stores information and/or instructions for use by controller 370.
- a RAM random access memory
- ROM read-only memory
- static storage device e.g., a flash memory, a magnetic memory, an optical memory, etc.
- controller 370 may communicate with other devices, networks, and/or systems connected to device 350 to exchange information regarding network topology. Controller 370 may create routing tables based on the network topology information, may create forwarding tables based on the routing tables, and may forward the forwarding tables to input components 355 and/or output components 365. Input components 355 and/or output components 365 may use the forwarding tables to perform route lookups for incoming and/or outgoing packets.
- Controller 370 may perform one or more processes described herein. Controller 370 may perform these processes in response to executing software instructions contained within a computer-readable medium.
- a computer-readable medium may be non-transitory, such as a memory device, or transitory.
- a memory device includes memory space within a single physical storage device or memory space spread across multiple physical storage devices.
- Software instructions may be read into a memory and/or storage component associated with controller 370 from another computer-readable medium or from another device via a communication interface. When executed, software instructions stored in a memory and/or storage component associated with controller 370 may cause controller 370 to perform one or more processes described herein. Additionally, or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.
- device 350 may include additional components, fewer components, different components, or differently arranged components than those shown in Fig. 3B . Additionally, or alternatively, a set of components (e.g., one or more components) of device 350 may perform one or more functions described as being performed by another set of components of device 350.
- Fig. 4 is a flow chart of an example process 400 for continuing a media access control security (MACsec) key agreement (MKA) session upon a network device becoming temporarily unavailable.
- MACsec media access control security
- MKA media access control key agreement
- one or more process blocks of Fig. 4 may be performed by a network device (e.g., network device 210).
- one or more process blocks of Fig. 4 may be performed by another device or a group of devices separate from or including the network device, such as another network device 210, a device in communication with network 220, and/or the like.
- process 400 may include communicating with another network device via a media access control security (MACsec) key agreement (MKA) communication link, wherein an MKA session has been established between the network device and the other network device (block 410).
- the network device e.g., using processor 310, memory 315, storage component 320, input component 325, output component 330, communication interface 335, input component 355, switching component 360, output component 365, controller 370, and/or the like
- MKA media access control security
- an MKA session has been established between the network device and the other network device.
- process 400 may include determining that the other network device is unavailable (block 420).
- the network device e.g., using processor 310, memory 315, storage component 320, input component 325, output component 330, communication interface 335, input component 355, switching component 360, output component 365, controller 370, and/or the like
- process 400 may include causing, based on determining that the other network device is unavailable, an MKA state of the network device to be placed in a paused state (block 430).
- the network device e.g., using processor 310, memory 315, storage component 320, input component 325, output component 330, communication interface 335, input component 355, switching component 360, output component 365, controller 370, and/or the like
- process 400 may include receiving, after causing the MKA state of the network device to be placed in the paused state, a packet from the other network device via the MKA communication link (block 440).
- the network device e.g., using processor 310, memory 315, storage component 320, input component 325, output component 330, communication interface 335, input component 355, switching component 360, output component 365, controller 370, and/or the like
- process 400 may include determining, based on the packet, that the MKA session has not ended (block 450).
- the network device e.g., using processor 310, memory 315, storage component 320, input component 325, output component 330, communication interface 335, input component 355, switching component 360, output component 365, controller 370, and/or the like
- process 400 may include continuing, based on the MKA session having not ended, the MKA session by reactivating the MKA state (block 460).
- the network device e.g., using processor 310, memory 315, storage component 320, input component 325, output component 330, communication interface 335, input component 355, switching component 360, output component 365, controller 370, and/or the like
- Process 400 may include additional implementations, such as any single implementation or any combination of implementations described below and/or in connection with one or more other processes described elsewhere herein.
- determining that the other network device is unavailable comprises: processing a particular packet received from the other network device to determine that the other network device has become unavailable.
- determining that the other network device is unavailable comprises: determining that the network device has not received an MKA packet from the other network device for a length of time.
- causing the MKA state of the network device to be placed in the paused state comprises: causing the network device to suspend transmission of MKA packets associated with the MKA session; causing the network device to suspend a timeout timer associated with the MKA session; causing the network device to store information associated with MKA session in a data structure, and causing the network device to initiate a resume timer associated with the MKA session, wherein the resume timer is configured or negotitated between the network device and the other network device.
- determining that the MKA session has not ended comprises: determining a length of time between causing the MKA state of the network device to be placed in the paused state and receiving the packet from the other network device via the MKA communication link; determining that the length of time does satisfy a threshold; identifying a message identifier of the packet; determining that the message identifier of the packet corresponds to a message identifier of the MKA session at a time when the MKA state was placed in the paused state, and determining, based on determining that the length of time does satisfy the threshold and that the message identifier of the packet corresponds to the message identifier of the MKA session at the time when the MKA session was placed in the paused state, that the MKA session has not ended.
- continuing the MKA session comprises: resuming the MKA session without performing a process for establishing a new MKA session.
- continuing the MKA session comprises: causing the MKA state of the network device to be placed into an active state.
- continuing the MKA session comprises: causing the MKA state of the network device to be placed into an active state, and causing a rekey process to be performed for the MKA session.
- process 400 includes configuring the network device to refrain from terminating an MKA session with the other network device when the other network device is unavailable.
- process 400 may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in Fig. 4 . Additionally, or alternatively, two or more of the blocks of process 400 may be performed in parallel.
- Fig. 5 is a flow chart of an example process 500 for continuing a media access control security (MACsec) key agreement (MKA) session upon a network device becoming temporarily unavailable.
- MACsec media access control security
- MKA media access control key agreement
- one or more process blocks of Fig. 5 may be performed by a network device (e.g., network device 210).
- one or more process blocks of Fig. 5 may be performed by another device or a group of devices separate from or including the network device, such as another network device 210, a device in communication with network 220, and/or the like.
- process 500 may include communicating with another network device via a media access control security (MACsec) key agreement (MKA) communication link, wherein an MKA session has been established between the network device and the other network device (block 510).
- the network device e.g., using processor 310, memory 315, storage component 320, input component 325, output component 330, communication interface 335, input component 355, switching component 360, output component 365, controller 370, and/or the like
- MKA media access control security
- an MKA session has been established between the network device and the other network device.
- process 500 may include causing, based on communicating with the other network device, information associated with an MKA state of the network device and information associated with the MKA session to be stored in a data structure (block 520).
- the network device e.g., using processor 310, memory 315, storage component 320, input component 325, output component 330, communication interface 335, input component 355, switching component 360, output component 365, controller 370, and/or the like
- process 500 may include determining that the network device is to become unavailable at a particular time (block 530).
- the network device e.g., using processor 310, memory 315, storage component 320, input component 325, output component 330, communication interface 335, input component 355, switching component 360, output component 365, controller 370, and/or the like
- process 500 may include sending, to the other network device and based on determining that the network device is to become unavailable at the particular time, a packet indicating that the network device is to become unavailable (block 540).
- the network device e.g., using processor 310, memory 315, storage component 320, input component 325, output component 330, communication interface 335, input component 355, switching component 360, output component 365, controller 370, and/or the like
- process 500 may include determining, after the particular time, that the network device has become available (block 550).
- the network device e.g., using processor 310, memory 315, storage component 320, input component 325, output component 330, communication interface 335, input component 355, switching component 360, output component 365, controller 370, and/or the like
- process 500 may include causing, after determining that the network device has become available, the network device to be updated based on the information associated with the MKA state of the network device and the information associated with the MKA session stored in the data structure (block 560).
- the network device e.g., using processor 310, memory 315, storage component 320, input component 325, output component 330, communication interface 335, input component 355, switching component 360, output component 365, controller 370, and/or the like
- Process 500 may include additional implementations, such as any single implementation or any combination of implementations described below and/or in connection with one or more other processes described elsewhere herein.
- sending the MKA packet to the other network device causes the other network device to place an MKA state of the other network device in a paused state.
- process 500 includes generating, after causing the network device to be updated, an additional MKA packet; and sending the additional MKA packet to the other network device via the MKA communication link.
- sending the additional MKA packet to the other network device causes the other network device to place an MKA state of the other network device in an active state.
- process 500 includes generating, after causing the network device to be updated, an additional MKA packet; sending the additional MKA packet to the other network device via the MKA communication link; receiving, after sending the additional MKA packet to the other network device, a rekey request MKA packet from the other network device; and causing, based on the rekey request MKA packet, a rekey process to be performed for the MKA session.
- process 500 includes generating, after causing the network device to be updated, an additional MKA packet; and sending the additional MKA packet to the other network device via the MKA communication link to cause the other network device to perform a rekey process for the MKA session.
- process 500 may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in Fig. 5 . Additionally, or alternatively, two or more of the blocks of process 500 may be performed in parallel.
- Fig. 6 is a flow chart of an example process 600 for continuing a media access control security (MACsec) key agreement (MKA) session upon a network device becoming temporarily unavailable.
- MACsec media access control security
- MKA media access control key agreement
- one or more process blocks of Fig. 6 may be performed by a network device (e.g., network device 210).
- one or more process blocks of Fig. 6 may be performed by another device or a group of devices separate from or including the network device, such as another network device 210, a device in communication with network 220, and/or the like.
- process 600 may include communicating with another network device via a media access control security (MACsec) key agreement (MKA) communication link, wherein an MKA session has been established between the network device and the other network device (block 610).
- the network device e.g., using processor 310, memory 315, storage component 320, input component 325, output component 330, communication interface 335, input component 355, switching component 360, output component 365, controller 370, and/or the like
- MKA media access control security
- an MKA session has been established between the network device and the other network device.
- process 600 may include causing, based on communicating with the other network device, information associated with an MKA state of the network device and information associated with the MKA session to be stored in a data structure (block 620).
- the network device e.g., using processor 310, memory 315, storage component 320, input component 325, output component 330, communication interface 335, input component 355, switching component 360, output component 365, controller 370, and/or the like
- process 600 may include determining, after causing the information associated with the MKA state of the network device and information associated with the MKA session to be stored in the data structure, that the network device has become available after being temporarily unavailable (block 630).
- the network device e.g., using processor 310, memory 315, storage component 320, input component 325, output component 330, communication interface 335, input component 355, switching component 360, output component 365, controller 370, and/or the like
- process 600 may include causing, after determining that the network device has become available, the network device to be updated based on the information associated with the MKA state of the network device and the information associated with the MKA session stored in the data structure (block 640).
- the network device e.g., using processor 310, memory 315, storage component 320, input component 325, output component 330, communication interface 335, input component 355, switching component 360, output component 365, controller 370, and/or the like
- process 600 may include sending, after causing the network device to be updated, an MKA packet to the other network device via the MKA communication link (block 650).
- the network device e.g., using processor 310, memory 315, storage component 320, input component 325, output component 330, communication interface 335, input component 355, switching component 360, output component 365, controller 370, and/or the like
- process 600 may include determining, based on sending the MKA packet to the other network device via the MKA communication link, that the MKA session has not ended (block 660).
- the network device e.g., using processor 310, memory 315, storage component 320, input component 325, output component 330, communication interface 335, input component 355, switching component 360, output component 365, controller 370, and/or the like
- process 600 may include performing, based on determining that the MKA session has not ended, at least one action (block 670).
- the network device e.g., using processor 310, memory 315, storage component 320, input component 325, output component 330, communication interface 335, input component 355, switching component 360, output component 365, controller 370, and/or the like
- Process 600 may include additional implementations, such as any single implementation or any combination of implementations described below and/or in connection with one or more other processes described elsewhere herein.
- a message identifier of the MKA packet corresponds to a message identifier of the MKA session at a time when the network device became temporarily unavailable.
- process 600 includes determining whether the network device has received one or more packets associated with the MKA session from the other network device via the MKA communication link.
- the network device determined that the MKA session has not ended performing the at least one action includes continuing the MKA session by reactivating the MKA state.
- performing the at least one action includes causing a rekey process to be performed for the MKA session.
- process 600 may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in Fig. 6 . Additionally, or alternatively, two or more of the blocks of process 600 may be performed in parallel.
- component is intended to be broadly construed as hardware, firmware, and/or a combination of hardware and software.
- traffic 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 network packet, a datagram, a segment, a message, a block, a cell, a frame, a subframe, a slot, a symbol, a portion of any of the above, and/or another type of formatted or unformatted unit of data capable of being transmitted via a network.
- PDU protocol data unit
- satisfying a threshold may, depending on the context, refer to a value being greater than the threshold, more than the threshold, higher than the threshold, greater than or equal to the threshold, less than the threshold, fewer than the threshold, lower than the threshold, less than or equal to the threshold, equal to the threshold, or the like.
- a network device may communicate with another network device via a media access control security (MACsec) key agreement (MKA) communication link, wherein an MKA session has been established between the network device and the other network device.
- the network device may determine that the other network device is unavailable.
- the network device may cause, based on determining that the other network device is unavailable, an MKA state of the network device to be placed in a paused state.
- the network device may receive, after causing the MKA state of the network device to be placed in the paused state, a packet from the other network device via the MKA communication link.
- the network device may determine, based on the packet, that the MKA session has not ended.
- the network device may continue, based on the MKA session having not ended, the MKA session by reactivating the MKA state.
- the terms “has,” “have,” “having,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Also, 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 explicitly stated otherwise (e.g., if used in combination with “either” or “only one of').
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Health & Medical Sciences (AREA)
- Cardiology (AREA)
- Health & Medical Sciences (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
- Mobile Radio Communication Systems (AREA)
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/824,028 US11711367B2 (en) | 2020-03-19 | 2020-03-19 | Continuing a media access control security (MACsec) key agreement (MKA) session upon a network device becoming temporarily unavailable |
Publications (2)
Publication Number | Publication Date |
---|---|
EP3883205A1 true EP3883205A1 (fr) | 2021-09-22 |
EP3883205B1 EP3883205B1 (fr) | 2024-06-26 |
Family
ID=70682596
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP20174112.1A Active EP3883205B1 (fr) | 2020-03-19 | 2020-05-12 | Poursuite d'une session d'accord de clé (mka) de sécurité de contrôle d'accès aux médias (macsec) sur un dispositif de réseau devenant temporairement indisponible |
Country Status (3)
Country | Link |
---|---|
US (2) | US11711367B2 (fr) |
EP (1) | EP3883205B1 (fr) |
CN (1) | CN113497822B (fr) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20220311641A1 (en) * | 2021-03-23 | 2022-09-29 | Schweitzer Engineering Laboratories, Inc. | Systems and methods for establishing a secure communication link in an electric power distribution system |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11711367B2 (en) | 2020-03-19 | 2023-07-25 | Juniper Networks, Inc. | Continuing a media access control security (MACsec) key agreement (MKA) session upon a network device becoming temporarily unavailable |
US11997076B2 (en) * | 2020-08-25 | 2024-05-28 | Schweitzer Engineering Laboratories, Inc. | Systems and methods for establishing secure communication in an electric power distribution system |
US11502825B2 (en) * | 2020-11-17 | 2022-11-15 | Schweitzer Engineering Laboratories, Inc. | Systems and methods for using entropy data in an electric power distribution system |
US11722501B2 (en) * | 2021-03-17 | 2023-08-08 | Schweitzer Engineering Laboratories. Inc. | Device management in power systems using media access control security (MACsec) |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20140258532A1 (en) * | 2010-05-25 | 2014-09-11 | Cisco Technology, Inc. | Keep-alive hiatus declaration |
Family Cites Families (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5694537A (en) * | 1995-07-31 | 1997-12-02 | Canon Information Systems, Inc. | Network device which selects a time service provider |
CN101471936B (zh) * | 2007-12-29 | 2012-08-08 | 华为技术有限公司 | 建立ip会话的方法、装置及系统 |
US8719567B2 (en) * | 2009-10-14 | 2014-05-06 | Cisco Technology, Inc. | Enabling QoS for MACsec protected frames |
US20160036813A1 (en) * | 2013-03-15 | 2016-02-04 | Hewlett-Packard Development Company, L.P. | Emulate vlans using macsec |
US10454887B2 (en) * | 2015-11-18 | 2019-10-22 | Cisco Technology, Inc. | Allocation of local MAC addresses to client devices |
US10306468B2 (en) * | 2016-06-29 | 2019-05-28 | T-Mobile Usa, Inc. | Internet protocol multimedia system session resurrection |
CN107769914B (zh) * | 2016-08-17 | 2021-02-12 | 华为技术有限公司 | 保护数据传输安全的方法和网络设备 |
WO2018095256A1 (fr) * | 2016-11-26 | 2018-05-31 | Huawei Technologies Co., Ltd. | Système, procédé et dispositifs permettant une négociation mka entre les dispositifs |
US20180302269A1 (en) * | 2017-04-17 | 2018-10-18 | Hewlett Packard Enterprise Development Lp | Failover in a Media Access Control Security Capable Device |
US20190007302A1 (en) * | 2017-06-29 | 2019-01-03 | Cisco Technology, Inc. | Mechanism for Dual Active Detection Link Monitoring in Virtual Switching System with Hardware Accelerated Fast Hello |
US10469461B1 (en) * | 2017-10-11 | 2019-11-05 | Juniper Networks, Inc. | Securing end-to-end virtual machine traffic |
US10637865B2 (en) * | 2017-10-16 | 2020-04-28 | Juniper Networks, Inc. | Fast heartbeat liveness between packet processing engines using media access control security (MACSEC) communication |
US20190386824A1 (en) * | 2018-06-13 | 2019-12-19 | Hewlett Packard Enterprise Development Lp | Failover in a media access control security capabale device |
US11128663B2 (en) * | 2018-10-16 | 2021-09-21 | Cisco Technology, Inc. | Synchronizing link and event detection mechanisms with a secure session associated with the link |
US11411915B2 (en) * | 2019-01-09 | 2022-08-09 | Cisco Technology, Inc. | Leveraging MACsec key agreement (MKA) state events to trigger fast IGP/EGP convergence on MACsec encrypted links |
US20200358764A1 (en) * | 2019-05-07 | 2020-11-12 | Verizon Patent And Licensing Inc. | System and method for generating symmetric key to implement media access control security check |
US11265301B1 (en) * | 2019-12-09 | 2022-03-01 | Amazon Technologies, Inc. | Distribution of security keys |
US11316869B2 (en) * | 2019-12-10 | 2022-04-26 | Cisco Technology, Inc. | Systems and methods for providing attestation of data integrity |
US11711367B2 (en) | 2020-03-19 | 2023-07-25 | Juniper Networks, Inc. | Continuing a media access control security (MACsec) key agreement (MKA) session upon a network device becoming temporarily unavailable |
-
2020
- 2020-03-19 US US16/824,028 patent/US11711367B2/en active Active
- 2020-05-12 EP EP20174112.1A patent/EP3883205B1/fr active Active
- 2020-05-12 CN CN202010399434.9A patent/CN113497822B/zh active Active
-
2023
- 2023-06-01 US US18/327,408 patent/US12041052B2/en active Active
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20140258532A1 (en) * | 2010-05-25 | 2014-09-11 | Cisco Technology, Inc. | Keep-alive hiatus declaration |
Non-Patent Citations (1)
Title |
---|
"MKA Suspension Brian Weis ; xbx-weis-mka-suspension-0713", IEEE DRAFT; XBX-WEIS-MKA-SUSPENSION-0713, IEEE-SA, PISCATAWAY, NJ USA, vol. 802.1, 14 July 2012 (2012-07-14), pages 1 - 9, XP068008497 * |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20220311641A1 (en) * | 2021-03-23 | 2022-09-29 | Schweitzer Engineering Laboratories, Inc. | Systems and methods for establishing a secure communication link in an electric power distribution system |
US11843479B2 (en) * | 2021-03-23 | 2023-12-12 | Schweitzer Engineering Laboratories, Inc. | Systems and methods for establishing a secure communication link in an electric power distribution system |
Also Published As
Publication number | Publication date |
---|---|
US20210297416A1 (en) | 2021-09-23 |
US11711367B2 (en) | 2023-07-25 |
US20230308445A1 (en) | 2023-09-28 |
CN113497822A (zh) | 2021-10-12 |
US12041052B2 (en) | 2024-07-16 |
CN113497822B (zh) | 2024-08-23 |
EP3883205B1 (fr) | 2024-06-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11316858B2 (en) | Fast heartbeat liveness between packet processing engines using media access control security (MACsec) communication | |
US12041052B2 (en) | Continuing a media access control security (MACSEC) key agreement (MKA) session upon a network device becoming temporarily unavailable | |
CN107682284B (zh) | 发送报文的方法和网络设备 | |
US11115391B2 (en) | Securing end-to-end virtual machine traffic | |
US10581669B2 (en) | Restoring control-plane connectivity with a network management entity | |
CN111953597B (zh) | 链路聚合组(LAG)的支持媒体访问控制安全(MACsec)的链路 | |
US11895228B2 (en) | Pausing a media access control security (MACsec) key agreement (MKA) protocol of an MKA session using a fast heartbeat session | |
EP3599751B1 (fr) | Maintien de tunnels de sécurité de protocole internet | |
US11876800B2 (en) | Monitoring a media access control security session | |
US11140200B1 (en) | Distributing a network policy using connectivity fault management | |
US11902380B1 (en) | Liveness detection for an authenticated client session | |
CN113452664B (zh) | 在网络隧道内建立网络微隧道 | |
US11368294B2 (en) | Facilitating hitless security key rollover using data plane feedback | |
US11570162B1 (en) | Preventing packet loss during timer-based encryption key rollover | |
US11626981B2 (en) | Facilitating hitless security key rollover using data plane feedback | |
US20210385195A1 (en) | Selective transport layer security encryption | |
US11570073B1 (en) | Service status notification | |
CN113452543B (zh) | 多宿主错误配置的检测 | |
US20230083034A1 (en) | Selective transport layer security encryption |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION HAS BEEN PUBLISHED |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE |
|
17P | Request for examination filed |
Effective date: 20220321 |
|
RBV | Designated contracting states (corrected) |
Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: EXAMINATION IS IN PROGRESS |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R079 Ref document number: 602020032859 Country of ref document: DE Free format text: PREVIOUS MAIN CLASS: H04L0029060000 Ipc: H04L0009400000 Ref country code: DE Ref legal event code: R079 Free format text: PREVIOUS MAIN CLASS: H04L0029060000 Ipc: H04L0009400000 |
|
17Q | First examination report despatched |
Effective date: 20231024 |
|
RIC1 | Information provided on ipc code assigned before grant |
Ipc: H04L 69/28 20220101ALI20231125BHEP Ipc: H04L 67/142 20220101ALI20231125BHEP Ipc: H04L 67/14 20220101ALI20231125BHEP Ipc: H04L 67/145 20220101ALI20231125BHEP Ipc: H04L 9/40 20220101AFI20231125BHEP |
|
GRAP | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOSNIGR1 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: GRANT OF PATENT IS INTENDED |
|
INTG | Intention to grant announced |
Effective date: 20240108 |
|
GRAS | Grant fee paid |
Free format text: ORIGINAL CODE: EPIDOSNIGR3 |
|
GRAA | (expected) grant |
Free format text: ORIGINAL CODE: 0009210 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE PATENT HAS BEEN GRANTED |
|
AK | Designated contracting states |
Kind code of ref document: B1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
REG | Reference to a national code |
Ref country code: GB Ref legal event code: FG4D |
|
REG | Reference to a national code |
Ref country code: CH Ref legal event code: EP |
|
P01 | Opt-out of the competence of the unified patent court (upc) registered |
Free format text: CASE NUMBER: APP_39144/2024 Effective date: 20240701 |