Check Point - Acceleration

SecureXL: Security Acceleration

SecureXL is a technology interface that accelerates multiple, intensive security operations, including operations carried out by Check Point's Stateful Inspection Firewall.
SecureXL accelerates Firewall and VPN performance by remembering certain attributes of packets and packet flows that have already been validated by the Firewall/VPN application. Then, validation of related packets and connections is delegated to the SecureXL API; this validation is done at the hardware interrupt level.

Packets attempting to establish a new TCP connection (or a comparable UDP) are handled in the slow path. Once the first packet is seen by the Firewall and suitable connections information is off-loaded to an appliance OS, further packets are handled at the OS's interrupt-level code.

SecureXL improved non-encrypted firewall traffic throughput and encrypted VPN traffic throughput. Packet acceleration is also referred to as throughput acceleration as it matches on the familiar 5-tuple of source address, destination address, source port, destination port and protocol. However, only packets during the specific TCP/UDP connection can be accelerated.

Session rate acceleration: SecureXL also reduces the overhead in establishing certain kinds of new connections, improving new connection rate(connections per second), connection setup/teardown rate (sessions per second) and throughput in certain high-connection rate traffic environment.

From a 5-tuple validation, the source port of a flow may be masked off, effectively providing a global match for source port. These new connection setup packets matching 4 out of 5 tuples avoid a round trip to the firewall application and limit the computing overhead. Security is not impacted because the OS continues to track the state of the new connection using Stateful inspection.

Application Layer Protocol (example HTTP)

Web pages consist of multiple components. Using HTTP 1.0, each component is downloaded from S2C using a separate TCP connection. This action involves substantial overhead in connection setup and tear-down and protective firewall connection tracking.

Once a connection involving a flow to port 80 is approved by the Firewall application for the web client (resulting from the first HTTP request), a template is created and stored. All subsequent connection setups carrying those additional requests can share that same template approval because it's ok that the source port differs. Establishing those subsequent connections does not involve a round trip to the Firewall, resulting in faster processing through the server Firewall.

HTTP 1.0 creates a separate connection for each HTTP component. The newer HTTP 1.1 improves the protocol's performance by permitting not only parallel, but also persistent and pipelined server connections. The server may keep the connection alive after sending the end of a component which avoids the need to create a new connection to send the next component.

FTP and many types of VOIP have handlers which precludes acceleration. There are several factors that preclude a packet from being accelerated (SDF, QoS, connections that have a Handler, multicast packets, etc.)
There are factors that can preclude templating if all other parameters are met for acceleration: time objects, dynamic objects, domain objects, source port ranges, IPS features not supported in Acceleration, NAT, Encrypted connections.

Once templating is disabled in the Rule Base, all connections matching rules lower in the Rule Base cannot be templated. Use fwaccel stat to determine at which rule templating is disabled and move the most used rules above that rule for session acceleration.

CoreXL: Multicore Acceleration