Prevenire Attacchi Denial-of-Service in Sistemi adAgenti Mobili: una Soluzione Generale per Piattaforme Java

How to Prevent Denial-of-Service Attacks ofMobile Agents: a Solution for Java-based Platforms

Paolo Bellavista, Antonio Corradi, Silvia Vecchi

Dipartimento di Elettronica Informatica e Sistemistica (DEIS)Università di Bologna

Viale Risorgimento, 2 - 40136 Bologna - ItalyPh.: +39-051-2093001; Fax: +39-051-2093073

E-mail: {pbellavista, acorradi, svecchi}@deis.unibo.it

AbstractLa tecnologia degli agenti mobili ha recentemente mostrato la sua efficacia in diversi domini applicativi, dalsupporto al mobile computing alla gestione integrata di reti, sistemi e servizi. Un problema ancora apertorimane però il controllo e la limitazione dinamica delle operazioni che agenti mobili malprogrammati o malevolipossono compiere sui sistemi ospitanti. È necessario non solo permettere/negare l'accesso di agenti a risorsema anche controllare dinamicamente il consumo di risorse da parte di agenti autorizzati, ad esempio perproteggere le risorse di esecuzione da attacchi denial-of-service. L'articolo presenta una soluzione per ilmonitoraggio distribuito e on-line di agenti mobili basati su Java, capace di fornire informazioni sul loro stato esul loro consumo di risorse, permettendo così di attuare le desiderate politiche di gestione. La soluzione è stataprogettata ed implementata come un componente della piattaforma SOMA e consente la visibilità diinformazioni di monitoraggio a diversi livelli di astrazione. Misure sperimentali su intrusione e tempo di reazionedel componente per il controllo on-line di agenti SOMA dimostra la fattibilità e l'efficacia dell'approccio che hascelto di non modificare la macchina virtuale standard di Java.

The Mobile Agent (MA) technology has already demonstrated its suitability in several application domains, frommobile computing to network, systems and service management. However, a problem that still limits MAdiffusion in commercial environments is how to control and limit dynamically the operations that eithermalicious or badly programmed agents are entitled to perform. It is necessary not only to rule the MA access toresources but also to control resource usage of admitted agents during execution, for instance to protectagainst possible denial-of-service attacks on hosting execution resources. The paper presents an on-linedistributed monitoring tool that gives information about the state of mobile agents and their use of resources,thus permitting to enforce the required management policies on MA resource consumption. The tool is a keycomponent of the Java-based SOMA programming framework and achieves visibility of monitoring informationat different levels of abstraction. The experimental measurements about overhead and reaction time of the on-line control of SOMA agent execution show the feasibility of the approach that does not modify the standardJava Virtual Machine.

1. IntroductionWhile the Mobile Agent (MA) technology has demonstrated its suitability in many application domains andthe number of MA platforms is increasing, there are still a limited number of examples of large-scale MA-based "industrial" services. The main motivation stems from the fact that software companies still do nottrust completely the MA technology because of the potential problems introduced by hosting execution offoreign active entities.

The research has obtained significant results in the MA security area, both in protecting hosting sitesfrom running agents and in defending agents from their current execution environments [Vig 98] [Cor 99].Most MA platforms exploit traditional security techniques to admit/deny the MA access to currently localresources. However, these techniques are not targeted to protect against Denial-of-Service (DoS) attackscaused by mobile agents that engage resources with the effect of making them unavailable for otheractivities. The same applies to the techniques for keeping track of resources in the sense of accountingthem to users for billability sake: this aspect is mostly disregarded by MA frameworks that tend not tosupport tools for the accounting of MA resource consumption to bill agent responsible users.

The confidence in MA systems can only be built by embodying components to support measurement,monitoring and eventual limitation of resource usage of mobile agents while they execute. For instance,even if several agents of the same user are authorized to execute on one host, the local administrator maywant to give a maximum threshold to the total CPU time engaged, in order to preserve CPU availability forother local activities and services. Similarly, once authenticated, an agent may obtain the permission to opennetwork connections toward some specified hosts, but its network usage should be eventually accounted forthe generated amount of traffic.

