Access-Controlled Resource Discovery for Pervasive Networks

Sanjay Raman, Dwaine Clarke, Matt Burnside, Srinivas Devadas, Ronald RivestMIT Laboratory for Computer Science

{sraman, declarke, event, devadas, rivest}@mit.edu

Abstract

Networks of the future will be characterized by a va-riety of computational devices that display a levelof dynamism not seen in traditional wired networks.Because of the dynamic nature of these networks, re-source discovery is one of the fundamental problemsthat must be faced. While resource discovery sys-tems are not a novel concept, securing these systemsin an efficient and scalable way is challenging. Thispaper describes the design and implementation of anarchitecture for access-controlled resource discovery.This system achieves this goal by integrating accesscontrol with the Intentional Naming System (INS), aresource discovery and service location system. Theintegration is scalable, efficient, and fits well within aproxy-based security framework designed for dynamicnetworks. We provide performance experiments thatshow how our solution outperforms existing schemes.The result is a system that provides secure, access-controlled resource discovery that can scale to largenumbers of resources and users.

1 Introduction

Resource discovery is one of the fundamental chal-lenges that must be faced in the context of pervasivecomputing. Simply stated, the goal of resource dis-covery is to provide a user with a snapshot of thecomputational environment in which he is operat-ing. Resource discovery is vital to enabling operationin pervasive networks as the network state is unpre-dictable. The dynamism of pervasive networks alsobrings rise to problems of security. Although oftenoverlooked, security is a critical component necessaryfor the practical realization of pervasive computing.As a resource provider, we want to guarantee that for-eign users that enter our environment will not be ableto act maliciously. Similarly, as a user in a foreign en-vironment, we want to know what resources we areable to use and which ones we can trust. Such accessrestrictions are easily handled in fixed networks asforeign users can simply be denied admission to the

network. But the fundamental notion behind per-vasive computing gives rise to the idea of resourcesand users of varying privileges interacting in the sameenvironment. Further complicating the issue is thatpervasive computing environments handle a diverseand heterogeneous set of users and resources [2], in-cluding computationally-limited devices, so it is im-portant to enforce a security framework that can beextended to many disparate resources. Communica-tion channels must be secure and access control mustbe granted to resources in order to regulate usage.While several systems [7, 15, 9] propose resource dis-covery solutions for dynamic environments, they donot consider how the integration of security protocolsinfluences scalability and performance.

Resource discovery systems are typically imple-mented in the network layer, below security, allow-ing networks to overlay any desired security proto-col. An access control framework can be layered overa resource discovery protocol, but these two proto-cols seem to have different goals. The goal of a re-source discovery system is to find the resource or ser-vice that best matches the criteria for which a user islooking. On the other hand, a security protocol thatenforces access control is concerned primarily withallowing users to perform authorized operations onprotected resources. The problem is that the bestcriteria-matching resource (e.g. “the nearest, least-loaded printer”) may not necessarily be a resource towhich a user has access.

The primary focus of this paper is to address theissue of resource discovery in a pervasive computingenvironment. More specifically, this paper presentsa system that integrates access control with resourcediscovery in order to enable scalable and efficient op-eration. This paper describes a resource discoverysystem that is scalable and efficient and is designedto elegantly integrate with a proxy-based security sys-tem [4].

The proxy-based security system uses a dis-tributed SPKI/SDSI protocol [13] which allows forprivate, encrypted communication between heteroge-neous lightweight devices in a pervasive computing

1

environment.The architecture presented in this paper makes four

key contributions:

• A scalable model for resource discovery basedon the Intentional Naming System [1] that in-tegrates access-control information with serviceinformation.

• Integration of access-controlled resource discov-ery with a proxy-based security infrastructure toprovide secure and authentic communication ina pervasive computing environment.

• Implementation of a resource lookup algorithmthat makes access control decisions while findingthe best resource.

• Design of lightweight, high-performing accesscontrol lists.

In the remainder of this section, we briefly out-line the proxy-based security architecture that is abasis for our system. We summarize the resource dis-covery problem in terms of a simple scenario in Sec-tion 2. Section 3 details our system architecture anddescribes how we have developed an access-controlledresource discovery system. We present the advan-tages and performance evaluation of our system inSection 4. We discuss some related systems in Sec-tion 5 and conclude the paper in Section 6.

1.1 Background

The resource discovery system presented here is de-signed to be an integral part of a larger proxy-basedsecurity architecture [4]. Resources are defined tobe any piece of hardware or software that is provid-ing a service to members of the network. A resourcemay be location-aware. In this architecture, each re-source has an associated trusted software proxy. Aproxy is software that runs on a network-visible com-puter and its primary function is to execute com-mands on behalf of the resource it represents. Prox-ies store certificates and other information for theresource they represent and are trusted implicitly.Proxies communicate with each other using a pro-tocol based on SPKI/SDSI (proxy-proxy protocol).A separate resource-proxy protocol is used for se-cure communication between resources and proxies.Having two different protocols allows us to run acomputationally-inexpensive security protocol on im-poverished resources and a sophisticated protocol forresource authorization on more powerful resources.Figure 1 shows an overview of this system and theprotocols it uses.

Proxy−Proxy

Resource Resource

Proxy

ProxyProxy

Resource−ProxyProtocol

ProtocolResource−Proxy

Device

Proxy Farm

Resource Network

Protocol

Figure 1: An overview of the basic components in theproxy-based security infrastructure. Proxies communi-cate via the proxy-proxy protocol. Devices and resourcescommunicate with proxies via the resource-proxy proto-col.

The proxy-proxy protocol layers SPKI/SDSI accesscontrol over an application protocol, which in turn islayered over a key-exchange protocol. This allows usto deal with a variety of application protocols thatmay be implemented across wired or wireless linksin a heterogeneous network. SPKI/SDSI features anelegant model for access control lists (ACLs) and del-egation of authority.

2 The Problem Restated

The problem that the system in this paper solves isthat of how to scale a system of resources that areprotected by access control. It is tremendously in-efficient if a user repeatedly attempts to contact aresource that he is prohibited from using. One onlyhas to consider an environment with a large numberof protected resources. If a user has no knowledgeof which resources he can access, it could take anexhaustive computational effort to find an accessibleresource. In order to gain scalability and efficiency,the resource discovery system needs to know aboutaccess control privileges so that it can return the bestresource to which a user has access. By knowing theuser’s authorizations (i.e., the groups to which he hasmembership) and the access control lists of the sup-ported resources, a resource discovery system can ef-fectively meet this goal.

