C
Information Assurance
The Navy’s communications architecture must be consistent with the Department of Defense (DOD) Information Assurance (IA) policy and its implementations. This presents a challenge, as IA plans and policies are still evolving and have significant issues that need to be resolved. The IA policy is formally known as the “Information Assurance (IA) Component of the GIG Integrated Architecture, Version 1.0.”1 “Increment 1 (2008) and elements of the end state” of the GIG IA policy were approved on the basis of a memorandum of January 24, 2005, signed by Patrick M. Kern, Senior Systems Engineer, Net Centric Initiatives, Office of the Assistant Secretary of Defense for Networks and Information Integration, with the request to the Services to “please include a prioritized list of the top IA technical, affordability and operational risk areas your organization would like to see the GIG community address during 2005 and 2006.”2 The naval operational elements, the
communications elements, and science and technology (S&T) elements must provide inputs into this important policy in the context of the emerging doctrine and operational performance metrics.
As a part of developing inputs to this IA policy and for the naval forces architectures, benefit versus risk trade-offs should be conducted considering the effects of network-centric attacks. The security issues associated with the Internet Protocol (IP) should be included.
Network-centric capabilities build on the IP. There is no doubt that using the IP is very important for the naval forces; however, debate develops over how universal IP should be as a protocol. This is an area of intense debate, but the trade-offs need to be done to ensure that whatever protocol is chosen, there is a net gain in supporting the mission under both peace and wartime conditions. The DOD is migrating from a widely diverse, noninteroperable set of military protocols to a commercial IP. The original heterogeneous mixture of protocols had an advantage: something done to one system would not impact another system. Since cross-system interaction was almost nonexistent, there were no synergistic gains, which are the heart of network-centric operations, although attacks in one area did not affect another.
At the other extreme is a monoculture of using only the IP. With monocultures, an attack can spread with exponentially increasing speed. This rapid propagation across monocultures is why chicken farmers isolate their monoculture chicken flocks. The bottom line is that there are issues with both uncontrolled heterogeneity and “all IP.” The advantages of IP are extremely attractive, and the DOD has established a policy that makes Internet Protocol, version 6 (IPv6) the universal protocol. Some of the disadvantages of IP have shown up, such as the denial of service and other attacks on the Internet. However, it is important to realize that the attacks so far are relatively unsophisticated, (presumably) carried out by individual hackers, and not representative of what could be mounted by a nation-state attack.3 Methods of isolation and IP monitoring and control capabilities must be developed to handle these potentially adverse cases.
As discussed in Chapter 3 of this report, High Assurance Internet Protocol Encryption (HAIPE) is being developed by the National Security Agency for the Global Information Grid (GIG). An issue with HAIPE-encrypted IP arises when bandwidth is constrained, such as in tactical wireless and satellite communications. HAIPE-encrypted IP (Voice over Secure IP [VoSIP]) is not as efficient for
|
tegic compass,” and “defers more significant changes to future increments to allow technology to mature and provide adequate opportunities for trades between IA approaches, operational performance and affordability.” |
functions such as encrypting voice as are other approaches, such as the use of the Future Narrow Band Digital Terminal (FNBDT).4 Both approaches will carry voice traffic; the trade-off to be made involves how important the efficient use of the available bandwidth is. Spectrum, signal-to-noise, and bandwidth, among other factors, should determine which approach is used. For example, in a bandwidth-constrained environment, the FNBDT is more efficient than either the current HAIPE 1.0 or 2.0 versions and the proposed HAIPE 3.0 version. Another part of the monoculture issue is the use of Voice over Internet Protocol (VoIP) with the converged data and control planes, compared with the totally separated conventional telephone system using Signaling System 7 or the in-between Voice over Asynchronous Transfer Mode (VoATM).5 A number of groups have raised security and other issues that need to be resolved.6
Other areas for the examination of whether IP should be used include com-
munications that have critical timing or demand high assurance of performance, such as weapons release or nuclear control. At least over the near term, if the speed of securely moving information is important, it can be sent using IP over ATM at speeds up to 10 Gbps. IP over ATM (which is what the Defense Information Systems Agency and others used in the networks that successfully supported Operation Iraqi Freedom) provides a very assured way of isolating and controlling the IP network that is almost immune to outsider attacks. Lastly, if quality of service (QoS) is important, there are a number of options that provide QoS, including Frame Relay, ATM, and various Time Division Multiplexed systems.
In addition to security and performance issues, IP and supporting protocols continue to evolve. This change is compounded by ongoing changes to the HAIPE encryption. The good news is that more capabilities are emerging to improve network-centric capabilities. The bad news is that changes, will continue until at least 2008 and, as discussed below, coupled with other IA changes may extend to 2012 or 2016.
IP encryptors go back to the 1970s,7 but the versions are still changing over shorter periods than the equipment-refreshment time of large organizations. For example, since the Navy/Marine Corps Intranet (NMCI) was started in 2000, five versions of IP encryption have been introduced: Taclane, HAIPE versions I, II, and III, and work is now starting on features for HAIPE IV. These versions address issues such as commercialization, the transition to IPv6, reducing the encryption overhead for bandwidth-constrained communications links, “black to black” network exchanges, scalable multicast, and QoS features. For these and other issues, a number of competing approaches must be resolved and incorporated into the HAIPE encryptors before a stable baseline will exist. Since only one generation of backward compatibility is required, this is a challenge for interoperability, procurement, and upgrade planning.
Lastly, as cited earlier with the Kern memorandum, IA is in flux at both the policy level and the technology level. “Future versions (2.0, 3.0, etc.) will address details of Increment 2 (2012) and Increment 3 (2016) of the IA component of the GIG architecture.”8 The Kern memorandum goes on: “for 2005-2006 End-to-End System Engineering Advisory Activity work will address: Technology risk and solutions to technical concerns, affordability risk and program synchronization, as well as operational performance and doctrine concerns.”9 The implications of these issues must be allowed for in the architecture to ensure that the
7 |
See Steven Kent and others’ summaries of encryption developments, at “Network Encryption-History and Patents” at <http://www.toad.com/gnu/netcrypt.html>. Accessed March 31, 2005. |
8 |
Patrick M. Kern, Office of the Assistant Secretary of Defense for Networks and Information Integration memorandum of January 24, 2005. |
9 |
Patrick M. Kern, Office of the Assistant Secretary of Defense for Networks and Information Integration memorandum of January 24, 2005. |
naval forces dependent on network-centric operations are adequately protected during this period of protocol and IA evolution. This will not be easy and will require a comprehensive understanding of the issues. For example, in VoSIP, one of the challenges in developing the security features is to converge on common standards to ensure interoperability across the various vendor products and with that, ensure that the security features are carried across all vendors’ telephones with which the naval users will interact.10 Another area is mobile communications, which has issues that are being worked through.