| TOC |
|
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.
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 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.
1.
Introduction
2.
Background
2.1.
Structured Peer-to-Peer Networks
3.
Terminology
4.
Goals for P2PNS
5.
Design Overview
5.1.
P2PNS Architecture
5.2.
P2PNS Name Resolution
5.2.1.
Two-stage Name Resolution
5.2.2.
Direct Name Resolution
5.2.3.
P2PNS Cache
5.3.
KBR Design
5.3.1.
KBR Security
5.3.1.1.
Secure NodeID Assignment
5.3.1.2.
Lookup over Disjoint Paths
5.3.1.3.
Secure Routing Table Maintenance
5.4.
DHT Design
5.4.1.
DHT Security
6.
Service Discovery
7.
P2PNS Interface
7.1.
REGISTER
7.2.
RESOLVE
8.
P2PNS Usage
8.1.
P2PSIP
8.2.
Distributed DNS
8.3.
Zeroconf Service Discovery
8.4.
HIP
8.5.
Jabber / XMPP
9.
Bootstrapping
10.
NAT Traversal
11.
Open Issues
12.
Acknowledgments
13.
IANA Considerations
14.
Security Considerations
15.
References
15.1.
Normative References
15.2.
Informative References
§
Author's Address
§
Intellectual Property and Copyright Statements
| TOC |
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) (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [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 (Bryan, D., “REsource LOcation And Discovery (RELOAD),” July 2007.) [3] and P2PP (Baset, S. and H. Schulzrinne, “Peer-to-Peer Protocol (P2PP),” July 2007.) [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 (Mockapetris, P., “Domain names - implementation and specification,” November 1987.) [5], decentralized XMPP (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.) [6] or decentralized HIP (Moskowitz, R. and P. Nikander, “Host Identity Protocol (HIP) Architecture,” May 2006.) [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.
| TOC |
| TOC |
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) (Dabek, F., Zhao, B., Druschel, P., Kubiatowicz, J., and I. Stoica, “Towards a Common API for Structured Peer-to-Peer Overlays,” 2003.) [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 (Maymounkov, P. and D. Mazieres, “Kademlia: A Peer-to-Peer Information System Based on the XOR Metric,” March 2002.) [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.
| TOC |
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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [2].
Terminology defined in RFC 3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [1] and the Concepts and Terminology for Peer-to-Peer SIP (Bryan, D., “Concepts and Terminology for Peer to Peer SIP,” July 2007.) [10] draft is used without definition.
DHT: Distributed hash table as defined in [8] (Dabek, F., Zhao, B., Druschel, P., Kubiatowicz, J., and I. Stoica, “Towards a Common API for Structured Peer-to-Peer Overlays,” 2003.).
KBR: Key-based routing layer as defined in [8] (Dabek, F., Zhao, B., Druschel, P., Kubiatowicz, J., and I. Stoica, “Towards a Common API for Structured Peer-to-Peer Overlays,” 2003.).
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 (Bryan, D., “Concepts and Terminology for Peer to Peer SIP,” July 2007.) [10] 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.
| TOC |
The name service P2PNS should fulfill the following requirements:
| TOC |
In this section we describe our P2PNS architecture and several security extensions for the KBR and DHT layer.
| TOC |
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 (Dabek, F., Zhao, B., Druschel, P., Kubiatowicz, J., and I. Stoica, “Towards a Common API for Structured Peer-to-Peer Overlays,” 2003.) [8] interface and contains the security extensions from Section 5.3.1 (KBR Security). 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.
+-------------+ +---------------------------------------+ | P2PNS Cache |<----------->| Application (SIP proxy, DNS Resolver) | +-------------+ register() +---------------------------------------+ ^ ^ resolve() | put() | | get() | v | +-----+ | | DHT | | +-----+ | | | | join() | | route() | | lookup()| v v +-------------+ | KBR | +-------------+
| TOC |
P2PNS offers two alternatives for resolving a P2PName to the current transport address:
| TOC |
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.
| TOC |
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 (DHT Security) 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.
| TOC |
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.
| TOC |
The current P2PNS implementation uses Kademlia (Maymounkov, P. and D. Mazieres, “Kademlia: A Peer-to-Peer Information System Based on the XOR Metric,” March 2002.) [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] (Baset, S. and H. Schulzrinne, “Peer-to-Peer Protocol (P2PP),” July 2007.) and extend it by the following security extensions.
| TOC |
The security of the P2PNS architecture largely depends on the security of the KBR layer. As shown in [11] (Castro, M., Druschel, P., Ganesh, A., Rowstron, A., and D. Wallach, “Secure routing for structured peer-to-peer overlay networks,” 2002.) 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 (Baumgart, I. and S. Mies, “S/Kademlia: A Practicable Approach Towards Secure Key-Based Routing,” December 2007.) [12]). In the following these requirements and security enhancements are summarized:
| TOC |
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 (American National Standards Institute, “ANSI X9.62-2005, Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (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 (National Insitute of Standards and Technology, “FIPS 180-2, "Secure Hash Standard",” 2002.) [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:
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.
| TOC |
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] (Baumgart, I. and S. Mies, “S/Kademlia: A Practicable Approach Towards Secure Key-Based Routing,” December 2007.) 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.
| TOC |
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.
| TOC |
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.
| TOC |
The proposed security mechanisms in Section 5.3.1 (KBR Security) 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:
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 Section 5.2.1 (Two-stage Name Resolution) 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.
| TOC |
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 (REGISTER)) 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 (DHT Security)). 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] (Xia, Y., Chen, S., and V. Korgaonkar, “Load Balancing with Multiple Hash Functions in Peer-to-Peer Networks,” 2006.).
| TOC |
P2PNS provides a XML-RPC interface with the following procedures to register and resolve P2PNames:
| TOC |
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 (Service Discovery)). The register() procedure uses the following parameters:
The return value is an <int>:
| TOC |
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 (Service Discovery)). The resolve() procedure uses the following parameters:
The return value is an <array>:
| TOC |
This section describes how P2PNS can be utilized for different application scenarios like P2PSIP or distributed DNS.
| TOC |
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 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.
............................................ . 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
| TOC |
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.
| TOC |
P2PNS could also be used for wide-area service discovery by adding P2PNS support to a mDNS/DNS-SD[16] (Krochmal, M. and S. Cheshire, “DNS-Based Service Discovery,” August 2006.) implementation. This way legacy applications with DNS-SD support can use P2PNS for service discovery, if DNS is not available.
| TOC |
The Host Identity Protocol (Moskowitz, R. and P. Nikander, “Host Identity Protocol (HIP) Architecture,” May 2006.) [7] uses DNS to resolve Host Identity Tags (HITs) to IP addresses. Alternatively the HIP DHT Interface (Ahrenholz, J., “HIP DHT Interface,” February 2007.) [17] draft proposes to use OpenDHT for HIT lookups. Similarly P2PNS can be used in two ways to resolve a HIT without DNS:
| TOC |
A decentralized XMPP (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.) [6] network, which is independent from DNS can be realized with P2PNS analogous to Section 8.1 (P2PSIP) 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.
| TOC |
P2PNS uses a combination of the following bootstrap mechanisms to find a bootstrap node:
| TOC |
The current implementation uses STUN (Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, “STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs),” March 2003.) [19] for NAT traversal. Further versions of P2PNS should also support ICE [20] (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” September 2007.) for better NAT traversal.
| TOC |
There are a lot of open issues. Some of these are:
| TOC |
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.
| TOC |
This document has no actions for IANA.
| TOC |
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.
| TOC |
| TOC |
| [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 (TXT). |
| [2] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| TOC |
| [3] | Bryan, D., “REsource LOcation And Discovery (RELOAD),” draft-bryan-p2psip-reload-01 (work in progress), July 2007 (TXT). |
| [4] | Baset, S. and H. Schulzrinne, “Peer-to-Peer Protocol (P2PP),” draft-baset-p2psip-p2pp-00 (work in progress), July 2007 (TXT). |
| [5] | Mockapetris, P., “Domain names - implementation and specification,” STD 13, RFC 1035, November 1987 (TXT). |
| [6] | Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Core,” RFC 3920, October 2004 (TXT, HTML, XML). |
| [7] | Moskowitz, R. and P. Nikander, “Host Identity Protocol (HIP) Architecture,” RFC 4423, May 2006 (TXT). |
| [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 (TXT). |
| [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 (TXT). |
| [17] | Ahrenholz, J., “HIP DHT Interface,” draft-ahrenholz-hiprg-dht-01 (work in progress), February 2007 (TXT). |
| [18] | Garcia, G., “P2PSIP bootstrapping using DNS-SD,” 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 (TXT). |
| [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 (TXT). |
| TOC |
| Ingmar Baumgart | |
| Institute of Telematics, Universitaet Karlsruhe (TH) | |
| Zirkel 2 | |
| Karlsruhe, 76128 | |
| Germany | |
| Phone: | +49 721 608 8281 |
| Email: | baumgart@tm.uka.de |
| TOC |
Copyright © 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.
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.