DE102021134581A1 - OUTSOURCING DECRYPTION OPERATIONS - Google Patents

Abstract

Examples described herein relate to a Transport Layer Security (TLS) offloading engine to: based on detection of encrypted data unassociated with a previously detected data header: look for one or more data headers; identify at least two candidate data headers for validation; and based on receiving an indication that the at least two candidate data headers are valid, perform decryption of received data in one or more packets. In some examples, the TLS offload engine is configured to: search for two or more other candidate data headers based on receiving an indication that one or more of the at least two candidate data headers is not a valid header.

Description

RELATED REGISTRATION

The present application claims the benefit of a priority date of US Provisional Patent Application Serial No. 63/130,669 filed December 26, 2020, the entire disclosure of which is incorporated herein by reference.

DESCRIPTION

Various cryptographic protocols provide security for communications over a computer network. Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are examples of security protocols. TLS provides end-to-end encryption at the application layer, and TLS can secure application-to-application communication. For example, cloud service providers (such as social media and online payment platforms) use TLS to provide secure communications. TLS is a widely used protocol used to secure Transmission Control Protocol (TCP) connections on the Internet. TLS is also a feature of HTTP/2, an Internet protocol.

TLS is at least defined in The Transport Layer Security (TLS) Protocol Version 1.3, RFC 8446 (August 2018). Data encrypted using TLS is of any size and travels from one end of a socket to another end of the socket. A TLS segment can span a fraction of a TCP packet or hundreds (or more) of TCP packets. TLS can encrypt e.g. B. each contain up to 16 KB of data using a cryptographic key agreed on by two sides of the connection. The two sides of the connection may periodically agree to update the key, e.g. B. with long-lived connections (e.g. with an audio or video stream). Kernel TLS (kTLS) is a Linux kernel implementation of a TLS datapath in which the encryption and decryption steps are offloaded to the kernel and match the flow of traffic in and out of a computer or server.

TLS data path offloading allows the network interface controller (NIC) to accelerate encryption, decryption, and authentication according to the Advanced Encryption Standard with Galois/Counter Mode (AES-GCM). Running encryption and decryption on the network interface can free up cores and memory bandwidth for other uses by applications and customer workloads. CPU-based cryptographic offloads involve copying data from memory to an encryption/decryption engine and copying encrypted/decrypted data back to memory. In some cases, many copy operations may take place, in which encryption and decryption operations are performed on a single, relatively small data set (e.g. 16 KB), and data sets are encrypted or decrypted one at a time. In other words, while an offload engine can save CPU cycles compared to performing the same operation using CPU instructions, CPU resources (such as CPU cycles, cache space, and disk space) are used when to migrate data for use by the encryption/decryption engine and after use by the encryption/decryption engine.

Decryption requires packets to arrive in order to be able to decrypt TLS segments, but when TCP packets arrive at the NIC out of order, the TLS accelerator must be able to decrypt the execute received packet contents out of order. In some solutions, when an out of order (OOO) packet is detected by a decryption accelerator, the accelerator waits for the maximum TLS segment size and then starts looking for the TLS header (e.g. 5- byte character). If there is a possible match, the decryption accelerator sends a pointer to the host system and waits for confirmation from the application or driver to start decrypting the records. After the first OOO packet, the decryption can be performed by a software stack running on a CPU. However, such a solution may not achieve header identification due to the latency between the time the accelerator sends the request and the time the acknowledgment is received from the host, resulting in no further cryptographic acceleration in the accelerator takes place.

character list

• 1 shows a flow of information from application data to the network.
• 2A represents an example system.
• 2 B represents an example system.
• 3A Figure 1 shows an example interaction between an operating system and a device driver.
• 3B represents an example interaction between an operating system and a network interface.
• 4 Figure 1 shows an example way of processing record headers in various scenarios where packets are received out of order.
• 5 represents an example state diagram.
• 6A represents an example of a header hunt.
• 6B represents an example of a candidate start identification of a record header.
• 7 Figure 1 shows an example of a header match, followed by sequential analysis of the received record to identify another header match.
• 8th Figure 12 illustrates an example process that may be performed by a recipient system.
• 9 represents an example system.
• 10 represents an example environment.

Detailed description

In some embodiments, based on the detection of a first OOO packet at a TLS cryptographic engine in a NIC, the cryptographic engine may perform a TLS header lookup or hunt mode to identify at least one previously undetected TLS header. In some examples, hardware resources that should be used for decryption can be used to perform TLS header string matching to find a new TLS header. Protocol software running on a CPU or XPU may not be informed of speculative TLS frame detection or TLS header hunting until the cryptographic engine has high confidence that a previously unidentified TLS header identified by the cryptographic engine. The confidence threshold is a programmable parameter in the cryptographic engine and can be a number of candidate record headers. In response to the protocol software providing an acknowledgment to the cryptographic engine that the candidate record headers are valid, the cryptographic engine and the protocol software can be synchronized in terms of the received start of the TLS frames, and the cryptographic engine can resume decryption of TLS frames.

While examples are described in terms of TLS, any cryptographic technique may be used, such as Any transport layer security or cryptographic scheme like SSL, Blockchain, Mozilla Network Security Services (NSS), DNS-based Authentication of Named Entities (DANE) (RFC 6698), etc.

1 shows a flow of information from the application data to the network. In this example 100, an application in user space can generate application data for transmission or process received data. In a kernel, a TLS layer can segment application data into records and encrypt the records. Records can be encrypted using AES-GCM. A record header can include fields of a header.type and header.len (record length) as well as application data. A record can end with a trailer, where a trailer can include TLS authentication fields. Based on an applicable maximum segment size (MSS), an encrypted data set may be provided for transmission using one or more packets as part of a stream of Transmission Control Protocol (TCP) compliant packets. In this example, one record is transmitted over packets p0, p1, and p2, and another record is transmitted over packets p2, p3, p4, and p5. It will be pointed out s that the packet p2 comprises portions of two data sets. While examples are provided in terms of TCP as the transport layer, any transport layer protocol may be used.

2A Figure 1 illustrates an example system. In this system, computing platform 200 may provide data for transmission and offload encryption of data to network interface 240, and also control which specific packets comprising segments of data are transmitted (or retransmitted) from network interface 240 ) will. For example, data can be encrypted using TLS or another encryption scheme. For example, TLS version 1.2 is described in at least RFC 5246 (2008) and TLS version 1.3 is described in at least RFC 8446 (2018), however any versions of TLS may be supported. Network interface 240 may perform encryption of data or a set of data from platform 200 and segment encrypted data for transmission using one or more packets. In the event of a packet loss or non-receipt at a receiver, the network interface 240 can issue a NACK (or a double ACK) and cause the unreceived packet to be retransmitted. The application 210 can track the record boundary per packet (e.g., packets 0-3 transmitrecord0, packets 3-4 transmitrecord1; and so on) using the transmit context 224 and determine which packet(s) to retransmit should be.

The computing platform 200 may include at least various processors 202 and memory 220 . Processors 202 may execute virtual execution environment 204, operating system 206, network interface driver (or device driver) 208, and applications 210. Processors 202 may be an execution core or computational engine capable of executing instructions. A core can have access to its own cache and read only memory (ROM), or multiple cores can share a cache or ROM. Cores can be homogeneous and/or heterogeneous devices. Any type of interprocessor communication technique can be used, such as e.g., but not limited to, messaging, interprocessor interrupts (IPI), interprocessor communication, etc. Cores may be connected in any manner, such as, but not limited to, bus, ring, or mesh. 202 processors may support one or more instruction sets (e.g., the x86 instruction set (with some extensions added with newer versions); the MIPS instruction set from MIPS Technologies of Sunnyvale, CA; the ARM instruction set (with optional additional Extensions such as NEON) from ARM Holdings of Sunnyvale, CA) including the instruction(s) described herein.

