HAIPE@ PEER DISCOVERY IN A DYNAMIC SCALING ARCHITECTURE

James KohlerDepartment of Defense and

Linthicum, MD

William T. Scott PhDGeneral Dynamics and

C4 SystemsScottsdale, AZ

Gary BudaSEE and

Baltimore, MD

Kristy GuyerDepartment of Defense

Linthicum, MD

Figure 1: HAIPE Tunnel Mode SPI

servers that support e-mail, DNS, VoIP, and web accesswill need to be designed and deployed with mechanisms tosupport the dynamics of the tactical environment. TheHAIPE peer discovery service will be designed to addressthe dynamics and the security needs of the new networkenvironment.

An SA can be established using either asymmetric keymaterial or symmetric key material. Symmetric keymaterial requires manual configuration of the SA and,therefore, there is no discovery problem for SAs that usesymmetric key material. SAs that use asymmetric keymaterial use the Internet Key Exchange (IKE) to establisha unique key for each pair of HAIPEs. This requires thesource HAIPE to know which remote HAIPE protects the

SA Tuple

HAIPE Tunnel

Mode EnCryption

r

HAIPEs are system components that provideconfidentiality and integrity services in IPv4 and IPv6environments that ensure an end user's sensitiveinformation is neither disclosed to unauthorized entities,modified, nor replayed. The HAIPE InteroperabilitySpecification (IS) is based on Internet Protocol Security(IPsec) (RFC 4301) and Encapsulating Security Payload(ESP) (RFC 4303). A Security Association (SA) thatdefines the security services used to protect traffic betweentwo HAIPEs must be established before user data can beencrypted and transmitted. An SA is identified by thedestination HAIPE CT IP address, the source HAIPE CTIP address, and an SA identifier called a SecurityParameter Index (SPI). Once an SA is established, datapackets are encrypted and encapsulated at the HAIPE andsent securely across the CT network to a peer HAIPE. InHAIPE protected networks, there is both a plaintext and aciphertext routing domain. Each of these routing domainsuses a different addressing scheme. HAIPEs provideisolation between the different routing domains. This isillustrated in Figure 1.

Currently, the Department of Defense (DoD) is facing alarge issue of providing infrastructure services to a singleciphertext (CT) network. In the future, these services willinclude Voice over Internet Protocol (VoIP), DomainName System (DNS), electronic mail (e-mail), web, and,because of the need for protected Internet Protocol (IP)communications between users, a High Assurance InternetProtocol Encryptor (HAIPECR

) peer discovery service. Asthe network is deployed, the DoD has the task of adaptingthese network services to a dynamic and growingarchitecture. Unlike commercial networks which arearchitected around relatively static metropolitan areas, theDoD network is more dynamic with tactical deploymentsaround the world changing to address global missions. So,

Many distributed peer-to-peer networks require adiscovery mechanism to learn the locations of, andservices offered by, participating peers. The problembecomes more complicated when the services reside on aplaintext (trusted) network and communications occurover a ciphertext (untrusted) network. This paperdescribes the discovery problem where a large number o.fpeers must be capable ofboth securely registering theirlocation and services with the network, and securelyquerying network participants to locate peers and/orservices. The targeted network environment includes up to106 nodes that may be fixed or mobile. These nodes mayhave limited bandwidth or intermittent availability. Also,the network end-to-end latency may be large. To addressthese constraints, the benefits ofvarious types o.fsolutionsmust be assessed. Tradeoffs between bandwidthrequirements and convergence times for push versus pullmechanisms and proactive versus reactive mechanisms fordata dissemination must be considered. Local storagerequirements and query response time must be taken intoaccount for solutions using local versus remote copystorage. And, the architecture, whether pure peer-to-peeror hierarchical, will be influenced by the required numberofnodes and the size ofthe required database. Securityposes an additional challenge as new nodes must be ableto establish secure communications with existing nodeswithout creating either an intolerable delay or anunacceptable burden on network administrators.

ABSTRACT

BACKGROUND

Page 1 of5

978-1-4244-2677-5/08/$25.00 ©2008 IEEE

host for which traffic is intended. This infonnation can bemanually configured in the HAIPE@ or an automatedmechanism can be used to learn peer HAIPE infonnation.

Creating two distinct routing domains creates anaddressing issue. The initiating PT host knows the addressof the destination PT host, but has no knowledge of the CTaddressing scheme. Preserving the original destinationaddress can pose a security issue and may not be routableon the CT network. The fronting HAIPEs must keep trackof which destination PT hosts are behind which HAIPEs,so they can readdress the packet. The new address is thatof the destination HAIPE rather than the plaintext host.The destination HAIPE then decrypts the packet andrestores the original plaintext destination address.