We claim that agent on-line monitoring is a critical factor for the acceptance and diffusion of the MAtechnology and for the enlargement of the core of MA-based industrial applications. The availability of an on-line monitoring component should be considered crucial for any MA platform, in order to observe thebehavior of mobile agents at runtime and to permit management operations that enforce the requiredpolicies in MA resource usage.

Most recent MA platforms adopt Java as the implementation language because of its obviousadvantages in the MA support (dynamic class loading, serialization, security mechanisms and policies,directly provided as basic facilities of the language environment). However, the Java Virtual Machine (JVM)tends to hide platform-dependent information and becomes an obstacle when dealing with on-linemonitoring. Some extensions of the Java technology can help in overcoming this transparency excess: theJVM Profiler Interface (JVMPI) [SUN 00] exports several JVM internal events for debugging and monitoringpurposes, while the Java Native Interface (JNI) permits to integrate Java programs with platform-dependentexecutable code [Gor 98]. In addition, the Java framework has already faced the necessity of integratingwith components and tools compliant with widespread Internet protocols, such as SNMP [Sta 98], and hasshown its suitability to encapsulate specific aspects of legacy components [Lee 00].

We have designed and implemented a Java-based MA programming environment, called Secure andOpen Mobile Agents (SOMA)* that is a modular and flexible middleware of facilities that support andfacilitate the deployment of MA-based services over the Internet [Bel 00a] [Bel 00b]. The paper focuses onthe description of the SOMA on-line monitoring and control facilities, which are key components to supportthe provision of QoS-aware MA-based services. The monitoring facility obtains and registers indicatorsabout resource usage, both local and remote, of SOMA agents. On the basis of these data, the controlfacility allows SOMA administrators to dynamically specify distributed management policies about agentresource consumption. Management policies include resource usage thresholds and corrective actions

* SOMA is available at http://lia.deis.unibo.it/Research/SOMA/

(agent priority downscaling, suspension and termination) to perform automatically when triggered bythreshold overcoming. The operations of specified mobile agents on available resources can be controlled,and possibly denied, with fine granularity. For instance, in case of locally congested situation, SOMAadministrators can dynamically limit the number of operations available to authorized agents of remoteusers, up to their complete exclusion.

The SOMA monitoring facility exploits JVMPI to collect application-level events produced within the JVM(e.g., object allocation and method invocation). In addition, it employs the JNI technology to make possiblethe integration with platform-dependent native monitoring mechanisms, currently implemented for WindowsNT, Solaris and Linux. The control facility is implemented in terms of SOMA mobile agents that collectdistributed monitoring information. It enforces the specified management policies on agent resourceconsumption by performing corrective actions locally to the network hosts where agents are overcoming theimposed limitations.

The paper reports also experimental results about the overhead and reaction time due to the monitoringand control facilities over the different supported operating systems. The overhead depends mainly on thegranularity of monitoring indicators, on the local/distributed nature of controlled thresholds and on the controlpolling frequency. Measurements show a tradeoff between overhead and reaction time that requires thepossibility for SOMA administrators to tune dynamically the properties of the control tool to service/systemruntime conditions. The performance results show that, not only for MA-based applications but also for awide class of Java-based Internet services, our approach is feasible and effective, without modifying thestandard JVM. We claim that this compliance is a basic requirement for any support infrastructure that aimsat working over global and open distributed environments such as the Internet.

2. Denial-of-Service and Resource AvailabilityAll systems that provide Internet-based services should consider the risk of DoS attacks and organize (atleast partial) solutions to prevent them to ensure service availability. Typical DoS situations happen when aserver is clogged by a flood of requests, or when some requests are too heavy to be scheduled withoutproducing unacceptable delay in service delivery for the other clients. In the latter case, all useful serverresources are deviated to satisfy unauthorized and malicious operations, so to make the server unavailableto meet other more significant and proper operation requests [Gar 00].

