SOS: Security Overlay Service Angelos D. Keromytis, Vishal Misra, Daniel Rubenstein- Columbia University ACM SIGCOMM 2002 CONFERENCE, PITTSBURGH PA, AUG 2002 Presented by Wei Zhou

References  A. Keromytis, V. Misra and D. Rubenstein, “ SOS: Secure Overlay Services ”, the Proceedings of the ACM SIGCOMM Conference, August 2002  D. Cook, “ Analysis of Routing Algorithms for Secure Overlay Service ”, Computer Science Department Technical Report CUCS , 2002

Outline  Introduction  System Design Rationale  System Architecture  Performance Analysis  Discussion

Introduction – the problem  The Communication by Emergency Services A critical service (the target) that resides in a well-known location (i.e. IP address). A group of pre-confirmed users, located anywhere in the wide-area network, who have authentication to communicate with that location. Example scenario  Without protection, such a service can be easily flooded by DDoS attacks

Design Rationale  Intuition A firewall standing in front of the server  One firewall is NOT enough Firewall Server

Design Rationale (cont.)  Replicate the firewall functionality, thus have a distributed firewall network.  A dedicated router set filtering packets that are not from one of the firewalls.  Assume high-powered routers with light-weight computation. Server Filtering router set

Design Rationale (cont.)  How to deal with spoofed traffic purporting to originate from one of these firewalls.  Target selects a small set of these firewalls as the designated authorized forwarding stations, and hides their identities to the public.  Why overlay network? Highly dynamic nature – a node can easily join in or be taken out from an overlay network. High level of connectivity – there is a (logic) link between any pair of participating nodes in an overlay network.

System Architecture – version 1 Source Point SOAP Secret Servlet Secret Servlet Secret Servlet Target Overlay nodes Filtered region

System Architecture (cont.)  Preliminary routing mechanism Each node receiving a packet forwards the packet to another randomly chosen overlay node, until the packet reaches a secret servlet. Not efficient  suppose N overlay nodes and Ns secret servlets, the expected number of intermediate overlay network nodes that a packet will have to go through is O(N/Ns).  Enhanced routing mechanism Actually CHORD service Enhance the routing efficiency to O(logN) Need to introduce one more type of nodes, beacon, who also knows the identity of the secret servlet

System Architecture – version 2 Source Point SOAP Secret Servlet Secret Servlet Secret Servlet Target Beacon Overlay nodes Filtered region

Overlay Routing Algorithm – CHORD Service m = 5  Each node with an ID via a hash function.  Suppose 2 m possible ids.  Each node contains a table of m entries.  The i th entry in the table of node x is the 1 st node whose id is >= (x + 2 i-1 (mode 2 m ))  If node x receives a packet destined to node y, it forwards the packet to the node in its table whose id is closest to, but <= y  For a node y not in the overlay, the node whose id is closest to but >= y stores information about y (i.e. knows that y is not in the overlay) : : : : : : : : : : : 22 :

Overlay Routing Algorithm – CHORD Service  CHORD guarantees that a packet will get to its destination through no more than logN nodes, where N is the size of the overlay.  Multiple destination nodes for a given identifier can be created by using different hash functions. (e.g. the target ’ s IP can be mapped to several beacons)  By choosing the right class of hash functions, the sequences of nodes used to carry a packet from a node to the destination are independent from one another. (e.g. the paths from a source to different beacons are independent)  CHORD is robust to changes in overlay membership: each node ’ s list is adjusted to account for nodes leaving and joining the overlay.

Architecture Summary  A site (target) selects a number of SOS nodes to act as secret servlets and sets up its filtering perimeter;  A secret servlet, upon informed of its role in the system (request authenticity verified), computes the key k for each of a number of well-known consistent hash functions, based on the target site’s network address range. Each of these keys will identify a number of overlay nodes that will act as beacons for that target site.  Beacons, will be informed by either the servlets or the target of the servlets’ ids (request authenticity verified).  A source must first contact an overlay access point (SOAP). After authenticating and authorizing the request, the SOAP securely routes all traffic from the source to the target to one of the beacons. The SOAP (and all subsequent hops on the overlay) can route the packet to an appropriate beacon in a distributed fashion using Chord by applying appropriate hash function to the target’s address to identify the next hop on the overlay.  The beacon then routes the packet to a secret servlet that then routes the packet (through the filtering) to the target.

Architecture Summary (cont.)  If a SOAP is attacked, the confirmed source point can simply choose an alternate SOAP by which it enters the overlay.  If a node within the overlay is attacked, the node simply exits the overlay until the attack terminates.  If a beacon is attacked, it exits and the CHORD service self-heals by choosing a new node as that beacon for that hash function.  If a secret servlet is attacked or its identity is breached, the target can simply choose alternate secret servlets.

Performance Analysis of SOS  Assumptions An attacker knows all the overlay nodes, and can attack any of them by bombarding them with traffic, however, an attacker can only manipulate finite resources and bandwidth. An attacker does not know which nodes are secret servlets or beacons, nor will they infer these identities. Attackers have not breached the security protocols of the overlay, i.e. their packets can always be identified by SOS nodes as being illegitimate Each legitimate user can access the overlay through a limited number of SOAPs, but different users access the overlay through different SOAPs  Three analysis models A Static Attack Dynamic Attacks and Recovery Attacking the Underlying Network

Performance Analysis (cont.)  A Static Attack P h (a, b, c): the probability that a set of b nodes selected randomly from a ≥ b nodes contains a specific subset of c nodes. Notations:  T – the target  {S i (T)} - the set of secret servlets  U s = |{S i (T)}|  {A i (T)} – the set of SOAPs  U o = |{A i (T)}|  {B i (T)} – the set of beacons  U b = |{B i (T)}|  n a - the number of nodes the attacker attacks  U S,T – a random variable that equals 1 if S can reach T during an ongoing attack and 0 otherwise P r [U T,S = 1] = (1 – P h (N, n a, U s ))(1 – P h (N, n a, U b ))(1 – P h (N, n a, U o ))

Performance Analysis (cont.) U s = U o = U b = 10, n a varies

Discussion  Combines IP Security, IP router filtering, and Overlay network routing techniques.  Proactive mechanism.  SOAPs and secret servlets both are a part of distributed firewalls.  The more the number of nodes in an overlay network, the more effectively the SOS protects its users from DDoS attacks.  Further questions Attacks from inside the overlay A Shared Secure Overlay – scalability issues Timely delivery

Thank you!