Packet Classification and Filtering for Network Processors JC

Packet Classification and Filtering for Network Processors JC Ho March 1, 2004 1

Topics Packet Classification Kounavis, et al: Directions in Packet Classification for Network Processors DDo. S Packet Filtering Thomas, et al: High-speed Legitimacybased DDo. S Packet Filtering with Network Processors March 1, 2004 2

Packet Classification March 1, 2004 3

Background Fundamental building block in supporting: Access control Quality of Service (Qo. S) VPN Other value added services March 1, 2004 4

Background—Cont. Often the first packet processing step in routers Must operate at line speed to prevent performance interference across flows Overhead of accessing search structure is large in time and memory Need to efficient algorithm to reduce overhead March 1, 2004 5

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 6

ACL—Data Structures Trie-based algorithms Hierarchical 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 7

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 8

ACL—Cont. Parallel search algorithms: Search n-dimensions separately AND bit vectors to get aggregate bit vector Heuristic algorithms: Exploit structure and redundancy in rules Low lookup time Problem: Exponential memory requirements March 1, 2004 9

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 10

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 11

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 12

IP Prefix Pair Analysis—Cont. Small ACL Close to client network Rules govern specific client subnets Many rules contain wild card in destination Large ACL Close to internet core Connect servers and networks Many rules contain wild card in source March 1, 2004 13

IP Prefix Pair Analysis—Cont. Partially-specified filters are lines and rectangles, small % in large ACLs Fully-specified filters are points and lines Shapes of filters determine size of trie data structures Trie data structures require much fewer blocks than theoretical upper bound March 1, 2004 14

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(n 2) space overhead, n is number of distinct IP prefix pair March 1, 2004 15

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 16

Transport-level Field Analysis Large number of routes Small number of unique transportlevel fields Expose sharing across multiple IP March 1, 2004 17

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 18

Transport-level Field Analysis— Cont. Many IP pairs share the same set of transport-level fields Number of unique entries in transportlevel fields are small March 1, 2004 19

Design Guidelines Two stage design Stage 1 2 -D match based on IP pair Prefix matching only Fast software algorithm Stage 2 Multi-dimension match based on transportlevel fields General range matching Small, special-purpose hardware March 1, 2004 20

Design Guidelines—Cont. Maintain partially-overlapped filters as unique filters in stage 1 Small number of such overlap Low space overhead Feasible implementation Reduce time overhead March 1, 2004 21

Design Guidelines Small, special-purpose hardware for stage 2 Parallel search Small number of fields = small space overhead March 1, 2004 22

DDo. S Packet Filtering March 1, 2004 23

Background DDo. S (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 24

Net. Bouncer Technology Packet processing and filtering device Make one of three decisions Accept and transmit incoming packet Discard packet Challenge sender to prove legitimacy March 1, 2004 25

Net. Bouncer Technology—Cont. Maintain a legitimacy list Add new client to list after passing legitimacy tests Prototype implemented on IXP 1200 March 1, 2004 26

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 27

Legitimacy Tests—Cont. Packet-based tests Lookup 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 28

Legitimacy Tests—Cont. Flow-based tests Intercept 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 29

Legitimacy Tests—Cont. Service-base tests Service and application level Distinguish attackers by intelligence test Attacks are usually automated Require human user to answer challenge March 1, 2004 30

Legitimacy List Management Organizing state information Host 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 31

Legitimacy List—Cont. Efficient lookup and update Large list Fast update rate Need space and time efficient structures Hash-trie structure Novel structure Combines hash tables and levelcompressed (LC) trie structures March 1, 2004 32

Prototype Architecture Based on IXP 1200 Network Processor Uses 2 Gigabit Ethernet ports March 1, 2004 33

Prototype Architecture—Cont. Fast path Uses 3 microengines Source IP found in legitimacy list Prepares packets and transmit March 1, 2004 34

Prototype Architecture—Cont. Test path Uses 3 microengines Challenges unknown source for legitimacy Calls Strong. Arm processor for more complex processing if necessary March 1, 2004 35

Prototype Architecture—Cont. March 1, 2004 36

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 37

Prototype Performance—Cont. Fast path Throughput 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 38

Prototype Performance—Cont. Test path Throughput 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 39

Conclusion Implementation limitations due to architecture of IXP 1200 Need coprocessor to perform dataintensive tasks, to reduce the load of microengines in IXP 1200 implementation clearly outperforms software version of Net. Bouncer March 1, 2004 40