The prevention of DoS attacks is even more crucial in systems likely to host execution of externalprograms, such as in MA environments. In MA systems, the advantages of uploading external code todynamically extend and tailor server operations means also to open server execution resources to theaccess of foreign programs. This potential danger is intrinsic not only to MA platforms but also to any systemsupporting code mobility and makes it peculiarly vulnerable to possible misbehavior and DoS attacks. Whilethere is no agreement yet on how to provide complete solutions for DoS prevention, especially in non-traditional mobile-code systems, a widespread guideline is to organize a partial protection based onauthentication and authorization techniques. These techniques permit to associate executing entities withproper permissions, thus defining and enforcing the desired access control policies.

However, traditional authentication/authorization techniques are not enough and do not prevent DoSattacks in MA systems for several reasons. First, they are not viable in all application scenarios. Forinstance, the idea of accepting only trusted external code can represent an intolerable limit to the opennessof highly dynamic systems that should permit limited and controlled resource accessibility even to MAscoming from unknown parties without preventive trust agreement. Then, even in case of a degree of trust

between parties, it is always possible that trusted code incurs in programming errors in the local resourceaccess. Finally, incoming code can maliciously overcome the authentication and authorization steps andoperate on resources that it is erroneously allowed to access. For instance, an authorized mobile agent mayengage intensively and uselessly system resources by executing either an endless loop of objectinstantiations or an endless sequence of migrations to a cyclic list of execution environments.

An alternative guideline to reduce the risks of DoS is a strict control of resource availability, with aprompt feedback that makes possible to take on-line the necessary corrective actions. The distributedmonitoring, control and management of resource availability are complex issues, mainly due to the intrinsicheterogeneity of open distributed systems and to the tendency of adopting abstraction perspectives that hidethe visibility of operating system internals. Recent years have shown the relevance of programmingapproaches that minimize the costs of portability over heterogeneous platforms: apart from the diffusion ofscripting languages, JVM is the most spread example of this tendency that prefers portability and class-loading dynamicity to execution efficiency and performance [Lee 00].

Java plays nowadays a central role in the development and deployment of Internet-based services. TheJVM support to code mobility directly at the language level (think to the case of Java applets and theirdynamic downloading into JVMs embedded in Web browsers) forced SUN developers to deal with relatedsecurity issues. As a consequence, the Java programming platform provides security mechanisms and toolssuitable to control Java resource access. The Java Security Manager (SM) permits to dynamicallyadmit/deny resource access to Java classes via the definition of specific security permissions policies. In itsdefault flavor, SM is as a basic component of the Java environment; service developers and administratorscan also program their SM by sub-classing and tailoring the basic one in response to system/application-specific requirements. By exploiting SM and the possibility to specify permissions and policies, a Javasystem administrator can decide “who” is granted access to, “which resources” is allowed to use, and “how”to act upon them, in the sense of which methods can be used.

However, it is not possible to express “how much” in a more quantitative way, i.e., to fix and control thatspecified limits on resource usage are not exceeded. In other words, there is no idea of ruling resourceusage in terms of maximum quotas assigned to specified and authorized entities. For instance, a Javasecurity policy can permit the invocation of the write() method of the DatagramSocket class bymobile agents that are instances of authorized classes coming from recognized responsible users. The Javasecurity mechanisms, policies and tools, however, cannot monitor and control resource consumption ofauthorized entities during execution, e.g., by imposing that a specified mobile agent do not produce morethan a specified amount of outgoing network traffic.

In one sentence, we claim that a general protection against DoS attacks (and also against unpredictableprogramming errors) requires the support for on-line monitoring and control of resource availability. In allcases when this possibility is not already given, it is necessary to design and implement middleware toolscapable of on-line observation of resource consumption, even in systems where this information is typicallyhidden by high levels of abstraction. In addition, these support tools should be able to control resourceconsumption during execution and, whenever specified thresholds are exceeded, to exclude unwantedresource occupation by performing management operations over malicious or badly programmed authorizedentities.

3. The SOMA Middleware for Internet ServicesThe provision of mechanisms and tools to protect hosting execution resources by possible denial-of-serviceattacks of either malicious or badly programmed agents is crucial to increase the confidence and diffusion ofthe MA technology. Most recent MA platforms are Java-based and the Java programming environmentalready provides several mechanisms and tools to deal with dynamic class loading, authentication andaccess control. However, we have already argued that this is not enough to prevent from excessiveresource consumption of hosted mobile agents.

