DISTRIBUTED TRAINING NETWORK GUARD (DTNG)

Transcription

1 AFRL-IF-RS-TR Final Technical Report January 2005 DISTRIBUTED TRAINING NETWORK GUARD (DTNG) Trusted Computer Solutions APPROVED FOR PUBLIC RELEASE; DISTRIBUTION UNLIMITED. AIR FORCE RESEARCH LABORATORY INFORMATION DIRECTORATE ROME RESEARCH SITE ROME, NEW YORK

2 STINFO FINAL REPORT This report has been reviewed by the Air Force Research Laboratory, Information Directorate, Public Affairs Office (IFOIPA) and is releasable to the National Technical Information Service (NTIS). At NTIS it will be releasable to the general public, including foreign nations. AFRL-IF-RS-TR has been reviewed and is approved for publication APPROVED: /s/ ROBERT M. FLO Project Engineer FOR THE DIRECTOR: /s/ JAMES W. CUSACK, Chief Information Systems Division Information Directorate

3 REPORT DOCUMENTATION PAGE Form Approved OMB No Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing this collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA , and to the Office of Management and Budget, Paperwork Reduction Project ( ), Washington, DC AGENCY USE ONLY (Leave blank) 2. REPORT DATE 3. REPORT TYPE AND DATES COVERED 4. TITLE AND SUBTITLE January 2005 DISTRIBUTED TRAINING NETWORK GUARD (DTNG) 6. AUTHOR(S) Jonathan Beskin Linda Schippler Romil Sharma FINAL Mar 00 Oct FUNDING NUMBERS C - F C-0027 PE F PR TA - 00 WU - P1 7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) Trusted Computer Solutions 2350 Corporate Park Drive Suite 500 Herndon VA SPONSORING / MONITORING AGENCY NAME(S) AND ADDRESS(ES) AFRL/IFSB 525 Brooks Road Rome NY PERFORMING ORGANIZATION REPORT NUMBER N/A 10. SPONSORING / MONITORING AGENCY REPORT NUMBER AFRL-IF-RS-TR SUPPLEMENTARY NOTES AFRL Project Engineer: Robert M. Flo/IFSB/(315) a. DISTRIBUTION / AVAILABILITY STATEMENT Robert.Flo@rl.af.mil 12b. DISTRIBUTION CODE APPROVED FOR PUBLIC RELEASE; DISTRIBUTION UNLIMITED. 13. ABSTRACT (Maximum 200 Words) The purpose of this project was to develop a Distributed Training Network Guard (DTNG) to allow simulation systems operating at different security levels to interoperate within a common, synthetic environment, thereby enhancing the capability to support full mission training and rehearsal. More specifically, the objective was to develop and demonstrate a multi-level security (MLS) network guard that supports distributed simulation training systems interoperating at different security levels within a High Level Architecture (HLA) environment. 14. SUBJECT TERMS simulation, distributed simulation, multi-level security, MLS, high level architecture, HLA, mission training, mission rehearsal 15. NUMBER OF PAGES 16. PRICE CODE SECURITY CLASSIFICATION OF REPORT UNCLASSIFIED 18. SECURITY CLASSIFICATION OF THIS PAGE UNCLASSIFIED 19. SECURITY CLASSIFICATION OF ABSTRACT UNCLASSIFIED 20. LIMITATION OF ABSTRACT NSN Standard Form 298 (Rev. 2-89) Prescribed by ANSI Std. Z UL

4 Table of Contents 1. INTRODUCTION GOALS/OBJECTIVE COMPONENTS ARCHITECTURE PROCESSES FOLLOWED HLA SUPPORT PHASES/MILESTONES BUGS/ENHANCEMENTS PERFORMANCE ISSUE TIME MANAGEMENT SUPPORT OWNERSHIP MANAGEMENT SUPPORT TRANSITION/FUTURE WORK SUMMARY i

