Query about running many, many, rules

[Alan DeKok <aland () deployingradius com>]

  How does PCAP handle running many rules?  The current approach is to
open one PCAP interface per rule.

  The end goal is to be able to run an live application with 1000's of
simultaneous rules.

  The issue is that the current pcap_open_* interfaces are pretty
limited.  I could open one pcap structure per rule.  But for my eventual
application, that would be bad.  It would mean copying each packet from
kernel space to user space, once for every rule.  At gigabit speeds, we
quickly become overloaded.

  I have some hardware which does a quick pass over the packet, binning
it into one of N buckets.  It uses a bloom filter approach to reject
many packets which won't match any rule.  The output of the HW is a tag
which says "looks like it matches rule X".

  I'd like to be able to take that tag, and use it to feed the packet
into a PCAP filter which does more in-depth checks.

  However... I can't do this right now.  There's pcap_open_live() for
interfaces.  There's pcap_open_offline() for files.  There's no
interface which says "here's a packet, run the rule against it".

  I think that this may be possible, without too much work.  I propose
the following:


1)  Create a function which will allow packet injection into pcap:

typedef int (*pcap_read_callback)(pcap_t *p, void *ctx, u_char *buffer,
                                int bufsize)

  This function would be called through pcap_read().  It would use a
user-supplied context to write data into the buffer, and return the
number of bytes written.


2) create a function which would open a "pcap" structure, using the
   above callback:

pcap_t *pcap_open_callback(pcap_read_callback callback, void *ctx,
                                char *ebuf, size_t size);


  The application could then open 1000's of these structures, as it's
just memory.  It would then get packets from the kernal (once), along
with the hardware tag.  The tag would tell it which pcap_t to use for
more detailed checks.


  I think that API is fairly simple.  It seems to fit with the current
philosophy of the pcap library and API.

  Comments?

  Alan DeKok.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers