Configuring ICAP Client Data Trickling Parameters

Description

Patience pages provide a solution to appease users during relatively short delays in object scans. However, scanning relatively large objects, scanning objects over a smaller bandwidth pipe, or high loads on servers might disrupt the user experience, because connection timeouts occur. To prevent such time-outs, you can allow data trickling to occur. During the Data Trickling, the data transmits at a very slow rate to the client at the beginning of the scan, or near the very end.

Trickle from the Start mode

In Trickle from Start mode, the ICAP Client The ICAP Client functionality in your Security Gateway or Cluster (in versions R80.40 and higher) enables it to interact with an ICAP Server responses (see RFC 3507), modify their content, and block the matched HTTP connections. buffers a small amount of the beginning of the HTTP response body. As the ICAP Server The ICAP Server functionality in your Security Gateway or Cluster (in versions R80.40 and higher) enables it to interact with an ICAP Client requests, send the files for inspection, and return the verdict. continues to scan the HTTP response, the ICAP Client allows one byte per second to the HTTP Client. After the ICAP Server completes its scan, if the object is deemed to be clean (no HTTP response modification is required), the ICAP Client sends the rest of the object bytes to the HTTP Client at the best speed allowed by the connection. If the object is deemed to be malicious, the ICAP Client terminates the connection and the remainder of the HTTP response object. Trickling from the Start is the more secure Data Trickling option, because the HTTP Client receives only a small amount of data pending the outcome of the virus scan.

Trickle at the End mode

In Trickle at End mode, the ICAP Client sends the HTTP response to the HTTP Client at the best speed allowed by the connection, except for the last 16KB of data. As the ICAP Server performs the content scan, the ICAP Client allows one byte per second to the HTTP Client. After the ICAP Server completes its scan, if the object is deemed to be clean (no HTTP response modification is required), the ICAP Client sends the rest of the object bytes to the HTTP Client at the best speed allowed by the connection. This method is more user-friendly than Trickle at Start. This is because users tend to be more patient when they notice that 99% of the object is downloaded versus 1%, and are less likely to perform a connection restart. However, network administrators might perceive this method as the less secure method, as a majority of the object is delivered before the results of the ICAP scan.

Notes about Data Trickling on Check Point Security Gateway

There is no true data-modification (meaning, no true content adaptation) during the data trickling.

In the Trickling at the End mode, there is no data modification at all.
Data Trickling (both Trickling from the Start and Trickling at the End modes) cannot work when there is no Content-length header in the HTTP message.
In the Trickling at the End mode, Check Point Security Gateway Dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies for connected network resources. supports the 204 status code (with the HTTP header "Allow: 204", for HTTP reply "No change / Unmodified").
There is still an applicative timeout (:icap_servers ()- :timeout) of the ICAP session that user needs to define according to the icap-service demand, after which the fail-action follows.

The applicative timeout is also a factor in determining the maximal buffer size for Trickling from the Start mode..

Configuring ICAP Client Data Trickling

You configure the ICAP Client Data Trickling with the specific kernel parameters on Security Gateway.

For general instructions, see the R81 Quantum Security Gateway Guide > Chapter Working with Kernel Parameters on Security Gateway.

Kernel Parameter 1

Item	Description
Name	`icap_blade_trickling_bytes_ps`
Description	Specifies how many bytes per second to send to the original HTTP destination, while Trickling from the Start works. The HTTP Client sees very slow upload and download progress.
Type	Integer
Default value	10
Notes	The configured value must be much less than the byte-rate of the ICAP connection.
Example	If the ICAP Server scans a file with the size of ~600 kilobytes for a 1 minute, the ICAP connection byte-rate is ~10 kilobytes per second. Therefore, the configured value must be much less than 10,000 bytes per second.

Kernel Parameter 2

Item	Description
Name	`icap_blade_trickling_interval`
Description	Specifies the interval in seconds for sending bytes to the original HTTP destination, while Trickling from the Start works.
Type	Integer
Default value	1
Notes	The configured value must be more than or equal to 1.
Example	Value 2 means that the ICAP Client sends bytes to the original HTTP destination only every 2 seconds.

Kernel Parameter 3

Item	Description
Name	`icap_blade_trickling_threshold_mb`
Description	Specifies the Content-Length threshold in megabytes. Only if the HTTP Content-Length of the original HTTP connection is greater than this threshold, the Trickling from the Start is activated.
Type	Integer
Default value	0
Example	Value 1 means: The ICAP Client sends only files that are larger than 1 megabyte to the original HTTP destination. The ICAP Client does not send all other files before it gets the verdict from the ICAP Server.

Kernel Parameter 4

Item	Description
Name	`icap_blade_trickling_kbytes_from_end`
Description	During the Trickling at the End mode, specifies how many kilobytes ICAP Client does not send to the original HTTP destination before the ICAP Client gets the verdict from the ICAP Server.
Type	Integer
Default value	16
Example	Value 16 means: The ICAP Client does not send only the last 16 kilobytes of the file before it gets the verdict from the ICAP Server. The ICAP Client sends all other files to the original HTTP destination in the HTTP connection byte-rate.