KR102643187B1 - Methods and devices for providing cybersecurity in time-aware end-to-end packet flow networks - Google Patents

Abstract

To provide secure communication over an end-to-end data path or a segment of an end-to-end path in a time-critical packet network comprising a plurality of packet engines 61-64 that perform packet processing, a cryptographic engine ( 71-74) is provided separately from the packet engine. Cryptographic engines 71-74 operate to perform at least one cybersecurity function. Cryptographic engine and key manager 44 provides central control over a plurality of cryptographic engines 71-74. A centralized data flow path manager (PFPM) 42 may establish endpoint nodes and intermediate transit nodes of the end-to-end data path of the packet network.

Description

Methods and devices for providing cybersecurity in time-aware end-to-end packet flow networks

The present invention relates to data transmission in packet networks. The invention particularly relates to a method and device for end-to-end and/or segment encryption and/or authentication of data traffic in a protected time-aware packet flow network.

In networks of mission-critical systems, such as monitoring of high-voltage lines or networks of other industrial automation control systems (IACS), many applications still rely on legacy connection-oriented technologies. In higher layer application design, the relationship between sender and receiver can be considered similar to a direct wired data link. When examining applications such as high-speed train steering, air traffic control, or high-voltage line automation, direct deterministic relationships between actors and reactors substantially simplify the upper layers of system design and contribute to today's high overall system reliability.

For various reasons, such as increased flexibility, it may be desirable to perform data transmission over a packet network even for mission-critical networks. In this case, the data integrity inherent in time division multiplexed (TDM) networks may no longer exist. To some extent for non-adversarial environments, Multipath Label Switching Transport Profile (MPLS-TP) allows some of the advantages of the connection-oriented paradigm to be exploited. Nevertheless, during overload situations and malfunctions, the end-to-end data path or link cannot be viewed as a direct wired connection. The powerful manipulation capabilities of packet networks, such as deleting packets from a stream, duplicating packets into a stream, and adding packets to a stream, present a very significant risk with respect to cyberattacks.

With enhanced security, it would be desirable to provide an end-to-end path over a time-critical packet network such as MPLS-TP.

It is an object of the present invention to provide improved methods, devices, and systems for data transmission in packet networks that provide enhanced security. It is a particular object to provide improved methods, devices and systems that operate to provide encrypted and/or authenticated data transmission in time-critical packet networks, while providing high robustness against cyber-attacks.

According to example embodiments, methods and devices are provided for deterministically transiting encrypted and authenticated data packets through complex, meshed network topologies. For such networks, such as Multipath Label Switching Transport Profile (MPLS-TP) networks, a protected end-to-end path and coherent association of each cybersecurity redundant data link endpoint is provided.

For security reasons, the two subsystems - the packet switching subsystem, which is responsible for routing packets through the network, and the cybersecurity (or encryption) subsystem - are strongly separated but may not be synchronized. Dynamic protocols may be used to support limited information exchange from the cybersecurity subsystem to the packet switching subsystem. This ensures that the two subsystems remain synchronized during all standard and exceptional network operating conditions.

In an exemplary embodiment, no packet additions are necessary, and the same delay can be maintained for all packets during the encryption step. A cryptographic engine performing encryption/decryption and/or authentication may add control information to dummy packets previously generated by a packet engine separate from the cryptographic engine. The packet engine may also widen inter-packet gaps if necessary to avoid any disruption that may be caused by the crypto engine requiring insertion of encryption information to encrypt the packets. This strengthens protocols such as Multipath Label Switching (MPLS) or other protocols for time-critical packet transmission to be truly cybersecurity.

In an example embodiment, a protected MPLS-TP end-to-end service setup may be linked with each cybersecurity redundant encryption endpoint, also referred to as a crypto engine. A clear separation of cybersecurity management and MPLS path management and designed restrictions through hardware, which may limit the exchange of information between MPLS and the cybersecurity subsystem, prevents arbitrary intrusion from the client node into the cryptographic engine or other components of the cybersecurity subsystem. can also be avoided.

According to one aspect of the invention, a method is provided for providing secure communication over an end-to-end data path (which may be provided by an MPLS tunnel) in a packet network. A packet network is a time-critical packet network that includes multiple packet engines that perform packet processing. The method includes performing at least one cybersecurity function by a plurality of cryptographic engines, wherein each cryptographic engine of the plurality of cryptographic engines is each associated with a respective packet engine of the plurality of packet engines and Provided separately. At least some of the encryption engines are, respectively, between a respective packet engine associated with an endpoint node of the packet network and a network-facing port of the endpoint node, or between a respective packet engine associated with the endpoint node and a first connected to the endpoint node. Provided between transit nodes. The method further includes centrally controlling the plurality of cryptographic engines by a cryptographic engine and key manager (CEKM).

This method may perform end-to-end encryption and/or authentication, or may be used for encryption and/or authentication along one or several segments of an end-to-end data path.

Controlling the plurality of cryptographic engines may include providing configuration information to the plurality of cryptographic engines and/or coordinating which keys are used by the plurality of cryptographic engines in the network.

By using a central control to coordinate the operation of all crypto engines in the network, and by using crypto engines that are physically separate from the packet engines, high security can be achieved.

The packet engine and associated crypto engine may be provided respectively by a Label Edge Router (LER) or Label Switch Router (LSR) of the MPLS network.

A packet network may include multiple LERs. Each LER may include at least two packet engines and at least four crypto engines. Two packet engines may be provided for each work and protection path, which may be different paths through the MPLS network. Two cryptographic engines may be connected to the first packet engine of the LER to provide end-to-end or segment encryption and/or authentication along the working path over the MPLS network for two opposing transmission directions along the working path. there is. Two additional cryptographic engines may be connected to the second packet engine of the LER to provide end-to-end or segment encryption and/or authentication along the protection path, for two opposing transmission directions along the protection path. .

The method may further include establishing, by a centralized Packet Flow Path Manager (PFPM), endpoint nodes and intermediate transit nodes of the end-to-end data path of the packet network.

PFPM can also configure packet engines in LERs, which are examples of endpoint nodes in an MPLS network.

PFPM can also configure packet engines in LSRs, for example intermediate transit nodes in an MPLS network.

The PFPM may be communicatively connected to all endpoint nodes (e.g., packet engines of every LER) and all intermediate transit nodes (e.g., packet engines of every LSR) of the packet network.

CEKM may run on a first server, and PFPM may run on a second server that is different from the first server. By separating control systems for path control and cybersecurity, additional security benefits are achieved.

The method may further include limiting information provided by the first server to the second server. Additional security advantages are thereby obtained.

The method may further include discovering, by the CEKM, hardware-defined identifiers of the plurality of cryptographic engines and providing, by the CEKM, the hardware-defined identifiers to the PFPM.

CEKM may provide only hardware-defined identifiers and alarms to PFPM. Alarms may also indicate abnormal operating conditions.

CEKM may also receive information about the data flow topology of the end-to-end data path from PFPM to configure multiple cryptographic engines. The information may include tunnel identifiers, MPLS labels or label stacks, and similar information.

CEKM and PFPM can also communicate over a secure channel.

A CEKM may be communicatively connected to each of a plurality of cryptographic engines.

The CEKM may communicate with each of a plurality of cryptographic engines via a secure protocol for notification and/or to configure the cryptographic engine.

The method may further include selecting, by a cryptographic engine of the plurality of cryptographic engines, bits from the data packet using a bit window, where the bit window is programmable. Bits selected according to a programmable bit window may identify data packets to be processed by the cryptographic engine.

The bit window may be different at the entry and exit nodes of the end-to-end data path.

Information exchanged between CEKM and PFPM may be used to configure a bit window.

The method includes configuring, by the CEKM, a first cryptographic engine associated with a first endpoint node of an end-to-end tunnel and a second cryptographic engine associated with the first endpoint node, respectively, based on information from the PFPM. It may include more. The first and second cryptographic engines may perform cybersecurity functions, such as encryption or authentication, respectively, for the protection path and operation of the protection tunnel through the MPLS network.

The method may further include configuring, by the CEKM, a third cryptographic engine associated with the first endpoint node and a fourth cryptographic engine associated with the first endpoint node for a reverse transmission direction on the end-to-end tunnel. there is. The third cryptographic engine and the fourth cryptographic engine may perform cybersecurity functions such as encryption or authentication for the reverse flow direction and the operation and protection path through the MPLS network, respectively.

A packet network may include multiple label edge routers (LERs). The label edge router may include a first crypto engine for the working path of the Multi Label Protocol Switching (MPLS) tunnel and a second crypto engine for the protection path to provide protection for protected tunnels.

The LER may include a third cryptographic engine for the reverse transmission direction on the working path and a fourth cryptographic engine for the reverse transmission direction on the protection path.

LER may include at least two packet engines.

A packet network may include multiple label switch routers (LSRs). An LSR may include at least two packet engines. Each LSR may include at least two crypto engines or at least four crypto engines. A crypto engine may be required for section encryption and one node can work in hybrid LER and LSR mode.

The method involves pre-shaping, by the packet engine, the flow of data packets entering the crypto engine to ensure that the positions of the data packets in the traffic flow remain unchanged and that all packets experience the same delay when passing through the crypto engine. Additional steps may be included.

The flow of data packets may be pre-shaped so that the time stamping information of data packets entering the crypto engine is still valid when the data packets leave the crypto engine.

Pre-shaping the flow of data packets may include widening, by the packet engine, gaps between packets before the flow of data packets enters the encryption engine.

Pre-shaping the flow of data packets may include inserting, by the packet engine, dummy packets into the flow of data packets before the flow of data packets enters the crypto engine. The crypto engine may also use dummy packets to insert control information inside.

Multiple packet engines and multiple cryptographic engines may use common global information entities to ensure global identification of data packets belonging to the same traffic flow.

