Secure connection initiation for preventing replay attacks in encrypted networks

Abstract

This disclosure relates to secure connection initiation for preventing replay attacks in encrypted networks. Systems and methods are provided for providing a shared token as part of establishing a communication connection (“connection establishment”) between the source and target devices with the network after a previous communication connection with the network between the source and target devices has been closed or compromised, to help prevent future replay attacks.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit and priority of U.S. Provisional Application No. 63 / 440,592, filed January 23, 2023, the contents of which are incorporated herein by reference in their entirety. Technical Field

[0003] This disclosure relates in its entirety to secure connection startup for preventing replay attacks in encrypted networks. Background Technology

[0004] A replay attack occurs when an entity sniffs or eavesdrops on secure network communications, intercepts data packets transmitted over a secure network connection, and then fraudulently delays or retransmits these packets. The headers or other content of the retransmitted packets may appear to originate from a source authorized to access the network, leading the entity to speculate that the network may be allowing its use. In this way, the entity fraudulently gains access to the network and may potentially access additional protected data.

[0005] Replay attacks can also have unauthorized effects on computer systems. For example, by fraudulently retransmitting data packets, improper data transmission in a network can cause silent corruption, job failures, or performance impacts. An entity that fraudulently retransmits data packets may cause problems and delays when transmitting permitted data packets in the network. Summary of the Invention

[0006] According to one aspect of this disclosure, a method for establishing a communication connection between devices is provided, comprising: transmitting a series of data packets from a source device to a target device, at least one of the data packets including a first shared token; closing a first communication connection between the source device and the target device via a communication network at a first time, the first shared token being stored by the target device after the first communication connection is closed; encrypting a portion of a first data packet by the source device using a key stored at a network interface card (NIC) of the source device, the first data packet corresponding to a request of the source device; initiating a second communication connection by the source device at a second time after the first time; transmitting the first data packet destined for the target device by the source device to the target device, the first data packet including the first shared token in an encrypted portion of the first data packet; receiving from the target device by the source device a rejection message in response to transmitting the first data packet, the rejection message including a second shared token in an encrypted portion of the rejection message; decrypting the rejection message by the source device to determine the second shared token; and establishing a third communication connection between the source device and the target device via the communication network by the source device to transmit a second data packet including the second shared token.

[0007] According to another aspect of this disclosure, a source device is provided, comprising: a memory; and a processor configured to execute machine-readable instructions stored in the memory, the machine-readable instructions causing the processor to perform the following operations when executed by the processor: transmitting a series of data packets from the source device to a target device, at least one of the data packets including a first shared token; closing a first communication connection between the source device and the target device via a communication network at a first time, the first shared token being stored by the target device after the first communication connection is closed; encrypting a portion of a first data packet using a key stored at a network interface card (NIC) of the source device, the first data packet corresponding to a request from the source device; initiating a second communication connection by the source device at a second time after the first time; transmitting the first data packet destined for the target device to the target device, the first data packet including the first shared token in an encrypted portion of the first data packet; receiving from the target device a rejection message in response to transmitting the first data packet, the rejection message including a second shared token in an encrypted portion of the rejection message; decrypting the rejection message to determine the second shared token; and establishing a third communication connection between the source device and the target device via the communication network to transmit a second data packet including the second shared token.

[0008] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided that stores a plurality of instructions executable by a processor, which, when executed by the processor, cause the processor to perform the following operations: transmit a series of data packets from a source device to a target device, at least one of the data packets including a first shared token; close a first communication connection between the source device and the target device via a communication network at a first time, the first shared token being stored by the target device after the first communication connection is closed; encrypt a portion of a first data packet corresponding to a request from the source device using a key stored at a network interface card (NIC) of the source device; initiate a second communication connection by the source device at a second time after the first time; transmit the first data packet destined for the target device to the target device, the first data packet including the first shared token in an encrypted portion of the first data packet; receive from the target device a rejection message in response to the transmission of the first data packet, the rejection message including a second shared token in an encrypted portion of the rejection message; decrypt the rejection message to determine the second shared token; and establish a third communication connection between the source device and the target device via the communication network to transmit a second data packet including the second shared token. Attached Figure Description

[0009] This disclosure is described in detail with reference to the following accompanying drawings, based on one or more different examples. The drawings are provided for illustrative purposes only and depict only typical examples.

[0010] Figure 1 The present disclosure illustrates some examples of networks used to establish secure connections to help prevent replay attacks.

[0011] Figure 2 The illustration shows a connection establishment process performed between a source device and a target device according to some examples of this disclosure.

[0012] Figure 3 These are example computational components that can be used to implement the various features of the examples described in this disclosure.

[0013] Figure 4 An exemplary architecture of a NIC according to some examples of this disclosure is shown.

[0014] Figure 5 A block diagram depicts an example computer system in which the various examples described herein can be implemented.

[0015] The accompanying drawings are not exhaustive and do not limit this disclosure to the precise form disclosed. Detailed Implementation

[0016] The examples disclosed herein provide a shared token as part of establishing a communication connection (“connection establishment”) between the source and target devices with the network after a previous communication connection with the network between the source and target devices has been closed or compromised, to help prevent future replay attacks. Connection establishment can be included during data transmission.

