Security services and the IXP

1
Security services and the IXP

• Wu-chang Feng
• wuchang_at_cse.ogi.edu
• Systems Software Laboratory
• Dept. of Computer Science and Engineering

2
About the project..

• 6 months old
• Just started, pardon the vapor
• Supported by Intel (12/2001) and ETIC (4/2002)
• Graduate Students
• Francis Chang francis_at_cse.ogi.edu
• Deepa Srinivasan deepsrini_at_hotmail.com
• Jin Choi (1/2003) j3choi_at_student.math.uwaterloo.c
  a
• Undergraduate Interns from Charles Consels group
• Ludovic Martorel
• Damien Berger

3
Talk outline

• IXP and network security research
• Packet classification
• Packet classification caching strategies
• Curriculum

4
The IXP and network security research
5
A research opportunity

• IXP
• Provides an open high-speed networking platform
• Research enabler
• Analyzing packet classification/routing
  algorithms
• Analyzing packet classification/routing lookup
  caching algorithms
• Security functions
• Sandbox to test and compare algorithms on a real
  platform

6
IXP and research

• Quickly becoming the ns of experimental
  networking systems
• Open hardware
• Open software
• Whats needed?
• A library of reference implementations and
  benchmarks
• IP route lookup (longest-prefix match) algorithms
  
• General packet classification algorithms
• Route and classification lookup caching
  algorithms
• Security functions

7
Our focus Security

• Borrow and use liberally
• Princeton (VERA)
• Columbia (NetBind)
• Georgia Tech (IDS)
• Utah (Emulab)
• Others..
• Build whats missing
• Range of full packet classifiers
• Range of lookup caching algorithms
• Merging the goals of research and education
• A security-focused IXP laboratory course
• Eventually, examine additional security services
• Anomaly detection
• Content filtering
• etc.

8
Packet classification

• Student Deepa Srinivasan

9
Packet classification

• Use the IXP and open-source tools to
• Compare full, packet classification algorithms
• Benchmark algorithms via real rule sets and real
  traffic traces
• Explore adaptive packet classifiers

10
A hard, but well-studied problem

• What are the key issues?
• Storage
• Search time
• Update time
• General filter matching problem Problems in
  computational geometry
• Nnumber of filters or rules, dnumber of
  dimensions