A global information entity may also represent a Multiprotocol Label Switching (MPLS) path.

Data packets may be encrypted by the crypto engine immediately after leaving the associated packet engine. Data packets may be decrypted by a crypto engine immediately before entering the associated packet engine.

Data packets are transmitted using standardized protocols, particularly those selected from the group consisting of AES, DES, triple-DES, or open protocols, especially selected from the group consisting of Blowfish, Twofish, MARS, RC6, Rijndael, and Serpent. It may be encrypted or decrypted.

The method may further include distributing, by CEKM, a key for encrypting and decrypting the data packet.

Multiple cryptographic engines may perform message authentication.

Message authentication may be performed using standardized protocols based on hash functions, particularly standardized protocols selected from the group consisting of MD5, SHA-1, SHA-2, and SHA-3, or open source protocols.

The method may further include propagating, by the crypto engine, traffic loss information to an interface of an associated packet engine to trigger a traffic diversion.

The step of propagating traffic loss information may be triggered by a failure of an optical data connection detected by a wide area network (WAN) facing line interface.

The method may further include monitoring the health of the data flow.

Monitoring the status of the data flow may include transmitting an additional stream of data packets by the packet engine.

Additional streams of data packets may include monitoring packets that are encrypted by the encryption engine, and/or ping and trace route messages that remain unencrypted.

Each cryptographic engine may each perform cybersecurity functions, such as encryption and/or authentication, without packet addition and without inter-packet gap widening performed by the cryptographic engine.

Multiple packet engines may perform time stamping, for example, on their ports.

The plurality of packet engines may operate within a time stamping context, and the plurality of crypto engines may operate outside the time stamping context of a packet network. By using a cryptographic engine that is not aware of the time stamping protocol, complexity can be reduced.

The crypto engine may operate independently of the time stamping of data packets.

The crypto engine may be a crypto engine that is neither time-aware nor topology-aware.

A packet network may also be an industrial automation control network.

A packet network may be a packet network for automation of high-voltage lines, high-speed train steering, or air traffic control.

CEKM may be a first server that performs cryptographic engine and key management functions.

PFPM may be a second server that performs packet flow path management functions.

According to another aspect of the invention, a cryptographic engine and key manager (CEKM) is provided for securing communications over an end-to-end data path in a time-critical packet network having a packet engine that performs packet processing, the packet network It includes the Packet Flow Path Manager (PFPM), which configures the traffic flow nodes of the packet network. The CEKM has a first interface for receiving information about the data flow topology of the end-to-end data path from the PFPM, and a second interface for providing configuration information to a plurality of separately provided crypto engines, each associated with an individual packet engine. wherein the plurality of cryptographic engines includes the second interface configured to perform at least one cybersecurity function, and at least one processor configured to generate configuration information based on a data flow topology.

CEKM may be configured to discover hardware-defined identifiers of multiple cryptographic engines and provide the hardware-defined identifiers to PFPM.

CEKM may be configured to block transmission of information other than hardware-defined identifiers and alarms to the PFPM.

CEKM may run on a first server that is different from the second server on which PFPM runs.

CEKM may operate to communicate with PFPM over a secure channel.

The CEKM may operate to receive information about the data flow topology of the end-to-end data path from the PFPM to configure multiple cryptographic engines.

A CEKM may be communicatively connected to each of a plurality of cryptographic engines.

The CEKM may be operative to communicate with each one of a plurality of cryptographic engines via a secure protocol for notification and/or to configure the cryptographic engines.

Information exchanged between CEKM and PFPM may be used to configure a bit window.

The CEKM may operate to configure a respective bit window for each crypto engine, where the crypto engine selects bits of a data packet according to a programmable bit window to determine whether the data packet will be processed by the crypto engine. .

CEKM may operate to configure bit windows differently for different cryptographic engines. For illustration purposes, the bit window may be configured differently for the two endpoints of an encrypted end-to-end path.

The CEKM may operate to configure bit windows for multiple cryptographic engines, respectively, based on information received from the PFPM.

The CEKM may operate to configure a first cryptographic engine associated with the first endpoint node of the end-to-end tunnel and a second cryptographic engine associated with the first endpoint node, respectively, based on information from the PFPM. The first and second cryptographic engines may respectively perform cybersecurity functions, such as encryption or authentication, for operation and protection paths over the MPLS network.

The CEKM may be operative to configure a third cryptographic engine associated with the first endpoint node and a fourth cryptographic engine associated with the first endpoint node for a reverse transmission direction on an end-to-end tunnel. The third cryptographic engine and the fourth cryptographic engine may respectively perform cybersecurity functions, such as encryption or authentication, for a reverse flow direction than the first and second cryptographic engines, respectively, for the operation and protection path through the MPLS network. .

CEKM may operate to configure two or four cryptographic engines associated with the second endpoint node of the end-to-end tunnel.

CEKM may operate to distribute keys for encrypting and decrypting data packets to multiple cryptographic engines.

CEKM may be a first server that performs cryptographic engine and key management functions.

According to another embodiment, a cryptographic engine is provided. The crypto engine includes a first interface configured to connect directly to a packet engine that performs packet processing for a time-critical packet network. The cryptographic engine includes a second interface configured to connect to a network-facing port of the endpoint node or a transit node connected to the endpoint node. The cryptographic engine includes a third interface configured to receive configuration information from a cryptographic engine and key manager (CEKM). The cryptographic engine operates to perform cybersecurity functions, such as encryption/decryption and/or authentication, on data packets of traffic flowing through the cryptographic engine without changing the order of the data packets in the traffic flow.

The cryptographic engine may operate to perform cybersecurity functions without packet addition and by maintaining the same delay for all packets.

The cryptographic engine operates to perform security functions without having any information about the topology of the data network (i.e., non-topology-aware) and without using time-stamping information of the data packets (i.e., non-time-aware). You may.

The crypto engine may operate to encrypt the data packet immediately after the data packet leaves the associated packet engine or to decrypt the data packet immediately before entering the associated packet engine.

The crypto engine uses either standardized protocols, particularly those selected from the group consisting of AES, DES, and triple-DES, or open protocols, especially those selected from the group consisting of Blowfish, Twofish, MARS, RC6, Rijndael, and Serpent. It may operate to perform encryption and/or decryption.

The cryptographic engine may operate to perform message authentication. Message authentication may be performed using standardized protocols based on hash functions, particularly standardized protocols selected from the group consisting of MD5, SHA-1, SHA-2, and SHA-3, or open source protocols.

A crypto engine may be operative to propagate traffic loss information to an interface of an associated crypto engine to trigger a traffic diversion.

The cryptographic engine may operate to propagate traffic loss information in response to a failure of an optical data connection detected by a wide area network (WAN) facing line interface.

The first interface of the crypto engine may be connected directly to the packet engine via at least one optical cable or at least one Ethernet cable.

A network according to an aspect of the present invention includes a plurality of packet engines that perform packet processing in a time-critical packet network; a packet flow path manager (PFPM) that operates to provide configuration information to traffic flow nodes in a packet network; A plurality of cryptographic engines according to an embodiment, wherein each cryptographic engine is operative to receive data packets of a traffic flow from an associated packet engine or to provide data packets of a traffic flow to an associated packet engine. ; and a cryptographic engine and key manager (CEKM) according to one embodiment coupled to a PFPM server and a plurality of cryptographic engines.

The network may be a network of industrial automation control systems (IACS).

PFPM may operate to establish endpoint nodes and intermediate transit nodes of the end-to-end data path of the packet network.

PFPM may operate to configure packet engines in LERs, for example endpoint nodes in an MPLS network.

PFPM may operate to configure packet engines in LSRs, for example intermediate transit nodes in an MPLS network.

The PFPM may be communicatively connected to all endpoint nodes (e.g., packet engines of every LER) and all intermediate transit nodes (e.g., packet engines of every LSR) of the packet network.

PFPM may be a second server that performs packet flow path management functions.

CEKM may operate to limit the information provided to PFPM to a plurality of crypto engines and hardware identifiers of alarms.

Each cryptographic engine may operate to select a bit from a data packet using a respective bit window, where the bits selected according to the programmable bit window identify the data packet to be processed by the cryptographic engine.

CEKM may operate to configure a programmable bit window.

The programmable bit window may be different at the entry and exit nodes of the end-to-end data path.

The network may also include label edge routers (LERs). The label edge router may include a first crypto engine for the working path of the Multi Label Protocol Switching (MPLS) tunnel and a second crypto engine for the protection path to provide protection for the working path.

The LER may include a third cryptographic engine for the reverse transmission direction on the working path and a fourth cryptographic engine for the reverse transmission direction on the protection path.

LER may include at least two packet engines.

A packet network may include multiple label switch routers (LSRs). An LSR may include at least two packet engines and at least four crypto engines.

The plurality of packet engines may each be configured to pre-shape the flow of data packets entering the crypto engine to ensure that the positions of the data packets in the traffic flow remain unchanged as they pass through the crypto engine.

The packet engine may operate to pre-shape the flow of data packets such that time stamping information of data packets entering the crypto engine is still valid when the data packets leave the crypto engine.

The packet engine may operate to widen the inter-packet gap before the flow of data packets enters the encryption engine.

The packet engine may operate to insert dummy packets into the flow of data packets before the flow of data packets enters the encryption engine.

The crypto engine may operate to use dummy packets to insert control information therein.

The plurality of packet engines and the plurality of cryptographic engines may operate to ensure global identification of data packets belonging to the same traffic flow using common global information entities.

Global information may also indicate Multiprotocol Label Switching (MPLS) paths.

The network may operate to perform state monitoring of data flows. Monitoring the status of the data flow may include transmitting an additional stream of data packets. Additional streams of data packets may include monitoring packets that are encrypted by the encryption engine, and/or ping and trace route messages that remain unencrypted.