A virtualized execution environment may include at least one virtual machine or container. A virtual machine (VM) can be software that runs an operating system and one or more applications. A VM can be defined by specification, configuration files, a virtual disk file, a non-volatile random access memory (NVRAM) settings file, and the log file, and is backed by the physical resources of a host computing platform. A VM can be an operating system (OS) or application environment installed on software that mimics dedicated hardware. The end user has the same experience on a virtual machine as they would on dedicated hardware. Specialized software, called a hypervisor, fully emulates the CPU, memory, disk, network, and other hardware resources of the PC client or server, and allows virtual machines to share the resources. The hypervisor can emulate multiple virtual hardware platforms isolated from each other, allowing virtual machines to run Linux® and Windows® server operating systems on the same underlying physical host. Examples of a hypervisor include kernel-based virtual machine (KVM), VMware Workstation Pro, Xen Server, VMware vSphere, VMware ESXi, VMware Player, VMware Workstation, Microsoft Hyper-V, QEMU, VirtualBox, or Kubernetes.

A container can be a software package of applications, configurations, and dependencies such that the applications run reliably on one computing environment with respect to another. Containers can share an operating system installed on the server platform and run as isolated processes. A container can be a software package that includes everything the software needs to run, such as system tools, libraries, and settings. Containers are not installed like traditional software programs, allowing them to be isolated from the other software and the operating system itself. Isolation may include permitted access to a region of addressable memory or storage by a particular container but not by another container. The isolated nature of the containers provides several advantages. First, the software can run the same in a container in different environments. For example a container that includes PHP and MySQL can run identically on both a Linux machine and a Windows® machine. Second, containers provide additional security since the software may not interfere with the host operating system. While an installed application can change system settings and modify resources such as the Windows® registry, a container can only modify settings within the container.

In some examples, operating system 206 may be any of Linux®, Windows® Server, FreeBSD, Android®, MacOS®, iOS®, Cisco IOS, Juniper Junos, or any other operating system. Operating system 206 and applications 210 may run within virtual execution environment 204 or outside of virtual execution environment 204 . Driver 208 may provide an interface between virtual execution environment 204 or operating system (OS) 206 and network interface 240 . In some examples, the OS 206 queries the device driver 208 for network interface 240 capabilities and learns of a network interface 240 ability to encrypt data for transmission, and an application can control which packet is to be transmitted or retransmitted. In other examples, the OS 206 can direct the network interface 240 to encrypt data for transmission and an application can control which packet to transmit or retransmit.

Applications 210 may be any type of application, including a media streaming application (e.g., video or audio), a virtual reality application (including headset and sound emitter), an augmented reality application, a Video or audio conferencing application, a video game application, or a database. In some examples, applications 210 run within virtual execution environment 204 or outside of virtual execution environment 204.

The computing platform 200 can open a socket to send packet traffic to a recipient. For example, the computing platform 200 (using the network interface 240) and the receiver can perform a TLS handshake to exchange information and establish a connection. When the connection is established, the computing platform 200 (or other entity) sends encryption information (e.g., the encryption key) for that socket (e.g., Security Association (SA)) to the network interface 240 for use by the encryption circuitry 248. The platform 200 may write ciphering information into the encryption keys 258 to specify a socket's 5-tuple (e.g., Layer 2 destination, source, Layer 4 destination port, Layer 4 source port, protocol). to map the encryption information provided by the sender.

The OS 206 may negotiate with the network interface 240 via the driver 208 to detect that data (e.g., at the TLS record level) requires offload TCP segmentation, data encryption, and control of certain packet transmissions (or retransmissions). is available. For example, the application 210 may cause the copying of application data from the data buffer 222 to the transmit queue 254 of the network interface 240 to be encrypted using TLS (e.g., up to 16 KB of data, headers, and trailers). In some examples, the OS 206 pre-segments data along TLS record boundaries instead of the maximum segment size (MSS) of the transport layer. For data to be transferred, OS 206 may provide a vector indicating whether one or more packets configured to carry a segment of data should be transferred, and the vector may be stored in transfer vectors 256 in memory 252 .

The interface 230 and the interface 242 can provide a communicative coupling between the platform 200 and the network interface 240 . The communicative coupling can be based, for example, on Peripheral Component Interconnect express (PCIe) or any public or proprietary standard. Direct memory access (DMA) engine 244 may transfer data and a corresponding packet descriptor to memory 252 . For example, a portion of the packet may be copied to a packet buffer in memory 252 via DMA.

Direct memory access (DMA) is a technology that allows an input/output (I/O) device to bypass a central processing unit (CPU) or core and send data directly to system memory send or receive from the same. Because DMA allows the CPU or core not to manage a copy operation when sending or receiving data to or from system memory, the CPU or core can be free to perform other operations. Without DMA, if the CPU or core uses programmed input/output, the CPU or core is typically open for the entire duration of a read or write ration occupies and is not available to perform other work. With DMA, the CPU or core can e.g. B. initiate a data transfer and then perform other operations while the data transfer is in progress. The CPU or core can receive an interrupt from a DMA controller when the data transfer is complete.

The transport layer offload engine 246 may examine packet data in the transmit queue 254 and determine whether a packet's header (e.g., n-tuple) identifies the packet as a TLS record and found a Security Association (SA) for that n-tuple becomes. For example, an n-tuple may include one or more of: a source IP address, a source port number, a destination IP address, a destination port number, and the protocol used. For example, a transmit queue 254 may include packet-related information for packet transmission, including one or more of: Layer 2 (L2) headers, Layer 3 (L3) headers, TCP headers, TLS record headers , TLS Application Data and TLS Record Trailer. The transport layer offload engine 246 may cause the encryption circuitry 248 to perform encryption of the data including the packet payload, the packet header, and/or the packet header and the payload.

After encryption, data is scheduled for transmission out the uplink at a maximum segment size (MSS) value at a time. So e.g. B. an MSS value of data that is part of a larger TCP datagram (e.g. a TLS dataset) is segmented and available for transmission. The segmentation may include copying the L2, L3, and L4 headers and prepending the headers to the segment of data and adjusting the checksums and lengths to create a valid header. In some examples, the transport layer offload engine 246 performs TCP segmentation offload or large send offload (LSO) for UDP packets. It should be noted that the transport layer offload engine 246 may be any protocol such as TCP (e.g. RFC 793), User Datagram Protocol (UDP) (e.g. RFC 768), Quick UDP Internet Connections (QUIC) (e.g. B. QUIC: A UDP-Based Multiplexed and Secure Transport draftietf-quic-transport-22 (July 2019)). If the packet is a TLS record without a security association, the packet can be transmitted without encryption, marked as a warning, or dropped, depending on an applicable configuration.

A packet refer to various formatted collections of bits that can be sent over a network, such as Ethernet frames, IP packets, TCP segments, UDP datagrams, QUIC segment, RTP segment, and so on. References to L2, L3, L4 and L7 layers (or Layer 2, Layer 3, Layer 4 and Layer 7) are references to respectively the second data link layer, the third network layer, the fourth transport Layer and the seventh application layer of the OSI (Open System Interconnection) layer model.

A packet can be associated with a flow. A flow can be one or more packets transmitted between two endpoints. A flow can be identified by a set of defined tuples, such as two tuples, that identify the endpoints (e.g., source and destination addresses). For some services, flows can be identified at a finer granularity using five or more tuples (e.g., source address, destination address, IP protocol, transport layer source port, and destination port).

When a packet is successfully received, an ACK may be sent to network interface 240 by the receiver. The OS 206 may maintain TSO data until TSO-associated packets are acknowledged received by a recipient. In connection with packet discards or lost packets at a receiver, indicated by NACK or double ACK, the OS 206 may use a transport layer stack to determine whether a packet should be retransmitted. In a retransmission scenario, the OS 206 may copy out a portion of the stored data, create a new TCP header from that data, and cause a packet containing the portion to be resent to the recipient.

