Internet DRAFT - draft-jaehwa-loadbalanced-sos-activenetwork
draft-jaehwa-loadbalanced-sos-activenetwork
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 <namedroppers@ops.ietf.org> 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]
