Project Number:	AD1006	
Project Title:	EuroView - X.500 Directory Services for Administrations in Europe	
Deliverable Type:	PU	

Deliverable Number:	D4.2	
 Contractual Date of Delivery:	14	
Actual Date of Delivery:	17	
Title of Deliverable:	EuroView Service Design	
Workpackage contributing to the Deliverable:	WP04	
Nature of the Deliverable:	RE	
Author:	Andrew Findlay, Damy Mahl	

Abstract	This document encompasses several aspects of the service design. The main elements include network infrastructure and connectivity and, to a lesser degree, user access methods. Emphasis is placed on simplicity of design whilst maintaining the highest possible level of efficiency.	
Keywords	SERVICE
NETWORK
INFRASTRUCTURE
ACCESS 	
Classification		

Name of Client:		
Distribution List:		
Authorised by:	Damy Mahl	
Issue:	1.1	
Reference:		
Total Number of Pages:	21	
Contact Details:	Phone: +44 1895 203061
E-Mail: Damy.Mahl@brunel.ac.uk	

Table of Contents
PART I	Title Page
Part II	
Document Control	
Executive Summary	
Scope Statement	
PART III	
1. Introduction	
2. Design Considerations	
3. Overview	
3.1 The Directory Database	
3.2 The Distributed Database	
3.3 Directory System Agents	
3.4 Chaining	
3.5 Referral	
3.6 Shadowing	
3.7 Relay DSAs	
3.8 Transport Bridges	
4. Choice of Technology	
4.1 DSA Implementations	
4.2 LDAP Implementations	
4.3 Hardware Platforms	
5. Connectivity and Naming	
5.1 Links With DANTE NameFLOW	
5.2 Backbone Connectivity	
5.3 User Connectivity	
6. Data Shadowing	
6.1 Shadowing	
7. Security Issues	
7.1 Firewalls	
7.2 Strong Authentication	
8. Service Performance	
8.1 Server Availability	
8.2 Network Availability	
8.3 Service Management and Monitoring	
9. Use of X.500 1993	
PART IV	
1. Bibliography	
2. References	

Part II
Document Control
Issue Number	Issue Date	Reason for Change	
1.0	6/3/97	Version One for Peer Review.	
1.1	17/5/97	Switch to a purely X.500/1993 orientation, remove terminology associated with Quipu.	
			
Executive Summary 
The goal of the EuroView project is to demonstrate the viability and utility of a directory service for European Administrations. EuroView will employ X.500/ISO 9594 technology for the core services, and will provide user access with LDAP and HTTP (World Wide Web) protocols. Profiles and naming conventions will be co-ordinated with DANTE NameFLOW and the IDA directory project. The diverse network environments of the users will be supported by using relay servers and data replication, both of which also contribute to security and performance. It will be possible to link any standards-compliant X.500 server to the EuroView system, but the core service will be built solely using products derived from Isode Limited source code.
Scope Statement
This document considers a solution to the infrastructural requirements of the EuroView users community. The ultimate goal is to formulate a design that overcomes the multi-protocol nature of the community and provides a useful and efficient method for service provision. The core network must provide optimal performance between EuroView administrations, though links to other European communities, particularly NameFLOW, are requisite. Related EuroView documents are “D3.1 User Requirements Report” and (when available) “D7.1 User Access Plan.”

