2.2. Design Rule

2.2. Design Rule

66. This design rule is developed for use in NATO Interoperability Standards & Profiles (NISP) version 4. It is based on experiences from the Swedish Network Based Defence initiative where it extends the design rule for Interoperability [2] and the IEAT concept developed within the frame of Multinational Experiment 5[3]. The design rule also considers the NATO Information Exchange Gateway (IEG) concept[10].

67. The design rule is applicable for collaborative federations in the coming 2-6 years which means that it covers both existing systems which won't be replaced as well as new systems which are developed and implemented during this time period.

68. The technical scope for the design rule is the highlighted areas of Figure 2.1. The design rule does not describe how to achieve interoperability on the Transport/Network level. Furthermore, it does not cover interoperability on the Community of Interest level. However, when design rules for these levels are created, this design rule will be used as the basis for enabling information exchange via services.

Figure 2.1. Simplified NNEC Technical Services framework with design rule scope

2.2.1. Context

2.2.1.1. Introduction

69. The design rule should be used when there is a need for several different military actors to cooperate in a federative manor in order to solve a common mission. The key capabilities that this design rule will help enable are:

Collaborative planning between multiple actors in a federation
Collaborative synchronization of execution between multiple actors in a federation
Collaborative assessment between multiple actors in a federation

70. The design rule does not address the operational activities needed to achieve the above capabilities, nor does it address the Community Of Interest (COI) technical services which supports these activities. Instead the design rule describes a set of principles, technologies and activities needed to create a technical platform which enables information exchange between the actors and can act as a foundation for the COI specific technical services when these are to be developed and deployed.

71. Since the design rule captures knowledge from previous experiences in this area it can save time and money for the involved actors. If the design rule is applied when defining the profile for such a mission, less time will be spent on getting to agreement on which services and underpinning technologies shall be used in the mission.

72. Many of the activities and technologies described in this design rule can also be applied when exchanging information and services with other actors than military organizations. However, there are specific aspects of collaborating with this type of organizations which are not covered by this design rule.

73. A suitable definition of interoperability in this design rule context (i.e. technical context) is: The ability of technical systems and/or organizations using technical systems to operate together by making (necessary) data & information and/or services produced by one system or organization available to the others, in an agreed format.

2.2.1.2. The International Military Federation

74. There are many challenges that have to be overcome in order to make collaborative work and knowledge sharing among the actors in an operation successful. In Section 2.2.3 of this design rule mainly addresses the technical aspects of the establishment of federation in which collaborating actors can exchange information. However, organizational, process and legislation aspects must be covered to some extent since all of these needs to be harmonized in order to make the collaboration effective. Therefore, a number of non-technical issues are described in Section 2.2.2.

75. The federation, depicted in Figure 2.2, is where the collaborating actors provide services which the other actors can consume. To create a federation, the actors need to create a federation agreement which defines the rules of the federation, such as which data formats, information classifications should be used. Rules regarding information ownership and service levels (including quality of service) are also included in the federation agreement.

76. Collaboration in multilateral operations has previously been based on bi-lateral agreements between all participants, but in order to achieve the speed and flexibility needed today, there is a need to establish a baseline federation agreement which can be used as a starting point when creating new missions.

77. Actors which participate in the federation connect networks and systems within their responsibility (i.e. domain) to other actors in order to be able to exchange information. To protect the internal information and control which information is being exchanged one or more Information Exchange Gateways (IEG) are stood up between the federation and the actors' network. In the IEG, one or more service interfaces are physically instantiated. This is referred to as a Service Interoperability Point (SIOP) according to the NATO C3 System Architecture Framework [6].

78. Within an actor's domain there can be one or more networks where information is stored. The decision which internal networks shall be connected is taken by each actor (Federation member) independently of the other actors. In Figure 2.2 two example networks are depicted, one federation network which holds information only relevant to the federation and one which is the actors' internal network. In this case, the IEG handles information exchange between these two networks as well as information exchange with other actors IEGs.

Figure 2.2. Federation Overview

79. The remainder of the design rule describes the challenges the actors face and how they can cooperate in order to create a federation to exchange information in a secure manor.

2.2.1.3. Related design rule areas

80. Interoperability is closely linked to the following other design rule areas:

81. Flexibility: The requirements on interoperability will change over time. Also, in some situations, very limited time will be available for making the necessary modifications of the system in order to fulfil the new requirements. This means that the organization, security and technical systems need to be very flexible with respect to configuration and modifiability in order to be able to adapt to changing and extended interoperability requirements. For more information, refer to [4].

82. Information security: With interoperability follows information security risks that must be handled. The connection of external systems must be done in such a way that the information security of each nation or organisation is not compromised. However information security mechanisms cannot be allowed to be static. In each specific case the need to protect information must be balanced against the possible consequences from not sharing the information. The three aspects of security; confidentiality integrity and availability, must all be considered.

