Protection and Interoperability for Mobile Agents: A ... - Semantic Scholar

IEICE TRANS. COMMUN., VOL.E83–B, NO.5 MAY 2000

961

PAPER

IEICE/IEEE Joint Special Issue on Autonomous Decentralized Systems

Protection and Interoperability for Mobile Agents: A Secure and Open Programming Environment∗ Paolo BELLAVISTA† , Antonio CORRADI† , and Cesare STEFANELLI†† , Nonmembers

SUMMARY The Mobile Agent technology helps in the development of applications in open, distributed and heterogeneous environments such as the Internet and the Web, but it has to answer to the requirements of security and interoperability to achieve wide acceptance. The paper focuses on security and interoperability, and describes a Secure and Open Mobile Agent (SOMA) programming environment where both requirements are main design objectives. On the one hand, SOMA is based on a thorough security model and provides a wide range of mechanisms and tools to build and enforce flexible security policies. On the other hand, the SOMA framework permits to interoperate with different application components designed with different programming styles. SOMA grants interoperability by closely considering compliance with the OMG CORBA and MASIF standards. SOMA has already shown the feasibility and effectiveness of the approach for the development of flexible and adaptive applications in several areas, particularly in network and systems management. key words: mobile agents, security, interoperability, CORBA, network and systems management

1.

Introduction