PART III
1.		Introduction
The goal of the EuroView project is to demonstrate the viability and usefulness of a directory service for European Administrations. The technology chosen to implement the service is X.500/ISO9594, an international recommendation developed by ISO and the ITU standards bodies. The X.500 technology has been the subject of a number of pilot services around the world. Most of these pilot services are now beginning to become established, although competition is appearing in the form of other protocols: some related and some unrelated to X.500. The most notable of these is LDAP, a lightweight directory access protocol, originally developed to ease hardware and software requirements for desktop X.500 access.
Recent developments have established LDAP as a popular access method to directory systems. X.500 DAP is perceived by some people as being too complex and bearing too heavy a requirement on hardware. The flipside to this is that though the competing technologies are simpler, they often lose out in terms of flexibility and overall functionality.
X.500 (the Isode Limited implementation in particular) has been adopted as the base technology for EuroView because of its ability to interoperate in an environment employing several transport protocols. This is a very important factor as the set of validation sites are connected via different networks, using either TCP/IP or X.25. Having said this, the infrastructure will utilize the Internet for basic connectivity. Users of X.25 will in effect be patched in to the service using gateway services.
It should be noted that use of a single implementation would not be recommended in a wider service, in order to promote real interoperability and to promote vendor competition.
Service access will be provided using a range of access protocols, including DAP, LDAP, and HTTP. 
Well designed service infrastructure is the most important aspect of any networked service. This is especially true of the EuroView service due, mainly, to problems presented by the multi-protocol environment of the pilot users. The requirement for rapid response times (ideally in the range of a few seconds) aggravates this. The directory contrasts with services like electronic mail where relatively lengthy latency times between request initiation (mail submission) and completion (mail receipt) are the norm. As a result, acceptable service levels are somewhat more difficult to attain.
Factors affecting integration and performance are:
•	Network connectivity/available bandwidth.
•	Transport protocols used, and the resulting need for gateways.
•	The number of systems involved.
•	Level of data replication employed.
•	Database sizes, and how well implementations cope with these.
•	Security requirements, especially with regards to use of firewalls.
Much of the detail of this document is a direct response to the needs of the validation sites as reported in the “EuroView User Survey”. Case by case detail is provided where necessary, especially when the needs of a particular site are problematic or unusual.
2.	Design Considerations
The user survey revealed several specific requirements:
1.	Very few organisations have direct links between end-user computers and national or international networks. Some have no ‘outside’ links at all, but most expect to connect in some way in the near future.
2.	Requirements for response times and service availability vary widely. To satisfy all respondents, EuroView should aim for searches to complete in less than ten seconds. The service should be resilient to the failure of individual components.
3.	Organisations want rich data for internal use but wish to publish a much smaller set of information to external clients.
3.	Overview
In order to understand how a directory service might operate in a multi-protocol environment  an overview of the X.500 mechanism is necessary. Several important techniques are employed to achieve a reliable and effective service. The major ones are described later in this chapter, though we start with a look at how the system “hangs together” by looking at the structure of the directory database and how servers in the system interact with each other.
The information presented here is an overview, and some points are glossed over. For full details see the text of the standard, X.500/ISO 9594. Information on implementation specifics can be found in the Isode release manual set.
3.1	The Directory Database
The directory database is made up of a set of directory entries, where each entry usually maps onto some real world object, such as a person, organization or country. Each entry consists of a set of attributes, where each attribute is made up of an attribute type and one or more associated attribute values. Examples of attribute types are countryName (abbreviation C), organizationName (abbreviation O) and postalAddress.
Entries in the database are organized into a hierarchical tree. This tree structure is known as the DIT, short for directory information tree. At the top of the tree is a notional root beneath which is a set of country entries. Below each country there are typically a number of organizational entries, and in some cases (like that of the United States) entries of other types, such as states or provinces. An illustration of the database’s tree structure is shown in Figure 3-1.

Figure 3-1. Example Directory Tree

