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 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 June 4, 2007 [Page 7] Internet-Draft P2P-SIP Dec 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 June 4, 2007 [Page 8] Internet-Draft P2P-SIP Dec 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 June 4, 2007 [Page 9] Internet-Draft P2P-SIP Dec 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 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 < 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 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. 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 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). 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 June 4, 2007 [Page 14] Internet-Draft P2P-SIP Dec 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 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. urn:ietf:params:xml:ns:p2p-sip sip:192.1.2.3:5060 turn:192.1.2.3:3386 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 Singh & Schulzrinne Expires June 4, 2007 [Page 19] Internet-Draft P2P-SIP Dec 2006 Singh & Schulzrinne Expires June 4, 2007 [Page 20] Internet-Draft P2P-SIP Dec 2006 6.2. urn:ietf:params:xml:ns:p2p-sip Singh & Schulzrinne Expires June 4, 2007 [Page 21] Internet-Draft P2P-SIP Dec 2006 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 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].

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 P2P-SIP: Peer-to-peer Internet telephony using SIP

Namespace for P2P-SIP data

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

See RFC&rfc.number; [RFC editor: replace with RFC number].

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, . [w3c:sign] Eastlake, D., Reagle, J., and D. Solo, "XML-signature syntax and processing", February 2002, . 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, . [Sing0602:Using] Singh, K. and H. Schulzrinne, "Using an external DHT as a SIP location service", Feb 2006, . [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, . [web:opendht] Rhea, S., "OpenDHT: A public distributed hash table service", . Singh & Schulzrinne Expires June 4, 2007 [Page 26] Internet-Draft P2P-SIP Dec 2006 URIs [1] 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]