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 December 2, 2006.

Copyright Notice

Copyright © The Internet Society (2006).

Abstract

This document describes the data format and interface to an external peer-to-peer (P2P) protocol for use as a location service in the Session Initiation Protocol (SIP)-based Internet telephony.

Table of Contents

1.  Introduction
2.  Scope of This Document
3.  DHT API
    3.1.  Overview
        3.1.1.  Signed Data
        3.1.2.  Immutable Data
        3.1.3.  Service Interface
    3.2.  XML Format for Input and Output
    3.3.  Fragmenting Large Values
    3.4.  RPC Protocol
4.  Format for Location Data
    4.1.  Contact Management
    4.2.  Key Storage
    4.3.  Presence
    4.4.  Offline Messages
    4.5.  NAT and Firewall Traversal
5.  Implementation using Data or Service Models
    5.1.  Data Model
    5.2.  Service Model
6.  XML Schema Definitions
    6.1.  urn:ietf:params:xml:ns:dht
    6.2.  urn:ietf:params:xml:ns:p2p-sip
7.  IANA Considerations
    7.1.  URN Namespace Registration for 'urn:ietf:params:xml:ns:dht'
    7.2.  URN Namespace Registration for 'urn:ietf:params:xml:ns:p2p-sip'
8.  Security Considerations
9.  References
    9.1.  Normative References
    9.2.  Informative References
Appendix A.  Acknowledgements
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1. Introduction

Peer-to-peer (P2P) systems inherently have high scalability, robustness and fault tolerance because there is no centralized server and the network self-organizes itself. This is achieved at the cost of higher latency for locating the resources of interest in the P2P overlay network. 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.) [RFC3261])-based Internet telephony and presence systems can perform lookup and update on an external P2P network. Such a P2P-SIP system has two components as shown in Figure 1: location data (or data storage) and user agent. We describe the interface between the two and the data format for storing the location data. The goal is to provide a clear separation between the location service and the session establishment.

                  SIP                      SIP
        +-----------------------+  +------------------+
        |                       |  |                  |
+-------+------+        +-------+------+      +--------------+
|              |        |              |      |              |
| User agent   |        | User agent   |      | User agent   |
|              |        |              |      |              |
+-------+------+        +-------+--+---+      +-------+------+
        |                       |
        |DHT API                |DHT API
        |                       |
+-------+------+        +-------+------+
|              |        |              |
| Location data|        | Location data|
|              |        |              |
+-------+------+        +-------+------+
        |                       |
        +-----------------------+
              P2P protocol

The two components can either be combined together in a single implementation or can be distributed in various deployment scenarios scenarios. Separating the two components gives rise to an external distributed hash table (DHT) architecture [Sing0602:Using] (Singh, K. and H. Schulzrinne, “Using an external DHT as a SIP location service,” Feb 2006.). The location data is distributed using a DHT such as Chord. The decision whether the DHT maintenance is implemented using an existing protocol such as SIP as the lower layer is outside the scope of this document. The user agent can be of two types: (1) SIP user agent that interacts with the location data, and (2) SIP user agent that does not interact with the location data. A DHT API is used by the SIP user agent to interact with or access the location data. Identifying the two types of user agents gives rise to a P2P-SIP proxy model, where a type (1) user agent also acts as a P2P-SIP proxy and registration server.

For the P2P-SIP architecture of Figure 1, three things need to be defined for interoperability: (1) a DHT API for accessing the location data, (2) data format for the location data, and (2) a P2P protocol for maintaining the DHT. In this document, we define (1) and (2) in Section 3 (DHT API) and Section 4 (Format for Location Data), respectively.

2. Scope of This Document

This document describes the use of P2P in SIP-based Internet telephony. Readers are expected to be familiar with SIP (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261]. This document does not propose any change in SIP. We propose only an interface and data format independent of any specific P2P algorithm.

3. DHT API

3.1. Overview

