Rethinking Hardware Support for Network Analysis and Intrusion Prevention

1. Rethinking Hardware Support for Network Analysis and Intrusion Prevention Vern Paxson (ICSI) Krste Asanovic (MIT) Sarang Dharmapurikar (Nuova Systems) John Lockwood (WUSTL) Ruoming Pang (Princeton) Robin Sommer (ICSI) Nicholas Weaver (ICSI) USENIX Hot Security July 31, 2006

2. Network Analysis Performance Pressures Growing in Multiple Dimensions • Increasingly, simple & efficient signature matching proves inadequate • False positives • Polymorphism • Zero-day attacks •  We need semantic application-aware analysis • But: that costs CPU (parsing) and memory (state)

3. Network Analysis Performance Pressures Growing in Multiple Dimensions, con’t • Attacks inexorably grow in sophistication • Arms race (particularly w/ attackers motivated by $$$) • Analysis also increasingly requires context (= state) • Problem of evasion leads to need to alter traffic via normalization … • … so we need to operate in-line • Plus we want to prevent attacks, not just detect them … • … so we need to operate in-line • We need to do a lot moreprocessing ….

4. Some Sobering Growth Trends • Network traffic rates inexorably grow • Network traffic volumes inexorably grow • We need to do more analysis on larger amounts of data at higher speeds … • But CPU performance is NOT inexorably growing any more.

5. Uniprocessor Performance (SPECint) 3X gap from historical growth From Hennessy and Patterson, Computer Architecture: A Quantitative Approach, 4th edition, 2006  All major manufacturers moving to multicore architectures • General-purpose uniprocessors have stopped historic performance scaling (no longer able to leverage Moore’s Law) • Power consumption • Wire delays • DRAM access latency • Diminishing returns of more instruction-level parallelism

6. Where Will We Find The Performance?? • FPGAs! • ASICs! • Multi-core! • Parallelism is here and is growing. • Yes, that’s what we will use … • … but how? • … and at what labor cost?

7. Rethinking Hardware Support … • Current efforts in the literature [SP01,FCH02, MLLP03,LMK+03,CS04,SP04,CMS05,LNZ+03, DKSL04,DL05,TSCV04,TS05,SL03,SML04,AL05] focus heavily on supporting signature-matching • TCAMs, FPGA features, Bloom Filters for string lookups • NFAs, DFAs, Aho-Corasick for reg-exp matching • Nearly stateless • Essentially “Snort in hardware” • Rudimentary stateful analysis - TCP stream reassembly w/ adversaries - unexamined in literature until USENIX Security 2005 • Commercial designs may be ahead; diff. to know

8. How Do We Get: • Stateful analysis • State management in presence of adversaries • Semantic rather than syntactic analysis • Including at semantic layers spanning multiple connections, hosts, applications • In-line processing for normalization, intrusion prevention • … expressed so it can leverage tomorrow’s massively parallel processors? And without having to code for hardware specifics?

9. Task-Level Parallelism inNetwork Analysis Note: Parallelism means individual forwarding latency needn’t be sec’s. Cycle budget can be ≈ msec.

10. Architectural Vision • Express high-level (semantic, app-aware, global context) analysis using a high-level language • E.g., Bro intrusion detection system • Compile these expressions to an abstraction of parallelism • E.g., Transactors • Retarget these abstractions to different, specific hardware instances (FPGAs, multi-core) to leverage their capabilities and resources

11. The Transactor Abstraction for Parallelism [AAC+05, GSA06] • Network of computational elements • Loosely coupled via FIFOs • No timing guarantees between elements • Transactor unit includes • Local architectural state (persists across transactions) • Buffered input/output channels • Set of transactions (code) that executes atomically • Scheduler that mediates execution & messaging • Computation always has a serializable equivalent • Properties strive for efficient execution and verifiable specifications

12. The Transactor Abstraction for Parallelism, con’t

13. Expressing High-Level Network Analysis • At lowest level, handcode analysis primitives for Transactor parallelism abstraction • Connection state management, checksum validation, stream reassembly, network/transport normalization • At mid-level, construct application protocol analyzers in a custom language (e.g., BinPAC, to appear IMC ‘06) • Takes specification of Binary & ASCII protocols, compiles to C++ • Retarget to compile to Transactor abstraction • At high-level, express analysis in custom language (e.g., Bro) and likewise retarget

14. Challenges • Development of high-quality optimizing compilers • For high-level analysis & protocol parsers  Abstraction • For Abstraction  hardware instances • Management of state and timers • Private vs. shared memory

15. Possibilities • A lot of work. But if achieved, can open up network security analysis to much richer and resilient set of capabilities. • Furthermore, consider that just about all of the components are notspecific to network security analysis but just network analysis in general • HW supporting such analysis in-line can change the paradigm of what network forwarding means • No longer: send along packets w/ minimal cycles • Rather: enable rich, in-depth transformationas the norm

16. Discussion • Goodbye to end-to-end semantics? • Opinion: yep :-( • Will parallel hardware progress sufficiently? • Just one weak link and Amdahl’s Law bites you • I.e., can we really keep the processing pipeline full & flowing? • Maybe the right answer is a completely different (and inherently parallelizable) model of detection? • Opinion: deep knowledge of app semantics is fundamental, remainder follows from that • More fundamental parallelism: push work out to edges • But how the heck to trust them?