Each cryptographic engine may operate to perform cybersecurity functions, such as encryption and/or authentication, without each packet append and by maintaining the same delay for all packets by the cryptographic engine.

The plurality of packet engines may each operate to perform time stamping, for example, on their ports.

The plurality of packet engines may each operate within a time stamping context, and the plurality of crypto engines may operate outside the time stamping context of the packet network. By using a cryptographic engine that is not aware of the time stamping protocol, complexity can be reduced.

The crypto engine may operate independently of the time stamping of data packets.

The crypto engine may be a time-unaware and topology-unaware crypto engine.

The packet network may also be a network of IACS.

A packet network may be a packet network for automation of high-voltage lines, high-speed train steering, or air traffic control.

According to another embodiment, a PFPM is provided that operates as described in connection with a network.

Methods, devices, and systems for transmission of encrypted and/or authenticated data over complex meshed packet network topologies provide enhanced security for timed networks.

Embodiments of the present invention are not limited thereto, but may also be employed in mission-critical packet networks such as automation of high-voltage lines.

The subject matter of the present invention will be explained in more detail with reference to preferred exemplary embodiments shown in the accompanying drawings.
1 is a schematic representation of a network including a packet engine and a crypto engine according to one embodiment.
Figure 2 is a schematic representation of a network including a packet engine and a crypto engine according to one embodiment.
3 is a block diagram of components of a network according to one embodiment.
4 is a diagram showing data packets before and after an encryption operation.
Figure 5 is a diagram showing data packets before and after encryption and authentication operations.
6 is a block diagram of a label switch router (LSR) including a packet engine and a crypto engine according to embodiments.
7 is a block diagram of a label edge router (LER) including a packet engine and a crypto engine according to embodiments.
Figure 8 is a diagram illustrating label stack encoding that may be used to determine whether a data packet or flow of data packets will be processed.
9 is a schematic diagram of a network including a packet engine and a crypto engine according to one embodiment.
Figure 10 is a block diagram of a cryptographic engine according to one embodiment.
11 is a flow diagram of a method according to one embodiment.
12 is a flow diagram of a method according to one embodiment.

Exemplary embodiments of the present invention will be described with reference to the drawings, wherein identical or similar reference numerals represent identical or similar elements. Although some embodiments will be described in the context of example networks, such as Multiprotocol Label Switching (MPLS) networks or MPLS-Transport Profile (MPLS-TP) networks, the methods and devices detailed below are generally used for meshed, complex packets. It may also be used for transmission of encrypted and authenticated data over a network topology.

Although embodiments will be described in which end-to-end encryption and/or authentication is performed, the techniques disclosed herein may also be used for encryption and/or authentication along segments of an end-to-end path.

In embodiments disclosed herein, both a working path and a protection path may be established to form a two-way protection tunnel. As used herein, RFC 7087, sections 3.42.1 and 3.42.2, entitled “MPLS-TP Rosetta Stone” (December 2013) and “MPLS-TP Survivability Framework” (September 2011). Per RFC 6372 entitled, the term "working path" may refer specifically to a path that carries traffic during normal network operation, and the term "protection path" may specifically refer to a path that carries traffic and protects it when the working path fails. It can also refer to the path being used. Entities such as packets or crypto engines along the work path are work entities according to RFC 7087, section 3.42.1, entitled "MPLS-TP Rosetta Stone" (December 2013). Entities such as packets or crypto engines along the protected path are protected entities according to RFC 7087, section 3.42.2, entitled "MPLS-TP Rosetta Stone" (December 2013).

As used herein, the term “packet” refers to a packetized data structure. As used herein, the term “packet” may include a data frame. A packet may be or contain a data frame.

As described herein, a “cryptographic engine” may be implemented as a cryptographic engine instance. One hardware implementation of a cryptographic engine may provide multiple cryptographic engine instances, for example, instances per port and direction. However, the crypto engine hardware may in some cases be separate from each packet engine.

Unless specifically stated otherwise, features of the embodiments may be combined with each other.

1 is a schematic representation of network 10. Network 10 may include a time-critical packet network. A packet network may have a plurality of nodes (11, 21, 31). A plurality of nodes 11, 21, and 31 may be communicatively coupled via MPLS-TP networks 16, 17, and 18, respectively. The plurality of nodes 11, 21, 31 may include endpoint nodes and intermediate nodes (or hops) of the transmission path. For MPLS-TP networks, endpoint nodes may be label edge routers (LERs) and intermediate nodes may be label switch routers (LSRs). The packet network may be a timing network, with time stamping performed by the packet engine of nodes 11, 21, and 31.

Nodes 11, 21, 31 may include associated packet engines 12, 22, 32 and physically separate packet engines 12, 22, 32 and crypto engines 14, 24, 34, respectively. . Each crypto engine 14, 24, 34 may be coupled directly to an associated packet engine 12, 22, 32, for example via an Ethernet cable or optical cable. Opposite ends of the Ethernet cable or optical cable may be attached directly to the packet engine 12, 22, 32 and the crypto engine 14, 24, 34.

As used herein, the term “cryptographic engine” refers to a device that operates to perform encryption/decryption and/or authentication operations. The cryptographic engine may optionally have dedicated components such as a physical random number generator to perform encryption/decryption and/or authentication operations.

It will be appreciated that each cryptographic engine hardware 14, 24, 34 may have multiple cryptographic engine instances, which may correspond to different ports and packet flow directions on different ports or individual nodes.

As used herein, the term “packet engine” refers to a device that operates to perform packet processing. The packet engine may include a packet switch and may insert dummy packets into the flow of data packets. The packet engine is time aware and may operate to perform time stamping at the ingress or egress port of the packet engine.

As used herein, the statement that an entity is disposed between two other entities (e.g., a crypto engine placed between a packet engine and a transit node) refers to the arrangement along the data flow path, i.e., the packet is placed between the entities. Describe the order of passage.

Each packet engine 12, 22, 32 may have a plurality of ports 13, 23, 33 respectively. Each crypto engine 14, 24, 34 may have a plurality of ports 15, 25, 35 respectively. The ingress port of the crypto engine 14, 24, 34 may be connected to the egress port of the associated packet engine 12, 22, 32, respectively. The ingress port of the crypto engine 14, 24, 34 may be connected to the egress port of the associated packet engine 12, 22, 32, respectively. Each cryptographic engine 14, 24, 34 may be coupled to an associated packet engine 12, 22, 32 via an unencrypted link.

Different cryptographic engines 14, 24, 34 may transmit data traffic over an encrypted path, for example over an MPLS-TP network.

Packet engines 12, 22, and 32 are each responsible for packet processing. Packet engines 12, 22, and 32 may be responsible for packet forwarding and individual switching. All packet processing, filtering and queuing are performed in packet engines 12, 22 and 32.

Cryptographic engines 14, 24, 34 perform encryption and/or authentication operations. It will be understood that the term “encryption operations” as used herein generally includes operations associated with encrypted transmission, and therefore may also include decryption at the receiving endpoint of the secure end-to-end path.

Cryptographic engines 14, 24, 34 may each have dedicated components, such as physical random number generators, to perform encryption/decryption and/or authentication operations.

As described in more detail below, packet engines 12, 22, 32 and crypto engines 14, 24, 34 transmit encrypted and/or authenticated data over a complex meshed packet network topology while: Operates to provide end-to-end or segment encryption and/or authentication.

Packet engines 12, 22, 32 may be controlled by a central control, for example a packet flow path manager (PFPM) 42. Cryptographic engines 14, 24, 34 may be controlled by a cryptographic engine and key manager (CEKM) 44. The functions of PFPM (42) and CEKM (44) may be performed on separate servers to enhance security. PFPM 42 may configure the packet engine to establish MLPS paths. CEKM 44 may configure a cryptographic engine using information about the path set by PFPM 42. Cryptographic engines 14, 24, 34 may ensure end-to-end or segment encryption and/or authentication, respectively, for the path through the network. CEKM 44 may be communicatively coupled to all crypto engines 14, 24, 34, such as via a secure channel.

The first subsystem formed by PFPM 42 and a plurality of packet engines 12, 22, 32 is responsible for packet processing, for example by establishing flow paths. A second subsystem formed by the CEKM 44 and a plurality of cryptographic engines 14, 24, 34 is responsible for cybersecurity functions. The first management network of the first subsystem connecting the PFPM 42 and the plurality of packet engines 12, 22, 32 is the second management network connecting the CEKM 44 and the plurality of crypto engines 14, 24, 34. It may also be separate from the second management network of the subsystem.

By using network wide, central coordination of multiple cryptographic engines 14, 24, 34 in the network, end-to-end or segment tunnel payload encryption and/or authentication can be realized.

By using crypto engines 14, 24, 34 provided as separate devices from each associated packet engine 12, 22, 32, crypto engines 14, 24, 34 are the devices responsible for time stamping and switching. It is provided separately. The cryptographic engine 14, 24, 34 need not be aware of the topology of the network and/or the end-to-end paths established therein. Cryptographic engines 14, 24, 34 do not need to be aware of any time stamping protocol. Unauthorized intrusion can also be prevented at the hardware level.

Because PFPM (42) and CEKM (44) run on separate servers and use separate management networks, security can be enhanced.

2 is a block diagram representation of network 10. Network 10 includes PFPM 42 and CEKM 44, which may run on different servers.

