10 Gbps IDS/IPS with Metanetworks' Meta Traffic Processor

1. The Meta Traffic Processor* Demonstration of 10 Gbps IDS/IPS Livio Ricciulli livio@metanetworks.org (408) 399-2284 Rome Laboratories *Supported by the Division of Design Manufacturing and Industrial Innovation of the National Science Foundation (Award #0339343) and the Air Force Rome Laboratories.

2. Brief History • Active Networks (DARPA Program) • Change behavior of network components (routers) dynamically (add new protocols, flow control algorithms, monitoring, etc..) • Discrete. Update network through separate management operations • Integrated. Packets cause network to update itself • Broad scope did not result in industry adoption • Lack of “killer application” • Lack of tight industry interaction • Tried to change too much too soon • Metanetworks’ bottom-up approach • Achieve programmability while reusing current infrastructure • Augment networks with new, non-invasive technology • Application-driven rather than design-driven • Work closely with users/operators • Revisit hardware computational model

3. 1-10 Gbps IDS/IPS Hardware • Open architecture to leverage open source software • More robust, more flexible, promotes composability • Directly support Snort signatures • Abstract hardware as a network interface from OS prospective • Retain high-degree of programmability • New threat models (around the corner) • Extend to application beyond IDS/IPS • Line-speed/low latency to allow integration in production networks • Unanchored payload string search • Support analysis across packets • Gracefully handle state exhaustion • Hardware support for adaptive information management • Detailed reporting when reporting bandwidth is available • Dynamically switch to more compact representations when necessary • Support the insertion of application-specific analysis code in the fast path

4. If you Cannot Measure it, You Cannot Manage it • Knowing what is in your network is very important • Catch misuses both incoming and outgoing • FBI says that effective network monitoring (not even IDS) is in top 3 most important things to do • Who and how is using the bandwidth • Decentralization • Cannot find out what the traffic is unless you do content inspection • Many p2p applications randomly changing ports (VOIP) • Key exchanges need to be monitored • Would like to know what applications are doing • High Speed High Complexity • 1G and 10G make content inspection a challenge • Hardware/Software co-design is a must

5. Flynn’s Computer Taxonomy MIMD Alert MISD Instructions Get packet Reduction Network Compare to rules Memory Processor Memory Processor P0 P1 Pn Memory Processor . . . . Memory Processor Data Alert Data Instructions SIMD SISD Alert Get packet Instructions Reduction Network Compare to rules Memory Processor P0 P1 Pn . . . . Instructions Alert Data Data

6. MISD Programmable Hardware Block FPGA Stateful Analysis Reduction Network Receive Clock Data Valid R1 R2 Rn . . . . Data Stream Match Memory Host Interface

7. AND AND Monitoring System RxData PHY RxEnable Block Direction 2 RxData PHY RxEnable Block Direction 1

8. Cost-effective & Powerful 100Mb-10Gb + PHY RAM Block State 1-8M Concurrent Flows Fail Close L-1 RAM Latency < 0.5 μs Read Only FPGA Packets PHY < 100 < 1500 Dynamic Policies Static Policies IPS/ IDS Web-based signature management service Compilation + runtime update Synthesis + firmware update Internet

9. Up to 6 cards/box SRAM SRAM SRAM SRAM SRAM SRAM SRAM SRAM SRAM SRAM SRAM SRAM SRAM SRAM PHY PHY PHY PHY PHY PHY PHY FPGA FPGA FPGA FPGA FPGA FPGA FPGA PCI PCI PCI PCI PCI PCI PCI Snort IDS/IPS CPU CPU

10. Content Inspection Performance Comparison

11. Static analysis of large number of IDS signatures 1 1 • Transform Snort rules or BPF expressions into a low-level declarative language • Extract fine-grain parallelism across thousands of signatures • Define independent FSMs each implementing a signature • Share comparison logic across multiple FSMs • Synthesizer further optimizes • Merge multiple FSMs sharing intermediate states • Eliminate redundant rules CA MA & & TC & & MATCHTHIS CATCHTHISONE HT & & HI & & SO S & & NE & |

12. Some Rule Compression Results

13. Router/Switch Inline • Use it for IPS or just to eliminate a TAP • Chain multiple cards • Traditional passive monitoring • Up to 6 cards per host • Extend passive capacity • Can hang multiple passive devices off 1 TAP or Mirror IDS/IPS CPU Multiple Mirrors Passive IDS/IPS To other passive devices CPU Mirror Port Passive Inline IDS/IPS To other passive device CPU

14. Layer-1 “T” Junction

15. Native IDS Acceleration • Wire-speed capture of interesting flows • Capture flows with specific bad signatures • Pass flows known to be good • ISO image transfers, data files • Open source IDS/monitoring tools • Snort, Bro All traffic All traffic (optional) Bad traffic To CPU

16. Native IDS/IPS • Wire-speed filtration of a subset of known bad packets • Worms, Viruses, Rootkits • Open source IDS/monitoring tools • Snort, Bro to inspect bad traffic • Dynamically add signatures • “Lock Down” while patching • Filter DDoS streams before bottleneck All traffic Firewall or Switch Good traffic Bad traffic To CPU

17. Transparent IDS Acceleration • Wire-speed capture and filtration of good flows • Capture flows known to be good for archiving • ISO image transfers, data files, etc… • Other IDS/monitoring appliances only receive a fraction of the traffic All traffic Unknown Other IDS To CPU Good traffic (optional)

18. Redundant IDS • Wire-speed capture of suspected flows • Capture flows with specific bad signatures • Pass and filter flows known to be good • ISO image transfers, data files • Open source IDS/monitoring tools • Snort, Bro All traffic All traffic or unknown Other IDS Bad traffic Correlate

20. Packet temporarily stored in a linked list Stateful matches Packets captured from linked list

21. Each packet can be Captured and/or Blocked

23. 10Gbps Information bandwidth management • Host bandwidth is << of fast-path • Flooding cannot be used to compromise blocking capability • FP rate in blocking when state is exhausted • Flooding can be exploited to reduce efficacy of monitoring • Need to find needle in a haystack but needs to cope with flood of packets • Hardware stateful analysis (implemented) • Intelligent Monitoring • Application-level programmability (implemented)

24. Intelligent Monitoring (work in progress) Rule 1 2 3 4 5 . . . n Switch off lower priority rules and report number of triggers only NOT entire packet  > T?  T = maximum amount of alerts tolerable

25. User-level programmability FPGA Block Reduction Network • User-level programmability • Define API to let user write ad-hoc wire-speed code • Add user modules to synthesis flow and share reduction network • Architecture provides determinism • It either fits or it does not fit in the FPGA • It either meets timing or does not meet timing • Load/store network processing much harder to predict Capture Capture Block Block User Defined User Defined Address Capture Data RW Valid Offset Valid Payload Offset Payload Payload Payload Common Functions Memory Interface Packet Processor Host Interface Layer-1 PCI Interface Applications Standard OS

26. Roadmap Multiple FPGA 10G Multiple FPGA 1G 10G PCI Card 1G Appliance Signature Services Compiler API 1G PCI Card Q4-03 Q1-04 Q2-04 Q3-04 Q4-04 Q1-05 Q2-05 Q3-05 Q4-05 Q1-06 Q3-06 Q4-06 Q1-07

27. IDS/IPS Demonstration • Background traffic saturates line • Stateful HTTP traffic added to background traffic • Show that can capture based on content • 9.6 Billion comparisons per second (600 rules x 16 Mpps) • Show that can filter based on content HTTP Clients Load All traffic Spirent SMB-6000 Filtered traffic HTTP Server CRC Captured Traffic

28. Summary • Extremely low latency design enables a wide variety of deployment options • Leverage Open Source software • 1G and 10G available today • Processing paradigm lends itself to ad-hoc application level programmability Livio Ricciulli livio@metanetworks.org (408) 399-2284 www.metanetworks.org