1 / 40

Network Processor Packet Classification and Filtering Summary

Explore packet classification and filtering in network processors, including ACL data structures, algorithms, case studies, and design guidelines. Learn about DDoS packet filtering challenges and solutions.

gbeavers
Télécharger la présentation

Network Processor Packet Classification and Filtering Summary

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related