White Paper

IRIS Organisational Messaging

SSE/04527/WHI/009 - $Revision: 1.17

$ Date: 4 January 2007

Page 1 /29

Preface
Trademark All brand names and product names are trademarks or registered trademarks of their respective companies.

Copyright Copyright 2005-2007 All rights reserved Systematic Software Engineering A/S

Systematic Software Engineering A/S Sren Frichs Vej 39 8000 rhus C Denmark Tel: +45 89 43 20 00 Fax: +45 89 43 20 20 sse@systematic.dk

Systematic Software Engineering Ltd The Coliseum, Riverside Way Camberley, Surrey GU15 3YL, UK Tel: +44 1276 675533 Fax: +44 1276 675544 ssel@systematic.co.uk

Systematic Software Engineering Inc 10680 Main Street, Suite 170 Fairfax, Virginia 22030 USA Tel: +1 703 385 7522 Fax: +1 703 385 7733 ssei@sseusa.com

www.iris-sse.com

Page 2 / 29

Table of Contents

1 2
2.1 2.1.1 2.1.2

Summary _________________________________ 4 Background _______________________________ 5

IRIS Product Family Integrated product suite Structured document support together with IRIS Forms 7 7 7

3
3.1 3.2 3.3 3.4 3.5 3.6

Objectives ________________________________ 8
Military Messages in a Desktop Environment Transmission and Connectivity Organisational Messages vs. Personal Email Operational Procedures - Workflow Automated Message Processing Security 8 9 9 10 11 11

4
4.1 4.2 4.3 4.4 4.5 4.6 4.7

Functionality _____________________________ 13
Users, Roles and Queues Military Message Form Addressing Structured Documents Automated Profiling - Distribution and Processing Operational Procedures - Workflow Connectivity to Other Systems Gateways 13 15 16 16 17 19 19

5
5.1 5.1.1 5.1.2 5.1.3 5.1.4 5.1.5 5.1.6 5.1.7 5.2 5.2.1 5.2.2

IRIS MMHS Solutions _______________________ 21

A National Military Message Handling System Choosing the appropriate architecture MMHS Architecture 1 Centralised Server MMHS Architecture 2 Distributed Local Servers MMHS Architecture 3 Gateway to External Networks MMHS Architecture 4 STANAG4406 Infrastructure MMHS Architecture 5 Multiple Organisations per Site MMHS Architecture 6 STANAG4406 Backbone Directory Services Microsoft Active Directory X.500/LDAP 21 21 22 22 23 23 24 25 25 25 26

6
SSE/04527/WHI/009 - $Revision: 1.17

IOM Security _____________________________ 27

$ - Date: 4 January 2007

Page 3 /29

6.1 6.2 6.3 6.4

Privacy Identification and Authentication Solving the Security Issues Informal versus Formal Messaging

27 27 27 28

Technical Specifications _____________________ 29

Page 4 / 29

Summary

IRIS Organisational Messaging (IOM) is a product in the IRIS messaging product suite from Systematic providing Military Message Handling Solutions based on a Microsoft Outlook and Microsoft Exchange Server environment. IOM provides a cost-efficient, user-friendly, integrated solution combining military organisational messages with personal email on a single desktop. It is a further development of the established and mature family of IRIS messaging products. IRIS product suite has been continuously enhanced since its inception over 15 years ago and is now in use in over 27 countries and more than 100,000 users. Key features of IOM: Based on Microsoft Exchange and Outlook utilising a well-known group-ware platform and adapting it to military messaging requirements. Role based, organisational messaging. Workflow facilities to support military operational procedures. Automatic profiling and processing of messages based on content and envelope attributes. PKI capability for electronic signatures and encryption utilising a national PKI infrastructure. Military addressing using Microsoft Exchange Server or X.500/ACP133 address books. Connectivity to STANAG4406, ACP127 and many other military protocols. Flexible architecture supporting multiple configurations and network topologies. Seamlessly integrated with IRIS Forms which provides an editing, validation and identification capability for military structured documents, e.g. NATO ADatP-3, USMTF, OTHT-GOLD, VMF, XML-MTF or national message formats. Simple integration with IRIS Information Mapping Tool (IMT) and other external applications for processing of structured documents e.g. parse messages and update databases.