Packet networks may use MPLS-TP as a data network technology. The packet network may include label edge routers (LERs) 53, 54 connected to client nodes 51, 52, respectively. LERs 53, 54 are the endpoints of an encrypted end-to-end tunnel. The packet network may include label switch routers (LSRs) 55, 56, 57, 58. A working path may be established between LERs 53, 54 via LSRs 55, 56. Different protection paths may be established between LERs 53, 54 via LSRs 57, 58. Protection paths are detailed in, for example, RFC 6372, titled "MPLS-TP Survivability Framework" (September 2011), and RFC 7087, sections 3.42.1 and 3.42.2, titled "MPLS-TP Rosetta Stone" (December 2013). As described, redundancy for data transmissions may be provided to protect the working path.

LER 53, the endpoint node of the end-to-end path to be secured, includes at least one packet engine (PE) and at least one crypto engine (CE). As described, LER 53 may include at least two packet engines 61, 62. LER 53 may include two cryptographic engines 71, 72 or more than two cryptographic engines. Although only two cryptographic engines 71 and 72 are shown in FIG. 2, LER 53 may include at least four cryptographic engines as will be described in more detail with reference to FIG. 7.

LER 54, another endpoint node in the end-to-end path to be secured, includes at least one packet engine (PE) and at least one crypto engine (CE). As described, LER 54 may include at least two packet engines 63, 64. LER 53 may include two cryptographic engines 73, 74 or more than two cryptographic engines. Although only two cryptographic engines 73 and 74 are shown in Figure 2, LER 54 can support at least four cryptographic engines (at least some of which may be cryptographic engine instances), as will be explained in more detail with reference to Figure 7. ) may also include.

Each LSR 55, 56, 57, 58 may each include at least one packet engine and at least one crypto engine. Each LSR 55, 56, 57, 58 may include at least two packet engines and at least four cryptographic engines, as described in more detail with reference to FIG. 6.

In operation, PFPM 42 may configure the packet engines of the endpoint nodes and intermediate nodes of the packet network. The crypto engine does not need to be topology aware. Rather, CEKM 44 can detect the hardware identifiers of all cryptographic engines and provide the hardware identifiers to PFPM 42. PFPM (42) can provide information related to the configuration path to CEKM (44). CEKM (44) can use information about the configuration path when configuring the crypto engine.

The cryptographic engines 71 and 72 of the endpoint node 53 are disposed within the endpoint node 53, between each packet engine 61 and 62 and the network-facing interface of the endpoint node 53. A crypto engine 71, 72 may generally be provided between the packet engine 61, 62 and a first intermediate node (referred to as the first hop for MPLS-TP) 55, 57. Similarly, the cryptographic engines 73, 74 of the endpoint node 54 are disposed within the endpoint node 54, between each packet engine 63, 64 and the network-facing interface of the endpoint node 54. do. A crypto engine 73, 74 may generally be provided between the packet engine 63, 64 and a first intermediate node (referred to as the first hop for MPLS-TP) 56, 58. The first intermediate node or first hop is the node closest to the endpoint node along the work path or protection path, respectively.

Time stamping is performed by packet engines 61, 62, 63, 64. For illustration, ports of packet engines 61, 62, 63, 64 connected to crypto engines 71, 72, 73, 74 may perform time stamping according to Precision Time Protocol (PTP), IEEE 15888. .

Timed (e.g., utilizing PTP), protected, and deterministic packet networks (such as MPLS), through utilizing central control and network-wide coordination of additional cryptographic engines (71, 72, 73, 74). Can be enhanced through cybersecurity features such as end-to-end traffic encryption and/or packet authentication. The cipher engines (71, 72, 73, 74) may not be topology-aware and time-aware, and between packet engines (61, 62, 63, 64) and the next hop, thus (MPSL, e.g. LER (54) ) outside the timestamping context between the endpoint node of the packet flow (for MPLS, e.g. LSR 56, 58), or between the packet engine and the network-facing port. It may also be located inside the endpoint nodes (53, 54).

To ensure the integrity and authentication of data transmission in a packet network, frame data is encrypted and/or authenticated by a crypto engine 71, 72, 73, 74. As a result, major portions of packets in the data stream may be replaced with their encrypted and/or authenticated counterparts. Encryption/authentication is separate from the packet engine (61, 62, 63, 64) and is performed in the encryption engine (71, 72, 73, 74), which is responsible for packet forwarding and each switching. All packet processing, filtering and queuing may be performed in packet engines 61, 62, 63, 64, which may also perform time stamping of PTP packets establishing the correct time/clock on all nodes as the end result. . Cryptographic engines 71, 72, 73, and 74 may each be connected to a network-facing port on the central card and then connected to the network on their own.

To maximize security, interaction between the cybersecurity subsystem 44, 71, 72, 73, 74 and the packet network subsystem 42, 61, 62, 63, 64 may be reduced. The only information available to the packet network subsystems 42, 61, 62, 63, 64 regarding the cryptographic engines 71, 72, 73, 74 is unit inventory information such as hardware defined identifiers and optionally abnormal operating conditions. It may be limited to alarms that indicate . Only the MPLS label, tunnel ID and encryption profile-id are provided by the PFPM 42 to the CEKM 44 in the direction through the engine, tunnel and secure link, such as a secure SSH link.

In operation, the initial MPLS label is set by the LER 54, which may also be referred to as the provider edge router. This labeled packet can cause the port to be attached to a cryptographic engine 73, 74 that functions as a cryptographic endpoint. Subsequent hops from LSR to LSR forward the packet.

The cryptographic engines of the intermediate transit nodes, i.e. LSRs 55, 56, 57, 58, decrypt the encrypted data packets output by the cryptographic engines of LERs 53, 54 when end-to-end encryption is performed. Alternatively, it is configured by CEKM (44) not to perform encryption. For example, the crypto engine of intermediate hops, or LSRs 55, 56, 57, 58, may have a lookup table that identifies the path along which encryption/decryption will be performed. The lookup table of the intermediate hops is constructed by CEKM 44 such that when end-to-end encryption is provided, the path of the MPLS end-to-end tunnel that only passes through the LSR does not trigger decryption or encryption.

As described in more detail below, the crypto engine may select bits from a data packet according to a programmable bit window to determine whether each data packet will be processed. A programmable bit window may be configured by CEKM 42. The lookup table of the crypto engine of the intermediate hops, i.e. LSRs 55, 56, 57, 58, may be set so that no decryption or encryption is triggered until the final hop is reached.

If encryption is to be performed only on segments of the end-to-end path, LSRs 55, 56, 57, 58 may also be programmed so that decryption can be performed at the end of the segment.

When the data packet reaches the final hop, that is, the encryption engine of LER (53, 54), the search for decryption is successful. The packet is decrypted and transmitted to the packet engine of the LER router. To allow cryptographic engines 71, 72 to decrypt data packets belonging to a particular tunnel, CEKM 44 causes cryptographic engines 71, 72 to decrypt the data packets of each tunnel terminating at endpoint node 53. It can also be configured to have lookup table information that allows

At the intermediate nodes, namely LSRs 55, 56, 57, 58, the configuration of the cryptographic engine ensures that the payload remains untouched. L2-MAC addresses, next hop MPLS label, TTL field and FCS field will be explained in more detail with reference to Figures 4 and 5 and are the only information that changes.

A protected MPLS tunnel with a working path and a protection path is handled as two encrypted connections. For each MPLS tunnel pair, there are four crypto engines that act as endpoints for the secure tunnel. Four cryptographic engines are identified and remain synchronized between the cybersecurity subsystem (44, 71, 72, 73, 74) and the packet network subsystem (42, 61, 62, 63, 64).

The operations of PFPM 42, CEKM 44, packet engine, and crypto engine will be described in more detail with reference to FIGS. 3 to 12.

Figure 3 is a schematic block diagram of the components of the network.

PFPM 42 may be an MPLS Path Manager (MPM). PFPM 42 may be implemented by software or other computer-readable instruction code executing on a second server. PFPM 42 may include a topology, path, and password profile manager 45. PFPM 42 may include operation and maintenance and device monitoring module 46.

The centralized PFPM 42 establishes data traffic endpoints 53, 54 along with intermediate transit points 55, 56, 57, 58. PFPM 42 may be connected for configuration and/or notification to control all nodes in the network.

To handle packet forwarding, PFPM 42:

- MPLS label to VLAN tag mapping via attachment circuitry, internal/external label setup/mapping to network end-to-end tunnels, data forwarding and termination parameters such as class of service identifier, and

- Individual network topology information such as tunnels, pseudo wires, virtual private networks

You may also have an information model for .

CEKM 44 may communicate with any crypto engine via a secure protocol for configuration and/or notification. The necessary information 112 regarding the data flow topology required for the configuration of the cryptographic engine is provided to the CEKM 44 by the PFPM 42.

CEKM 44 may include a master key generator 47, a key manager 48, and a path endpoint manager 49. CEKM 44 may retain and manage each encryption endpoint information:

- Master key used to generate session keys.

- Label information used to identify packets to which a session key should be applied.

- Engine id identifies the engine to which the above information should be applied.

In normal use, that is, when the network is set up and no maintenance or testing is performed, users do not access the CEKM 44. Users accessing PFPM 42 will not access any protected information in the cybersecurity subsystem, increasing the overall security and robustness of the solution.

The LER may include a plurality of packet engines, e.g., a first packet engine 63 for the working (w) path 117 and a second packet engine 64 for the protection (p) path 118. It may be possible. Packet engines 63, 64 may include ports 83, 87 connected to associated crypto engines 73, 74, respectively. Ports 83, 87 may be operable to perform time stamping. Ports 83, 87 may be IEEE 15888 recognized to perform time stamping according to PTP.

