Peer-to-Peer Name Service (P2PNS)

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) 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 and P2PP 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, decentralized XMPP or decentralized HIP. 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.

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). 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 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.

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. Terminology defined in RFC 3261 and the Concepts and Terminology for Peer-to-Peer SIP draft is used without definition. DHT: Distributed hash table as defined in . KBR: Key-based routing layer as defined in . 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 this is called Peer-ID. P2PName: An arbitrary string which can be resolved to a Transport Address by using P2PNS. 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.

The name service P2PNS should fulfill the following requirements: 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. The P2PNS architecture should be completely decentralized. In particular it should not depend on any central login servers or other trustworthy authorities. The user should be able to choose an arbitrary P2PName. P2PNS should provide mechanisms to guarantee the uniqueness of P2PNames and prevent identity theft. For P2PSIP applications P2PNS should support unmodified legacy SIP UAs and provide gateway functionality between P2PSIP and server-based SIP networks.

In this section we describe our P2PNS architecture and several security extensions for the KBR and DHT layer.

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 interface and contains the security extensions from . 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.

| Application (SIP proxy, DNS Resolver) | +-------------+ register() +---------------------------------------+ ^ ^ resolve() | put() | | get() | v | +-----+ | | DHT | | +-----+ | | | | join() | | route() | | lookup()| v v +-------------+ | KBR | +-------------+ ]]>

P2PNS offers two alternatives for resolving a P2PName to the current transport address:

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.

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 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.

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.

The current P2PNS implementation uses Kademlia 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 and extend it by the following security extensions.

The security of the P2PNS architecture largely depends on the security of the KBR layer. As shown in 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). In the following these requirements and security enhancements are summarized:

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 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 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: Generate a new public key pair (k_priv, k_pub). Calculate H(H(k_pub)) and check, if the first c bit are 0. 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.

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 for Kademlia showed a significant increase in lookup success by using several disjoint paths. 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.

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.

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.

The proposed security mechanisms in 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: Data records may only be deleted or modified by the owner of the record. Data records should be replicated on several nodes to inhibit manipulation by single malicious nodes. 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 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. 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 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.

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 ) 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 ). 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 .

P2PNS provides a XML-RPC interface with the following procedures to register and resolve P2PNames:

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 ). The register() procedure uses the following parameters: Name (<base64>): The name to register. Transport Address (<base64>): The current IP address and port for the given P2PName. If this is empty, the node's current IP address and KBR port is used. Type (<int>): 0: The name is registered as P2PName. 1: The name is registered as a service. TTL (<int>): The time-to-live for this mapping in seconds. The return value is an <int>: 0: The registration was successful. 1: The registration was rejected, because the name is already registered by another node. 2: The registration failed, because the overlay is not available.

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 ). The resolve() procedure uses the following parameters: Name (<base64>): The name to resolve. Type (<int>): 0: The given name is a P2PName. 1: The given name is a service. The return value is an <array>: Transport Address (<base64>): The current IP address and port for the given name. Error code (<int>): 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.

This section describes how P2PNS can be utilized for different application scenarios like P2PSIP or distributed DNS.

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:

| 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 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.

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.

.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 ]]>

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.

P2PNS could also be used for wide-area service discovery by adding P2PNS support to a mDNS/DNS-SD implementation. This way legacy applications with DNS-SD support can use P2PNS for service discovery, if DNS is not available.

The Host Identity Protocol uses DNS to resolve Host Identity Tags (HITs) to IP addresses. Alternatively the HIP DHT Interface draft proposes to use OpenDHT for HIT lookups. Similarly P2PNS can be used in two ways to resolve a HIT without DNS: Register the HIT as P2PName (This is similar to the HIP DHT Interface proposal) 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 is needed).

A decentralized XMPP network, which is independent from DNS can be realized with P2PNS analogous to 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.

P2PNS uses a combination of the following bootstrap mechanisms to find a bootstrap node: Locate local peers by using mDNS as described in the P2PSIP bootstrapping using DNS-SD draft. If DNS is available, try to use DNS-SD as described in the P2PSIP bootstrapping using DNS-SD draft. Try to connect to a node from a list of stored nodes known from previous sessions. Probe random IP addresses from a list of given IP address ranges (e.g. dial-in networks).

The current implementation uses STUN for NAT traversal. Further versions of P2PNS should also support ICE for better NAT traversal.

There are a lot of open issues. Some of these are: Which KBR protocols shows the best performance for P2PNS? The Broose protocol seems to be a promising alternative to Kademlia. Where should the private key k_priv be stored (DHT, P2PNS Cache, SIP proxy)? Is it necessary to sign all messages or should only "important" messages be signed? What is the performance (bandwidth consumption/latency) of the two-stage approach compared to the direct approach?

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.

This document has no actions for IANA.

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.