2010 International Conference on Advances in Computer Engineering
Integrated Mechanism to Prevent Agent Blocking in Secure Mobile Agent Platform System Ramandeep Kaur and Rama Krishna Challa
Rajwinder Singh
Department of Computer Science NITTTR , Sector – 26 Chandigarh , India e-mail:
[email protected]
Department of Computer Science Engg. Chandigarh Engineering College , Landran Mohali , India e-mail:
[email protected] amount of data interchanged between the client and the server, mobile agent system provides considerable improvement in performance over client-server communication. Hence the use of mobile agents is expanding rapidly in many Internet applications [3,4,5]. Communication over the Internet is not reliable. Hosts connected via the Internet constantly fail and recover. The communications links go down any time. Due to high communication loads, link failure and the software bugs, transient communications and node failures are common in the Internet. Therefore reliability is an important issue for Internet application [6]. Failure in mobile agent may lead to partial or complete loss of an agent. The following undesirable scenario may occur when mobile agents are sent from one host to another: • An agent [7] travels from one host to another, it never reaches its destination due to crashes or because it is terminated by a malicious host or agent. This is an agent failure.
Abstract—Mobile agent paradigm has attracted attention recently but it is still not widely used. While a mobile agent model overcomes the limitations of traditional client-server distributed computing, there are several fundamental issues in design, implementation and deployment of mobile agent systems running over the Internet. These include agent fault tolerance, agent security, inter agent communication and synchronization. In this work we focus our study on the agent fault tolerance with prevention against blocking attacks. In this paper, we propose fault tolerance mechanism for preventing the agent blocking in scenarios where the agent is captured by malicious host in the network. This approach makes use of acknowledgements and partial result retrieval and when implemented in SMAPS allowed the originator to retrieve partial results and track the location of mobile agent at any time during the process of transaction execution. The proposed mechanism has been implemented and evaluated in terms of parameters such as fault tolerant time, message size and communication overhead. The results show the improvement in reliability and performance, especially for mobile agents in Internet application.
•
The host platform on which an agent resides crashes or shuts down unexpectedly, due to failure. Many agents on the hosts may be inactive but in waiting state due to unavailability of external events. If more agents migrate through this host, it may run out of memory. This is an agent host failure.
•
Destination node fails or there is a failure in communication link.
Keywords-mobile agent, fault tolerance, fault tolerant time, blocking attacks.
I.
INTRODUCTION
A mobile agent [1] is a piece of program code that can execute autonomously without the supervision of owner. Mobile agents are capable of interacting and learning from their environment and can react accordingly. The mobile agent performs its job whenever it is found appropriate and it is not restricted to be collocated with its client. Mobility [2] allows an agent to move to remote location and continue its thread of execution on a remote host machine. Mobile agents are particularly attractive for designing distributed and decentralized applications [8] as they can reduce the processing time and network bandwidth usage by moving the code closer to the data located on a remote host. They are sent by owners and they visit a series of hosts. The mobile agents are executed locally on these hosts to perform their tasks and will return to the owners with their results. Mobile agent carries the application code with them from the client to the server instead of transferring the data between a client and a server. Since the size of code is often less than the 978-0-7695-4058-0/10 $26.00 © 2010 IEEE DOI 10.1109/ACE.2010.74
Failure detection and recovery are two important issues in the design of reliable mobile agent system [9]. Fault tolerance guarantees the uninterrupted operation of a distributed software system despite network failure. Thus it is important to make mobile agent execution fault tolerant. In this paper we present a user transparent fault tolerance approach in mobile agent environments that would help in prevention of loss of information collected by an agent, in event of attack by malicious host. The user can select a single application given to the environment and can decide for every application whether it has to be treated fault tolerant or not. This means that a user or application can itself decide individually if and when fault tolerance has to be activated. The execution of fault tolerant and non fault tolerant application is possible. Thus to enable fault tolerant application it is not necessary to change the application code, thus providing transparency. 158
The rest of paper is organized as follows. Section 2 provides the brief introduction to architectural framework of Secure Mobile Agent Platform System (SMAPS) and the basic concept for fault tolerance mechanism for mobile agents. Section 3 describes the proposed non-blocking approach deployed for prevention of agents by use of acknowledgements and returning back of partial results back to the originator in scenario when the agent is captured by malicious or hostile host. In Section 4 we report on the implementation results of proposed mechanism and examine the effect of varying parameters followed by conclusions in Section 5. II.
examines the nature of the received mobile agent and executes it. The execution of the agent depends on its nature and state. The agent can be transferred from one AHS to another whenever required. On completion of execution, the agent submits its results to the AHS, which in turn stores the results until the remote AL retrieves them for the user. The AHS is the key component of SMAPS. It consists of the manager modules and the host modules. The host modules lie at the base of the SMAPS architecture. It is the basic utility module, lying below the manager modules and is responsible for driving the AHS, by ensuring proper coordination between various managers and making them work in tandem. The various manager modules reside on the layer above the host module layer. They interact with it and work in tandem with other managers, upon receiving connection requests from the AL or the AHS.
INTRODUCTION TO SECURE MOBILE AGENT PLATFORM SYSTEM
In our work, we implemented our proposed mechanism on Secure Mobile Agent Platform System (SMAPS) [10] for experimental evaluation. The existing security and adaptability features of SMAPS when combined with proposed fault tolerance mechanism offers viable solutions to various problems encountered in mobile agent platforms in general. Figure 1 shows basic block of the SMAPS. Each node of the network has an Agent Host Server (AHS), which presents a secure execution environment on which new agents may be created, accepted or to which agents may be dispatched and an Agent Launcher (AL), which is responsible for submitting the mobile agent on behalf of the user to the AHS. AHS treats every agent as a distinct principal and provides protection mechanisms that isolate agents. The system differs from other mobile agents systems in the abstractions it provides to address issues of agent isolation. AHS agents are light-weight implementations as threads instead of processes. Each agent is an autonomous object with a unique identification and agents communicate via asynchronous message passing. SMAPS proposes a new agent model, the protected agent model which ensures complete isolation against unauthorized access of any type. A user, who wants to perform a task, submits the mobile agent designed to perform that task, to the AL on the user system. SMAPS instantiates a private object of its own, an instance of predefined object AgentProtected, and uses it as a wrapper around the newly created agent by declaring the agent to be a private object of AgentProtected object. This type of encapsulation ensures complete isolation, preventing other agents to access the agent state directly. The AL then tries to establish a connection with the specified AHS, where the user already holds an account. An agent is only allowed to communicate with its environment over the AHS engine through the methods defined in a predefined interface object, AgentInterface, which is also made the private object of the agent during the creation process. The interface provides functions for the agent to communicate with AHS. All variables of agents are declared as private and they have corresponding access or methods. Agents issue or receive method invocation requests through asynchronous messages over the secure communication facility of SMPAS. If the connection is established, the AL submits the mobile agent to it and can then go offline. The AHS
Mobile Agent with task
Security Manage
Manager Modules
Persistence Manager
Location Manager
Agent Launcher User
Engine
Host Modules RMI Policy Management
Agent Host Server
JVM
Mobile Agent with result
Figure 1. Architecture of SMAPS
In order to enable use of mobile agents in untrustworthy environments such as Internet it is essential to ensure that the mobile agent execution be made fault tolerant. The two main desired properties while ensuring fault tolerance are 1) exactly once and 2) non blocking. Exactly once property ensures that the all the operations in the entire sequence of stages of mobile agents, are executed exactly once. Message Queues for Mobile Agent Execution can be employed for ensuring the property of exactly once execution [12]. Non blocking may be achieved by using replication as efficient mechanism but is not much feasible in case of malicious host (as it may violate exactly once property). The blocking attacks results in the blocking of mobile agent execution due to malicious host or agent/host/communication failure. If the mobile Agent is captured by the malicious host, it might not be able to return to the originator with the collected data. Based on the approach of sending timely acknowledgements and partial results [13], our work mainly focuses on reliably returning the information collected by the mobile agent back to the originator even in the scenario of the mobile agent being captured by the malicious host(s).
159
III.
PROPOSED SCHEME FOR ACHIEVING NON BLOCKING PROPERTY
MAp. If the agent lifetime expires and the partial results received by the originator don’t prove sufficient, then the originator has the option of relaunching the mobile agent.
This scheme was implemented in SMAPS to ensure that the originator of the mobile agent at any point of time would have the information regarding the state of mobile agent, its partial results along with the ability to upgrade the preferences the mobile agent is carrying. Assumptions and Notations The security aspect is a taken care of by the secure architecture of Secure Mobile Agent Platforms (SMAP). The inbuilt security helps in authenticating the visited hosts and agents. The main consideration is handling the scenario where the hosts first obtains authentication but then after having obtained the authority for mobile agent execution, begins to behave maliciously. The hosts that turned hostile pose the danger of blocking the mobile agent and halt its further movement in the network. It is assumed that the agent’s operations are idempotent (thus exactly once need not be main consideration) and non blocking is ensured. The notation used in implementing non blocking property in SMAPS is as follows: Ho: Originator host Hi: Hosts visited by host during its movement in the network (1< i < n) MA : Mobile agent originally launched MAi: Mobile agent with new / changed preferences MAp: Mobile agent carrying partial results MAr: Mobile agent carrying results MAI: Mobile agent carrying renewed preferences LTMA: Life time of mobile agent Ii: Information collected from host Hi FTMA: Fault tolerant time for mobile agent ACK(Hi): Acknowledgement from host Hi
ACK(H4) ACK (H2)
MA(I0, I1,I2)
MA(I0, I1)
MA(I0) Ho
H1
H2
MA(I0, I1,I2I3)
H3
MA(I0, I1,I2,I3,I4)
H4
H5
MAr(I0, I1,I2,I3,I4,I5) LifeTime (LTMA)
Figure 2. Mobile agent execution with n = 2
Considering the scenario in which the agent has been captured by the hostile host Hk . For scenario shown in Figure 3, where execution of mobile agent is done with n = 3, when the number of visited hosts reaches 3, an acknowledgement is sent to the originator. The fault tolerant time FTMA could also be used as a check to send the acknowledgement to the originator. But if the agent is captured when neither the fault tolerance time nor the life time of the agent has expired, the originator would not do anything till any one of them expires. PROBE(H4) ACK (H2)
MA(I0) Ho
The scenario considered is the web based e- marketplace that provides user with the information on the products for sale by collecting the prices and comparing the prices of the set of product specified by the user. The information needs to be collected in real time for time sensitive applications such as stock market, online shopping, etc. from different hosts H1,H2…Hn selected dynamically by freely roaming mobile agent over the network. Therefore the originator is assumed to be always connected to the network to collect the results. Implementing the proposed solution, an agent is originally launched by the originator Ho. Under general operation of a mobile agent it returns to the originator after the expiry of its LTMA. The various implementations schemes can be possibly used. One of them as shown in Figure 2, requires that the host Hi+1 having received the mobile agent to send the acknowledgement ACK(Hi+1) to the host Hi, conveying that the mobile agent has been successfully forwarded to the next host i.e. Hi+2 after its successful operation on Hi+1. Another implementation is by use of FTMA, which is predefined depending on the networks transmission time and on the time sensitivity of the application. If the expiry of FTMA occurs and there is no acknowledgement received from Hi+1, then the Hi would send the set of information (partial results) collected till now back to the originator in form of
H1
MA(I0, I1,I2I3)
MA(I0, I1,I2)
MA(I0, I1) H2
H3
H4
H5
MAr(I0, I1,I2,I3,I4,I5)
LifeTime (LTMA)
Figure 3. Mobile agent execution with n=3, scenario when custody occurs at Host 4
At expiry of either of the time, the originator sends a PROBE(Hj) to the host Hj (j
