Flexible verification of source identifiers

Abstract

The present disclosure generally relates to flexible verification of source identifiers. Systems and methods are provided for validating identifiers using a dynamic matching scheme, including software defined matching or hardware validated matching. The software-defined match may determine whether the two identifiers are logically identical when the two identifiers are both generated by the software application and match each other, and the hardware verification match may determine whether an identifier provided by a message tagging process generated by a hardware component of the device matches a second identifier. When a device sends a communication in a network, the flexible verification process may allow a source of a trusted device while releasing trust of a user operating the trusted device or installing software (e.g., an operating system) on the device for temporary use. By independently validating the device by de-trust association and separation from a user operating the device, communications sent and received by the system may accordingly be further trusted or distrusted.

Description

Background Art

[0001] In a traditional system, a network message sent by a source computer is matched with a receive request issued by a receiver computer. This match is performed using a match bit and a source identifier in the message transport layer. The match bit is completely controlled by the user software as part of the traditional packet transmission matching mechanism. These values ​​are provided by the sender / source and the receiver / destination. If the source identifier used in the receiver's buffer matches the identifier contained in the message, the network message is added to the receiver's buffer. These messages can be provided by the sender device to the receiver device. In some cases, the source of the network message identifies itself. In some cases, the source of the network message can be identified by the source device without the user operating the device knowing. In some cases, the receiver needs to know whether the source identifier is trustworthy. This can be problematic when the source device is used by multiple entities, both trusted and untrusted. Better security measures are therefore needed. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] One or more different embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings. The drawings are provided for illustration purposes only and merely depict typical or exemplary embodiments.

[0003] Figure 1 A system for implementing flexible authentication according to some embodiments of the present disclosure is shown.

[0004] Figure 2 A NIC authentication system according to some embodiments of the present disclosure is shown.

[0005] Figure 3 An exemplary process for dynamically verifying a source identifier and adding a corresponding message to a buffer at a receiver device according to some embodiments of the present disclosure is shown.

[0006] Figure 4 An exemplary process for dynamically verifying a source identifier and adding a corresponding message to a buffer at a receiver device according to some embodiments of the present disclosure is shown.

[0007] Figure 5 An exemplary process for dynamically verifying a source identifier and adding a corresponding message to a buffer at a receiver device according to some embodiments of the present disclosure is shown.

[0008] Figure 6 Exemplary computing components are shown that can be used to implement various features of the implementations described in this disclosure.

[0009] Figure 7 A block diagram of an exemplary computer system is shown in which various embodiments described in this disclosure may be implemented.

[0010] The drawings are not exhaustive and are not intended to limit the disclosure to the precise forms disclosed. DETAILED DESCRIPTION

[0011] One way to identify a device user is through a data signature. When using a trusted device, the user can provide their data signature as well as a device identifier. These combined data security mechanisms can prove that the device corresponds to real hardware that is allowed to run in the communication network, and that the user operating the device has access to the device message buffer that receives the network message. In some examples, these network messages are created in user space, and message / buffer matching is performed using information provided by the user. However, this information may be fraudulently provided by the user, and the sender device or the receiver device should not trust this information. Traditional message retrieval programs (e.g., packet switching) may automatically accept information from untrusted devices or users. For example, in traditional packet switching, data is divided into packets with headers and payloads, which are sent over the network. The network hardware uses the data in the header to direct the packet to its destination, and then the operating system or application software at the destination extracts and uses the payload.

[0012] This technical problem can traditionally be solved by installing trusted software (e.g., an agent or operating system) at the device and using the trusted software to send network messages. However, this requires the device to download, install, and maintain software. In addition, when the device is connected to the data center as a client device, the data center must assume a certain degree of trust in the client device, and this assumption may be unfounded. For example, the client device may be a computing node rented to a customer, and the customer may be unknown and untrustworthy, causing the client device to become the customer's host device. Moreover, when network messages are sent via the operating system of the client / host device through downloaded trusted software, traditional systems will cause technical problems, and the operating system will use resources to process and send these messages through the trusted software instead of performing other operations. The performance of the operating system (and the entire client / host device) may be reduced.

[0013] Examples of the systems described herein can abandon the requirement that the host device download trusted software or utilize operating system resources to send additional messages, but instead implement an application programming interface (API) to standardize the format of the sent messages and enhance data security. The process can correspond to the matching scheme at the source device and the confirmation scheme at the target device, which can help verify the identifier in the message. By implementing the matching scheme and the confirmation scheme, the system can completely eliminate the reliance on the operating system, which helps to dynamically verify the source identifier. For example, the system can dynamically determine whether to use software-defined matching or hardware-verified matching to generate an identifier at the source device. When generating an identifier / message, a specific matching scheme can be utilized, and the target device can implement a confirmation scheme when receiving the sent message to confirm the type of matching scheme used when generating the message.

[0014] Various matching schemes may be implemented. Software-defined matching may correspond to a software implementation, i.e., determining whether two identifiers are logically identical when both are generated by a software application and match each other, and hardware-verified matching may include an implementation, i.e., determining whether an identifier provided by a message marking process generated by a hardware component of the device matches a second identifier. The message marking process may be implemented by a NIC in a trusted hardware device. This allows trust in the source of the device having the NIC when the device sends communications in a network, while removing trust in the user who is operating the trusted device or installing software (e.g., an operating system) on it for temporary use.

[0015] The source identifier can uniquely identify the source of the message, including an identification of the host device hardware or software associated with a customer who installs its own software on the host device. In other examples, the format of the source identifier can correspond to the format required by the network API of the host device, including the length or character limit of the identifier. An illustrative example of such an API corresponds to a format including libfabric and references to openfabrics, kfabric, or Portals. In some examples, the format can correspond to a framework that facilitates exporting high-performance network services to applications. In some examples, the format can correspond to an interface between software and structural hardware (e.g., at a kernel). In some examples, the format of the API is associated with its framework or profile.

[0016] The message may also include one or more match scheme selection bits. The one or more match scheme selection bits may exist separately from the source identifier to dynamically determine whether the source device uses software-defined matching or hardware-verified matching. The source device may add the one or more match scheme selection bits and the source identifier (generated by software-defined matching or hardware-verified matching) to the message, which may then be analyzed by the target device to improve system security.

