Internet DRAFT - draft-baumgart-p2psip-p2pns
draft-baumgart-p2psip-p2pns
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 (<base64>): The name to register.
o Transport Address (<base64>): 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 (<int>):
* 0: The name is registered as P2PName.
* 1: The name is registered as a service.
o TTL (<int>): The time-to-live for this mapping in seconds.
The return value is an <int>:
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 (<base64>): The name to resolve.
o Type (<int>):
* 0: The given name is a P2PName.
* 1: The given name is a service.
The return value is an <array>:
o Transport Address (<base64>): The current IP address and port for
the given name.
o 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.
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]
