[Bro-Dev] #434: Fix secondary path

[Bro Tracker]

#434: Fix secondary path
---------------------+--------------------
  Reporter:  robin   |      Owner:
      Type:  Task    |     Status:  new
  Priority:  Normal  |  Milestone:  Bro2.2
 Component:  Bro     |    Version:
Resolution:          |   Keywords:
---------------------+--------------------

Comment (by seth):

 > Concrete example comes from wanting to estimate flow sizes in TCP
 traffic
 > without having to capture all TCP packets.  You can do this with SYN+FIN
 > packets, except for very large flows that wrap the sequence space, you
 > can't figure out the correct connection size.  large-conns.bro allows
 > figuring this out at only the cost of a pretty inexpensive additional
 > packet filter.

 Instead of doing a secondary filter, does it make sense to have a filter
 which leaves ack packets being allowed through?  You will increase the
 number of packets making it through (the default window for large-conns is
 16KB so you may even get ~16x as many packets).  The difference I see
 though is that for each captured packet with the secondary path mechanism
 it ends up creating a Bro data structure and inserting an event in the
 event queue which is going to have a fair amount of load by itself.

 You have the obvious benefits of complete ack tracking such as monitoring
 for gaps and reusing the existing connection size counting code in the
 core.

 There is a lot of infrastructure type work I have ready for the 2.2
 release too which will make a lot of this sort of large and (and possibly
 dynamic) filter creation much easier.  If you write filters dynamically
 that become too large they can start to take a significant amount of time
 to compile but we should be able to work around that by threading the bpf
 compilation step (another use for the 'when' statement?).  Compiled BPF
 filter insertion time doesn't seem to increase with an increase in the
 size of the filter either.

 There is another implicit problem with this example that I don't like in
 that it relies on TCP offsets which don't work in BPF for IPv6 traffic and
 I don't expect that to start working anytime soon.

 I'm not necessarily fighting for or against the secondary path, but I'm
 having a hard time finding a concrete example that can't be done without
 the secondary path.

-- 
Ticket URL: <http://tracker.bro-ids.org/bro/ticket/434#comment:6>
Bro Tracker <http://tracker.bro-ids.org/bro>
Bro Issue Tracker