SSE/04527/WHI/009 - $Revision: 1.17

$ - Date: 4 January 2007

Page 5 /29

Background

In the world of modern military information systems the use of email plays a role in many systems, operating side-by-side with Military Message Handling for relaying official information between organisational units. In many systems email co-exists with the military message handling, sometimes working from the same workstations and at other times completely separate. Historically, the two worlds of commercial email and Military Message Handling have had little or nothing in common. Military Message Handling dates back to the earliest days of teleprinter equipment when standards such as ACP127 (or related standards such as JANAP128 and ACP126) were in fact developed for the teleprinter and telex equipment. With the emergence of commercial standards such as X.400, the defence market defined ACP123/STANAG4406 as an enhancement of the commercial X.400 standard adding the extensions necessary for Military Message Handling. Many nations have or are in the process of implementing ACP123/STANAG4406 compliant systems. For the exchange of military messages within the NATO community, networks, such as NICS TARE (NATO Integrated Communications Systems Terminal Relay Equipment) and NMS (NATO Messaging System), are established to ensure the safe exchange of messages between NATO headquarters and member nations. Although NICS TARE is now an older system, national Message Handling Systems within NATO will continue to have requirements for interfacing with it until the NATO Messaging System is fully deployed. There are a number of good reasons to base a system around a COTS email and groupware product reasons that are covered in this white paper. Military organisations may ask themselves: How can we achieve the cost-efficiency and state-of-the-art technology of the commercial email tools whilst still being able to fulfil the requirements of Military Message Handling as well as being able to communicate with the Military Message Handling Systems? With IOM a fully integrated solution for military messaging is provided, leveraging the proven functionality of many of the IRIS modules while utilising the financial, technological and usability benefits of the Microsoft Outlook and Exchange groupware products.

Page 6 / 29

Figure 1 illustrates a situation on the left with two co-located systems with no interaction capability. This solution may require additional hardware and user training whereas the solution to the right is a single system that mixes the different message traffic on one well-known platform Microsoft Outlook enabled by IOM.

Figure 1 Message Handling and Email Configurations So far we have discussed the advantages of using commercial email technology as a background for Military Message Handling without looking at the extent to which such solutions are applicable. The IOM solution is ideal for a number of situations: To bring military messages to the desktop PC within classified environments such as SECRET system high. To bring military messages to systems where email already exists, i.e. where Outlook is being used today. To provide message handling functionality within systems already based on a Microsoft Windows platform.

Together with IRIS Forms, IOM seamlessly integrates message content handling capabilities for manual or automatic processing of message standards such as USMTF, ADatP-3 or XML-MTF. For instance, when a message is received that has been prepared in accordance with one of these standards; it can be automatically detected by the IOM Profiler and used to update a database with the IRIS IMT. For manual processing, IRIS Forms can easily be invoked providing customisable forms. The level of integration is such that a message type attribute, e.g. OWN SITUATION REPORT can be selected by the user to be shown as one of the Outlook Inbox columns. The whole solution provides the user with the feeling they are using a totally integrated solution with a common interface throughout, rather than a loose coupling of mismatched products.

SSE/04527/WHI/009 - $Revision: 1.17

$ - Date: 4 January 2007

Page 7 /29

2.1

IRIS Product Family

The IRIS message handling range of products was first delivered to NATO in 1992 to meet a specific NATO ADSIA requirement for handling NATOs ADatP-3 (ADSIA being NATOs Allied Data Systems Interoperability Agency, which later became the NATO Information Systems and Exchange Branch, operating under the NATO C3 Staff). The project, for which IRIS was delivered, was implemented under a NATO NPIS (NATO Procedural Interoperability Standards) MOU and managed by the German BWB (MOD) on behalf of NATO. In September 1992, IRIS was accepted by NATO as having met their requirements.

2.1.1

Integrated product suite

The IRIS product range has now become an integrated product suite that provides a comprehensive set of messaging tools for military message handling, from the transport layer to applications. IRIS incorporates military message profiling and workflow capabilities, together with tools for application integration including information modelling and mapping modules enabling databases to be easily updated from incoming messages and enabling messages to be generated from databases.

2.1.2

Structured document support together with IRIS Forms

