P2PSIP Working Group I. Baumgart Internet-Draft Institute of Telematics, Intended status: Standards Track Universitaet Karlsruhe (TH) Expires: May 12, 2008 November 9, 2007 Peer-to-Peer Name Service (P2PNS) draft-baumgart-p2psip-p2pns-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 12, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes P2PNS, a secure distributed name service for P2PSIP. P2PNS can be used to resolve SIP AoRs to Contact URIs without using DNS or central SIP servers. P2PNS provides several security mechanisms to efficiently prevent identity theft and to ensure the uniqueness of SIP AoRs in a completely decentralized and untrusted network without login servers. The proposed proxy architecture allows a seamless integration of legacy SIP UAs, avoids modifications to the complex SIP protocol stack and facilitates the Baumgart Expires May 12, 2008 [Page 1] Internet-Draft Peer-to-Peer Name Service (P2PNS) November 2007 deployment of P2PSIP networks. Because P2PNS provides a generic name service it is not limited to P2PSIP but can also be used e.g. to build a distributed DNS system. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Structured Peer-to-Peer Networks . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Goals for P2PNS . . . . . . . . . . . . . . . . . . . . . . . 5 5. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. P2PNS Architecture . . . . . . . . . . . . . . . . . . . . 5 5.2. P2PNS Name Resolution . . . . . . . . . . . . . . . . . . 6 5.2.1. Two-stage Name Resolution . . . . . . . . . . . . . . 6 5.2.2. Direct Name Resolution . . . . . . . . . . . . . . . . 7 5.2.3. P2PNS Cache . . . . . . . . . . . . . . . . . . . . . 7 5.3. KBR Design . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3.1. KBR Security . . . . . . . . . . . . . . . . . . . . . 7 5.3.1.1. Secure NodeID Assignment . . . . . . . . . . . . . 8 5.3.1.2. Lookup over Disjoint Paths . . . . . . . . . . . . 8 5.3.1.3. Secure Routing Table Maintenance . . . . . . . . . 9 5.4. DHT Design . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4.1. DHT Security . . . . . . . . . . . . . . . . . . . . . 9 6. Service Discovery . . . . . . . . . . . . . . . . . . . . . . 11 7. P2PNS Interface . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.2. RESOLVE . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. P2PNS Usage . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. P2PSIP . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.2. Distributed DNS . . . . . . . . . . . . . . . . . . . . . 15 8.3. Zeroconf Service Discovery . . . . . . . . . . . . . . . . 15 8.4. HIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.5. Jabber / XMPP . . . . . . . . . . . . . . . . . . . . . . 16 9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 16 10. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 16 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 14. Security Considerations . . . . . . . . . . . . . . . . . . . 17 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 15.1. Normative References . . . . . . . . . . . . . . . . . . . 17 15.2. Informative References . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Baumgart Expires May 12, 2008 [Page 2] Internet-Draft Peer-to-Peer Name Service (P2PNS) November 2007 1. Introduction An emerging use case for peer-to-peer protocols are decentralized VoIP networks. The IETF P2PSIP working group has been formed to develop protocols for using the Session Initiation Protocol (SIP) [1] in networks without centralized servers. These decentralized VoIP networks can e.g. be used as failover for traditional server-based SIP networks in emergency cases. In traditional SIP networks the main task of a SIP server is to resolve an Address of Record (AoR) to the current IP address (Contact URI) of a user. This name resolution usually depends on DNS. In this paper we present a distributed name service using a DHT to resolve AoRs to Contact URIs without relying on DNS and central SIP servers. Apart from this decentralized name resolution the call setup is based on the standard SIP protocol. The benefit of this approach is that we can easily connect legacy SIP phones to our P2PSIP network. This connection is accomplished by a SIP proxy located between SIP phone and DHT which handles the name resolution. Currently there are several other P2PSIP proposals like RELOAD [3] and P2PP [4] which are similar to our P2PNS approach. We therefore focus on two aspects in this document which we think have been neglected by similar proposals. The first aspect is flexibility: P2PNS is a generic name service and not limited to P2PSIP. Other applications for P2PNS are e.g. decentralized DNS [5], decentralized XMPP [6] or decentralized HIP [7]. In P2PNS there is a clear separation between the overlay layer (key-based routing), the data storage layer (distributed hash table), the name resolution layer (P2PNS Cache) and the protocols, that utilize the name service (like SIP or DNS). In this architecture the specification of the key-based routing protocol is independent from P2PSIP and KBR protocol implementations can therefore easily be reused for other peer-to-peer applications. The second aspect is security: We propose several security mechanisms to provide a high level of security in a completely decentralized network without login severs. In particular P2PNS provides mechanisms to guarantee the uniqueness of P2PNames and to prevent identity theft. These security mechanisms are based on a cryptographically generated nodeID, which is used to authenticate overlay nodes. 2. Background Baumgart Expires May 12, 2008 [Page 3] Internet-Draft Peer-to-Peer Name Service (P2PNS) November 2007 2.1. Structured Peer-to-Peer Networks In this section we provide some background on structured peer-to-peer networks. A common service which is provided by all structured peer- to-peer networks is the key-based routing layer (KBR) [8]. This layer provides efficient routing to identifiers called keys from a large identifier space. Every participating node in the overlay chooses a unique nodeID from the same id space and maintains a routing table with nodeIDs and IP addresses of neighbors in the overlay topology. Every node is responsible for a particular range in the identifier space, usually for all keys close to its nodeID in the id space. The KBR layer provides a route() method to efficiently route a message to an arbitrary key by successively forwarding the message to overlay neighbors which have a nodeID closer to the destination key. For P2PNS we propose to use the Kademlia [9] protocol as KBR layer, although our findings can also be applied to other KBR protocols. On top of the KBR we use a distributed hash table (DHT), which is a distributed storage service for storing (key, value) data records. The DHT layer provides the two methods get(key) and put(key, value). The node responsible for storing a data record with a specific key is discovered by using the route() method of the underlying KBR layer. 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. Terminology defined in RFC 3261 [1] and the Concepts and Terminology for Peer-to-Peer SIP [10] draft is used without definition. DHT: Distributed hash table as defined in [8]. KBR: Key-based routing layer as defined in [8]. Node: An instance of an participant in the overlay. NodeID: A unique 160 bit identifier used to address nodes in the overlay. In Concepts and Terminology for Peer-to-Peer SIP [10] this is called Peer-ID. P2PName: An arbitrary string which can be resolved to a Transport Address by using P2PNS. Baumgart Expires May 12, 2008 [Page 4] Internet-Draft Peer-to-Peer Name Service (P2PNS) November 2007 ServiceName: An well-known name for a service which can be resolved to the Transport Address of a node offering this service. Transport Address: The IP address and port used to address a node. 4. Goals for P2PNS The name service P2PNS should fulfill the following requirements: o The name service should not be limited to P2PSIP, but also support e.g. distributed DNS. Therefore the name service should be independent from the SIP protocol. o The P2PNS architecture should be completely decentralized. In particular it should not depend on any central login servers or other trustworthy authorities. o The user should be able to choose an arbitrary P2PName. o P2PNS should provide mechanisms to guarantee the uniqueness of P2PNames and prevent identity theft. o For P2PSIP applications P2PNS should support unmodified legacy SIP UAs and provide gateway functionality between P2PSIP and server- based SIP networks. 5. Design Overview In this section we describe our P2PNS architecture and several security extensions for the KBR and DHT layer. 5.1. P2PNS Architecture The P2PNS architecture comprises a name resolution and caching layer (P2PNS Cache) on top of an external overlay which provides KBR and DHT services. The KBR service can be provided by any structured peer-to-peer protocol which provides a Common API [8] interface and contains the security extensions from Section 5.3.1. Applications like a SIP proxy connect to P2PNS by using a XML-RPC interface which provides register() and resolve() functions. The P2PNS architecture is shown in the following figure. Baumgart Expires May 12, 2008 [Page 5] Internet-Draft Peer-to-Peer Name Service (P2PNS) November 2007 +-------------+ +---------------------------------------+ | P2PNS Cache |<----------->| Application (SIP proxy, DNS Resolver) | +-------------+ register() +---------------------------------------+ ^ ^ resolve() | put() | | get() | v | +-----+ | | DHT | | +-----+ | | | | join() | | route() | | lookup()| v v +-------------+ | KBR | +-------------+ 5.2. P2PNS Name Resolution P2PNS offers two alternatives for resolving a P2PName to the current transport address: 5.2.1. Two-stage Name Resolution The preferred alternative is to use a two-stage approach to resolve a P2PName to the current transport address. For this purpose every peer chooses once a 160 bit nodeID for joining the overlay. This nodeID is retained even if the peer changes its IP address or leaves the overlay from time to time. The KBR layer allows us to efficiently resolve the nodeID to the current IP address of a peer by using the lookup() or route() methods. By choosing the nodeID as P2PName the name resolution layer could therefore use the KBR service to resolve a P2PName without using a DHT. Because using the nodeID as P2PName is against the requirement of letting the user choose an arbitrary string as P2PName we additionally store a mapping from the arbitrary P2PName to the corresponding nodeID in the DHT. In this case the name resolution layer first queries the DHT for the nodeID of the destination node and in a second step resolves this nodeID to the node's current IP address. If the user wants to register a transport address different from the node's current IP address this mapping is stored locally at the destination node. In this case the name resolution process involves the lookup of this mapping at the destination node as the final step. Baumgart Expires May 12, 2008 [Page 6] Internet-Draft Peer-to-Peer Name Service (P2PNS) November 2007 5.2.2. Direct Name Resolution Instead of using the two-stage name resolution approach, it is also possible to directly store a P2PName to transport address mapping in the DHT. But due to the proposed security mechanisms in Section 5.4.1 storing and modifying data records in the DHT is very bandwidth consuming, because data records are replicated on several nodes. However by using the two-stage approach it is not necessary to modify data records, because the P2PName to nodeID mapping doesn't change. So an IP address change has an effect on the KBR layer only, which can be handled very efficiently. 5.2.3. P2PNS Cache To reduce communication overhead and lookup latency when resolving the same P2PName several times, the static P2PName to nodeID mappings are cached locally. The nodeID to transport address mapping may also be cached. Because this mapping can be outdated, it has to be verified. This is done by trying to directly contact the destination node using the stored destination transport address. If this verification fails, the mapping is refreshed by using the KBR lookup() method. 5.3. KBR Design The current P2PNS implementation uses Kademlia [9] as KBR protocol, although the P2PNS approach is not limited to a specific KBR protocol. Kademlia was chosen, because it is simple to implement, is already insusceptible to several common attacks and is the only widely deployed structured overlay network in the Internet today (i.e. BitTorrent, OverNet and eMule). The specification of a KBR protocol is out of scope of this document. Instead we propose to use the P2PP proposal [4] and extend it by the following security extensions. 5.3.1. KBR Security The security of the P2PNS architecture largely depends on the security of the KBR layer. As shown in [11] KBR protocols have to fulfill three requirements to provide a high level of security. On the basis of these requirements we decided to use Kademlia as KBR protocol and extended it by several security enhancements (S/Kademlia [12]). In the following these requirements and security enhancements are summarized: Baumgart Expires May 12, 2008 [Page 7] Internet-Draft Peer-to-Peer Name Service (P2PNS) November 2007 5.3.1.1. Secure NodeID Assignment Most important it should be hard for an attacker to generate a large number of nodeIDs (Sybil attack) or to choose a particular nodeID freely (Eclipse attack). In P2PNS every node generates a 224 bit ECDSA [13] public key pair and calculates its nodeID by applying a cryptographic hash function H(x) on its public key k_pub. The current implementation uses the SHA-1 [14] hash function. To impede the generation of a large number of nodeIDs we additionally make use of crypto puzzles. A simple crypto puzzle is given below: 1. Generate a new public key pair (k_priv, k_pub). 2. Calculate H(H(k_pub)) and check, if the first c bit are 0. 3. If the condition in step 2 is not true, repeat step 1. Otherwise the crypto puzzle is solved and the nodeID is H(k_pub). This approach has several benefits compared to the usual approach to generate the nodeID by applying a hash function on the IP address of the node. First the node may keep the nodeID if the IP address changes. Furthermore the public key approach can be used in networks with NAT (Network Address Translation), in which several nodes share the same public IP address. The public key pair (k_priv, k_pub) is used in the following to authenticate overlay signaling. For this purpose overlay messages are signed with k_priv. In this way the receiving node may use the public key k_pub attached to the message to verify the authorship. To provide a higher level of security the nodeID assignment can additionally be restricted by using certificates of an offline CA. 5.3.1.2. Lookup over Disjoint Paths As second requirement the overlay should provide several disjoint and preferably short paths to all destination keys to successfully deliver messages in presence of malicious nodes. The number of disjoint paths depends particularly on the employed overlay topology (e.g. ring, hypercube or de Bruijn graph). The Kademlia protocol is based on a hypercube topology and provides the bucket size parameter k, which can be used to tune routing table redundancy to the required level of security. We studied the influence of disjoint paths on lookup success in a network with malicious nodes by using the OverSim framework. The simulation results [12] for Kademlia showed a significant increase in lookup success by using several disjoint paths. Baumgart Expires May 12, 2008 [Page 8] Internet-Draft Peer-to-Peer Name Service (P2PNS) November 2007 Most overlay protocols can be used with recursive as well as iterative routing. In P2PNS iterative routing is used to ensure the resulting paths are really disjoint. Furthermore with iterative routing the originator of the lookup can constantly monitor the lookup progress. Yet iterative routing exhibits the disadvantage of roughly doubling the time for a lookup to finish in comparison to recursive routing. 5.3.1.3. Secure Routing Table Maintenance An important security property of KBR protocols is the robustness of the signaling protocol for routing table maintenance in the presence of malicious nodes. As long as the nodeID selection is limited, Kademlia is very robust against adversarial routing table manipulations due to is implicit stabilization by incoming lookup requests. Because Kademlia uses a least-recently-used replacement strategy for routing table updates, new nodes are only added if older nodes fail. Therefore Kademlia is not vulnerable to the flooding of bogus routing updates once the network is bootstrapped. 5.4. DHT Design The DHT layer is a distributed storage service for storing (key, value) data records. The DHT layer provides the two methods get(key) and put(key, value) to the upper layer. The nodes responsible for storing a data record with a specific key are discovered by using the route() or lookup() method of the underlying KBR layer. 5.4.1. DHT Security The proposed security mechanisms in Section 5.3.1 are the basis for providing a secure DHT service. Yet the DHT layer has to fulfill additional requirements to secure the stored P2PName to nodeID mappings: o Data records may only be deleted or modified by the owner of the record. o Data records should be replicated on several nodes to inhibit manipulation by single malicious nodes. o The DHT should be secure against insertion DoS attacks. In order to prevent the unauthorized modification of data records the DHT layer additionally stores the nodeID of the owner along with the data. If a node wants to subsequently modify a data record, it has to sign the modification request with its private key k_priv. The receiver of the request has verify the signature and to ensure that Baumgart Expires May 12, 2008 [Page 9] Internet-Draft Peer-to-Peer Name Service (P2PNS) November 2007 H(k_pub) coincides with the nodeID of the data record's owner. The node, that is responsible for storing a data record is determined by means of the key of the record. In this case the key is the hash value of the P2PName. In order to prevent users from choosing an already existing P2PName, the DHT only stores a single data record for a each key. Consequently the user how stores his P2PName first is eligible for this name. Data records are replicated on several nodes, because a malicious node may arbitrarily tamper with locally stored data records. The replicas are stored on neighbor nodes close to the key as these nodes can be efficiently discovered by a single KBR lookup. A peer resolves a P2PName to nodeID mapping by querying all replicas in parallel. Thereupon the peer makes a majority decision on all received replies to determine the most plausible destination nodeID. In order to handle churn every newly joined node first requests all data records in his responsibility from his neighbor nodes and stores them locally. Finally the DHT has to be protected against adversarial flooding of insertion requests. This is important because the verification of the signature of a STORE message is computational expensive. Moreover the storage of unnecessary data records consums valuable peer ressources. To compensate for the computational ressources for verifying the signature of a STORE message, the requesting node has to solve the following crypto puzzle: For the key k of the data record determine an appropriate b, so that the first c bits of H(k XOR b) are equal to the first c bits of the own nodeID. The constant c is used to specify the complexity of the puzzle and b is the solution of the puzzle. The crypto puzzle makes the insertion of a large number of data records harder, but doesn't completely prevent an insertion DoS attack. Therefore we additionally limit the allow number of data records per owner by using the following approach: To store a new data record the owner O sends a GRANT message to all neighbors close to his own nodeID after solving the crypto puzzle. These neighbors store all keys of the data records that O has already stored in the DHT. If the maximum number of allowed data records per owner is exceeded the GRANT message is rejected. In a second step the node O sends a STORE message with his data record containing the AoR to nodeID mapping to all replicating nodes. These nodes use a CHECK message to verify if the neighbor nodes of O have authorized the storage and finally store the data record locally. Baumgart Expires May 12, 2008 [Page 10] Internet-Draft Peer-to-Peer Name Service (P2PNS) November 2007 These proposed security mechanisms make the storage and modification of data records rather expensive in terms of computational and communication costs. But by using the two-stage approach of Section 5.2.1 the static P2PName to nodeID mapping has to be stored only once when new P2PName is registered for the first time. If a node later change its IP address or temporarily leaves the network, this is efficiently handled by the KBR layer without involving complex DHT operations. 6. Service Discovery P2PNS also supports service discovery in a similar way to name resolution. This can e.g. be used to locate STUN servers or bootstrap nodes. A node registers a service by calling register() (see Section 7.1) with a well-known service name (e.g. "STUN"). This service registration is stored in the DHT by a put(H(ServiceName), nodeID) call similar to storing a P2PName/nodeID mapping. Because the same service may be provided by different nodes, a ServiceName/nodeID mapping in the DHT is allowed to contain several different nodeIDs. Consequently a ServiceName record has no dedicated owner like a P2PName record (see Section 5.4.1). To anyhow inhibit malicious nodes from arbitrarily modifying ServiceName records, the only allowed modification is to add the own nodeID to a record. If the service directory is used to store a large number of nodes for a ServiceName, the load in the DHT should be balanced by using multiple hash functions [15]. 7. P2PNS Interface P2PNS provides a XML-RPC interface with the following procedures to register and resolve P2PNames: 7.1. REGISTER The register() procedure is used to register a new P2PName or to update the transport address for an existing P2PName. The same procedure is also used to register a service (see Section 6). The register() procedure uses the following parameters: o Name (): The name to register. o Transport Address (): The current IP address and port for the given P2PName. If this is empty, the node's current IP Baumgart Expires May 12, 2008 [Page 11] Internet-Draft Peer-to-Peer Name Service (P2PNS) November 2007 address and KBR port is used. o Type (): * 0: The name is registered as P2PName. * 1: The name is registered as a service. o TTL (): The time-to-live for this mapping in seconds. The return value is an : o 0: The registration was successful. o 1: The registration was rejected, because the name is already registered by another node. o 2: The registration failed, because the overlay is not available. 7.2. RESOLVE The resolve() procedure is used to resolve a registered P2PName to the current corresponding transport address. The same procedure is also used for service discovery (see Section 6). The resolve() procedure uses the following parameters: o Name (): The name to resolve. o Type (): * 0: The given name is a P2PName. * 1: The given name is a service. The return value is an : o Transport Address (): The current IP address and port for the given name. o Error code (): * 0: The name resolution was successful. * 1: The name resolution failed, because the name is not registered. * 2: The name resolution failed, because the overlay is not available. Baumgart Expires May 12, 2008 [Page 12] Internet-Draft Peer-to-Peer Name Service (P2PNS) November 2007 8. P2PNS Usage This section describes how P2PNS can be utilized for different application scenarios like P2PSIP or distributed DNS. 8.1. P2PSIP In order to facilitate the use of legacy server-based SIP phones, we propose to employ a proxy architecture. In this architecture every P2PSIP peer consists of a SIP UA, a local SIP proxy as well as a P2PNS implementation. The proxy is used as a location server for resolving AoRs to Contact URIs by using the P2PNS services. To facilitate the interconnection of P2PSIP and server-based SIP networks we propose to use AoRs of the form username@p2pname.org. The username part can be freely chosen by the user whereas the domain part p2pname.org is fixed and used to identify the P2PSIP network. In order to connect the P2PSIP network to the server-based SIP network DNS is used. In this case the domain name p2pname.org should contain a SRV DNS record pointing to several of the P2PSIP proxies which are used to forward SIP INVITEs to the appropriate P2PSIP nodes. This can also be used to interconnect multiple P2PSIP networks by using different domain parts for each overlay. In a pure P2PSIP network DNS is not used at all. The following figure shows the P2PNS architecture for P2PSIP: +-------------+ +-----------+ | P2PNS Cache |<----------->| SIP proxy | +-------------+ register() +-----------+ ^ ^ resolve() ^ | put() | | | get() | | SIP v | | +-----+ | v | DHT | | +-----------+ +-----+ | | SIP UA | ^ | +-----------+ | join() | | route() | | lookup()| v v +-------------+ | KBR | +-------------+ The following figure illustrates an example of an AoR registration. In the first step the UA at peer Y sends a SIP REGISTER message with the AoR U to the local P2PSIP proxy. The proxy then connects to the Baumgart Expires May 12, 2008 [Page 13] Internet-Draft Peer-to-Peer Name Service (P2PNS) November 2007 P2PNS XML-RPC interface and calls register(U). If the the P2PNS layer is not already connected to the overlay, it joins with the nodeID ID_Y. Finally the P2PNS layer stores the AoR to nodeID mapping in the DHT. .................................................. . 2.register(U) . . +-------------+ +-----------+ . . | P2PNS Cache |<-----------| SIP proxy | . . +-------------+ +-----------+ . . | | ^ . . 4.put( | | 1.REGISTER(To:U)| . . U,ID_Y) | | (SIP) | . . v | | . . +-----+ | | . . | DHT | |3.join(ID_Y) +-----------+ . . +-----+ | | SIP UA | . . v +-----------+ . . +-------------+ User U . . | KBR | . . +-------------+ . .................................................. Peer Y The following figure shows how the user at peer X establishes a call to the AoR U. At first the UA sends an INVITE to the local P2PSIP proxy. Subsequently the proxy queries P2PNS by a resolve(U) call. The P2PNS layer first fetches the corresponding nodeID for the AoR U from the DHT (if the mapping is not already cached). In the next step the obtained nodeID gets resolved to the current IP address of peer Y. Finally the INVITE message gets forwarded to the UA of U via the proxy at peer Y. Baumgart Expires May 12, 2008 [Page 14] Internet-Draft Peer-to-Peer Name Service (P2PNS) November 2007 ............................................ . 2.resolve(U) 5.INVITE(To:U) (SIP) . +-------------+ +-----------+ . .......... . | P2PNS Cache |<-----------| SIP proxy |--->.User U . . +-------------+ +-----------+ . .@ Peer Y. . | | ^ . .......... . |3.get(U) | 1.INVITE(To:U)| . . | | (SIP) | . . v | | . . +-----+ |4.lookup(ID_X) | . . | DHT | | +-----------+ . . +-----+ | | SIP UA | . . v +-----------+ . . +-------------+ User V . . | KBR | . . +-------------+ . ............................................ Peer X 8.2. Distributed DNS Similar to the P2PSIP approach P2PNS can be used to build a distributed DNS system by adding P2PNS support to a caching-only name server. For distributed DNS a P2PName is a FQDN of the form arbitrary_hostname.p2pname.org. For all name resolution requests to *.p2pname.org the name server queries P2PNS using a XML-RPC resolve() call. 8.3. Zeroconf Service Discovery P2PNS could also be used for wide-area service discovery by adding P2PNS support to a mDNS/DNS-SD[16] implementation. This way legacy applications with DNS-SD support can use P2PNS for service discovery, if DNS is not available. 8.4. HIP The Host Identity Protocol [7] uses DNS to resolve Host Identity Tags (HITs) to IP addresses. Alternatively the HIP DHT Interface [17] draft proposes to use OpenDHT for HIT lookups. Similarly P2PNS can be used in two ways to resolve a HIT without DNS: o Register the HIT as P2PName (This is similar to the HIP DHT Interface [17] proposal) o Use the HIT as nodeID. This allows an efficient HIT resolution by only using the KBR layer (Only the second stage of the two-stage approach described in Section 5.2.1 is needed). Baumgart Expires May 12, 2008 [Page 15] Internet-Draft Peer-to-Peer Name Service (P2PNS) November 2007 8.5. Jabber / XMPP A decentralized XMPP [6] network, which is independent from DNS can be realized with P2PNS analogous to Section 8.1 by adding a P2PNS interface to a XMPP server. In this case the Jabber ID (JID) is of the form username@p2pname.org with the fixed domain part p2pname.org. 9. Bootstrapping P2PNS uses a combination of the following bootstrap mechanisms to find a bootstrap node: o Locate local peers by using mDNS as described in the P2PSIP bootstrapping using DNS-SD [18] draft. o If DNS is available, try to use DNS-SD as described in the P2PSIP bootstrapping using DNS-SD [18] draft. o Try to connect to a node from a list of stored nodes known from previous sessions. o Probe random IP addresses from a list of given IP address ranges (e.g. dial-in networks). 10. NAT Traversal The current implementation uses STUN [19] for NAT traversal. Further versions of P2PNS should also support ICE [20] for better NAT traversal. 11. Open Issues There are a lot of open issues. Some of these are: 1. Which KBR protocols shows the best performance for P2PNS? The Broose protocol seems to be a promising alternative to Kademlia. 2. Where should the private key k_priv be stored (DHT, P2PNS Cache, SIP proxy)? 3. Is it necessary to sign all messages or should only "important" messages be signed? 4. What is the performance (bandwidth consumption/latency) of the two-stage approach compared to the direct approach? Baumgart Expires May 12, 2008 [Page 16] Internet-Draft Peer-to-Peer Name Service (P2PNS) November 2007 12. Acknowledgments This research was supported by the German Federal Ministry of Education and Research as part of the ScaleNet project 01BU567. The author likes to thank Sebastian Mies for his valuable contributions to this work. 13. IANA Considerations This document has no actions for IANA. 14. Security Considerations Using crypto puzzles as defense against Sybil attacks is currently the most promising approach in completely decentralized networks. However crypto puzzles only make a Sybil attack harder and cannot completely prevent it. If the attacker has sufficient computing ressources to solve a large number of crypto puzzles particularly small networks as well as the bootstrap phase are still vulnerable to attacks. In these cases the nodeID assignment should additionally be restricted by using certificates of an offline CA. 15. References 15.1. Normative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 15.2. Informative References [3] Bryan, D., "REsource LOcation And Discovery (RELOAD)", draft-bryan-p2psip-reload-01 (work in progress), July 2007. [4] Baset, S. and H. Schulzrinne, "Peer-to-Peer Protocol (P2PP)", draft-baset-p2psip-p2pp-00 (work in progress), July 2007. [5] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [6] Saint-Andre, P., Ed., "Extensible Messaging and Presence Baumgart Expires May 12, 2008 [Page 17] Internet-Draft Peer-to-Peer Name Service (P2PNS) November 2007 Protocol (XMPP): Core", RFC 3920, October 2004. [7] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [8] Dabek, F., Zhao, B., Druschel, P., Kubiatowicz, J., and I. Stoica, "Towards a Common API for Structured Peer-to-Peer Overlays", Proceedings of the 2nd International Workshop on Peer-to-Peer Systems (IPTPS '03) , 2003. [9] Maymounkov, P. and D. Mazieres, "Kademlia: A Peer-to-Peer Information System Based on the XOR Metric", Lecture Notes in Computer Science, Peer-to-Peer Systems: First International Workshop (IPTPS 2002) , March 2002. [10] Bryan, D., "Concepts and Terminology for Peer to Peer SIP", draft-ietf-p2psip-concepts-00 (work in progress), July 2007. [11] Castro, M., Druschel, P., Ganesh, A., Rowstron, A., and D. Wallach, "Secure routing for structured peer-to-peer overlay networks", SIGOPS Oper. Syst. Rev, ACM Press , 2002. [12] Baumgart, I. and S. Mies, "S/Kademlia: A Practicable Approach Towards Secure Key-Based Routing", Proceedings of the International Workshop on Peer-to-Peer Networked Virtual Environments 2007 (P2P-NVE 2007), Hsinchu, Taiwan , December 2007. [13] American National Standards Institute, "ANSI X9.62-2005, Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)". [14] National Insitute of Standards and Technology, "FIPS 180-2, "Secure Hash Standard"", 2002. [15] Xia, Y., Chen, S., and V. Korgaonkar, "Load Balancing with Multiple Hash Functions in Peer-to-Peer Networks", Proceedings of the 12th International Conference on Parallel and Distributed Systems (ICPADS'06) , 2006. [16] Krochmal, M. and S. Cheshire, "DNS-Based Service Discovery", draft-cheshire-dnsext-dns-sd-04 (work in progress), August 2006. [17] Ahrenholz, J., "HIP DHT Interface", draft-ahrenholz-hiprg-dht-01 (work in progress), February 2007. [18] Garcia, G., "P2PSIP bootstrapping using DNS-SD", Baumgart Expires May 12, 2008 [Page 18] Internet-Draft Peer-to-Peer Name Service (P2PNS) November 2007 draft-garcia-p2psip-dns-sd-bootstrapping-00 (work in progress), October 2007. [19] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [20] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-18 (work in progress), September 2007. Author's Address Ingmar Baumgart Institute of Telematics, Universitaet Karlsruhe (TH) Zirkel 2 Karlsruhe, 76128 Germany Phone: +49 721 608 8281 Email: baumgart@tm.uka.de Baumgart Expires May 12, 2008 [Page 19] Internet-Draft Peer-to-Peer Name Service (P2PNS) November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Baumgart Expires May 12, 2008 [Page 20]