5 1. INTRODUCTION 1.1 GOALS/OBJECTIVE The United States Air Force has embarked on a major effort to provide the warfighter with a simulation training environment called Distributed Mission Training (DMT). The DMT global network concept calls for interfacing geographically separated simulations (live, virtual, and/or constructive) into a realistic synthetic training environment to enable warfighters to train the way they fight! However, today s distributed simulation environments can only operate at a single system high security level since there are no security mechanisms to address the transfer of data between simulations executing at different security levels. Trusted Computer Solutions was tasked to develop a Distributed Training Network Guard (DTNG) to allow simulation systems operating at different security levels to interoperate within a common synthetic environment thereby enhancing the capability to support full mission training and rehearsal. More specifically, the objective was to develop and demonstrate a multi-level security (MLS) network guard that supports distributed simulation training systems interoperating at different security levels within a High Level Architecture (HLA) environment. 1.2 COMPONENTS The Air Force Research Laboratory, Warfighter Training Research Division (AFRL/HEA) Mesa AZ and the Information Systems Division (AFRL/IFS) Rome NY in conjunction with Trusted Computer Solutions (TCS) Inc. Herndon VA, the primary development contractor, 1

6 and L3 Communications at the Mesa Research Site (MRS) embarked on a multilevel security program known as the DTNG. The DTNG program has designed and developed both a Trusted Bridge Federate (TBF) and a companion Security Reclassification Rule Set Intelligent Assistant Tool (SRRSIAT). Collectively, these two components are referred to as the DTNG. The TBF is the physical real-time automated network guard component that supports twoway data transfer between simulation federations operating at different security levels. The SRRSIAT is a stand-alone interactive graphical user interface (GUI) application that provides the federation security classification/domain expert the capability to develop and review classification rules that govern the transfer of objects, attributes, interactions, parameters, and the execution of cross security level Run-Time Infrastructure (RTI) operations for cross federation object models (FOMs). The TBF is designed to be FOMindependent and operates using a subset of the confederation of FOMs that include the objects and interactions that can cross security levels. The FOM associated with any specific exercise forms the basis for all the objects and operations against which filtering and guising rules are applied. These rules can be simple yes/no rules or more sophisticated rules. For example, filtering rules may be to zero out, clear, or null the data values of attributes, subattributes, parameters and sub-parameters. Guising or sanitizing rules allow for changing attribute or parameter values within the constraints of the data type. 2

7 2. ARCHITECTURE The TBF architecture is illustrated in Figure 1. This architecture diagram is simplified to show two federations, each operating at a different security label, each with its own RtiExec and FedExec process. The RtiExec process sends messages out to the Federation, and the FedExec process receives messages from the Federation. Both of these are provided as part of the RTI library from MäK Technologies or other RTI vendors. Communication between the federations is accomplished through a bridge federate, where a bridge federate has been defined as follows: A bridge federate is a federate that participates in multiple federations. It is comprised of several internal components: one surrogate federates for each participating federation, a transfer manager, and a FOM mapping specification. Single-Level Federation RtiExec/ FedExec FOM L FOM L Federate Federate Untrusted Surrogate Federate L Trusted Bridge Federate Untrusted Surrogate Federate H FOM TBF Trusted Bridge Federate Single-Level Federation RtiExec/ FedExec Federate Federate FOM H FOM H Figure 1. Trusted Bridge Federate Architecture 3

8 The TBF includes an Untrusted Surrogate Federate (USF) for each federation operating at a different security label and a single Trusted Bridge Process (TBP). The USF processes operate as federates on the trusted operating system component to handle the cross-federation operations for all federates on the system-high networks. For the example of object publication, a USF will appear to publish all objects published by federates on all other federations other than the federation operating at its security label and will forward on all objects published by its federation (that have been released by the TBP). There is no direct communication between the USF processes executing at different security labels. Communication between the USFs occurs through the TBP. The TBP is responsible for mapping and processing data from one federation to another federation. It performs any necessary modifications of the data in accordance with the security policy and guarantees the integrity of the data. It also includes all the processing necessary to manage asynchronous communication between the USFs. In the TBF architecture, every federate, in all attached federations including the TBF itself, uses the confederation FOM. The TBP security filter only passes data between the USFs: (1) if there is a security policy for that object or interaction; and (2) if the data meets the security policy rules for that object or interaction. This architecture represents the most efficient approach to implementing the TBF. It is not dependent on availability of RTI vendor source code and does not require any modification to the RTI specification. It also consolidates and protects the trusted software on the trusted 4