When integrated with IRIS Forms, not only is NATOs ADatP-3 Message Text Format (MTF) supported, but many other well known MTF standards are also supported, including USMTF Baselines, OTHT-GOLD and VMF (Variable Message Format). Each of these MTF standards can be converted to and from the XML-MTF standard based on XML (eXtensible Markup Language). IRIS Forms has been specifically designed to handle multiple MTF Baselines and publications, with minimum effort required to introduce new message types. Support is guaranteed for future Baselines, under annual maintenance contracts and, where necessary, through new product releases. In the USA, IRIS has been through annual JTIC testing in order to demonstrate conformance with each new USMTF Baseline publication (JITC being the DoDs Joint Interoperability Test Command at Fort Huachuca, in Arizona). For further information on the structured document support in the IRIS products, please read the IRIS Forms White Paper.

Page 8 / 29

Objectives

IOM provides a complete and fully integrated military messaging solution. A complete solution is more than just a user interface for preparing a military message. A number of key elements are required to fulfil the requirements of most systems. Military messages in a desktop environment Providing a user interface for preparing and processing military messages. Mixing military messages with interpersonal email. Providing a single user interface based around Outlook utilising the Microsoft Office features. Transmission and connectivity Organisational messages vs. personal email Interfaces to ACP127, STANAG4406/P772 and many legacy systems. Messages are sent from organisation to organisation. Organisational mailboxes are monitored by a profiler and messages are distributed to roles. Users act as roles, supporting a 24x7x365 staffing. Operational procedures workflow Support for operational procedures, workflow, staffing & releasing, and privileges.

Automated message processing

Enabling automated message profiling and distribution to operators or systems/applications. Encryption Authentication Message integrity Secure storage

Security

3.1

Military Messages in a Desktop Environment

The obvious difference between military messaging and email systems, based on standards such as SMTP, is that military messages contain information not found in standard email systems, hence the need for a standard like ACP123/STANAG4406 to define the representation of such information. Examples of the military information requirements are:
SSE/04527/WHI/009 - $Revision: 1.17 $ - Date: 4 January 2007

Page 9 /29

Security details such as Classification, Caveat and Privacy Marking. Processing of messages according to different message priorities (Precedence categories e.g. Immediate and Flash). The use of Subject Indicator Codes (SIC) for automated routing and message distribution. The use of MTF standards such as ADatP-3, USMTF and XML-MTF.

The basic requirement for a Military Message Handling System (MMHS) is to provide the user interfaces for working with this information.

3.2

Transmission and Connectivity

Whereas email and military message handling are similar in terms of the end user functionality, in many cases there are vast differences in the areas of transmission and communications. An essential part of Military Message Handling is assurance of delivery. This is one of the reasons that the X.400 standard was chosen as the basis for the ACP123/STANAG4406 definitions. X.400 ensures the delivery of messages where possible, providing comprehensive audit trails and nondelivery reports when failures occur. Email systems based on Internet technology do not provide this delivery assurance. Messages may be lost or left unmanaged depending on the different email systems used and their capabilities. This alone makes Internet email solutions unsuitable for formal military messaging requirements. Military messages are assigned a precedence from a list of at least four alternatives; flash, immediate, priority and routine. Additional precedence levels are often used in override and emergency situations. These precedence levels are used actively in the processing of the messages throughout the MMHS ensuring the processing of high precedence messages before lower priority messages or for restricting the message traffic to allow only the highest precedence messages, for example in the event of excessive message traffic. Email systems often provide the capability of assigning priorities; however these are mostly for information purposes on the receiving side, and their use does not necessarily ensure faster transmission between the mail servers. For military message handling, support of existing standards, such as STANAG4406 and ACP127 and established interfaces to networks such as the NICS TARE or the NMS, are required in order to communicate with other nations or systems using their own means of communication.

3.3

Organisational Messages vs. Personal Email

Military messages consist of information relayed between organisations rather than between individuals. The fact that military messages are handled by organisations according to operational procedures imposes differences compared to personal email in the required solutions. Military Message Handling organisational roles: is typically organised with different

Page 10 / 29

Message drafter, the role drafting an official message. Communications personnel, the role with knowledge of the delivery details and procedures of the messaging systems, ensuring correct delivery of the messages as well as distribution of incoming messages. Authorising/releasing officer, the role with the authority to release the message from the organisation. Co-ordinating officer, the role involved in the drafting process who reviews and provide comments on messages that have been drafted.