[0017] Technical improvements are implemented throughout the disclosure. For example, the system can allow for implementation of software-defined matching or dynamic definition of hardware-verified matching, where the hardware-verified matching relies on a NIC that is configured to tag outgoing messages with a predefined source identifier, and the software-defined matching uses, for example, one or more matching scheme selection bits to identify a matching scheme. By disassociating the trust and independently verifying the device independently of the user operating the device, communications sent and received by the client device can be further trusted or distrusted accordingly.

[0018] Figure 1 A system for implementing flexible verification of source identifiers according to some embodiments of the present disclosure is shown. In this example, messages corresponding to a set of data packets can be sent and received at various devices, including from a first host 110A to a first NIC 120A to a switch 150 to a second NIC 120B to a second host 110B. A verification system 140 can be implemented at each NIC 120 to help manage flexible verification of source identifiers from host devices 110. Switch 150 is configured to receive and route messages according to a specific message format and reject improperly formatted messages.

[0019] Host devices 110 (shown as first host 110A and second host 110B) are configured to provide hardware and software capabilities to customers. In some examples, host devices 110 can be rented or otherwise used temporarily by customers, including first host device 110A providing rented hardware capabilities to a first customer and second host device 110B providing rented hardware capabilities to a second customer. Customers or system administrators of a data center can load software onto host devices 110, including operating systems or other software functions.

[0020] The host device 110 includes a processor 112 (shown as a first processor 112A in the first host 110A and a second processor 112B in the second host 110B), a memory 114 (shown as a first memory 114A in the first host 110A and a second memory 114B in the second host 110B), and a network application programming interface (API) 116 (shown as a first network API 116A in the first host 110A and a second network API 116B in the second host 110B). The host device 110 is configured as a sender device and a receiver device to send and receive messages, respectively.

[0021] Processor 112 may include a general or special purpose processing engine, such as a microprocessor, controller, or other control logic. Processor 112 may be connected to a bus, but may use any communication medium to facilitate interaction with host device 110 via network API 116 to communicate externally with NIC 120 and other devices (e.g., switch 150 or other host devices).

[0022] Memory 114 may include random access memory (RAM) or other dynamic storage for storing information and instructions to be executed by processor 112. Memory 114 may also be used to store temporary variables or other intermediate information during the execution of instructions to be executed by processor 112. Memory 114 may also include read-only memory ("ROM") or other static storage device coupled to the bus for storing static information and instructions for processor 112.

[0023] The network API 116 is configured to provide a standardized software interface (eg, libfabric) that the processor 112 at the host device 110 can use to send and receive messages. NIC commands can be used to generate, send, and receive messages, as described below.

[0024] NIC 120 (shown as a first NIC 120A and a second NIC 120B) is a network interface card (NIC) that can be embedded in an instance of the authentication system 140, such as Figure 2 NIC 120 is configured to perform various operations associated with sending and receiving communications between host device 110, and is also configured to implement a hardware verification matching process to mark the identifiers described herein (via verification system 140).

[0025] The NIC 120 includes a network interface 122 (shown as a first network interface 122A in the first NIC 120A and a second network interface 122B in the second NIC 120B), a host interface 126 (shown as a first host interface 126A in the first NIC 120A and a second host interface 126B in the second NIC 120B), and an authentication system 140 (shown as a first authentication system 140A in the first NIC 120A and a second authentication system 140B in the second NIC 120B). The NIC 120 enables each host device 110 to communicate via a network using the host interface 126 (e.g., an interface for connecting to a host processor) and the high-speed network interface 122.

[0026] In some examples, the host interface 126 can be a peripheral component interconnect (PCI) interface or a peripheral component interconnect express (PCIe) interface. The host interface 126 can be coupled to the host via a host connection, which can include N (for example, in some chips, N can be 16) PCle Gen 4 channels, which can run at a signaling rate of up to 25Gbps per channel. The host interface 126 can facilitate high-speed network connections. The host interface 126 can use M (for example, in some chips, M can be 4) full-duplex serial channels to run at a total rate of 100Gbps or 200Gbps. Each of these M channels can run at a rate of 25Gbps or 50Gbps based on non-return-to-zero (NRZ) modulation or pulse amplitude modulation 4 (PAM4), respectively. The high-speed network interface 122 may support the Institute of Electrical and Electronics Engineers (IEEE) 802.3 Ethernet-based protocol and an enhanced frame format that provides support for higher rate small messages.

[0027] NIC 120 may support one or more of the following: point-to-point message passing based on Message Passing Interface (MPI), remote memory access (RMA) operations, offloading and progress of bulk data collection operations, and Ethernet packet processing. When the host device 110 sends an MPI message, NIC 120 may match the corresponding message type. In addition, NIC 120 may implement the Eager protocol and the Rendezvous protocol of MPI, thereby offloading the corresponding operations from the host device 110.

[0028] In addition, the RMA operations supported by NIC 120 may include PUT, GET, and Atomic Memory Operations (AMO). NIC 120 may provide reliable transmission by providing a connection-based error detection and retry mechanism for ordered operations that can manipulate the target state. The hardware of NIC 120 may maintain the state required for the retry mechanism.

[0029] The NIC 120 may facilitate the progression of trigger operations, general offload mechanisms, and related sequences of operations, such as bulk data collection. The NIC 120 may support a network API 116 (e.g., a libfabric API) that facilitates network communication services for the host device 110. The NIC 120 may also support low-level network programming interfaces, such as a Portal API (not shown). In addition, the NIC 120 may provide efficient Ethernet packet processing.

[0030] The verification system 140 is configured to verify messages sent from a sender device (first host 110A) to a receiving device (second host 110B), including, for example, verifying the source of the message. The verification system 140 may verify the source of a data packet using a source identifier.

[0031] For ease of explanation, the use of Figure 1 The components described in the example of sending and receiving a set of data packets via a network are as examples of messages. For example, the egress port of the first host 110A can send a data packet via the ingress port 128A of the host interface 126A at the first NIC 120A. The verification system 140A of the first NIC 120A can verify the data packet. The egress port of the network interface 122A of the first NIC 120A can inject the data packet into the network via the switch 150. The data packet can be received from the network via the ingress port 125B of the network interface 122B at the second NIC 120B. The verification system 140B of the second NIC 120B can verify the data packet. The egress port of the host interface 126B can send the data packet to the second host 110B.

