Each day millions of people around the world use tools with such strange
names as Morpheus, Bearshare/Gnutella, Freenet, and the notorious Napster.
The tools, collectively known as peer-to-peer (P2P) technologies, have
become the leading-edge way to exchange multimedia files over the Internet
but are largely unexplored for the exchange of structured information
or for government use. In a P2P system, each computer, called a node,
has the ability to function as both a client and a server. In practice,
the majority of users of P2P systems function as distributed clients
only. How Peer-to-Peer Systems Work by Paul
Silvey describes the general characteristics of P2P systems.
The ability to deliver and utilize timely, accurate information in
a secure manner is key to the success of any battlefield activity. Information
flowing through battlefield systems is used to determine the courses
of action in the battle; therefore, deployed forces need highly redundant
distributed systems that are hard to kill. Could P2P technologies offer
new capabilities for command and control systems in the battlefield
environment? Using file-sharing technologies as an illustration, this
article suggests how they might help to address the needs of military
users.
Examples of P2P Architectures
Napster
Napster allows users to share files in MP3 (Moving Picture Experts
Group, audio layer 3) format. Users download the Napster software, which
functions as both a client for performing searches for music files and
as a server for sharing selected files with the general Napster community.
When a registered user logs on to the Napster site, the client software
uploads to the Napster server a list and descriptions of the files the
user wants to share. When a user (the requester) searches for a file,
the query goes to the Napster server, which returns a list of “hits.”
The requester then selects which hit to retrieve and the client software
downloads the actual files directly from the user in the list associated
with that hit. The Napster servers never store the MP3 files themselves;
they simply associate filenames and descriptions with users who have
files to share.
The Napster architecture is thus partially centralized. The network
of Napster servers acts as a single point for all user queries; it points
users to their peers who have the files they want. Once the files are
downloaded into the requester’s machine, they are automatically
shared, making them more available to the overall user community.
Gnutella
Unlike Napster, Gnutella systems have no central server; in addition,
Gnutella is a protocol, not P2P software. It is supported by numerous
software packages, such as Bearshare, Limewire, and Todenode.
Users join a Gnutella network by connecting their Gnutella-compatible
software to any node or nodes in the network. When a user enters a query
for a file, the network sends the request to all nodes to which the
user’s software is directly connected. Each node checks if the
request matches any of the files it is sharing and responds to the requester;
it also forwards the request to each node to which it is directly connected,
and so on, until the request hop count is exceeded. Thus, a single request
can fan out to thousands of nodes, each of which will route its response
to the originating node along the reverse path of the request. Individual
nodes cannot know from whom the original request came, because they
send their response to the node making the request (i.e., directly connected
to them). Only the original node “knows” it is the final destination
of the response. Requesters select the source from which they would
like to receive the file and make a direct connection to that peer user.
Only then would the peer user know who (Internet Protocol [IP] address)
made the original request.
One interesting aspect of Gnutella networks is that node connections
change over time. More capable (i.e., higher bandwidth) nodes migrate
to the center of Gnutella networks because they support traffic needs
better. Thus, the network adapts to the capabilities of the nodes comprising
it. A Gnutella network is also highly resilient: the lack of central
control makes a Gnutella network very difficult to disrupt.
FastTrack (Morpheus)
Somewhere between Napster and Gnutella (topologically at least) lies
FastTrack, a semi-distributed P2P network. Morpheus, licensed by MusicCity
Networks from FastTrack, is a Gnutella-like network wherein individual
users forward queries to so-called peer “supernodes”-normal
nodes with processing and network capabilities superior to those of
other peer nodes. The supernodes then forward the request to all of
their directly connected nodes and supernodes. Selection and designation
of supernodes vary as the network evolves. Morpheus performs better
than a Gnutella network because traffic is focused through the supernodes.
Morpheus and FastTrack software also permits “intelligent downloading,”
in which a selected file can be simultaneously downloaded, or retrieved
piecemeal, from multiple nodes and rebuilt at the final destination.
The system automatically cancels the connections of nodes that perform
poorly during transfer and uses other nodes with better performance
to retrieve the missing file fragment. If a download is terminated for
any reason, it can be resumed later to complete the transfer.
Freenet
Freenet is a decentralized open-source P2P network. It allows users
to share information with confidence that the information will remain
private and unchanged.
In Freenet, users do not search for information. Instead, they use
encrypted keys to “tell” the network to retrieve a particular
file. The client software forwards the request key to a connected node
that either replies with the file or forwards the request to a directly
connected node that it determines might have the file associated with
the key. The request continues in this manner until either the hop count
is exceeded or a node determines that it has the file associated with
the key. That node then passes the entire file back to the node that
referred the request, and so on, until the originator’s node receives
the file. The file is cached at every node along the path of the request,
and stays in the cache until no further requests are received. Freenet
maintains the next hop of a similar key request in the cache for a longer
period of time to help route future requests.
In Freenet, user anonymity is stronger than in either Gnutella or Morpheus/FastTrack
because the actual file transfers are both encrypted and routed back
through the request route. One node on the network cannot be certain
where a request or a file transfer originates or terminates.
Data inserted in the Freenet network naturally migrates to where it
is requested most frequently, and is removable only through lack of
use. Information tends to be highly redundant in localized areas.
The Battlefield System Environment
MITRE has been involved in a variety of projects using P2P technology
for defense needs. These efforts range from analyzing security aspects
of the emerging P2P technologies for the North Atlantic Treaty Organization
(NATO), to Defense Advanced Projects Research Agency (DARPA) investigations
on collaboration technology (e.g., Groove) and network centric command,
control and intelligence (C2I), to potential use of P2P in Army Battle
Command Systems (ABCS). MITRE is helping to realize the potential of
P2P technology to enhance future battlefield systems.
How might battlefield systems benefit from applying P2P tools? Battlefield
systems generally have highly redundant, dynamic (ad hoc) network infrastructures,
and communication usually takes place over low-bandwidth “pipes.”
Both systems and networks need to be reliable and secure, and systems
should be quickly deployable and self-configuring or adapting. Because
the average soldier is not an engineer, systems should also be easy
for people with little technical training to support and understand.
Addressing conventions pose a continuing problem in battlefield systems.
Do you reference individual soldiers, units, machines, or platforms?
How do you reference them: by IP address, domain name, URN (uniform
resource name), or URL (uniform resource locator)? What happens when
they move around the battlefield, or when a unit or individual reattaches
to an existing unit or “split-jumps” from the original unit?
Battlefield systems must ensure the integrity and authenticity of information,
and control access to information. They must ensure that users are who
they say they are (authentication), and that authenticated users are
authorized to retrieve the information (authorization).
Battlefield systems are increasingly automated. Information is not
just retrieved, or “pulled:” instead, some information is
automatically distributed, or “pushed,” among battlefield
systems on the basis of domain-specific criteria.
Finally, information, like people, generally has a sphere of influence.
Some information is used, as is, by pockets of users. Other information
is refactored into other forms usable in other locales. For example,
situation awareness (e.g., location of friendly and enemy troops) has
different spheres of influence. Detailed information about individual
soldiers or platforms has critical value to others in the vicinity,
but higher echelons in the battlefield require such information to be
aggregated or “rolled up.” Battlefield systems must avoid
overloading users with information.
Matching P2P Capabilities with Battlefield Needs
No existing P2P system can provide the single solution to problems
faced in battlefield system environments. However, some of the key concepts
and aspects of available implementations may help to resolve certain
difficulties. For example, all of the P2P systems mentioned are easily
maintainable and self-configuring, and all allow any node simply to
attach to the network at either a central point or from anywhere. These
networks evolve without user intervention other than usage, so the maintenance
and robustness exhibited by P2P networks appear to correlate well with
battlefield requirements.
With regard to addressing, all P2P systems bypass traditional domain
name server usage. Each utilizes its own scheme for addressing: generally
mapping a user-defined ID to the current IP location of the user. If
a user relocates, simply connecting to the system creates a new association,
so the user can “float” in the network to other locations
with full functionality. This capability would be valuable for mobile
users, such as deployed Army units.
Node connections in some commercial P2P networks change over time.
More capable (i.e., higher bandwidth) nodes migrate to the center of
the networks because they support traffic needs better; thus the network
adapts to the capabilities of the nodes composing it. Such networks
are also highly resilient: the lack of central control makes them very
difficult to disrupt. These types of features, as well as the intelligent
downloading capabilities of Morpheus and FastTrack software, could potentially
make P2P networks especially valuable for MITRE’s military sponsors.
Of all the commercial systems currently available, few can ensure information
integrity and authenticity. Freenet, which uses encrypted keys, is one
of the most promising P2P technologies for these requirements. The very
nature of the network protects the key requests, data files, and even
user anonymity. However, managing keys remains a major issue, as does
discovering or sharing the keys used for making requests. Moreover,
unlike the other P2P technologies discussed, Freenet has no “search”
mechanisms that allow users to request metadata about files.
One aspect of Freenet with special relevance to the battlefield environment
is the natural migration of information to where the information is
most often requested. However, all current P2P systems are “pull”
technologies, whereas battlefield systems require automation, and “push”
services often are one aspect of automation. A “push-based”
Freenet would be an interesting prospect.
For more information, please contact Stanley Manoski
using the employee directory.