Military messages are addressed to organisational entities (e.g. Naval Material Command, Chief of Staff etc.) rather than to named individuals. Upon reception of messages, distribution to the responsible individuals is not only based on message addresses, but also on message content, subject etc. Larger installations with heavy traffic loads may have a number of communications personnel handling the pool of incoming and outgoing messages. In other words, several operators may monitor the same queue of incoming messages.

3.4

Operational Procedures - Workflow

Formal military messages are most often used in an environment with a set of operating procedures (or workflow) for the message drafting process and the message reception process. The actual process varies from organisation to organisation. Typical elements are outlined in Figure 2.

MMHS Workflow: Drafting

Notes IRIS supports operational procedures for message drafting, co-ordination and release

Staffing/Reviewer

Co-ordination

Drafter To Releaser Reject Releasing Officer

Staffing/Reviewer

Figure 2 Workflow The message drafter prepares a message, for example a daily briefing or situation report. Co-ordination may be necessary with other officers, either for additional input or for review comments. Co-ordination (also called staffing) can be shotgun (all at once) or sequential staffing (one after the other). Co-ordinating officers have the capability to attach notes with comments to a message for the attention of the message drafter. Some
SSE/04527/WHI/009 - $Revision: 1.17 $ - Date: 4 January 2007

Page 11 /29

drafters may directly release the message for transmission but in many cases this privilege is restricted to certain personnel/officers, and hence the drafter must send the message to the releasing officer. IOM supports all the alternative workflow options described above making it possible to define and configure new workflow concepts or modify the workflow details. This ensures that the operational procedures for message handling are correctly enforced. Many workflow procedures may evolve over time as the capabilities of the automated systems become better understood. IOM supports military workflow by providing a default initial capability which is configurable for future tailoring to suit the needs of the users.

3.5

Automated Message Processing

Since many military messages are in fact messages sent between automated systems, such as Command and Control systems, there is a requirement for the automated processing of messages in order to reduce the level of operator intervention. The IRIS Profiler (a part of IOM) can be configured with filters to automatically distribute messages to the correct operators/organisational units based on the contents of the message and to other systems or applications for automated processing. Some email products support an Inbox assistant which provides personal automatic processing of messages. Such functionality is also relevant for users of military messages. However, the automation typically required in the world of computerised, organisational systems is to process the messages before they are delivered to the roles. The term Profiling User Agent (PUA) is often used to describe an automated User Agent (mail client), such as the IRIS Profiler, for setting up automatic routing/distribution of messages based on content rather than on the typical personal addressing.

3.6

Security

IOM offers: Secure message transfer across unsecured networks Authentication of sender Secure storage on server Message integrity

IOM provides an off-the-shelf security solution addressing the three major security concerns: Privacy Identification Management

Page 12 / 29

IOM is based on standard Microsoft tools and readily available commercial standards, providing ease of configuration and use, as well as the flexibility and functionality needed to implement a secure and reliable system, whilst allowing the greater levels of security inherent in nationally developed and controlled security plug-ins.

SSE/04527/WHI/009 - $Revision: 1.17

$ - Date: 4 January 2007

Page 13 /29

Functionality

IOM is a client/server application based around a number of components that will be described in this chapter.

Figure 3 IOM Components In essence, the user will experience normal emails and military messages presented together in the standard Outlook email client window.

4.1

Users, Roles and Queues

User/role privileges are configured by the system administrator. When this set-up has been completed, the user can select one or more roles from the set of roles they have been granted access to (shown in Figure 4). IOM generates a folder where the personal inbox is displayed along with the inboxes of the selected roles. This effectively provides the user with an overview of all incoming messages of his interest. This folder is called the consolidated view. A sample screen shot is shown in Figure 5, where the roles AIR, INT and OPO are shown along with the personal inbox of the user iomuser.

Page 14 / 29

Figure 4 Selecting Roles Roles are organisational units, each with their own mailbox on the Microsoft Exchange server. This means that the messages are stored centrally and made visible to all the users that have activated the specific role. The military messages are not stored in the inbox of the individual user. Microsoft Outlook is used as the main user interface and military messages are received in much the same way as personal emails. Users will continue to receive personal emails in their own inbox as usual.

