Integrity and Security of the Application Level Active Networks Ognjen Prnjat, Temitope Olukemi, Ioannis Liabotis, Lionel Sacks University College London, Torrington Place, London WC1E 7JE, England phone: +44 20 7679 3198; email: {oprnjat | tolukemi | iliaboti | lsacks}@ee.ucl.ac.uk Abstract The advances in programmable networks enforce the importance of ensuring and maintaining the integrity and security of the network and the supporting systems. In the future programmable network scenarios, the threats to integrity and security will rapidly increase as third-party value added service providers and end-users start deploying their customised applications on the operator infrastructure. Here we discuss some typical integrity issues relevant in the programmable network scenarios. We introduce the Application Level Active Networking (ALAN) principles, and the basic management principles of ALAN-enabled networks, developed by the IST project ANDROID (Active Network Distributed Open Infrastructure Development). In this context, we discuss the candidate approach to managing the integrity issues in ALANenabled networks and reflect on some integrity-oriented techniques. Finally, we focus on security management, and briefly describe the ANDROID security architecture.

1 INTRODUCTION Convergence between computing and telecoms is most apparent in the field of programmable networks. Developments such as active networks, open network APIs, and mobile agents anticipate the future environment where the IT world, rich in applications, will cohabit with the telecoms world, rich in networks. By exploiting these technologies, third party application developers and end-users will have the access to the network control and infrastructure traditionally operated and run by the dominant Telcos. This scenario of open network provision is strongly driven by the deregulation forces in Europe and the US; and the market trends towards rapid and efficient development and deployment of user-customised services. Demands for services are diversifying, and the requirements of availability and functionality increase as the business and industrial processes become ever more dependent on communications. Environment is thus forming, in which the 3rd party, value-added service providers, or even end-users, will develop customised applications, exploiting the infrastructure provided by the Telcos, by accessing it at

the considerably lower level of control than it was previously possible. Network operators will have little knowledge of the logic of the applications deployed over their control plane, the active packets travelling through their networks, or the pieces of mobile code deployed on their equipment. However, they will require the assurance from the application developers that their applications will not harm the operation of the operators' control systems or the network as a whole. They will require a guarantee that the integrity of their support systems and the network is preserved. Integrity is defined as [Ward95] "ability of the network to retain its specified attributes in terms of performance and functionality". The bestdocumented integrity breach is the January 1990 brownout [McDo94] of the AT&T American network. A control mutation originating in the switching system propagated through the signalling network causing degradation of operation and ending in a shut-down. The whole eastern seaboard of the US lost telephone connections for nine hours, with the financial loss of 1 billion dollars. A number of similar integrity breaches followed in Pacific Bell and Bell Atlantic networks in the next two years [Hoan93]. Considering these incidents, the established operators should demand assurance before opening their networks to less experienced players whose actions might endanger operation of the network. Integrity issues are crucial in the future telecoms scenarios [Prnj00b], where a number of players in the market will have to interwork, on both service and management levels, while having to be confident that this interworking will not jeopardise the correct and proper functioning of the networks and systems. This paper discusses the integrity issues likely to be encountered in the future open environment. Next, programmable network approaches are discussed, with the focus on the Application Level Active Networking (ALAN) architecture. Then, we focus on the methodology for management of integrity in the ALAN environments. Finally, we briefly present the security architecture for ALAN-enabled networks within the context of the IST project ANDROID.