Each entry has a naming component, called its relative distinguished name (RDN). The RDN consists of one or more distinguished attribute-value pairs from the entry. The attribute may have more values which are not relevant to the entry’s RDN. For country entries the RDN of an entry is specified as being the countryName attribute; the name of the entry for Great Britain is countryName=GB, usually abbreviated to c=GB. The RDN specifies the name relative to its parent entry. The distinguished name (or DN) on the other hand specifies exactly where the entry is positioned in the DIT. The DN of an entry is the concatenation of an entry’s RDN with the sequence of RDNs of all entries above it in the tree. In Figure 3-1 the DN for the entry “o=Dr. Materna GmbH” is as follows:
c=DE, o=Dr Materna GmbH
The structure and content of the directory information tree is enforced by a set of rules called the directory schema. The schema used by the EuroView project is specified in EuroView deliverable D4.1.
3.2	The Distributed Database
The X.500 database is distributed. This means that each server only holds a fragment of the complete database. The reasons for this are manifold, with the greatest plus being the property of local manageability. Looking back at Figure 3-1 this means, for example, that the data belonging to Dr. Materna is managed and controlled by Dr. Materna. Sensitive issues related to the data such as access control (what is presented and to whom), data organization (how it is presented) and maintenance (how up to date is) are local responsibilities.
From a technical standpoint the advantage of using a distributed database is that the system is scaleable. The directory should work just as well with many participating organizations as it does with just a few. Also the introduction of a new server does not require reconfiguration of every other server in the system, though more of this later.
3.3	Directory System Agents
X.500 servers are referred to as directory system agents, abbreviated to DSA. Each DSA can hold part of the overall database. In an oft seen case this could be equivalent to an organization running a server to hold all of its local data in the directory. Users of that organization can contact the DSA using a DUA (directory user agent) in order to access directory data, e.g. to query another user’s e-mail address. If the requested  data is local, i.e. it belongs to the organization running the DSA, then the server just queries its own database for the required information and returns it to the users. This is the simple scenario. In the situation where a user wishes to access data held in a remote part of the directory the DSA takes the following steps:
1.	Determine which DSA contains the required data.
2.	Request the data from that DSA.
In X.500, step 1 is the critical phase. In order to satisfy this step, each DSA contains some knowledge of other DSAs in the system. Knowledge of another DSA is referred to as a knowledge reference. A knowledge reference describes a DSA in terms of how to reach it and also what data it is responsible for. Specifically, it contains the following information:
•	Type of reference.
•	DSA contact point (its address). 
•	DSA authority, in other words the data it has access to or has further knowledge of (this is referred to as specific knowledge). 
The unit of data authority in the knowledge scheme is a naming context. A naming context is a set of entries contained in a partial subtree, as well as a set of knowledge references. Each naming context can only be mastered by a single DSA, but copies can be held by other DSAs. The DSA holding the master version of a naming context is said to have administrative authority over that naming context.
In the case of a DSA holding all of the data belonging to an organization the one and only naming context held by that DSA is all of the data for that organization. The partial DIT in Figure 3-2 shows the data subtree for Dr. Materna. In the simple case described above, the whole subtree corresponds to a single naming context.

Figure 3-2. A Naming Context
The example DIT in Figure 3-1 is shown divided into a set of naming contexts in Figure 3-3.

Figure 3-3. Example DIT
A DSA must contain a minimal set of knowledge references for each of the naming contexts it has authority over:
1.	Superior Reference The DSA must have a reference to a superior DSA that is ‘nearer’ to, and knows how to get to, the root of the directory tree. So in Figure 3-3 DSA 4 must contain a reference to either of DSA 1, 2 or 3.
2.	Subordinate References The DSA must have references to all DSAs that hold naming contexts subordinate to contexts for which it has authority. So, looking at the same diagram, DSA 1 must have references to its subordinates: DSA 2 and DSA 3. Similarly DSA 2 must hold references to DSA 4 and DSA 5. 
In general terms a DSA uses its superior reference when it is requested to supply data which it does not hold. Subordinate references are employed when a DSA is requested to obtain data in a subordinate context. Looking at Figure 3-3, the DSA for Spain (DSA 3) will contact its subordinate, DSA 6, for information on information held in the “o=Sema Group” subtree.
Another important form of DSA reference is the cross reference, which refers to a DSA holding data in a non-local and/or non-subordinate naming context. By holding a cross reference a DSA gains knowledge of how to directly access the data held in a naming context, without resorting to a superior reference. This has the effect of limiting the number of hops required to access that data to one.
3.4	Chaining
There are two modes in which interactions between DSAs can occur. The first of these is the chaining mode. Here a request is passed between DSAs until a DSA containing the appropriate part of the DIT is located. The result of the initial request is then passed back along the chain of connected DSAs. 
Figure 3-4 depicts a chained operation. The operation represented is a request by a user at Dr. Materna in Germany for data in Sema Group in Spain. In this diagram the order of interactions is defined by the numbers associated with the interaction arrows. The individual requests made are:
1.	Materna client DUA requests Materna DSA for data.
2.	Materna DSA uses its superior reference to contact the DSA for Germany.
3.	German DSA uses a subordinate reference of the root to contact Spanish DSA.
4.	Spanish DSA uses a subordinate reference to contact the DSA for Sema.
5.	The Sema DSA returns a request result, which is chained back through the established connections.