[0032] Figure 2 An authentication system of a NIC according to some embodiments of the present disclosure is shown. The authentication system 200 may be an example of an implementation of a first authentication system 140A of a first NIC 120A and a second authentication system 140B of a second NIC 120B.

[0033] The verification system 200 may include a machine-readable medium having one or more interfaces, circuits, and modules for implementing the functions of the verification system 200 discussed herein. For example, the machine-readable medium may carry one or more sequences of one or more instruction processors for execution. Such instructions contained on the machine-readable medium may cause the verification system 200 to perform the features or functions of the disclosed technology. For example, the interfaces, circuits, and modules of the machine-readable medium may include, for example, a format recognition module 210, a verification selection module 220, a transmitter module 230, a receiver module 240, a software-defined matching engine 250, and a hardware verification matching engine 260.

[0034] The format identification module 210 is configured to receive a first format of an application programming interface (API), the API comprising Figure 1 The network API 116 at the host device 110 in the example of FIG. 116. For example, the host device may select a system environment for implementing a particular scheme for source identifier verification. The system environment may vary depending on the intended use of the environment by the host / client.

[0035] The format identification module 210 is also configured to generate an identifier, wherein the format of the identifier conforms to the message format. The NIC 200 associated with the sender host device can determine the source identifier and one or more matching scheme selection bits to be included in the sent message, while some traditional systems may limit the identifier to the MAC address or other predefined identifier of the host device. This is a technical solution to technical problems involving computer user identification, because the source identifier can help identify the difference between two users working on the same host device, while the MAC address only identifies the host device and does not distinguish between the user / operator of the device at a particular time.

[0036] The format of the source identifier may vary depending on the implementation. For example, the format may limit the incoming message to contain a 32-bit identifier. The network API may follow a predefined format to define the identifier. A portion of the message format may be reserved as one or more matching scheme selection bits to identify the type of matching scheme to be implemented (e.g., software-defined matching or hardware verification matching), and the remainder of the message may be reserved for the source identifier associated with the source client device. In other examples, the source identifier is selected by a client operating the host device or an administrative user of the host device, including by utilizing a logical endpoint identifier (e.g., IP address) and PID, a physical endpoint identifier (e.g., MAC address or network address) and PID, a token unique within the scope of an application or service, and an identifier generated using information provided by the user software for finding a source identifier or token. In some examples, such as in software-defined matching, the API may define the format of the source identifier. In another example, the sender device or receiver device may be numbered (e.g., zero to N minus one), and the software may determine the value of each of these devices. The receiver device may recognize the value reserved for sender / receiver communication and accept the communication when the communication from the sender device contains the value.

[0037] The source identifier may be stored at the control plane as part of a "communication profile," which may correspond to a NIC data structure that stores the protected state associated with the client. A device may support multiple communication profiles, and the system itself may control whether the communication profile is programmable by the operating system, a user of the host device, or remotely by a management system in the data center.

[0038] In some examples, the use of source identifiers can also be implemented using a specific operating system (OS). For example, a trusted OS can store certificates or signatures that meet government requirements. When the operating system is trusted, it can program the source identifier using a communication profile that is accessed when the device starts or loads its driver. The management system can allow read-only or read / write access to the communication profile (for example, the operating system can set the source identifier by writing to the communication profile). When the operating system is not trusted, that is, when a trusted data center provides hardware as bare metal and lacks corresponding trusted software, any write access to the communication profile can be prohibited, and the management system programs the source identifier of each NIC / host device.