HAIPE peer discovery is an automated mechanism bywhich a source HAIPE device fronting an originating(source) host locates the CT and PT IP addresses of one ormore target HAIPE devices that are fronting thedestination host to which the traffic is intended. SinceHAIPEs isolate PT networks from CT networks anddifferent IP address schemes are maintained on the PT andCT networks, the HAIPE requires a mechanism todetennine the IP addresses for the peer HAIPE that isprotecting a specified PT destination. This mechanism,HAIPE peer discovery, then provides an alternative tomanual configuration for a HAIPE to learn how to reachPT hosts in remote enclaves that are protected by remoteHAIPEs. The HAIPE peer discovery problem is illustratedin Figure 2.

solution space, there is additional capability required.First, as the name Generic Discovery Client indicates, thisis only the client piece of the problem. A server isrequired and, currently, there is not a known discoveryserver being developed. Second, a single server can not beexpected to contain all of the HAIPE discoveryinfonnation for both the tactical and the strategicenterprises. Therefore, multiple servers are required andinfonnation must be distributed among the servers.

CURRENT NETWORK ENVIRONMENT

The current DoD core networks provide data, video, andvoice services to a relatively small number of fixed sitesaround the world that are connected with high bandwidth(e.g., 1 gigabit per second (Gbps)) links. These networksare similar to the commercial backbone of the Internetwith security overlaid, so building the commercial servicesofVoIP, DNS, e-mail, and web as the Internet has today isrelatively simple.

For these static networks, the problem ofHAIPE peerdiscovery is limited. There is an overhead cost associatedwith either manually configuring peer HAIPE and hostinfonnation in each HAIPE, or registering HAIPE and hostinfonnation with a discovery server and querying thediscovery server when HAIPE infonnation for adestination prefix is needed. Since the network isrelatively static, the discovery information does not changefrequently and additional discovery traffic for updateswould be minimal.

Figure 2: HAIPE Discovery Problem

HAIPE PEER DISCOVERY IN A GLOBALENTERPRISE

However, the goal for the DoD is for every ship, aircraft,vehicle, and dismounted solider to participate in IP-basedsecure communications over a single CT network. This isa much different and more complex problem than thecurrent fixed core network.

PROBLEM SPACE DEFINITION

In the near future, tactical network communications will beprotected with HAIPEs. Soldiers will carry HAIPEcompliant radios, ships will have multiple HAIPEs toprotect communications between ships and from ship toshore, and aircraft will HAIPE encrypt theircommunications to ground tenninals and between aircraft.Pushing encryption to the edge of the network willincrease both the number of HAIPE nodes in the networkand the mobility of nodes in the network considerably. Inthis dynamic environment, the HAIPE peer discoveryservice must be able to handle both CT mobility (theHAIPE and all hosts protected by the HAIPE move) andPT mobility (a host moves from one HAIPE protectedenclave to another HAIPE protected enclave).

Plaintext Domain 2

Which HAiPE protectsPT Host 2? Where

should the protectedpacket be forwarded? J-----,

HAIPE products may contain a discovery capability calledGeneric Discovery Client (GDC). GDC provides thecapability for a HAIPE to register itself and its protectedprefix/host addresses with a server and to query a server toidentify remote HAIPEs associated with destination hosts.While this is a critical piece of the HAIPE discovery

Page 2 of5

CT mobility can occur when a HAIPE@ and all of the hostsprotected by the HAIPE move from one area of the globalenterprise to another, resulting in readdressing of theHAIPE CT IP address. This invalidates all existing SAs tothat HAIPE and new SAs must be established with the newHAIPE CT IP address. This scenario is valid for a soldieror vehicle with a HAIPE enabled radio moving betweencoverage areas. Note that mobility of the HAIPE withoutreaddressing the CT IP address of the HAIPE is handledby the CT routing infrastructure and does not require re­establishment of SAs to the mobile HAIPE.

PT mobility can occur when a network is protected bymore than one HAIPE and the primary HAIPE becomesunreachable (e.g., the primary HAIPE either fails or isremoved from the network). SAs then need to beestablished with the secondary HAIPE. Although devicesmay not be moving in this scenario, from the perspectiveof the source HAIPE, destination hosts have moved frombehind the primary HAIPE to behind the secondaryHAIPE. This scenario is an example of a fault tolerantnetwork architecture.

Along with mobility, the discovery service must allow forevolutionary changes in an existing network. Tacticalnetworks can grow as multiple HAIPE enabled units entera coverage area. A tactical enterprise discovery serverarchitecture must be able to scale in size by addingdiscovery service capability as the network grows.

