000026663 - What is a 'session' in regards to the RSA NetWitness Platform?

For UDP, packets from same source and destination IP/ UDP port pairs are assembled into a session until it hits some of the pre-configured limits such as timeouts, assembler.size.max, etc.

For TCP, source and destination IP/TCP port pairs and TCP flags are used to to assemble a TCP session until it hits some of the pre-configured limits such as timeouts, assembler.size.max, etc.

In decoder, there are several parameters in /decoder/config node that dictates sessions:

assembler.size.max; assembler.timeout.session; assembler.timeout.packet; assembler.session.flush

assembler.size.max: limit the size of the session assembled;

assembler.timeout.session: specifies a time period to wait since last packet in the session before the session is considered ?completed?; it is used for all UDP and TCP traffic as well (decoder does not remove a TCP session when RST/FIN are encountered); if additional packets for the timed out session arrive later, a new session is created;

assembler.timeout.packet: behaves the same as it always has, timing packets out of the packet pool and sending them to the database. This comes into play when line rates are sufficiently low that waiting for the packet pool to fill would introduce latency beyond the timeout duration. When the packet pool is full, the oldest packets are removed when new packets are received and assembler.timespan will be less then assembler.timeout.packet. Normal behavior is for a session to be parsed after a timeout is reached or it's forced out of the pool due to memory constraints. However, if the session is not finished, packets should continue to be chained to that session after parsing, assuming assembler.session.flush is set to 1. The session will not be reparsed, but viewing the session in wireshark or in Investigator's content view will show the full packet capture, up until the session size limit is reached or until no more packets are seen according to the session timeout settings in assember.timeout.session parameter.

Setting session and packet timeouts to 0 will provide more accurate statistics, but the consequence is the session stays hidden in assembler longer, so this is not a good solution.