The DHT API presented here consists of data and service interfaces, and is based on OpenDHT (Rhea, S., Godfrey, B., Karp, B., Kubiatowicz, J., Ratnasamy, S., Shenker, S., Stoica, I., and H. Yu, “OpenDHT: a public DHT service and its uses,” August 2005.) [Rhea0510:opendht]. The data interface allows inserting, retrieving and removing data on the DHT, and the service interface allows a node to join the DHT for a service and another node to lookup for a service node. To provide protection against malicious addition or deletion of data, a simple key-value pair, (k,v), is not enough. Thus, data put on the DHT should be either signed or immutable (can not be changed).

3.1.1. Signed Data

The put-auth(k,v,n,t,Kp,s) interface is used to store a value, v, associated with a key, k, which expires at absolute time, t. Kp is the public key of the writer, with associated private key, Ks. Here, s is the signature of the tuple (k,v,n,t) signed using the private key Ks, i.e., s={H(k,v,n,t)}Ks. The key-value pair can be removed using the same nonce, n.

The remove-auth(k,H(v),n,t,Kp,s) interface is used to explicitly remove the corresponding key-value pair. Here, H(v) represents one-way hash of v, e.g., using SHA1. The record is implicitly removed at the expiry time, t.

To fetch a record for a given key, the get-auth(k,H(Kp)) interface is used which returns a list of tuples (v,n,t,s), that were stored with public key, Kp. Alternatively, get(k) is used to return a list of tuples (v,n,t,s,H(Kp)) that contains all the tuples from all the users so that the requester can explicitly filter the records.

The interface allows putting multiple values under the same key, i.e., both (k1,v1) and (k1,v2) can be stored. For example, if Bob has many SIP phones, each phone can store its own contact IP address under Bob's DHT key, and Alice's phone can retrieve all these contacts when making a call. Secondly, a put with same key, value, nonce and public key, just updates the expiration time, t. The expiration can be mapped by the user agent to the Expires header in SIP REGISTER request for expiry of contact bindings.

3.1.2. Immutable Data

Immutable data is useful for storing data with self-verifiable keys, even though it limits the application's ability to choose keys. For example, put-immut(v,t) is used to write (k,v) with expiry, t, such that k=H(v), and get-immut(k) returns (v,t). The data can not be removed, and will only expire. Immutable data interface is used to store fragments of a large DHT value, if the DHT imposes a limit on the size of the value as described in Section 3.3 (Fragmenting Large Values).

3.1.3. Service Interface

The service interface allows a node to join as a service node to provide a particular service to the other nodes, and the other nodes to lookup for the service nodes providing the particular service.

The join(N,h) interface adds the host, h, to the list of hosts providing the functionality or service of the namespace, N. The function returns an identifier for this service host.

The lookup(k,N) interface looks up the key k in namespace N and returns (h,i) of the host that provides the functionality or service of namespace, N, and whose node identifier, i, most immediately follows the key, k.

The leave(N,h,i) interface is used to remove the host, h, with identifier, i, from the list of providers for namespace or service, N.

3.2. XML Format for Input and Output

The parameters and return values for the DHT interface are specified in XML.

The DHT key, k, is represented using the key element, for example

<key>sip:alice@example.net</key>

The DHT node hashes this key to appropriate number of bits before using it as a DHT key. If the DHT algorithm is known to the user agent, it can include the hashed value instead of the clear text key as shown below:

<key Id="One">
  <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
  <DigestValue>Y8eVClzbJ8Wk315al7pW6/RZsvM=</DigestValue>
</key>

The DHT value, v, is represented using the value element, which can encapsulate any other element (e.g., string). The value includes both the expiration and nonce as shown below:

<value Id="Two" expires="2006-12-31T18:00:00Z" nonce="82771583613">
 <string>sip:alice@192.1.2.3:5060<string>
</value>

To support multiple key-value pairs, the optional reference attribute is used to associated the value element with the corresponding key element.

