TCP Segment limit enforcement

[Michael_Gonnaso]

Does anyone have any details regarding "TCP Segment limit enforcement" is? We are running R80.10 take 70 on all devices.

We recently had an issue where our Checkpoint was causing a slowdown in all traffic, which was solved by failing over the cluster. 

After that I was looking through the logs and saw millions of matches on the IPS protection "TCP Segment limit enforcement".

We did not have any network events, or loops, during this issue. Some traffic would make it fine, as it was seemingly random as to what the Checkpoint would drop.

I did find a seeming related SK but it is only for R77: sk114529

Traffic is dropped by IPS protection "TCP Segment Limit Enforcement" due to attack "TCP segment out ... 

[PhoneBoy]

The SK is still relevant for R80.10 (even though it is not marked as such).

Threat Description	For every TCP segment that passes through the Security Gateway, the Security Gateway  retains a copy of the segment until it receives an acknowledgment that the segment was received. This buffered data occupies space in the Security Gateway's memory.
IPS Protection Description	This IPS protection enforces a limit on the number and size of buffered segments per connection. When a connection reaches one of these limits, the Security Gateway will not accept new segments for this connection until buffered segments are acknowledged.

Bottom line: IPS is "holding" some TCP traffic back until the remote end acknowledges receipt.

Most TCP/IP stacks handle this situation ok, so applications may not notice an issue (except perhaps as a delayed response).

[Michael_Gonnaso]

Interesting. Ok so it does apply.

What is the risk we are attempting to mitigate or control with this IPS protection?

I understand you wouldn't want hosts to send more data than the window, but a host generally would reject the extra data anyways. Same with unacknowledged data.

[PhoneBoy]

Some TCP/IP stacks don't handle this overflow condition gracefully 

Also you might be able to figure out what the remote IP stack is by playing with these windows.

[Michael_Gonnaso]

Ok awesome, thank you for the information.

It sounds like it is best for inspecting traffic from external sources, and generally not all internal traffic.

Always assess your risks and understand what the protection is mitigating/controlling. 

[Albert_Wilkes]

Regarding impact after disabling a protection: I believe to have read somewhere and/or logically think that disabling this protection will basically allow an attacker to bypass ALL your layer 7 protections in URLF, APCL, IPS, DLP, AV etc.. This is because you would allow passthrough of packets (i.e. bytes, URLs, malware) that contain data that the CP parser can't put into context anymore. Say a signature for an attack that you configured in IPS to block TCP traffic consists of 10bytes, the way to bypass a protection would be to send the first (say) 9 bytes, then transmit enough data to exceed the sliding window buffer in the firewall's TCP implementation (say 32kb), then send the last byte of the 10bytes. They would potentially be reassembled by the communication partner which doesn't have to deal with thousands of simultaneous sessions and therefore might have a much bigger TCP receive window.

Happy to be proven wrong...

On another note, I seem to work with some customers that only saw this protection being triggered from R80.10 but we're still investigating.

[Trey_Havener]

Is there any way to bypass this protection between 2 gateways in a tunnel?  One of our remote sites is having all kinds of issues with this being triggered by a couple of different applications.  The Gateway at the remote site is a 1470 running 77.20.85 which is fairly up to date for that model. But that's not the side triggering it.  Our 5400s seem to be the ones barking about it which are running 80.20 Take 47.