packet classification and filtering for network processors
DESCRIPTION
Packet Classification and Filtering for Network Processors. JC Ho. Topics. Packet Classification Kounavis, et al: Directions in Packet Classification for Network Processors DDoS Packet Filtering Thomas, et al: High-speed Legitimacy-based DDoS Packet Filtering with Network Processors. - PowerPoint PPT PresentationTRANSCRIPT
March 1, 2004 1
Packet Classification and Filtering for Network Processors
JC Ho
March 1, 2004 2
Topics
Packet ClassificationKounavis, et al: Directions in Packet Classification for Network Processors
DDoS Packet FilteringThomas, et al: High-speed Legitimacy-based DDoS Packet Filtering with Network Processors
March 1, 2004 3
Packet Classification
March 1, 2004 4
Background
Fundamental building block in supporting:
Access control
Quality of Service (QoS)
VPN
Other value added services
March 1, 2004 5
Background—Cont.
Often the first packet processing step in routersMust operate at line speed to prevent performance interference across flowsOverhead of accessing search structure is large in time and memoryNeed to efficient algorithm to reduce overhead
March 1, 2004 6
Access Control List (ACL)
Basis of packet classification
Set of rules governing classification
Determine action A associated with highest priority rule matching packet p
March 1, 2004 7
ACL—Data Structures
Trie-based algorithmsHierarchical radix tree structure
Search in multiple dimension structures
Match in one dimension, then search separate tree linked to matched node
Require as many memory access as # of bits in fields used for classification
Large memory overhead with increase in dimensions
March 1, 2004 8
ACL—Cont.
Hash-based algorithms:Perform series of hash lookups
O(n) storage and time complexity
Number of hash tables can be as large as number of rules
Memory overhead limits scalability of number of rules
March 1, 2004 9
ACL—Cont.
Parallel search algorithms:Search n-dimensions separatelyAND bit vectors to get aggregate bit vector
Heuristic algorithms:Exploit structure and redundancy in rulesLow lookup time
Problem:Exponential memory requirements
March 1, 2004 10
Case Study and Findings
Based on four databases of packet classification rules from large ISPs and corporate intranet
IP prefix pair analysis
Transport-level field analysis
March 1, 2004 11
IP Prefix Pair Analysis
Source and destination IP pairs characterize distinct paths in ACL
Structural analysis exposes different types (shapes) of filter in 2-D space
Overlap analysis exposes space overhead in ACL containing overlapped filters
March 1, 2004 12
IP Prefix Pair Analysis—Cont.
Partially- and fully-specified filters
Represented geometrically as point, line, rectangle in 2-D IP address space
Dependency between size of ACL and number of filters having wild cards in source or destination IP
Wild cards determine shape of filters
March 1, 2004 13
IP Prefix Pair Analysis—Cont.
Small ACLClose to client networkRules govern specific client subnetsMany rules contain wild card in destination
Large ACLClose to internet coreConnect servers and networksMany rules contain wild card in source
March 1, 2004 14
IP Prefix Pair Analysis—Cont.
Partially-specified filters are lines and rectangles, small % in large ACLsFully-specified filters are points and linesShapes of filters determine size of trie data structures Trie data structures require much fewer blocks than theoretical upper bound
March 1, 2004 15
IP Prefix Pair Analysis—Cont.
Fully-overlapped filters represented by the contained filter
No overhead
Partially-overlapped navigate structure—time overhead
Or create new filter—space overhead
Worst-case O(n2) space overhead, n is number of distinct IP prefix pair
March 1, 2004 16
IP Prefix Pair Analysis—Cont.
Time overhead is infeasible due to increasing line speed
Space overhead is manageable Overlapped filters are much fewer than theoretical worst-case
March 1, 2004 17
Transport-level Field Analysis
Large number of routes
Small number of unique transport-level fields
Expose sharing across multiple IP
March 1, 2004 18
Transport-level Field Analysis—Cont.
Each filter (IP address pair) may be associated with several rules
Each rule with different combination of transport-level fields
About 90% of transport-level field sets contain only 1 to 4 entries, remaining 10% between 5 and 40 entries
Most fields specify TCP and UDP
March 1, 2004 19
Transport-level Field Analysis—Cont.
Many IP pairs share the same set of transport-level fields
Number of unique entries in transport-level fields are small
March 1, 2004 20
Design Guidelines
Two stage designStage 1
2-D match based on IP pairPrefix matching onlyFast software algorithm
Stage 2Multi-dimension match based on transport-level fieldsGeneral range matchingSmall, special-purpose hardware
March 1, 2004 21
Design Guidelines—Cont.
Maintain partially-overlapped filters as unique filters in stage 1
Small number of such overlapLow space overhead
Feasible implementation
Reduce time overhead
March 1, 2004 22
Design Guidelines
Small, special-purpose hardware for stage 2
Parallel search
Small number of fields = small space overhead
March 1, 2004 23
DDoS Packet Filtering
March 1, 2004 24
Background
DDoS (Distributed Denial of Service) is a growing concern to the security and network communities
One of the most difficult problems
Increasing in sophistication
Discerning legitimate packets is essential
March 1, 2004 25
NetBouncer Technology
Packet processing and filtering device
Make one of three decisionsAccept and transmit incoming packet
Discard packet
Challenge sender to prove legitimacy
March 1, 2004 26
NetBouncer Technology—Cont.
Maintain a legitimacy list
Add new client to list after passing legitimacy tests
Prototype implemented on IXP 1200
March 1, 2004 27
Legitimacy Tests
Distinguish legitimate traffic from illegitimate traffic
Need to abstract and analyze traffic at one or more levels of protocol stack
March 1, 2004 28
Legitimacy Tests—Cont.
Packet-based testsLookup source IP on legitimacy list
Challenge unknown sources with an ICMP echo message
Incoming message is encapsulated in payload of ICMP echo request, not stored locally
Expect reply with original message
March 1, 2004 29
Legitimacy Tests—Cont.
Flow-based testsIntercept SYN packet
Return SYN/ACK to source address
Wait for ACK return from source
Forward to original destination address
Wait for ACK from destination
Complete 3-way handshake
March 1, 2004 30
Legitimacy Tests—Cont.
Service-base testsService and application level
Distinguish attackers by intelligence testAttacks are usually automated
Require human user to answer challenge
March 1, 2004 31
Legitimacy List Management
Organizing state informationHost lookup table (HLT) stores IP addresses of legitimate sources
HTL nodes link to legitimacy state entry (LSE) regarding flow and service info
LSE contains flow-tree (FT) and application list (AL)
FT contains flow info from each host
AL contains application and service info
March 1, 2004 32
Legitimacy List—Cont.
Efficient lookup and updateLarge list
Fast update rate
Need space and time efficient structures
Hash-trie structureNovel structure
Combines hash tables and level-compressed (LC) trie structures
March 1, 2004 33
Prototype Architecture
Based on IXP 1200 Network Processor
Uses 2 Gigabit Ethernet ports
March 1, 2004 34
Prototype Architecture—Cont.
Fast pathUses 3 microengines
Source IP found in legitimacy list
Prepares packets and transmit
March 1, 2004 35
Prototype Architecture—Cont.
Test pathUses 3 microengines
Challenges unknown source for legitimacy
Calls StrongArm processor for more complex processing if necessary
March 1, 2004 36
Prototype Architecture—Cont.
March 1, 2004 37
Prototype Performance
Packet size varies between 64 bytes and 1496 bytes
Legitimacy list size varies between 100 and 4200 entries (max memory capacity in IXP 1200)
March 1, 2004 38
Prototype Performance—Cont.
Fast pathThroughput varies between 990 Mbps and 298 Mbps depending on packet and hash table size
Small packet size increases packet frequency
Small hash table size increases lookup time
Latency varies dramatically depending on legitimacy list size and hash table size
March 1, 2004 39
Prototype Performance—Cont.
Test pathThroughput ranges between 50 Mbps and 140 Mbps
Large packet size increases processing overhead
Latency varies depending on hash table size and packet size
March 1, 2004 40
Conclusion
Implementation limitations due to architecture of IXP 1200
Need coprocessor to perform data-intensive tasks, to reduce the load of microengines in IXP 1200
IXP 1200 implementation clearly outperforms software version of NetBouncer