The signature and public key are represented using W3C's digital signature format [w3c:sign] (Eastlake, D., Reagle, J., and D. Solo, “XML-signature syntax and processing,” February 2002.). The signature as shown below is computed over both the key and value. Note that the KeyInfo element may directly include the public key, Kp, or may point to an external resource that contains the user's public key.

 <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
  <SignedInfo>
   <CanonicalizationMethod
    Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
   <SignatureMethod
     Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
   <Reference URI="#One">
    <Transforms>
     <Transform
      Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
    </Transforms>
    <DigestMethod
     Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
    <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
   </Reference>
   <Reference URI="#Two">
    <Transforms>
     <Transform
      Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
    </Transforms>
    <DigestMethod
      Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
    <DigestValue>qZk+NkcGgWq6PiVxeFDCbJzQ2J0=</DigestValue>
   </Reference>
  </SignedInfo>
  <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>
  <KeyInfo>
   <KeyValue>
    <RSAKeyValue>
    <Modulus>
xA7SEU+e0yQH5rm9kbCDN9o3aPIo7HbP7tX6WOocLZAtNfyxSZDU16ksL6W
jubafOqNEpcwR3RdFsT7bCqnXPBe5ELh5u4VEy19MzxkXRgrMvavzyBpVRg
5foK5hhmbktQhyNdy/6LpQRhDUDsTvK+g9Ucj47es9AQJ3U=
     </Modulus>
     <Exponent>AQAB</Exponent>
    </RSAKeyValue>
   </KeyValue>
  </KeyInfo>
 </Signature>
</parameter>

This document defines the default Algorithm for CanonicalizationMethod, SignatureMethod, Transform and DigestMethod elements as shown in the above example. Thus, if the default algorithms are used, those elements may be absent. This saves bandwidth for an external DHT architecture. Thus, the above signature can also be represented as follows:

 <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
  <SignedInfo>
   <Reference URI="#One">
    <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
   </Reference>
   <Reference URI="#Two">
    <DigestValue>qZk+NkcGgWq6PiVxeFDCbJzQ2J0=</DigestValue>
   </Reference>
  </SignedInfo>
  <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>
  <KeyInfo>...</KeyInfo>
 </Signature>

An example parameter for put-auth interface is shown below:

<dhtRecord xmlns="urn:ietf:params:xml:ns:dht">
 <key Id="One">...</key>
 <value Id="Two">...</value>
 <Signature>...</Signature>
</dhtRecord>

A similar parameter is used for remove-auth interface, except that a DigestValue element is used instead of a string in the value element.

The get-auth interface takes the DHT key and SHA1 of the public key as shown below. The KeyInfo element is absent for the get interface.

<dhtRecord>
 <key>...</key>
 <KeyInfo>
  <KeyValue>
   <DigestValue>...</DigestValue>
  </KeyValue>
 </KeyInfo>
</dhtRecord>

The put-immut and get-immut interfaces take similar parameters except that the Signature element is absent.

The return values for get and get-auth contains a list of dhtRecord elements without the public key in the KeyInfo elements. Instead a KeyName element is included to identify the signer. Alternatively, a hash element can be included in the KeyValue element to indicate SHA1 hash of the public key.

The service interface uses the dhtService element to represent a service query or service host. It requires the definition for namespace, serviceHost, and hostIdentifier.

The complete XML schema for input and output of DHT interface is defined in Section 6.1 (urn:ietf:params:xml:ns:dht)

3.3. Fragmenting Large Values

Some DHT implementations may impose a limit on the size of value put on the DHT. Another layer is needed to split the large value into chunks of smaller values. The solution below is inspired from Merkle tree. The idea is to split a large data into a number of smaller pieces, hash those pieces, and then iteratively combine and rehash the resulting hashes in a tree-like fashion until a single root hash is created.

Suppose, the DHT limits the value to 1024 bytes, then the DHT value, if larger than 1024 bytes, is split into chunks of at most 1024 bytes. Each such chunk is stored on the DHT using the immutable data interface. Thus, each chunk is verifiable, i.e., integrity protected where the DHT key of the chunk is same as the hash of the chunk data. All the DHT keys of the children are stored in the DHT value of the parent.

