idnits 2.17.1 draft-baset-p2psip-p2pp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 3789. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3800. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3807. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3813. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 19, 2007) is 5996 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Address-Info' on line 1109 -- Looks like a reference, but probably isn't: 'Uptime' on line 1110 -- Looks like a reference, but probably isn't: 'Certificate' on line 1111 -- Looks like a reference, but probably isn't: 'Connections' on line 1112 -- Looks like a reference, but probably isn't: 'Node-Resource-Utilization' on line 1113 -- Looks like a reference, but probably isn't: 'Peer-Info' on line 1146 -- Looks like a reference, but probably isn't: 'Owner' on line 1147 -- Looks like a reference, but probably isn't: 'Signature' on line 1148 -- Looks like a reference, but probably isn't: 'X' on line 1568 -- Looks like a reference, but probably isn't: 'P2P-Options' on line 2593 -- Looks like a reference, but probably isn't: 'Ext' on line 2595 -- Looks like a reference, but probably isn't: 'Expires' on line 2517 -- Looks like a reference, but probably isn't: 'Routing-Table' on line 2518 -- Looks like a reference, but probably isn't: 'Neighbor-Table' on line 2519 -- Looks like a reference, but probably isn't: 'Routing-table' on line 2579 -- Looks like a reference, but probably isn't: 'Neighbor-peers' on line 2580 -- Looks like a reference, but probably isn't: 'Resource-List' on line 2594 == Unused Reference: '3' is defined on line 3633, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 3661, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 3672, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 3698, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 3704, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 3708, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 3720, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4485 (ref. '3') ** Obsolete normative reference: RFC 4234 (ref. '4') (Obsoleted by RFC 5234) == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-13 == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-05 == Outdated reference: A later version (-09) exists of draft-ietf-p2psip-concepts-01 == Outdated reference: A later version (-08) exists of draft-ietf-behave-nat-behavior-discovery-01 Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 24 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Baset 3 Internet-Draft H. Schulzrinne 4 Intended status: Standards Track Columbia University 5 Expires: May 22, 2008 M. Matuszewski 6 Nokia 7 November 19, 2007 9 Peer-to-Peer Protocol (P2PP) 10 draft-baset-p2psip-p2pp-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 22, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document defines the Peer-to-Peer Protocol (P2PP), an 44 application-layer binary protocol, for creating and maintaining an 45 overlay of participant nodes. The overlay can be created using 46 various structured and unstructured peer-to-peer protocols such as 47 Bamboo, Chord, Pastry, Kademlia, Gnutella, and Gia. P2PP uses a 48 secure transport, supports an application API, has mechanisms for NAT 49 and firewall traversal, exchanging node capabilities, and diagnostic 50 information. P2PP is designed to support a P2P Session Initiation 51 Protocol (SIP) network, but it can be used for other applications as 52 well. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 10 59 3.1. High-Level Requirements . . . . . . . . . . . . . . . . . 10 60 3.2. Node Model . . . . . . . . . . . . . . . . . . . . . . . . 10 61 3.2.1. P2PP Node Stack . . . . . . . . . . . . . . . . . . . 12 62 3.3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . 14 63 3.4. Message Model . . . . . . . . . . . . . . . . . . . . . . 15 64 3.5. Reliability Model . . . . . . . . . . . . . . . . . . . . 16 65 3.6. Security Model . . . . . . . . . . . . . . . . . . . . . . 18 66 3.6.1. Threat Model . . . . . . . . . . . . . . . . . . . . . 19 67 3.7. NAT and Firewall Traversal . . . . . . . . . . . . . . . . 20 68 3.8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 20 69 3.8.1. Peer Mobility . . . . . . . . . . . . . . . . . . . . 20 70 3.8.2. Client Mobility . . . . . . . . . . . . . . . . . . . 21 71 3.8.3. Session Mobility . . . . . . . . . . . . . . . . . . . 22 72 3.9. Overview of Operations . . . . . . . . . . . . . . . . . . 22 73 3.9.1. Enrollment, Authentication, and Bootstrap . . . . . . 22 74 3.9.2. Overlay Maintenance . . . . . . . . . . . . . . . . . 23 75 3.9.3. Data Storage and Retrieval . . . . . . . . . . . . . . 24 76 3.9.4. Connection Management and Other . . . . . . . . . . . 24 77 3.10. Overlay Migration . . . . . . . . . . . . . . . . . . . . 25 78 4. Overlay Layer . . . . . . . . . . . . . . . . . . . . . . . . 26 79 4.1. Peer State . . . . . . . . . . . . . . . . . . . . . . . . 26 80 4.2. Key Components of a P2PP Message . . . . . . . . . . . . . 27 81 4.3. Request, Response, and Indications Processing . . . . . . 29 82 4.3.1. ACK generation . . . . . . . . . . . . . . . . . . . . 32 83 4.3.2. Recursive and Iterative Routing . . . . . . . . . . . 33 84 4.4. Message Encoding Guidelines . . . . . . . . . . . . . . . 35 85 4.5. Enrollment and Authentication . . . . . . . . . . . . . . 36 86 4.5.1. HTTP Digest Authentication . . . . . . . . . . . . . . 37 87 4.5.2. Authentication without a Central Authority . . . . . . 38 89 4.6. Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . 38 90 4.7. Joining, Leaving . . . . . . . . . . . . . . . . . . . . . 38 91 4.7.1. Join . . . . . . . . . . . . . . . . . . . . . . . . . 39 92 4.7.2. Leave . . . . . . . . . . . . . . . . . . . . . . . . 41 93 4.8. Publish, LookupObject, LookupPeer . . . . . . . . . . . . 42 94 4.8.1. Publish . . . . . . . . . . . . . . . . . . . . . . . 42 95 4.8.2. LookupObject . . . . . . . . . . . . . . . . . . . . . 42 96 4.8.3. LookupPeer . . . . . . . . . . . . . . . . . . . . . . 43 97 4.9. Maintenance . . . . . . . . . . . . . . . . . . . . . . . 43 98 4.9.1. Node Timers . . . . . . . . . . . . . . . . . . . . . 44 99 4.10. Replication . . . . . . . . . . . . . . . . . . . . . . . 44 100 4.11. Capabilities and Diagnostics . . . . . . . . . . . . . . . 45 101 5. P2PP Processing . . . . . . . . . . . . . . . . . . . . . . . 46 102 5.1. Resources and Services . . . . . . . . . . . . . . . . . . 46 103 5.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 47 104 5.2.1. NAT Traversal Service Advertisement and Discovery . . 48 105 5.2.2. Gathering of Candidates and NAT Behavior Discovery . . 48 106 5.2.3. Communicating with a Peer Behind a NAT . . . . . . . . 48 107 5.2.4. Maintenance of NAT Bindings . . . . . . . . . . . . . 49 108 5.2.5. Load Balancing for Media Flows . . . . . . . . . . . . 49 109 5.2.6. ICE Overhead . . . . . . . . . . . . . . . . . . . . . 49 110 5.3. Route Log . . . . . . . . . . . . . . . . . . . . . . . . 50 111 5.4. P2PP and SIP . . . . . . . . . . . . . . . . . . . . . . . 50 112 6. Transport Layer . . . . . . . . . . . . . . . . . . . . . . . 51 113 6.1. Transaction Identifier . . . . . . . . . . . . . . . . . . 51 114 6.2. Message State Machine . . . . . . . . . . . . . . . . . . 51 115 6.2.1. State Machine for Unreliable Transports . . . . . . . 51 116 6.2.2. State Machine for Reliable Transports . . . . . . . . 53 117 6.3. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 55 118 7. Security Considerations . . . . . . . . . . . . . . . . . . . 56 119 7.1. Routing Security . . . . . . . . . . . . . . . . . . . . . 56 120 7.1.1. Peer-ID Assignment . . . . . . . . . . . . . . . . . . 56 121 7.1.2. Message Forwarding and Message Integrity . . . . . . . 56 122 7.1.3. Routing and Neighbor Table Management . . . . . . . . 56 123 7.1.4. Admission Control . . . . . . . . . . . . . . . . . . 56 124 7.1.5. Residual Attacks . . . . . . . . . . . . . . . . . . . 57 125 7.2. Storage Security . . . . . . . . . . . . . . . . . . . . . 57 126 7.2.1. Integrity . . . . . . . . . . . . . . . . . . . . . . 57 127 7.2.2. Permissions . . . . . . . . . . . . . . . . . . . . . 57 128 7.2.3. Quota . . . . . . . . . . . . . . . . . . . . . . . . 57 129 7.2.4. Residual Attacks . . . . . . . . . . . . . . . . . . . 57 130 8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 58 131 8.1. Enroll . . . . . . . . . . . . . . . . . . . . . . . . . . 58 132 8.2. Authenticate . . . . . . . . . . . . . . . . . . . . . . . 58 133 8.3. Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . 59 134 8.4. Join . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 135 8.5. Leave . . . . . . . . . . . . . . . . . . . . . . . . . . 60 136 8.6. KeepAlive . . . . . . . . . . . . . . . . . . . . . . . . 60 137 8.7. LookupPeer . . . . . . . . . . . . . . . . . . . . . . . . 60 138 8.8. ExchangeTable . . . . . . . . . . . . . . . . . . . . . . 61 139 8.9. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 61 140 8.10. Replicate . . . . . . . . . . . . . . . . . . . . . . . . 61 141 8.11. Transfer . . . . . . . . . . . . . . . . . . . . . . . . . 62 142 8.12. PublishObject . . . . . . . . . . . . . . . . . . . . . . 62 143 8.13. LookupObject . . . . . . . . . . . . . . . . . . . . . . . 62 144 8.14. RemoveObject . . . . . . . . . . . . . . . . . . . . . . . 63 145 8.15. Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . 63 146 8.16. Connect . . . . . . . . . . . . . . . . . . . . . . . . . 63 147 8.17. Invite . . . . . . . . . . . . . . . . . . . . . . . . . . 63 148 9. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 65 149 9.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 65 150 9.2. General Object Format . . . . . . . . . . . . . . . . . . 67 151 9.3. P2PP TLV Objects . . . . . . . . . . . . . . . . . . . . . 67 152 9.3.1. Peer-Info . . . . . . . . . . . . . . . . . . . . . . 67 153 9.3.2. Unhashed-Id . . . . . . . . . . . . . . . . . . . . . 69 154 9.3.3. Request-Options . . . . . . . . . . . . . . . . . . . 69 155 9.3.4. P2P-Options . . . . . . . . . . . . . . . . . . . . . 71 156 9.3.5. Routing-Table . . . . . . . . . . . . . . . . . . . . 71 157 9.3.6. Neighbor-table . . . . . . . . . . . . . . . . . . . . 72 158 9.3.7. PLookup . . . . . . . . . . . . . . . . . . . . . . . 72 159 9.3.8. Resource-ID . . . . . . . . . . . . . . . . . . . . . 73 160 9.3.9. RLookup . . . . . . . . . . . . . . . . . . . . . . . 73 161 9.3.10. Resource-Object . . . . . . . . . . . . . . . . . . . 74 162 9.3.11. Expires . . . . . . . . . . . . . . . . . . . . . . . 75 163 9.3.12. Owner . . . . . . . . . . . . . . . . . . . . . . . . 75 164 9.3.13. Certificate . . . . . . . . . . . . . . . . . . . . . 76 165 9.3.14. Signature . . . . . . . . . . . . . . . . . . . . . . 76 166 9.3.15. Capabilities and Diagnostics . . . . . . . . . . . . . 76 167 9.4. Response Codes and Errors . . . . . . . . . . . . . . . . 78 168 9.4.1. Response Codes . . . . . . . . . . . . . . . . . . . . 78 169 9.4.2. Error Object . . . . . . . . . . . . . . . . . . . . . 79 170 10. Application Layer . . . . . . . . . . . . . . . . . . . . . . 80 171 10.1. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 80 172 10.2. Join . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 173 10.3. Leave . . . . . . . . . . . . . . . . . . . . . . . . . . 80 174 10.4. Publish . . . . . . . . . . . . . . . . . . . . . . . . . 80 175 10.5. Remove . . . . . . . . . . . . . . . . . . . . . . . . . . 80 176 10.6. Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . 81 177 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 82 178 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 83 179 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 180 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 89 181 14.1. Normative References . . . . . . . . . . . . . . . . . . . 89 182 14.2. Informative References . . . . . . . . . . . . . . . . . . 89 183 Appendix A. Background . . . . . . . . . . . . . . . . . . . . . 92 184 Appendix B. Message Flow . . . . . . . . . . . . . . . . . . . . 93 185 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 94 186 Intellectual Property and Copyright Statements . . . . . . . . . . 95 188 1. Introduction 190 This document defines Peer-to-Peer Protocol (P2PP) for creating and 191 maintaining an overlay of participant nodes. The design of P2PP 192 exploits commonalities in the peer-to-peer (p2p) protocols such as 193 Bamboo [22] Chord [12], CAN [13], Pastry [14], Kademlia [15], and Gia 194 [19] thereby defining a protocol that does not contain any peer-to- 195 peer protocol specific details and has an extension mechanism to 196 incorporate a protocol-specific feature. P2PP defines mechanisms for 197 NAT and firewall traversal, uses a secure transport, and has 198 mechanisms for exchanging node capabilities and diagnostic 199 information. P2PP allows non-participant nodes to use overlay 200 services through participant nodes. 202 2. Terminology 204 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 205 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 206 document are to be interpreted as described in RFC 2119 [1]. 208 Some of the terminology has been borrowed from the P2P terminology 209 draft [8]. 211 User: A human user running the P2PP application and is identified by 212 a user-ID. 214 User Identifier (User-ID): A user identifier is an information that 215 represents a user in the overlay. 217 Node: A node is an entity that runs an overlay protocol (peer) or 218 can access the services provided by an overlay network (client). 220 Peer: A peer is a node participating in an overlay that provides 221 storage and routing services to other nodes in the overlay [8]. 223 Client: A client is a node participating in an overlay that provides 224 neither routing nor storage and retrieval functions [8]. 226 Peer Protocol: A structured or unstructured protocol such as Chord, 227 Kademlia, Pastry, Gia. 229 Joining Peer (JP): The peer which intends to join the overlay 230 network. 232 Admitting Peer (AP): An admitting peer is a peer that receives a 233 join request from a joining peer. 235 Identifier (ID): An identifier is information that uniquely 236 identifies a resource-object, a node, or a service. Peer-ID is a 237 form of identifier. We use the term identifier (ID) and key 238 interchangeably. 240 Peer-ID: A Peer-ID is information that uniquely identifies a peer 241 within a given overlay [8]. In DHT-based overlays, this is a hash 242 of a unique node identifier such as an IP address. In 243 unstructured overlays, this is typically an unhashed unique 244 identifier. 246 Routing Table: A routing table (known as finger table in Chord) is 247 used by a peer to locate a peer or a resource-object. Peers in a 248 DHT-based overlay contain a routing table which is a list of 249 overlay peer-IDs and their IP addresses stored against identifiers 250 that are exponentially away from the peer's identifier and thus 251 has a particular structure. The routing-table size is 252 algorithmically bounded. In unstructured networks, peers also 253 maintain a routing table. This specification does not put an 254 upper limit on the number of entries a node can store in its 255 routing table. 257 Note that the distinction between neighbor and routing table is an 258 artifact of structured peer-to-peer networks. 260 Routing Peers: The list of peers stored in a routing table are 261 called routing peers. 263 Neighbor Table: In a DHT-based overlay, a node's neighbor table 264 (known as successor list in Chord and leaf-set in Pastry) contains 265 a list of overlay peer-IDs and their IP addresses which are 266 'immediately' close to the node's identifier according to the DHT 267 metric. The purpose of the neighbor table is to maintain 268 correctness. In an unstructured overlay, nodes typically only 269 maintain a routing table. 271 Neighbor Peers: The list of peers stored in a neighbor table are 272 called neighbor peers. 274 Resource Object: A resource-object is a blob of data stored in the 275 overlay and is identified by a resource-ID. Examples of resource- 276 objects are SIP URIs, routing-records, file-names, and service 277 identifiers such as those identifying STUN or TURN servers. Each 278 resource-object has meta-data associated with it such as content- 279 type, content-usage, owner and expiration-time. The meta-data can 280 also be defined by the user. Resource Object is known as resource 281 record in the concepts document [8]. 283 Service: A node can offer services such as NAT and firewall 284 traversal and may relay traffic for other nodes. A node 285 advertises its service capabilities in the overlay using a 286 resource-object. Different nodes can advertise the same service. 287 The nodes store service advertisements as resource-objects in the 288 overlay. 290 Heterogeneous Network Environments: A heterogeneous network 291 environment comprises of nodes that use different mechanisms for 292 network connectivity such as dialup, DSL, or wireless. 294 Overlay Operator: An entity that uses P2PP to implement an overlay. 296 Enrollment and Authentication Server: An entity which enrolls and 297 authenticates a user. 299 Bootstrap Server: An entity which provides an IP address and port 300 number of an existing node in the overlay to the joining peers. 302 Diagnostic Server: An entity which gathers diagnostic information 303 from peers in the overlay. This information can be used to 304 construct a geographical map of the overlay to visually identify 305 load hotspots in the overlay. 307 3. Design Overview 309 3.1. High-Level Requirements 311 There are five high-level requirements for a peer protocol. 313 Overlay formation The protocol should allow nodes to form an overlay 314 using well-known structured or unstructured peer-to-peer 315 protocols. 317 Overlay maintenance: The protocol should provide mechanisms to 318 maintain connectivity and resource availability in an overlay. 320 Resource publishing and lookup: The protocol should provide a 321 mechanism for a peer to publish a resource-object or advertise its 322 service and a mechanism to lookup the resource-object and the node 323 offering a service. 325 Heterogeneous capabilities and connectivity: The protocol should 326 allow nodes with heterogeneous capabilities and connectivity (such 327 as NATs) to form an overlay. 329 Security The protocol should provide mechanisms to protect against 330 well-known threats against overlays. 332 3.2. Node Model 334 P2PP is an application layer protocol that allows participating nodes 335 to form an overlay using a structured or unstructured peer protocol. 336 The participating nodes typically represent a human user. There is a 337 one-to-many relationship between the human user and the nodes, i.e., 338 a user can participate in the overlay through one or multiple nodes. 339 P2PP defines two types of nodes, namely, peers and clients. A peer 340 is a node participating in an overlay that provides storage and 341 routing services to other nodes in the overlay. A client is a node 342 that does not participate in the overlay and hence does not provide 343 any storage or routing services. Instead, it communicates with one 344 or more peers to make use of the storage and routing services 345 provided by peers. A peer can participate in more than one overlay 346 and a client can also communicate with peers in different overlays. 348 User 349 / | \ 350 / | \ 351 / | \ 352 / | \ 353 +-----+ +-----+ +-------+ 354 |Peer1| |Peer2| |Client1| 355 +-----+ +-----+ +-------+ 357 Figure 1: Relationship between user, peers and clients. 359 P2PP does not define a priori which nodes can act as peers or clients 360 and leaves the decision to overlay operator. The rationale is that 361 P2PP can be used to form an overlay of participating nodes in many 362 different network environments. These include Internet, a 363 corporation, a small office, mobile networks and so on. Nodes which 364 are suitable candidates for becoming a peer in one environment may 365 not necessarily be suitable in other environment. CPU, memory, 366 uptime and network connectivity are some issues which determine 367 whether the node can act as a peer or a client. 369 The classification of a node as a peer or a client is not permanent; 370 a client can join the overlay as a peer or a peer can invite a client 371 to join the overlay. Similarly, a peer can leave the overlay and 372 join as a client. 374 In P2PP, peers and clients are identified by a fixed length 375 identifier and are chosen from the same identifier space. To some 376 extent, the identifier assignment depends on the underlying peer 377 protocol. For structured protocols such as DHTs, a peer and a client 378 identifier is a randomly chosen identifier whose length depends on 379 the underlying hash function. For unstructured protocols, the 380 identifier can be chosen in an appropriate way. Peers and clients 381 can choose their own identifiers or have a central authority choose 382 their identifiers. The human users are identified by an identifier 383 such as SIP AOR or an email address. The user identifiers are chosen 384 in a distributed fashion and may or may not be managed by a central 385 authority. 387 The lack of central management authority for choosing a user 388 identifier implies that two users can potentially select the same 389 user identifier. Likewise, the possibility of collision also arises 390 if peers and clients were to choose their own identifiers. Further, 391 lack of a central authority on user and node identifier assignment 392 opens the system to Sybil attack [23]. To address these issues, P2PP 393 defines an entity called an enrollment and authentication (E&A) 394 server. The E&A server authenticates the users, and ensures that 395 user and node identifiers are unique. A peer can act as an E&A 396 server. 398 Bootstraping is a fundamental issue in the overlay as the peers must 399 somehow discover the address of other peers in the overlay. 400 Similarly, clients also need to discover the address of one or more 401 peers in the overlay. There are different mechanisms for discovering 402 a peer already in the overlay [21]. P2PP describes a bootstrap 403 server based mechanism, and defines an entity, called bootstrap 404 server. The bootstrap server provides the peers and clients with the 405 IP address of participating peers. The bootstrap server may be co- 406 located with the E&A server. A peer can also act as a bootstrap 407 server. 409 For diagnostic purposes, an overlay operator may like to construct a 410 'map' of nodes. This allows the overlay operator to identify 411 problematic hotspots in the overlay and take remedial actions. P2PP, 412 defines an entity called diagnostic server, which crawls the overlay 413 and gathers diagnostic information. 415 Purists can argue that the use of enrollment and authentication 416 server, bootstrap server, and diagnostic server violates the 417 distributed nature of the overlay. We do not disagree with the 418 argument and note that an overlay operator may dispense with these 419 entities provided it is aware of the issues that may arise as a 420 consequence. From our experience, we think that the practical issues 421 involved in running an overlay necessitate their usage. 423 P2PP allows peers to provide services such as NAT traversal. Many 424 peers can provide the same service. Besides storage and routing, 425 P2PP also allows clients to provide services. Besides, peers and 426 clients can store and retrieve data from the overlay. 428 P2PP represents both clients and peers by a peer-info object. 430 3.2.1. P2PP Node Stack 432 The protocol stack of a P2PP node comprises of three conceptual 433 layers, namely, application, overlay, and transport layers. Figure 2 434 shows the three layers. 436 ^ 437 | 438 | 439 Application +------------+ +-----------+ 440 Layer |SIP Proxy/UA| |Application| 441 | +------------+ +-----------+ 442 V | | 443 ================|=================|========= P2PP API 444 | | 445 ^ +---------------------+--------------+ 446 | | routing | routing | 447 Overlay | maintenance | state | 448 Layer | replication +--------------| 449 | | NAT traversal | resource | 450 | | storage | objects | 451 V +---------------------+--------------+ 452 | | | 453 ^ +---------------------------+ 454 | | -state-machine for | 455 | | reliable and unreliable | 456 | | transports | 457 | +---------------------------+ 458 Transport | | | 459 Layer .......................................... 460 | . Transport Layer Security (TLS or DTLS) . 461 | .......................................... 462 | | | 463 | +-----+ +-----+ 464 | | UDP | | TCP | ... other 465 | +-----+ +-----+ protocols 466 | | | 467 | ............................. 468 | . IP Layer Security . 469 | ............................. 470 V | | | 471 =================================|========|========|============= 472 | | | 473 +------------------------------------+ 474 | IP | 475 +------------------------------------+ 477 Figure 2: Protocol stack of a P2PP peer. 479 3.2.1.1. Application Layer 481 The application layer defines an asynchronous application-level API. 482 An application can issue these API to the overlay layer to accomplish 483 functions such as joining or leaving an overlay, and to search for 484 another peer or resource-object in the overlay. 486 3.2.1.2. Overlay Layer 488 The overlay layer is the 'brain' of P2PP protocol stack. It has 489 mechanisms for routing, overlay maintenance, replication, NAT 490 traversal, and storage management. The overlay layer receives API 491 requests from the usage layer and accomplishes the requested 492 function. The routing mechanism routes the requests in a recursive, 493 iterative, or parallel manner. The overlay maintenance mechanism 494 strives to preserve routing correctness and connectivity in the 495 presence of churn. The replication mechanism maintains availability 496 of resource-objects in the system. The NAT traversal mechanism uses 497 ICE (TODO: and variants?) to traverse NATs. The client does not have 498 routing, storage, or replication mechanisms. (TODO: split the 499 layer?) 501 3.2.1.3. Transport Layer 503 P2PP allows sending messages over an unreliable or a reliable 504 transport. It, however, prefers the use of reliable transport such 505 as TCP or TLS. For unreliable transports such as UDP and DTLS, it 506 provides an ACK-based hop-by-hop reliability mechanism. For reliable 507 transports, reliability is provided by the underlying transport 508 protocol. 510 3.2.1.3.1. Listening Ports 512 The specification proposes a standard UDP and TCP listening port to 513 be assigned by IANA. The current implementation uses port 7080 as a 514 listening port for UDP and TCP, and 7081 for DLTS and TLS. 516 3.3. Data Model 518 The peers in P2PP provide storage services. This allows other peers 519 and clients to store data on a peer or a set of peers. In P2PP, the 520 data to be stored is defined as a resource-object. A resource-object 521 has a resource-ID which acts as the object locator. For structured 522 overlays such as DHTs, resource-ID is a fixed length identifier. For 523 unstructured overlays, resource-ID can have a variable length. A 524 resource-object has a type and sub-type which identify the 525 information being stored. The type and sub-type define a name-space, 526 i.e., resource-objects having same resource-ID but a different type 527 and sub-type belong to a different namespace. An example of a type 528 is a user or a service identifier. Each resource-object has a 529 'value' whose description depends on the type and sub-type. The 530 relationship between resource-ID, type, sub-type, and value is shown 531 in Figure 3. 533 Each resource-object has certain properties, namely, the owner of the 534 object, the node storing the object and the cryptographic signature 535 of the object. P2PP allows peers to store data having the same 536 resource-ID, type and sub-type but different owners. Similarly, P2PP 537 allows nodes to search for resource-objects published by different 538 owners. 540 Examples of data-types include buddy lists, user-record, and services 541 such as NAT and firewall traversal. 543 +-----------------------------------------------------------+ 544 | +-------------------------------------------------------+ | 545 | | Resource-ID | | 546 | +-------------------------------------------------------+ | 547 | +-------------------------+ +-------------------------+ | 548 | | Type1 | | Type2 | | 549 | | +---------+ +---------+ | | +---------+ +---------+ | | 550 | | |Sub-type1| |Sub-type2| | | |Sub-type1| |Sub-type2| | | 551 | | +---------+ +---------+ | | +---------+ +---------+ | | 552 | | +------+ +------+ | | +------+ +------+ | | 553 | | |Value1| |Value1| | | |Value1| |Value1| | | 554 | | +------+ +------+ | | +------+ +------+ | | 555 | | | | | | 556 | | +------+ +------+ | | +------+ +------+ | | 557 | | |Value2| |Value2| | | |Value2| |Value2| | | 558 | | +------+ +------+ | | +------+ +------+ | | 559 | | | | | | 560 | +-------------------------+ +-------------------------+ | 561 | | 562 +-----------------------------------------------------------+ 564 Figure 3: Resource-object. 566 3.4. Message Model 568 P2PP messages begin with a header followed by a sequence of type- 569 length-value (TLV) objects. P2PP defines five types of message. 570 However, the three key messages are requests, responses, and 571 indications. The requests always generate a response, where as 572 indications do not require any. Indications are useful in scenarios 573 such as informing other peers about a routing table change. The 574 response have a response code which is inspired from HTTP and SIP 575 response codes. 577 P2PP allows nodes to forward requests in a recursive or an iterative 578 manner. In recursive routing, a request is forwarded from one peer 579 to the other until it reaches its destination. The response is then 580 sent along the same path on which the request was received. In 581 iterative routing, if a peer determines that it is not the 582 destination of the message, it sends in its response the IP address 583 of the next hop. The request originator then sends the request to 584 the next hop. Peers never forward the indications. Figure 4 and 5 585 show a conceptual diagram of request routing in a recursive and 586 iterative manner, respectively. 588 Peer1 Peer2 Peer3 589 | Request | | 590 |-------------->| Request | 591 | |------------->| 592 | | Response | 593 | |<-------------| 594 | Response | | 595 |<--------------| | 597 Figure 4: A conceptual diagram showing request routing in a recursive 598 manner. 600 Peer1 Peer2 Peer3 601 | Request | | 602 |-------------->| | 603 | Response | | 604 |<--------------| | 605 | Request | 606 |-----------------------------<| 607 | Response | 608 |<-----------------------------| 609 | | 611 Figure 5: A conceptual diagram showing request routing in an 612 iterative manner. 614 3.5. Reliability Model 616 P2PP defines a hop-by-hop reliability model, i.e., the request, 617 response, and indications originators are only responsible for 618 ensuring that the message reaches the next hop. P2PP allows nodes to 619 send messages over a reliable and unreliable transport. For 620 unreliable transports, P2PP provides an acknowledgement (ACK) based 621 mechanism to ensure reliability of message delivery. The 622 acknowledgement is the fourth type of P2PP message. 624 P2PP does not support message fragmentation and instead makes use of 625 the underlying reliable transport such as TCP or TLS larger than MTU 626 messages. 628 For recursive routing, the hop-by-hop reliability model allows the 629 routing path to be a mix of reliable and unreliable transports. 630 Figure 4 and 5 showed the message forwarding in a recursive manner 631 and iterative manner over reliable transport. Figure 6(a) and 7(a) 632 show the unoptimized message forwarding in a recursive and iterative 633 manner over unreliable transport. In recursive routing, the peer 634 responsible for generating a response sends an ACK and then 635 immediately sends a response. In iterative routing, every node must 636 acknowledge the request and immediately send the response. To avoid 637 the transmission of an ACK followed by a response, P2PP, defines a 638 fifth type of message, namely, responseACK which combines the 639 response and acknowledgement in one message. 641 Peer1 Peer2 Peer3 Peer1 Peer2 Peer3 642 | Request | | | Request | | 643 |-------------->| | |-------------->| | 644 | ACK | | | ACK | | 645 |<--------------| Request | |<--------------| Request | 646 | |------------->| | |------------->| 647 | | ACK | | | ResponseACK | 648 | |<-------------| | |<-------------| 649 | | Response | | | ACK | 650 | |<-------------| | |------------->| 651 | | ACK | | Response | | 652 | |------------->| |<--------------| | 653 | Response | | | ACK | | 654 |<--------------| | |-------------->| | 655 | ACK | | | | | 656 |-------------->| | 657 (a) (b) 659 Figure 6: Request routing in a recursive manner over unreliable 660 transport. (a) unoptimized forwarding (b) optimized forwarding. 662 Peer1 Peer2 Peer3 Peer1 Peer2 Peer3 663 | Request | | | Request | | 664 |-------------->| | |-------------->| | 665 | ACK | | | ResponseACK | | 666 |<--------------| | |<--------------| | 667 | Response | | | ACK | | 668 |<--------------| | |-------------->| | 669 | ACK | | | | 670 |-------------->| | | Request | 671 | | |----------------------------->| 672 | Request | | ResponseACK | 673 |----------------------------->| |<-----------------------------| 674 | ACK | | ACK | 675 |<-----------------------------| |----------------------------->| 676 | Response | | | 677 |<-----------------------------| 678 | ACK | 679 |----------------------------->| 681 (a) (b) 683 Figure 7: Request routing in an iterative manner over unreliable 684 transport. (a) unoptimized forwarding (b) optimized forwarding. 686 Thus, P2PP defines five types of message, namely, request, response, 687 responseACK, indication, and acknowledgement. A response or 688 responseACK must match to the request. Similarly, an ACK must match 689 to the request, response, or responseACK that it acknowledges. The 690 transmission of a request, response, responseACK, and an indication 691 is governed by a transaction state-machine described in Section 6.2. 693 3.6. Security Model 695 P2PP provides a hop-by-hop security model. The nodes in P2PP 696 establish an unreliable or reliable secure channel with other nodes 697 using DTLS or TLS. However, peers establish a secure SIP session in 698 an end-to-end manner. 700 P2PP uses an enrollment and authentication (E&A) server to enroll new 701 users in the overlay and to authenticate existing users. Once 702 authenticated, it issues a certificate that binds the user-identifier 703 and public key of the user. Further, it also generates a peer or a 704 client identifier and adds it to the certificate. 706 P2PP also allows nodes to operate without a central enrollment and 707 authentication server. In such a scenario, nodes use self-signed 708 certificates and generate their own identifiers. 710 3.6.1. Threat Model 712 This section lists the security threats and discusses mechanisms P2PP 713 provides to protect against some of these threats. The threats 714 against overlays can be loosely classified into routing, storage, and 715 replay threats. Below we list some of the possible attacks within 716 each threat. P2PP provides protection against some of these attacks. 718 Routing Threats 720 1. Obtain a significant portion of user or peer identifiers to 721 launch a Sybil attack. 723 2. Sniff on the messages between peers. 725 3. Corrupt a message flow between peers, thereby violating message 726 integrity. 728 4. Infer user or flow identity from the legitimately received 729 messages. 731 5. Incorrectly route or drop a message. 733 6. Poison routing or neighbor tables. 735 7. Launch a DoS or DDoS against a peer or set of peers. 737 Storage Threats 739 1. Corrupt a stored object, thereby violating storage integrity. 741 2. Unauthorized storage or lookup. 743 3. Launch a storage DoS attack against a peer or set of peers. 745 4. Does not invalidate storage cache, thereby returning old copies 746 of the stored object. 748 Replay Threats 750 1. Replay a message. 752 Currently, P2PP provides protection against (1)-(3) of routing 753 threats, (1)-(3) of storage threats, and (1) of replay threats. The 754 next section discusses mechanism provided by P2PP for protection 755 against these threats. 757 3.7. NAT and Firewall Traversal 759 P2PP allows any node to act as a NAT traversal server. The node 760 providing the NAT traversal service allows the node behind a NAT to 761 discover their NAT types and to determine their reachable address 762 using STUN [5] or TURN [6]. Many nodes can provide the NAT traversal 763 service and a key issue is how this information is published in the 764 overlay and how to discover an appropriate NAT traversal server. 765 P2PP provides RTT and autonomous-system (AS) number based mechanisms 766 for a node to discover a close-by NAT traversal server. In a large 767 corporation, peers may also use an IP-prefix based mechanism to 768 discover a close by NAT traversal server. P2PP leaves the selection 769 of this mechanism to overlay operator. P2PP also allows an 770 overloaded node providing NAT traversal service to redirect NAT 771 traversal requests to unloaded nodes. 773 In a peer-to-peer network, there is no guarantee on the availability 774 of a node. A node whose reachability depends on a peer providing NAT 775 traversal service may discover that the peer is no longer online. 776 Consequently, the reachable IP address of a node obtained through a 777 peer providing a NAT traversal service that is no longer online 778 becomes invalid. Therefore, a node may need to discover another peer 779 providing NAT traversal service, determine its new reachable address, 780 readvertise this information in the overlay, and establish new 781 connections with routing and neighbor peers. Depending on the churn 782 rate, this can incur a significant communication overhead. 784 The requests can be routed in a recursive or an iterative manner. 785 The choice of routing mechanism has an impact on the performance of 786 NAT traversal mechanism. We discuss these issues in Section 4.3.2 787 and suggest that the non significant overhead of ICE [7] as-is does 788 not lead to its automatic selection as a NAT traversal mechanism. 790 TODO: Besides NATs, the firewalls can hinder connectivity and result 791 in non-transitivity of connection. 793 3.8. Mobility 795 We classify P2PSIP mobility into three subcategories: peer mobility, 796 client mobility, and session mobility. The following sections 797 discuss different aspects of P2PSIP mobility in details. 799 3.8.1. Peer Mobility 801 Mobile devices such as mobile and WiFi phones or laptops may move 802 from one network to another by doing handover between different 803 access networks or moving from one WLAN access point to another. 804 Whenever a peer changes its access network (e.g., from WCDMA to 805 WLAN), its IP address also changes. In P2PSIP networks where P2PSIP 806 peer software runs also in mobile terminals, peer-IDs must not be 807 assigned based on IP addresses. If a peer-ID was constructed using 808 an IP address of a peer, any change in the IP address would cause the 809 change of the peer-ID, introducing instability in the DHT network. 810 Further, a peer needs to inform its routing and neighbor peers about 811 any change in the IP address. 813 Any change in the peer-ID computed using IP address require a peer to 814 leave the P2PSIP overlay network and join the overlay network once 815 again with the new peer-ID. Besides updates to the DHT do not take 816 place immediately after a node has gone. It may take some time until 817 all the data is again in the proper place, including the re-creation 818 of routing tables. This may cause network instability and require 819 additional resources to handle network adaptation especially in a 820 battery powered mobile devices. Besides in the transition period 821 search delay for user contact information may be higher, delaying the 822 call establishment. 824 Rather than constructing peer-IDs by hashing the IP address or a 825 random peer-ID, which is no longer static for the duration of the 826 connection to the DHT, P2PP allows P2PSIP networks to assign a static 827 and unique (within a DHT ring) peer-IDs. The enrollment and peer-ID 828 assignment is presented in Section 4.5. In addition, P2PP allows 829 peers to advertise changes of their IP addresses to other peers. 830 When a peer moves to another subnet after a handover, it receives a 831 new IP address. Since the peer-ID does not change, it does not 832 introduce instability into the DHT. However, the peer has to inform 833 its neighbors about its new IP address. To each neighbor, the peer 834 presents the new IP address, and authentication data (a certificate) 835 that also includes the existing peer-ID. The neighbor authenticates 836 the update request and stores the new IP address bound to that 837 peer-ID. 839 3.8.2. Client Mobility 841 Mobile clients may change IP address in the same way as mobile peers 842 do. The main difference between the client mobility and the peer 843 mobility is that the client mobility does not influence the structure 844 of the overlay. However, the client mobility may have impact on the 845 reachability of the client itself. In case of a handover, a mobile 846 client must update user records in DHT in real time if it still wants 847 to be reachable. In order to fulfill this requirement, the client 848 must contact the peer that stores the user record. When the client 849 changes its IP address, it must update the user record by sending 850 publish request directly to the peer storing the record. If the peer 851 is not reachable, the client must send the publish request to any of 852 the available peers using either recursive or iterative routing. 854 3.8.3. Session Mobility 856 Session mobility is related to the mobility of SIP user agent during 857 a SIP session. This may happen when one or more endpoints that are 858 participating in the same SIP session change their IP addresses 859 because of a handover. In order to preserve the service continuity, 860 clients need to support a method that will minimize session 861 interruption due to handovers. This memo does not provide any 862 solution for SIP session mobility. Instead, it is expected that a 863 generic SIP solution for session mobility will be re-utilized in 864 P2PSIP once such solution is developed. 866 3.9. Overview of Operations 868 The following table gives a brief description of P2PP messages and 869 their message type. It also indicates which messages may be sent by 870 a peer or a client. The messages have been grouped together by 871 relevant functions. 873 3.9.1. Enrollment, Authentication, and Bootstrap 875 +--------------+---------+--------+---------------------------------+ 876 | Operation | Message | Peer | Description | 877 | | Type | or | | 878 | | | Client | | 879 +--------------+---------+--------+---------------------------------+ 880 | Enroll | R | P|C | Enrolls the user in the | 881 | | | | overlay. | 882 | | | | | 883 | Authenticate | R | P|C | Authenticate the user and | 884 | | | | generates a certificate binding | 885 | | | | user-ID, peer or client ID, and | 886 | | | | public key of the peer. | 887 | | | | | 888 | Bootstrap | R | P|C | Clients and peers send this | 889 | | | | request to a bootstrap server | 890 | | | | or a peer to discover the IP | 891 | | | | address of a peer in the | 892 | | | | overlay. | 893 +--------------+---------+--------+---------------------------------+ 895 3.9.2. Overlay Maintenance 897 +---------------+---------+--------+--------------------------------+ 898 | Operation | Message | Peer | Description | 899 | | Type | or | | 900 | | | Client | | 901 +---------------+---------+--------+--------------------------------+ 902 | Join | R | P|C | Peers send this request to | 903 | | | | join the overlay. Depending | 904 | | | | on the peer protocol being | 905 | | | | used, the join request is | 906 | | | | forwarded to the peer where | 907 | | | | this peer will join. Client | 908 | | | | sends a join request to a peer | 909 | | | | discovered using bootstrap | 910 | | | | mechanism and becomes attached | 911 | | | | to the peer. | 912 | | | | | 913 | Leave | I | P|C | Peers send the leave | 914 | | | | indication to their routing | 915 | | | | and peers indicating their | 916 | | | | departure. Clients | 917 | | | | periodically send the leave | 918 | | | | message to their respective | 919 | | | | peers. | 920 | | | | | 921 | KeepAlive | I | P|C | Peers periodically send a | 922 | | | | keepalive indication to their | 923 | | | | routing and neighbor peers to | 924 | | | | check whether they are alive. | 925 | | | | Clients send a keepalive to | 926 | | | | their peers to check whether | 927 | | | | they are alive. | 928 | | | | | 929 | LookupPeer | R | P | Peers send this request to | 930 | | | | discover a peer that may fill | 931 | | | | or update a missing entry in | 932 | | | | their routing or neighbor | 933 | | | | table. | 934 | | | | | 935 | ExchangeTable | R | P | Peers periodically send this | 936 | | | | request to their routing and | 937 | | | | neighbor peers obtain their | 938 | | | | routing and neighbor tables. | 939 | | | | | 940 | Replicate | R | P | Peers periodically send this | 941 | | | | request to replicate the | 942 | | | | resource-objects for | 943 | | | | availability. The choice of | 944 | | | | peers on which to replicate | 945 | | | | the objects depends on the | 946 | | | | peer protocol. | 947 | | | | | 948 | Transfer | R | P | After a successful join or | 949 | | | | graceful or ungraceful failure | 950 | | | | of peers, a peer transfers the | 951 | | | | ownership of resource-objects | 952 | | | | using a transfer request. | 953 +---------------+---------+--------+--------------------------------+ 955 3.9.3. Data Storage and Retrieval 957 +---------------+---------+--------+--------------------------------+ 958 | Operation | Message | Peer | Description | 959 | | Type | or | | 960 | | | Client | | 961 +---------------+---------+--------+--------------------------------+ 962 | PublishObject | R | P|C | Publish a resource-object. | 963 | | | | Also, used to refresh or | 964 | | | | update an existing | 965 | | | | resource-object. | 966 | | | | | 967 | LookupObject | R | P|C | Search for a resource-object. | 968 | | | | | 969 | RemoveObject | R | P|C | Remove the resource-object. | 970 +---------------+---------+--------+--------------------------------+ 972 3.9.4. Connection Management and Other 974 +-----------+---------+--------+------------------------------------+ 975 | Operation | Message | Peer | Description | 976 | | Type | or | | 977 | | | Client | | 978 +-----------+---------+--------+------------------------------------+ 979 | Tunnel | R | P|C | Tunnel an application layer | 980 | | | | protocol message into a P2PP | 981 | | | | message. Mostly used for sending | 982 | | | | SIP messages to peers or clients | 983 | | | | behind a NAT. | 984 | | | | | 985 | Connect | R | P|C | Send an ICE offer (TBD). | 986 | | | | | 987 | Invite | R | P | Peers send an invite request to a | 988 | | | | client, inviting them to become a | 989 | | | | peer. | 990 | | | | | 991 | Query | R | P|C | Query a peer or a client to | 992 | | | | discover the services they provide | 993 | | | | or the resource-objects they | 994 | | | | store. | 995 +-----------+---------+--------+------------------------------------+ 997 3.10. Overlay Migration 999 This mechanism allows nodes to migrate from one overlay protocol to 1000 the other and to download a software update for the overlay protocol. 1001 (TBD.) 1003 4. Overlay Layer 1005 4.1. Peer State 1007 A peer maintains the following state: 1009 Peer-to-Peer Algorithm: Peer-to-peer algorithm of the overlay. 1011 Overlay-ID: ID of the overlay this peer is part of. 1013 Hash Algorithm: The hash algorithm, if any, being used. 1015 Base: The logarithm base for a DHT, if a DHT is used as a peer 1016 protocol. 1018 Routing Table: A table of other peers in the overlay. For each 1019 peer, the following information is maintained. 1021 Peer-ID: The ID of the peer. For a structured p2p algorithm, it 1022 is typically the hash of the IP address of the peer. Otherwise, 1023 it can be an IP address or some unique ID. 1025 IP address and port: The IP address and port of the peer. 1027 RTT: The round-trip-time of this peer. If TCP is used, an 1028 application may obtain this value from the TCP stack if the 1029 underlying OS supports it. 1031 Uptime: The uptime of the peer. 1033 Neighbor Table: A table of peers with ID adjacent to the peer's ID 1034 in a structured overlay. For each peer, the following information 1035 is maintained. 1037 Peer-ID: The ID of the peer. For a structured p2p algorithm, it 1038 is typically the hash of the IP address of the peer. Otherwise, 1039 it can be an IP address. 1041 IP address and port: The IP address and port of the peer. 1043 RTT: The round-trip-time of this peer. 1045 Uptime: The uptime of the peer (overlay software). 1047 Number of Neighbors: Total number of peers in routing and neighbor 1048 tables. 1050 Publish Table: The resource-objects this peer has published in the 1051 overlay. It must periodically refresh the resource-objects before 1052 the passage of their refresh time interval. 1054 Resource Table: Resource-objects this peer is responsible for. 1056 Replicated Resource Table: Resource-objects this peer stores as 1057 backup for other objects. 1059 Transaction Table: A transaction table which keeps track of in- 1060 progress transactions. The transaction can be a request, 1061 response, or an indication transaction. 1063 Uptime: The uptime of this peer. 1065 Number of Clients: Number of clients connected to this peer. 1067 Media Relay Flows: The number and bandwidth of media flows being 1068 relayed through this peer. 1070 Additionally, it may keep track of the following diagnostic 1071 information: 1073 Bandwidth: The current bandwidth being used. 1075 Number of Messages: The number and cumulative size of messages 1076 received within the last x seconds. 1078 Autonomous System Number: The AS number of the peer. It can be used 1079 to advertise STUN or TURN services. 1081 4.2. Key Components of a P2PP Message 1083 This section describes the key TLV objects defined by P2PP. 1085 Common Header: The common header is a fixed length header which is 1086 part of every message (Section 9.1. It contains the message type, 1087 request or indication type, TTL, a magic cookie to differentiate P2PP 1088 from other protocols, transaction-ID, source-ID and a response-ID. 1089 The message type defines the type of the message, namely, request, 1090 response, responseACK, or indication where as the request or 1091 indication type defines the type of request or indication being sent. 1092 The transaction-ID is a unique number chosen by the request or 1093 indication originator. The source-ID represents the peer-ID of the 1094 message originator peer. Response-ID is only included in the ACK, 1095 response, or a responseACK, and represents the peer-ID of the peer 1096 generating the response, responseACK, or ACK. Since peer-IDs must be 1097 unique and peers must choose a locally unique transaction-ID, the 1098 combination of source-ID and transaction-ID can uniquely identify a 1099 message. 1101 Peer-Info: Peer-Info TLV represents a peer in the overlay. A peer 1102 has a fixed length identifier and a set of reachable IP address and 1103 port numbers gathered using ICE. Further, a peer maintains its 1104 uptime information, number of connected clients, routing and neighbor 1105 peers, a certificate, and bandwidth. This information is encoded as 1106 follows: 1108 Peer-Info = Peer-ID 1109 [Address-Info] 1110 [Uptime] 1111 [Certificate] 1112 [Connections] 1113 [Node-Resource-Utilization] 1114 [ext] 1116 Similar to peers, clients also have an identifier derived from the 1117 same identifier space as peers. There is almost no difference 1118 between the peer-info TLV representing a peer and peer-info TLV 1119 representing a client, except that other peers must not update their 1120 routing and neighbor tables with the client. Peers can also invite 1121 clients to become peers in the overlay and therefore, it made sense 1122 that clients already have an identifier when they receive such an 1123 invitation as they can then immediately join the overlay, without 1124 going through an E&A server and obtaining a certified peer-ID. 1126 This specification represents both peers and clients with a peer-info 1127 object. When forwarding messages, the message originated by a peer 1128 or a client is differentiated based on a 'peer or client' flag in the 1129 common header. 1131 An approximate size of a peer-info object for a 20 byte peer-ID, and 1132 an address info object containing host, server-reflexive, and relay 1133 candidates is (4+4+20+4+46)=78 bytes. 1135 Resource-Object: Resource-object represents the information that 1136 peers store in the overlay. As discussed in Section 3.2, a resource- 1137 object has a resource-ID, type, sub-type, and a value. Further, a 1138 resource-object has additional properties, namely, owner, peer who 1139 inserted or updated the object, and a signature. Resource-ID is a 1140 fixed length identifier for DHTs and could be a variable length 1141 identifier for unstructured overlays. The size of the resource- 1142 object is limited to 65,536 bytes. A resource-object is encoded as 1143 follows: 1145 Resource-Object = Resource-ID 1146 [Peer-Info] 1147 [Owner] 1148 [Signature] 1149 Value 1150 [ext] 1152 4.3. Request, Response, and Indications Processing 1154 To send a request, response, responseACK, or an indication, a peer 1155 creates a transaction and passes it the message. The peer identifies 1156 a transaction using a source-ID and transaction-ID tuple as described 1157 in Section 6.1. For response and responseACK, an additional 1158 consideration is that it must contain the same source-ID and 1159 transaction-ID as the request for which the response is being 1160 generated. Similar considerations hold for ACK which acknowledges 1161 requests, responses, or indications over unreliable transport. 1162 Following considerations apply when sending a message. 1164 1. A node may set request-routing-table or request-neighbor-table 1165 flags requesting to receive the peer-info objects containing 1166 peer-ID and address-info objects. If the message was sent over 1167 unreliable transport, the node issuing the request SHOULD always 1168 set the in-separate-request flag in the Request-Options object. 1169 For a routing table that contains 100 nodes, which can be typical 1170 for a million user overlay, and an average peer-info object size 1171 of 78 bytes, the routing or neighbor table is not likely to fit 1172 within response UDP packet. 1174 A message can be received over UDP or TCP. A message received over 1175 unreliable is processed according to the following steps: 1177 1. The peer checks whether a transaction already exists in the 1178 transaction table. As described in Section 4.1, a peer keeps 1179 track of in-progress transactions in a transaction table. If a 1180 transaction exists, the peer sends an ACK response and terminates 1181 the message processing. The received requests are matched 1182 against the response transaction having the same source-ID and 1183 transaction-ID where as the received responses are matched 1184 against request and response transactions. 1186 2. If the transaction does not exist in the transaction table, the 1187 peer checks the TTL field in the common header. If TTL is equal 1188 to zero, and the message was a request, it MUST reply with a 410 1189 (TTL Hops Exceeded) response and include its Peer-ID in the 1190 Response-ID field in the common header. Additionally, it MUST 1191 send an ACK to the received request. If a peer receives a 1192 response, indication or an ACK with a TTL equal to zero, it 1193 ignores the message. Instead of sending a separate ACK and a 1194 response message, it sends a responseACK message. It creates a 1195 responseACK transaction as shown in Figure 3 and passes it the 1196 responseACK message. The transaction has the same source-ID as 1197 the one received in the request. The response-ID is set to the 1198 ID of the peer generating response or responseACK. The response 1199 is always sent to the peer from whom the request was received and 1200 not to the peer who issued the request. 1202 3. If TTL is greater than zero, recursive routing was being used (R 1203 flag is set in the common header), and the peer cannot generate a 1204 response for the received request, it determines the next hop 1205 from its routing or neighbor tables, creates a request 1206 transaction, and passes it the request after decrementing TTL by 1207 one in the common header. The transaction has the same 1208 identifier (source-ID, transaction-ID) as the one received in the 1209 request. The rest of the forwarded request remains unchanged. 1210 Also, it sends an ACK message to the peer from whom it received 1211 the request and sets its own peer-ID in the response-ID of the 1212 ACK message. If a response is received for which a corresponding 1213 request transaction exists, the peer immediately terminates the 1214 request transaction, creates a response transaction and passes it 1215 the received response for delivery to the upstream peer. 1217 4. If TTL is greater than zero, iterative routing was being used, 1218 and the peer cannot satisfy the request, it determines the next 1219 hop from its routing or neighbor tables. It then creates a 1220 responseACK transaction and passes it a 302 (Next Hop) response. 1221 The peer includes its Peer-Info and the next hop Peer-Info object 1222 in the responseACK message. 1224 5. If a peer can generate a response for a received request, it must 1225 create a responseACK transaction. If a peer receiving the 1226 request determines that it can generate a response, which will 1227 fit within UDP MTU, it checks if the Request-Options object was 1228 present and that request-routing-table or request-neighbor-table 1229 and in-separate-request flags were set. If set, the peer waits 1230 for a random time between RA and RB seconds, and sends a copy of 1231 its routing or neighbor table or both in an ExchangeTable request 1232 to the peer which issued the request (not the peer which 1233 forwarded the request). If in-separate-request was not set, the 1234 peer includes in the response as much of the requested routing or 1235 neighbor table entries as permitted by the UDP MTU. 1237 6. If the peer receiving the request determines that it can generate 1238 a response but the response will not fit within UDP MTU, it can 1239 reply with a 413 (Message Too Large) or a 480 (Alternative 1240 Service) response to indicate to the node issuing the request to 1241 retry the request over TCP. A 413 response is not sent if the 1242 response can fit within UDP MTU but requested routing or neighbor 1243 table cannot fit within MTU. 1245 7. A peer should always send an ACK to any retransmissions of the 1246 request, response, or indication. 1248 8. The peer checks if it can update its routing and neighbor tables 1249 from the received request or response. 1251 9. If a peer receives a response, it immediately replies with an ACK 1252 message. It then searches for the corresponding request 1253 transaction in its transaction table. If a request transaction 1254 is found, and if the peer receiving the response was the request 1255 originator it passes the response to the overlay layer. 1256 Otherwise, it creates a response transaction and passes it the 1257 received response. The response is sent to the same IP address 1258 and port number from which the request was received. If a 1259 request transaction is not found and the peer receiving the 1260 response was not the request originator, the response is 1261 discarded. However, an ACK is still generated for the discarded 1262 response. The transmission of ACK is an indication that the peer 1263 receiving the response is still alive. 1265 A peer sending an indication sets the TTL field to one. A peer 1266 receiving an indication over unreliable transport immediately 1267 generates an ACK. An indication is never forwarded so R flag is 1268 never set for an indication. 1270 To send a message over a reliable transport, a peer creates an 1271 appropriate transaction as shown in Figure 4 and 5 and passes it the 1272 message. 1274 A request or response received over a reliable transport is processed 1275 according to the following steps. 1277 1. The peer checks whether a transaction already exists in the 1278 transaction table. This transaction can either be a request, 1279 response transaction. 1281 2. If the transaction does not exist in the transaction table, the 1282 peer checks the TTL field in the common header. If TTL is equal 1283 to zero, it MUST reply with a 410 (TTL Hops Exceeded) response 1284 and include its Peer-ID in the Response-ID field in the common 1285 header. It creates a response transaction as shown in Figure 5 1286 and passes it the response . The transaction has the same 1287 identifier as the one received in the request. The response is 1288 always sent to the peer from whom the request was received and 1289 not to the peer who issued the request. 1291 3. If TTL is greater than zero, recursive routing was being used (R 1292 flag is set in the common header), and the peer cannot generate a 1293 response for the received request, it determines the next hop 1294 from its routing or neighbor tables, creates a request 1295 transaction, and passes it the request after decrementing TTL by 1296 one in the common header. The transaction has the same 1297 identifier (source-ID, transaction-ID) as the one received in the 1298 request. The rest of the forwarded request remains unchanged. 1300 4. If TTL is greater than zero, iterative routing was being used, 1301 and the peer cannot satisfy the request, it determines the next 1302 hop from its routing or neighbor tables. It then creates a 1303 response transaction and passes it a 302 (Next Hop) response. 1304 The peer includes its Peer-Info and the next hop Peer-Info object 1305 in the response. 1307 5. If a peer receiving the request determines that it can generate a 1308 response, it checks if the Request-Options object was present and 1309 whether request-routing-table or request-neighbor-table and in- 1310 separate-request flags were set. If set, the peer waits for a 1311 random time between RA and RB seconds, and sends a copy of its 1312 routing or neighbor table or both in an ExchangeTable request to 1313 the peer which issued the request. If in-separate-request was 1314 not set, the peer includes in the response up to 256 routing and 1315 neighbor table entries each. 1317 6. The peer checks if it can update its routing and neighbor tables 1318 from the received request or response. 1320 7. The peer receiving the response searches for the corresponding 1321 request transaction in its transaction table. If a request 1322 transaction is found, and if the peer receiving the response was 1323 the request originator it passes the response to the overlay 1324 layer. Otherwise, it terminates the request transaction, creates 1325 a response transaction and passes it the received response. The 1326 response is sent to the same IP address and port number from 1327 which the request was received. If a request transaction is not 1328 found and the peer receiving the response was not the request 1329 originator, the response is discarded. 1331 4.3.1. ACK generation 1333 A node MUST send an ACK for every request, response, responseACK, or 1334 indication received over unreliable transport. The following diagram 1335 depicts the message for requests forwarded in a recursive manner over 1336 unreliable transport. 1338 A B C 1339 (idA) (idB) (idB) 1340 | req(sid=idA,rid=) | | 1341 |----------------------->| | 1342 | ACK(sid=idA,rid=idB) | | 1343 |<-----------------------| req(sid=idA,rid=) | 1344 | |------------------------>| 1345 | | respACK(sid=idA,rid=idC)| 1346 | |<------------------------| 1347 | | ACK(sid=idA,rid=idC) | 1348 | |------------------------>| 1349 |respACK(sid=idA,rid=idC)| | 1350 |<-----------------------| | 1351 | ACK(sid=idA,rid=idC) | | 1352 |----------------------->| | 1354 Figure 6: Message flow for requests forwarded in a recursive manner 1355 over unreliable transport. 1357 The encoding of response-ID field in the ACK is according to the 1358 following rule: If no response-ID was received in the message, then 1359 the node generating an ACK MUST include its own peer-ID as the 1360 response-ID. If the source-ID and response-ID field were already 1361 present in the message, then the ACK message should copy back 1362 source-ID and response-ID fields. 1364 4.3.2. Recursive and Iterative Routing 1366 P2PP does not require all peers must use either recursive or 1367 iterative routing. Based on their connectivity information, peers 1368 may choose to send requests in a recursive or iterative manner. The 1369 request routing mechanism is determined by a recursive or iterative 1370 flag in the common header. Only requests can be sent in a recursive 1371 or iterative manner. Below, we discuss the issues involved in the 1372 use of recursive and iterative routing that highlight the need to 1373 support both mechanisms. Further, we also discuss the issues that 1374 are peculiar to the recursive or iterative forwarding of requests. 1376 4.3.2.1. Loop Detection 1378 Iterative routing does not require the design of complicated 1379 mechanisms, such as route-log, for detecting forwarding loops nor is 1380 there a need to design mechanisms for message forking and fork 1381 explosion. 1383 4.3.2.2. Rogue Peer 1385 If the message is forwarded in a recursive manner, a rogue peer along 1386 the request path may simply drop the message. It will be a while 1387 before the request originator realizes such a behavior. In iterative 1388 routing, a peer has control of the messages and it could quickly 1389 determine if its messages are being dropped. 1391 4.3.2.3. Secure Channel Establishment 1393 In recursive routing, a peer sends a message to its routing or 1394 neighbor peers. It is likely that a node sending the message has a 1395 secure reliable or unreliable channel with its routing or neighbor 1396 peers. In iterative routing, a node may need to communicate with 1397 previously uncontacted peers. It is quite possible that the peers 1398 contacted during iterative routing may never be contacted again. 1399 When requests are routed in an iterative manner, and if a peer 1400 somehow has certificate of the communicating peer, it may use DTLS or 1401 TLS. 1403 In DTLS the secure channel establishment at least requires two RTT of 1404 setup time. In addition, for TLS, a TCP connection must be 1405 established. This requires 1.5 RTT of setup time. The nodes can 1406 securely communicate after the establishment of secure and/or 1407 reliable channel. 1409 If a node uses DTLS or TLS to establish a secure channel with other 1410 nodes while forwarding requests in an iterative manner, it could 1411 incur a per hop setup overhead of 2 and 3.5 RTT for DTLS and TLS, 1412 respectively. Recursive routing does not have this setup overhead 1413 because nodes typically only communicate with peers in their routing 1414 and neighbor tables with which they have a long lived secure 1415 connection. This makes the choice of iterative routing less 1416 attractive than recursive routing. 1418 As discussed in Section 4.3.2 iterative routing has three nice 1419 properties. First, unlike recursive routing, the request originator 1420 has control over which nodes it should contact. Second, the number 1421 of message hops is always one which prevents complicated routing bugs 1422 and schemes for loop detection. Finally, it prevents fork explosion 1423 when parallel copies of the request are issued in a recursive manner. 1425 Thus, we believe, there is a need to incorporate iterative routing 1426 mechanism as part of P2PP and ensure that the use of underlying 1427 transport protocol such as DTLS does not impact the performance of 1428 iterative routing vis-a-vis recursive routing. Clearly, DTLS is 1429 unsuitable for iterative routing due to it's per hop secure channel 1430 setup overhead. Therefore, we propose a to design a new secure and 1431 unreliable transport protocol which preserves message confidentiality 1432 and integrity, and is geared towards iterative routing in overlay 1433 networks. This suggestion is open to discussion. 1435 4.3.2.4. NAT Traversal 1437 Recursive routing is more friendly towards NATs and firewalls since a 1438 peer sends a message to the peers that have been recently 1439 communicated with. In iterative routing, a peer will likely have to 1440 send a message to a previously unknown peer. This unknown peer could 1441 be behind a NAT. A mechanism based on an offer/exchange mechanism of 1442 ICE will incur a significant communication overhead (REF:sec). 1443 Further, it is possible that a peer may not need to subsequently 1444 communicate with this peer behind the NAT and the overhead of ICE 1445 connectivity checks is perhaps overkill. The other mechanism to 1446 communicate with a peer behind a NAT is that a peer simultaneously 1447 sends the message to the host, server reflexive, and relay address of 1448 the peer behind a NAT. This requires the peer behind a NAT to 1449 publish and periodically refresh this information. 1451 4.3.2.5. Route Log 1453 The recursive forwarding of requests require intermediate peers to 1454 maintain state. The peers forwarding the request in a recursive 1455 manner may avoid the need of maintaining state by adding their Peer- 1456 Info objects to the route-log. The peers can only add their Peer- 1457 Info objects to the route-log if it was explicitly requested by the 1458 request originator. 1460 As discussed in Section 4.2, the approximate size of a peer-info 1461 object containing peer-ID and host, server-reflexive, and relay 1462 addresses is 78 bytes. If the request traverses approximately 20 1463 hops, the route-log size can easily exceed UDP MTU (assuming UDP is 1464 1,500 bytes). Route-logs are not needed when messages are forwarded 1465 in an iterative manner. 1467 4.4. Message Encoding Guidelines 1469 The message originator sets the source-ID in the message header and 1470 includes its peer-info object in the message. It may set the peer-ID 1471 object in the peer-info object. The peer generating an ACK or a 1472 response retains the request originator peer-ID in source-ID field. 1473 Additionally, it sets its own peer-ID in the response-ID field in the 1474 common header and includes its peer-info object. Unless requested by 1475 the message originator, the ACK or response message does not include 1476 the request originator's peer-info object. The rationale is that the 1477 request originator's peer-info has already been seen by the peers 1478 along the request path and its inclusion in the response or an ACK 1479 gives no further information. 1481 If the message originator requested a route log, then peers along the 1482 message path MUST add their peer-info objects after the peer-info 1483 objects in the received message. 1485 4.5. Enrollment and Authentication 1487 This section describes secure enrollment and authentication in a 1488 P2PSIP network using PKCS#10 on top of TLS and an optional HTTP 1489 digest mechanism. The secure enrollment assumes the existence of a 1490 Registration Authority (RA) and Certificate Authority (CA). The 1491 functions of RA and CA can be implemented in separate network 1492 entities, however for simplicity assume we that they are collocated 1493 in one entity called an enrollment and authentication (E&A) server. 1495 To enroll in an overlay, a user chooses an identifier and a password. 1496 The user identifier can be an email address, a SIP AoR, or any 1497 appropriate blob. The node then generates a public/private key pair 1498 and embeds the user and node identifier in the distinguished name of 1499 a certificate signing request (CSR). The node must store the private 1500 key as securely as possible. The CSR is encoded using PKCS#10 1501 [REF:]. The node then establishes a TLS connection with the server 1502 (without client certificate authentication) and sends the CSR with 1503 H(password) to the enrollment and authentication server (E&A) in an 1504 enroll request. 1506 If the request is authenticated, the server creates a random or a 1507 static peer-ID and embeds it in a DER encoded X.509 certificate along 1508 with the user identifier. It then sends this X.509 certificate 1509 containing user-ID, peer-Id and the expiration time in a 200 (Ok) 1510 response to the peer that sent the enroll request. If a bootstrap 1511 server is co-located with the E&A server, the 200 response includes a 1512 P2P-Options TLV and a list of bootstrap peers. 1514 One reason for the server to choose a peer-ID for the peer instead of 1515 the peer randomly generating its peer-ID is that a joining peer is 1516 unaware of the hash algorithm being used. The other reason is that 1517 it prevents a node from selecting a peer-ID or set of peer-IDs that 1518 it may use occupy a certain position in a structured overlay. In a 1519 mobility based deployment of P2PP, the server may assign the same 1520 peer-ID to the peer during its subsequent runs to minimize the effect 1521 of churn. 1523 A node which is already enrolled does not generate a new public / 1524 private key pair. Instead, it uses its existing public key and 1525 user-ID to generate a CSR and sends it along with a H(password) to 1526 the E&A server in an authenticate request. (TODO: certificate reuse 1527 before expiry) 1529 The enrollment and authentication mechanism is separate from the 1530 bootstrap mechanism because overlay may be formed in a non-secure 1531 environment. The E&A and bootstrap servers may be co-located. This 1532 is useful in a small network scenario. 1534 A first peer in the overlay or any peer can also act as an E&A 1535 server. 1537 The separation of user-ID and peer-ID allows multiple devices 1538 representing the same user to participate in the overlay. An 1539 structured overlay implementer may use peer-ID=H(user-ID), which 1540 would mean that a node publishing the user-info object is the one 1541 responsible for it. 1543 4.5.1. HTTP Digest Authentication 1545 TODO: draw figure. 1547 The message flow describes enrollment process in P2PSIP including the 1548 certificate request originated by a P2PSIP node using PKCS#10 with 1549 HTTP Digest on top of TLS. The flow starts with a P2PSIP node 1550 generating a public-private key pair. Next the P2PSIP node 1551 establishes a TLS connection with an enrollment server. It may 1552 registers its user-ID and password. The user-ID is in the form of 1553 SIP URI: username@domain. The registration of a user-ID and password 1554 can be separated from the enrollment process; however in this example 1555 we assume that both processes happen at the same time. 1557 Next the P2PSIP node sends a POST HTTP request to the enrollment 1558 server which generates an 403 Unauthorized response. The response 1559 contains a WWW-Authenticate header which instructs the node to use 1560 HTTP Digest authentication. The node creates a PKCS#10 request with 1561 the user-ID, public key, and optionally additional attributes and 1562 extensions. It sends the PKCS#10 request in the HTTP request by 1563 calculating the Authorization header values using the username and 1564 password. 1566 When the enrollment server receives the request, it verifies the 1567 Authorization header using user name and password as specified in RFC 1568 2617 [X]. If the verification succeeds, the incoming PKCS#10 request 1569 is taken in for further processing. After the PKCS#10 request has 1570 been processed and certificate(s) has been created, the enrolment 1571 server generates a HTTP response containing the certificate. The 1572 enrolment server generates a single certificate that includes both 1573 the user-ID and a peer-ID. When P2PSIP peer/client receives the 1574 certificate(s), it stores the certificate (or set of certificates) to 1575 the local certificate management system. 1577 OPEN ISSUE: Is it more reasonable to include the user-ID and the 1578 peer-ID in a single certificate or to have separate certificates? 1580 4.5.2. Authentication without a Central Authority 1582 TBD. Shared secret is one of the mechanisms. 1584 4.6. Bootstrap 1586 To join an overlay, a joining peer (JP) must determine the peer 1587 protocol that is being run in the overlay and must discover a peer 1588 that is already part of the overlay, thereafter called an admitting 1589 peer (AP). The bootstrap process assumes that JP has already been 1590 enrolled and authenticated. 1592 There are different mechanisms to discover a node already in the 1593 overlay as specified by Matthews [21]. This specification defines 1594 one mechanism, namely, bootstrap node or server that a joining peer 1595 can use to discover a peer already in the overlay. This mechanism 1596 assumes that the joining node already knows the IP address and port 1597 number of a bootstrap node or server. The bootstrap node may or may 1598 not be part of the overlay and it may be co-located with the 1599 enrollment and authentication server. 1601 To discover the peers already in the overlay, a JP sends a bootstrap 1602 request to the bootstrap node or server. The bootstrap node or 1603 server replies with its own peer-info object, the peer-info object of 1604 the peer that sent the bootstrap request along with its randomly 1605 generated peer-ID, a list of peer-info objects representing peers in 1606 the overlay, and a P2P-Options TLV. The JP then sends the join 1607 request to one of the peers in the list. If the list is empty, then 1608 the joining peer is the first peer in the overlay. 1610 A node sending the bootstrap request sets a 32-bit source-ID of 1611 0x00000000. The bootstrap node sets a 32-bit response-ID of 1612 0x00000001 in its response, even if it is part of the overlay, 1613 because the peer sending the bootstrap request may not be aware of 1614 the overlay parameters. 1616 If a JP has obtained a list of bootstrap peers in response to 1617 authenticate request, it does not need to send a bootstrap request. 1619 4.7. Joining, Leaving 1620 4.7.1. Join 1622 A JP discovers the overlay protocol and existing peer in the overlay 1623 using the bootstrap mechanism described in Section 4.6. It then 1624 sends a join request to the peer in the overlay. The overlay nodes 1625 are connected in a graph and conceptually, a JP adds a new vertex to 1626 this graph. Thus, the join process should correctly inform the JP's 1627 immediate neighbor peer(s) and take ownership of any resource-objects 1628 from them. Overall, the join operation involves the following steps: 1630 1. Determine its reachable address. 1632 2. Discover the peer(s) where the node will join. 1634 3. Inform the discovered peer(s) about itself. 1636 4. Build routing and neighbor tables (if any). 1638 5. Get ownership of any resource-objects. 1640 6. Publish user-info, the reachable address for the user. 1642 A JP searches for an appropriate STUN and TURN server in the overlay. 1643 The criteria for searching a STUN and/or a TURN server depends on the 1644 overlay implementer. After searching for the appropriate server, a 1645 JP determines its host, server-reflexive, and relay addresses. 1647 The JP MAY request the join request to be forwarded in a recursive 1648 (R=1) or an iterative manner (R=0). It does so by setting the 1649 appropriate value of R flag in the common header. A peer receiving 1650 the join request with the recursive routing flag set forwards it to 1651 the peer where JP will join. A peer receiving the join request with 1652 iterative routing flag set replies with a 302 (Next Hop) response if 1653 the JP will not be its immediate neighbor. 1655 If a peer receiving the request determines that the JP will be its 1656 neighbor, it MUST send a 200 (Ok) response to the node from which it 1657 received the request. The response contains the time before which 1658 the JP should send a keepalive message. The response may also 1659 contain a copy of the neighbor table of the peer. 1661 Once the JP receives a 200 (Ok) response, it checks the received 1662 neighbor table. It then sends a join request with the S flag set in 1663 the Request-Options object to the peers in the received neighbor 1664 table. The join request with S flag set indicates the overlay peers 1665 that the JP will be their new neighbor. It is up to the peer 1666 generating the 200 (Ok) response to decide, based on the p2p 1667 algorithm being used, which neighbors (successors, predecessors) a 1668 joining peer may contact to insert itself appropriately in the 1669 overlay. The neighbors of this newly joining peer should update 1670 their neighbor and routing tables appropriately. If the structured 1671 peer protocol does not require a neighbor table, then the join 1672 request with S flag is not sent. 1674 A JP MAY request to receive a copy of routing and neighbor tables of 1675 the peers that receive the join request. It does so by following the 1676 rules defined in Section 4.3. 1678 Finally, a JP publishes the user-info object in the overlay as 1679 described in Section 4.8.1. The user-info object contains the X.509 1680 certificate, and the host, server-reflexive, and relay addresses of 1681 the peer. The successful response contains an Expires header. A 1682 node keeps track of the resource-objects and their expire times in a 1683 'Publish Table' (Section 4.1). A JP should resend a publish request 1684 with the user-info object before the passage of time in Expires 1685 header. 1687 Once, the JP has successfully joined the overlay, its neighbor peers 1688 transfer it the ownership of appropriate resource-objects, using a 1689 Transfer request. The JP may also establish secure connections with 1690 its routing or neighbor peers. 1692 4.7.1.1. Rejecting or Deferring a Join Request 1694 Peers in the overlay may decide to reject a join request with a 406 1695 (Request Rejected) response because it does not satisfy the overlay 1696 policy for peers. NAT and node resources are examples of such 1697 policies. This specification does not specify any policy for peer 1698 admission and defers this decision to the overlay operator. 1700 Peer(s) in the overlay may not be willing to admit a JP node with no 1701 history about its uptime. If so, they reply with a 407 (Join Request 1702 Deferred) response and an Expires object after which the peer can 1703 reissue the join request. The JP receiving this response should join 1704 as a client in the overlay. It should reissue the join request 1705 without setting the peer flag in the common header. 1707 After the passage of time in Expires header, a client may attempt to 1708 insert itself again as a peer in the overlay. The AP or other peers 1709 may explicitly invite the client to join the overlay before the 1710 passage of time in the Expires field by sending an Invite request. 1712 4.7.1.2. Client Join 1714 A client enrolls and authenticates itself and discovers a peer 1715 already in the overlay using mechanisms defined in Section 4.5 and 1716 Section 4.6, respectively. It gathers its reachable addresses 1717 (Section 4.7.1.3) and sends a join request without setting the peer 1718 flag in the common header. The peer receiving the join request may 1719 immediately reply with a 200 (Ok) request if it can support a new 1720 client. It is up to the overlay implementer to decide how many 1721 clients may connect to a peer. If a AP determines that it already 1722 has a certain number of clients, it replies with a 302 (Redirect) 1723 response containing a list of peers to which a client may send the 1724 join request. 1726 After receiving a 200 response to its join request, the client 1727 publishes its user-info as a resource-object object in the overlay. 1728 The resource-object types are defined in Section 13. If the 1729 resource-object insertion is successful, the AP sends a 200 (Ok) 1730 response to the client and includes an Expires header. The client 1731 then establishes a TCP connection with the AP and periodically send 1732 it a keepalive. It sends all subsequent requests to its connected 1733 peer. 1735 4.7.1.3. NAT traversal 1737 A peer receiving a join request MUST include a resource-list object 1738 in its response indicating whether it is acting as a STUN or a TURN 1739 server. A peer may then gather its ICE candidates. 1741 The recommended operation mode is that each peer acts as a STUN or 1742 TURN server. 1744 4.7.2. Leave 1746 A peer sends a Leave indication to gracefully inform its routing or 1747 neighbor peers about its departure. It includes in the leave message 1748 a list of resource-objects the neighbor nodes should take over. The 1749 peers receiving a leave message must update their routing or neighbor 1750 tables appropriately. 1752 A peer SHOULD send the leave message over TCP as the size of peer-IDs 1753 and resource-objects is likely to exceed MTU. However, a peer SHOULD 1754 avoid a new TCP connection to send the leave message. 1756 A client MAY also send a leave message to inform its peer(s) about 1757 its impending departure. 1759 (Open Issue: The user should not have to wait for the p2p application 1760 to shut down. The p2p application is waiting for the receipt of 1761 Leave ACK.) 1763 4.8. Publish, LookupObject, LookupPeer 1765 4.8.1. Publish 1767 A node sends a publish request to a peer already in the overlay to 1768 publish a new resource-object or update an existing resource-object. 1769 A node typically sends a publish request in response to a usage layer 1770 API call. The resource-object have a content-type and a sub-type; 1771 the commonly used types are User-Info, STUN, TURN, and STUN+TURN. 1772 The publish operation involves locating the peer responsible for the 1773 resource-object and then inserting either the network address of the 1774 resource-object publisher or the resource-object itself. 1776 The publisher of the resource-object MUST also include information 1777 about its owner in the publish request because it may not necessarily 1778 be the owner of the resource-object. It is possible for multiple 1779 owners to publish or update an existing resource-object, as a peer 1780 may be interested in retrieving the resource-object published or 1781 updated by a certain owner. 1783 Additionally, a publisher must ensure that the integrity of the 1784 resource-object is preserved. It computes a digital signature over 1785 the whole resource-object, and includes the Signature object and its 1786 X.509 certificate as a sub-TLV of the resource-object. The signature 1787 is encoded using PKCS#7. 1789 The format of the Owner TLV is left to the overlay implementer. It 1790 can be a user-ID or a peer-ID. (TODO: can we leave it to the overlay 1791 implementer?) 1793 A peer generating a 200 (Ok) response to a Publish request MUST 1794 include an Expires header. The publisher of the resource-object MUST 1795 reissue the Publish request before the passage of time in Expires. 1797 A peer storing the resource-object MUST store the object signature 1798 and X.509 certificate of the resource publisher. 1800 4.8.2. LookupObject 1802 A node issues a LookupObject request to retrieve a resource-object 1803 from the overlay. It sets the content-type, sub-type, and 1804 resource-ID fields in the Rlookup TLV. Additionally, it may set the 1805 owner field in RLookup TLV. 1807 A peer receiving the LookupObject request must include in its 200 1808 response the certificate of the object publisher. If multiple owners 1809 had published data under the resource-ID being searched, and if the 1810 owner is not specified, the peer storing the resource-object includes 1811 all objects in its response. 1813 The resource-object size may exceed UDP MTU if the request was sent 1814 over UDP. The node responsible for the resource-object replies with 1815 a 480 (Alternative Service) response. The query originator, on 1816 receiving this response, reissues the LookupObject request over TCP 1817 to the peer responsible for the resource-object. 1819 The peer generating a 200 response for a LookupObject request MUST 1820 include the X.509 certificate of the publisher in its response. 1822 4.8.3. LookupPeer 1824 A peer issues a LookupPeer request to discover another peer in the 1825 overlay. For example, in Bamboo [22], a peer uses global tuning and 1826 local tuning to update its routing table. In these methods, a peer 1827 issues a lookup on an identifier which has L digits in common with 1828 peer-ID but differs in the (L+1)st digit (global tuning), or 1829 periodically contacts a random member of its routing table and 1830 requests all members at a certain level (local tuning). To 1831 accomplish this, a peer can issue a LookupPeer request. (TODO: 1832 reword) 1834 A peer can issue a LookupPeer request to locate a single peer, 1835 multiple peers or range of peers. The 'Num' field controls the 1836 maximum number of peer-info objects returned in the response. 1838 4.9. Maintenance 1840 A peer performs various maintenance operations to maintain links with 1841 other peers in the overlay. The maintenance operations use the 1842 messages provided by P2PP to maintain links with other peers in the 1843 overlay. This involves the following two operations: 1845 1. KeepAlive to neighbor and routing peers after the expiry of KAT 1846 timer. 1848 2. Periodic update of neighbor and routing tables after the expiry 1849 of RMT and NMT timer. 1851 A client sends a periodic keepalive to its peer to maintain its link 1852 with the peer. 1854 P2PP provides three messages namely, KeepAlive, ExchangeTable, and 1855 LookupPeer for overlay maintenance. KeepAlive is used to determine 1856 the liveness of the destination peer; ExchangeTable is used to obtain 1857 the routing and/or neighbor table of the peer; and LookupPeer is used 1858 to search for a specific peer to fill a routing-table entry. The 1859 transmission of these requests is governed by timers in 1860 Section 4.9.1. Additionally, a receipt of a message from a neighbor 1861 or routing peer results in updating its keepalive timer. It is up to 1862 the overlay implementer to adjust the values of these timers. 1864 The maintenance algorithms are DHT specific and are specified in a 1865 separate draft (TODO). However, the messages to accomplish 1866 maintenance operations are defined in this draft. 1868 4.9.1. Node Timers 1870 This section defines node-specific timers for overlay maintenance and 1871 ExchangeTable requests. The timer values are only provided as a 1872 reference. The overlay implementer is free to choose a suitable 1873 value depending on the system requirements. 1875 Timer Value Description 1876 --------------------------------- 1877 KAT 10s KeepAlive timer 1878 RMT 30s Routing-table maintenance timer 1879 NMT 30s Neighbor-table maintenance timer 1880 RT 30s Replication management timer 1881 RRT Var. Resource refresh timer 1882 RA 10s Start of range-time for message transmission 1883 RB 30s End of range-time for message transmission 1885 (TODO: a separate draft for overlay maintenance operations) 1887 4.10. Replication 1889 The replication mechanism describes how resource-objects are 1890 replicated in the overlay. It is necessary to replicate resource- 1891 objects in the overlay to maintain their availability during churn. 1892 Resource-objects can be replicated by the publisher or by the node at 1893 which they are stored. The number of replicas depends on the 1894 availability requirements. 1896 Either the node which publishes the resource or the node at which the 1897 resource-object is stored can initiate replication. P2PP provides a 1898 replicate request to replicate a group of resource-objects. 1900 The replication process is triggered after the expiry of RT 1901 (replication management timer). If there has not been any change in 1902 the routing or neighbor table of a peer, there is no need to 1903 replicate. 1905 4.11. Capabilities and Diagnostics 1907 (TODO: This section needs to be elaborated.) 1909 P2PP provides a mechanism to allow nodes with heterogeneous 1910 capabilities to exchange their capabilities and their current 1911 resource utilization. Nodes exchange their resource-utilization and 1912 their capabilities during maintenance and at join. Nodes should 1913 exchange capabilities when establishing communication for the first 1914 time. The capabilities and diagnostic information is included as 1915 part of Peer-Info object. 1917 P2PP provides a GetDiagnostic request message. Peers can use this 1918 message to send their current capabilities and diagnostic information 1919 to another peer or a central server. This is useful for debugging 1920 purposes. 1922 Peers can use Query request (Section 8.9 to explicitly request the 1923 capabilities of another peer. 1925 5. P2PP Processing 1927 5.1. Resources and Services 1929 The resource-object represents the resources a node is responsible 1930 for or the services it may provide. A resource-object has a type, a 1931 sub-type, a resource-ID, and a value. It has additional attributes, 1932 namely, owner, expires, signature, peer-info, and X.509 certificate. 1933 The type and sub-type identify the type of resource-object that is 1934 being published or searched. The resource-ID represents a searchable 1935 identifier for a resource or a service and is qualified by the type 1936 and sub-type fields. It is possible for different resource-objects 1937 and services to have the same resource-ID (representing a 1938 discoverable identifier), but a different type and sub-type. Thus, 1939 type and sub-type represent a unique namespace in the system. The 1940 peer-info represents the publisher of the resource-object. 1942 It is possible for a peer or a set of peers to provide the same 1943 service. Many peers may be interested in using the service provided 1944 by different peers. The protocol should provide a mechanism for 1945 peers to publish their service information, to discover the peers 1946 providing the same service and to judiciously balance the load on the 1947 service peers. We discuss four different ways in which a peer can 1948 advertise their service information for appropriate discovery by 1949 interested peers. 1951 Standard Service Name: All peers use a standard service name to 1952 advertise the same service. The standard service name represents a 1953 discoverable identifier and is published in resource-ID field of the 1954 resource-object. In structured networks such as DHTs, keys are 1955 stored against identifiers. If a standard service name was used, it 1956 will always hash to a particular value. The information about all 1957 peers providing the same service will be stored at a peer with an 1958 identifier closest to the hash value of a service name. A peer which 1959 happens to have a peer-ID that is closest in the DHT sense to the 1960 hash of the service name will end up storing information about all 1961 peers providing this service, and will need to replicate it to 1962 neighbor peers for availability. In a large system where hundreds or 1963 thousands of peers may provide the same service, this scheme 1964 overburdens the storage and bandwidth capacity of the peer 1965 responsible for this information. 1967 ReDiR: ReDiR is a mechanism proposed by OpenDHT [10] that addresses 1968 the issues discussed above. ReDiR proposes to build a two- 1969 dimensional quad-tree of the nodes that have joined under a key and 1970 embeds them in the DHT using Publish/LookupObject interface. Using 1971 this tree, ReDiR performs lookup in logarithmic number of operations 1972 and based on past lookups, it can reduce the average lookup to a 1973 constant number of operations. To publish its service advertisement, 1974 a node picks a random level l, and computes a hash of service name 1975 and l H(service_name,l). If node(s) providing the service exist at 1976 this level, it recomputes H(service_name,l+1) and searches for the 1977 next level. It then publishes its service information at the next 1978 available level. 1980 Random Id: Another mechanism to prevent service advertisement and 1981 lookup requests always going to a certain peer is to pick k random 1982 identifiers and publish the service advertisement under those random 1983 identifiers. A node searching for a peer providing a certain service 1984 picks up a random identifier and searches it in the overlay for 1985 corresponding service name. The idea is that it will likely hit upon 1986 a node which provides this service if a sufficient number of 1987 advertisements were published in the overlay. 1989 Random Walk and Learning: One option is not to explicitly publish 1990 information about the nodes providing the service and instead spread 1991 this information implicitly. A node must have a routing table and 1992 may have a neighbor table. The routing and neighbor peers of a node 1993 inform it about the list of services they are providing in a 1994 Resource-List TLV. Since a node's routing table may contain few 1995 hundred (realistic?) entries, it is possible that some of them may 1996 provide the service. A node searching for a peer providing certain 1997 service performs a random walk over its routing or neighbor peers 1998 till it finds an appropriate peer. 2000 Note that the first three schemes are geared towards DHTs while the 2001 last scheme is applicable to unstructured networks. The resource 2002 (service) publishing and discovery uses the APIs provided the 2003 underlying peer protocol and is not tied to the underlying peer 2004 protocol. The peers can also learn about the nodes providing a 2005 certain service as a side effect of other messages received. This is 2006 exactly what random walk and learning scheme achieves. 2008 5.2. NAT Traversal 2010 The easiest and simplest way solve NAT traversal issues in a global 2011 deployment is to only allow nodes with unrestricted network 2012 connectivity to become peers. In such a scenario, all peers act as 2013 STUN and TURN servers. This is however not realistic on the Internet 2014 as is or applicable for P2PSIP providers that cannot afford large 2015 numbers of public peers required to support large overlays. Thus, 2016 P2PP allows peers behind NATs to participate in the overlay. 2018 The following issues are related to NAT traversal. 2020 1. Publishing and discovery of NAT traversal service in the overlay. 2022 2. Gathering of candidates and NAT behavior discovery. 2024 3. Communicating with a peer behind a NAT. 2026 4. Maintenance of NAT bindings. 2028 5. Load balancing 2030 5.2.1. NAT Traversal Service Advertisement and Discovery 2032 P2PP allows peers to provide NAT traversal service. Peers providing 2033 such a service publish this information in the overlay may use one of 2034 the four mechanism described in Section 5.1. Additionally, for 2035 structured overlays, peers may use hash of the autonomous system 2036 number of their host or server-reflexive IP address as a resource-ID. 2038 It is possible for peers at various NAT levels to offer STUN and TURN 2039 service. Peers behind p2p-friendly NATs may also provide STUN and 2040 TURN service [25]. 2042 5.2.2. Gathering of Candidates and NAT Behavior Discovery 2044 At join, a JP searches for an appropriate peer providing STUN or TURN 2045 server in the overlay using LookupObject request. It then gathers 2046 its host, server-reflexive, and relay candidates using the discovered 2047 peers. Note that the relay candidate is used for relaying P2PP 2048 messages. A JP may also use NAT behavior discovery mechanisms 2049 defined in [24] to discover the type of NAT it is behind. A JP may 2050 use this information to determine if it should join as a peer or a 2051 client (although this is not recommended by [24]. Alternatively, the 2052 AP (admitting peer) decides based on the gathered candidates whether 2053 JP satisfies the overlay implementer guidelines for a peer. 2055 It is impossible to determine uptime guarantees for a peer providing 2056 a STUN or TURN service. A peer should keep a list of peers providing 2057 STUN or TURN service and may maintain and advertise more than one 2058 server-reflexive and relay candidates. 2060 5.2.3. Communicating with a Peer Behind a NAT 2062 The choice of recursive or iterative routing has an impact on the 2063 mechanisms to communicate peers behind a NAT. If a all nodes in the 2064 overlay use recursive routing, then under low churn they only need to 2065 communicate with their routing and neighbor peers. The nodes behind 2066 NATs can form a communication channel with their routing and neighbor 2067 peers by exchanging their gathered candidates in a Connect request 2068 and response. 2070 The situation changes when the overlay has moderate or heavy churn or 2071 uses iterative routing. During these circumstances, a peer behind a 2072 NAT may need to communicate with other peers only once; and it may 2073 never subsequently communicate with them. Since these peers have 2074 published their host, server-reflexive, and relay candidates in the 2075 overlay, a peer intending to communicate with them simply sends a 2076 copy of the message to these addresses. 2078 5.2.4. Maintenance of NAT Bindings 2080 A peer sends the STUN Binding request to maintain NAT bindings. 2082 5.2.5. Load Balancing for Media Flows 2084 5.2.6. ICE Overhead 2086 ICE is geared towards establishing long-lived sessions. In a typical 2087 ICE usage scenario, a peer planning to establish communication with 2088 other peers gathers its address candidates and sends them in an offer 2089 to the remote peer. The assumption is that a peer is unaware of the 2090 address candidates of the remote peer and they must exchange this 2091 information and discover the address candidates best suitable for 2092 subsequent exchange. 2094 In P2PP, peers gather their address candidates at join and publish 2095 them in the overlay. Further, a node will have all the address 2096 candidates for peers in its routing table or neighbor table. When a 2097 user-info object is published, all the address-candidates are also 2098 published along with it. Thus, when a user-info object is retrieved 2099 or a peer-info object is in returned in a 302 response, they will 2100 contain all the address candidates of the peer. A peer forwarding 2101 requests in an iterative manner can simply send copies of the message 2102 to all the address candidates of the peer. If subsequent 2103 communication is desired, then the address candidates be 2104 appropriately pruned. 2106 TODO: Discuss below. 2108 Encoding overhead: User and password, foundation and component-id 2109 size. P2PP ICE encoding removed user password, and reduced 2110 foundation and comp-id size. 2112 TURN message exchange overhead: Allocate an address and then create 2113 permissions in a separate message. 2115 5.3. Route Log 2117 TODO: Only needed for recursive routing. 2119 5.4. P2PP and SIP 2121 SIP [2] messages to peers with restricted connectivity are tunneled 2122 through peers with unrestricted connectivity. The SIP message is 2123 encapsulated in a resource-object and is sent to the peer responsible 2124 for the node with restricted connectivity. 2126 6. Transport Layer 2128 This section defines mechanisms for reliably delivering a message to 2129 the next hop. For requests, a transaction constitutes of a single 2130 request followed by acknowledgements (if any), and a response. For 2131 responses, reponseACKs, and indications, a transaction consists of 2132 single response, responseACK, or indication, followed by an ACK if 2133 unreliable transport is used. Section 3.4 and Section 3.5 discussed 2134 the need for acknowledgements and responseACKs. 2136 6.1. Transaction Identifier 2138 A transaction is identified by a source-ID, transaction-ID tuple, and 2139 a transaction-type triple. This is used to match acknowledgements 2140 (ACK) to requests, responses and indications. However, the responses 2141 and responseACKs are matched to requests using only source-ID and 2142 transaction-ID tuple. A transaction can be of four types, namely, 2143 request, response, responseACK, or an indication. The source-ID, 2144 transaction-ID, and transaction-type must be preserved in the ACKs. 2145 Each request or indication has a locally unique 32-bit 2146 transaction-ID. 2148 6.2. Message State Machine 2150 This section defines state machine for unreliable and unreliable 2151 transports. 2153 6.2.1. State Machine for Unreliable Transports 2155 For unreliable transports, the transaction state machine for requests 2156 is shown in Figure 8 whereas state machine for responses and 2157 indications is shown in Figure 9. 2159 The "Trans_Msg" (abbreviation for transmit message) state is entered 2160 when a peer sends a request, response, responseACK, or an indication. 2161 When entering this state, the transaction should set timer T1 and T2. 2162 Timer T1 governs retransmissions and is updated after ith 2163 retransmission as follows: T1=2^i*T0. If timer T2 fires, the state 2164 machine transitions to "Failed" state and is terminated. 2166 If a request was sent and an acknowledgement was received, the state 2167 machine transitions to "Wait_Resp" state. When entering this state, 2168 the transaction should set timer T3. If timer T3 fires, the state 2169 machine transitions to "Failed" state and is terminated. If a 2170 responseACK was received, the transaction sends an ACK and is 2171 terminated. 2173 If a response, responseACK, or an indication was sent and ACK was 2174 received, the state-machine immediately transitions to the 2175 "Terminated" state. 2177 +-----------+ 2178 | | 2179 | Initial | 2180 | | 2181 +-----------+ 2182 | 2183 | tx_Msg / set Timer T1 and T2 2184 Timer T1 fires / | 2185 T1=2^i*T0 V Transport Err. or 2186 tx_Msg +------------+ Timer T2 fires 2187 +------| | Inform App. 2188 | | Trans_Msg |----------------->+ 2189 +----->| | | 2190 +------------+ | 2191 | | ACK received / | 2192 +----------------------+ | set Timer T3 | 2193 | | stop Timer T1, T2 | 2194 | V | 2195 | +-----------+ Transport Err. | 2196 | responseACK rcvd / | | or Timer T3 fires | 2197 | stop Timer T1, T2 | Wait_Resp |------------------>| 2198 | send ACK | | | 2199 | +-----------+ | 2200 | | | 2201 | | Resp received / | 2202 | | send ACK | 2203 | V | 2204 | +------------+ | 2205 | | | | 2206 +------------------->| Terminated | | 2207 | | | 2208 +------------+ | 2209 | 2210 +-----------+ | 2211 | | | 2212 | Failure |<------------------+ 2213 | | 2214 +-----------+ 2216 Figure 8: Transaction state machine for requests for unreliable 2217 transport 2218 +-----------+ 2219 | | 2220 | Initial | 2221 | | 2222 +-----------+ 2223 | 2224 | tx_Msg / set Timer T1 and T2 2225 Timer T1 fires / | 2226 T1=2^i*T0 V Transport Err. or 2227 tx_Msg +------------+ Timer T2 fires 2228 +------| | Inform App. 2229 | | Trans_Msg |----------------->+ 2230 +----->| | | 2231 +------------+ | 2232 | | 2233 | ACK received | 2234 | stop Timer T1, T2 | 2235 V | 2236 +------------+ | 2237 | | | 2238 | Terminated |----------------->| 2239 | | | 2240 +------------+ | 2241 | 2242 +-----------+ | 2243 | | | 2244 | Failure |<------------------+ 2245 | | 2246 +-----------+ 2248 Figure 9: Transaction state machine for responses and indications for 2249 unreliable transport 2251 6.2.2. State Machine for Reliable Transports 2253 For reliable transports, the transaction state machine for requests 2254 is shown in Figure 10; the state machine for responses and 2255 indications is shown in Figure 11. 2257 The "Trans_Msg" state is entered, when a peer issues or forwards the 2258 request, response, or an indication. If the message was a response 2259 or an indication and was successfully sent, the state machine 2260 transitions to "Terminated" state. If the message was a request and 2261 was successfully sent, the transaction sets Timer T3 and transitions 2262 to "Wait_Resp" state. If a response is received, the transaction is 2263 terminated. No ACK is sent for requests, responses, and indications 2264 sent over reliable transport. Similarly, no responseACK is generated 2265 for a request. 2267 If the request was forwarded in a recursive manner, the application 2268 MUST not terminate the reliable-transport connection. If the request 2269 was forwarded in an iterative manner, an application MAY terminate 2270 the reliable transport connection if it does not anticipate its 2271 reuse. 2273 +-----------+ 2274 | | 2275 | Initial | 2276 | | 2277 +-----------+ 2278 | 2279 | tx_Msg 2280 | 2281 V 2282 +------------+ Transport Err. 2283 | | Inform App. 2284 | Trans_Msg |----------------->+ 2285 | | | 2286 +------------+ | 2287 | Msg successfully sent / | 2288 | set Timer T3 | 2289 | | 2290 V | 2291 +-----------+ Transport Err. | 2292 | | or Timer T3 fires | 2293 | Wait_Resp |------------------>| 2294 | | | 2295 +-----------+ | 2296 | | 2297 | Resp received | 2298 | | 2299 V | 2300 +------------+ | 2301 | | | 2302 | Terminated | | 2303 | | | 2304 +------------+ | 2305 | 2306 +-----------+ | 2307 | | | 2308 | Failure |<------------------+ 2309 | | 2310 +-----------+ 2312 Figure 10: Transaction state machine for requests for a reliable 2313 transport 2314 +-----------+ 2315 | | 2316 | Initial | 2317 | | 2318 +-----------+ 2319 | 2320 | tx_Msg 2321 | 2322 V 2323 +------------+ Transport Err. 2324 | | Inform App. 2325 | Trans_Msg |---------------+ 2326 | | | 2327 +------------+ | 2328 | | 2329 | Msg successfully sent| 2330 V | 2331 +------------+ | 2332 | | | 2333 | Terminated | | 2334 | | | 2335 +------------+ | 2336 | 2337 | 2338 +-----------+ | 2339 | | | 2340 | Failure |<---------------+ 2341 | | 2342 +-----------+ 2344 Figure 11: Transaction state machine for responses and indications 2345 for a reliable transport 2347 6.3. Timers 2349 This section defines timers for message state machines. 2351 Timer Value 2352 ---------------------- 2353 T0 500 ms 2354 T1 T0 2355 T2 5s 2356 T3 5s 2358 7. Security Considerations 2360 7.1. Routing Security 2362 7.1.1. Peer-ID Assignment 2364 In P2PP, user-IDs and peer-IDs are assigned in a centralized and 2365 secure manner. This provides protection against Sybil attacks [23]. 2366 The user-IDs are typically chosen by a user at the time of enrollment 2367 and peer-IDs are chosen in a manner which preserves their uniqueness 2368 across different network environments such as NAT. During enrollment 2369 and/or authentication, a node sends its peer-ID and user-ID in a DER 2370 encoded certificate signing request (CSR) to a central trusted 2371 authority, typically the entity providing overlay software. If 2372 approved, the CA responds with a DER encoded X.509 signed 2373 certificate, which binds the public key of the node to the user-ID 2374 and peer-ID. Peers and clients must enroll themselves before 2375 participating in the overlay. Section 4.5 discusses the enrollment 2376 process. 2378 There are circumstances in which a central trusted authority may not 2379 be available or has a significant establishment overhead. The 2380 examples are overlays setup for a meeting or in a small office 2381 environment. One of the peers, typically the first peer in the 2382 overlay, may act as a central authority. Additionally, self-signed 2383 certificates may be used. (TODO: Can we deprecate this mechanism?) 2385 7.1.2. Message Forwarding and Message Integrity 2387 P2PP provides protection against routing threats (2)-(4) by sending 2388 and forwarding messages over secure and [un]reliable transports, 2389 namely, DTLS or TLS. Message integrity is also provided by these 2390 transports. P2PP provides protection against (4) by only a hash 2391 identifier of a user-ID in its certificate or messages. 2393 7.1.3. Routing and Neighbor Table Management 2395 Despite secure ID assignment and message forwarding, the peers can be 2396 compromised in an overlay. An attacker with a secure ID performing 2397 secure forwarding can poison the routing and neighbor tables of non- 2398 faulty nodes. (TODO: Use schemes in various p2p security papers. Is 2399 there a need to standardize it?) 2401 7.1.4. Admission Control 2403 TBD. 2405 7.1.5. Residual Attacks 2407 TBD. 2409 7.2. Storage Security 2411 7.2.1. Integrity 2413 P2PP provides protection against storage integrity threats by 2414 mandating peers to digitally sign a message in a PKCS#7 format (TODO: 2415 evaluate its overhead.) Peers store their X.509 certificates with 2416 the stored data which allows nodes searching for the stored data to 2417 verify its integrity. 2419 7.2.2. Permissions 2421 TODO 2423 7.2.3. Quota 2425 TODO 2427 7.2.4. Residual Attacks 2429 TODO 2431 8. Message Formats 2433 All P2PP messages begin with a common header, followed by a sequence 2434 of type-length-value (TLV) objects. This section describes all P2PP 2435 messages and their contents at a high level in ABNF [4]. 2437 P2PP defines eighteen messages as shown below. The messages are 2438 grouped together by related functions they perform. 2440 P2PP-Msg = Enroll / Authenticate / Bootstrap / 2441 Join / Leave / KeepAlive / 2442 LookupPeer / ExchangeTable / Query 2443 Replicate / Transfer / 2444 Publish / LookupObject / RemoveObject / 2445 Tunnel / Connect 2446 Invite / 2447 GetDiagnostics 2449 8.1. Enroll 2451 Enrolls the user in the overlay. 2453 Enroll = Common-header 2454 [Request-Options] 2455 Peer-Info 2456 Certificate-Sign-Request 2457 Password 2459 Enroll (Resp) = Common Header 2460 Peer-Info 2461 X.509-Certificate 2462 [P2P-Options] 2463 [Peer-Info]* 2464 [Ext] 2466 8.2. Authenticate 2468 Authenticate the user and generates a certificate binding user-ID, 2469 peer or client ID, and public key of the peer. 2471 Authenticate = Common-header 2472 [Request-Options] 2473 Peer-Info 2474 Certificate-Sign-Request 2475 Password 2477 Authenticate (Resp) = Common Header 2478 Peer-Info 2479 X.509-Certificate 2480 [P2P-Options] 2481 [Peer-Info]* 2482 [Ext] 2484 8.3. Bootstrap 2486 A request sent by a peer or a client to a bootstrap server or peer to 2487 discover the IP address of a peer already in the overlay. 2489 Bootstrap = Common-header 2490 Peer-Info 2492 Bootstrap (Resp) = Common Header 2493 Peer-Info (bootstrap peer) 2494 Peer-Info (request originator) 2495 P2P-Options 2496 [Peer-Info]* 2497 [Ext] 2499 P2P-options = Hash-algorithm 2500 Hash-algorithm-length 2501 DHT-algorithm 2502 OverlayID-length 2503 Overlay-ID 2505 8.4. Join 2507 A request sent by a peer to join the overlay. The join request sent 2508 by a client is not forwarded to other peers. 2510 Join = Common-header 2511 [Request-Options] 2512 Peer-Info 2514 Join (Resp) = Common Header 2515 Peer-Info 2516 [Peer-Info]* 2517 [Expires] 2518 [Routing-Table] 2519 [Neighbor-Table] 2520 [Ext] 2522 Routing-table = Num-entries 2523 [Peer-Info]* 2525 Neighbor-peers = Num-entries 2526 [Peer-Info]* 2528 8.5. Leave 2530 Peers send the leave indication to their routing and peers indicating 2531 their departure. Clients periodically send the leave message to 2532 their respective peers. 2534 Leave = Common-header 2535 Peer-Info 2536 [Peer-Info]* 2537 [Resource-object]* 2539 8.6. KeepAlive 2541 Peers periodically send a keepalive indication to their routing and 2542 neighbor peers to check whether they are alive. Clients send a 2543 keepalive to their peers to check whether they are alive. 2545 KeepAlive = Common-header 2546 Peer-Info 2547 Expires 2549 KeepAlive (Resp) = Common-header 2550 Peer-Info 2551 Expires 2553 8.7. LookupPeer 2555 Peers send this request to discover a peer that may fill or update a 2556 missing entry in their routing or neighbor table. 2558 LookupPeer = Common-Header 2559 [Request-Options] 2560 Peer-Info 2561 PLookup 2563 LookupPeer (resp) = Common-Header 2564 Peer-Info 2565 [Peer-Info]* 2566 [Ext] 2568 8.8. ExchangeTable 2570 Peers periodically send this request to their routing and neighbor 2571 peers obtain their routing and neighbor tables. 2573 ExchangeTable = Common-Header 2574 Peer-Info 2575 Request-Options 2577 ExchangeTable (resp) = Common-Header 2578 Peer-Info 2579 [Routing-table] 2580 [Neighbor-peers] 2581 [Ext] 2583 8.9. Query 2585 Query a peer or a client to discover the services they provide or the 2586 resource-objects they store. 2588 Query = Common-Header 2589 Peer-Info 2591 Query (resp) = Common-Header 2592 Peer-Info 2593 [P2P-Options] 2594 [Resource-List] 2595 [Ext] 2597 8.10. Replicate 2599 Peers periodically send this request to replicate the resource- 2600 objects for availability. The choice of peers on which to replicate 2601 the objects depends on the peer protocol. 2603 Replicate = Common-header 2604 Peer-Info 2605 [Resource-Object]* 2606 [Ext] 2608 Replicate (Resp) = Common-header 2609 Peer-Info 2611 8.11. Transfer 2613 After a successful join or graceful or ungraceful failure of peers, a 2614 peer transfers the ownership of resource-objects using a transfer 2615 request. 2617 Transfer = Common-header 2618 Peer-Info 2619 [Resource-object]+ 2620 [Ext] 2622 Transfer (Resp) = Common-header 2623 Peer-Info 2625 8.12. PublishObject 2627 Publish a resource-object. Also, used to refresh or update an 2628 existing resource-object. 2630 PublishObject = Common-header 2631 [Request-Options] 2632 Peer-Info 2633 Resource-Object 2635 Publish (Resp) = Common-header 2636 Peer-Info 2637 Expires 2639 8.13. LookupObject 2641 Search for a resource-object. 2643 LookupObject = Common-header 2644 [Request-Options] 2645 Peer-Info 2646 RLookup 2648 LookupObject (resp) = Common-header 2649 Peer-Info 2650 Resource-Object 2652 8.14. RemoveObject 2654 Remove a resource-object. 2656 RemoveObject = Common-header 2657 [Request-Options] 2658 Peer-Info 2659 Resource-Object 2661 Remove (Resp) = Common-header 2662 Peer-Info 2664 8.15. Tunnel 2666 Tunnel an application layer protocol message into a P2PP message. 2667 Mostly used for sending SIP messages to peers or clients behind a 2668 NAT. 2670 Tunnel = Common-header 2671 [Request-Options] 2672 Peer-Info 2673 Resource-Object 2675 Tunnel (Resp) = Common-header 2676 Peer-Info 2678 8.16. Connect 2680 Send an ICE offer (TBD). 2682 Connect = Common-header 2683 [Request-Options] 2684 Peer-Info 2686 Connect (Resp) = Common-header 2687 Peer-Info 2689 8.17. Invite 2691 Peers send an invite request to a client, inviting them to become a 2692 peer. 2694 Invite = Common-header 2695 Peer-Info 2697 Invite (Resp) = Common-header 2698 Peer-Info 2700 9. Packet Formats 2702 This section defines PDUs for the messages and their methods defined 2703 above. 2705 9.1. Common Header 2707 All P2PP messages begin with a common header. It has a fixed format, 2708 as shown below. 2710 0 1 2 3 2711 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 2712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2713 |V=2| T |A|P|R| Reserved | Request Type | TTL | 2714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2715 | Magic Cookie | 2716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2717 | Transaction-ID | 2718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2719 | Message Length | 2720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2721 // Source-ID // 2722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2724 Version (2 bits): The protocol version number. The current version 2725 is 1. 2727 T (2 bits): Indicates the message type: (00) for a request, (01) for 2728 an indication, (10) for a response, (11) for a responsACK. 2730 A flag: If set (A=1), the message is an acknowledgement for the 2731 request, response, responseACK, or an indication. The A flag is 2732 never set for reliable transports. 2734 P flag: If set (P=1), the message is sent by a peer. Otherwise, a 2735 client sends the message. 2737 R flag: If set (R=1), the request is sent in a recursive manner. 2738 Otherwise, it is sent in an iterative manner. The flag is not set 2739 for responses or indications. 2741 Request or Indication Type (8 bits): The request or indication 2742 message type such as join and leave. 2744 TTL (8 bits): A hop count for the number of peers this request can 2745 traverse. 2747 Magic cookie (32 bits): A field with a fixed value (0x596ABF0D) to 2748 differentiate P2PP messages from other protocol messages such as 2749 STUN. 2751 Transaction-ID (32 bits): A unique number to match responses with 2752 the originated requests. Along with source-ID, it can uniquely 2753 identify a message in the system. 2755 Message Length (32 bits): The byte length of the message after the 2756 common header itself. 2758 Source-ID (variable): The Peer-ID of the peer of client sending the 2759 request. For DHTs, it is the fixed length output of the hash 2760 function. For unstructured networks, it is a fixed length 2761 identifier. The length of this field is determined at Join. For 2762 bootstrap and authenticate requests, its length is always four 2763 bytes. 2765 For responses, the rightmost 9-bits of the Reserved field contain the 2766 response code. The response contains a destination-ID field, which 2767 is the peer-ID of the node generating the provisional or final 2768 response. 2770 0 1 2 3 2771 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 2772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2773 |V=2| T |A|P|R| Response code | Request Type | TTL | 2774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2775 | Magic Cookie | 2776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2777 | Transaction-ID | 2778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2779 | Message Length | 2780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2781 // Source-ID // 2782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2783 // Response-ID // 2784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2786 The Peer-ID of the peer or client sending the response. For DHTs, 2787 it is the fixed length output of the hash function. For 2788 unstructured networks, it is a fixed length identifier. The 2789 length of this field is determined during bootstrap. For 2790 responses to bootstrap and authenticate requests, its length is 2791 always four bytes. 2793 9.2. General Object Format 2795 Each P2PP object begins with a fixed header giving the object type 2796 and length. This is followed by the object Value. 2798 0 1 2 3 2799 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 2800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2801 | Object-Type |A|B| Reserved | Length | 2802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2803 // Value // 2804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2806 Object-Type (8 bits): An IANA-assigned identifier for the type of 2807 the object. 2809 AB=00 "(Mandatory)": If the object is not understood, the entire 2810 message containing it MUST be rejected with an "Object Type Error" 2811 message with sub code 1 ("Unrecognized Object"). 2813 AB=01 "(Ignore)": If the object is not understood, it MUST be 2814 deleted and the rest of the message processed as usual. 2816 Length (16 bits): The byte length of the object. 2818 The combination AB=10 and AB=11 are reserved. 2820 9.3. P2PP TLV Objects 2822 9.3.1. Peer-Info 2824 Type: Peer-Info 2826 Length: Variable (depends on the length of Peer-ID, IP version and 2827 unhashed key if any. The Peer-Info MUST include an address-info 2828 object or a peer-ID. It may also include additional objects such 2829 as unhashed-ID, uptime, neighbor/resource utilization, and expires 2830 which defines the keepalive interval. The peer issuing the 2831 request may not include its peer-ID in the peer-Info object as it 2832 is already included in the common header. However, peers in the 2833 request path must include their peer-ID as well as address-info 2834 objects. 2836 Peer-ID: 2838 0 1 2 3 2839 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 2840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2841 // Peer-ID // 2842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2844 Peer-ID (variable): It is an identifier of the node (client or peer) 2845 issuing or forwarding the request. For DHTs, it is a fixed-length 2846 output of a hash function. For unstructured networks, it is also 2847 a fixed-length identifier. 2849 Uptime: 2851 0 1 2 3 2852 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 2853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2854 | Uptime | 2855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2857 Uptime (32 bits): The uptime of this peer in number of seconds. 2859 Resource-List: 2861 0 1 2 3 2862 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 2863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2864 | Num |Resource-Type1 |Resource-Type2 |Resource-Type3 | 2865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2867 Num (8 bits): Number of resource-lists. 2869 Resource-Type (8 bits): Same as Cont-Type in Resource-Info object. 2870 Typically, only included for the services such as STUN or TURN 2871 that the node is currently providing. 2873 Address-Info: 2875 0 1 2 3 2876 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 2877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2878 | Num |R|Resv.| IP-ver| Foundation | Component-ID | 2879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2880 | Priority | 2881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2882 | TT | HT | Port | Peer address // 2883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2884 Num (4 bits): Number of ICE candidates. 2886 R flag: If set, rel-addr and rel-port are included as defined in ICE 2887 [7]. 2889 IP-Ver (4 bits): The IP version number, 4 or 6. 2891 Foundation (8 bits): The foundation field as defined by ICE. Note 2892 that the length of this field is only 8-bits as compared to 64- 2893 bits as defined by ICE specification. 2895 Component-ID (8 bits): The component-ID field as defined by ICE. 2897 Priority (32 bits): The priority of the address obtained through 2898 ICE. 2900 TT (4 bits): The transport type of the address. One of UDP (0000), 2901 or TCP (0001). 2903 HT (4 bits): The address type of the peer as defined in ICE [7]. 2904 One of host (0000), server reflexive (0001), peer reflexive 2905 (0010), or relayed candidate (0011). 2907 Port (16 bits): The port on which this peer listens for requests. 2909 Peer Address (variable): The IP address of the peer. Its length 2910 depends on the IP-Ver field. 2912 9.3.2. Unhashed-Id 2914 Unhashed ID: 2916 0 1 2 3 2917 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 2918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2919 // Unhashed-ID // 2920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2922 Unhashed-ID (variable): Unhashed-ID of a user, resource, or peer 2923 identifier. this peer. This is only included in a DHT-based 2924 overlay. 2926 9.3.3. Request-Options 2927 Type: Request-Options 2929 Length: Fixed (32-bit word) 2931 0 1 2 3 2932 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 2933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2934 |P|R|N|E|A|S|L| | 2935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2937 P (1 bit): If set (P=1), designate one copy as primary for parallel 2938 lookups. 2940 R (1 bit) request-routing-table: If set (R=1), send a copy of the 2941 routing table to the peer issuing the request either in a response 2942 or in a separate ExchangeTable request. The transmission of the 2943 routing-table copy is governed by the in-separate-request (E flag) 2944 and partial-copy (A flag) flags. 2946 N (1 bit) request-neighbor-table: If set (N=1), send a copy of the 2947 neighbor table to the peer issuing the request in a response or 2948 ExchangeTable request. The transmission of routing-table copy is 2949 governed by the in-separate-request and partial-copy flags. 2951 E (1 bit) in-separate-request: If set (E=1), and if R or N are also 2952 set, the peer is requesting to receive routing or neighbor table 2953 in an ExchangeTable request. If not set (E=0), and if R or N are 2954 also set, each peer along the request path can add a copy of its 2955 routing or neighbor table before forwarding the response. The 2956 number of entries in all routing-tables should not exceed 256. 2957 Peers along the request path may remove routing-table entries 2958 added by a previous hop, if their own routing-tables have a better 2959 performance metric (such as uptime) than the ones received in the 2960 message. The size of routing-table is likely to exceed UDP MTU. 2961 The specification recommends that the ExchangeTable request should 2962 always be sent over TCP. 2964 A (1 bit) partial-reply for routing or neighbor table: If set (A=1), 2965 the peer generating the definite response sends a copy of the 2966 routing or neighbor table as determined by the P and N flags in 2967 its response as permitted by the UDP MTU. If E (in-separate- 2968 request) is also set, the rest of the routing or neighbor table is 2969 sent in a separate ExchangeTable request. The number of entries 2970 in all neighbor-tables should not exceed 256. 2972 S (1 bit): If set (S=1), the request is being sent to the immediate 2973 neighbors of the newly joining peer. The request must be a join 2974 request. 2976 L (1 bit): If set (L=1), each peer along the request must add its 2977 peer-info object that includes peer-ID, address-info, and 2978 resource-list objects. 2980 9.3.4. P2P-Options 2982 Type: P2P-Options 2984 Length: Variable (depends on the length of Overlay-ID) 2986 0 1 2 3 2987 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 2988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2989 |Hash-Algorithm |H-Algorithm-Len| P2P-Algorithm | Base | 2990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2991 | OverlayID Len | Overlay-ID // 2992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2994 Hash-Algorithm (8 bits): An IANA-assigned identifier for the hash 2995 algorithm. 2997 H-Algorithm-Len (8 bits): The byte length of the hash algorithm. If 2998 set to zero, then no hash algorithm is used. 3000 P2P-Algorithm (8 bits): An IANA-assigned identifier for the P2P 3001 algorithm being used. 3003 Base: The base for hash algorithms. It is set to zero for 3004 unstructured overlays. 3006 OverlayID-Length (8 bits): The byte length of overlay-ID. 3008 Overlay-ID (variable): Overlay-ID. 3010 9.3.5. Routing-Table 3012 Type: Routing-Table 3014 Length: Variable (depends on the number of Peer-Info objects) 3015 0 1 2 3 3016 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 3017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3018 | Num entries | | 3019 +-+-+-+-+-+-+-+-+ [Peer-Info]+ + 3020 // // 3021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3023 Num-entries (8 bits): Number of Peer-Info objects in the routing 3024 table. 3026 Peer-Info (variable): One or more Peer-Info objects. 3028 9.3.6. Neighbor-table 3030 Type: Neighbor-Table 3032 Length: Variable (depends on the number of Peer-Info objects) 3034 0 1 2 3 3035 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 3036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3037 | Num entries | | 3038 +-+-+-+-+-+-+-+-+ [Peer-Info]+ + 3039 // // 3040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3042 Num-entries (8 bits): Number of Peer-Info objects in the neighbor 3043 table. 3045 Peer-Info (variable): One or more Peer-Info objects. 3047 9.3.7. PLookup 3049 Type: PLookup 3051 Length: Variable (depends on the length of Peer-ID and whether this 3052 is a range lookup) 3054 0 1 2 3 3055 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 3056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3057 | Num |E|R| Peer-IDa // 3058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3059 // Peer-IDb // 3060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3062 Num (6 bits): Number of peers to look for. 3064 E (1 bit): If set (E=1), then search for a peer whose peer-ID is the 3065 same as peer-IDa. Otherwise, return up to Num peers whose ID is 3066 'closest' to Peer-IDa 3068 R (1 bit): If set (R=1), then it is a range lookup. It is only set, 3069 if E is not set. 3071 Peer-IDa (variable): Peer-ID. The length of Peer-ID is determined 3072 at join. 3074 Peer-IDb (variable): Peer-ID. The length of Peer-ID is determined 3075 at join. 3077 9.3.8. Resource-ID 3079 Resource-ID: 3081 0 1 2 3 3082 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 3083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3084 // Resource-ID // 3085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3087 Resource-ID (variable): It is an identifier of the resource. For 3088 DHTs, it is a fixed-length output of a hash function. For 3089 unstructured networks, its length is variable. 3091 9.3.9. RLookup 3093 Type: Resource-Object 3095 Length: Variable (depends on the size of resource-object) 3096 0 1 2 3 3097 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 3098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3099 | Cont-type | Sub-Type | Resource-ID // 3100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3101 | Additional Information | 3102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3104 Cont-type: An IANA assigned identifier for the type of content 3105 contained in this resource-object. 3107 Sub-type: An IANA assigned identifier which further classifies the 3108 content type as defined by cont-type. 3110 Resource-ID (variable): The Resource-ID TLV of the resource object. 3112 Additional Information: Owner 3114 9.3.10. Resource-Object 3116 Type: Resource-Object 3118 Length: Variable (depends on the size of resource-object) 3120 0 1 2 3 3121 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 3122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3123 | Cont-type | Sub-Type | Resource-ID // 3124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3125 // Resource-Object-Value // 3126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3127 | Additional Information | 3128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3130 Cont-type: An IANA assigned identifier for the type of content 3131 contained in this resource-object. 3133 Sub-type: An IANA assigned identifier which further classifies the 3134 content type as defined by cont-type. 3136 Resource-ID (variable): The Resource-ID TLV of the resource object. 3138 Resource-Object-Value (variable): Variable length. Its value 3139 depends on the content-type and sub-type. 3141 9.3.10.1. Additional Information Fields 3143 The resource-object may use the following TLVs to express additional 3144 information about itself. 3146 Owner (variable): The owner TLV object. 3148 Expires (fixed): The expires TLV object. 3150 Signature (Variable): The cryptographic signature of the resource- 3151 object. 3153 X509 (fixed): The X509 certificate of the peer publishing the 3154 resource-object. 3156 9.3.11. Expires 3158 Type: Expires 3160 Length: Fixed (32-bit word) 3162 0 1 2 3 3163 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 3164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3165 | Expire time in seconds | 3166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3168 Expires (32 bits): Time in seconds 3170 9.3.12. Owner 3172 Type: Owner 3174 Length: Variable 3176 0 1 2 3 3177 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 3178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3179 // Owner // 3180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3182 Owner (variable): The owner of the Resource-Object. Format TBD. 3184 9.3.13. Certificate 3186 An X.509 certificate. 3188 Type: Certificate 3190 Sub-Type: Self-Signed (0x00), Server-Signed (0x01). 3192 Length: Variable. Depends on the size of X.509 certificate. 3194 0 1 2 3 3195 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 3196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3197 // Certificate // 3198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3200 Certificate (variable): The length of X.509 certificate. 3202 9.3.14. Signature 3204 The signature of the resource-object. 3206 Type: Signature 3208 Length: Variable. Depends on the type of signature algorithm being 3209 used. 3211 0 1 2 3 3212 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 3213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3214 // Signature // 3215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3217 Signature (variable): The signature length of resource-object. 3219 9.3.15. Capabilities and Diagnostics 3221 Time Window: 3223 0 1 2 3 3224 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 3225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3226 | Time Window | 3227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3228 Time Window (32 bits): The elapsed time in seconds since the 3229 gathering of message statistics. This can be included as part of 3230 every diagnostic TLV. 3232 AS Number: 3234 0 1 2 3 3235 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 3236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3237 | Autonomous System Number | 3238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3240 Autonomous System Number (32 bits): The autonomous system of node's 3241 IP address, if available. 3243 Connections: 3245 0 1 2 3 3246 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 3247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3248 | Number of Neighbor Peers | Number of Routing Peers | 3249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3250 | Number of clients | 3251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3253 Number of Neighbor Peers (16 bits): The number of neighbor peers of 3254 this peer. 3256 Number of Routing Peers (16 bits): The number of routing peers of 3257 this peer. 3259 Number of Clients (16 bits): The number of clients connected with 3260 this peer. 3262 Node-Resource-Utilization: 3264 0 1 2 3 3265 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 3266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3267 | Peer bandwidth | 3268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3269 | CPU Util. | BW. Util. | 3270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3271 Peer Bandwidth (32 bits): Estimated peer bandwidth in kilo bits per 3272 second. This is tricky to determine and is TBD. 3274 CPU Utilization (8 bits): CPU Utilization of this peer on a scale of 3275 1 to 100. Represent the percentage of CPU being used. If should 3276 be an average over the last five seconds. 3278 Bandwidth Utilization (8 bits): Bandwidth utilization of this peer 3279 on a scale of 1 to 100. Represent the percentage of bandwidth 3280 being used. It should be an average over the last five seconds. 3282 Messages-Received: 3284 0 1 2 3 3285 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 3286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3287 | Msg Type | Number of messages | 3288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3289 | ...... | 3290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3292 Msg Type (8 bits): The message types as defined in Section 13. The 3293 number 254 is reserved for responses and 255 for ACKs. 3295 Number of messages (24 bits): The number of messages received for 3296 the 'msg type' since the elapsed time. 3298 9.4. Response Codes and Errors 3300 9.4.1. Response Codes 3302 There are four different types of response codes. They are no 3303 provisional response codes. The description is given below: 3305 2xx (Success): Response data which indicates that the request has 3306 been processed successfully in some sense. 3308 3xx (Redirect): Response data which indicates that the request 3309 should be redirected. 3311 4xx (Request Failure): Response data which indicates that the 3312 request has failed. 3314 9.4.1.1. 2xx (Successful) Responses 3315 200 Ok. A successful answer to the request. 3317 9.4.1.2. 3xx (Redirect) Responses 3319 302 Next Hop. This response is only generated for iterative 3320 requests if the peer receiving the request is not the final 3321 destination for the request. 3323 9.4.1.3. 4xx-511 (Permanent-Failure) Responses 3325 400 Bad request. There was an error parsing the request. 3327 404 Not found. This response is generated for a lookup request if 3328 the resource-object being searched for is not found. 3330 405 Error inserting object. There was an error inserting the 3331 resource-object. 3333 406 Request rejected. The request was understood but rejected by 3334 the peer. 3336 407 Join request deferred. The peer issuing the join request should 3337 retry after a certain time. 3339 410 TTL hops The number of TTL hops exceeded. 3341 413 Message too large. The response message size was too large. 3342 This response is typically generated for unreliable transports. 3344 418 Timeout. The request timed out. This response is generated when 3345 request was forwarded in a recursive manner over UDP and no 3346 response was received. 3348 9.4.2. Error Object 3350 TBD. 3352 10. Application Layer 3354 An application using peer-to-peer protocol issues non-blocking calls 3355 to P2PP layer to accomplish operations, namely, join, leave, publish, 3356 lookup, remove, and query. Since an operation may take long time to 3357 complete, an application supplies a call-back function for each API, 3358 not shown in the parameters. The 'in' parameters are passed to P2PP 3359 in the API call, whereas the 'out' parameters are returned in the 3360 call-back function after the operation is complete. Upon success, 3361 the call-back function returns a value of zero. 3363 10.1. Query 3365 Query([out]Overlay-ID, [out]P2P-Algorithm, [out]Hash-Algorithm, 3366 [out]Hash-Algorithm-Len, [in]Overlay-peer-network-address, 3367 [in]Overlay-peer-port) 3369 10.2. Join 3371 Join([in]Overlay-ID, [in]Overlay-peer-network-address, [in]Overlay- 3372 peer-port) 3374 An application uses this API to inform the P2PP layer to start the 3375 join process. 3377 10.3. Leave 3379 Leave([in]Overlay-ID) 3381 An application uses this API to inform the P2PP layer that it wishes 3382 to leave the overlay immediately. An application does not wait for 3383 this operation to be completed and may shut down immediately. 3385 10.4. Publish 3387 Publish([in]Resource-ID, [in]Resource-Object) 3389 An application uses this API to publish a new resource-object in the 3390 overlay or update an existing one. 3392 10.5. Remove 3394 Remove([in]Resource-ID) 3396 An application uses this API to explicitly remove a resource-object 3397 from the overlay. 3399 10.6. Lookup 3401 Lookup([in]Resource-ID, [out]Resource-Object) 3403 An application uses this API to search for a resource-object in the 3404 overlay. If the resource-object is found, it is returned in the API 3405 call. 3407 (Open Issue: Each operation should have a crypto-signed counterpart.) 3409 11. Open Issues 3411 1. Mandatory DHT: P2PP supports bamboo but elaborate. 3413 2. SIP record insertion and lookup. 3415 3. ICE overhead analysis for recursive and iterative routing and in 3416 the presence of churn. 3418 4. Redirecting media relaying requests. 3420 5. Overlay migration. 3422 6. Reactive vs. periodic maintenance. 3424 7. How can a node estimate its CPU and bandwidth utilization? 3426 8. Non-SIP usage of P2PP 3428 9. Secure protocol for iterative routing. 3430 10. HTTP authentication. 3432 12. Acknowledgements 3434 The authors will like to thank the following (in alphabetical order) 3435 for their helpful comments and suggestions. Christian Schmidt, 3436 Christian Dickmann, Miguel Garcia, Jae W. Lee, Esko Kokkonen, Kundan 3437 Singh, Henry Sinnreich, Eunsoo Shim and Marc Willekens. 3439 13. IANA Considerations 3441 Listening Port: The port on which a peer listens for request. The 3442 current implementation uses 7080 for UDP and TCP and 7081 for DTLS 3443 and TLS. 3445 Message Types: The P2PP common header contains a one byte message 3446 type field. A message can either be a request or a response. The 3447 following values are allocated by this specification for request 3448 and indication messages. 3450 +--------------+----------------+ 3451 | Message Type | Message | 3452 +--------------+----------------+ 3453 | 0 | Enroll | 3454 | | | 3455 | 1 | Authenticate | 3456 | | | 3457 | 2 | Bootstrap | 3458 | | | 3459 | 3 | Join | 3460 | | | 3461 | 4 | Leave | 3462 | | | 3463 | 5 | KeepAlive | 3464 | | | 3465 | 6 | LookupPeer | 3466 | | | 3467 | 7 | ExchangeTable | 3468 | | | 3469 | 8 | Query | 3470 | | | 3471 | 9 | Publish | 3472 | | | 3473 | 10 | LookupObject | 3474 | | | 3475 | 11 | RemoveObject | 3476 | | | 3477 | 12 | Replicate | 3478 | | | 3479 | 13 | Transfer | 3480 | | | 3481 | 14 | Tunnel | 3482 | | | 3483 | 15 | Connect | 3484 | | | 3485 | 16 | GetDiagnostics | 3486 +--------------+----------------+ 3488 Object Types: There is a one byte field in the object header. The 3489 following values for object types are defined by this 3490 specification. 3492 +-------+-----------------------------+ 3493 | OType | Object Type | 3494 +-------+-----------------------------+ 3495 | 0 | Peer-Info | 3496 | | | 3497 | 1 | Peer-ID | 3498 | | | 3499 | 2 | Address-Info | 3500 | | | 3501 | 3 | Unhashed-ID | 3502 | | | 3503 | 4 | Uptime | 3504 | | | 3505 | 5 | P2P-Options | 3506 | | | 3507 | 6 | Request-Options | 3508 | | | 3509 | 7 | Diagnostic-Options | 3510 | | | 3511 | 8 | Routing-Table | 3512 | | | 3513 | 9 | Neighbor-Table | 3514 | | | 3515 | 10 | PLookup | 3516 | | | 3517 | 11 | Resource-ID | 3518 | | | 3519 | 12 | RLookup | 3520 | | | 3521 | 13 | Resource-Object | 3522 | | | 3523 | 14 | Expires | 3524 | | | 3525 | 15 | Owner | 3526 | | | 3527 | 16 | Certificate-Signing-Request | 3528 | | | 3529 | 17 | X.509-Cer7-Signature | 3530 | | | 3531 | 19 | Time-Window | 3532 | | | 3533 | 20 | Connections | 3534 | | | 3535 | 21 | Node-Resource-Utilization | 3536 | 22 | Messages-Received | 3537 | | | 3538 | 23 | AS-Number | 3539 | | | 3540 | 24 | Error | 3541 +-------+-----------------------------+ 3543 Algorithm: There is a one byte algorithm field in the P2P-options 3544 object which defines the hash function being used. The following 3545 values are allocated by this specification for this field. 3547 +-------+-----------+ 3548 | AType | Algorithm | 3549 +-------+-----------+ 3550 | 0 | None | 3551 | | | 3552 | 1 | SHA1 | 3553 | | | 3554 | 2 | SHA-256 | 3555 | | | 3556 | 3 | SHA-512 | 3557 | | | 3558 | 4 | MD4 | 3559 | | | 3560 | 5 | MD5 | 3561 +-------+-----------+ 3563 Algorithm: There is a one byte P2P-algorithm field in the P2P- 3564 options object which defines the p2p algorithm being used. The 3565 following values are allocated by this specification for this 3566 field. 3568 +-------+---------------+ 3569 | PType | P2P-Algorithm | 3570 +-------+---------------+ 3571 | 0 | Chord | 3572 | | | 3573 | 1 | CAN | 3574 | | | 3575 | 2 | Kademlia | 3576 | | | 3577 | 3 | Pastry | 3578 | | | 3579 | 4 | Bamboo | 3580 | | | 3581 | 5 | Tapestry | 3582 | | | 3583 | 6 | Accordion | 3584 | | | 3585 | 7 | SkipNet | 3586 | | | 3587 | 8 | Mercury | 3588 | | | 3589 | 9 | Gia | 3590 +-------+---------------+ 3592 Cont-Type: This is a one-byte field in the Resource-Info object 3593 which defines the content-type of the object. The following types 3594 are currently defined. 3596 +-----------+---------------+ 3597 | Cont-Type | Description | 3598 +-----------+---------------+ 3599 | 0 | User-Info | 3600 | | | 3601 | 1 | STUN | 3602 | | | 3603 | 2 | TURN | 3604 | | | 3605 | 3 | STUN+TURN+ICE | 3606 +-----------+---------------+ 3608 Component-ID: The component ID as defined by ICE. 3610 +--------------+-------------+ 3611 | Component-ID | Description | 3612 +--------------+-------------+ 3613 | 0 | RTP | 3614 | | | 3615 | 1 | RTCP | 3616 | | | 3617 | 2 | SIP | 3618 | | | 3619 | 2 | P2PP | 3620 +--------------+-------------+ 3622 14. References 3624 14.1. Normative References 3626 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3627 Levels", BCP 14, RFC 2119, March 1997. 3629 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 3630 Petersen, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 3631 Session Initiation Protocol", RFC 3261, June 2002. 3633 [3] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of 3634 Extensions to the Session Initiation Protocol (SIP)", RFC 4485, 3635 May 2006. 3637 [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax 3638 Specifications:ABNF", RFC 4234, October 2005. 3640 [5] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Simple 3641 Traversal Underneath Network Address Translators (NAT) (STUN)", 3642 draft-ietf-behave-rfc3489bis-13 (work in progress), 3643 November 2007. 3645 [6] Rosenberg, J., Mahy, R., and C. Huitema, "Obtaining Relay 3646 Addresses from Simple Traversal Underneath NAT (STUN)", 3647 draft-ietf-behave-turn-05 (work in progress), November 2007. 3649 [7] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 3650 Methodology for Network Address Translator (NAT) Traversal for 3651 Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in 3652 progress), October 2007. 3654 14.2. Informative References 3656 [8] Willis, D., Bryan, D., Matthews, P., and E. Shim, "Concepts and 3657 Terminology for Peer-to-Peer SIP", 3658 draft-ietf-p2psip-concepts-01 (work in progress), 3659 November 2007. 3661 [9] Bryan, D., Lowekamp, B., and C. Jennings, "dSIP: A P2P Approach 3662 to SIP Registration and Resource Location", 3663 draft-bryan-p2psip-dsip-00 (work in progress), February 2007. 3665 [10] Rhea, S., Godfrey, B., Karp, B., Kubiatowicz, J., Ratnasamy, 3666 S., Shenker, S., Stoica, I., and H. Yu, "OpenDHT: A Public DHT 3667 Service and its Uses", SIGCOMM '05:Proceedings of the 2005 3668 conference on Applications, technologies, architectures, and 3669 protocols for computer communications. Philadelphia, PA, 3670 pp. 73-84, 2005. 3672 [11] Pugh, W., "Skip Lists: A Probabilistic Alternative to Balanced 3673 Trees", Workshop on Algorithms and Data Structures. pp. 437- 3674 449, 1989. 3676 [12] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D., Kaashoek, 3677 M., Dabek, F., and H. Balakrishnan, "Chord: A Scalable Peer-to- 3678 peer Lookup Service for Internet Applications", IEEE/ACM 3679 Transactions on Networking, vol. 11, no. 1, pp. 17-32, 2003. 3681 [13] Ratmasamy, S., Francis, P., Handley, M., Karp, R., and S. 3682 Shenker, "A Scalable Content-Addressable Network", SIGCOMM '01: 3683 Proceedings of the 2001 conference on Applications, 3684 technologies, architectures, and protocols for computer 3685 communications. San Diego, CA, pp. 161-172, August 2001. 3687 [14] Rowstron, A. and P. Druschel, "Pastry: Scalable, distributed 3688 object location and routing for large-scale peer-to-peer 3689 systems", Proceedings of the 18th IFIP/ACM International 3690 Conference on Distributed Systems Platforms (Middleware 2001), 3691 March 2002. 3693 [15] Maymounkov, P. and D. Mazieres, "Kademlia: A Peer-to-Peer 3694 Information System Based on the XOR Metric", IPTPS'01: Revised 3695 Papers from the First International Workshop on Peer-to-Peer 3696 Systems London, UK, pp. 53-65, March 2002. 3698 [16] Karger, D., Lehman, E., Leighton, T., Panigraphy, R., Levine, 3699 F., and D. Lewin, "Consistent hashing and random trees: 3700 distributed caching protocols for relieving hot spots on the 3701 World Wide Web", STOC '97: Proceedings of the twenty-ninth 3702 annual ACM symposium on Theory of computing , 1997. 3704 [17] Balakrishnan, H., Kaashoek, F., Karger, D., Morris, R., and I. 3705 Stoica, "Looking up data in P2P systems", Communications of the 3706 ACM, vol. 46, no. 2, pp. 43-48, 2003. 3708 [18] Dabek, F., Zhao, B., Druschel, P., Kubiatowicz, J., and I. 3709 Stoica, "Towards a Common API for Structured Peer-to-Peer 3710 Overlays", IPTPS'03: Proceedings of the 2nd International 3711 Workshop on Peer-to-Peer Systems. Berkeley, California, 3712 February 2003. 3714 [19] Chawathe, Y., Ratnasamy, S., Breslau, L., Lanham, N., Kaashoek, 3715 M., and S. Shenker, "Making gnutella-like p2p systems 3716 scalable", SIGCOMM '03: Proceedings of the 2003 conference on 3717 Applications, technologies, architectures, and protocols for 3718 computer communications. New York, NY, USA, pp. 407-418, 2003. 3720 [20] Li, J., Stribling, J., Morris, R., and M. Kaashoek, "Bandwidth- 3721 efficient management of DHT routing tables", in Proceedings of 3722 the 2nd USENIX Symposium on Networked Systems Design and 3723 Implementation (NSDI '05). Boston, MA, USA, 2005. 3725 [21] Cooper, E., Johnston, A., and P. Matthews, "Bootstrap 3726 Mechanisms for P2PSIP", 3727 draft-matthews-p2psip-bootstrap-mechanisms-00 (work in 3728 progress), February 2007. 3730 [22] Rhea, S., Geels, D., Roscoe, T., and J. Kubiatowicz, "Handling 3731 Churn in a DHT", Proceedings of the 2004 USENIX Annual 3732 Technical Conference (USENIX '04) Boston, Massachusetts, 3733 June 2004. 3735 [23] Docuer, J., "The Sybil Attack", IPTPS '02 , March 2002. 3737 [24] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery Using 3738 STUN", draft-ietf-behave-nat-behavior-discovery-01 (work in 3739 progress), June 2007. 3741 [25] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 3742 Peer(P2P) Communication Across Network Address 3743 Translators(NATs)", draft-srisuresh-behave-p2p-state-04, 3744 September 2006. 3746 Appendix A. Background 3747 Appendix B. Message Flow 3748 Authors' Addresses 3750 Salman A. Baset 3751 Dept. of Computer Science 3752 Columbia University 3753 1214 Amsterdam Avenue 3754 New York, NY 10027 3755 USA 3757 Email: salman@cs.columbia.edu 3759 Henning Schulzrinne 3760 Dept. of Computer Science 3761 Columbia University 3762 1214 Amsterdam Avenue 3763 New York, NY 10027 3764 USA 3766 Email: hgs@cs.columbia.edu 3768 Marcin Matuszewski 3769 Nokia 3770 Helsinki, 3771 Finland 3773 Email: marcin.matuszewski@nokia.com 3775 Full Copyright Statement 3777 Copyright (C) The IETF Trust (2007). 3779 This document is subject to the rights, licenses and restrictions 3780 contained in BCP 78, and except as set forth therein, the authors 3781 retain all their rights. 3783 This document and the information contained herein are provided on an 3784 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3785 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3786 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3787 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3788 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3789 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3791 Intellectual Property 3793 The IETF takes no position regarding the validity or scope of any 3794 Intellectual Property Rights or other rights that might be claimed to 3795 pertain to the implementation or use of the technology described in 3796 this document or the extent to which any license under such rights 3797 might or might not be available; nor does it represent that it has 3798 made any independent effort to identify any such rights. Information 3799 on the procedures with respect to rights in RFC documents can be 3800 found in BCP 78 and BCP 79. 3802 Copies of IPR disclosures made to the IETF Secretariat and any 3803 assurances of licenses to be made available, or the result of an 3804 attempt made to obtain a general license or permission for the use of 3805 such proprietary rights by implementers or users of this 3806 specification can be obtained from the IETF on-line IPR repository at 3807 http://www.ietf.org/ipr. 3809 The IETF invites any interested party to bring to its attention any 3810 copyrights, patents or patent applications, or other proprietary 3811 rights that may cover technology that may be required to implement 3812 this standard. Please address the information to the IETF at 3813 ietf-ipr@ietf.org. 3815 Acknowledgment 3817 Funding for the RFC Editor function is provided by the IETF 3818 Administrative Support Activity (IASA).