Secure Overlay Services Adam Hathcock Information Assurance Lab Auburn University

Secure Overlay Services (SOS) Proactive approach to prevent DoS attacks. A target is protected by removing all incoming packets from unapproved sources. A network of selected nodes form an overlay which protect a specific target. Packets are validated at entry points of the overlay and once inside are tunneled securely to secretly designated nodes. Once validated, all traffic is forwarded to the target through the overlay.

SOS (cont.) To mitigate attacks: No unauthenticated traffic is allowed in the overlay. Filtering of non-overlay traffic near the target can be done at line-speed. The vulnerability of the target is offloaded onto the overlay. The overlay is recoverable Node roles can be assigned randomly and secretly which makes it much more difficult to bring down the entire overlay.

Architecture Description Nodes that participate in the SOS are known to the public and the attacker. However, the role of certain nodes may be kept secret. Routing through the overlay is handled by the Chord protocol. The target site is protected by very simple filtering rules.

The Players SOAP - Secure Overlay Access Point: The start point in for all traffic that will communicate with the target Handles authentication of users and traffic Target: The nodes or set of nodes that will be filtered to only allow overlay traffic

The Players Beacon The end-point in a chord ring Beacon forwards traffic to the Secret Servlet Secret Servlet The node that will communicate with a specific target or group of targets

Basic SOS architecture and operation Source point SOAP Beacon Secret servlet target Overlay Nodes Filtered region 1- Routers in the filtered region only accept traffic from the secret servlets. The site selects one or more secret servlets. 2- The informed secret servlet node will compute keys for each of the overlay nodes that will act as beacons. 3- Servlets will contact the beacons that they identified and let them know of their existence and the beacons will then store the information. 4- When a source wants to communicate with a target, it sends the request to a SOAP to access the protected site. Using chord, the traffic is directed to a beacon. 5- The beacon then routes it to the secret servlet.

SOS Design Rationale Source point SOAP Beacon Secret servlet target Overlay Nodes Filtered region Any node can act as a beacon for a secret servlet by using multiple hash functions used for routing. SOAP, beacon or secret servlets are redundant and have the ability to be reassigned to different nodes in order to strengthen the architecture.

Chord Protocol Secret Servlets generate keys which are used in the chord protocol to designate beacon nodes. Key is usually the hash of a target’s IP address. The key is symmetric and transitive. Provides fast distributed computation of a hash function, mapping keys to nodes responsible for them. A chord node only needs a small amount of “routing” information about other nodes. Since the routing information is distributed, a node resolves the hash function by communicating with other nodes.

Chord Protocol (cont.) Consistent Hashing A consistent hash function assigns each node and key an m-bit identifier. A node’s identifier is chosen by hashing the node’s IP address and the key identifier is produced by hashing the key. Identifiers are ordered on an identifier circle. Key k is assigned to the first node whose identifier is equal to or follows the identifier of k in the identifier space and is therefore called the successor node of key k going in a clockwise manner.

Chord Protocol (cont.) Example: Consistent hashing M=6 Chord ring has 10 nodes and stores 5 keys. Successor of identifier 10 is 14, so key 10 is located at node 14. Also keys 24 and 30 would be located at node 32. key 38 at node 38 and key 54 at node 56.

Chord Protocol (cont.) Simple key location: Diagram: Path taken by a query from node 8 for key 54. Look up is implemented with little per-node state Each node needs to know how to contact its current successor.

Chord Protocol (cont.) Scalable key location Lookups are accelerated by maintaining additional routing information that are not essential for correctness. Since the identifier is m bits, each node maintains a routing table with m entries called the finger table. The finger table contain both the chord identifier and the IP address and a port number of the relevant node. Figure: Finger Table entries for node 8

Chord Protocol (cont.) Scalable key location (cont.) Example: Node 8 wants to find successor of key 54. The largest finger of node 8 preceding 54 is node 42, so node 8 will ask node 42 to resolve the query. Also node 42 will determine the largest finger in its finger table that precedes 54 which is node 51 Finally node 51 will discover that its own successor which is node 56 succeeds key 54 so it will return node 56 to node 8

Chord Protocol (cont.) Dynamic operations and failures: example (join operation) Node 26 joins the system between nodes 21 and 32. The arcs represent the successor relationship. (a) Initial state: node 21 points to node 32. (b) Node 26 finds its successor (i.e., node 32) and points to it. (c) Node 26 copies all keys less than 26 from node 32. (d) The stabilize procedure updates the successor of node 21 to node 26.

References A. D. Keromytis, V. Misra, and D. Rubenstein. SOS: Secure Overlay Services. In Proceedings of ACM SIGCOMM, pages , August I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan. Chord: A Scalable Peer-To-Peer Lookup Service for Internet Applications. In Proceedings of ACM SIGCOMM, Morein, W.G., Stavrou, A., Cook, D.L., Keromytis, A.D., Misra, V., Rubenstein, D.: Using Graphic Turing Tests to Counter Automated DDoS Attacks Against Web Servers. In: Proceedings of the 10th ACM International Conference on Computer and Communications Security (CCS). (2003) D. Karger, E. Lehman, F. Leighton, R. Panigrahy, M. Levine, and D. Lewin. Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web. In Proceedings of ACM Symposium on Theory of Computing (STOC), pages 654–663, May 1997.