Figure 5 IOM Extended Outlook window Any military message property can be shown in a Microsoft Outlook column, e.g. the Classification shown in Figure 5 (other examples not
SSE/04527/WHI/009 - $Revision: 1.17 $ - Date: 4 January 2007

Page 15 /29

shown are Precedence and Message ID). Different icons are used to identify the military messages. Most of the powerful features of Microsoft Outlook are available for managing both military messages and personal email, e.g. folders, archiving, searching, sorting, grouping, auto preview etc. IOM has been specifically designed to benefit from standard Microsoft Outlook and Exchange server features.

4.2

Military Message Form

The standard Microsoft Outlook email window is used to view or create personal email. However, for military messages, the IOM Message Manager is used for entering and viewing message header information such as security classification, addresses, body text, attachments, and other attributes. This window consists of a Primary page showing frequently used information and a Details page for specialised information.

Figure 6 Message Form Primary Page The Details page contains less often used information, but ensures that all military attributes are available to the user. Features of the Message Manager include: Export to file / Import from file.

Page 16 / 29

Using attachments (binary or textual). Subject Indicator Codes (SIC), Special Handling Instructions etc. with browsers. Access to Workflow, MDE etc.

4.3

Addressing

IOM can use addresses stored on Exchange server or in an X.500 directory.

Figure 7 Addressing in IOM

4.4

Structured Documents

When integrated with IRIS Forms, IOM allows the users to draft and view structured documents. IRIS Forms can handle messages from a number of standards, e.g. ADatP-3, USMTF, OTHT-GOLD, VMF, XML-MTF, and other national formats. IRIS Forms presents a graphic view of the message structure and a form interface guides the user through the drafting process. It can validate messages to ensure that they comply with the chosen standards.

SSE/04527/WHI/009 - $Revision: 1.17

$ - Date: 4 January 2007

Page 17 /29

Figure 8 IRIS Forms editor for structured documents The IRIS Forms editor handles messages of multiple MTF baselines and provides a generic interface to all message types based on message definitions imported as Schemas (formerly known as Mission Files) produced by the IRIS Definition System (IRIS/DEF). The editor also has capabilities that allow system integrators to define customised views with editing capabilities for messages. This capability is based on XML and XSL technology. The Forms editor is described in more detail in the IRIS Forms White Paper. For further information on IRIS Definition System (IRIS DEF) please refer to separate White Paper.

4.5

Automated Profiling - Distribution and Processing

The ability to automatically distribute and process messages is an essential feature of any military message handling environment for two main reasons: Automatic distribution of incoming messages to the correct organisational units or operators. Since formal messages are relayed between organisations and an organisation may have several

Page 18 / 29

operational roles, it is important that all incoming messages are further distributed locally to all the appropriate recipients. Automatic processing based on message content, i.e. identifying messages to be automatically processed and interfacing with the appropriate third party applications. The automated processing of messages, such as ADatP-3 and USMTF, is an essential requirement in the Command and Control community.

The IOM Profiler is a very powerful tool for achieving automated processing of incoming messages. Using IRIS, filtering can be applied to message attributes including classification, SIC, priorities, addresses, keywords within the message body and by examining the message content - the message identifier (Message ID) and message validity 1 . The IRIS Information Mapping Tool (IMT) product provides the capability to automatically process, or generate, message contents in accordance with many message standards such as ADatP-3, USMTF, XML-MTF etc. IMT represents both messages and databases using a common data model technique and provides the developer with a high level mapping language to transfer information between the models. See the IRIS IMT White Paper for more information. With the IOM Profiler configured as an automated server (Profiling User Agent), connecting to IMT when required, the capability to distribute and process messages is achieved. The IOM Profiler distributes incoming messages to roles as illustrated in the following figure:

Figure 9 Distribution of Incoming Messages to Roles Figure 9 illustrates how an incoming message is received and distributed in IOM. The message is received by the exchange server through a gateway and stored in the organisations official mailbox. The IOM Profiler is

installed.

1 Filtering on Message ID and validity is only possible with IRIS Forms

SSE/04527/WHI/009 - $Revision: 1.17

$ - Date: 4 January 2007

Page 19 /29

automatically notified of the new message and distributes it to a number of role mailboxes or IMT for message processing based on the distribution criteria set-up by the IRIS administrator. All users, who have selected the receiving role will immediately see the message in their consolidated view.