[0017] Source and target devices can transmit messages via a shared network connection (e.g., "first connection") at one time and attempt to reconnect the same two devices at another time (e.g., "second connection"). For example, during the first connection, an application executing on the source device's NIC can request data operations on the target device's memory location (e.g., a "GET" or "PUT" command for Remote Direct Memory Access (RDMA)). The target device's NIC can receive the request, facilitate the execution of the operation, and send a response with the execution result. Using the request for data operations, the source device's NIC can include a token in the request. When the target device provides a response to the source device indicating that the request is complete, the response can include the token. The connection can be removed, closed, or destroyed, making it impossible to maintain a persistent connection between the source and target devices, but the target device can store the token locally to identify the request / response from the source device. This allows systems facilitating connections between thousands of source and target devices to maintain fewer persistent connections between devices, especially when devices do not actively transmit data packets to each other. The system can operate more efficiently overall, and the overhead of handling activity to keep connections persistent is reduced.

[0018] For example, a second connection can be initiated by an application executing on the source device's NIC requesting data manipulation of the target device's memory location (e.g., a "GET" or "PUT" command in Remote Direct Memory Access (RDMA)). When the same device attempts to reconnect in the second connection, the token transmitted by the source device during the first connection can be reused by the NIC at the source device. The target device can compare the received token and the source device's identifier with the stored token to confirm the previous connection established between the target device and the source device. Since the token has already been used (e.g., it exists in the target device's storage), the target device can generate a second shared token and transmit it back to the source device in response to the source device's rejection of the second connection attempt using the first shared token. A third connection can be initiated by the source device using the second shared token, which includes the second shared token with a new request message. By checking the validity of the first shared token and transmitting the second shared token with a rejection message, the device can confirm that the expected devices are communicating with each other in the network. This also helps prevent fraudsters from using previously used tokens to transmit requests to the target device. This can also help prevent replay attacks by fraudsters' devices that reuse packets transmitted over the network to gain access to the network.

[0019] Technological improvements have been implemented throughout this disclosure. For example, in addition to helping prevent replay attacks during communication in a distributed environment, the disclosed techniques also improve authentication and authorization in the connection establishment process by combining shared tokens with the handshake process. In this improved authentication and authorization, entities are allowed to form a connection when the correct token is properly shared and stored. The system can ensure that connection establishment between the source and target devices uses the correct shared token without maintaining a persistent connection between the two devices. Furthermore, by adapting communication between the source and target devices using the systems and methods described herein, large-scale network communication systems can be established between various entities to allow devices to interoperate with high-performance computing (HPC) systems. The security protocols established at different entities can be independent and optimized individually for each computing environment. This allows multiple systems to use data centers that cannot or are unwilling to adhere to a single standardized protocol to handle resource-intensive computing such as artificial intelligence (AI) and machine learning (ML).

[0020] Figure 1Exemplary networks for establishing secure connections to help prevent replay attacks are illustrated according to some examples of this disclosure. In example 100, source device 110 is connected to target device 130 via interconnect structure 120. Source device 110 and target device 130 include NIC 140 (illustrated as NIC 140A at the source device and NIC 140B at the target device), host interface 142 (illustrated as host interface 142A at the source device and host interface 142B at the target device), high-speed network interface 144 (illustrated as high-speed network interface 144A at the source device and high-speed network interface 144B at the target device), and other device components 180 (illustrated as other device components 180A at the source device and other device components 180B at the target device connected via a bus or other connection medium, such as...). Figure 4 and Figure 5 (Further illustration in the middle).

[0021] Source device 110 and destination device 130 can have unique addresses or IDs within the interconnection structure 120, and various types of devices and networks can be represented as source device 110 and destination device 130. For example, devices can include network devices, mobile devices, storage arrays, InfiniBand (IB) based HPC networks, terminal hosts, and IP / Ethernet networks. Typically, devices can have edge ports and fabric ports. Edge ports can be coupled to devices outside the fabric. Fabric ports can be coupled to another switch within the fabric via fabric links.

[0022] In some examples, traffic can be injected into interconnect 120 via the egress port of source device 110 and exit interconnect 120 via the ingress port of another (or the same) device, including destination device 130. An ingress link can couple the network interface controller (NIC) of the first device to the ingress edge port of the second device. Interconnect 120 can then transmit traffic to the egress port of the source device, which can then deliver the traffic to the destination device via another NIC.

[0023] NIC 140 can be designed to enable each corresponding device to communicate with interconnect 120, including, for example, being equipped with host interface 142 (e.g., an interface for connecting to a host processor) and high-speed network interface 144 for communicating with links coupled to interconnect 120.

[0024] In some examples, host interface 142 may be a Peripheral Component Interconnect (PCI) or High-Speed ​​Peripheral Component Interconnect (PCIe) interface. Host interface 142 may be coupled to a host via a host connector that may include N (e.g., N may be 16 in some chips) PCIe Gen 4 lanes capable of operating at signaling rates up to 25 Gbps per lane. Host interface 142 may facilitate high-speed network connectivity for communication with links in interconnect structure 120. Host interface 142 may operate at a total rate of 100 Gbps or 200 Gbps using M (e.g., M may be 4 in some chips) full-duplex serial channels. Each of the M channels may operate at a rate of 25 Gbps or 50 Gbps based on Non-Return-to-Zero (NRZ) modulation or Pulse Amplitude Modulation 4 (PAM4), respectively. The high-speed network interface 144 can support the IEEE 802.3 Ethernet-based protocol and an enhanced frame format that supports higher-speed small messages.

[0025] The NIC 140 can support one or more of the following: point-to-point messaging via the Message Passing Interface (MPI), remote memory access (RMA) operations, offloading and scheduling of bulk data operations, and Ethernet packet processing. When a host sends an MPI message, the NIC 140 can match the corresponding message type. Furthermore, the NIC 140 can implement both urgent and conventional protocols for MPI to offload the corresponding operation from the host.