In some examples, a sequence number of a packet to be retransmitted is identified using NACK or double ACK. The OS 206 may request the application 210 to identify one or more records that correspond to the packet to be retransmitted. A send context 224 may be used to associate byte ranges of data with a packet identifier (e.g., a sequence number) configured to transmit the byte range of data. Using the sending context 224, the application 210 determines which data set is the subject of retransmission of the packet and provides a complete data set that includes one or more segments to be retransmitted in a packet.

In this example, network interface 240 does not store the status of one or more transmitted packets, but uses the bandwidth of interfaces 230 and 242, which may not be bandwidth limited, to access a record for packet retransmission. When a Peripheral Component Interconnect Express (PCIe) interface is used, a record can traverse a PCIe interface to be re-encrypted and utilizes the additional bandwidth of the PCIe interface. This results in some interface bandwidth usage, but a PCIe interface may not be a bottleneck even during peak network events.

Transceiver 270 may be capable of receiving and transmitting packets in accordance with applicable protocols, such as Ethernet as described in IEEE 802.3, although other protocols may be used. Transceiver 270 can receive and transmit packets to and from a network over a network medium (not shown). Transceiver 270 may include PHY circuitry 272 and media access control (MAC) circuitry 274 . PHY circuitry 272 may include encoding and decoding circuitry (not shown) for encoding and decoding data packets. The MAC circuitry 274 may be configured to arrange the data to be transmitted into packets that include destination and source addresses along with network control information and error detection hash values. Network interface 240 includes one or more ports 280-0 through 280-Z. A port can represent a physical port or a virtual port. A packet can be sent or received using ports 280-0 through 280-Z.

2 B represents an example of a receiver system. The receiver system can have elements similar to the transmitter system of 2A use and receiver-side elements are described for illustrative purposes, but elements of transmitter and receiver systems can be combined. Data from received packets may be stored in receive queue 290 . The receive manager 294 may use the receive context 292 to store a receive context identifying which segment(s) of data are being received and identifying the one or more received segments. The receive manager 294 may determine whether to receive segments of data based on identifying a header of data and its specified length in a received packet and identified in the receive context 292 . The memory 252 may be on-chip or off-chip to the network interface 240 . If the memory 252 is off-chip to the network interface 240, the memory 252 may be communicatively coupled using an interface such as any type of Double Data Rate (DDR) memory interface. In some embodiments, upon receipt of segments of data, the data is decrypted using decryption circuitry 250 and provided to data buffer 222 of platform 200 for access by an application.

In some embodiments, the transport layer offload engine 246 may use the receive manager 294 to identify received and missing packets and generate ACKs or NACKs or duplicate ACKs to a sender for missing packets and for successfully received packets. For example, if a segment is not received within a time slot of another packet carrying a segment of the same data, the receive manager 294 may generate a NACK or double ACK and cause it to be transmitted to the receiver to request retransmission of one or more packets. A NACK or double ACK can identify a missing sequence number.

According to some embodiments described herein, the decryption circuitry 250 may perform TLS data path offloading of decryption and authentication according to AES-GCM. For example, if a header of a TLS record is detected, the decryption circuitry 250 may perform decryption of the TLS records received in one or more packets. For example, in cases where a TLS record is received for which no TLS header has previously been identified, processors 202 of computing platform 200 may perform TLS record decryption and decryption circuitry 250 may search for an integer M of candidates -Search for TLS headers. Decryption circuitry 250 may attempt to identify M candidate TLS headers by searching for a string identifying a TLS header and using a record length field associated with the identified TLS header to indicate an end of record and a start of a next Record (z. B. the next record header) to determine. Decryption circuitry 250 may determine if a character string identifying a TLS header is present in the next record header. Based on the detection of M candidate TLS headers based on record length fields, the Decryption circuitry 250 provides the M candidate TLS headers to one or more of: OS 206, driver 208, or applications 210. OS 206, driver 208, or applications 210 may indicate to decryption circuitry 250 whether the M candidate TLS headers are valid or whether there is an invalid header among the M candidate TLS headers. If M candidate TLS headers are indicated as valid headers, decryption circuitry 250 can proceed with decryption of the TLS records. While examples refer to TLS records, any type of data can be decrypted using any decryption standard or specification.

It is noted that while network interface 240 is referred to, any type of accelerator or hardware device may be used in place of the network interface, e.g. B. a memory controller (e.g. a non-volatile memory express (NVMe) memory controller), an infrastructure processing unit (IPU) or a data processing unit (DPU) or a smartNIC.

In some examples, one or both of the network interface 240 of 2A or 2 B ternary content-addressable memory (TCAM) storing packet processing rules or matching action rules to be applied by a programmable packet processing pipeline of a data plane. A TCAM can search its entire contents in a single clock cycle. The packet processing rules or the matching action rules may include, for example, one or more of: access control lists (ACLs), forwarding rules, quality of service (QoS), or other metadata.

3A 12 illustrates an example interaction between an operating system and a device driver. For example, operating system 306 may determine a capability of a device associated with device driver 308. FIG. For example, operating system 306 may receive an indication of a device's (e.g., network interface) ability to perform one or more of: data encryption (e.g., TLS or kTLS), data segmentation, packetization from data segmentation, selective retransmission of packets with encrypted data, buffering of received packets with encrypted data, reassembly of received data, decryption of received data (e.g., TLS or kTLS), search for candidate record headers, packet acknowledgment or packet retransmission request, or any operation that is offloaded to a network interface.

3B Figure 12 illustrates an example interaction between an operating system and a network interface. For example, operating system 306 may provide requests to network interface 340 to initiate packet transmission and to utilize one or more features of network interface 340: data encryption (e.g., TLS or kTLS), data segmentation, packetization from data segmentation, selective retransmission of packets containing encrypted data, candidate header lookup, or transport layer segmentation. Network interface 340 may provide operating system 306 with an indication of packet receipt. In some examples, the indication of packet receipt may or may also include: a received packet header, dummy packet data, decrypted data from data decryption performed by network interface 340, TLS or kTLS data decryption, a decrypted data set, a retransmitted data segment, or a decrypted data segment, identification of one or more candidate record headers, and others.

4 Figure 1 shows an example way of processing record headers in various scenarios where packets are received out of order. For Case I, a valid TLS record header (e.g. 5 bytes) and an initialization vector (IV) for a record in packets TCP1 and TCP2 are received at the receiver, but received out of order (e.g .TCP2, then TCP1). A TLS header can include a type, a TLS version (e.g., TLS1.2, TLS1.3, or others), and a record length. An IV can be a seed used to decrypt the record. The record can be determined valid based on the decoding of the header and IV. In case I, the header (e.g. the decrypted header) and IV can be provided to an entity or agent (e.g. the host) for decryption at a protocol stack or an application. The NIC's decryption offload engine can track the receipt of the record via multiple TCP packets that are received out of order because the record header and IV were detected. When receiving TCP packets, the data set can be included its tail (e.g. 16 bits) for decryption by ordering the TCP packets from TCP1 to TCP8. For the next TLS record, the NIC's decryption offload engine can perform a decryption.

For Case II, packets TCP1 through TCP4 are received at the receiver NIC in order, and the NIC's decryption offload engine can decrypt portions of the data set. Based on the header, the record length can be determined by the decryption offload engine. The record can be determined valid based on the decoding of the header and IV. However, the TCP5 packet is received out of order, and another packet such as TCP6 is received at the receiver NIC. The NIC's decryption offload engine can finish decrypting the record and send the header (e.g., the decrypted header), the IV, the decrypted record sections, and the received encrypted record segments to the host (e.g., the protocol stack or application) send to decrypt the encrypted record segments. The swap engine may stop or temporarily pause execution of record decryption.

In cases III and IV, a TCP packet is received for a record segment for which the NIC's decryption offload engine has not previously identified a full header. Record size and IV (e.g. key seed) may not be available to decrypt the TLS record. In either Case III or IV, the offload engine can perform a search for M headers and provide the candidate M headers to the host to determine if the M headers are valid. If the M headers are valid, the offload engine can proceed to perform record decryption of the data associated with a next identified header.

