1 / 23

FPGA Network Firewalling

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

willa
Download Presentation

FPGA Network Firewalling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. FPGA Network Firewalling David Thomas

  2. Outline • The Diadem firewall project • Role of FPGAs within Diadem • The IBM FPGA Firewall • Primary Goals • Progress

  3. 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

  4. 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

  5. Example network architecture

  6. Diadem network architecture

  7. Example : SYN flood attack (1) • TCPuses three way handshaking: • client -> server : SYN • client <- server : SYN, ACK – alloc state • 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

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

  9. Example : SYN flood response • Use firewall between clients and server to screen new connections • client->fwall:SYN • client<-fwall:SYN,ACK (using cookie) • client->fwall:ACK (client added to whitelist) • client<-fwall:RST (connection dropped) • client->fwall->server:SYN (client now on whitelist) • client<-fwall<-server:SYN,ACK • client->fwall->server:ACK (connection established)

  10. Diadem network architecture

  11. Accelerated network architecture

  12. 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

  13. 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

  14. 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

  15. 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 RAM @ 117MHz • Four independent banks • ZBT: can interleave reads and writes at full speed

  16. Firewall Model

  17. 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

  18. 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

  19. 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

  20. Firewall Architecture

  21. 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

  22. 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

  23. 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

More Related