TCP Session
Reassembly
TCP reassembly causes the sensor to reassemble a TCP
session's packets before they are compared against the signatures. This helps
keep resources from being tied up. There are three TCP session reassembly
options you can choose from: No Reassembly, Loose Reassembly, and Strict
Reassembly.
|
Note |
This only applies to version 2.5(X) software and later for
the IDSM. If you do not have an IDSM, this section will not apply. |
No Reassembly
Simply stated, the sensor does not reassemble TCP sessions.
All packets are processed on arrival. No reassembly can generate false positives
and negatives because of the potential for packets being processed out-of-order.
It is not recommended unless your network is subject to a higher-than-normal
rate of packet loss.
Loose Reassembly
A step up from not reassembling at all, loose reassembly
does process all packets in order. The problem loose reassembly causes is the
same though. False positive alarms are generated because the sensor allows gaps
in the sequence when reassembling the session record.
Strict Reassembly
If you are going to do TCP session reassembly, strict
reassembly is the way to go. I'd like to say there is no chance of any false
positives or negatives, but you might try and hold me to it. The odds are in my
favor though. Unless all of the packets are received and the session is
completely reassembled, the sensor will not analyze the session.
|
Warning |
Remember, when we talk about reassembly (whenever you have a
network device do any type of reassembly of fragments, sessions, and so on…),
we're talking about the overhead involved. It will consume memory and be
CPU-intensive. |
Sections
Comments (0 posted)
Syndication