[0039] In some examples, the format of the source identifier can be divided into sub-parts that the host device can use to identify the type of matching scheme to be implemented in this environment, as further described in conjunction with the verification selection module 220. For example, the source identifier can include one or more matching scheme selection bits and identifiers provided by the transmitter and receiver in user space (e.g., associated with the device's transport layer) so that their combined length conforms to the message format. In other examples, one or more matching scheme selection bits can be reserved to identify the type of matching scheme to be implemented (e.g., software-defined matching or hardware-verified matching), and the remaining bits can be reserved for source identifiers generated by software-defined matching or hardware-verified matching.

[0040] The verification selection module 220 is configured to determine the type of matching scheme to be used in the transmission. In some examples, the matching scheme can be dynamically determined to use software-defined matching or hardware-verified matching. When the source identifier is included in the message, the message can include one or more matching scheme selection bits and the source identifier in a separate field, or the source identifier can include both the identifier and the one or more matching scheme selection bits. In either example, the one or more matching scheme selection bits can be used to identify whether a software-defined match or a hardware-verified match is merged with a predefined data format.

[0041] Verification selection module 220 is further configured to generate a message including one or more matching scheme selection bits for identifying whether to implement software-defined matching or hardware verification matching, and an identifier associated with a message source (eg, host device 110 ).

[0042] In some examples, a user operating the host device 110 can select a matching scheme from a user interface that identifies a trusted or untrusted environment provided to the customer via the host device 110, and the selection can be sent to the corresponding NIC for analysis and implemented by the verification selection module 220. The customer can load an operating system to the host device 110 and then to a trusted host device to rely on software-defined matching. In other examples, the system can default to a zero-trust environment utilizing the host device 110 that implements hardware verification matching, rather than trusting access to the communication profile storing the identifier.

[0043] The transmitter module 230 is configured to receive a message from a transmitter host device (the first host device 110A) and identify a switch for transmitting the message to a specific receiver host device ( Figure 1 The switch 150 in FIG. 1 ). The transmitter module 230 may transmit the message.

[0044] The receiver module 240 is configured to receive a message from a switch (switch 150) and identify a receiver host device (second host device 110B) used to send the message. As an illustrative example, the first host device 110A may act as a message sender and use the transmitter module 230 for a particular message, while the second host device 110B may act as a message receiver and use the receiver module 240 for a particular message.

[0045] The receiver module 240 can utilize a target side buffer that accepts message transmissions based on a source identifier and a traditional packet switching match bit. A message is matched to a buffer when the source identifier in the buffer at the receiver device receiving the message matches the source identifier carried in the message.

[0046] The software-defined matching engine 250 is configured to reserve a subset of source identifier bits to define identifiers to be matched between messages sent by a sender host device (e.g., first host device 110A). For example, as discussed herein in conjunction with software-defined matching, the identifier format may be defined by the network API 116 at the host device 110 for incoming and outgoing messages.

[0047] The source identifier can be determined by various methods. For example, the sender device or receiver device can be numbered (e.g., zero to N minus one), and the software-defined matching engine 250 can determine a value for each of these host devices. In other examples, the source identifier is selected by the user, including by utilizing a logical endpoint identifier (e.g., an IP address) and a process identifier (PID), an endpoint identifier (e.g., a MAC address or network address) and a PID, a token that is unique within the scope of an application or service, and an identifier generated using information provided by the user software for looking up a source identifier or token. The receiver device can recognize a value reserved for sender / receiver communications and accept communications when communications from the sender device contain that value.

[0048] The hardware verification matching engine 260 is configured to generate a message including one or more matching scheme identifier bits for identifying whether a software-defined match or a hardware verification match is implemented, and an identifier associated with a message source (e.g., the host device 110). The identifier may include a hardware verification bit, a process identifier (PID), and an endpoint identifier (NID).

[0049] In hardware verification matching, the hardware verification matching engine 260 marks a predefined value as a source identifier of all outgoing messages. The NIC 200 using the hardware verification matching engine 260 is configured to use the source identifier to mark messages. The marking process can be associated with a minimum trust that the device sending the communication is a trusted device without also trusting the user operating the device or the software running on the device. In some examples, the message marking process can be configured to implement a control plane function that marks the source identifier on the message. Even if the user upgrades management privileges or control functions in the local operating system, the host device may not be able to implement the message marking process.

[0050] The control plane of the sender device may store a communication profile including a source identifier. The communication profile may not be accessible to a client operating system of the client device or a user operating the device. The communication profile may store an identifier associated with a hardware verification match, and the communication profile may not be accessed when a hardware verification match is achieved.

[0051] The data center system may rely on a message tagging process performed by the hardware verification matching engine 260, which may render the communication profile unnecessary during the hardware verification matching phase. In other words, some examples of the data center system may store the full identifier in the communication profile (e.g., a 32-bit identifier containing one bit of the profile and the remaining 31 bits for software-defined matching / hardware verification matching), and some examples of the data center system may store the full identifier in the NIC, and the message tagging process may add the identifier during the hardware verification matching phase.

[0052] In hardware verification matching, the NIC associated with the sender device marks a predefined value as an identifier of the outgoing message. The hardware component can be embedded with the sender device when the device is manufactured. In some examples, the NIC can be associated with a minimum trust that the device sending the communication is a trusted device, without also trusting the user operating the host device or the software running on the host device.

[0053] The message marking process can mark the source identifier to the outgoing message as part of the control plane function of the NIC. The message marking process can only be implemented on hardware components (such as NICs) of previously trusted types. Even if the user upgrades administrative privileges or control functions in the local operating system, the host-side software may not be able to implement the message marking process. In some examples, the control plane function of the NIC can perform other operations, including restricting the use of traffic classes, adding traffic in the overlay network, or applying access control rules.

[0054] In practice, when a receiver device receives a message, the receiver device checks one or more match scheme selection bits generated based on a particular match scheme, for example to determine a corresponding confirmation scheme (e.g., software-defined matching or hardware-verified matching) to be implemented to help verify the source of the message. Other bits may be preliminarily reviewed without departing from the essence of the present disclosure. The remaining bits may be checked to determine the source identifier of the sender device. The NIC associated with the receiver device implements a corresponding procedure associated with the confirmation scheme and determines whether the messages all originate from a specific user and sender device, or from different trusted / untrusted sender devices.

[0055] In some examples, the functionality of the software-defined matching engine 250 and the hardware-verified matching engine 260 can be combined to provide a specific matching scheme selection mechanism (using one or more matching scheme selection bits added to the message) and hardware predefined identifier tags to form a trust hierarchy that can improve the security of messages sent in the system. In some examples, the hierarchy can be determined by the API of the data center system and is not permanently associated with the device because the various devices in the communication path are providing verification of the authenticity of the message based on a predefined format. In addition, by using hardware-verified matching, the trust hierarchy implemented by the system may not need to rely on a trusted operating system of the user device, a software application of the user device (e.g., a kernel driver or a sender operating system), or the identifier itself. In addition, the system can support multiple communication profiles or equivalent devices that store the control plane state of each device / NIC to allow different applications or services to identify themselves in different ways without imposing additional processing burden on the sending device.

[0056] Figure 3 FIG. 1 shows a verification process in a second system environment according to some embodiments of the present disclosure. In this example, Figure 3 The first NIC 310 and the second NIC 320 shown can be respectively connected to Figure 1 The first NIC at client device 130A and the second NIC at client device 130B are shown to correspond.

[0057] At block 330, the first NIC 310 may determine the format of the API. For example, the format of the messages accepted by the API may be predetermined to operate within the constraints of an existing API. In other examples, the format of the source identifier may correspond to the format required by the network API of the host device, including length or character restrictions on the identifier. The format may be associated with a framework or profile of the API, or include a specific format, such as libfabric, kfabric, or Portals.

[0058] In some examples, the first NIC 310 may access the communication profile. This is at least an optional step of the process. For example, the logical matching scheme may not access the communication profile. Instead, the system may select a logical matching scheme and use its own source identifier instead of any identifier stored with the communication profile. The NIC of the source device may determine that the logical matching scheme is selected and does not interfere with the contents of the communication profile.

[0059] In some examples, the communication profile may be stored in a NIC associated with the first NIC 310 and include a source identifier associated with the first NIC 310. The identifier may conform to a format required by the API and be limited to a specific length (e.g., 32 bits). In some examples, the control plane of the first NIC 310 may store the identifier in the communication profile. By limiting control plane access to the communication profile, a client operating system of a client device or a user operating the device may not be able to access the communication profile.

[0060] At block 334, the first NIC 310 may generate an identifier using software-defined matching. Software-defined matching may generate the identifier using software to determine a logical endpoint identifier (e.g., an IP address) and PID, a physical endpoint identifier (e.g., a MAC address or network address) and PID, a token that is unique within the scope of an application or service, or an identifier generated using information provided by user software to look up a token associated with the first host device 310.

[0061] At block 336, the first NIC 310 may send the identifier in the message along with one or more matching scheme selection bits to the second NIC 320. The matching bits may identify a software defined match as the confirmation scheme to be used by the receiver in the reserved portion of the identifier.

[0062] At block 340, the second NIC 320 may receive the message. A temporary buffer at the second NIC 320 may receive and store the message. In some examples, packets of the message are saved in temporary storage within the NIC while the system determines a matching scheme to use and performs matching.

[0063] At box 342, the second NIC 320 can determine that the first NIC 310 uses software-defined matching to generate an identifier or message based on one or more matching scheme selection bits in the message. For example, the second NIC 320 can determine that one or more matching scheme selection bits are included in the sent message, while some traditional systems may limit the identifier to the MAC address or other predefined identifier of the host device. A portion of the message format can be reserved as one or more matching scheme selection bits to identify the type of matching scheme to be implemented (e.g., software-defined matching or hardware-verified matching), and the remainder of the message can be reserved for a source identifier associated with the source client device. The second NIC 320 can identify the format of the message including the one or more matching scheme selection bits to confirm that the message is a format reserved for communications from a trusted source. When the message includes this value, the second NIC 320 can accept the communication.

[0064] At box 344, the second NIC 320 can use a confirmation scheme based on the recognition of the identifier generated using software-defined matching. For example, the confirmation scheme can determine whether the message is from a specific user and sender device, or from different trusted / untrusted sender devices, by confirming that one or more matching scheme selection bits are in the correct position / format and that the format / value of the source identifier matches the device sending the message. The message may be rejected or passed to higher-level software. When the source of the message cannot be verified, the higher-level software can receive the message. For example, in a client-server application, the server can take different actions depending on whether it can trust the source of the message.

[0065] At block 346, the second NIC 320 may add the message to a buffer at the second NIC 320 for software-defined matching. For example, when a source identifier in the buffer at the second NIC 320 matches a source identifier carried in the message, data packets of the message are added to the buffer (e.g., for processing).

[0066] Figure 4 FIG. 1 shows a verification process in a third system environment according to some embodiments of the present disclosure. In this example, Figure 4 The first NIC 410 and the second NIC 420 shown can be respectively connected to Figure 1 The first NIC at device 130A and the second NIC at device 130B are shown to correspond.

[0067] Similar to at block 330 , at block 430 , the first NIC 410 may determine the format of the API.

[0068] At box 432, the first NIC 410 can determine a hardware verification match and the use of a match bit. For example, a hardware verification match relies on the configuration of the first NIC 410 to mark the outgoing message with a predefined source identifier, and also add a match bit separate from the source identifier to identify that a hardware verification match is used. The source device can add the match bit and the source identifier to the message. Once a hardware verification match is identified for the first NIC 410, the first NIC 410 can determine the source identifier based on a message marking process generated by the hardware components of the device. The first NIC 410 can determine to identify its message source as a hardware verification match or a software-defined match, or use a default determination (e.g., configured to always use hardware verification).

[0069] At block 434, the first NIC 410 may initiate a message marking process for marking messages with an identifier based on the hardware verification matching process. The message marking process may be implemented by a NIC associated with the first NIC 410 to mark a predefined value as an identifier for all incoming and outgoing messages. For example, the marking process may mark a predefined value stored at a secure location on the first NIC 410 as a source identifier for all outgoing messages. The marking process may be associated with a minimum level of trust that the device sending the communication is a trusted device (e.g., using the first NIC 410 that has access to the predefined value), without also trusting a user operating the device or software running on the device.

[0070] In some examples, the message marking process can be configured to implement a control plane function that marks a source identifier on a message, such that (e.g., even when a user escalates administrative privileges or control functions in a local operating system) a host device may not be able to implement the message marking process. A control plane associated with the first NIC 410 can store an identifier associated with a hardware verification match that is used during the marking process, and the function of the control plane can be implemented to initiate the marking process of marking the identifier on a data packet.

[0071] At block 436, the first NIC 410 may send the identifier along with one or more match scheme selection bits (e.g., different from the match bits) in a message to the second NIC 420. The one or more match scheme selection bits may identify a hardware verified match as a confirmation scheme to be used by the receiver in the reserved portion of the identifier.

[0072] At block 440, the second NIC 420 may receive the message. A temporary buffer at the second NIC 420 may receive and store the message. In some examples, packets of the message are saved in temporary storage within the NIC while the system determines a matching scheme to use and performs matching.

[0073] At block 442, the second NIC 420 may determine that the first NIC 410 used hardware verification matching based on one or more matching scheme selection bits in the message. The second NIC 420 may identify the format of the message including the one or more matching scheme selection bits to confirm that the message has a format reserved for communications from a trusted source. When the message includes this value, the second NIC 420 may accept the communication and discard / reject any communication that does not conform to the format of the message including the one or more matching scheme selection bits and the identifier.

[0074] Similar to at block 344, at block 444, the second NIC 420 may use a confirmation scheme based on the identification of the identifier generated using hardware verification matching. The message may be rejected or passed to higher-level software. The higher-level software may receive the message when the source of the message cannot be verified. For example, in a client-server application, the server may take different actions depending on whether it can trust the source of the message.

[0075] At block 446, the second NIC 420 may add the message to a buffer at the second NIC 420 for hardware-defined matching. For example, when a source identifier in the buffer at the second NIC 420 matches a source identifier carried in the message, data packets of the message are added to the buffer (e.g., for processing).

[0076] Figure 5 FIG. 1 shows a verification process in a third system environment according to some embodiments of the present disclosure. In this example, Figure 5 The first NIC 510 and the second NIC 520 shown can be respectively connected to Figure 1 The first NIC at client device 130A and the second NIC at client device 130B are shown to correspond.

[0077] Similar to block 330 , at block 530 , the first NIC 510 may determine the format of the API.

[0078] At block 532, the first NIC 510 may determine that a dynamic implementation of hardware-verified matching or software-defined matching may depend on the client's use of the data center system relative to the client's use of its computing nodes. The system environment may vary depending on the client's intended use of the environment.

[0079] In the first system environment, the host device trusts the operating system installed from the client entity. The client can manage the system and trust the operating system they installed. The implementation can also trust the host device (hardware) itself, which is configured to execute instructions to run the operating system on behalf of the client. The NIC of the host device can implement a message marking process for hardware verification matching, and the operating system can provide an identifier used by the NIC as part of the job startup. Since the trust hierarchy is identified in this environment, the user is allowed to access the communication profile storing the identifier (e.g., marked on the device as part of the hardware verification matching process). In some examples, the operating system can write the identifier to the communication profile through a critical section routine (Critical Section Routine, CSR) (e.g., a code segment where the process obtains an exclusive lock so that no other process can execute it at the same time), but due to the message marking process implemented, the communication profile may not need to be used.

[0080] In a second system environment, the operating system installed by the user at the host device is not trusted because the host device hardware may be rented by an unknown user (for example, in a bare metal environment). Such a system can allow a customer to install software on a rented computing node. The computing node may include a NIC configured with the message marking process described herein. The system can limit read-only access to the communication configuration file by the operating system installed on the device and provide additional security through the message marking process. Write access can be prohibited to improve the data security of the environment and continue to allow the operating system to run in the environment. The management system programs the source ID for each NIC as part of the device or job initialization.

[0081] In a third system environment, physical security in the data center is at risk, and each communication sent with software-defined matching or hardware-authenticated matching may be further encrypted and unreadable by users in the data center. Data traffic may be encrypted to help prevent access to data through physical devices. Communication profiles and access to other data may be managed based on the zero trust scenario discussed above. Data center administrators may leave settings unchanged. Users may be allowed to view their own data traffic. Encryption is implemented to prevent illegal devices from being inserted into the data center system.

[0082] Similar to blocks 334 and 434 , at block 534 , the first NIC 510 may generate a message identifier based on selecting a hardware-verified match or a software-defined match.

[0083] At block 536, the first NIC 510 may send the identifier in a message along with one or more matching scheme selection bits to the second NIC 520. The one or more matching scheme selection bits may identify the selected matching scheme as the confirmation scheme to be used by the receiver.

[0084] Similar to block 340 , at block 540 , the second NIC 520 may receive the message.

[0085] Similar to blocks 342 and 442 , at block 542 , the first NIC 520 may determine a matching scheme based on one or more matching scheme selection bits in the message.

[0086] Similar to blocks 344 and 446 , at block 544 , the second NIC 520 may add the message to a buffer at the second NIC 520 for the selected matching scheme.

[0087] It should be noted that the terms "optimize," "optimal," and the like as used herein may be used to mean making or achieving a performance as efficient or perfect as possible. However, as one of ordinary skill in the art reading this document will recognize, perfection is not always achievable. Thus, these terms may also encompass making or achieving a performance as good or efficient or practical as possible under given circumstances, or making or achieving a performance that is better than that achievable with other settings or parameters.

[0088] Figure 6 Exemplary computing components that can be used to implement the processes and devices described herein are shown. Figure 6 , the computing component 600 can be, for example, a server computer, a controller, or any other similar computing component capable of processing data. Figure 6 In the exemplary embodiment shown, computing component 600 includes a hardware processor 602 and a machine-readable storage medium 604 .

[0089] The hardware processor 602 may be one or more central processing units (CPUs), semiconductor-based microprocessors, and / or other hardware devices suitable for retrieving and executing instructions stored in the machine-readable storage medium 604. The hardware processor 602 may fetch, decode, and execute instructions, such as instructions 606 to 610, to control processes or operations for implementing a dynamically modular and customizable computing system. As an alternative or in addition to retrieving and executing instructions, the hardware processor 602 may include one or more electronic circuits including electronic components for performing the functions of one or more instructions, such as a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or other electronic circuits.

[0090] A machine-readable storage medium, such as machine-readable storage medium 604, may be any electrical, magnetic, optical, or other physical storage device that contains or stores executable instructions. Thus, machine-readable storage medium 604 may be, for example, a random access memory (RAM), a non-volatile RAM (NVRAM), an electrically erasable programmable read-only memory (EEPROM), a storage device, an optical disk, or the like. In some embodiments, machine-readable storage medium 604 may be a non-transitory storage medium, wherein the term "non-transitory" does not encompass transient propagating signals. As described in detail below, machine-readable storage medium 604 may be encoded with executable instructions, such as instructions 606 to 610.

[0091] Hardware processor 602 may execute instructions 606 to receive the format of the API. For example, the format required by the network API of the host device may include a length or character limit for an identifier corresponding to a message sender or message source.

[0092] The hardware processor 602 may execute instructions 608 to generate an identifier and one or more matching scheme selection bits. In some examples, the one or more matching scheme selection bits correspond to a confirmation scheme. In some examples, the format of the source identifier may vary depending on the implementation. For example, the format may limit the incoming message to contain a 32-bit identifier. The network API may define the identifier in accordance with a predefined format. A portion of the message format may be reserved as one or more matching scheme selection bits to identify the type of matching scheme to be implemented (e.g., software-defined matching or hardware-verified matching), and the remainder of the message may be reserved for the source identifier associated with the source client device. In other examples, the source identifier is selected by a client operating the host device or an administrative user of the host device, including by utilizing a logical endpoint identifier (e.g., an IP address) and PID, a physical endpoint identifier (e.g., a MAC address or a network address) and PID, a token unique within the scope of an application or service, and an identifier generated using information provided by the user software for finding a source identifier or token.

[0093] The hardware processor 602 may execute instructions 610 to send one or more matching scheme selection bits and an identifier from the first NIC to the second NIC. The second NIC may be caused to add the identifier to a buffer based on the identifier (e.g., one or more matching scheme selection bits and an identifier, or a confirmation scheme for verifying the identifier contained in the message). For example, a receiver device may utilize a target side buffer that accepts message transmissions based on a source identifier and a traditional packet switching matching bit. When the source identifier in the buffer at the receiver device receiving the message matches the source identifier carried in the message, the message is matched to the buffer. The receiver device may also identify one or more matching scheme identifier bits in the received message. The one or more matching scheme identifier bits may identify whether a software-defined match or a hardware-verified match is implemented, as well as an identifier associated with the message source. The identifier may include a hardware verification bit, a process identifier (PID), and an endpoint identifier (NID).

[0094] Figure 7 1 shows a block diagram of an exemplary computer system 700 in which various embodiments described herein may be implemented. For example, the computer system 700 may correspond to the first host 110A or the second host 110B or any system including the NIC 120, all of which are in Figure 1 . Computer system 700 includes a bus 702 or other communication mechanism for transmitting information, and one or more hardware processors 704 are coupled to bus 702 for processing information. (One or more) hardware processors 704 can be, for example, one or more general-purpose microprocessors.

[0095] The computer system 700 also includes a main memory 706, such as a random access memory (RAM), cache, and / or other dynamic storage device, coupled to the bus 702 for storing information and instructions to be executed by the processor 704. The main memory 706 may also be used to store temporary variables or other intermediate information during the execution of instructions to be executed by the processor 704. Such instructions, when stored in a storage medium accessible to the processor 704, render the computer system 700 a special-purpose machine customized to perform the operations specified in the instructions.

[0096] The computer system 700 also includes a read-only memory (ROM) 708 or other static storage device coupled to the bus 702 for storing static information and instructions executed by the processor 704. A storage device 710, such as a magnetic disk, an optical disk, or a USB flash drive (flash drive), is provided and coupled to the bus 702 for storing information and instructions.

[0097] The computer system 700 may be coupled to a display 712, such as a liquid crystal display (LCD) (or touch screen), via the bus 702 for displaying information to a computer user. An input device 714 including alphanumeric and other keys is coupled to the bus 702 for communicating information and command selections to the processor 704. Another type of user input device is a cursor controller 716, such as a mouse, trackball, or cursor direction keys, for communicating direction information and command selections to the processor 704 and for controlling movement of a cursor on the display 712. In some implementations, in the absence of a cursor, the same direction information and command selections as a cursor controller may be achieved by receiving touches on a touch screen.

[0098] The computing system 700 may include a user interface module for implementing a GUI, which may be stored in a mass storage device as an executable software code executed by the computing device. This module and other modules may include components, such as software components, object-oriented software components, class components, and task components, processes, functions, properties, procedures, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables, for example.

[0099] In general, as used herein, the terms "component", "engine", "system", "database", "data repository", etc. may refer to logic implemented in hardware or firmware, or to a set of software instructions, possibly with entry and exit points, written in a programming language such as Java, C or C++. Software components may be compiled and linked into executable programs, installed in dynamic link libraries, or may be written in interpreted programming languages ​​such as BASIC, Perl or Python. It should be understood that software components can be called from other components or from themselves, and / or can be called in response to detected events or interrupts. Software components configured to execute on a computing device may be located on a computer-readable medium, such as a compact disc, digital video disc, flash drive, disk, or any other tangible medium, or as a digital download (and may initially be stored in a compressed or installable format, requiring installation, decompression or decryption prior to execution). Such software code may be stored in part or in whole on a memory device of an executing computing device for execution by the computing device. Software instructions may be embedded in firmware such as an EPROM. It should also be understood that hardware components may be composed of connected logic units (such as gates and flip-flops) and / or may be composed of programmable units such as programmable gate arrays or processors.

[0100] The computer system 700 can implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic that, in combination with the computer system, makes the computer system 700 or programs it into a special purpose machine. According to one embodiment, the techniques described herein are performed by the computer system 700 in response to the processor 704 executing one or more sequences of one or more instructions contained in the main memory 706. Such instructions can be read into the main memory 706 from another storage medium such as the storage device 710. The execution of the sequence of instructions contained in the main memory 706 causes the processor 704 to perform the process steps described herein. In alternative embodiments, hardwired circuits can be used in place of software instructions or in combination therewith.

[0101] As used herein, the term "non-transitory media" and similar terms refer to any medium that stores data and / or instructions that cause a machine to operate in a specific manner. Such non-transitory media may include non-volatile media and / or volatile media. Non-volatile media include, for example, optical or magnetic disks, such as storage device 710. Volatile media include dynamic memory, such as main memory 706. Common forms of non-transitory media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, tapes or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a pattern of holes, RAM, PROM, EPROM, FLASH-EPROM, NVRAM, any other memory chip or cassette tape, and networked versions thereof.

[0102] Non-transient media are distinct from, but can be used with, transmission media. Transmission media participate in the transfer of information between non-transient media. For example, transmission media include coaxial cables, copper wire, and optical fiber, including the wires that comprise bus 702. Transmission media can also take the form of acoustic or light waves, such as those generated in radio wave and infrared data communications.

[0103] The computer system 700 also includes a communication interface 718 coupled to the bus 702, which is configured to send a message containing an identifier, which is generated according to a specific matching scheme implemented at the computer system 700, and is sent to other computer systems, each of which may include its own NIC, as discussed herein. The communication interface 718 provides a two-way data communication coupled to one or more network links, which are connected to one or more local networks. For example, the communication interface 718 can be an integrated services digital network (ISDN) card, a cable modem, a satellite modem, or a modem that provides a data communication connection to a corresponding type of telephone line. For another example, the communication interface 718 can be a local area network (LAN) card to provide a data communication connection to a compatible LAN (or a WAN component communicating with a WAN). A wireless link can also be implemented. In any such implementation, the communication interface 718 sends and receives an electrical signal, an electromagnetic signal, or an optical signal, which carries a digital data stream representing various types of information.

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

[0105] Computer system 700 can send messages and receive data, including program code, through one or more networks, network links and communications interface 718. In the Internet example, a server can transmit the requested code for an application program through the Internet, an ISP, a local area network and communications interface 718.

[0106] The received code may be executed by processor 704 as it is received and / or stored in storage device 710 or other non-volatile storage for later execution.

[0107] Each of the processes, methods and algorithms described in the foregoing sections can be embodied in a code component executed by one or more computer systems or computer processors comprising computer hardware, and fully or partially automated by it. 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" (software as a service, SaaS). The process and algorithm can be implemented in part or in whole 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 the present disclosure, and some methods or process boxes can be omitted in some embodiments. The methods and processes described herein are also not limited to any particular order, and the boxes or states associated therewith can be executed in other appropriate orders, or can be executed in parallel or in some other way. Boxes or states can be added to or removed from the disclosed exemplary embodiments. The performance of certain operations or processes can be distributed between computer systems or computer processors, not only residing in a single machine, but also deployed across multiple machines.

[0108] 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 form circuits. In implementation, various circuits described herein can be implemented as discrete circuits, or the functions and features described can be shared in part or in whole in one or more circuits. Although various features or functional elements can be individually described or declared as separate circuits, these features and functions can be shared between one or more common circuits, and such descriptions should not require or imply that separate circuits are needed to implement such features or functions. In the case of using software to implement the circuit in whole or in part, such software can be implemented to operate together with a computing or processing system such as a computer system 700, which can perform the functions described therein.

[0109] As used herein, the term "or" may be interpreted as inclusive or exclusive. Furthermore, descriptions of "resources," "operations," or "structures" in the singular should not be interpreted as excluding the plural. Unless expressly stated otherwise or otherwise understood in the context of use, conditional language, such as "may," "can," "might," or "could" are generally intended to convey that certain embodiments include and other embodiments do not include certain features, elements, and / or steps.

[0110] Unless expressly stated otherwise, the terms and phrases used herein and their variations should be interpreted as open ended and not restrictive. Adjectives such as "conventional," "traditional," "normal," "standard," "known," and terms of similar meaning should not be interpreted as limiting the items described to items available for a given time period or as of a given time, but should be interpreted as covering conventional, traditional, normal, or standard technology that may be available or known at any time now or in the future. In some cases, the presence of expanded words and phrases such as "one or more," "at least," "but not limited to," or other similar phrases should not be interpreted as meaning that a narrower situation is intended or required in the absence of such expanded phrases.

Claims

1. A device comprising: a first network interface card (NIC); Memory; and a processor configured to execute instructions stored in the memory, wherein the processor is configured to: receiving a first format for an application programming interface (API); generating an identifier in a second format, wherein the second format of the identifier conforms to the first format for the API; generating one or more matching scheme selection bits associated with the identifier; adding the one or more matching scheme selection bits to the identifier, wherein the second format of the identifier remains compliant with the first format of the API; sending the one or more matching scheme selection bits and the identifier to a receiver device including a second NIC; and Based on sending the identifier to the second NIC, the second NIC is enabled to add the identifier to a buffer at the second NIC based on the identifier.

2. The apparatus of claim 1 , wherein the one or more matching scheme selection bits are associated with an acknowledgement scheme, and wherein the second NIC is configured to: identifying the one or more matching scheme selection bits and the identifier as originating from the first NIC of a client device accessible in a control plane with the receiver device; switching to the validation scheme for the identifier associated with the one or more matching scheme selection bits; as well as The second NIC is enabled to add data packets to the buffer at the second NIC of the receiver device associated with the acknowledgment scheme.

3. The device according to claim 1, wherein: The identifier includes a source identifier of a user of the first NIC and the one or more matching scheme selection bits, and a length of the identifier fills a data space allowed by the first format of the API.

4. The device according to claim 1, wherein: A first user of the first NIC is associated with an identifier of a second user different from the first NIC.

5. The device according to claim 1, wherein: The first format for the API is associated with a framework or profile of the API.

6. The device according to claim 1, wherein: The second NIC is embedded in the receiver device, and the second NIC is configured to: The identifier is stamped on the data packet.

7. The device according to claim 1, wherein: The second NIC is configured as: The identifier is marked on the data packet using a control plane function.

8. A computer-implemented method comprising: receiving, at a first network interface card (NIC), a first format for an application programming interface (API); generating one or more matching scheme selection bits associated with the identifier; adding the one or more matching scheme selection bits to the identifier, wherein a second format of the identifier conforms to the first format of the API; sending the one or more matching scheme selection bits and the identifier to a receiver device including a second NIC; and Based on sending the identifier to the second NIC, the second NIC is enabled to add the identifier to a buffer at the second NIC based on the identifier.

9. The computer-implemented method of claim 8, wherein: The one or more matching scheme selection bits are associated with a confirmation scheme, and the method further comprises: identifying the one or more matching scheme selection bits and the identifier as originating from the first NIC of a client device accessible in a control plane with the receiver device; switching to the validation scheme for the identifier associated with the one or more matching scheme selection bits; and The second NIC is enabled to add data packets to the buffer at the second NIC of the receiver device associated with the acknowledgment scheme.

10. The computer-implemented method of claim 8, wherein: The identifier includes a source identifier of a user of the first NIC and the one or more matching scheme selection bits, and a length of the identifier fills a data space allowed by the first format of the API.

11. The computer-implemented method of claim 8, wherein: A first user of the first NIC is associated with an identifier of a second user different from the first NIC.

12. The computer-implemented method of claim 8, wherein: The first format for the API is associated with a framework or profile of the API.

13. The computer-implemented method of claim 8, wherein: The second NIC is embedded in the receiver device, and the method further comprises: The identifier is stamped on the data packet.

14. The computer-implemented method of claim 8, wherein: The method further comprises: The identifier is marked on the data packet using a control plane function.

15. A non-transitory computer-readable storage medium storing a plurality of instructions executable by one or more processors, which, when executed by the one or more processors, cause the one or more processors to: receiving, at a receiver device including a second network interface card (NIC) and from a first NIC, a message having an identifier conforming to a format for an application programming interface (API); determining one or more matching scheme selection bits associated with the identifier and a matching scheme for generating the matching scheme selection bits; initiating a validation scheme associated with the matching scheme to verify the identifier in the message; as well as When the identifier is verified using the validation scheme, the identifier is added to a buffer at the second NIC.

16. The non-transitory computer readable storage medium of claim 15, wherein: The second NIC is configured as: identifying the one or more matching scheme selection bits and the identifier as originating from a first NIC of a client device accessible in a control plane with the receiver device; as well as Switching to the validation scheme for the identifier associated with the one or more matching scheme selection bits.

17. The non-transitory computer-readable storage medium of claim 15, wherein: The identifier includes a source identifier of a user of the first NIC and the one or more matching scheme selection bits, and a length of the identifier fills a data space allowed by the format of the API.

18. The non-transitory computer readable storage medium of claim 15, wherein: A first user of the first NIC is associated with an identifier of a second user different from the first NIC.

19. The non-transitory computer readable storage medium of claim 15, wherein: The format for the API is associated with a framework or profile of the API.

20. The non-transitory computer readable storage medium of claim 15, wherein: The second NIC is embedded in the receiver device, and the second NIC is configured to: The identifier is stamped on the data packet.

Images