To distinguish a fragmented value from an unfragmented value, a nul byte is prepended to the fragmented value. Thus, if the DHT value has the first byte as a nul character, then the rest of the value is assumed to be DHT keys of other chunks delimited by nul characters. The user agent should get all those chunks using get-immut, and concatenate the values to get the original DHT value.

3.4. RPC Protocol

For an external DHT architecture, we recommend using XML RPC to access the DHT API because of its simplicity. The list of XML RPC methodName and corresponding input (parameter) and output (return value) are shown below:

-----------------------------------------------
Procedure      Input            Output
-----------------------------------------------
put-auth       dhtRecord        boolean
remove-auth    dhtRecord        boolean
get-auth       dhtRecord        dhtRecords
get            dhtRecord        dhtRecords
put-immut      dhtRecord        boolean
get-immut      dhtRecord        dhtRecords
join           dhtService       dhtService
leave          dhtService       boolean
lookup         dhtService       dhtService
-----------------------------------------------

The dhtRecord, dhtRecords and dhtService elements are encoded using the string element of XML RPC. The special characters, < and &, are replaced by &lt; and &amp;, respectively in the binary string. Alternatively, base64 element may be used in which case the special characters are not replaced before encoding in base64. Example messages for a get request and response are shown below:

POST /RPC2 HTTP/1.0
User-Agent: Mozilla/1.0.7
Host: betty.userland.com
Content-Type: text/xml
Content-length: 236

<?xml version="1.0" encoding="UTF-8">
<methodCall>
 <methodName>get</methodName>
 <params>
  <param><value><string>representation of dhtRecord with
   replacement of special characters</string></value></param>
 </params>
</methodCall>

HTTP/1.1 200 OK
Connection: close
Content-Length: 221
Content-Type: text/xml
Date: Fri, 07 Apr 2006 19:55:08 GMT
Server: UserLand Frontier/5.1.2-WinNT

<?xml version="1.0" encoding="UTF-8"?>
<methodResponse>
 <params>
  <param><value><string>representation of dhtRecords with
   replacement of special characters</string></value></param>
 </params>
</methodResponse>

TBD: Should we define a SOAP-based interface also? The advantage of SOAP is that the dhtRecord, dhtRecords and dhtService can be explicitly used instead of converting and encapsulating in a string element.

The next section defines the DHT key and value format for SIP related location data.

4. Format for Location Data

The P2P-SIP design consists of many logical operations such as contact management, cryptographic key storage, NAT and firewall traversal, presence and offline message storage. In this section, we define the key and value of the DHT API for these operations.

4.1. Contact Management

The DHT interface is used to store the user contact information. For example, Bob stores his contacts using the DHT key as a SIP URI for his address-of-record (AOR), sip:bob@example.net, and the DHT value as a SIP URI for his contact, sip:bob@192.1.2.3:5060.

<key>sip:bob@example.net</key>
<value expires="2006-12-31T18:00:00Z" nonce="82771583614">
 <contacts xmlns="urn:ietf:params:xml:ns:p2p-sip">
  <contact displayName="Bob Wilson" expires="2006-12-31T18:00:00Z">
   sip:bob@192.1.2.3:5060
  </contact>
 </contacts>
</value>
<Signature>
  ...
  <KeyInfo><KeyName>bob@example.net</KeyName></KeyInfo>
</Signature>

The DHT stores the content of the value element, which is the contacts element in this case, as the DHT value. Note that the expires attribute of contact is not needed if the user sets the expiration for the DHT value.

This simple scheme allows multiple devices of the user to register under the same SIP AOR. Any public data such as user contacts on the DHT should be signed as described before, so that others can verify its validity. The caller verifies that the contacts retrieved from the DHT for bob@example.net are signed either by the user identity, bob@example.net, his domain example.net, or a mutually trusted certificate authority (CA) such as VeriSign. If the KeyInfo contains a KeyName, the user should also store his public key or certificate on the DHT as described next.

4.2. Key Storage