2.1 A Simple Scenario

This issue is especially pertinent when dealing withnetworks where the state of the network is highly dy-namic. It is very plausible that a user will not know

2

Proxy Network

managersAK

Edward

developersBK

KA managers

KB developersdevelopersBK

managersAK

schedule.doc schedule.doc

schedule.doc

schedule.doc

schedule.doc

schedule.doc

Proxy

Proxy

Proxy

Proxy

ProxyProxy

?

?

Figure 2: This figure illustrates the conflict experiencedby a resource discovery system in an access-controlled en-vironment. How does Edward find the closest, accessiblecopy of schedule.doc without performing an exhaustivesearch?

exactly what resources are available, nor will the userknow which he is authorized to use. As a simple ex-ample, consider an environment which treats all de-vices in the network as resources in a peer-to-peer ap-plication. Figure 2 illustrates the following scenario:

Edward, a manager at a large software firm,arrives in the morning at a conference withhis location-aware device. Upon arrivingand coming online, Edward wants to down-load his personalized conference schedule forthe given day. At this conference, thereare two tracks: one for managers and onefor software developers. Thus, the users inthe system are divided into two groups, KA

managers and KB developers. All theusers already at the conference have a doc-ument, schedule.doc, in their repository,but the document is track-specific. Thatis, the copy of schedule.doc that mem-bers of KA managers have is different thanthe copy that members of KB developershave. When Edward comes online, he wantsto synchronize his copy of schedule.doc bygetting the latest version. The conferenceis spread out over several buildings and theusers are spatially far apart. Because thephysical area of the conference is large, thereis no central repository for the schedules.Instead, schedule distribution and synchro-nization happen peer-to-peer. As a memberof KA managers, Edward must get the doc-ument from another member of his group.

Members of KA managers do not have ac-cess to the schedules of members of KB

developers, and vice versa. Edward wouldalso like to get the schedule from the ge-ographically closest user, in order to mini-mize his delay and make the synchronizationprocess as fast as possible.

2.2 Problems

This scenario creates a conflict of interests. Not onlymust Edward find the closest user, but he must alsofind a user that is in his group (a resource to whichhe has access). A simple resource discovery systemcould easily tell Edward the location and identityof the closest user. This problem has been solvedmany different ways [1, 16, 11]. But, how does Ed-ward know if the physically-closest user is a mem-ber of his group? And, if this user is not a memberof his group, where exactly is the closest member ofEdward’s group? Mobility of the users only furthercomplicates the issue. It would be time consumingand inefficient for Edward to blindly search for theclosest member of his group. The only way in whicha resource discovery system can identify the closest,accessible resource is to know ahead of time Edward’sidentity and authorizations.

2.3 A Naıve Solution

Before presenting our solution, it is instructive tooutline a naıve solution. This solution will be usedas a baseline of comparison in terms of performanceand will be important for the analysis of Section 4.Resource discovery systems that do not incorporatethe ideas presented in this paper will typically oper-ate by returning the address(es) of the best criteria-matching resource. It will become clear that issuesof scalability and efficiency are major obstacles withsuch a system.

In attempting to discover the geographically-closest user, Edward will query the resource discoverysystem through his personal proxy. The proxy willtell the resource discovery system to “find me theclosest user”. Ideally, Edward would like to contactthe closest, accessible user, but this resource discov-ery system does not know anything about Edward’sidentity or authorizations. In response to the query,the resource discovery system will return a list of thegeographically-closest users to Edward’s proxy. Atthis point, Edward’s proxy does not know which ofthe resources in the list are accessible to him. Theonly reasonable way for the proxy to proceed is tosequentially iterate through the resources in the list

3

in the hope that they are accessible. The proxy mustengage in some sort of authorization check in orderto determine if the user has access to the resource.As long as a contacted resource fails, the proxy willhave to repeat the process.

This approach can be inefficient and surely is notscalable. If a given user has access to every resourcein the network, then the efficiency of access controlis not an issue. But, in most heterogeneous environ-ments, users are assumed to be diverse and accessprivileges will exhibit the same differences. In Ed-ward’s scenario, if he is not close to any users of hisgroup, he would have to iterate through many inac-cessible resources before finally finding a match. Ed-ward is faced with executing a process on the orderof O(n) if there are n other resources in the network.The results of Section 4 will illustrate this point.

3 System Architecture

A better approach would be to give the resource dis-covery system knowledge about the access controllists that protect the resources. We require that thedesigned system be secure, efficient, scalable, and ro-bust. In order to meet our goals, the IntentionalNaming System (INS) [1] was selected. The solutionpresented here uses several modifications to inten-tional naming that enables access control decisionsto be made while finding the best resource. Beforedetailing our solution, we summarize INS as a stan-dalone resource discovery system.

3.1 Intentional Naming Overview

Intentional Naming System (INS) is a resource dis-covery and service location system intended for dy-namic networks. INS is ideal for dynamic networksbecause an application only needs to tell the servicethe resource characteristics it is seeking. Since theavailability of resources may be dynamic, these sys-tems require a naming service that is just as flexi-ble. The Domain Naming Service (DNS) works wellfor static networks since an application can be fairlyconfident in the names of resources. INS providesusers with a layer of abstraction so that applicationsdo not need to know the availability or exact nameof the resource for which they are looking. A sim-ple example of a user’s request in INS is to find thenearest, least-loaded printer. DNS would require theuser to know the exact name of the resource, such aspulp.lcs.mit.edu.

INS uses a simple language based on expressionscalled name specifiers, which are composed of anattribute and value. An attribute is simply a

possible values

RAME N

226

room

building

memoryavailable−

56mb480640x87%

resolutionbattery−life

second (2)

floorfloor

lcs

600x80050%fourth (4)

bldg−34ai−lab

128mb 5:16

duration

printer under−repaironline idle

availabilityorthogonal attributes

service

root

camera

ECORD

Figure 3: A graphical view of an example INS name-tree.The name-tree consists of alternating layers of attribute-nodes, which contain attributes and value-nodes (possiblevalues). Value-nodes contain pointers to all the namerecords they correspond to. The bold region shows anexample name-specifier.

category by which a resource can be classified.For example, a camera in the system can be de-scribed by its resolution, battery-life, and/oravailable-memory. An INS name, or intentionalname, is a hierarchy of these atomic name specifiers.An example of an INS name is [service=camera[resolution=640x480] [battery-life=87%][available-memory=56mb]] to describe a camerawith the specified properties.

INS is comprised of a network of Intentional NameResolvers (INRs) that serve client requests for re-sources and maintain information about the search-able metatdata of each resource. Data is representedin the form of a dynamic name-tree, which is a datastructure used to store the correspondence betweenname specifiers and the destination resource. Thestructure of a name-tree strongly resembles the hi-erarchy of a name specifier. Name-trees consist ofalternating levels of attributes and values, with mul-tiple values possible at each attribute. A particu-lar name specifier is resolved by traversing the tree,making sure to visit all the corresponding attribute-value pairs of the target resource. Each leaf value inthe name-tree has a pointer to a name-record, whichholds the physical location of the resource. Figure 3illustrates an example name-tree.

3.2 Security Integration with INS

The solution presented here uses several modifica-tions to intentional naming that enable access controldecisions to be made while finding the best resource.While INS does allow for a security framework to belayered over it, we have already seen how a system can

4

benefit from integrating access control decisions withresource discovery. INS is extended in the followingthree ways to provide access-controlled resource dis-covery:

1. implementation of a real-time maintenance ofthe access control lists in the INS name resolvers,

2. introduction of a certificate-based authorizationstep during resolution of an INS request, and

3. design of a lookup algorithm that prunes thepossible name records by eliminating resourcesbased on a user’s identity and authorizations.

In the following sections, the key extensions of INSare presented. Finally, we will return to the scenariothat is discussed above to see how this new systemintegrates access-control information and INS knowl-edge to efficiently return the best, accessible resource.Another key factor influencing this design was its in-clusion as a small piece of a larger security infras-tructure. Therefore, some of the components of thisdesign were chosen to leverage the existing function-ality of the proxy-based security system [4].

3.2.1 Storage of ACLs in INS

Assuming that resources have the ability to informINS of the access control lists that protect them, howcan these lists be properly stored in the INS knowl-edge base so that they can be referenced when mak-ing resource decisions? INS uses a name-tree to storeits knowledge about resources in the system. Name-trees are dynamic, changing their structure based onhow resources advertise and re-advertise themselvesto INS.

An access control list is treated as an additionalattribute that defines a resource. One can specifya camera based on its resolution, say; similarly,an access control list is just another way to classifythe camera. In order to store ACLs as attribute-value pairs, a new type of attribute was introduced.Previously, all attributes were treated as searchable,in that they were used as a dimension along whicha resource can be explicitly queried. But, when auser makes a request for a resource, the user cannotspecify the ACL attribute-value pair in the query.Nor do we want the ACLs being represented as ad-ditional branches in the name-tree. So, in order tostore ACLs, the concept of a hidden attribute wasdefined. INS attributes are now defined as search-able or hidden, with the only hidden attribute beingthat of the ACL. When advertising its service pro-file, a resource will advertise its ACL like any other

searchable attribute, but the name resolvers are re-sponsible for denoting the ACL as a hidden attributeand storing it on the name-record for the particularresource.

Storing ACLs as attribute-value pairs is advanta-geous because we do not change the manner in whichdata is stored and we do not have to radically al-ter the way in which queries are handled (ref. Sec-tion 3.2.2). The structure of the name-tree remainsthe same, while the hidden attributes are stored di-rectly on the name-records for each resource.

3.2.2 Redesign of lookup algorithm and ACLpropagation

[1] describes the LOOKUP-NAME algorithm that INSuses to retrieve name-records for a given name-specifier. This algorithm operates by pruning at-tribute branches of the name-tree that fail to matchthe given search criteria, ultimately arriving at a sub-set of all the name-records that contains the possi-ble matching resources. This algorithm works wellwith the way name-trees are organized in INS. Sincethe name-trees consist of alternating levels of at-tributes and values, it is very easy to prune branchesof the tree while progressing through the target name-specifier. But, left alone, this algorithm fails to workwith hidden attributes such as ACLs.

Due to the transparency that is required, userswill not explicitly construct queries with ACL name-specifiers. One option for determining a user’s ac-cessible resources would be as follows. First, theLOOKUP-NAME algorithm would be run to comple-tion, arriving at a list of criteria-matching resources.At this point, INS would have a handle to the name-records for each of the matching resources. We couldproceed by iterating through these possible name-records and checking whether the user making therequest is on the ACL. While this approach will saveus considerably over the approach of contacting eachof the resources for access decisions, it still is ineffi-cient. A closer inspection of the LOOKUP-NAME al-gorithm reveals additional ways in which this processcan be optimized.

We designed a modified algorithm, LOOKUP-

NAME-AC, that eliminates potential name-recordswhile pruning S, the set of all possible name-records.The LOOKUP-NAME-AC algorithm operates undersome assumptions on the state of the INS name-tree.In order for the algorithm to terminate successfully,the algorithm assumes that each value node in thename-tree contains an intermediate ACL. This inter-mediate ACL is computed to be the logical OR (∨)of the intermediate ACLs stored at all of the value

5

nodes that are its children in the INS name-tree. Be-ginning at the value-nodes that contain pointers toname-records, intermediate ACLs are computed. Forthese leaf nodes, the intermediate ACL is simply theACL of the name-record to which it points. Aftercomputing the ACLs at these leaf nodes, the inter-mediate ACLs for the parent nodes are computed allthe way up the name-tree. OR’ing (∨) multiple ac-cess control lists happens at the “entry” level. Thatis, the result of the logical OR (∨) of two ACLs isa new ACL with every entry that exists in either ofthe two ACLs. For example, if acla = [e1, e2, e3] andaclb = [e1, e2, e4, e5], then:

acla ∨ aclb = [e1, e2, e3, e4, e5], (1)

where the notation acl = [e1,...,en] indicates thate1,...,en are entries of the ACL. Figure 4 illustrateshow ACLs are propagated up the INS name-tree fromthe leaf nodes.

The modified algorithm is similar to its predeces-sor, except now it eliminates candidate records basedon whether the user is included in intermediate ACLs.This new algorithm takes the user’s identity andauthorization rules as arguments. For each name-specifier in the INS query, INS will prune branchesthat do not match the search criteria and that do notcontain the user in their intermediate ACLs througha series of recursive calls. When the algorithm termi-nates, it returns only the relevant, accessible name-records. By taking the OR of the ACLs, we enableaccess control decisions to be made while INS is lo-cating the proper name-record, eliminating the needto iterate through inaccessible resources and branchesof the tree. This simplifies the task of the lookup al-gorithm as well as potentially reducing the amount ofthe name-tree that needs to be traversed. This algo-rithm terminates without the need to backtrack anddoes not ever check a given ACL more than once. Theadditional cost of this algorithm, though, is clearly inthese checks that the algorithm must make for eachname-specifier, but we argue in Section 4 that thistradeoff is still advantageous.