2 INTEGRITY ATTRIBUTES Integrity is a broad term, encompassing a variety of issues concerning system structure, functionality and behaviour. Integrity can be decomposed in a set of attributes [Prnj99a][Prnj00a], some of which overlap with certain concepts established in the general computing fields of dependability and safety. Some basic system integrity concepts are outlined below. Security refers to the ability of the system to detect and avoid intentional external attack. In this paper, we consider security as the most distinct attribute of integrity. Robustness is the ability of the system to handle unexpected events. A system that is robust can cope with all eventualities and continue operations. Reliability is [Reib91]: “the probability of a system performing its purpose adequately for the period of time intended under the operation conditions encountered”. Resilience is the ability of the system to recover from faults. Availability is “the percentage of time during which the system is operational and conforms to its specification” [Vill92]. Performance is the throughput of the system, often traded off against functionality. Scalability is the impact on performance as more entities (processes, devices etc.) are added to the system. Data Coherence: the information copied or distributed through the system needs to remain consistent through time and change of circumstances. Liveness means that system can be live at all times: a system might not remain live because it is in a state of either deadlock, when it is expecting an event which cannot occur; or livelock, when it oscillates between a closed set of states that it cannot leave. Feature Interactions refer to when two or more systems, each with well-defined and understood behaviour, result in unforeseen behaviour while operated together [Came93]. Complexity may be an assessment of how long an operation takes – known as time complexity. Computational complexity relates to how well a given procedure can be analytically described or determined. Data complexity refers to the complexity of data structures and their interdependencies. A high level of complexity, unless it is there to increase robustness, poses more threats to system operation and thus to integrity. A high level of coupling between system components indicates a high level of interdependence: a failure, or an integrity breach, can ripple through the system via the coupling paths. A distinct sub-attribute of integrity is risk. Here we view risk essentially as ~ 1/integrity, i.e. the higher the risk, the lower integrity. The topics described above are all interrelated. A system with poor scalability will loose performance as the number of entities it involves grows. This would reduce availability. Loss of performance and availability can impact on timing of dependent systems, by impacting on data coherence or the liveness constraints. Thus, a

framework for analysing the integrity issues and building the desired level of integrity into newly developed systems and applications is of crucial importance. This is particularly important in the future scenarios of programmable networks where the network operators will have no notion of what are the integrity impacts of opening their networks to the third parties.

3 ALAN AND ANDROID There are numerous approaches to programmable networks. The initial active network concepts are based on data packets which travel through the network carrying programs in their header which can run on network devices such as switches or routers [Tenn96]. These concepts progressed through active bridging [Alex97], where packets carry only the flag indicating the desirability of running a program. The latest initiative in this area is the Application Level Active Networking [Mars99a], on which this paper concentrates. Mobile agents are another big arena of research and development, telecoms [Karm97] applications including IN-based service provisioning, network management by delegation [Gold98] and personal communication services. The network programming interfaces provide an open access for service developers to the service components and network control in the operator domain [Laza97]. The Application Level Active Networking (ALAN) provides an environment in which developers can engineer applications through the network (terminal devices, edge nodes and network elements or service points); by providing platforms on which 3rd party software can be dynamically loaded and run [Mars99a]. Combined with a high performance IP network, this would provide a context in which a wide variety of network products and services could be engineered; thus providing a candidate environment for advanced data services, grid computing and ultimately the network computer. The ALAN system consists of regular client and server applications that are located in the existing Internet. Clients and servers communicate through Dynamic Proxy Servers (DPS) that are located in strategic points between them. DPS provides an Execution Environment for Proxylets - EEP. Proxylets are downloaded to the DPS and executed on behalf of the users. Those applications provide functionalities that enhance the level of service or introduce new services to the final user. End-to-end active services are provided by one or more DPS’s executing one or more proxylets. WWW servers can be used for proxylet storage. Messaging is done in XML and is carried over HTTP. These concepts were developed further in the IST project ANDROID, which focuses on the development of a scalable, lightweight management infrastructure for the

ALAN-based active networks. ANDROID system is an event driven, policy enabled management system [Mars00]. The focus of ANDROID is on developing the management for primary issues of starting and maintaining the services and on resource [Liab01] and security management. In the ANDROID context, an active network consists of a number of interconnected active nodes and non-active nodes. Active nodes are either active routers or active servers. Active routers support policy based management [Slom99] of router functionality using predefined active modules. Active servers allow user installation and management of application level software components (proxylets) (and thus are effectively ALAN DPSs). The default active server platform is FunnelWeb [FunnelWeb]. In ANDROID, active server is an end system with a full protocol stack, providing an execution environment capable of running user provided processes that are unrestricted above the transport layer. An active server can be considered as a single processor computer, a multiprocessor computer or a cluster of computers that are connected with high-speed links.

more interconnected active service(s) with connection to the terminal devices (Figure 2). For example a specific kind of caching hierarchy can be combined with a specific kind of multicast nodes to provide a specialised cached data stream – possibly with transcoding points to accommodate both mobile and fixed network users. Integrated service A Integrated service B PRX Type A

PRX Type B

PRX Type B

Active Sever

IP network

PRX Type A

Active Sever

End-to-end application

PRX Type A

PRX Type B

PRX Type B

Active Sever

IP network

User 1

PRX Type A

Active Sever User 2

Figure 2 - Active service

Management Element

Policy Store

4 INTEGRITY MANAGEMENT APPROACH Proxylet Type A

Proxylet Type B

Proxylet Type A

Execution Environment X

Proxylet Type B

Execution Environment Y

Operating System

Active Server Figure 1 - Active server architecture

The basic platform for ALAN/ANDROID active servers is shown in Figure 1. The key elements on the active server are: the proxylets providing the functionality for the active services (marked as "proxylet type A/B"; the EEP providing the execution environment for the proxylets; the management element, providing the management functions and the policy store storing the management policies, which are the bounding conditions for instigation and running of the active services. Note that each active server can accommodate one or more EEPs and that each EEP can accommodate one or more proxylets. An integrated active service consists of one or several proxylets of the same type, running on active servers, connected together with an IP network. An example of this might be a caching hierarchy or a transcoding point. An active application is then one or

The crucial issue in this context is to develop an applicable architecture and techniques for maintaining the integrity of communications networks which combine Application Level Active Network (ALAN) capabilities and a Quality of Service (QoS) enabled Internet Protocol (IP) based network. The techniques will need to be proactive, adaptive, highly automated and novel. Engineers concerned with constructing platforms have to develop several aspects of the system: the platforms themselves; example applications; security; and management and integrity methodologies. The following discussion effectively outlines an envisaged research proposal. Development

Testing

Integrity level

User/operational requirements

Validation tests

Operational integrity

System requirements

Verification tests

System integrity

Architectural design Detailed design

Integration tests

Integrated integrity Unit integrity

Unit tests

Construction phase

Figure 3 - Development lifecycle and integrity

A three dimensional approach to tackling integrity issues throughout the conventional system development lifecycle (Figure 3) has been developed in [Prnj99a] [Prnj00a]. The first axis, derived from the Hierarchical Object-Oriented Design (HOOD) [Robi92] methodology, considered the development cycles with the stages of: operational level (runtime / deployment), system, integrated and unit development levels (Figure 3). The second axis is derived from the Open Distributed Processing [ODP] viewpoints and considered the systems perspectives of: enterprise, information, computational, engineering and technology viewpoints. Finally, specific integrity issues were identified, as introduced in section 2. The framework enabled identification of integrity risk points that have specific meaning in the context of specific integrity attributes as seen from different viewpoints and at different stages of the development lifecycle (Figure 4). In addition specific techniques were developed [Prnj99b] [Prnj99c] for some of these integrity risk points. The context for this work was the classical design - build - deploy cycle of current distributed telecommunications systems in general, and management systems in particular. Integrity level

System viewpoint

Operational

Enterprise

System

Computational

Integrated

Information

Unit

Engineering Technology

Integrity attribute Robustness Resilience Availability Performance Scalability Data coherence Liveness Feature interaction Complexity Coupling Security Reliability

Figure 4 - Integrity framework

Some of these integrity concepts can be applied to certain aspects of ALAN and associated management systems. However, due to the dynamic aspect of these service platforms, some extension of the current approach is required and some new techniques will need to be developed. Specifically, the system integration and runtime integrity methodologies will need to be extended to accommodate the need to include program elements whose behaviour is not known completely a priori [Mars99b]. In the context of ALAN, the integrity levels can be perceived as follows. Unit integrity focuses on the single proxylet on an EEP. An integrated active service consists of one or several proxylets of the same type, running on active servers, connected together with an IP network. An example of this might be a caching hierarchy or a transcoding point. Integrated integrity level thus focuses on this. An active application is then one or more interconnected active service(s) with connection to the

user terminal devices. For example a specific kind of caching hierarchy can be combined with a specific kind of multicast nodes to provide a specialised cached data stream – possibly with transcoding points to accommodate both mobile and fixed network users. System integrity level focuses on this. Finally, operational integrity level considers the integrity of the entire service, in its relation to the environment, users’ influence, and influence of other services. At each of the integrity levels, specific integrity issues need to be considered. These issues are envisaged to be handled using policies and metadata associated with the proxylet [Mckee99]. Metadata is information on proxylets. Metadata can be developed on unit, integrated and service levels. In its basic form, metadata includes the interface description, constrains, and pre/post conditions [Mckee99]. For the purpose of integrity handling, metadata could contain also integrity information: scalability, performance; as well as relationship of components making up the service, collaboration information, in terms of the expected performance/resource usage of the collaborators. Finally, metadata should contain references to relevant management policies associated with the proxylet/service. In the first phase, covering the time between when an active service is requested and when it starts to run, ensuring that a set of diverse proxylets constitutes a working set needs to be verified. For unit level integrity, developing proxylets for a specific EEP and certification is important. At the integrated level, a network of one flavour of proxylets is built. It is possible to develop a set of metadata hints [Mckee99] to indicate to the management system the broad operational boundaries of the services to which these proxylets contribute. These hints should feed up to the systems and operational levels to circumscribe the behaviour and environment of the running services. Two other important techniques need to be developed at this level; the use of test data and watchdog signals. Both of these are normally available in classical network technologies. The only issue in this context is that requirements on these fronts are intrusive into the design of proxylets – i.e. requires the proxylet builders to modify their systems; rather than being something the communications provider does. At the systems level, specific services are constructed out of one or more flavour of proxylet(s) plus specifics of network connectivity and terminal equipment. At this level there are issues about how the different flavours of proxylets combine; for example in terms of resources usage, security, feature interactions, scalability, availability and such like. This information can be included in the metadata on this level. As for the classical case, some amount of pre-emptive decision

making can be made at this level to ensure that the application can run (admission control), that there are required dynamic resources and that the proxylets are resident on the best platforms (given demands from other applications and the condition of the communications network). At the operational level, the service is being exploited by the user community. The information available at this level is from the performance monitoring (resource usage patterns) and from the fault notifications. Depending on the strategies available from test data and watchdog facilities, extra information can be available to monitor in order to asses the running system for its integrity state. The above considerations can be combined into a full working system as illustrated in Figure 5. This diagram shows the generic information and action feeds through the proposed system. Parameterisations of the appropriate measurable integrity features are included in the XML metadata for use in the next stage. This information includes details about measurables, expectations and remedial actions. At the integration level proxylet service specific information is built. This is combined at the system level to accommodate the interworking between different proxylets and other resources such as network capacities / QoS and Service Level Agreements (SLAs). This information is combined with customer specific information to make decisions on resource allocation, platform choice and monitoring tasks at the operational level. It also provides envelopes – through policies – as to appropriate remedial actions such as when to inform operators, inform customers, reallocate resources, kill a service and what kind of information to feed back to refine the hints in the metadata. High level Faults, Warnings

Operational

Runtime: Fault, Perf Topology

Contingency Actions

Hints: System, User…

Compatibility Policies & Decisions

Systems Integration

Feed Back

Resource Usage Hints

Watchdog Hints

Test data Hints

Service Metadata

Customer SLA

Multiple Proxylet Dynamic / Static Network Single Proxylet

Figure 5 - High-level integrity architecture

The approach is generic. The information flows in the second phase (run-time: entire lifetime of the usage of the active service) are analogous. In addition the second phase live measurement of resource utilisation, performance and faults should be combined with historical data and knowledge of operational policies to forecast problems in individual service sessions or

network nodes. Each metric should be associated with a weighting factor. The value of the weight will itself depend on current and historical state, and also on an adaptive adjustment factor derived from the success of previous forecasts. A history based, adaptive mechanism is required since user demand is both fractal and continuously evolving. Forecasts would need to be used to schedule service requests so as to avoid incipient problems. The mechanism can also be used to forecast the impact of management actions. The system should be programmable, to enable evolution of control actions that the system can autonomously test and deploy (within bounds set by its operating policies). This is required since the input information is partial, and can never be sufficient to enable system wide optimisation.

5 ALTERNATIVE APPROACHES Some solutions to the integrity problem where offered in the area of active networks [Psou99]. Secure Active Network Environment (SANE) [Scot98] is a layered architecture, providing the static checks which ensure that the system starts in the correct state, and the dynamic checks on the per-user or per-packet basis. These checks include authentication, and securing the active node by providing a restricted execution environment for the 3rd party programs, as well as a naming scheme to partition the node resources. Proof Carrying Code (PCC) [Necu97] similarly focuses on the integrity of the active node, by attaching a proof of correctness to each active packet, which is checked at the node before program execution. Finally, a number of active network programming languages, such as Safetynet [Wake] and PLAN [Hick99] aim to ensure integrity at the level of the programming language by tightly controlling the processing time, memory allocation and threading, removing the requirements for run-time checks, and similar. These solutions seem effective for the protection of the active nodes themselves, but are not fully applicable in the integrated scenarios where particular integrity issues involving collaboration of a number of nodes and proxylets arise. Moreover, in the ALAN-base scenarios that we described above, a number of system and operational-level integrity issues must be considered.

6 SECURITY ARCHITECTURE This section deals with more specific security issues in the ALAN and ANDROID context. The security architecture developed for ANDROID is shown in Figure 6. Security is divided in three levels: user security, platform security, and management security. User security focuses on the security of the actual active application, in terms of end-end service, and thus belongs

to the operational integrity level. Platform security refers to the security provided by the management elements and policies in action on the active servers. This aspect of security encompasses proxylet deployer authentication, proxylet authentication and access control, and proxylet runtime monitoring. Thus, this belongs to the unit integrity level. The integrated and service integrity levels would be concerned with the inter-proxylet communications, which are not depicted here. Finally, the third aspect of security focuses on the security of the management information flow itself. SLA

SM

SM

Platform security

AS User security

active service

AS

policies

notifications

Management security

Management interface Proxylet Policy composition object Policy handler Security envelope Security manager

SM

Figure 6 - ANDROID security architecture

on the operator infrastructure. In this paper, we discussed some typical integrity issues relevant in the Application Level Active Networking (ALAN) scenarios. We have discussed a candidate approach and architecture for managing the integrity issues in ALAN-enabled networks and recommended some integrity-oriented techniques. Our focus was on security of the ALAN-enabled networks: we have presented the high-level security architecture developed for the IST project ANDROID, and have discussed a number of security-related issues in this context. The full development of such an integrity management approach and related techniques would benefit three principal communities: the network operators hosting the active network service platforms, the service providers who produce specific proxylets and those third parties providing the end systems. Each of these players on the market needs a framework to be able to specify a range of requirements and constraints so that products from one player are acceptable to the other. It is thus critical, for the deployment of the end-end services, that there are clear agreements, between the players, on security, reliability, safety, performance, availability, etc. - in short - integrity.

8 ACKNOWLEDGEMENTS

The above figure effectively depicts the decomposition of an operational-level SLA (performed by the policy composition objects) into policies which are in effect on the particular active servers (ASs) hosting the proxylets which support the end-end active service. The policies on the active server form a security envelope within which the proxylet can securely execute. The security policies are interpreted, and security envelope is formed, by the security manager. The security manager is to perform a number of security actions. Proxylet deployer authentication is to be performed using role/ID matching. The authentication of proxylets is to be performed using the JAR signing (since proxylets are Java archive - JAR - files). Proxylet access control is to be done through updating the FunnelWeb java.policy file which restricts the proxylet access to resources. Finally, the run-time proxylet resource usage monitoring should be performed on the active server. The security of management information exchange is envisaged to be done using XML signatures.

This work was partially conducted in the context of the IST project ANDROID. Authors would particularly like to thank Ian Marshall, Paul Mckee and Mike Fisher, all of BT, and Jan Vorbrüggen of MediaSec Technologies for discussions on some of the ideas presented in this paper.

7 CONCLUSION

[Hick99] M. Hicks et. al., “A Secure PLAN”, Proceedings of the First International Working Conference on Active Networks (IWAN '99), Springer-Verlag, 199.

Issues of ensuring and maintaining the integrity of the network and the supporting systems are increasingly important in the future programmable network scenarios, where third-party value added service providers and even end-users will be deploying their customised applications

9 REFERENCES [Alex97] Alexander et. al., "Active Bridging", Computer Communications Review, Vol. 27, No. 4, pp. 101-111, 1997. [Came93] E. J. Cameron, H. Velthuijsen, “Feature Interactions in Telecommunications Systems”, IEEE Communications Magazine, pp. 18-23, August 1993. [FunnelWeb] FunnelWeb http://dmir.socs.uts.edu.au/projects/alan/ [Gold98] G. Goldszmidt, Y. Yemini, "Delegated Agents for Network Management", IEEE Communications Magazine, Vol. 36, No. 3, pp. 66-70, March 1998.

[Hoan93] B. Hoang, D. J. Bastien, B. Lewin, “Common Channel Signalling Network Integrity Experiences from the US”, Proceedings of the IEEE Conference on Communications (ICC’93), Vol. 2, pp. 644 – 649, 1993.

[Karm97] A. Karmouch, "Mobile Software Agents for Telecommunications", IEEE Communications Magazine Guest Editorial, Vol. 36, No. 7, 1997. [Laza97] A. Lazar, "Programming Telecommunication Networks", IEEE Network, pp. 2-12, October 1997. [Liab01] I. Liabotis, O. Prnjat, L. Sacks, "Policy-Based Resource Management for Application Level Active Networks", Second IEEE Latin American Network Operations and Management Symposium LANOMS 2001; Belo Horizonte, Brazil, August 2001. [Mars99a] I. W. Marshall, et. al., "Application-level Programmable Network Environment", BT Technology Journal, Vol. 17, No. 2, April 1999. [Mars99b] I. W. Marshall, M. Fry, L. Velasco, A. Ghosh, "Active Information Networks and XML", in "Active Networks" ed. S. Covaci, LNCS 1653 pp. 60-72, Springer Verlag, 1999. [Mars00] I. W. Marshall, J. Hardwicke, H. Gharib, M. Fisher and P. Mckee "Active Management of Multiservice Networks" Proceedings Network Operations and Management Conference (NOMS), 2000.

[Prnj99c] O. Prnjat, L. Sacks, " Impact of Security Policies on the TMN X Interface Integrity and Performance", Proceeding of the First IEEE Latin American Network Operations and Management Symposium (LANOMS'99), December 1999. [Prnj00a] O. Prnjat, L. Sacks, "High Integrity Inter-Domain Management", in A. Galis (Ed.), "Multi-Domain Communication Management Systems", CRC Press - USA, ISBN: 084930587X, June 2000. [Prnj00b] O. Prnjat, L. Sacks, "Inter-domain Integrity Management for Programmable Network Interfaces", Proceedings of the 3rd IFIP/IEEE International Conference on Management of Multimedia Networks and Services (MMNS'2000), September 2000. [Psou99] K. Psounis, “Active Networks: Applications, Security, Safety and Architectures”, IEEE Communications Surveys, First Quarter 1999. [Reib91] A. L. Reibman, M. Veeraraghavan, “Reliability Modelling: an Overview for System Designers”, IEEE Computer, April 1991. [Robi92] P. J. Robinson, "Hierarchical Object-Oriented Design", Prentice-Hall, 1992.

[McDo94] J. C. McDonald, “Public Network Integrity Avoiding a Crisis in Trust”, IEEE Journal on Selected Areas in Communications, Vol. 12, No. 1, pp. 5-12, January 1994.

[Scot98] D. Scott et. al., ”A Secure Active Network Environment Architecture”, IEEE Network, May/June 1998, vol. 12, no. 3.

[Mckee99] P. Mckee and I. W. Marshall "Behavioural Specification Using XML" Proceedings IEEE FTDCS '99 (Capetown), pp. 53-59.

[Slom99] M. Sloman, E. Lupu, "Policy Specification for Programmable Networks", Proceedings of IWAN '99 Conference, Springer-Verlag, 1999.

[Necu97] G. C. Necula, “Proof-Carrying Code”, 24th ACM SIGPLAN-SIGACT Symposium Proceedings, 1997.

[Tenn96] D. Tennenhouse, D. Wetherall, "Towards an Active Network Architecture", Computer Communications Review, Vol. 26, No. 2, 1996.

[ODP] ITU Draft Recommendation X.901-X.904, "Basic Reference Model of Open Distributed Processing"; Part 1: "Overview and Guide to Use", 1995; Part 2: "Foundations", 1995; Part 3: "Architecture", 1995; Part 4: "Architectural Semantics", 1995. [Prnj99a] O. Prnjat, L. Sacks, "Integrity Methodology for Interoperable Environments", IEEE Communications, Special Issue on Network Interoperability, Vol. 37, No. 5, pp. 126-139, May 1999. [Prnj99b] O. Prnjat, L. Sacks, "Telecommunications System Design Complexity and Risk Reduction Based on System Metrics", Proceedings of the 10th European Workshop on Dependable Computing (EWDC10), May 1999.

[UML] Rational Software Corporation, Unified Modelling Language, www.rational.com [Vill92] A. Villmeur, “Reliability, Availability, Maintainability and Safety Assessment, Vol. 1: Methods and Techniques”, John Wiley and Sons, 1992. [Wake] I. Wakeman et. al., The Safetynet Project, www.cogs.susx.ac.uk/projects/safetynet/ [Ward95] K. Ward, “Impact of Network Interconnection on Network Integrity”, British Telecommunications Engineering, Vol. 13, pp. 296-303, January 1995. [XML] Extensible Markup Language (XML) W3C Recommendation 10.2.1998.