Abstract: A method may include determining a first weight for a first type of operation and a second weight for a second type of operation. The first weight may correspond to a first quantity of the first type of operation a hardware resource is capable of performing during a time interval. The second weight may correspond to a second quantity of the second type of operation the hardware resource is capable of performing during the time interval. Utilization of the hardware resource may correspond to a weighted sum of the respective quantities of the first type of operation and the second type of operation offloaded to the hardware resource. Allocation of hardware resources may be adjusted based on utilization. Related systems and articles of manufacture are also provided.

Abstract: The present invention is directed towards systems and methods for managing one or more SSL sessions. A first node from a cluster of nodes intermediary between a client and a server may receive a first request from the client to use a first session established with the server. The first request may include a session identifier of the first session. The first node may determine that the first session is not identified in a cache of the first node. The first node may identify, via a hash table responsive to the determination, an owner node of the first session from the cluster using a key. The key may be determined based on the session identifier. The first node may send a second request to the identified owner node for session data of the first session. The session data may be for establishing a second session with the server.

Abstract: The present invention is directed towards systems and methods for distributed operation of a plurality of cryptographic cards in a multi-core system. In various embodiments, a plurality of cryptographic cards providing encryption/decryption resources are assigned to a plurality of packet processing engines in operation on a multi-core processing system. One or more cryptographic cards can be configured with a plurality of hardware or software queues. The plurality of queues can be assigned to plural packet processing engines so that the plural packet processing engines share cryptographic services of a cryptographic card having multiple queues. In some embodiments, all cryptographic cards are configured with multiple queues which are assigned to the plurality of packet processing engines configured for encryption operation.

Abstract: This disclosure is directed to systems and methods for handling the processing of a next protocol negotiation extension for a transport layer security (TLS) session. A device, intermediary to a client and a server, may receive a client hello message from the client in a handshake to establish a transport layer security (TLS) session with the server. The client hello message may include a next protocol negotiation extension. The device may include a first TLS processor that is software based and a second TLS processor that is hardware based. The device may determine that the client hello message includes the next protocol negotiation extension. The device may establish, responsive to the determination, the TLS session using the first TLS processor. The device may process, upon establishment of the TLS session using the first TLS processor, encrypted data for the TLS session using the second TLS processor.

Abstract: The present invention is directed towards systems and methods for managing one or more SSL sessions. A first node from a cluster of nodes intermediary between a client and a server may receive a first request from the client to use a first session established with the server. The first request may include a session identifier of the first session. The first node may determine that the first session is not identified in a cache of the first node. The first node may identify, via a hash table responsive to the determination, an owner node of the first session from the cluster using a key. The key may be determined based on the session identifier. The first node may send a second request to the identified owner node for session data of the first session. The session data may be for establishing a second session with the server.

Abstract: This disclosure is directed to systems and methods for handling the processing of a next protocol negotiation extension for a transport layer security (TLS) session. A device, intermediary to a client and a server, may receive a client hello message from the client in a handshake to establish a transport layer security (TLS) session with the server. The client hello message may include a next protocol negotiation extension. The device may include a first TLS processor that is software based and a second TLS processor that is hardware based. The device may determine that the client hello message includes the next protocol negotiation extension. The device may establish, responsive to the determination, the TLS session using the first TLS processor. The device may process, upon establishment of the TLS session using the first TLS processor, encrypted data for the TLS session using the second TLS processor.

Abstract: The present invention is directed towards systems and methods for distributed operation of a plurality of cryptographic cards in a multi-core system. In various embodiments, a plurality of cryptographic cards providing encryption/decryption resources are assigned to a plurality of packet processing engines in operation on a multi-core processing system. One or more cryptographic cards can be configured with a plurality of hardware or software queues. The plurality of queues can be assigned to plural packet processing engines so that the plural packet processing engines share cryptographic services of a cryptographic card having multiple queues. In some embodiments, all cryptographic cards are configured with multiple queues which are assigned to the plurality of packet processing engines configured for encryption operation.

Abstract: The present invention is directed towards systems and methods for distributed operation of a plurality of cryptographic cards in a multi-core system. In various embodiments, a plurality of cryptographic cards providing encryption/decryption resources are assigned to a plurality of packet processing engines in operation on a multi-core processing system. One or more cryptographic cards can be configured with a plurality of hardware or software queues. The plurality of queues can be assigned to plural packet processing engines so that the plural packet processing engines share cryptographic services of a cryptographic card having multiple queues. In some embodiments, all cryptographic cards are configured with multiple queues which are assigned to the plurality of packet processing engines configured for encryption operation.

Abstract: The present invention is directed towards systems and methods for maintaining Certificate Revocation Lists (CRLs) for client access in a multi-core system. A first core may generate a secondary CRL corresponding to a master CRL maintained by the first core. The CRLs may identify certificates to revoke. The first core can store the secondary CRL to a memory element accessible by the cores. A second core may receive a request to validate a certificate. The second core can provisionally determine, via access to the secondary CRL, whether the certificate is revoked. The second core may also determine not to revoke the certificate. Responsive to the determination, the second core may request the first core to validate the certificate. The first core can determine whether to revoke the certificate based on the master CRL. The first core may send a message to the second core based on the determination.

Abstract: The present invention is directed towards systems and methods for distributed operation of a plurality of cryptographic cards in a multi-core system. In various embodiments, a plurality of cryptographic cards providing encryption/decryption resources are assigned to a plurality of packet processing engines in operation on a multi-core processing system. One or more cryptographic cards can be configured with a plurality of hardware or software queues. The plurality of queues can be assigned to plural packet processing engines so that the plural packet processing engines share cryptographic services of a cryptographic card having multiple queues. In some embodiments, all cryptographic cards are configured with multiple queues which are assigned to the plurality of packet processing engines configured for encryption operation.

Abstract: The present invention is directed towards systems and methods for maintaining Certificate Revocation Lists (CRLs) for client access in a multi-core system. A first core may generate a secondary CRL corresponding to a master CRL maintained by the first core. The CRLs may identify certificates to revoke. The first core can store the secondary CRL to a memory element accessible by the cores. A second core may receive a request to validate a certificate. The second core can provisionally determine, via access to the secondary CRL, whether the certificate is revoked. The second core may also determine not to revoke the certificate. Responsive to the determination, the second core may request the first core to validate the certificate. The first core can determine whether to revoke the certificate based on the master CRL. The first core may send a message to the second core based on the determination.