Packet engines 63 and 64 may include packet switches 82 and 86, respectively. Packet switches 82, 86 may be operative to perform pre-shaping of the flow of data packets. Preshaping is to ensure that the crypto engine 73, 74 can grow data packets with inter-packet gaps and thus maintain the same delay for all packets without changing the packet order by the crypto engine 73, 74. This may include widening the gap between packets. Preshaping may include generating dummy packets that are inserted into the flow of data packets output to the crypto engine 73, 74. The dummy packet may have empty sections, which may be filled with control information by the crypto engine 73, 74. This allows management channel information to be transmitted by the cryptographic engines 73, 74 without the need to generate additional packets by the cryptographic engines 73, 74.

The packet engine's central processing unit 81 not only operates as a dummy packet controller (DPC), but may also perform additional functions such as software configuration management (SCM), operations and maintenance (OAM), and path controller, respectively.

The central control 60 of the LER may perform control and/or management functions for a plurality of packet engines based on packet engine (PE) configuration information 113 received from each PFPM 42. Central control 60 may provide packet engine (PE) notifications 114 to PFPM 42. Central control 60 may pass PE configuration information 113 to CPUs 81, 85, for use in path control and/or dummy packet generation, for example.

Cryptographic engines 73, 74 for the working and protection paths may include ports 94, 104 directly connected to the packet engine and network-facing ports 97, 107, respectively. Cryptographic engines 73, 74 may include components for encryption 95, 105 and/or decryption 96, 106 and/or components for authentication, respectively. Cryptographic engines 73, 74 may each include a physical random number generator 91, which may be a quantum random number generator (QRNG). Cryptographic engines 73, 74 may each include a key storage element 92. Cryptographic engines 73 and 74 may each include an identifier storage element 93 that stores a hardware identifier, such as a board-id, that is unique in the network for each cryptographic engine.

Cryptographic engines 73, 74 may use programmable bit windows to select bits from data packets. This mechanism can identify data packets from the traffic flow to be processed by the crypto engine. The crypto engine may use a lookup table and compare selected bits to information in the lookup table to determine whether a data packet will be processed.

At network entry, packets with the same identifier will be encrypted/authenticated with the same key and/or process to belong to the same data flow. In MPLS, these data flows are called bidirectional label switched path pairs. Upon termination, traffic will be decrypted/identified based on the same mechanism. Typically, the flow identifier may change at every hop. In MPLS, MPLS labels can change at every hop. Therefore, the bit window and window content should be considered different upon entry or exit. PFPM 42 and CEKM 44 ensure this by supplying appropriate entry and exit identifiers and, optionally, auxiliary information 112 to the CEKM 44 function.

MPLS packets are sent from the packet engine 63. Data packets are transmitted to crypto engine 73 via data link 117. By observing predefined sections of packets and finding patterns in a local lookup table, crypto engine 73 obtains the necessary keys and auxiliary information to perform encryption and/or authentication. If the lookup fails, the data packet remains untouched. At the remote end, the crypto engine (currently in decryption mode) checks the packet against a lookup table to obtain an individual key to decrypt the data packet.

Data packets with the same bit vector (e.g., the same board identifier) in the same engine are encrypted using the same key and therefore belong to the same data flow. In MPLS, these data flows are called bidirectional label-switched paths that may belong to protected tunnels. The tunnel-identifier (tunnel-id) globally identifies the MPLS tunnel and encrypted connection.

The bit pattern for cryptographic search may include a top of the stack label (path identifier) and additional bits (top of stack TTL value, bottom of stack label). This may prevent matches for OAM packets addressing intermediate hops. In this way, OAM packets that should not be encrypted, such as trace routes, are guaranteed to remain unencrypted at intermediate hops.

The bit pattern for decryption search includes a top-of-stack label (path identifier) and additional bits (top-of-stack S-bit, bottom-of-stack label) to distinguish encrypted packets from unencrypted OAM packets, e.g., traceroute. You may.

An example of label stack encoding will be described in more detail with reference to FIG. 8 below.

CEKM (44) and PFPM (42) exchange information through secure channels (111, 112). The information may also be used to set bit windows in content and location. For one protected tunnel, PFPM 42 may configure entry/encryption and exit/decryption engines for the working and protection paths, respectively. This must be done for each traffic direction. If the same crypto engine handles both directions, two crypto engines must be configured on the endpoint node for each bidirectional tunnel pair. If separate crypto engines are provided for two directions, four crypto engines must be configured on one endpoint node for each bidirectional tunnel pair. Notification interface 111 provides alarm, or fault, and inventory information from CEKM 44 to PFPM 42.

The two information models in PFPM (42) and CEKM (44) are minimally configured for each cryptographic engine, from PFPM (42) to CEKM (44), via configuration interface (112) and alarm/notification interface (111). Maintain consistency by transmitting data. When the PFPM 42 performs MPLS path management, the MPLS-tunnel is prepared with all necessary information for the endpoint nodes and/or intermediate transit nodes. This can also be triggered by the end user when specifying an endpoint. Only after receiving a positive acknowledgment from CEKM 44, PFPM 42 applies the route in the packet engine.

To establish coherent operation in the attached cryptographic engine, PFPM 42 may perform the following steps to control the flow to establish an encrypted end-to-end path:

- Once the user sets up a protection tunnel in PFPM by selecting an endpoint and specifying an encryption profile and intermediate hop limits, the system automatically routes the initially simulated tasks and protection paths centrally. Thereby, endpoints are identified.

- For protected tunnels, PFPM 42 provides the necessary information to configure the entry/encryption and exit/decryption engines for the working and protection paths. This must be done for each traffic direction. On each endpoint node, four engines may be configured twice for each of the two directions. Even though the data flow is encrypted within the MPLS-TP tunnel, the unencrypted external labels change at every hop. The tunnel-id may be used as a global identifier of the tunnel both by the PFPM 42 and the packet engine on the one hand and the CEKM 44 and the crypto engine on the other.

The following steps may be performed:

○ Step A: To configure all crypto engines for one path of the protected tunnel, the following tuples are exchanged between PFPM (42) and CEKM (44): Global engine address (i.e. hardware definition of the crypto engine) identifier); tunnel-id; MPLS label; direction; and profile-id. The profile-id may identify a set of auxiliary information, such as the type of traffic that should remain untouched.

○ Step B: Upon verification of successful application of the configuration of the cryptographic engine, pre-shaping parameter configuration may be applied to the packet engine to ensure proper timing and sequencing of packet flows.

○ Step C: After receiving positive confirmation from CEKM 44 that the configuration is successfully applied, PFPM 42 sets up the route by applying the configuration to the packet engine; If a positive confirmation is not received, the simulation of PFPM 42 may be rolled back and the configuration will not be applied.

- Taking down a path involves the same acknowledgment, now the path will be taken down in reverse order from step C to step A.

As the data flow is encrypted within an end-to-end context (in a tunnel called MPLS-TP), the label changes at every hop. Special global information entities are used for end-to-end or segment encryption or cybersecurity connectivity with both the PFPM and its connected packet engines and the CEKM and individual cryptographic engines. In MPLS, a global information entity that may be used by both the security domain and the operational/user domain may identify a tunnel. This ensures global identification across hops, implies encryption or cybersecurity topology, and MPLS topology.

PFPM 42 may hold information about data services, pseudo wires and tunnels along with label switched paths. By adding or subtracting MPLS services, items in the network information model may change and must remain consistent with the packet engine and crypto engine. The network information model can be kept consistent with the packet engine directly via data link 113. The network information model can be kept consistent with individual cryptographic engines through CEKM (44).

For illustration purposes, CEKM 44 will ensure that the appropriate key is used for the identified MPLS bi-directional tunnel at both ends for encryption/decryption. CEKM (44) can also discover all engines via hardware-defined board-id. This is the only information about the cryptographic engines available in both PFPM (42) and CEKM (44). The board-id or other hardware defined identifier is unique on the network and identifies the network wide to the individual crypto engine. The tunnel-id, established during setup of an end-to-end bidirectional tunnel, is an identifier for the end-to-end connection to both the cybersecurity subsystem (CEKM and Crypto Engine) and the packet flow subsystem (PFPM and Packet Engine). plays the role of By providing the global engine address (board-id) and tunnel-id, and MPLS labels per direction to the CEKM 44, the PFPM 42 enables and Encryption can also be controlled without interference. The exchange of board-id, tunnel-id, MPLS label and direction, together with the profile-id selecting one of a set of predefined engine parameters, completely determines the behavior of the cybersecurity subsystem (i.e. CEKM and crypto engine) .

Key distribution and other necessary configuration information 115 is distributed to the CEKM 44 to each cryptographic engine 73, 74 for a working or protection path after CEKM 44 receives topology information from the path management function via interface 112. (44) may also be provided by.

This allows coherent processing of MPLS-TP and crypto engine operations. CEKM and PFPM each operate centrally, but the management of the crypto engine is decoupled from that of the packet engine.

Taking high availability requirements into account, two cryptographic engines 73, 74 may be provided, with the first cryptographic engine 73 used in the working path and the second cryptographic engine 74 used in the protection path of the protected tunnel pair. It is used. Two interfaces may connect to each central card, and two interfaces may connect to the aggregation layer of the network. Via dedicated logical links 115, 116, cryptographic engines 73, 74 connect to CEKM 44, potentially in tandem with PFPM 42. A front interface per engine can also be performed for initial bringing up.

Packets are either encrypted in the crypto engine 73, 74 immediately after leaving the packet engine 63, 64, or decrypted in the crypto engine 73, 74 just before entering the packet engine 63, 64. Encryption and decryption may be performed via standardized encryption/decryption protocols such as AES, DES or Triple-DES, or open protocols such as Blowfish, Twofish, MARS, RC6, Rijndael und Serpent. Hash-based message authentication is performed using standardized protocols that use hash functions such as MD5, SHA-1, SHA-2, SHA-3, or their open source counterparts.

To implement a wire-speed encrypted data path, a wire-speed crypto engine 73, 74 that does not interfere with the timing or order of incoming packets may, for example, use AES 128/256-bit encryption for each individual data packet and Decryption may also be provided.

