Network Working Group K. Singh
Internet-Draft H. Schulzrinne
Expires: December 2, 2006 Department of Computer Science,
Columbia University
May 31, 2006
Data format and interface to an external peer-to-peer network for SIP
location service
draft-singh-p2p-sip-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 2, 2006.
Copyright Notice
Copyright (C) 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.
Singh & Schulzrinne Expires December 2, 2006 [Page 1]
Internet-Draft P2P-SIP May 2006
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 December 2, 2006 [Page 2]
Internet-Draft P2P-SIP May 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 December 2, 2006 [Page 3]
Internet-Draft P2P-SIP May 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 December 2, 2006 [Page 4]
Internet-Draft P2P-SIP May 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 December 2, 2006 [Page 5]
Internet-Draft P2P-SIP May 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 December 2, 2006 [Page 6]
Internet-Draft P2P-SIP May 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
sip:alice@example.net
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:
Y8eVClzbJ8Wk315al7pW6/RZsvM=
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:
sip:alice@192.1.2.3:5060
Singh & Schulzrinne Expires December 2, 2006 [Page 7]
Internet-Draft P2P-SIP May 2006
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 December 2, 2006 [Page 8]
Internet-Draft P2P-SIP May 2006
j6lwx3rvEPO0vKtMup4NbeVu8nk=
qZk+NkcGgWq6PiVxeFDCbJzQ2J0=
MC0CFFrVLtRlk=...
xA7SEU+e0yQH5rm9kbCDN9o3aPIo7HbP7tX6WOocLZAtNfyxSZDU16ksL6W
jubafOqNEpcwR3RdFsT7bCqnXPBe5ELh5u4VEy19MzxkXRgrMvavzyBpVRg
5foK5hhmbktQhyNdy/6LpQRhDUDsTvK+g9Ucj47es9AQJ3U=
AQAB
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 December 2, 2006 [Page 9]
Internet-Draft P2P-SIP May 2006
j6lwx3rvEPO0vKtMup4NbeVu8nk=
qZk+NkcGgWq6PiVxeFDCbJzQ2J0=
MC0CFFrVLtRlk=...
...
An example parameter for put-auth interface is shown below:
...
...
...
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.
...
...
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 December 2, 2006 [Page 10]
Internet-Draft P2P-SIP May 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 December 2, 2006 [Page 11]
Internet-Draft P2P-SIP May 2006
The dhtRecord, dhtRecords and dhtService elements are encoded using
the string element of XML RPC. The special characters, < and &, are
replaced by < and &, 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
get
representation of dhtRecord with
replacement of special characters
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
representation of dhtRecords with
replacement of special characters
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 December 2, 2006 [Page 12]
Internet-Draft P2P-SIP May 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.
sip:bob@example.net
sip:bob@192.1.2.3:5060
...
bob@example.net
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 December 2, 2006 [Page 13]
Internet-Draft P2P-SIP May 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).
certificate:bob@example.net
CN=bob@example.net,O=P2P Inc.,ST=New York,C=US
MIID5jCCA0+gA...lVN
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 December 2, 2006 [Page 14]
Internet-Draft P2P-SIP May 2006
subscribe:presence:bob@example.net
sip:bob@example.net
...
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.
xyza21212sdfdsfs7989fsdbc
A23B45C564587
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 December 2, 2006 [Page 15]
Internet-Draft P2P-SIP May 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.
urn:ietf:params:xml:ns:p2p-sip
sip:192.1.2.3:5060
turn:192.1.2.3:3386
Singh & Schulzrinne Expires December 2, 2006 [Page 16]
Internet-Draft P2P-SIP May 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 December 2, 2006 [Page 17]
Internet-Draft P2P-SIP May 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 December 2, 2006 [Page 18]
Internet-Draft P2P-SIP May 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
Singh & Schulzrinne Expires December 2, 2006 [Page 19]
Internet-Draft P2P-SIP May 2006
Singh & Schulzrinne Expires December 2, 2006 [Page 20]
Internet-Draft P2P-SIP May 2006
6.2. urn:ietf:params:xml:ns:p2p-sip
Singh & Schulzrinne Expires December 2, 2006 [Page 21]
Internet-Draft P2P-SIP May 2006
Singh & Schulzrinne Expires December 2, 2006 [Page 22]
Internet-Draft P2P-SIP May 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
DHT API: Distributed Hash Table Application Programming
Interface
Namespace for DHT API
urn:ietf:params:xml:ns:dht
See RFC&rfc.number; [RFC
editor: replace with RFC number].