Figure 3-4. Chaining Mode

This example shows how the system might work. It is important to note that the number of steps taken will in fact be reduced by establishing cross references between the Materna and Sema DSAs. In this case the Materna DSA would connect to directly the Sema DSA, eliminating the need to contact the national servers.
Cross references between EuroView DSAs will be established by hand. The use of cross references in this way has the cost of reducing the scalability of the infrastructure because the number of cross references increases exponentially against the number of DSAs. This is not a problem with the EuroView infrastructure as use of this technique is likely to be reserved for the central EuroView DSAs running at the project partner sites. 
3.5	Referral
In this mode, chained operations between DSAs are not used. A DSA receiving a request for which it has a further knowledge reference will not pass that request on, but will pass back a referral to the next DSA in the chain. Referrals contain a knowledge reference to another DSA. 
The client (be it a DSA or DUA) must take note of that reference and then pass the original request to the referenced DSA.

Figure 3-5. Referral Mode
Referral is a request mode often used when a stronger level of security is required, because referral mode requires that the client connect directly with each DSA contacted. In chaining mode the data may pass through several extra DSAs.
3.6	Shadowing
It is often the case that a particular server cannot be reached easily, or that data cannot be transferred very quickly. This may be due to a combination of factors: low bandwidth connection, slow or many intervening DSAs, etc.. In such cases it is often desirable to replicate data contained in a master DSA, to another more accessible server. Replicating data across DSAs has a number of benefits for the overall service:
•	Fault tolerance. If one DSA is down then another may hold the required data.
•	Optimization. A DSA holding replicated data may be nearer to the user.
•	Access to unreachable data. Data held on a private or inaccessible network can be made available  by replicating data to a more accessible DSA (e.g. a user on the Internet may not be able easily reach a DSA running on an X.25 network).
3.7	Relay DSAs
The EuroView service must run in a multi-protocol networking environment. Most DSAs run at user sites will, however, run in a single protocol environment, and as such does not have any direct access to servers on other networks. For example a DSA running in a purely X.25 community has no direct access to the Internet. One possible solution to this is to configure a relay DSA that has access to both networks. The relay DSA can then pass requests from the uni-protocol server to appropriate servers in other networks. In some cases the DSA pointed to by a superior reference can (implicitly) act as a relay. When the superior DSA cannot serve this purpose a relay has to be configured.

Figure 3-6. Relay DSAs
Figure 3-6 shows a relay DSA acting as a relay for access to DSA 1 (sitting on a private X.25 network). The relay advertises itself as an access point for the data actually held in DSA 1. 
3.8	Transport Bridges

Figure 3-7. Transport Bridges

