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

March 1, 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

March 1, Packet Classification

March 1, Background Fundamental building block in supporting: Access control Quality of Service (QoS) VPN Other value added services

March 1, 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, 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, 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, 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, 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, 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, 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, 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, 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, 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, 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, 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, Transport-level Field Analysis Large number of routes Small number of unique transport- level fields Expose sharing across multiple IP

March 1, 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, 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, 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 transport- level fields General range matching Small, special-purpose hardware

March 1, 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, Design Guidelines Small, special-purpose hardware for stage 2 Parallel search Small number of fields = small space overhead

March 1, DDoS Packet Filtering

March 1, 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, NetBouncer 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, NetBouncer Technology—Cont. Maintain a legitimacy list Add new client to list after passing legitimacy tests Prototype implemented on IXP 1200

March 1, Legitimacy Tests Distinguish legitimate traffic from illegitimate traffic Need to abstract and analyze traffic at one or more levels of protocol stack

March 1, 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, 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, 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, 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, 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 level- compressed (LC) trie structures

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

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

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

March 1, Prototype Architecture—Cont.

March 1, 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, 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, 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, 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