[Bro] linking a wrong_fragment event to a connection

[Veronica Estrada]

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.

BTW, in the case of BRO processed KDDCup 99 data, all the wrong fragments
belong to SF labeled UDP/ICMP connections (for UDP connections wrong
fragment count is 3 and the others 1). I thought SF is printed for
completely flows but I read in an old message of this list (nov 2004) that
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?

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).

Thank you in advance for any help you can provide.
Veronica

On Fri, Mar 12, 2010 at 12:56 AM, Vern Paxson <vern at icir.org> wrote:

> > How can I know which connection has generated that wrong fragment event?
>
> In general you can't.  Most individual fragments do not possess transport
> headers, so there is no well-defined connection associated with them.
> *If* the fragment is part of a whole collection, then you can locate the
> transport header at the beginning of the collection and use its ports -
> but Bro may not have even seen this first part yet.  So it only reports
> the involved hosts.  (It also could in principle report ports if the
> problematic fragment happens to be the first *and* includes a full
> transport
> header [which it doesn't have to], but Bro doesn't go out of its way to
> do the extra work in this case.)
>
> > By the way, I read about active and passive timeouts on connections
> > ("Flow-based TCP Connection Analysis" by Limmer and Dressler).
> > I don't understand how this topic is treated in BRO.
>
> You'll need to explain how those timeouts are defined in that paper for
> others to be able to comment on how Bro's connection timeouts relate to
> them.
>
>                Vern
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20100313/9e38e54b/attachment.html