One of the important conclusions from the user survey was that many validation sites use one protocol for internal LAN use and another for any external connection. It is not unusual for a site to have users working on a TCP/IP local network, with X.25 used for external access. If there is a local DSA that is connected to the LAN and has external connectivity the problem goes away, as users can connect to the DSA using TCP/IP, with the DSA then making external connections using X.25. In many cases EuroView users will not employ a local DSA and will access the central service. In this situation a transport bridge can be used as an alternative. A transport bridge is a protocol gateway that uses the Isode communicatons stack to convert calls from one network protocol to another. 
4.	Choice of Technology
This section details the software and hardware platforms adopted by EuroView. A number of factors influence the choice of platform:
•	Up to date implementations.
•	Reliability.
•	Efficiency.
•	Previous experience with the platform.
•	Vendor planned upgrade paths.
4.1	DSA Implementations
In principle, any implementation of X.500 can be connected to the EuroView directory. However, to contain the support effort required, the partners have agreed to standardize on products based on the Isode Limited software for the core DSAs. Two DSA implementations are available: IC-DSA which supports both X.500 (1993) and LDAP, and Quipu which supports X.500 (1988) and the Internet extensions.
The major advantage of the Isode software is that it is provided in source code form. This means that the software can then (potentially at least) be tailored to specific requirements. One implementation enhancement currently under consideration is improvement of the existing search algorithms to work better with international character sets.
4.2	LDAP Implementations
At present there is only one widely available public domain version of LDAP, and that is the release made by the University of Michigan. Commercial implementations are beginning to appear, though these are all derived from the Michigan code. The public domain code has undergone a number of releases, and is known to be a stable piece of software.
4.3	Hardware Platforms
The recommended hardware platform for EuroView servers are Sun Sparc machines running a reasonably up to date version of the Solaris operating system (the current version being 2.5). This is the test reference platform for the Isode Limited source release and is thus likely to be the best hardware on which to run the service.
5.	Connectivity and Naming
This section discusses connectivity issues relating to both the EuroView backbone and access to the backbone by EuroView users. The user group is divided into two types: those wishing to run a local DSA, and those unwilling or unable to run on site X.500 services. The second of these user classes is likely to use the directory by connecting to the centralized EuroView service and are discussed more fully in the User Access Plan.
The main connectivity problem is effective bridging between the Internet and X.25 communities. This presents a particular difficulty as Administrations in different countries make use of different protocols, e.g. the Spanish and German validation sites mainly have X.25 connectivity whilst those in Britain are connected solely via the Internet.
In general national and international connectivity will be provided by using the Internet as the core network. Relay DSAs will be used to link national and X.25 networks and private networks to the core infrastructure.
5.1	Links With DANTE NameFLOW
The NameFLOW service grew out of a project that started in 1991 as part of a pan-European networking project for the research community, called COSINE. Its purpose was to establish an international, standardised, distributed directory to store contact details of researchers, including e-mail addresses, so that members of the community could find information about other organisations and people quickly and easily. NameFLOW is now a fully fledged service providing access to hundreds of organizations and over two million individual entries across Europe. It also acts an umbrella organization that coordinates the activities of several national directory services. EuroView will coordinate naming and technology with NameFLOW so that links can be made when required without major upheaval. The NameFLOW system will be used to provide links into and out of the EuroView service, however, it is intended that communication between EuroView DSAs will be restricted to the EuroView infrastructure.
5.2	Backbone Connectivity
One DSA running at each of the project partners sites will form the “backbone” of the service. Each of these servers will have full Internet access, with the Spanish DSA having national X.25 connectivity. The DSAs are summarized in Table 5-1.

DSA DN	Site	Connectivity	
c=DE, cn=EuroView-DE	Dr. Materna, Dortmund	Internet, X.25	
c=ES, cn=EuroView-ES	SEMA Group, Madrid	Internet, X.25	
c=GB, cn=EuroView-GB	Brunel University, London	Internet	
Table 5-1. EuroView Backbone DSAs

Each of these DSAs will be second level DSAs, subordinate to first level national DSAs. The relationship between DSAs can be looked at in two ways: protocol map and knowledge model. The protocol map depicts the connectivity of all supra-organizational DSAs that are expected to be accessed by the EuroView service (this does not include slave or backup DSAs).
The EuroView service has been designed to allow for links with DANTE NameFLOW in each country. This requires consideration of national DSAs as well as network infrastructure. Table 5-2 and Figure 5-1 summarize the links involved.
DSA DN	Masters	Connectivity	
cn=Puma	c=DE	Internet, X.25	
cn=Iguana	c=ES	Internet	
cn=Inca Dove	c=GB	Internet	
cn=Rockhopper Penguin 	c=AT	Internet	
cn=Giant Tortoise	ROOT	Internet	
Table 5-2. Higher Level DSAs

