packet classification and filtering for network processors

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