5 12 illustrates an example state diagram. The state diagram may represent operational modes of an offloading device at a NIC and a host system. In state 502, kTLS offload decryption may be performed in the NIC. For example, a kTLS offload engine or other processors in the NIC can perform decryption of TLS records or other data types. In some examples, a TLS offload engine includes kTLS offload operations. For example, a system may remain in state 502 to decrypt a record received in one or more packets if a record header and IV for the record have been identified and detected by the kTLS offload engine. If a record header and IV for a record are not identified and not detected by the NIC's kTLS offload engine, hunt mode 504 may be entered.

In hunt mode 504, the kTLS offload engine may identify an integer number M of header (HDR) detections. In this example, M is at least 3, but M can be any integer including 1 or more than 3. In hunt mode 504, the kTLS offload engine can perform searches for one or more headers of different data sets. Searching for a header may involve searching for a header character set by performing a string match of a preamble (e.g., type (TY)), a header (e.g., a string of 0303), and a data length field (LE ) is performed. For example, a header character set may include one or more characters including "Don't Care" or "Wild Card". In some examples, a string match and a record length between 0 and less than 16 KB can be used to identify a candidate header. If a string match and/or an allowable record length is found, the NIC's kTLS offload engine can use the record length information in the header to identify a start of a next record. In cases where two or more headers are to be identified, after identifying a first header, the NIC's kTLS offload engine may look for a header of the next record by using a length of the first record. The NIC's kTLS offload engine can continue for M-1 number of headers. String matching can be performed at a decryption engine to analyze the payload word by word. The string matching engine can consider the headers on the word boundary.

For one or more detected headers, the NIC's kTLS offload engine can indicate to the host that a candidate header was received by providing one or more of: TCP packet sequence number for a TCP packet comprising the candidate header, offset from a beginning of the TCP packet to a beginning of the candidate header, candidate header type (TY), candidate header character string (e.g. 0303) and/or candidate header length (LE) value. For example, the NIC's kTLS offload engine can provide a host (e.g., driver, OS, or application) with the display provide, and the host can enter resynchronization mode 506. The host can store a context in memory that keeps track of the TLS frames received and where a TLS frame begins in a TCP packet (e.g. using a link list). Using the stored context tracking the received TLS frames, the host can verify one or more candidate headers by determining whether the candidate header is as expected (or not) in a TCP packet with a given sequence number and positioned at a specific offset in the TCP packet. By comparing the sequence number and offset associated with the candidate header received from the kTLS offload engine to the expected sequence number and offset, the host can determine whether a candidate header is valid. In response to the host identifying M candidate headers as valid, a resync_request with the TCP _SN of the last header location may be sent to the driver for confirmation.

Chase mode 504 may correspond to Case III and Case IV, where the NIC and the software running on the host processor are aware of a future first tcp sn (e.g., sequence number of the first TCP packet in a TLS segment) and tls_rec_sn (e.g., e.g. the sequence number of the current TLS segment) cooperatively synchronize.

A final speculative header TCP sequence number (HDR_TCP_SN), a header counter (HDR_CNTR), and a number of record headers passed after resync request can be stored in a tuple in the header tuple structure. To increase a chance of finding the header, the offload engine can identify multiple candidate header tuples, seeding at least one header from another initial string match that matches the TLS version bytes. An example of this header_tuple structure is shown in Table 1 below. In some examples, the header_tuple may replace part of the SA_Dynamic context or use memory resources that are otherwise available for use in storing the SA_Dynamic context. Table 1 HDR_CNTR_0[8b] HDR_TCP_SN_0[4B] TLS_Headers[5B] flags[8b] HDR_CNTR 1 HDR_TCP_SN_1 MSB=0: tls header search; MSB=1: wait for resync_response M = number of matching headers HDR_CNTR 2 HDR_TCP_SN_2 HDR_CNTR 3 HDR_TCP_SN_3

Table 2 below shows an example of data stored during a hunt mode. Table 2 no SA_Dynamic Fields during hunt mode and resync mode TLS1.2 and 1.3 Valid 2 1 HDR_TUPLE _0 HDR CNTR 0 8th HDR_TCP_SN_0 32 TLS_HDR 40 FLAGS_0 8th HDR TUPLE_1 88 HDR TUPLE 2 (HDR_CNT, HDR_TCP_SN) 40 Reserved 29 ECC 9 Reserved 24 HDR_TUPLE _2(TLS _HDR, FLAGS) 48 HDR TUPLE _ 3 88 LAST_ 4 bytes 32 Stores the last 4 bytes of a string match payload 34 flags 16 Reserved 32 35 Reserved 7 ECC 9 36 In total 512

In response to the host receiving a resync_request from the kTLS page engine, the host may wait until the TCP_SN of the header is provided in a resync_request from the page engine to the host. The host can generate a positive or negative response to the offload engine with the same resync_request_id and including the tls_rec_sn of the TCP_SN of the record header. After the offload engine receives the resync response from the driver, it looks up the header tuple entry for the given resync_request_id and adds the tls_rec_sn to the HDR_CNTR to generate the correct tls_rec_sn for the TCP_SN header in the header_tuple.

Register or memory space can be allocated to store Security Association (SA) dynamic field bits such as B., but not limited to partial encryption data (PED). In some examples, during hunt mode 504, at least some of the SA dynamic field bits are not valid and the storage resources for these bits could be used by the kTLS offload engine to store the candidate TLS header information. During hunt mode 504, information of multiple candidate headers (e.g., at least the TCP packet sequence number and the offset from a start of a TCP packet where a candidate header begins) may be stored in the SA dynamic field bits .

A number of tuple headers tracked may depend on how many bits are needed to track a header and how much space is available in the SA table. A header tuple can be 88b, and storing 4 header tuples adds 332b in the SA_Context and replaces a lower half of the SA_Context, leaving the error correction coding (ECC), flags, and debug counters in the SA_Context intact . One or more of the 8-header trace sequence may be based on a different version of byte alignment. The first header trace sequence that has M matching headers sends the resync _request to the host. In some examples, subsequent resync requests are not performed after an initial resync_request is sent to the host until a negative resync response is received from the host. In the meantime, other header_tuples can be used to further track potential header locations.

In resynchronization mode 506, the host can determine whether the one or more M candidate headers received from the NIC's kTLS offload engine correspond to a valid record header. For example, the host driver, the protocol layer stack (e.g., OS), and/or the application can decode the record header and determine if the header is a valid header. In some examples, if the version bytes of the M candidate headers match an expected value, the M candidate headers may be determined to be valid. In some examples, if a version byte of one or more of the M candidate headers does not match an expected value, the M candidate headers may be determined to be invalid. The host can confirm that TCP_SN includes a valid TLS TCP_SN header and send the corresponding tls_rec_sn of that header. The host can indicate that the header is valid and cause the NIC to enter state 502, where the NIC's kTLS offload engine can perform a decryption of the records starting at the header of a next record. However, if one or more of the M candidate headers are invalid, the hunt mode 504 is re-entered, a counter is reset to 0, and must reach M again. In some examples, when the Host does not send a response to the candidate headers in a prescribed amount of time, enter a TIMEOUT and perform a search for M candidate headers.

During resynchronization mode 506, hunt mode 504 may continue wherein a kTLS offload engine may track headers if a new header is received. The offload engine may keep a count of a number of additional headers that have arrived after the resync_request was sent to the host.

In response to receiving an acknowledgment of a valid header from the host, the correct TLS_REC_SN for the current TLS record can be constructed by adding the tls_rec_sn that came from the host and the number of headers the swap engine has counted since then. The page engine can store the first_TCP_SN and a quantity of zero-bit padding can be reset to 0 and the decryption by the page engine can restart from the first packet containing the next TLS header.

6A Figure 1 shows an example of a header hunt. In this example, a header hunt begins to identify a type (TY), a 0303 character string, followed by a valid length (LE). After receiving a resync indication from a host, the NIC can perform decryption beginning at the beginning of a next detected record.

