Network Working Group Jaehwa Lee Internet-Draft KT Advanced Technology Lab Expires: April 16, 2006 Choong Seon Hong Kyung Hee University October, 2005 Load Balance-based Reorganizing Protocol for SOS in Active Network draft-jaehwa-loadbalanced-sos-activenetwork-00.txt This Internet-Draft will expire on April 16, 2005. Status of This Document By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Distribution of this draft, which is intended to become a Best Current Practice, is unlimited. Comments should be sent to the DNS Working Group mailing list or to the author. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than a "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract Secure overlay services (SOS) architecture has been proposed to provide reliable communication between clients and a target under DDoS attacks. The SOS architecture employs a set of overlay nodes arranged in three hierarchical layers that controls access to the target. Although the architecture is novel and works well under simple congestion based attacks, we observe that it is flimsy after it resisted the DDoS for a period of time and it didn't pay attention to the endurance of the Nodes. We propose an Algorithm to improve the secure overlay services (SOS) both on load balance and resilient. Lee& Hong Expires April 16, 2006 [Page 1] Internet-Draft Load Balance-based Reorganizing October, 2005 Protocol for SOS in AN Table of Contents 1. Introduction ------------------------------------------------ 2 2. Related work ------------------------------------------------ 2 2.1 DDOS ----------------------------------------------------- 3 2.2 Active Network---------------------------------------------- 4 3. SOS(secure overlay service) -------------------------------- 4 ¡¡¡¡3.1 Overview of SOS ---------------------------------------- 5 ¡¡¡¡3.2 Chord in SOS ------------------------------------------- 5 ¡¡¡¡3.3 Analysis of the Architecture---------------------------- 6 3.4 Solution ----------------------------------------------- 7 4. Reference --------------------------------------------------- 7 5. Acknowledgments --------------------------------------------- 7 ee& Hong Expires April 16, 2006 [Page 2] Internet-Draft Load Balance-based Reorganizing October, 2005 Protocol for SOS in AN 1. Introduction Current level of sophistication in system resilience to Distributed Denial of Services (DDoS) or other forms of attacks is far from definite. Tremendous amount of research is being done in order to improve the system security under DDoS attacks. Communication reliability over the Internet is critical in emergency, medical, and other related services. Apart from providing a high degree of path availability for communication, such systems need to be resilient to attacks from malicious users within and outside of the system that aim to disrupt communication. Also, attacks on special nodes or hot spots in such systems can have catastrophic effects. A Secure Overlay Services (SOS) architecture has been proposed in [1] in the framework of a set of clients communicating with a target during critical situations. The SOS architecture provides a high degree of path availability in the presence of random DDoS attacks. The proposed SOS architecture has a variety of very nice and novel features. It is simple and easily deployable. In fact with only a very few set of nodes across the 3 layers, the SOS architecture provides good performance in terms of providing path availability between clients and the target even without system recovery under on?going attacks. 2. Related work 2.1. DDOS A DDoS attack is a cyber attack in which an overwhelming flood of network packets is generated by many different sources for the purpose of interfering with or preventing legitimate access to a service. Typically DDoS attacks are directed at one or more targets such as end?users, web servers, portions of networks, or network infrastructure components. For example, an amateur attacker disabled some of the world¡¯s largest web services (e.g., Yahoo!, CNN, Amazon, and Buy.com) for several hours in February 2000. Creating defenses for DDoS is difficult for several reasons. The network traffic transmitted in a DDoS attack can be virtually indistinguishable from traffic for legitimate use of the service 2.2. Active Network ¡¡¡¡The BASIC goals of active networking (AN) are to create networking technologies that, in contrast to current networks, are easy to evolve and which allow application specific customization. To achieve these goals, AN uses a simple idea, that the network would be easier to change and customize if it were programmable. Although there are a few pioneering efforts that predate it, AN became a vigorous research area when DARPA began funding research in the mid-1990s. ee& Hong Expires April 16, 2006 [Page 3] Internet-Draft Load Balance-based Reorganizing October, 2005 Protocol for SOS in AN The reason that the AN is a combination of ideas from each of these areas is clear. First, the basic goal of the AN is to build networking systems, as such networking is the core discipline that is built upon. Further, the AN focuses on how to build networks. But we can view networks as low-level distributed systems. Thus, building networks is building distributed systems, and thus, issues and ideas from distributed systems come into play. Programming languages research becomes important because we wish to build these low-level distributed systems so that they can be programmed and programming languages are the key to expressing programs. PL plays a role not just in what we can express, but also in what can not be expressed, thus giving us control over the power of programmability. Finally, two critical issues, security and resource allocation and control, motivate the operating systems (OS) role, as the focus of OS has been the abstraction, protection, and management of system resources. 3. SOS (Secure overlay Service) 3.1. Overview of SOS The goal of the SOS architecture is to allow communication between a confirmed user and a target. By confirmed, we mean that the target has given prior permission to this user. Typically, this means that the user¡¯s packets must be authenticated and authorized by the SOS infrastructure before traffic is allowed to flow between the users through the overlay to the target. Both peers can use the SOS infrastructure to protect bidirectional communications; this is particularly important for ¡°static¡± sites (e.g., two branches of the same company). For mobile clients the reverse direction¡¯s traffic (from the target site to the client) can be sent directly over the Internet, or it can also use the SOS infrastructure. -------------- ------ --------------- -------- |Source point| -----> |SOAP| |Secert Servlet| ------> |Target| -------------- ------ --------------- -------- | | | | -------------- -------- |Overlay Node| ------> |Beacon| -------------- -------- Fig 1 Basic SOS Architecture Forwarding of a packet within the SOS architecture, depicted in Fig1, proceeds through five stages Lee& Hong Expires April 16, 2006 [Page 4] Internet-Draft Load Balance-based Reorganizing October, 2005 Protocol for SOS in AN a) A source point that is the origin of the traffic forward a packet to a special overlay node called a secure overlay access point (SOAP) that receives and verifies that the source point has a legitimate communication for the target.? b) The SOAP routes the packet to a special node in the SOS architecture that is easily reached, called the beacon. c) The beacon forward the packet to a ¡°secret¡± node, called the secret servlet, whose identity is known to only a small subset of participants in the SOS architecture. d) The secret servlet forward the packet to the target. e) The filter around the target stops all traffic from reaching the target except for traffic that is forwarded from a point whose IP address is the secret servlet. In the following discussion, we motivate why the SOS architecture requires the series of steps described above 3.2. Chord in SOS Many distributed peer-to-peer applications need to determine the node that stores a data item. The Chord protocol solves this challenging problem in decentralized manner. It offers a powerful primitive: given a key, it determines the node responsible for storing the key's value, and does so efficiently. In the steady state, in an node network, each node maintains routing information for only about O(log N)other nodes, and resolves all lookups via O(log N) messages to other nodes. Updates to the routing information for nodes leaving and joining require only O(log N) messages. Attractive features of Chord include its simplicity, provable correctness, and provable performance even in the face of concurrent node arrivals and departures. It continues to function correctly, albeit at degraded performance, when a node's information is only partially correct. Our theoretical analysis, simulations, and experimental results confirm that Chord scales well with the number of nodes, recovers from large numbers of simultaneous node failures and joins, and answers most lookups correctly even during recovery. Lee& Hong Expires April 16, 2006 [Page 5] Internet-Draft Load Balance-based Reorganizing October, 2005 Protocol for SOS in AN 3.3. Analysis of the Architecture Chord needs to deal with nodes joining the system and with nodes that fail or leave voluntarily. In order to ensure that lookups execute correctly as the set of participating nodes changes, Chord must ensure that each node¡¯s successor pointer is up to date. It does this using a ¡°stabilization¡± protocol that each node runs periodically in the background and which updates Chord¡¯s finger tables and successor pointers. But this kind process does not pay attention to the load balance. Because Chord only can make sure the logical link will be repaired as soon as it can. This will bring troubles when the successor was already very busy or was going to exit the SOS system. For example, there is always probability of some logical neighbor nodes was attacked in same time. At this time the Nodes may not broke down immediately, but to fall into poor situation. Then the successor task moving among those Nodes is inefficient and of no worth. SOS is robust against DDoS attacks because if any node (no matter it¡¯s a SOAP, Beacon or Secret Servlet) within the overlay is attacked, the node simply exits the overlay .The Chord services will self?heals, providing new paths over the reformed overlay to (potentially new sets of) beacons. There three kind changes take place in the SOS system: (1) Node exit (by Chord); (2) Node reconfiguration (by SOS); (3) Node rejoin (by Chord) Both of last two operations is change the logical place of nodes, but in fact they don¡¯t cooperate well. Node reconfiguration is use for change the logical structure of the SOS to stop the inertial DDOS attack. Reconfiguration will change the topology in the SOS though exchange the logical place of the Nodes. Node reconfiguration is use for change the logical structure of the SOS to stop the inertial DDOS attack. Reconfiguration will change the topology in the SOS though exchange the logical place of the Nodes. In the Chord, we mapped the Identifiers to the Nodes. Normally we mapped the immediate identifiers to the geographical detached Node in order to make the system robust, when facing DDoS attack. When Nodes rejoin the Chord, it will find its own place in the Chord circle in rely on the pristine Consistent Hashing Function. But now the Identifiers were not organized by ascending order. Since the jumbled order caused by Nodes¡¯ reconfiguration was not control by Chord, there is probability of the geographical neighbor Node became the logical neighbor node in Chord. This is against our original expectation. And it¡¯s dangerous when the attacker used the bound attack. (attack a group of seriate IP address) Lee& Hong Expires April 16, 2006 [Page 6] Internet-Draft Load Balance-based Reorganizing October, 2005 Protocol for SOS in AN 3.4. Solution To the load balance, this problem can set down by collecting the load balance information of the successor node. In active Node the Bill board can store and collect the information of the node. We can take the load balance factor into account during the cause of select the alternate node. The Nodes update the information in Bill board every a short time or the topology was changed. Then the nodes can get load balance parameter from the Bill board. To the jumbled rejoining, we define a new algorithm in order to deal with this problem. Before the rejoin, we can first check if the successor is a geographical neighbor node of the rejoin node.? If it is, try one of nodes in its finger table.? Until find the one who is not a geographical neighbor node. Then go on the rejoin steps. 1) Send rejoin_request // Rejoin Node // 2) Receive rejoin_request // Response Node // Select object from the finger_Node_table If (load_balance_check = busy) & (geography_detach_policy_check = ok) Return the object ID as the response Else select next object from the finger_node_table Repeat the Check process Until the object is Null, return Process Failure 3) Receive rejoin_response // Rejoin Node // Copies all keys less than predecessor Node from object Node Updates the predecessor Node Lee& Hong Expires April 16, 2006 [Page 7] Internet-Draft Load Balance-based Reorganizing October, 2005 Protocol for SOS in AN 4. Reference [1] A. Keromytis, A, V. Misra, and D. Rubenstein, ¡°SOS: Secure overlay services,¡± in Proceedings of ACM SIGCOMM, Pittsburg, PA, August 2002. [2] Stoica, I., Morris, R., Karger, D., Kaashoek< M., and Balakrishnan, H., ¡°Chord: A scalable peer-to-peer lookup service for internet applications,¡± ACM SIGCOMM, San Diego, CA, August 2001. [3] Xuan, D., Chellappan, S., Wang, X., and Wang, S., ¡°Analysis of the generalized secure overlay services architecture,¡± Technical Report, The Department of Computer and Information Science, The Ohio State University, August 2003. [4] Chu, Y., Rao, S., and Zhang, H., ¡°A case for end system multicast,¡± in Proceedings of ACM SIGMETRICS, Santa Clara, CA, June 2000. [5] Blaze, M., Ioannidis, J., and Keromytis, A., ¡°Trust management for IPsec,¡± in Proc. Network and Distributed System Security Symp., Feb. 2001, pp. 135-151. [6] Dabek, F., Kaashoek, F., Karger, D., and Stoica, I., ¡°Wide-area cooperative storage with CFS,¡± in Proc. ACM Symp. Operating Systems Principles, Banff, Canada, 2001, pp. 202-215. [7] Kubiatowicz, J., Bindel, Chen, Y., Czerwinski, S., Eaton, P., Geels, D., Gummadi, R., Rhea, S., Weatherspoon, H., Weimer, W., Wells,C., and Zhao,B., ¡°Oceanstore: An architecture for global-scale persistent storage,¡± in Proc. 9th Int. Conf. Architectural Support for Programming Languages and Operating systems (ASPLOS 2000), Boston, MA, Nov. 2000, pp. 190-201. Authors' Addresses Jaehwa Lee KT Advanced Technology Lab Woomyun, Seocho, Seoul, Korea E-mail : lethal@kt.co.kr Choong Seon Hong Department of Computer Engineering Kyung Hee University 1 Seocheon, Giheung, Yongin, Gyeongi-Do, 449-701, Korea Phone: +82 31 201 2532 E-mail : cshong@khu.ac.kr Lee& Hong Expires April 16, 2006 [Page 8] Internet-Draft Load Balance-based Reorganizing October, 2005 Protocol for SOS in AN Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lee& Hong Expires April 16, 2006 [Page 9]