To perform packet encryption/decryption, keys may be distributed by CEKM 44 to crypto engines 73, 74 via interface 115. Notification of inventory, alarms and failures may be performed via interface 116 from the crypto engine to CEKM 44.

CEKM 44 may maintain a list of managed cryptographic engines. CEKM 44 may schedule updates of the master key at configurable intervals. The master key may be generated by CEKM 44.

Generation of keys and/or distribution of keys by CEKM 44 may be performed using conventional mechanisms.

Cryptographic engine activity, alarms and notifications may be collected by CEKM 44 and forwarded to PFPM 42.

Failure of the optical data connection detected by the WAN facing line interface of the crypto engine for the working or protection path may be propagated to the respective node facing interfaces 94, 104. This propagates traffic loss information to interfaces 83 and 87 of packet engines 63 and 64. Packet engines 63, 64 may trigger traffic switching when receiving a link loss signal.

Loss of signal may be detected by a Small Form Pluggable (SFP) device implementing a WAN-facing line interface, and may be signaled to the crypto engine 73, 74 via a physical input signal. Matching paths 117, 118 towards packet engines 63, 64 may be identified, and corresponding SPF devices may be instructed to switch off the transmit signal via a dedicated physical signal.

To monitor the status of the data flow, additional streams of packets may be transmitted. Additional streams of packets may be transmitted alongside the data traffic. Two options are available:

- End-to-end monitoring packets are encrypted like other payloads and therefore share the same process. In particular, these encrypted monitoring packets may be processed like regular data packets.

- On the other hand, ping and trace route messages are left unencrypted as intermediate hops may present problems.

The two options described above can be identified by the cryptographic engine using a suitably configured bit window mechanism, as described previously. In the case of MPLS, the pseudo wire id can be identified and the “time to live” byte can be read. This predefined value or range of TTL bytes may be used to distinguish between two usage options: end-to-end monitoring packets to be encrypted/decrypted and ping and trace route messages to remain unencrypted.

In MPLS-TP, additional streams of OAM/Bidirectional Forwarding Detection (BFD) monitoring packets may be sent at regular intervals to perform continuity checks. These packets are encrypted like any other payload and therefore share the same process. Other OAM packets, such as ping and trace route messages, serve as a detection mechanism for failure of intermediate nodes and remain unencrypted, allowing intermediate points to signal their availability.

OAM messages are identified by cryptographic engines 73, 74 with an appropriately configured bit window mechanism as described above. The bit window mechanism can also look for label (13) (bottom of the stack label). By setting a specific TTL value or range, individual "debugging modes" can be distinguished from the modes of "continuity checking", and the crypto engine can thus know whether the OAM packet will be encrypted or not.

Cryptographic engines 73, 74 may be neither topology aware nor time aware. The cryptographic engine 73, 74 does not need to have any knowledge of the path being established. Cryptographic engines 73, 74 do not need to have any knowledge of time stamping information and/or any time stamping protocol. To ensure that the packet order and relative timing are not affected by the cybersecurity function(s) performed by the crypto engine 73, 74, traffic leaves the packet engine 63, 64 and enters the crypto engine 73, 74. It may be pre-molded before entering. This allows packets to be uninterrupted in their position in the data flow compared to their position before entering the crypto engine. This ensures that the timestamping of the packet on ports (83, 87) is still valid when passing through the crypto engine (73, 74).

When the crypto engine 73, 74 performs encryption, a sequence number is added to each data packet, increasing the length by, for example, 8 bytes, as will be explained with reference to Figure 4. When the cryptographic engines 73, 74 perform authentication, an additional 16 bytes for the message authentication code are added, as explained with reference to Figure 5. To ensure that there is no change in packet flow, packet engines 63, 64 keep the number of bytes in the inter-packet gap sufficiently large. This compensates for the increase in packet length required when bytes are added to the packet by the crypto engine 73, 74. Preshaping may be performed by the packet engine 63, 64, such that the order and relative timing of packets are changed by the crypto engine 73, 74, which is not time-aware and is placed outside of the timestamping context of the network. eliminate the risk of

4 and 5 illustrate the operation of the cryptographic engines 73 and 74 when performing encryption and/or authentication operations on data packets 120 received from the packet engines 63 and 64. The packet engines 63, 64 enlarge the inter-packet gap 129 to a value of, for example, 36 bytes. Data packet 120 may be an unencrypted MPSL data packet. Data packet 120 may include a preamble and a start frame delimiter (SFD) 121. Data packet 120 may include a destination media access control (MAC) address 122. Data packet 120 may include a source address media access control (MAC) address 123. Data packet 120 may include an MPLS Label Switched Path (MPLS LSP) 124. Data packet 120 may include an MPLS Pseudo-Wire (MPLS PW) 125. Data packet 120 includes an unencrypted pseudo-wire payload 126. Data packet 120 may include a Frame Check Sequence (FCS) 127.

4 shows an encrypted data packet 130, which results from the encryption operations of the cryptographic engines 73 and 74 when applied to the data packet 120. An encryption code 131 may be added to the encrypted data packet 130. Encrypted data packet 130 includes an encrypted payload 132 that may be generated from an MPLS PW 125 and a PW payload 126. Encrypted payload 132 may define encrypted service data.

Encryption causes the encrypted data packet 130 to have a size that exceeds the size of its unencrypted counterpart 120. However, the inter-packet gap 129 is adjusted so that the increase in size of the encrypted data packet 130 relative to the unencrypted data packet 120 does not exceed the expanded inter-packet gap 129, and the packet engines 63, 64 ) is expanded by . Cryptographic engines 63, 64 grow data packets into the enlarged interpacket gap 129, but not beyond it. A finite interpacket gap 138 may remain between successive encrypted data packets. For illustration, interpacket gap 138 may have 28 bytes when encryption code 131 has 8 bytes.

5 shows an encrypted data packet 135 with authentication, which results from the encryption and authentication operations of the cryptographic engines 73 and 74 when applied to the data packet 120. Encrypted data packet 135 may include an authentication code 133. Encrypted payload 132 and authentication code 133 may define encrypted service data.

Encryption and authentication, together with authentication, cause the encrypted data packet 135 to have a size that exceeds the size of its unencrypted counterpart 120. However, the inter-packet gap 129 is controlled by the packet engine ( 63, 64). Cryptographic engines 63, 64 grow data packets into the enlarged interpacket gap 129, but not beyond it. With authentication, a finite interpacket gap 139 may remain between successive encrypted data packets. For illustration purposes, interpacket gap 139 may have 12 bytes when authentication code 133 has 16 bytes.

In addition to increasing the inter-packet gap size, packet engines 63, 64 may generate dummy packets and insert dummy packets into the flow of data packets provided to crypto engines 73, 74. The crypto engine 73, 74 may use dummy packets to insert control information therein. This eliminates the need for the crypto engine 73, 74 to create new packets and insert them into the traffic. Rather, existing dummy packets generated by packet engine 63 may be filled with control information by crypto engines 73 and 74, as will be described with reference to FIG. 10.

10 is a block diagram representation of crypto engine 73. The associated packet engine may generate dummy packets 241 for insertion into the data flow. Dummy packet 241 contains no payload data, but is merely received by crypto engine 73, which may be used by crypto engine 73 to insert control data therein, for example, for cryptographic key exchange. It may also be created to provide packets included in pre-shaped data traffic. Packet engine 63 inserts dummy packet 241 into the data flow (i.e., a sequence of data packets containing payload data). Dummy packet 241 may be an SCC packet.

At least a portion of the dummy packets 241 in the stream may be filled and used for management channel transmissions by crypto engine 73.

Cryptographic engine 73 provides dummy packets 59 to controller 243 or other integrated semiconductor circuits when cryptographic engine 73 needs to generate control packets for management channel transmission, such as cryptographic key exchange. It may also include a device 242 for doing so. Device 242 may select dummy packets from incoming pre-shaped data traffic. To this end, crypto engine 73 may scan all packet headers to distinguish dummy packets from regular data traffic containing payload data.

Dummy packets 241 that are not needed for management channel transmission may be removed from the pre-shaped data traffic by crypto engine 73.

Controller 243 may fill at least a portion of dummy packet 241 with management channel-related control data, particularly related to encryption and/or authentication. Controller 63 may use at least some of the dummy packets 241, for example, for encryption key exchange. Control packet 244 is created by filling at least a portion of dummy packet 241 with security-related management channel control data. Device 242 may reinsert control packet 244 into the pre-shaped data traffic in place of dummy packet 241 .

Figure 6 is a block diagram of LSR 160 illustrating transit traffic. Each of the plurality of LSRs 55, 56, 57, 58 of network 10 may have a configuration as described with reference to FIG. 6. A data packet may transit four crypto engine instances in the LSP path for the LSR case.

LSR 140 may include a first packet engine 141 and a second packet engine 142. If LSR 140 is an intermediate hop in the MPLS path, both first packet engine 141 and second packet engine 142 may be used. However, a packet switch (generally configured and operating as described for packet switches 82, 86 of Figure 3) may be in standby operation and may function only as a port forwarder.

LSR 140 may include multiple cryptographic engines 162, 164, 165, and 166.

First packet engine 141 may have port A (151) and port B (152). Second packet engine 142 may have port A (153) and port B (154). Cryptographic engine 143 may have port A 155 and port B 156. Cryptographic engine 146 may have port A 157 and port B 158.

Traffic from interface 109 received on port A 157 of crypto engine 146 is transmitted via crypto engine 146 to second packet engine 142 via port B 158 of crypto engine 146. It may also flow to port B (154) of . Second packet engine 142 may have a packet switch that only forwards data packets to first packet engine 141. The first packet engine 141 may output data traffic through port A 151 to port A 155 of the first encryption engine 143. Traffic flow may be output to interface 108 via port B 156 of crypto engine 143.