9 operating system component. The USF encapsulates all the HLA functionality required to communicate with other federations, while the TBP encapsulates all of the security-relevant functions as well as all communication with the USFs. The TBP controls the execution and communication between the USFs. There will be two or more USFs connected to a single TBP, one for each federation connected to the guard device. However, standard security approval processes do not typically permit direct or indirect connection between Top Secret Sensitive Compartmented Information (SCI) and Unclassified systems. Therefore, connection of multiple single-level federation networks will likely be limited to single-step interconnections. For example, accreditation approval can reasonably be expected for connections between Top Secret-SCI to Secret-US and Secret- Releasable Levels or between Secret-US and Secret-Releasable Levels to Unclassified. On startup, the TBP reads a configuration file to determine at which security label each USF should be created, and how to start the USFs. The USFs will then perform normal startup activities for a federate and will initiate communication with the RTI for its federation. The TBF uses the confederation FOM but will only operate on objects, attributes, interactions, and parameters for which there are security-filter rules. Since the uniqueness of HLA handles is only maintained within a federation, the TBF must maintain unique identifiers across all USFs. Therefore, prior to processing any communication between federations, the FOM will be processed to provide the following information: 5

10 A list of object classes, where each is mapped to a unique identifier A list of interaction classes, where each is mapped to a unique identifier A list of attributes, where each is mapped to a unique. These attributes would additionally have a data type and a data size associated with them. This information is obtained from the Object Model Template (OMT). A list of parameters, where each is mapped to a unique identifier. These parameters will additionally have a data type and a data size associated with them. This information is obtained from the OMT. At the heart of the TBF is the security classification filtering process. For each source security label to each target security label, filtering rules are defined based on the rule set defined using the SRRSIAT. The state cache holds both state information and the current value of all received entity attributes for all entities. Entity information includes the most current value of all attributes that have been received for all entities. In addition to the original design documentation, Unified Modeling Language (UML) models were created to support the design effort. These models are difficult to reproduce on paper, but have been included on the CD for review. The files are SRRSIAT.mdl and TBF.mdl for the different respective projects. 6

11 3. Processes Followed As much as possible, TCS engineers follow standard development, configuration management, coding and review processes for all TCS products, both commercial and custom, such as the Trusted Bridge Federate. TCS used its standard C++ and Java programming methodologies for the DTNG. These standards are attached to this document, named, the Trusted Computer Solutions Guide to C++ Programming Style and the Java Coding Conventions. In addition to these standards, TCS also used Scott Meyers, Effective C++ and More Effective C++, as strict guidelines for developing fast, efficient, readable code that is of the highest quality. TCS also used on the Trusted Bridge Federate project the standard TCS configuration management practices, as documented in the attached, TCS Configuration Management Plan. Finally, TCS employed a system of biweekly peer review for all design and coding. This was a semi-formal system, whereby the individual engineers would meet on a daily basis to discuss the existing design and development strategies. As classes and methods were developed, all members of the team were consulted for design issues before implementation. Every two weeks, the engineers on the project would review each other s code to gain fuller understanding of the project and to ensure that no errors were being introduced. 7

12 4. HLA SUPPORT The High-Level Architecture (HLA) mandate establishes a common high-level simulation architecture to facilitate the interoperability of all types of models and simulations among themselves and C41 systems. The HLA is designed to promote standardization in the M&S community and to facilitate the reuse of M&S components. The HLA is defined by three components: federation rules, the HLA Interface Specification, and the Object Model Template (OMT). The Run-Time Infrastructure (RTI) software implements the interface specification and represents one of the most tangible products of the HLA. It provides services in a manner that is comparable to the way a distributed operating system provides services to applications. The DTNG has used implementations of the RTI from two major companies: DMSO and MaK Technologies. The TBF initially used the DMSO RTI but a decision was made by the Air Force in conjunction with TCS that it was not optimal for real-time applications. Currently the DTNG uses and supports the MaK RTI up to version and can also support all versions of the DMSO RTI with minor modifications. An effort to move to MaK RTI version 2.0 is currently in progress. The TBF currently supports Federation Management (Create, Join, Resign, Saves, Restores, Synchronization), Declaration Management (Publish, Subscribe, Unpublish, Unsubscribe), and Object Management (Register/Delete Object Instance, Attribute Update, Attribute Update Requests, Send Interactions). Management Object Model (MOM) calls are not handled because they are a security risk for federations and the data is not passed to the TBF 8

13 (by design of HLA). Time Management, Object Ownership, and Data Distribution Management are not currently supported by the TBF but are possible enhancements provided proper funding and demand. 9