Figure 5-1. Protocol Map
All of the EuroView service DSAs have direct Internet connectivity, and indirect International X.25 via the first level national servers of Germany or the Spanish EuroView server. In the case of peer activity, i.e. communication between EuroView, servers the Internet is always used for direct connection.
Cross references will be established between EuroView DSAs to reduce the dependence on the national NameFLOW DSAs.
5.3	User Connectivity
Having established the general level of accessibility of the EuroView backbone the next step is to consider how validation sites will connect to the service. Table 5-3 lists users by external connection type. 

Validation Site	Country	Connectivity	
MAP	Spain	X.25	
MAS	Spain	X.25 (via MAP)	
AA	Germany	X.25	
Magistrat Wien	Austria	Internet, X.25	
DTI	United Kingdom	Internet	
CCTA	United Kingdom	Internet	
Table 5-3. Validation Site Connectivity
There is no problem with connectivity in the UK as all validation sites have Internet connectivity. Whilst this is not the case in Germany the situation is alleviated greatly by the fact that the German national DSA has both Internet and X.25 capability. This DSA will relay requests from the Internet to German X.25 sites. Similarly external requests (e.g. from EuroView Internet users in other countries) will be relayed via the national server.
The Spanish sites represent a problem in that user access must be via X.25, whilst the national server does not have the relevant capability. The Spanish EuroView server, situated at SEMA, has both Internet and X.25 and will act as a relay. User DSAs in Spain will use the central DSA as a superior reference (thereby using the EuroView server as a means of accessing the global X.500 service). Conversely the Spanish central DSA will act as a relay and advertise itself as the access point for data held in the user DSAs. 
The bi-protocol Sema DSA can equally act as a relay DSA for all EuroView servers, thereby ensuring that data within the EuroView service, be it on a public X.25 or Internet DSA, will be accessible to all EuroView users.
6.	Data Shadowing
Though it may be possible to chain requests to a particular server, the result may be unsatisfactory for any of a number of reasons, such as slow service response due to lack of bandwidth or due to a excessive number of “hops” in the form of chaining (connection overhead). Replication of data, using the techniques of slaving and shadowing, can often result in much better levels of service performance and availability. This is because the same data is made available from a number of DSAs; DSAs which may be more accessible to certain user communities.
Caution should be exercised though, if, for example, the amount of data being replicated in a shadow agreement is great then the shadow operation itself can cause service degradation! 
6.1	Shadowing
The notion of data replication was introduced to overcome problems of efficiency and access. In EuroView two levels of shadowing will be necessary.
•	Country Level
Replication of the country level is necessary to reduce the need for access to first level servers, which tend to respond slowly due to excessive usage and also to limit the number of simultaneous connections supported. In this case the amount of data copied is minimal and the performance gain is appreciable, and so should be configured into EuroView backbone and user DSAs.
•	National Level
National level organizations and DSA entries will also need to be shadowed in EuroView backbone DSAs. This may be limited to organizations and servers that are part of or related to EuroView, depending on the amount of data that needs to be copied, and the required degree of interworking with other directory services such as NameFLOW and IDA.
•	Organizational Level
In some instances it may be necessary to replicate the entirety of an organization’s directory data between EuroView DSAs. Replication may well be critical in the Spanish case where a relay DSA will be employed to provide connectivity. As this is a single point of access between directory communities (the Spanish X.25 users and the rest of the EuroView service) any server downtime or network failure would result in loss of service. Replicating Spanish user data to each of the central services will add a large degree of fault tolerance to the system and improve performance greatly. This may present a resource problem depending on how much data is stored by the Spanish contingent. 
7.	Security Issues
Two major security issues exist:
•	Use of firewalls.
•	Requirement for strong authentication, leading to the need for certification authorities.
7.1	Firewalls
A ‘firewall’ is a network component that links a secure network to a less secure one. It controls the type of traffic that can flow between the two networks according to some security policy. The nature of firewalls is to restrict network traffic; in terms of what is allowed through the firewall (packet filtering) and also the mechanisms permitted (trusted software and services). 
Firewalls often have two parts:
•	Network routers which perform packet filtering and limits connections between the internal and external networks.
•	Bastion host (or “application gateway”) which is a host machine that is used to run proxy services. A proxy service is an intermediate gateway that handles, monitors and ‘vets’ communications between a client (e.g. a Web browser) and a server (e.g. a Web server). Examples of protocols that can be handled by an appropriate server are Telnet, FTP and Web.
Introduction of a new service into an environment where a firewall is in use can be difficult, especially when the new service may work in a way not currently supported or easily handled by the firewall without compromising its integrity. As such it is probably better to set up a service to work within the current restrictions of the firewall rather than to adapt the firewall to the service. In particular if no application proxy is available for the service then other means of protection must be considered.
The important questions for a directory service as envisaged by EuroView, are:
•	Will the DSA sit inside or outside of the firewall?
•	Similarly will LDAP or Web/X.500 gateway positioning be problematic?
The DSA is likely to be placed outside a secured network as this eliminates the need for filtering of incoming connections to the DSA, because all externally initiated connections will not need to access services guarded by the firewall.
This, though, assumes that data held by the DSA is not regarded as overly sensitive and in need of protection. Where access to sensitive data is an issue one answer may be to implement two servers. One DSA positioned within the secure perimeter holding sensitive data with the DSA holding “public” data outside the secure boundary or, if appropriate, on a bastion host. This is not a perfect solution as it makes restricted external access to the sensitive data, using access control, difficult to achieve.

 Figure 7-1. Example DSA and Firewall Configuration

