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]