It will be appreciated that one node may operate in a hybrid LER and LSR mode. Therefore, there is a one-to-one correspondence between the packet engines (141, 142) and crypto engines (143, 144, 145, 146) of the LSR and the packet engines (141, 142) and crypto engines (143, 144, 145, 146) of the LER. exist. Accordingly, crypto engines 144 and 145 may perform encryption/decryption and/or authentication operations for a reverse flow direction than crypto engines 143 and 146, for example, when the node is operating in LER mode.

When a node operates in LSR mode, the crypto engine 143, 146 may use a bit window mechanism to determine whether an encrypted data packet will be decrypted. For an encrypted end-to-end path, LSR 140 is configured so that crypto engines 143, 146 do not decrypt encrypted data packets at intermediate hops in the bidirectional data path. The bit pattern for decryption search includes a top-of-stack label (path identifier) and additional bits (top-of-stack S-bit, bottom-of-stack label) to distinguish encrypted packets from unencrypted OAM packets, e.g., traceroute. You may. OAM packets, such as ping and trace route messages, serve as a detection mechanism for failure of intermediate nodes and remain unencrypted, as indicated by a properly configured bit window.

Figure 7 is a block diagram of LER 160. Each of the plurality of LERs 53, 54 of network 10 may have a configuration as described with reference to FIG. 7. Both MPLS traffic and encryption sessions may originate at LER 160.

LER 160 may include a first packet engine (PE) 161 for the working (w) path and a second packet engine (162) for the protection (p) path. The first packet engine 161 is provided with a tunnel start 181 for the working path. Protection flow 182, indicated by a dotted line in FIG. 7, may originate in first packet engine 161.

LER 160 may include multiple cryptographic engines 163, 164, 165, and 166.

LER 160 may include line card 168. Line card 168 may have ports 169.

First packet engine 161 may have port A 171 and port B 172. Second packet engine 162 may have port A 173 and port B 174. Cryptographic engine 163 may have port A 175 and port B 176. Cryptographic engine 166 may have port A 177 and port B 178. Cryptographic engines 163 and 166 perform encryption and/or authentication for the first direction in the bi-directional tunnel pair. Each associated cryptographic engine 164 may be connected to a first packet engine 161 that is the same as the cryptographic engine 163, and a cryptographic engine that may be connected to a second packet engine 162 that is the same as the cryptographic engine 166. 165 may perform decryption and/or authentication for a second direction on a bidirectional tunnel pair opposite to the first direction.

Traffic from line card 168 may be provided by first packet engine 161 via port A 171 to port A 175 of crypto engine 163. Cryptographic engine 163 may perform encryption and/or authentication operations. Critical parts of each data packet are replaced with their encrypted counterparts. Encrypted traffic is output to interface 108 through port B 176 of crypto engine 163.

The protection path may extend through the second packet engine 162. Traffic may be output to port B 178 of crypto engine 166 via port B 174 of packet engine 162. Cryptographic engine 166 may perform encryption and/or authentication operations. Traffic on the protection path may be output to interface 109 via port B 156 of crypto engine 166.

Cryptographic engines 163, 166 may use a bit window mechanism to determine which data packets will be encrypted. The bit pattern for cryptographic search may include a top of the stack label (path identifier) and additional bits (top of stack TTL value, bottom of stack label).

Cryptographic engines 164, 165 may use a bit window mechanism to determine which data packets will be decrypted. The bit pattern for decryption search includes a top-of-stack label (path identifier) and additional bits (top-of-stack S-bit, bottom-of-stack label) to distinguish encrypted packets from unencrypted OAM packets, e.g., traceroute. You may.

8 shows data 190 representing label stack encoding, for example, according to RFC 3032. Exemplary data includes label values, stack bottom bits, and Time to Live (TTL). Cryptographic engines may be configured using programmable bit windows to determine whether a data packet will be processed by the respective cryptographic engine or whether a data packet will remain untouched. For illustration purposes, the bit pattern for cryptographic search may include a top of stack label (path identifier) and additional bits (top of stack TTL value, bottom of stack label). The bit pattern for decryption search includes a top-of-stack label (path identifier) and additional bits (top-of-stack S-bit, bottom-of-stack label) to distinguish encrypted packets from unencrypted OAM packets, e.g., traceroute. You may.

Using the bit window mechanism, various options can be identified to perform traffic state monitoring by the crypto engine. For illustration purposes, a pseudo wire id can be identified and a “time to live” byte can be read. This predefined value or range of TTL bytes may be used to distinguish between end-to-end monitoring packets to be encrypted/decrypted and ping and trace route messages that remain unencrypted, respectively, for traffic status monitoring.

9 is a block diagram showing the hierarchy of management functions for network 10. PFPM 42 controls packet flow. CEKM 44 controls the cryptographic engines at the endpoint nodes and intermediate nodes of the encryption path, i.e. the cybersecurity path, and provides respective keys. Network 10 may include a plurality of LERs 201, 202, 203, 204, each including a packet engine 211, 212, 213, 214 and a crypto engine 221, 222, 223, 224. there is. Although only one packet engine and one crypto engine are shown in Figure 9, it will be appreciated that each LER may include multiple packet engines and multiple crypto engines as described above. For illustration purposes, each LER 201, 202, 203, 204 may include two packet engines for the working and protection paths, respectively, and four cryptographic engines for use in two directions of both the working and protection paths. there is.

CEKM 44 may receive a hardware-defined identifier 233 from the cryptographic engine. Hardware defined identifier 233 may be a board identifier, for example. Each crypto engine may have a hardware-defined identifier that is unique on the network. A hardware defined identifier may be provided to PFPM 42 via interface 232.

The following control steps may be performed:

Step A: CEKM 44 and PFPM 42 may exchange the following tuples 231, 232 for each path, respectively:

ⅰ. Hardware-defined identifier (i.e. global engine address)

ⅱ. tunnel-id,

ⅲ. MPLS labels,

iv. direction,

v. profile-id.

The profile-id may identify a set of auxiliary information, such as the type of traffic that should remain untouched.

Step B: Upon verifying successful application of the crypto engine configuration, the PFPM applies pre-shaping parameter configuration 234 to ensure proper timing and sequencing of packet flows. Pre-shaping parameter configuration 234 may be provided to the packet engine's dummy packet controllers 215, 216.

Step C: After receiving positive confirmation that the preformation parameter configuration has been successfully applied, PFPM 42 applies the path configuration 235 to the packet engine. If preforming parameter configuration is not successful, the simulation of PFPM 42 may be rolled back and the configuration may not be applied.

Taking down a route involves the same acknowledgment. The path is taken down from stage C to stage A in reverse order.

Figure 11 is a flow diagram of a method 250 according to one embodiment.

At step 251, multiple cryptographic engines provided separately from each packet engine may be controlled using a central CEKM. Controlling multiple cryptographic engines may include providing keys for encryption to the cryptographic engines. Controlling the plurality of cryptographic engines may include configuring programmable bit windows by the CEKM, depending on the path set by the PFPM.

At step 252, a cryptographic engine provided separately from the packet engine may perform at least one cybersecurity-related function. Cybersecurity-related functions may also include encryption/decryption. Cybersecurity-related functions may also include authentication.

Figure 12 is a flow diagram of a method 260 according to one embodiment. Method 260 may be performed by CEKM according to one embodiment.

At step 261, the CEKM may provide the hardware identifier of the cryptographic engine to the PFPM. CEKM may not provide PFPM with information about its cybersecurity systems other than this inventory information.

At step 262, the CEKM may receive information about the route or topology information from the PFPM. Information about the route may include, for example, tunnel-id, MPLS label or label stack, and direction.

At step 263, the CEKM may communicate with all cryptographic engines via a secure protocol to configure the cryptographic engines. Configuring the cryptographic engine may include programming programmable bit windows used by the cryptographic engine to determine whether a data packet is eligible for a cybersecurity feature.

At step 264, the CEKM may receive notifications from the cryptographic engine during operation of the network. CEKM can also provide alerts to PFPM.

Methods, devices, and systems according to embodiments provide secure communications and wire-like decisions, even when transiting through complex meshed networks.

Although example embodiments have been described with reference to the drawings, modifications and variations may be implemented in other embodiments. The methods, devices, and systems may be used in, but are not limited to, MPLS networks.

Methods, devices and systems according to embodiments may be used to deterministically transit encrypted and authenticated data packets through complex, meshed network topologies. For these networks, such as MPLS-TP networks, coherent association with cybersecurity redundant data link endpoints in a protected end-to-end tunnel, i.e. a cryptographic engine, is provided. For security reasons, the two subsystems are strongly separated but can also be synchronized. Dynamic protocols can also be used to support strictly limited information exchange. This ensures that the two redundant systems remain aligned with each other during all standard and exceptional network operating conditions.

Although embodiments will be described in which end-to-end encryption and/or authentication is performed, the techniques disclosed herein may also be used for encryption and/or authentication along segments of an end-to-end path.

The method, device, and system do not require packet addition and ensure that the same delay is maintained for all packets during the encryption phase. The crypto engine's potential need to add packets to the stream is avoided by adding dummy packets by a packet engine separate from the crypto engine. Ultimately, the inter-packet gap can be widened in the packet engine when necessary to avoid any disruption due to crypto engine control packet exchange requirements.

Embodiments of the present invention enhance protocols such as MPLS to be truly cybersecurity.

As those skilled in the art will understand, the embodiments disclosed herein are provided for better understanding and are by way of example only. Various modifications and changes will occur to those skilled in the art without departing from the scope of the invention as defined by the claims.

Claims (26)

