Argus tweaking and design considerations

[Peter Van Epp]

> 
> Argus tweaking and design considerationsMy comments mirror Peter's..
> 
> I think we should optimize for performance to get as much through as
> possible.
> Once we exceed maximum performance, it would be good to degrade as
> gracefully as possible, but I think we should prefer beefier/specialized
> hardware
> to overflow handling that produces suboptimal results anyway. I think that
> accuracy is *highly* important, up to the maximum data flow possible.

	One thing on my (infinitely long :-)) list of interesting things to 
poke at is an open source embedded OS that was mentioned in Circuit Cellar Inc
magazine. It runs an "optimised for performance" version of the FreeBSD/BSD4.4
IP stack and would probably make a good base for a dedicated sensor such as
has been discussed on the NFR list (bootable from CDrom, everything in memory
no file system per se, grabs packets, processes them in a way requested by
an external managment machine and forwards them (or the interesting parts of
them) out a link to the machine that deals with the exceptions. In the argus
case, it would aggregate the flows and shove only updates toward the management
reporting station. In the IDS case I'd see something like VJ header prediction
which strips uninteresting (i.e. expected headers) and only forwards as much
of the recovered data as the management station wants, but also forwards 
unexpected header values (i.e. ones that don't match the forward prediction)
as being a possible attack. Fragments with different offsets would be one 
case of this, unused flag bits changing state would be another). The advantage
is that you can limit the amount of processing you need to do at wire speed.
In this case you add in the mininum number of tasks needed to do your 
processing without any of the general purpose support a full OS needs (which
is both overkill and overhead in this application). There is a port that 
runs on PC hardware (for easy development) but it can be ported to custom
hardware (possibly required for the level of perfomance we are starting to 
talk about i.e. multistreams of DWDM on fibre).
	The first step in this is to do what I started out to do and 
characterize what load a given CPU/motherboard chipset/interface card/operating
system configuration will handle with argus which tells us were we are 
compared to where we want to be (and what the bottlenecks are to getting there).

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