14 5. PHASES/MILESTONES The DTNG program consists of two phases. Phase 1 consisted of a 36-month contract, beginning March 2000 with TCS During this phase, the DTNG (TBF and SRRSIAT) was developed using a spiral schema. Informal demonstrations, formal T&E, user documentation, initial certification and accreditation support, and transition to ASC/YW were all completed. Phase 2 (FY03-04) called for support to an ACC Operational Customer. TCS was tasked to perform operational site-specific integration, initial operational rule set development, C&A support documentation development, and technology transfer, which are all currently underway. The Operational Customer has been determined to be TACCSF in Albuquerque, NM. The DTNG program was designed with two spiral enhancement cycles to provide adequate time to implement corrective actions. After each spiral enhancement, tests were performed to test specific functions and key performance measures. The DTNG TBF Initial Capabilities Demonstration was successfully demonstrated on July 25, A series of vignettes were demonstrated to a broad range of the M&S community. Through the series of five demonstration vignettes, eight of the nine functional areas of the TBF were successfully demonstrated. The nine functional areas are: 1. Rules Library 2. Filtering and Cache 3. Trusted Guard & Control 4. Message Passing Interface 10

15 5. Inbound Message Handler 6. Outbound Message Handler 7. Human Computer Interface 8. Configuration Support 9. Auditing The security auditing function had not been completed in time for the demonstration. This vital security function is necessary for certification and accreditation of the system. This functionality, as well as the continued development of the SRRSIAT, was all addressed during the Spiral 1 Enhancement phase. The DTNG Spiral 1 Test was conducted 6 10 January 03 with the primary objective of the test being the performance measurements of the TBF, since a key performance parameter of the system is to provide a near real-time throughput of 12MS 16MS. The test was successfully conducted in that valuable performance data was collected while testing the system under different load levels and test conditions. In addition, system integration test, security testing, and audit feature capabilities were evaluated. Unfortunately, the allotted time devoted to the remaining test was insufficient due to the effort placed in conducting a sound performance measurement test. The SRRSIAT initial capabilities were also demonstrated although the system still required additional development and testing. The main issue resulting from the Spiral 1 Test was the TBF spike latency measurements discovered during the extensive performance measurements test. Also, security test were not sufficiently extensive to determine whether all basic security aspect were being executed properly. 11

16 The DTNG Spiral 2 Test & Demonstration was conducted February 10 21, Spiral 2 enhancements were based on ensuring security and auditing features of the system were properly installed and configured, completing the SRRSIAT modules, and resolving issues/problems detected during Spiral 1 Test. Spiral 2 Test focused on the performance, security, and auditing capabilities of the TBF, and SRRSIAT functionality and GUI evaluation, as well as a major systems capability demonstration of the DTNG to DoD organizations and contractors. The SRRSIAT functional capabilities were demonstrated by developing the security rule set for Vignette 5. Once the rule set was developed, it was compiled and imported into the TBF and tested. This specific capability was part of the overall demonstration that was presented to DoD organizations and contractors. Trusted Computer Solutions has wrapped up the DTNG version 0.9 Beta to be delivered to the US Air Force by the end of October 2003 and has already begun Phase 2 of the program. 12

17 6. BUGS/ENHANCEMENTS The current bugs and requests for enhancements for the TBF all fall between Priority 3 and Priority 5. None are critical to the functionality of the TBF. They are as follows: 1. Priority 3 Compartmenting Issue With Trusted Solaris, a high side service that binds to all interfaces will receive low side data. This would mean that the high side USF receives federation traffic intended for the low side USF if they both use the same port number. The high side USF then sends this data through the TBF to the low side, which causes an infinite loop. It may be possible to create and use separate compartments to prevent this problem. It may also be possible to use the TCSecure:eFilter component to enforce this security. These solutions need to be tested. 2. Priority 3 Performance Issue (see Section 7.1.1) The TBF seems to have a "spiking" problem in its performance. About 95% of the data passes well under the target range of 12-16ms but 5% of the data spikes as high as 100ms. The exact cause has not yet been determined. One possible fix might be converting all the Unix queues to customized Shared Memory Segments. This solution would be an enhancement to the TBF. 13

18 3. Priority 3 No Rule Support Against RTI Operations TBF needs to support rule specifications against RTI operations. For example, the Rule Library should be able to handle a rule such as do not allow any discover object instances to go across. 4. Priority 4 Rule Generator Needs To Generate attributes.txt Configuration File The TBF needs an "attributes.txt" file, which is currently being generated by a Perl script. The SRRSIAT/Rule Generator needs to be able to generate this file upon creation of libraries. This file is used by the TBF to map class and attribute names to the internal numbers used by the TBF. 5. Priority 3 Level Issue (FIXED) Currently in the configuration file of the TBF, it is necessary to have the lines in the correct order otherwise it is misleading as to which is the high side and which is the low side. Someone not careful or not knowing about this constraint might get confused with how the TBF seems to be "reversed". This needs to be corrected to make the configuration file easier to work with. 6. Priority 4 Simplify Installation Process The TBF/Srrsiat needs a simplified installation process so that a network administrator can install both products easily. In addition, an icon is 14