2.2.2. Problem

83. There are several challenges to the effort of creating a federation for collaboration between military partners, both related to technology, but also related to how organizations, humans and legislation systems work.

84. This chapter summarizes the basic requirements for the federation and identifies the challenges which must be overcome in order to establish the federation. The issues identified for these challenges are given an answer to in Section 2.2.3.

Basic requirements for information exchange

85. The intent of this section is to identify a few of the most elementary (information exchange) requirements which are set on all international military federations. This is not a complete list, but these requirements acts as a driver for identifying the basic set of technologies needed in a federation.

[IER 1]: People from the different organisational actors SHALL be able to communicate with each other using voice or text communication.
[IER 2]: It SHALL be possible to discover and retrieve information (i.e. search) provided to the federation by different actors.

Challenges based on international agreements and regulations

86. Information and services exchange between nations and organisations (e.g. unclassified, restricted, secret and top secret classification) is based on government agreement between nations and organisations. Qualified information and services exchange can only take place if such agreement exists. To achieve this agreement is a lengthy process that often takes many months to finalize. It has also been proven complicated to negotiate and sign such an agreement between more than two nations and organisations at a time (multilateral). Nations are willing to share more information and services with some parties and less with others. This creates complicated situations during multilateral operations.

[Issue_1]: How can a common, agreed description for analyzing and describing international military interoperability be created?

Challenges based on national law, national integrity and regulations

87. Differing laws, rules and regulations together with different cultures regarding information sharing are likely to impact willingness to share information and slow down process of getting agreements on what to share.

88. Parties participating in a multilateral operation are likely to have different requirements and priorities which will imply different scope and granularity of information exchange for each party. The parties will be required to protect their national integrity while sharing information with the other parties. By this, it is likely that the parties wish to get access to more information and services than they are willing to provide themselves. It is also so that the parties will need to limit the possibilities for others to control how and what information is provided.

[Issue_2]: How can the impact of national laws and regulations in coming to agreement of what information to share be minimized in order to support the requirements of flexibility and ability to change?
[Issue_3]: How can parties participating in a multilateral operation protect their national integrity by using mechanisms to protect internal information and be able to control what information is released to others?
[Issue_4]: How can the parties in a multilateral operation jointly come to agreement of what information shall be exchanged, how it shall be exchanged and how it shall be handled by receiving parties?

Challenges based on interpretation of information content

89. Semantic differences, i.e. differences in languages and the meaning of words and expressions, are likely to be an issue when exchanging information. If the collaborating parties cannot understand the information being communicated, the information will not be of any use and the trust of accessible information will be challenged. There is a need for the parties to eventually meet in a combined opinion, a common and agreed set of descriptions in order to reach wanted effects.

90. In order to solve the semantic challenge there is a need to understand the content of information and services exchanged between different systems/actors to be able to come to an agreement of the meaning of the information. However, the increasing requirements of the ability to rapidly change directions of the flow of information, as well as the actual content, means that the work with defining models and requirements for information exchange must be done continuously and during the whole lifecycle of an operation.

[Issue_5]: How can the parties in a multilateral operation agree on what information shall be exchanged?
[Issue_6]: How can differences in semantics and information models be handled in order to minimize the risk of the parties not understanding each other?
[Issue_7]: How can it be ensured that the work with understanding others semantics and information models is done in all stages of the development lifecycle?

Challenges based on technical issues

91. Architecture and technical implementations of information systems will be different in most of the cases. The complete technical system will probably not be homogenous, rather a federation of heterogeneous systems and therefore hard to govern and manage.

92. Agreeing on standards, formats and mechanisms for information exchange is a critical success factor, however the sovereignty of the parties will increase the complexity of this task since there is no governing organ that can make the decisions.

93. A common understanding and agreement on the architecture and design for the federation is vital in order to succeed with agreeing on how information shall be exchanged. A major challenge in this perspective is that the maturity of using architecture and design as governing tools is likely to vary greatly among collaborating parties, thus slowing down the agreement process.

94. Since each actor has huge amounts of data of various kinds within their internal networks there is a need to have the means to organize and prioritize what to share. Also, when information has been shared within the federation, there must be mechanisms to be able to verify the authenticity, track usage of and prevent that the information is used by actors which are not meant to use it.

[Issue_8]: Which architecture can enable governance and structure to mechanisms for information exchange between heterogeneous systems?
[Issue_9]: Which standards, formats and mechanisms for information exchange should be used?
[Issue_10]: What does a common architecture description framework for multilateral operations contain?
[Issue_11]: What mechanisms shall be used in order to control what information to make available to partners in an international military operation?
[Issue_12]: What mechanisms can be used to maintain information security and system safety, e.g. weapon safety, when external systems are connected to a nation's internal network?

Challenges based on culture, lack of trust and organizational issues