A method of providing secure communication over end-to-end data paths in a packet network, comprising:
The packet network is a time-critical packet network including a plurality of packet engines (12, 22, 32; 61-64; 141, 142; 161, 162; 211-214) that perform packet processing,
The above method is,
performing at least one cybersecurity function by means of a plurality of cryptographic engines (14, 24, 43; 71-74; 143-146; 163-166; 221-224), said plurality of cryptographic engines ( Each of the encryption engines (14, 24, 43; 71-74; 143-146; 163-166; 221-224) includes the plurality of packet engines (12, 22, 32; 61-64; 141, 142; 161, 162; 211-214) associated with and provided separately from the individual packet engine, the cryptographic engines (14, 24, 43; 71-74; 143-146; 163-166; 221-224) ) at least some of each,
Between an individual packet engine (12, 22, 32; 61-64; 141, 142; 161, 162; 211-214) associated with an endpoint node of the packet network and a network-facing port of the endpoint node, or
The individual packet engine (12, 22, 32; 61-64; 141, 142; 161, 162; 211-214) associated with the endpoint node and a first transit node (55-58) connected to the endpoint node ) between
provided, performing said at least one cybersecurity function; and
Centrally controlling the plurality of cryptographic engines (14, 24, 43; 71-74; 143-146; 163-166; 221-224) by a cryptographic engine and key manager (CEKM) 44. A method of providing secure communication over end-to-end data paths, comprising: According to claim 1,
Endpoint nodes (140; 53, 54) and intermediate transit nodes (160; 55-58) of the end-to-end data paths of the packet network are managed by a centralized Packet Flow Path Manager (PFPM) (42). ), further comprising the step of establishing: According to claim 2,
The PFPM 42 is communicatively connected to all endpoint nodes 140; 53, 54 and intermediate transit nodes 160; 55-58 of the packet network via end-to-end data paths. How to provide secure communications. According to claim 2,
wherein the CEKM (44) runs on a first server and the PFPM (42) runs on a second server that is different from the first server. According to claim 2,
A method for providing secure communication over end-to-end data paths, further comprising restricting information provided by the CEKM (44) to the PFPM (42). According to claim 4,
discovering, by the CEKM 44, hardware-defined identifiers of the plurality of cryptographic engines (14, 24, 43; 71-74; 143-146; 163-166; 221-224); and
further comprising providing, by the CEKM 44, the hardware defined identifiers to the PFPM 42,
The CEKM (44) provides only the hardware defined identifiers and alarms to the PFPM (42). The method according to any one of claims 2 to 6,
The CEKM 44 operates end-to-end from the PFPM 42 to configure the plurality of cryptographic engines (14, 24, 43; 71-74; 143-146; 163-166; 221-224). A method of providing secure communication over end-to-end data paths, receiving information regarding the data flow topology of the data path. According to claim 7,
The method of claim 1, wherein the information regarding the data flow topology includes a tunnel identifier, MPLS label, and direction. The method according to any one of claims 2 to 6,
The CEKM (44) and the PFPM (42) communicate over a secure channel. The method according to any one of claims 1 to 6,
The CEKM 44 is communicatively connected to each of the plurality of cryptographic engines 14, 24, 43; 71-74; 143-146; 163-166; 221-224, and the cryptographic engines 14 , 24, 43; 71-74; 143-146; 163-166; 221-224) via a security protocol for configuring and/or notifying the plurality of cryptographic engines 14, 24, 43; 71- 74; 143-146; 163-166; 221-224). A method of providing secure communication over end-to-end data paths, communicating with each of the following. According to claim 2,
further comprising selecting bits from a data packet using a bit window by the crypto engine of the plurality of crypto engines (14, 24, 43; 71-74; 143-146; 163-166; 221-224). wherein the bit window is programmable,
The bits selected according to the programmable bit window identify data packets to be processed by the cryptographic engine. According to claim 11,
The bit window is different at the ingress and egress nodes of the end-to-end data path, and the information exchanged between the CEKM 44 and the PFPM 42 is used to configure the bit window. A method of providing secure communication over two-end data paths. The method according to any one of claims 1 to 6,
By the packet engines 12, 22, 32; 61-64; 141, 142; 161, 162; 211-214, the positions of data packets in the traffic flow are maintained unchanged when passing through the encryption engine. further comprising pre-shaping the data packets entering the crypto engine, wherein the data packets are pre-shaped such that time stamping information of the data packets entering the crypto engine is still valid when the data packets leave the crypto engine. A method of providing secure communication over shaped, end-to-end data paths. The method according to any one of claims 1 to 6,
The plurality of packet engines (12, 22, 32; 61-64; 141, 142; 161, 162; 211-214) and the plurality of crypto engines (14, 24, 43; 71-74; 143-146) ; 163-166; 221-224) is a method for providing secure communication over end-to-end data paths, ensuring global identification of data packets belonging to the same traffic flow using a common global information identity. According to claim 14,
The method of claim 1, wherein the global information identity indicates a multiprotocol label switching (MPLS) tunnel. The method according to any one of claims 1 to 6,
Data packets are sent to the crypto engine (14, 24, 43; 71-74; 163-166; 221, 224) immediately after leaving the associated packet engine (12, 22, 32; 61-64; 161, 162; 201, 204). or the data packets are decrypted by the crypto engine immediately before entering the associated packet engine (12, 22, 32; 61-64; 161, 162; 201, 204). A method of providing secure communication over end data paths. The method according to any one of claims 1 to 6,
The plurality of cryptographic engines (14, 24, 43; 71-74; 143-146; 163-166; 221-224) perform message authentication and provide secure communication over end-to-end data paths. method. The method according to any one of claims 1 to 6,
Further comprising propagating traffic loss information to the interfaces of the associated packet engines to trigger traffic switching, by the crypto engines (14, 24, 43; 71-74; 143-146; 163-166; 221-224). And
Wherein the step of propagating traffic loss information is triggered by a failure of an optical data connection detected by a wide area network (WAN) facing line interface. The method according to any one of claims 1 to 6,
further comprising monitoring the status of the data flow, including transmitting an additional stream of data packets,
The additional stream of data packets is:
end-to-end monitoring packets encrypted by the cryptographic engines (14, 24, 43; 71-74; 143-146; 163-166; 221-224); and/or
A method of providing secure communication over end-to-end data paths, including ping and trace route messages remaining unencrypted. The method according to any one of claims 1 to 6,
The packet engines (12, 22, 32; 61-64; 141, 142; 161, 162; 211-214) perform time stamping, and the crypto engines (14, 24, 43; 71-74; 143) -146; 163-166; 221-224) is a method for providing secure communication over time-unaware and topology-unaware, end-to-end data paths. The method according to any one of claims 1 to 6,
A method of providing secure communication over end-to-end data paths, wherein the packet network is a packet network for automation of high voltage lines. Securing communication over end-to-end data paths in a time-critical packet network with packet engines (12, 22, 32; 61-64; 141, 142; 161, 162; 211-214) performing packet processing. As a cryptographic engine and key manager (CEKM) (44) to
The packet network includes a packet flow path manager (PFPM) that configures traffic flow nodes of the packet network,
The CEKM (44) is,
a first interface operative to receive information regarding the data flow topology of an end-to-end data path from the PFPM 42;
As a second interface operative to provide configuration information to a plurality of separately provided crypto engines (14, 24, 43; 71-74; 143-146; 163-166; 221-224), each associated with an individual packet engine, , the second interface wherein the plurality of cryptographic engines (14, 24, 43; 71-74; 143-146; 163-166; 221-224) are configured to perform at least one cybersecurity function; and
A cryptographic engine and manager of keys, comprising at least one processor operative to generate the configuration information based on the data flow topology. According to claim 22,
The CEKM 44 discovers hardware-defined identifiers of the plurality of cryptographic engines (14, 24, 43; 71-74; 143-146; 163-166; 221-224), and detects only the hardware-defined identifiers. A crypto engine and manager of keys operative to provide only messages and alarms to the PFPM 42. As a crypto engine,
a first interface operative to connect directly to a packet engine (12, 22, 32; 61-64; 141, 142; 161, 162; 211-214) that performs packet processing for a time critical packet network;
a second interface operative to connect to a network-facing port of an endpoint node or a first transit node connected to the endpoint node; and
a third interface operative to receive configuration information from a Crypto Engine and Key Manager (CEKM) 44;
The cryptographic engine (14, 24, 43; 71-74; 143-146; 163-166; 221-224) is configured to configure the cryptographic engine (14, 24, 43) based on the configuration information received from the CEKM (44). ; 71-74; 143-146; 163-166; 221-224) a cryptographic engine that operates to perform cybersecurity functions on data packets of traffic flowing through. According to claim 24,
The cryptographic engine (14, 24, 43; 71-74; 143-146; 163-166; 221-224) does not have information about the topology of the end-to-end path on which the security function is performed and the data packet A cryptographic engine that operates to perform the security functions without using their time stamping information. As a network,
a plurality of packet engines (12, 22, 32; 61-64; 141, 142; 161, 162; 211-214) operative to perform packet processing in a time-critical packet network;
a Packet Flow Path Manager (PFPM) 42 operative to provide configuration information to traffic flow nodes of the packet network;
Receiving data packets of a traffic flow from each associated packet engine (12, 22, 32; 61-64; 141, 142; 161, 162; 211-214) or from said associated packet engine (12, 22, 32; 61- Cryptographic engines (14, 24, 43; 71-74) according to claim 24 or 25, operative to provide data packets of the traffic flow to 143-146; 163-166; 221-224); and
Cipher according to claim 22 or 23, coupled to the PFPM (42) and the plurality of cryptographic engines (14, 24, 43; 71-74; 143-146; 163-166; 221-224) Network, including Engine and Key Manager (CEKM) 44.

Images