This is the reason why we have worked on the development of mechanisms, policies and tools for thecontrol of distributed Java-based mobile agents during execution. Our approach has a general applicability,not only to other MA platforms implemented in Java, but also to Java-based distributed applications wheresystem administrators should control and rule dynamically the amount of executing resources consumed.

We have designed and implemented the SOMA platform as a modular and flexible MA DistributedProcessing Environment (DPE) intended as a middleware of two facility layers (see Figure 1). The LowerLayer of Facilities (LLF) provides the basic functionality for SOMA agents:• the naming facility. It maintains and permits to access the information about the current state of any

(possibly mobile) entity. A basic identification mechanism dynamically tags any entity in the system(agents, resources, service components and principals, i.e. users/organizations responsible for agentexecution) with globally unique identifiers that do not change even after entity migration. On this basis,the SOMA naming service puts together LDAP-compliant and discovery-based solutions [Bel 01a].

• The communication facility. It provides tools for communication and coordination between possiblymobile entities. When hosted in the same execution locality, agents interact via shared objects, such asblackboards and tuple spaces for tight cooperation [Cab 00]. Otherwise, agents can exchangeasynchronous messages delivered also in case of migration of the target entity.

• The migration facility. It supports the transport of one entity that requests to change its allocation.Entities capable of reallocation are represented by agents, which can move in the network either viaSOMA native migration methods or via standard interfaces such as the OMG Mobile Agent SystemsInteroperability Facility (MASIF) [MAS 98];

• The monitoring facility. It is in charge of observing resource properties, from disk free space toeffectively available network bandwidth, from CPU usage to heap memory allocated by any agentthread. This is achieved by enlarging the JVM visibility of kernel and application state via the integrationwith JVMPI [SUN 00] and with platform-dependent monitoring modules via JNI [Gor 98]. Details aboutthe monitoring facility are given in the following.

Upon this basic layer of middleware facilities, SOMA offers an Upper Layer of Facilities (ULF):• the interoperability facility. It allows SOMA agents to interwork with existing software and hardware

components via compliance with CORBA [Bel 01b]. SOMA implements the MASIF interface to enablethe interaction of its agents with other MASIF-compliant MA platforms, and the Agent CommunicationChannel to support interoperable communication of SOMA agents with entities of (either mobile or not)agent platforms that can understand the Agent Communication Language specified in FIPA [FIP 00].

• The security facility. It aims to protect both mobile agents and hosting execution localities.Authentication is based on standard certificates and on the Entrust public key infrastructure.Authorization extends the Java standard mechanisms for access control. Secrecy is achieved byintegrating the cryptographic libraries furnished by external providers. Integrity has required thedevelopment of MA-specific protocols for the protection of mobile agents from the execution environment[Cor 99]. Denial-of-service protection is considered a particular case of on-line QoS control and is incharge of the QoS facility introduced below.

Other DPE CORBA DPE

SOMA LLF

Namin

gCom

mun

ic.M

igra

tion

NetworkElement

Layer

ServiceLayer

MiddlewareLayer

Mon

itorin

gSOMA ULF

Inter

oper

ab.

Secur

ity

QoS

SOMA-based Applications

Network, Systems &Service Management

MobileComputing

MultimediaDistribution

Figure 1. The SOMA layered architecture of middleware facilities.

• The QoS facility. It exploits the data collected and registered by the monitoring facility for the control,adaptation and accounting of distributed operations performed by SOMA agents. Monitoring data areused on-line to control the respect of resource consumption thresholds imposed to SOMA agents (asdescribed in the following) and to adapt QoS-aware services to the current availability of networkresources, e.g., by down-scaling multimedia streams in case of network bandwidth degradation [Bel00b]. The same monitoring data are processed and filtered off-line to compile log files suitable foraccounting of agent resource consumption. The security facility is in charge of the non-repudiableassociation of agent consumes with responsible users.

In addition to provide this service infrastructure for mobile agents, SOMA offers locality abstractions todescribe any kind of interconnected system, ranging from simple Intranet LANs to the Internet. Any nodehosts at least one place for agent execution; several places are grouped into domain abstractions thatcorrespond to network localities. In each domain, a default place is in charge of inter-domain routingfunctionality and integration with legacy components via CORBA.