6B Figure 12 provides an example of identifying a candidate start of a record header. In this example, the host indicates that the candidate header is not a valid header. The NIC may begin its hunt for a candidate header in a record being examined when the indication from the host indicates that the M candidate headers include an invalid header.

7 Figure 1 shows an example of a header match, followed by sequential analysis of the received record to identify another header match. For at least two candidate header matches, an identified record length can be used to determine whether there is another candidate header at or after the identified record length and at a beginning of a next record. One or more candidate headers can be identified and distinguished using a sequence number. In this example, the sequence numbers SQ#1 and SQ#2 are used to track two search candidate headers. For the sequence numbers SQ#1 and SQ#2, an attempt can be made to identify M candidate headers.

8th Figure 12 illustrates an example process that may be performed by a recipient system. The process may be performed, for example, using a network interface and a decryption offload device such as a kTLS or TLS offload engine. At 802, a packet is received on a network interface. The network interface may include the ability to manage rearrangement of data segments (e.g., portions of TLS records) and perform decryption of data segments. The network interface can include one or more of: NIC, IPU, or DPU. At 804, a receive context may be updated to identify one or more received packets. For example, packets can carry encrypted data such as encrypted TLS records and their associated preamble and header. The preamble and/or header may be unencrypted in some examples. Various techniques can be used by a network interface to track the receipt of segments of data, e.g. B. a linked list that tracks one or more received data and one or more segments received for the data based on receipt of the header of the data and the length of the data expected to be received.

At 806, it may be determined whether the received packet includes a data segment for which a header was not previously identified. For example, a received packet that includes a segment number that is not a next expected sequential number relative to other previously received packets may be considered an out-of-order received packet, and if a data segment in such an out-of-order packet is inconsistent therewith coincides with being within data (e.g., TLS record) for which a header was received and a data length identified, the data segment may be considered not to have a previously received or identified header. If the received packet includes a data segment for which no header was previously identified, the process may proceed to 810. If the received packet is a data segment for which a header was previously identified, the process may proceed to 808.

At 808, the network interface can decrypt the data. For example, a kTLS or TLS decryption offload device of the network interface may decrypt data such as TLS records based on applicable decryption standards. Decrypted data can be copied to a host system for an application to access from storage. Data decryption can be done on 128-bit data segments received in packets. Zero padding before or after a data segment can be used when less than a full 128-bit data segment is available for decryption. Information from decrypted data segments may be used to decrypt one or more subsequent data segments in accordance with the applicable decryption specifications.

At 810, the network interface can cause the host system to decrypt data and the network interface can perform a search for candidate data headers. In some examples, a host may perform data decryption for one or more data segments for which a header was not previously identified, and also perform data decryption until the offload device is allowed to resume data decryption. In some examples, the offload device may search for M consecutive matched header candidates. In some examples, the M header candidates may refer to sequential header candidates identified using M data length fields. In some examples, M is greater than or equal to 2 to increase a likelihood that the offload device correctly identified multiple identified headers. In some examples, the data header is unencrypted and the offload device may identify a data header by a header identifying character sequence, such as: B. the character sequence 0303, although other sequences can also identify data headers. The number M of header candidates that the offload device should identify can be configured by an administrator using a device driver.

In some examples, the offload device may determine if a candidate header is present after a previously identified data length. If a header candidate is present after a previously identified data length, the offload device may include that header candidate in the M header candidates. In some examples, even after a candidate header and data length have been found, in addition to searching for another candidate header at or after the previously identified data length, searching for other candidate headers and associated data lengths within the data of the previously identified data length to be continued. Accordingly, an N number of searches for the header of the data segment having a previously unidentified header in the data can be performed in parallel. N can represent a number of parallel header streams to be traced. In some examples, N can be 1 or more.

When searching for a candidate header, a length value associated with a header can be used to identify a next data header. If the next data header matches a character sequence that identifies a header, that next data header may match a second header candidate. The second header candidate can identify a length of the data associated with the second header candidate and an offset to a position of a start of other data. The offload device may determine whether a third candidate header is positioned after a data length associated with the second candidate header. After M number of identifications of candidate headers identified positioned at positions determined by the data length of a previous candidate header, the process may proceed to 812 . Note that in some examples, if M headers are not found in a certain period of time, an indication can be made to the host to indicate the loss of synchronization, and the host can cause the swap engine to find the candidate headers. Stop or pause search.

According to some embodiments, instead of being idle or using the host CPU to perform header detection, some computing resources of the offloading device may be used to perform the search for headers. This can lower CPU usage or allow the CPU to be used for other activities that require header detection, e.g. B. to increase a speed of data decryption.

At 812, the host can determine whether the M candidate headers correspond to valid headers. For example, an application, operating system, or driver may determine whether the M header candidates correspond to headers based on having valid version identifiers or having expected values in other fields. If the M candidate headers correspond to valid headers, the process may proceed to 814 . If one or more of the M candidate headers does not correspond to a valid header, the process may return to 810 .

At 814, the host may indicate to the offload device that the M candidate headers correspond to valid data headers. At 816, the offload device may resume decryption of data associated with a next received data header. The next received data header may be a data header identified by the offload device after the offload device receives an indication that the M header candidates correspond to data headers.

9 Figure 12 illustrates a system. The system may use embodiments described herein to offload data decryption and header lookup to a network interface offload engine. A system 900 includes a processor 910 that provides processing, operation management, and execution of instructions for the system 900. Processor 910 may include any type of microprocessor, central processing unit (CPU), graphics processing unit (GPU), processing core, or other processing hardware to provide processing for system 900 or a combination of processors. Processor 910 controls the overall operation of system 900 and may include one or more general purpose or special purpose programmable microprocessors, digital signal processors (DSPs), programmable controllers, application specific integrated circuits (ASICs), programmable logic devices ( PLDs; programmable logic devices) or the like or a combination of such components. An xPU or XPU can refer to at least one or more of: a CPU, IPU, DPU, GPU, GPGPU, and/or other processing units (e.g., accelerators).

Various examples of a processor, XPU, or IPU may run an application composed of microservices, where a microservice runs in its own process and communicates using protocols (e.g., application program interface (API), messaging, or remote Procedure Calls (RPC)). Microservices can be deployed independently using centralized management of these services. The management system can be written in different programming languages and use different data storage technologies. A microservice can be characterized by one or more of: using fine-grained interfaces (to independently deployable services), polyglot programming (e.g. code written in multiple languages to capture additional functionality and efficiencies not available in a single language), or Use of containers or virtual machines and decentralized continuous delivery of microservices.

In one example, system 900 includes an interface 912 coupled to processor 910, which may represent a higher speed interface or a high throughput interface for system components requiring higher bandwidth connections, such as a memory subsystem 920 or graphics interface components 940 or accelerators 942. The interface 912 represents an interface circuit that may be a stand alone component or integrated on a processor die. If present, the graphics interface 940 interfaces with graphics components to provide a visual display to a user of the system 900 . In one example, graphics interface 940 may drive a high definition (HD) display that provides an output to a user. High definition can refer to a display that has a pixel density of approximately 100 PPI (pixels per inch) or greater and can include formats such as Full HD (e.g. 1080p), Retina displays, 4K (ultra high definition or UHD (ultra high definition)) or others. In one example, the display may include a touch screen display. In one example, graphics interface 940 generates a display based on data stored in memory 930 or based on operations performed by processor 910, or both. In one example, graphics interface 940 generates a display based on data stored in memory 930 or based on operations performed by processor 910, or both.

