AIRBORNE NETWORK ARCHITECTURE System Communications Description & Technical Architecture Profile Version 1.1 7 October 2004 This document contains a description of the USAF Airborne Network Architecture. It is expected that this architecture will continue to be developed in terms of both the level of detail in which it is expressed and in the evolution of its fundamental concepts. Please contact the Chair of the Airborne Network Special Interest Group to determine the most recent version of this document. Prepared by HQ ESC/NI1 for the USAF Airborne Network Special Interest Group Table of Contents 1. Introduction ............................................................................................................... 1 1.1 Definition of Airborne Network ............................................................................ 1 1.2 Purpose of Document ............................................................................................ 1 1.3 Relationship to Other Documents.......................................................................... 1 1.4 Contents ................................................................................................................. 2 1.5 Intended Use .......................................................................................................... 3 2. Operational Context .................................................................................................. 4 2.1 Operational Concept Description for the Airborne Network (OV-1).................... 4 2.2 Objective Airborne Network Communications Capabilities ................................. 4 3. Airborne Network Tenets ......................................................................................... 7 4. Airborne Network Description (SV-1) ..................................................................... 9 4.1 Overview ............................................................................................................... 9 4.2 Network Functions ................................................................................................ 9 4.2.1 Inter-node Connectivity .................................................................................. 9 4.2.2 Information Assurance (IA) .......................................................................... 11 4.2.3 Network Management ................................................................................... 12 4.2.4 Link Management ......................................................................................... 13 4.2.5 Network Services .......................................................................................... 14 4.3 Network Topologies (Nodes and Links) ............................................................. 14 4.3.1 Node Types ................................................................................................... 15 4.3.2 Link Types .................................................................................................... 25 4.3.2.1 Backbone............................................................................................... 25 4.3.2.2 Subnet ................................................................................................... 26 4.3.2.3 Network Access .................................................................................... 26 4.3.2.4 Legacy ................................................................................................... 26 4.3.3 Typical Topologies ....................................................................................... 26 4.3.3.1 Space, Air, Ground Tether .................................................................... 26 4.3.3.2 Flat Ad-Hoc .......................................................................................... 27 4.3.3.3 Tiered Ad-Hoc ...................................................................................... 28 4.3.3.4 Persistent Backbone .............................................................................. 28 5. Airborne Network System Functions (SV-4) ......................................................... 30 5.1 On-Board Infrastructure ...................................................................................... 30 5.1.1 Intra Platform Distribution ............................................................................ 30 5.1.1.1 Serial Data Buses .................................................................................. 30 5.1.1.2 Local Area Networks ............................................................................ 30 5.1.2 Platform Information Assurance ................................................................... 30 5.1.3 Platform Network Management .................................................................... 31 5.1.4 Gateways/Proxies .......................................................................................... 31 5.1.4.1 Legacy Infrastructure Gateways ........................................................... 31 5.1.4.2 Legacy Transmission System Data Link Gateways.............................. 32 5.1.4.3 TDL Gateways ...................................................................................... 32 5.1.4.4 Performance Enhancing Proxies ........................................................... 32 5.2 AN Equipment ..................................................................................................... 33 5.2.1 Inter-node Connectivity ................................................................................ 33 i 5.2.1.1 Routing/Switching ................................................................................ 33 5.2.1.2 Quality of Service (QoS)/Class of Service (CoS) ................................. 35 5.2.1.2.1 QoS-Aware Application Interfaces ................................................... 37 5.2.1.2.2 QoS/CoS Mechanisms ...................................................................... 37 5.2.1.2.3 QoS-Based Routing/Switching ......................................................... 38 5.2.1.2.4 QoS Manager .................................................................................... 38 5.2.2 Information Assurance .................................................................................. 39 5.2.2.1 GIG IA Architecture ............................................................................. 40 5.2.2.2 Supporting Infrastructures .................................................................... 43 5.2.2.2.1 Security Management Infrastructure (SMI) ...................................... 43 5.2.2.2.2 DoD Key Management Infrastructure (KMI) ................................... 44 5.2.2.2.3 Public Key Infrastructure (PKI) ........................................................ 45 5.2.2.3 AN Information Flows .......................................................................... 46 5.2.2.3.1 Least Privilege .................................................................................. 47 5.2.2.3.2 User Traffic ....................................................................................... 48 5.2.2.3.3 Policy Dissemination ........................................................................ 48 5.2.2.3.4 Network Management ....................................................................... 48 5.2.2.3.5 Network Control ............................................................................... 49 5.2.2.4 AN IA Boundary ................................................................................... 49 5.2.2.5 Dynamic Policy Based Security Management (PBSM) ....................... 50 5.2.2.5.1 PBSM Framework ............................................................................ 51 5.2.2.5.2 Policy Protection ............................................................................... 53 5.2.2.5.3 Security Management System........................................................... 53 5.2.2.6 Data Protection...................................................................................... 53 5.2.2.6.1 Application Layer Protection ............................................................ 54 5.2.2.6.2 Network Layer Protection ................................................................. 54 5.2.2.6.3 Link Layer Protection ....................................................................... 55 5.2.2.7 Key Management .................................................................................. 56 5.2.2.8 Authentication System .......................................................................... 58 5.2.2.9 ASWR ................................................................................................... 58 5.2.2.9.1 Network Intrusion Detection System ................................................ 59 5.2.2.9.2 Virus Detection, Prevention, and Removal....................................... 60 5.2.2.9.3 Vulnerability Assessment System (VAS) ......................................... 60 5.2.2.10 Protocol Security................................................................................... 60 5.2.2.11 Other Security Functions ...................................................................... 61 5.2.2.11.1 Firewalls .......................................................................................... 61 5.2.2.11.2 Guards – Cross Domain Solutions................................................... 61 5.2.2.11.3 Covert channels ............................................................................... 61 5.2.2.12 Security Modeling and Simulation ....................................................... 61 5.2.3 Network Management ................................................................................... 61 5.2.3.1 Cluster-Based Management Architecture ............................................. 62 5.2.3.1.1 Network Manager ............................................................................. 62 5.2.3.1.2 Cluster Managers .............................................................................. 63 5.2.3.1.3 Intelligent NM Agents ...................................................................... 64 5.2.3.2 Policy Based Management Framework ................................................ 64 5.2.3.3 Network Management System Components ......................................... 66 ii 5.2.4 Link Management ......................................................................................... 69 5.2.4.1 Link Management Architecture ............................................................ 69 5.2.4.2 Link Management System Components ............................................... 70 5.2.5 Network Services .......................................................................................... 71 5.2.5.1 Overview ............................................................................................... 71 5.2.5.2 Name Resolution Service ...................................................................... 73 5.2.5.2.1 Naming Service Features .................................................................. 73 5.2.5.2.2 Naming Service Architecture ............................................................ 75 5.2.5.3 Dynamic Network Configuration Management.................................... 75 5.2.5.4 Network Time Service .......................................................................... 75 5.3 Off-Board Transmission Systems ........................................................................ 76 6. GIG Integration and Interoperability ...................................................................... 78 6.1 GIG Operational Mission Concepts .................................................................... 78 6.1.1 Provide Common Services ............................................................................ 79 6.1.2 Provide Worldwide Access ........................................................................... 79 6.1.3 Provide Dynamic Resource Allocation ......................................................... 79 6.1.4 Provide Dynamic Group Formation.............................................................. 80 6.1.5 Provide Computer Network Defense (CND) ................................................ 80 6.1.6 Provide Management and Control of GIG Network and Resources............. 80 6.2 GIG Enterprise Services ...................................................................................... 81 6.2.1 Enterprise Service Management/Network Operations.................................. 81 6.2.2 Information Assurance/Security ................................................................... 81 6.3 GIG Transport Convergence ............................................................................... 83 6.4 GIG Routing Architecture ................................................................................... 83 6.5 GIG Quality of Service Architecture ................................................................... 83 6.6 Interface Definition.............................................................................................. 85 8. Node and Link Configurations for Candidate Platform Types (SV-5) ................... 94 8.1 Approach ............................................................................................................. 94 8.2 Fighter Platform ................................................................................................... 94 8.2.1 Operational Profile ........................................................................................ 94 8.2.2 AN Capabilities, Links, and Topologies ....................................................... 95 8.2.3 AN System Configuration............................................................................. 96 8.2.4 Airborne Fighter Platform AN Issues and Risks .......................................... 97 8.3 Airborne C4ISR Platform .................................................................................... 97 8.3.1 Operational Profile ........................................................................................ 97 8.3.2 AN Capabilities, Links, and Topologies ....................................................... 98 8.3.3 AN System Configuration............................................................................. 99 8.3.4 C4ISR Platform AN Issues and Risks ........................................................ 100 8.4 Airborne Communications Relay Platform ....................................................... 100 8.4.1 Operational Profile ...................................................................................... 100 8.4.2 AN Capabilities, Links, and Topologies ..................................................... 101 8.4.3 AN System Configuration........................................................................... 102 8.4.4 Airborne Communications Relay Platform AN Issues and Risks .............. 103 9. Recommended Network Standards ....................................................................... 104 9.1 Current Standards (TV-1) .................................................................................. 104 9.2 Emerging Standards (TV-2) .............................................................................. 113 iii 9.3 Areas for Further Development ......................................................................... 120 10. AN Architecture Issues ......................................................................................... 129 11. List of Acronyms .................................................................................................. 136 12. References ............................................................................................................. 140 http://www.unik.no/paalee/ iv 1. Introduction This document represents the work performed by the USAF Airborne Network Special Interest Group to define an Objective Airborne Network Architecture. Additional efforts are planned to further define this architecture. TBDs (to be determined) inserted in the text indicate areas still being worked. 1.1 Definition of Airborne Network The Airborne Network is defined to be an infrastructure that provides communication transport services through at least one node that is on a platform capable of flight. This can best be visualized in the context of the operating domains served by the Global Information Grid (GIG). The Transformational Communications Satellite System (TSAT) network will provide space connectivity and the GIG-Bandwidth Expansion (GIG-BE) network together with networks such as those provided under the Combat Information Transport System and Theater Deployable Communications will provide surface connectivity. Airborne connectivity within the GIG will be provided by the Airborne Network. The Airborne Network will connect to both the space and surface networks, making it an integral part of the communications fabric of the GIG. 1.2 Purpose of Document In general, a network architecture defines a set of high-level design principles that guides the technical design of a network. Its role is to ensure that the resulting technical design will be consistent and coherent – the pieces fit together smoothly – and that the design will satisfy the requirements on network function associated with the architecture. The architecture is more general than a particular conformant technical design, and is expected to be relatively long-lived – applicable to more than one generation of technology. Finally, the architecture should guide technology development in a consistent direction, preventing the implementation of inconsistent point solutions throughout the network that could lead to the loss of functionality and interoperability. [Source: Developing a Next-Generation Internet Architecture, July 2000] The Airborne Network Architecture defines the structure of Airborne Network components, their relationships, and the principles and guidelines governing their design and evolution over time. It consists of the design tenets, technical standards, architectural views (system and technical) and a description of the operational capabilities achieved. The architecture is documented following the guidance of the DoD Architecture Framework. This document defines a “To-Be” or objective set of airborne network capabilities, functions and system components to be used to assist planning activities associated with the acquisition or implementation of a particular network capability. It should not be used on its own as an all-encompassing design for the Airborne Network. 1.3 Relationship to Other Documents 1 The following documents also provide acquisition or implementation planning details for the Airborne Network, and are related to this document as indicated: Airborne Network Architecture Progress Summary Version 1.0 – Provides the scope, purpose, and intended uses of the Airborne Network Architecture, describes the process used to develop the architecture, and summarizes the major results and conclusions. Airborne Network Architecture Roadmap (Draft) – Provides a time phased approach for implementing the Airborne Network capabilities and network functions. Airborne Network Technical Requirements Document (Draft) – Provides detailed technical requirements for system components needed to implement the Airborne Network. ConstellationNet Addendum to C2 Constellation CONOPS – Provides the required operational capabilities of the ConstellationNet of which the Airborne Network is a component. USAF ConstellationNet Sub-Enterprise Architecture (formerly known as the AF Infostructure Architecture) – Provides context and overall guidance for domain level architectures for implementing a net-centric infostructure. Includes operational, system, and technical views of the Air Force information infrastructure (to include the Airborne Network) at the Enterprise level. Command and Control Enterprise Reference Architecture (C2ERA) – Provides the technical direction for designing, acquiring and integrating the computing and communications capabilities of the Air Force C2 Enterprise. Net-Centric Enterprise Solutions for Interoperability (NESI) – Provides a technical architecture and implementation guidance to facilitate the design, development, maintenance, evolution, and usage of information systems that support the Network-Centric Warfare (NCW) environment. 1.4 Contents The Airborne Network Architecture is documented in terms of the following perspectives: Operational Context – Objective communications capabilities that the Airborne Network must provide to the warfighter to support future network-centric operations are described in Section 2. Tenets – Network principles applicable to any Airborne Network design that provide high level guidance for decision making are contained in Section 3. Systems Architecture Views – Guidelines for where and when to implement different system functions or technologies are contained in Sections 4 through 7. Section 4 describes the objective Airborne Network functions and topologies; Section 5 identifies the systems components needed to provide those functions; Section 6 discusses implications of integrating the Airborne Network into the future Global Information Grid (GIG); Section 7 contains several model diagrams for the network and platforms; and Section 8 presents notional system configurations for several candidate platform types. Technical Standards – Technical standards for major Airborne Network components and interfaces, both existing and emerging, are listed in Section 9. 2 1.5 Issues – Architectural and technical issues identified during the development of the architecture that require further research are presented in Section 10. Intended Use The Airborne Network Architecture is intended to guide the acquisition of network capability for airborne platforms by defining investment opportunities, system requirements, technical standards, implementation guidelines, and GIG interoperability directives. Investment Decisions – The Airborne Network Architecture identifies functional areas requiring further investigation and development to define technical solutions and/or standards. Requirements Definition – The Airborne Network Architecture provides a common framework to identify required network, platform, and communications component functionality to enable a desired set of network capabilities needed to support future Air Force mission operations. Standards Definition – The Airborne Network Architecture provides a list of key technical standards for use in near-term and interim airborne network implementations. Implementation Guidance – The Airborne Network Architecture provides a list of tenets and system configuration diagrams that should be used to guide the development of lower level system architectures and system designs. GIG Interoperability Direction – The Airborne Network Architecture identifies GIG interoperability directives and architectural guidance relevant to the airborne network 3 2. 2.1 Operational Context Operational Concept Description for the Airborne Network (OV-1) Network-centric operations and network-centric warfare (NCW) refers to an information superiority-enabled concept of operations that generates increased combat power and air mobility by networking sensors, decision makers, and shooters to achieve shared awareness, increased speed of command, higher tempo of operations, greater lethality, increased survivability, and a degree of self synchronization. In essence, NCW translates information superiority into combat power by effectively linking knowledgeable entities in the battlespace. [Source: Network Centric Warfare, Alberts, Gartska and Stein, 1999] The Department of Defense (DoD) Joint Vision (JV) 2020 projects to a future period of United States dominance across the full spectrum of military operations. The military capabilities necessary to realize this vision depend upon achieving Information and Decision Superiority through the implementation of an internet-like, assured Global Information Grid (GIG). Within the AF, achieving Information and Decision Superiority depends upon extending the capabilities of the GIG into the airborne and space environments. When fully realized, this AF vision will enable interoperable networkcentric operations between Joint Service, Allied, and Coalition forces. [Source: Airborne Network Prioritization Plan] To realize the AF vision, the extension of the GIG in the airborne domain – the Airborne Network, must be easy to use, configure, and maintain and must provide: Ubiquitous and assured network access to all Air Force platforms GIG core services whose integrity is assured Quality appropriate to the commander’s intent and rules of engagement (ROE) Rapid response to mission growth, emerging events and changing mission priorities End-to-end interoperation with joint services, coalition, and non-DoD partners and legacy systems in all physical network domains (sub-surface, surface, airborne and space) [Source: Operating Concept for C2 Constellation ControlNet Network Centric Infostructure] 2.2 Objective Airborne Network Communications Capabilities The Objective Airborne Network that can provide the capabilities listed in section 2.1 will be a communications utility that provides an adaptable set of communications capabilities that can be matched to the particular mission, platforms, and communications transport needs. Communications capabilities can be expressed in terms of the connectivity that can be established, the services that can be supported over the network connections, and the operations that are required for the user to establish, maintain, and access the network connections. Table 2-1 identifies an objective set of communications capabilities for the Airborne Network. All of these capabilities would not necessarily be needed for every instantiation of the Airborne Network, but will be necessary to support all missions, operations, and platforms. 4 Table 2-1. Summary of Airborne Network Objective Capabilities Network Capability & Attributes Connectivity Airborne Network Objective Capabilities Coverage Geographic span of links directly interfacing to a subject node Diversity of links Total number and types of links that can be used to “connect” to the subject node Beyond Line of Sight (BLOS) extending Globally (enabling access to anywhere from anywhere) Throughput Total average throughput of all links directly interfacing to the subject node Type of connection Nature of connections that can be established between the subject nodes and directly connected nodes Network interface Networks that can be directly interfaced from the subject node (e.g., DISN (NIPRNET, SIPRNET, JWICS), Transformational Communications, TDL Networks, CDL Networks) Number of links (system and media) matched to the mission matched to the environment (to enable guaranteed access) Type of links extend across the spectrum of radio frequencies including infrared and optical Throughput matched to the mission and automatically adaptable to accommodate unplanned or transient conditions Dynamically reconfigurable to optimize performance, cost, and mission effectiveness Flexible connections able to forward Globally Interface to AN subnet and backbone links, as well as, legacy (i.e., TDL or CDL), coalition and GIG component networks operating any version network protocol (i.e., IPv6 or IPv4), as needed Services Real-time data Any data flows that must be sent in real time (i.e., low latency) with assured delivery (e.g., AMTI or GMTI tracks, munition terminal stage updates, RPV control, TCT&ISR tipoffs, NBC alert) Continuous interactive voice (e.g., Voice over IP telephone and radio nets) Continuous interactive video (e.g., Video over IP, Video Teleconferencing) Streaming multimedia & multicast (e.g., Video imagery) Block transfer & transactional data Short blocks of interactive data (e.g., Telnet, HTTP, client/server, chat) Batch transfer data Long blocks of bulk data (e.g., Email, FTP) Multiple simultaneous multilevel precedence and preemption (MLPP) real-time data links or nets, as needed Multiple simultaneous MLPP voice links or nets, as needed Multiple simultaneous MLPP video links, as needed Multiple simultaneous MLPP multimedia links, as needed Multiple simultaneous MLPP block & transactional links, as needed Multiple simultaneous MLPP batch data links, as needed Operations Managing All aspects related to managing the links and the network including: Planning -- frequency allocation, transmission, routing, network services Simplified network planning to include the allocation and configuration of network resources, including legacy networks, when needed Automated analyses of network performance to 5 Network Capability & Attributes and traffic. Monitoring -- performance and use, fault, and security aspects of a link, network, or network component. Analyzing -- performance optimization and diagnostics. Controlling -- add, remove, initialize, and configure links, networks, or network components Airborne Network Objective Capabilities diagnose faults, determine suboptimal conditions, and identify needed configuration changes Monitoring and controlling of AN link and network resources and interfaces with legacy networks Maintenance of network situational awareness (SA) and distribution of Network SA to peer networks Match use of network resources to commander’s operational objectives Forming and Adapting Automated provisioning, initialization and restoration of all AN link resources To include: Provisioning -- obtaining the needed link and network resources. Initialization and Restoration -establishing or restoring a link or network service. Accessing All aspects related to obtaining or denying access to a link or network, to include: Protection – communications security as well as authentication, authorization, accounting Detection Reaction Link and subnet protection matched to the threat, with automated detection and reaction User data and AN management and control data protection matched to the threat 6 3. Airborne Network Tenets The following statements are proposed as tenets of the Airborne Network (AN) Architecture. These reflect the underlying principles of any AN design that claims to be conformant with the AN architecture. 1. Standards Based: AN system components comply with applicable DoD and AF standards lists. Leverage commercial investment in COTS-based networks and their evolution wherever feasible Relax standards only for unique must-have DoD features Evolve standards to accommodate DoD features Migrate towards use of open standards 2. Layered: AN system components are functionally layered. Follows successful COTS Internet model Minimizes description of inter-layer interfaces Allows technology evolution of layers for maximum cost benefit 3. Modular: AN is inherently modular in nature, capable of being extended and expanded to meet the changing communications service requirements of the platforms needed to support any particular mission. Components can be continuously added and removed as needed during the time frame of the mission (hours, days), such that the network can be adjusted to fit the mission, during the mission User capabilities that need to be supported determine the technical capabilities of the network components selected New network components that provide new operational capabilities can be integrated as needed. 4. Internetworked: AN is capable of internetworking using all available commercial and military transmission media (i.e., line-of-sight (LOS) radio communications paths, satellite communications (SATCOM) paths, and laser communications (Lasercom) paths). 5. Interoperable: AN is capable of interoperating with other peer networks (e.g., space, terrestrial, and warfighter networks) and legacy networks (as needed for coalition interoperability and transition operations). 6. Implemented as a Utility: AN integrates separate transmission mechanisms with a single common, standards-based network layer (e.g., IPv4, IPv6) for delivery of common user (i.e., mission-independent) network services. 7. Adaptable: AN is capable of adapting to accommodate changes in user mission, operating environment, and threat environment. 8. Efficient: AN efficiently utilizes available communication resources. 9. Autonomous: AN can operate autonomously or as part of a larger inter-network. Platform network can operate without connectivity to external nodes 7 AN can operate without connectivity to ground nodes 10. Secure: AN supports user and system security. Multiple independent levels of security User, operations, management, and configuration data integrity and confidentiality Identification and authentication. 11. Managed: AN is capable of integrating into broader AF and joint network management infrastructures. 12. Policy Based: AN is capable of integrating into policy-based management and security infrastructures. 8 4. 4.1 Airborne Network Description (SV-1) Overview The Target Airborne Network must be capable of supporting the diverse AF missions, platforms, and communications transport needs of the future. The network will vary from a single aircraft connected to a ground station to support voice or low speed data, to a constellation of hundreds of aircraft transporting high speed imagery and real-time collaborative voice and video. The target network must be capable of forming a topology that is matched to the particular mission, platforms, and communications transport needs, and doing so in a way that minimizes the amount of pre-planning and operator involvement. The Airborne Network will be described in terms of the network functions it must perform and the network topologies (i.e., physical or logical configuration of functional nodes and links) needed to enable the network. The network functional nodes will be defined in terms of the system components or modules needed to achieve the desired functionality. 4.2 Network Functions The Airborne Network functions will be described from five perspectives, as follows: Inter-node connectivity – How AN nodes (i.e., platforms) interconnect to each other. Information Assurance – What security functions are needed and where do they go. Link Management – How the network controls and makes use of AN communications links. Network Management – How the network controls its configuration and maintains its integrity. Network Services – What network services are needed and how are they used. 4.2.1 Inter-node Connectivity AN nodes are capable of establishing connections with one or more other AN nodes, whether airborne, in space, or on the surface, as needed. The transmission paths used to establish the physical connections, may be asymmetric with respect to bandwidth, and may be bidirectional or unidirectional (including receive only). Also, the forward and reverse network connections relative to any node could take different physical paths through the network. The AN connections may be point-to-point, broadcast, or multipoint/multcast. AN nodes are capable of establishing connections to relay (receive and transmit with the same data formats and on the same media/frequency), translate (receive and transmit with the same data formats but on different media or frequencies), or gateway (receive and transmit with different data formats and on different media/frequencies) information, as needed. 9 AN nodes are capable of establishing connectivity to other AN nodes based upon a prearranged network design that prescribes inter-node connectivity (i.e., topology) of the network. Also, AN nodes are capable of establishing link connectivity to other AN nodes autonomously, without prearrangements that identify the specific AN nodes, and dynamically as opportunities and needs arise. Key inter-node connectivity functions include the following: Backbone connectivity – Some AN nodes are capable of establishing stable high bandwidth network connections for interconnecting other networks and AN subnets, as needed to satisfy the information transport requirements of the host platform and network. The backbone connection will consist of persistent or quasi-persistent links between two or more AN nodes that are high-capacity in comparison to the subnet links connected to the nodes, permit use of the common network and transport protocols, and provide access to other subnets and/or global network. Backbones are capable of carrying both local and transit traffic. Backbone system components consist primarily of routers/switches and trunks. Subnet connectivity – AN nodes are capable of establishing and internetworking with prearranged, static, and ad-hoc subnets with specific sets of nodes, as needed, for instance to support a particular mission, transmission media or location. AN nodes are capable of leaving a subnet and rejoining it or another subnet at any time with minimal prearrangements. Network access connectivity – AN nodes are capable of establishing legacy and/or IP network connections using any available media; some AN nodes are capable of providing access to any space or terrestrial IP network as opportunities and needs arise. Routing/switching – AN nodes are capable of routing or switching IP packets to/from any local LAN, subnet, backbone, or space or terrestrial IP network (i.e., end system, intra-area, inter-area, and inter-domain ( or autonomous system (AS)) routing) as opportunities and needs arise. AN nodes are capable of routing and switching both platform and transit traffic as needed. Routing decisions will be made on an expanded set of metrics to optimize performance for the AN, such as on hops, bandwidth, delay, reliability, load, media preference, BER or packet loss rate, stability, availability, geographic position, speed and heading. AN nodes are capable of handing off routing capabilities to another AN node (such as when a platform goes off station and is replaced by another platform). Quality of Service (QoS)/Class of Service (CoS) – The AN is capable of establishing and changing connections and forwarding IP-packets on routes and in a sequence that satisfies the indicated delivery performance requirements associated with the information flow. The AN will implement standards-based QoS/CoS mechanisms that are compatible with those implemented in interconnected GIG networks enabling timely information exchanges across diverse networks, systems and communities of interest (COIs). The QoS/CoS mechanisms must support all communications services (e.g., voice, data, video), provide preferential treatment based on priority (with preemption), enable policy-based assignment of service 10 classes and priorities, rapidly respond to changes in assignments, and work end-toend on all host and network devices, as needed. 4.2.2 Information Assurance (IA) AN IA services include identification, authentication, integrity, confidentiality, availability, non-repudiation, security policy management, and key management. AN IA components will enable or extend access to GIG based security or may organically provide the security services. IA services will be enabled regardless if the AN is connected to other networks that comprise the overall GIG and during periods of connectivity interruption. IA services will be designed to function under constraints such as low-bandwidth, high-latency connections, unidirectional links, or with nodes operating in LPI/LPD modes to include receive-only. Key Information Assurance functions include the following: Policy Based Security Management (PBSM) – PBSM provisions and supports the specification and enforcement of access control policies, logging, monitoring, and auditing. Policy based security management enables: o Specification of authorization policies for access control o Specification of obligation policies for logging, monitoring, and auditing o Analyses of policies Data Protection – AN security services will protect user data and AN administrative data, provide cover to transmitted data, and provide the mechanisms to support Multiple Independent Levels of Security and Multi-Level Security. o User Data – The AN will employ modern, high-assurance NSA Type 1 encryption and algorithms to secure user packet and circuit data. The AN will provide data security over operational environments ranging from US military only to those that will incorporate operations with U.S. military and national assets and U.S. allies and coalition partners. o AN Administrative Data – (configuration, management, operations, etc.) – The AN will employ public key technologies and protocols, such as SSL, TLS, IPSec to ensure the integrity and confidentiality of AN administrative data. Administrative data includes that used to monitor the health and status of AN components and to configure and operate those components, as well as, that needed for actual network operations, such as routing updates. o AN Transmitted Data – Transmission Security algorithms and keys, or TRANSEC, will provide transmitted signals covertness or cover to avoid detection, identification and exploitation (such as traffic analyses.) o Multiple Independent Levels of Security (MILS) Support – The AN will provide for simultaneous operations in multiple independent security domains each secured by their own encryption device. Once secured the resultant data will be transported by a common black transport network. o Multi-level Security (MLS) Support – The AN will provide for simultaneous operations in multiple security domains on one red network. The red network 11 data will be secured using encryption devices and then transported through a common black transport network. Key Management – The AN will use DoD Key Management Infrastructure (KMI) and Electronic Key Management System (EKMS) processes as its core key management capability. The AN may provide user interfaces and/or a pass-through capability that enable platform LAN and user access to the services provided by these systems. Authentication, Identification, Integrity, and Access Control. – The AN will provide services to enable user and device authentication, identification, and access control, with or without interface to GIG security services. Attack Sensing, Warning, and Response (ASWR) – The AN will provide for host and network based Intrustion Detection Systems, Intrustion Prevention Systems, and Virus Detection, Prevention, and Removal applications. o Intrusion Detection System (IDS) – The AN IDS will defend system components against threat actions carried by network data traffic by detecting and responding to inappropriate, incorrect or anomalous network activity. The two basic categories of IDS are host-based and network-based. The AN will use a combination of host based and network based IDS processes. o Intrustion Prevention System (IPS) – The IPS detects and prevents known attacks. o Virus Detection, Prevention, and Removal – The AN will check for the presence of malicious executable code (e.g., viruses, worms, Trojan horses, etc.) and remove or “repair” the suspect files or alert the operator. Protocol Security – The routing, transport, management, and other protocols used to enable the AN must be secured. Dependent on the sensitivity of the protocol’s data, that security may require identification and authentication between endpoints, applying a digital signature to the transmitted data to provide origin and integrity validation, or encryption to provide confidentiality. 4.2.3 Network Management AN Network Management enables operators to plan network resources and equipment configurations, analyze and predict network performance, monitor and display current network status, isolate and resolve faults, and configure network components. Key Network Management functions include the following: Fault, Configuration, Accounting, Performance, Security (FCAPS) Management o Identify when faults and anomalies occur; report, isolate, analyze, and resolve faults o Provide configuration of AN system parameters, detect configuration changes o Perform accounting of resource utilization to verify that resources are being utilized in accordance with commanders’ operational objectives o Collect network performance statistics, status, and event notification data, analyze and resolve performance faults and reconfigure network resources as warranted 12 o Conduct security fault/anomaly detection, analysis, and security system/component (re)configuration. Network Situation Awareness o Collect (or receive), analyze, and fuse AN composition, status, performance, and information assurance data (including legacy network status) in near realtime to produce user-defined views of the mission critical AN resources of concern to a commander or NetOps center. o Display system and network resources, showing their operational status and linkages to other resources. o Tailor reporting to facilitate the timely sharing of data and consistency of data across the AN, its peer networks, and other GIG component networks. Network Resource Planning o Develop and maintain a network resource plan (to include a frequency management plan) for the allocation and configuration of network elements through range of operations o Interoperate with legacy/coalition network planning tools to ensure an integrated plan o Formulate policies in accordance with network resource plan o Store policies in policy repository Policy Based Network Management (PBNM) o Construct, store, and distribute network policies, including for IA and QoS o Dynamically update network policies o Perform policy accounting, including SLA management and negotiation o Provide network access control Network Modeling, Analysis, and Simulation o Provide tools for examining network functional and performance characteristics; use results to refine resource planning and policy formulation o Provide integrated full network simulation to include the AN, legacy, and coalition links 4.2.4 Link Management AN Link Management enables real-time autonomous management of the resources and services provided by the RF and optical links that interconnect the AN nodes. This includes finding/locating nodes/links, provisioning link bandwidth, admission control, and managing radio and network configurations. Advertising and Discovery – Each AN node will be capable of advertising its identity and location to enable it to be discovered by other AN nodes. The AN Link Management will identify, authenticate, locate and determine the network capabilities of all advertising AN nodes. 13 Establishing and Restoring – The AN will form links among advertising AN nodes to satisfy mission operational requirements and prescribed network configurations in accordance with current policies. The AN Link Management will be capable of setting and adjusting AN network component and link parameters to modify the performance of any link. As an example the AN will determine the protocols and data rate to be used over each link, and will be capable of adjusting data rate for a given link. Monitoring and Evaluation – The AN Link Management will monitor and evaluate the current operational state of all advertising AN nodes network components and links. The AN Link Management will determine the network performance being achieved by each active AN node and link. In addition, the AN Link Management will determine the network performance being achieved by the overall network to determine whether or not the current topology needs to be altered to satisfy current mission operational requirements. Topology Management – The AN Link Management will determine how the AN nodes will be interconnected in order to establish an AN topology that satisfies current mission operational requirements. This includes determining each AN node network component and link parameters, performing admission control for each node requesting connection to the AN, provisioning of link resources, and managing the handoff of links to ensure seamless connectivity. 4.2.5 Network Services 4.3 Name Resolution System – The AN contains a Name Resolution System to resolve hostnames, domains and IP addresses for the AN. The Name Resolution System will include master and replica servers geographically separate with automated failover capability. The AN Name Resolution System will be fully integrated into the GIG Organization, Service and Root DNS architecture. Dynamic Network Configuration Management – The AN includes the capabilities to dynamically assign and distribute IP addresses, manage network servers, IP networks and subnets. The AN network configuration management system also provides a view of the IP network, subnet, domain, name resolution server, network time server, etc. Network Time Service – The AN includes Network Time Servers (NTS) synchronized with Coordinated Universal Time (UTC) to provide synchronized time distribution within an AN node. The AN NTS will be fully integrated into the GIG UTC, Intermediate, and Client Node Network Time Service architecture. The AN also provides network time services that are fully functional in a GPS denied environment, or when the network is disconnected from the GIG infrastructure. Network Topologies (Nodes and Links) The Airborne Network must be capable of supporting diverse AF airborne platforms. These platforms will vary in their communications capability needs, flight patterns, and 14 size, weight and power (SWAP) constraints. The network must be capable of interconnecting all platforms, supporting all needed services, and providing access to all needed GIG services. Some of the platforms will be high performance aircraft capable of operating at high speeds, needing to rapidly join and exit networks while having SWAP for very limited communications resources (which may be legacy systems). The network must also be capable of guaranteeing certain levels of performance to support bandwidth, latency or loss sensitive applications. Figure 4-1 depicts a Notional Airborne Network Topology showing the different types of network nodes and links that address these needs. To optimize network performance, operations, fault-resilience and ensure the efficient use of resources, the use of relatively stable connections should be maximized especially in the Airborne Backbone (when such a configuration is needed), while the highly mobile platforms and dynamic network connections are isolated to the Tactical Subnets. The Airborne Network should be capable of forming whatever topology is best matched to the mission, platforms, and communications transport needs as discussed in section 4.3.3. Figure 4-1. Notional Airborne Network Topology 4.3.1 Node Types The node types depicted in Figure 4-1 indicate the minimum network functionality that must be performed at each node to realize the target AN capabilities. A brief description of each node type follows: Legacy – Airborne platforms that are equipped with legacy communications systems capable of supporting voice, tactical data link (TDL), and possibly some point-topoint IP network connections for very limited services (e.g., email only). 15 Relay/Gateway – Airborne platforms that are equipped with legacy communications systems as described for a legacy node, but also include equipment that enable them to access multiple TDLs and to relay data Beyond Line of Sight (BLOS), or transfer data formats from one link to another. Network Access – Airborne platforms equipped with IP network-capable communications systems, which provides an IP network connection to an AN or GIG network node. These nodes are tethered to the network, and do not provide any AN service to other nodes on the network. Network Capable – Airborne platforms equipped with IP network-capable communications systems, which can join an IP data network (Tactical Subnet) and provide limited AN service (e.g., transit routing) to other nodes on that local network. Internetwork – Airborne platforms equipped with IP network-capable communications systems, which can access and interconnect multiple IP data networks. These nodes are equipped with gateway and network services functionality that enable them to provide GIG services to other airborne nodes when interconnected to the GIG through a Network Service Provider node. Network Service Provider – Airborne platforms, fixed or deployed ground facilities, or space-based packages equipped with IP network capable communications systems, which can access multiple IP data networks. These nodes are equipped with gateway and network services functionality that enable them to interconnect with a GIG network (e.g., DISN, JTF Service Component Network, etc.) service delivery node (SDN) and to provide GIG services to other airborne nodes. Table 4-1 and 4-2 summarizes the network capabilities and functionalities for each node type, respectively. Table 4-1. Summary of Node Types and Typical Network Capabilities Node Type Legacy Connectivity Coverage: Mostly LOS, some BLOS Diversity: Single or few legacy links and link types Throughput: Typically low speed connections Type of connection: PtPt, Pt-MultPt, automatic relay Network interfaces: Legacy links and tactical subnets Network Capability Service Typically a subset of communications transport services, including: Real-time data Voice Interactive data 16 Operation Managing: Manual planning, analyzing, monitoring, and controlling of node resources locally. Limited automated management and monitoring for some legacy links. Forming and Adapting: Manual provisioning, initialization and restoration of node link resources. Limited dynamic resource sharing. Accessing: Link and tactical subnet protection, with limited manual detection and reaction. Node Type Relay/ Gateway Network Access Network Capable Internetwork Connectivity Network Capability Service Coverage: Typically LOS and BLOS Diversity: Few to several legacy links and link types Throughput: Typically low speed connections Type of connection: PtPt, Pt-MultPt, TDL Forwarding Network interfaces: Legacy links and tactical subnets Typically a subset of communications transport services, including: Real-time data Voice Interactive data Coverage: LOS & BLOS Diversity: Single IP network-capable link Throughput: Low to high speed connection Type of connection: Ptto-Pt Network interfaces: Tactical subnets, AN backbone, GIG networks All or most communications transport services, including: Real-time data Voice Video Multimedia & multicast Interactive data Bulk (time insensitive) data Coverage: Typically LOS Diversity: Single IP network-capable link Throughput: Low to high speed connection Type of connection: PtPt, Pt-MultPt, Forwarding Network interfaces: Tactical subnets Typically a subset of communications transport services, including: Real-time data Voice Interactive data Coverage: LOS & BLOS Diversity: Multiple links All or most communications transport services, including: 17 Operation Limited dynamic joining and leaving of subnets. Managing: Manual planning, analyzing, monitoring, and controlling of node resources locally Forming and Adapting: Manual provisioning, initialization and restoration of node link resources Accessing: Link and tactical subnet protection, with limited manual detection and reaction Managing: Monitoring and controlling of node resources locally and from a remote network node, distribute network SA data, match use of resources to operational objectives Forming and Adapting: Automated provisioning, initialization and restoration of AN link and network resources Accessing: GIG protection, with automated detection and reaction Managing: Monitoring and controlling of node resources locally and from a remote network node, distribute network SA data, match use of resources to operational objectives Forming and Adapting: Automated provisioning, initialization and restoration of AN link and network resources Accessing: Tactical subnet protection, with automated detection and reaction Managing: Automated analyses of network Node Type Network Service Provider Connectivity Network Capability Service and link types Throughput: Low to high speed connections, high speed connections to AN backbone Type of connection: PtPt, Pt-MultPt, Forwarding Network interfaces: Tactical subnets, AN backbone Real-time data Voice Video Multimedia & multicast Interactive data Bulk (time insensitive) data Coverage: LOS & BLOS Diversity: Many links and link types Throughput: Low to high speed connections, high speed connections to AN backbone and GIG Type of connection: PtPt, Pt-MultPt, Forwarding Network interfaces: Tactical subnets, AN backbone, and GIG networks All communications transport services, including MLPP: Real-time data Voice Video Multimedia & multicast Interactive data Bulk (time insensitive) data Operation performance, monitoring and controlling of node resources locally and from a remote network node and of connected AN resources, maintain and distribute network SA, match use of resources to operational objectives Forming and Adapting: Automated provisioning, initialization and restoration of AN link and network resources Accessing: Tactical subnet and AN backbone protection, with automated detection and reaction Managing: Simplified network planning, automated analyses of network performance, monitoring and controlling of node resources and of connected AN resources, maintain and distribute network SA, match use of resources to operational objectives Forming and Adapting: Automated provisioning, initialization and restoration of AN link and network resources Accessing: AN and GIG protection, with automated detection and reaction Table 4-2. Summary of Node Types and Network Functionality Node Type Network Functions Connectivity Subnet Access (through gateway) Legacy Information Assurance User data and orderwire communications bulk encrypted Limited TRANSEC capabilities 18 Node Type Network Functions Manual key management; some OTAR Link Management None Network Management None, other than management approach applied by the legacy system; Relay/Gateway provides proxy function for management of legacy systems by the AN management framework Network Services None Connectivity Legacy Link Access Subnet Access (through gateway) Information Assurance User data and orderwire communications bulk encrypted Limited TRANSEC capabilities Manual key management; some OTAR Relay/ Gateway Link Management None Network Management Conduct proxy function between AN management and legacy management Network Services None Connectivity GIG Access QoS Network Access Information Assurance Policy Based Security Management User data protection through use of Inline Network Encryptor (e.g., HAIPE) Node data Protection – use of IPSec, Type 2 encryption, etc., to protect management and control data TRANSEC I&A, data integrity validation, etc. Automated Key Management – management of node’s keys; access to replacement keys Attack Sensing, Warning, and Response Virus Protection Protocol Security Link Management Advertising and Discovery Advertises node’s identity and location Discovers nodes that advertise their identity and location; authenticates nodes identity and determines available network capabilities 19 Node Type Network Functions Establishing and Restoring Requests network service needed to satisfy mission operational requirements from designated AN link manager node Sets and adjusts AN network component and link parameters to establish or modify the required link(s) as directed by the designated AN link manager node Monitoring and Evaluation Monitors and evaluates node’s network and link performance Reports status to designated AN link manager node Network Management Fault, Configuration, Accounting, Performance, Security Management Collect network performance statistics, status, and event notification data from local network elements, analyze and resolve faults and configure local network resources, autonomously if needed Report network performance statistics, status, and event notification data to a designated AN manager node and receive and respond to configuration requests from the AN manager node Network Situation Awareness Report network events to a designated AN manager node Policy Based Network Management Request, receive, and respond to policy updates Provide network access control Network Services Name Resolution System Dynamic Network Configuration Management Network Time Connectivity Subnet Subnet Access Routing/ Switching (Intra-Area Router) QoS Network Capable Information Assurance Policy Based Security Management User data protection through use of Inline Network Encryptor (e.g., HAIPE) Node data Protection – use of IPSec, Type 2 encryption, etc., to protect management and control data TRANSEC I&A, data integrity validation, etc. Automated Key Management – management of node’s keys; access to replacement keys Attack Sensing, Warning, and Response Virus Protection Protocol Security Link Management Advertising and Discovery Advertises node’s identity and location Discovers nodes that advertise their identity and location; authenticates nodes identity and determines available network capabilities Establishing and Restoring 20 Node Type Network Functions Requests network service needed to satisfy mission operational requirements from designated AN link manager node Sets and adjusts AN network component and link parameters to establish or modify the required link(s) as directed by the designated AN link manager node Monitoring and Evaluation Monitors and evaluates node’s network and link performance Collects/processes/analyzes status reports from assigned subnet nodes Reports status to designated AN link manager node Topology Management Determines needed subnet connectivity for assigned nodes to establish a topology that satisfies current mission operational requirements Performs admission control for each node requesting connection Provisions subnet resources, determines network and link parameters for assigned nodes, and directs adjustments to network component and link parameters for assigned nodes that request network service Determines and directs needed adjustments to the assigned nodes’ network component and link parameters to accommodate changes in service requests, participating nodes or equipment status (based on status reports) Manages the handoff of links within its subnet to ensure seamless connectivity Reconfigures subnet topology as directed by the designated AN link manager node Network Management Fault, Configuration, Accounting, Performance, Security (FCAPS) Management Identify when faults and anomalies occur; report, isolate, analyze, and resolve faults Provide configuration of AN system parameters, detect configuration changes Perform accounting of resource utilization to verify that resources are being utilized in accordance with commanders’ operational objectives Collect network performance statistics, status, and event notification data, analyze and resolve performance faults and reconfigure network resources as warranted Conduct security fault/anomaly detection, analysis, and security system/component (re)configuration. Network Situation Awareness Collect (or receive), analyze, and fuse local AN composition, status, performance, and information assurance data in near real-time Tailor reporting to facilitate the timely sharing of data and consistency of data across the AN Policy Based Network Management Provision and dynamically update local network policies, including for IA and QoS Perform policy accounting, including SLA management and negotiation Provide network access control Internetwork Network Services Name Resolution System Dynamic Network Configuration Management Network Time Connectivity Backbone 21 Node Type Network Functions Subnet Subnet and Backbone Access Routing/ Switching (Intra-Area Router, Area Border Router) QoS Information Assurance Policy Based Security Management User data protection through use of Inline Network Encryptor (e.g., HAIPE) Node data Protection – use of IPSec, Type 2 encryption, etc., to protect management and control data TRANSEC I&A, data integrity validation, etc. Automated Key Management – management of node’s keys; access to replacement keys Attack Sensing, Warning, and Response Virus Protection Protocol Security Link Management Advertising and Discovery Advertises node’s identity and location Discovers nodes that advertise their identity and location; authenticates nodes identity and determines available network capabilities Establishing and Restoring Requests network service needed to satisfy mission operational requirements from designated AN link manager node Sets and adjusts AN network component and link parameters to establish or modify the required link(s) as directed by the designated AN link manager node Monitoring and Evaluation Monitors and evaluates node’s network and link performance Collects/processes/analyzes status reports from assigned subnet and/or backbone nodes Reports status to designated AN link manager node Topology Management Determines needed subnet and/or backbone connectivity for assigned nodes to establish a topology that satisfies current mission operational requirements Performs admission control for each node requesting connection Provisions subnet and/or backbone resources, determines network and link parameters for assigned nodes, and directs adjustments to network component and link parameters for assigned nodes that request network service Determines and directs needed adjustments to the assigned nodes’ network component and link parameters to accommodate changes in service requests, participating nodes or equipment status (based on status reports) Manages the handoff of links within its subnet and/or backbone to ensure seamless connectivity Reconfigures subnet and/or backbone topology as directed by the designated AN link manager node Network Management Fault, Configuration, Accounting, Performance, Security (FCAPS) Management Identify when faults and anomalies occur; report, isolate, analyze, and resolve faults 22 Node Type Network Functions Provide configuration of AN system parameters, detect configuration changes Perform accounting of resource utilization to verify that resources are being utilized in accordance with commanders’ operational objectives Collect network performance statistics, status, and event notification data, analyze and resolve performance faults and reconfigure network resources as warranted Conduct security fault/anomaly detection, analysis, and security system/component (re)configuration. Network Situation Awareness Collect (or receive), analyze, and fuse AN composition, status, performance, and information assurance data in near real-time to produce user-defined views of the mission critical AN resources of concern to a commander or NetOps center Display system and network resources, showing their operational status and linkages to other resources Tailor reporting to facilitate the timely sharing of data and consistency of data across the AN Policy Based Network Management Provision and dynamically update local network policies, including for IA and QoS Perform policy accounting, including SLA management and negotiation Provide network access control Network Services Name Resolution System Dynamic Network Configuration Management Network Time Connectivity Backbone Subnet Subnet, Backbone, GIG Access Routing/ Switching (Intra-Area Router, Area Border Router, AS Border Gateway Router) QoS Network Service Provider Information Assurance Policy Based Security Management User data protection through use of Inline Network Encryptor (e.g., HAIPE) Node data Protection – use of IPSec, Type 2 encryption, etc., to protect management and control data TRANSEC I&A, data integrity validation, etc. Automated Key Management – management of node’s keys; access to replacement keys Attack Sensing, Warning, and Response Virus Protection Protocol Security Link Management Advertising and Discovery Advertises node’s identity and location Discovers nodes that advertise their identity and location; authenticates nodes identity and determines available network capabilities Establishing and Restoring 23 Node Type Network Functions Requests network service needed to satisfy mission operational requirements from designated AN link manager node Sets and adjusts AN network component and link parameters to establish or modify the required link(s) as directed by the designated AN link manager node Monitoring and Evaluation Monitors and evaluates node’s network and link performance Collects/processes/analyzes status reports from assigned AN nodes Reports status to designated AN link manager node Topology Management Determines needed access, subnet and/or backbone connectivity for assigned nodes to establish a topology that satisfies current mission operational requirements Performs admission control for each node requesting connection Provisions access, subnet and/or backbone resources, determines network and link parameters for assigned nodes, and directs adjustments to network component and link parameters for assigned nodes that request network service Determines and directs needed adjustments to the assigned nodes’ network component and link parameters to accommodate changes in service requests, participating nodes or equipment status (based on status reports) Manages the handoff of links within its subnet and/or backbone to ensure seamless connectivity Reconfigures access, subnet and/or backbone topology as directed by the designated AN link manager node Network Management Fault, Configuration, Accounting, Performance, Security (FCAPS) Management Identify when faults and anomalies occur; report, isolate, analyze, and resolve faults Provide configuration of AN system parameters, detect configuration changes Perform accounting of resource utilization to verify that resources are being utilized in accordance with commanders’ operational objectives Collect network performance statistics, status, and event notification data, analyze and resolve performance faults and reconfigure network resources as warranted Conduct security fault/anomaly detection, analysis, and security system/component (re)configuration. Network Situation Awareness Collect (or receive), analyze, and fuse AN composition, status, performance, and information assurance data in near real-time to produce user-defined views of the mission critical AN resources of concern to a commander or NetOps center. Display system and network resources, showing their operational status and linkages to other resources. Tailor reporting to facilitate the timely sharing of data and consistency of data across the AN and its peer networks. Network Resource Planning (likely performed at a single AF Network Operations facility or ground NSP) Develop and maintain a network resource plan for the allocation and configuration of network elements through range of operations Formulate policies in accordance with network resource plan Store policies in policy repository Policy Based Network Management Provision and dynamically update network policies, including for IA and QoS 24 Node Type Network Functions Perform policy accounting, including SLA management and negotiation Provide network access control Network Modeling, Analysis, and Simulation (likely performed at a single AF Network Operations facility or ground NSP) Provide tools for examining network functional and performance characteristics; use results to refine resource planning and policy formulation Network Services Name Resolution System Dynamic Network Configuration Management Network Time 4.3.2 Link Types 4.3.2.1 Backbone The AN quasi-persistent core backbone will provide a high-performance and faultresilient routed structure that can be characterized by a defined network capacity, latency and loss rate. The backbone should be composed of relatively stable high bandwidth links between a defined set of platforms. Ideally, the backbone links should be symmetric and point-to-point with as equal bandwidth, latency, and loss characteristics as is possible. It should be implemented to enable alternative path routing and fast routing convergence, consistent steady-state traffic engineering and latency performance, and consistent failure mode behavior. This backbone should also be implemented to enable optimized paths between interconnections, dynamic load-sharing across the core structure where appropriate, and efficient and controlled use of bandwidth. [Source: Understanding Enterprise Network Design Principles] The AN backbone will provide the following advantages to the overall network performance: Reduce overall network complexity: Even if it is based upon and formed using mobile ad-hoc networking technology, the backbone can be considered a part of the routing infrastructure that does not change nearly as frequently as other subnets attached to it. It therefore enables use of a much simpler and efficient routing protocol among backbone routers, essentially the same protocol as is used on terrestrial networks. Increases overall network stability: The fact that there are platforms whose locations and flight characteristics are relatively stable gives them the inherent ability to form relatively stable interconnections between them, whether they form these connections in an ad-hoc fashion or not. These stable links can be used in network paths between users having needs for stable and persistent connectivity. Facilitates reliable performance: Including relatively stable links in the network paths enables resources to be reserved, where needed, for traffic having high reliability requirements. 25 Provides location for common services: Many of the nodes comprising the backbone can be used to host common network services, such as directories and gateways, so that smaller, more constrained platforms do not need to do so. Provides aggregation points for SATCOM and ground interconnects: Nodes on the backbone can serve as airborne concentration points for interconnection to the SATCOM backbone networks and terrestrial networks. 4.3.2.2 Subnet AN subnets will be formed to satisfy the specific communications transport needs of a set of platforms. The subnet links maybe point-to-point or broadcast, high or low bandwidth, LOS or SATCOM as needed to satisfy the mission needs. Subnet connections can be prearranged quasi-static connections, ad hoc quasi-static connections, ad hoc dynamic connections (connections of opportunity) consisting of any communications media capable of supporting IP traffic. 4.3.2.3 Network Access AN network access links will provide connectivity to AN and/or GIG services. The network access links may be high or low bandwidth, LOS or SATCOM and function as a circuit or trunk. These links must enable AN and GIG security, addressing, network management, QoS, admission control, and network services. 4.3.2.4 Legacy AN legacy links refer to any connectivity established using non-IP communications systems typically capable of supporting voice, tactical data link (TDL), and possibly some point-to-point IP network connections for very limited services (e.g., email only). 4.3.3 Typical Topologies The Airborne Network will be capable of forming many different topologies, each matched to a particular mission, set of platforms, and communications transport needs. This flexibility will enable the AN to meet performance objectives while minimizing the infrastructure required or the use of scarce resources. 4.3.3.1 Space, Air, Ground Tether Tethering aircraft consists of establishing a direct connection to another aircraft or ground node, via a point-to-point link for nodes within line of sight (LOS) or via a SATCOM link for nodes that are beyond line of sight (BLOS). As in the case of the VIP/SAM aircraft that have been recently equipped with the Senior Level Communications System (SLCS) or a B-2 with reachback communications, a SATCOM link provides connectivity to a network ground entry point as shown at the left in Figure 4-2. Strike aircraft that accompany C2 aircraft such as an AWACS are tethered via point-to-point links as shown in the center of the figure. Finally, C2 or ISR aircraft may connect via a LOS link 26 directly to a network ground entry point as shown at the right in the figure. Each of these tethered alternatives requires the presence of a tethering point that has been prepositioned. Figure 4-2. Airborne Network Tethered Topologies 4.3.3.2 Flat Ad-Hoc A flat ad-hoc topology, as shown in Figure 4-3, refers to establishing nonpersistent network connections as needed among the AN nodes that are present. With this network the AN nodes dynamically “discover” other nodes to which they can interconnect and form the network. The specific interconnections between the nodes are not planned in advance, but rather are made as opportunities arise. The nodes join and leave the network at will continually changing connections to neighbor nodes based upon their location and mobility characteristics. This type of network topology would best serve missions involving a relatively small number of aircraft that are very dynamic and have modest communications transport needs. Figure 4-3. Airborne Network Flat Ad-Hoc Topology 27 4.3.3.3 Tiered Ad-Hoc Ad-hoc networks can be flat in the sense that all AN nodes are peers of each other in a single network, as discussed above, or they can dynamically organize themselves into hierarchical tiers such that higher tiers are used to move data between more localized subnets. Figure 4-4 depicts such a tiered ad-hoc topology. This network topology would be beneficial as the number of aircraft increases, or their mobility patterns become more stable, or the communications transport needs increase. Figure 4-4. Airborne Network Tiered Ad-Hoc Topology 4.3.3.4 Persistent Backbone A network topology characterized by a persistent backbone in shown in Figure 4-5. The backbone is established using relatively persistent wideband connections among highvalue platforms flying relatively stable orbits. The backbone provides the connectivity between the tactical subnets which are considered edge networks relative to the backbone. The backbone provides concentration points for connectivity to the space backbone as well as to terrestrial networks. This type of network topology would be needed to support a C2 Constellation consisting of several C2 and ISR aircraft exchanging high volumes of high priority, latency-sensitive sensor and command data among themselves and with strike aircraft. 28 Figure 4-5. Airborne Network Persistent Backbone Topology 29 5. 5.1 Airborne Network System Functions (SV-4) On-Board Infrastructure 5.1.1 Intra Platform Distribution 5.1.1.1 Serial Data Buses Serial data buses will provide highly reliable, fault tolerant, deterministic, serial switched interconnections for on-board mission systems where timing jitter and missed deadlines are intolerable. Serial data buses, such MIL-STD-1553B and newer enhanced rate standards, typically employ dual (and multiple) redundancy to provide the requisite levels of fault tolerance and command/response techniques to provide the guaranteed real-time deterministic performance. 5.1.1.2 Local Area Networks Avionics-quality data networks based on COTS networking technologies will provide high data throughput while achieving bounded latency, determinism and guaranteed availability for critical applications. 5.1.2 Platform Information Assurance The platform security system will enable authenticated and authorized operators to monitor ongoing security events and verify the configuration of security components. Within the constraints of security policy, it will allow authenticated and authorized operators the ability to modify system security behavior. Platform security components will integrate with the AN Policy Based Security Management (PBSM) system allowing dissemination, installation and enablement of security policy on platform security components. Through interfaces with the AN network management system, authorized network management systems will be able to query platform security components and platform secured components to determine their configuration, health, and performance. IA capabilities that may be provided by platform LANs include: Ability to report configuration, status, and performance of security components (e.g., HAIPE devices) and secured components (e.g., routers). Ability to receive, validate, process, and implement security policy distributed by the AN PBSM system. Provide for user and AN node data protection. Data protection includes support for data confidentiality, integrity, digital signatures, etc., as appropriate for the data and applications. Accomplish I&A. Provide for Key Management. Support Attack Sensing, Warning, and Response (ASWR.) ASWR includes Intrusion Detection and Prevention and Virus Detection. ASWR will provide 30 the capability to report all instances of detected security threats such as unauthorized attempts to use or penetrate the network or to deny service. Provide for protocol security. 5.1.3 Platform Network Management The platform network management system will enable operators to manage all on-board network elements. The platform network management system will interface and interoperate with the AN network management system to enable operators to manage remote network elements in the airborne network. The platform network management system will be capable of: Monitoring the health and status (to include identifying and locating faults) of managed network elements through both passive receipt and interpretation of status and alert messages and by active probes. Reporting the settings of all configurable parameters that can be provided by every network element. The system will enable an authorized and authenticated operator to change the settings of all configurable parameters for every network element. Monitoring and reporting the utilization of every network element. The system will be capable of receiving and applying network policy information to effect changes in allocations of network resources to traffic flows. Changing the security configuration of network elements. The system will be capable of reporting the initial configuration and all changes to the security configuration of network elements and host systems and all instances of detected security threats such as unauthorized attempts to use or penetrate the network or to deny service. 5.1.4 Gateways/Proxies Gateways and/or proxies will enable: (1) interconnection of legacy on-board infrastructure (e.g., serial data buses) to the IP-based airborne network, (2) use of legacy off-board transmissions systems to transport IP-based traffic, (3) interconnection of legacy Tactical Data Link (TDL) systems into the airborne network, and (4) the use of standard COTS and AF IP-based user applications over impaired (i.e., limited bandwidth, long delays, high loss rates, and disruptions in network connections) airborne network connections. These systems will facilitate the transition of the legacy on-board infrastructure, transmission systems, TDLs, and user applications to the objective airborne network systems. Therefore, these systems will only be needed during a transition period, and the scope of the needed functionality will vary with specific platforms. (Note, the transition period may extend indefinitely to accommodate interoperability with allied and coalition platforms and systems.) 5.1.4.1 Legacy Infrastructure Gateways 31 Legacy gateways provide an interface(s) between the on-board legacy infrastructure (such as MIL-STD-1553 data, audio and video) and the on-board IP network to enable legacy host systems (e.g., servers, OWSs, radios, radio access, video distribution and display, etc.) to interoperate with IP-based host systems and to access the airborne network. 5.1.4.2 Legacy Transmission System Data Link Gateways Legacy transmission system gateways can be used to enable legacy voice and data radio channels to be used to transport IP traffic. These gateways (such as those developed for AFRL’s Information for Global Reach (IFGR) project) overcome the low bandwidth, high loss, long delay, half-duplex environments of legacy radio systems using a variety of techniques. A combination of Forward Error Correction (FEC) and Automatic Request for retransmission (ARQ) can be used to decrease the wireless error rate in the datalink layer along with some of the Performance Enhancing Proxy techniques discussed below. 5.1.4.3 TDL Gateways TDL gateways (such as the Common Link Interface Processor (CLIP)) perform message processing and formatting, data translation and forwarding, and radio interface and control to enable interconnection of legacy data link systems into the airborne network. 5.1.4.4 Performance Enhancing Proxies Performance Enhancing Proxies (PEPs) improve the performance of user applications running across the AN by countering wireless network impairments, such as limited bandwidth, long delays, high loss rates, and disruptions in network connections. These systems are functionally implemented between the user application and the network and can be used to improve performance at the application and transport functional layers of the OSI model. Some techniques that can be employed include: Compression: Data compression or header compression can be used to minimize the number of bits sent over the network. Data bundling: Smaller data packets ca be combined (bundled) into a single large packet for transmission over the network. Caching: A local cache can be used to save and provide data objects that are requested multiple times, reducing transmissions over the network (and improving response times). Store-and-forward: Message queuing can be used to ensure message delivery to users who become disconnected from the network or are unable to connect to the network for a period of time. Once the platform connects, the stored messages are sent. Pipelining: Rather than opening several separate network connections pipelining can be used to share a single network connection for multiple data transfers. 32 5.2 Protocol streamlining: The number of transmissions to set-up and take down connections and acknowledge receipt of data can be minimized through a combination of caching, spoofing, and batching. Translation: A translation can be performed to replace particular protocols or data formats with more efficient versions developed for wireless environments. Embedded acknowledgments: Acknowledgements can be embedded in the header of larger information carrying packets to reduce the number of packets traversing the network. Intelligent restarts: An intelligent restart mechanism can be used to detect when a transmission has been dropped and reestablished, and then resume the transmission from the break point instead of at the beginning of the transmission. Transmission Control Protocol (TCP) replacement or enhancement: A replacement to standard TCP, or an enhanced TCP variant can be used over wireless links with high losses and/or long delays. Link Error Awareness (LEA): LEA can be used to distinguish and handle efficiently the two type of network losses -- losses due to congestion, and losses related to link errors. AN Equipment 5.2.1 Inter-node Connectivity 5.2.1.1 Routing/Switching The AN routing/switching function will enable the dynamic exchange of traffic with other platforms and will be capable of both off-board and transit routing. Off-board routing pertains only to the traffic originating on or destined for hosts on the local platform. Transit routing deals with traffic originating on other platforms and destined for hosts on other platforms. AN routers/switches will also enable the exchange of traffic to other GIG fixed, deployed, and mobile networks. AN routers/switches must be capable of performing static, dynamic or ad hoc routing as needed, with flat or hierarchical routing topologies. The AN will enable platforms to dynamically change their points of attachment to the network with no disruption to incoming or outgoing traffic flows and minimal loss of data (i.e., seamless roaming). The AN routers/switches must direct traffic from the on-board infrastructure to an offboard legacy, subnet, network access or backbone link transmission system. Typical routing/switching functions include: Media translation Address translation Security and firewalls Neighbor (network router) discovery Exchange of routing information Detection and propagation of link status changes 33 Initialization and maintenance of routing tables Path determination Packet marking, classification, conditioning, and servicing (queuing and scheduling) Packet forwarding Policy enforcement Packet filtering Load Balancing Route flap dampening (i.e., suppressing router update transmissions caused by unstable links changing available paths) Table 5-1 summarizes the AN routing functional requirements. Table 5-1. AN Routing Functional Requirements Requirement Description Loop-free AN routing/switching will produce forwarding paths that do not contain circular routing loops, i.e., traffic passes through an AN router/switch only once on its path from source to destination. Directionality AN routing/switching will be possible with the use of bidirectional, unidirectional, or asymmetric paths. Routing Topologies AN routing/switching will support both flat network topologies and hierarchical network topologies. When in a hierarchical network topology, the AN will be capable of end system, intra-area, inter-area, and inter-domain (or autonomous system (AS)) routing) as opportunities and needs arise. Transmission Types AN routing/switching will be capable of routing user information as unicast, broadcast, multicast, and anycast network transmissions between AN Nodes on any part of the AN or GIG. Time reference The AN routing/switching will not require a universal time reference at all nodes in network. Routing Metric As a minimum, the AN will enable routing decisions to be based upon the following criteria: number of hops, bandwidth availability, delay, relative reliability of each available path, traffic load, media preference (to prioritize non performance functions such as LPI/LPD, AJ, fast handoff capability), path bit error rate or packet loss rate cost (i.e., dollars). As a goal, the AN shall also enable routing decisions to be based upon the following criteria: 34 Requirement Description relative stability of the path as determined by the number of link state changes that have occurred in a unit of time over all links comprising the path, relative availability of the path as determined by the proportion of time the path has been operational in an interval of time, geographic position, speed and heading. Constraint Based Routing The AN will enable the use of any combination of the above route selection criteria for routing decisions, prioritized and weighted according to user determined policy and quality of service needs. Responsiveness The AN will change the routes used to forward information in response to changes in the available communications resources, offered traffic patterns, and performance demands in order to make most efficient use of network resources in accordance with the communications policy in place at the time. Scalability The AN routing protocols will operate with varying numbers of platforms, varying numbers of fast moving platforms, varying amounts of offered traffic per platform. Robustness The AN routing protocol will be resistant to link or node failures or high link bit error rates. In the event of a failure of a single AN Node or link, the AN will be capable of routing traffic to the remaining AN Nodes. The AN will provide a failover mechanism for any critical AN nodes to avoid potential single points of failure. The AN will be capable of routing information to segments of the network that became partitioned due to critical AN Node or link failures by using any other links or networks available, including terrestrial and space networks. Compatibility with standard Internet protocols AN routing will be compatible with standard Internet routing protocols and compliant with applicable Air Force and DoD directives on their use. 5.2.1.2 Quality of Service (QoS)/Class of Service (CoS) QoS mechanisms will allow the AN to make decisions on resource allocation and traffic handling based on recognition of different types of traffic with different performance expectations. The AN must also provide the capability to prioritize traffic based on class of user, application, or mission; and to preempt a lower priority data flow if a higher priority flow is initiated and insufficient resources exist to carry both flows simultaneously. This capability, referred to as Class of Service (CoS) support, corresponds approximately to Multi-Level Precedence and Preemption (MLPP). The AN will provide the capability to assess QoS/CoS requirements to determine if they can be met. QoS requirements are used to derive network resource and configuration 35 needs. They are successively mapped into quantitative QoS parameters relevant to various AN systems that can be monitored and controlled. QoS parameters may be oriented towards Performance - sequential versus parallel processing, delays, data rate Format - transfer rate, data format, compression schema, image resolution Synchronization - loosely versus tightly coupled, synchronous versus asynchronous Cost - platform rates, connection and data transmission rates User - subjective quality of images, sound, response time In allocating resources, the Link Management system must not only consider resource availability and resource control policies, but also QoS requirements. To ensure the required QoS is sustained, the Link Management system must be capable of monitoring QoS parameters and reallocating resources in response to system anomalies. This requires monitoring resource availability and its dynamic characteristics, e.g., measuring processing workload and network traffic, to detect deviations in the QoS parameters. When there is a change of state, i.e., degradation in the QoS, and the Link Management system cannot make resource adjustments to compensate, then the application is notified. The application must either adapt to the new level of QoS or scale to a reduced level of service. Supporting these QoS functional requirements for the AN, where the network topologies, links, platforms, and information exchange needs are dynamic will require an adaptable QoS architecture. This architecture must include QoS-aware application interfaces, a variety of dynamically configurable QoS/CoS mechanisms, QoS-based routing, and a network-wide QoS manager as depicted in Figure 5-1. 36 Link Management Host Server or OWS PB Network Management PB Security Management Peer QoS Manager QoS Manager Application Application QoS Application Interface QoS-Based Routing QoS Mechanisms Application QoS Mechanisms Router/Switch Transmission System AN Node Data Control Figure 5-1. QoS Functional Components 5.2.1.2.1 QoS-Aware Application Interfaces The AN must be capable of providing adequate communications services for a wide variety of user mission applications, from those that do not address QoS to those that are fully QoS-aware capable of requesting specific QoS needs and adapting to degraded network conditions. QoS-aware application interface components will provide the functionality necessary to provide consistent QoS treatment for all user mission applications, including: Identification, classification, and marking of traffic flows Monitoring and controlling of traffic flow rates and bandwidth allocations 5.2.1.2.2 QoS/CoS Mechanisms The AN end-to-end QoS/CoS architecture must include multiple, complementary mechanisms, such as admission control, traffic shaping, various queue management strategies, and application-layer aspects as listed in Table 5-2. 37 Table 5-2. QoS Mechanisms Tools/Techniques/Technologies Use and Benefit Differentiated Services (DiffServ) Admission Control Bandwidth Broker 802.1Q and P Resource Reservation Protocol--Tunneling Extensions (RSVP-TE) Multi-Protocol Label Switching--Traffic Engineering (MPLS-TE) Real-time configuration management of applications, networks, and edge-user devices Application-to-Network exchange of network capability and performance information (traffic engineering) Metadata Tagging (pending modification of DoD Standards) Prioritizing tool Policy admission tool Network controlling tool Traffic classification and routing tool Connection assurance tool Connection assurance and traffic engineering tool Positive enterprise control tools Applications can behave adaptively to changing network conditions to provide the user with best possible service Data is marked with time sensitivity to indicate usefulness, accuracy, and/or need 5.2.1.2.3 QoS-Based Routing/Switching The AN will employ QoS-based routing/switching in which paths for flows are determined based upon knowledge of available network resources as well as the QoS requirement of the flows. QoS-based routing path-selection criteria will include QoS parameters such as available bandwidth, link and end-to-end path utilization, node resources consumption, delay and latency, and induced jitter. The main objectives of QoS-based routing are: Dynamic determination of feasible paths: QoS-based routing will determine a path, from among all available choices, that is capable of accommodating the QoS of the given flow. Feasible path selection will be subject to policy constraints. Optimization of resource usage: Network state-dependent QoS-based routing will enable the efficient utilization of network resources by improving the total network throughput. Graceful performance degradation: State-dependent routing will compensate for transient inadequacies in network engineering (e.g., during focused overload conditions), giving better throughput and a more graceful performance degradation. 5.2.1.2.4 QoS Manager Each AN node will have a QoS manager that brokers network resources and services for user mission applications, provisions network resources, and controls the QoS-related configuration of network components. Each QoS manager will receive requests from host applications and peer QoS managers for network services. The QoS manager at 38 Network Service Provider nodes will also receive requests from other component GIG networks. Each QoS manager will interoperate with the link management, policy-based network management, and policy-based security managements systems to provision network resources. Each QoS manager will also be capable of controlling the QoSrelated configuration of the network components located at the node. The QoS manager will be a distributed function capable of performing the following: Brokering Network Resources and Services o Verify user/application QoS privileges o Negotiate service level agreement (SLA) with application subject to network and security policies o Negotiate SLA with other GIG networks subject to network and security policies o Monitor network performance o Alert application/GIG network when network not meeting SLA (i.e., QoS violations) o Identify corrective actions and renegotiate SLA with application/GIG network Provisioning Network Resources o Map QoS requests to network devices o Manage end-to-end network configuration o Perform admission control o Monitor, allocate, and release network resources o Request additional network resources o Adapt to changes in available network resources Controlling Network Components o Configure network components for selected QoS/CoS mechanisms o Adapt/modify network component QoS/CoS related parameters (e.g., routing metrics, router update mechanism, router flow conditioning, queue management, flow scheduling, etc) 5.2.2 Information Assurance AN Information Assurance components will enable or extend access to DoD GIG based security or may organically provide the security services. IA services will be enabled regardless if the AN is connected to other GIG transport networks or operating as a GIG disconnected, stand-alone network segment. IA services will be designed to function under constraints such as low-bandwidth, high-latency connections, unidirectional links, or with nodes operating in LPI/LPD modes to include receive-only. AN IA components will interoperate with the GIG IA infrastructure and other non-GIG IA infrastructures including coalition IA infrastructures. This interoperability may come from direct interface with the external infrastructure (e.g., with GIG core security functions) or 39 through a gateway or proxy system (e.g., interoperating with allied or coalition IA infrastructure.) 5.2.2.1 GIG IA Architecture The Department of Defense (DoD), Intelligence Community (IC), and other Federal agencies (e.g., the National Aeronautics and Space Agency (NASA) and the Department of Homeland Security (DHS)) require the development of an assured global national security information technology enterprise to achieve their strategic visions of information superiority, net-centric operations, and collaborative information sharing. To achieve their visions, the DoD’s GIG and the IC’s Horizontal Integration (HI) initiatives will transform the way they operate, communicate, and use information. This transformation from a need-to-know to a need-to-share information protection model is enabled by tightly integrating the business, warfighter, and national intelligence domains with the technical infrastructure domain through a net-centric enterprise capability. The AN is an element of the GIG technical infrastructure, providing airborne connectivity to support mission critical communications and applications. The GIG IA Architecture defines six operational mission concepts that IA enablers must support. (See section 6 for additional discussion on GIG operational mission concepts and IA system enablers.) GIG Mission Concepts and IA System Enablers (Functions) As an element of the GIG fabric, the AN is a transport component of the larger GIG enterprise. The AN IA architecture will support the six primary GIG mission areas as follows: Provide Common Services – Provision a set of common services to all users to support all missions, enabling the Task, Post, Process, and Use (TPPU) model of information management. o The AN will use Distributed Policy-Based Access Control to mediate access for all users to system communications, information and services based on user identities, privileges, digital policy, object attributes, environmental attributes and mission need. o The AN will determine the end-to-end protection that can be provided combined with the end-to-end protection required by an information object and visibility into enforcement mechanisms to ensure that information is not shared with systems that cannot adequately protect it to create a Secure Endto-End Communications Environment. o Enterprise-Wide Network Defense and Situational Awareness will allow the AN to audit all accesses to communications, information and services, protect audit information during generation, processing and storage in such a way as to ensure non-repudiation by the user, and use audit information to detect inappropriate access to information and resources. o The AN will use Distributed Policy-Based Access Control to enable authorized users to access control policy when critical mission needs require it. 40 Provide Worldwide Access – The ability to connect regardless of location giving users access to all assets needed to accomplish their mission. o Using Identification and Authentication Strength of Mechanism to ensure confidentiality and authentication, the AN will provide a communications path for users that have strongly authenticated identities and verified authorizations. o Using Enterprise-Wide Network Defense and Situational Awareness, the AN will provide notification of compromised devices and the revocation of all authorization for that device. o Using Enterprise-Wide Network Defense and Situational Awareness, the AN will have the ability to create audit files that include strongly authenticated and protected information about endpoints, network devices and processes, and network management control actions. o To ensure confidentiality, the AN will protect network topology and access location data using the Secure End-to-End Communications Environment that could be used to geolocate users. o Using Distributed Policy-Based Access Control, the AN will provide access control to network transport capabilities based on authenticated user identity, user privileges, authenticated network access device identity, location, Quality of Service/Class of Service (QoS/CoS) and user priority settings. Provide Dynamic Resource Allocation – Allocate network and computing resources based on dynamic mission needs. The AN will use Assured Management and Allocation of Resources to: o Provide two-way authentication and the establishment of the integrity of all management and control commands that implement resource configuration, allocation and enforcement. o Provide a policy based enforcement mechanism to ensure that users are not exceeding their allocated resources or privileges. o Provide a policy override feature to enforce priority of certain information such as survival data. o Ensure audit log entry of all changes to the QoS/CoS settings and policy override actions are securely maintained. o Provide real-time situational awareness picture of all resources. Provide Dynamic Group Formation – Dynamically form groups of users and enable these groups to communicate and share a common set of information and services only with each other. o Using Dynamic Policy Management, the AN will provide dynamic allocation and enforcement of COI communications and computing resources and services. 41 o Dynamic Policy Management will also provide support for cross-domain connectivity between the GIG, the AN, and other external systems. Provide Computer Network Defense (CND) – Provide a proactive and reactive capability for computer network defense; protect, monitor, detect, analyze and adaptively respond to unauthorized system and network activities. Using EnterpriseWide Network Defense and Situational Awareness, the AN will be able to: o Provide increased priority to enable the timely delivery and processing of sensor data and the derived situational awareness information to support the execution of analyzed and deliberate responses. o Provide real-time monitoring, collection, anomaly detection and analysis of all sensor data. o Ensure protection mechanisms are provided to sensor data and the derived situational awareness information to guarantee their integrity and availability. o Provide for the secure collection and processing of sensor and situational awareness data throughout the AN. o Provide secure logs to record all CND and IA actions taken to adjust the AN and GIG configurations. The logs should include the initiating user, time of action and the action taken. o Provide an ability to automatically uncover vulnerabilities and predict intrusion/attack strategies that can exploit the vulnerabilities. Provide Management and Control of GIG Network and Resources – Securely manage and control all communication, computing resources and services, remotely and in an automatic manner. Given the scope of management and control, protection of this information is critical to preventing unauthorized entities (including GIG and non-GIG entities) from gaining access to GIG components and affecting the availability of the GIG. o Using Assured Management of Enterprise-Wide IA Mechanisms and Assets, the AN will provide secure management of the configuration of the GIG, monitoring for unauthorized configuration changes and securely applying updates; provide the capability to automatically configure and reconfigure its resources, receive configuration status from its resources and generate reports on the configuration of its resources; provide the ability to set limits on the usage of its resources and provide for automatic corrective actions when thresholds are exceeded; provide the ability to define, enforce and control a digital security policy across security domains and COIs; provide the ability to correlate and deconflict differing policies to arrive at a mutually acceptable policy; provide the ability to securely distribute and validate updates or changes to the digital security policy; and provide the ability for network managers to manage and control differential delivery of information, based on QoS/priority settings of the information flow, as well as traffic planning/engineering inputs at a network level. 42 o Enterprise-Wide Network Defense and Situational Awareness will allow the AN to ensure all components, especially IA-specific, have the capability of recording audit events and posting audit reports for access by management and control entities, and maintaining the availability and integrity of all such records. 5.2.2.2 Supporting Infrastructures 5.2.2.2.1 Security Management Infrastructure (SMI) Supporting infrastructures provide the foundation upon which IA mechanisms are used in the network, enclave, and computing environments for securely managing the system and providing security-enabled services. Supporting infrastructures provide security services for networks, end-user workstations, servers for Web, applications, and files, and singleuse infrastructure machines (e.g., higher-level Domain Name Server (DNS) services, higher-level directory servers). An overall supporting infrastructure for secure environments is referred to as a Security Management Infrastructure (SMI). An SMI is comprised of components, functions, and products provided by external systems and/or within the system. Examples of SMI provided products include software-based cryptographic algorithms, symmetric keys, public keys, X.509 certificates, and virus update files. Under the Cryptographic Modernization Initiative (CMI), the DoD is transforming the cryptographic inventory to offer significant operational benefit in alignment with the Department’s commitment to transformational communications and related (e.g., netcentric) warfare doctrines. The CMI will introduce new End Cryptographic Units (ECUs) incorporating flexible, programmable cryptography, new cryptographic algorithms, new key types, and capabilities for electronic downloading of new operating or application software, including cryptographic software. ECUs will have provisions for dynamically changing operating modes, algorithms, or keys in response to new missions. The emerging ECU characteristics require an overarching ECU Management Infrastructure. Currently, a framework consisting of five categories of ECU management has been defined.1 Inventory Management – Tracking possession (quantities, locations, status, owner identity) of ECUs. Configuration Management – Establishing hardware and software baselines for ECUs; managing optional and mandatory hardware and software updates; and maintaining records of approved equipment and system configurations. User Data Management – Creation, distribution and installation of various types of user data associated with a specific mission, not categorized as configuration or 1 ECU management categories are defined in the GIG IA Architecture and are still undergoing refinement as is the ECU management program. As a result, these categories should be considered notional at this time. 43 key management data. Examples are frequency allocations or hop sets and IP addresses. Key Management – Provisioning of cryptographic key and PKI certificates to ECUs, including ordering, generation, production, delivery, loading, auditing, accounting, and tracking of keys and certificates. Policy Management – Provide authority structure to manage and change security policies enforced in ECUs. The specific infrastructures and processes supporting these management categories will consist of a combination of external infrastructures and local, organizational infrastructures. For example, management of AN ECU inventory records will be conducted at an AN management facility with interfaces to external organizations such as NSA. User data management, policy management and configuration management functions will also be initiated and performed at an AN management facility. Configuration functions such as reprogramming of cryptographic algorithms will require interfacing to the DoD’s KMI. The KMI will provide the secure creation, distribution, control and management of public key products, traditional symmetric keys, and support for manual cryptographic systems. The KMI will support the entire range of key management needs including registration, ordering, key generation, certificate generation, distribution, accounting, compromise recovery, rekey, destruction, data recovery, and administration. While the DoD KMI is the primary source for AN key-related products, dependent on mission requirements, the IC Public Key Infrastructure (PKI) and the DoD PKI may provide support for certain key and certificate requirements. Currently, the DoD is operating a separate PKI that provides X.509 based certificate products for DoD personnel and devices. Similarly, the DoD is currently operating the legacy Electronic Key Management System (EKMS) that provides key management support for all other symmetric (i.e., traditional) and asymmetric (i.e., public) key management needs. However, in the FY07 – FY09 timeframe, EKMS functions will be transitioning into the DoD KMI.2 Also, the DoD PKI will be brought under the DoD KMI umbrella. Early AN operations may need to interface with the EKMS to obtain key. The AN must also project evolving its key management processes from EKMS to KMI. 5.2.2.2.2 DoD Key Management Infrastructure (KMI) The AN will use the DoD Key Management Infrastructure (KMI) and Electronic Key Management System (EKMS) processes as its core key management capability. The AN will limit the keys it requests from the KMI to those necessary to configure, operate and manage the devices that are integral to and directly managed by the AN. These keys will include those necessary to enable operator, manager, and administrator access to AN components. It’s anticipated that some legacy EKMS functions will be operational past the 2012 timeframe. However, early transition to emerging KMI functionality will improve automated key delivery and should simplify key management processes. 2 44 The KMI will support the AN by providing: End Cryptographic Unit (ECU) registration Key ordering and generation Certificate generation Key distribution, accounting, and compromise recovery Rekey functions Key destruction Key and ECU administration Over the Network Keying HAIPEs, IPSec, and circuit link encryptors electronic key products and upgraded cryptographic algorithms TRANSEC device and packet masking function key material TBD functions and keys 5.2.2.2.3 Public Key Infrastructure (PKI) PKI delivered Public Key (PK) services will support several security functions including validating integrity and origin of signed executable code (e.g., waveforms), configuration data, distributed key material, and management and control data. PK services also provide the basis for mutual authentication, and support identification and authorization. Finally, the PK certificates will be used to secure IPSec, TLS, and SSL tunnels and provide security to AN control and management data. An AN will require node authentication and access control. The AN nodes will not process information received from other nodes or AN management systems or devices external to the AN until it validates that it is communicating with a valid, operational entity via crypto verification of the public key certificate. The digital signature will be used to provide authentication and integrity security services. The AN must provide the means for AN connected networks to access GIG resident PK services. The AN may need to host functionality that will extend PKI services, such as certificate status checking, to the airborne network thereby ensuring entities (applications, devices, and humans) are able to seamlessly access PK services. PKI will support the AN by providing: Identity, integrity, confidentiality, and non-repudiation Class TBD person certificates Class TBD device certificates 45 Support certificate issuance, validation, and revocation for device and people certificates PKI must support Disconnected operations Terminal, ECU, manager, operator, and administrator and other AN entity authentication Role based access management for nodes and other AN components including system managers, administrators and operators Secure policy distribution Network management and operations Protocol security The AN may need to support extending PKI services to the AN operational domain by providing: Local storage of for certificate status validation data such as Certificate Revocation Lists (CRL) Processes, such as OCSP responders, necessary to support accomplishing certificate validation while minimizing bandwidth impact Local support for certificate public key storage LDAP or other DoD PKI interoperable directory service Extended PKI support when disconnected from DoD infrastructure. 5.2.2.3 AN Information Flows Though the AN will support multiple user communities, the types of information flows handled by the system are common among those user communities. Table 5-3 identifies the types of AN information flows that need to be protected within the system boundaries. Security of the AN and the information transiting the system are critical to mission success. Classified national security information carried over the AN will be transmitted only by secure means. Sensitive but unclassified information will be protected during transmission according to the level of risk and the magnitude of loss or harm that could result from disclosure, loss, misuse, alteration, destruction, or nonavailability. The AN will have the capability to transmit user information ranging in classification from unclassified up to and including Top Secret/Sensitive Compartmented Information (TS/SCI). The classification levels will be dependent on the ability of the system security components and processes or information originator to encrypt the information and the ability of the end user to provide the appropriate cryptographic devices for decryption. AN system information (management, disseminated policy, etc.) will be protected in a threat environment up to TBD. 46 Table 5-3. Summary of MAC and Confidentiality Level by Information Flow Information Flow Mission Assurance Category MAC 1 MAC 1 MAC 1 MAC 1 MAC 1 MAC 1 MAC 1 User Policy Dissemination – Category I Policy Dissemination – Category II Network Management – Category I Network Management – Category II Network Control – Category I Network Control – Category II Confidentiality Level Defined by User Sensitive Classified Sensitive Classified Sensitive Classified Figure 5-2 depicts the System information flows and where those flows will interface with AN components and the GIG. Inbound Flow GiG User [Direction] Net Mgmt Net Control Pol Diss Inbound Flow Outbound Flow [Status] Net Mgmt AN Node or User Net control Terminal Pol Diss User [Direction] [Status] Net Mgmt Net Mgmt Net Control AN NOC Net Control Pol Diss Pol Diss User Outbound Flow Figure 5-2. Data Flows in Relation to AN, AN Nodes, and the GIG 5.2.2.3.1 Least Privilege Least Privilege is an important IA concept for the AN. The key concept behind least privilege is that a user be provided no more privileges than necessary to perform a task. In an environment like the AN, this clearly becomes important in trying to ensure that users in a given user community are not capable of exceeding their assigned permissions and administrators of the AN are given system access compatible with their roles and responsibilities. To accomplish least privilege requires identifying what the user's job is, determining the minimum set of privileges required to perform that job, and restricting the user to a security domain with only those privileges. By enforcing least privilege, 47 users or objects of the AN system will be unable to circumvent the organizational security policy. 5.2.2.3.2 User Traffic Transport of user information through the AN is the core mission of the system. User information will flow from a user’s enclave – with confidentiality protection provided by the AN node or, in some cases, the user – to the AN. Typically, user information will enter the AN via an AN node or an edge interface with another transport network, then flow through the AN out to another AN node or through an interface to another transport network, and then to the distant end user’s enclave. User information can be data, voice, video, or imagery. The information owners or producers will determine the information sensitivity or confidentiality level; the AN node or the user’s system will provide for endto-end confidentiality protection. While the user information will enter the AN as sensitive unclassified, the AN will be responsible for ensuring the availability of the transport and will be required to provide services to protect the transport, such as TRANSEC, logical separation between users in different user communities, and packet header masking or cover over RF communications. 5.2.2.3.3 Policy Dissemination Policy dissemination information is the system data flows that are used to distribute security and management policy and enforce how AN components are managed, utilized and protected. Those AN components include all resources within the enterprise such as physical devices (e.g., routers, servers, workstations, security components), software (services, applications, processes), firmware, bandwidth, information, and connectivity. The policy dissemination data flows are the digital set of rules, coded in software or hardware into GIG assets, by which all actions of these assets must abide. To achieve enterprise wide (end-to-end) policy management of the AN, the policies defining the rules for use of information, communications (transport), and management and control functions must be integrated into a cohesive system policy. This includes establishment of an agreed approach for risk measurement, risk management and risk acceptance, through an Assured Information Sharing policy [TBD]. The policy defining interconnections with non-AN entities would specify functions such as U.S. access and handling rights for a foreign partner’s restricted data. Reciprocally, AN policies must address the access to GIG assets by these partners. The dynamic and adaptive aspect of policy dissemination information allows for the rapid adjustment of these rules in response to crisis situations that require either a reduction of privileges or increased latitude. These adjustments will change the criteria used to determine how resources are allocated to users and how access control decisions are made. The AN must not only support adjustments to policy, but must also support conditional policies. 5.2.2.3.4 Network Management 48 Network management information is essential to gaining a view into the status and configuration of the AN. Network management information may include audit data, the capturing of AN network events, configuration commands and information, component management commands (such as AN node session establishment or disconnection), traffic statistics and performance data. Keying management information is also considered part of network management information. Network management information is transmitted between the AN Network Manager and the AN network components. Network management data flows are two-way flows of information. In addition to the intra-AN management flows, network management information will also be securely exchanged with external network operations centers (NOCs) (such as the Global Network Operations and Security Center (GNOSC)). All AN management information flows must use authentication and protection techniques approved by NSA to ensure the authenticity and integrity of the information. 5.2.2.3.5 Network Control Network control information includes link management exchanges, network services exchanges, router exchanges (e.g., Interior Gateway Protocol (IGP) exchanges, Exterior Gateway Protocol (EGP) exchanges, routing table updates), QoS signaling exchanges (e.g., Resource Reservation Protocol – Traffic Engineering (RSVP-TE). Network control information protection must include confidentiality mechanism to protect against traffic analysis attacks as well as integrity and authentication mechanisms to ensure the control information is authentic and unaltered. Control information that contains information that identifies individual users of the AN and/or their location must be protected at the MAC 1, Classified level. 5.2.2.4 AN IA Boundary Definition For the purposes of AN IA Architecture, an Information Assurance Boundary will be defined as: A conceptual term used to delineate system Security Services; Integrity, Confidentiality, Non-Repudiation, Authentication and Availability, from other system services. The Information Assurance Boundary is rarely analogous to a physical boundary and will often consist of functions implemented in both hardware and software. IA Boundary Identification Process Identification of a system’s IA Boundary begins with creating the system’s Security Policy. This Security Policy specifies the system’s Security Services to be provided, the data elements requiring these protections and the handling requirements to be implemented. Any physical or functional component of the system which implements a 49 part of its Security Policy is considered to be “Inside the IA Boundary” of that system. Once the IA Boundary is established, it is submitted to the system’s Designated Approving Authority (DAA) for Approval. AN IA Boundary The IA Boundary is established by the Designated Approving Authority (DAA) to include all hardware and software sub-systems which implement parts of the system Security Policy. AN functions which may be included in the AN IA Boundary are listed below: Encryption: TRANSEC, HAIPE, Bulk Encryption Privilege Management (e.g., PCF functions). Data Security Services (Integrity, Confidentiality, etc.) ASWR Key Management: Key Ordering, Generation, Distribution, etc. Network Operations and Management Network Services (e.g., DNS, Configuration Management Server) Backbone Routing Services (e.g., Routers, Switches) Operator Authentication mechanism(s) 5.2.2.5 Dynamic Policy Based Security Management (PBSM) The AN, characterized by dynamic network topologies, will be subject to various types of complex security attacks and varying operational needs. The AN IA management capability will need to cover multiple security domains and COIs. This will require the trusted creation, distribution, and automated enforcement of IA policy directives. Policies prescribe the operational need, acceptable security risk, and weighting between the two under various conditions. The policy must be implemented in a manageable, flexible means, not “hard coded” into the design of system components. Dynamic policy management is the establishment of digital policies for enforcing how AN assets are managed, utilized, and protected. This includes policies for access control, quality of protection, quality of service, resource allocation, connectivity, prioritization, audit, and computer network defense, as well as policies covering the use of AN component hardware and software. AN assets include all resources within the AN such as the physical devices (e.g., terminals, gateways, routers, security components), software (services, applications, processes), firmware, bandwidth, information, and connectivity. For example, security policies will be used to guide: Firewall configurations including open and closed ports and allowed or disallowed protocols Proxy configuration Attack profiles to detect 50 Actions to take when an attack is detected Identification and Authentication (I&A) policy Virus checking policies, etc. To achieve enterprise wide (end-to-end) policy management, the AN will implement core policies promulgated by the GIG. These policies will define the rules for information use, communications (transport), management and control functions, and service access. The AN will take these core policies and modify them for operations within the AN’s domain and unique operational requirements. The AN must be able to support the policies of non-AN participants (e.g., IC, Allied Nations, NATO, etc.) who may have airborne and other networks that will need to interoperate with the AN. Support and interoperating with policies generated by non-AN sources will require establishment of an agreed approach for risk measurement, risk management and risk acceptance. The policy would also specify functionality such as U.S. access and handling rights for allied-restricted data. In most cases, the GIG core policy will addresses cross-user group handling rules requiring little modification within the AN. The dynamic aspect of policy management allows for the rapid adjustment of these rules to meet operational scenarios that require a rapid reduction of privileges and accesses or increased latitude. These adjustments will change the criteria used to determine how resources are allocated to users and how access control decisions are made. The AN must support conditional policies. The policy for accessing an AN asset will specify different access rules based upon the conditions that apply to this set of information. Factors such as destination system or data source, path (within the AN or from outside the AN, or routing through the AN) etc., may modify the level of trust afforded an entity within the AN ultimately modifying the level of access allowed. 5.2.2.5.1 PBSM Framework Policy based security management requires a framework that addresses policy management from the point of policy creation to policy installation in end devices. This framework must include the ability to dynamically update AN policy in response to changing network conditions or in response to updated GIG security policies. Figure 5-3 provides an architectural framework (based upon the policy management architecture developed by the IETF Policy Framework Working Group) for performing dynamic policy management within the AN. 51 GiG Policy Input AN Policy PreEngineering Network Modeling Validate Policy Policy Input Point Logical Language Policy Promulgation Point Deconflicted Policy Policy Distribution Point Device-Specific Commands — e.g., config file Push Pull Policy Enforcement Point Current configuration/error or event traffic Figure 5-3. Notional Policy Management Architectural Framework Policy management begins with a pre-engineering phase in which the GIG source policy and locally developed policy or modifications to the GIG policy is validated before entering into the AN. Validated GIG and local security policies enter the AN at a policy input point as follows: The entity entering the policy at the input point must be authenticated and validated – the input point must determine if the entity has the proper authorizations to enter policy. The policies are coded in a high level language suitable to define policy that will be transferred to a policy promulgation point. The policy promulgation point performs policy deconfliction to resolve any conflicts between the GIG enterprise-wide policy, AN mission specific and community of interest policies, and the policies of non-AN entities (e.g., allied, coalition, etc.) that have access to the AN. The deconflicted policy is provided to a policy distribution point, which will likely be at management and configuration nodes, for inclusion in AN device configuration loads. The policy is distributed to a policy enforcement point -- a network or security device -- using a push or pull model. The push model will be used for policy that must take effect immediately because new behavior is needed under a particular condition. The pull model can be used in cases where a policy change is scheduled to take effect at a particular time but is not critical to current 52 operations. Ensuring that AN entities stay synchronized with current policy is a critical aspect of policy distribution As needed to meet network node distribution, policy promulgation, distribution, and enforcement points may be hierarchal distributed in order to support the distributed nature of the AN. It is anticipated the network and security management structures will take advantage of similar data flow and physical architectures to ensure that all AN assets are security and operationally managed. 5.2.2.5.2 Policy Protection The AN policy management architecture will implement the security services and mechanisms necessary to protect the policy throughout its life cycle. From the point of creation to installation in the policy enforcement point, every entity handling digital policy must maintain the integrity of policy information for policy-at-rest and policy-intransit. AN assets must maintain integrity of the source of origin for policy throughout the management infrastructure. Depending on the source and value of the policy, the AN may need to provide policy confidentiality protection. Every entity sending or receiving policy information must be identified and authenticated. An AN entities privileges to send, receive, and modify policy as well as to send error messages to the policy promulgation point must also be validated. Other security services include the logging of all policy management transactions and the assured availability of the management infrastructure. A critical aspect of maintaining the security posture of the AN, the availability of the policy input, promulgation, distribution, and enforcement points is vital to nearly all AN functions. 5.2.2.5.3 Security Management System TBD 5.2.2.6 Data Protection The AN will use a variety of mechanisms to secure user and system data at rest and in transit. These mechanisms will range from the Type 1, High Assurance Internet Protocol Encryptor (HAIPE) to commercial Type 2 encryption systems, to software based mechanisms, such as the IPSec protocol described by RFC 2401. The level of security to be applied to a data object will be defined by the object’s “Quality of Protection”3 or QoP markings. The AN Distributed Policy Based Security Management and Access Control systems will provide the enforcement mechanisms to assure the specified QoP is 3 As part of the data labeling, an object will be associated with security properties and policies necessary for protecting it. Properties can include how to protect the object as it travels across the network (e.g., commercial grade vs Type 1 protection, as well as object and/or packet and/or link level data-in-transit protection requirements), how the object can be routed (e.g, must be contained within DoD controlled resources or can flow through networks external to the GIG), or how the data object must be protected at rest. Quality of Protection is different from metadata that describes the contents of the object. Metadata is designed to facilitate discovery and data sharing. QoP defines how a data object is protected while it is at rest and in transit. 53 provided. Data, be it user data or system management data including policies, is vulnerable at two different times, when at rest stored in a form waiting to be used and when in transit between the storage facility and the user. Data-at-rest protection will be required for some types of data (e.g., sensitive data, some policy, etc.) and for certain environments, such as information stored on a system in a hostile environment. For shared information, data-at-rest protection must be provided at the object level, where an object is defined as a file, or pieces of a file. This leads to a large range of object types each of which must be properly protected. Data-at-rest protection will be provided in a number of ways including media encryption mechanisms. Data-in-transit protection consists of the ability to provide confidentiality, integrity, and or authentication services to the information as it is transmitted through the AN. Protection of data-in-transit includes providing traffic flow security (TFS). Traffic flow security should be provided for all high-risk links in the AN but could also be provided for medium or low risk links. In general, TFS protections include protections against network mapping and traffic analysis. In general, the lower in the protocol stack confidentiality is applied, the greater the TFS benefit. For IP networks a variety of mechanisms can be used. For IP environments where the communications links are circuit based and routers are protected, hop-by-hop link encryption can be applied to provide TFS for encrypted packet traffic. AN network traffic will be protected at the application, network, and link layers. 5.2.2.6.1 Application Layer Protection Application layer data-in-transit security is the protection of information as it flows from one end user terminal to another, where the end user terminals apply the protection mechanisms, and the protected information is not accessible at any point during transmission. Application layer protections, implemented by user applications or other user-managed security tools, are beyond the scope of the AN. However, they can impact AN security by preventing virus checking and intrusion detection and prevention tools from inspecting the contents of the data payload. 5.2.2.6.2 Network Layer Protection Network layer data-in-transit security is the protection of IP packets as they flow across the AN to other AN nodes or to nodes existing beyond the edge of the AN. Protection could be from enclave to enclave, or from host to host. High Assurance Internet Protocol Encryptor (HAIPE) compliant devices will be used to provide Type 1 data-in-transit network layer security. The AN HAIPE device will be a modular, software programmable INFOSEC module designed to meet the low and high data throughput requirements necessary to support all AN users. Its modular design will facilitate its operation as a component of the AN node or as a platform LAN supporting component. 54 In order to support backwards compatibility with legacy communications systems, the HAIPE supporting programmable INFOSEC module (PIM) will also support operations as a bulk encryption device. Being able to program the PIM as a HAIPE device or bulk encryption device will facilitate use of AN supporting components to provide capabilities that will be matched to the mission, platforms, and communications transport needs. Figure 5-4 provides a notional, block diagram view of the components that may comprise an AN node supporting terminal. Key to Figure 5-xx components is their flexibility – they are designed to support straight through connectivity or bypassing and are designed around a function agnostic switching fabric. This will allow a module to be programmed as a switch, router, or other network component as required to meet mission needs. Router is function/data agnostic switching fabric — can be router, switch, mux, etc. Software load and operations policy dictates how it operates. PIM [ HAIPE or Bulk ] RF or Optical Control TRANSEC ASWR IDS/IPS Virus Key Management Router, PIM, router — with connectivity options that will allow horizontal flow through terminal or input and/or output to be redirected to platform. 1. Security Applications but could be net management, etc. 2. Applications on red and black side. 3. Red supports plain text [user] data. 4. Black supports terminal [security, management, control, configuration, etc.] ASWR IDS/IPS Virus Key Management Figure 5-4. Notional AN Supporting Terminal Block Diagram 5.2.2.6.3 Link Layer Protection As an RF based network, the AN will need to provide protection against a number of threats, such as jamming, not found in wired networks. IP networking link layer protection will be provided by Transmission Security (TRANSEC) mechanisms. TRANSEC implemented link layer security provides the following protection and functions: Anti-Jam (A/J) protection 55 Low Probability of Interception/Detection (LPI/LPD) protection Traffic Flow Security (TFS) and Traffic Analysis Protection (Note, the HAIPE device provides IP network layer TFS protection) Signals analysis protection Protocol and header cover/packet masking TRANSEC isolation for major sets of users (If connecting to TSAT, AN supporting TRANSEC will need to meet TSAT TRANSEC user group separation requirements.) TRANSEC will be implemented in a stand-alone, embedded, modular programmable INFOSEC device that will operate at the data rates and crypto algorithms necessary to support user needs. 5.2.2.7 Key Management Key management is one of the fundamental aspects of Information Assurance. Key management includes the following elements/attributes: Key Management Plan – a document that describes the process of handling and controlling cryptographic keys and related material (such as initialization values) during their life cycle in a cryptographic system, including ordering, generating, distributing, storing, loading, escrowing, archiving, auditing, and destroying the material. Algorithm Flexibility – the capability to support a variety of cryptographic algorithms and systems, of varying strengths and types, and to change algorithms when appropriate to meet new interoperability or mission requirements. Coalition Interoperability – the capability of interoperating with cryptographic systems used by coalition partners while simultaneously providing a high assurance U.S.-only capability. Authorized Key Sources – keys can be either locally generated or provided by a central authority which is source and integrity validated. Trusted Key Storage – keys must be stored securely on an End Cryptographic Unit (ECU) such that it cannot be extracted in a useful way by an attacker (including attackers’ software agents), and it cannot be modified in an unauthorized way without detection. Key compromise recovery mechanisms – the capability to identify all ECUs impacted by a key compromise and ensure the rapid recovery of operations. Key destruction mechanisms – the capability of “destroying” keys when required by circumstances. Key Management Architecture (KMA) The AN KMA will consist of the following elements: 56 AN Network Operations Center (NOC) (i.e., terrestrial management facility or network service provider) AN Nodes and Terminals Key Loading and Initialization Facility (KLIF) National Security Agency (NSA) KMI/EKMS TBD The AN key management infrastructure must be capable of operating for extended periods of time without connectivity or support from the. Therefore, a closed system for supporting the key material requirements of the AN elements will be needed, rather than an open system where the elements could interact directly with the NSA KMI/EKMS for all key materials. The AN NOC will be the primary interface to the NSA KMI/EKMS for key material. The NOC is expected to support and supply keying material to all other elements of the AN as well as supporting all crypto planning functions, compromise recovery functions and support the controlling authority. Prior to performing any key management services, the identity of the node or component must be ascertained using a robust method such as a PK-based digital signature. Benign key distribution techniques must be used to ensure that RED keys are accessible only to the end-device. Where possible, and in any newly developed cryptographic devices, the use of asymmetric (public) keys should be used in favor of symmetric keys. Asymmetric keys have inherent properties that make them more secure than symmetric keys.4 The AN network must support in-band benign keying and rekeying of AN node and component public key certificates. Also, with the emergence of multi-channel, software programmable communications systems, it may be advantageous to distribute all keys for a given system as part of the system’s configuration file essentially delivering initial key material outside the key distribution system. TRANSEC for RF links will continue to require the use of symmetric keys. The AN must support the benign distribution of these keys to the node in support of the appropriate user group, protect these keys while resident in the equipment through robust anti-tamper and provide timely compromise recovery. The AN NOC will also: Report key compromises to KMI Report public key certificate revocations back to the PKI. Control of the PCFs Authenticate terminals/users/networks 4 With asymmetric keys, a unique key is generated for each transaction through a public key exchange, while in a shared symmetric key operation, a single compromise leads to a system-wide compromise. Also, public key certificates allow for individual certificate revocation to selectively remove compromised individuals/devices without system wide rekeying. 57 Download/upload mandatory software Maintain ECU inventory records Manage ECU (inventory, configuration, user data, key and policy) Manage the security configuration of AN resources Audit and ASWR Manage security policies Manage user groups 5.2.2.8 Authentication System Authentication establishes the validity of a claimed identity and Access Control is the prevention of unauthorized use of the system’s resources. Robust Authentication and Access Control is especially important to the AN to ensure that the given user/device has been provided appropriate access to the AN’s resources. Authentication applies to all of the information flows as follows: User Information Flows: Required in order to establish/maintain the logical separation of COIs. Network Management Flows: Required to avoid spoofing by a potential adversary. Network Control Flows: Required to insure the integrity of network operations and to enable proper management/control. Policy Control Flows: Required to insure proper maintenance and separation of the COIs. Access to and use of the system will be restricted to known verified users. Factors that may be used in the authentication process include Biometrics, cryptographic tokens, and integrated Public Key Infrastructure etc. Multiple factors will be required to ensure that only users with known, verified identity are allowed access. Network management information flows must include a minimum of two factor authentication features. Configuration files, routing tables, and software updates must have robust authentication to assure management by only the control center. Network control systems must be protected by rigorous physical and personnel security methods. Robust and, at a minimum two-factor authentication, including PKI and biometrics must be used to improve the security of network control transactions. 5.2.2.9 ASWR 58 The AN will provide host and network based Intrusion Detection Systems (IDS), Intrusion Prevention Systems (IPS), and Virus Detection, Prevention, and Removal applications. Larger AN nodes, such as the Network Service Provider and Internetwork nodes, will support full IDS, IPS, or virus applications and detect and respond to anomalous network traffic. Less capable nodes, such as Network Access and Network Capable nodes, will employ agents that monitor network traffic for anomalous behavior sending data back to an aggregation point and then responding to the central services instructions. Transient encrypted user data will not be tested for anomalous content as the node will not have the keys or requirement to unwrap the packet for inspection. The AN will support plain text (red side) IDS, IPS, and virus capabilities. However, platforms with organic IDS and/or IPS capability may request the AN node to pass their plain text data directly to their processes. The AN node is responsible to monitor the AN management and control path for anomalous network behavior and virus infected code taking action based on the current policy. ASWR process and sensor collected data will be sent to network management aggregation points. The network management nodes will analyze the data to determine if detected anomalous behaviors are localized to a few nodes or occurring network wide. Processed and aggregated data will be forwarded to GIG network operations centers. Dependent on the analysis results, network security and operations policy will be generated and distributed throughout the network modifying IDS, firewall, and other security component behavior, to minimize anomalous behavior impact. The AN will employ reactive IDS and migrate to IPS as intrusion detection systems and software technology matures. 5.2.2.9.1 Network Intrusion Detection System The Intrusion Detection System (IDS) defends system components against threat actions carried by network data traffic. The AN will use a combination of host based and network based IDS processes. Host-based IDS components -- traffic sensors and analyzers – will run directly on one or more of the hosts they are designed to protect. Network-based IDS sensors will be placed on subnetwork components, and associated analysis components run either on subnetwork processors or other, more powerful, hosts. The IDS will be configured using GIG provided attack signatures that will be delivered with the AN Node configuration files. Updated attack signatures that result from local detection of previously unknown attacks or is received from the GIG will be delivered using security policy updates or via an updated configuration file. 59 The IDS will evolve to become the Intrusion Prevention System (IPS.) The IPS hardware and software detects and prevents known attacks. It will employ methods such as heuristic, anomaly checking, or signature based filtering to detect the attack. Intrusion prevention is specifically targeted at detecting and then preventing publicly known yet stealthy application-specific attacks. Intrusion prevention blocks malicious actions using multiple algorithms and will provide blocking capabilities that include (plus go beyond) signature-based blocking of known attacks. The AN IDS and IPS processes will locally log and report back to the AN NOC detection and any remediation results. The NOC will use the information to modify network security policy. In addition, the NOC will aggregate the information and report it back to the appropriate GIG network operations center. 5.2.2.9.2 Virus Detection, Prevention, and Removal The AN virus detection, prevention, and removal implementation will employ signature matching, code enumeration, and checksum comparison to detect virus infected code or data.5 Once detected, and dependent on the security and operations policy in place, the virus checking application may attempt to remove or “fix” the data file or it may alert the operator or it may quarantine the file for later action. The virus checking application is only effective when applied to plain text data. Because of this and the need to provide a defense in depth capability, hosts on platform LANs should also implement their own local virus checking applications. The AN virus detection and remediation processes will locally log and report back to the AN NOC detection and remediation results. The NOC will use the information to modify network security policy. In addition, the NOC will aggregate the information and report it back to the appropriate GIG network operations center. 5.2.2.9.3 Vulnerability Assessment System (VAS) TBD 5.2.2.10 Protocol Security The routing, transport, management, and other protocols used to enable the AN must be secured. At a minimum, protocol security will include origin validation, integrity, confidentiality, and mutual authentication between endpoints. Dependent on the sensitivity of the protocol’s data, that security may require use of Type 1 or Type 3 encryption techniques. 5 There are three common approaches to viral code detection. The first, signature matching, requires information about the virus. Specifically, a signature-based detector requires the virus’ code length and the location of its “contagious” segment. The second technique, code enumeration, involves examining known programs periodically to test whether any unknown segments of code have been added to the original file. It is most effective when applied before each execution of the program. Finally, checksum methods compare the current size of a file and the summed value of its bytes to the same attributes of a known uninfected version - an infection will often change these values. 60 Many of the standards based protocols do not organically provide for the level of security required by the AN or else have security implementations that will cause excessive overhead if employed in the AN. These shortfalls must be remediated by extending current specifications or generation of replacement specifications that are optimized for use in the wideband, wireless domain. 5.2.2.11 Other Security Functions 5.2.2.11.1 Firewalls TBD 5.2.2.11.2 Guards – Cross Domain Solutions TBD 5.2.2.11.3 Covert channels TBD 5.2.2.12 Security Modeling and Simulation TBD 5.2.3 Network Management The Airborne Network will be characterized by dynamic network topologies and bandwidth-constrained, variable quality links. Due to the special challenges posed by these features, it will be impractical to apply the same network management (NM) methods used in terrestrial networks to the Airborne Network. Two significant architectural challenges must be addressed: (1) enabling the NM capability to adapt to dynamic topology changes; and (2), developing efficiency enhancements to minimize management overhead over bandwidth constrained, variable quality links. The NM architecture for terrestrial networks is typically a centralized or hierarchical structure in which the relationship between the manager(s) and managed nodes changes very infrequently. The Airborne Network, however, will self-form, and undergo dynamic topology changes. Nodes may enter and leave the network, subnets may partition from the main network, separate subnets may merge to create a larger network, etc. As such, reliance upon static management relationships between nodes, and the assumption of a static topology, cannot be applied to the management architecture of the Airborne Network. The Airborne Network will also be confronted by significant efficiency demands. In general, maintaining network robustness when the majority of the network nodes are mobile will require a higher degree of maintenance overhead when compared to static terrestrial networks. Yet Airborne Network links will be bandwidth limited, and of variable quality; the dynamic nature of highly mobile airborne platforms will result in occasions of link outages and degraded link quality. These constraints make it critical 61 that the network management function be not only efficient, but also balance the “cost” of its transactions against the benefit that would result from conducting the transactions. 5.2.3.1 Cluster-Based Management Architecture To address these challenges, a cluster-based management architecture is needed. A cluster-based management architecture groups individual nodes into clusters that are managed by a cluster manager. The cluster managers are in turn managed by a network manager. The main concept behind cluster management is to convert a traditionally centralized process into a semi-distributed process to address the challenges posed by mobile networking (i.e., a dynamic topology and enhanced NM efficiency). The major components of the architecture include a Network Manager, Cluster Managers, and Intelligent NM Agents. 5.2.3.1.1 Network Manager The Network Manager executes management applications that monitor and control the managed elements – i.e., the subordinate cluster managers. Location options for the Network Manager include an air-based or ground-based node. Based on the tenet that the Airborne Network management solution scale across the variety of operational configurations (including autonomous operations disconnected from GIG enterprise services), it is assumed that the Network Manager will typically be air-based. It should be noted that a ground-based manager is not precluded in this architecture; in certain instances, a ground-based manager may be advantageous given the benefits of collocation within terrestrial centers of C2. However, to enable the desired management efficiency and autonomy features, the architecture will assume capabilities of an air-based manager. A required feature of an airborne Network Manager is its ability to transition management responsibilities to another node if the hosting platform leaves the network, or is no longer able to serve as the Network Manager. As such, a fail-over and hand-off function is required of the manager. 62 Cluster 1 Cluster 2 Cluster 3 = Terrestrial-based Peer or Super-ordinate Manager = Network Manager = Cluster Manager = Intelligent NM Agent Figure 5-5. Cluster Based Management Framework 5.2.3.1.2 Cluster Managers Cluster Managers are selected dynamically as the network forms. The performance objective in selection of clusters is to minimize protocol overhead between the node and manager, while maximizing management service availability over a dynamic topology. As Cluster Managers are selected, local NM/PBNM services are instantiated within them. These intermediate managers then take responsibility for local NM and policy dissemination functions in accordance with the policies of Network Manager. Cluster Managers act as proxies to aggregate and filter information -- based on cost-benefit examination -- from the cluster’s nodes to the Network Manager. Likewise, Cluster Managers receive NM and policy directives from the Network Manager and disseminate as appropriate to constituent cluster nodes. When acting as elements of a larger network, the Cluster Managers may collaborate among themselves to adapt to the changing topology. New Cluster Managers may be designated as subnets partition. As partitions merge, Cluster Managers may collaborate to determine who will serve the role of Cluster Manager of the larger network. Thus, the maintenance of Cluster Managers is dynamic to adapt to the topology changes of network. Cluster Managers enable clusters to operate autonomously while disconnected from the Network Manager due to network partitioning, loss of links to the Network Manager, etc. 63 Because the Cluster Manager maintains the cluster’s topology, health, and status information locally, this information will be available to the Network Manager upon reconnection of the cluster to the network. Thus, a dynamic and distributed management structure, rather than a centralized static structure, is applied to adapt to the dynamic topology of the Airborne Network. 5.2.3.1.3 Intelligent NM Agents Imparting local intelligence within the managed elements enables the nodes to conduct localized and autonomous collection, aggregation, analysis, and problem resolution -thus reducing the management overhead that occurs in centralized architectures with “dumb” agents. Intelligent NM Agents conduct cost-benefit assessments for interacting with the Cluster Managers – taking into account the link’s available bandwidth, the node’s Emission Control (EMCON) state, the importance and timeliness of event reporting, etc. 5.2.3.2 Policy Based Management Framework The IETF Policy Framework Working Group has developed a policy management architecture that is considered the best approach for policy management on the Internet. It includes the following components: Policy Server – A graphical user interface for specifying, editing, and administering policy. Policy Repository – A device used to store and retrieve policy information. PDP (policy decision point) – A resource manager or policy server that is responsible for handling events and making decisions based on those events and updating the PEP configuration appropriately. PEP (policy enforcement point) – Network devices such as routers, firewalls, radios, and hosts that enforce the policies received from the PDP. LPDP (local policy decision point) – Scaled-down PDP used when a policy server is not available. In addition to the Policy Server/PDP and PEPs, an intermediate set of elements, termed cluster PDPs, will be needed within the airborne management architecture to accommodate efficiency and autonomy requirements. In most implementations of the framework, the Policy Server, Policy Repository, and PDP are collocated and may potentially be hosted within the same physical device. The discussion of the framework below assumes this consolidation of system components. In the framework, a ground-based resource planner would formulate high-level airborne networking policies -- that is, formulation of the relatively static, high-level specifications of the desired behavior of flows. These sets of high-level policies would be downloaded into the Policy Server/Repository/PDP. The Policy Server/Repository/PDP is responsible for distributing policies to the intermediary PDPs. There are two approaches for 64 distributing policy: outsourcing, and delegated provisioning. In outsourcing, all policy decisions are conducted at the PDP. In delegated provisioning, policy directives may be defined in broader terms, with flexibility for local policy interpretation based on local events and conditions. The accompanying figure illustrates a hybrid solution for policy distribution. The outsourcing model (as reflected by the blue lines) is applied to maintain explicit control of particular PEPs. The provisioning model (as reflected by red lines) is recommended at cluster PDPs to minimize signaling overhead and enable the adaptation features required in policy enforcement to accommodate a dynamic topology. Policy managed services may include quality of service, traffic engineering features, and security attributes. Each service would employ a common set of policies, called a Policy Information Base (PIB). Modeling, Analysis & Simulation Tools Resource Planning Tool(s) Policy planning Policy formulation Policy Server/Repository/PDP: Cluster PDP Policy Distribution Policy Decisions Policy Accounting Cluster PDP Cluster PEPs Cluster PEPs Cluster PDP Cluster PEPs Policy provisioning Policy outsourcing Figure 5-6. Policy Based Network Management Framework PBNM Overlay The policy network management framework outlined above may be overlaid onto the cluster-based management architecture. As shown in the figure below, cluster managers are provisioned to act as intermediary (Local) Policy Decision Points (LPDP), interpreting and distributing policies from the Policy server/PDP to their cluster nodes (Cluster PEPs). Because each cluster manager acts as a local PDP for its cluster PEPs, the node is imparted with a degree of self-sufficiency required in semi-autonomous cluster operations. 65 Cluster 1 Cluster 2 Cluster 3 = Ground-based resource planning, and policy formulation, and modeling, analysis, and simulation = Network Manager/Policy Server/PDP = Cluster Manager/LPDP = Cluster PEPs Figure 5-7. Cluster Based Management Framework with PBNM Overlay Modeling, Analysis, and Simulation tools would take policies formulated from the Resource Planner -- and policy accounting statistics from the Policy Server/ Repository/PDP -- to evaluate the performance of current policies, and provide a facility to conduct “what if” scenarios to formulate improved and/or adjusted policies. These functions would be conducted at a ground based node. 5.2.3.3 Network Management System Components The general system components for conducting NM across the AN is reflected in Figure 5-x. This particular diagram depicts the notional placement of those system components within the platform AN Equipment and On-Board Infrastructure. In today’s Internet, management interoperability is accomplished using TCP/IP for communications protocols, SNMP for a management protocol, and a standard management information base for managing these protocols (MIB-II). In a similar fashion, the objective AN will require an analogous set of communications protocols, management protocol, and the corresponding MIBs. Every AN managed device will implement an Intelligent Agent (IA). The IA will execute the client-level portion of FCAPS functions for the AN, maintaining the fault, configuration, performance, and security attributes of the device. In platforms with multiple managed devices, a “master” IA will proxy and aggregate information across the 66 “slave” IAs, compiling summary reports to the Cluster Manager. The IA is focused on minimizing unnecessary management overhead across bandwidth-constrained AN links. As such, the master IA will apply a high degree of “intelligence” to conduct localized and autonomous collection, aggregation, analysis, and problem resolution functions concerning the platform’s managed objects. The master IA acts as a proxy to aggregate and filter information -- based on cost-benefit examination -- from the platform’s managed devices to the Cluster Manager. A MIB specifically tailored to these features (IA MIB) will support Intelligent Agent functionality. In platforms with a single managed device, the IA will act in a combined master/slave role. In platforms with an on-board infrastructure and local network manager, the IA can provide an HMI by “piggy-backing” on the local platform NM process. This HMI will present local health and status of the platform’s managed devices. All nodes that are “Network Capable” will implement Cluster Manager functions. The Cluster Manager is the crucial component in adapting the NM architecture to nodal mobility and topology changes. The Cluster Manager is an application process that is invoked autonomously and dynamically via participation within server election and handover protocols. When invoked, the CM process assumes the mid-level management role in FCAPS functions, distributing control and configuration commands to IAs in accordance with the policy and provisioned directives of the Network Manager (NM). Likewise, the CM aggregates IA summary reports of fault, configuration, performance and security data and forwards them to the NM. To enable management over the dynamic network, these processes conduct (or leverage) a clustering protocol that adapts the regional management function to the local topology changes. An affiliated CM MIB is accessed by these processes and provides the required database for conducting cluster management. Internetwork nodes and Network Service Provider nodes will implement a Network Manager application process. This application layer process manages the airborne network as a whole, via provisioning of commands to managed devices via the elected cluster managers. The NM application accesses an affiliated MIB data base (NM MIB). The HMI for this function is hosted by the on-board infrastructure, and provides top-level Network FCAPS and Network SA. 67 Figure 5-8. Network Management System Components Network Manager • Conduct overall monitoring of AN • Delegate control and configuration commands to CMs • Present AN Situation Awareness (SA) Cluster summary reports of Fault, Configuration, Accounting, Performance, and Security Control and configuration commands to CMs Cluster Manager • Autonomously select and advertise role as CM • Maintain cluster organization through participation in clustering protocol • Aggregate cluster SA from cluster’s IAs; • Conduct cost-benefit analyses for intelligent reporting to NM Distribution of NM/CM control and configuration commands to intelligent agents IA summary reports of Fault, Configuration, Performance, and Security Intelligent Agent-Master • Auto-discovery of CM • Localized and autonomous problem resolution • Aggregate platform’s managed device status data • Conduct cost-benefit analyses for intelligent reporting Distribution of NM/CM/IA control and configuration commands to managed devices Raw reports (Fault, Configuration, Performance, and Security) Intelligent Agent-Slave • Maintain managed device data in Device MIB Figure 5-9. Network Management System Components: Relationships and Activities 68 5.2.4 Link Management 5.2.4.1 Link Management Architecture A Link Management (LM) architecture that accommodates the characteristics and challenges of the AN consists of employing multiple managers each responsible for a subset of the total nodes that constitute the AN. This architecture will allow the LM system to function in a modular decentralized fashion that promotes efficiency as well as adaptability. The LM architecture components consist of a high level LM Executive, LM Autonomous Managers, and Intelligent LM Agents. Figure 5-10 shows the overall architecture. LM Executive LM Agent LM Agent LM Agent LM Autonomous Manager LM Autonomous Manager LM Autonomous Manager LM Autonomous Manager LM Agent LM Agent LM Agent LM Agent LM Agent = Logical Connectivity Figure 5-10. LM Architecture LM Executive The purpose of LM Executive (LME) is to maintain status of the entire AN, and if necessary, control subordinate LM Autonomous Managers. The LME monitors and evaluates the AN overall topology by interfacing with LM Autonomous Managers (LMAMs). The LME identifies any specific actions to be taken to alter the network topology when needed and executes them by controlling/overriding the LMAMs. The LME also prepares summary reports of LM information pertaining to the entire AN. LM Autonomous Managers 69 Each LM Autonomous Manager monitors and controls a subset of the total nodes (and associated links) that constitute the AN. As described above, the LM Executive monitors and controls these subordinate managers. In addition, each autonomous manager can exchange information with other autonomous managers to accomplish operations involving more than one LM subnetwork. The LM Autonomous Manager (LMAM) determines how the nodes of the subnetwork will be interconnected, performs admission control for each node, and provisions the needed link resources. The LMAM also monitors its LM subnetwork (nodes and links) and determines whether or not the current topology needs to be altered to accommodate any changes such as link or component failures or changes to the subnetwork participants. When necessary, the LMAM identifies the specific actions to be taken to alter the network topology and commands the corresponding LM Agent to perform these actions on the target link. In addition, the LMAM recognizes the conditions requiring hand-offs between nodes and will enable these hand-offs to be performed seamlessly. Intelligent LM Agents An LM Agent (LMA) advertises the identity and location of its node and identifies, authenticates, locates and determines the role of AN nodes from which it receives advertisements. This information is used by the topology establishment and adaptation functions in the corresponding LMAM. The LMA also determines the operational state of the resident network components and links and the network performance being achieved. Under the direction of an LMAM, the LMA changes the value of network and link parameters when necessary to modify the performance of any link. 5.2.4.2 Link Management System Components AN Link Management system components are depicted in Figure 5-11. 70 Figure 5-11. LM System Components 5.2.5 Network Services 5.2.5.1 Overview Network services refer to the services necessary for the effective access to and utilization of the network’s communications transport service. Examples include name resolution, dynamic host configuration (including dynamic address configuration), security authentication services, policy services for network admission, etc). These network services may be accessed by hosts or applications. Since the AN must be capable of self-forming and self-adapting with nodes dynamically joining or exiting the network, the network services architecture must be either: (1) impervious to these dynamics, able to supply the desired services despite the dynamic changes of the network; or (2) capable of adapting to these changes to provide the desired services. Also, when the AN must operate autonomously, without connectivity to ground nodes, the network services must be provided from airborne locations. Finally, the network service overhead traffic needs to be minimized over the bandwidth-constrained, variable quality links of the AN. For dynamic networks, if every network service (e.g., name resolution, address configuration) as well as, Network Management and Link Management conducts its own service transactions separately and independently of the other services, it could create an environment in which the service overhead traffic saturates the capacity of the network links. This condition and the above factors dictate the need for a distributed network services architecture with common approaches used to deliver the different services. 71 Options for distributed architectures range in the “level of distribution” delivered: from (1) partitioning of the network into regional clusters, in which cluster heads provide services to a network region or “cluster”; to (2), complete distribution, in which every node can render the service. Delivering network services with a distributed service architecture across a dynamic network will require that a number of service maintenance functions be performed. These service maintenance functions include server election, service discovery, service advertisement, and the need to maintain regional clusters through which to deliver services. Rather than forming separate, independent architectures – with each service employing its own physical architecture and corresponding maintenance transactions – a unified, common architecture for AN Network Services is established to achieve efficiency gains across the AN. In this architecture, cluster maintenance is conducted as a single process for all network services. Additionally, servers of the various services are collocated such that functions such as service election, discovery, advertisement, and other common service maintenance operations can be conducted on a common basis, rather than once per independent service. This enforces a single physical services architecture. (Another opportunity for leveraging commonality may be exploited by “piggy backing” upon functional facilities provided by other lower-layer processes, such ad hoc routing maintenance transactions.) The basic functionality of these service maintenance functions are described below: Server Election One of the attributes of a distributed architecture that supports dynamic networking is the ability of multiple (and in some cases, all) nodes to act in the capacity of “a server”. As a network self-forms, nodes that can act as a server are elected (or selected), and take on the server capability. To minimize potential performance impacts in highly dynamic networks, this process could include election of primary and backup servers. If a node leaves or becomes inoperable, an election process ensues to select a new server. If two subnets, previously disconnected and employing their own server merge, the election/selection process reconciles the redundancy. Service Advertisement Once nodes have been elected to act as servers, an advertisement feature is often employed to announce that it is acting in the server capacity. This announcement is conducted periodically, or on an event-oriented basis. Minimizing service advertisement overhead is a critical need for constrained-bandwidth networks; as such, various features may be employed, including constraining the broadcast announcement to n-hops (i.e., a cluster), using multicasts rather than broadcasts, and enacting the announcement only upon trap-driven events, etc. Service Discovery 72 A feature that often complements, and works in concert with the service advertisement function, is the service discovery function. This is employed by nodes which are in search of a server, such as those that have recently joined the network and need immediate service. Again, minimizing overhead is a critical need for constrainedbandwidth networks; the same approaches to mitigate overhead for service announcement may also be employed within this function. Cluster Maintenance A clustering approach to distributed architectures groups individual nodes into clusters that are serviced by a cluster server. The main concept behind clustering is to convert a traditionally centralized process into a semi-distributed process that adapts to dynamic network challenges. The performance objective in selection of clusters is to minimize protocol overhead between client and server while maximizing service availability. To do this, clusters maintenance protocols optimize the cluster attributes to adapt to the dynamics of the network. Clusters that are too large suffer from an excess of clientserver transaction traffic, while clusters that are too small suffer from an excess of cluster maintenance overhead. Additional factors that impact cluster maintenance include, among others, relative node speed, cluster density, mobility characteristics, etc. 5.2.5.2 Name Resolution Service A name resolving service (or naming service) translates the name of a resource to its physical IP address. A name resolving service also uses reverse mapping to translate the physical IP address to the name of the resource. Application of the current terrestrialbased Domain Name System (DNS) to the AN is impractical due to its reliance upon dedicated, fixed, terrestrial-based name servers. Since the AN must be able to operate disconnected from the terrestrial GIG infrastructure, an airborne-based naming service is needed that is self-sufficient and autonomous, while at the same time backwards compatible and interoperable with terrestrial-based services DNS services. The naming service must also be adaptive to AN dynamics -- name-providing nodes may leave the network, become disconnected due to topology partitioning, or go into EMCON mode. Finally, the AN naming service must also be efficient in the face of bandwidthconstrained, variable quality AN links. 5.2.5.2.1 Naming Service Features Interoperability and compatibility with GIG-based name services The AN name resolution architecture will accommodate both airborne- and GIG-based name resolution. The architecture should leverage terrestrial GIG-based name resolution services when appropriate. However, in instances in which GIG-based services are infeasible, unavailable, or impractical -- (e.g., due to disconnected operations, high-cost ground-air links, etc.) -- the architecture will provide a self-sufficient, air-based name resolution capability. The air-based capability will be backwards compatible and 73 interoperable with GIG-based services, to allow zone transfers/updates and airbornebased caches of GIG-based authoritative zone information. Autonomous Name Registration The AN air-based name resolution service will require an autonomous name registration process to discover and formulate a knowledge base of the existing names. Self Configuration and Service Advertisement/Discovery The AN air-based name resolution service will require a distributed naming architecture with self-configuration, autonomous server election, and service advertisement/discovery capabilities to support the spontaneous, self-forming features of the AN. An autonomous name registration capability will provide self-configuration of zone data and supporting resource records upon which naming services are based. After self-configuration of resource records, an autonomous server election process will occur to select naming capable nodes. A service advertisement/discovery processes will then enable nodes that can provide naming services to announce themselves. Other nodes seeking name resolution services will employ a server discovery process to locate appropriate name servers. Thus, a distributed naming architecture is formed such that airborne nodes do not have to rely on fixed, dedicated name servers. Distributed Architecture for Adaptation to Network Dynamics Continuous self-configuration and autonomous advertisement/discovery processes provide continuous service adaptation to dynamic topology changes. Additionally, these distributed services provide built-in redundancy and fail-over features to accommodate loss of primary service-providing nodes and/or their supporting links. Scalability The architecture must scale across the range of operational AN scenarios – i.e., from a small cluster of nodes disconnected from the GIG to a theater-wide deployment of AN assets. Efficiency The AN will provide efficient discovery of the naming service across the bandwidthconstrained, variable quality links of the dynamic AN topology. The discovery apparatus must be efficient and optimized to the current state of the dynamically changing network. Efficiency options include use of multicast and/or constrained (hop-limited) broadcasts. The AN name resolution architecture will conduct efficient name-resolution transactions. In GIG-connected operations, the naming service will evaluate when it is more efficient (or more expedient) to conduct name resolution via GIG-based services, rather than via AN-based services, and vice-versa. 74 5.2.5.2.2 Naming Service Architecture The AN name service architecture will consist of a distributed airborne-based naming system, with gateways to provide access, interoperability, and backwards compatibility to terrestrial-based GIG DNS services. Autonomous features (such as name registration, name server election, and name server discovery) will be supported by protocols to minimize overhead and efficiently use bandwidth-constrained AN links, such localized multicast and/or constrained (hop-limited) broadcast transactions. 5.2.5.3 Dynamic Network Configuration Management The AN will automatically configure and reconfigured as nodes join, depart, and move from one subnet to another. Providing a network-wide reconfiguration capability will require accurate current knowledge of the entire network structure. The AN dynamic network configuration management system will collect node configuration and capability data. This network configuration data will be stored in a repository and distributed to each of the AN subnetworks. Within a subnetwork, the AN dynamic network configuration management system will dynamically assign and distribute IP addresses, subnet mask, domain name for any network interface and distribute (and update) addresses of network servers (e.g., Name Resolution Server, Network Time Server, Network Policy Server, QoS Manager, Security Manager, Network Manager, Link Manager). The AN dynamic network configuration management system will also distribute other network configuration information (e.g., routing protocols and configuration). Figure 5-12 depicts the major functional components of the AN dynamic network configuration management system. QoS Manager PB Security Manager Dynamic Configuration Server Dynamic Configuration Server Dynamic Configuration Server Configuration Database Configuration Server PB Network Manager AN Node AN Node Link Manager AN Management AN Node configuration & capabilities AN Node configuration & capabilities AN Node configuration & capabilities Figure 5-12. Dynamic Network Configuration Management Functional Components 5.2.5.4 Network Time Service 75 The AN Network Time Service will enable the synchronization of all AN network devices, as well as the synchronization with external time sources. Time provided by the AN Network Time Service will be traceable to the Coordinated Universal Time (UTC), an international standard, based upon atomic timekeeping coordinated between the U.S. Naval Observatory (USNO), the National Institute of Standards and Technology (NIST) and 25 other countries. Each AN node will include a Network Time Server (NTS) synchronized with the UTC (when able to connect to a UTC or Intermediate node) to provide synchronized time distribution within the AN node. The AN NTS will be fully integrated into the GIG UTC, Intermediate, and Client Node Network Time Service architecture [per the Network Time Service Profile]. Each AN node will include: An NTS capable of being synchronized with UTC using one of the following as primary and at least one other as secondary: o Network Time Distribution (e.g., Network Time Protocol) – USNO and NIST provide precise (±30 ms) time synchronization services over the network using the Network Time Protocol (NTP). Since NTP uncertainty is heavily based upon network latencies, in reliable, high bandwidth, low latency networks, the uncertainty factor can be reduced to µs or ns precision. o Global Positioning System (GPS) using redundant antennas – GPS is a highly precise (±200 or ±340 ns) method of time synchronization. GPS satellites employ redundant atomic clocks synchronized with USNO to ensure precise timing and availability. The GPS Standard Positioning System (SPS) provides time accuracies to within 340 ns for most nonmilitary applications. The Precise Positioning System (PPS) provides time accuracies to within 200 ns for military applications. o Two-Way Satellite Time Transfer (TWSTT) – TWSTT is the most accurate method of delivering time to a node. A dedicated satellite connection to USNO is established to provide highly precise (±1 ns) synchronization. The ability to synchronize the NTS with the NTS of any peer AN nodes to achieve locally coordinated time. A backup clock providing at least the accuracy of a rubidium clock configured as a failover device in case of a disconnected or degraded state. Within each AN node, time will be distributed to supported network devices and hosts, using the Network Time Protocol. 5.3 Off-Board Transmission Systems As a minimum, the Off-Board Transmission Systems provide the physical and data link layer capabilities used to create the backbone, subnet and network access links of the Airborne Network. Off-Board Transmission Systems components include radios (i.e., RF/optical and modem subsystems), multiplexers, and transmission security (TRANSEC) equipment used for the transport of all information onto and off of the platform. OffBoard Transmission Systems must be capable of interfacing to and interoperating with 76 the AN Equipment system components. As such it must be capable of being managed by the AN Network Management System and Link Management System. Furthermore, the Off-Board Transmission Systems components must be capable of implementing QoS mechanisms that enable the required end-to-end services to be provided when used in conjunction with the AN Equipment. Multiple transmission systems may be implemented on some platforms to accommodate various communications needs. The physical and data link layer capabilities of each of these transmission systems may be very different, each optimized for different needs such as high bandwidth, beyond line of sight connectivity, high mobility, or low probability of detection. However, the Off-Board Transmission Systems must provide a common interface to the AN Equipment network components to enable interoperability between these different systems. Note, some of the network functionality may actually be implemented as part of a transmission system component (e.g., radio or terminal), but the network functions must be separable to accommodate network functions implemented on the platform and to facilitate implementation of different network configurations. Legacy transmission systems will interface to the AN Equipment through gateways as described in section 5.1. Black Side routing and Common MANET services Black Side IP Routing MANET Services Data Link Layer Physical Layer Multiple security domains with Red side routing if necessary HAI PE HAI PE HAI PE HAI PE Other HAI PE Description Coalition Confident ial Red Side TS IP Routing NATO Secret Red Side Secret IP Routing Network Layer Notional JTRS Protocol Stack HAI PE OSI Model Satcom Data Link Legacy or Future Data Link SRW Data Link NDL Data Link WNW Data Link Above 2GHz Legacy or Future PHY SRW NDL WNW Multiple Data Link and Physical Layers for varying environments and communications needs Figure 5-13. Off-Board Transmission Functional Representation 77 6. GIG Integration and Interoperability The future Global Information Grid (GIG) will provide an end-to-end, seamless, internetlike communications capability that meets the mobility, security, and reliability needs of the DoD for mobile and fixed ground-based, air-based, and space-based assets. The communications traffic will be comprised of a combination of voice, video, and data, across multiple security levels using an unclassified (black) transport layer. The GIG transport network will be comprised of a number of component networks, including the Airborne Network, as depicted in Figure 6-1. Each component network will need to pass data both internally among its network members and externally to/from other GIG component networks. Achieving the end-to-end functionality required by the GIG will necessitate that the Airborne Network interface and interoperate with other GIG component networks and with the GIG Enterprise Services (GIG ES). Figure 6-1. Major GIG Component Networks 6.1 GIG Operational Mission Concepts The following GIG operational mission concepts define the target functionality of the integrated GIG transport network which must be provided by the GIG component networks, including the AN. 78 6.1.1 Provide Common Services GIG information, service applications, transport capabilities and management features are focused toward providing the user with the resources needed to successfully complete any mission, anytime, anywhere. This focus is best evident in the shift from the existing centralized Task, Process, Exploit, and Disseminate (TPED) operational concept of providing information from producers to consumers based on a “need-to-know” sharing model to a net-centric Task, Post, Process, and Use (TPPU) “need-to-share” paradigm in which information is posted to the GIG allowing all users of the GIG (and subsequently the AN) to discover and use information. The primary emphasis of TPPU is to get the right information to the user as quickly as possible to impact the decision making process. Users across the enterprise must be able to discover the existence, and location, of needed information, retrieve it in a timely manner, process it as required and post the resulting “value added” product for sharing with the community. 6.1.2 Provide Worldwide Access GIG users will be able to access GIG information and services from anywhere in the world. This includes access from both fixed and mobile locations as well as access in both wired and wireless environments. The GIG will provide ubiquitous login that enables users to identify/authenticate themselves and their current role/context to the network, to GIG services, and for information access from any supported physical location. Once a user has been authenticated and is granted access, the GIG infrastructure will institute and maintain network connectivity, employing a variety of communication and usage modes to provide near real-time access to information and services (e.g., survival information, “task” requests, “post” or “use” services, collaboration via multimedia) at all security levels. Assuring on-demand connectivity, the GIG will be able to dynamically route traffic as needed to achieve mission needs in all environments (i.e., fixed, mobile, wired and wireless connections). 6.1.3 Provide Dynamic Resource Allocation The GIG will support simultaneous, multiple, global missions. The GIG communications and computing resources, while large, are still limited and these resources must be dynamically allocated to provide optimal support to the many varied mission objectives that are constantly evolving and changing in priority. The GIG must have the ability to establish and manage critical characteristics of all resources needed by a GIG user/entity including priority/ precedence level, QoS and CoS levels (e.g., guaranteed or expedited delivery options), and computing resources (e.g., bandwidth, storage, processing). Ensuring efficient and flexible use of GIG resources will require the convergence of voice, data, and video onto a single network. Additionally, the mobile and dynamically changing tactical environment will require users/entities to connect/re-connect to GIG throughout a communication session to react to changes in the communications infrastructure topology. The GIG will need the ability to identify a user/entity as a GIG entity and dynamically establish the user’s device(s) connectivity, resources, and privileges. 79 6.1.4 Provide Dynamic Group Formation GIG information will need to be shared among users/entities with varying levels of privilege and trust in order to carry out specific missions. Communities of Interest (COI) will allow groups of users with common information needs to access, and control access to, the information they need to carry out a specific task. Users and entities will need to be able to be members of multiple COIs under either a periods processing or simultaneous access model (e.g., participating in a U.S.-only COI, a Coalition COI, and a bilateral COI with a Coalition partner nation in execution of a mission). The scope of COI group formation includes dynamic allocation of communications and computing resources as well as dynamic access to enterprise services. COIs may be established and disestablished dynamically, to meet changing missions, or remain fixed to support ongoing tasks. The COI construct is envisioned as the main mechanism for enabling coalition partners to use the GIG as needed, without having their access jeopardize the availability of the GIG. When only small numbers of coalition partners need to participate, GIG identities could be issued to them temporarily. 6.1.5 Provide Computer Network Defense (CND) The GIG will provide a proactive and reactive capability for computer network defense. The GIG will protect, monitor, detect, analyze and adaptively respond to unauthorized system and network activities. Authorized managers and users of the GIG will have the ability (based upon their user profile and privileges) to receive near real-time situational awareness of current threats, configuration, status, and performance of the GIG communications and computing resources. This CND situational awareness will be provided via monitoring of the GIG to obtain sensor data, detection of anomalies within that sensor data, and analysis of those anomalies to provide defensive courses of action. All of these defensive capabilities (i.e., monitoring, detection, and analysis) combine to support CND situational awareness, which enables CND response actions. AN CND situational awareness will be a user defined operational picture (UDOP) of the AN cyberspace at the various organizational levels. Automated situational views will be enabled through user- defined subscription of sensor data, which is combined with appropriate analytical tools that produce awareness, knowledge, and defensive courses of action. 6.1.6 Provide Management and Control of GIG Network and Resources The GIG will support the ability to remotely manage and control all GIG communications, computing resources and services. The common management and control capability of the GIG includes the generation, collection and/or distribution of resource, access, audit, status, performance, fault, configuration, and inventory data to support the auditing/supervisory functions required for network management, security management, and CND operations. It also includes the management and control of the control (signaling) information flowing between GIG communications and computing resources to support end-to-end connectivity, QoS, and prioritization. 80 6.2 GIG Enterprise Services GIG ES will be a suite of value-added information, web, and computing capabilities that will be available to all components, deployed by users across DoD in a consistent manner. This will enable leveraging of best-of-breed concepts and will maximize the net-centric performance of the GIG. When GIG ES is first fielded, the first suite of services that will be offered as part of the core enterprise services (the services that are useful throughout the DoD) will include Enterprise Service Management and IA/Security. All information technology (IT) systems and National Security Systems (NSS) acquired, procured (systems or services), or operated by any DoD component will need access to the Core Enterprise Services. There is no single DoD “net” for a service provider to live within, and it is desirable to offer common core services across all the nets. The networks may require separately hosted solutions for core support. Interface devices such as gateways and guards that span some of these boundaries may also be required. Thus the core services must exist in Operational Area networks (OANs), Metropolitan Area Networks (MANs), and Wide Area Networks (WANs) (both Continental U.S. (CONUS) and Theaters) to include the AN. 6.2.1 Enterprise Service Management/Network Operations Effective operational management of GIG transport systems and their components will in large part depend upon having an infrastructure that has been instrumented with monitoring and reporting capabilities, an in-depth knowledge regarding critical mission processes that the infrastructure must support, an understanding of the relationships between the two, and the ability to present relevant status and associated mission impact assessments to decision makers at all levels. This will necessitate an increased level of information sharing and integration between management operations across different technology, operational, and security domains. GIG transport service providers must take an active role in developing the necessary set of cross-domain operational policies, processes, and procedures, based on internationally accepted common bodies of knowledge needed to enhance the flow of information between different management domains thereby ensuring that problems are proactively detected, isolated and resolved with the minimum impact to the user as well as providing for improved planning and provisioning through better communications of requirements. Enterprise Service Management will provide end-to-end GIG performance monitoring, configuration management and problem detection/resolution, as well as enterprise IT resource accounting and addressing, for example, for users, systems and devices. Additionally, general help desk and emergency support to users is encompassed by this service area, similar to 911 and 411. 6.2.2 Information Assurance/Security 81 The GIG operational mission concepts provide the target functionality for which IA constructs were conceptualized and specified. Seven core IA functions emerged as the foundational enablers for the GIG mission concepts. Each of these constructs, referred to as IA system enablers, are the architectural building blocks for achieving (enabling) one or more of the GIG mission concepts. Full interoperability with the GIG IA Architecture and other, GIG supporting transport networks, requires the AN support the core IA functions: Identification and Authentication Strength of Mechanism is the process of evaluating the strength of user authentication, the assurance of the requesting client and other Information Technology (IT) components, and the risk associated with the user’s operating environment to determine the associated level of trust of the entity. Identity and Authentication (I&A) Strength of Mechanism (SoM) scores enable dynamic access control decisions to be made based on how resistant the authentication of each service request is to impersonation or forgery. Distributed Policy-Based Access Control is used to manage and enforce rule-based access control policies based on real-time assessment of the operational need for access and the security risk associated with granting access. Secure End-to-End Communications Environment as it applies to the AN primarily involves the protection of data in transit and, to a lesser extent, data at rest. Dynamic Policy Management enables the establishment of digital policies for enforcing how assets are managed, utilized, and protected. It allows the flexibility needed to ensure the right asset is available, at the right place, at the right time. Assured Management and Allocation of GIG Resources maintains the integrity and availability of all enterprise resources and ensures that they are available based on operational needs. Enterprise-Wide Network Defense and Situational Awareness consists of enterprise-wide protection, monitoring, detection and analysis that support mission situational awareness and response actions. Assured Management of Enterprise-Wide IA Mechanisms and Assets encompasses the policies, procedures, protocols, standards and infrastructure elements required to reliably support initialization and over-the-network security management (command, control and monitoring) of IA mechanisms and assets. Consequently, the AN will be expected to achieve the requisite level of system security needed to maintain the overall level of GIG enterprise security that enables these mission capabilities. Properly designed and implemented, IA within the GIG will provide the needed availability, integrity, and confidentiality to allow authorized users to access the information they need to carry out their mission while preventing unauthorized users 82 from denying, degrading, or exploiting that mission. AN IA functions will ensure these security services are in place for the GIG supporting, AN air-to-air, air-to-ground, and air-to-space transport infrastructure. 6.3 GIG Transport Convergence GIG transport convergence (i.e., convergence of voice, data, and video onto a single network) will require the phase out all legacy transmission and link-layer technologies over time. In the ideal end-state, all information will be transferred over a secure black core using the Internet Protocol. IP convergence necessitates the development of a comprehensive end-to-end architecture for information transfer that addresses all aspects of the GIG infrastructure (e.g., LANs, WANs, etc). This architecture must ensure consistent voice/video over IP implementations, application modifications to adjust to changing network conditions, and consistent definition and treatment of service level agreements. However, one of the most difficult parts of this architecture will be addressing the performance management of end-to-end flows which transit nodes in the infrastructure with extreme changes in bandwidth, heavy congestion, long latencies, and the inherent difficulties of mobile tactical environments. No technology exists today to achieve end-to-end enforceable and measurable performance in the heterogeneous DoD environment with its many transformational communications networks. Additional details on the DoD IP convergence planning can be found in TBD. 6.4 GIG Routing Architecture TBD 6.5 GIG Quality of Service Architecture The Military Communications Electronics Board (MCEB) has established a GIG End-toEnd QoS Working Group led by the Defense Information Systems Agency (DISA). This working group is preparing recommendations for a phased approach to implementing QoS within the GIG. Figure 6-2 depicts a notional technical approach for realizing endto-end QoS across several network domains. This diagram and the QoS mechanisms listed are not intended to specify a specific framework, but to illustrate the recognized subdivision of the GIG into multiple domains and types of domain, as well as to identify mechanisms of potential utility within each type of domain. 83 BB BB BB CAC CAC SWITCHED LAN CORE/DISTRIBUTION Tactical LAN RSVP, DIFFSERV, 802.X, MPLS DIFFSERV, MPLS RSVP, DIFFSERV, 802.X, MPLS Figure 6-2: End-to-End Strawman Technical Approach for QoS/CoS The working group has also prepared a table of “Proposed DiffServ Flow Classification and Corresponding DiffServ Code Points (DSCPs)/Class Selector Code Point (CSCP) Values” that identify traffic flow classes based upon nature of the flows and military traffic precedence levels within the flow classes. This proposal addresses the DoD enterprise’s need to standardize the methodology for describing IP traffic flow types and precedence levels, as well as, having consistent end-to-end treatment of DSCPs (assured delivery markings). DSCP values need to be preserved through the various networks from source to destination, to ensure the mission commander’s intent is known and can be properly complied with by all networks and systems. Based on current technologies, implementation of an end-to-end QoS/CoS capability will depend upon adherence to the following general guidelines: End-to-end QoS/CoS support requires all network domains to adopt a common QoS/CoS architecture. Service level agreements (SLAs) will likely be needed between domains; however, the existence of SLAs does not eliminate the need for a common QoS/CoS architecture. An end-to-end QoS/CoS architecture must include support at the network layer, allowing traversal of heterogeneous networks providing a commonly understood set of network-layer technologies. The selected QoS/CoS architecture must be applicable to different types of domains ranging from vastly over provisioned, for example GIG-BE, to highly bandwidthlimited, such as mobile, tactical networks. Within individual domains, QoS/CoS support may be provided at the link layer. In these cases, network-layer technologies may utilize that support in order to efficiently accomplish QoS/CoS provision within that domain. A complete, end-to-end QoS architecture must include multiple, complementary mechanisms, such as admission control, traffic shaping, various queue management strategies, and application-layer aspects. 84 Provisions must exist for existence and enforcement of QoS/CoS policy, as well as management of this policy across the GIG enterprise. [Source: DoD Transport Design Guidance Document, Version 0.97] Additional details on the DoD end-to-end QoS/CoS planning can be found in TBD. 6.6 Interface Definition To ensure interoperability, a consistent method to interface with GIG component networks will be defined. This interface definition must describe: Types of communication transport services provided across the interfaces (e.g., MLPP voice, real-time data, etc.) Type of networking relationships that exist between the two networks at the interface (e.g., peer, hierarchical peer, etc.) Traffic security classification levels, security associations and security procedure for both sides of each interface Security related attributes of the two networks (e.g., both networks are red, both networks are black, one network is black and other network is red, or traffic type dependent relationships) Types of routing protocol information and resource availability information needing to be transferred across the interface QoS/CoS features, guarantees, and applicable parameters offered on both sides of the interface Implementation of any Performance Enhancing Proxies (PEPs) Implementation details in terms of the user (or data), control, and management plane protocols, procedures, and exchanges. A good joint interface agreement should be written in accord with the following prescriptions. 1. Provide a ‘network architecture’ picture showing all possible interfaces between two networks (with internal nodes and links depicted with enough detail to put the interface in context). Explicitly identify ‘gateway nodes’ from the perspective of the two networks. Also, identify the connection mechanism between the two gateways. 2. The default assumption is that the interface between the two networks will be at the link level. This means that links connecting gateways in one network with gateways in another network are the ‘physical interfaces’ for carrying user traffic. 3. Describe the types of user information transfer services (data or bearer plane services) provided across the interfaces (there could be more than one in that different traffic types may use different services). 4. Describe the networking relationships exist between networks at this interface. 85 5. Describe assumptions on traffic security classification levels, security associations and security procedure for both sides of each interface. 6. Describe the security related attributes of the two networks (e.g., both networks are red, both networks are black, one network is black and other network is red, or traffic type dependent relationships). Describe where the PlainText (PT)CypherText (CT) boundaries occur, if the two networks have different attributes for traffic segments. 7. Describe the types of routing protocol information and resource availability information needing to be transferred across the interface. 8. Describe Quality of Service (QoS) features offered on both sides of the interface. For packet service, these may include: Differential Services (DiffServe), Integrated Services (IntServe), Resource Reservation Protocol (RSVP), RSVPTraffic Engineering (RSVP-TE), etc. If there is a difference in the offerings in two networks, describe where ‘translation (aggregation, etc.) occurs. Also describe if there is any policing and Call Admission Control (CAC) function in one or both direction. Also describe what happens to traffic above acceptable value by the policing function and to the flows rejected by the CAC function. 9. For packet services, if one or both networks terminates a transport layer protocol (e.g. via Performance Enhancing Proxies), identify the termination and specify any requirements created on the other network. Also, specify if the network with will have a matching termination at the other end. 10. For each of the two networks, specify whether the Multi-Level Precedence and Preemption (MLPP) classification is supported. These include Routine (R), Priority (P), Immediate (I), Flash (F) and Flash Override (FO). Describe how MLPP is activated (indicators, fate of preempted traffic, etc.) and what interactions take place at the interface in relation to this capability. 11. For each network, describe if it can specify and provide QoS guarantees. Also, specify all QoS parameters that can be guaranteed in this fashion. QoS here should be interpreted in a broad sense: data rate, delay, loss, jitter, availability, recovery time, etc. [Source: DoD Transport Design Guidance Document, Version 0.97] 86 7. Airborne Network Model Diagrams (SV-2) Table 7-1 summarizes the key system functionality (described in section 5) that will be required at each network node type. Figures 7-1 through 7-6 depicts this information in an SV-2 graphic for each node. Table 7-1. Summary of Node Types and System Functionality Node Type On-Board Infrastructure Platform Distribution Sensor data buses (as needed) Digital audio & data buses IP-based LANs Legacy AN Equipment Off-Board Transmission None One or more legacy voice/data terminals (e.g., UHF SATCOM terminals, HF/VHF/UHF LOS radios, TDL terminals, CDL terminals, Commercial SATCOM, MILSATCOM terminals) None Several legacy voice/data terminals (e.g., UHF SATCOM terminals, HF/VHF/UHF LOS radios, TDL terminals, CDL terminals, Commercial SATCOM, MILSATCOM terminals) Routing/Switching No AN routing One or more IP-capable voice/data/video terminals (e.g., MUOS SATCOM terminals, TC SATCOM terminals, Commercial SATCOM terminals, Network CDL terminals, Tactical Subnet terminals, Information Assurance TRANSEC Network Management None Gateways Data Link Gateway PEPs Platform Distribution Sensor data buses (as needed) Digital audio & data buses IP-based LANs Relay/ Gateway Information Assurance TRANSEC Network Management None Gateways TDL Gateway Data Link Gateway PEPs Network Access Platform Distribution Sensor data buses (as needed) Digital audio buses IP-based LANs Information Assurance TBD QoS/CoS QoS Application Interface QoS Mechanisms QoS Manager 87 Node Type On-Board Infrastructure AN Equipment Off-Board Transmission Lasercom terminals) Network Management Local Network Management System (for On-Board, AN, and OffBoard network components) NM HMI (e.g., Console) Gateways Legacy Infrastructure Gateway PEPs Information Assurance SM Agent Policy Enforcement HAIPE TRANSEC IDS & Virus Protection Vulnerability Assessment System Firewalls & Guards Link Management LM Agent Network Management Intelligent NM Agent Platform Distribution Sensor data buses (as needed) Digital audio buses IP-based LANs Information Assurance TBD Network Capable Network Management Local Network Management System (for On-Board, AN, and OffBoard network components) NM HMI (e.g., Console) Gateways Legacy Infrastructure Gateway PEPs Network Services Name Resolution Service: Naming Client (name resolver) . Routing/Switching Intra-area Routing QoS/CoS QoS Application Interface QoS Mechanisms QoS Manager Information Assurance SM Agent Policy Enforcement HAIPE TRANSEC IDS & Virus Protection Vulnerability Assessment System Firewalls & Guards Link Management LM Agent LM Autonomous Manager Network Management Cluster Manager Intelligent NM Agent Cluster Policy Decision Point 88 One or more IP-capable voice/data/video terminals (e.g., TC SATCOM terminals, Commercial SATCOM terminals, Network CDL terminals, Tactical Subnet terminals) Node Type On-Board Infrastructure AN Equipment Off-Board Transmission Network Services Name Resolution Service: Local Zone Database and Resource Records, Local Name Server, Naming Client (name resolver) Platform Distribution Sensor data buses (as needed) Digital audio buses IP-based LANs Information Assurance TBD Network Management Local Network Management System (for On-Board, AN, and OffBoard network components and subnet management) NM and Policy Management HMI (e.g., Console) Internetwork Gateways Data Link Gateway Legacy Infrastructure Gateway PEPs Routing/Switching Intra-area & Inter-area Routing QoS/CoS QoS Application Interface QoS Mechanisms QoS Manager Information Assurance Security Manager Policy Distribution, & Enforcement HAIPE TRANSEC IDS & Virus Protection Vulnerability Assessment System Firewalls & Guards Some legacy voice/data terminals (e.g., UHF SATCOM terminals, HF/VHF/UHF LOS radios, CDL terminals) Multiple IP-capable voice/data/video terminals (e.g., MUOS SATCOM terminals, TC SATCOM terminals, Commercial SATCOM terminals, Network CDL terminals, Tactical Subnet terminals, Lasercom terminals) Link Management LM Agent LM Autonomous Manager LM Executive Network Management AN Network Manager Intelligent NM Agent Cluster Manager Policy Server/Repository Policy Decision Point Cluster Policy Decision Point Network Services Name Resolution Service: Local Zone Database and Resource Records, Local Name Server, Naming Client (name resolver) Network Platform Distribution Routing/Switching 89 Some legacy voice/data Node Type Service Provider On-Board Infrastructure Sensor data buses (as needed) Digital audio buses IP-based LANs Information Assurance TBD Network Management Local Network Management System (for On-Board, AN, and OffBoard network components and AN/subnet management) NM and Policy Management HMI (e.g., Console) Ground-based Resource Planning Tools Ground-based Modeling, Analysis, and Simulation Tools Gateways Data Link Gateway Legacy Infrastructure Gateway PEPs AN Equipment Intra-area, Inter-area, & Interdomain Routing QoS/CoS QoS Application Interface QoS Mechanisms QoS Manager Information Assurance Security Manager Policy Input, Distribution, & Enforcement HAIPE TRANSEC KLIF IDS & Virus Protection Vulnerability Assessment System Firewalls & Guards Security M&S Link Management LM Agent LM Autonomous Manager LM Executive Network Management AN Network Manager Policy Server/Repository Policy Decision Point Network Services Name Resolution Service: Gateway to GIG DNS, Local Zone Database and Resource Records, Local Name Server, Naming Client (name resolver) 90 Off-Board Transmission terminals (e.g., UHF SATCOM terminals, HF/VHF/UHF LOS radios, CDL terminals) Multiple IP-capable voice/data/video terminals (e.g., MUOS SATCOM terminals, TC SATCOM terminals, Commercial SATCOM terminals, Network CDL terminals, Tactical Subnet terminals, Lasercom terminals) Figure 7-1. Legacy Node Communications Diagram Figure 7-2. Relay/Gateway Node Communications Diagram 91 Figure 7-3. Network Access Node Communications Diagram Figure 7-4. Network Capable Node Communications Diagram 92 Figure 7-5. Internetwork Node Communications Diagram Figure 7-6. Network Service Provider Node Communications Diagram 93 8. Node and Link Configurations for Candidate Platform Types (SV-5) 8.1 Approach In this section, a notional AN system configuration is presented for several candidate platform types. The notional system configuration should be considered the minimum set of system functionality needed to provide the network capabilities necessary to support the projected (time independent) platform mission operations discussed here. The notional configurations are only intended to depict the needed systems functions and their inter-relationships, which can be used as guidelines for where and when to implement different system functions or technologies. It is not intended to be a network design specifying the exact type, quantities, sizing or placement of system components for specific platforms. This section begins with a notional highly mobile platform with minimal information exchange needs, referred to as an Airborne Fighter platform. The second notional platform is a relatively slow-moving platform with more intensive information exchange needs, referred to as an Airborne C4ISR platform. The third notional platform is a relatively slow-moving airborne platform that supports AN network range extension, internetworking, and gateway functions. This platform is referred to as an Airborne Communications Relay platform. For each notional platform type, a brief operational profile is provided in terms of the operational characteristics that drive the AN implementation and employment. These characteristics include flight patterns, information exchange needs, and any physical constraints imposed by the platform. These drivers are used to determine the needed network capabilities (connectivity, network services and operations), the minimum airborne network functions, links and topologies, and finally the corresponding network node and system functions for each platform in an objective AN. 8.2 Fighter Platform 8.2.1 Operational Profile An airborne fighter platform flight profile includes periods of stable flight patterns and dynamic maneuvers at high speeds. Its relatively small size limits the amount of space available for mounting antennas and installing equipment. It also limits the amount of prime power available to AN equipment and other on-board processing. It will host only one or two crew members, thus its mission applications, sensors, and munitions will be specialized for conducting one or two mission types (e.g., Close Air Support (CAS) or Suppression of Enemy Air Defenses (SEAD)). It will be employed as part of a strike package or combat air patrol (CAP). The strike package or CAP includes groups of two to four airborne fighter platforms up to a total of 200 platforms. The strike package or CAP will have supporting airborne C2 and ISR platform(s), tanker (refueling) platform(s), and ground C2 platform(s). Each airborne 94 fighter platform requires connectivity to all other strike package or CAP and supporting platforms; however, a majority of information will be exchanged between airborne fighter platforms. This is driven in large part because of the need for frequent (e.g., every 2 seconds) situational awareness and target sorting updates (e.g., position location on both friendlies and hostiles) in a highly mobile environment. The second largest information exchange is general background situational awareness exchanges between an airborne fighter platform and airborne C4ISR platform(s). The majority of information is exchanged as real-time (fixed format message) data and voice. Some imagery files and live video feeds may be forwarded to airborne fighter platforms from the supporting platforms. Networked munitions on-board the airborne fighter platform may also be exchanging information. 8.2.2 AN Capabilities, Links, and Topologies Table 8-1 summarizes the network capabilities needed to support the operational profile described in section 8.2.1. Table 8-1. Airborne Fighter Platform AN Capabilities Connectivity Coverage: LOS, potentially BLOS Diversity: 2 or 3 links/2 or 3 waveforms Throughput: Low speed to high speed connections Type of connection: PtPt, Pt-MultPt, Forwarding Network interfaces: Legacy links and tactical subnets Network Capabilities Services Real-time data Voice Interactive data Airborne Fighter Platform 95 Operation Managing: Legacy node: Manual planning, analyzing, monitoring, and controlling of legacy node resources locally. Network node: Monitoring and controlling of network capable node resources locally and from a remote network node, distribute network SA data, match use of resources to operational objectives. Forming and Adapting: Legacy node: Manual provisioning, initialization and restoration of legacy node link resources. Network node: Automated provisioning, initialization and restoration of AN link resources. Accessing: Legacy Node: Link and tactical subnet protection, with limited manual detection and reaction for legacy node resources. Connectivity Network Capabilities Services Operation Network node: Tactical subnet protection, with automated detection and reaction for network capable node resources. The minimum network capabilities needed to support the airborne fighter platform operational profile can be provided by legacy and network capable AN nodes with legacy and subnet links. Airborne fighter platforms will participate in both tethered and flat adhoc network topologies. A tethered topology would primarily be used for reachback and forwarding between the airborne fighter platform and supporting elements. A flat ad-hoc topology would be used between airborne fighter platforms in a strike package or CAP for the more frequent information exchanges. 8.2.3 AN System Configuration Figure 8-1 depicts the minimum system configuration to implement the AN node functions, links, and topologies to support airborne fighter platform operations. Link Management & Network Services Link Manager Name Server Config Mgt Time Server Bus/LAN Interface Sensor Systems HAIPE HF/VHF/UHF Voice Data HAIPE Routing & Security MUOS SATCOM Voice Data Internal External Switch Firewall & Switch External Name Service QoS Manager External Router Intrusion Detection TDL Voice/Data WNW Voice Data Legacy Voice Systems VoIP Gateway Network Management HAIPE AN Network Policy NM Manager Database Decision Point On-Board Networks AN Equipment Figure 8-1. Fighter Platform AN System Configuration 96 Off-Board Transmission 8.2.4 Airborne Fighter Platform AN Issues and Risks TBD 8.3 Airborne C4ISR Platform 8.3.1 Operational Profile This operational profile applies to the mission crew (as opposed to the flight crew) on manned C4ISR platforms. A C4ISR platform flight profile includes periods of enroute flying and repeated, stable flight patterns. The relatively large size enables space available for mounting antennas and installing significant communications equipment to accommodate multiple mission crew functions. It also enables prime power available to AN equipment and other on-board processing. It will host up to three dozen mission crew members, including a communications operator. A C4ISR platform’s mission applications and sensors will support multiple capabilities and mission types. Mission durations for any single aircraft and crew could range up to 12 hours; with aerial refueling it could be extended to 24 hours. C4ISR platforms often operate beyond lineof-sight of ground infrastructure. A C4ISR platform could be employed as a stand-alone or as part of a multiple sensor platform ISR constellation. Some will also be employed as airborne elements of the tactical air control system (AETACS) for support to strike package(s), CAP, etc. (refer to section 8.2.1 for description of fighter aircraft employment). These C4ISR platforms require a broad range of connectivity to simultaneously support ISR and battle management (for AETACS) functions for multiple mission types. In stand-alone and ISR constellation missions, connectivity is primarily used to send/receive tasking and status and to distribute raw and processed (e.g., tracks) sensor data. Air Tasking Order (ATO) updates, theater and national imagery/video and other intel data must be received. The raw sensor data is collected and off-loaded in continuous streams. The volume of information and its distribution is dependent upon the type of sensor data. For example, Air Moving Target Indicator (AMTI) is relatively low volume, but is distributed to a comparatively greater number of platforms (including airborne and ground) than Ground Moving Target Indicator (GMTI) and Synthetic Aperture Radar (SAR) and other types of sensor data. The larger volumes of data are offloaded to one or more ground stations (up to 30), which may be located in theater (LOS or BLOS of platform operation) or in CONUS (reachback connectivity from platform). This data is offloaded in real time (as it is collected), and can include video. As more processing capability is fielded in airborne platforms to enable collaborative targeting, some of this large volume data may also be provided to other airborne C4ISR platforms. For battle management functions, the C4ISR platform requires connectivity to all strike package or CAP aircraft and supporting (ground and airborne) platforms; however, a majority of information will be exchanged with the other airborne ISR and strike package 97 or CAP platforms. This is driven in large part because of the need for frequent (e.g., every 2 seconds) situational awareness updates (e.g., position location) in a highly mobile environment. The second largest information exchange is command and control information between the C4ISR platform and the ground tactical air control system (GTACS) elements, including the Air and Space Operations Center (AOC). The C4ISR platform forwards information between networks and COIs involved in multiple mission types. The majority of information is exchanged as real-time (fixed format message) data, interactive data (files), and voice. Some imagery files may be forwarded between C4ISR platforms, GTACS elements, and strike package or CAP aircraft. 8.3.2 AN Capabilities, Links, and Topologies Table 8-2 summarizes the network capabilities needed to support the operational profile described in section 8.3.1. Table 8-2. C4ISR Platform AN Capabilities Connectivity Coverage: LOS and BLOS Diversity: >10 links/ waveforms Throughput: Low speed to high speed connections Type of connection: PtPt, Pt-MultPt, Forwarding Network interfaces: Legacy links, tactical subnets, GIG Network Capabilities Services Real-time data Voice Interactive data Video Bulk transfer C4ISR Platform 98 Operation Managing: Legacy node: Manual planning, analyzing, monitoring, and controlling of legacy node resources locally. Network node: Monitoring and controlling of network capable node resources locally and from a remote network node, distribute network SA data, match use of resources to operational objectives. Forming and Adapting: Legacy node: Manual provisioning, initialization and restoration of legacy node link resources. Network node: Automated provisioning, initialization and restoration of AN link resources. Accessing: Legacy node: Link and tactical subnet protection, with limited manual detection and reaction for legacy node resources. Connectivity Network Capabilities Services Operation Network node: Tactical subnet protection, with automated detection and reaction for network capable node resources. The minimum network capabilities needed to support the C4ISR platform operational profile can be provided by legacy and internetwork AN nodes with network access, subnet and legacy links. C4ISR platforms will participate in both tethered and tiered adhoc network topologies. A tethered topology would primarily be used for reachback and forwarding between the C4ISR platform, GTACS, and strike package or CAP aircraft. A tiered ad-hoc topology would be used between the C4ISR platform and airborne fighter platforms in a strike package or CAP. Some operational concepts for collaborative targeting may also require airborne backbone links and topologies for timely distribution of high volume sensor data between C4ISR platforms. An airborne backbone could also be used in an extended theater to provide reachback capabilities between strike package, CAP aircraft, and GTACS elements. 8.3.3 AN System Configuration Figure 8-2 depicts the minimum system configuration to implement the AN node functions, links, and topologies to support C4ISR platform operations. 99 Bus/LAN Interface Sensor Systems HAIPE Link Management & Network Services Link Manager HAIPE Network, Policy, Security, QoS Mgt Servers Name,Time, Config Mgt Servers Apps & Transport Proxies Mission Servers, OWS, Voice & Video Name Server Config Mgt Time Server HF/VHF/UHF Voice Data TDL Gateway High Assurance Guard MUOS SATCOM Voice Data TDL Voice/Data HAIPE Routing & Security Classified Users CDL Voice Data Internal External Switch Firewall & Switch External Name Service QoS Manager Network, Policy, Security, QoS Mgt Servers External Router Intrusion Detection Com’l SATCOM Voice Data Name,Time, Config Mgt Servers Apps & Transport Proxies TCM SATCOM Voice Data HAIPE Network Management Mission Servers, OWS, Voice & Video Unclassified Users AN Network NM Policy Policy Manager Database Server Decision Point High Assurance Guard WNW Voice Data Lasercom Voice Data Legacy Voice Systems VoIP Gateway HAIPE On-Board Networks AN Equipment Off-Board Transmission Figure 8-2. C4ISR Platform AN System Configuration 8.3.4 C4ISR Platform AN Issues and Risks TBD 8.4 Airborne Communications Relay Platform 8.4.1 Operational Profile This operational profile applies to airborne communications relay functions onboard a widebody platform or a UAV that may or may not be dedicated to the communications relay function. Airborne communications relay platform flight profile includes periods of enroute flying and repeated, stable flight patterns. The relatively large size of widebodies theoretically enables space available for mounting antennas and installing significant communications equipment; however this may be limited by the primary mission function for the platform (e.g., C4ISR). UAVs offer long endurance and high altitude, which give wide area air and surface coverage and good optical paths to satellites. Mission durations for any single aircraft and crew could range up to 12 hours or more for widebodies and longer for UAVs. Airborne communications relay platforms could 100 operate within line-of-sight or beyond line-of-sight of ground infrastructure. They may or may not have a communications operator on-board. The mission of an airborne communications relay platform is to be employed as part of and/or support to C4ISR constellation and/or strike package(s) or CAP. The communications relay platform provides connectivity between elements of a strike package, CAP aircraft, C4ISR platforms, and GTACS platforms that require range extension or internetworking and gateway functions between networks for information interoperability. For platforms that are beyond line of sight of ground infrastructure (and have no space infrastructure connection) the communications relay platform provides critical connectivity for C2 and situational awareness. The airborne communications relay platform must support all information exchange types and characteristics used within a theater. 8.4.2 AN Capabilities, Links, and Topologies Table 8-3 summarizes the network capabilities needed to support the operational profile described in section 8.4.1. Table 8-3. Airborne Communications Relay Platform AN Capabilities Connectivity Coverage: LOS and BLOS Diversity: >10 links/ waveforms Throughput: Low speed to high speed connections Type of connection: PtPt, Pt-MultPt, Forwarding Network interfaces: Legacy links, tactical subnets, GIG Network Capabilities Services Real-time data Voice Interactive data Video Bulk transfer Airborne Communica tions Relay Platform 101 Operation Managing: Legacy node: Manual planning, analyzing, monitoring, and controlling of legacy node resources locally. Network node: Monitoring and controlling of network capable node resources locally and from a remote network node, distribute network SA data, match use of resources to operational objectives. Forming and Adapting: Legacy node: Manual provisioning, initialization and restoration of legacy node link resources. Network node: Automated provisioning, initialization and restoration of AN link resources. Accessing: Legacy node: Link and tactical subnet protection, Connectivity Network Capabilities Services Operation with limited manual detection and reaction for legacy node resources. Network node: Tactical subnet protection, with automated detection and reaction for network capable node resources. The minimum network capabilities needed to support the airborne communications relay platform operational profile can be provided by legacy and internetwork AN nodes with network access, subnet and legacy links. Airborne communications relay platforms will participate in both tethered and tiered ad-hoc network topologies. A tethered topology would primarily be used for reachback and forwarding between the C4ISR platform, GTACS, and strike package or CAP aircraft. A tiered ad-hoc topology would be used between the C4ISR platform and airborne fighter platforms in a strike package or CAP. Some operational concepts for collaborative targeting may also require airborne backbone links and topologies for timely distribution of high volume sensor data between C4ISR platforms. An airborne backbone could also be used in an extended theater to provide reachback capabilities between strike package or CAP and GTACS elements. 8.4.3 AN System Configuration Figure 8-3 depicts the the minimum system configuration to implement the AN node functions, links, and topologies to support airborne communications relay platform operations. 102 Link Management & Network Services Link Manager Name Server Config Mgt Time Server HF/VHF/UHF Voice Data MUOS SATCOM Voice Data TDL Voice/Data Routing & Security CDL Voice Data Legacy Voice Systems VoIP Gateway HAIPE Internal External Switch Firewall & Switch External Name Service QoS Manager External Router Intrusion Detection Com’l SATCOM Voice Data TCM SATCOM Voice Data Network Management AN Network NM Policy Policy Manager Database Server Decision Point WNW Voice Data Lasercom Voice Data On-Board Networks AN Equipment Off-Board Transmission Figure 8-3. Airborne Communications Relay Platform AN System Configuration 8.4.4 Airborne Communications Relay Platform AN Issues and Risks TBD 103 9. 9.1 Recommended Network Standards Current Standards (TV-1) Table 9-1 includes a list of the key technical standards that should be used in near-term and interim AN implementations to provide the AN functionality defined herein. This list is not all inclusive and many of the standards only provide a subset of the desired functionality. See section 9.2 for potential emerging standards that provide more of the desired functionality and section 9.3 for a list of areas for which widely accepted standards do not yet exist. Standards that are included in the Department of Defense (DoD) Information Technology Standards Registry (DISR) are noted. Table 9-1. Applicable Technical Standards Standards Area Connectivity Description/Discussion Applicable Standards Routing Open Shortest Path First (OSPF) RFC 1584 (Multicast Extensions to OSPF) (DISR) - RFC 2328/ IETF Standard 54 (OSPF Version 2) (DISR) - RFC 2740 (OSPF for IPv6) RFC 3630 (Traffic Engineering Extensions to OSPF v2) Border Gateway Protocol (BGP) (DISR) - RFC 1771, (Border Gateway Protocol 4 (BGP-4) RFC 1997 (BGP Communities) RFC 2439 (Route Flap Dampening) (DISR) - RFC 2545 (Extensions for IPv6 Inter-Domain Routing) RFC 2796 (Route Reflection) (DISR) - RFC 2858 (Multiprotocol Extensions) RFC 2918 (Route Refresh Capability) RFC 3065 (AS Confederations) RFC 3107 (Label Information) RFC 3392 (Capabilities Advertisement) Intermediate System to Intermediate System (IS-IS) RFC 1142 (IS-IS Intra-Domain Routing Protocol) RFC 1195 (IS-IS in TCP/IP Environments) Quality of Service Differentiated Services (DiffServ) DiffServ: (DISR) - RFC 2474 (DiffServ Field) 104 Standards Area Description/Discussion Applicable Standards RFC 2475 (DiffServ Arch) RFC 2597 (AF PHB) RFC 2638 (Bandwidth Broker for Diffserv Arch) RFC 3086 (Per Domain Behaviors) RFC 3140 (PHB Coding) RFC 3246 (EF PHB) Multi-Protocol Label Switching (MPLS) MPLS: (DISR) - RFC 2702 (Requirements for Traffic Engineering over MPLS) (DISR)-RFC 2917 (Core MPLS IP VPN Arch) (DISR) - RFCs 3031 (MPLS-Arch), RFC 3032 (MPLS LSR Encoding) RFC 3209 (RSVP-TE for MPLS LSPs) RFC 3477 ((RSVP-TE for MPLS LSPs – Unnumbered Links) DiffServ & MPLS: RFC 3270 (MPLS-DS, with Mapping Guide) Integrated Services (IntServ) IntServ: (DISR) - RFC 2205 (RSVP) (DISR) - RFC 2207 (RSVP Extensions for IPSec) RFC 2209 (rsvp Message Processing Rules) (DISR) - RFC 2210 (RSVP and IntServ) RFC 2211 (Controlled Load Service), RFC 2212 (Guaranteed Service) RFC 2215 (Characterization Parameters) RFC 2688 (IntServ over Low Speed Networks) RFC 2746 (RSVP over IP Tunnels) RFC 2815 (IntServ over IEEE 802 Networks) RFC 2961 (RSVP Overhead Reduction) (DISR) - RFC 3175 (Aggregate RSVP) 105 Standards Area Description/Discussion Applicable Standards IntServ & DiffServ: RFC 2996 (RSVP DCLASS Object) RFC 2297 (RSVP Null Service Type) RFC 2998 (Framework IntServ over DiffServ) Admission Control and Policy RFC 2750 (RSVP Extensions for Admission Control) RFC 2753 (Framework for Policy-based Admission Control) RFC 2814 (RSVP-Based Admission Control over IEEE 802 Networks) RFC 3644 (Policy QoS Information Model) Information Assurance DoD IA DoD IA Policy Framework 8500 - General DoDD 8500.1, "Information Assurance (IA)," 10/24/2002 DoDI 8500.2, "Information Assurance (IA) Implementation," 02/06/2003 8510 - Certification and Accreditation 8520 - Security Management (SMI, PKI, KMI, EKMS) DoDD 8520.1, "Protection of Sensitive Compartmented Information (SCI)," 12/20/2001 DoDI 8520.2, "Public Key Infrastructure (PKI) and Public Key (PK) Enabling," 04/01/2004 8530 - Computer Network Defense /Vulnerability Mgt DoDD O-8530.1 “Computer Network Defense (CND),” 01/08/01 DoDI O-8530.2 “Support to Computer Network Defense (CND),” 03/09/01 8540 - Interconnectivity/Multi-Level Security (SABI) 8550 - Network/Web (Access, Content, Privileges) 106 Standards Area Description/Discussion Applicable Standards DoDI 8551.1, "Ports, Protocols, and Services Management (PPSM)," 08/13/2004 8560 - Assessments (Red Team, TEMPEST Testing & Monitoring) 8570 - Education, Training, Awareness DoDD 8570.1, "Information Assurance Training, Certification, and Workforce Management," 08/15/04 8580 - Other (Mobile Code, IA OT&E, IA in Acquisition) DoDI 8580.1, "Information Assurance (IA) in the Defense Acquisition System," 07/09/2004 Network Layer Security IPSec (DISR) - RFC2401 (Security Architecture for the Internet Protocol) (DISR) - RFC2402 (IP Authentication Header) (DISR) - RFC2406 (IP Encapsulating Security Payload (ESP)) ASWR Respons Authentication/ DoDD 8500.1, DoDI 8500.2 US DOD CP: “X.509 Certificate Policy (CP) for the U.S. Department of Defense (DOD)”, Version 5.0, 1 December 1999 DoD Certificate Policy Identification RFC 2560 (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol –OCSP) Online Certificate Status Protocol X.509 RFC2510 (Internet X.509 Public Key Infrastructure Certificate Management Protocols) RFC2511 (Internet X.509 Certificate Request Message Format) RFC2585 (Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP) RFC2587 (Internet X.509 Public Key Infrastructure LDAPv2 Schema) RFC3161 (Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)) RFC3279 (Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure 107 Standards Area Description/Discussion Applicable Standards Certificate and Certificate Revocation List (CRL) Profile) RFC3280 (Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile) Security Policy Management Data Encryption Key Distribution DoD Directive 8500 DoDD 8500.1, DoDI 8500.2 SNMPv3 RFC 3414 (User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)) IPSec RFC3585 (IPsec Configuration Policy Information Model) HAPIS NSA HAIPIS Version 2, May 2004 DoD Directive 8500 DoDD 8500.1, DoDI 8500.2 Internet Key Exchange RFC2409 (The Internet Key Exchange (IKE)) Public-Key Cryptography Standards (DISR) - RFC2315 (PKCS #7: Cryptographic Message Syntax Version 1.5) RFC2898 (PKCS #5: Password-Based Cryptography Specification Version 2.0) RFC2985 (PKCS #9: Selected Object Classes and Attribute Types Version 2.0) RFC2986 (PKCS #10: Certification Request Syntax Specification Version 1.7) RFC3447 (Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1) RFC3207 (SMTP Service Extension for Secure SMTP over Transport Layer Security) Secure Socket Layer (DISR) - Draft-freier-ssl-version3-01 Transport Layer Security (DISR) - RFC2246 (The TLS Protocol Version 1.0) RFC2595 (Using TLS with IMAP, POP3 and ACAP) RFC2712 (Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)) RFC2830 (Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security) 108 Standards Area Description/Discussion Applicable Standards RFC3268 (Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)) RFC3436 (Transport Layer Security over Stream Control Transmission Protocol) RFC3546 (Transport Layer Security (TLS) Extensions) (DISR) - RFC2408 (Internet Security Association and Key Management Protocol (ISAKMP)) IPSec DoD Directive 8500 Secure Directory DoDD 8500.1, DoDI 8500.2 LDAP RFC2649 (An LDAP Control and Schema for Holding Operation Signatures) RFC2829 (Authentication Methods for LDAP) RFC3062 (LDAP Password Modify Extended Operation) RFC3112 (LDAP Authentication Password Schema) Secure Domain Name Services DNS (DISR) - RFC2535 (Domain Name System Security Extensions) RFC3645 (Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG)) Network Management Common Management Protocol IETF Standard 62: RFC3411 (Architecture for SNMP Management Frameworks) RFC 3412 (Message Processing & Dispatching for SNMP) RFC 3413 (SNMP Applications) RFC 3414 (User-Based Security Model for SNMPv3) RFC 3415 (View-Based Access Control Model for SNMP) RFC 3416 (Version 2 of the Protocol Operations for SNMP) RFC 3417 (Transport Mappings for SNMP) RFC 3418 (MIB for SNMP) Common Structure of Management Information (SMI) Provides a common structure and format rules for representing management information; SMIv1 and SMIv2 109 (DISR) IETF Standard 16: RFC 1155 (Structure and Identification of management information for TCP/IP-based Standards Area Description/Discussion Applicable Standards internets) RFC 1212 (Concise MIB definitions) IETF Standard 58: RFC 2578 (Structure of Management Information Version 2 (SMIv2)) RFC 2579 (Textual Conventions for SMIv2) RFC 2580 (Conformance Statements for SMIv2) Management Information Base General (DISR) IETF Standard 17: RFC 1213 (Management Information Base for Network Management of TCP/IP-based internets:MIB-II) The following 3 RFCs update RFC 1213: (DISR) RFC 2011 (SNMPv2 Management Information Base for the Internet Protocol using SMIv2) (DISR) RFC 2012 (SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2) (DISR) RFC 2013 (SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2) (DISR) IETF Standard 59: RFC 2819 (Remote Network Monitoring Management Information Base) (DISR) RFC 1657 (Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2) Other MIBs RFC 1724 (RIP Version 2 MIB Extension) (DISR) RFC 1850 (OSPF Version 2 Management Information Base) (DISR) RFC 2021 (Remote Network Monitoring Management Information Base Version 2 using SMIv2) RFC 2096 (IP Forwarding Table MIB) RFC 2206 (RSVP Management Information Base using SMIv2) RFC 2213 (Integrated Services Management Information Base using SMIv2) RFC 2214 (Integrated Services Management Information Base using SMIv2) 110 Standards Area Description/Discussion Applicable Standards RFC 2564 (Application Management MIB) (DISR) RFC 2605 (Directory Server Monitoring MIB) RFC 2667 (IP Tunnel MIB) RFC 2720 (Traffic Flow Measurement: Meter MIB) (DISR) RFC 2788 (Network Services Monitoring MIB) (DISR) RFC 2790 (Host Resources MIB) RFC 2922 (Physical Topology MIB) RFC 2932 (IPv4 Multicast Routing MIB) RFC 2933 (Internet Group Management Protocol MIB) RFC 2959 (Real-Time Transport Protocol Management Information Base) RFC 3273 (Remote Network Monitoring Management Information Base for High Capacity Networks) RFC 3287 (Remote Monitoring MIB Extensions for Differentiated Services) RFC 3289 (Management Information Base for the Differentiated Services Architecture) RFC 3559 (Multicast Address Allocation MIB) Link Management Location Management (DISR) RFC3261 (SIP: Session Initiation Protocol) RFC3265 (Session Initiation Protocol (SIP)Specific Event Notification) Registration RFC3326 (The Reason Header Field for the Session Initiation Protocol (SIP)) RFC3327 (Session Initiation Protocol (SIP) Extension Header Field for Registering NonAdjacent Contacts) RFC3608 (Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration) IETF Best Current Practice (BCP)0075, RFC3665 (Session Initiation Protocol (SIP) Basic Call Flow Examples) ITU-T G.7714/Y.1705 (Generalized automatic discovery techniques), November 2001 ITU-T G.7714.1/Y.1705.1 (Protocol for Service, Node and Path Discovery 111 Standards Area Description/Discussion Applicable Standards automatic discovery in SDH and OTN networks), April 2003 (DISR) RFC2461 (Neighbor Discovery for IP Version 6 (IPv6)) RFC3379 (Delegated Path Validation and Delegated Path Discovery Protocol Requirements) RFC3674 (Feature Discovery in Lightweight Directory Access Protocol (LDAP)) Network Services Name Resolution Service (DISR) - IETF Standard 13 Domain Name System (RFC 1034/RFC 1035) Configuration Management RFC 951, Bootstrap Protocol (BOOTSP) Network Time (DISR) - RFC 2131, Dynamic Host Configuration Protocol RFC 3396 (Update of RFC 2131) (DISR) - RFC 1305 Network Time Protocol (Version 3) Network Time Protocol 112 9.2 Emerging Standards (TV-2) Table 9-2. Applicable Emerging Technical Standards Standards Area Connectivity Description/Discussion Applicable Standards Routing OSPF Draft-ietf-ospf-scalability-08 (Prioritized Treatment of OSPF Packets) Draft-ietf-ospf-cap-03 (Advertising Optional Router Capabilities), July 2004 Draft-ietf-isis-wg-multi-topology-07 (Multi-topology Routing), June 2004 IS-IS RFC 3784 (IS-IS Extensions for Traffic Engineering), June 2004 RFC 3787 (Recommendations for Networks Using IS-IS) Mobile Ad Hoc Routing RFC 3561 (AODV Protocol) RFC 3626 (OLSR Protocol) draft-chandra-ospf-manet-ext-01 (OSPF Extensions), July 2004 draft-ietf-manet-dsr-10 (The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks), July 2004 draft-spagnolo-manet-ospf-wirelessinterface-01 (OSPFv2 Wireless Interface Type), May 2004 draft-spagnolo-manet-ospf-design (Design Considerations for a Wireless OSPF Interface), April 2004 draft-jeong-manet-maodv6-00 (Multicast Ad hoc On-Demand Distance Vector Routing for IP version 6), July 2004 Quality of Service DiffServ and IntServ RFC 3670 (Model for QoS Datapath Mechanisms), January 2004 RFC 3754 (Multicast for DiffServ), April 2004 ID draft-baker-diffserv-basic-classes-03 (DSCP<=> PHB Mapping Guide), July 2004 QoS and Signaling IETF Next Steps in Signaling 113 Standards Area Description/Discussion Applicable Standards WG The Next Steps in Signaling (NSIS) working group is considering protocols for signaling information about a data flow along its path in the network. RFC 3726 (Requirements for Signaling Protocols), April 2004 draft-ietf-nsis-fw-06 (Next Steps in Signaling: Framework), July 2004 draft-ash-nsis-nslp-qspec-01 (QoS-NSLP QSpec Template), July 2004 draft-tschofenig-nsis-qos-ext-authz-00 (Extended QoS Authorization for the QoS NSLP), July 2004 draft-ietf-nsis-qos-nslp-04 (NSLP for Quality-of-Service signaling), July 2004 QoS and Routing Framework RFC 2386 (Framework for QoS Routing), August 1998 QoS Routing Mechanisms and OSPF Extensions describes extensions to the OSPF protocol to support QoS routes. QoS and Measurement RFC 2676 (QoS Routing), August 1999 RFC 2330 (Framework for IP Performance Metrics) RFC 3432 (Network performance measurement with periodic streams) Information Assurance DoD IA DoD IA Policy Framework 8510 - Certification and Accreditation DoDD 8510.aa “DoD C&A” DoD 8510.1-M “DITSCAP DoDI 8510.bb “DITSCAP Implementation” 8520 - Security Management (SMI, PKI, KMI, EKMS) DoDI 8520.cc “Communications Security” (COMSEC)” 8530 - Computer Network Defense /Vulnerability Mgt DoDI O-8530.cc “DoD Vulnerability Management” 114 Standards Area Description/Discussion Applicable Standards 8540 - Interconnectivity/Multi-Level Security (SABI) DoDI 8540.aa “Interconnection & Data Transfer Between Security Domains” 8550 - Network/Web (Access, Content, Privileges) DoDD 8550.aa “Web Site Administration” DoD 8550.bb-G “Firewall Configuration” DoDI 8550.dd “DoD Biometrics” 8560 - Assessments (Red Team, TEMPEST Testing & Monitoring) DoDD 8560.aa “Information Assurance Monitoring and Readiness Testing of DoD Telecommunications and Information Systems” Authentication/ X.509 RFC3709 (Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates), February 2004 Identification RFC3739 (Internet X.509 Public Key Infrastructure: Qualified Certificates Profile), March 2004 FC3779 (X.509 Extensions for IP Addresses and AS Identifiers), June 2004 RFC3850 (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling), July 2004 Key Distribution IKE RFC3664 (The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)), January 2004 RFC3706 (A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers), February 2004 RFC3734 (Extensible Provisioning Protocol (EPP) Transport Over TCP), March 2004 TLS RFC3749 (Transport Layer Security Protocol Compression Methods), May 2004 Secure Mobility IPSec RFC3776 (Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents), June 2004 Secure Directory LDAP RFC3829 (Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and Response Controls), July 2004 Network Management 115 Standards Area Description/Discussion Common Structure of Management Information (SMI) Management Information Base Applicable Standards RFC 3780 (SMIng-Next Generation SMI), May 2004 RFC 3781 (SMIng-Mappings to SNMP), May 2004 IPv6 MIBs (DISR) RFC 2452 (IP Version 6 Management Information Base for the Transmission Control Protocol), December 1998 (DISR) RFC 2454 (IP Version 6 Management Information Base for the User Datagram Protocol), December 1998 RFC 2465 (Management Information Base for IP Version 6: Textual Conventions and General Group), December 1998 (DISR) RFC 2466 (Management Information Base for IP Version 6: ICMPv6 Group), December 1998 RFC 3595 (Textual Conventions for IPv6 Flow Label), September 2003 RFC 2940 (Definitions of Managed Objects for COPS Protocol Clients), October 2000 Other MIBs RFC 3747 (The Differentiated Services Configuration MIB), April 2004 RFC3812 (MPLS Traffic Engineering (TE) MIB), June 2004 RFC 3813 (MPLS Label Switching Router (LSR) MIB), June 2004 RFC 3814 (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) MIB), June 2004 RFC 3816 (Definitions of Managed Objects for RObust Header Compression (ROHC)), June 2004 RFC3873 (Stream Control Transmission Protocol (SCTP) Management Information Base (MIB)), September 2004 Policy-Based Network Management Common Policy Protocol RFC 2748 (COPS), January 2000 RFC 3084 (COPS Usage for Policy Provisioning, COPS-PR), March 2001 Common Structure of Policy Provisioning Information (SPPI) RFC 3159 (Structure of Policy Provisioning Information, SPPI), August 2001 Policy Information Schema and Models RFC 3060 (Policy Core Information Model Specification – Version 1), February 2001 116 Standards Area Description/Discussion Applicable Standards RFC 3460 (Policy Core Information Model Extensions), January 2003 RFC 3585 (IPsec Configuration Policy Information Model), August 2003 RFC 3644 (Policy QoS Information Model), November 2003 RFC 3670 (Information Model for Describing Network Device QoS Datapath Mechanisms), January 2004 RFC 3317 (Differentiated Services Quality of Service Policy Information Base), March 2003 Policy Information Base RFC 3318 (Framework Policy Information Base), March 2003 RFC 3571 (Framework Policy Information Base for Usage Feedback), August 2003 draft-ietf-ipsp-ipsecpib-10 (IPSec Policy Information Base), April 2004 Link Management Handoff Across Heterogeneous Links Manage mobile nodes including fast handoff for highly dynamic wireless networks and efficient location update for highly mobile nodes Dynamic Mobility Agents (DMA) Protocol, AMPS Protocol Design Document, CECOM MOSAIC Project, Contract DAAB07-01-C-L534, May 19, 2002 Domain Announcement Protocol (DAP) Location Management RFC3680 (A Session Initiation Protocol (SIP) Event Package for Registrations), March 2004 RFC3825 (Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information), July 2004 Registration Establish and Maintain Channels RFC3840 (Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)), August 2004 Signaling to establish, maintain and recover paths; determination of route and properties of a path; link or node removal from network Draft-ietf-ccamp-lmp-10 (Link Management Protocol (LMP)), October 2003 Draft-ietf-ccamp-gmpls-g709-07 (Generalized MPLS Signalling Extensions for G.709 Optical Transport Networks Control), March 2004 Draft-ietf-ccamp-gmpls-recoveryfunctional-02 (Generalized MPLS Recovery Functional Specification), April 2004 117 Standards Area Description/Discussion Applicable Standards Draft-ietf-ccamp-gmpls-segment-recovery00 (GMPLS Based Segment Recovery), April 2004 Draft-ietf-ccamp-gmpls-recovery-analysis03 (Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-basedRecovery Mechanisms (including Protection and Restoration)), April 2004 Draft-ietf-ccamp-gmpls-recovery-e2esignaling-01 (RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery), May 2004 Draft-ali-ccamp-mpls-graceful-shutdown00 (Graceful Shutdown in MPLS Traffic Engineering Networks), June 2004 Draft-rabbat-fault-notification-protocol-05 (Fault Notification Protocol for GMPLSBased Recovery), June 2004 Draft-vasseur-ccamp-te-router-info-00 (Routing extensions for discovery of TE router information), July 2004 Draft-huang-gmpls-recovery-resourcesharing-00 (Generalized MPLS Recovery Resource Sharing), July 2004 Topology Topology Dissemination RFC 3684 (Topology Dissemination – Reverse Path Forwarding), February 2004 Dynamic Topology Changes Draft-xushao-ipo-mplsovergmpls-02 (Requirements for MPLS over GMPLSbased Optical Networks (MPLS over GMPLS), May 2004 Service, Node and Path Discovery RFC3810 (Multicast Listener Discovery Version 2 (MLDv2) for IPv6), June 2004 RFC3832 (Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV), July 2004 Draft-daigle-snaptr-01 (Domain-based Application Service Location Using SRV RRs and the DynamicDelegation Discovery Service (DDDS)), June 2004 Draft-daniel-manet-dns-discoveryglobalv6-00 (DNS Discovery for global connectivity in IPv6 Mobile Ad Hoc Networks), March 2004 Draft-ietf-ipv6-2461bis-00 (Neighbor Discovery for IP version 6 (IPv6)), July 2004 Draft-ietf-eap-netsel-problem-01 (Network Discovery and Selection Problem), July 118 Standards Area Description/Discussion Applicable Standards 2004 Network Services Name Resolution Service RFC 3363 (IPv6 Address Representation in DNS), August 2002 (DISR)- RFC 3596 (DNS Extensions to Support IPv6), October 2003 draft-daniel-manet-dns-discovery-globalv600 (DNS Discovery for global connectivity in IPv6 Mobile Ad Hoc Networks), March 2004 Configuration Management RFC 3646 (DHCP for IPv6), December 2003 RFC 3736 (Stateless DHCP for IPv6), April 2004 RFC 3825 (DHCP Option for LocationBased Configuration), July 2004 Automatic Configuration and Reconfiguration Distribute network configuration information (e.g., IP addresses, DNS server) within a subnetwork; update configuration database Dynamic Registration and Configuration Protocol (DRCP), AMPS Protocol Design Document, CECOM Multifunctional Onthe-move Secure Adaptive Integrated Communications (MOSAIC) Project, Contract DAAB07-01-C-L534, May 19, 2002 Draft-boucadair-netconf-req-00 (Requirements for Efficient and Automated Configuration Management), July 2004 Draft-ietf-netconf-prot-03 (NETCONF Configuration Protocol), June 2004 draft-jelger-manet-gateway-autoconf-v6-02 (Gateway and address autoconfiguration for IPv6 adhoc networks), April 2004 draft-jeong-manet-addr-autoconf-reqts-02 (Requirements for Ad Hoc IP Address Autoconfiguration), July 2004 Distribute network configuration information to subnetworks Dynamic Configuration Distribution Protocol (DCDP), AMPS Protocol Design Document, CECOM MOSAIC Project, Contract DAAB07-01-C-L534, May 19, 2002 Collect node configuration and capability information Configuration Database Update Protocol (YAP), AMPS Protocol Design Document, CECOM MOSAIC Project, Contract DAAB07-01-C-L534, May 19, 2002 Select nodes to perform link management and network services functions Adaptive Configuration Manager (ACM) , AMPS Protocol Design Document, CECOM MOSAIC Project, Contract DAAB07-01-C-L534, May 19, 2002 119 Standards Area Description/Discussion Applicable Standards Adaptive Configuration Agent (ACA), AMPS Protocol Design Document, CECOM MOSAIC Project, Contract DAAB07-01-C-L534, May 19, 2002 Network Time 9.3 Areas for Further Development Table 9-3. AN Technical Standards Gaps Standards Area Connectivity Description/Discussion Status Routing Protocol for Heterogeneous (Wired and Wireless) Environments By extending and building off a wired routing protocol framework, the probability of successful transition and interoperability within heterogeneous (fixed wired and ad hoc wireless) networks may be greatly improved. Several draft RFCs have been prepared that describe potential wireless extension to OSPF Mobile Ad Hoc Routing There is extensive work on mobile ad hoc routing (shown in rightmost column) for which there are no immediate standardization plans. draft-ietf-manet-odmrp-04 (On-Demand Multicast Routing Protocol; Draft Expiredno subsequent RFC) draft-ietf-manet-maodv-00 (Multicast AODV Protocol; Draft Expired; no subsequent RFC) draft-ietf-manet-rdmar-00 (Relative Distance Micro-discovery Ad Hoc Routing Protocol); Draft Expired; no subsequent RFC) draft-ietf-manet-tora-spec-04 (TemporallyOrdered Routing Algorithm (TORA) Version 1; Draft Expired; no subsequent RFC) draft-ietf-manet-zone-zrp-04 (The Zone Routing Protocol (ZRP) for Ad Hoc Networks; Draft Expired; no subsequent RFC) draft-ietf-manet-star-00 (Source Tree Adaptive Routing (STAR) Protocol; Draft Expired; no subsequent RFC) draft-ietf-manet-admr-00 (The Adaptive Demand-Driven Multicast Routing Protocol for Mobile Ad Hoc Networks; Draft Expired; no subsequent RFC) draft-ietf-manet-cedar-spec-00 (Core 120 Standards Area Description/Discussion Status Extraction Distributed Ad hoc Routing Specification; Draft Expired; no subsequent RFC) draft-ietf-manet-cbrp-spec-01 (Cluster Based Routing Protocol; Draft Expired; no subsequent RFC) draft-ietf-manet-longlived-adhoc-routing00 (Long-lived Ad Hoc Routing based on the Concept of Associativity; Draft Expired; no subsequent RFC) draft-jeong-umr-manet-00 (Unicast Routing based Multicast Routing Protocol for Mobile Ad Hoc Networks; Draft Expired; no subsequent RFC) Quality of Service QoS and Routing draft-perkins-manet-aodvqos-01 (Quality of Service for Ad hoc On-Demand Distance Vector Routing; Draft Expired; no subsequent RFC) QoS and Resource Reservation BGRP: A Framework for Scalable Resource Reservation. The Border Gateway Reservation Protocol (BGRP) is used for inter-domain resource reservation that can scale in terms of message processing load, state storage and control message bandwidth. draft-pan-bgrp-framework-00 (Draft expired; no subsequent RFC) QoS and Dynamic SLAs/SLSs COPS Usage for SLS negotiation (COPS-SLS) is a protocol for supporting Service Level Specification (SLS) negotiation. draft-nguyen-rap-cops-sls-03 (Draft expired; no subsequent RFC) Attributes of a Service Level Specification (SLS) Template depicts a standard set of information to be dynamically negotiated between a customer and an IP service provider or between service providers, by means of instantiated Service Level Specifications (SLS). draft-tequila-sls-03 Service Level Specification for draft-somefolks-sls-00 121 (Draft expired; no subsequent RFC) Standards Area Description/Discussion Status Inter-domain QoS Negotiation describes a structure for defining Service Level Specifications for QoS negotiation over IP networks. The high level schema described in this document is intended for use during the process of QoS negotiation between a customer entity and a provider entity. (Draft expired; no subsequent RFC) QoS and Signaling: DRSVP aims to overcome the shortcomings of RSVP in terms of QoS adaptation. By treating a reservation as a request for service somewhere within a range, flexibility needed to deal with network dynamics is gained. As available resources change, the network can readjust allocations within the reservation range. INSIGNIA (protocol) is the first QoS signaling protocol specifically designed for resource reservation in ad hoc environments. It supports inband signaling by adding a new option field in IP header called INSIGNIA to carry the signaling control information. The INSIGNIA module is responsible for establishing, restoring, adapting, and tearing down real-time flows. It includes fast flow reservation, restoration and adaptation algorithms that are specifically designed to deliver adaptive real-time service in MANETs. If the required resource is unavailable, the flow will be degraded to best-effort service. QoS reports are sent to source node periodically to report network topology changes, as well as QoS statistics (loss rate, delay, and throughput) N. Schult, M. Mirhakkak and D. Thomson. A New Approach for Providing Quality of Service in Dynamic Network Environment. http://www.mitre.org/support/papers/ tech_papers99_00/thomson_mp_ dynamic/thomson_dynamic.pdf. draft-ietf-manet-insignia-01 (Draft expired; no subsequent RFC) draft-salsano-bgrpp-arch-00 122 Standards Area Description/Discussion Inter-domain QoS Signaling: the BGRP Plus Architecture describes a scalable inter-domain resource control architecture for DiffServ networks. The architecture is called BGRP Plus, as it extends the previously proposed BGRP framework (draft-pan-bgrp-framework00.txt). QoS and Frameworks for WideArea Ad-Hoc Networks SWAN is a stateless network model which uses distributed control algorithms to deliver service differentiation in mobile wireless ad hoc networks in a simple, scalable and robust manner. SWAN uses explicit congestion notification (ECN) to dynamically regulate admitted realtime traffic in the face of network dynamics brought on by mobility or traffic overload conditions. The Flexible QoS Model for MANET (FQMM) is based both on IntServ and Diffserv. Applications with high priority, use the per-flow QoS guarantees of IntServ. Applications with lower priorities achieve DiffServ per-class differentiation. The INSIGNIA QoS framework supports adaptive services that can provide base QoS (i.e., minimum bandwidth) assurances to real-time voice and video flows and data, allowing for enhanced levels (i.e., maximum bandwidth) of service to be 123 Status (Draft expired; no subsequent RFC) G. Ahn, A. T. Campbell, A. Veres, and L.H. Sun, “SWAN: Service Differentiation in Stateless Wireless Ad-hoc Networks”, Proc. IEEE Infocom, pp. 457-466, June 2002. draft-ahn-swan-manet-00 (Service Differentiation in Stateless Wireless Adhoc Networks; Draft Expired; no subsequent RFC) H. Xiao, W. K.G. Seah, A. Lo, and K. Chaing “Flexible QoS Model for Mobile Ad-hoc Networks”, IEEE Vehicular Technology Conference, Vol. 1, pp 445449, Tokyo, Japan, May 2000. S. Lee, G. Ahn, X. Zhang, and A. T. Campbell, “INSIGNIA: An IP-Based QoS framework for Mobile Ad-hoc Networks”, Journal of Parallel & Distributed Computing, Vol. 60, No. 4, pp 374-406, April 2000. Standards Area Description/Discussion Status delivered when resources become available. INSIGNIA is designed to adapt user sessions to the available level of service without explicit signaling between source-destination pairs. The PYLON framework views a mobile multihop network as a network that needs to cling to a fixed access network in order to gain access to the rest of the world. The hosting access network is expected to provide the mobile multihop network with suitable Service Level Agreement (SLA), Traffic Conditioning Agreement (TCA), and service provisioning policies. This framework uses aggregate RSVP signaling to perform inter-domain resource reservation. iMAQ is a cross-layer architecture to support the transmission of multimedia data over a mobile multihop network. Hard QoS guarantees cannot be provided and resources are not reserved. The framework involves the network layer (an ad hoc routing layer) and a middleware service layer. At each mobile node, these two layers share information and collaborate to provide QoS assurances to multimedia traffic. MMWN (Multimedia support for Mobile Wireless Network) system consists of adaptive link and network algorithms to support quality of service in large, multihop mobile wireless network. MMWN consists of modular system of distributed, adaptive algorithms at link and network layer. The key features of the system are: adaptive control of link quality; 124 Y. L. Morgan and T. Kunz, “PYLON: An Architectural Framework for Ad-hoc QoS Interconnectivity with Access Domains”, Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03) iMAQ: An integrated mobile ad hoc QoS framework. http://cairo.cs.uiuc.edu/adhoc/. . R. Ramanathan and M. Steenstrup. Hierarchically organized, multihop mobile wireless networks for quality of service support. Mobile Networks and Applications, 3(1):110–119, 1996. Standards Area Description/Discussion hierarchical organization; routing with quality of service; and autonomous repair of multipoint virtual circuit with resource reservations. AQuaFWiN architecture has used several concepts such as hierarchical organization, adaptive power control from existing architectures. The key distinguishing feature of the proposed architecture is the generic feedback mechanism which can be used to achieve adaptability at different layers of the network. Status Bobby Vandalore, Raj Jain, Sonia Fahmy, Sudhir Dixit AQuaFWiN: Adaptive QoS Framework for Multimedia in Wireless Networks and its Comparison with other QoS Frameworks, 1999 Information Assurance Security Architecture for Secure Management Transactions The AN must be able to operate when disconnected from terrestrially-based services making application of current security approaches difficult, if not impossible, to implement. The AN architecture in general, and the NM Architecture in particular, must be capable of securing administrative transactions over a disconnected, dynamically changing network. A number of different security constructs exist that can be applied to today’s wireline NM transactions, including public key technologies, security protocols including IPSec enabled virtual private networks (VPN), Transport Layer Security (TLS), Secure Socket Layer (SSL), as well as protocols with built-in security features, such as the SNMPv3 User Security Module. These approaches were designed upon the premise that dedicated, terrestrialbased security resources would be available to support these security services. Network Management Service Advertisement and Discovery Mechanisms To support the spontaneous, selfforming features of the AN, the network management architecture will require autonomous election of cluster managers and advertisement/discovery of those managers within the network. A service advertisement mechanism enables nodes with NM/PBNM services to announce themselves, while a service discovery process enables nodes seeking NM/PBNM services to locate NM/PBNM servers. Both of these features enable the NM Architecture to adapt to the network’s dynamic topology changes. 125 Proprietary and standards-based solutions for automated service discovery exist for fixed, wire-line networks (Service Location Protocol, Salutation Protocol, etc). However, these most likely would not be appropriate for dynamic topology networks. One issue is the problem of broadcast flooding over dynamic topology networks with bandwidth-constrained links. The selected service discovery methods would need to constrain the broadcast function in some fashion to avoid redundant flooding and inefficient use of bandwidth resources. Some potential options include use of MANET multicast and/or constrained (hoplimited) broadcasts. Standards Area Description/Discussion Status Clustering Protocol for Management of Dynamic Topology Networks The main concept behind cluster management is to convert a traditionally centralized process into a semi-distributed process that adapts to dynamic network challenges. The performance objective in selection of clusters is to minimize protocol overhead between client and server while maximizing management service availability. Selection of cluster size is an important parameter in forming and maintaining clusters. Clusters that are too large suffer from an excess of (NM/PBNM) message overhead due to collection of data from a large number of clients. Networks with clusters that are too small suffer from an excess of overhead in cluster maintenance traffic. Factors that impact selection of clusters include, among others, relative node speed, cluster density, mobility characteristics, etc. Various recent research endeavors have proposed cluster management schemes. However, none of these have been formally implemented, nor evaluated against the particular attributes (relative node speed, cluster density, mobility characteristics) of a military airborne network. Policy Based Network Management Policy Information Base draft-ietf-rap-acct-fr-pib-01 (Framework of COPS-PR Policy Information Base for Accounting Usage; Draft Expired; no subsequent RFC) draft-rawlins-rsvppcc-pib-02 (RSVP Policy Control Criteria PIB; Draft Expired; no subsequent RFC) draft-jacquenet-fwd-pib-00 (An IP Forwarding Policy Information Base; Draft Expired; no subsequent RFC) draft-jacquenet-ip-te-pib-02 (An IP Traffic Engineering Policy Information Base; Draft Expired; no subsequent RFC) draft-li-rap-mplspib-00 (MPLS Traffic Engineering Policy Information Base; Draft Expired; no subsequent RFC) draft-otty-cops-pr-filter-pib-00 (A Filtering Policy Information Base (PIB) for Edge Router Filtering Service and Provisioning via COPS-PR; Draft Expired; no subsequent RFC) Link Management Node Advertisement and Discovery Mechanisms The Ad-Hoc Mobility Protocol Suite (AMPS) consisting of Dynamic Registration and Configuration Protocol 126 Standards Area Description/Discussion Status (DRCP), Dynamic Configuration Distribution Protocol (DCDP), Configuration Database Update Protocol (YAP) and Adaptive Configuration Agent (ACA) developed for the CECOM Multifunctional On-the-move Secure Adaptive Integrated Communications (MOSAIC) Project provides many of the desired functionality. Node Admission Control Handoff Across Heterogeneous Links Dynamic Mobility Agents (DMA) Protocol and Domain Announcement Protocol (DAP) developed for the MOSAIC Project provide many of the desired functionality. Link Resource Provisioning Node and Link RealTime Performance Monitoring and Evaluation Network Topology Optimization Link Management Architecture and Transactions Network Services Name Resolution Service draft-engelstad-manet-name-resolution-01 (Name Resolution in on-demand MANETS and over external IP Networks; Draft Expired; no subsequent RFC) draft-jeong-manet-dns-service-00 (DNS Service for Mobile Ad Hoc Networks; Draft Expired; no subsequent RFC) draft-park-manet-dns-discovery-globalv600 (DNS Discovery for global connectivity in IPv6 Mobile Ad Hoc Networks; Draft Expired; no subsequent RFC) Configuration Management draft-paakkonen-addressing-htr-manet-00 (IPv6 addressing in a heterogeneous MANET-network; Draft Expired; no subsequent RFC) draft-perkins-manet-autoconf-01 (IP Address Autoconfiguration for Ad Hoc 127 Standards Area Description/Discussion Status Networks; Draft Expired; no subsequent RFC) draft-rantonen-manet-idaddress-dadadhocnet-00 (IP Address Autoconfiguration with DAD minimization for Ad Hoc Networks; Draft Expired; no subsequent RFC) Service Discovery draft-koodli-manet-servicediscovery-00 (Service Discovery in On-Demand Ad Hoc Networks; Draft Expired; no subsequent RFC) Network Time RFC 2030 (Simple NTP version 4), October 1996 Khoa To and James Sasitorn; N.A.M.E: The Network Time Protocol for Ad Hoc Mobile Environments; Computer Science Department Rice University Houston, Texas 128 10. AN Architecture Issues Table 10-1. AN Architecture Issues ID Issue Connectivity Description/Discussion CN1 Network and Link Stability How much network stability is needed in terms of throughput, latency, loss, and error rates to support AF mission traffic and ensure needed performance guarantees? What functions are required to provided the needed stability? Are there any AF mission traffic types that should not be supported with an IPbased network, today, in the interim, in the target (consider efficiency as well as network performance)? How should application and networking protocols be adapted to accommodate link instability? CN2 Directional Links What channel access mechanisms are most appropriate for ad hoc networks that combine directional and omni directional elements (a.k.a. directional ad hoc networks)? How should one initiate and maintain a network topology in directional ad hoc networks? What routing algorithms are necessary for standard (unicast), highassurance, and multipoint data delivery services in directional ad hoc networks? CN3 Network and Link Handoffs What functions are required to perform seamless/near seamless radio handoffs? What functions are required to ensure uninterrupted network connectivity as platforms move through several different subnets? CN4 Routing The Airborne Network must deliver a set of routing protocols that can be run on all platforms which are dynamic enough to accommodate rapid topological changes while maintaining efficiency with respect to bandwidth consumption from routing information exchanges. The routing protocols should be capable of intelligent routing decisions by taking into account such things as link characteristics (e.g. capacity and error rate of a particular radio subnet), number of hops, traffic requirements (e.g. delaysensitivity, precedence levels), etc. CN5 QoS The Airborne Network must have a consistent approach to providing Quality of Service (QoS) across the AN constellation. It is necessary to specify the protocols that will be employed, and describe the roles that various network elements are expected to play. These roles include such things as initiating resource reservations, classifying and tagging IP packets, providing prioritized queuing mechanisms, responding to requests for resource reservations, etc. 129 Status DISA is defining a GIG QoS architecture; however, it is unknown if it will be suitable for the AN. ID Issue Description/Discussion Status CN6 Real-Time Traffic What standards should be used for voice (VoIP), video (video over IP), and circuit emulation? DISA is defining a VoIP standard implementation. CN7 GIG Integration The Airborne Network must interface to and be integrated with other Service and Joint networks. An AN service delivery point (SDP) Interface definition is needed to indicate how the AN would interface with the GIG and other peer-networks? CN8 IP Convergence The most difficult part of implementing converged IP-based networks will be addressing the performance management of end-to-end flows which transit nodes in the infrastructure with extreme changes in bandwidth, heavy congestion, long latencies, and the inherent difficulties of mobile tactical environments. Enterprise management in industry today focuses on single enterprises, single technology groups, and single communities of interest. There is an absence of tools and technologies for real-time management across networks, particularly in the area of real-time configuration and performance. Information Assurance IA1 DoD and Service IA Policy Existing policy doesn't adequately address operations in a wireless or wireless ad hoc network environment. IA2 HAIPE Specification and Interoperability A core the High Assurance IP Interoperability Specification (HAIPIS) is being developed. However, a lightweight and potentially other variants of HAIPIS are also being developed to accommodate different operational environments. Lack of interoperability between HAIPE variants, including between wireless and wired HAIPE devices, will impact interoperability. GIG E2E Working Group and HAIPE Working Group is baselining HAIPISv2 and defining modules that may accompany HAIPISv2. NSA is working to baseline HAIPIS Lite requirements. IA3 Encryption Processing Speeds HAIPE, TRANSEC, and other encryption device data processing speeds may not keep pace with required network throughput speeds. NSA has seeded industry with funding to develop high speed HAIPE devices. IA4 Crypto Modernization Initiative CMI may not deliver the high assurance algorithms, keys, and hardware products when needed to support wireless and laser based packet and/or circuit switched networks. DoD Research Area -- identify algorithms and emcryption key 130 ID Issue Description/Discussion Status products needed to support near, mid, and long term wireless IP capability. IA5 Protocol Security IA6 DoD PKI Integration Not all protocols have built-in security or have minimal built-in security. Many protocols [i.e., OSPF, SNMP, BGP] rely on ubiquitous shared secrets and/or only provide limited integrity or authentication checking. Few provide data confidentiality. DoD PKI supports authenticating and identifying humans, devices, and information. However, effective PKI use requires continuous connectivity to the PKI. Current design is terrestrially based and has little support for the tactical environment and no support for the ad hoc network. Issues that must be resolved include certificate management and validation over bandwidth constrained networks and employment of PK services when disconnected from the GIG infrastructure. Care must be taken to ensure that use of PK services for the AN doesn’t become a single point of failure. Services collaborated and developed DoD Tactical Function Requirements Document (FRD) that identifies delta between current PKI ORD needs and extending PKI to the tactical environment. Other, related issues are the applicability of current certificate design to non fixed IP or domain name devices; usability of identity certificates to support implementation of role based access control systems; and adequacy of DoD PKI trust model. DoD and service timeline to develop tactical solutions are unknown. IA7 Key Management IA8 Access Control IA9 Authentication Current EKMS is predominately manual. Emerging EKMS capability is moving towards increased automation. Large numbers of wireless devices and [potentially] different subnets will drive EKMS solutions plus make manual key delivery impractical. Need to define AN EKMS requirements in terms of operational employment [ad hoc, non-ad hoc and anchored, non-anchored networking] and need timeline. AN entities will need to support OTAR, OTNK, OTAZ, and OTAT. Devices will be managed and maintained by entities that may be local or remote to the device itself. Level of entity access to a device will be based on the entity's role in relation to that device [can manage, can operate, can monitor, etc.] The security impacts of centralized versus distributed and unified versus federated management systems needs to determined. Nodes [AN, management, humans, etc.] will need to be authenticated by devices and/or networks [dependent on the activity to be accomplished.] The 131 HAIPE is working towards automated over-the-air rekey. OTNK [Over the Network Keying] is yet to be developed; however, a OTNK pilot is underway. ID Issue Description/Discussion Status functional layer at which the authentication will occur, how it will be managed, and how the authentication state will transfer through the AN needs to determined. How IDS and IPS will operate in the AN environment must be determined, including whether these functions are distributed throughout all nodes or centralized at specific nodes. How data aggregation and response will be accomplished. What response time is needed and reasonable? What is the impact of operating in an ad hoc network? Should these functions be network centric and interoperate between devices or device centric? How will device compromise be detected? Once detected, how will AN nodes be informed of the compromise and how will recovery be accomplished? What is anticipated operational impact during a recovery phase? Various protocols may be more or less susceptible to use as a path to carry covert data. IA10 Intrusion Detection System (IDS) and Intrusion Prevention Systems (IPS) IA11 Compromise and Compromise Recovery IA12 Covert Channel IA13 Black or Unclassified Terminals Unmanned terminals [relay nodes, UAV, etc.] will need operational TRANSEC keys and may be queried for status data. Software, wrapped keys, and other code may exist in the terminal, that if compromised, may have significant security implications. How will device be maintained "black" while operational? IA14 MSLS and MLS. AN will initially support multiple single levels of security and eventually support multiple level security. How will this support be implemented and supported? IA15 Allied/Coalition Security Environment IA16 Interoperability with Other Networks IA17 Operations, Management, and Control Data Mixed U.S., coalition, and allied operations will require ability to operate across multiple security domains, using mixed encryption and TRANSEC algorithms and keys, interacting with U.S. and nonU.S. public key infrastructures. AN security infrastructure and protocols must interoperate with infrastructures and protocols implemented to support other networks [e.g., GIG, tactical ground, fixed terrestrial, etc.] Hierarchical or layered IA functions must interoperate with their logical peers on other networks. System configuration, link and network management data, device code updates, etc. must have source and integrity validated before receiving entities 132 JTRS is implementing an unmanned relay node. TCM has requirement for a black terminal. NSA has expressed concern over how terminal can remain black w/operational keys. JTRS is implementing MSLS through use of independent channel per security domain. ID IA18 Issue Description/Discussion Integrity and Validity operationally employ it. Operation over Wireless Links Traffic flow security, as implemented by the High Assurance Internet Protocol Encryptor, have a performance impact. In a low speed link, TFS support may significantly impact overall user data throughput. Network Management NM1 Efficiency What efficiency improvements (e.g., compression, aggregation) can be implemented to reduce NM traffic? Transaction-intensive NM exchanges must be minimized (in frequency and size) to prevent high overhead. NM2 Management of Multiple Network Security Levels The Airborne Network must be capable of the management of multiple network security levels -i.e., management of multiple security levels of red networks and a black network. An integrated, efficient solution is needed. NM3 Management of AdHoc Networks NM4 Integrated Network Management What needs to be done to develop a unified NM capability for the AN when separate acquisitions (FAB-T, JTRS, MP-CDL) are implementing different NM and administrative domains ? What are the interface and integration requirements for providing integrated, inter-domain NM? Should there be a top-level NM or "Services Manager" (over TC, JTRS, MP-CDL constituents) for AN policy management, E2E provisioning, and AN Situational Awareness? NM5 Policy Management How can QoS Provisioning and Policy Based Network Management (policy distribution, enforcement, provisioning) be performed in a dynamic network composed of multiple separately managed links and subnets? Link Management LM1 Cross-Layer Approach Determine how link management functions (e.g., topology management, admission control, QoS/CoS) may be implemented via cross-layer approach. Determine relative benefits and tradeoffs of physical, MAC, network and application layer techniques in combination with one another. 133 Status The HAIPIS Working Group is seeking technological solutions that can be applied to the next generation of HAIPE devices enabling them to provide TFS while decreasing their wireless operational impact. ID Issue Description/Discussion LM2 Link Discovery Protocols Efficient link discovery/establishment protocols needed. LM3 Dynamic Link Configuration LM4 Measurement and reporting of link conditions Which radio/terminal (layer 1 and 2) parameters are dynamically changeable? To what extent can these parameters be changed? Which conditions are measurable, measurement techniques, measurement frequency, establishment of acceptable ranges, reporting thresholds? What parameters should be reported for each link type? LM5 Topology Management Determine tradeoffs between factors such as computation overhead, levels of hierarchal organization, optimal node power, desired connectivity, maximum data rate for links, vulnerability to jamming, network survivability, graceful performance degradation under dynamic changes. LM6 Dynamic Resource Provisioning What are the protocols, approaches, technologies for dynamically provisioning link resources for the AN? LM7 Dynamic Network Configuration LM8 Link Management of Ad Hoc Networks What are the protocols, approaches, technologies for dynamically configuring network parameters throughout the AN? What are the protocols, approaches, technologies to leverage for LM of ad hoc networks? Network Services NS1 IP Address Management The Airborne Network must have a well-defined address management plan in place in order to handle the distribution of IP addresses to network elements on airborne platforms. The address management plan must be consistent across the entire AN constellation, and roles and responsibilities for each platform must be well defined. The address management plan must clearly identify when and how network elements will be assigned IP addresses. This includes the renumbering of network elements during operation. NS2 Domain Name System (DNS) The Airborne Network must have a consistent and robust approach to providing DNS services for nodes in the constellation. In order to do this, an operations model must be established that details such things as the location of DNS servers, redundancy plans, and the responsibility of specific platforms with respect to whether or not they provide DNS services for others in the AN constellation. NS3 Mobility Management In the Airborne Network mobility management will be needed to ensure that platforms can be located quickly and that packet delivery operates properly and without interruption as platforms move throughout the network. An integrated muli-layer, multi-transport system solution is needed. 134 Status ID Issue Description/Discussion NS4 Network Time Protocol Currently Network Time Service is not a ubiquitous service across the GIG. Security directives prevent IP-based time synchronization across firewall boundaries (AFI 33-115, 16). General G1 Airborne Network Service Providers What is the minimum set of services required on an airborne NSP node? What is required to ensure that an airborne NSP node failure or loss will not impact mission operations? G2 Proxies The use of proxies can improve the performance of user applications running across the AN by countering wireless network impairments, such as limited bandwidth, long delays, high loss rates, and disruptions in network connections. However, proxies performance can be impacted by the security and data link mechanism. An integrated muli-layer, multi-transport system solution is needed. 135 Status 11. List of Acronyms ACA ACM AETACS AMPS AMTI AN AOC AS ASWR ATO AWACS Adaptive Configuration Agent Adaptive Configuration Manager Airborne Elements of the Tactical Air Control System Ad-Hoc Mobility Protocol Suite Air Moving Target Indicator Airborne Network Air and Space Operations Center Autonomous System Attack Sensing, Warning, and Response Air Tasking Order Airborne Warning and Control System BGP BLOS Border Gateway Protocol Beyond Line-of-Sight CAP CAS CITS CLIP CND COIs CONOPS CONUS CoS C2ERA Combat Air Patrol Close Air Support Combat Information Transport System Common Link Interface Processor Computer Network Defense Communities of Interest Concept of Operations Continental United States Class of Service Command and Control Enterprise Reference Architecture DAA DAP DCDP DHS DISN DMA DNS DoD DRCP Designated Approving Authority Domain Announcement Protocol Dynamic Configuration Distribution Protocol Department of Homeland Security Defense Information System Network Dynamic Mobility Agents Domain Name System Department of Defense Dynamic Registration and Configuration Protocol ECU EGP EKMS EMCON End Cryptographic Unit Exterior Gateway Protocol Electronic Key Management System Emission Control FCAPS FEC Fault, Configuration, Accounting, Performance, Security Forward Error Correction 136 GIG GIG-BE GIG ES GMTI GNOSC GPS GTACS Global Information Grid GIG-Bandwidth Expansion GIG Enterprise Services Ground Moving Target Indicator Global Network Operations and Security Center Global Positioning System Ground Tactical Air Control System HAIPE HAIPIS HI High Assurance Internet Protocol Encryptor High Assurance IP Interoperability Specification Horizontal Integration I&A IA IDS IFGR IGP IPS ISR IT Identity and Authentication Information Assurance Intrusion Detection System Information for Global Reach Interior Gateway Protocol Intrusion Prevention System Intelligence Surveillance and Reconnaissance Information Technology JWICS JV Joint Worldwide Intelligence Communications System Joint Vision KLIF KMA KMI Key Loading and Initialization Facility Key Management Architecture Key Management Infrastructure LDAP LM LMA LMAMs LME LMP LOS LPDP LPI/LPD Lightweight Directory Access Protocol Link Management LM Agent LM Autonomous Managers LM Executive Link Management Protocol Line of Sight Local Policy Decision Point Low Probability of Interception/Detection MANs MIB MILS MLPP MLS MOSAIC Metropolitan Area Networks Management Information Base Multiple Independent Levels of Security Multi-Level Precedence and Preemption Multi-level Security Multifunctional On-the-move Secure Adaptive Integrated Communications 137 MPLS MPLS-TE Multi-Protocol Label Switching Multi-Protocol Label Switching--Traffic Engineering NASA NCW NESI NIPRNET NIST NM NM NOC NSA NSS NTP NTS National Aeronautics and Space Agency Network Centric Warfare Net-Centric Enterprise Solutions for Interoperability Unclassified-but-Sensitive Internet Protocol Router Network National Institute of Standards and Technology Network Management Network Manager Network Operations Center National Security Agency National Security Systems Network Time Protocol Network Time Server OANs OTAR OTAT OTAZ OTNK Operational Area networks Over-The-Air Rekeying Over-The-Air Transfer Over-The-Air Zeroize Over-The-Network Keying PBNM PBSM PDP PEP PEP PIB PIM PKI Policy Based Network Management Policy Based Security Management Policy Decision Point Policy Enforcement Point Performance Enhancing Proxy Policy Information Base Programmable INFOSEC Module Public Key Infrastructure QoS Quality of Service RF ROE RSVP-TE RSVP-TE Radio Frequency Rules of Engagement Resource Reservation Protocol--Tunneling Extensions Resource Reservation Protocol – Traffic Engineering SAR SATCOM SDN SDP SEAD SIP SIPRNET SLA Synthetic Aperture Radar Satellite Communications Service Delivery Node Service Delivery Point Suppression of Enemy Air Defenses Session Initiation Protocol Secret Internet Protocol Router Network Service Level Agreement 138 SLCS SMI SoM SoMI SPPI SPS SSL Senior Level Communications System Security Management Infrastructure Strength of Mechanism Structure of Management Information Structure of Policy Provisioning Information Standard Positioning System Secure Socket Layer TAP TCP TCT TDC TDL TFS TLS TPED TPPU TRANSEC TSAT TS/SCI TWSTT Traffic Analysis Protection Transmission Control Protocol Time Critical Targeting Theater Deployable Communications Tactical Data Link Traffic Flow Security Transport Layer Security Task, Process, Exploit, and Disseminate Task, Post, Process, and Use Transmission Security Transformational Communications Satellite System Top Secret/Sensitive Compartmented Information Two-Way Satellite Time Transfer UAV UDOP USNO UTC Unmanned Aerial Vehicle User Defined Operational Picture U. S. Naval Observatory Coordinated Universal Time VoIP VPN Voice over IP Virtual Private Networks WAN Wide Area Network YAP Configuration Database Update Protocol 139 12. References 1. B. Braden et al., Developing a Next-Generation Internet Architecture, July 2000 2. Airborne Network Architecture Progress Summary Version 1.0, USAF Airborne Network Special Interest Group, May 2004 3. Airborne Network Architecture Roadmap (Draft) 4. Airborne Network Technical Requirements Document Version 0.4, USAF Airborne Network Special Interest Group, 11 September 2003 5. Alberts, D. S., J. J. Gartska, and F. P. Stein., Network Centric Warfare: Developing and Leveraging Information Superiority, DoD C4ISR Cooperative Research Program, Washington, DC., 1999 6. Airborne Network (AN) Prioritization Plan, Headquarters USAF (AF/XICA), 31 March 2004 7. Operating Concept for C2 ConstellationNet Network Centric Infostructure, AFC2ISRC/SCY, 1 April 2004 8. Understanding Enterprise Network Design Principles, Cisco Systems, Inc, 2001 9. U.S. Air Force Infostructure Enterprise Architecture, Version 1.3, Air Force Communications Agency, 27 February 2004 10. U. S. Air Force Network Management Platform Profile, Version 0.9, Air Force Communications Agency, 5 December 2002 11. U. S. Air Force Network and Infrastructure Defense Platform Profile, Version 0.9, Air Force Communications Agency, 27 November 2002 12. U. S. Air Force Domain Name Service Profile, Version 1.0, Electronic Systems Center 13. (ESC/NI2), 23 February 2004 14. U. S. Air Force Network Time Service Profile, Version 1.0, Electronic Systems Center 15. (ESC/NI2), 28 January 2004 16. Framework for QoS-based Routing in the Internet, RFC 2386, IETF Network Working Group, August 1998 17. “Quality of Service - Glossary of Terms”, http://www.qosforum.com/whitepapers/qos-glossary-v4.pdf, May 1999 140 18. Proposed Draft Strawman DSCP Mapping for GIG Enterprise IP Networks Version 11p, DoD GIG QoS/CoS Working Group, 22 March 2004 19. Guidelines for Improved Applications Performance over Networks, Defense Information Systems Agency, 11 April 2003 20. Blaine, D., DoD Global Information Grid (GIG) Quality of Service / Class of Service(QoS / CoS) Net-Centric Effective Assured Delivery of Information, Defense Information Systems Agency, 30 September 2003 21. DoD Transport Design Guidance Document, Version 0.97, The MITRE Corporation, April 2004 22. A Framework for Policy-based Admission Control, RFC 2753, IETF Network Working Group, January 2000 23. Terminology for Policy-Based Management, RFC 3198, IETF Network Working Group, November 2001 24. Kam, A., Trafton, R., Assessment of Mobile Routing Protocols for the Airborne Network, USAF Global Grid Technical Note Number 2003-04, Electronic Systems Center (ESC/NI1), October 2003 25. Trafton, R., Doane, J., Lam, L., Performance Enhancing Proxy Evaluation: Peribit SR-50, Mentat SkyX Gateway XR10, USAF Information Transport Technical Note Number 2004-01, Electronic Systems Center (ESC/NI1), February 2004 26. Kam, A., Morin, S., Trafton, R., Networking Over RF Links, USAF Global Grid Technical Note Number 2003-01, Electronic Systems Center (ESC/NI1), May 2003 27. Incremental Update -- AMPS Protocol Design Document, CECOM Multifunctional On-the-move Secure Adaptive Integrated Communications (MOSAIC) Project, Telcordia Technologies, Inc., 1 April 2003 28. Differentiated Services with Distributed Quality of Service Managers, CECOM Multifunctional On-the-move Secure Adaptive Integrated Communications (MOSAIC) Project, Rockwell Collins, August 2002 29. Incremental Update - DS/BB Protocol Design Document, CECOM Multifunctional On-the-move Secure Adaptive Integrated Communications (MOSAIC) Project, Telcordia Technologies, Inc., 1 April 2003 141 30. Global Information Grid Core Enterprise Services Strategy Version 1.1a, Office of the Assistant Secretary of Defense for Networks and Information Integration/DoD Chief Information Officer, July 2003 31. Global Information Grid Information Assurance Reference Capabilities Document, Volume I, Sections 2 and 3 32. Xukai Zou, Byrav Ramamurthy and Spyros Magliveras; Routing Techniques in Wireless Ad Hoc Networks-Classification and Comparison; International Conference on 33. Computing, Communications and Control Technologies: CCCT'04, August 2004 34. Shahrokh Valaee and Baochun Li, Distributed Call Admission Control for Ad Hoc 35. Networks, Proceedings of IEEE 56th Vehicular Technology Conference, Volume: 2, September 2002 36. Shigang Chen and Klara Nahrstedt, Distributed Quality-of-Service Routing in Ad Hoc Networks, August 1999 37. Jamal N. Al-Karaki and Ahmed E. Kamal, Quality of Service Routing in Mobile Ad hoc Networks: Current and Future Trends, Mobile Computing Handbook, M. Ilyas and I. Mahgoub (eds.), CRC Publishers, 2004 38. Prasant Mohapatra, Jian Li and Chao Gui; QoS in Mobile Ad Hoc Networks; June 2003 39. Imrich Chlamtac, Marco Conti and Jennifer J.-N. Liu; Mobile Ad Hoc Networking: Imperatives and Challenges; 2003 40. Khoa To and James Sasitorn; N.A.M.E: The Network Time Protocol for Ad Hoc Mobile Environments; Computer Science Department Rice University Houston, Texas 41. Chen, Wenli and Jain, Nitin, August 1999, ANMP: Ad Hoc Network Management Protocol, IEEE Journal on Selected Areas in Communications, Vol. 17, No. 8. 42. Shen, Chien-Chun, Srisathapornphat, Chavalit, and Jaikaeo, Chaiporn, February 2003, An Adaptive Management Architecture for Ad Hoc Networks, IEEE Communications Magazine. 43. Phanse, Kaustubh and DaSilva, Luiz A., Protocol Support for Policy-Based Management of Mobile Ad Hoc Networks, submitted for (conference) publication, 2003, http://www.ee.vt.edu/~kphanse/research.html 142 44. Toner,S. & O'Mahony,D., Self-Organising Node Address Management in Ad-hoc Networks, in Springer Verlag Lecture notes in Computer Science 2775, Springer Verlag, Berlin, 2003, pp 476-483, also at http://ntrg.cs.tcd.ie/publications.php 45. Liotta, A., G. Knight, and G. Pavlou, On the Performance and Scalability of Decentralised Monitoring Using Mobile Agents, in Active Technologies for Network and Service Management, Proceedings of the 10th IFIP/IEEE International Workshop on Distributed Systems: Operations and Management (DSOM '99), Zurich, Switzerland, R. Stadler, B. Stiller, eds., pp. 3-18, Springer, October 1999, http://www.ee.surrey.ac.uk/Personal/A.Liotta/Publications/ 46. Intel Labs, Simplifying Support of New Network Services Using COPS-PR, http://www.intel.com/labs/manage/cops/ 47. Phanse, Kaustubh and DaSilva, Luiz A., Extending PBNM to Ad Hoc Networks, http://www.ee.vt.edu/~kphanse/research.html 143