4.6

Operational Procedures - Workflow

Military operational procedures are supported by workflow mechanisms in IOM. The workflow mechanism defines privileges and procedures for message handling and the rules are set-up by the IRIS administrator. The workflow mechanism is configurable and can be tailored to specific requirements. Below are some of the standard workflow operations: Sequential staffing: sequential review process where a message drafter can define a sequence of other roles that will receive the message for review, in sequence. Each reviewer can choose to forward the message to the next role in the sequence or to interrupt the review and send the message back to the drafter. Staffing shotgun: a parallel review process where the drafter can select a number of roles, to receive the message for review at the same time. Review and Release: some roles may not be allowed to release organisational messages. The review and release process sends the message to a role with release privileges. The release role can choose to release the message to the external addressee or reject the release and send it back to the drafter. Transfer responsibility: military organisational messages are distributed to roles who must take action on the messages. If a receiving role is unable to take action on an incoming message then the responsibility can be transferred to another role.

To support the above workflow operations, IOM implements a note mechanism by which a user can attach notes to workflow messages. These notes are internal to IOM and will not be included when messages are released to external recipients.

4.7

Connectivity to Other Systems Gateways

IOM can be connected to message transfer systems through a number of message gateways. The gateways are capable of converting from the format used by IOM to a number of military message formats. The standard Microsoft Exchange Server is provided with an SMTP and X.400 connector. While these connectors may be sufficient to implement a national message handling infrastructure (see section 5 for examples) it will often be a requirement to connect IOM to a legacy and/or current military network using one or more military protocols. To support connections to such systems IOM contains a Gateway component based on a plug-in architecture allowing administrators to easily set-up several differently configured gateways through a common interface.

Page 20 / 29

On an IOM server any number of gateway instances can be activated; each supporting a specific protocol and delivery mechanism. Currently 2 gateways are available for IOM: STANAG4406 Ed. 3 connector with full Message Transfer Agent (MTA), P1 and P772 capabilities. This connector is based on a third-party product but is fully integrated and supported by IOM. A file-based connector supporting a number of military protocols. Supports ACP127, ACP126(m), JANAP128 and other protocols.

Systems integrators can develop other gateways in support of other protocols or delivery mechanisms as required. This is done by implementing a gateway back-end that handles the transfer of messages and conversion of protocols. The IOM gateways are administrated from the normal Exchange System Manager.

Figure 10 IRIS Gateways with Plug-in Backends When a new gateway is installed it can be configured to handle specific address types and handle a certain address space. In support of addresses for the chosen protocol, IOM supports the required address types required for the protocols (e.g. Plain Language Address and Routing Indicator for ACP127). Once the address types and address spaces are defined the Exchange Server routing engine will automatically route and handle messages through the gateway.

SSE/04527/WHI/009 - $Revision: 1.17

$ - Date: 4 January 2007

Page 21 /29

IRIS MMHS Solutions

Many nations have a requirement to provide a Military Message Handling System (MMHS). While most modern messaging systems are required to be STANAG4406 compliant, it is not often appreciated that solutions can be implemented that do not necessarily need a fully STANAG4406 compliant solution for all users and that cost-effective alternatives are available offthe-shelf. A national system can be provided with all the benefits of STANAG4406 but based on using Systematics products. Gateways supporting a fully-compliant STANAG4406 capability, for international connection to other countries and NATO, can then be installed when required. The following sections focus on the alternative architectures that can be used to fulfil national military messaging requirements with international interoperability in mind. It will be shown that a national MMHS can be implemented using Systematics IOM and the STANAG4406 connector, possibly in stages as national requirements/international obligations develop and by continuing to reuse previous installations as the system is enhanced. The architecture of the proposed national MMHS is based around the IRIS product suite on a Microsoft Windows infrastructure. All architectures offer the same basic functionality to the end users in terms of user interfaces, messaging capabilities, elements of service (i.e. all message attributes as defined in STANAG4406) etc.

5.1

A National Military Message Handling System

