Packet Classification and Filtering for Network Processors

1. Packet Classification and Filtering for Network Processors JC Ho

2. 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

3. Packet Classification

4. Background • Fundamental building block in supporting: • Access control • Quality of Service (QoS) • VPN • Other value added services

5. 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

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

7. 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

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

9. 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

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

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

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

13. 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

14. 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

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

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

17. Transport-level Field Analysis • Large number of routes • Small number of unique transport-level fields • Expose sharing across multiple IP

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

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

20. 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

21. 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

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

23. DDoS Packet Filtering

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

25. NetBouncer Technology • Packet processing and filtering device • Make one of three decisions • Accept and transmit incoming packet • Discard packet • Challenge sender to prove legitimacy

26. NetBouncer Technology—Cont. • Maintain a legitimacy list • Add new client to list after passing legitimacy tests • Prototype implemented on IXP 1200

27. Legitimacy Tests • Distinguish legitimate traffic from illegitimate traffic • Need to abstract and analyze traffic at one or more levels of protocol stack

28. 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

29. 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

30. 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

31. 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

32. 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

33. Prototype Architecture • Based on IXP 1200 Network Processor • Uses 2 Gigabit Ethernet ports

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

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

36. Prototype Architecture—Cont.

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)

38. 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

39. 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

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