Uniform resource name (URN) IN Ajanta, A Mobile Object EnVironment
by
Tanvir Ahmed
Submitted in partial fulfillment of the requirements for the degree of
Master of Science in Computer Science
University of Minnesota
May 1999
Approved by ______
Chairperson of Supervisory Committee
______
______
______
Program Authorized
to Offer Degree______
Date ______
University of Minnesota
Abstract
UniforM RESOURCE NAME (Urn) in ajnata, a mobile object environment
by Tanvir Ahmed
Chairperson of the Supervisory Committee: Professor Anand Tripathi
Department of Computer Science
Ajanta is a Java based mobile agent system. Location-independent global naming is one of its basic system requirements. In this report, we have described our adaptation of Uniform Resource Name (URN) scheme in Ajanta. We have examined the architectural and functional requirements of name resolution for mobile agents and have presented our implementation of Ajanta name service. Security and robustness are the basic requirements of this name service. Name registry enforces access control on its entries and protects the name-space delegated to principal like user, agent-server, name-registry and even mobile agent. A detail description is provided on different scenarios of name resolution based on mobile objects like agents and other stationary objects like agent-servers.
Table of Contents
1Introduction......
2Ajanta Programming Environment......
2.1Main Components of Ajanta System......
2.1.1Mobile Agent......
2.1.2Stationary Agent Server......
2.1.3Human User......
2.1.4Name Registry......
2.1.5Principal......
2.2Interaction Protocol......
3Overview of Ajanta Name Service......
3.1Design Principles......
3.2URN Format......
3.3Functional Requirements......
3.4Security Requirements......
4Name Registry Architecture......
4.1Authentication Mechanism......
4.2Access-Control on Name Creation and Update......
5Name Registry Implementation......
5.1Name-Registry Entry......
5.2Name Registry Interfaces......
5.3Caching and Serialization......
6A Global Scenario of Name Resolution......
7Future Work and Conclusion......
Acknowledgments
I would like to thank my advisor, Professor Anand Tripathi, for his guidance, support and for generously providing his knowledge and ideas of system design throughout this project. By the time I joined Ajanta, considerable amount of work has been done by Professor Tripathi and Neeran Karnik. Without their considerable patience and guidance, this project would not be possible.
I would also like to thank Manish Vora, Ram Singh and Arvind Prakash for providing their valuable views during many design meetings. I am thankful to them for their friendly support even when they have to endure bugs or inconsistencies, my name-registry imposed on them, during the development cycle of the naming system.
1
1Introduction
All the existing global naming schemes are location dependent. Hence whenever a named object moves, the name of the object becomes obsolete. We already face this problem with Uniform Resource Locator (URL)[7] and the current solution is to use re-direction. For resources that are usually stationary, this scheme may work for an acceptable amount of time. Still it is not feasible if we have to follow three or four redirections for a URL. For resources that are mobile in nature, meaning that they change location frequently, like an agent in the Internet, all the existing naming schemes fail.
Ajanta[1] is a Java-based framework for programming mobile agent based applications on the Internet. Ajanta needs a location-independent naming, meaning the name does not correspond to a physical location, which will allow unique identification of autonomous mobile agents. Moreover, the autonomy of the mobile objects requires that the task of name creation and name resolution be separate and independent. From application programmers viewpoint, the system interface of Ajanta framework is abstracted and simplified by using a location-independent, global, uniform identifier which allows us to transparently access mobile agents without requiring any knowledge of their locations.
To comply with the location independent naming requirement of mobile objects in Ajanta we adopted Uniform Resource Name (URN) [2] scheme. A Uniform Resource Name (URN) is a persistent, location-independent resource identifier that can be used for accessing the characteristics of the resource, or the resource itself.
In this paper we have described our implementation of Ajanta Name Server framework which closely follows the functional requirements mentioned in different RFCs[2, 5]. This framework is envisioned as an integral part of Ajanta system, but many of the design can be reused for any URN resolution architecture.
2Ajanta Programming Environment
2.1Main Components of Ajanta System
2.1.1Mobile Agent
A mobile agent is a program, which represents a user in a network and is capable of migrating autonomously from node to node, performing computations on behalf of that user.
2.1.2Stationary Agent Server
A host in the Internet can provide services to mobile agents by running an agent server. An agent server creates a confined execution environment for visiting agents and allows the local resource owner to grant access of its resources to agents in a selective manner. It provides primitive operations to agent programmers, such as those that allow agents to migrate to other servers, communicate with each other, query their environment, etc.
2.1.3Human User
The agent represents this human user, also known as owner. An agent can be created by agent-server, application program or another agent. Thus, the owner or the human user needs not to be the creator of an agent.
2.1.4Name Registry
The name registry provides the name service and can store any characteristics of an entity. Ajanta name-registry works as a repository of public-keys of all the entities. An entity with a name in Ajanta needs to register itself with a name-registry. For first time registration of an agent server, the location of this name-registry is provided to the server by the user. This bootstrap name-registry is called the local name registry. It is the entry point of the agent-server’s query/update calls. When a name queried is not present in the local name-registry, the local name registry will query other name-registries to resolve the name.
2.1.5Principal
A principal is a uniquely identifiable entity. In Ajanta, a principal can be an agent-server, an agent, a user and even a name-registry. Actions in the system are always performed on behalf of some authorized principal.
2.2Interaction Protocol
A user, typically a system administrator, runs a name registry and provides naming service for other users. A client in the network is provided with the URL of a name-registry. As mentioned before, this is the local name-registry, which is the entry point for any query/update for that client. Conversely, the owner of the client needs to register its identity (a pair containing a unique URN as a name and a Public Key for authentication) with the local name-registry.
In the Internet, a user running mobile agent applications runs agent-servers to host mobile agents. A machine can run multiple agent-servers as long as they use different ATP (Agent Transfer Protocol) port, which is used for receiving serialized agents. An agent-server may not
wish to share a RMI (Remote Method Invocation) registry[2] with other agent-servers for security reasons. For example, if an agent-server shares a RMI registry running under the authority of a different owner, the RMI registry can be stopped to deny the agent-server’s service to the world. In that case, a user starts its own RMI registry on a user-defined port for its agent servers and publishes this port to the world. Moreover, it may wish to use a unique port for its code-base, an entity that is queried by agents to dynamically load runtime objects, also known as object-store in many literature. Publishing all these agent-server specific info is done by registering itself with the name-registry.
Usually mobile agents are created by an agent-server. Upon creation it is given a URN and is registered with the name-registry. Whenever the agent moves, the current agent-server updates the agent’s new location in the name-registry. This is done as a part of the agent transfer protocol.
The local name-registry is registered with a root name-registry, so that the names maintained by it can be served to the world. For that, a published location “ajanta.cs.umn.edu” is running a root name-registry. Any user wants to maintain an Ajanta naming service need to contact with the administrator of the root name registry. This registration will enable the agent-servers of the new domain query/update other Ajanta name-registries through local name-registry and vice-versa.
Figure 1 shows the interaction of Ajanta name-registries, agent-servers and agents. The dotted circle indicates logical domain boundaries of Ajanta name-service. The name-registry inside the circle is the local name registry for all the agent-servers inside the circle. When an agent moves from an agent-server to another in the same domain, only the local name-registry is queried. In Figure 1, an agent in domain A is migrating to an agent-server within the same domain. For that the local name-registry of domain A is queried and updated. However, when an agent moves to a different domain, the local name-registry queries the remote domain name-registry. For example, when an agent in domain B migrates to a host in domain C, the current domain name-registry, as a part of agent transfer protocol, queries the destination domain name-registry.
3Overview of Ajanta Name Service
3.1Design Principles
The design of the Ajanta Name Service has been directed by the following requirements:
- Name resolution service is built on top of the existing name resolution infrastructures. This reflects current trend of system development, which allows us to reuse a working infrastructure. It also facilitates rapid development as well as widespread deployment.
- One of the main requirements of the Ajanta design is robustness. To ensure the robustness requirement, whenever a design trade-off is in question, we preferred simpler design. Besides, a simple primary implementation will allow us to measure performance gain on future novel implementations.
- The current challenge in the Internet is the security. We have paid special attention to the security and consistency of the name service.
In accordance with the URN syntax specification [1], an example of a URN in Ajanta's namespace is:
urn:ans:ajanta.cs.umn.edu/tahmed/ResourceName
Here “ans” is the Namespace Identifier (NID) [1] and ”ajanta.cs.umn.edu/UserName/-ResourceName” is the Namespace Specific String (NSS). The NID indicates the unique name-space for which a URN is created. In our case, it is “ans”, which stands for “Ajanta Name Space”. The representation of NSS part is NID specific. We use a hierarchical naming where sub name-spaces are separated by slash, ‘/’ and specify a DNS host name as the first string of the NSS. By doing so, we use the existing resolution framework of the Domain Name System (DNS) for URN resolution -- the translation of URN to a URL, or another URN, or other characteristics. In the above URN example, “ajanta.cs.umn.edu” is the DNS domain where the object was first created. We refer to this as the creation domain, which is used as a hint to locate an object. Within this name-space, “tahmed” is a naming authority, means he can create name under the name-space “ajanta.cs.umn.edu/tahmed”. “ResourceName” is a unique string in this name-space. In Ajanta, the first level of the name-space goes to the local name-registry. That means every creation domain runs an Ajanta name-registry. The local name-registry assigns the second level of the name-space to human users. The human users are free to assign the third and consecutive level of the name-space to any principals. This hierarchical structure provides ease of maintenance and delegation of namespaces. A new name can be created by a naming authority only in its own namespace A detail discussion of these follows in section 3.4.
3.3Functional Requirements
Ajanta's name registry maintains the mapping between the URN of an entity and its characteristics, including its current location. In Ajanta, depending on the type of the object, like agent, agent-server, name-registry etc the name-registry needs to store different attributes. Some basic attributes have to be stored for all types of names. These basic attributes include the object’s current location, a string name and a public-key pair for unique identification and an access control list for enforcing access control policies. Examples of type specific attributes are, agent-server name for agent name, ATP port, code-base port and RMI port for agent-server name etc. Moreover, each entry keeps some system information like “last modification time”, “last access time” etc to facilitate accounting.
Application level API’s are provided for the client to create new entries or query/update an existing one. All updates require authentication, and they are performed only if permitted by the access-control policies. The URN resolution procedure used in Ajanta first queries the local name-registry. If that name registry is unable to resolve locally, it queries the name-registry in the URN's creation domain. The creation domain name-registry maintains all the URNs created in its domain and contains the authoritative versions of their name registry entries. In our current implementation, whenever an object migrates, its creation domain is updated. If an object migrates to a host in a domain other than its creation domain, then the current domain need to update the creation domain name-registry. Hence, also system level API’s are provided to query/update from a name-registry to other name-registries.
Depending on types and amounts of information queried or updated the name-registry has to provide both fine-grained and coarse grained update and lookup interfaces. For initial registration of a name, the name-registry provides coarse update interfaces, so that the client can register all the pertaining attributes for a name by one call. Later updates are usually attribute specific. On the other hand, query interfaces are fine grained. For example, querying only the current location of an entry. For both the application and system interfaces, Ajanta has to deal with fine and coarse grained query /update calls.
3.4Security Requirements
The name service framework has to address three security requirements: (1) client /server authentication, (2) access control on the name server's registry entries and (3) access control on name-space assigned to different autonomous principals.
Usually the local name-registry will run on a local DNS domain machine and the client will trust the name-registry’s identity. However, the identities of the client principals need to be authenticated as a client is permitted to update the server entries. To meet authentication requirements, Ajanta name registry maintains DSA public key for signature verification and the El-Gamal public key for decryption for each registered principal, and it executes a challenge/response based authentication protocol for any update operation. The authentication is enforced for both sides when a name-registry interacts with another.
Currently Ajanta allows read permission for all its published information in the name-registry but needs to enforce update policies. The name registry protects its database using access control lists for its entries. The ACL (Access Control List) also protects the name-space delegated to principals, means the assigned principals are the only ones who can create name under the name-space. Currently, the ACL is checked against two kind of permission: (1) Update and (2) Create-Name.
The Update permission protects the entry from unauthorized update. It is checked against every time a principal wants to write or modify an entry. Only the owners of an ACL are permitted to change the ACL permissions. If a principal has update permission on an entry but not an owner of the ACL, he/she will not be able to update the ACL entry. He/she certainly will be able to update other values for that name.
The Create-Name permission protects the name-space under the current URN. Only authorized principals are allowed to create name under the name-space of a URN. The NSS part of a URN separates name-spaces by slash “/”. So for a URN we can find its default naming authority by taking the sub-string ended before last slash “/” of the original name. In the above example, a naming authority for the URN is “urn:ans:ajanta.cs.umn.edu/tahmed”. This principal is the default naming authority for name-space “ajanta.cs.umn.edu/tahmed”. Other naming authority for this name-space can be dynamically added or deleted. This is done by adding the desired principal with create-name permission in the ACL entry. These are the principals who can create name under the name-space “urn:ans:ajanta.cs.umn.edu/tahmed”. When a new name is created, the creator and the new name become the default naming authority for the new name. In our example, if the name “urn:ans:ajanta.cs.umn.edu/tahmed/ResourceName” is created by “urn:ans:ajanta.cs.umn.-edu/tahmed”, both of them become the naming authority for the name-space “ajanta.cs.umn.edu/tahmed/ResourceName”. At the same time they become the owner of the ACL for this new name and therefore can add other principals as naming-authority if needed. These issues will be further discussed in section 4.2.