3.2.3 Dynamic maintenance of name-trees

ACLs are resource properties that may change.Groups or keys may be added or removed, or theoperations allowed by a particular group/key maybe changed. In dealing with name-tree mainte-nance, there are three qualities that any design shouldachieve:

• Freshness. Our primary goal is to keep thestate information in the INS name-tree fresh. At

any point in time, we want to know with highprobability that the access control and resourceinformation is up-to-date.

• Responsiveness. The maintenance procedureshould be responsive to changes made to the ac-cess control information. It is important thatchanges to ACLs are rapidly reflected in the INSknowledge base.

• Authentication and Privacy. Finally, main-tenance updates should be authentic and pri-vate. There are a whole suite of attacks thatcan be centered around unauthentic updates (re-play, DoS). Also, entities should not be able tomaliciously learn sensitive information about re-sources. For these reasons, the security of main-tenance updates is very important.

Many of these issues have been considered when de-signing INS for service updates, so our focus is specifi-cally on how access control updates are handled. Re-sponsiveness is achieved by using triggered updateswhich are fired when an ACL changes state. Periodicupdates are also used to enforce freshness. The util-ity of these updates comes from the fact that ACLstypically have expiration times. Clearly, the updateperiod should be chosen such that it is less than theACL expiration time (Tupdate < texpire) but not sosmall that it unnecessarily floods the network withupdate packets. Upon receiving an update request,INS actively modifies its name-tree to reflect the cur-rent state of access rights and intermediate ACLs arerecomputed. Handling the privacy and authenticityof these messages, as well as the authenticity of mes-sages in which a resource updates INS with its otherservice attributes, is a subject of ongoing research.

3.2.4 User authorization rules

In order for this system to function, INS needs ac-cess to the user’s set of current authorizations. Themodified lookup algorithm depends on knowing theuser’s identity and the groups of which he is a mem-ber. Each proxy in the system stores a user’s signedSPKI/SDSI certificates. [5] describes an efficient al-gorithm for determining, from a set of SPKI/SDSIcertificates, the access control groups of which a par-ticular user is a member and the operations that heis allowed to perform. Complete and detailed de-scriptions of the procedures are found in [5], but thisis well beyond the scope of this paper. In essence,a (finite) transitive closure is taken over the certifi-cates, and rules representing the user’s authorizationsare extracted. The rules are simple and not signed.

6

intermediate ACLs

acl

acl1 acl2Vlcs

floorfloor

second (2)

battery−life resolution

87% 640x480

available−memory

building

room

226

NAME RECORD ECORDRAME N NAME RECORDECORDRAME N

acl1 2acl acl3 4acl

acl2

acl4

3acl1acl

acl3

1acl 2acl 3acl acl4

acl43acl2acl1acl VVV

acl1 acl2 acl3 4aclV V V

600x80050%

ai−lab bldg−34 printer camera

root

service

online

fourth (4) 128mb short

duration

idle

availability

under−repair

56mb

2

Figure 4: This shows how ACLs are propagated from the leaf nodes up the INS tree to the root of the data structure.At each intermediate value-node in the tree, an ACL is stored and is computed by taking the logical OR (∨) of theACLs at all of the child nodes.

However, each rule has a representation as a signeduser certificate, or a chain of signed user certificates.The closure algorithm is run when there is a changein the user’s certificates, such as when he acquires anew certificate, or when one of his certificates expires.

The proxy presents the user’s authorization rulesto INS with the user’s query. INS uses the rulesto check if the user is on an (intermediate or leaf)ACL contained at a node in the INS tree (using theLOOKUP-NAME-AC algorithm). An important pointis that these ACL checks performed by INS can bemade fast and efficient. The ACL check is used todetermine if a user is on an ACL, and it is not nec-essary for INS to know the proof that the user wouldgenerate to show that he is on the ACL.

When INS has completed its searching and re-turned an address, the proxy will then use a secureauthentication and authorization protocol to contactthe resource [4]. The modified INS system we presentnow returns only resources to which the user has ac-cess, so the proxy should only have to execute thissecurity protocol once.

3.3 ACL Design

Access control lists are vital components of this sys-tem. As such, the design of the ACLs are very impor-tant in terms of storage and performance. Since weare storing ACLs on INS nodes, the simple operationsof checking, OR’ing, and generating ACLs must per-form well and optimize the storage space that theyconsume.

Instead of utilizing an existing implementation, we

chose to design our own lightweight representationfor ACLs. An ACL is a collection of ACL entrieswhich are keyed by a user’s public key. As a result,ACLs in our system are internally represented by alexicographically-ordered tree, where an entry can befound by traversing the tree and making a simplelexicographic decision at each depth. When entriesare added to the ACL, they are added in the properlocation of the sorted tree. We use a red-black tree(binary tree) implementation of a sorted map. A red-black tree with n elements has at most a depth of2log(n + 1). Such an implementation guarantees alog(n) time cost for adding new indices and lookingup values. By using a sorted tree, we rely on the pre-computation at insertion to reduce the overall lookuptime.

3.4 The Scenario Revisited

After presenting the components of the access-controlled resource discovery system, it is helpful torevisit the scenario presented in Section 2.1 to seehow this new system handles the same problem.

Again, Edward is looking to obtain a copy of hisschedule, schedule.doc, from the closest user in hisgroup. Edward places a request for the documentvia his proxy. Edward does not explicitly have toindicate to his proxy his group membership or thefact that he wants to retrieve the document from an-other group member; this is handled automaticallyby his proxy. Edward’s proxy contacts an INR withwhich it has previously registered. It then queriesthe INR for the best accessible resource, translating

7

the request specified by Edward to an INS-specificname-specifier. Edward’s proxy also computes hisauthorization rules (they may be computed on thefly or pulled from the proxy’s cache) and sends themalong with the request to the INR. The INR, whichhas received access control advertisements from allthe registered resources in the network, takes the re-quest and the user’s authorizations and executes theLOOKUP-NAME-AC algorithm. After a single execu-tion of this algorithm, the INR returns the closest, ac-cessible resource to Edward’s proxy. Edward’s proxythen uses a secure protocol to contact the resourceand uses a standard secure copy protocol to retrievethe file from the resource. Because INS knew aboutEdward’s group membership, it returned a resourcethat is accessible, meaning the time-consuming secu-rity protocol would only have to be executed once.