The accelerators 942 may be programmable or fixed function offload engines that a processor 910 can access or use. at for example, an accelerator among accelerators 942 may provide compression (DC) capability, cryptographic services such as public key encryption (PKE), cipher, hash/authentication capabilities, decryption, or other capabilities or services. In some embodiments, an accelerator among accelerators 942 additionally or alternatively provides the field selection control capabilities described herein. In some cases, the accelerators 942 may be integrated into a CPU or connected to a CPU through various devices (e.g., a connector to a motherboard or circuit board that includes a CPU and provides an electrical interface with the CPU). For example, accelerators 942 may include a single or multi-core processor, graphics processing unit, logic execution unit, single or multi-level cache, functional units usable for executing programs or threads independently, application specific integrated circuits (ASICs), Neural network processors (NNPs), programmable control logic, and programmable processing elements such as field programmable gate arrays (FPGAs). The accelerators 942 may provide multiple neural networks, CPUs, processor cores, general purpose graphics processing units, or graphics processing units may be provided for use by artificial intelligence (AI) or machine learning (ML) models For example, the AI model may use or include one or more of: a reinforcement learning scheme, a Q-learning scheme, deep Q-learning, or an Asynchronous Advantage Actor-Critic (A3C), a combinatorial neural network , a recurrent combinatorial neural network, or another AI or ML model Multiple neural networks, processor cores, or graphics processing units can be made available for use by AI or ML models.

A memory subsystem 920 represents the main memory of system 900 and provides storage for code to be executed by processor 910 or data values to be used in executing a routine. The memory subsystem 920 may include one or more memory devices 930, such as read-only memory (ROM), flash memory, one or more varieties of random access memory (RAM), such as DRAM, or other storage devices, or a combination of such devices. Memory 930 stores and hosts, among other things, an operating system (OS) 932 to provide a software platform for execution of instructions in system 900 . In addition, applications 934 can be executed from memory 930 on the OS 932 software platform. Applications 934 represent programs that have their own operational logic for performing one or more functions. Processes 936 represent agents or routines that provide utility functions to the OS 932 or one or more applications 934, or a combination. The OS 932, applications 934, and processes 936 provide software logic to provide system 900 functions. In one example, memory subsystem 920 includes a memory controller 922, which is a memory controller for generating and issuing instructions to memory 930. It is noted that the memory controller 922 could be a physical part of the processor 910 or a physical part of the interface 912. For example, memory controller 922 may be an integrated memory controller integrated on circuit with processor 910 .

Although not specifically illustrated, it is understood that the system 900 may include one or more inter-device buses or bus systems, such as a memory bus, a graphics bus, interface buses, or others. Buses or other signal lines may communicatively or electrically couple components together, or communicatively as well as electrically couple the components. Buses may include physical communication lines, point-to-point links, bridges, adapters, controllers, or other circuitry or a combination. For example, buses may be one or more of a system bus, a Peripheral Component Interconnect (PCI) bus, a Hyper Transport or Industry Standard Architecture (ISA) bus, a Small Computer System Interface (SCSI) bus, a universal serial bus (USB) or an Institute of Electrical and Electronics Engineers (IEEE) standard 1394 bus (Firewire).

In one example, system 900 includes an interface 914 that may be coupled to interface 912 . In one example, interface 914 represents interface circuitry, which may include discrete components and integrated circuitry. In one example, multiple user interface components or peripheral components, or both, couple to interface 914. A network interface 950 provides system 900 with the ability to communicate with remote devices (e.g., servers or other computing devices) over one or more networks. The network interface 950 can include an Ethernet adapter, wireless connection components ten, cellular network connection components, USB (Universal Serial Bus) or other wired or wireless standards-based or proprietary interfaces. Network interface 950 may send data to a device that is in the same data center or rack, or to a remote device, which may include sending data stored in memory. Network interface 950 may receive data from a remote device, which may include storing received data in memory.

Some examples of network device 950 are part of, or are used by, an infrastructure processing unit (IPU) or data processing unit (DPU). An IPU or DPU may include a network interface with one or more programmable or fixed function processors to offload operations that could have been performed by a CPU. The IPU or DPU may include one or more storage devices. In some examples, the IPU or DPU can perform virtual switching operations, manage memory transactions (e.g., compression, cryptography, virtualization, etc.), and manage operations performed on other IPUs, DPUs, servers, or devices.

Some examples of network device 950 may perform TLS offload and header lookup according to embodiments described herein.

In one example, the system 900 includes one or more input/output (I/O) interface(s) 960. The I/O interface 960 may include one or more interface components through which a user can communicate with the System 900 interacts (e.g., audio, alphanumeric, tactile/touchable, or other interfacing). A peripheral interface 970 may include any hardware interface not specifically mentioned above. Peripheral devices generally refer to devices that dependently connect to system 900. A dependent connection is one in which the system 900 provides the software platform or hardware platform, or both, on which the operation is performed and with which a user interacts.

In one example, the system 900 includes a storage subsystem 980 to store data in a non-volatile manner. In one example, at least certain components of storage 980 may overlap with components of storage subsystem 920 in certain system implementations. Storage subsystem 980 includes one or more storage devices 984, which may be or include any conventional medium for storing large amounts of data in a non-volatile manner, such as one or more magnetic, solid state, or optical-based disks, or a combination . Storage 984 includes code or instructions and data 986 in a persistent state (e.g., the value persists despite power to the system 900 being interrupted). Storage 984 may generally be considered a "memory," although memory 930 is typically execution or operational memory for providing processor 910 with instructions. While storage 984 is non-volatile, memory 930 may include volatile memory (e.g., the value or state of the data is indeterminate when power to system 900 is interrupted). In one example, storage subsystem 980 includes a controller 982 to interface with storage 984 . In one example, controller 982 is a physical part of interface 914 or processor 910, or may include circuitry or logic in both processor 910 and interface 914.

Volatile memory is memory whose state (and hence the data stored therein) is indeterminate if power to the device is interrupted. Dynamic volatile memory requires updating the data stored in the device to maintain state. An example of dynamic volatile memory includes dynamic random access memory (DRAM) or a variant such as synchronous DRAM (SDRAM). Another example of volatile memory includes a cache or static random access memory (SRAM). A memory subsystem as described herein may be compatible with a number of memory technologies, such as DDR3 (Double Data Rate Version 3, originally published by JEDEC (Joint Electronic Device Engineering Council) on June 27, 2007). DDR4 (DDR version 4, first specification published in September 2012 by JEDEC), DDR4E (DDR version 4), LPDDR3 (Low Power DDR version3), JESD209-3B, August 2013 by JEDEC ), LPDDR4) LPDDR version 4, JESD209-4 originally released by JEDEC August 2014), WIO2 (Wide Input/Output Version 2), JESD229-2 originally released by JEDEC August 2014 , HBM (High Bandwidth Memory), JESD325, originally published by JEDEC in October 2013, LPDDR5 (currently under discussion by JEDEC), HBM2 (HBM version 2), currently under discussion by JEDEC, or other or combinations of storage technologies, and technologies based on derivations or extensions of such specifications.

A non-volatile memory (NVM) device is a memory whose state is determined even if power to the device is interrupted. In one embodiment, the NVM device may be a block-addressable memory device such as NAND technologies, or more specifically, multi-threshold NAND flash memory (e.g., single-level cell ("SLC"), multi-level cell (" MLC"), Quad-Level Cell ("QLC"), Tri-Level Cell ("TLC"), or other NAND). An NVM device may also include a byte-addressable three-dimensional write-in-place cross-point memory device or other byte-addressable write-in-place NVM device (also referred to as persistent storage), such as single or multi-level phase change memory (PCM) or phase change memory with a switch (PCMS), Intel® Optane™ memory, NVM devices using chalcogenide phase change material (eg, chalcogenide glass), resistive memory, comprising metal oxide based, oxygen vacancy based and conductive bridge random access memory (CB-RAM), nanowire memory, ferroelectric random access memory (FeRAM, FRAM), magnetoresistive random access memory (MRAM) with memristor technology, spin transfer torque (STT) MRAM, a spintronic magnetic junction memory based device, a magnetic tunneling junction (MTJ) b asing device, a DW (Domain Wall; domain wall) and SOT (Spin Orbit Transfer) based device, a thyristor based memory device or one or more of the above or other memory.