19 necessary to allow the TBF to be run by someone other than the root role, which is currently necessary to allow TCSecure:eFilter to operate. 7. Priority 3 Variable Length Data A more permanent way needs to be implemented for data coming in of variable length. Currently there is a work-around by "estimating" the max size of the data and just storing it in a character array and allocating enough memory for that character array. 8. Priority 5 Hanging Child Processes If for some reason the TBF exits abnormally, the USF processes will continue to run, and the TCSecure:eFilter will not close the necessary ports. If the user is unaware of this, the TBF will print out several error messages when it is next run. The TBF needs to check for the presence of the USF processes, and force them to shut down before the TBF starts up. 9. Priority 5 Add Time Management Support (see Section 7.1.2) Adding HLA Time Management Support can be done if necessary. However, this will require significant effort and design. 10. Priority 5 Transition to MAK 2.0 This is currently being dealt with. 11. Priority 5 Ownership Management Support (see Section 7.1.3) 15

20 Adding HLA Ownership Management support to the TBF can be done if required by the customer. This is a significant effort and considered an enhancement to the TBF. 6.1 PERFORMANCE ISSUE Performance testing conducted in the Air Force Research Laboratory in Mesa, Arizona during January of 2003 showed that the TBF (Trusted Bridge Federate) has a performance spiking issue that needs to be addressed. The target throughput requirement of the TBF is 12-16ms per message average. Several variations of tests were conducted including: Testing without the TBF to give us a baseline network latency A simple rule set that passes all the data And a complicated rule set. For our experiment we chose Vignette 1A. Different loads were also tested from low (2 Viper simulators and no other entities) in a single direction to high (2 Viper simulators and 20 entities with 20 second updates) in both directions. All tests yielded similar results. The average throughput was considerably faster than expected (average 3.9 ms), but 5-6% of the data peaked, sometimes as much as 100ms. It was theorized that this might be due to a lack of processors on the system. The TBF was tested on a 2 processor SunFire 880 when there were in fact 4 main processes running 16

21 simultaneously (TBF, Low-Side USF, High-Side USF, and the Trusted Solaris 8 Operating System). Upon further testing with a 4 processor machine at Trusted Computer Solutions main headquarters in Herndon, VA, it was determined that increasing the number of processors reduced the number of spikes to nearly a third. Though it is impractical to guarantee a hundred percent of the data to pass within the 12-16ms threshold, further investigation may help in reducing the percentage of spikes significantly. One possible issue may lie within the Unix system queues that are being used by the TBF. These queues seem to be slow in regards to real-time applications. This may be because the queues are filling to maximum capacity and blocking, and thereby causing the system to spike. A quick fix to this problem may be adjusting the maximum size of the system queues enough so that they don t reach a maximum capacity in a realistic training exercise. This may temporarily fix the problem for a specific training exercise but it surely isn t a cure-all for the performance problem. A level of effort to investigate this is approximately 2 staff weeks. Another area worth investigating is modifying the main processes to be real-time. This might minimize the number of blocks and interruptions that take place during run-time and might minimize performance peaks. Again, this may temporarily fix the problem for a specific training exercise but it surely isn t a cure-all. The level of effort to investigate this is approximately 1 staff month. Finally, an area that may be worth a few months effort that may truly minimize the spiking issue (to as little as can be expected) is to replace the system queues altogether with a 17

22 custom-written shared memory management interface. This will possibly rid the TBF of any delays that are currently being caused by pushing and popping messages off the system queues. Since the TBF is coded entirely in C++, only modifications in implementation will need to be revisited while the interface can remain the same. This is the advantage of having a product built in an object-oriented design fashion. Though this option will take longer than the others suggested, it is very possible that this is actually what needs to be done to minimize the performance spikes to an acceptable percentage. The level of effort to implement shared memory is approximately 3 staff months. If the shared memory option is chosen and later it is decided to increase the number of processors from 2 to 4, no additional changes to the system will need to be made. Since memory is separate from the processors, it shouldn t have any effect at all. Shared memory will not cause any problems with Trusted Solaris or any of its security features. Shared memory is a multilevel resource, exactly like the Unix queues that are currently used. In fact, the queues are implemented using shared memory by Trusted Solaris. So there should be no problem with security or accreditation for using multilevel shared memory structures. 6.2 TIME MANAGEMENT SUPPORT Time Management in HLA is a set of services, which coordinate the advancement of logical time, and its relationship to wall clock time during the federation execution. A main goal of time management is to support interoperability among simulations utilizing different internal 18