The mobile place is the locality abstraction used to support mobile devices: it enhances the normal placewith specific features for automatic reconfiguration when changing domain of attachment [Bel 01a].Other details about the SOMA programming framework are presented elsewhere [Bel 00a] [Bel 00b] and areout of the scope of this paper that, in the following, specifically focuses on the exploitation of the monitoringand QoS facilities for denial-of-service protection.

4. Resource Management in SOMASOMA provides a Resource Management (RM) component to monitor, account and control the amount ofresources used by SOMA mobile agents. RM is based on a resource management infrastructure thatrealizes both local and distributed monitoring and allows performing some control actions on SOMA agentsduring execution. A local manager called Place Resource Manager (PRM) inspects the behavior of agentsrunning on a single SOMA place with the goals of charging for used resources and of performing automaticcorrective actions to enforce locally imposed resource limits. The RM distributed monitoring is based on ad-hoc SOMA agents that move among the places to gather local information from PRMs; on the basis of thisinformation, RM enforces global policies about agent resource consumption.

4.1. The RM ArchitecturePRM is a SOMA stationary agent that provides monitoring and controlling functionality, by implementingmethods to get monitoring data, e.g., CPU effective time and memory occupation of specified SOMA agents,and to set management parameters, e.g., the polling frequency of controls and the values of consumptionthresholds.

The PRM consists of two main components (see Figure 2):• the local monitoring component, in its turn composed by the JVM Monitor (JM) and the Operating

System Monitor (OSM), which collect, respectively, monitoring indicators about Java threads and aboutlocal resources at the system level, such as CPU, memory, file system and network;

• the Local Monitoring Manager (LMM) component, which reads, filters and processes monitoringinformation in order to trigger promptly corrective management actions on agents in case of resourcemisuse.

By exploiting the local function provided by PRMs at any place, RM achieves distributed monitoring/controlof agent resource consumption via Collection mobile agents and performs distributed correctivemanagement via Action mobile agents, as described in Section 4.4.

4.2. Local MonitoringThe local monitoring component consists of two different modules in charge of observing two different typesof resources. JM collects information about all resources at the language level accessed from within theJVM. For any active Java thread on the local JVM, it provides lifetime, number of loaded classes and usedmonitors, number and size of allocated objects, number of TCP/UDP and file read/write operations. Inaddition, it provides also the reference to (and the monitoring information about) the belonging thread group;this information is necessary to operate on SOMA agents that can consist of either one or more Javathreads anyhow belonging to the same group.

OSM gets system-level information on all processes running on the host and on the usage of thecommunication infrastructure. For any process, it is possible to observe process identifier and name, CPUusage (time and percentage, both of the process and of its composing threads) and allocated memory(physical and virtual). The network information includes the total number of sent/received UDP packets, ofTCP connections and sent/received segments, and of TCP/UDP packets received with errors.

The monitoring information provided by JM is exploited to account and control SOMA agents for theirusage of language-level resources. This knowledge can also permit to ascertain approximately the usage ofsome system resources, e.g., through JVMPI-based observation of TCP/UDP read/write operations one caninfer information about bandwidth usage [Bel 00c]. However, some fundamental information is missing fromJVM monitoring, such as CPU usage time and percentage. Only joint monitoring operations of JM and OSmodules can obtain a complete figure, to protect any SOMA place from potentially dangerous DoSconditions. Let us finally note that both JVM and system-level monitoring information is updated continuouslybecause JM and OS modules are continuously notified by events triggered respectively by JVMPI and nativemonitoring libraries [Bel 00c].

4.3. Local ManagementLMM is the module on any SOMA place that coordinates monitoring, controlling and corrective operations. Itexecutes a loop consisting of three main phases.

Figure 2. The RM architecture for local and distributed MA DoS prevention.

Firstly, it reads the concise monitoring indicators provided by the local monitoring component according tothe LMM current configuration. For instance, from the whole JVM monitoring information, LMM can receiveonly pre-processed and filtered monitoring information such as the number and size of objects allocated bythe SOMA agents of a specified responsible user. While the monitoring information described in the previoussection is updated continuously, LMM samples the concise indicators of interest depending on a pollingfrequency parameter. This frequency can be changed dynamically depending on application/system-specificrequirements and impacts significantly on the performance of the SOMA tool for DoS prevention (seeSection 5).