Global distributed systems such as the Internet and the Web have proposed a new framework for application development and have motivated the interest in new programming paradigms based on mobile and dynamic entities. Remote Evaluation, Code On Demand and Mobile Agents (MA) [1]–[3] propose the migration not only of data but also of code over the network, to improve the flexibility of the traditional client/server (C/S) model. The MA model differs from the above ones because it allows executing entities to decide autonomously about their migration (code and runtime state). The MA paradigm is still in its infancy, but has already demonstrated its wide potential of applicability [3]. It could be suitable for several application areas, such as network and systems management, mobile Manuscript received October 4, 1999. Manuscript revised January 4, 2000. † The authors are with the Dipartimento di Elettronica, Informatica e Sistemistica, Universit` a di Bologna, Viale Risorgimento 2, 40136 Bologna, Italy. †† The author is with the Dipartimento di Ingegneria, Universit` a di Ferrara, Via Saragat 1, 44100 Ferrara, Italy. ∗ Work carried out under the financial support of the Italian Ministero dell’Universit` a e della Ricerca Scientifica e Tecnologica (MURST) in the framework of the Project “MOSAICO: Design Methodologies and Tools of High Performance Systems for Distributed Applications.”

computing, distributed information retrieval, and ecommerce. Numerous benefits are expected, including dynamic customization of both servers and clients, autonomy and adaptability in realizing user asynchronous operations, traffic reduction by exploiting resource locality and filtering opportunities, and robust remote interaction over unreliable networks and intermittent connections. In addition to the issues specific to code mobility, MA systems for Internet-based applications should address all the intrinsically complex aspects of the distributed systems area [4]. In particular, the paper claims that there are two issues deserving more attention by researchers and practitioners and that could greatly widen the application opportunities: the capacity of providing the proper level of security needed by applications and the possibility of granting the necessary degree of interoperability. The issue of security, overlooked in some of the first MA proposals, should be reconsidered in order to find solutions to the problems raised by the deployment of the MA technology in untrusted environments such as the Internet. Code mobility, intrinsic to the MA programming paradigm, adds another dimension of complexity to the problem of security. Interoperability is another critical requirement in the Internet scenario: MA applications should be capable of interacting with any other application and service, independent of the adopted programming style. The globality of the scenario forces to consider open solutions and standards for the interoperability issue. The paper describes an MA framework called Secure and Open Mobile Agents (SOMA, available at http://lia.deis.unibo.it/Research/SOMA/) that answers the key issues raised by the adoption of an MA programming environment for the Internet. SOMA provides a hierarchy of locality abstractions that helps in modeling a large variety of different schemes of interconnected networks. SOMA has been designed according to a layered architecture with several modules in each layer. The basic layer provides a rich set of facilities to simplify the deployment of MA-based services. On top of the basic layer, the security module makes available a large number of security mechanisms and tools, to permit different tradeoffs between performance and security, while the interoperability module exploits the CORBA technology [5] to achieve the


962

full integration with other CORBA-compliant environments, based on distributed OO frameworks and on MA platforms via the Mobile Agent System Interoperability Facility (MASIF) [6]. MASIF is a standard proposal to support agent mobility and management and is built on top of CORBA. We have used SOMA as a platform for the design, implementation and deployment of distributed applications in several application areas. In particular, we have realized an environment for network and systems management, which exploits the SOMA technology to furnish secure management services and interoperability with CORBA-compliant legacy systems. 2.

Security and Interoperability in MA Systems

The deployment of MA applications in the Internet environment can be accelerated as soon as MA systems can provide solutions that respect the opening and closing properties. The opening property permits to overcome the system boundaries in order to interoperate with any necessary external component and to allow any external recognized usage, while the closing property is the possibility of constraining the system in such a way to identify and exclude any malicious intrusion. The opening property is granted by interoperability considerations and the closing property by security mechanisms and policies. The first MA prototypes fail to satisfy completely the opening and closing properties. For this reason, a significant portion of the recent MA research has focused on the areas of security and interoperability (see Sect. 6 about related work). Here, we try to identify the main aspects of security and interoperability peculiar of MA frameworks and to detail possible guidelines for solution. Security is a fundamental issue when dealing with mobile agents in the untrusted Internet environment, where the communication network is assumed insecure and any node could host the execution of possibly malicious agents. The most common solutions adapt to the MA technology the accepted and standard mechanisms already emerged in the distributed computing area [7]. A secure MA framework should protect both agents and their execution environments from each others. At the moment, the MA research about security has mainly concentrated on the issue of protecting sites from potentially malicious agents [8]. This means to ensure that incoming agents cannot access to information they are not authorized to act upon, they cannot cause a denial of service to other authorized entities, and they cannot deliberately interfere with agents of other users. To this purpose, it is possible to exploit standard solutions for cryptographic authentication and authorization controls. Agent execution can be confined by adopting sand-boxing techniques and more flexible evo-

lutions with a finer degree of granularity controls [7]. Also the issue of agent protection from malicious sites is fundamental for MA applications in untrusted environments. The secrecy of message and agent transfer can benefit from accepted mechanisms and tools for securing the communication layer [7], while preserving agent integrity is still an active research area [9]. A crucial goal of MA security is to identify the application-specific proper balance between different and sometimes contrasting requirements: security, flexibility, usability, and efficiency. For this reason, it is important that the programming framework provides a large variety of security mechanisms, tools and infrastructures, to flexibly answer the different requirements of application designers. The second important property for MA systems to achieve is full interoperability. In general, MA proposals tend to consider it the provision of an easy access to users of the Internet and the Web. We claim that full interoperability means not only the possibility of user access via friendly GUI interfaces, but also the capacity of interacting with other applications, either designed according to the same MA style or with very different styles, and even with legacy systems. The goal of interoperability requires to identify the aspects of the MA technology candidate to become standard. The main recognized effort in the standardization toward interoperability of Object-Oriented components is Common Object Request Broker Architecture (CORBA), promoted by the Object Management Group (OMG) [5]. The OMG works in different specialized areas, and one of its subgroups has defined the MASIF standard [6]. MASIF integrates the traditional C/S model and the MA paradigm, thus providing CORBA-based interfaces for agent registering, management and transfer. There are also other interesting approaches toward the standardization of many aspects of the MA technology, such as the FIPA proposal that focuses on the definition of general standard languages and protocols for communication and management of heterogeneous agents [10]. 3.

The SOMA Programming Environment

This section gives a general overview of the architecture of the SOMA programming environment and then presents the design solutions adopted to provide the opening and closing properties. 3.1 The SOMA Architecture SOMA is based on a hierarchy of locality abstractions to model and describe any kind of open and global distributed system, ranging from simple LANs to the Internet, as depicted in Fig. 1. Any node owns at least one place that constitutes the agent execution environment. Several places can be grouped into a domain

BELLAVISTA et al.: PROTECTION AND INTEROPERABILITY FOR MOBILE AGENTS

963

Fig. 1

Locality abstractions and CORBA connection.

Fig. 2

The SOMA layered architecture.

abstraction that corresponds to a network locality. In each domain, a default place hosts a gateway to perform inter-domain functionality, to maintain domain-specific runtime information and to permit full integration with other components via the interoperability facility (see Sect. 3.3). Places and domains abstract a logical representation of system physical resources, and permit users and administrators to express their needs in terms of mobile agents, and to develop new applications and services based on mobile code. Mobility is an intrinsic feature not only of agents but also of most entities in the SOMA system, e.g. a mobile place is suitable for modeling the behavior of a nomadic terminal. The SOMA programming framework is designed according to a layered architecture, built on top of the Java Virtual Machine (JVM), as depicted in Fig. 2. SOMA main features are provided by the facility layer, that contains the principal functionality to fully support MA-based applications. This layer is composed by a set of basic facilities and by two distinguished components in charge of granting the opening and closing properties. The SOMA basic facilities include:

• the naming facility to associate entities with globally unique identifiers (GUID) and to organize these identifiers in name systems to make possible the tracing of entities even if they move. This facility allows to put together a set of different naming systems (DNS-, CORBA-, and LDAP-compliant), possibly characterized by different resolution policies, and is currently implemented by a coordinated set of dedicated agents; • the migration facility to permit the migration of one entity that should change its allocation. The reallocated entity should be traced also in the new location by any entity in need of its services, and, if it is active, should transparently restart its execution at the new location; • the communication facility to provide tools for coordination and communication between possibly mobile entities. Within the same place, agents interact by means of shared objects, such as blackboards and tuple spaces for tight cooperation. Outside the scope of the place, agents can perform coordinated tasks by exchanging asynchronous messages that are delivered to agents also in case of migration; • the monitoring facility to observe the state of local resources and services and to provide this information to the application level for permitting dynamic adaptive reactions. SOMA can monitor both system indicators (e.g. CPU load, file system occupation, printer status, available network bandwidth and collision rate) and application indicators (e.g. available services, program versioning, local agents state); • the persistency facility to give the possibility to suspend temporarily executing agents and to store them on a persistent medium. The facility allows agents not to waste system resources while they are waiting for external events such as the reconnection of one user or terminal to yield back the results of autonomously performed operations. In addition, it can be also exploited in providing faulttolerant solutions by organizing and disseminating stored copies of agents [13]. As shown in Fig. 2, on top of the basic facilities we have realized two advanced SOMA facilities to provide a rich set of mechanisms for interoperability and security. • The security facility provides tools for protecting both mobile agents and places. Authentication is based on standard certificates and on a public key infrastructure; authorization extends the Java standard mechanisms for access control; secrecy is achieved by integrating the cryptographic libraries furnished by external providers; integrity has required the development of MA-specific protocols for the protection of mobile agents from the execution environment.


964

• The interoperability facility allows SOMA agents to interwork with existing software and hardware components via compliance with CORBA IIOP specification [5]. SOMA agents can play the role of CORBA clients and can register themselves as CORBA servers to offer access points to an application outside the SOMA system. In addition, SOMA is compliant with the OMG work on MASIF [9] that standardizes the basic functions an MA framework should offer for agent management and transfer to other systems, whether MA-based or not. Further details about the SOMA programming framework and its implementation are presented elsewhere [11], [12] and are out of the scope of this paper, where we specifically focus on the SOMA facilities for security and interoperability. 3.2 The SOMA Security Facility SOMA has been designed and implemented by considering security as a key property integrated at any system layer [13]. Only this pervasive approach can achieve a level of security higher than the minimal one reached by MA systems that add a security strategy a posteriori. Whenever possible, SOMA security model has been implemented by taking into account only the standard security solutions usually employed in distributed systems. In fact, the design and the exploitation of ad hoc security mechanisms could require too great an effort, and, more important, nonstandard tools are close and unlikely to be accepted if compared with widespread solutions. SOMA addresses all the security issues that emerge in the context of real MA applications running on the Internet [15]: it provides protection for both hosts and agents, and ensures secrecy and integrity for agent communication and migration. SOMA recognizes a set of principals, i.e., the users responsible for agent and resource operations, and supports the definition of any model of trust for principals and mobile agents, to define who or what in the system is trusted, in what way, and to what extent. The SOMA security facility implements the model of trust and enforces the security policies. Principals are identified by standard certificates and are associated with a limited number of roles throughout the SOMA system. Roles permit to express the required model of trust, by determining the permitted operations on system resources. The association of principals with roles simplifies user administration and enhances the dynamicity in system configuration: only the information about roles needs to be propagated in the system, while principals are locally and dynamically associated with possibly different roles [16]. A graphical tool for run-time role management allows administra-

Fig. 3 Different security paths for agents from un/trusted domains.

tors to define new roles and to update existing ones, to associate principals with roles, and to automatically generate corresponding place policies. Mobile agents are signed by their principals, and the authentication phase ascertains the role of the agent principal [16]. When one agent is signed by more principals, it aggregates the permissions associated with their corresponding roles. Once authenticated, agents are authorized to interact with resources at the place according to the dynamically enforced security policy; any resource has its specific role-based access control list. Places can also maintain some accounting information on resource consumption by exploiting the functionality provided by the SOMA monitoring facility. Secrecy for agent/message transfer in SOMA exploits standard solutions for securing the communication layer. The issue of agent protection from hosting places is still an active area of research [15]. For instance, SOMA provides mobile agent integrity protection by using a number of integrity protocols that can suit different application scenarios; the main idea is to detect any possible modification of the data collected by agents moving in an untrusted domain [17]. Our security infrastructure is based on layered security policies: the definition of different locality abstractions enforces security policies where actions are controlled at both the place and the domain level. The domain defines a global security policy that imposes general authorizations and prohibitions; each place can only apply restrictions to the domain-level set of permissions (see Fig. 3). The wide variety of security mechanisms available in SOMA, and the clear distinction between mechanisms and policies give the possibility to decide a suitable trade-off between security needs and required performances, tailored on specific circumstances. As depicted in Fig. 3, agents from internally trusted domains can directly access to authorization check, while agents from untrusted ones have to overtake all the secrecy, in-


965

Fig. 4

SOMA full compliance with CORBA.

tegrity, authentication and authorization steps. As an additional example, two endpoints can negotiate SSL connection parameters in order to have none/short/ long key protection according to the nature of the application and to the level of trust they grant to each other. 3.3 The SOMA Interoperability Facility The large number of recently implemented MA platforms shows the interest of the distributed systems area in the MA programming paradigm. This variety, however, risks to endanger interoperability and to limit the growth of an MA applications industry. The only way to promote both interoperability and system diversity is to standardize some aspects of the MA technology. In the area of the traditional C/S approach to OO distributed computing, CORBA is the universally adopted standard for object management, apart from the notable exception of Microsoft which has its own Distributed Component Object Model (DCOM) [18]. CORBA puts together objects that can communicate to each other across boundaries such as network, different operating systems, and different programming languages. CORBA provides network transparency, openness and interoperability. In addition to that core functionality, it specifies an extensive set of object services, common facilities and application interfaces. The MA model embodies a new programming paradigm, distinguished from the C/S one, and, consequently, different from the CORBA programming model under many points of view (e.g. location awareness vs. network transparency). However, we claim that CORBA can play a fundamental role in achieving interoperability also for the MA technology, working as a standard bridge among proprietary implementations. CORBA compliance imposes some additional costs, especially in terms of run-time performance, but it is worth the trouble because it ensures openness and stability to applications, saving the investments in MAbased programming. Our scenario puts together two models: we use proprietary and efficient solutions for internal operations among SOMA entities, but provide

standard CORBA interfaces, both for exploiting the available CORBA services and for making SOMA itself a CORBA application object. There are three different aspects in providing SOMA compliance with CORBA (see Fig. 4): 1. an agent may call external CORBA objects (SOMA agents as CORBA clients); 2. an agent may publish its interface on a CORBA ORB (SOMA applications as CORBA servers); 3. any external entity may manage SOMA entities through the standard MASIF interface (interoperability between SOMA and other MASIF-compliant MA platforms). The first two features are obtained via the CORBA C/S module of the SOMA interoperability facility, which provides functionality to simplify the application designer duty in deploying CORBA-compliant components: agents can play the role of CORBA clients or can register themselves as CORBA servers to offer an application access point outside the SOMA system (see the network and systems management service in Sect. 5). Even if there is no conceptual problem for a mobile agent to register itself as a CORBA server, we currently grant this possibility only to SOMA agents that do not migrate during their lifetime (stationary agents) in order to avoid the burden of de/registering to the CORBA Naming Service at any migration. The third functionality is more complex an issue, and is addressed by the MASIF standard. MASIF does not suggest standardization of local agent operations such as agent interpretation, serialization, execution and deserialization because these actions are application specific, and there is currently no reason to limit MA system implementations to a single rigid architecture. MASIF proposes a standardization for agent and agent system names, for agent system types and for location syntax. It defines two interfaces (MAFAgentSystem and MAFFinder) with the typical sets of functionality respectively for agent management and for agent tracking. Agent management allows an external system to control agents of a MASIF-compliant MA system: MASIF defines interfaces for actions such as


966

suspending/resuming/terminating agents or for moving agents from an MA system to another one if the two systems have a compatible type. Agent tracking permits the tracing of agents registered with MAFFinders, which essentially provide an MA name service, since the CORBA Naming Service is not suitable for entities like agents, which are mobile by nature. Agent communication is outside the scope of MASIF, since it is extensively addressed by CORBA as object communication. The CORBA and MASIF standards recognize the need of security information and its management; all the implementations are required to introduce tools and mechanisms to enforce security when interacting with external components. SOMA also considers the additional security threats introduced by CORBA interoperability. On the one hand, sending/receiving CORBA requests/replies requires security techniques for channel encryption to ensure privacy on message exchange. On the other hand, the possibility for SOMA agents to act as CORBA servers and for SOMA places to host non-SOMA agents call for mechanisms for client/agent authentication, auditing and access control. SOMA takes into account the security problems by providing solutions compliant to both CORBA Security Services (CORBA SSs) [19] and MASIF security features. 4.

The SOMA Implementation

SOMA is implemented in Java to exploit its easy integrability with the Web scenario and its intrinsic portability in heterogeneous environments: we have developed the system on SUN Solaris workstations, and easily ported it to Win9x/NT PCs. Our support operates on both architectures and uses the Java 2 Platform [20]. The OO nature of the Java language has helped the design of the SOMA system: the encapsulation principle suits the abstraction needs of both resources and agents; the classification principle makes possible to inherit behavior from already specified components; multithreading, garbage collection and error management simplify writing robust CORBA objects. A well-known problem of Java is the lack of full mobility support, especially for Java threads: it is not possible to save the whole state of a thread before its migration to a different node. This restriction can be overcome either by modifying the JVM or by providing a new operation at the application level. We have chosen the latter solution to preserve portability. The new operation for mobility allows one agent to move itself during execution, by specifying the itinerary it has to follow and the method to be activated after any migration. 4.1 The Security Facility Implementation A large number of security mechanisms is available in

order to provide large flexibility in the choice of the most suitable security level for the specific context (application type, agents coming from trusted/untrusted domains and communicating in a secure/insecure network). The protection of execution environments from malicious agents is addressed by authentication and access control mechanisms, and is based on a public key infrastructure with X.509 certificates. Security policies define the permissions to operate on local resources for any recognized role in the system. Policies are defined at both the place and the domain levels and are stored in encrypted files. SOMA provides also a graphical management tool for domain/place administration that can add/delete/modify entries in the policy file at run-time, with no need to suspend execution. From the agent perspective, integrity and secrecy for message exchange and agent transfer are achieved by standard cryptographic mechanisms. When configuring the SOMA system for untrusted environments, it is possible to choose between the DES channel encryption, or the SSL protocol solution (that is just about to be integrated in the next release of SOMA). In the former case, any agent traversing an insecure path is encrypted with a secret key, previously exchanged through either the RSA or the DH protocol, and only valid for one session of interaction. In the latter case, we adopted the SSL protocol provided by the iSaSiLk package [21] that realizes not only confidentiality but also authentication and integrity on the standard socket communication layer. SSLv3 can support a set of different algorithms (RSA/DH/DSA for certification and private keys, RSA/DH for secret keys). During a preliminary handshake phase, the two socket ends can choose the algorithms to use, according to the required security needs; the choice can be renegotiated at any time during the communication session. Finally, SOMA protects agents from misbehavior of execution environments, by providing several protocols to preserve the integrity of both agent code and state. These protocols prevent malicious environments not only from modifying the information collected by one agent, but also from deleting part of it without being detected. The different integrity protocols available in the SOMA environment are targeted to different application cases, and can exhibit slightly different costs depending on the required security level [17]. In particular, Table 1 presents the performance of the Multiple Hops (MH) integrity protocol for agent state protection. The experimental results have been obtained by considering one agent that gathers 1 kB of data in each visited site, in the case of a cluster of 300-MHz PentiumII PCs with Windows NT. Table 1 compares the agent migration cost without any integrity protection with the one obtained by considering the MH protocol. The total migration costs are composed of a trans-


967 Table 1

Performance evaluations of the MH integrity protocol.

mission cost (TTX ) and of the execution overhead (TEXEC ) required to perform the needed cryptographic operations. The transmission cost further consists of the network overhead and the serialization one (the SOMA framework employs the Java de/serialization mechanisms to support agent migration), and linearly depends on agent size. The use of the MH protocol imposes a slight increase in agent size (and consequently in TTX ), and introduces an additional execution overhead TEXEC . The reported results, obtained as an average measure over a large number of tests, show that granting integrity to SOMA applications imposes a limited and acceptable performance reduction. 4.2 The Interoperability Facility Implementation Java and CORBA can be seen as two object infrastructures that complement each other very well. Java deals with implementation transparency, turning heterogeneous resources in homogeneous ones through the JVM common software layer. CORBA deals with network transparency, by providing the middleware to support C/S distributed applications independent of object physical location. A platform for universal network computing can be created by using Java as a programming language and CORBA as an integration technology [22]. The CORBA Interface Definition Language (IDL) maps to Java in a simply and intuitive way because of the characteristics and the OO nature of the Java language. Moreover, it is possible to achieve portability across all vendor ORBs† : first of all, the IDL-toJava standard defines an interface for portable stubs and skeletons, that can be dynamically moved and run within any Java ORB that supports the interface; secondly, all vendors have implemented the CORBA 3.0 Portable Object Adapter (POA) [23] in their products, overcoming the portability problems of the previous CORBA Basic Object Adapter. SOMA provides CORBA compliance by means of the interoperability facility that is composed by two distinct modules: the first one (CORBA C/S ) simplifies the design of SOMA entities as CORBA clients/servers; the second one (MASIFBridge) provides the MASIF functionality (see Figs. 4 and 5). Since MASIF implementation imposes an additional load on the execution place, it is not viable to extend all the SOMA localities with this feature. We

Fig. 5 Places with no/CORBA C/S/full interoperability facility.

have decided that only one place for domain (the default place) should be extended with the MASIFBridge module that represents the interoperability access point towards other MA systems. On the other hand, the CORBA C/S module is lightweight and many places in the same domain may use it to access to the CORBA bus, either for calling external services or for registering as servers. Any SOMA agent, resident on a CORBA C/S place, is able to act as a CORBA client/server through both static invocation/registration (IDL stub/skeleton) and dynamic ones (DII/DSI). Our implementation, based on the VisiBroker ORB, exploits only the portable functions provided by its POA, for not being tied to that particular ORB realization. The MASIF Bridge provides the basic functionality for agent management and naming (create agent(), fetch class(), receive agent(), get MAFFinder() methods in the MAFAgentSystem class, and all the methods in the MAFFinder class). We are currently working to integrate the remaining features specified in the MASIF interface in order to achieve the complete CORBA compliance. We are also testing the SOMA interoperability with the Grasshopper Agent System [24], the unique commercial MA system that has already implemented the MASIF interface. From the security point of view, the current SOMA implementation transfers CORBA requests/replies over a secure transmission channel implemented on VisiBroker SSL Pack [25] functionality. On the basis of this optional pack of VisiBroker, we have achieved privacy and integrity for CORBA messages, and defined an infrastructure for X.509 certificate distribution between non-SOMA entities. This approach is not an open standard solution, and forces computing entities to a specific proprietary implementation. It is only a temporary solution, and we are working on the realization of open † The most diffused Java ORBs, at the moment, are Iona OrbixWeb and Borland VisiBroker for Java.


968 Table 2 Time performance for SOMA agent migration through MASIF/SOMA.

and portable security services compliant with CORBA SSs specifications. To evaluate the interoperability costs in SOMA, Table 2 compares the average cost of the native migration mechanism with the one imposed by the MASIF interface. We have carried out the experimental results in a SOMA system composed by several domains, and we have measured the cost for migration between default places of different domains. The measures have been taken on an Ethernet LAN of 300-MHz PentiumII PCs with Windows NT. As we expected, MASIF agent migration is more expensive than SOMA proprietary one, as reported in the Total columns. The Total columns include the initial setup overhead to establish a connection between previously unconnected places. For this reason, any successive migration between the same places achieves better performance, as indicated in the table. In addition, in the case of MASIF migration, the Total column includes also the cost to obtain needed references to the MAFAgentSystem and MAFFinder from CORBA and MASIF naming services (as reported in the phase 1 column). The results also show that MASIF performance is only about 10% worse than the SOMA one in the case of successive migrations for 50 kB-sized agents. This is mainly due to the fact that both the VisiBroker ORB and the SOMA framework use the same Java de/serialization mechanisms, and the de/serialization overhead represents the most relevant factor with the increasing of agent size. The performance obtained for MASIF migration, however, is extremely acceptable and demonstrates the viability of the MASIF approach to interoperability. 5.

SOMA Applications: The Network, Systems and Service Management Environment

We have already exploited the SOMA framework to design, implement and deploy MA-based applications in several areas, from network and systems management (presented in the following) to mobile computing in case of both terminal and user mobility, from adaptive multimedia distribution with QoS requirements to autonomous retrieval of highly heterogeneous information for virtual museum services. Additional information about the SOMA undergoing activity for the real-

ization of distributed applications can be obtained at http://lia.deis.unibo.it/SOMA/Applications.shtml. Here, instead, our intention is to sum up our experience in the realization of a network, systems and service management environment [11], [12] that we have implemented upon the SOMA programming framework. We have decided to report this experience because management operations particularly stress the crucial properties of security and interoperability available in SOMA. Our management environment can help in the automation of management operations: it is capable of monitoring the state of the distributed system, of assisting and simplifying the dynamic configuration of any new network component, and of controlling and coordinating managed sets of distributed and heterogeneous resources. The MA approach represents an alternative and flexible solution to the problems of systems management tools, based on traditional protocols, such as SNMP and CMIP, that adopt a C/S model of interaction. The SOMA programming framework makes possible to delegate specific controlling actions to agents, that can move autonomously close to the part of the system to be managed, exploiting locality and reducing the message traffic over the network. The environment already provides a predefined set of agents for systems management and can be easily extended and tailored to new specific administration needs. Any authorized user can dynamically instantiate management agents to perform coordinated tasks either on the global scope of her managed system, or on a subset of the domains that compose it, or with the granularity of a single resource. Agents can autonomously monitor both system indicators (e.g. CPU load, file system occupation, printers status, available network bandwidth and collision rate) and application indicators (e.g. available services, program versioning, local agent states). They can either trigger agent-performed corrective operations or alert the administrator when some even complex threshold conditions are crossed. In addition, they can collect management data to report the time evolution of specified indicators for off-line performance analysis. Agents can obtain the value for system indicators both via SNMP interrogation in the case of SNMP-compliant managed resources, and via local interaction with Monitor stationary agents (i.e. objects that permanently execute on a place and exploit platform-dependent monitor functionality through the Java Native Interface mechanism). The mobile agents employed in systems management can be in charge of very sensible operations because agents usually have system duties. The risk of an incorrect action, due to either erroneous or malicious reasons, is intolerable, therefore the closing property should be considered a key property of management environments. In our environment, the authentication check verifies agent signatures when agents are enter-


969

Fig. 6 Web-enhanced CORBA access to the configuration GUIs of our SOMA-based management environment.

ing the place, and the authorization phase grants agents the right to access local resources according to the roles of their responsible administrators. To ensure secrecy, management agents can be encrypted when traversing an insecure path. The use of the MH protocol permits the detection of any possible violation of agent integrity. From the interoperability point of view, the management framework is already capable, on the one hand, of requesting external services from CORBA-compliant management tools, based either on SNMP or CMIP. On the other hand, in order to allow the access of authorized administrators from a non-SOMA host, our management tool can also act as a CORBA server. In this way, an administrator can exploit the management environment also via anywhere available user interfaces, such as CORBA-enhanced Web browsers (e.g. Netscape Communicator 4.x, as shown in Fig. 6). We have realized user-friendly graphical interfaces to operate directly on the managed resources. For example, Fig. 6 shows how the administrator can control the initial configuration of the system and its modification at run-time. The administrator is authenticated and is authorized to perform different operations, depending on her role. The same interface permits administrators to handle new roles, to add new places and domains to the systems, and to provide new resources and behavior. 6.

Related Work

Several MA systems have been recently proposed and implemented, and some surveys on the MA technology start to appear [3], [26]–[28]. This section tries to identify the emerging trends in the multiplicity of the

proposals, and, in particular, to examine the different directions of solution provided in the security and interoperability areas. The first realized MA platforms supported mobile agents written in a large variety of general-purpose/adhoc implementation languages (Ara in Tcl and C/C++, D’Agents in Tcl, Java and Scheme, Tacoma in C/C++, ML, Perl, Python, Scheme and Visual Basic [29]–[31]). A clearly emerging trend in recent MA systems is the uniform choice of Java. Some properties of the Java language make it particularly suitable to support the MA technology. The JVM bytecode is absolutely portable, and can also achieve efficiency due to the enhancements introduced by just-in-time compilation [32]. In addition, the Java language simplifies the realization of a secure and interoperable MA framework. The Java 2 Platform provides mechanisms and tools for users to define their suitable model of trust. This model of trust is enforced by an embedded Java Security Manager that controls any resource access on the basis of the policies defined by the local administrator. Moreover, this default security manager can be easily refined to deal with either MA- or application-specific requirements. With regard to interoperability, Java integration with CORBA is facilitated by the package org.omg.CORBA, which is available beginning from Java 2. From the point of view of security, all the solutions for protecting agents/execution sites from malicious intrusions of agents/execution sites, which are provided in the most diffused MA systems, tend to extensively employ the Java security mechanisms and tools. The largest part of the research work to protect hosting resources from malicious agents is along the direction of extending the Java Security Manager. Voyager implements a proprietary security manager [33]; Aglets does not allow application developers to subclass its security manager, but permits its dynamic configuration via a GUI tool or directly editing policy files [34]; Grasshopper provides customizable policies based on the identity of the agent and of the group to which it belongs [24]. SOMA makes available its security manager for subclassing and provides role-based policies enforced at both the domain and the place levels. Agents are associated with either their launching users or their code creators or both. In general, user and agent authentication mechanisms tends to move toward standards, such as X.509 certificates, in the latest versions of several platforms (Grasshopper, SOMA). Agent attacks, such as denial-of-service, based on malicious consumption of host resources, are still difficult to face in an efficient way. The only diffused countermeasures are to maintain and ascertain the uniqueness of agent identifiers. Resource managers encapsulate resources and are in charge of accounting for resource consumption: they are potentially capable of avoiding malicious cloning and flooding. Not all platforms provide confidentiality, integrity and paternity for the transmission


970

of messages and agents between hosts: aglets use symmetric cryptography algorithms for domain authentication and message integrity, but provide neither code encryption nor signing; solutions based on public key cryptography are the most diffused (Grasshopper, Concordia [35], SOMA), mainly via the establishment of an SSL channel from host to host, even if some systems (Concordia, SOMA) consider important the possibility to choose the application-specific proper solution among a variety of available security mechanisms (IDEA, DES, RC4, RC5, Misty or Triple DES symmetric key encryption mechanisms in Concordia, DES, RSA, DH, DSA in SOMA). The issue of protecting agents from possibly malicious hosting execution sites is even more difficult to solve, even if some recent works start to propose algorithms to protect agent state from deletion [15], [17]. From the point of view of interoperability, the research interest in the interoperation between heterogeneous MA platforms and between mobile agents and non-MA systems is more recent than the one about security, and the results achieved suffer from this novelty. However, the uniform choice of the Java language represents a milestone that can significantly accelerate the standardization process toward interoperability. In addition, though MASIF standardizes only a little subset of the functionality required for inter-working and leaves completely to system designers the responsibility of how to accommodate incoming foreign agents from other platforms (possibly written in different languages and packed with different serialization mechanisms), it has already achieved a large degree of acceptance and several platforms either have worked or are working to be compliant with it. The FIPA emerging standard has also attracted some interest for its possibility of expressing agent knowledge and behavior in an interoperable way. Some MA systems, such as Concordia, continues to provide proprietary non-standard facilities (Concordia bridge) to permit MA-based applications to interoperate with legacy services (in the Concordia case, PDAs and smart phones). Other systems consider MASIF but do not provide yet a fully compliant implementation of the standard. The aglets communication API is derived from MASIF, and its default implementation is called Aglets Transfer Protocol, a TCP-based applicationlevel protocol modeled on HTTP. Though aglets use a MASIF-derived interface for the communication layer, which is consequently protocol-independent (ATP, RMI and CORBA IIOP are supported), they do not export it as a CORBA object; therefore, the interface is not usable for the inter-working of heterogeneous agents. Other MA platforms provide mobility as an extension to well-assessed architectures for heterogeneous distributed computing [33], [36]. For instance, Voyager is tightly integrated with distributed processing computing via the implementation of a specific ORB mech-

anism (Voyager ORB ) that is proprietary, Java-specific and agent-specific. In that way, the integration with traditional C/S solutions is natural, but close to the exploitation of a proprietary functionality that does not permit the exchange of heterogeneous agents. On the contrary, some recent MA systems follow a more open approach to face the interoperability issue via compliance with standards: Grasshopper and SOMA have adopted and implemented MASIF, while other systems have announced their intention to become compliant in the next months. In addition, the last version of the Grasshopper system is the first commercial MA platform also compliant with FIPA, which however, probably due to its generality, has not yet achieved the expected interest neither in the industrial nor in the academic MA research. 7.

Conclusions

The MA technology is raising increasing interest and seems to be an elegant and uniform solution to a wide spectrum of application areas, from network and systems management to mobile computing, from distributed information retrieval to electronic commerce. Many MA systems already exist, but the major limit to their use in real complex applications for the Internet stems from their lack of security and interoperability. SOMA has been designed to provide an integrated approach to security: we have implemented mechanisms to protect local resources from malicious agents, agents from untrusted hosts, and communication among SOMA entities; our role-based policies can flexibly adapt to different contexts in order to obtain a suitable balancing between security and performances. Interoperability among different MA systems seems the other missing element to leverage the growth of MA applications industry. SOMA faces the issue of CORBA compliance, carefully taking into account its cost in terms of the added system overhead. SOMA agents can play the role of CORBA clients/servers; one place for domain, at least, publishes the MASIF interface to the CORBA ORB, thus permitting the full interoperability with other external and authorized CORBA systems, either MA-based or not. SOMA makes available a large variety of mechanisms, policies and tools to achieve flexibly proper levels of security and interoperability. These properties make our programming framework particularly suitable for the design, implementation and deployment of distributed services in several application domains, such as mobile computing, multimedia distribution and autonomous retrieval of museum information. In particular, we have extensively worked in the network, systems and service management area, where agents fulfill the administration needs by moving and autonomously executing on the managed nodes.


971

References [1] A. Fuggetta, G.P. Picco, and G. Vigna, “Understanding code mobility,” IEEE Trans. Software Eng., vol.24, no.5, May 1998. [2] J.W. Stamos and D.K. Gifford, “Remote evaluation,” ACM Trans. Prog. Lang. and Syst., vol.12, no.4, Oct. 1990. [3] K. Rothermel and F. Hohl, ed., Moblie Agents, Proc. 2nd International Workshop on Mobile Agents, Springer-Verlag, Lecture Notes in Computer Science, vol.1477, Sept. 1998. [4] J. Vitek and C. Tschudin, “Mobile object systems towards the programmable internet,” Lecture Notes in Computer Science, no.1222, Springer-Verlag, April 1997. [5] Object Management Group, CORBA/IIOP Rev 2.2, OMG Document formal/98-07-01, http://www.omg.org/corba/ corbaiiop, Feb. 1998. [6] GMD FOKUS, and IBM Corp, “Mobile Agent Facility Specification,” Joint Submission supported by Crystaliz Inc., General Magic Inc., the Open Group, OMG TC Document orbos/97-10-05, ftp://ftp.omg.org/docs/orbos/97-1005.pdf, 1998. [7] W. Stallings, Network and Internetwork Security: Principle and Practice, Prentice Hall, 1995. [8] G. Vigna, ed., “Mobile agents and security,” Lecture Notes in Computer Science, vol.1419, Springer-Verlag, 1998. [9] T. Sander and C. Tschudin, “Protecting mobile agents against malicious hosts,” in [7]. [10] Foundation for Intelligent Physical Agents—FIPA’99 version 0.2, http://www.fipa.org/spec/fipa99spec0.2.htm. [11] P. Bellavista, A. Corradi, and C. Stefanelli, “An open secure mobile agent framework for systems management,” J. Network and Systems Management, vol.7, no.3, Sept. 1999. [12] P. Bellavista, A. Corradi, C. Stefanelli, and F. Tarantino, Mobile Agents for Web-based Systems Management, Internet Research, vol.9, no.5, Nov. 1999. [13] F.M. Assis-Silva and R.Popescu-Zeletin, “An approach for providing mobile agent fault tolerance,” in [3]. [14] A. Corradi, M. Cremonini, and C. Stefanelli, “Security models and abstractions in a mobile agent environment,” WETICE98 Workshop on Collaboration in Presence of Mobility, Stanford, USA, June 1998. [15] B. Yee, “A sanctuary for mobile agents,” Proc. DARPA Workshop on Foundations for Secure Mobile Code, March 1997. [16] E. Lupu and M. Sloman, “A policy based role object model,” Proc. EDOC’97, IEEE, Oct. 1997. [17] M. Cremonini, A. Corradi, R. Montanari, and C. Stefanelli, “Mobile agents and security: Protocols for integrity,” 2nd IFIP Int. Working Conference on Distributed Applications and Interoperable Systems (DAIS’99), Helsinki, June 1999. [18] Microsoft—DCOM, http://www.microsoft.com/com/tech/ DCOM.asp [19] Object Management Group, CORBA Security Services, OMG Document formal/98-12-17, http://www.omg.org/ cgi-bin/doc?formal/98-12-17, Dec. 1998. [20] D. Flanagan, Java Power Reference, O’Reilly & Associates, March 1999. [21] Institute for Applied Information Processing and Communications—iSaSiLk 3.0, http://jcewww.iaik.at/iSaSiLk/. [22] S.M. Lewandowski, “Frameworks for component-based client/server computing,” ACM Computing Surveys, vol.30, no.1, March 1998. [23] Object Management Group, The Portable Object Adapter, OMG Document formal 99-07-15, http://www.omg.org/cgibin/doc?formal/99-07-15, July 1999. [24] IKV++-GrassHopper, http://www.ikv.de/products/ grass-

hopper/ [25] Borland—VisiBroker for Java, http://www.borland.com/ visibroker/ [26] M.K. Perdikeas, F.G. Chatzipapadopoulos, I.S. Venieris, and G. Marino, “Mobile agent standards and available platforms,” Computer Networks, vol.31, pp.1999–2016, Sept. 1999. [27] N.M. Karnik and A.R. Tripathi, “Design issues in mobileagent programming systems,” IEEE Concurrency, vol.6, no.3, Sept. 1998. [28] V.A. Pham and A. Karmouch, “Mobile software agents: An overview,” IEEE Commun., vol.36, no.7, July 1998. [29] H. Peine, “Security concepts and implementations for the ara mobile agent system,” Proc. 7th IEEE Workshop on Enabling Technologies: Infrastructure for the Collaborative Enterprises, USA, June 1998. [30] R.S. Gray, D. Kotz, G. Cybenko, and D. Rus, “D’Agents: Security in a multiple-language, mobile-agent system,” in [6]. [31] D. Johansen, F.B. Schneider, and R. van Renesse, “What TACOMA taught us,” in Mobility, Mobile Agents and Process Migration—An Edited Collection, eds. D. Milojicic, F. Douglis, and R. Wheeler, Addison Wesley, 1998. [32] Sun Microsystems—Java HotSpot, http://java.sun.com/ products/hotspot/ [33] ObjectSpace—Voyager, http://www.objectspace.com/voyager/ [34] D.B. Lange and M. Oshima, Programming and Deploying Java Mobile Agents with Aglets, Addison Wesley, 1998. [35] Mitsubishi Electric—Concordia, http://www.concordia. mea.com/ [36] Ad Astra Engineering—Jumping Beans, http://www. jumpingbeans.com

Paolo Bellavista received his Laurea in electronic engineering from University of Bologna, Italy, in 1997. He is currently pursuing a Ph.D. in computer science engineering at the Dept. Electronics Computer Science and Systems of the same university. His research interests include distributed computing, distributed objects, mobile agents, network and systems management, adaptive multimedia systems, and distance learning. He is a student member of the IEEE, ACM and AICA (Italian Association for Computing).


972

Antonio Corradi received his Laurea in electronic engineering from the University of Bologna, Italy, in 1979, and his MS in electrical engineering from Cornell University in 1981. He is currently an associate professor of computer science at the University of Bologna. His scientific interests include distributed systems, object and agent systems, network management, and distributed and parallel architectures. He is a member of the IEEE, ACM and AICA.

Cesare Stefanelli received his Laurea in electronic engineering from the University of Bologna, Italy, in 1992 and the Ph.D. degree in computer science in 1996. He is currently an associate professor of operating systems at the University of Ferrara. His research interests include distributed and mobile computing, mobile code, network and systems management, network security. He is a member of the IEEE and AICA.