HARDWARE BASED PACKET FILTERING USING FPGAs (or “How hardware is better than software at judging a book by its cover”) Timothy Whelan Supervisor: Mr Barry Irwin Security and Networks Research Group Department of Computer Science Rhodes University

Contents Problem Description FPGA Pros FPGA Cons Theory of Operation Lessons Learned Future Extensions

Problem Description Network nodes receive a lot of packets. Not all packets are good. Some packets are better. Wouldn’t it be nice to be able to accept/reject packets based on who the sender is and what they are sending? And let’s try to do that as fast as possible! 12 3

Problem Description - Goals Goals 1.Be able to classify packets according to basic 5-tuple. 1.(source/destination IP/port and transport protocol used) 2.Provides a basic context in which further decisions can be made. Be able to alter classification rules with relative ease. Times change; classification rules will need to change too. Assess feasibility of using FPGA’s. Can they do the job? Are they worth it?

FPGA Pros 1.Ultimately they are circuits. 2.They are also re-configurable circuits. Useful for changing classification rules. 3.Dedicated to the application. Won’t waste time on “other stuff”. 4.Xilinx support is HUGE. IP cores, code generators, user guides, application notes, case studies, reference designs, step-by-step tutorials.

FPGA Cons 1.Unfamiliar platform. 2.Xilinx support is HUGE! Too large to quickly learn how to use tools – ChipScope, CoreGenerator. 3.Provide best worse-case performance. A dedicated IC will always out perform an FPGA. 4.Ultra low level. But voltage level conversions are normally provided. 5.No default I/O for debugging. Have to create a form of basic I/O to use as debugging.

Theory of Operation RX_clk RX_dv RX_data (nybble) Rule count Ethernet cable RS-232 interface

Theory of Operation: Locating fields

Theory of Operation: Stripping fields Extracting packet data Extracting protocol number and IP address

Theory of Operation: Bit-for-bit AND

Theory of Operation: Data output To get rule counts from the device the user pushes a button on the board. The device then reads each rule count stored in memory and transmits it over a serial RS-232 interface to a connected computer.

Lessons Learned 1.Require much experience one does. Inference engine can destroy synchronized signals. 2.FPGA’s are extremely versatile. Range of applications: DSP – video processing – network computing. 3.RTFM If you can’t figure out how it works, read the manual. 4.It might actually work! The full process can be simulated and synthesized without timing warnings. (And the literature says so).

Future extensions 1.Output counts over the network Can monitor device from anywhere. 2.Implement the RAM interface. Board has a 512MB DDR2 RAM chip. 3.Add functionality. Provide more rule matching e.g. TCP flags Board as a LCD screen built on it and has a VGA output.