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, cont

• 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 more processing .

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 Moores 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, thats what we will use
• but how?
• and at what labor cost?

7
Rethinking Hardware Support

• Current efforts in the literature SP01,FCH02,
  MLLP03,LMK03,CS04,SP04,CMS05,LNZ03,
  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 tomorrows
  massively parallel processors? And without
  having to code for hardware specifics?

9
Task-Level Parallelism inNetwork Analysis
Note Parallelism means individual forwarding
latency neednt be ?secs. 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
AAC05, 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, cont
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 not specific 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 transformation as
  the norm

16
Discussion

• Goodbye to end-to-end semantics?
• Opinion yep -(
• Will parallel hardware progress sufficiently?
• Just one weak link and Amdahls 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?