To avoid any central server, the certificates, keys, and any configuration are also stored on the DHT. For example, Bob can store his certificate with DHT key, certificate:bob@example.net, and DHT value as KeyInfo containing X509Data for X.509 certificate. Multiple certificates of Bob from different CAs can be put under the same DHT key. Since the information needs to be available to any potential caller, the value is unencrypted. An example is shown below. Note that the DHT value need not have the expires attribute (in which case the maximum time-to-live is DHT implementation dependent) and need not have a nonce (in which case it can not be explicitly removed).

<key>certificate:bob@example.net</key>
<value>
 <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
  <X509Data>
   <X509SubjectName>
    CN=bob@example.net,O=P2P Inc.,ST=New York,C=US
   </X509SubjectName>
   <X509Certificate>MIID5jCCA0+gA...lVN</X509Certificate>
  </X509Data>
 </KeyInfo>
</value>

The user can also store his private configuration information such as private key on the DHT. Thus, he can share the same configuration among multiple clients. However, this sensitive information in stored encrypted on the DHT. For example, Bob can store his encrypted private key with the DHT key, private:bob@example.net:secret. In addition to encrypting the private key with a secret, the secret is also used by Bob to generate the DHT key, so that other malicious users cannot pollute the values for k. Since the user chosen secret password is much easier to remember for the user than his private key, storing the encrypted private key on the DHT is helpful.

4.3. Presence

The presence data is handled differently because, unlike the contact information, which needs to be available to all the potential callers, the watcher list should be visible only to the presentity (the entity being watched). For example, if Alice wants to subscribe for the presence status of Bob, she puts her signed identity in Bob's watcher list with the DHT key, subscribe:presence:bob@example.net. The DHT value is encrypted using Bob's public key so that only Bob can decrypt watcher identity. This mechanism also works for events other than presence. An example is shown below:

<key>subscribe:presence:bob@example.net</key>
<value expires="2006-12-31T18:00:00Z" nonce="82771583615">
 <watchers xmlns="urn:ietf:params:xml:ns:p2p-sip">
  <watcher event="presence" entity="alice@home.com"
   expires="2006-12-31T18:00:00Z">
    sip:bob@example.net
  </watcher>
 </watchers>
</value>
<Signature>...</Signature>

Since this information needs to be encrypted, the value uses the W3C's EncryptedData element [w3c:encrypt] (Eastlake, D. and J. Reagle, “XML encryption syntax and processing,” December 2002.) instead. This document defines the default algorithms for EncryptionMethod as shown in the following example, hence may be skipped if using the default algorithms.

<value expires="2006-12-31T18:00:00Z" nonce="82771583615">
 <EncryptedData Type="urn:ietf:params:xml:ns:p2p-sip#watchers"
  xmlns="http://www.w3.org/2001/04/xmlenc#">
 <EncryptionMethod
   Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
 <ds:KeyInfo xmlns:ds="http://www.w3.org/2001/04/xmldsig#">
  <EncryptedKey CarriedKeyName="TempKey"
   xmlns="http://www.w3.org/2001/04/xmlenc#">
   <EncryptionMethod
    Algorithm="http://www.w3.org/2001/04/xmlenc#rsa1_5"/>
   <CipherData>
    <CipherValue>xyza21212sdfdsfs7989fsdbc</CipherValue>
   </CipherData>
  </EncryptedKey>
 <ds:KeyInfo>
 <CipherData>
  <CipherValue>A23B45C564587</CipherValue>
 </CipherData>
 </EncryptedData>
</value>

Additionally, Alice can store her encrypted friends list on the DHT similar to the private key storage described earlier.

4.4. Offline Messages

When Alice calls Bob, and Bob is not registered or does not pick up the phone, Alice can store an offline message (text or multimedia) with DHT key, offline:bob@example.net. When Bob comes back, he can retrieve his offline messages. The signing and encryption is similar to the watcher list.

An offline message is also stored as an EncryptedData element. The Type attribute refers to text or audio format for offline text or voice message, respectively.

