1
2NetFlow TCP RST/FIN handling:
3
4	    According to some Cisco specs, and also according to the
5	IPFIX Applicability spec, the flows expiration algorithm
6	includes the condition where flushing is performed when
7	the Metering Process can detect the end of a Flow.
8	The example is given specifying the TCP RST or FIN bits
9	as the indicators of a connection termination.
10	    This supposedly intuitive behavior nevertheless has
11	a big flaw: the TCP connection does NOT usually end with
12	one these flags. Under normal circumstances, the last packet
13	of the TCP stream is ACK, which acknowledges a correctly
14	processed FIN (RFC793, #3.5).
15	    Any implementation which blindly expires the record
16	when it sees the RST or FIN TCP flags will indeed create
17	two flow records, one with the flow information about the
18	main body of a TCP connection, and another with only the
19	data about the ACK packet of that previously discovered
20	TCP stream.
21
22	    Overall, the question boils down to the following:
23	what is better: create a single flow and expire it
24	only after several seconds of its inactivity (when the
25	flow is supposedly finished), or create two flows,
26	one of which contains the main body of a connection and
27	another one describes the final ACK packet of this
28	connection (the last one is generated only after _its_
29	inactivity).
30
31	    The first way is chosen for IPCAD.
32