Secondly, it records monitoring indicators by associating Java threads with SOMA agents and SOMAagents in their turn with responsible users by exploiting SOMA security mechanisms and tools [Bel 00b].This is the basis to attribute resource usage in a non-repudiable way and to charge responsible users.

Lastly, it verifies whether the monitoring indicators in the last polling interval have exceeded the specifiedthresholds on agent resource consumption. In this case, LMM operates on agents overcoming thresholdswith different level of corrective recovery actions. It can suspend the specified agents, lower their priorityand, in the worst case, kill them. In addition, the corrective operation can also depend on the agent (and itsprincipal) previous history.

LMM can be configured to automatically update the polling frequency to reduce the overhead in case ofregular conditions and to observe more closely the system in critical conditions. If during the last threecycles there has been no alarms on the place, the polling frequency is gradually decreased; if a thresholdovercoming alarm is detected it is increased.

4.4. Distributed Monitoring and ManagementThe distributed resource management is a more coordinated task and may require the cooperation ofseveral different local PRMs. We have adopted a design guideline obvious in an MA environment: wheneverseveral PRMs are involved, their coordination is achieved by means of mobile agents in charge of providingeach PRM the needed common information and of transporting actions to be done. In particular, we havedeployed two specialized mobile agents, Collection MAs (CMAs) and Action MAs (AMAs). CMAs areresponsible for moving around to propagate monitoring and resource information; AMAs are in charge of

transporting all management information, and more specifically, the requested operations to be eventuallyperformed in case of problems. Let us note that the choice of employing mobile agents is significant in thiscase: in fact, both types of agents are capable of transporting (and installing) new management code insome target nodes, instead of moving only predefined and agreed upon values.

Consider the DoS prevention issue in a distributed perspective. If the local PRM has the goal of takingcare of local resources, and consequently of their usage by currently local agents, the MA infrastructure hasthe goal of permitting distributed operations:• related to resource consumption of one specific agent that may have a maximum threshold in its

lifetime. When arriving at a new node, the agent remaining quota has to be verified before let it enter;• related to resource usage of a specified user, responsible for several concurrent mobile agents. Let us

note that the MA infrastructure is analogous to this case;• related to different resources concurrently, such as when we want to limit the contemporaneous access

to different and distributed resources. These access patterns are more difficult to be granted becausethey tend to require also prompt propagation. We may require, for instance, that all agents of aspecified user are not concurrently accessing more than 3 database objects in different places.

CMAs are the agents devoted to visit different places to collect local information with the goal of building adistributed perspective. For instance, specific CMAs can be activated by a query about the CPU usage of auser. One or more CMAs can go around at specified times to yield back the CPU employed up to now so tobill for user resource usage. Another CMA utilization is to monitor a shared resource, such as bandwidth:CMAs can observe how its allocation is distributed among the places of a SOMA domain, to take possibleload balancing actions. AMAs are the agents interested in management operations to be propagated todifferent PRMs to impose and trigger control actions. They can be carrier of simple variations of a previousconsumption threshold (by transporting a new value), but can also migrate by carrying an action code, suchas a new management operation to execute when exceeding a specified threshold. This adds flexibility anddynamicity to the entire system: when the AMA arrives at a site (and if it is authorized to do so), it makes asubstitution of a previously imposed policy, without any need of restarting or blocking the provided services.

Figure 3. Some GUIs presenting monitoring information collected by the local MM.

Let us note that more complex cases can be thought: AMAs that can launch CMAs to obtain a moreglobal scope of information, and so on. However, we have decided to limit operations to the ones whereefficiency can be reasonably expected, in order to leverage usability and effective deployment of the SOMAtool for DoS prevention.

SOMA administrators can configure and control RM operations via several graphical user interfaces(GUIs) with Web accessibility. In particular, Figure 3 shows GUIs that visualize monitoring information(about SOMA agents, system processes and network traffic) and alarm information (number of alarms andresponsible agents) and that allow the setting of consumption thresholds and of polling frequency.