The difference between storage of watcher list (presence data) and offline message is that the watcher list is periodically refreshed by the individual watchers, whereas the offline message is usually removed by the recipient after retrieval.

4.5. NAT and Firewall Traversal

SIP calls across NATs (Network Address Translators) or firewalls require media relay (e.g., TURN) and NAT detection service (e.g., STUN). A P2P-SIP node (user agent in Figure 1) implements both STUN and TURN servers, and provides these services to other users. The service is advertised in the DHT using the service interface.

Instead of using separate service namespaces for STUN, TURN and presence composition, we use a single service name, p2p-sip.

<namespace>urn:ietf:params:xml:ns:p2p-sip</namespace>
<serviceHosts>
 <serviceHost service="presence">sip:192.1.2.3:5060</serviceHost>
 <serviceHost service="turn">turn:192.1.2.3:3386</serviceHost>
</serviceHosts>

5. Implementation using Data or Service Models

There are two approaches to do the P2P-SIP operations of the previous section: any user directly updates the DHT (called as "data model") or forwards the request to the service node responsible for that user key ("service model").

5.1. Data Model

In this model the DHT is used as a shared data storage and the P2P-SIP operations are performed by the user by directly updating the corresponding DHT data. For example, a user stores his contact information and a caller stores the offline messages in the DHT. Similarly a P2P proxy updates the data in the DHT on behalf of the user to provide transparent SIP service to non-P2P users.

There are several limitations to this approach. For example, presence composition or programmable call routing are not easy to implement. Moreover, we need service discovery for STUN and TURN servers anyway. An alternative service model solves this problem as described below.

5.2. Service Model

In this model, every P2P-SIP client or proxy, joins the DHT for the p2p-sip service namespace. The p2p-sip service includes SIP registrar, presence agent, offline message storage, and STUN and TURN servers at the minimum.

When a user, Alice, wants to send a SIP message to, say sip:bob@example.net, she looks up the DHT to find the service node responsible for this user identifier, and sends the SIP request to that node. The service node acts as the proxy, registrar and presence server for all the users for which it is responsible. The service node also does any safe programmable call handling scripts and presence composition.

For signed or encrypted data such as contact information, there are two approaches: either the user sends the signed contacts in the SIP message or the user authorizes the service node to sign the contacts on his behalf. The first approach requires changes in existing SIP clients, whereas the second approach just uses a chain of certificates for verification of signed contacts.

The service model is more extensible than the data model. A P2P-SIP service node readily interworks with any non-P2P clients who just happen to know one or more service node addresses. The service mode readily extends to built-in DHT architecture since only the service interface (join and lookup) is used in the DHT, instead of the data interface (get and put) by the user agent.

Typically, the data interface can be built on top of the service interface. Note however that the ReDiR interface of OpenDHT [Rhea0510:opendht] (Rhea, S., Godfrey, B., Karp, B., Kubiatowicz, J., Ratnasamy, S., Shenker, S., Stoica, I., and H. Yu, “OpenDHT: a public DHT service and its uses,” August 2005.), which is a service interface, is in fact built on top of the data interface and resides purely on the client side.

6. XML Schema Definitions

This section gives the schema for DHT input and output, and data format for SIP related location data.

6.1. urn:ietf:params:xml:ns:dht

<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:dht"
  xmlns="http://www.w3.org/2001/XMLSchema"
  xmlns:d="urn:ietf:params:xml:ns:dht"
  xmlns:s="http://www.w3.org/2000/09/xmldsig#"
  elementFormDefault="qualified"
  attributeFormDefault="unqualified">

 <import namespace="http://www.w3.org/XML/1998/namespace"
   schemaLocation="http://www.w3.org/2001/xml.xsd"/>

 <element name="key" type="d:keyType"/>

 <complexType name="keyType">
  <union>
   <element ref="string"/>
   <element name="base64" type="Base64Binary"/>
   <sequence>
    <element ref="s:DigestMethod" minOccurs="0"/>
    <element ref="s:DigestValue"/>
   </sequence>
  </union>
  <attribute name="Id" type="ID" use="optional"/>
  <attribute name="reference" type="token" use="optional"/>
 </complexType>

 <element name="value" type="d:valueType"/>

 <complexType name="valueType">
  <choice>
   <element ref="string"/>
   <element name="base64" type="Base64Binary"/>
   <sequence>
    <element ref="s:DigestMethod" minOccurs="0"/>
    <element ref="s:DigestValue"/>
   </sequence>
   <any processContents="lax" namespace="##other"/>
  </choice>
  <attribute name="Id" type="ID" use="optional"/>
  <attribute name="reference" type="token" use="optional"/>
  <attribute name="expires" type="dateTime" use="optional"/>
  <attribute name="nonce" type="token" use="optional"/>
 </complexType>

 <element name="dhtRecord" type="d:dhtRecordType"/>

 <complexType name="dhtRecordType">
  <sequence>
   <element ref="d:key" minOccurs="0"/>
   <element ref="d:value" minOccurs="0"/>
   <element ref="s:Signature" minOccurs="0"/>
   <element ref="s:KeyInfo" minOccurs="0"/>
  </sequence>
  <attribute name="Id" type="ID" use="optional"/>
 </complextType>

 <element name="dhtRecords" type="d:dhtRecordsType"/>

 <complexType name="dhtRecordsType">
  <sequence>
   <element ref="d:dhtRecord" minOccurs="0" maxOccurs="unbounded"/>
  </sequence>
  <attribute name="Id" type="ID" use="optional"/>
 </complexType>

 <element name="dhtService" type="d:dhtServiceType"/>

 <complexType name="dhtServiceType">
  <sequence>
   <element name="namespace" type="anyURI" minOccurs="0"/>
   <element name="key" type="d:keyType" minOccurs="0"/>
   <element name="hostIdentifier" type="d:keyType" minOccurs="0"/>
   <element ref="d:serviceHosts" minOccurs="0"/>
  </sequence>
  <attribute name="Id" type="ID" use="optional"/>
 </complexType>

 <element name="serviceHosts" type="d:serviceHostsType"/>

 <complexType name="serviceHostsType">
  <sequence>
   <element ref="d:serviceHost" minOccurs="0" maxOccurs="unbounded"/>
  </sequence>
  <attribute name="Id" type="ID" use="optional"/>
 </complexType>

 <element name="serviceHost" type="d:serviceHostType"/>

 <complexType name="serviceHostType">
  <simpleContent>
   <extention base="anyURI">
    <attribute name="service" type="string" use="optional"/>
    <attribute name="Id" type="ID" use="optional"/>
   </extension>
  </simpleContent>
 </complexType>

</schema>

6.2. urn:ietf:params:xml:ns:p2p-sip

<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:p2p-sip"
  xmlns="http://www.w3.org/2001/XMLSchema"
  xmlns:p="urn:ietf:params:xml:ns:p2p-sip"
  elementFormDefault="qualified"
  attributeFormDefault="unqualified">

 <import namespace="http://www.w3.org/XML/1998/namespace"
   schemaLocation="http://www.w3.org/2001/xml.xsd"/>

 <element name="contacts" type="p:contactsType"/>

 <complexType name="contactsType">
  <sequence>
   <element name="contact" type="p:contactType"
    maxOccurs="unbounded"/>
  </sequence>
  <attribute name="Id" type="ID" use="optional"/>
 </complexType>

 <complexType name="contactType">
  <simpleContent>
   <extension base="anyURI">
    <attribute name="Id" type="ID" use="optional"/>
    <attribute name="user" type="anyURI" use="optional"/>
    <attribute name="displayName" type="string" use="optional"/>
    <attribute name="expires" type="dateTime" use="optional"/>
    <attribute name="priority" type="p:priority" use="optional"/>
   </extension>
  </simpleContent>
 </complexType>

 <simpleType name="priority">
  <restriction base="decimal">
   <pattern value="0(.[0-9]{0,3})?"/>
   <pattern value="1(.0{0,3})?"/>
  </restriction>
 </simpleType>

 <element name="watchers" type="p:watchersType"/>

 <complexType name="watchersType">
  <sequence>
   <element name="watcher" type="p:watcherType"
     maxOccurs="unbounded"/>
  </sequence>
  <attribute name="Id" type="ID" use="optional"/>
 </complexType>

 <complexType name="watcherType">
  <simpleContent>
   <extension base="anyURI">
    <attribute name="Id" type="ID" use="optional"/>
    <attribute name="entity" type="anyURI" use="optional"/>
    <attribute name="expires" type="dateTime" use="optional"/>
   </extension>
  </simpleContent>
 </complexType>

 <element name="presenceAgent" type="anyURI"/>

 <element name="turnServer" type="anyURI"/>

 <element name="stunServer" type="anyURI"/>

</schema>

7. IANA Considerations

7.1. URN Namespace Registration for 'urn:ietf:params:xml:ns:dht'

URI:

urn:ietf:params:xml:ns:dht

Description:

This is the XML namespace for XML elements defined by RFCXXXX [RFC editor: replace with RFC number] to describe distributed hash table's API.

Registrant Contact:

Henning Schulzrinne, hgs@cs.columbia.edu

XML:

BEGIN
 <?xml version="1.0"?>
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
 "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml"
 <head>
     <meta http-equiv="content-type"
     content="text/html;charset=iso-8859-1"/>
     <title>DHT API: Distributed Hash Table Application Programming
     Interface</title>
 </head>
 <body>
     <h1>Namespace for DHT API</h1>
     <h2>urn:ietf:params:xml:ns:dht</h2>
     <p>See <a href="URL of published RFC">RFC&rfc.number; [RFC
     editor: replace with RFC number]</a>.</p>
 </body>
 </html>
END

7.2. URN Namespace Registration for 'urn:ietf:params:xml:ns:p2p-sip'

URI:

urn:ietf:params:xml:ns:p2p-sip

Description:

This is the XML namespace for XML elements defined by RFCXXXX [RFC editor: replace with RFC number] to describe data format for SIP related location data.

Registrant Contact:

Henning Schulzrinne, hgs@cs.columbia.edu

XML:

BEGIN
 <?xml version="1.0"?>
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
 "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml"
 <head>
     <meta http-equiv="content-type"
     content="text/html;charset=iso-8859-1"/>
     <title>P2P-SIP: Peer-to-peer Internet telephony using
     SIP</title>
 </head>
 <body>
     <h1>Namespace for P2P-SIP data</h1>
     <h2>urn:ietf:params:xml:ns:p2p-sip</h2>
     <p>See <a href="URL of published RFC">RFC&rfc.number; [RFC
     editor: replace with RFC number]</a>.</p>
 </body>
 </html>
END

8. Security Considerations

In Figure 1, both the DHT API and the P2P protocol must be secured and protected against malicious users. This document deals with only the DHT API and the location data. The security of the P2P protocol is outside the scope. This works for externally managed DHT architecture with trusted nodes, e.g., OpenDHT (Rhea, S., “OpenDHT: A public distributed hash table service,” .) [web:opendht]. However, if potentially malicious nodes can form the DHT, the P2P protocol must be protected against misbehaving nodes for P2P-SIP to work securely.

Transport Layer Security (TLS) can be used for the RPC protocol to access the location data. The data stored on the DHT is signed and encrypted as described in this document.

9. References

9.1. Normative References

9.2. Informative References

Appendix A. Acknowledgements

The document reflects discussions with Salman Baset, Xiaotao Wu and Vishal Singh. The work is supported by grant from SIPquest Inc.

Authors' Addresses

Intellectual Property Statement

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.

Disclaimer of Validity

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

Copyright Statement

Copyright © The Internet Society (2006). 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.

Acknowledgment

Funding for the RFC Editor function is currently provided by the Internet Society.