A configuration that goes some way to satisfy the needs illustrated above is depicted in Figure 7-1.
The issue of LDAP and Web/X.500 gateways is less sensitive, as connections to these can reasonably be limited to internal users. The only connections initiated by these gateways will be directly to the organizational DSA. It should then be reasonable to limit access to the gateways by placing them inside the firewall perimeter. If the DSA is outside the boundary, then connections from the gateway to the DSA will have to be enabled using the appropriate means. The behaviour of Web gateways can be further controlled by use of Web proxy servers.
An application proxy for X.500 services, called the Guardian DSA, has been developed by the ICE-TEL project. The Guardian DSA performs filtering operations on all X.500 operations passing through the firewall, and can in this way limit the external view onto an internal DSA, e.g. by preventing or limiting external access to internal data, such as telephone numbers, addresses or pointers to internal documents. The Guardian DSA is a promising development, and will be evaluated by EuroView for possible use in the service.
7.2	Strong Authentication
The X.509 standard defines a strong authentication system based on public-key cryptography. This provides much better proof of identity than simple password based schemes.
As yet there is little requirement for strong authentication. However, secure communication will need to be implemented if global and widely accessible directory services are to become a reality. Strong authentication is essential if security of data depends on access controls in DSAs. Further the storage and delivery of authentication certificates is likely to be a major requirement to support other applications.
8.	Service Performance
EuroView will strive to provide the levels of service determined in D3.1 User Requirements Report. Performance levels will vary, and are dependent on a number of parameters:
1.	Connection bandwidth between client and server.
2.	Connection bandwidth between EuroView DSAs, central and local.
3.	Level of chaining required to satisfy a request.
4.	Need for intermediate gateways.
In the simple case of a user accessing a central EuroView DSA directly via a fast Internet connection the service can be expected to match up to requirements. A less optimal situation would be that of a user in the UK on a local network connecting via public X.25 to a gateway machine in another country (possibly Germany), and then looking up data held on a server running on a local site back in the UK. This is a complex and patently inefficient scenario, unfortunately one for which rapid response times cannot be enforced within limits of available resource. However some guarantees can be made (e.g. availability of central services), and some specific actions can be taken to monitor and maintain the X.500 service.
8.1	Server Availability
EuroView plans for central DSAs to be accessible 24 hours a day and 7 days a week. Totally uninterrupted service is probably not possible, as software faults are always likely to occur. To counter this DSAs will be run in “auto start” mode. This means that if a DSA crashes, a wrapper program will restart the server automatically. This will minimize down time in individual servers. Use of replication between EuroView DSAs should ensure that the system is tolerant to failure of a single server. In this case, though the service is still online, performance levels may well be reduced.
8.2	Network Availability
Although “best efforts” will be made to maximize network availability in practice this will be difficult. The UK DSA running at Brunel University is a good example. The UK Academic network has no quality of service agreements for availability, and, as a result, EuroView can offer no service agreements for service availability. In practise, however, the network  is nearly always accessible and availability should be near 100%.
8.3	Service Management and Monitoring
The server software provided by EuroView has support for the SNMP network management protocol. The EuroView partners do not make use of SNMP for service management and monitoring are unlikely to do so during the course of the project, as the gain in service assessment is unlikely to match or exceed the cost of setting up and maintaining management, especially if  performed on a one-off basis. 
SNMP may well be used to generate statistics on DSA usage. At present the following aspects of DSA usage can be monitored:
•	Number of anonymous connections made.
•	Number of unauthenticated connections made.
•	Number of connections made using simple authentication.
•	Number of connections that have been rejected for security reasons.
•	Total number of operations forwarded to this DSA from other DSAs or DUAs.
•	Number of individual user operations of any type handled by this DSA.
•	Number of referrals returned by this DSA.
•	Number of errors (security or otherwise) returned by this DSA.
•	Current number of incoming and outgoing associations.
The figures outlined above can give a good overview of DSA usage, but they will not give any strong indication of DSA performance. The best way to do this is with a DSA probe. A probe is a piece of software that sends requests to a DSA at regular intervals. The requests sent can be something as simple as a connection request (is the DSA up?), or else some random timed query (how quickly does the DSA satisfy real world requests and does it find an appropriate answer?). Probes can provide a good measure of how well a DSA (and indeed the service overall) responds to the kinds of requests that users are likely to make.
Probes are often difficult to set up and maintain. An even better solution may be to analyse the log files of a central DUA service. A possibility here is the proposed central Web/X.500 gateway. All requests and responses made via this route are logged, with the log file containing the exact query made, response time and success or otherwise of requests.
9.	Use of X.500 1993
X.500 1993 implementations have been put through their paces in a series of interoperability tests run by DANTE as part of the preparation for its upcoming transition to 1993. The conclusion of these tests were that the various systems were still not ready for service deployment. Some of these problems were due to bugs in some of the new implementations. Some came about as a result of deficiencies in the standard itself. The most notable of these is the issue of management of the root context. The root context is the root entry plus the set of subordinate references to the first level entries, i.e. national master DSAs, countries and other global entities. At present the standard stipulates that each first level DSA gains a copy of the root naming context by setting up individual bilateral agreements with each DSA that masters data at the first level. This is problematic as the method results in too great a number of agreements to maintain. A proposal currently being considered is to set up a DSA that holds agreements with each DSA at the first level and keeps a copy of the entire root context. All other DSAs can then maintain copies of the root context by making a single agreement with this DSA. The exact details of the mechanism have yet to be pushed through the ISO and ITU standards bodies. Until this, and other problems, are fully resolved it will not be possible to build a fully X.500 1993 compliant international directory service. EuroView is co-operating with DANTE and other directory service providers to resolve the issue. As an interim measure, EuroView will use X.500 1988 Quipu DSAs to service the higher levels of the DIT.

PART IV
1.		Bibliography
1.	ITU X.500/ISO 9594 “The Directory - Overview of Concepts, Models and Services”.
2.	“Administrator’s Guide: X.500(1988) Directory Services”. Isode Limited Manual Set.
2.		References
1.	“The NameFLOW Paradise Directory Service”, http://www.dante.net/nameflow.html
2.	D4.1 “EuroView User Survey” Angel Inglada Fernandez. Sema Group, Madrid. May 1996.
3.	Deliverable 6 “Guardian DSA”, ICE-TEL Project, http://www.darmstadt.gmd.de/ice-tel/