95. Even if we have solved "challenges based on international agreements and regulations" we will still most likely hesitate to share information since the organizational culture does not foster incentives to share information[7]. This is understandable, but not very efficient from an operational perspective. We have to overcome these limitations and see the goal of the operations as more important than the individual organizations ego.

96. Today's military organizations are experienced and usually organized around various stovepipe principles. This is a convenient, straight forward way of defining requirements, responsibilities and timetables for implementing new and enhanced systems. Operations were information is expected to be exchanged between both organizations and technical systems will set new requirements on the procurement process, working methods and the organizations working those issues.

[Issue_13]: Data are not generally created to support enterprise needs. There are typically technical and political boundaries that inhibit this. To "line" applications development organizations, enterprise-level requirements for data are typically viewed as "external", as their direct customers, and typically the sponsor of the application, is not rewarded for serving the greater good, but for locally optimizing the performance of their organization[7].

2.2.3. Solution

2.2.3.1. Architecture for interoperability

97. The most important instrument in resolving the issue of creating a description for analyzing and describing international military interoperability as described in [Issue_1] is to create an architecture. This design rule outlines an architecture which provides the means to create a foundation for the federation in which information exchange among parties can take place.

98. The architecture is described by:

Governing aspects (design principles and rules) used to explain and develop architectural principles and structures in important areas of the architecture.
Common terminology & definitions.
Structure. How systems, aspects and terminology/definitions are organized and grouped.
Systems in terms of mission and/or technical systems.
Services which describe how systems interact.

99. It is absolutely vital that the architecture addresses both operational and technical aspects so that there is a clear description of what purpose the technical implementation has [Principle_4].

2.2.3.1.1. Service Oriented Architecture

100. The Architecture outlined in this Design rule is Service Oriented [Principle_5]. The aim of this is to achieve a loose coupling of services with underlying systems, whether it is mission or technical systems. So, instead of describing interaction directly between systems, the systems use services to interact with each other. By specifying a contract for information exchange, a service definition [Principle_6], the inside of a system can be replaced or modified without having to change other systems which interacts with it. Thereby the issue of enabling information exchange between heterogeneous systems [Issue_8] is resolved.

101. Services used or provided by technical systems should as far as possible be expressed in a common way and contain formal descriptions suitable for IT processing.

102. The Service description shall contain:

The allowed service protocols (process) to be used for information exchange.
The interfaces (or message types) that are used to exchange information between a service consumer and a service producer.
The definition of the data types that are used in the interfaces (messages) and therefore are in the information exchange model.
The properties that consumers can use to distinguish between different implementations of a service.

103. To enable systems to find and connect to each other, information about services shall be published and accessible for the collaborating parties' IT systems.

2.2.3.1.2. Architecture description framework

104. In order for all parties to obtain a common "language" on how to describe their systems and the services they bring to the federation this design rule also covers an architecture description framework. The architecture description framework does not describe the architecture itself, but rather guides how the architecture shall be structured and what it should describe.

105. The current valid description framework within NATO is the NATO Architectural Framework (NAF) version 3[9] which provide the rules, guidance, and product descriptions for developing, presenting and communicating architectures which includes both operational aspects as well as technical aspects [Principle_4].

106. In the Framework, there are seven major perspectives (i.e., views) that logically combine to describe the architecture of an enterprise. These are the NATO All View (NAV), NATO Capability View (NCV), NATO Programme View (NPV), NATO Operational View (NOV), NATO Systems View (NSV), NATO Service-Oriented View (NSOV) and NATO Technical View (NTV). Each of the seven views depicts certain architecture attributes. Some attributes bridge several views and provide integrity, coherence, and consistency to architecture descriptions.

107. To support the creation of views and make sure they are consistent, NAF v3 defines a metamodel. The NATO Architecture Framework Metamodel (NMM) defines the relationships between the different components of the framework. It defines the architectural objects and components that are permitted in NAF v3 views and their relationships with each other.

108. There are certain views which are more important when designing architectures for multinational operations where interoperability is in focus [Issue_10]:

109. NATO All-Views (NAV) which capture aspects which overarch all other views. These views set the scope and context of the architecture, such as goals and vision, scenario and environmental conditions as well as time.

110. NATO Capability View (NCV) which explain what capabilities are needed in order to fulfil the strategic intent for the mission. Specifically, capabilities related to interaction between actors are important to identify in these views. If produced correctly, these views can already say a lot of which services are needed to fulfil the business needs. In particular, the NCV-2, Capability Taxonomy and NCV-7, Capability to Services Mapping views are important.

111. NATO Operational View (NOV) which is a description of the tasks and activities, operational elements, and information exchanges required to accomplish NATO missions. To design for interoperability all of these views do not have to be complete, but it is important to know which operational nodes exist and how they interact (NOV-2). Also, the information model defined in the NOV-7 view is important, especially for such information for which there are no or unclear standards to rely on. When going into more details of the architecture, the requirements on information exchange (NOV-3) are necessary to understand.