23 time management mechanisms (message ordering, internal time flow, transportation services, etc). The TBF does not currently support Time Management. This is largely due to the fact that the TBF was designed for real-time simulations. The TBF can be redesigned to support Time Management but the implications need to be stated and understood. The architecture of the TBF at a high level will remain basically the same as the current design. Significant changes will need to be made to the message passing systems between the USFs and the TBF. This will add a level of synchronization to the TBF. Two modes of operation (enable Time Management and disable Time Management) will have to be implemented as part of this effort to support customers who require Real Time processing. Once Time Management is enabled, performance will be drastically impacted and the TBF will not run at real-time speeds. Time Management in HLA assumes no common, global clock. For this reason, the TBF will attempt to synchronize time between federations. This will require the TBF to join each federation as being time constrained and time regulating. The TBF will need to be the last federate on each federation to advance time in order to maintain synchronization. This will cause the entire simulation to slow down even further. Only after knowing the details of how Time Management is handled in an operational environment can it be concluded whether the lag time will be acceptable or not. Adding the ability to support Time Management does not severely impact security, as the TBF, like all federates that are time constrained, will receive messages in the correct time 19

24 order, which means that whatever it has received is close enough to now that it makes no difference to an accreditor. Some filtering would have to be done on the time-related data, but not a significant amount, since there is not much sensitive data there. The level of effort to implement Time Management is approximately 8 staff months. Considerable modifications need to be made to the TBF and the SRRSIAT. 6.3 OWNERSHIP MANAGEMENT SUPPORT The TBF does not currently support Ownership Management of HLA objects. The TBF can be redesigned to support Ownership Management but the implications need to be stated and understood. In order for the TBF to support Ownership Management, it would have to use the GRIM RPR 2.0 FOM or some variant of that process. There are two ways that the TBF can be modified to transfer ownership of objects. They are described below. With the first method, TCS will only modify the TBF to handle Object Ownership HLA calls and not worry about the filtering of the data that is passed during the ownership transfer. The GRIM RPR implementation of Ownership Transfer seems to require a DIS method for handling this data. In this method, TCS will not implement a DIS to HLA converter. The customer will have to do one of two things to filter the data properly during an ownership transfer: 20

25 1. The customer can implement his or her own DIS to HLA smart filter. It should be noted that this would be a significant effort. 2. A process change is required. Rather than data being sent across as part of the ownership transfer interaction, the relinquishing federate would publish the necessary data via the normal updateattributevalues( ) HLA command. The TBF is already capable of handling this with ease. During the actual transfer of ownership, the records portion of the ownership transfer interaction will be dropped and the data will not be passed. This means that all federates in the exercise will have to implement the process described above for the filtering to work properly. TCS will require about 5 staff months to implement the Ownership Transfer calls for either of the two options listed above. TCS could implement a DIS to HLA converter which would ease the filtering process but it would require a much more significant effort (about 24 staff months). 21

26 7. TRANSITION/FUTURE WORK The DTNG project is now being transitioned to an operational environment at TACCSF s MLS lab in Albuquerque, NM. Trusted Computer Solutions will release DTNG version 0.9 beta to the United States Air Force by the end of June Trusted Computer Solutions will then make an effort to significantly enhance/modify the TBF by implementing and/or fixing many of the above-mentioned bugs and enhancements. Fixing the performance issue by implementing shared memory segments is on top of the list as a future upgrade. This new version, version 1.0, will then be part of Trusted Computer Solutions product line as a COTS product. Version 1.0 will be the first version to completely undergo C&A. 22

27 8. SUMMARY The concept of Distributed Mission Training (DMT) calls for interfacing geographically separated simulations into a realistic synthetic training environment. The Network Guard extends this concept to include... at multiple security levels. The DTNG Project has all in all progressed a lot further than initially anticipated. All the major milestones have been met and transition to Phase 2 (real operational environment and C&A) is currently underway. 23