A power source (not shown) provides power to the system 900 components. More specifically, a power source typically interfaces with one or more power supplies in the system 900 to provide power to the system 900 components. In one example, the power supply includes an AC-to-DC (alternating current to direct current) adapter for plugging into an electrical outlet. Such alternating current (AC) power may be a renewable energy (e.g., solar power) power source. In one example, a power source includes a direct current (DC) power source, such as an external alternating current to direct current (AC to DC) converter. In one example, a power source or power supply includes wireless charging hardware for charging via proximity to a charging pad. In one example, a power source may include an internal battery, an AC power supply, a motion-based power supply, a solar power supply, or a fuel cell source.

Embodiments herein may be implemented in various types of computing and networking equipment such as switches, routers, racks, and blade servers used in a data center and/or server farm environment. The servers used in data centers and server farms include tiered server configurations such as rack-based servers or blade servers. These servers are communicatively linked via various network approaches, such as partitioning server sets into local area networks (LANs) with appropriate switching and routing facilities between the LANs to form a private intranet. For example, cloud hosting facilities can typically utilize large data centers with multiple servers. A blade includes a separate computing platform configured to perform server-like functions, i.e., a "server on a card". Accordingly, a blade includes components that are common to conventional servers, including a main printed circuit board (mainboard; main board) that has internal cabling (e.g., buses) for coupling appropriate integrated circuits (ICs) and other components that are on the board are attached, provides.

In one example, system 900 may be implemented using interconnected computing systems of processors, memory, storage, network interfaces, and other components. High-speed links may be used to communicatively couple devices, where high-speed links may be consistent with one or more of: Ethernet (IEEE 802.3), remote direct memory access (RDMA), InfiniBand, Internet Wide Area RDMA Protocol (iWARP), User Datagram Protocol (UDP), quick User Datagram Protocol (UDP) Internet Connections (QUIC), RDMA over Converged Ethernet (RoCE), Peripheral Component Interconnect express (PCIe), Intel QuickPath Interconnect (QPI), Intel Ultra Path Interconnect (UPI), Intel On -Chip System Fabric (IOSF), Omnipath, Compute Express Link (CXL), HyperTransport, high-speed fabric, NVLink, Advanced Microcontroller Bus Architecture (AMBA) interconnect, OpenCAPI, Gen-Z, Cache Coherent Interconnect for Accelerators (CCIX), 3GPP Long Term Evolution (LTE) (4G), 3GPP 5G, and variations thereof. Data may be copied or stored on virtualized storage nodes using a protocol such as NVMe over Fabrics (NVMe-oF) or NVMe.

10 Figure 10 illustrates an environment 1000 comprising multiple compute racks 1002, some of which include a top of rack (ToR) switch 1004, a pod manager 1006, and a plurality of pooled system drawers. Various embodiments may be used to decrypt data on a network interface and perform header lookup on a network interface. In general, the pooled system drawers may include pooled compute drawers and pooled storage drawers. Optionally, the pooled system drawers may also include pooled memory drawers and pooled input/output (I/O) drawers. In the illustrated embodiment, the pooled system drawers include an Intel® XEON® pooled compute drawer 1008 and an Intel® ATOM™ pooled compute drawer 1010, a pooled storage drawer 1012, a pooled memory drawer 1014, and a pooled I/O drawer 1016. Some of the pooled system drawers are connected to the ToR switch 1004 via a high-speed link 1018, such as an Ethernet link or a silicon photonics (SiPh) optical link.

Multiple of the compute racks 1002 may be interconnected (e.g., to a pod-level switch or a data center switch) via their ToR switches 1004 as represented by connections to a network 1020 . In some embodiments, groups of compute racks 1002 are managed as separate pods via a pod manager 1006 . In one embodiment, a single pod manager is used to manage racks in the pod. Alternatively, distributed pod managers can be used for pod management operations.

An environment 1000 also includes a management interface 1022 used to manage various aspects of the environment. This includes managing a rack configuration, with corresponding parameters stored as rack configuration data 1024 .

In some examples, the network interface and other embodiments described herein may be used in conjunction with a base station (e.g., 3G, 4G, 5G, etc.), macro base station (e.g., 5G networks), pico station (e.g., a IEEE 802.11 compliant access point), nanostation (e.g., for point-to-multipoint (PtMP) applications), on-premises data centers, remote data centers, edge network elements, fog network elements, and/or hybrid data centers (e.g., data centers, that use virtualization, cloud, and software-defined networking to deliver application workloads across physical data centers and distributed multi-cloud environments).

Various examples may be implemented using hardware elements, software elements, or a combination of both. In some examples, hardware elements can include devices, components, processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, etc.), integrated circuits, ASICs, PLDs, DSPs, FPGAs, memory units, logic gates, registers , a semiconductor device, chips, microchips, chipsets, etc. In some examples, software elements can be software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, APIs, sets of instructions, computational code, computer code, code segments , computer code segments, words, values, symbols, or any combination thereof. The determination of whether an example is implemented using hardware elements and/or software elements can be made according to any number of factors such as desired computation rate, power levels, thermal tolerances, processing cycle budget, input data rates, output data rates , memory resources, data bus speeds, and other design or performance constraints as desired for a given implementation. A processor can be one or more of a combination of a hardware state machine, digital control logic, central processing unit, or any hardware, firmware, and/or software elements.

Some examples may be implemented using or as an article of manufacture or at least one computer-readable medium. A computer-readable medium may include a non-transitory storage medium for storing logic. In some examples, the non-volatile storage medium may include one or more types of computer-readable storage media capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, and so on. In some examples, the logic can be various software elements, such as software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, API, sets of instructions , computational code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof.

According to some examples, a computer-readable medium may include a non-transitory storage device medium for storing or maintaining instructions that, when executed by a machine, computing device, or system, cause the machine, computing device, or system to perform methods and/or operations pursuant to carry out the examples described. The instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, and the like. The instructions may be implemented according to a predefined computer language, manner, or syntax to direct a machine, computing device, or system to perform a particular function. The instructions may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled, and/or interpreted programming language.

One or more aspects of at least one example may be implemented by representative instructions, stored on at least one machine-readable medium, representing various logic within the processor that, when read by a machine, computing device, or system, the machine , causing the computing device or system to produce logic for performing the techniques described herein. Such representations, known as "IP cores," may be stored on a tangible, machine-readable medium and shipped to various customers or manufacturing facilities for loading into the manufacturing machines that actually make the logic or processor.

Occurrences of the phrase "a single example" or "an example" are not necessarily referring to the same example or embodiment. Any aspect described herein may be combined with any other aspect or similar aspect described herein, regardless of whether the aspects are described in relation to the same figure or element. Dividing, omitting, or including block functions depicted in the accompanying figures does not imply that the hardware components, circuits, software, and/or elements to implement those functions must necessarily be divided, omitted, or included in exemplary embodiments.

Some examples may be described using the terms "coupled" and "connected" along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, descriptions using the terms "connected" and/or "coupled" may indicate that two or more elements are in direct physical or electrical contact with one another. However, the term "coupled" can also mean that two or more elements are not in direct contact with each other, but continue to cooperate or interact with each other.

The terms "first,r,s", "second,r,s" and the like are not used herein to denote any order, quantity, or importance, but rather are used to distinguish one element from another. As used herein, the terms "a,e,s" (a, an) do not denote a quantity limitation, but rather the presence of at least one of the items referred to. The term "asserted," as used herein with respect to a signal, means a state of the signal in which the signal is active and achieved by applying any logic level to the signal, either logic 0 or logic 1 can. The terms "follow" or "after" may refer to immediately following or following another event or events. Other sequences of steps may also be performed according to alternative embodiments. Furthermore, additional steps may be added or removed depending on the particular application. Any combination of changes may be used and the many variations, modifications, and alternative embodiments would be understood by those skilled in the art having the benefit of this disclosure.