112. Currently, the operational views in NAF does not fully support modelling of services. The authors of this design rule recommends that future versions of NAF are complemented with the capabilities of using services to describe interaction between operational nodes instead of needlines.

113. NATO Service-Oriented View (NSOV) focuses strictly on identifying and describing services. The view also supports the description of service taxonomies, service orchestrations and a mapping of services to operational activities. The service description (NSOV-2) is a key component of a Service Oriented Architecture [Principle_6]. It is used to detach the functionality provided by a system (or services provided by an organizational unit) from the actual system. A service description includes information on how to interact with the service, what requirements a system must fulfil if it implements the service and what information model the services uses. Within NSOV-2 a SIOP can be depicted as a higher-level service interface. The detailed technical specification of a SIOP is contained within a Service Interoperability Profile (SIP). SIPs are addressed in NTV-1 Technical Standards Profile.

114. In the NATO Systems View (NSV), the NSV-1 view is the most important since it describes how the different systems interact to fulfil the operational needs. The system descriptions should be kept on a black-box level, i.e. it is not relevant to describe the internals of the systems.

2.2.3.2. Key Principles

Sovereignty of collaborating parties

115. The sovereignty of the collaborating parties is fundamental; organizational right to use organic information systems and working methodology with various support tools shall in all situations be respected. The decision to publish information to the federation is the responsibility, and right, of each actor. Information content and possible restrictions will always be any actor's sovereign decision.

[Principle_1]: Each collaborating party decides which information to publish into the federation.

View on information

116. Information shall be regarded as an operations wide asset and not be exclusive to any single operational area or function, with exceptions for agreed confidentiality. Collaborating parties should avoid over-classification of information. Information should be provided as a published service.

[Principle_2]: Information published into the arena is available to all parties, if no restrictions have been agreed.

Agreements for Information Exchange

117. Agreements to facilitate Information Exchange shall exist for the operation and between the collaborating parties. The agreements includes which information is required to be exchanged, models for how exchanged information shall be structured, how information can be translated between models and the format of the exchanged information.

[Principle_3]: Requirements, models, translations and format for information exchange in the arena are regulated by agreements.

Architecture

118. Establishment of a consistent and understandable architecture should be supported by a common terminology and a common architecture description framework. In order to ensure that the technical architecture fully supports the operational needs, there is a need for a joint architecture.

[Principle_4]: The operational and technical aspects of the architecture are described using a common description framework.

119. The architecture of the federation must support exchange of information between many heterogeneous systems in order to fit all actors' needs. A Service Oriented Architecture (SOA) achieves this by separating information exchange capabilities from business logic and system specific implementations.

[Principle_5]: The technical architecture for information exchange follows the tenets of the Service Oriented Architecture concept.

120. OASIS (organization) defines Service as "a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description."

[Principle_6]: Technical services for information exchange are specified in a service description.

Technology

121. Open and accepted international standards, both civilian and military should be used. Bespoke and proprietary standards shall only be considered when it delivers significant higher value.

[Principle_7]: Technical services for information exchange uses open standards whenever possible.

Security

122. To achieve information exchange in a secure way using services, a set of principles which guides the use of security functions is needed:

[Principle_8]: Service consumers and service providers use a common methods for authentication and authorization of users and services.
[Principle_9]: There is a common method to obtain integrity by which a service consumer can check that the data sent from another part is not changed by a third part.
[Principle_10]: There is a common method to guarantee the confidentiality of the information exchanged. This means that it is possible to prevent outsiders from getting access to the information that is exchanged.

123. It is important to remember that these principles only apply between the borders of the actors in the federation, not end-to-end between users. The reason for this is that it is very hard and cost driving to govern how security mechanisms shall be implemented within an actor.

2.2.3.3. The information aspect

124. In order to meet operational needs for information exchange and to build a federation, supported by technical systems serving as operational nodes, a number of areas must be addressed:

Information Exchange Requirement specifications
Information Exchange Models within collaboration areas and their relation to international standards, domain Community Of Interest (COI) models, semantic structures etc
Translation specifications and translation mechanisms
Specification of information exchange mechanisms in the federation e.g. common data management services, mediation services and bridges to external systems

125. Documenting the above according to [Principle_3] address issues [Issue_1], [Issue_2], [Issue_4], [Issue_5], [Issue_6] and [Issue_9] by creating agreements of what information is to be exchanged, how to interpret the information and which mechanisms are utilised to enable the information exchange.

126. This chapter covers the definition aspect of information, technologies which implement these definitions, like for example mediation, are covered in Section 2.2.3.

2.2.3.3.1. Information Exchange Requirements

