[Bro] linking a wrong_fragment event to a connection

[Vern Paxson]

> Thanks for your kindly answer about fragment. So maybe I should focus on
> bad_TCP_checksum / bad_UDP_checksum and bad_icmp_checksum instead
> of excessively_large_fragment, excessively_small_fragment,
> fragment_inconsistency,
> fragment_overlap,fragment_protocol_inconsistency
> etc..)? In that case, I will have the header with the information I need.

Yes, those all have some sort of flow information associated with them.
(Though I would skip bad_icmp_checksum, as for ICMPs the flow is a somewhat
vague notion.)

> BTW, in the case of BRO processed KDDCup 99 data

Side note: I hope you're only looking at that data get a handle on using
Bro or such.  Using it for research is a well-known pitfall; see
http://www.icir.org/vern/talks/vp-IDS-Pitfalls-DIMVA07.pdf .

> when BRO encounters a flow mid-stream and that flow get shut down BRO uses
> SF label. You mentioned plans for adding Bro state tracking to solve it.
> What is the situation at the moment?

It's available, see the discussion "If you set the new control variable
record_state_history to T" in the CHANGES file.

> The paper I am talking about defines the timeouts that could affect the
> probability to split a flow during its lifetime:
> active timeout is full length of TCP connection passive timeout refers to
> idle times in active flows where no packet is transfer (it is called also
> the maximum packet gap).

Bro does the latter, since it needs to make the decision in real-time.

		Vern