Disjunctive language, such as the phrase "at least one of X, Y, or Z," unless specifically stated otherwise, is otherwise understood within the context generally used to show that an object, term, etc. can be either X, Y or Z or any combination thereof (e.g. X, Y and/or Z). Thus, such disjunctive language is not generally intended and is not intended to imply that particular embodiments require the presence of at least one of X, at least one of Y, or at least one of Z. Additionally, conjunctive language such as the phrase "at least one of X, Y, and Z" should also be understood as X, Y, Z, or any combination thereof, including "X, Y, and/or Z", unless specifically stated otherwise .

Representative examples of the devices, systems, and methods disclosed herein are provided below. An embodiment of the devices, systems, and methods may include any one or more and any combination of the examples described below.

Example 1 includes an apparatus comprising: a Transport Layer Security (TLS) offload engine to: based on detection of encrypted data unassociated with a previously detected data header: search for one or more data headers; identify at least two candidate data headers for validation; and based on receiving an indication that the at least two candidate data headers are valid, perform decryption of received data in one or more packets.

Example 2 includes one or more other examples wherein the TLS offload engine is configured to: based on receiving an indication that one or more of the at least two candidate data headers is not a valid header, for two or more other candidate search data headers.

Example 3 includes one or more other examples wherein, to search for one or more data headers, the TLS offload engine is configured to: identify a header character set associated with a first candidate data header; determine a data length associated with the first candidate data header; and identify the header character set associated with a second candidate data header at a location based on the data length.

Example 4 includes one or more other examples wherein to identify at least two candidate data headers for validation, the TLS offload engine is configured to: provide the first and second candidate data headers to another agent or entity for validation .

Example 5 includes one or more other examples where the TLS offload engine is configured to: search for another candidate data header after the first candidate data header and before the second candidate data header.

Example 6 includes one or more other examples where at least one candidate data header includes one or more of: a preamble, a header, and a length field.

Example 7 includes one or more other examples where to search for one or more data headers, the TLS offload engine is configured to use resources otherwise used for decryption to search for one or more data headers.

Example 8 includes one or more other examples and includes a network interface that includes the TLS offload engine, wherein the network interface includes one or more of: an infrastructure processing unit (IPU), a data processing unit (DPU), a network interface controller (NIC), or a smartNIC.

Example 9 includes one or more other examples and includes a server, the server configured to determine whether the at least two candidate data headers are valid and to indicate whether the at least two candidate data headers are valid or one or include multiple invalid candidate data headers.

Example 10 includes one or more other examples and includes a method comprising: at a Transport Layer Security (TLS) offload engine based on the detection of encryption lten data not associated with a previously detected header: searching for one or more headers; identifying at least two candidate headers; and based on receiving an indication that the at least two candidate headers are valid headers, performing decryption of received data in one or more packets.

Example 11 includes one or more other examples and includes: at the TLS offload engine: based on receiving an indication that one or more of the at least two candidate headers is not a valid header, searching for two or more other candidate headers.

Example 12 includes one or more other examples, searching for one or more headers comprising: identifying a header character set associated with a first candidate header; determining a data length associated with the first candidate header; and identifying the header character set associated with a second candidate header at a location based on the data length.

Example 13 includes one or more other examples comprising identifying at least two candidate headers for validation: providing the first and second candidate headers to a server for validation.

Example 14 includes one or more other examples and includes: searching for another candidate header after the first candidate header and before the second candidate header.

Example 15 includes one or more other examples where at least one candidate header includes one or more of: a preamble, a header, and a length field.

Example 16 includes one or more other examples and at least one computer-readable medium comprising instructions stored thereon that, if executed by at least one processor, cause the at least one processor to: execute a device driver to configure a network interface controller to: searches for two or more candidate headers based on an identification of data for which its header has not previously been identified.

Example 17 includes one or more other examples wherein to search for two or more candidate headers, the network interface controller is configured to: identify a header character set associated with a first candidate header; determining a data length associated with the first candidate header; and identifying the header character set associated with a second candidate header.

Example 18 includes one or more other examples where the network interface controller is configured to: provide the first and second candidate headers to a host system for validation.

Example 19 includes one or more other examples wherein to search for one or more candidate headers, the network interface is configured to: search for another candidate header after the first candidate header and before the second candidate header.

Example 20 includes one or more other examples where at least one candidate header includes one or more of: a preamble, a header, and a length field.

Claims (20)

A device comprising: a Transport Layer Security (TLS) offload engine to: based on the detection of encrypted data not associated with a previously detected data header: search for one or more data headers; identify at least two candidate data headers for validation, and perform decryption of received data in one or more packets based on receiving an indication that the at least two candidate data headers are valid. The device according to claim 1 wherein the TLS offload engine is configured to: search for two or more other candidate data headers based on receiving an indication that one or more of the at least two candidate data headers are not a valid header. The apparatus of any preceding claim, wherein to search for one or more data headers, the TLS offload engine is configured to: identify a header character set associated with a first candidate data header; determine a data length associated with the first candidate data header; and identify the header character set associated with a second candidate data header at a location based on data length. The device according to claim 3 wherein to identify at least two candidate data headers for validation, the TLS offload engine is configured to: provide the first and second candidate data headers to another agent or entity for validation. The device according to claim 3 or 4 wherein the TLS offload engine is configured to: search for another candidate data header after the first candidate data header and before the second candidate data header. The device according to claim 1 wherein at least one candidate data header comprises one or more of: a preamble, a header, and a length field. The apparatus of any preceding claim, wherein to search for one or more data headers, the TLS offload engine is configured to use resources otherwise used for decryption to search for one or more data headers. The device according to any one of the preceding claims, comprising a network interface comprising the TLS offload engine, the network interface comprising one or more of: an infrastructure processing unit (IPU), a data processing unit (DPU), a network interface controller (NIC) or a smartNIC. The device according to any one of the preceding claims, comprising a server, the server being adapted to determine whether the at least two candidate data headers are valid and to indicate whether the at least two candidate data headers are valid or one or contain multiple invalid candidate data headers. A method comprising: at a Transport Layer Security (TLS) offloading engine, based on the detection of encrypted data not associated with a previously detected header: Search for one or more headers; identifying at least two candidate headers; and based on receiving an indication that the at least two candidate headers are valid headers, performing decryption of received data in one or more packets. The procedure according to claim 10 comprising: at the TLS offload engine: based on receiving an indication that one or more of the at least two candidate headers is not a valid header, searching for two or more other candidate headers. The procedure according to claim 10 or 11 , searching for one or more headers, comprising: identifying a header character set associated with a first candidate header; determining a data length associated with the first candidate header; and identifying the header character set associated with a second candidate header at a location based on the data length. The procedure according to claim 12 , identifying at least two candidate headers for validation, comprising: providing the first and second candidate headers to a server for validation. The procedure according to claim 12 or 13 , comprising: searching for another candidate header after the first candidate header and before the second candidate header. The procedure according to claim 12 , 13 or 14 wherein at least one candidate header comprises one or more of: a preamble, a header, and a length field. At least one computer-readable medium comprising instructions stored thereon that, when executed by at least one processor, cause the at least one processor to: Running a device driver to configure a network interface controller to search for two or more candidate headers based on an identification of data for which its header has not previously been identified. The at least one computer-readable medium according to Claim 16 wherein to search for two or more candidate headers, the network interface controller is configured to: identify a header character set associated with a first candidate header; determining a data length associated with the first candidate header; and identifying the header character set associated with a second candidate header. The at least one computer-readable medium according to Claim 17 , wherein the network interface controller is configured to: provide the first and second candidate headers to a host system for validation. The at least one computer-readable medium according to Claim 17 or 18 wherein to search for one or more candidate headers, the network interface is configured to: search for another candidate header after the first candidate header and before the second candidate header. The at least one computer-readable medium according to Claim 18 , 18 or 19 wherein at least one candidate header comprises one or more of: a preamble, a header, and a length field.

Images