127. An Information Exchange Requirement (IER) is a specification of the required information exchanged between operational nodes. IERs are identified in the business modelling process and specify the elements of the user information used in support of a particular activity. The specification is done according to the NOV-3 view of NAF[9].

2.2.3.3.2. Information Exchange Models

128. An Information Exchange Model (IEM) is a specification of the information which are exchanged between operational nodes. IEMs are used when deciding which information objects are to be exchanged in service interactions. The specification is done according to the NOV-7 view of NAF[9].

129. An IEM is constructed top-down based on model elements from other existing Information Models e.g. standards as well as bottom-up based on information requirements specifications from Operational Concepts and Requirements Implications (OCRI)[8].

130. When designing Information Exchange Models several different approaches exist:

Model based, e.g. JC3IEDM, ISO19100 series
Ontology based e.g. Semantic web
Message based e.g. ADatP-3

131. Given the timeframe for this design rule, a model based approach is the best approach considering what the technology can handle and results from ongoing modelling work. The ontology based approach can be adopted at a later stage when the technology and methods are more mature while the message based approach is to be avoided if possible since it cannot handle the complexity of integrated models.

2.2.3.3.3. Translations

132. There may be a large number of translations between two information models. Each translation is based on thorough analysis and is documented in a translation specification together with estimates of information loss.

133. There are different approaches to making translations between the models:

Manual model mapping, that is when two models are compared and decision are made at element level on how to map and/or translate to the other models. This is often the case when the models to compare are documented according to different standards regarding ontological metadata notation, modelling style etc.
Rule based model mapping that is when two models are compared and mapped to each other based on formalized rules. Automated translation has the potential to be applied in runtime, thus increasing flexibility in information exchange.

134. Technologies which perform automated translation between information models is not yet available to any greater extent. Therefore, the translation technologies described in Section 2.2.3.5.6 focuses on supporting translation rules which are based on manual model mappings.

2.2.3.3.4. Information Exchange Objects

135. An information object is a set of data elements that are contained and treated as one unit. The content structure may vary in complexity from the simplest form with a number of data elements and an identifier to complex data structures and large quantities of data elements. Examples of information objects are documents, messages and data sets such as geographical data sets.

136. Information objects are created, processed, stored and moved/exchanged via services. An information exchange object is a standardised view, or an excerpt from, an information exchange model which from a technical point of view is suitable to exchange as a coherent set. Thus information exchange objects is a subset of all information objects which are meant to be exchanged via services.

2.2.3.3.5. Services and the information aspect

137. In a Service Oriented Architecture [Principle_5], information objects are created, processed, stored and moved/exchanged via services. Therefore it is important to understand the architectural relationship between services and information. I.e. how are services and information specified in order to enable the implementation of a service oriented architecture.

138. As depicted in Figure 2.3, a service has operations. They are used for specification of how a consumer can interact with the service, for example create, read, update, delete. An operation requires one or more information objects to be exchanged between the consumer and provider, for example a message or a document. These exchange objects are excerpts from an information exchange model.

Figure 2.3. Services and the information aspect

139. Translations are use to describe how information exchange models relate to each other and can also be used by mechanisms to automatically translate exchange objects from different information models. Information exchange requirements are set on service operations and exchange objects, i.e. what functionality shall the service provide and what information shall it handle.

2.2.3.4. The security aspect

140. When determining appropriate security solutions for a federation it is of outmost importance to analyse the information which needs to be assured. This is important in order to avoid a "too secure" solution, thus introducing higher costs and more difficult procedures than needed. The flexibility which is introduced by the NNEC concept requires a constant analysis of the need for information confidentiality, integrity and availability (CIA). Also, time needs to be considered in these analyses, i.e. how long does the information need to be protected.

141. This design rule does not cover how to perform CIA analyses, but it is certain that there is a need to be able to handle different levels of security in the federation. A set of scenarios has been defined in the IEG concept[10] which are used in this design rule to handle difference in security levels.

The Information Exchange Gateway Concept

142. Information Exchange Gateways (IEGs) are used to protect information assets of the participants in the federation. Since each participant provides an IEG to protect their assets there is a need to standardise the services and the architecture of IEGs in order to enable sharing of IEG components between the participants and use of commercially available technology. The NATO IEG concept[10] describes that each IEG has three major services:

143. "The first is the Node Protection Service (NPS). The NPS provides protection to the infrastructure; its purpose is to protect the physical assets of the "node" or nation being protected by the IEG."

144. "The second major component/service is the Information Protection Service (IPS). NATO and each nation are responsible for protecting the flow of information out of its area (node or network). The mechanisms used to protect the information flow must satisfy the organization (nation or NATO) that the IEG is protecting."

145. "The third major component/service is the Information Exchange Service (IES). The IEG must facilitate the flow of information between the protected node/network and the external organizations that are authorized (by the Information Protection Service)."

146. Together these services provide the solution to issues [Issue_3], [Issue_11] and [Issue_12]. More details on the implementation of IEGs can be found in Section 2.2.3.5.7.