In the simplest form a national MMHS provides messaging between national sites/users. IOM is a COTS solution which has been designed to specifically support military messaging requirements, based on Microsofts Exchange Server and Outlook products. Therefore, the backbone of the national messaging system can be either based on a central Exchange Server or on a network of Exchange Servers. If a national email system consisting of a network of Exchange Servers exists, then these existing servers may be reused to support both the informal email system and the MMHS. The architectures of such systems are shown below.

5.1.1

Choosing the appropriate architecture

The IOM solution is extremely flexible with support for a wide range of alternative configurations and architectures. In the following sections, six examples of architectures are described. Architecture 3 offers a costeffective solution which supports modern and legacy communications protocols with the ability to be extended with additional STANAG4406 gateways (Architecture 4) and multiple Exchange Servers (Architecture 5). This can also be further enhanced to form a combined solution with backbone STANAG4406 MTAs providing a redundant failure-tolerant MMHS solution. Regardless of which architecture is chosen a messaging infrastructure can be implemented in increments, always retaining investments as national requirements or international obligations develop.

Page 22 / 29

5.1.2

MMHS Architecture 1 Centralised Server

Figure 11 Centralised Server Architecture 1 is only recommended for national systems with a small number of sites and users. There is a single point of failure due to the central Exchange Server and bandwidth requirements between the Exchange Server and the IOM clients are relatively high. It is however a low cost solution with central administration. Systematic can provide gateways for interconnection to other systems e.g. legacy telex systems, NICS TARE and the planned NATO Messaging System.

5.1.3

MMHS Architecture 2 Distributed Local Servers

Figure 12 Distributed Local Servers Architecture 2 is recommended for nations with organisational sites each with multiple users and/or functional roles. Bandwidth requirements are reduced to only include actual message traffic while client/server communication takes place on a local area network at each site. This architecture does not have a single point of failure and although central administration can be achieved with Windows Active Directory, the system will still be operational and manageable even if a domain controller fails. IOM is designed to handle both personal/informal email as well as organisational military messaging on the same network of Exchange Servers. This means that Architecture 2 can be implemented on top of an

SSE/04527/WHI/009 - $Revision: 1.17

$ - Date: 4 January 2007

Page 23 /29

existing email infrastructure or, in the case of a completely new MMHS infrastructure; email support can be made available. The backbone of Architecture 2 is a TCP/IP network and although message traffic between sites/organisational elements is based on ESMTP, every user has the full messaging capability of STANAG4406 in terms of elements of service.

5.1.4

MMHS Architecture 3 Gateway to External Networks

Architecture 3 shows how a national MMHS implementation, based on Architectures 1 or 2, can be amended with gateways for interconnection to other systems. Multiple gateways can be provided as required and, for example, multiple sites can connect directly to NICS TARE or the NATO Messaging System through a single gateway.

Figure 13 Gateway to External Networks The STANAG4406 gateway is closely integrated with IOM. Messages on the national MMHS are automatically routed through the gateway to the external systems.

5.1.5

MMHS Architecture 4 STANAG4406 Infrastructure

Architecture 4 shows how a fully compliant STANAG4406 capability can be added to the architectures described previously.

Page 24 / 29

Figure 14 STANAG4406 Infrastructure Architecture 4 makes every site/organisational element STANAG4406 compliant. This adds flexibility as every element can be taken offline and fielded with other STANAG4406 compliant networks, e.g. in support of an exercise or operation. Each element can interconnect to other networks through the gateway capabilities.

5.1.6

MMHS Architecture 5 Multiple Organisations per Site

If one physical site hosts more than one organisational unit and a large number of users, consideration should be given to installing the Exchange Server on a separate server and maybe even to installing multiple Exchange Servers one for each organisational unit as shown in Figure 15.

Figure 15 Multiple Organisations per site Architecture 5 is recommended for fixed sites with multiple organisations and large number of users. The separate Exchange Servers for the organisations help to share the workload; however, having just one shared STANAG4406 gateway is sufficient for most sites as this only handles the official organisational messages in and out of the site while the Exchange Servers handle all message stores and users.
SSE/04527/WHI/009 - $Revision: 1.17 $ - Date: 4 January 2007

Page 25 /29

5.1.7

MMHS Architecture 6 STANAG4406 Backbone

In Architectures 4 and 5, the STANAG4406 connectors are interconnected to form the X.400/STANAG4406 network. Routing and rerouting is automatic. An alternative to having MTAs at every site is to have a backbone network of MTAs as shown in Figure 16.

