Replication for Tactical Directory

Why is Directory Needed for Military Applications?

ACP 133 Directory is a key component of most modern military communication and messaging systems. ACP 133 defines a complex military schema, based on X.500, which provides support for both applications and information services. This international core specification is used as the basis for national and NATO directories.

An ACP 133 Directory provides a general purpose infrastructure that can be used for a variety of military purposes. The most important application of directory is support of Messaging Clients. A typical military messaging client might comprise of:

• Microsoft Outlook (base email client).
• Boldon James Safe.Mil (military extensions).
• Boldon James Masterkey (directory lookup).

The integrated directory lookup that is provided by a client solution is needed for several reasons:

• Recipient Identification (search or browse of the directory).
• Recipient Verification: it is important to verify at origination that messages are correctly addressed, and directory helps this to happen.
• Recipient Parameters: to check that the capabilities and maximum size of message can be handled by the recipient.
• Certificate: to verify digital signature of incoming messages and to encrypt outgoing messages.

It can be seen the the directory is supporting essential reliability and security of core services.

Military Directory Replication

Military directory has a very simple replication strategy: “Replicate data wherever needed”. If an application contacts a directory server to get information, the necessary data should be replicated into this server. There should be no requirement to contact other directories, as this could lead to reliability issues in the event of communications failure. The consequence of this is that a military directory has very high level of data replication.

This is discussed in more detail in the Isode whitepaper [Building a Highly Replicated Directory: The case for X.500 DISP].

What is Tactical Directory?

A military operation will typically have one or more tactical headquarters with significant computing and communications infrastructure. A tactical directory would be used to support messaging and other infrastructure in the tactical HQ. The infrastructure for a tactical HQ will typically be put together over a few days before an operation, and this infrastructure (including the directory) will be tailored for the operation. A tactical HQ will typically have two sets of infrastructure in order to support continuous operation and mobility. One set will be operational, and the other will be moved to the next operational site.

It must be reasonably straightforward and fast to set up a tactical directory, and this process should be easily repeatable to support multiple sets of infrastructure and partial or total destruction of this infrastructure.

Once operational, tactical messaging and other applications will contact the tactical directory. The services provided by the are essentially the same as those provided by any other military directory. Given that queries will be resolved locally, the (tactical) location of the directory is not significant to its operation. The important difference for a tactical directory is getting initial data into the directory and then keeping it up to date; This is directory replication.

What Data is Needed?

The tactical directory should hold data relating to information relevant to the operation, and in particular data on all potential senders and recipients of messages being sent to or from the tactical operation. It is important to include all data that might be needed. However, it is undesirable to include information that will not be needed. In general it is not sensible to distribute information to where it is not needed (need to know). A more important consideration here is that the tactical directory may have limited external communications bandwidth. Because of this, it is important not to waste communications resource in updating data that is not needed in the tactical directory.

Data in the tactical directory may come from many groups and countries. Combined operations (e.g., NATO) are common, and in this situation it is important to be able to put together a directory that holds information from all of these different locations. The ACP 133 standard adopted across NATO is important to enabling this.

Master Data and Data Feeds

Data should not be mastered in the tactical directory, as an instance of the tactical directory may be destroyed and changes made there would be lost. Also, tactical HQ staff will generally have more pressing things to do than update the directory. In general, updates to a tactical directory should be fed from an appropriate supporting server.Updates are fed to multiple tactical directory servers (DSAs or Directory System Agents), some of which may be non-operational (e.g., in transit). Thus you can have as many directory servers as you need, all holding the same data.

X.500 DISP

X.500 DISP (Directory Information Shadowing Protocol) is the standard replication protocol that is a part of X.500 and of ACP 133. It is the only open standard for directory replication. DISP has a number of important features relevant to a tactical directory:

• Incremental replication, to optimize network and resource usage.
• Flexible update scheduling.
• Data filtering.
• Security features: digital signature of each connection and of each update.

These characteristics, as well as NATO standards compliance, make DISP ideal for sending data to the tactical directory. It should be configured so that a single DISP connection can feed a directory with necessary updates. From the standpoint of the tactical directory server, this needs to be a simple setup, so that it is very straightforward to configure a new tactical directory.

Getting the Right Data to the Tactical Directory

Because military directory is highly replicated, the data needed to supply the tactical directory will be available in the server that is going to supply it (at field HQ in the example above). There is a need to configure the information that is sent to the tactical directory. X.500 attribute filtering may be useful in some situation, where directory entries contain information that is not needed by the tactical applications.

The most important optimization is to configure which entries are sent to the tactical directory. This could be configured for each replication agreement. Difficulties with this are:

• The configuration is complex, and this complexity affects both sides of the agreement.
• Changes in information sent need to be managed at the replication agreement.

A better approach is the mechanism of the type set out in JSP 457 (the specification of the UK Military Directory). This uses a “publishTo”, multi-valued attribute in every entry. The values indicate where the entry can be distributed to. This can be used to control general distribution (e.g., “PublishTo=NATO Countries”) and also to control distribution to specific tactical directories. This can be applied to single entries or to areas of the directory (e.g., a subtree) using the X.500 collective attribute mechanism.

The key advantage of the PublishTo approach, is that control on data distribution is tied to the data and not to the replication agreement. This means that the configuration is administered in the natural location, and that replication agreements are kept simple. It gives a flexible and efficient approach for controlling replication to the tactical directory.

Management

Managing the local tactical directory will have requirements similar to military directory management. It would generally be a component that would just run and do its job. It is important to check that updates are getting through correctly. A tool such as Isode’s M-Vault Console (MVC) is ideal for this. MVC can monitor either the supplier or consumer end of an agreement (or both) on multiple directory servers. It will alert the operator to any delays or failure in replication. This is illustrated in the screenshot below.

Conclusions

This paper describes replication to the tactical directory, and how this can be implemented with ACP 133 directory products such a Isode’s M-Vault. Key functionality identified is used of X.500 DISP for replication, and a PublishTo mechanism to control data distribution.