Current IXP projects at the Vrije Universiteit comprise 3 themes:
In intrusion detection, we have built a signature detection system on
an IXP1200 network card (with an eye on making the solution cheap). We
have published results in RAID'05~\cite{cardguard:05}. It uses the
Aho-Corasick string matching algorithm to find signatures of worms,
viruses, spam, etc. in live traffic streams. For UDP, we were able to
achieve speeds under worst-case conditions (every packet needs to be
scanned in its entirety for all rules) that easily exceed 500
Mbps. For TCP with full TCP flow reconstruction we were still able to
achieve 100 Mbps under worst-case scenarios. One of the reasons why we
achieved fairly high rates on such an old card is that we discovered
and exploited signifant locality of reference in the Aho-Corasick
algorithm with realistic rules (thousands of snort rules) and real
traffic. Indeed, only a small number of states is visited frequently,
while all other states are visited hardly ever. By mapping the
deterministic finite automaton that constitutes the runtime part of
the Aho-Corasick algorithm in an efficient way over the various levels
in the memory hierarchy (frequently needed states are stored in fast
on-chip memory, all other states are in slow off-chip DRAM), we don't
suffer many off-chip memory references that would slow down the
system. The system may function either as an intrusion detection
system or as an intrusion prevention system. The current status of
this project is that we have developed a more elaborate pattern
matching algorithm and are currently implementing it on the Intel
IXP2400 and IXDP2850 network processors.
References:
@InProceedings{cardguard:raid05,
  author = {Herbert Bos and Kaiming Huang},
  title = {Towards software-based signature detection for intrusion prevention on the network card},
  booktitle = {Proceedings of Eighth International Symposium on Recent Advances in Intrusion Detection (RAID2005)},
  year = 2005,
  address = {Seattle, WA},
  url = {http://www.cs.vu.nl/~herbertb/papers/cardguard_raid05.pdf},
  month = {September}
}
A large effort constitutes the Fairly Fast Packet Filters (FFPF) network monitoring project~\cite[ffpf:osdi04]. The idea of FFPF is to allow end-users to simply click together packet processing functions to form a complex packet processing graph (not unlike the way one composes a graph in the Click router project) that is subsequently instantiated in {\em all} relevant levels of the processing hierarchy: userspace at the host, kernelspace at the host, user/kernelspace at the IXP's XScale and the IXP's microengines. FFPF is responsible both for locating the level at which to instantiate a function and for automatically connecting it to elements on which it depends. In doing so, it makes sure that the configuration is such that as much processing as possible is performed at the lowest levels of the processing hierarchy (e.g., the network card) and that needless packet copies are avoided (e.g., packets may be memory mapped to higher levels, or a function at a lower level may write directly to memory at the higher levels in a DMA-like fashion).
The FFPF framework is both very efficient (e.g., in avoiding memory copies and context switching where possible and using DMA where needed) and flexible in the way in which new and heterogeneous hardware can be incorporated. We have developed several packet processing languages (collectively known as the FFPF packet languages~\cite{fpl3:networking05}, or FPL) that are more expressive than most existing filter languages (such as the well-known BSD packet filters). For instance, unlike BPF it allows for persistent state, common programming constructs such as looping, and the use of external functions. This permits programmers to write fairly complex programs in FPL (e.g., functions to gather statistics, transcode packets, or even to use external functions implemented in hardware or C to embed computationally expensive operations such as encryption in an efficient manner). The FPL compiler is able to generate the following types of object code: (a) shared libraries in user space, (b) Linux kernel modules, or (c) object code for the IXP's microengines. As the object code consists of highly optimised native code, the language offers good performance. At the same time, it is a high-level language, designed to be easy to use by end users such as system administrators~\cite{nicfix:ipom04}.
While we have developed our own FPL languages to fully exploit all features of the FFPF framework, we stress that the framework is language-agnostic and allows one to combine different solutions. For instance, it is possible to connect BPF filters to FPL functions and connect those to some third party's solution. Not only does this makes the framework versatile, it also makes it easy to incorporate in existing environments.
We are currently using FFPF to replace the entire networking subsystem
of the Linux kernel. We expect the result to be much more efficient
and probably more efficient. Moreover, it would seemlessly integrate
programmable network cards, such as the IXPs in the networking
subsystem.
References:
@InProceedings{ffpf:osdi04,
  author={Herbert Bos and Willem de Bruijn and Mihai Cristea and Trung Nguyen and Georgios Portokalidis},
  title={{FFPF: Fairly Fast Packet Filters}},
  booktitle={Proceedings of OSDI'04},
  month={December},  address={San Francisco, CA},
  year=2004
}
@InProceedings{nicfix:ipom04,
  author = {Trung Nguyen and Willem de Bruijn and Mihai Cristea and Herbert Bos},
  title = {Scalable network monitors for high-speed links:a bottom-up approach},
  booktitle = {Proceedings of {IEEE IPOM'04}},
  year = 2004,
  month = {October},
  address = {Beijing, China}
}
@InProceedings{fpl3:networking05,
  author = {Mihai Cristea and Willem de Bruijn and Herbert Bos},
  title = {FPL-3: towards language support for distributed packet processing},
  booktitle = {Proceedings of IFIP Networking'05},
  year = 2005,
  address = {Waterloo, Ontario, Canada},
  url = {http://www.cs.vu.nl/~herbertb/papers/Networking_05.pdf},
  month = {May}
}
One of our earliest projects on the IXP network processor involved the
implementation of the well-known BLAST algorithm in the field of
bioinformatics. BLAST is designed to perform a similarity search,
whereby a genome database is searched for the occurrence of a pattern
that is similar to a target DNA sequence. The key issue is that it is
a similarity search rather than an exact-match problem which makes it
somewhat different from most application in networking. We found that
a careful implementation of BLAST by means of a parallelised version
of the Aho-Corasick algorithm enables an obsolete 232MHz IXP1200
network processor to perform on par with a 1.8GHz P4.
References:
@InProceedings{ixpblast:04,
  author = {Herbert Bos and Kaiming Huang},
  title = {On the feasability of using network processors for {DNA} queries},
  booktitle = {Proceedings of the Third Workshop on Network Processors \& Applications - {NP3}. Also published as Chapter 10 in "Network Processor Design, Vol. 3", Morgan Kaufmann.},
  year = 2004,
  address = {Madrid, Spain},
  month = {February}
}