Information zones

147. Information Zones is a concept identified and defined to achieve confidentiality with high assurance, for a gathering of information within a defined perimeter, and interactions to its surrounding with a number of services and nodes inside the zone. The concept gives the advantage to separate assurance on security mechanisms to meet external and internal threats.

148. In a federative approach such as the one described in this design rule, each federation participant (actor) is to be considered as (at least) one information zone. The reason for this is that there is a clear responsibility for information and information management within each actor. At the border of the information zones there are Information Exchange Gateways (IEG) which protects the information within the zone and allows controlled sharing of information between information zones. See Figure 2.4.

Figure 2.4. Informationzones in the federation

149. The information classification level in each zone will differ and therefore the information assurance level needs to be adjusted accordingly. I.e. the more sensitive information within a zone, the more protection and dissemination control is needed.

150. By basing the security on information zones with boundary protection and controlled information flow and access to the zone, it is made easier to achieve high assurance since only a few mechanisms, i.e. the IEG, needs to be inspected/evaluated to meet the security requirement.

151. In the federation there may be several information zones depending on the classification of exchanged information. However, the number of information zones should be kept to a minimum in order to avoid unnecessary costs and complexity for implementation and maintenance of the federation.

2.2.3.5. Technology and profiles

152. As mentioned in Section 2.2.1.2, there is "a need to establish a baseline federation agreement which can be used as a starting point when creating new missions". The technology described in this chapter supports the creation of such an agreement by addressing [Issue_9] > "Which standards, formats and mechanisms for information exchange should be used?"

153. In other terms, the standards, formats and mechanisms defined in this chapter shall serve as the baseline for an international military federation.

154. There are two basic user requirements defined in Section 2.2.2 which acts as drivers for the technology defined in this chapter. These requirements are:

[IER 1]: People from the different organisational actors SHALL be able to communicate with each other using voice or text communication.
[IER 2]: It SHALL be possible to discover and retrieve information (i.e. search) provided to the federation by different actors.

155. To be able to fulfil these requirements, a set of technical capabilities are needed. First of all, there must be network (IP) connectivity between the actors in the federation; however this is not covered by this design rule. Once network connectivity is established, the technical systems of the actors need to be able to publish and find the services which are to be used. Of course, all communication in the federation network must be secured by relevant security mechanisms.

156. In order to fulfil [IER 1], users first need to be able to find each other and once they have done that they can start collaborating.

157. To fulfil [IER 2] the Information Discovery Services are used to find relevant information. To retrieve the information, Messaging Services can be used. In some cases the information models used by the different actors does not match and then the Translation Services are used to translate the content.

158. Lastly, it is important for the actors in the federation to know the status of the services in the federation, especially if there are mission critical services which are provided by other actors.

159. The following chapters describe the above in more detail giving advice how to implement the technologies needed to provide these services.

2.2.3.5.1. Discovery services

Service Discovery Services

160. The Service registry enables the technical systems to discover each other. The service registry is a vital part needed for enabling the loose coupling between systems since it provides functionality for the systems to find each other , with such registry the relationships between the systems does not need to be hard coded into the systems. This means that it will be easy to add or remove participants and services from the federation.

161. The Service registry SHALL be implemented using UDDI v3 according to NISP[12]. In order to achieve high availability and allow each participant to be able to publish services, the Service registry shall be implemented using a replication pattern. I.e. the service registry is replicated between all participants in the federation.

162. The Service registry SHALL include the following information (metadata):

Service provider

Unique id, Name, Description

Service type

Unique id, Name, Description, Version

Service instance

Unique id, Name, Description,Service interfaces (bindings e.g. WSDL) and applicable security mechanisms, Endpoint (e.g. URL), Owner - both service provider and human user owning the service, Security Classification - UNCLASS, RESTRICTED etc

Information Discovery Services

163. Each actor in a federation holds information which might be relevant to other actors. Therefore it is of outmost importance that there are mechanisms to discover information across actors. These mechanisms have to include the capability for an actor to decide which information shall be available to others according to [Principle_1] and [Principle_2].

164. There are mainly two ways of making the information discovery happen. One is to copy information between actors and let each actor make the information searchable, but this is not very efficient since it requires a lot of bandwidth and makes it hard to keep track of which information has been copied.

165. The other way of enabling information discovery is to use a federated search pattern where each actor provides a search interface to its information. This is much more efficient from a data distribution point of view, but requires that all actors come to agreement on the search interface. There are initiatives ongoing to standardise the ability to perform federated search, the most prominent one is the OpenSearch initiative^[1]. Even though OpenSearch is not a formal standard it is well on its way to be adopted by many of the major tool vendors.

166. In either case, the actors in the federation must implement search engines which can index information (if the have any) and search clients which can access the search engines. A search client is in most cases an ordinary web browser, but can also be a more complex application if there are specific needs.