[0026] NIC 140 also supports data operations, including PUT, GET, Atomic Memory Operations (AMO), or other Remote Direct Memory Access (RDMA) commands, and provides reliable transport. For example, for NIC 140A at source device 110, NIC 140 can provide a retry mechanism for idempotent operations. Idempotent operations can be performed more than once without error, while non-idempotent operations may cause errors if the operation is performed more than once. Furthermore, connection-based error detection and retry mechanisms can be used for ordered operations that can manipulate the target state. The hardware of NIC 140 can maintain the state required for the retry mechanism. In this way, NIC 140 can reduce the burden on the host (e.g., software). The strategy for determining the retry mechanism can be specified by the host via driver software, thus ensuring the flexibility of NIC 140.

[0027] In some examples, NIC 140 can facilitate the progress of triggering operations, general offloading mechanisms, and sequences of dependent operations (such as bulk data collections). NIC 140 can support application programming interfaces (APIs) (e.g., free-structure APIs) that facilitate structured communication services provided by interconnect structure 120 to applications on the host device. NIC 140 can also support low-level network programming interfaces, such as portal APIs. Additionally, NIC 140 can provide efficient Ethernet packet processing, which can include efficient transmission when NIC 140 is located at the source device, and flow redirection and checksum calculation when NIC 140 is located at the destination device. Furthermore, NIC 140 can support virtualization (e.g., using containers or virtual machines).

[0028] Figure 2 The illustration shows a connection establishment process performed between a source device and a target device according to some examples of this disclosure. In this example, source device 210 and target device 220 may respectively correspond to Figure 1 The diagram illustrates source device 110 and target device 130. The connection establishment process can involve providing a shared token from a device permitted to communicate via the network (e.g., target device 220) as part of establishing an initial connection with the network (e.g., source device 210). Connection establishment can be included during data transfer between source device 210 and target device 220 and utilize... Figure 4 The NIC architecture described in the document is used for implementation.

[0029] At box 225, a first connection for data transfer can be established and closed. For example, once the first connection is established, an application executing on the source device's NIC can request data operations on the target device's memory location (e.g., a "GET" or "PUT" command for Remote Direct Memory Access (RDMA)). The first data packet may include a shared token. The shared token may be stored within the encrypted portion of the first data packet. The target device's NIC can receive the request, facilitate the execution of the operation, and send a response with the execution result. The source device's NIC can include the token in the request for the data operation. When the target device provides a response to the source device indicating that the request is complete, the response may include the token. The connection may be removed or disconnected, making it impossible to maintain a persistent connection between the source and target devices, but the target device can store the token locally to identify the request / response from the source device.

[0030] Shared tokens can correspond to various formats. For example, a shared token may correspond to a sequence number established during a previous connection between source device 210 and target device 220. In some examples, a shared token may correspond to the current time synchronized across source device 210 and target device 220. In some examples, a shared token may correspond to a list of available tokens, where the use of each available token is tracked by source device 210 and target device 220.

[0031] The first example of a shared token would be a sequence number. When a shared token is generated using a sequence number, the shared token can correspond to the next expected sequence number used during the last connection between the nodes. In some examples, this form of shared token can be stored more efficiently compared to a typical connection state. The source device 210 and the target device 220 can store the sequence number using simple data structures and local memory after the connection state of the last connection is broken (or the device is detached).

[0032] The second example would be using the current time. For instance, in a system synchronizing time across devices / systems, the current time can be used as a shared token. In some examples, the current time can be used as a shared token, provided that two devices do not attempt to establish a connection twice within a certain time window or time range. This time window or time range can be very narrow. In this example, the system could implement a time range that includes the current time. This time range can be used as a token, and the connection can be maintained at least for the duration of this time range. While maintaining the connection, the system can prevent re-establishment of the connection during this time range.

[0033] The third example implements connection establishment using a list of available tokens. When a shared token is generated using the list of available tokens for connection establishment, the shared token can correspond to one of the available tokens in the list. The source device 210 and the target device 220 can track which tokens have been used by the peer node, allowing them to retire used shared tokens or determine when a shared token should no longer be used for connection establishment. A characteristic of this approach is that connection establishment can be lightweight, and the connection establishment rate can be lower than the packet acceptance rate. For example, connection overhead can be performed over multiple clock cycles (i.e., 10 to 20 nanoseconds) instead of within the round-trip time (2 to 5 microseconds). Dynamic connections performed during the round-trip time before a connection can be used may not meet the requirement of sufficiently high performance within acceptable limits. In some examples, connection establishment can perform multi-cycle lookups. Even in a system that processes one packet per cycle, a 16-cycle connection establishment penalty can be reasonable. In contrast, the round-trip time can be a few microseconds, and the lookup can be a few nanoseconds.