In a fixed core environment, bandwidth is considered to bereadily available. Using bandwidth for signaling protocols(e.g., Resource Reservation Protocol (RSVP)) in a fixedcore network is feasible, in part, due to the availablebandwidth. Using a small percentage of bandwidth in thefixed core environment provides ample capacity forHAIPE peer discovery without impacting user throughput.However, in a tactical network, bandwidth is limited. Thismakes protocols that are feasible in the core, not practicalin a tactical environment. Due to the degree of mobility intactical networks, HAIPE peer discovery is a criticalservice for the tactical environment. A tactical HAIPEpeer discovery architecture must have minimal impact onuser throughput as the network capacity is limited.

Latency and user expectation for establishing securecommunications must also be considered. The localdiscovery server should be able to answer most queries,minimizing the queries that need to be sent to a differentdiscovery server. Server performance (i.e., the time torespond to a query, either locally or through a discoveryserver in a different part of the enterprise affects latency.Latency must be managed such that the user's perceptionof the time required to establish an SA is acceptable.

Other factors such as time to conduct an asymmetric keyexchange also affect latency and need to be consideredalong with the time to resolve a discovery query.

Similar to user throughput, power consumption is also alimiting factor in tactical environments. While someenvironments, i.e., shipboard, may have more poweravailable than a battery powered manpack, power is still alimiting factor. The benefit provided by HAIPE peerdiscovery in increased connectivity must outweigh thecosts in resource consumptions.

To effectively solve the HAIPE peer discovery problem,the number of nodes, the mobility of the nodes, and thedeployment timeline need to be quantified anddocumented. The following programs and organizationshave provided information, detailed in the next section,about the number and mobility of nodes and expecteddeployment of the nodes: Warfighter InformationNetwork-Tactical (WIN-T), Joint Tactical Radio System(JTRS), Global Information Grid - Bandwidth Expansion(GIG-BE), Automated Digital Network System (ADNS),Future Combat Systems (FCS), Office of the Secretary ofDefense (OSD), Army, Navy, Air Force, and DefenseInformation Systems Agency (DISA). The concept ofoperations (CONOP) for the future DoD networks is toallow every node to have the ability to talk to every othernode. This problem definition and the HAIPE peerdiscovery solution should support, and not inhibit, theoperational realities of communication through a chain ofcommand and greater communication between nodesinside of an Area of Responsibility (AOR).

NUMBER OF NODES

DoD networks in the 2020 time frame are expected toinclude at least 400,000 solider nodes, 60,000 vehiclenodes, 6,000 airborne nodes, and 4,500 ship nodes, allenabled with HAIPE COMSEC. The Army and Air Forcealone plan to field over 70,000 gateway HAIPE devices. Ifthe HAIPE architecture is extended to unattended groundsensors (UGS) and intelligent munitions systems (IMS)then the number of devices grows by a factor often. UGSnetworks add other complications. Nodes in the network,or the network as a whole, may have intermittent or noconnectivity over an extended period of time. Hence aHAIPE peer discovery system must scale to support atleast this number of nodes. As capabilities are pushed tothe network edge, the number of nodes is expected tocontinue to grow. Timelines for deployment of thedifferent node types are not clearly documented. Forsimplicity, a linear deployment beginning in 2012 isassumed here, see Figure 3.

Page 3 of5

Deployment Timeline

MOBILITY OF NODES

Figure 3: Deployment Timeline

The slowest moving nodes are the UGS and IMS nodes.Once deployed they usually remain relatively fixed and arestatic members of their networks. Frequently theircommunications link will be limited range radio linksforcing them to use local discovery servers.

The next slowest moving nodes are the ship-based nodes,which have the ability to move from one area to another atthe rate of one time per day. Long range SatelliteCommunications (SATCOM) based links are likely to beused by ship-based nodes for HAIPE peer discoverycommunications. High Frequency (HF) and laser line ofsite links also may be present to allow ciphertext (CT)communication between ships; however, this should havelimited impact on HAIPE peer discovery.

Dismounted solider nodes move up to 12 miles per hour.These nodes will likely be readdressed at most once every30 minutes. As with UGS and IMS, these devices willhave low power requirements that result in a limited rangeof communications. Because of this limited range, thesenodes will be readdressed frequently as soldiers move.Another point to note is that some solider nodes maycommunicate using Mobile User Objective System(MUOS) based devices. They will have a point of presenceon the GIG that presence will have a complicated dynamicaddress allocation scheme.

one specific CT IP address. Static nodes protected by aHAIPE will also retain their IP addresses. While staticnodes will not have dynamic IP addresses, static nodes stillwill need to communicate with discovery servers to locateother static and mobile nodes.-Fixed Nodes

-Ship

Soldier

-Vehicle

-Aircraft

-Total

600000 ~-,.-----r---""---r--,

U) 500000 .....--...............I--...............~~~~~

CD