2.2.3.5.2. Repository Services

Metadata Registry Services

167. A metadata registry is a database which contains information about information which is useful for enabling information discovery. For example, search engines create metadata registries when they index content. But there are also other applications for metadata registries, like when an actor has sensitive information which needs to be able to be discovered. Say that there is a database which contains classified analyses of some sort. The analyses are of very good quality and can be of use to many, but it is impossible to publish them to everyone in the federation. So in order to make other actors aware that the analysis exists, unclassified analysis metadata, like what the analysis looks at and who has done it, can be published in a metadata repository. Now the other actors can discover that there is an analysis and contact the author to get approval for getting the contents.

168. To be able to store the metadata, the NATO Discovery Metadata Specification (NDMS) SHALL be used. This specification is based on the international standard ISO 15836 the Dublin Core (DC) Metadata Element Set.

2.2.3.5.3. Directory Services

Enterprise Directory Services

169. Sharing information about users is key to a federation since it enables people to find each other. The user directory holds information which enables authentication of users by certificates and public keys, authorization of users by roles and discovery of users by contact information which enables collaboration.

170. Each actor in the network shall provide information about the users that represents them. However, it is preferable if the federation has one point of access to all user directories. Therefore, the implementation of user directories in a federation shall follow the federated database pattern. This means that each actor provides their own database, but one actor provides a single entry point to all databases.

171. For the user registry LDAP shall be used according to NISP[12]. Products which can provide the single entry point to multiple LDAP databases are often referred to as Virtual LDAPs.

2.2.3.5.4. Collaboration Services

Audio based conference service

172. For voice communications standards SHALL be applied as according to TACOMS[13]. Streaming voice and video communication cannot be handled by the IEGs, TACOMS describes how to implement this functionality without the use of IEGs.

2.2.3.5.5. Messaging Services

Server-to-server e-mail messaging service

173. E-mail has become one of the most important applications for any business or organization of today. The main challenge for using e-mail in a federation is to be able to control that no classified information is embedded or attached to e-mails going out from an actor and protecting the actors from malicious software, such as viruses. This means that the IEG needs to be able to scan and filter incoming and outgoing messages.

174. Extra care needs to be taken for outgoing information where confidential information can be hidden in document history and inside images. Therefore, only text-based attachments (like OpenDocument Format or Office Open XML, see NISP[12]) without inserted code or images shall be allowed through the IEG.

175. It is also vital to have a manual inspection capability in the IEG to be able to assess the degree of confidentiality of the e-mail messages leaving an actor.

176. As described by NISP[12], SMTP according to RFC 2821 and others SHALL be used for e-mail. To secure communication between SMTP agents, TLS according to RFC 3207, SHOULD be used.

Instant messaging service

177. For instant messaging XMPP (IETF RFC3920:2004 -3923:2004) SHALL be used according to NISP[12]. XMPP is an XML based publish/subscribe protocol which is used by most of the dominant tool vendors. Using XML enables possibility for inspection and control of messages in IEGs which is very important in a federation.

178. There is one important aspect of XMPP which is not covered by the current standard specification; there is no security tagging options available which is needed when messages shall be passed between information zones with different security classifications. So if this is required a custom extension to XMPP needs to be defined.

179. Another thing which must be considered in a federation is routing of messages. Currently there are no XMPP servers which support routing of XMPP messages. This consequence of not being able to route messages is that the IEG has to be implemented as a transparent proxy, i.e. the systems on the outside of the IEG need to know about the systems on the inside. Even though the IEG can be used for inspection and filtering of messages in this case; it is not always a preferred solution from a security perspective. So, if the security requirements say that the IEG needs to act as a non-transparent proxy, the XMPP server needs to be modified to be able to act as an XMPP server and be able to route messages between XMPP domains.

Message passing service

180. In order to achieve an efficient exchange of information between the actors in a federation there is a need to be able to route and distribute messages. This type of capability is often included in the Enterprise Service Bus (ESB) concept.

181. An ESB refers to a software architecture construct, implemented by technologies found in a category of middleware infrastructure products usually based on Web services standards that provides foundational services for more complex service-oriented architectures.

182. An ESB generally provides an abstraction layer on top of an implementation of an Enterprise Messaging System which allows integration architects to exploit the value of messaging without writing code.

183. The ESB shall enable endpoints to interact in their native interaction modes through the bus. It shall support a variety of endpoint protocols and interaction styles. These interaction patterns are the least which shall be supported:

Request/response: Handles request/response-style interactions between endpoints. The ESB is based on a messaging model, so a request/response interaction is handled by two related one-way message flows -- one for the request and one for the response.
Request/multi-response: A variant of the above, where more than one response can be sent. Is often referred to as a subscription pattern.
Event propagation: Events may be anonymously distributed to an ESB-managed list of interested parties. Services may be able to add themselves to the list.

