Network Working Group S. Baset
Internet-Draft H. Schulzrinne
Intended status: Standards Track Columbia University
Expires: May 22, 2008 M. Matuszewski
Nokia
November 19, 2007
Peer-to-Peer Protocol (P2PP)
draft-baset-p2psip-p2pp-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 22, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Baset, et al. Expires May 22, 2008 [Page 1]
Internet-Draft Peer-to-Peer Protocol November 2007
Abstract
This document defines the Peer-to-Peer Protocol (P2PP), an
application-layer binary protocol, for creating and maintaining an
overlay of participant nodes. The overlay can be created using
various structured and unstructured peer-to-peer protocols such as
Bamboo, Chord, Pastry, Kademlia, Gnutella, and Gia. P2PP uses a
secure transport, supports an application API, has mechanisms for NAT
and firewall traversal, exchanging node capabilities, and diagnostic
information. P2PP is designed to support a P2P Session Initiation
Protocol (SIP) network, but it can be used for other applications as
well.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. High-Level Requirements . . . . . . . . . . . . . . . . . 10
3.2. Node Model . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. P2PP Node Stack . . . . . . . . . . . . . . . . . . . 12
3.3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4. Message Model . . . . . . . . . . . . . . . . . . . . . . 15
3.5. Reliability Model . . . . . . . . . . . . . . . . . . . . 16
3.6. Security Model . . . . . . . . . . . . . . . . . . . . . . 18
3.6.1. Threat Model . . . . . . . . . . . . . . . . . . . . . 19
3.7. NAT and Firewall Traversal . . . . . . . . . . . . . . . . 20
3.8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.8.1. Peer Mobility . . . . . . . . . . . . . . . . . . . . 20
3.8.2. Client Mobility . . . . . . . . . . . . . . . . . . . 21
3.8.3. Session Mobility . . . . . . . . . . . . . . . . . . . 22
3.9. Overview of Operations . . . . . . . . . . . . . . . . . . 22
3.9.1. Enrollment, Authentication, and Bootstrap . . . . . . 22
3.9.2. Overlay Maintenance . . . . . . . . . . . . . . . . . 23
3.9.3. Data Storage and Retrieval . . . . . . . . . . . . . . 24
3.9.4. Connection Management and Other . . . . . . . . . . . 24
3.10. Overlay Migration . . . . . . . . . . . . . . . . . . . . 25
4. Overlay Layer . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1. Peer State . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2. Key Components of a P2PP Message . . . . . . . . . . . . . 27
4.3. Request, Response, and Indications Processing . . . . . . 29
4.3.1. ACK generation . . . . . . . . . . . . . . . . . . . . 32
4.3.2. Recursive and Iterative Routing . . . . . . . . . . . 33
4.4. Message Encoding Guidelines . . . . . . . . . . . . . . . 35
4.5. Enrollment and Authentication . . . . . . . . . . . . . . 36
4.5.1. HTTP Digest Authentication . . . . . . . . . . . . . . 37
4.5.2. Authentication without a Central Authority . . . . . . 38
Baset, et al. Expires May 22, 2008 [Page 2]
Internet-Draft Peer-to-Peer Protocol November 2007
4.6. Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . 38
4.7. Joining, Leaving . . . . . . . . . . . . . . . . . . . . . 38
4.7.1. Join . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.7.2. Leave . . . . . . . . . . . . . . . . . . . . . . . . 41
4.8. Publish, LookupObject, LookupPeer . . . . . . . . . . . . 42
4.8.1. Publish . . . . . . . . . . . . . . . . . . . . . . . 42
4.8.2. LookupObject . . . . . . . . . . . . . . . . . . . . . 42
4.8.3. LookupPeer . . . . . . . . . . . . . . . . . . . . . . 43
4.9. Maintenance . . . . . . . . . . . . . . . . . . . . . . . 43
4.9.1. Node Timers . . . . . . . . . . . . . . . . . . . . . 44
4.10. Replication . . . . . . . . . . . . . . . . . . . . . . . 44
4.11. Capabilities and Diagnostics . . . . . . . . . . . . . . . 45
5. P2PP Processing . . . . . . . . . . . . . . . . . . . . . . . 46
5.1. Resources and Services . . . . . . . . . . . . . . . . . . 46
5.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 47
5.2.1. NAT Traversal Service Advertisement and Discovery . . 48
5.2.2. Gathering of Candidates and NAT Behavior Discovery . . 48
5.2.3. Communicating with a Peer Behind a NAT . . . . . . . . 48
5.2.4. Maintenance of NAT Bindings . . . . . . . . . . . . . 49
5.2.5. Load Balancing for Media Flows . . . . . . . . . . . . 49
5.2.6. ICE Overhead . . . . . . . . . . . . . . . . . . . . . 49
5.3. Route Log . . . . . . . . . . . . . . . . . . . . . . . . 50
5.4. P2PP and SIP . . . . . . . . . . . . . . . . . . . . . . . 50
6. Transport Layer . . . . . . . . . . . . . . . . . . . . . . . 51
6.1. Transaction Identifier . . . . . . . . . . . . . . . . . . 51
6.2. Message State Machine . . . . . . . . . . . . . . . . . . 51
6.2.1. State Machine for Unreliable Transports . . . . . . . 51
6.2.2. State Machine for Reliable Transports . . . . . . . . 53
6.3. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7. Security Considerations . . . . . . . . . . . . . . . . . . . 56
7.1. Routing Security . . . . . . . . . . . . . . . . . . . . . 56
7.1.1. Peer-ID Assignment . . . . . . . . . . . . . . . . . . 56
7.1.2. Message Forwarding and Message Integrity . . . . . . . 56
7.1.3. Routing and Neighbor Table Management . . . . . . . . 56
7.1.4. Admission Control . . . . . . . . . . . . . . . . . . 56
7.1.5. Residual Attacks . . . . . . . . . . . . . . . . . . . 57
7.2. Storage Security . . . . . . . . . . . . . . . . . . . . . 57
7.2.1. Integrity . . . . . . . . . . . . . . . . . . . . . . 57
7.2.2. Permissions . . . . . . . . . . . . . . . . . . . . . 57
7.2.3. Quota . . . . . . . . . . . . . . . . . . . . . . . . 57
7.2.4. Residual Attacks . . . . . . . . . . . . . . . . . . . 57
8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 58
8.1. Enroll . . . . . . . . . . . . . . . . . . . . . . . . . . 58
8.2. Authenticate . . . . . . . . . . . . . . . . . . . . . . . 58
8.3. Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . 59
8.4. Join . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
8.5. Leave . . . . . . . . . . . . . . . . . . . . . . . . . . 60
8.6. KeepAlive . . . . . . . . . . . . . . . . . . . . . . . . 60
Baset, et al. Expires May 22, 2008 [Page 3]
Internet-Draft Peer-to-Peer Protocol November 2007
8.7. LookupPeer . . . . . . . . . . . . . . . . . . . . . . . . 60
8.8. ExchangeTable . . . . . . . . . . . . . . . . . . . . . . 61
8.9. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 61
8.10. Replicate . . . . . . . . . . . . . . . . . . . . . . . . 61
8.11. Transfer . . . . . . . . . . . . . . . . . . . . . . . . . 62
8.12. PublishObject . . . . . . . . . . . . . . . . . . . . . . 62
8.13. LookupObject . . . . . . . . . . . . . . . . . . . . . . . 62
8.14. RemoveObject . . . . . . . . . . . . . . . . . . . . . . . 63
8.15. Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . 63
8.16. Connect . . . . . . . . . . . . . . . . . . . . . . . . . 63
8.17. Invite . . . . . . . . . . . . . . . . . . . . . . . . . . 63
9. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 65
9.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 65
9.2. General Object Format . . . . . . . . . . . . . . . . . . 67
9.3. P2PP TLV Objects . . . . . . . . . . . . . . . . . . . . . 67
9.3.1. Peer-Info . . . . . . . . . . . . . . . . . . . . . . 67
9.3.2. Unhashed-Id . . . . . . . . . . . . . . . . . . . . . 69
9.3.3. Request-Options . . . . . . . . . . . . . . . . . . . 69
9.3.4. P2P-Options . . . . . . . . . . . . . . . . . . . . . 71
9.3.5. Routing-Table . . . . . . . . . . . . . . . . . . . . 71
9.3.6. Neighbor-table . . . . . . . . . . . . . . . . . . . . 72
9.3.7. PLookup . . . . . . . . . . . . . . . . . . . . . . . 72
9.3.8. Resource-ID . . . . . . . . . . . . . . . . . . . . . 73
9.3.9. RLookup . . . . . . . . . . . . . . . . . . . . . . . 73
9.3.10. Resource-Object . . . . . . . . . . . . . . . . . . . 74
9.3.11. Expires . . . . . . . . . . . . . . . . . . . . . . . 75
9.3.12. Owner . . . . . . . . . . . . . . . . . . . . . . . . 75
9.3.13. Certificate . . . . . . . . . . . . . . . . . . . . . 76
9.3.14. Signature . . . . . . . . . . . . . . . . . . . . . . 76
9.3.15. Capabilities and Diagnostics . . . . . . . . . . . . . 76
9.4. Response Codes and Errors . . . . . . . . . . . . . . . . 78
9.4.1. Response Codes . . . . . . . . . . . . . . . . . . . . 78
9.4.2. Error Object . . . . . . . . . . . . . . . . . . . . . 79
10. Application Layer . . . . . . . . . . . . . . . . . . . . . . 80
10.1. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 80
10.2. Join . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
10.3. Leave . . . . . . . . . . . . . . . . . . . . . . . . . . 80
10.4. Publish . . . . . . . . . . . . . . . . . . . . . . . . . 80
10.5. Remove . . . . . . . . . . . . . . . . . . . . . . . . . . 80
10.6. Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . 81
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 82
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 83
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 89
14.1. Normative References . . . . . . . . . . . . . . . . . . . 89
14.2. Informative References . . . . . . . . . . . . . . . . . . 89
Appendix A. Background . . . . . . . . . . . . . . . . . . . . . 92
Appendix B. Message Flow . . . . . . . . . . . . . . . . . . . . 93
Baset, et al. Expires May 22, 2008 [Page 4]
Internet-Draft Peer-to-Peer Protocol November 2007
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 94
Intellectual Property and Copyright Statements . . . . . . . . . . 95
Baset, et al. Expires May 22, 2008 [Page 5]
Internet-Draft Peer-to-Peer Protocol November 2007
1. Introduction
This document defines Peer-to-Peer Protocol (P2PP) for creating and
maintaining an overlay of participant nodes. The design of P2PP
exploits commonalities in the peer-to-peer (p2p) protocols such as
Bamboo [22] Chord [12], CAN [13], Pastry [14], Kademlia [15], and Gia
[19] thereby defining a protocol that does not contain any peer-to-
peer protocol specific details and has an extension mechanism to
incorporate a protocol-specific feature. P2PP defines mechanisms for
NAT and firewall traversal, uses a secure transport, and has
mechanisms for exchanging node capabilities and diagnostic
information. P2PP allows non-participant nodes to use overlay
services through participant nodes.
Baset, et al. Expires May 22, 2008 [Page 6]
Internet-Draft Peer-to-Peer Protocol November 2007
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
Some of the terminology has been borrowed from the P2P terminology
draft [8].
User: A human user running the P2PP application and is identified by
a user-ID.
User Identifier (User-ID): A user identifier is an information that
represents a user in the overlay.
Node: A node is an entity that runs an overlay protocol (peer) or
can access the services provided by an overlay network (client).
Peer: A peer is a node participating in an overlay that provides
storage and routing services to other nodes in the overlay [8].
Client: A client is a node participating in an overlay that provides
neither routing nor storage and retrieval functions [8].
Peer Protocol: A structured or unstructured protocol such as Chord,
Kademlia, Pastry, Gia.
Joining Peer (JP): The peer which intends to join the overlay
network.
Admitting Peer (AP): An admitting peer is a peer that receives a
join request from a joining peer.
Identifier (ID): An identifier is information that uniquely
identifies a resource-object, a node, or a service. Peer-ID is a
form of identifier. We use the term identifier (ID) and key
interchangeably.
Peer-ID: A Peer-ID is information that uniquely identifies a peer
within a given overlay [8]. In DHT-based overlays, this is a hash
of a unique node identifier such as an IP address. In
unstructured overlays, this is typically an unhashed unique
identifier.
Routing Table: A routing table (known as finger table in Chord) is
used by a peer to locate a peer or a resource-object. Peers in a
DHT-based overlay contain a routing table which is a list of
overlay peer-IDs and their IP addresses stored against identifiers
Baset, et al. Expires May 22, 2008 [Page 7]
Internet-Draft Peer-to-Peer Protocol November 2007
that are exponentially away from the peer's identifier and thus
has a particular structure. The routing-table size is
algorithmically bounded. In unstructured networks, peers also
maintain a routing table. This specification does not put an
upper limit on the number of entries a node can store in its
routing table.
Note that the distinction between neighbor and routing table is an
artifact of structured peer-to-peer networks.
Routing Peers: The list of peers stored in a routing table are
called routing peers.
Neighbor Table: In a DHT-based overlay, a node's neighbor table
(known as successor list in Chord and leaf-set in Pastry) contains
a list of overlay peer-IDs and their IP addresses which are
'immediately' close to the node's identifier according to the DHT
metric. The purpose of the neighbor table is to maintain
correctness. In an unstructured overlay, nodes typically only
maintain a routing table.
Neighbor Peers: The list of peers stored in a neighbor table are
called neighbor peers.
Resource Object: A resource-object is a blob of data stored in the
overlay and is identified by a resource-ID. Examples of resource-
objects are SIP URIs, routing-records, file-names, and service
identifiers such as those identifying STUN or TURN servers. Each
resource-object has meta-data associated with it such as content-
type, content-usage, owner and expiration-time. The meta-data can
also be defined by the user. Resource Object is known as resource
record in the concepts document [8].
Service: A node can offer services such as NAT and firewall
traversal and may relay traffic for other nodes. A node
advertises its service capabilities in the overlay using a
resource-object. Different nodes can advertise the same service.
The nodes store service advertisements as resource-objects in the
overlay.
Heterogeneous Network Environments: A heterogeneous network
environment comprises of nodes that use different mechanisms for
network connectivity such as dialup, DSL, or wireless.
Overlay Operator: An entity that uses P2PP to implement an overlay.
Baset, et al. Expires May 22, 2008 [Page 8]
Internet-Draft Peer-to-Peer Protocol November 2007
Enrollment and Authentication Server: An entity which enrolls and
authenticates a user.
Bootstrap Server: An entity which provides an IP address and port
number of an existing node in the overlay to the joining peers.
Diagnostic Server: An entity which gathers diagnostic information
from peers in the overlay. This information can be used to
construct a geographical map of the overlay to visually identify
load hotspots in the overlay.
Baset, et al. Expires May 22, 2008 [Page 9]
Internet-Draft Peer-to-Peer Protocol November 2007
3. Design Overview
3.1. High-Level Requirements
There are five high-level requirements for a peer protocol.
Overlay formation The protocol should allow nodes to form an overlay
using well-known structured or unstructured peer-to-peer
protocols.
Overlay maintenance: The protocol should provide mechanisms to
maintain connectivity and resource availability in an overlay.
Resource publishing and lookup: The protocol should provide a
mechanism for a peer to publish a resource-object or advertise its
service and a mechanism to lookup the resource-object and the node
offering a service.
Heterogeneous capabilities and connectivity: The protocol should
allow nodes with heterogeneous capabilities and connectivity (such
as NATs) to form an overlay.
Security The protocol should provide mechanisms to protect against
well-known threats against overlays.
3.2. Node Model
P2PP is an application layer protocol that allows participating nodes
to form an overlay using a structured or unstructured peer protocol.
The participating nodes typically represent a human user. There is a
one-to-many relationship between the human user and the nodes, i.e.,
a user can participate in the overlay through one or multiple nodes.
P2PP defines two types of nodes, namely, peers and clients. A peer
is a node participating in an overlay that provides storage and
routing services to other nodes in the overlay. A client is a node
that does not participate in the overlay and hence does not provide
any storage or routing services. Instead, it communicates with one
or more peers to make use of the storage and routing services
provided by peers. A peer can participate in more than one overlay
and a client can also communicate with peers in different overlays.
Baset, et al. Expires May 22, 2008 [Page 10]
Internet-Draft Peer-to-Peer Protocol November 2007
User
/ | \
/ | \
/ | \
/ | \
+-----+ +-----+ +-------+
|Peer1| |Peer2| |Client1|
+-----+ +-----+ +-------+
Figure 1: Relationship between user, peers and clients.
P2PP does not define a priori which nodes can act as peers or clients
and leaves the decision to overlay operator. The rationale is that
P2PP can be used to form an overlay of participating nodes in many
different network environments. These include Internet, a
corporation, a small office, mobile networks and so on. Nodes which
are suitable candidates for becoming a peer in one environment may
not necessarily be suitable in other environment. CPU, memory,
uptime and network connectivity are some issues which determine
whether the node can act as a peer or a client.
The classification of a node as a peer or a client is not permanent;
a client can join the overlay as a peer or a peer can invite a client
to join the overlay. Similarly, a peer can leave the overlay and
join as a client.
In P2PP, peers and clients are identified by a fixed length
identifier and are chosen from the same identifier space. To some
extent, the identifier assignment depends on the underlying peer
protocol. For structured protocols such as DHTs, a peer and a client
identifier is a randomly chosen identifier whose length depends on
the underlying hash function. For unstructured protocols, the
identifier can be chosen in an appropriate way. Peers and clients
can choose their own identifiers or have a central authority choose
their identifiers. The human users are identified by an identifier
such as SIP AOR or an email address. The user identifiers are chosen
in a distributed fashion and may or may not be managed by a central
authority.
The lack of central management authority for choosing a user
identifier implies that two users can potentially select the same
user identifier. Likewise, the possibility of collision also arises
if peers and clients were to choose their own identifiers. Further,
lack of a central authority on user and node identifier assignment
opens the system to Sybil attack [23]. To address these issues, P2PP
defines an entity called an enrollment and authentication (E&A)
server. The E&A server authenticates the users, and ensures that
user and node identifiers are unique. A peer can act as an E&A
Baset, et al. Expires May 22, 2008 [Page 11]
Internet-Draft Peer-to-Peer Protocol November 2007
server.
Bootstraping is a fundamental issue in the overlay as the peers must
somehow discover the address of other peers in the overlay.
Similarly, clients also need to discover the address of one or more
peers in the overlay. There are different mechanisms for discovering
a peer already in the overlay [21]. P2PP describes a bootstrap
server based mechanism, and defines an entity, called bootstrap
server. The bootstrap server provides the peers and clients with the
IP address of participating peers. The bootstrap server may be co-
located with the E&A server. A peer can also act as a bootstrap
server.
For diagnostic purposes, an overlay operator may like to construct a
'map' of nodes. This allows the overlay operator to identify
problematic hotspots in the overlay and take remedial actions. P2PP,
defines an entity called diagnostic server, which crawls the overlay
and gathers diagnostic information.
Purists can argue that the use of enrollment and authentication
server, bootstrap server, and diagnostic server violates the
distributed nature of the overlay. We do not disagree with the
argument and note that an overlay operator may dispense with these
entities provided it is aware of the issues that may arise as a
consequence. From our experience, we think that the practical issues
involved in running an overlay necessitate their usage.
P2PP allows peers to provide services such as NAT traversal. Many
peers can provide the same service. Besides storage and routing,
P2PP also allows clients to provide services. Besides, peers and
clients can store and retrieve data from the overlay.
P2PP represents both clients and peers by a peer-info object.
3.2.1. P2PP Node Stack
The protocol stack of a P2PP node comprises of three conceptual
layers, namely, application, overlay, and transport layers. Figure 2
shows the three layers.
Baset, et al. Expires May 22, 2008 [Page 12]
Internet-Draft Peer-to-Peer Protocol November 2007
^
|
|
Application +------------+ +-----------+
Layer |SIP Proxy/UA| |Application|
| +------------+ +-----------+
V | |
================|=================|========= P2PP API
| |
^ +---------------------+--------------+
| | routing | routing |
Overlay | maintenance | state |
Layer | replication +--------------|
| | NAT traversal | resource |
| | storage | objects |
V +---------------------+--------------+
| | |
^ +---------------------------+
| | -state-machine for |
| | reliable and unreliable |
| | transports |
| +---------------------------+
Transport | | |
Layer ..........................................
| . Transport Layer Security (TLS or DTLS) .
| ..........................................
| | |
| +-----+ +-----+
| | UDP | | TCP | ... other
| +-----+ +-----+ protocols
| | |
| .............................
| . IP Layer Security .
| .............................
V | | |
=================================|========|========|=============
| | |
+------------------------------------+
| IP |
+------------------------------------+
Figure 2: Protocol stack of a P2PP peer.
3.2.1.1. Application Layer
The application layer defines an asynchronous application-level API.
An application can issue these API to the overlay layer to accomplish
functions such as joining or leaving an overlay, and to search for
Baset, et al. Expires May 22, 2008 [Page 13]
Internet-Draft Peer-to-Peer Protocol November 2007
another peer or resource-object in the overlay.
3.2.1.2. Overlay Layer
The overlay layer is the 'brain' of P2PP protocol stack. It has
mechanisms for routing, overlay maintenance, replication, NAT
traversal, and storage management. The overlay layer receives API
requests from the usage layer and accomplishes the requested
function. The routing mechanism routes the requests in a recursive,
iterative, or parallel manner. The overlay maintenance mechanism
strives to preserve routing correctness and connectivity in the
presence of churn. The replication mechanism maintains availability
of resource-objects in the system. The NAT traversal mechanism uses
ICE (TODO: and variants?) to traverse NATs. The client does not have
routing, storage, or replication mechanisms. (TODO: split the
layer?)
3.2.1.3. Transport Layer
P2PP allows sending messages over an unreliable or a reliable
transport. It, however, prefers the use of reliable transport such
as TCP or TLS. For unreliable transports such as UDP and DTLS, it
provides an ACK-based hop-by-hop reliability mechanism. For reliable
transports, reliability is provided by the underlying transport
protocol.
3.2.1.3.1. Listening Ports
The specification proposes a standard UDP and TCP listening port to
be assigned by IANA. The current implementation uses port 7080 as a
listening port for UDP and TCP, and 7081 for DLTS and TLS.
3.3. Data Model
The peers in P2PP provide storage services. This allows other peers
and clients to store data on a peer or a set of peers. In P2PP, the
data to be stored is defined as a resource-object. A resource-object
has a resource-ID which acts as the object locator. For structured
overlays such as DHTs, resource-ID is a fixed length identifier. For
unstructured overlays, resource-ID can have a variable length. A
resource-object has a type and sub-type which identify the
information being stored. The type and sub-type define a name-space,
i.e., resource-objects having same resource-ID but a different type
and sub-type belong to a different namespace. An example of a type
is a user or a service identifier. Each resource-object has a
'value' whose description depends on the type and sub-type. The
relationship between resource-ID, type, sub-type, and value is shown
in Figure 3.
Baset, et al. Expires May 22, 2008 [Page 14]
Internet-Draft Peer-to-Peer Protocol November 2007
Each resource-object has certain properties, namely, the owner of the
object, the node storing the object and the cryptographic signature
of the object. P2PP allows peers to store data having the same
resource-ID, type and sub-type but different owners. Similarly, P2PP
allows nodes to search for resource-objects published by different
owners.
Examples of data-types include buddy lists, user-record, and services
such as NAT and firewall traversal.
+-----------------------------------------------------------+
| +-------------------------------------------------------+ |
| | Resource-ID | |
| +-------------------------------------------------------+ |
| +-------------------------+ +-------------------------+ |
| | Type1 | | Type2 | |
| | +---------+ +---------+ | | +---------+ +---------+ | |
| | |Sub-type1| |Sub-type2| | | |Sub-type1| |Sub-type2| | |
| | +---------+ +---------+ | | +---------+ +---------+ | |
| | +------+ +------+ | | +------+ +------+ | |
| | |Value1| |Value1| | | |Value1| |Value1| | |
| | +------+ +------+ | | +------+ +------+ | |
| | | | | |
| | +------+ +------+ | | +------+ +------+ | |
| | |Value2| |Value2| | | |Value2| |Value2| | |
| | +------+ +------+ | | +------+ +------+ | |
| | | | | |
| +-------------------------+ +-------------------------+ |
| |
+-----------------------------------------------------------+
Figure 3: Resource-object.
3.4. Message Model
P2PP messages begin with a header followed by a sequence of type-
length-value (TLV) objects. P2PP defines five types of message.
However, the three key messages are requests, responses, and
indications. The requests always generate a response, where as
indications do not require any. Indications are useful in scenarios
such as informing other peers about a routing table change. The
response have a response code which is inspired from HTTP and SIP
response codes.
P2PP allows nodes to forward requests in a recursive or an iterative
manner. In recursive routing, a request is forwarded from one peer
to the other until it reaches its destination. The response is then
Baset, et al. Expires May 22, 2008 [Page 15]
Internet-Draft Peer-to-Peer Protocol November 2007
sent along the same path on which the request was received. In
iterative routing, if a peer determines that it is not the
destination of the message, it sends in its response the IP address
of the next hop. The request originator then sends the request to
the next hop. Peers never forward the indications. Figure 4 and 5
show a conceptual diagram of request routing in a recursive and
iterative manner, respectively.
Peer1 Peer2 Peer3
| Request | |
|-------------->| Request |
| |------------->|
| | Response |
| |<-------------|
| Response | |
|<--------------| |
Figure 4: A conceptual diagram showing request routing in a recursive
manner.
Peer1 Peer2 Peer3
| Request | |
|-------------->| |
| Response | |
|<--------------| |
| Request |
|-----------------------------<|
| Response |
|<-----------------------------|
| |
Figure 5: A conceptual diagram showing request routing in an
iterative manner.
3.5. Reliability Model
P2PP defines a hop-by-hop reliability model, i.e., the request,
response, and indications originators are only responsible for
ensuring that the message reaches the next hop. P2PP allows nodes to
send messages over a reliable and unreliable transport. For
unreliable transports, P2PP provides an acknowledgement (ACK) based
mechanism to ensure reliability of message delivery. The
acknowledgement is the fourth type of P2PP message.
P2PP does not support message fragmentation and instead makes use of
the underlying reliable transport such as TCP or TLS larger than MTU
Baset, et al. Expires May 22, 2008 [Page 16]
Internet-Draft Peer-to-Peer Protocol November 2007
messages.
For recursive routing, the hop-by-hop reliability model allows the
routing path to be a mix of reliable and unreliable transports.
Figure 4 and 5 showed the message forwarding in a recursive manner
and iterative manner over reliable transport. Figure 6(a) and 7(a)
show the unoptimized message forwarding in a recursive and iterative
manner over unreliable transport. In recursive routing, the peer
responsible for generating a response sends an ACK and then
immediately sends a response. In iterative routing, every node must
acknowledge the request and immediately send the response. To avoid
the transmission of an ACK followed by a response, P2PP, defines a
fifth type of message, namely, responseACK which combines the
response and acknowledgement in one message.
Peer1 Peer2 Peer3 Peer1 Peer2 Peer3
| Request | | | Request | |
|-------------->| | |-------------->| |
| ACK | | | ACK | |
|<--------------| Request | |<--------------| Request |
| |------------->| | |------------->|
| | ACK | | | ResponseACK |
| |<-------------| | |<-------------|
| | Response | | | ACK |
| |<-------------| | |------------->|
| | ACK | | Response | |
| |------------->| |<--------------| |
| Response | | | ACK | |
|<--------------| | |-------------->| |
| ACK | | | | |
|-------------->| |
(a) (b)
Figure 6: Request routing in a recursive manner over unreliable
transport. (a) unoptimized forwarding (b) optimized forwarding.
Baset, et al. Expires May 22, 2008 [Page 17]
Internet-Draft Peer-to-Peer Protocol November 2007
Peer1 Peer2 Peer3 Peer1 Peer2 Peer3
| Request | | | Request | |
|-------------->| | |-------------->| |
| ACK | | | ResponseACK | |
|<--------------| | |<--------------| |
| Response | | | ACK | |
|<--------------| | |-------------->| |
| ACK | | | |
|-------------->| | | Request |
| | |----------------------------->|
| Request | | ResponseACK |
|----------------------------->| |<-----------------------------|
| ACK | | ACK |
|<-----------------------------| |----------------------------->|
| Response | | |
|<-----------------------------|
| ACK |
|----------------------------->|
(a) (b)
Figure 7: Request routing in an iterative manner over unreliable
transport. (a) unoptimized forwarding (b) optimized forwarding.
Thus, P2PP defines five types of message, namely, request, response,
responseACK, indication, and acknowledgement. A response or
responseACK must match to the request. Similarly, an ACK must match
to the request, response, or responseACK that it acknowledges. The
transmission of a request, response, responseACK, and an indication
is governed by a transaction state-machine described in Section 6.2.
3.6. Security Model
P2PP provides a hop-by-hop security model. The nodes in P2PP
establish an unreliable or reliable secure channel with other nodes
using DTLS or TLS. However, peers establish a secure SIP session in
an end-to-end manner.
P2PP uses an enrollment and authentication (E&A) server to enroll new
users in the overlay and to authenticate existing users. Once
authenticated, it issues a certificate that binds the user-identifier
and public key of the user. Further, it also generates a peer or a
client identifier and adds it to the certificate.
P2PP also allows nodes to operate without a central enrollment and
authentication server. In such a scenario, nodes use self-signed
certificates and generate their own identifiers.
Baset, et al. Expires May 22, 2008 [Page 18]
Internet-Draft Peer-to-Peer Protocol November 2007
3.6.1. Threat Model
This section lists the security threats and discusses mechanisms P2PP
provides to protect against some of these threats. The threats
against overlays can be loosely classified into routing, storage, and
replay threats. Below we list some of the possible attacks within
each threat. P2PP provides protection against some of these attacks.
Routing Threats
1. Obtain a significant portion of user or peer identifiers to
launch a Sybil attack.
2. Sniff on the messages between peers.
3. Corrupt a message flow between peers, thereby violating message
integrity.
4. Infer user or flow identity from the legitimately received
messages.
5. Incorrectly route or drop a message.
6. Poison routing or neighbor tables.
7. Launch a DoS or DDoS against a peer or set of peers.
Storage Threats
1. Corrupt a stored object, thereby violating storage integrity.
2. Unauthorized storage or lookup.
3. Launch a storage DoS attack against a peer or set of peers.
4. Does not invalidate storage cache, thereby returning old copies
of the stored object.
Replay Threats
1. Replay a message.
Currently, P2PP provides protection against (1)-(3) of routing
threats, (1)-(3) of storage threats, and (1) of replay threats. The
next section discusses mechanism provided by P2PP for protection
against these threats.
Baset, et al. Expires May 22, 2008 [Page 19]
Internet-Draft Peer-to-Peer Protocol November 2007
3.7. NAT and Firewall Traversal
P2PP allows any node to act as a NAT traversal server. The node
providing the NAT traversal service allows the node behind a NAT to
discover their NAT types and to determine their reachable address
using STUN [5] or TURN [6]. Many nodes can provide the NAT traversal
service and a key issue is how this information is published in the
overlay and how to discover an appropriate NAT traversal server.
P2PP provides RTT and autonomous-system (AS) number based mechanisms
for a node to discover a close-by NAT traversal server. In a large
corporation, peers may also use an IP-prefix based mechanism to
discover a close by NAT traversal server. P2PP leaves the selection
of this mechanism to overlay operator. P2PP also allows an
overloaded node providing NAT traversal service to redirect NAT
traversal requests to unloaded nodes.
In a peer-to-peer network, there is no guarantee on the availability
of a node. A node whose reachability depends on a peer providing NAT
traversal service may discover that the peer is no longer online.
Consequently, the reachable IP address of a node obtained through a
peer providing a NAT traversal service that is no longer online
becomes invalid. Therefore, a node may need to discover another peer
providing NAT traversal service, determine its new reachable address,
readvertise this information in the overlay, and establish new
connections with routing and neighbor peers. Depending on the churn
rate, this can incur a significant communication overhead.
The requests can be routed in a recursive or an iterative manner.
The choice of routing mechanism has an impact on the performance of
NAT traversal mechanism. We discuss these issues in Section 4.3.2
and suggest that the non significant overhead of ICE [7] as-is does
not lead to its automatic selection as a NAT traversal mechanism.
TODO: Besides NATs, the firewalls can hinder connectivity and result
in non-transitivity of connection.
3.8. Mobility
We classify P2PSIP mobility into three subcategories: peer mobility,
client mobility, and session mobility. The following sections
discuss different aspects of P2PSIP mobility in details.
3.8.1. Peer Mobility
Mobile devices such as mobile and WiFi phones or laptops may move
from one network to another by doing handover between different
access networks or moving from one WLAN access point to another.
Whenever a peer changes its access network (e.g., from WCDMA to
Baset, et al. Expires May 22, 2008 [Page 20]
Internet-Draft Peer-to-Peer Protocol November 2007
WLAN), its IP address also changes. In P2PSIP networks where P2PSIP
peer software runs also in mobile terminals, peer-IDs must not be
assigned based on IP addresses. If a peer-ID was constructed using
an IP address of a peer, any change in the IP address would cause the
change of the peer-ID, introducing instability in the DHT network.
Further, a peer needs to inform its routing and neighbor peers about
any change in the IP address.
Any change in the peer-ID computed using IP address require a peer to
leave the P2PSIP overlay network and join the overlay network once
again with the new peer-ID. Besides updates to the DHT do not take
place immediately after a node has gone. It may take some time until
all the data is again in the proper place, including the re-creation
of routing tables. This may cause network instability and require
additional resources to handle network adaptation especially in a
battery powered mobile devices. Besides in the transition period
search delay for user contact information may be higher, delaying the
call establishment.
Rather than constructing peer-IDs by hashing the IP address or a
random peer-ID, which is no longer static for the duration of the
connection to the DHT, P2PP allows P2PSIP networks to assign a static
and unique (within a DHT ring) peer-IDs. The enrollment and peer-ID
assignment is presented in Section 4.5. In addition, P2PP allows
peers to advertise changes of their IP addresses to other peers.
When a peer moves to another subnet after a handover, it receives a
new IP address. Since the peer-ID does not change, it does not
introduce instability into the DHT. However, the peer has to inform
its neighbors about its new IP address. To each neighbor, the peer
presents the new IP address, and authentication data (a certificate)
that also includes the existing peer-ID. The neighbor authenticates
the update request and stores the new IP address bound to that
peer-ID.
3.8.2. Client Mobility
Mobile clients may change IP address in the same way as mobile peers
do. The main difference between the client mobility and the peer
mobility is that the client mobility does not influence the structure
of the overlay. However, the client mobility may have impact on the
reachability of the client itself. In case of a handover, a mobile
client must update user records in DHT in real time if it still wants
to be reachable. In order to fulfill this requirement, the client
must contact the peer that stores the user record. When the client
changes its IP address, it must update the user record by sending
publish request directly to the peer storing the record. If the peer
is not reachable, the client must send the publish request to any of
the available peers using either recursive or iterative routing.
Baset, et al. Expires May 22, 2008 [Page 21]
Internet-Draft Peer-to-Peer Protocol November 2007
3.8.3. Session Mobility
Session mobility is related to the mobility of SIP user agent during
a SIP session. This may happen when one or more endpoints that are
participating in the same SIP session change their IP addresses
because of a handover. In order to preserve the service continuity,
clients need to support a method that will minimize session
interruption due to handovers. This memo does not provide any
solution for SIP session mobility. Instead, it is expected that a
generic SIP solution for session mobility will be re-utilized in
P2PSIP once such solution is developed.
3.9. Overview of Operations
The following table gives a brief description of P2PP messages and
their message type. It also indicates which messages may be sent by
a peer or a client. The messages have been grouped together by
relevant functions.
3.9.1. Enrollment, Authentication, and Bootstrap
+--------------+---------+--------+---------------------------------+
| Operation | Message | Peer | Description |
| | Type | or | |
| | | Client | |
+--------------+---------+--------+---------------------------------+
| Enroll | R | P|C | Enrolls the user in the |
| | | | overlay. |
| | | | |
| Authenticate | R | P|C | Authenticate the user and |
| | | | generates a certificate binding |
| | | | user-ID, peer or client ID, and |
| | | | public key of the peer. |
| | | | |
| Bootstrap | R | P|C | Clients and peers send this |
| | | | request to a bootstrap server |
| | | | or a peer to discover the IP |
| | | | address of a peer in the |
| | | | overlay. |
+--------------+---------+--------+---------------------------------+
Baset, et al. Expires May 22, 2008 [Page 22]
Internet-Draft Peer-to-Peer Protocol November 2007
3.9.2. Overlay Maintenance
+---------------+---------+--------+--------------------------------+
| Operation | Message | Peer | Description |
| | Type | or | |
| | | Client | |
+---------------+---------+--------+--------------------------------+
| Join | R | P|C | Peers send this request to |
| | | | join the overlay. Depending |
| | | | on the peer protocol being |
| | | | used, the join request is |
| | | | forwarded to the peer where |
| | | | this peer will join. Client |
| | | | sends a join request to a peer |
| | | | discovered using bootstrap |
| | | | mechanism and becomes attached |
| | | | to the peer. |
| | | | |
| Leave | I | P|C | Peers send the leave |
| | | | indication to their routing |
| | | | and peers indicating their |
| | | | departure. Clients |
| | | | periodically send the leave |
| | | | message to their respective |
| | | | peers. |
| | | | |
| KeepAlive | I | P|C | Peers periodically send a |
| | | | keepalive indication to their |
| | | | routing and neighbor peers to |
| | | | check whether they are alive. |
| | | | Clients send a keepalive to |
| | | | their peers to check whether |
| | | | they are alive. |
| | | | |
| LookupPeer | R | P | Peers send this request to |
| | | | discover a peer that may fill |
| | | | or update a missing entry in |
| | | | their routing or neighbor |
| | | | table. |
| | | | |
| ExchangeTable | R | P | Peers periodically send this |
| | | | request to their routing and |
| | | | neighbor peers obtain their |
| | | | routing and neighbor tables. |
| | | | |
Baset, et al. Expires May 22, 2008 [Page 23]
Internet-Draft Peer-to-Peer Protocol November 2007
| Replicate | R | P | Peers periodically send this |
| | | | request to replicate the |
| | | | resource-objects for |
| | | | availability. The choice of |
| | | | peers on which to replicate |
| | | | the objects depends on the |
| | | | peer protocol. |
| | | | |
| Transfer | R | P | After a successful join or |
| | | | graceful or ungraceful failure |
| | | | of peers, a peer transfers the |
| | | | ownership of resource-objects |
| | | | using a transfer request. |
+---------------+---------+--------+--------------------------------+
3.9.3. Data Storage and Retrieval
+---------------+---------+--------+--------------------------------+
| Operation | Message | Peer | Description |
| | Type | or | |
| | | Client | |
+---------------+---------+--------+--------------------------------+
| PublishObject | R | P|C | Publish a resource-object. |
| | | | Also, used to refresh or |
| | | | update an existing |
| | | | resource-object. |
| | | | |
| LookupObject | R | P|C | Search for a resource-object. |
| | | | |
| RemoveObject | R | P|C | Remove the resource-object. |
+---------------+---------+--------+--------------------------------+
3.9.4. Connection Management and Other
+-----------+---------+--------+------------------------------------+
| Operation | Message | Peer | Description |
| | Type | or | |
| | | Client | |
+-----------+---------+--------+------------------------------------+
| Tunnel | R | P|C | Tunnel an application layer |
| | | | protocol message into a P2PP |
| | | | message. Mostly used for sending |
| | | | SIP messages to peers or clients |
| | | | behind a NAT. |
| | | | |
| Connect | R | P|C | Send an ICE offer (TBD). |
| | | | |
Baset, et al. Expires May 22, 2008 [Page 24]
Internet-Draft Peer-to-Peer Protocol November 2007
| Invite | R | P | Peers send an invite request to a |
| | | | client, inviting them to become a |
| | | | peer. |
| | | | |
| Query | R | P|C | Query a peer or a client to |
| | | | discover the services they provide |
| | | | or the resource-objects they |
| | | | store. |
+-----------+---------+--------+------------------------------------+
3.10. Overlay Migration
This mechanism allows nodes to migrate from one overlay protocol to
the other and to download a software update for the overlay protocol.
(TBD.)
Baset, et al. Expires May 22, 2008 [Page 25]
Internet-Draft Peer-to-Peer Protocol November 2007
4. Overlay Layer
4.1. Peer State
A peer maintains the following state:
Peer-to-Peer Algorithm: Peer-to-peer algorithm of the overlay.
Overlay-ID: ID of the overlay this peer is part of.
Hash Algorithm: The hash algorithm, if any, being used.
Base: The logarithm base for a DHT, if a DHT is used as a peer
protocol.
Routing Table: A table of other peers in the overlay. For each
peer, the following information is maintained.
Peer-ID: The ID of the peer. For a structured p2p algorithm, it
is typically the hash of the IP address of the peer. Otherwise,
it can be an IP address or some unique ID.
IP address and port: The IP address and port of the peer.
RTT: The round-trip-time of this peer. If TCP is used, an
application may obtain this value from the TCP stack if the
underlying OS supports it.
Uptime: The uptime of the peer.
Neighbor Table: A table of peers with ID adjacent to the peer's ID
in a structured overlay. For each peer, the following information
is maintained.
Peer-ID: The ID of the peer. For a structured p2p algorithm, it
is typically the hash of the IP address of the peer. Otherwise,
it can be an IP address.
IP address and port: The IP address and port of the peer.
RTT: The round-trip-time of this peer.
Uptime: The uptime of the peer (overlay software).
Number of Neighbors: Total number of peers in routing and neighbor
tables.
Baset, et al. Expires May 22, 2008 [Page 26]
Internet-Draft Peer-to-Peer Protocol November 2007
Publish Table: The resource-objects this peer has published in the
overlay. It must periodically refresh the resource-objects before
the passage of their refresh time interval.
Resource Table: Resource-objects this peer is responsible for.
Replicated Resource Table: Resource-objects this peer stores as
backup for other objects.
Transaction Table: A transaction table which keeps track of in-
progress transactions. The transaction can be a request,
response, or an indication transaction.
Uptime: The uptime of this peer.
Number of Clients: Number of clients connected to this peer.
Media Relay Flows: The number and bandwidth of media flows being
relayed through this peer.
Additionally, it may keep track of the following diagnostic
information:
Bandwidth: The current bandwidth being used.
Number of Messages: The number and cumulative size of messages
received within the last x seconds.
Autonomous System Number: The AS number of the peer. It can be used
to advertise STUN or TURN services.
4.2. Key Components of a P2PP Message
This section describes the key TLV objects defined by P2PP.
Common Header: The common header is a fixed length header which is
part of every message (Section 9.1. It contains the message type,
request or indication type, TTL, a magic cookie to differentiate P2PP
from other protocols, transaction-ID, source-ID and a response-ID.
The message type defines the type of the message, namely, request,
response, responseACK, or indication where as the request or
indication type defines the type of request or indication being sent.
The transaction-ID is a unique number chosen by the request or
indication originator. The source-ID represents the peer-ID of the
message originator peer. Response-ID is only included in the ACK,
response, or a responseACK, and represents the peer-ID of the peer
generating the response, responseACK, or ACK. Since peer-IDs must be
unique and peers must choose a locally unique transaction-ID, the
Baset, et al. Expires May 22, 2008 [Page 27]
Internet-Draft Peer-to-Peer Protocol November 2007
combination of source-ID and transaction-ID can uniquely identify a
message.
Peer-Info: Peer-Info TLV represents a peer in the overlay. A peer
has a fixed length identifier and a set of reachable IP address and
port numbers gathered using ICE. Further, a peer maintains its
uptime information, number of connected clients, routing and neighbor
peers, a certificate, and bandwidth. This information is encoded as
follows:
Peer-Info = Peer-ID
[Address-Info]
[Uptime]
[Certificate]
[Connections]
[Node-Resource-Utilization]
[ext]
Similar to peers, clients also have an identifier derived from the
same identifier space as peers. There is almost no difference
between the peer-info TLV representing a peer and peer-info TLV
representing a client, except that other peers must not update their
routing and neighbor tables with the client. Peers can also invite
clients to become peers in the overlay and therefore, it made sense
that clients already have an identifier when they receive such an
invitation as they can then immediately join the overlay, without
going through an E&A server and obtaining a certified peer-ID.
This specification represents both peers and clients with a peer-info
object. When forwarding messages, the message originated by a peer
or a client is differentiated based on a 'peer or client' flag in the
common header.
An approximate size of a peer-info object for a 20 byte peer-ID, and
an address info object containing host, server-reflexive, and relay
candidates is (4+4+20+4+46)=78 bytes.
Resource-Object: Resource-object represents the information that
peers store in the overlay. As discussed in Section 3.2, a resource-
object has a resource-ID, type, sub-type, and a value. Further, a
resource-object has additional properties, namely, owner, peer who
inserted or updated the object, and a signature. Resource-ID is a
fixed length identifier for DHTs and could be a variable length
identifier for unstructured overlays. The size of the resource-
object is limited to 65,536 bytes. A resource-object is encoded as
follows:
Baset, et al. Expires May 22, 2008 [Page 28]
Internet-Draft Peer-to-Peer Protocol November 2007
Resource-Object = Resource-ID
[Peer-Info]
[Owner]
[Signature]
Value
[ext]
4.3. Request, Response, and Indications Processing
To send a request, response, responseACK, or an indication, a peer
creates a transaction and passes it the message. The peer identifies
a transaction using a source-ID and transaction-ID tuple as described
in Section 6.1. For response and responseACK, an additional
consideration is that it must contain the same source-ID and
transaction-ID as the request for which the response is being
generated. Similar considerations hold for ACK which acknowledges
requests, responses, or indications over unreliable transport.
Following considerations apply when sending a message.
1. A node may set request-routing-table or request-neighbor-table
flags requesting to receive the peer-info objects containing
peer-ID and address-info objects. If the message was sent over
unreliable transport, the node issuing the request SHOULD always
set the in-separate-request flag in the Request-Options object.
For a routing table that contains 100 nodes, which can be typical
for a million user overlay, and an average peer-info object size
of 78 bytes, the routing or neighbor table is not likely to fit
within response UDP packet.
A message can be received over UDP or TCP. A message received over
unreliable is processed according to the following steps:
1. The peer checks whether a transaction already exists in the
transaction table. As described in Section 4.1, a peer keeps
track of in-progress transactions in a transaction table. If a
transaction exists, the peer sends an ACK response and terminates
the message processing. The received requests are matched
against the response transaction having the same source-ID and
transaction-ID where as the received responses are matched
against request and response transactions.
2. If the transaction does not exist in the transaction table, the
peer checks the TTL field in the common header. If TTL is equal
to zero, and the message was a request, it MUST reply with a 410
(TTL Hops Exceeded) response and include its Peer-ID in the
Response-ID field in the common header. Additionally, it MUST
send an ACK to the received request. If a peer receives a
response, indication or an ACK with a TTL equal to zero, it
Baset, et al. Expires May 22, 2008 [Page 29]
Internet-Draft Peer-to-Peer Protocol November 2007
ignores the message. Instead of sending a separate ACK and a
response message, it sends a responseACK message. It creates a
responseACK transaction as shown in Figure 3 and passes it the
responseACK message. The transaction has the same source-ID as
the one received in the request. The response-ID is set to the
ID of the peer generating response or responseACK. The response
is always sent to the peer from whom the request was received and
not to the peer who issued the request.
3. If TTL is greater than zero, recursive routing was being used (R
flag is set in the common header), and the peer cannot generate a
response for the received request, it determines the next hop
from its routing or neighbor tables, creates a request
transaction, and passes it the request after decrementing TTL by
one in the common header. The transaction has the same
identifier (source-ID, transaction-ID) as the one received in the
request. The rest of the forwarded request remains unchanged.
Also, it sends an ACK message to the peer from whom it received
the request and sets its own peer-ID in the response-ID of the
ACK message. If a response is received for which a corresponding
request transaction exists, the peer immediately terminates the
request transaction, creates a response transaction and passes it
the received response for delivery to the upstream peer.
4. If TTL is greater than zero, iterative routing was being used,
and the peer cannot satisfy the request, it determines the next
hop from its routing or neighbor tables. It then creates a
responseACK transaction and passes it a 302 (Next Hop) response.
The peer includes its Peer-Info and the next hop Peer-Info object
in the responseACK message.
5. If a peer can generate a response for a received request, it must
create a responseACK transaction. If a peer receiving the
request determines that it can generate a response, which will
fit within UDP MTU, it checks if the Request-Options object was
present and that request-routing-table or request-neighbor-table
and in-separate-request flags were set. If set, the peer waits
for a random time between RA and RB seconds, and sends a copy of
its routing or neighbor table or both in an ExchangeTable request
to the peer which issued the request (not the peer which
forwarded the request). If in-separate-request was not set, the
peer includes in the response as much of the requested routing or
neighbor table entries as permitted by the UDP MTU.
6. If the peer receiving the request determines that it can generate
a response but the response will not fit within UDP MTU, it can
reply with a 413 (Message Too Large) or a 480 (Alternative
Service) response to indicate to the node issuing the request to
Baset, et al. Expires May 22, 2008 [Page 30]
Internet-Draft Peer-to-Peer Protocol November 2007
retry the request over TCP. A 413 response is not sent if the
response can fit within UDP MTU but requested routing or neighbor
table cannot fit within MTU.
7. A peer should always send an ACK to any retransmissions of the
request, response, or indication.
8. The peer checks if it can update its routing and neighbor tables
from the received request or response.
9. If a peer receives a response, it immediately replies with an ACK
message. It then searches for the corresponding request
transaction in its transaction table. If a request transaction
is found, and if the peer receiving the response was the request
originator it passes the response to the overlay layer.
Otherwise, it creates a response transaction and passes it the
received response. The response is sent to the same IP address
and port number from which the request was received. If a
request transaction is not found and the peer receiving the
response was not the request originator, the response is
discarded. However, an ACK is still generated for the discarded
response. The transmission of ACK is an indication that the peer
receiving the response is still alive.
A peer sending an indication sets the TTL field to one. A peer
receiving an indication over unreliable transport immediately
generates an ACK. An indication is never forwarded so R flag is
never set for an indication.
To send a message over a reliable transport, a peer creates an
appropriate transaction as shown in Figure 4 and 5 and passes it the
message.
A request or response received over a reliable transport is processed
according to the following steps.
1. The peer checks whether a transaction already exists in the
transaction table. This transaction can either be a request,
response transaction.
2. If the transaction does not exist in the transaction table, the
peer checks the TTL field in the common header. If TTL is equal
to zero, it MUST reply with a 410 (TTL Hops Exceeded) response
and include its Peer-ID in the Response-ID field in the common
header. It creates a response transaction as shown in Figure 5
and passes it the response . The transaction has the same
identifier as the one received in the request. The response is
always sent to the peer from whom the request was received and
Baset, et al. Expires May 22, 2008 [Page 31]
Internet-Draft Peer-to-Peer Protocol November 2007
not to the peer who issued the request.
3. If TTL is greater than zero, recursive routing was being used (R
flag is set in the common header), and the peer cannot generate a
response for the received request, it determines the next hop
from its routing or neighbor tables, creates a request
transaction, and passes it the request after decrementing TTL by
one in the common header. The transaction has the same
identifier (source-ID, transaction-ID) as the one received in the
request. The rest of the forwarded request remains unchanged.
4. If TTL is greater than zero, iterative routing was being used,
and the peer cannot satisfy the request, it determines the next
hop from its routing or neighbor tables. It then creates a
response transaction and passes it a 302 (Next Hop) response.
The peer includes its Peer-Info and the next hop Peer-Info object
in the response.
5. If a peer receiving the request determines that it can generate a
response, it checks if the Request-Options object was present and
whether request-routing-table or request-neighbor-table and in-
separate-request flags were set. If set, the peer waits for a
random time between RA and RB seconds, and sends a copy of its
routing or neighbor table or both in an ExchangeTable request to
the peer which issued the request. If in-separate-request was
not set, the peer includes in the response up to 256 routing and
neighbor table entries each.
6. The peer checks if it can update its routing and neighbor tables
from the received request or response.
7. The peer receiving the response searches for the corresponding
request transaction in its transaction table. If a request
transaction is found, and if the peer receiving the response was
the request originator it passes the response to the overlay
layer. Otherwise, it terminates the request transaction, creates
a response transaction and passes it the received response. The
response is sent to the same IP address and port number from
which the request was received. If a request transaction is not
found and the peer receiving the response was not the request
originator, the response is discarded.
4.3.1. ACK generation
A node MUST send an ACK for every request, response, responseACK, or
indication received over unreliable transport. The following diagram
depicts the message for requests forwarded in a recursive manner over
unreliable transport.
Baset, et al. Expires May 22, 2008 [Page 32]
Internet-Draft Peer-to-Peer Protocol November 2007
A B C
(idA) (idB) (idB)
| req(sid=idA,rid=) | |
|----------------------->| |
| ACK(sid=idA,rid=idB) | |
|<-----------------------| req(sid=idA,rid=) |
| |------------------------>|
| | respACK(sid=idA,rid=idC)|
| |<------------------------|
| | ACK(sid=idA,rid=idC) |
| |------------------------>|
|respACK(sid=idA,rid=idC)| |
|<-----------------------| |
| ACK(sid=idA,rid=idC) | |
|----------------------->| |
Figure 6: Message flow for requests forwarded in a recursive manner
over unreliable transport.
The encoding of response-ID field in the ACK is according to the
following rule: If no response-ID was received in the message, then
the node generating an ACK MUST include its own peer-ID as the
response-ID. If the source-ID and response-ID field were already
present in the message, then the ACK message should copy back
source-ID and response-ID fields.
4.3.2. Recursive and Iterative Routing
P2PP does not require all peers must use either recursive or
iterative routing. Based on their connectivity information, peers
may choose to send requests in a recursive or iterative manner. The
request routing mechanism is determined by a recursive or iterative
flag in the common header. Only requests can be sent in a recursive
or iterative manner. Below, we discuss the issues involved in the
use of recursive and iterative routing that highlight the need to
support both mechanisms. Further, we also discuss the issues that
are peculiar to the recursive or iterative forwarding of requests.
4.3.2.1. Loop Detection
Iterative routing does not require the design of complicated
mechanisms, such as route-log, for detecting forwarding loops nor is
there a need to design mechanisms for message forking and fork
explosion.
Baset, et al. Expires May 22, 2008 [Page 33]
Internet-Draft Peer-to-Peer Protocol November 2007
4.3.2.2. Rogue Peer
If the message is forwarded in a recursive manner, a rogue peer along
the request path may simply drop the message. It will be a while
before the request originator realizes such a behavior. In iterative
routing, a peer has control of the messages and it could quickly
determine if its messages are being dropped.
4.3.2.3. Secure Channel Establishment
In recursive routing, a peer sends a message to its routing or
neighbor peers. It is likely that a node sending the message has a
secure reliable or unreliable channel with its routing or neighbor
peers. In iterative routing, a node may need to communicate with
previously uncontacted peers. It is quite possible that the peers
contacted during iterative routing may never be contacted again.
When requests are routed in an iterative manner, and if a peer
somehow has certificate of the communicating peer, it may use DTLS or
TLS.
In DTLS the secure channel establishment at least requires two RTT of
setup time. In addition, for TLS, a TCP connection must be
established. This requires 1.5 RTT of setup time. The nodes can
securely communicate after the establishment of secure and/or
reliable channel.
If a node uses DTLS or TLS to establish a secure channel with other
nodes while forwarding requests in an iterative manner, it could
incur a per hop setup overhead of 2 and 3.5 RTT for DTLS and TLS,
respectively. Recursive routing does not have this setup overhead
because nodes typically only communicate with peers in their routing
and neighbor tables with which they have a long lived secure
connection. This makes the choice of iterative routing less
attractive than recursive routing.
As discussed in Section 4.3.2 iterative routing has three nice
properties. First, unlike recursive routing, the request originator
has control over which nodes it should contact. Second, the number
of message hops is always one which prevents complicated routing bugs
and schemes for loop detection. Finally, it prevents fork explosion
when parallel copies of the request are issued in a recursive manner.
Thus, we believe, there is a need to incorporate iterative routing
mechanism as part of P2PP and ensure that the use of underlying
transport protocol such as DTLS does not impact the performance of
iterative routing vis-a-vis recursive routing. Clearly, DTLS is
unsuitable for iterative routing due to it's per hop secure channel
setup overhead. Therefore, we propose a to design a new secure and
Baset, et al. Expires May 22, 2008 [Page 34]
Internet-Draft Peer-to-Peer Protocol November 2007
unreliable transport protocol which preserves message confidentiality
and integrity, and is geared towards iterative routing in overlay
networks. This suggestion is open to discussion.
4.3.2.4. NAT Traversal
Recursive routing is more friendly towards NATs and firewalls since a
peer sends a message to the peers that have been recently
communicated with. In iterative routing, a peer will likely have to
send a message to a previously unknown peer. This unknown peer could
be behind a NAT. A mechanism based on an offer/exchange mechanism of
ICE will incur a significant communication overhead (REF:sec).
Further, it is possible that a peer may not need to subsequently
communicate with this peer behind the NAT and the overhead of ICE
connectivity checks is perhaps overkill. The other mechanism to
communicate with a peer behind a NAT is that a peer simultaneously
sends the message to the host, server reflexive, and relay address of
the peer behind a NAT. This requires the peer behind a NAT to
publish and periodically refresh this information.
4.3.2.5. Route Log
The recursive forwarding of requests require intermediate peers to
maintain state. The peers forwarding the request in a recursive
manner may avoid the need of maintaining state by adding their Peer-
Info objects to the route-log. The peers can only add their Peer-
Info objects to the route-log if it was explicitly requested by the
request originator.
As discussed in Section 4.2, the approximate size of a peer-info
object containing peer-ID and host, server-reflexive, and relay
addresses is 78 bytes. If the request traverses approximately 20
hops, the route-log size can easily exceed UDP MTU (assuming UDP is
1,500 bytes). Route-logs are not needed when messages are forwarded
in an iterative manner.
4.4. Message Encoding Guidelines
The message originator sets the source-ID in the message header and
includes its peer-info object in the message. It may set the peer-ID
object in the peer-info object. The peer generating an ACK or a
response retains the request originator peer-ID in source-ID field.
Additionally, it sets its own peer-ID in the response-ID field in the
common header and includes its peer-info object. Unless requested by
the message originator, the ACK or response message does not include
the request originator's peer-info object. The rationale is that the
request originator's peer-info has already been seen by the peers
along the request path and its inclusion in the response or an ACK
Baset, et al. Expires May 22, 2008 [Page 35]
Internet-Draft Peer-to-Peer Protocol November 2007
gives no further information.
If the message originator requested a route log, then peers along the
message path MUST add their peer-info objects after the peer-info
objects in the received message.
4.5. Enrollment and Authentication
This section describes secure enrollment and authentication in a
P2PSIP network using PKCS#10 on top of TLS and an optional HTTP
digest mechanism. The secure enrollment assumes the existence of a
Registration Authority (RA) and Certificate Authority (CA). The
functions of RA and CA can be implemented in separate network
entities, however for simplicity assume we that they are collocated
in one entity called an enrollment and authentication (E&A) server.
To enroll in an overlay, a user chooses an identifier and a password.
The user identifier can be an email address, a SIP AoR, or any
appropriate blob. The node then generates a public/private key pair
and embeds the user and node identifier in the distinguished name of
a certificate signing request (CSR). The node must store the private
key as securely as possible. The CSR is encoded using PKCS#10
[REF:]. The node then establishes a TLS connection with the server
(without client certificate authentication) and sends the CSR with
H(password) to the enrollment and authentication server (E&A) in an
enroll request.
If the request is authenticated, the server creates a random or a
static peer-ID and embeds it in a DER encoded X.509 certificate along
with the user identifier. It then sends this X.509 certificate
containing user-ID, peer-Id and the expiration time in a 200 (Ok)
response to the peer that sent the enroll request. If a bootstrap
server is co-located with the E&A server, the 200 response includes a
P2P-Options TLV and a list of bootstrap peers.
One reason for the server to choose a peer-ID for the peer instead of
the peer randomly generating its peer-ID is that a joining peer is
unaware of the hash algorithm being used. The other reason is that
it prevents a node from selecting a peer-ID or set of peer-IDs that
it may use occupy a certain position in a structured overlay. In a
mobility based deployment of P2PP, the server may assign the same
peer-ID to the peer during its subsequent runs to minimize the effect
of churn.
A node which is already enrolled does not generate a new public /
private key pair. Instead, it uses its existing public key and
user-ID to generate a CSR and sends it along with a H(password) to
the E&A server in an authenticate request. (TODO: certificate reuse
Baset, et al. Expires May 22, 2008 [Page 36]
Internet-Draft Peer-to-Peer Protocol November 2007
before expiry)
The enrollment and authentication mechanism is separate from the
bootstrap mechanism because overlay may be formed in a non-secure
environment. The E&A and bootstrap servers may be co-located. This
is useful in a small network scenario.
A first peer in the overlay or any peer can also act as an E&A
server.
The separation of user-ID and peer-ID allows multiple devices
representing the same user to participate in the overlay. An
structured overlay implementer may use peer-ID=H(user-ID), which
would mean that a node publishing the user-info object is the one
responsible for it.
4.5.1. HTTP Digest Authentication
TODO: draw figure.
The message flow describes enrollment process in P2PSIP including the
certificate request originated by a P2PSIP node using PKCS#10 with
HTTP Digest on top of TLS. The flow starts with a P2PSIP node
generating a public-private key pair. Next the P2PSIP node
establishes a TLS connection with an enrollment server. It may
registers its user-ID and password. The user-ID is in the form of
SIP URI: username@domain. The registration of a user-ID and password
can be separated from the enrollment process; however in this example
we assume that both processes happen at the same time.
Next the P2PSIP node sends a POST HTTP request to the enrollment
server which generates an 403 Unauthorized response. The response
contains a WWW-Authenticate header which instructs the node to use
HTTP Digest authentication. The node creates a PKCS#10 request with
the user-ID, public key, and optionally additional attributes and
extensions. It sends the PKCS#10 request in the HTTP request by
calculating the Authorization header values using the username and
password.
When the enrollment server receives the request, it verifies the
Authorization header using user name and password as specified in RFC
2617 [X]. If the verification succeeds, the incoming PKCS#10 request
is taken in for further processing. After the PKCS#10 request has
been processed and certificate(s) has been created, the enrolment
server generates a HTTP response containing the certificate. The
enrolment server generates a single certificate that includes both
the user-ID and a peer-ID. When P2PSIP peer/client receives the
certificate(s), it stores the certificate (or set of certificates) to
Baset, et al. Expires May 22, 2008 [Page 37]
Internet-Draft Peer-to-Peer Protocol November 2007
the local certificate management system.
OPEN ISSUE: Is it more reasonable to include the user-ID and the
peer-ID in a single certificate or to have separate certificates?
4.5.2. Authentication without a Central Authority
TBD. Shared secret is one of the mechanisms.
4.6. Bootstrap
To join an overlay, a joining peer (JP) must determine the peer
protocol that is being run in the overlay and must discover a peer
that is already part of the overlay, thereafter called an admitting
peer (AP). The bootstrap process assumes that JP has already been
enrolled and authenticated.
There are different mechanisms to discover a node already in the
overlay as specified by Matthews [21]. This specification defines
one mechanism, namely, bootstrap node or server that a joining peer
can use to discover a peer already in the overlay. This mechanism
assumes that the joining node already knows the IP address and port
number of a bootstrap node or server. The bootstrap node may or may
not be part of the overlay and it may be co-located with the
enrollment and authentication server.
To discover the peers already in the overlay, a JP sends a bootstrap
request to the bootstrap node or server. The bootstrap node or
server replies with its own peer-info object, the peer-info object of
the peer that sent the bootstrap request along with its randomly
generated peer-ID, a list of peer-info objects representing peers in
the overlay, and a P2P-Options TLV. The JP then sends the join
request to one of the peers in the list. If the list is empty, then
the joining peer is the first peer in the overlay.
A node sending the bootstrap request sets a 32-bit source-ID of
0x00000000. The bootstrap node sets a 32-bit response-ID of
0x00000001 in its response, even if it is part of the overlay,
because the peer sending the bootstrap request may not be aware of
the overlay parameters.
If a JP has obtained a list of bootstrap peers in response to
authenticate request, it does not need to send a bootstrap request.
4.7. Joining, Leaving
Baset, et al. Expires May 22, 2008 [Page 38]
Internet-Draft Peer-to-Peer Protocol November 2007
4.7.1. Join
A JP discovers the overlay protocol and existing peer in the overlay
using the bootstrap mechanism described in Section 4.6. It then
sends a join request to the peer in the overlay. The overlay nodes
are connected in a graph and conceptually, a JP adds a new vertex to
this graph. Thus, the join process should correctly inform the JP's
immediate neighbor peer(s) and take ownership of any resource-objects
from them. Overall, the join operation involves the following steps:
1. Determine its reachable address.
2. Discover the peer(s) where the node will join.
3. Inform the discovered peer(s) about itself.
4. Build routing and neighbor tables (if any).
5. Get ownership of any resource-objects.
6. Publish user-info, the reachable address for the user.
A JP searches for an appropriate STUN and TURN server in the overlay.
The criteria for searching a STUN and/or a TURN server depends on the
overlay implementer. After searching for the appropriate server, a
JP determines its host, server-reflexive, and relay addresses.
The JP MAY request the join request to be forwarded in a recursive
(R=1) or an iterative manner (R=0). It does so by setting the
appropriate value of R flag in the common header. A peer receiving
the join request with the recursive routing flag set forwards it to
the peer where JP will join. A peer receiving the join request with
iterative routing flag set replies with a 302 (Next Hop) response if
the JP will not be its immediate neighbor.
If a peer receiving the request determines that the JP will be its
neighbor, it MUST send a 200 (Ok) response to the node from which it
received the request. The response contains the time before which
the JP should send a keepalive message. The response may also
contain a copy of the neighbor table of the peer.
Once the JP receives a 200 (Ok) response, it checks the received
neighbor table. It then sends a join request with the S flag set in
the Request-Options object to the peers in the received neighbor
table. The join request with S flag set indicates the overlay peers
that the JP will be their new neighbor. It is up to the peer
generating the 200 (Ok) response to decide, based on the p2p
algorithm being used, which neighbors (successors, predecessors) a
Baset, et al. Expires May 22, 2008 [Page 39]
Internet-Draft Peer-to-Peer Protocol November 2007
joining peer may contact to insert itself appropriately in the
overlay. The neighbors of this newly joining peer should update
their neighbor and routing tables appropriately. If the structured
peer protocol does not require a neighbor table, then the join
request with S flag is not sent.
A JP MAY request to receive a copy of routing and neighbor tables of
the peers that receive the join request. It does so by following the
rules defined in Section 4.3.
Finally, a JP publishes the user-info object in the overlay as
described in Section 4.8.1. The user-info object contains the X.509
certificate, and the host, server-reflexive, and relay addresses of
the peer. The successful response contains an Expires header. A
node keeps track of the resource-objects and their expire times in a
'Publish Table' (Section 4.1). A JP should resend a publish request
with the user-info object before the passage of time in Expires
header.
Once, the JP has successfully joined the overlay, its neighbor peers
transfer it the ownership of appropriate resource-objects, using a
Transfer request. The JP may also establish secure connections with
its routing or neighbor peers.
4.7.1.1. Rejecting or Deferring a Join Request
Peers in the overlay may decide to reject a join request with a 406
(Request Rejected) response because it does not satisfy the overlay
policy for peers. NAT and node resources are examples of such
policies. This specification does not specify any policy for peer
admission and defers this decision to the overlay operator.
Peer(s) in the overlay may not be willing to admit a JP node with no
history about its uptime. If so, they reply with a 407 (Join Request
Deferred) response and an Expires object after which the peer can
reissue the join request. The JP receiving this response should join
as a client in the overlay. It should reissue the join request
without setting the peer flag in the common header.
After the passage of time in Expires header, a client may attempt to
insert itself again as a peer in the overlay. The AP or other peers
may explicitly invite the client to join the overlay before the
passage of time in the Expires field by sending an Invite request.
4.7.1.2. Client Join
A client enrolls and authenticates itself and discovers a peer
already in the overlay using mechanisms defined in Section 4.5 and
Baset, et al. Expires May 22, 2008 [Page 40]
Internet-Draft Peer-to-Peer Protocol November 2007
Section 4.6, respectively. It gathers its reachable addresses
(Section 4.7.1.3) and sends a join request without setting the peer
flag in the common header. The peer receiving the join request may
immediately reply with a 200 (Ok) request if it can support a new
client. It is up to the overlay implementer to decide how many
clients may connect to a peer. If a AP determines that it already
has a certain number of clients, it replies with a 302 (Redirect)
response containing a list of peers to which a client may send the
join request.
After receiving a 200 response to its join request, the client
publishes its user-info as a resource-object object in the overlay.
The resource-object types are defined in Section 13. If the
resource-object insertion is successful, the AP sends a 200 (Ok)
response to the client and includes an Expires header. The client
then establishes a TCP connection with the AP and periodically send
it a keepalive. It sends all subsequent requests to its connected
peer.
4.7.1.3. NAT traversal
A peer receiving a join request MUST include a resource-list object
in its response indicating whether it is acting as a STUN or a TURN
server. A peer may then gather its ICE candidates.
The recommended operation mode is that each peer acts as a STUN or
TURN server.
4.7.2. Leave
A peer sends a Leave indication to gracefully inform its routing or
neighbor peers about its departure. It includes in the leave message
a list of resource-objects the neighbor nodes should take over. The
peers receiving a leave message must update their routing or neighbor
tables appropriately.
A peer SHOULD send the leave message over TCP as the size of peer-IDs
and resource-objects is likely to exceed MTU. However, a peer SHOULD
avoid a new TCP connection to send the leave message.
A client MAY also send a leave message to inform its peer(s) about
its impending departure.
(Open Issue: The user should not have to wait for the p2p application
to shut down. The p2p application is waiting for the receipt of
Leave ACK.)
Baset, et al. Expires May 22, 2008 [Page 41]
Internet-Draft Peer-to-Peer Protocol November 2007
4.8. Publish, LookupObject, LookupPeer
4.8.1. Publish
A node sends a publish request to a peer already in the overlay to
publish a new resource-object or update an existing resource-object.
A node typically sends a publish request in response to a usage layer
API call. The resource-object have a content-type and a sub-type;
the commonly used types are User-Info, STUN, TURN, and STUN+TURN.
The publish operation involves locating the peer responsible for the
resource-object and then inserting either the network address of the
resource-object publisher or the resource-object itself.
The publisher of the resource-object MUST also include information
about its owner in the publish request because it may not necessarily
be the owner of the resource-object. It is possible for multiple
owners to publish or update an existing resource-object, as a peer
may be interested in retrieving the resource-object published or
updated by a certain owner.
Additionally, a publisher must ensure that the integrity of the
resource-object is preserved. It computes a digital signature over
the whole resource-object, and includes the Signature object and its
X.509 certificate as a sub-TLV of the resource-object. The signature
is encoded using PKCS#7.
The format of the Owner TLV is left to the overlay implementer. It
can be a user-ID or a peer-ID. (TODO: can we leave it to the overlay
implementer?)
A peer generating a 200 (Ok) response to a Publish request MUST
include an Expires header. The publisher of the resource-object MUST
reissue the Publish request before the passage of time in Expires.
A peer storing the resource-object MUST store the object signature
and X.509 certificate of the resource publisher.
4.8.2. LookupObject
A node issues a LookupObject request to retrieve a resource-object
from the overlay. It sets the content-type, sub-type, and
resource-ID fields in the Rlookup TLV. Additionally, it may set the
owner field in RLookup TLV.
A peer receiving the LookupObject request must include in its 200
response the certificate of the object publisher. If multiple owners
had published data under the resource-ID being searched, and if the
owner is not specified, the peer storing the resource-object includes
Baset, et al. Expires May 22, 2008 [Page 42]
Internet-Draft Peer-to-Peer Protocol November 2007
all objects in its response.
The resource-object size may exceed UDP MTU if the request was sent
over UDP. The node responsible for the resource-object replies with
a 480 (Alternative Service) response. The query originator, on
receiving this response, reissues the LookupObject request over TCP
to the peer responsible for the resource-object.
The peer generating a 200 response for a LookupObject request MUST
include the X.509 certificate of the publisher in its response.
4.8.3. LookupPeer
A peer issues a LookupPeer request to discover another peer in the
overlay. For example, in Bamboo [22], a peer uses global tuning and
local tuning to update its routing table. In these methods, a peer
issues a lookup on an identifier which has L digits in common with
peer-ID but differs in the (L+1)st digit (global tuning), or
periodically contacts a random member of its routing table and
requests all members at a certain level (local tuning). To
accomplish this, a peer can issue a LookupPeer request. (TODO:
reword)
A peer can issue a LookupPeer request to locate a single peer,
multiple peers or range of peers. The 'Num' field controls the
maximum number of peer-info objects returned in the response.
4.9. Maintenance
A peer performs various maintenance operations to maintain links with
other peers in the overlay. The maintenance operations use the
messages provided by P2PP to maintain links with other peers in the
overlay. This involves the following two operations:
1. KeepAlive to neighbor and routing peers after the expiry of KAT
timer.
2. Periodic update of neighbor and routing tables after the expiry
of RMT and NMT timer.
A client sends a periodic keepalive to its peer to maintain its link
with the peer.
P2PP provides three messages namely, KeepAlive, ExchangeTable, and
LookupPeer for overlay maintenance. KeepAlive is used to determine
the liveness of the destination peer; ExchangeTable is used to obtain
the routing and/or neighbor table of the peer; and LookupPeer is used
to search for a specific peer to fill a routing-table entry. The
Baset, et al. Expires May 22, 2008 [Page 43]
Internet-Draft Peer-to-Peer Protocol November 2007
transmission of these requests is governed by timers in
Section 4.9.1. Additionally, a receipt of a message from a neighbor
or routing peer results in updating its keepalive timer. It is up to
the overlay implementer to adjust the values of these timers.
The maintenance algorithms are DHT specific and are specified in a
separate draft (TODO). However, the messages to accomplish
maintenance operations are defined in this draft.
4.9.1. Node Timers
This section defines node-specific timers for overlay maintenance and
ExchangeTable requests. The timer values are only provided as a
reference. The overlay implementer is free to choose a suitable
value depending on the system requirements.
Timer Value Description
---------------------------------
KAT 10s KeepAlive timer
RMT 30s Routing-table maintenance timer
NMT 30s Neighbor-table maintenance timer
RT 30s Replication management timer
RRT Var. Resource refresh timer
RA 10s Start of range-time for message transmission
RB 30s End of range-time for message transmission
(TODO: a separate draft for overlay maintenance operations)
4.10. Replication
The replication mechanism describes how resource-objects are
replicated in the overlay. It is necessary to replicate resource-
objects in the overlay to maintain their availability during churn.
Resource-objects can be replicated by the publisher or by the node at
which they are stored. The number of replicas depends on the
availability requirements.
Either the node which publishes the resource or the node at which the
resource-object is stored can initiate replication. P2PP provides a
replicate request to replicate a group of resource-objects.
The replication process is triggered after the expiry of RT
(replication management timer). If there has not been any change in
the routing or neighbor table of a peer, there is no need to
replicate.
Baset, et al. Expires May 22, 2008 [Page 44]
Internet-Draft Peer-to-Peer Protocol November 2007
4.11. Capabilities and Diagnostics
(TODO: This section needs to be elaborated.)
P2PP provides a mechanism to allow nodes with heterogeneous
capabilities to exchange their capabilities and their current
resource utilization. Nodes exchange their resource-utilization and
their capabilities during maintenance and at join. Nodes should
exchange capabilities when establishing communication for the first
time. The capabilities and diagnostic information is included as
part of Peer-Info object.
P2PP provides a GetDiagnostic request message. Peers can use this
message to send their current capabilities and diagnostic information
to another peer or a central server. This is useful for debugging
purposes.
Peers can use Query request (Section 8.9 to explicitly request the
capabilities of another peer.
Baset, et al. Expires May 22, 2008 [Page 45]
Internet-Draft Peer-to-Peer Protocol November 2007
5. P2PP Processing
5.1. Resources and Services
The resource-object represents the resources a node is responsible
for or the services it may provide. A resource-object has a type, a
sub-type, a resource-ID, and a value. It has additional attributes,
namely, owner, expires, signature, peer-info, and X.509 certificate.
The type and sub-type identify the type of resource-object that is
being published or searched. The resource-ID represents a searchable
identifier for a resource or a service and is qualified by the type
and sub-type fields. It is possible for different resource-objects
and services to have the same resource-ID (representing a
discoverable identifier), but a different type and sub-type. Thus,
type and sub-type represent a unique namespace in the system. The
peer-info represents the publisher of the resource-object.
It is possible for a peer or a set of peers to provide the same
service. Many peers may be interested in using the service provided
by different peers. The protocol should provide a mechanism for
peers to publish their service information, to discover the peers
providing the same service and to judiciously balance the load on the
service peers. We discuss four different ways in which a peer can
advertise their service information for appropriate discovery by
interested peers.
Standard Service Name: All peers use a standard service name to
advertise the same service. The standard service name represents a
discoverable identifier and is published in resource-ID field of the
resource-object. In structured networks such as DHTs, keys are
stored against identifiers. If a standard service name was used, it
will always hash to a particular value. The information about all
peers providing the same service will be stored at a peer with an
identifier closest to the hash value of a service name. A peer which
happens to have a peer-ID that is closest in the DHT sense to the
hash of the service name will end up storing information about all
peers providing this service, and will need to replicate it to
neighbor peers for availability. In a large system where hundreds or
thousands of peers may provide the same service, this scheme
overburdens the storage and bandwidth capacity of the peer
responsible for this information.
ReDiR: ReDiR is a mechanism proposed by OpenDHT [10] that addresses
the issues discussed above. ReDiR proposes to build a two-
dimensional quad-tree of the nodes that have joined under a key and
embeds them in the DHT using Publish/LookupObject interface. Using
this tree, ReDiR performs lookup in logarithmic number of operations
and based on past lookups, it can reduce the average lookup to a
Baset, et al. Expires May 22, 2008 [Page 46]
Internet-Draft Peer-to-Peer Protocol November 2007
constant number of operations. To publish its service advertisement,
a node picks a random level l, and computes a hash of service name
and l H(service_name,l). If node(s) providing the service exist at
this level, it recomputes H(service_name,l+1) and searches for the
next level. It then publishes its service information at the next
available level.
Random Id: Another mechanism to prevent service advertisement and
lookup requests always going to a certain peer is to pick k random
identifiers and publish the service advertisement under those random
identifiers. A node searching for a peer providing a certain service
picks up a random identifier and searches it in the overlay for
corresponding service name. The idea is that it will likely hit upon
a node which provides this service if a sufficient number of
advertisements were published in the overlay.
Random Walk and Learning: One option is not to explicitly publish
information about the nodes providing the service and instead spread
this information implicitly. A node must have a routing table and
may have a neighbor table. The routing and neighbor peers of a node
inform it about the list of services they are providing in a
Resource-List TLV. Since a node's routing table may contain few
hundred (realistic?) entries, it is possible that some of them may
provide the service. A node searching for a peer providing certain
service performs a random walk over its routing or neighbor peers
till it finds an appropriate peer.
Note that the first three schemes are geared towards DHTs while the
last scheme is applicable to unstructured networks. The resource
(service) publishing and discovery uses the APIs provided the
underlying peer protocol and is not tied to the underlying peer
protocol. The peers can also learn about the nodes providing a
certain service as a side effect of other messages received. This is
exactly what random walk and learning scheme achieves.
5.2. NAT Traversal
The easiest and simplest way solve NAT traversal issues in a global
deployment is to only allow nodes with unrestricted network
connectivity to become peers. In such a scenario, all peers act as
STUN and TURN servers. This is however not realistic on the Internet
as is or applicable for P2PSIP providers that cannot afford large
numbers of public peers required to support large overlays. Thus,
P2PP allows peers behind NATs to participate in the overlay.
The following issues are related to NAT traversal.
Baset, et al. Expires May 22, 2008 [Page 47]
Internet-Draft Peer-to-Peer Protocol November 2007
1. Publishing and discovery of NAT traversal service in the overlay.
2. Gathering of candidates and NAT behavior discovery.
3. Communicating with a peer behind a NAT.
4. Maintenance of NAT bindings.
5. Load balancing
5.2.1. NAT Traversal Service Advertisement and Discovery
P2PP allows peers to provide NAT traversal service. Peers providing
such a service publish this information in the overlay may use one of
the four mechanism described in Section 5.1. Additionally, for
structured overlays, peers may use hash of the autonomous system
number of their host or server-reflexive IP address as a resource-ID.
It is possible for peers at various NAT levels to offer STUN and TURN
service. Peers behind p2p-friendly NATs may also provide STUN and
TURN service [25].
5.2.2. Gathering of Candidates and NAT Behavior Discovery
At join, a JP searches for an appropriate peer providing STUN or TURN
server in the overlay using LookupObject request. It then gathers
its host, server-reflexive, and relay candidates using the discovered
peers. Note that the relay candidate is used for relaying P2PP
messages. A JP may also use NAT behavior discovery mechanisms
defined in [24] to discover the type of NAT it is behind. A JP may
use this information to determine if it should join as a peer or a
client (although this is not recommended by [24]. Alternatively, the
AP (admitting peer) decides based on the gathered candidates whether
JP satisfies the overlay implementer guidelines for a peer.
It is impossible to determine uptime guarantees for a peer providing
a STUN or TURN service. A peer should keep a list of peers providing
STUN or TURN service and may maintain and advertise more than one
server-reflexive and relay candidates.
5.2.3. Communicating with a Peer Behind a NAT
The choice of recursive or iterative routing has an impact on the
mechanisms to communicate peers behind a NAT. If a all nodes in the
overlay use recursive routing, then under low churn they only need to
communicate with their routing and neighbor peers. The nodes behind
NATs can form a communication channel with their routing and neighbor
peers by exchanging their gathered candidates in a Connect request
Baset, et al. Expires May 22, 2008 [Page 48]
Internet-Draft Peer-to-Peer Protocol November 2007
and response.
The situation changes when the overlay has moderate or heavy churn or
uses iterative routing. During these circumstances, a peer behind a
NAT may need to communicate with other peers only once; and it may
never subsequently communicate with them. Since these peers have
published their host, server-reflexive, and relay candidates in the
overlay, a peer intending to communicate with them simply sends a
copy of the message to these addresses.
5.2.4. Maintenance of NAT Bindings
A peer sends the STUN Binding request to maintain NAT bindings.
5.2.5. Load Balancing for Media Flows
5.2.6. ICE Overhead
ICE is geared towards establishing long-lived sessions. In a typical
ICE usage scenario, a peer planning to establish communication with
other peers gathers its address candidates and sends them in an offer
to the remote peer. The assumption is that a peer is unaware of the
address candidates of the remote peer and they must exchange this
information and discover the address candidates best suitable for
subsequent exchange.
In P2PP, peers gather their address candidates at join and publish
them in the overlay. Further, a node will have all the address
candidates for peers in its routing table or neighbor table. When a
user-info object is published, all the address-candidates are also
published along with it. Thus, when a user-info object is retrieved
or a peer-info object is in returned in a 302 response, they will
contain all the address candidates of the peer. A peer forwarding
requests in an iterative manner can simply send copies of the message
to all the address candidates of the peer. If subsequent
communication is desired, then the address candidates be
appropriately pruned.
TODO: Discuss below.
Encoding overhead: User and password, foundation and component-id
size. P2PP ICE encoding removed user password, and reduced
foundation and comp-id size.
TURN message exchange overhead: Allocate an address and then create
permissions in a separate message.
Baset, et al. Expires May 22, 2008 [Page 49]
Internet-Draft Peer-to-Peer Protocol November 2007
5.3. Route Log
TODO: Only needed for recursive routing.
5.4. P2PP and SIP
SIP [2] messages to peers with restricted connectivity are tunneled
through peers with unrestricted connectivity. The SIP message is
encapsulated in a resource-object and is sent to the peer responsible
for the node with restricted connectivity.
Baset, et al. Expires May 22, 2008 [Page 50]
Internet-Draft Peer-to-Peer Protocol November 2007
6. Transport Layer
This section defines mechanisms for reliably delivering a message to
the next hop. For requests, a transaction constitutes of a single
request followed by acknowledgements (if any), and a response. For
responses, reponseACKs, and indications, a transaction consists of
single response, responseACK, or indication, followed by an ACK if
unreliable transport is used. Section 3.4 and Section 3.5 discussed
the need for acknowledgements and responseACKs.
6.1. Transaction Identifier
A transaction is identified by a source-ID, transaction-ID tuple, and
a transaction-type triple. This is used to match acknowledgements
(ACK) to requests, responses and indications. However, the responses
and responseACKs are matched to requests using only source-ID and
transaction-ID tuple. A transaction can be of four types, namely,
request, response, responseACK, or an indication. The source-ID,
transaction-ID, and transaction-type must be preserved in the ACKs.
Each request or indication has a locally unique 32-bit
transaction-ID.
6.2. Message State Machine
This section defines state machine for unreliable and unreliable
transports.
6.2.1. State Machine for Unreliable Transports
For unreliable transports, the transaction state machine for requests
is shown in Figure 8 whereas state machine for responses and
indications is shown in Figure 9.
The "Trans_Msg" (abbreviation for transmit message) state is entered
when a peer sends a request, response, responseACK, or an indication.
When entering this state, the transaction should set timer T1 and T2.
Timer T1 governs retransmissions and is updated after ith
retransmission as follows: T1=2^i*T0. If timer T2 fires, the state
machine transitions to "Failed" state and is terminated.
If a request was sent and an acknowledgement was received, the state
machine transitions to "Wait_Resp" state. When entering this state,
the transaction should set timer T3. If timer T3 fires, the state
machine transitions to "Failed" state and is terminated. If a
responseACK was received, the transaction sends an ACK and is
terminated.
If a response, responseACK, or an indication was sent and ACK was
Baset, et al. Expires May 22, 2008 [Page 51]
Internet-Draft Peer-to-Peer Protocol November 2007
received, the state-machine immediately transitions to the
"Terminated" state.
+-----------+
| |
| Initial |
| |
+-----------+
|
| tx_Msg / set Timer T1 and T2
Timer T1 fires / |
T1=2^i*T0 V Transport Err. or
tx_Msg +------------+ Timer T2 fires
+------| | Inform App.
| | Trans_Msg |----------------->+
+----->| | |
+------------+ |
| | ACK received / |
+----------------------+ | set Timer T3 |
| | stop Timer T1, T2 |
| V |
| +-----------+ Transport Err. |
| responseACK rcvd / | | or Timer T3 fires |
| stop Timer T1, T2 | Wait_Resp |------------------>|
| send ACK | | |
| +-----------+ |
| | |
| | Resp received / |
| | send ACK |
| V |
| +------------+ |
| | | |
+------------------->| Terminated | |
| | |
+------------+ |
|
+-----------+ |
| | |
| Failure |<------------------+
| |
+-----------+
Figure 8: Transaction state machine for requests for unreliable
transport
Baset, et al. Expires May 22, 2008 [Page 52]
Internet-Draft Peer-to-Peer Protocol November 2007
+-----------+
| |
| Initial |
| |
+-----------+
|
| tx_Msg / set Timer T1 and T2
Timer T1 fires / |
T1=2^i*T0 V Transport Err. or
tx_Msg +------------+ Timer T2 fires
+------| | Inform App.
| | Trans_Msg |----------------->+
+----->| | |
+------------+ |
| |
| ACK received |
| stop Timer T1, T2 |
V |
+------------+ |
| | |
| Terminated |----------------->|
| | |
+------------+ |
|
+-----------+ |
| | |
| Failure |<------------------+
| |
+-----------+
Figure 9: Transaction state machine for responses and indications for
unreliable transport
6.2.2. State Machine for Reliable Transports
For reliable transports, the transaction state machine for requests
is shown in Figure 10; the state machine for responses and
indications is shown in Figure 11.
The "Trans_Msg" state is entered, when a peer issues or forwards the
request, response, or an indication. If the message was a response
or an indication and was successfully sent, the state machine
transitions to "Terminated" state. If the message was a request and
was successfully sent, the transaction sets Timer T3 and transitions
to "Wait_Resp" state. If a response is received, the transaction is
terminated. No ACK is sent for requests, responses, and indications
sent over reliable transport. Similarly, no responseACK is generated
for a request.
Baset, et al. Expires May 22, 2008 [Page 53]
Internet-Draft Peer-to-Peer Protocol November 2007
If the request was forwarded in a recursive manner, the application
MUST not terminate the reliable-transport connection. If the request
was forwarded in an iterative manner, an application MAY terminate
the reliable transport connection if it does not anticipate its
reuse.
+-----------+
| |
| Initial |
| |
+-----------+
|
| tx_Msg
|
V
+------------+ Transport Err.
| | Inform App.
| Trans_Msg |----------------->+
| | |
+------------+ |
| Msg successfully sent / |
| set Timer T3 |
| |
V |
+-----------+ Transport Err. |
| | or Timer T3 fires |
| Wait_Resp |------------------>|
| | |
+-----------+ |
| |
| Resp received |
| |
V |
+------------+ |
| | |
| Terminated | |
| | |
+------------+ |
|
+-----------+ |
| | |
| Failure |<------------------+
| |
+-----------+
Figure 10: Transaction state machine for requests for a reliable
transport
Baset, et al. Expires May 22, 2008 [Page 54]
Internet-Draft Peer-to-Peer Protocol November 2007
+-----------+
| |
| Initial |
| |
+-----------+
|
| tx_Msg
|
V
+------------+ Transport Err.
| | Inform App.
| Trans_Msg |---------------+
| | |
+------------+ |
| |
| Msg successfully sent|
V |
+------------+ |
| | |
| Terminated | |
| | |
+------------+ |
|
|
+-----------+ |
| | |
| Failure |<---------------+
| |
+-----------+
Figure 11: Transaction state machine for responses and indications
for a reliable transport
6.3. Timers
This section defines timers for message state machines.
Timer Value
----------------------
T0 500 ms
T1 T0
T2 5s
T3 5s
Baset, et al. Expires May 22, 2008 [Page 55]
Internet-Draft Peer-to-Peer Protocol November 2007
7. Security Considerations
7.1. Routing Security
7.1.1. Peer-ID Assignment
In P2PP, user-IDs and peer-IDs are assigned in a centralized and
secure manner. This provides protection against Sybil attacks [23].
The user-IDs are typically chosen by a user at the time of enrollment
and peer-IDs are chosen in a manner which preserves their uniqueness
across different network environments such as NAT. During enrollment
and/or authentication, a node sends its peer-ID and user-ID in a DER
encoded certificate signing request (CSR) to a central trusted
authority, typically the entity providing overlay software. If
approved, the CA responds with a DER encoded X.509 signed
certificate, which binds the public key of the node to the user-ID
and peer-ID. Peers and clients must enroll themselves before
participating in the overlay. Section 4.5 discusses the enrollment
process.
There are circumstances in which a central trusted authority may not
be available or has a significant establishment overhead. The
examples are overlays setup for a meeting or in a small office
environment. One of the peers, typically the first peer in the
overlay, may act as a central authority. Additionally, self-signed
certificates may be used. (TODO: Can we deprecate this mechanism?)
7.1.2. Message Forwarding and Message Integrity
P2PP provides protection against routing threats (2)-(4) by sending
and forwarding messages over secure and [un]reliable transports,
namely, DTLS or TLS. Message integrity is also provided by these
transports. P2PP provides protection against (4) by only a hash
identifier of a user-ID in its certificate or messages.
7.1.3. Routing and Neighbor Table Management
Despite secure ID assignment and message forwarding, the peers can be
compromised in an overlay. An attacker with a secure ID performing
secure forwarding can poison the routing and neighbor tables of non-
faulty nodes. (TODO: Use schemes in various p2p security papers. Is
there a need to standardize it?)
7.1.4. Admission Control
TBD.
Baset, et al. Expires May 22, 2008 [Page 56]
Internet-Draft Peer-to-Peer Protocol November 2007
7.1.5. Residual Attacks
TBD.
7.2. Storage Security
7.2.1. Integrity
P2PP provides protection against storage integrity threats by
mandating peers to digitally sign a message in a PKCS#7 format (TODO:
evaluate its overhead.) Peers store their X.509 certificates with
the stored data which allows nodes searching for the stored data to
verify its integrity.
7.2.2. Permissions
TODO
7.2.3. Quota
TODO
7.2.4. Residual Attacks
TODO
Baset, et al. Expires May 22, 2008 [Page 57]
Internet-Draft Peer-to-Peer Protocol November 2007
8. Message Formats
All P2PP messages begin with a common header, followed by a sequence
of type-length-value (TLV) objects. This section describes all P2PP
messages and their contents at a high level in ABNF [4].
P2PP defines eighteen messages as shown below. The messages are
grouped together by related functions they perform.
P2PP-Msg = Enroll / Authenticate / Bootstrap /
Join / Leave / KeepAlive /
LookupPeer / ExchangeTable / Query
Replicate / Transfer /
Publish / LookupObject / RemoveObject /
Tunnel / Connect
Invite /
GetDiagnostics
8.1. Enroll
Enrolls the user in the overlay.
Enroll = Common-header
[Request-Options]
Peer-Info
Certificate-Sign-Request
Password
Enroll (Resp) = Common Header
Peer-Info
X.509-Certificate
[P2P-Options]
[Peer-Info]*
[Ext]
8.2. Authenticate
Authenticate the user and generates a certificate binding user-ID,
peer or client ID, and public key of the peer.
Authenticate = Common-header
[Request-Options]
Peer-Info
Certificate-Sign-Request
Password
Baset, et al. Expires May 22, 2008 [Page 58]
Internet-Draft Peer-to-Peer Protocol November 2007
Authenticate (Resp) = Common Header
Peer-Info
X.509-Certificate
[P2P-Options]
[Peer-Info]*
[Ext]
8.3. Bootstrap
A request sent by a peer or a client to a bootstrap server or peer to
discover the IP address of a peer already in the overlay.
Bootstrap = Common-header
Peer-Info
Bootstrap (Resp) = Common Header
Peer-Info (bootstrap peer)
Peer-Info (request originator)
P2P-Options
[Peer-Info]*
[Ext]
P2P-options = Hash-algorithm
Hash-algorithm-length
DHT-algorithm
OverlayID-length
Overlay-ID
8.4. Join
A request sent by a peer to join the overlay. The join request sent
by a client is not forwarded to other peers.
Join = Common-header
[Request-Options]
Peer-Info
Baset, et al. Expires May 22, 2008 [Page 59]
Internet-Draft Peer-to-Peer Protocol November 2007
Join (Resp) = Common Header
Peer-Info
[Peer-Info]*
[Expires]
[Routing-Table]
[Neighbor-Table]
[Ext]
Routing-table = Num-entries
[Peer-Info]*
Neighbor-peers = Num-entries
[Peer-Info]*
8.5. Leave
Peers send the leave indication to their routing and peers indicating
their departure. Clients periodically send the leave message to
their respective peers.
Leave = Common-header
Peer-Info
[Peer-Info]*
[Resource-object]*
8.6. KeepAlive
Peers periodically send a keepalive indication to their routing and
neighbor peers to check whether they are alive. Clients send a
keepalive to their peers to check whether they are alive.
KeepAlive = Common-header
Peer-Info
Expires
KeepAlive (Resp) = Common-header
Peer-Info
Expires
8.7. LookupPeer
Peers send this request to discover a peer that may fill or update a
missing entry in their routing or neighbor table.
LookupPeer = Common-Header
[Request-Options]
Peer-Info
Baset, et al. Expires May 22, 2008 [Page 60]
Internet-Draft Peer-to-Peer Protocol November 2007
PLookup
LookupPeer (resp) = Common-Header
Peer-Info
[Peer-Info]*
[Ext]
8.8. ExchangeTable
Peers periodically send this request to their routing and neighbor
peers obtain their routing and neighbor tables.
ExchangeTable = Common-Header
Peer-Info
Request-Options
ExchangeTable (resp) = Common-Header
Peer-Info
[Routing-table]
[Neighbor-peers]
[Ext]
8.9. Query
Query a peer or a client to discover the services they provide or the
resource-objects they store.
Query = Common-Header
Peer-Info
Query (resp) = Common-Header
Peer-Info
[P2P-Options]
[Resource-List]
[Ext]
8.10. Replicate
Peers periodically send this request to replicate the resource-
objects for availability. The choice of peers on which to replicate
the objects depends on the peer protocol.
Baset, et al. Expires May 22, 2008 [Page 61]
Internet-Draft Peer-to-Peer Protocol November 2007
Replicate = Common-header
Peer-Info
[Resource-Object]*
[Ext]
Replicate (Resp) = Common-header
Peer-Info
8.11. Transfer
After a successful join or graceful or ungraceful failure of peers, a
peer transfers the ownership of resource-objects using a transfer
request.
Transfer = Common-header
Peer-Info
[Resource-object]+
[Ext]
Transfer (Resp) = Common-header
Peer-Info
8.12. PublishObject
Publish a resource-object. Also, used to refresh or update an
existing resource-object.
PublishObject = Common-header
[Request-Options]
Peer-Info
Resource-Object
Publish (Resp) = Common-header
Peer-Info
Expires
8.13. LookupObject
Search for a resource-object.
LookupObject = Common-header
[Request-Options]
Peer-Info
RLookup
Baset, et al. Expires May 22, 2008 [Page 62]
Internet-Draft Peer-to-Peer Protocol November 2007
LookupObject (resp) = Common-header
Peer-Info
Resource-Object
8.14. RemoveObject
Remove a resource-object.
RemoveObject = Common-header
[Request-Options]
Peer-Info
Resource-Object
Remove (Resp) = Common-header
Peer-Info
8.15. Tunnel
Tunnel an application layer protocol message into a P2PP message.
Mostly used for sending SIP messages to peers or clients behind a
NAT.
Tunnel = Common-header
[Request-Options]
Peer-Info
Resource-Object
Tunnel (Resp) = Common-header
Peer-Info
8.16. Connect
Send an ICE offer (TBD).
Connect = Common-header
[Request-Options]
Peer-Info
Connect (Resp) = Common-header
Peer-Info
8.17. Invite
Peers send an invite request to a client, inviting them to become a
peer.
Baset, et al. Expires May 22, 2008 [Page 63]
Internet-Draft Peer-to-Peer Protocol November 2007
Invite = Common-header
Peer-Info
Invite (Resp) = Common-header
Peer-Info
Baset, et al. Expires May 22, 2008 [Page 64]
Internet-Draft Peer-to-Peer Protocol November 2007
9. Packet Formats
This section defines PDUs for the messages and their methods defined
above.
9.1. Common Header
All P2PP messages begin with a common header. It has a fixed format,
as shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2| T |A|P|R| Reserved | Request Type | TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Source-ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version (2 bits): The protocol version number. The current version
is 1.
T (2 bits): Indicates the message type: (00) for a request, (01) for
an indication, (10) for a response, (11) for a responsACK.
A flag: If set (A=1), the message is an acknowledgement for the
request, response, responseACK, or an indication. The A flag is
never set for reliable transports.
P flag: If set (P=1), the message is sent by a peer. Otherwise, a
client sends the message.
R flag: If set (R=1), the request is sent in a recursive manner.
Otherwise, it is sent in an iterative manner. The flag is not set
for responses or indications.
Request or Indication Type (8 bits): The request or indication
message type such as join and leave.
Baset, et al. Expires May 22, 2008 [Page 65]
Internet-Draft Peer-to-Peer Protocol November 2007
TTL (8 bits): A hop count for the number of peers this request can
traverse.
Magic cookie (32 bits): A field with a fixed value (0x596ABF0D) to
differentiate P2PP messages from other protocol messages such as
STUN.
Transaction-ID (32 bits): A unique number to match responses with
the originated requests. Along with source-ID, it can uniquely
identify a message in the system.
Message Length (32 bits): The byte length of the message after the
common header itself.
Source-ID (variable): The Peer-ID of the peer of client sending the
request. For DHTs, it is the fixed length output of the hash
function. For unstructured networks, it is a fixed length
identifier. The length of this field is determined at Join. For
bootstrap and authenticate requests, its length is always four
bytes.
For responses, the rightmost 9-bits of the Reserved field contain the
response code. The response contains a destination-ID field, which
is the peer-ID of the node generating the provisional or final
response.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2| T |A|P|R| Response code | Request Type | TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Source-ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Response-ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Peer-ID of the peer or client sending the response. For DHTs,
it is the fixed length output of the hash function. For
unstructured networks, it is a fixed length identifier. The
length of this field is determined during bootstrap. For
responses to bootstrap and authenticate requests, its length is
always four bytes.
Baset, et al. Expires May 22, 2008 [Page 66]
Internet-Draft Peer-to-Peer Protocol November 2007
9.2. General Object Format
Each P2PP object begins with a fixed header giving the object type
and length. This is followed by the object Value.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object-Type |A|B| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Value //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object-Type (8 bits): An IANA-assigned identifier for the type of
the object.
AB=00 "(Mandatory)": If the object is not understood, the entire
message containing it MUST be rejected with an "Object Type Error"
message with sub code 1 ("Unrecognized Object").
AB=01 "(Ignore)": If the object is not understood, it MUST be
deleted and the rest of the message processed as usual.
Length (16 bits): The byte length of the object.
The combination AB=10 and AB=11 are reserved.
9.3. P2PP TLV Objects
9.3.1. Peer-Info
Type: Peer-Info
Length: Variable (depends on the length of Peer-ID, IP version and
unhashed key if any. The Peer-Info MUST include an address-info
object or a peer-ID. It may also include additional objects such
as unhashed-ID, uptime, neighbor/resource utilization, and expires
which defines the keepalive interval. The peer issuing the
request may not include its peer-ID in the peer-Info object as it
is already included in the common header. However, peers in the
request path must include their peer-ID as well as address-info
objects.
Peer-ID:
Baset, et al. Expires May 22, 2008 [Page 67]
Internet-Draft Peer-to-Peer Protocol November 2007
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Peer-ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Peer-ID (variable): It is an identifier of the node (client or peer)
issuing or forwarding the request. For DHTs, it is a fixed-length
output of a hash function. For unstructured networks, it is also
a fixed-length identifier.
Uptime:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Uptime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Uptime (32 bits): The uptime of this peer in number of seconds.
Resource-List:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num |Resource-Type1 |Resource-Type2 |Resource-Type3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Num (8 bits): Number of resource-lists.
Resource-Type (8 bits): Same as Cont-Type in Resource-Info object.
Typically, only included for the services such as STUN or TURN
that the node is currently providing.
Address-Info:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num |R|Resv.| IP-ver| Foundation | Component-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TT | HT | Port | Peer address //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Baset, et al. Expires May 22, 2008 [Page 68]
Internet-Draft Peer-to-Peer Protocol November 2007
Num (4 bits): Number of ICE candidates.
R flag: If set, rel-addr and rel-port are included as defined in ICE
[7].
IP-Ver (4 bits): The IP version number, 4 or 6.
Foundation (8 bits): The foundation field as defined by ICE. Note
that the length of this field is only 8-bits as compared to 64-
bits as defined by ICE specification.
Component-ID (8 bits): The component-ID field as defined by ICE.
Priority (32 bits): The priority of the address obtained through
ICE.
TT (4 bits): The transport type of the address. One of UDP (0000),
or TCP (0001).
HT (4 bits): The address type of the peer as defined in ICE [7].
One of host (0000), server reflexive (0001), peer reflexive
(0010), or relayed candidate (0011).
Port (16 bits): The port on which this peer listens for requests.
Peer Address (variable): The IP address of the peer. Its length
depends on the IP-Ver field.
9.3.2. Unhashed-Id
Unhashed ID:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Unhashed-ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unhashed-ID (variable): Unhashed-ID of a user, resource, or peer
identifier. this peer. This is only included in a DHT-based
overlay.
9.3.3. Request-Options
Baset, et al. Expires May 22, 2008 [Page 69]
Internet-Draft Peer-to-Peer Protocol November 2007
Type: Request-Options
Length: Fixed (32-bit word)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|R|N|E|A|S|L| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P (1 bit): If set (P=1), designate one copy as primary for parallel
lookups.
R (1 bit) request-routing-table: If set (R=1), send a copy of the
routing table to the peer issuing the request either in a response
or in a separate ExchangeTable request. The transmission of the
routing-table copy is governed by the in-separate-request (E flag)
and partial-copy (A flag) flags.
N (1 bit) request-neighbor-table: If set (N=1), send a copy of the
neighbor table to the peer issuing the request in a response or
ExchangeTable request. The transmission of routing-table copy is
governed by the in-separate-request and partial-copy flags.
E (1 bit) in-separate-request: If set (E=1), and if R or N are also
set, the peer is requesting to receive routing or neighbor table
in an ExchangeTable request. If not set (E=0), and if R or N are
also set, each peer along the request path can add a copy of its
routing or neighbor table before forwarding the response. The
number of entries in all routing-tables should not exceed 256.
Peers along the request path may remove routing-table entries
added by a previous hop, if their own routing-tables have a better
performance metric (such as uptime) than the ones received in the
message. The size of routing-table is likely to exceed UDP MTU.
The specification recommends that the ExchangeTable request should
always be sent over TCP.
A (1 bit) partial-reply for routing or neighbor table: If set (A=1),
the peer generating the definite response sends a copy of the
routing or neighbor table as determined by the P and N flags in
its response as permitted by the UDP MTU. If E (in-separate-
request) is also set, the rest of the routing or neighbor table is
sent in a separate ExchangeTable request. The number of entries
in all neighbor-tables should not exceed 256.
Baset, et al. Expires May 22, 2008 [Page 70]
Internet-Draft Peer-to-Peer Protocol November 2007
S (1 bit): If set (S=1), the request is being sent to the immediate
neighbors of the newly joining peer. The request must be a join
request.
L (1 bit): If set (L=1), each peer along the request must add its
peer-info object that includes peer-ID, address-info, and
resource-list objects.
9.3.4. P2P-Options
Type: P2P-Options
Length: Variable (depends on the length of Overlay-ID)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Hash-Algorithm |H-Algorithm-Len| P2P-Algorithm | Base |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OverlayID Len | Overlay-ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hash-Algorithm (8 bits): An IANA-assigned identifier for the hash
algorithm.
H-Algorithm-Len (8 bits): The byte length of the hash algorithm. If
set to zero, then no hash algorithm is used.
P2P-Algorithm (8 bits): An IANA-assigned identifier for the P2P
algorithm being used.
Base: The base for hash algorithms. It is set to zero for
unstructured overlays.
OverlayID-Length (8 bits): The byte length of overlay-ID.
Overlay-ID (variable): Overlay-ID.
9.3.5. Routing-Table
Type: Routing-Table
Length: Variable (depends on the number of Peer-Info objects)
Baset, et al. Expires May 22, 2008 [Page 71]
Internet-Draft Peer-to-Peer Protocol November 2007
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num entries | |
+-+-+-+-+-+-+-+-+ [Peer-Info]+ +
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Num-entries (8 bits): Number of Peer-Info objects in the routing
table.
Peer-Info (variable): One or more Peer-Info objects.
9.3.6. Neighbor-table
Type: Neighbor-Table
Length: Variable (depends on the number of Peer-Info objects)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num entries | |
+-+-+-+-+-+-+-+-+ [Peer-Info]+ +
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Num-entries (8 bits): Number of Peer-Info objects in the neighbor
table.
Peer-Info (variable): One or more Peer-Info objects.
9.3.7. PLookup
Type: PLookup
Length: Variable (depends on the length of Peer-ID and whether this
is a range lookup)
Baset, et al. Expires May 22, 2008 [Page 72]
Internet-Draft Peer-to-Peer Protocol November 2007
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num |E|R| Peer-IDa //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Peer-IDb //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Num (6 bits): Number of peers to look for.
E (1 bit): If set (E=1), then search for a peer whose peer-ID is the
same as peer-IDa. Otherwise, return up to Num peers whose ID is
'closest' to Peer-IDa
R (1 bit): If set (R=1), then it is a range lookup. It is only set,
if E is not set.
Peer-IDa (variable): Peer-ID. The length of Peer-ID is determined
at join.
Peer-IDb (variable): Peer-ID. The length of Peer-ID is determined
at join.
9.3.8. Resource-ID
Resource-ID:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Resource-ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Resource-ID (variable): It is an identifier of the resource. For
DHTs, it is a fixed-length output of a hash function. For
unstructured networks, its length is variable.
9.3.9. RLookup
Type: Resource-Object
Length: Variable (depends on the size of resource-object)
Baset, et al. Expires May 22, 2008 [Page 73]
Internet-Draft Peer-to-Peer Protocol November 2007
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cont-type | Sub-Type | Resource-ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cont-type: An IANA assigned identifier for the type of content
contained in this resource-object.
Sub-type: An IANA assigned identifier which further classifies the
content type as defined by cont-type.
Resource-ID (variable): The Resource-ID TLV of the resource object.
Additional Information: Owner
9.3.10. Resource-Object
Type: Resource-Object
Length: Variable (depends on the size of resource-object)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cont-type | Sub-Type | Resource-ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Resource-Object-Value //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cont-type: An IANA assigned identifier for the type of content
contained in this resource-object.
Sub-type: An IANA assigned identifier which further classifies the
content type as defined by cont-type.
Resource-ID (variable): The Resource-ID TLV of the resource object.
Resource-Object-Value (variable): Variable length. Its value
depends on the content-type and sub-type.
Baset, et al. Expires May 22, 2008 [Page 74]
Internet-Draft Peer-to-Peer Protocol November 2007
9.3.10.1. Additional Information Fields
The resource-object may use the following TLVs to express additional
information about itself.
Owner (variable): The owner TLV object.
Expires (fixed): The expires TLV object.
Signature (Variable): The cryptographic signature of the resource-
object.
X509 (fixed): The X509 certificate of the peer publishing the
resource-object.
9.3.11. Expires
Type: Expires
Length: Fixed (32-bit word)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expire time in seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Expires (32 bits): Time in seconds
9.3.12. Owner
Type: Owner
Length: Variable
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Owner //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Owner (variable): The owner of the Resource-Object. Format TBD.
Baset, et al. Expires May 22, 2008 [Page 75]
Internet-Draft Peer-to-Peer Protocol November 2007
9.3.13. Certificate
An X.509 certificate.
Type: Certificate
Sub-Type: Self-Signed (0x00), Server-Signed (0x01).
Length: Variable. Depends on the size of X.509 certificate.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Certificate //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Certificate (variable): The length of X.509 certificate.
9.3.14. Signature
The signature of the resource-object.
Type: Signature
Length: Variable. Depends on the type of signature algorithm being
used.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Signature //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Signature (variable): The signature length of resource-object.
9.3.15. Capabilities and Diagnostics
Time Window:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Baset, et al. Expires May 22, 2008 [Page 76]
Internet-Draft Peer-to-Peer Protocol November 2007
Time Window (32 bits): The elapsed time in seconds since the
gathering of message statistics. This can be included as part of
every diagnostic TLV.
AS Number:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Autonomous System Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Autonomous System Number (32 bits): The autonomous system of node's
IP address, if available.
Connections:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Neighbor Peers | Number of Routing Peers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of clients |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Number of Neighbor Peers (16 bits): The number of neighbor peers of
this peer.
Number of Routing Peers (16 bits): The number of routing peers of
this peer.
Number of Clients (16 bits): The number of clients connected with
this peer.
Node-Resource-Utilization:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CPU Util. | BW. Util. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Baset, et al. Expires May 22, 2008 [Page 77]
Internet-Draft Peer-to-Peer Protocol November 2007
Peer Bandwidth (32 bits): Estimated peer bandwidth in kilo bits per
second. This is tricky to determine and is TBD.
CPU Utilization (8 bits): CPU Utilization of this peer on a scale of
1 to 100. Represent the percentage of CPU being used. If should
be an average over the last five seconds.
Bandwidth Utilization (8 bits): Bandwidth utilization of this peer
on a scale of 1 to 100. Represent the percentage of bandwidth
being used. It should be an average over the last five seconds.
Messages-Received:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg Type | Number of messages |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Msg Type (8 bits): The message types as defined in Section 13. The
number 254 is reserved for responses and 255 for ACKs.
Number of messages (24 bits): The number of messages received for
the 'msg type' since the elapsed time.
9.4. Response Codes and Errors
9.4.1. Response Codes
There are four different types of response codes. They are no
provisional response codes. The description is given below:
2xx (Success): Response data which indicates that the request has
been processed successfully in some sense.
3xx (Redirect): Response data which indicates that the request
should be redirected.
4xx (Request Failure): Response data which indicates that the
request has failed.
9.4.1.1. 2xx (Successful) Responses
Baset, et al. Expires May 22, 2008 [Page 78]
Internet-Draft Peer-to-Peer Protocol November 2007
200 Ok. A successful answer to the request.
9.4.1.2. 3xx (Redirect) Responses
302 Next Hop. This response is only generated for iterative
requests if the peer receiving the request is not the final
destination for the request.
9.4.1.3. 4xx-511 (Permanent-Failure) Responses
400 Bad request. There was an error parsing the request.
404 Not found. This response is generated for a lookup request if
the resource-object being searched for is not found.
405 Error inserting object. There was an error inserting the
resource-object.
406 Request rejected. The request was understood but rejected by
the peer.
407 Join request deferred. The peer issuing the join request should
retry after a certain time.
410 TTL hops The number of TTL hops exceeded.
413 Message too large. The response message size was too large.
This response is typically generated for unreliable transports.
418 Timeout. The request timed out. This response is generated when
request was forwarded in a recursive manner over UDP and no
response was received.
9.4.2. Error Object
TBD.
Baset, et al. Expires May 22, 2008 [Page 79]
Internet-Draft Peer-to-Peer Protocol November 2007
10. Application Layer
An application using peer-to-peer protocol issues non-blocking calls
to P2PP layer to accomplish operations, namely, join, leave, publish,
lookup, remove, and query. Since an operation may take long time to
complete, an application supplies a call-back function for each API,
not shown in the parameters. The 'in' parameters are passed to P2PP
in the API call, whereas the 'out' parameters are returned in the
call-back function after the operation is complete. Upon success,
the call-back function returns a value of zero.
10.1. Query
Query([out]Overlay-ID, [out]P2P-Algorithm, [out]Hash-Algorithm,
[out]Hash-Algorithm-Len, [in]Overlay-peer-network-address,
[in]Overlay-peer-port)
10.2. Join
Join([in]Overlay-ID, [in]Overlay-peer-network-address, [in]Overlay-
peer-port)
An application uses this API to inform the P2PP layer to start the
join process.
10.3. Leave
Leave([in]Overlay-ID)
An application uses this API to inform the P2PP layer that it wishes
to leave the overlay immediately. An application does not wait for
this operation to be completed and may shut down immediately.
10.4. Publish
Publish([in]Resource-ID, [in]Resource-Object)
An application uses this API to publish a new resource-object in the
overlay or update an existing one.
10.5. Remove
Remove([in]Resource-ID)
An application uses this API to explicitly remove a resource-object
from the overlay.
Baset, et al. Expires May 22, 2008 [Page 80]
Internet-Draft Peer-to-Peer Protocol November 2007
10.6. Lookup
Lookup([in]Resource-ID, [out]Resource-Object)
An application uses this API to search for a resource-object in the
overlay. If the resource-object is found, it is returned in the API
call.
(Open Issue: Each operation should have a crypto-signed counterpart.)
Baset, et al. Expires May 22, 2008 [Page 81]
Internet-Draft Peer-to-Peer Protocol November 2007
11. Open Issues
1. Mandatory DHT: P2PP supports bamboo but elaborate.
2. SIP record insertion and lookup.
3. ICE overhead analysis for recursive and iterative routing and in
the presence of churn.
4. Redirecting media relaying requests.
5. Overlay migration.
6. Reactive vs. periodic maintenance.
7. How can a node estimate its CPU and bandwidth utilization?
8. Non-SIP usage of P2PP
9. Secure protocol for iterative routing.
10. HTTP authentication.
Baset, et al. Expires May 22, 2008 [Page 82]
Internet-Draft Peer-to-Peer Protocol November 2007
12. Acknowledgements
The authors will like to thank the following (in alphabetical order)
for their helpful comments and suggestions. Christian Schmidt,
Christian Dickmann, Miguel Garcia, Jae W. Lee, Esko Kokkonen, Kundan
Singh, Henry Sinnreich, Eunsoo Shim and Marc Willekens.
Baset, et al. Expires May 22, 2008 [Page 83]
Internet-Draft Peer-to-Peer Protocol November 2007
13. IANA Considerations
Listening Port: The port on which a peer listens for request. The
current implementation uses 7080 for UDP and TCP and 7081 for DTLS
and TLS.
Message Types: The P2PP common header contains a one byte message
type field. A message can either be a request or a response. The
following values are allocated by this specification for request
and indication messages.
+--------------+----------------+
| Message Type | Message |
+--------------+----------------+
| 0 | Enroll |
| | |
| 1 | Authenticate |
| | |
| 2 | Bootstrap |
| | |
| 3 | Join |
| | |
| 4 | Leave |
| | |
| 5 | KeepAlive |
| | |
| 6 | LookupPeer |
| | |
| 7 | ExchangeTable |
| | |
| 8 | Query |
| | |
| 9 | Publish |
| | |
| 10 | LookupObject |
| | |
| 11 | RemoveObject |
| | |
| 12 | Replicate |
| | |
| 13 | Transfer |
| | |
| 14 | Tunnel |
| | |
| 15 | Connect |
| | |
| 16 | GetDiagnostics |
+--------------+----------------+
Baset, et al. Expires May 22, 2008 [Page 84]
Internet-Draft Peer-to-Peer Protocol November 2007
Object Types: There is a one byte field in the object header. The
following values for object types are defined by this
specification.
+-------+-----------------------------+
| OType | Object Type |
+-------+-----------------------------+
| 0 | Peer-Info |
| | |
| 1 | Peer-ID |
| | |
| 2 | Address-Info |
| | |
| 3 | Unhashed-ID |
| | |
| 4 | Uptime |
| | |
| 5 | P2P-Options |
| | |
| 6 | Request-Options |
| | |
| 7 | Diagnostic-Options |
| | |
| 8 | Routing-Table |
| | |
| 9 | Neighbor-Table |
| | |
| 10 | PLookup |
| | |
| 11 | Resource-ID |
| | |
| 12 | RLookup |
| | |
| 13 | Resource-Object |
| | |
| 14 | Expires |
| | |
| 15 | Owner |
| | |
| 16 | Certificate-Signing-Request |
| | |
| 17 | X.509-Cer7-Signature |
| | |
| 19 | Time-Window |
| | |
| 20 | Connections |
| | |
| 21 | Node-Resource-Utilization |
Baset, et al. Expires May 22, 2008 [Page 85]
Internet-Draft Peer-to-Peer Protocol November 2007
| 22 | Messages-Received |
| | |
| 23 | AS-Number |
| | |
| 24 | Error |
+-------+-----------------------------+
Algorithm: There is a one byte algorithm field in the P2P-options
object which defines the hash function being used. The following
values are allocated by this specification for this field.
+-------+-----------+
| AType | Algorithm |
+-------+-----------+
| 0 | None |
| | |
| 1 | SHA1 |
| | |
| 2 | SHA-256 |
| | |
| 3 | SHA-512 |
| | |
| 4 | MD4 |
| | |
| 5 | MD5 |
+-------+-----------+
Algorithm: There is a one byte P2P-algorithm field in the P2P-
options object which defines the p2p algorithm being used. The
following values are allocated by this specification for this
field.
Baset, et al. Expires May 22, 2008 [Page 86]
Internet-Draft Peer-to-Peer Protocol November 2007
+-------+---------------+
| PType | P2P-Algorithm |
+-------+---------------+
| 0 | Chord |
| | |
| 1 | CAN |
| | |
| 2 | Kademlia |
| | |
| 3 | Pastry |
| | |
| 4 | Bamboo |
| | |
| 5 | Tapestry |
| | |
| 6 | Accordion |
| | |
| 7 | SkipNet |
| | |
| 8 | Mercury |
| | |
| 9 | Gia |
+-------+---------------+
Cont-Type: This is a one-byte field in the Resource-Info object
which defines the content-type of the object. The following types
are currently defined.
+-----------+---------------+
| Cont-Type | Description |
+-----------+---------------+
| 0 | User-Info |
| | |
| 1 | STUN |
| | |
| 2 | TURN |
| | |
| 3 | STUN+TURN+ICE |
+-----------+---------------+
Component-ID: The component ID as defined by ICE.
Baset, et al. Expires May 22, 2008 [Page 87]
Internet-Draft Peer-to-Peer Protocol November 2007
+--------------+-------------+
| Component-ID | Description |
+--------------+-------------+
| 0 | RTP |
| | |
| 1 | RTCP |
| | |
| 2 | SIP |
| | |
| 2 | P2PP |
+--------------+-------------+
Baset, et al. Expires May 22, 2008 [Page 88]
Internet-Draft Peer-to-Peer Protocol November 2007
14. References
14.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Petersen, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of
Extensions to the Session Initiation Protocol (SIP)", RFC 4485,
May 2006.
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications:ABNF", RFC 4234, October 2005.
[5] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Simple
Traversal Underneath Network Address Translators (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-13 (work in progress),
November 2007.
[6] Rosenberg, J., Mahy, R., and C. Huitema, "Obtaining Relay
Addresses from Simple Traversal Underneath NAT (STUN)",
draft-ietf-behave-turn-05 (work in progress), November 2007.
[7] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in
progress), October 2007.
14.2. Informative References
[8] Willis, D., Bryan, D., Matthews, P., and E. Shim, "Concepts and
Terminology for Peer-to-Peer SIP",
draft-ietf-p2psip-concepts-01 (work in progress),
November 2007.
[9] Bryan, D., Lowekamp, B., and C. Jennings, "dSIP: A P2P Approach
to SIP Registration and Resource Location",
draft-bryan-p2psip-dsip-00 (work in progress), February 2007.
[10] Rhea, S., Godfrey, B., Karp, B., Kubiatowicz, J., Ratnasamy,
S., Shenker, S., Stoica, I., and H. Yu, "OpenDHT: A Public DHT
Service and its Uses", SIGCOMM '05:Proceedings of the 2005
conference on Applications, technologies, architectures, and
protocols for computer communications. Philadelphia, PA,
Baset, et al. Expires May 22, 2008 [Page 89]
Internet-Draft Peer-to-Peer Protocol November 2007
pp. 73-84, 2005.
[11] Pugh, W., "Skip Lists: A Probabilistic Alternative to Balanced
Trees", Workshop on Algorithms and Data Structures. pp. 437-
449, 1989.
[12] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D., Kaashoek,
M., Dabek, F., and H. Balakrishnan, "Chord: A Scalable Peer-to-
peer Lookup Service for Internet Applications", IEEE/ACM
Transactions on Networking, vol. 11, no. 1, pp. 17-32, 2003.
[13] Ratmasamy, S., Francis, P., Handley, M., Karp, R., and S.
Shenker, "A Scalable Content-Addressable Network", SIGCOMM '01:
Proceedings of the 2001 conference on Applications,
technologies, architectures, and protocols for computer
communications. San Diego, CA, pp. 161-172, August 2001.
[14] Rowstron, A. and P. Druschel, "Pastry: Scalable, distributed
object location and routing for large-scale peer-to-peer
systems", Proceedings of the 18th IFIP/ACM International
Conference on Distributed Systems Platforms (Middleware 2001),
March 2002.
[15] Maymounkov, P. and D. Mazieres, "Kademlia: A Peer-to-Peer
Information System Based on the XOR Metric", IPTPS'01: Revised
Papers from the First International Workshop on Peer-to-Peer
Systems London, UK, pp. 53-65, March 2002.
[16] Karger, D., Lehman, E., Leighton, T., Panigraphy, R., Levine,
F., and D. Lewin, "Consistent hashing and random trees:
distributed caching protocols for relieving hot spots on the
World Wide Web", STOC '97: Proceedings of the twenty-ninth
annual ACM symposium on Theory of computing , 1997.
[17] Balakrishnan, H., Kaashoek, F., Karger, D., Morris, R., and I.
Stoica, "Looking up data in P2P systems", Communications of the
ACM, vol. 46, no. 2, pp. 43-48, 2003.
[18] Dabek, F., Zhao, B., Druschel, P., Kubiatowicz, J., and I.
Stoica, "Towards a Common API for Structured Peer-to-Peer
Overlays", IPTPS'03: Proceedings of the 2nd International
Workshop on Peer-to-Peer Systems. Berkeley, California,
February 2003.
[19] Chawathe, Y., Ratnasamy, S., Breslau, L., Lanham, N., Kaashoek,
M., and S. Shenker, "Making gnutella-like p2p systems
scalable", SIGCOMM '03: Proceedings of the 2003 conference on
Applications, technologies, architectures, and protocols for
Baset, et al. Expires May 22, 2008 [Page 90]
Internet-Draft Peer-to-Peer Protocol November 2007
computer communications. New York, NY, USA, pp. 407-418, 2003.
[20] Li, J., Stribling, J., Morris, R., and M. Kaashoek, "Bandwidth-
efficient management of DHT routing tables", in Proceedings of
the 2nd USENIX Symposium on Networked Systems Design and
Implementation (NSDI '05). Boston, MA, USA, 2005.
[21] Cooper, E., Johnston, A., and P. Matthews, "Bootstrap
Mechanisms for P2PSIP",
draft-matthews-p2psip-bootstrap-mechanisms-00 (work in
progress), February 2007.
[22] Rhea, S., Geels, D., Roscoe, T., and J. Kubiatowicz, "Handling
Churn in a DHT", Proceedings of the 2004 USENIX Annual
Technical Conference (USENIX '04) Boston, Massachusetts,
June 2004.
[23] Docuer, J., "The Sybil Attack", IPTPS '02 , March 2002.
[24] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery Using
STUN", draft-ietf-behave-nat-behavior-discovery-01 (work in
progress), June 2007.
[25] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-
Peer(P2P) Communication Across Network Address
Translators(NATs)", draft-srisuresh-behave-p2p-state-04,
September 2006.
Baset, et al. Expires May 22, 2008 [Page 91]
Internet-Draft Peer-to-Peer Protocol November 2007
Appendix A. Background
Baset, et al. Expires May 22, 2008 [Page 92]
Internet-Draft Peer-to-Peer Protocol November 2007
Appendix B. Message Flow
Baset, et al. Expires May 22, 2008 [Page 93]
Internet-Draft Peer-to-Peer Protocol November 2007
Authors' Addresses
Salman A. Baset
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
Email: salman@cs.columbia.edu
Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
Email: hgs@cs.columbia.edu
Marcin Matuszewski
Nokia
Helsinki,
Finland
Email: marcin.matuszewski@nokia.com
Baset, et al. Expires May 22, 2008 [Page 94]
Internet-Draft Peer-to-Peer Protocol November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Baset, et al. Expires May 22, 2008 [Page 95]