Introduction to Windows Peer-to-Peer Networking
Published: January 01, 2003 | Updated: September 27, 2006
Abstract
This article provides an overview of peer-to-peer networking, including a description of peer-to-peer networking scenarios. This paper also describe the goals of Microsoft® Windows® Peer-to-Peer Networking and how it works, including detailed descriptions of IPv6 and NAT traversal, peer discovery and name resolution, graphing, grouping, replicated storage, and searching.
On This Page
Peer-to-Peer Networking Overview
Windows Peer-to-Peer Networking
How Windows Peer-to-Peer Networking Works
Summary
Related Links
Peer-to-Peer Networking Overview
Peer-to-peer networking is the utilization of the relatively powerful computers (personal computers) that exist at the edge of the Internet for more than just client-based computing tasks. The modern personal computer (PC) has a very fast processor, vast memory, and a large hard disk, none of which are being fully utilized when performing common computing tasks such as e-mail and Web browsing. The modern PC can easily act as both a client and server (a peer) for many types of applications.
The typical computing model for many applications is a client/server model. A server computer typically has vast resources and responds to requests for resources and data from client computers. Client computers initiate requests for resources or data from server computers. A good example of the client/server model of computing is Web browsing. Web servers on the Internet are typically high-end dedicated server computers with very fast processors (or multiple processors) and huge hard disk arrays. The Web server stores all of the content associated with a Web site (HTML files, graphics, audio and video files, etc.) and listens for incoming requests to view the information on a particular Web page. When a page is requested, the Web server sends the page and its associated files to the requesting client.
Peer-to-peer networking has the following advantages over client/server networking:
Content and resources can be shared from both the center and the edge of the network. In client/server networking, content and resources are typically shared from only the center of the network.
A network of peers is easily scaled and more reliable than a single server. A single server is subject to a single point of failure or can be a bottleneck in times of high network utilization.
A network of peers can share its processor, consolidating computing resources for distributed computing tasks, rather than relying on a single computer, such as a supercomputer.
Shared resources of peer computers can be directly accessed. Rather than sharing a file stored on a central server, a peer can share the file directly from its local storage.
Peer-to-peer networking solves the following problems:
Allows the processing resources of edge computers to be utilized for distributed computing tasks.
Allows local resources to be shared directly, without the need for intermediate servers.
Allows efficient multipoint communication without having to rely on IP multicast infrastructure.
Peer-to-Peer Networking Scenarios
Peer-to-peer networking enables or enhances the following scenarios:
Real-time communications (RTC)
Collaboration
Content distribution
Distributed processing
Improved Internet technologies
Real-Time Communications (RTC)
For RTC, peer-to-peer networking enables serverless instant messaging and real-time matchmaking and game play.
Serverless instant messaging
RTC exists today. Computer users can chat and have voice or video conversations with their peers today. However, many of the existing programs and their communications protocols rely on servers to function. If you are participating in an ad-hoc wireless network or are a part of an isolated network, you are unable to use these RTC facilities. Peer-to-peer technology allows the extension of RTC technologies to these additional networking environments.
Real-time matchmaking and game play
Similar to RTC, real-time game play exists today. There are many Web-based game sites that cater to the gaming community via the Internet. They offer the ability to find other gamers with similar interests and play a game together. The problem is that the game sites exist only on the Internet and are geared toward the avid gamer who wants to play against the best gamers in the world. These sites track and provide the statistics to help in the process. However, these sites do not allow a gamer to set up an ad-hoc game among friends in a variety of networking environments. Peer-to-peer networking can provide this capability.
Collaboration
For collaboration, peer-to-peer networking allows the sharing of a workspace, files, and experiences.
An example of a collaboration-based Windows Peer-to-Peer Networking application is Windows Meeting Space, which is included in Windows Vista. For more information, see Windows Meeting Space.
Project workspaces solving a goal
Shared workspace applications allow for the creation of ad-hoc workgroups and then allow the workgroup owners to populate the shared workspace with the tools and content that will allow the group to solve a problem. This could include message boards, productivity tools, and files.
Sharing your files with other people
A subset of project workspace sharing is the ability to share files. Although this ability exists today with the current version of Windows, it can be enhanced through peer-to-peer networking to make file content available in an easy and friendly way. Allowing easy access to the incredible wealth of content at the edge of the Internet or in ad-hoc computing environments increases the value of network computing.
Sharing your experiences
With wireless connectivity becoming more prevalent, peer-to-peer networking allows you to be online in a group of peers and to be able to share your experiences (such as a sunset, a rock concert, or a vacation cruise) while they are occurring.
Content Distribution
Peer-to-peer networking allows the distribution of text, audio, and video and software product updates.
Text messages
Peer-to-peer networking can allow for the dissemination of text-based information in the form of files or messages to a large group of users. An example is a news list.
Audio and video
Peer-to-peer networking can also allow for the dissemination of audio or video information to a large group of users, such as a large concert or company meeting. To distribute the content today, you must configure high-capacity servers to collect and distribute the load to hundreds or thousands of users. With peer-to-peer networking, only a handful of peers would actually get their content from the centralized servers. These peers would flood this information out to a few more people who send it to others, and so on. The load of distributing the content is distributed to the peers in the cloud. A peer that wants to receive the content would find the closest distributing peer and get the content from them.
Distribution of product updates
Peer-to-peer networking can also provide an efficient mechanism to distribute software such as product updates (security updates and service packs). A peer that has a connection to a software distribution server can obtain the product update and propagate it to the other members of its group.
Distributed Processing
Peer-to-peer networking allows computing tasks to be distributed and processor resources to be aggregated.
Division and distribution of a task
A large computing task can first be divided into separate smaller computing tasks well suited to the computing resources of a peer. A peer could do the dividing of the large computing task. Then, peer-to-peer networking can distribute the individual tasks to the separate peers in the group. Each peer performs its computing task and reports its result back to a centralized accumulation point.
Aggregation of computer resources
Another way to utilize peer-to-peer networking for distributed processing is to run programs on each peer that run during idle processor times and are part of a larger computing task that is coordinated by a central server. By aggregating the processors of multiple computers, peer-to-peer networking can turn a group of peer computers into a large parallel processor for large computing tasks.
Improved Internet Technologies
Peer-to-peer networking can also provide an improved utilization of the Internet and support new Internet technologies. Historically, the Internet was designed so that network peers can have end-to-end connectivity. The modern-day Internet, however, more closely resembles a client/server environment where communication in many cases is not end-to-end due to the prevalence of Network Address Translators (NATs).
This return to the original purpose of the Internet will enable the creation of a new wave of applications for personal communication and group productivity.
Windows Peer-to-Peer Networking
Windows Peer-to-Peer Networking is a developer platform to create peer-to-peer applications for computers running Windows XP with Service Pack 2, Windows XP Professional x64 Edition, Windows XP with Service Pack 1 and the Advanced Networking Pack for Windows XP, or Windows Vista™. The long-term goal of Windows Peer-to-Peer Networking is the following:
To enable people to communicate securely and share information with one another without a dependence on centralized servers, but to work even better when servers are present.
Computers running Windows Vista already have Windows Peer-to-Peer Networking installed. For computers running Windows XP with SP2, do the following to install Windows Peer-to-Peer Networking:
Click Start, click Control Panel, and then click Add or Remove Programs.
Click Add/Remove Windows Components.
In Components, click Networking Services (but do not select its check box), and then click Details.
Select the Peer-to-Peer check box, and then click OK.
Click Next, and then follow the instructions in the wizard.
For computers running Windows XP with Service Pack 1 (SP1), you can install Windows Peer-to-Peer Networking with the Advanced Networking Pack for Windows XP, a free download.
The design of Windows Peer-to-Peer Networking incorporates the following principles:
Secure
Scalable
Distributed
Serverless
Robust in the face of failure and/or attack
Self-tuning
Self-repairing
How these design principles were achieved is described throughout this paper.
Windows Peer-to-Peer Networking and DNS
Another point of contrast between client/server and peer-to-peer networking is the use of the Domain Name System (DNS). Server computers are typically registered in DNS so that client computers can resolve a name to the IP address of the server computer. Client computers are typically not registered in DNS for the following reasons:
Many client computers have transient connectivity; they connect for unpredictable amounts of time and can be assigned a new IP address for each connection.
Client computers do not have shared resources and do not respond to requests for resources. Therefore, other computers do not need to resolve the names of client computers. DNS address records for client computers are not necessary.
Peer computers, on the other hand, have resources to share. However, they still have transient connectivity. Peer computers could use DNS dynamic update to register their names, however, very few DNS servers on the Internet support DNS dynamic update. To be successful for peer-to-peer networking, peer computers must not rely on the existing DNS infrastructure. Therefore, there must be a mechanism to resolve peer names to their addresses that does not rely on DNS. For Windows Peer-to-Peer Networking, this mechanism is Peer Name Resolution Protocol (PNRP) and is described in Peer Name Resolution Protocol.
Windows Peer-to-Peer Networking Security
In a peer environment, there are no centralized servers with security databases or that can provide typical security services such as authentication and authorization. For example, in an Active Directory domain, domain controllers provide authentication services using Kerberos. In a serverless peer environment, the peers must provide their own authentication.
For Windows Peer-to-Peer Networking, authentication is provided using self-signed certificates, some of which are formatted as X.509 certificates. Although one usually thinks of X.509 certificates in relation to a public key infrastructure (PKI) that contains a hierarchy of certification authorities (CAs), self-signed certificates are certificates that are created by each peer. Peer networking allows any node to act as a CA and removes the requirement that the root certificate to be deposited in each peer's trusted root store. Each peer generates the public key/private key pair and the certificate that is signed using the private key. The self-signed certificate is used for authentication and to provide information about the peer entity. Like X.509 authentication, peer networking authentication relies upon a chain of certificates tracing back to a public key that is trusted.
For more information about authentication for Windows Peer-to-Peer Networking, see the "Grouping" section of this article.
How Windows Peer-to-Peer Networking Works
In this section, we briefly describe the Windows Peer-to-Peer Networking architecture and then describe the details of the fundamental peer-to-peer capabilities of peer discovery and name resolution, graphing, grouping, replicated storage, and searching.
Windows Peer-to-Peer Networking Architecture
The architecture of Windows Peer-to-Peer Networking in Windows XP is shown in Figure 1.
.gif "Figure 1: Windows Peer-to-Peer Networking architecture")
Figure 1: Windows Peer-to-Peer Networking architecture in Windows XP
Windows Peer-to-Peer Networking architecture consists of the following components:
Graphing The Graphing component is responsible for maintaining a set of connected nodes known as a graph and providing flooding and replication of data across the graph. The Graphing component uses the Flood & Synchronization, Store, and Graph Maintenance subcomponents.
Grouping The Grouping component is the security layer provided by default on top of a graph. The security layer defines the security model behind group creation, invitation, and connection to the group. In addition, Grouping leverages PNRP as the name resolution protocol - and enables multiple applications to share the same graph. The Grouping component uses the Group Security and Group Security Service Provider (SSP) subcomponents.
NSP The Name Service Provider (NSP) component provides a mechanism to access an arbitrary name service provider. In the case of Windows Peer-to-Peer Networking, peer-to-peer applications use the NSP interface to access PNRP.
PNRP The PNRP component provides peer-to-peer name resolution.
Identity Manager Identity manager enables the creation and management of peer-to-peer identities.
Microsoft TCP/IP version 6 protocol The Microsoft TCP/IP version 6 protocol (IPv6) provides the transport over which Windows Peer-to-Peer Networking operates.
The details of how Windows Peer-to-Peer Networking works are described in the following sections:
IPv6 and NAT traversal
Name resolution and peer discovery with PNRP
Graphing
Grouping
Replicated store
Searching
IPv6 and NAT Traversal
Windows Peer-to-Peer Networking uses IPv6 as its Internet layer. IPv6 was chosen because it restores the end-to-end computing model to networking. With IPv6, there are no issues with address shortage that require the use of Network Address Translators (NATs). For more information about how NATs translate addresses and port numbers and use port mappings, see Windows 2000 Network Address Translator (NAT). NATs for IPv4 extend the lifetime of the IPv4 public address space, but at the expense of breaking end-to-end communication.
IPv6 support was included in Windows XP with no service packs as a developer preview edition. A production-quality release of an IPv6 protocol is available in Windows XP with SP1, Windows XP with SP2, the Windows Server 2003 family, Windows Vista, and Windows Server Code Name “Longhorn” (now in beta testing). A common misconception about IPv6 is that the existing IPv4 infrastructure (your intranet and the Internet) must be upgraded to support IPv6 before it can be used. This is not true. The designers of IPv6 realized that IPv4 infrastructures will be in place for the foreseeable future and created a series of transition technologies that allow IPv6 traffic to be sent over an IPv4 network by encapsulating an IPv6 packet with an IPv4 header.
The two transition technologies that are recommended for use and enabled by default for the IPv6 protocol for Windows are the following:
Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
ISATAP is an address assignment and automatic tunneling technology that is used to provide unicast IPv6 connectivity between IPv6 hosts across an IPv4 intranet. ISATAP is described in RFC 4214.
6to4
6to4 is an address assignment and automatic tunneling technology that is used to provide unicast IPv6 connectivity between IPv6 sites and hosts across the IPv4 Internet. 6to4 is described in RFC 3056.
For more information about ISATAP and 6to4 in Windows, see the IPv6 Transition Technologies white paper.
For IPv6 connectivity across the IPv4 Internet, 6to4 is the preferred address assignment and tunneling technology. However, 6to4 depends on the assignment of a public IP address to a computer connected to a private network that acts as a 6to4 router. The IPv6 protocol for Windows XP and the Windows Server 2003 family can be used as a 6to4 router either automatically by enabling Internet Connection Sharing (ICS) or through manual configuration. Many Network Address Translators (NATs) that are used to connect small office or home office networks to the Internet do not yet have 6to4 router capability. Additionally, there might be more than one NAT between a host on a private network and the IPv4 Internet, in which case 6to4 would not work even if the NAT connected to the private network had 6to4 functionality. Another issue with NATs is their default inability to forward traffic that does not use either TCP or UDP. IPv6 over IPv4 traffic uses protocol 41. If this type of traffic is not recognized by the NAT, it is discarded.
To address the need for an IPv6 over IPv4 address assignment and tunneling solution that works for hosts that are located across NATs that cannot also be 6to4 routers, Microsoft is working with the Internet standards bodies to define Teredo, also known as IPv6 NAT Traversal (NAT-T). Teredo is defined in RFC 4380.
Teredo works by assigning global IPv6 addresses that are based on the public IPv4 address of the NAT interface that is connected to the Internet and then encapsulating IPv6 packets with both an IPv4 header and a UDP header. By using both an IPv4 and a UDP header, most NATs can translate Teredo traffic.
Teredo client support is included with Windows XP SP2, Windows XP Professional x64 Edition, Windows Server 2003 Service Pack 1, Windows Vista, and Windows Server “Longhorn.” For computers running Windows XP with SP1, you must install the Advanced Networking Pack for Windows XP.
For additional information about how Teredo works, see Teredo Overview.
Name Resolution and Peer Discovery with PNRP
In order for communication to occur between peers, they must be able to discover each other's presence and resolve each other's network locations (addresses, protocols, and ports) from names or other types of identifiers. How peers discover each other and resolve each other's names for communication is complicated by transient connectivity and the lack of address records in DNS.
Windows Peer-to-Peer Networking solves this problem with a name resolution and peer discovery protocol known as the Peer Name Resolution Protocol (PNRP). For more information, see Peer Name Resolution Protocol.
Graphing
A peer graph, or graph, is a set of nodes that are multiply connected to form a coupled network of nodes for the purposes of propagating data in the form of records or point-to-point data streams. Another way to think of a graph is as a collection of peer graph nodes connected such that any peer graph node may communicate with all other graph nodes via a series of logical neighbor connections. A peer graph node is a peer connected to a peer graph.
A peer graph is built and based on flooding. Flooding is the process of propagating a record to all users connected to a graph. A flooding protocol is used to do the following:
Propagate the addition of new records to all the nodes of the graph.
Propagate the updates of changed records to all nodes of the graph.
Propagate the deletion of deleted records to all the nodes of the graph.
To perform these functions, each flooded record that is identified by a globally unique identifier (GUID), has an increasing version number or sequence number, and is further qualified by an age or a status.
In addition, a synchronization process ensures that peers have the same set of records, which can result in the flooding of more records.
A well-connected graph has the following properties:
It is connected. There is a path between any two nodes,
It has a small diameter. There are a relatively small number of hops between the nodes on the farthest edges of the graph. The benefit to a small diameter is that updates are propagated rapidly to all graph nodes.
It is robust. The graph remains connected even if some nodes or some connections disappear.
A graph is built based the connections of neighbors. A neighbor in a graph is a peer graph node that is one graph hop away (is directly connected via a TCP connection). A graph hop is a logical connection that operates above the Internet layer, and can therefore be one or multiple router hops away.
A node ID is a random number a peer graph node chooses when they connect to a peer graph. The node ID should be unique across the graph. A graph is identified by a graph signature, which is the lowest node ID of all graph nodes connected to a peer graph. The graph signature is used to detect breaks in the graph known as partitions.
Graph Maintenance
The flooding protocol already defines how information is flooded throughout the graph. The graph maintenance protocol defines how the group evolves to maintain robust connectivity and to maintain a small diameter. This is done through the following:
A signature procedure computes the signature of a group. If the group is partitioned, each of the partitions will have a different signature. This can be used to detect that two or more partitions need to be repaired. Designated nodes in the graph known as contacts keep track of the signature records. Contacts are elected randomly.
A reconnection procedure allows nodes to establish appropriate connections.
A disconnection procedure allows nodes to leave a graph without creating a hole in the graph.
When information is flooded across the graph, a graph node that has multiple connections will receive multiple copies of it. To decide which connections to keep and which to remove, a graph node evaluates flooded information and calculates a bidirectional utility index, a number used to indicate the usefulness of the information sent between given connected peers. The utility index has a low value when the information sent across the connection has been consistently previously received and is of no value.
On an ongoing basis, based on the current utility index and the information that is received during the flooding, peer nodes make adjustments in their connections to neighboring nodes. Connections are created and removed so that the graph converges to a topology that is optimal for flooding for the current traffic pattern.
Connecting to a Graph
When initially connecting to a graph, a peer node connects to a node that is already connected to the graph. The peer node determines the address of the peer node connected to the graph through any method to resolve the IP address of a graph node, such as DNS or the peer discovery and name resolution methods as described in Peer Name Resolution Protocol.
If the selected peer node has less than the maximum allowable number of graph connections to neighbors, it will send an accept response. If it has already reached the maximum number, it will send a rejection response. In the rejection response is a referral list, a list of other nodes in the graph. The peer node attempting to connect to the graph that receives the rejection response picks at random a peer graph node in the referral list, and tries to connect to it.
The process to pick a new neighbor after connecting to the graph is the same. The reject message from the tentative new neighbor contains a referral list. The peer node attempting to connect to a new neighbor that receives the rejection response picks at random a peer graph node in the referral list, and tries to connect to it.
Disconnecting from a Graph
When a node disconnects from a graph, it sends a disconnect message. This can potentially create a graph partition. The disconnect message carries a referral list, which includes all neighbors except the node being disconnected from. When a node receives a disconnect message from a neighbor, it should try to reconnect to peer in the referral list.
Detecting and Repairing a Graph Partition
As nodes connect and disconnect from graphs, partitions in the graph may occur. For each graph there is a graph signature and one or more contacts. The number of contacts for the graph is proportional to the size of the graph. Peers can belong to multiple graphs. The contact and graph signature information is flooded to all the nodes of the graph. The contact and graph signature information is refreshed periodically. If the contact and graph signature information becomes stale, a partition has occurred. When this is detected, an attempt to communicate with the contact node is made. If successful, an attempt is made to reconnect the graph.
Graph Partition Repair Example
To provide an example of a graph partition, let's build a graph and then examine the information that is exchanged to detect the partition and to repair it.
Building an Example Graph
The following process describes how a graph is built:
We start our graph (Graph X) with a single node, Node A. Node A has the node ID 2. Node A creates a Signature record for the Graph X with graph signature of 2. Node A also creates a Contact record for Graph X/Node A with graph signature of 2.
Node B joins the graph. Node B has node ID 1 and connects to Graph X via Node A. Node B gets Node A's record database, which consists of the Signature record for the graph and the Contact record for Node A.
Node B notices that the graph signature for Graph X is higher than its own node ID. The graph signature for Graph X should be 1, rather than 2.
Node B floods a new Signature record for Graph X with graph signature of 1 to Node A. Node A updates its record database with the new Signature record from Node B.
Node A checks its own Contact record. Node A notices that its own Contact record has a graph signature set to 2, when it should be set to 1, the new graph signature for Graph X.
Node A changes the graph signature of its own Contact record to 1 and floods a new copy of its Contact record to Node B.
Node B updates its Contact record for A with the new graph signature of 1.
Note
Graph records contain a digital signature and cannot be altered. However, they can be replaced. Therefore, the use of the term "update" in this discussion refers to the replacement of a record with a record containing a higher version number, rather than the changing of the record's contents.
At this point, the graph records have been synchronized and the graph topology has converged. Both Node A and Node B have the same information in their record databases for the graph: a Signature record with the graph signature set to 1 and a Contact record for Node A with the graph signature set to 1.
Node C, with the node ID of 5, connects to Graph X via Node B. After connecting to Node B, Node C gets Node B's record database, consisting of the Signature record and the Contact record for Node A. Once again, the graph has converged: Node A, Node B, and Node C have the same information in their record databases for Graph X.
Over time, separate graph connection forms between Node C and Node A to form a fully interconnected graph.
Let's jump ahead to Graph X with 6 nodes as shown in Figure 7.
.gif "Figure 7: Example Graph X with six nodes")
Figure 7: Example Graph X with six nodes
Graph X consists of Node A (node ID 2), Node B (node ID 1), Node C (node ID 5), Node D (node ID 7), Node E (node ID 8), and Node F (node ID 9), with Node A and Node D as contacts.
The graph topology has converged. All the nodes have the same record database: a Signature record with graph signature of 1, a Contact record for Node A with graph signature of 1, and a Contact record for Node D with graph signature of 1. The Signature record has a valid lifetime of 5 minutes and is periodically refreshed (within 5 minutes) by Node B. The Contact records also have valid lifetimes and are periodically refreshed.
Repairing the Graph Partition
The graph connection between Node A and Node E is severed. The following process repairs the partition:
In the bottom partition of the graph—consisting of Node D, Node E, and Node F—the Signature record expires after a maximum time of 5 minutes because the refreshed Signature record sent by Node B is not propagated to nodes in the bottom partition.
When the current Signature records expires, all the nodes in bottom partition of the graph calculate a random backoff delay that is proportional to their node IDs before flooding a new Signature record with their own node ID. Because Node D has lowest node ID, it floods a new Signature record with graph signature of 7 first. Node E and Node F receive the new Signature record and update their own Signature records.
Node D updates its own Contact record with a graph signature of 7 and floods that new record to Node E and Node F. As the information is propagated to the graph nodes, each notes that the Contact record for Node A with a graph signature of 1 does not match the Contact record for Node D with graph signature of 7. To resolve the inconsistency, each node calculates a random backoff delay. After the delay, the node will attempt to connect with Node A to repair the partition. For this example, the delay for Node D is less than the delay for Node E or Node F. Node D connects with Node A.
Node A and Node D exchange records. Node D notes that Node A sent it a new Signature record with graph signature of 1, which is lower than the current graph signature. Node D floods the new Signature record with graph signature of 1 to Node E and Node F.
Node D updates its own Contact record for Node D with graph signature of 1 and floods the updated Contact record for Node D with graph signature of 1 to Node E and Node F. Then, Node D floods the new Contact record for Node A with graph signature of 1.
The graph has converged. All the nodes in the graph have the same set of graph records: a Signature record with graph signature of 1, a Contact record for Node A with graph signature of 1, and a Contact record for Node D with graph signature of 1.
If Node D, Node E, or Node F were not able to establish a graph connection with Node A or any other node in the upper partition (consisting of Node A, Node B, and Node C) due to network reachability problems, then two graphs would exist. There is another process to perform long-term partition repair.
The detection of a graph partition is based on the expiration of the Signature record. The repair of the graph partition is based on the attempts to correct inconsistencies between the graph signature in the current Signature record and the graph signature in contact records. New connections are attempted to those contacts that have incorrect graph signatures in their Signature records. These new connections and the ensuing graph record synchronization repair the graph. Over time, using normal graph maintenance, the optional topology for flooding is obtained automatically.
Graph Security
Graphs are merely the association of a group of nodes with connections that define a topology for flooding. They are by themselves unsecured. Windows Peer-to-Peer Networking provides an architecture that allows pluggable modules for the security of the graph. A specific security module can define:
Who can connect and send data to the graph (connection authentication, confidentiality, and integrity)
How the traffic sent over the graph is encrypted (message/record confidentiality)
How the traffic sent over the graph is validated (message/record integrity)
Windows Peer-to-Peer Networking provides a single graph security provider named the Microsoft Peer Grouping.
The Windows XP Peer-to-Peer SDK provides APIs to develop your own graph security provider. For more information, see the topic titled "Adding Security for a Peer Graph" on the Microsoft Developer Network.
Grouping
Grouping is the combination of PNRP, peer graphing, and the Microsoft Peer Grouping security provider. The Microsoft Peer Grouping security provider provides the following:
The management of the credentials of the members of a group
The secure publication of records in a group
A unique group ID identifies every group. This group ID is used by group members to differentiate between different groups for which the local machine is a member, and also for identification of groups between different peers. Groups use secured peer names, as defined for PNRP, as group IDs.
For secure groups, participation is restricted to a set of users known as group members. Every group member has an identity, a unique peer name, and credentials that prove the ownership of the group member's identity. Every group member also has credentials to prove they are a member of a group.
Information in the form of records is securely flooded throughout a group. A record contains the following:
The publishing member identity
Data to prove record validity
A validity time
A payload that contains the record information
The security provided by Windows Peer Grouping is a combination of the following:
Peer names
Group membership certificates (the credentials associated with peer names)
Roles (member and administrator)
Secure publishing
Security policies
Secure connections
Peer Names
As described in Peer Name Resolution Protocol, secured peer names are only registered by their owner and are protected with public key cryptography. Unsecured peer names can be as small as 3 characters long. Secured peer names must be at least 40 characters long. No peer name can be greater than 191 characters long, plus a NULL character.
A secured peer name is considered owned by the peer entity having the corresponding private key. Ownership can be proved via the CPA, which is signed using the private key. A malicious user cannot forge ownership of a peer name without the corresponding private key.
Group security uses a peer name to identify each member of the group. Peer names are statistically unique. Group security also uses a peer name to identify a group. When a group is created, a new public/private key pair for the group is created, upon which the group peer name is based. The member that owns the private key corresponding to the peer name of the group is the group owner.
Group Membership Certificates (GMCs)
To participate in a group, every member must have credentials that are used to prove group membership when performing group functions such as connecting to a group or publishing records in a group. These credentials are X.509 certificates known as group membership certificates, or GMCs. The characteristics of the GMC are the following:
The Subject field of the GMC is a peer name identifying the member.
To prove ownership of a GMC, the member presenting it must prove ownership of the peer name contained in the certificate. Ownership of the peer name is based on the knowledge of the private key corresponding to the peer name. Credential ownership can easily be verified using a simple challenge.
For a trusted X.509 certificate, the certificate chain leads to a self-signed root certificate whose authority is trusted.
For a GMC to be validated, it should be a leaf certificate descended from a trusted authority. A group is identified by the group’s peer name. A group peer name can thus be trusted, and hence, can act as a trusted authority that can issue X.509 certificates. When the group peer name is used as the root authority, it is easy to verify that the key used to sign the root certificate is the group’s private key. Hence, any certificate chain that leads to the self-signed root certificate of the group is trusted. Such a root certificate should contain: Subject: group peer name, Issuer: group peer name, and be signed using the group private key. Such a self-signed root certificate is known as a group root certificate, or GRC.
In X.509 certificates, authority to issue certificates can be delegated to trusted sub-authorities.
The load of issuing member GMCs can be distributed to additional group members known as administrators. Administrators can further delegate this responsibility, if authorized by the group’s security policy.
Like any other X.509 certificate, GMCs have a validity period.
A GMC is considered invalid any time outside that validity period. A group member maintains membership in the group by renewing its GMC before it expires.
Note: Windows Peer-to-Peer Networking GMCs use certificate properties differently than X.509. The Subject Name property in a GMC is a meaningless friendly name and the Subject Alternative Name property is used to store the actual peer name of the certificate subject.
Secure Publishing
A group database contains information published by group members. Apart from the member-published information it also contains security information. Both regular and security-related information has to be secured. Group security provides data integrity and authorization for secure publishing:
Data integrity
The records published in the group carry security data. This security data contains the cryptographic signature of the record contents (including the payload and parts of the header). This enables detection of record tampering. Only explicitly authorized group members can update records published by other group members without making those records invalid.
Authorization
Not all members are authorized to publish all kinds of records, and not all members are allowed to update records published by other group members. Therefore, it is required to check for authorization that the publisher had the right to publish records, and that the signer had the right to sign the record. This authorization is done against the privileges that the publisher and signer have.
The signer information included in the security data is the peer name of the signer and the signer’s GMC serial number. Because roles present in the GMC give authority to publish records, a serial number is included along with other security data to ensure that verification of authorization is done against the right set of roles. A single group member can have multiple valid GMCs. The most common cause is when a GMC with different roles is issued to a member before their current GMC expires.
Publishing GMCs
A GMC contains most of the information required for any verification that needs to be done for that group member (for example, public key for signatures, roles for authorization etc.) Verification of information published by a group member requires that group member’s GMC. The publication of the GMC is done automatically on the user's behalf at an appropriate time. This allows others to verify information that the member publishes using this GMC. If the user’s current GMC is already published, it doesn’t need to be published again when publishing additional records.
Security Policies
The group creator will want to have some control over the behavior of group security. For example, the group creator will want to control whether administrators can make other users administrators, etc. This level of control is provided by different configurable security policies. During any kind of verification, these security policies are consulted before doing any further complex cryptographic checks.
Secure Connections
Secure connections are established between a graph’s members using Security Service Providers (SSPs). The SSP used for groups is known as the P2P Group Connect Protocol SSP. The credential used for establishing connection is the GMC of the group member. A member’s GMC chain can be renewed and locally deposited as part of normal operation of establishing a connection.
Group Processes
This section describes the following group processes:
Creating a group
Joining a group
Creating a Group
An application on a peer node creates a group by:
Creating a Group Root Certificate (GRC), signed with a private key owned by the group owner
The GRC is a different self-signed certificate than the identity certificate, also owned by the group owner.
Registering the group ID of the group with PNRP
Configuring a set of group security policies
The group security policies define the behavior of group security.
Issuing invitations
An invitation is an XML blob containing invitation parameters and a GMC for the tentative group member.
Joining and Connecting to a Group
To join a group, a peer node must first receive an invitation from the group owner. To receive an invitation from the group owner, the tentative group member must first pass identifying materials to the group owner, which are the peer name and its public key. This information is passed using an out-of-band process such as email, file sharing, XML, etc. The group owner then issues the invitation to the tentative group member.
Upon receipt of the invitation, the tentative group member uses the invitation information to connect to the graph for the group. To connect to the group, the tentative group member uses PNRP and the group ID to resolve the address of a group member. Typically each user will have an identity certificate (IDC). The IDC is used for the initial secure TLS channel that is established with a current group member.
Mutual authentication between the tentative group member and the current group member occurs. Both the tentative group member and the current group member trust GMC certificate chains that chain up to the group owner's GRC. This trust is in the context of the peer group, for peer group activities. The tentative group member passes the leaf GMC (with the same identity as that in the IDC) it received in the invitation to the current group member. The current group member verifies that the GMC of the tentative group member has a valid chain of certificates up to the GRC for the group. The current group member passes its leaf GMC to the tentative group member. The tentative group member verifies that the GMC of the current group member has a valid chain of certificates up to the GRC for the group.
After mutual authentication, the tentative group member is now a new group member that has a single neighbor, the graph node that accepted the connection and with which the authentication occurred. The new group member gets the current set of records for the group from the current group member.
Over time, the new group member uses graphing to establish multiple neighbor connections and optimize the shape of the underlying group graph for flooding.
Replicated Store
The replicated store is the set of records associated with a graph that are securely published and synchronized between all the members of the group. The replicated store represents the view of the group data, which should be the same for all group members. Graphing ensures that records are propagated to all nodes. Grouping prevents unauthorized records from being propagated throughout the graph. Record replication between group members uses SSL to provide encryption and data integrity for record data.
When a new group member joins the group, they automatically receive all the group records from the current group member to which they attach. After the initial synchronization, group members periodically resynchronize their replicated stores to ensure that all group members consistently have the same view.
After joining the group, applications can register new record types and begin publishing them using the security of the group. When an application publishes a new record, the security mechanisms for the group are applied to the record and it is published securely. New records published by applications are automatically flooded to all group members.
Applications can also register interest in receiving all the records of a specific record type. When the record is received, the application is notified and the record data is passed to the application. For example, a group chat application can register interest in receiving all chat records types so that it can monitor the chat activity within the group and notify the user appropriately.
Searching
Searching is the mechanism for locating data within the group. There are two different search models:
A local search searches the replicated store, the set of local records for the group. In a local search, a group member does not send search queries to other group members.
A distributed search sends queries to group members. Windows Peer-to-Peer Networking does not yet support distributed searches, however the architecture of Windows Peer-to-Peer Networking does allow you to develop distributed searching components and capabilities.
For Windows Peer-to-Peer Networking, the local search includes the use of the common logical operators AND and OR, and the use of "not equal". Because all group records have a common set of fields, you can perform keyword searches on these fields. Group records can also have a set of attributes, which are extensible metadata that describe the record. As long as the schema for the included attributes is followed, you can also search on the information in the record attributes.
Summary
Windows Peer-to-Peer Networking is a new platform supported by Windows XP and Windows Vista that allows better utilization of PC computing resources and the creation of a new wave of peer applications for RTC, collaboration, content distribution, distributed processing, and improved Internet technologies. Windows Peer-to-Peer Networking uses IPv6, which restores the end-to-end computing model. With Teredo, IPv6 nodes can even communicate across one or more IPv4 NATs. For a serverless name resolution and peer discovery mechanism, Windows Peer-to-Peer Networking uses PNRP. To associate peer members together to securely share data, Windows Peer-to-Peer Networking uses graphing (for an efficient flooding topology) and grouping (for authentication and secure communication). Group members maintain a replicated store containing all the shared data of the group and can search the store using keywords, attributes, and common logical operators.
Related Links
See the following resources for additional information: