FPGA Network Firewalling David Thomas

Outline The Diadem firewall project Role of FPGAs within Diadem –The IBM FPGA Firewall Primary Goals Progress

The Diadem Project Funded by the EU (your tax Euros at work) Nine partners –Four academic –Three industrial Five countries –France, Germany, Slovenia, UK, Poland Three year project, 6 months left

Diadem Goals Create a firewall that uses distributed elements within networks to detect and respond to attacks –Monitoring elements detect attacks in progress –Policy elements decide how to react to attacks –Firewall elements put reaction policy into effect Target areas are large organisations or ISPs with many peering points to foreign networks

Example network architecture

Diadem network architecture

Example : SYN flood attack (1) TCP uses three way handshaking: 1.client -> server : SYN 2.client <- server : SYN, ACK – alloc state 3.client -> server : ACK – established Between steps 2 and 3 server must maintain state, using system memory Memory can only be released after a timeout. After memory is used up no new connections can be established

Example : SYN flood attack (2) Attacker uses zombies to spoof source addresses Zombies continually perform steps 1 but never send packet 3 1.fake_ip1 -> server : SYN 2.fake_ip1 <- server : SYN,ACK – backlog=1 3.fake_ip2 -> server : SYN 4.fake_ip2 <- server : SYN,ACK – backlog=2 Server backlog keeps growing until no new connections can be established

Example : SYN flood response Use firewall between clients and server to screen new connections 1.client->fwall:SYN 2.client<-fwall:SYN,ACK (using cookie) 3.client->fwall:ACK (client added to whitelist) 4.client<-fwall:RST (connection dropped) 5.client->fwall->server:SYN (client now on whitelist) 6.client<-fwall<-server:SYN,ACK 7.client->fwall->server:ACK (connection established)

Diadem network architecture

Accelerated network architecture

The IBM FPGA Firewall (1) IBM (one of the partners) have created a hardware accelerated firewall Uses a host PC and a PCI FPGA card –Host PC reads packets from network and extracts packet headers srcIp,dstIp,srcPort,dstPort,flags : ~ 100 bits –FPGA does packet classification: looks at packet headers supplied by host and determines correct action (accept, reject, log etc.) –Host PC applies appropriate action to packet and sends it back to network The FPGA only does packet classification

The IBM FPGA Firewall (2) They’ve had some problems –They use weird FPGA boards with no support –They’re talking to the FPGA in kernel mode! –The number of rules they can apply is limited by the amount of TCAM they can instantiate TCAMs use SRL16s, not block RAMs –No expertise in FPGAs There is a bottleneck on the PC side –It is difficult to process gigabit streams in software, even when packet classification is done in hardware

Enter Imperial… What IC brings to the table –We have RC300s: full duplex Gb ethernet –We know a lot about FPGAs –We don’t take three hours for lunch Our goal: a standalone FPGA firewall –Performs the functionality of IBM firewall –Uses the same API as the IBM firewall –Operates at high data and packet rates

Current Platform: RC300 Virtex-II xc2v600 FPGA –6 M Gates (33K Slices) –2.6 MBits of embedded RAM Intel IXF1104 MAC –Two full duplex 1Gb ethernet ports –Exposed to FPGA as two 8-bit streams at 125MHz Samsung ZBT SRAM –4MB of 36 bit wide 117MHz –Four independent banks –ZBT: can interleave reads and writes at full speed

Firewall Model

Assumptions The firewall does not need to be very clever –Rules are translated into tables elsewhere –Updates are sent to the firewall as binary patches to be applied to internal tables (as UDP packets or over USB) The firewall does not need to maintain state –No support for packet fragmentation/assembly –No need to recognise packets as part of a stream The firewall is connected to a single endpoint at each port –Only needs to know two Ethernet MACs, no ARP The set of firewall responses is very simple

Classification Classifications is performed on a subset of packet header info –Source and destination IP address (2x32 bits) –Source and destination ports (2x16 bits) –Miscellaneous flags/protocol type (~12 bits) Rules specify list of rules in order or priority –Dest=server:80, src=?:?, Protocol=TCP – Accept –Dest=server:?, src=?:?, Protocol=? – Reject Classifier needs to find the first matching rule within the list

Responses Basic –Accept, Reject –Redirect (patch IP dest for inward, source for outward) –Log (Envelope packet info and send to an IP) –Reply with error –Throttling (random drop) –Simple combinations of above Possible –Throttling (limit to specified rate) –SYN flood protection –Statistics gathering

Firewall Architecture

Integration Acts as simple front-end firewall –Acts as a high-speed barrier when under attack –Will still require existing IBM firewall behind it to apply more complex rules (e.g. content inspection) Can implement same API as existing IBM firewall –API implemented on Linux host –Host translates API calls into table updates and forwards them to the RC300 over Ethernet or USB –May only support a subset of functionality

Progress Basic firewall is working –Support up to 1024 rules (IBM does 256) –Support up to 17.5 Mpackets/s –Up to 800 Gb/s Limited by the Celoxica PSL Currently working on integration with Diadem API

Summary Diadem firewall project –Distributed firewall to respond to distributed attacks FPGAs used within the firewall for speed Initial implementation currently running on the RC300