[0034] At box 230, a second connection can be initiated after the first connection is closed or destroyed. For example, a first packet of a connection handshake or connection establishment process can be transmitted from source device 210 to target device 220 to attempt to establish a connection between the two devices. In some examples, source device 210 encrypts a portion of the first packet used in the connection handshake using a key. The key may be received from a key server before receiving a message requesting communication establishment and is stored at the NIC of source device 210. In some examples, the key may be delivered as an encryption key (e.g., from a key server accessible on the network's interconnect structure).

[0035] At box 240, a second data packet (and subsequent data packets) can be transmitted from source device 210 to target device 220. The transmission of the second data packet can be initiated before receiving an acknowledgment from target device 220 (e.g., regarding box 230). This acknowledgment can identify the initiation of a connection between source device 210 and target device 220 in response to the first connection establishment process.

[0036] While the first connection establishment is being performed, the source device 210 can continue transmitting data packets after the first data packet. In some examples, when the connection is successfully established, all packets sent after the successful connection request (which may already be in flight) do not need to be retransmitted. Data packets sent between the first unsuccessful connection establishment and the second successful connection establishment can be retransmitted.

[0037] At box 250, a rejection message with a second shared token is transmitted. For example, if the target device 220 determines that the shared token has been previously used, the target device may transmit a rejection message to the source device 210 in response to the attempted connection establishment. In another example, if the target device 220 determines that the shared token has expired, the target device may transmit a rejection message to the source device 210 in response to the attempted connection establishment.

[0038] A rejection message may include a second shared token in the encrypted portion of the message. This second shared token may be received by the source device 210 and used in subsequent connection establishment attempts. When a portion of the message is encrypted, the source device 210 may use a key from a key server to decrypt that portion of the message. As discussed herein, the key may be received before the message requesting communication establishment is received, and the key may be stored at the source device 210's NIC (e.g., the key is not transmitted during the connection establishment process).

[0039] At box 260, a third connection establishment process can be initiated. For example, when source device 210 receives a rejection message, source device 210 can decrypt the message and identify the second shared token. In some examples, source device 210 can locally store the second shared token and delete the first shared token. Source device 210 can then use the second shared token to initiate the third connection establishment.

[0040] By checking the validity of the first shared token and transmitting a second shared token with a rejection message, the device can also help prevent replay attacks from random packets transmitted in the network.

[0041] At box 270, a second data packet (and subsequent data packets) can be transmitted from source device 210 to target device 220. The transmission of the second data packet can be initiated before receiving an acknowledgment from target device 220. This acknowledgment can identify the establishment of a third connection between source device 210 and target device 220 in response to a third connection establishment process.

[0042] In some examples, target device 220 may access stored data packets received under the second connection establishment procedure, but may not access received data packets received under the third connection establishment procedure.

[0043] In some examples, packets received before a successful connection is established can be dropped or deleted, so that the system's main memory will not be affected (e.g., used for storing packets). In other examples, source device 210 can continue transmitting packets after the first packet while the third connection establishment is being performed.

[0044] Once the connection establishment process is successful, further data packets can continue to be transmitted between the source device 210 and the target device 220. For example, an application running on the NIC of the source device 210 can request data operations on memory locations of the target device 220 (e.g., a "GET" or "PUT" command for Remote Direct Memory Access (RDMA)). The NIC of the target device 220 can receive the request, facilitate the execution of the operation, and send a response with the execution result to the source device 210. Examples of the result may include, but are not limited to: one or more values ​​generated based on calculations associated with the operation; indicators indicating whether the operation was successful or unsuccessful; the memory location or index associated with the operation; and information indicating the state of the data structure based on the operation performed on the data structure.

[0045] Other operations can also be initiated. For example, RDMA operations can include, but are not limited to, atomic memory operations, adding data to a queue, and indicating that an operation is complete. Because RDMA operations can be issued from source device 210 and span interconnect structures (e.g., Figure 1The interconnect structure 120 in the source NIC is transmitted to the target device 220, so these operations can be performed based on the request-response communication protocol between the source NIC and the target NIC.

[0046] In some examples, while the second connection establishment is underway, the source device can continue transmitting data packets after the first packet. In some examples, when the second connection is successfully established, all packets sent after the successful connection request (which may already be in flight) do not need to be retransmitted. Data packets sent between the first unsuccessful connection establishment and the second successful connection establishment can be retransmitted.

[0047] It should be noted that the terms "optimized," "optimal," etc., as used herein, can be used to mean achieving or realizing the most efficient or perfect performance possible. However, those skilled in the art who read this document will recognize that perfection is not always achievable. Therefore, these terms can also encompass achieving or realizing the best possible, most efficient, or most practical performance under given conditions, or achieving or realizing performance superior to that achievable using other settings or parameters.

[0048] Figure 3 The illustrations depict example computing components, based on various examples, that can be used to implement secure connection initiation to prevent replay attacks in encrypted networks. Now refer to... Figure 3 The computing component 300 can be, for example, a server computer, a controller, or any other similar computing component capable of processing data. Figure 3 In an example implementation, computing unit 300 includes hardware processor 302 and machine-readable storage medium 304.

[0049] Hardware processor 302 may be one or more central processing units (CPUs), semiconductor-based microprocessors, and / or other hardware devices suitable for fetching and executing instructions stored in machine-readable storage medium 304. Hardware processor 302 may fetch, decode, and execute instructions (such as instructions 305 to 314) to control processes or operations for implementing a dynamically modular and customizable computing system. As an alternative to or supplement to fetching and executing instructions, hardware processor 302 may include one or more electronic circuits, such as field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or other electronic circuits, containing electronic components for executing one or more instructions.

[0050] Machine-readable storage media (such as machine-readable storage media 304) can be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. Therefore, machine-readable storage media 304 can be, for example, random access memory (RAM), non-volatile RAM (NVRAM), electrically erasable programmable read-only memory (EEPROM), storage devices, optical discs, etc. In some examples, machine-readable storage media 304 can be a non-transitory storage medium, where the term "non-transitory" does not cover transient propagation signals. As described in detail below, machine-readable storage media 304 can be encoded using executable instructions (e.g., instructions 305 to 314).

[0051] Hardware processor 302 can execute instructions 305 to close a first communication connection between the source device and the target device via a communication network at an immediate time. In some examples, the first communication connection can be closed while a series of data packets are being transmitted from the source device and the target device. At least one of the data packets in the series may include a first shared token, which is stored by the target device after the first communication connection is closed or inactive.

[0052] In some examples, the hardware processor 302 may execute instructions to transfer a series of data packets from a source device to a destination device prior to instruction 305. In some examples, at least one data packet in the series includes a first shared token.

[0053] Hardware processor 302 can execute instructions 306 to encrypt a portion of the first data packet. Encryption can be performed using a key stored at the NIC of the source device. In some examples, the first data packet corresponds to a request from the source device to initiate data operations at the destination device.

[0054] Hardware processor 302 can execute instruction 307 to initiate a second communication connection between the source device and the target device. The second communication connection can be initiated at a second time after the first time, which corresponds to the closure of the first communication connection between the source device and the target device.

[0055] Hardware processor 302 can execute instructions 308 to transmit a first data packet to a target device. The transmission can be performed from the source device to the target device. The first data packet includes a first shared token within its encrypted portion. In some examples, the communication connection between the source device and the target device may be inactive when the first data packet is transmitted.

[0056] Hardware processor 302 can execute instruction 310 to receive a rejection message in response to the transmission of the first data packet. The rejection message can be received by the source device from the destination device. The rejection message may include a second shared token in its encrypted portion. The encrypted portion of the rejection message can be encrypted using a key stored at the NIC of the source device.

[0057] Hardware processor 302 can execute instruction 312 to decrypt the rejection message to determine the second shared token. Decryption can be performed by the source device using a key stored at the source device's NIC. Encryption of the rejection message can be performed using a second key stored at the target device's NIC.

[0058] Hardware processor 302 can execute instruction 314 to establish a third communication connection. It can perform a transmission to transmit a second data packet including a second shared token. The third communication connection can be established via a communication network. The third communication connection can be used to transmit the second data packet, which includes the second shared token within its encrypted portion.

[0059] Figure 4 An exemplary architecture of the NIC 400 is illustrated. The source and target devices illustrated herein may include the NIC 400, host interface 404, high-speed network interface 406, and other device components. In some examples, host interface 404 may be a Peripheral Component Interconnect (PCI) or High-Speed ​​Peripheral Component Interconnect (PCIe) interface. Host interface 404 may be coupled to a host via a host connector that may include N (e.g., N may be 16 in some chips) PCIe Gen 4 lanes capable of operating at signaling rates up to 25 Gbps per lane. Host interface 404 may facilitate high-speed network connectivity that can communicate with links in the interconnect structure. Host interface 404 may operate at a total rate of 100 Gbps or 200 Gbps using M (e.g., M may be 4 in some chips) full-duplex serial channels. Each of the M channels can operate at rates of 25 Gbps or 50 Gbps, respectively, based on non-return-to-zero (NRZ) modulation or pulse amplitude modulation 4 (PAM4). The high-speed network interface 406 can support the IEEE 802.3 Ethernet-based protocol and enhanced frame formats to support higher-speed small messages.

[0060] For example, port macros of the high-speed network interface 406 can facilitate low-level Ethernet operations such as Physical Coding Sublayer (PCS) and Media Access Control (MAC). Additionally, the NIC 400 can provide support for Link Layer Retry (LLR). Incoming packets can be parsed by parser 428 and stored in buffer 429. Buffer 429 can be a PFC buffer, which is supplied with latency bandwidth for buffering a threshold amount (e.g., one microsecond). The high-speed network interface 406 may also include a control transmission unit 424 and a control reception unit 426 for managing outgoing and incoming packets, respectively.

[0061] In some examples, during each of the first, second, or third communication connections between the source and target devices, the source device may transmit a series of data packets, which are received at the high-speed network interface 406, parsed by the parser 428, and stored in the target device's buffer 429. The target device's control transmission unit 424 and control reception unit 426 may also manage outgoing and incoming packets from the source device.

[0062] NIC 400 may include a command queuing (CQ) unit 430. Command queuing unit 430 is responsible for retrieving and issuing host-side commands. Command queuing unit 430 may include a command queue 432 and a scheduler 434. Command queue 432 may include two separate queues for initiator commands (PUT, GET, etc.) and target commands (Append, Search, etc.). Command queue 432 may be implemented as a circular buffer maintained in the memory of NIC 400.

[0063] Applications running on the host can write directly to command queue 432. Scheduler 434 may include two separate schedulers, one for initiator commands and one for target commands. Initiator commands may be sorted into stream queue 436 based on a hash function. A stream queue in stream queue 436 may be assigned to a unique stream. Furthermore, command queue unit 430 may further include a trigger operation module (or logic block) 438, which is responsible for queuing and dispatching trigger commands.

[0064] Outbound delivery engine (OXE) 440 can pull commands from flow queue 436 for processing and dispatch. Outbound delivery engine 440 may include an Address Translation Request Unit (ATRU) 444, which can send address translation requests to Address Translation Unit (ATU) 412. ATU 412 can provide virtual-to-physical address translation on behalf of different engines such as outbound delivery engine 440, inbound delivery engine (IXE) 450, and event engine (EE) 416. ATU 412 can maintain a large translation buffer 414. ATU 412 can perform translation itself or use a host-based address translation service (ATS). Outbound delivery engine 440 may also include a Message Segmentation Unit (MCU) 446, which can segment large messages into packets corresponding to the size of the Maximum Transmission Unit (MTU). MCU 446 may include multiple MCU modules. When an MCU module becomes available, it can obtain the next command from the assigned flow queue. Received data can be written to data buffer 442. The MCU module can then send the packet header, corresponding traffic classification, and packet size to the traffic shaper 448. The shaper 448 can then determine which requests initiated by the MCU 446 can enter the network.

[0065] The selected packet can then be sent to Packet and Connection Tracking (PCT) 470. PCT 470 can store the packet in queue 474. PCT 470 can also maintain the status information of outbound commands and update the status information upon receiving a response. PCT 470 can also maintain packet status information (e.g., allowing matching of responses with requests), message status information (e.g., tracking the progress of multi-packet messages), initiator completion status information, and retry status information (e.g., maintaining information needed to retry commands in case of lost requests or responses). If no response is returned within a threshold time, the corresponding command can be stored in retry buffer 472. PCT 470 can facilitate connection management of initiator commands and target commands based on source table 476 and target table 478, respectively. For example, PCT 470 can update its source table 476 to track the status required for reliable delivery of packets and message completion notifications. PCT 470 can forward outbound packets to high-speed network interface 406, which stores the packets in outbound queue 422.

[0066] In some examples, the state of transmitted data packets and rejection messages transmitted by the destination device and received by the source device can be maintained by PCT 470. For example, PCT 470 can maintain packet state information when a data packet is transmitted (at PCT 470 of the source device), received (at PCT 470 of the destination device), and rejected (at PCT 470 of the destination device).

[0067] NIC 400 may also include an inbound delivery engine 450, which provides packet processing when NIC 400 is the source or destination. Inbound delivery engine 450 can receive incoming packets from high-speed network interface 406. Parser 456 can parse the incoming packets and pass the corresponding packet information to list processing engine (LPE) 464 or message status table (MST) 466 for matching. LPE 464 can match incoming messages against buffers. LPE 464 can determine the buffer and starting address to use for each message. LPE 464 can also manage a pool of list entries 462 used to represent buffers, as well as unexpected messages. MST 466 can store matching results and information needed to generate destination completion events. MST 466 can be used by unrestricted operations, including multi-packet PUT commands and single-packet and multi-packet GET commands.

[0068] Subsequently, parser 456 can store the packet in packet buffer 454. Inbound delivery engine 450 can obtain the matching results for conflict checking. Then, direct memory access (DMA) write and atomic memory operation (AMO) module 452 can issue updates generated by DMA write and AMO operations to memory. If the packet includes a command to generate a target memory read operation (e.g., a GET response), the packet can be passed to outbound delivery engine 440. NIC 400 may also include event engine 416, which can receive requests to generate event notifications from other modules or units in NIC 400. Event notifications can specify the generation of fill events or count events. Event engine 416 can manage an event queue located in host processor memory, and write complete events to that host processor memory. Event engine 416 can forward count events to command queue unit 430.

[0069] Figure 5 A block diagram of an example computer system 500 is depicted, in which various examples of the examples described herein may be implemented. The computer system 500 includes a bus 502 or other communication mechanism for transmitting information, and one or more hardware processors 504 coupled to the bus 502 for processing information. The one or more hardware processors 504 may be, for example, one or more general-purpose microprocessors.

[0070] Computer system 500 also includes main memory 506 (such as random access memory (RAM), cache, and / or other dynamic storage devices) coupled to bus 502 for storing information and instructions to be executed by one or more processors 504. Main memory 506 may also be used to store temporary variables or other intermediate information during the execution of instructions to be executed by processor 504. When such instructions are stored in storage media accessible to processor 504, computer system 500 becomes a dedicated machine customized to perform the operations specified in the instructions.

[0071] Computer system 500 further includes read-only memory (ROM) 508 or other static storage devices coupled to bus 502 for storing static information and instructions of processor 504. Storage devices 510, such as disks, optical discs, or USB thumb drives (flash drives), are provided and coupled to bus 502 for storing information and instructions.

[0072] Computer system 500 can be coupled to display 512, such as a liquid crystal display (LCD) (or touchscreen), via bus 502 for displaying information to a computer user. Input device 514, including alphanumeric keys and other keys, is coupled to bus 502 for transmitting information and command selections to processor 504. Another type of user input device is cursor control 516, such as a mouse, trackball, or arrow keys, for transmitting directional information and command selections to processor 504 and for controlling cursor movement on display 512. In some examples, the same directional information and command selections as with cursor control can be implemented via receiving touch on the touchscreen without a cursor.

[0073] The computing system 500 may include a user interface module for implementing a GUI, which may be stored as executable software code executed by one or more computing devices in a mass storage device. By way of example, this module and other modules may include components such as software components, object-oriented software components, class components, and task components; processes; functions; properties; programs; subroutines; program code segments; drivers; firmware; microcode; circuits; data; databases; data structures; tables; arrays; and variables.

[0074] Generally, terms such as “component,” “engine,” “system,” “database,” and “data storage area” as used herein can refer to logic implemented in hardware or firmware, or to a set of software instructions written in programming languages ​​such as Java, C, or C++, which may have entry and exit points. Software components can be compiled and linked into an executable program, installed in a dynamic link library, or written in interpreted programming languages ​​such as BASIC, Perl, or Python. It will be understood that software components can be invoked from other components or from themselves, and / or can be invoked in response to detected events or interrupts. Software components configured to execute on a computing device can be provided on computer-readable media such as optical discs, digital video discs, flash drives, magnetic disks, or any other tangible media, or can be provided as digital downloads (and can be stored originally in a compressed or installable format that needs to be installed, decompressed, or decrypted before execution). Such software code can be stored, in part or in whole, on a memory device executing the computing device for execution by the computing device. Software instructions can be embedded in firmware such as EPROM. It will be further understood that hardware components may include connection logic units such as gates and flip-flops, and / or may include programmable units such as programmable gate arrays or processors.

[0075] Computer system 500 may implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic. This custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic, combined with the computer system, enable computer system 500 to be a special-purpose machine or to be programmed as such. According to one example, the techniques of this invention are executed by computer system 500 in response to one or more processors 504 executing one or more sequences of one or more instructions contained in main memory 506. Such instructions may be read into main memory 506 from another storage medium, such as storage device 510. Execution of the sequence of instructions contained in main memory 506 causes one or more processors 504 to perform the process steps described herein. In alternative examples, hardwired circuitry may be used in place of or in combination with software instructions.

[0076] As used herein, the term "non-transitory media" and similar terms refer to any medium that stores data and / or instructions that enable a machine to operate in a particular manner. Such non-transitory media can include non-volatile media and / or volatile media. Non-volatile media include, for example, optical discs or magnetic disks, such as storage device 510. Volatile media include dynamic memory, such as main memory 506. Common forms of non-transitory media include, for example, floppy disks, floppy disks, hard disks, solid-state drives, magnetic tape or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a perforated pattern, RAM, PROMs and EPROMs, flash EPROMs, NVRAMs, any other memory chips or cartridges, and networking versions of these media.

[0077] Non-transient media differ from transmission media but can be used in conjunction with them. Transmission media participate in the transmission of information between non-transient media. For example, transmission media include coaxial cables, copper wires, and optical fibers, including conductors containing bus 502. Transmission media can also take the form of sound waves or light waves, such as those generated during radio wave and infrared data communication.

[0078] Computer system 500 also includes a communication interface 518 coupled to bus 502. Communication interface 518 provides bidirectional data communication coupled to one or more network links connected to one or more local networks. For example, communication interface 518 may be an Integrated Services Digital Network (ISDN) card, a cable modem, a satellite modem, or a modem for providing data communication connectivity to a corresponding type of telephone line. As another example, communication interface 518 may be a Local Area Network (LAN) card for providing data communication connectivity to a compatible LAN (or a WAN component communicating with a WAN). Wireless links may also be implemented. In any such implementation, communication interface 518 transmits and receives electrical, electromagnetic, or optical signals carrying streams of digital data representing various types of information.

[0079] Network links typically provide data communication to other data devices via one or more networks. For example, a network link can provide a connection from a local network to a host computer or to a data device operated by an Internet Service Provider (ISP). The ISP, in turn, provides data communication services through a global packet data communication network now commonly referred to as the "Internet." Both local networks and the Internet use electrical, electromagnetic, or optical signals that carry streams of digital data. Signals through various networks, as well as signals on network links and signals through communication interface 518 (which carries digital data to and from computer system 500), are example forms of transmission media.

[0080] Computer system 500 can send messages and receive data including program code through one or more networks, network links, and communication interfaces 518. In the Internet example, the server can transmit application request code through the Internet, ISP, local network, and communication interface 518.

[0081] The received code may be executed by processor 504 and / or stored in storage device 510 or other non-volatile storage device for later execution upon receipt.

[0082] Each of the processes, methods, and algorithms described in the preceding sections can be implemented in code components executed by one or more computer systems or computer processors, including computer hardware, and can be fully or partially automated by these code components. The one or more computer systems or computer processors can also operate to support the execution of related operations in a “cloud computing” environment or as “Software as a Service (SaaS)”. These processes and algorithms can be implemented, partially or fully, in a dedicated circuit. The various features and processes described above can be used independently of each other or can be combined in various ways. Different combinations and sub-combinations are intended to fall within the scope of this disclosure, and certain method blocks or process blocks may be omitted in some embodiments. The methods and processes described herein are not limited to any particular order, and blocks or states associated with these methods and processes can be executed in a suitable other order, or can be executed in parallel, or can be executed in some other way. Blocks or states can be added to or removed from the disclosed examples. The execution of certain operations or processes can be distributed across computer systems or computer processors, so that they are not confined to a single machine but deployed across multiple machines.

[0083] As used herein, circuits can be implemented using any form of hardware, software, or a combination thereof. For example, one or more processors, controllers, ASICs, PLAs, PALs, CPLDs, FPGAs, logic components, software routines, or other mechanisms can be implemented to constitute a circuit. In implementations, the various circuits described herein can be implemented as discrete circuits, or the described functions and features can be shared partially or wholly among one or more circuits. Although various features or functional elements can be described or claimed individually as separate circuits, these features and functions can also be shared within one or more common circuits, and such description should not require or imply the need for separate circuits to implement such features or functions. In cases where software is used to implement the circuit wholly or partially, such software can be implemented to operate in conjunction with a computing or processing system (such as computer system 500) capable of performing the functions described with respect to the software.

[0084] As used herein, the term “or” can be interpreted in an inclusive or exclusive sense. Furthermore, descriptions of resources, operations, or structures in the singular form should not be construed as excluding the plural. Unless expressly stated otherwise, or understood otherwise in the context in which they are used, conditional language (among others, such as “can,” “may,” “possibly,” or “may”) is generally intended to convey that certain examples include certain features, elements, and / or steps while others do not.

[0085] Unless otherwise expressly stated, the terms and phrases used in this document, and their variations thereof, should be interpreted as open-ended rather than restrictive. Adjectives and terms with similar meanings, such as “traditional,” “customary,” “normal,” “standard,” “known,” etc., should not be interpreted as limiting the described items to those available for a given period of time or prior to a given time, but should be understood to encompass traditional, customary, normal, or standard techniques that may be available or known at any time now or in the future. In some cases, the presence of broad words and phrases (such as “one or more,” “at least,” “but not limited to,” or other similar phrases) should not be interpreted as indicating an intention or requirement for a narrower scope where such broad phrases may not exist.

Claims

1. A method for establishing a communication connection between devices, comprising: A series of data packets are transmitted from the source device to the target device, and at least one of the data packets includes a first shared token; The first communication connection between the source device and the target device is closed immediately via the communication network, and the first shared token is stored by the target device after the first communication connection is closed; The source device encrypts a portion of a first data packet, corresponding to a request from the source device, using a key stored at the network interface card (NIC) of the source device. The source device initiates a second communication connection at a second time after the first time. The source device transmits the first data packet destined for the target device to the target device, and the first data packet includes a first shared token in the encrypted portion of the first data packet; The source device receives a rejection message from the target device in response to the transmission of the first data packet, the rejection message including a second shared token in the encrypted portion of the rejection message; The source device decrypts the rejection message to determine the second shared token; as well as A third communication connection is established between the source device and the target device via the communication network to transmit a second data packet including the second shared token.

2. The method as described in claim 1, wherein, When the first data packet is transmitted, the first communication connection and the second communication connection between the source device and the target device are inactive.

3. The method as described in claim 1, wherein, The rejection message is based on the expiration of the first shared token.

4. The method of claim 1, wherein, The first shared token and the second shared token correspond to the serial numbers established during the previous connection between the source device and the target device.

5. The method of claim 1, wherein, The first shared token and the second shared token correspond to the current time synchronized across the source device and the target device.

6. The method of claim 1, wherein, The first shared token and the second shared token correspond to a list of available tokens, wherein the use of each available token is tracked by the source device and the target device.

7. The method of claim 1, wherein, The key is delivered from the key server before the first data packet is transmitted using the second communication connection.

8. The method of claim 1, wherein, The key is transmitted as an encryption key.

9. A source device, comprising: Memory; as well as A processor configured to execute machine-readable instructions stored in the memory, which, when executed by the processor, cause the processor to perform the following operations: A series of data packets are transmitted from the source device to the target device, and at least one of the data packets includes a first shared token; The first communication connection between the source device and the target device is closed immediately via the communication network, and the first shared token is stored by the target device after the first communication connection is closed; A portion of a first data packet, corresponding to a request from the source device, is encrypted using a key stored at the network interface card (NIC) of the source device. The source device initiates a second communication connection at a second time after the first time. The first data packet destined for the target device is transmitted to the target device, and the first data packet includes a first shared token in its encrypted portion; The target device receives a rejection message in response to the transmission of the first data packet, the rejection message including a second shared token in its encrypted portion; Decrypt the rejection message to determine the second shared token; as well as A third communication connection is established between the source device and the target device via the communication network to transmit a second data packet including the second shared token.

10. The source device as claimed in claim 9, wherein, When the first data packet is transmitted, the first communication connection and the second communication connection between the source device and the target device are inactive.

11. The source device as claimed in claim 9, wherein, The rejection message is based on the expiration of the first shared token.

12. The source device as claimed in claim 9, wherein, The first shared token and the second shared token correspond to the serial numbers established during the previous connection between the source device and the target device.

13. The source device as claimed in claim 9, wherein, The first shared token and the second shared token correspond to the current time synchronized across the source device and the target device.

14. The source device as claimed in claim 9, wherein, The first shared token and the second shared token correspond to a list of available tokens, wherein the use of each available token is tracked by the source device and the target device.

15. The source device as claimed in claim 9, wherein, The key is delivered from the key server before the first data packet is transmitted using the second communication connection.

16. The source device as claimed in claim 9, wherein, The key is transmitted as an encryption key.

17. A non-transitory computer-readable storage medium storing a plurality of instructions executable by a processor, the plurality of instructions causing the processor to perform the following operations when executed by the processor: A series of data packets are transmitted from the source device to the target device, and at least one of the data packets includes a first shared token; The first communication connection between the source device and the target device is closed immediately via the communication network, and the first shared token is stored by the target device after the first communication connection is closed; A portion of a first data packet, corresponding to a request from the source device, is encrypted using a key stored at the network interface card (NIC) of the source device. The source device initiates a second communication connection at a second time after the first time. The first data packet destined for the target device is transmitted to the target device, and the first data packet includes a first shared token in its encrypted portion; The target device receives a rejection message in response to the transmission of the first data packet, the rejection message including a second shared token in its encrypted portion; Decrypt the rejection message to determine the second shared token; as well as A third communication connection is established between the source device and the target device via the communication network to transmit a second data packet including the second shared token.

18. The non-transitory computer-readable storage medium of claim 17, wherein, When the first data packet is transmitted, the first communication connection and the second communication connection between the source device and the target device are inactive.

19. The non-transitory computer-readable storage medium of claim 17, wherein, The rejection message is based on the expiration of the first shared token.

20. The non-transitory computer-readable storage medium of claim 17, wherein, The first shared token and the second shared token correspond to the serial numbers established during the previous connection between the source device and the target device.

Images