Figure 16 STANAG4406 Backbone Architecture 6 consists of a number of backbone MTAs (BBMTA) interconnected to form a STANAG4406 compliant infrastructure for a national MMHS. In this architecture most BBMTAs are installed in secured locations and form a redundant failure-tolerant network supporting the national sites. Each site can be connected to one or more BBMTAs for added redundancy and any number of BBMTAs can be connected to external networks thus providing a high availability not only for the national MMHS but also the interoperability with foreign MMHS solutions. If some or all sites are required to be STANAG4406 compliant, a combination of Architecture 4 and 6 could be considered.

5.2

Directory Services

Common to all the architecture alternatives described above is a directory service required to provide valid address information to the users. Two different directory service solutions for a national MMHS are discussed in this section: based on Microsoft Active Directory or X.500/LDAP.

5.2.1

Microsoft Active Directory

All the architectures described above assume a Windows 2000 or 2003 infrastructure with Active Directory in a single Forest. In such an environment, central administration is possible and address information is automatically replicated between the servers. Address information can also be replicated with external naming services of external messaging systems. Active Directory is a feature of Windows 2000 and 2003 servers.

Page 26 / 29

5.2.2

X.500/LDAP

If address information is to be stored in a specific schema (e.g. NATO ACP 133) X.500 servers can be installed either centrally or distributed and replicated using X.500 DISP. IOM is LDAP compliant and can browse address information stored in LDAP/X.500 servers. As for a Microsoft Active Directory solution, the X.500 servers can replicate information with foreign systems, e.g. the future NATO Messaging System.

SSE/04527/WHI/009 - $Revision: 1.17

$ - Date: 4 January 2007

Page 27 /29

IOM Security

In the IRIS environment, security involves several important topics that can be grouped into the following categories: Privacy, Identification and Management of the Security Strategy.

6.1

Privacy

Network monitoring programs are readily available for monitoring network traffic and intercepting messages. Radio networks are even more vulnerable due to their open nature. A message can be captured by a third party unknown to the sender or intended receiver. If either the sender or intended receiver realises that the message was not delivered, they are likely to accept that it was lost and simply resend it. Perhaps even more potentially damaging is the ability of a third party to intercept and modify the content of a message before delivering it to the intended recipient. To counter these threats a mechanism is needed to ensure that a message has not been read or tampered with by anyone other than the intended recipient.

6.2

Identification and Authentication

It is common knowledge among hackers that the From field in a message may contain any information, with the potential to mislead the recipient. Some marketing companies use this technique to hide their identities when sending messages. This trick works because people generally trust the information in the From field. In a secure system, this is not enough and a method to guarantee the identity of the sender is needed.

6.3

Solving the Security Issues

The security provided within IOM has been designed with the emphasis on interoperability, compliance with international standards and ease of customisation. IOM integrates with Public Key Infrastructure (PKI) in a manner that enables: Signing of messages to ensure verification of sender identity and thereby content integrity. Encryption and decryption to avoid unwanted access.

A full coverage of PKI concepts and all the components involved are outside the scope of this document.

Page 28 / 29

6.4

Informal versus Formal Messaging

IOM allows the user to work with informal as well as formal messages. Informal messages are the usual email messages that can be sent to an individual or a group of individuals, otherwise referred to as person-toperson messaging. When seen from the IOM perspective, formal messages are messages that are sent to an organisation. These messages usually end up in one or more role inboxes within the organisation with one or more individuals taking action based on the content of the message. These are two very different situations that IOM handles seamlessly and intuitively, but that require extra consideration when a security solution is implemented.

SSE/04527/WHI/009 - $Revision: 1.17

$ - Date: 4 January 2007

Page 29 /29

Technical Specifications

The IOM server components run on these platforms: Microsoft Windows Server 2000 with Microsoft Exchange Server 2000 Microsoft Windows Server 2003 with Microsoft Exchange Server 2003

The IOM client runs on these platforms: Microsoft Windows 2000 and XP Microsoft Outlook 2000, XP and 2003

The IRIS gateway supports these communication protocols: ACP 127 ACP 126(m) JANAP 128 DD 173 DOI 193 Std DOI 103 Special STANAG4406 RFC 822 (Email) XML MIP MEM Extended SMTP