4 Evaluation

A prototype system was implemented in Java usingINS 2.0, a pure Java implementation of INS. In thissection, a formal evaluation of this system is pre-sented. The overall goal is to quantify how our designoutperforms a resource discovery system that doesnot integrate access control with resource decisions.These experiments were all conducted using off-the-shelf Intel Pentium II 266MHz computers with a 512KB cache and 128 MB RAM, running Windows NTServer 4.0. The software was built and run usingSun’s Java Virtual Machine version 1.3.

4.1 Comparison of resource retrievaltime

A measure of the time savings of our solution is nec-essary to evaluate its effectiveness. As a baseline, thissystem will be compared to a basic scheme, where INSis used as the resource discovery system, but does nothave access to ACLs or the authorizations of the re-quester. This basic scheme was described in detailin Section 2.3. For convention, we will assume thatthe user, U is operating in a network with n totalresources.

To understand the performance gains of this newsolution, we must analyze the time it takes U to suc-cessfully access the most optimal resource and com-pare this time in both the basic and access-controlledsystems. This time is denoted as tBASIC for the basicscheme and as tAC for the access-controlled system.Each of these time values can be generally expressedby the following equation:

tx = tquery + (n∑

k=1

bk · (tlatency + tacl−check)) + tcrypto

(2)tquery is the query time, the time it takes the resourcediscovery system to respond to U ’s request. tquery

also includes any time U ’s proxy uses to prepare therequest. bk is a boolean value that is 1 if U contactsresource k and 0 if U does not. tlatency is the round-trip network latency between two proxies. This isessentially the time it takes U to retrieve a resource’sACL over the network. tacl−check is the ACL-checktime, the time it takes for a simple ACL check tobe performed. ACL checks were made very fast withour adopted implementation (as will be shown laterin this section). Finally, tcrypto is the time it takesU to derive the full authorization proof and for thisproof to be verified by a particular resource’s proxy.

4.1.1 tBASIC

In the basic scheme, the time for U to successfullyaccess the most optimal resource is given by the fol-lowing equation:

tBASIC = tqueryBASIC+

1p· (tlatency + tacl−check)

+ tcrypto (3)

This derivation of tBASIC can be found in [12].tqueryBASIC

is the time it takes the LOOKUP-NAME

algorithm to execute and p is the probability U hasaccess to a given resource.

4.1.2 tAC

Similarly, the time to retrieve a resource using ouraccess-controlled solution is given by:

tAC = tqueryAC + tlatency + tcrypto

= tqueryBASIC + Dn · tacl−check

+ tlatency + tcrypto (4)

The key difference is that tAC is not dependent onthe likelihood that U has access to a given resource.Instead, the query time, tqueryAC

, depends on Dn,which represents the number of ACL checks that willhave to be made while traversing the INS name-tree.It is a function of the number of resources in thenetwork (n), but is also affected by the complexity ofthe name-tree and name-specifiers. For more details,see [12].

8

Name-Tree Lookup Performance

0

100

200

300

400

500

600

700

800

0 2000 4000 6000 8000 10000 12000

Names in the Name-Tree

Lo

oku

ps/

sec

Figure 5: The lookup rate (lookups/sec) is plottedagainst the number of names in the name-tree. As thenumber of names increases, the lookup rate progressivelygets smaller, starting from a maximum of around 700lookups/sec to 200 lookups/sec.

4.1.3 Name Lookup Performance, tqueryBASIC

and tqueryAC

To quantify the difference between tqueryBASICand

tqueryAC, we constructed a large, random name-tree

and timed how long it took the tree to perform 1000random lookups using each algorithm. The name-treeand name-specifiers were chosen uniformly accordingto the parameters defined in [1] (ra = 3, rv = 3, na

= 2, and d = 3). n, the number of distinct, uniquenames in the tree, was varied from 1 to 13000 in in-crements of 100 to see how tqueryBASIC and tqueryAC

vary with increasingly large name-trees. The maxi-mum heap size of the JVM was limited to 64MB, thuslimiting the range of the experimentation.

Figure 5 shows the results of this experiment. Us-ing the basic LOOKUP-NAME algorithm, the perfor-mance went from a maximum of around 700 namelookups/sec to a minimum of 200 lookups/sec. FromFigure 5, it is evident that as the number of namesin the name-tree increases, the lookup rate decreases.As a result, the amount of time required for a singlelookup increases. But, the drop-off is not as drasticas one would think and clearly is not linear. For amoderately large system with approximately 2000 re-sources (or names), the average lookup time is around1.8 ms. For small systems on the order of hundreds ofresources, the lookup time is around 1.4 ms. Thesetimes are small and the difference in lookup timesbetween the small and large systems is minimal.

The experiment was repeated in the access-controlled case. Each resource was initialized withACLs containing 10 unique entries and the interme-diate ACLs were computed. Figure 6 presents theperformance results of the LOOKUP-NAME-AC algo-

Name-Tree with ACLs Lookup Performance

0

50

100

150

200

250

300

350

0 500 1000 1500 2000 2500 3000 3500

Names in Name-Tree

Look

ups/

sec

Figure 6: The lookup rate (lookups/sec) is plottedagainst the number of names in the name-tree. Eachname in the name-tree is protected by an ACL with 10unique keys. As the number of names increases, thelookup rate progressively gets smaller, starting from amaximum of around 325 lookups/sec to 240 lookups/sec.

rithm as the number of names in the tree varied from1 to 3500. As is evident from this figure, the lookuprate is significantly reduced from the rate without theACL checks. The experiment was terminated at amaximum of 3500 names due to memory constraintsof the JVM. With approximately 100 name-records inthe tree, a rate of 325 lookups/second was achieved.In the non-access-controlled case, this rate was muchhigher at around 700 lookups/sec. At approximately3500 name-records, the rate of the LOOKUP-NAME-

AC algorithm was at 240 lookups/sec, indicating onlya drop of in about 90 lookups/sec. Conversely, therate in the basic case dropped to 450 lookups/sec with3500 names, indicating a drop of 250 lookups/sec.