-g 400000~...........................,~~~z'0 300000 ........................................................"­CDE 200000 -+--...................,.....,..,.~::1

Z 100000 ~~r'~""""""'"

Each of the HAIPE@ node types has mobilitycharacteristics ranging from fast moving aircraft mountedHAIPEs to slow moving shipboard HAIPEs to staticHAIPEs. The physical mobility and the functional rangeof communications of the nodes are quantified below onlyto help to determine when nodes may be readdressed, andhence, when discovery actions are required. A node bothmay travel within one AOR retaining a single address andmay move between coverage areas requiring the HAIPECT IP interface to be readdressed. HAIPE mobilitycharacteristics are discussed below and are summarized inTable 1.

For vehicle-based nodes, the rate of motion may requiredevices to be readdressed with a frequency of once every10 minutes; however, the additional bandwidth and poweravailable in this environment makes the problem space lessdifficult than in the soldier-based node environment.

None

Once per monthUGS/IMS

Static Terrestrial Core

Table 1: HAIPE Mobilityr-----..~-:-.-:"""!'~~~ --.,..--~~.---,

Ship-based

Dismounted Soldier

Vehicle-based

Airborne

Once per day

Once per 30 minutes

Once per 10 minutes

Once per minute

The last, and most mobile, type of node is the airbornenode, which has mobility rates that could causereaddressing every minute. Additionally, airborneplatforms have power restrictions and bandwidthlimitations.

The first and most simple type of node is the static nodewhich has no mobility. Static HAIPE nodes will retain

These different types ofnodes and the interaction betweena tactical HAIPE peer discovery solution and a terrestrialHAIPE peer discovery solution is illustrated in Figure 4.

Page 4 of5

/

Figure 4: Tactical Networks

CONSIDERATIONS FOR HAIPE SERVER-TO­SERVER PROTOCOL

In addition to the mobility characteristics described above,there are several other parameters that need to beconsidered when designing a HAIPE® discovery serversolution for the DoD enterprise. Due to the size of theDoD enterprise, it is reasonable to assume that a givenHAIPE discovery server can neither store all HAIPE peerdiscovery information, nor process all of thequeries/updates as they occur. An enterprise levelarchitecture must be developed to optimize the discoveryinformation updates and to minimize the flow of queries.

In a tactical environment, the HAIPE discoveryarchitecture also has to scale dynamically as tacticalnetworks evolve with changing mission needs. Units mayenter an AOR and need to utilize services such as HAIPEdiscovery. These units will either have their discoverycapability integrated into the AOR or directly utilize anexisting HAIPE peer discovery capability. Similarly whena unit leaves an AOR, discovery information must beupdated as quickly as possible so that stale discoveryinformation is not promulgated through the network. Thisscaling must occur as seamlessly as possible. Dynamicscaling must also consider failover and redundancy.Tactical environments may experience asset losses orcommunications disruptions that must not prohibit servicessuch as HAIPE peer discovery from operating.

Given the diversity of the DoD enterprise, there may beseveral server-to-server protocols optimized for differentenvironments, resulting in distinct HAIPE peer discoverydomains. For example, a server-to-server discoveryprotocol for the core may be too bandwidth intensive fordisadvantaged tactical nodes to use. To ensure

interoperability between HAIPE peer discovery domains,there must be a consistent, well-defined interface that willallow differing server-to-server protocols to exchangediscovery information. This will allow users to discoverpeers across the entire DoD enterprise.

Multiple discovery servers will need to be deployed in theDoD enterprise due to storage limitations of a server andchanges in the network. First, all discovery informationcannot be stored on one server given the large number ofnetwork nodes. Second, when nodes are highly mobile,updates to the discovery server will occur more frequently.If only one server is used, the discovery information maychange several times before the information is updated atthe server. Hence, some discovery information may neverbe valid. More localized discovery servers will receiveand process the updates more quickly and will be able toprovide more accurate information to local HAIPEsrequesting discovery information.

SUMMARY

The DoD networks will consist of many nodes withdiverse characteristics. Node mobility will vary fromstatic to highly mobile. Also, bandwidth and poweravailability varies greatly over the different types of nodes.The HAIPE peer discovery solution must addressscalability, mobility, and constrained resource issues toallow all HAIPE nodes to locate all other peer HAIPEnodes in a dynamic and evolving network with a perceiveddelay that is acceptable to users. The next steps todeveloping a HAIPE peer discovery server based solutionare to gain a better understanding of the capabilities andlimitations of existing and planned networks, then toidentify the data that will need to be exchanged fromHAIPE to server and from server to server. This will leadto an interface definition and the selection or developmentof a protocol or set of protocols for the HAIPE peerdiscovery server architecture problem.

Page 5 of5