5. Experimental ResultsThe DoS prevention in SOMA starts with the monitoring of agent resource consumption during execution tobuild the on-line control that current consumption is compatible with established thresholds, and, if neededto perform management operations (from corrections to total block) on agents overcoming imposed quotas.The feasibility and effectiveness of a distributed tool for DoS prevention can be evaluated in terms of itsoverhead and reaction time. The overhead is expressed as [Ton-Toff]/Toff, where Ton and Toff are the averagecompletion times of a Java benchmark respectively with DoS prevention enabled/disabled. The reaction timeis the interval between threshold overcoming and starting of recovery actions. To validate the applicability ofour approach that maintain the standard JVM, we have thoroughly measured overhead and reaction time forseveral different platforms, e.g., Intel PentiumII 600MHz PCs with either Microsoft Windows NT 4.0 or SuSELinux 7.1, and SUN Ultra5 400MHz workstations with Solaris 7. The hosts are interconnected via 10 MbpsEthernet local area networks.

The total overhead and reaction time of DoS prevention in SOMA depend on the composition ofmonitoring, control and management. With regards to the collection of monitoring data, we haveexperimented a very limited overhead, negligible for most classes of Internet-based services. This stemsfrom the minimum intrusion of both JVMPI notifications and native monitoring mechanisms: for a detailedpresentation and discussion of these results see [Bel 00c].

Different is the overhead of the controlling functionality that is not negligible and depends on severalfactors: polling frequency of monitoring indicators, number and type of local/distributed thresholds, andnumber of SOMA agents in the system. Figure 4 reports the experimental overhead of the SOMA tool forDoS prevention with polling frequencies from 0.1 to 1 Hz and with 2 to 10 mobile agents per placecontemporarily overcoming the imposed thresholds. In this value range typical of most MA-based Internetservices, the overhead of DoS prevention is always lower than 15% when there are no more than 2 mobileagents triggering corrective operations at the same time. This is not an intrusion to be neglected but it canbe considered acceptable in any distributed application where service temporary/permanent unavailability ismore relevant an issue than this degree of resource consumption and performance degradation. In addition,experimental results show that the overhead is linearly dependent on the polling frequency. This permits tosignificantly reduce the overhead in most cases of distributed services/systems that do not require morethan 2 controls/second. Figure 4 reports the measurements executed on Windows platforms; analogousresults, with the same trends, have been experimented also on Linux and Solaris platforms.

Figure 4. Experimental results about the overhead of the SOMA tool for DoS prevention.

Let us analyze the results about reaction time. When dealing with thresholds within a local scope, i.e.,involving resources and SOMA agents resident at a single place, the corrective management interventioncan be triggered immediately after the threshold control: in the worst case, the reaction time is about 2 timesthe reciprocal of the polling frequency. When the frequency of controls increases, the reaction timedecreases but conversely the overhead increases too. This is the reason why SOMA administrators shouldwork on tuning the polling frequency depending on system/application-specific scenarios. For instance, incase of MA-based multimedia services with real-time constraints, it is necessary to have high pollingfrequencies to permit prompt corrective operations within the constraints of maximum delay, jitter andbandwidth. Any distributed system providing multimedia services should take into account also the loss ofperformance due to the overhead at high polling frequencies. In case of MA-based services without strictreal-time constraints, such as in asynchronous distributed information retrieval whose main goal is serviceavailability, the minimization of reaction time can be relaxed, thus reducing the imposed overhead.

The MA-based control of distributed thresholds has exhibited a linear dependency on the number ofplaces hosting resources and of agents involved in the observed thresholds. So, too complex thresholdsspanning over too large sets of execution environments should be avoided when we need a low reactiontime. The locality of a single SOMA domain is usually the most suitable one for the definition and control ofagent resource consumption quotas and permits to obtain a reaction time acceptable for most MA-basedInternet services.