Table 1 details the average lookup times for the twoalgorithms for varying sizes of the name-tree. Thedifference between the lookup times is on the orderof few milliseconds and can be attributed directly tothe intermediate ACL checks that are made. In thefollowing section, it will be shown that tacl−check, thetime for a simple ACL check is on the order of ap-proximately .07 ms. Based on the name-trees we usedduring the experimentation, we can calculate approx-imately 15 intermediate ACL checks. This roughlyaccounts for about a 15 × .07 ≈ 1.05 ms difference be-tween the lookup times. The numbers in Table 1 seemto support this back-of-the-envelope calculation.

4.1.4 Access Control List Performance,tacl−check

One of the fundamental differences between a basicsolution and ours is the use of ACL checks duringthe name-lookup process. In order to determine the

9

Names in Average Lookup Time (ms)Name-Tree LOOKUP-NAME-AC LOOKUP-NAME

100 3.24 1.45200 3.23 1.47500 3.35 1.481000 3.52 1.611500 3.66 1.762000 3.80 1.882500 3.94 2.043500 4.23 2.31

Table 1: This table shows the average lookup time ex-perienced by the two algorithms for varying sizes of thename-tree.

ACL Performance

8000

9000

10000

11000

12000

13000

14000

15000

16000

17000

0 2000 4000 6000 8000 10000 12000 14000

Number of ACL Entries

AC

L C

heck

s/se

c

Figure 7: The ACL check rate (in ACL checks/sec) isplotted against the number of entries in the ACL. It isevident that the rate decreases with an increasing numberof entries, but only slightly. Also of note, are the fourregions of concentration of points.

cost of an ACL check, random large ACLs were con-structed with the number of distinct entries in theACL ranging from 1 to 14000 and the number of ACLchecks that could be executed in the span of a sec-ond was measured. Figure 7 illustrates the results ofthis experiment. As expected, as the number of en-tries in the ACL grows, the ACL check rate decreaseslogarithmically. ACLs in our system are representedby red-black trees (binary trees), keyed by the users’public keys, that guarantee a log(n) time cost foradding new indices and looking up values. As thenumber of entries in the ACL goes from 1 to 1000,the check rate decreases by 500 checks/sec. A similarrate decrease can be seen as the number of entries isvaried from 1000 to 10000.

Figure 7 shows five stratified regions of lookup

rates, that correspond to the number of decisions thatmust be made in order to find a key in the ACL. De-pending on where a key is located in the range of pos-sible keys, the number of decisions to find it in thetree can vary. For an ACL of 1000 entries, the timeit takes to perform an ACL check can be one of thefollowing values: .083 ms, .074 ms, .067ms, or .061ms(according to the four different regions in the graph).These values are an order of magnitude smaller thanthe time taken by the LOOKUP-NAME algorithm tofind a name. Therefore, the idea of making severalACL checks during the name retrieval process adds aminimal time cost and seems very reasonable.

4.1.5 Round-Trip Network Latency, tlatency

tlatency is the round-trip network latency betweenproxies in the network. It is a fundamental compo-nent of the resource retrieval time in the basic solu-tion (tBASIC), which requires a client proxy to ex-plicitly contact potential target proxies in order todetermine access privileges. To estimate this param-eter, simulations were run in ns [8].

A precise measure of tlatency is somewhat subjec-tive, as the exact value of the round-trip time betweentwo proxies depends on the network infrastructure,number of hops between proxies, current traffic con-ditions, link bandwidth, and any additional networkcharacteristics. For simulation purposes, we adopta network structure where proxy-proxy communica-tion will take at most two hops. Two routers arelinked together, with each router containing sevenend proxies, each sending packets according to thefollowing traffic flows. A third router is connected toINS and the other two routers. Therefore, in order tocommunicate with another proxy, a proxy must onlysend packets through two hops. The links betweenproxies and routers each have a bandwidth of 133Mbps and a propagation delay of 5 ms. The router-router links have a bandwidth of 100 Mbps. Thereare three main traffic flows in this network, namelyProxy-Proxy traffic, Proxy-INS service updates, andProxy-INS requests. A single proxy-proxy flow wasstarted between two proxies and the round-trip timefor each packet was measured over a span of thirtyseconds. Figure 8 shows the results of this experi-ment.

As is evident from this figure, the round-trip timestays almost constant throughout the duration of thetraffic flow. Initially, there is some variance as TCPuses a slow-start mechanism to find the optimal win-dow size. But, after equilibrium is reached, the meanRTT of proxy-proxy communication is 48.37 ms. It isworth noting that in a network with many resources,

10

Proxy-Proxy Latency

48.3

48.4

48.5

48.6

48.7

48.8

48.9

49

0 1000 2000 3000 4000 5000 6000 7000

Sequence Number

RT

T (

ms)

Figure 8: The results of the simulation are shown here.The RTT of packets sent between proxies is constantthroughout the packet flow. The mean RTT between twonetwork proxies is 48.37 ms.

this number is a best-case scenario. The link band-widths used were large, the propagation delays weresmall, and the two-hop assumption will break downas the number of resources increases. Despite usingfavorable conditions, we see that tlatency is three fullorders of magnitude larger than tacl−check. As willbe shown in Section 4.1.6, this result plays a key rolein determining the efficiency of our access-controlledresource discovery system.

4.1.6 tAC versus tBASIC

In this section, we analyze the difference in retrievaltimes between the two solutions. Subtracting Equa-tion 4 from 3, we get:

∆t(n) = tBASIC(n)− tAC(n)

=1p(tlatency + tacl−check)−

(Dn · tacl−check + tlatency) (5)

From Equation 5, we can see that whether the access-controlled scheme outperforms the basic scheme de-pends on whether 1

p ·(tlatency+tacl−check) is greaterthan (Dn · tacl−check + tlatency). If it is, we canconclude it is more efficient for INS to perform theACL checks as it descends down its name tree, ratherthan leaving this up to the user’s proxy. In or-der to make this comparison, we consider our sce-nario (in Section 2.1) with 1000 total users dividedequally among the two groups (KA managers andKB developers). Therefore, the probability thatEdward has access to any given resource is p = 0.5.If we also assume the structure of the name-tree is

as described previously, Dn = 15. From our experi-ments in Section 4.1.4, we will assume an ACL checkwith 1000 entries per ACL takes .083 ms. Finally,the latency between proxies will be assumed to be48.37 ms (as calculated in Section 4.1.5). Using theseparameters, the difference in lookup time is:

∆t(n) =1

0.5(48.37 + 0.083)− (15 · 0.083 + 48.37)

= 47.291 ms (6)