184. When passing messages in the above patterns, the ESB SHALL be able to perform the following:

Route: Changes the route of a message, selecting among service providers that support the requester's intent. Selection criteria can include message content and context, as well as the targets' capabilities.
Distribute: Distributes the message to a set of interested parties and is usually driven by the subscribers' interest profiles.

185. The ESB SHALL be able to handle the following formats and protocols:

SOAP over HTTP for Web Services
JMS for Java messages
XMPP for Instant messaging and XML based Publish subscribe messaging

186. When implementing the ESB concept in federations there are some things which must be considered. First, the products which realize the messaging and mediation capabilities needs to be the same everywhere since there are very small chances of realizing integration between two different products due to a lack of standardization. This means that the federation agreement must include which product to use.

187. Secondly, the management of rules for transformation of messages needs to be considered. ESB and messaging products are often built for central management of transformation rules, thus enabling a better control over the messaging capabilities in an enterprise. However, this can be problematic in a federative approach since all actors need to agree on the transformation rules or appoint one actor which has the authority to manage these.

2.2.3.5.6. Mediation Services

Translation Services

188. Translation is about manipulating messages in-flight between a service provider and a consumer (requests or events). This means that messages dispatched by a requester are transformed into messages understood by a slightly incompatible provider selected from a set of potential endpoints.

189. Translation services are often considered being a part of the ESB concept.

190. The patterns which translation products SHALL be able to handle are:

Protocol switch: Enables service requesters to dispatch their messages using a variety of interaction protocols or APIs, such as SOAP/HTTP and JMS. Transcodes requests into the targeted service provider's format. Can be applied at the requester or the provider end of an interaction, at both ends, or anywhere in between.
Transform: Translates the message payload (content) from the requester's schema to the provider's schema. This may include enveloping, de-enveloping, or encryption.
Enrich: Augments the message payload by adding information from external data sources, such as customization parameters defined by the mediation, or from database queries.
Correlate: Derives complex events from message or event streams. Includes rules for pattern identification and rules that react to pattern discovery, for example, by generating a complex event derived from content of the triggering event stream.

191. Also see Section 2.2.3.5.5 for details in ESB implementation.

2.2.3.5.7. Information Assurance Services

192. As a minimum baseline for IEGs in a federation, the following shall be implemented in order to fulfil [Principle_8], [Principle_9] and [Principle_10]:

193. The IEGs shall include a Information Protection Service (IPS). This shall provide the following services:

Authentication to verify the identity of users and systems sending/receiving data
Authorization to verify rights for users and systems to send/receive data
Content encryption/decryption capabilities to assure confidentiality and integrity of the data
Information dissemination control to be able to control which data is passed through the IEG.

194. To be able to inspect the data flowing through the IEG, the data must be unencrypted. The IEG can send and receive encrypted data, but encrypted data must be decrypted by the IEG before it can be inspected and decrypted again for further transport.

195. The Information Exchange Service (IES) which the IEG shall be able to handle is described in the other technology sections of Section 2.2.3.5.

196. The requirements for Node Protection Service (NPS) is not determined by this design rule, however some type of node protection is always needed. Since this design rule does not cover the communication layer, there is a need to create a design rule which describes this.

2.2.3.5.8. Service Management Services

197. Service management can be divided into managing, where the technical systems and services are being controlled, and monitoring where information regarding the status of the technical systems and services are shared.

198. In a federation, the participants may be able to managed systems and services provided by other participants, but this is unlikely due to information responsibility of organizations. I.e. a participant which is responsible for the information within its information zone will not let another actor have administrative privileges to the system where this information resides.

199. However, sharing monitoring information between the participants is essential if the Service Level Agreements (SLAs) shall be fulfilled. These SLAs are included in the agreements for information exchange as specified by [Principle_3].

200. Monitoring information is to be provided using the Simple Network Management Protocol version 3 (SNMP v3) standard according to NISP[12]. Using a non-XML based format for monitoring, like SNMP, will require a special filtering engine in the IEG IPS (see chapter Section 2.2.3.5.7).

201. It is important to set the monitoring scope properly when implementing the monitoring solution in order to avoid dissemination of to much information into the federation. Therefore, monitoring information SHALL only be provided regarding the services which are provided by an actor. Important metrics to provide monitoring information about are:

Availability of services, both past, current and future (planned outages)
Performance in the form of response times and throughput
Capacity, like for example maximum number of users or used storage space

2.2.3.6. Summary

202. To summarize, Figure 2.5 depicts all the technologies mentioned in the chapters above. Together these technologies provide the foundation for secure information exchange in a multilateral collaboration federation in the NNEC context.

Figure 2.5. Technology Overview

2.2.4. Rejected solutions

203. This subject will be described in a future revision of the volume.

^[1]http://www.opensearch.org/