• Requires
• O(log N) time with O(Nd) space
• OR
• O((log N)(d-1) time with O(N) space
• Classic space-time tradeoff problem

11
A space-time tradeoff example

• Hierarchical tries slow and compact
• Set-pruning tries fast and large

12
Hierarchical Trie
(Figure should terminate at R2)
13
Set-pruning Trie
14
A space-time tradeoff example

• Hierarchical tries vs. Set-pruning tries
  (worst-case)

Algorithm Time Storage Updates Notes
Linear Search N N 1 Simple, poor scaling, iptables
Hierarchical trie Wd NdW d2W Backtracking search
Set-pruning trie dW Nd Nd Fast retrieval at the cost of storage. Good for relatively static classifiers.
N Number of Rules W Width of dimension d
Number of dimensions
15
Packet classification

• Approaches
• Generic classifiers
• Optimized for best worst-case performance
• Heuristic classifiers
• Take advantage of structure in rule sets (as done
  with IP router lookups)
• Tradeoff speed, storage, and update time in the
  worst case for speed and storage in the common
  case
• Hardware classifiers
• Throw hardware and parallel processing at the
  problem
• Serves as a wish-list for the IXP
• Is a hardware-based packet classification engine
  in the works?
• Can I go home?
• Will I need to shoot myself when the IXP4xxx
  comes out?

16
So many algorithms, so little time

• Which one to choose?
• Hierarchical tries with backtracking search
• Set-pruning tries
• Bit vector, Fractional cascading Lakshman98
• Aggregated bit vector Baboescu00
• Grid of tries, Cross-producting Srinivasan98
• Area-based quadtrees Buddhikot99
• Fat inverted segment tree Feldman00
• Tuple-space search Srinivasan99
• Recursive flow classification Gupta99
• Hierarchical intelligent cuttings Gupta00
• Performance and cost a function of
• d number of dimensions
• W width of dimensions
• N number of rules
• l number of levels in tree (FIS-tree only)

17
Summary of schemes Gupta00
Algorithm Time Storage Updates Notes
Linear Search N N 1 Simple, poor scaling
Hierarchical trie Wd NdW d2W
Set-pruning trie Cross-producting dW Nd Nd Fast retrieval at the cost of storage. Good for relatively static classifiers.
Grid-of-tries W d-1 NdW NdW Rebuild for each update Could be used for last 2 dimensions of a multi-dimensional hierarchical trie.
AQT aW NW a Sqrta(N) a is a tunable integer parameter
FIS-tree (l 1) W l x N1 1/l -- Tree must be recomputed on update
RFC d Nd --- Not suitable for large sets of rules (gt 6000) pre-processing and large storage space. 10Gbps line rates in hardware and 2.5Gbps rates in software.
Hierarchical Intelligent Cuttings d Nd --- Parameters can be tuned to trade-off query time against storage requirements.
Tuple-space search M N 1 Performs well for multiple dimensions if the number of tuples (i.e. hash entries) are small. Only supports prefixes generic rules increase storage complexity.
Ternary CAM 1 N 1 Simple Good for small classifiers Costly
Bit vector dW N/memwidth dN2 --- Incremental updates not supported Good for multiple dimension and a small number of rules
N of rules, WWidth of dimensions, d of
dimensions, llevels of tree, M of Tuples
18
Is there a winner?

• Not really, it depends on.
• Rule sets
• Incoming traffic characteristics
• Metric desired (average vs. worst-case lookup
  time)
• Hardware cost (memory, ternary CAM)
• How much chip area did that 16-entry CAM on the
  IXP2xxx take?

19
Adaptive packet classifiers

• Hypothesis
• Value in adaptation
• Reconfigure for high-speed based on amount of
  memory and rule set given a fixed hardware
  configuration and performance metric
• Approach
• Implement a small set of classifiers
• Build modules that translate ipchains/iptables/net
  filter rule sets into data structures of
  individual classifiers
• Study adaptation policies for classifiers based
  on rule analysis
• Implement seamless switching between
  implementations (i.e. double buffering
  Partridge98)
• Performance evaluation using
• Library of publicly available rule sets
• Public traffic trace
• An Emulab with loadable IXPs ?

20
Classification lookup caching

• Student Francis Chang

21
Caching and IP route lookups

• IP destination-based routing
• A one-dimensional packet classifier
• Caching instrumental in building gigabit IP
  routers
• Full lookup extremely expensive to support at
  high rates
• Cache of 12,000 entries gives 95 hit rate
  Jain86, Feldmeier88, Heimlich90, Jain90,
  Newman97, Partridge98
• A 50 Gb/s IP Router Partridge98
• Switched interconnection fabric
• Alpha 21164-based forwarding cards (separate from
  line cards)
• First-level on-chip caches Icache8kB (2048
  instructions), Dcache8kB
• Secondary on-chip cache96kB
• Fits 12000 entry route cache in memory
• 64 bytes per entry presumably due to cache line
  size
• Tertiary cache16MB (full, double-buffered route
  table)

22
Caching and multi-dimension lookups

• Flow-based firewalls
• A five-dimensional packet classifier
• Caching even more important
• Full classification algorithms will not run
  anywhere near line-speed on the current
  incarnation of the IXP
• Inherently harder to do
• Much lower hit rates Xu00
• Rule and traffic dependent

23
Current approaches

• Direct-mapped hashing with LRU replacement
• Typical for IP route caches Partridge98
• Parallel hashing and searching with
  set-associative hardware Xu00
• ASIC solution with parallel processing and a
  fixed, LRU replacement scheme
• Proprietary vendor solutions
• ?

24
Class-based caching

• Structure of application traffic can provide
  useful information
• W. Feng, F. Chang, W. Feng, J. Walpole,
  Provisioning On-line Games A Traffic Analysis
  of a Busy Counter-Strike Server
• Packet load of an on-line game server over 10ms
  intervals

25
Observations

• Game traffic
• Large number of periodic packets
• Extremely small packet sizes
• Persistent flows
• Small number of clients per server
• Without caching, a packet classification disaster
• With caching, a poster-child for LFU replacement?
• Web traffic
• Bursty, heavy-tailed packet arrival
• Many more clients per server
• Small number of packets per flow

26
Goal of study

• Attack the packet classification caching problem
• Resource requirements and data structures for
  high performance packet classification caches
• Segregate, Hash, and Cache
• Understand traffic characteristics
• Examine hierarchical class-based partitioning of
  cache
• Examine class-based partitioning of
  classification function (i.e. MEv2)
• Examine alternative replacement algorithms per
  class such as LFU

27
Curriculum

• Student Jin Choi

28
An IXP course for OGI/OHSU

• Goal
• Spread the IXP gospel
• Provide students with experience on a modern
  networking platform
• Train (and test drive) potential Ph.D. students
• Train future Intel employees
• 171 OGI/OHSU alums _at_ Intel
• Intel is the single largest employer of OGI/OHSU
  graduates

29
Approach

• Ask for help
• Dirk Raj (PCs, IXP boards, and support)
• Ken Mackenzie (course material and advice)
• Keep it simple
• Align with security research project
• Ask for feedback
• Curriculum completed
• Guide and slide presentation available at
  http//www.cse.ogi.edu/wuchang/ixp/
• Course will be offered as CSE58? Networking
  Practicum
• Scheduled for Spring 2003

30
The course itself

• Errata
• Weekly 3-hour sessions
• Dedicated laboratory of 10 IXP workstations
• Cloned via Norton Ghost
• Week 1
• Conceptual framework
• IXP architecture
• Hardware StrongARM, memory resources,
  micro-engines
• Software ACEs, microACEs
• Week 2
• Introduce Linux/Windows2000/VMware, and the IXP
  platform
• Remedial Linux network administration material
• ifconfig, route, netstat, ipchains, ping,
  traceroute, arp etc.
• Learn the IXP environment setup/configuration
• Building core components on Linux using standard
  GNU toolchain
• Building microcode using microengine toolchain on
  Windows2000

31
The course itself (cont.)

• Week 3
• Build and run the L3 forwarder application
• Test with external sources and sinks
• Week 4
• Add a packet counter to the L3 forwarder
• Makes sure that everyone with a CS degree from
  OGI/OHSU has programmed in assembly code at some
  point.
• Week 5
• In-line port filter
• Add microcode to block TCP segments based on
  destination port
• Code review of L3 forwarder to design full port
  filter

32
The course itself (cont.)

• Week 6 continued

33
The course itself (cont.)

• Week 6
• Full port filtering functionality
• Pass port numbers to be blocked as arguments
• SRAM management (allocation and initialization of
  multi-stride trie in the core component, access
  to data structure from the microengine)
• Add logic in core component to handle port
  filtering of exceptional packets

34
The course itself (cont.)

• Week 7-10
• Propose and implement functions of their own for
  a final project
• Packet classifiers
• Classification lookup caching

35
Questions
36
Future work

• Support for high-speed intrusion and anomaly
  detection (E-boxes and A-boxes)
• Content-based filters
• Basic network-level filters (Snort)
• Application-specific filters (Bro)
• Usage-based filters
• Accounting
• Logging

37
What makes sense on an IXP?

• Function-based decomposition used in security
• Common Intrusion Detection Framework (CIDF)
  Porras01
• Event generators (E-boxes)
• produce entries based on filtered activities
• Event databases (D-boxes)
• store events in a persistent manner
• Event analyzers (A-boxes)
• synthesize higher-level activity based on
  individual range of events
• Response units (R-boxes)
• perform actions based on events