Even with the parameters chosen to favor the ba-sic solution, the access-controlled solution wins by alarge margin. It is likely that this is a conservative es-timate. With 1000 resources in the network, tlatency

will likely be greater than 48.4 ms as the propagationdelays of the links will increase and the number ofhops between proxies will increase. Furthermore, if pbecomes smaller, the basic solution is subject to moretrips across the network, making our savings greater.The main difference in the resource retrieval times foreach solution can be attributed directly to the factthat ACL checks are extremely fast. Our solution isnot subject to the network latency and the three or-ders of magnitude saved in performing an ACL checkgive our solution a clear advantage. The query timesaved in the basic solution is minimal compared tothe time that the ACL checks save.

4.2 Performance of ACL propagation

The LOOKUP-NAME-AC algorithm requires that inter-mediate value nodes in the name-tree have computedthe logical OR of all the ACLs in its subtree. In or-der to do this, the propagateAcls method is calledperiodically (for freshness) and any time a triggeredupdate is initiated by a user’s proxy.

The propagateAcls method is invoked every timean update to an ACL occurs. For analysis pur-poses, the time between ACL updates is denotedεtriggered. Immediately after an ACL update occurs,the propagateAcls method must be called. Sincethe method is synchronized, the name routers can-not service any incoming requests during this time,backlogging requests in a queue. This creates some-what of a “time-slotted” service model (as shown inFigure 9), where the requests can only be servicedbetween the end of the execution of propagateAclsand the time the next update arrives.1 Essentially,

1In reality, there are other maintenance updates that theINRs handle, such as changes to service profiles (e.g. growthin the number of documents in a particular printer’s queue, ora particular speaker going offline, etc.). But for the simplicityof this analysis, these updates are ignored here. The argument

11

0

triggeredepsilon

propagatet

SlotService

SlotMaintenance

5tt43tt21t

(ACL updates)

Figure 9: The propagateAcls method must be calledafter an ACL update has been sent to the INR. Since themethod is synchronized, new requests cannot be servicedwhile the method is being executed. Servicing of requestscan only occur between the execution of propagateAclsand the next update.

the INR can serve requests for some time, update it-self, serve requests, and so on. Clearly, the goal hereis to minimize the maintenance time with respect tothe available service time so that the service slots aremuch bigger compared to the maintenance slots.

This “slotted” model can potentially lead to prob-lems, because users will not stop sending requestswhen the INR is under maintenance. A queue willbuild up as the name-tree is under maintenance andthe requests in the queue along with all other requestsmust be processed before the next update arrives, orthe system will experience congestion and collapse.If we model the queue as an M/M/1 queue [3] withPoisson arrivals and exponential service times, a for-mulation can be made as to when operation of thesystem will be successful (i.e., no collapse). The ar-rival rate of INS requests is λ. The service rate isµ (the average service time is 1

µ ). In this system,1µ equals tqueryAC . The time for the execution ofpropagateAcls is tpropagate. The collapse conditionwill occur if all the requests are not serviced beforethe next ACL update arrives. While the INR is undermaintenance, we expect NQ, the queue size, to growto λtpropagate (by Little’s Theorem [3]). Similarly,while the INR is in the service slot, the number of in-coming requests will be λ(εtriggered - tpropagate). Thetime to service these requests must be less than theduration of the service slot in order for queue buildupto be avoided. That is:

εtriggered À tpropagate · µ

µ− λ(7)

Is it a reasonable assumption that this conditionholds? We have seen that tpropagate is on the order ofa few seconds and 1

µ is on the order of a few millisec-onds. According to Equation 7, it can be seen that as

presented can be easily extended to account for these updatesas well.

Storage Required by Name-Trees

0

5

10

15

20

25

30

35

40

45

50

0 250 500 750 1000 1250 1500 1750 2000 2250

Number of Name Records

Siz

e of

Nam

e-T

ree

(MB

)

Without ACLs With ACLs With ACLs, After Propagation

Figure 10: There are three plots shown here. The firstplot shows the memory used by standard name-trees with-out ACLs. The second plot shows the same name-treeswith ACLs on the records. The final plot shows the nametrees with the ACLs after the propagateAcls method hasbeen called (the name trees contain intermediate ACLs).As the number of name-records increases, the memoryused increases linearly.

long as the INR is not receiving requests at the samefrequency (every few milliseconds), then the systemwill be fine. Even if λ is on the order of a request/ms,the frequency of ACL changes will be on the order ofminutes, not milliseconds. The condition in Equa-tion 7 will easily hold and the system operation willbe smooth.

4.3 Tradeoffs

The premise our solution makes is that basic solutionsscale poorly and are based on inefficiencies that limitthe performance of the system. Specifically, findinga resource requires explicit contact to check accessprivileges. From the experiments, we have verifiedthis by showing our solution significantly reduces theresource retrieval time. At the same time, it makesa large system with many resources manageable andefficient. A similarly-sized system may be inoperableunder the basic resource discovery approach.

While saving time, our solution does add greaterrequirements for storage to INS. This is primarilydriven by the need to store ACLs (both resource-leveland intermediate) in the name-tree, a constraint notmade necessary by the basic solution. We analyze theadditional space required by our solution and com-pare it to that of the basic solution.

Ultimately, the goal is to evaluate how much morememory the access-controlled solution requires thanthe basic solution. Again, using randomly con-structed name trees (with the same dimensions asdescribed in prior experiments), the number of name-

12

records in the tree was varied from 0 to 2500 andthe physical size of these trees was measured. As abase case, the name-trees were created without ac-cess control lists. These are the name-trees usedby the basic solution. As a second experiment,the name-trees were then created with each name-record containing an ACL with 10 unique entries.The size of these trees was measured. The final ex-periment involved measuring the size of the name-trees after the propagateAcls method was called.The propagateAcls method forces the computationof the intermediate ACLs, so the memory used in-creases. Figure 10 shows the results of these experi-ments.

From this figure, we can clearly see that the name-trees required by the access-controlled solution usemuch more memory than the basic name-trees. Aname-tree of 2000 name records that does not storeACLs uses approximately 9.4 MB of storage, whereasa name-tree that stores ACLs and has executed itspropagation takes up 38.1 MB. In fact, from the fig-ure, ACL-propagated name-trees use 3.75 times morespace, on average, than basic name-trees:

size(TAC(n)) = 3.75 · size(TBASIC(n))= 3.75× [(0.0185 · n) + 0.40] Mb

(8)

