Argus 2.0 wishes

[Peter Van Epp]

> 
> Hey Peter,
>    Well, argus doesn't report the ICMP byte counts.
> In order to convey some critical ICMP data for
> redirect and unreachable ICMP flows, I borrowed the
> src and dst byte count fields.  I can fix this, but
> it will change the format of some ICMP flows, and
> so the change will have to be in 1.9 or 2.0, whichever
> is next.

	Yes I remembered that being said before about ICMP (that somewhere was
needed for the flag bytes and counts were it) probably when I asked about 
ICMP counts in the past :-).
	
> 
>    The frag record is actually pretty interesting.
> It is generated when a fragment could not be mapped
> to a parent flow because the 0 offset packet was not
> seen.  This is the basis of a fragment covert channel.
> This condition also happens when packets are naturally
> dropped in the network, so you should take the indication
> with a grain of salt.  The record is trying to help you
> to know the nature of the problem, the record that
> we generate has some fragment reassembly metrics in it.
> 
>    The fields are:
> 
> > Thu 03/09 05:52:25 frag  ip  203.108.46.136        ->  
> > 142.58.230.123 
> 
>                         Pkts   Bytes     Bytes     Max Bytes
>                Frag ID  recv   expected  observed  per Pkt    State
>                  54016  pk  1  ex    0   ob  156   max  156   TIM
>     
> The bytes expected is extracted from the first packet, and so
> if the first packet isn't received this value can't be supplied.
> 
> Carter
> 

	Thanks that helps a lot. It looks like a good plan would be to check
for a successful flow between the end points nearby in time (especially if 
it has the "frags" flag set), if there is one its probably dropped packets,
if there isn't the "scumbag cracker" alert should go off and the sniffer 
get deployed to look more closely :-) keeping in mind that it still might 
just be dropped packets. The idea is to direct limited human attention to 
things that might or might not be problems but need a human to decide.

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada