Network Working Group                                           K. Singh
Internet-Draft                                            H. Schulzrinne
Intended status: Standards Track        Department of Computer Science,
Expires: June 4, 2007                                Columbia University
                                                                Dec 2006


 Data format and interface to an external peer-to-peer network for SIP
                            location service
                         draft-singh-p2p-sip-01

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 June 4, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).












Singh & Schulzrinne       Expires June 4, 2007                  [Page 1]


Internet-Draft                   P2P-SIP                        Dec 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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Scope of This Document . . . . . . . . . . . . . . . . . . . .  5
   3.  DHT API  . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  6
       3.1.1.  Signed Data  . . . . . . . . . . . . . . . . . . . . .  6
       3.1.2.  Immutable Data . . . . . . . . . . . . . . . . . . . .  6
       3.1.3.  Service Interface  . . . . . . . . . . . . . . . . . .  7
     3.2.  XML Format for Input and Output  . . . . . . . . . . . . .  7
     3.3.  Fragmenting Large Values . . . . . . . . . . . . . . . . . 11
     3.4.  RPC Protocol . . . . . . . . . . . . . . . . . . . . . . . 11
   4.  Format for Location Data . . . . . . . . . . . . . . . . . . . 13
     4.1.  Contact Management . . . . . . . . . . . . . . . . . . . . 13
     4.2.  Key Storage  . . . . . . . . . . . . . . . . . . . . . . . 13
     4.3.  Presence . . . . . . . . . . . . . . . . . . . . . . . . . 14
     4.4.  Offline Messages . . . . . . . . . . . . . . . . . . . . . 15
     4.5.  NAT and Firewall Traversal . . . . . . . . . . . . . . . . 16
   5.  Implementation using Data or Service Models  . . . . . . . . . 17
     5.1.  Data Model . . . . . . . . . . . . . . . . . . . . . . . . 17
     5.2.  Service Model  . . . . . . . . . . . . . . . . . . . . . . 17
   6.  XML Schema Definitions . . . . . . . . . . . . . . . . . . . . 19
     6.1.  urn:ietf:params:xml:ns:dht . . . . . . . . . . . . . . . . 19
     6.2.  urn:ietf:params:xml:ns:p2p-sip . . . . . . . . . . . . . . 21
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
     7.1.  URN Namespace Registration for
           'urn:ietf:params:xml:ns:dht' . . . . . . . . . . . . . . . 23
     7.2.  URN Namespace Registration for
           'urn:ietf:params:xml:ns:p2p-sip' . . . . . . . . . . . . . 23
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 26
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 26
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
   Intellectual Property and Copyright Statements . . . . . . . . . . 30








Singh & Schulzrinne       Expires June 4, 2007                  [Page 2]


Internet-Draft                   P2P-SIP                        Dec 2006


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

                                 Figure 1

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



Singh & Schulzrinne       Expires June 4, 2007                  [Page 3]


Internet-Draft                   P2P-SIP                        Dec 2006


   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 and Section 4, respectively.










































Singh & Schulzrinne       Expires June 4, 2007                  [Page 4]


Internet-Draft                   P2P-SIP                        Dec 2006


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 [RFC3261].
   This document does not propose any change in SIP.  We propose only an
   interface and data format independent of any specific P2P algorithm.













































Singh & Schulzrinne       Expires June 4, 2007                  [Page 5]


Internet-Draft                   P2P-SIP                        Dec 2006


3.  DHT API

3.1.  Overview

   The DHT API presented here consists of data and service interfaces,
   and is based on OpenDHT [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



Singh & Schulzrinne       Expires June 4, 2007                  [Page 6]


Internet-Draft                   P2P-SIP                        Dec 2006


   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.

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>



Singh & Schulzrinne       Expires June 4, 2007                  [Page 7]


Internet-Draft                   P2P-SIP                        Dec 2006


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








































Singh & Schulzrinne       Expires June 4, 2007                  [Page 8]


Internet-Draft                   P2P-SIP                        Dec 2006


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




Singh & Schulzrinne       Expires June 4, 2007                  [Page 9]


Internet-Draft                   P2P-SIP                        Dec 2006


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



Singh & Schulzrinne       Expires June 4, 2007                 [Page 10]


Internet-Draft                   P2P-SIP                        Dec 2006


   The complete XML schema for input and output of DHT interface is
   defined in Section 6.1

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 [1] 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
   -----------------------------------------------



Singh & Schulzrinne       Expires June 4, 2007                 [Page 11]


Internet-Draft                   P2P-SIP                        Dec 2006


   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.







Singh & Schulzrinne       Expires June 4, 2007                 [Page 12]


Internet-Draft                   P2P-SIP                        Dec 2006


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



Singh & Schulzrinne       Expires June 4, 2007                 [Page 13]


Internet-Draft                   P2P-SIP                        Dec 2006


   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:









Singh & Schulzrinne       Expires June 4, 2007                 [Page 14]


Internet-Draft                   P2P-SIP                        Dec 2006


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



Singh & Schulzrinne       Expires June 4, 2007                 [Page 15]


Internet-Draft                   P2P-SIP                        Dec 2006


   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>


























Singh & Schulzrinne       Expires June 4, 2007                 [Page 16]


Internet-Draft                   P2P-SIP                        Dec 2006


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



Singh & Schulzrinne       Expires June 4, 2007                 [Page 17]


Internet-Draft                   P2P-SIP                        Dec 2006


   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], which is a service interface, is in fact built on
   top of the data interface and resides purely on the client side.












































Singh & Schulzrinne       Expires June 4, 2007                 [Page 18]


Internet-Draft                   P2P-SIP                        Dec 2006


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"/>



Singh & Schulzrinne       Expires June 4, 2007                 [Page 19]


Internet-Draft                   P2P-SIP                        Dec 2006


     <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"/>



Singh & Schulzrinne       Expires June 4, 2007                 [Page 20]


Internet-Draft                   P2P-SIP                        Dec 2006


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




Singh & Schulzrinne       Expires June 4, 2007                 [Page 21]


Internet-Draft                   P2P-SIP                        Dec 2006


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

















Singh & Schulzrinne       Expires June 4, 2007                 [Page 22]


Internet-Draft                   P2P-SIP                        Dec 2006


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







Singh & Schulzrinne       Expires June 4, 2007                 [Page 23]


Internet-Draft                   P2P-SIP                        Dec 2006


   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





























Singh & Schulzrinne       Expires June 4, 2007                 [Page 24]


Internet-Draft                   P2P-SIP                        Dec 2006


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





































Singh & Schulzrinne       Expires June 4, 2007                 [Page 25]


Internet-Draft                   P2P-SIP                        Dec 2006


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3174]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
              (SHA1)", RFC 3174, September 2001.

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

   [w3c:encrypt]
              Eastlake, D. and J. Reagle, "XML encryption syntax and
              processing", December 2002,
              <http://www.w3.org/TR/xmlenc-core/>.

   [w3c:sign]
              Eastlake, D., Reagle, J., and D. Solo, "XML-signature
              syntax and processing", February 2002,
              <http://www.w3.org/TR/xmldsig-core/>.

9.2.  Informative References

   [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,
              <http://portal.acm.org/
              ft_gateway.cfm?id=1080102&type=pdf>.

   [Sing0602:Using]
              Singh, K. and H. Schulzrinne, "Using an external DHT as a
              SIP location service", Feb 2006, <http://
              mice.cs.columbia.edu/getTechreport.php?techreportID=388>.

   [Stoc0108:Chord]
              Stoica, I., Morris, R., Karger, D., Kaashoek, F., and H.
              Balakrishnan, "Chord: A scalable peer-to-peer lookup
              service for internet applications", August 2001,
              <http://www.pdos.lcs.mit.edu/papers/chord:sigcomm01/>.

   [web:opendht]
              Rhea, S., "OpenDHT: A public distributed hash table
              service", <http://www.opendht.org>.



Singh & Schulzrinne       Expires June 4, 2007                 [Page 26]


Internet-Draft                   P2P-SIP                        Dec 2006


URIs

   [1]  <http://www.xmlrpc.com>
















































Singh & Schulzrinne       Expires June 4, 2007                 [Page 27]


Internet-Draft                   P2P-SIP                        Dec 2006


Appendix A.  Acknowledgements

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















































Singh & Schulzrinne       Expires June 4, 2007                 [Page 28]


Internet-Draft                   P2P-SIP                        Dec 2006


Authors' Addresses

   Kundan N. Singh
   Department of Computer Science, Columbia University
   1214 Amsterdam Avenue
   MC 0401
   New York, NY  10027
   US

   Email: kns10@cs.columbia.edu


   Henning G. Schulzrinne
   Department of Computer Science, Columbia University
   1214 Amsterdam Avenue
   MC 0401
   New York, NY  10027
   US

   Email: hgs@cs.columbia.edu































Singh & Schulzrinne       Expires June 4, 2007                 [Page 29]


Internet-Draft                   P2P-SIP                        Dec 2006


Full Copyright Statement

   Copyright (C) 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.

   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.


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





Singh & Schulzrinne       Expires June 4, 2007                 [Page 30]