For relatively small name-trees, this difference is notsubstantial. But, as the number of name-recordsgrows fairly large, the difference in the name-treesizes is significant. The computational resources re-quired to store the name-trees become large as thesystem scales. As the number of name-records grow,the sizes of the intermediate ACLs also grow accord-ingly. Note, this is the worst case scenario. Eventhough each ACL has 10 different entries, it is verypossible that entries can be repeated across resources,thereby somewhat limiting the size of the trees. De-spite this fact, integrating access-control into INS re-quires additional memory in the name routers.

Nevertheless, storage is cheap and can be solvedsimply by adding more memory to each INR. On theother hand, saving time is not as simple as installingadditional components to each router. As such, thestorage-time tradeoff is one that is worth making.

5 Related Work

There are several protocols that have been developedthat provide resource discovery services. This sec-tion presents some of these protocols and gives a briefanalysis of each.

Jini network technology [14] is a Java environmentdeveloped by Sun Microsystems that supports re-source discovery. The overall goal of Jini is to turn anetwork into a flexible, easily-administered tool withwhich resources can be easily found by clients. Inpractice, Jini extends the Java application environ-ment from a single virtual machine to a network ofmachines. Communication between a network of vir-tual machines occurs by exchanging serialized Javaobjects over Java Remote Method Invocation (RMI).Jini provides a lookup service to all clients in thenetwork. The lookup service enables clients to queryfor the resources through a standard Java interface.While Jini offers a great deal of flexibility, its relianceon the Java Virtual Machine (JVM) makes it only assecure as the minimally secure JVM. The Jini archi-tecture does not include any security in addition tothe normal Java security facilities (for protecting theclient JVM from malicious code), and the security as-pects of RMI are insufficient for a trust-based securitymodel [6]. RMI execution is layered on top of Javasockets and is abstracted in such a way that networkconnections are formed automatically. While Javauses secure sockets, it is difficult for a client to verifythat a stub is using secure sockets, potentially com-promising sensitive information. Furthermore, issuessuch as access-control are not explicitly handled byJini.

The Service Location Protocol (SLP) [17] is a de-centralized, lightweight, scalable and extensible pro-tocol for service (or resource) discovery within a sys-tem. SLP eliminates the need for a user to know thename of a network host, but rather, the user suppliesthe desired type of service and a set of attributeswhich describe the service. SLP is not designed toscale to large numbers of users and its performanceis questionable in unknown dynamic networks.

Universal Plug-and-Play (UPnP) is Microsoft’sstandard for resource discovery. Resources in the sys-tem advertise and describe themselves using the eX-tensible Markup Language (XML). UPnP relies heav-ily on XML, HTTP, and IP and therefore can leverageknown and tested communication models. For secu-rity, UPnP relies on existing World Wide Web secu-rity models such as SSL. While these methods aresecure, they are computationally intensive and maynot be applicable in an environment where clients andresources are computationally-starved.

The Portolano Project [16], developed at the Uni-versity of Washington, is a large-scale networking in-frastructure designed to support pervasive computingenvironments. Initial security proposals involve usingIPsec-based authentication [10], but these issues haveyet to be explored and remain an area of ongoing re-

13

search.

6 Conclusion

This paper has experimentally verified the merits ofour resource discovery system that integrates accesscontrol by comparing it to alternative systems. Theresource retrieval time is greatly reduced using thisarchitecture, while security is not compromised. Thisallows our system to scale to levels that traditional re-source discovery systems wishing to implement accesscontrol would be unable to efficiently reach. Whilethe implementation and execution of this system doesrequire additional memory in each intentional namerouter, sacrificing storage for time and efficiency is aworthwhile tradeoff.

Together with the proxy-based security model, thisarchitecture meets all the goals of a secure system. Itfeatures efficient and scalable access-control for allresources while integrating with a powerful resourcediscovery system. We believe that this architectureis a flexible and generalized security infrastructureready to support the pervasive computing trends thatwill surely dominate the future.

References

[1] W. Adjie-Winoto, E. Schwartz, H. Balakrishnan,and J. Lilley. The Design and Implementation ofan Intentional Naming System. Operating Sys-tems Review, 34(5):186-301, December 1999.

[2] G. Banavar, J. Beck, E. Gluzberg, J. Munson,J. Sussman, and D. Zukowski. Challenges: AnApplication Model for Pervasive Computing. InProc. ACM MOBICOM, August 2000.

[3] D. P. Bertsekas and R. Gallagher. Data Net-works. Prentice Hall, second edition, 1991.

[4] M. Burnside, D. Clarke, T. Mills, A. Maywah,S. Devadas, and R. Rivest. Proxy-based securityprotocols in networked mobile devices. In Proc.ACM SAC02, March 2002.

[5] D. Clarke, J.-E. Elien, C. Ellison, M. Fredette,A. Morcos, and R. Rivest. Certificate Chain Dis-covery in SPKI/SDSI. Journal of Computer Se-curity, 2001. To appear.

[6] P. Eronen. Security in the jini networking tech-nology: A decentralized trust management ap-proach.

[7] P. Eronen and P. Nikander. Decentralized JiniSecurity. In Proc. of the Network and DistributedSystem Security Symposium, February 2001.

[8] K. Fall and K. Varadhan. The ns manual.

[9] Hewlett-Packard. CoolTown. Seehttp://cooltown.hp.com.

[10] S. Kent and R. Atkinson. Security architecturefor the internet protocol (rfc 2401). November1998.

[11] D. L. Martin, A. J. Cheyer, and D. B. Moran.The open agent architecture: A framework forbuilding distributed software systems. In AppliedArtificial Intelligence, March 1999.

[12] S. Raman. A secure framework for access-controlled resource discovery in dynamic net-works. Master’s thesis, Massachusetts Instituteof Technology, 2002.

[13] R. Rivest and B. Lampson. SDSI - A Sim-ple Distributed Security Infrastructure. Seehttp://theory.lcs.mit.edu/ rivest/sdsi10.ps.

[14] Sun Microsystems Inc. Jini Network Techonol-ogy. http://www.sun.com/jini.

[15] UC Berkeley. The Ninja Project: EnablingInternet-scale Services from Arbitrarily SmallDevices. See http://ninja.cs.berkeley.edu.

[16] University of Washington. Portolano: AnExpedition into Invisible Computing. Seehttp://portolano.cs.washington.edu.

[17] J. Veizades, E. Guttman, C. Perkins, and S. Ka-plan. Service location protocol (rfc 2156). June1997.

14