6. ConclusionsOur first results in monitoring, controlling and possibly limiting resource consumption of SOMA agents haveshown, on the one hand, the feasibility of Java-based on-line monitoring, and, on the other hand, thenecessity of the dynamic tuning of the monitoring overhead by adjusting the polling frequency toapplication/system-specific requirements. In normal working conditions, all tests indicate that DoSprevention in SOMA produces a very limited overhead and achieves an acceptable reaction time when thepolling frequency goes under 0.5 Hz.

Notwithstanding the encouraging results obtained, there is much work still to be done toward a completeand flexible control of SOMA agent resource consumption. Apart from the performance improvement by

adopting different filtering strategies to maintain only the monitoring indicators currently of interest, we intendto work on:� extending the distributed monitoring and control of SOMA agents to permit the accounting and billing of

registered SOMA users for the effective resource usage of their agents. Accounting and billing canexploit the large set of monitoring information provided by the monitoring facility at runtime, but do notrequire the evaluation and processing of monitoring data on-line. This suggests differentiated strategiesfor data collection, with possibly significant overhead reductions;

� implementing agent prototypes in charge of negotiating the quality of the execution resources offered bythe hosting environment before migration. Obviously, it will be possible to extend these prototypes viasub-classing for rapid development of new MA components, thus accelerating the deployment of specificInternet services with QoS requirements.

AcknowledgementsWork supported by the Italian MURST in the framework of the Project "MUSIQUE: QoS Infrastructure for Web-basedMultimedia Services with Heterogeneous Accessibility" and by the University of Bologna Funds for Selected ResearchTopics "An Integrated Infrastructure to Support Secure Services".

References[Bel 00a] P. Bellavista, A. Corradi and C. Stefanelli, "Protection and Interoperability for Mobile Agents: A Secure and

Open Programming Environment", IEICE Transactions on Communications, Vol. E83-B, No. 5, May 2000.[Bel 00b] P. Bellavista, A. Corradi and C. Stefanelli, "An Integrated Management Environment for Network

Resources and Services", IEEE Journal on Selected Areas in Communication, Vol. 18, No. 5, May 2000.[Bel 00c] P. Bellavista, A. Corradi and C. Stefanelli, "Monitor and Control of Mobile Agent Applications”, ACM

OOPSLA Workshop on Experiences with Autonomous Mobile Objects and Agent Based Systems,Minneapolis, USA, Oct. 2000.

[Bel 01a] P. Bellavista, A. Corradi and C. Stefanelli, "Mobile Agent Middleware for Mobile Computing", IEEEComputer, Vol. 34, No. 3, Mar. 2001.

[Bel 01b] P. Bellavista, A. Corradi and C. Stefanelli, "Middleware Services for Interoperability in Open Mobile AgentSystems", Microprocessors and Microsystems, Elsevier Science, Vol. 25, No. 2, May 2001.

[Cab 00] G. Cabri, L. Leonardi, and F. Zambonelli, "Mobile-agent Coordination Models for Internet Applications",IEEE Computer, Vol. 33, No. 2, Feb. 2000.

[Cor 99] A. Corradi, M. Cremonini, R. Montanari and C. Stefanelli, "Mobile Agents Integrity for Electronic CommerceApplications", Information Systems, Elsevier, Vol. 24, No. 6, 1999.

[FIP 00] Foundation for Intelligent Physical Agents – FIPA 2000 Specifications, http://www.fipa.org/.[Gar 00] L. Garber, "Denial-of-service Attacks Rip the Internet", IEEE Computer, Vol. 33, No. 4, Apr. 2000.[Gor 98] R. Gordon, Essential Java Native Interface, Prentice Hall, 1998.[Lee 00] J. Lee, "Enabling Network Management Using Java Technologies", IEEE Communications, Vol. 38, No. 1,

Jan. 2000.[MAS 98] 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/98-03-09,ftp://ftp.omg.org/pub/docs/orbos/98-03-09.pdf, Sep. 1998.

[Sta 98] W. Stallings, SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, Addison Wesley, 1998.[SUN 00] Sun Microsystems - Java Virtual Machine Profiler Interface (JVMPI), http://java.sun.com/

products/jdk/1.3/docs/guide/jvmpi/jvmpi.html.[Vig 98] G. Vigna (ed.), Mobile Agents and Security, Lecture Notes in Computer Science, Vol. 1419, Springer

Verlag, 1998.