One document matched: draft-bryan-p2psip-dsip-00.txt
P2PSIP D. Bryan
Internet-Draft SIPeerior Technologies, Inc.
Intended status: Standards Track B. Lowekamp
Expires: August 29, 2007 SIPeerior; William & Mary
C. Jennings
Cisco Systems
February 25, 2007
dSIP: A P2P Approach to SIP Registration and Resource Location
draft-bryan-p2psip-dsip-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 August 29, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document outlines the motivation, requirements, and
architectural design for a distributed Session Initiation Protocol
(dSIP). dSIP is a Peer-to-Peer (P2P) based approach for SIP
registration and resource discovery using distributed hash tables
maintained with SIP messages. This design removes the need for
Bryan, et al. Expires August 29, 2007 [Page 1]
Internet-Draft dSIP February 2007
central servers from SIP, while offering full backward compatibility
with SIP, allowing reuse of existing clients, and allowing P2P
enabled peers to communicate with conventional SIP entities. A basic
introduction to the concepts of P2P is presented, backward
compatibility issues addressed, and security considerations are
discussed.
dSIP is one possible implementation of the protocols being discussed
for creation in the P2PSIP WG. In the context of the work being
proposed, this draft represents a concrete proposal for the P2PSIP
Peer Protocol, using SIP with extensions as the underlying protocol.
In this architecture, no P2PSIP Client Protocol is needed, rather
unmodified SIP is used for access by non-peers.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Peer-to-Peer Fundamentals . . . . . . . . . . . . . . . . 6
3.2. DHTs and Overlay Structure . . . . . . . . . . . . . . . . 7
3.3. P2PSIP . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. The Architecture of dSIP . . . . . . . . . . . . . . . . . . . 8
4.1. Peer Functions and Behavior in dSIP . . . . . . . 9
4.2. P2P Overlay Structure . . . . . . . . . . . . . . . . . . 10
4.3. Use of SIP Messages in dSIP . . . . . . . . . . . . . . . 11
4.4. Routing in dSIP . . . . . . . . . . . . . . . . . . . . . 12
4.4.1. dSIP Operations . . . . . . . . . . . . . . . . . . . 13
4.5. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 15
5. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Option Tags . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. Hash Algorithms and Identifiers . . . . . . . . . . . . . 16
5.2.1. Peer-IDs . . . . . . . . . . . . . . . . . . . . . . . 16
5.2.2. Resource-IDs and the Replication . . . . . . . . . . . 17
5.3. P2PSIP URIs . . . . . . . . . . . . . . . . . . . . . . . 17
5.3.1. Peer URIs . . . . . . . . . . . . . . . . . . . . . . 17
5.3.2. Resource URIs and the resource-ID URI Parameter . . . 18
5.4. The DHT-PeerID Header and Overlay Parameters . . . . . . . 19
5.4.1. Hash Algorithms and the algorithm Parameter . . . . . 19
5.4.2. Overlay Names and the overlay Parameter . . . . . . . 20
5.4.3. DHT Algorithms and the dht Parameter . . . . . . . . . 21
5.4.4. PeerID Expires header parameter . . . . . . . . . . . 21
5.5. The DHT-Link Header . . . . . . . . . . . . . . . . . . . 21
5.5.1. Expires Processing . . . . . . . . . . . . . . . . . . 22
6. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Peer Registration . . . . . . . . . . . . . . . . . . . . 23
Bryan, et al. Expires August 29, 2007 [Page 2]
Internet-Draft dSIP February 2007
6.2. Resource Registration . . . . . . . . . . . . . . . . . . 23
6.3. Session Establishment . . . . . . . . . . . . . . . . . . 24
6.4. DHT Maintenance . . . . . . . . . . . . . . . . . . . . . 24
7. Peer/DHT Operations . . . . . . . . . . . . . . . . . . . . . 25
7.1. Peer Registration . . . . . . . . . . . . . . . . . . . . 25
7.1.1. Constructing a Peer Registration . . . . . . . . . . . 25
7.1.2. Processing the Peer Registration . . . . . . . . . . . 27
7.2. Peer Query . . . . . . . . . . . . . . . . . . . . . . . . 29
7.2.1. Constructing a Peer Query Message . . . . . . . . . . 29
7.2.2. Processing Peer Query Message . . . . . . . . . . . . 30
7.3. Populating the Joining Peer's Routing Table . . . . . . . 31
7.4. Transfering User Registrations . . . . . . . . . . . . . . 31
7.5. Peers Leaving the Overlay Gracefully . . . . . . . . . . . 31
7.6. NAT and Firewall Traversal . . . . . . . . . . . . . . . . 32
7.7. Handling Failed Requests . . . . . . . . . . . . . . . . . 32
8. Resource Operations . . . . . . . . . . . . . . . . . . . . . 32
8.1. Resource Registrations . . . . . . . . . . . . . . . . . . 32
8.2. Refreshing Resource Registrations . . . . . . . . . . . . 33
8.3. Removing Resource Registrations . . . . . . . . . . . . . 34
8.4. Querying Resource Registrations . . . . . . . . . . . . . 34
8.5. Session Establishment . . . . . . . . . . . . . . . . . . 34
8.6. Presence . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.7. Offline Storage . . . . . . . . . . . . . . . . . . . . . 35
9. Pluggable DHT Algorithm Requirements . . . . . . . . . 35
10. Security Considerations . . . . . . . . . . . . . . . . . . . 36
10.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 36
10.2. Protecting the ID Namespace . . . . . . . . . . . . . . . 37
10.2.1. Protection Using ID Hashing . . . . . . . . . . . . . 37
10.2.2. Cryptographic Protection . . . . . . . . . . . . . . . 38
10.3. Protecting the resource namespace . . . . . . . . . . . . 38
10.4. Protecting the Routing . . . . . . . . . . . . . . . . . . 39
10.5. Protecting the Signaling . . . . . . . . . . . . . . . . . 39
10.6. Protecting the Media . . . . . . . . . . . . . . . . . . . 39
10.7. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 39
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 39
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
14. Changes to this Version . . . . . . . . . . . . . . . . . . . 40
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
15.1. Normative References . . . . . . . . . . . . . . . . . . . 41
15.2. Informative References . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . . . . 44
Bryan, et al. Expires August 29, 2007 [Page 3]
Internet-Draft dSIP February 2007
1. Introduction
As SIP [1] and SIMPLE based Voice over IP (VoIP) and Instant
Messaging (IM) systems have increased in popularity, situations have
emerged where centralized servers are either inconvenient or
undesirable. For example, a group of users wishing to communicate
between each other, but using machines that are not consistently
connected to the network, are often forced to use a central server
that is outside the control of the group. Similarly, groups wishing
to establish ephemeral networks for use in meetings, conferences, or
classes often do not wish to configure a centralized server.
Organizations may also want to allow their members to communicate
with each other without traffic flowing to third parties, but may not
have the staff or equipment to maintain a server.
Peer-to-Peer (P2P) computing has emerged as a mechanism for
completely decentralized, server-free implementations of various
applications. In particular, many recent efforts have focused on
applying P2P to SIP within the IETF, starting with the forerunners of
this document submitted by the authors. Since then a substantial
usecases document [15] has emerged and, most recently, a concepts and
terminology [2] document has helped define a common set of terms.
This iteration of this document incorporates the terminology from
that draft.
This draft presents dSIP, a SIP based system that uses P2P mechanisms
to remove the need for central servers in SIP and SIMPLE based
communications systems. While this draft evolved from early work
done on the SoSIMPLE [16] P2PSIP project, it has changed extensively.
This works reflects experience gained in actually building
commercially available P2PSIP products based on this draft, as well
as from extensive work/insight gleaned from the P2PSIP mailing list.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3].
Terminology defined in RFC 3261 [1] is used without definition.
We use the terminology and definitions from the Concepts and
Terminology for Peer to Peer SIP [2] draft extensively in this
document without further definition. Other terms used in this
document are defined inline when used and are also defined below for
reference.
Bryan, et al. Expires August 29, 2007 [Page 4]
Internet-Draft dSIP February 2007
In this illustrative purposes in this document we sometimes use 10
hexadecimal digit values for SHA-1 hashes. In reality, SHA-1
produces 40 digit values. They are shortened in this document for
clarity and typographical considerations only.
2.1. Definitions
Peer-to-Peer (P2P) Architecture: An architecture in which peer nodes
cooperate together to perform tasks. Each peer has essentially
equal importance and performs the same tasks within the network.
Additionally, peers communicate directly with one another to
perform tasks. Contrast this to a Client-Server architecture.
Client-Server Architecture: An architecture in which some small
number of nodes (servers) provide services to a larger number of
nodes (clients). Client nodes initiate connections to servers,
but typically do not communicate among themselves.
Conventional SIP: The architecture used by SIP as defined by
RFC3261, RFC3263, and many others. Conventional SIP centralizes
certain roles, such as registrar, but allows for direct end-to-end
establishment of dialogs and media connections.
Distributed Hash Table (DHT): A mechanism in which resources are
given a unique key produced by hashing some attribute of the
resource, locating them in a hash space (see below). Peers
located in this hash space also have a unique ID within the hash
space. Peers store information about resources with keys that are
numerically similar to the peer's ID in the hash space.
Namespace or hash space: The range of values that valid results from
the hash algorithm fall into. For example, using the SHA-1
algorithm, the namespace is all 40 digit hexadecimal identifiers.
This namespace forms the set of valid values for Peer-IDs and
Resource-IDs (see below).
Routing Table: The list of peers that a peer uses to send messages
to when routing. The structure and makeup of this table varies
depending on the particular DHT selected.
Connection Table: A list of peers that the peer currently is
maintaining open connections to. In general, this is a superset
of the Routing Table. The extra entries may be cached entries for
efficiency or additional entries needed for NAT traversal
purposes.
Neighbors: A collection of peers that a particular peer can reach in
one hop. In general, note that a peer's set of neighbors is
equivalent to the entries in that peer's Routing Table. However,
neighbors may include one or more peers that immediately precede
the peer (predecessors) and one or more peers that immediately
follow the peer in the namespace (successor peers). Note that
neighbor relations do NOT have to be symmetric.
Bryan, et al. Expires August 29, 2007 [Page 5]
Internet-Draft dSIP February 2007
Adapter Peer: An adapter peer is a peer in the overlay that acts as
an adapter for other non-P2P enabled SIP entities, allowing them
to access the resources of the overlay. The adapter peer
participates actively in the overlay network, while the non-P2P
enabled SIP entities it provides service to DO NOT participate
directly in the overlay. Compare these to the term "super peer"
in the P2P community, although adapter peers may be thin software
shims intended for only one client.
Peer Admission: The act of a peer joining the overlay. Registration
allows a peer to communicate with other peers, and requires
(allows?) it to take on some server-like responsibilities such as
maintaining resource location information. It DOES NOT register
the user so that they can receive phone calls, which is the
conventional SIP use of the word registration. We refer to
conventional SIP registration as "user registration".
User Registration: The act of a user registering themselves with a
SIP network. User registration creates a mapping between a SIP
URI and a contact for a user. This is the conventional meaning of
registration in SIP. For a dSIP peer, this action MUST occur
after peer registration. User or resource registration are terms
used in this draft to refer to P2PSIP Resource Record Insertion,
with the additional requirement that the resource's (user's) peer
must first be admitted.
Joining Peer: During the peer admission process, this is the peer
that is attempting to register -- that is, the peer that is
attempting to join the overlay network.
Bootstrap Peer: During the process of peer registration, the
bootstrap peer is the peer that the joining peer contacts. This
peer may be a well-known peer, a peer located using a broadcast
method, a peer that the joining peer previously knew about, or a
peer that another bootstrap peer referred the joining peer to.
The bootstrap peer MAY validate the joining peer's credentials and
help the joining peer in opening connections to the admitting
peer, but its primary purpose is to direct the joining peer to the
admitting peer.
Admitting Peer: During the process of peer registration, this is the
peer that is currently responsible for the portion of the
namespace the new peer will eventually reside in. This peer is
responsible for generating many of the messages exchanged during
peer registration.
3. Background
3.1. Peer-to-Peer Fundamentals
The fundamental principle behind Peer-to-Peer (P2P) Architectures is
that applications are provided by number of entities, called peers or
Bryan, et al. Expires August 29, 2007 [Page 6]
Internet-Draft dSIP February 2007
nodes working together with each other to accomplish tasks. Each and
every peer is responsible for contributing to serving some of the
transactions that take place on the network. Contrast this with the
more traditional Client-Server Architecture in which a large number
of clients communicate only with a small number of central servers
responsible for performing tasks.
Each peer provides server-like functionality and services as well as
being a client within the system. In this way, the services or
resources that would be provided by a centralized entity are instead
available in a distributed fashion from the peers of the system.
Note that a particular peer may or may not provide a particular
service, but some peer does, ensuring that collectively the peers can
provide that particular service. The peers form a logical cluster of
peers called an overlay or overlay network. The services provided
are often said to be provided by the overlay, since collectively the
members provide the services. The overlay is so named because they
form a new, small sub-network at a higher logical level than lower
level network connections.
In many P2P systems peers are assumed to be ephemeral in nature. A
peer may join or leave the overlay at any time. The design of
algorithms for P2P architectures take this into account. Information
is replicated, and the topology of the overlay can be quickly adapted
as peers enter and leave.
3.2. DHTs and Overlay Structure
While very early P2P systems used flood based techniques, most newer
P2P systems locate resources using a Distributed Hash Table, or DHT
to improve efficiency. Peers are organized using a Distributed Hash
Table (DHT) structure. In such a system, every resource has a
Resource-ID, which is obtained by hashing some keyword or value that
uniquely identifies the resource. Resources can be thought of as
being stored in a hash table at the entry corresponding to their
Resource-ID. The peers that make up the overlay network are also
assigned an ID, called a Peer-ID, in the same hash space as the
Resource-IDs. A peer is responsible for storing all resources that
have Resource-IDs near the peer's Peer-ID. The hash space is divided
up so that all of the hash space is always the responsibility of some
particular peer, although as peers enter and leave the system a
particular peer's area may change. Messages are exchanged between
the peers in the DHT as the peers enter and leave to preserve the
structure of the DHT and exchange stored entries. Various DHT
implementations may visualize the hash space as a grid, circle, or
line.
Peers keep information about the location of other peers in the hash
Bryan, et al. Expires August 29, 2007 [Page 7]
Internet-Draft dSIP February 2007
space and typically know about many peers nearby in the hash space,
and progressively fewer more distant peers. We refer to this table
of other peers as a Routing Table. When a user wishes to search,
they consult the list of peers they are aware of and contact the peer
with the Peer-ID nearest the desired Resource-ID. If that peer does
not know how to find the resource, it either returns information
about a closer peer it knows about, or forwards the request to a
closer peer. In this fashion, the request eventually reaches the
peer responsible for the resource, which then replies to the
requester.
3.3. P2PSIP
Unlike a conventional SIP architecture, P2PSIP systems require no
central servers. In a conventional SIP architecture many UAs connect
to one or more central servers which play a number of roles,
including proxy server, registrar, presence server, and redirect
server. In a P2PSIP architecture, the peers participating in the
overlay not only act as conventional SIP UAs, allowing their users to
place and receive calls, but, when viewed collectively with the other
peers, perform the roles normally provided by a central server. Each
participating peer will maintain some fraction of the information
that would normally be maintained by the central servers in a
conventional SIP network.
P2PSIP peers provide many functions, more than any single entity in a
conventional SIP architecture. Minimally, a participating peer must
be an active member of the overlay, participating in storage of
resources, routing and providing some SIP "server-like" behaviors as
well. In the terminology used in the concepts draft, these peers
speak the P2PSIP Peer Protocol to organize among themselves.
The general concepts are more fully explained in the Concepts and
Terminology for Peer to Peer SIP [2] draft.
4. The Architecture of dSIP
In this section we provide an overview of the architecture of dSIP
and explain how it works in an informative way. Protocol details and
syntax are provided in a normative form in the remainder of the
document.
dSIP is a specific proposal for the P2PSIP Peer Protocol proposed in
the Concepts and Terminology for Peer to Peer SIP [2] draft, using
SIP messages as the syntax for encoding the protocol. The function
of the P2PSIP Peer Protocol is to provide for mechanisms to maintain
the overlay, as well as to store and retrieve information, and to
Bryan, et al. Expires August 29, 2007 [Page 8]
Internet-Draft dSIP February 2007
route messages when needed. dSIP's syntax is SIP with a number of
newly defined headers, however no new methods are added to SIP in
dSIP.
Because dSIP uses conventional SIP messages, the mechanisms used for
NAT traversal in SIP, including STUN [4], TURN [17], and ICE [5] are
reused, as explained in NAT Traversal for dSIP [6]. As a
consequence, many peers are able to participate in the overlay even
when behind NATs. For those that cannot for some reason,
conventional SIP can be used, and these peers can connect using
adapter peers, as described below. Since conventional SIP is used
for this, there is no need for a P2PSIP Client Protocol, and
therefore dSIP defines no such protocol.
dSIP is modular, allowing for the use of multiple DHTs, including
those defined later. DHTs can be negotiated among the peers in much
the same way as codecs or features are negotiated in conventional
SIP. For compatibility, support for one basic DHT algorithm, Chord,
is required. Additional DHTs can be added and supported. We detail
the Chord algorithm for dSIP [7] and provide an alternate DHT
algorithm for dSIP, based on Bamboo [8]. Note that this document
does not specify the details of the DHTs, including Chord. These are
defined in their own documents, which describe how the basic dSIP
operations and syntax are used to implement that specific DHT
algorithms. Our intention and hope is that others will design other
overlay algorithms that rely on the same basic operations so that
compatibility can be maintained.
4.1. Peer Functions and Behavior in dSIP
dSIP peers provide many functions, more than any single entity in a
conventional SIP architecture. Minimally, a participating peer must
be an active member of the overlay and must provide some SIP "server-
like" behaviors as well. The code that implements the additional
server-like and DHT behavior can be located in several places in the
network. The simplest is to have peers that are endpoints directly
joining the overlay as peers. In this case, these peers provide the
basic functionality of any SIP endpoint, but additionally implement
the operations described in this document to enable self-organization
and provide SIP server-like functionality.
The behavior can also be located in an adapter peer, which allows one
or more non-P2P aware SIP UAs (UAs that do not speak dSIP) to
interact with the P2P overlay network. These adapters perform the
additional self-organizing and SIP server-like behavior on behalf of
the UA or UAs they support. In this case, only the adapter peer is a
peer in the overlay, the UAs are not peers themselves. In this
approach, the adaptors speak the P2PSIP Peer Protocol (dSIP in this
Bryan, et al. Expires August 29, 2007 [Page 9]
Internet-Draft dSIP February 2007
case), where the UAs speak conventional SIP. All interaction with
the P2P overlay is carried out by the adapter peer. The adapter
essentially acts as a proxy server for the unmodified SIP UAs. The
adapter can take the form of a small software shim or may be code
within a conventional RFC 3261 server.
In most places in this document, which type of peer we are discussing
won't affect the discussion. In those cases where it will, we have
noted the differences.
4.2. P2P Overlay Structure
The P2P overlay in dSIP consists of peers, which collectively serve
as a directory service for locating resources (users, voicemail
messages, etc.). Peers are organized using a supported Distributed
Hash Table (DHT) P2P structure. dSIP allows for pluggable DHT
algorithms the exact form of which is defined in the DHT algorithm
definition.
Each peer is assigned a Peer-ID, and each resource that is stored in
the overlay is assigned a Resource-ID. These values must map to the
same name space. dSIP provides for various algorithms to be used to
produce these values, although all members of the overlay must use
the same algorithm. For example, in the Chord DHT implementation,
SHA-1 is used to produce 160 bit values for both the Peer-ID and
Resource-ID.
The Peer-ID assigned to each peer determines the peer's location in
the DHT and the range of Resource-IDs for which it will be
responsible. The exact mapping between these is determined by the
DHT algorithm used by the overlay. The mechanism for selecting these
Peer-IDs depends on the security mechanism being used by the overlay.
For example, a simple SHA-1 hash of the IP address and the port of
the peer could be used to generate the Peer-IDs or alternatively, a
certificate based system in which CAs assign Peer-IDs could be used
to obtain the Peer-IDs [9].
Every resource has a Resource-ID, obtained by hashing some keyword
that identifies the resource. The Resource-IDs map to the same space
as the Peer-IDs. In the case of users, the unique keyword is the
userid and the resource is the registration -- a mapping between the
user name and a contact. Resources can be thought of as being stored
in the distributed hash table at a location corresponding to their
Resource-ID. Because entities searching for resources must be able
to locate them given the unique keyword, Resource-IDs are produced by
hashing, and are never assigned, regardless of the DHT and security
algorithms being used.
Bryan, et al. Expires August 29, 2007 [Page 10]
Internet-Draft dSIP February 2007
A resource with Resource-ID k will be stored by the peer with Peer-ID
closest to the Resource-ID, as defined by the particular pluggable
DHT algorithm being used. As peers enter and leave, resources may be
stored on different peers, so the information related to them is
exchanged as peers enter and leave. Redundancy is used to protect
against loss of information in the event of a peer failure and to
protect against compromised or subversive peers.
Since each DHT is defined and functions differently, we generically
refer to the table of other peers that the DHT maintains and uses to
route requests (neighbors) as a Routing Table. dSIP defines the
syntax for the headers used to exchange these entries, but leaves the
exact form of the data each DHT stores in the table as a decision for
the DHT implementation. Peers may additionally maintain a list of
peers to which they maintain connections for purposes other than
routing, for example NAT traversal or caching. This larger table
(usually a superset of the routing table) is referred to as the
connection table in dSIP. In this draft, we refer to routing
decisions being made from the entries in the routing table, although
a peer might choose an entry from the connection table if it is a
better match.
When locating a resource with a particular Resource-ID, the peer will
send the request to the routing table entry with the Peer-ID closest
to the desired Resource-ID, as defined by the particular DHT in use.
Since DHTs must converge on the resource, the peer receiving the
request is assumed to know of a peer with a Peer-ID closer to the
Resource-ID, and responds by suggesting or forwarding the message to
this peer, depending on the routing mechanism being used.
4.3. Use of SIP Messages in dSIP
dSIP uses SIP messages to implement the P2PSIP Peer Protocol. This
was done for a number of reasons. In order to properly implement a
P2PSIP protocol, it is necessary to have mechanisms to store,
retrieve and query the locations of resources, as well as to route
information. NAT traversal and security considerations require
several techniques for routing information, as discussed below.
Pluggable hashing techniques and DHT algorithms require capabilities
to negotiate the use of these pluggable modules. We have found SIP
offers mechanisms that meet all of these requirements today, has well
defined security mechanisms, and additionally works well with the
IETF suite of NAT traversal techniques: STUN, TURN and ICE. Because
all this work would need to be redefined in a new P2PSIP protocol,
and because all P2PSIP devices must, by definition, implement SIP
anyway, we feel the only reasonable syntax choice for the P2PSIP Peer
Protocol is SIP.
Bryan, et al. Expires August 29, 2007 [Page 11]
Internet-Draft dSIP February 2007
Our motivation throughout has been to preserve the semantics of
conventional SIP messages to the extent possible. All of the
messages that are needed to maintain the DHT, as well as those needed
to query for information, are implemented using SIP messages.
Fundamentally, messages are being exchanged for two purposes. The
purpose of the first class of messages is to maintain the DHT, such
as the messages needed to join or leave the overlay, and to transfer
information between peers. The second type of message is the type
most SIP users will be familiar with -- registering users, inviting
other users to a session, etc. -- basic session establishment. As
the DHT is used as a distributed registrar, the registration and
other searches are performed within the DHT. Once the target
resource has been located, further communication proceeds directly
between the UAs (or designated adapter peers) as with conventional
SIP communications.
The messages used to manipulate the DHT are SIP REGISTER messages.
RFC 3261, Section 10.2, specifies that REGISTER messages are used to
"add, remove, and query bindings." Accordingly, we have selected
REGISTER methods to use to add, remove, and query bindings. We use
REGISTER both for the bindings of hosts as neighbors (entries in the
routing table) in DHT maintenance operations as well as the bindings
of resource names to locations that are commonly maintained by SIP
registrars. The only fundamental difference is that these operations
occur within the overlay, rather than on the conventional server.
4.4. Routing in dSIP
When a peer sends a message within the DHT, it begins by calculating
the target ID it is attempting to locate, using the particular
algorithm used by the overlay. The target could be another user, a
particular resource, or a peer (including itself) for DHT maintenance
purposes. It then consults its routing table, and its other neighbor
peers, for the closest peer it is aware of to the target ID, as
defined by the closeness metric of the DHT in use.
In discussions of P2PSIP, several mechanisms have been discussed for
routing. In each case, the initial message is sent from the
requester to the peer in the routing table most likely to route
correctly, as defined by the DHT algorithm in use. Subsequently,
that peer may provide further routing using one of three mechanisms.
These three types of routing are:
o Iterative: If the contacted peer is not responsible for the target
ID, then the contacted peer issues a 302 redirect response
pointing the search peer toward the best match the contacted peer
has for the target ID. The searching peer then contact the peer
to which it has been redirected and the process iterates until the
responsible peer is located.
Bryan, et al. Expires August 29, 2007 [Page 12]
Internet-Draft dSIP February 2007
o Recursive: If the contacted peer is not responsible for the target
ID, it will forward the query to the nearest peer to the target
that it knows, and the process repeats until the target is
reached. The response unwinds and follows the same path on the
message return. Because dSIP uses SIP messages for transport,
SIP's proxy behavior is used to enable recursive routing.
o Semi-Recursive: Semi-Recursive is the same as Recursive routing on
the outbound leg, but the reply "shortcuts" and is directly sent
back to the requester. When discussing these techniques, we often
just refer to Iterative and Recursive, because of the similarity
between recursive and semi-recursive routing.
Various mechanisms may be used within the same overlay and even
within the same search. For example, a search may start as
iterative, but if a particular peer receiving the request knows that
the requester cannot reach the next hop directly (perhaps due to NAT
issues), the search may have recursive and iterative portions.
In general, the messages can be routed using any of these mechanisms,
and this draft does not specify which mechanism will be used. The
decision as to which mechanism is appropriate may be a factor of
security, NAT traversal, or even the properties of the particular DHT
being used. We generally refer to the message as being routed
through the overlay.
4.4.1. dSIP Operations
dSIP provides mechanisms that are used for a number of operations.
4.4.1.1. Peer Registration
When a peer (called the joining peer) wishes to join the overlay, it
determines its Peer-ID and sends a REGISTER message to a bootstrap
peer already in the overlay, requesting to join. Any peer in the DHT
may serve as a bootstrap peer. The mechanism for selecting bootstrap
peers is application dependent, and discussed in Bootstrapping
(Section 4.5).
Following the iterative routing scheme, the bootstrap peer looks up
the peer it knows nearest to the Peer-ID of the joining peer and
responds with 302 redirect to this closer peer. The joining peer
will repeat this process until it reaches the peer currently
responsible for the space it will occupy.
If recursive routing is being used, the bootstrap peer looks up the
peer it knows nearest to the Peer-ID of the joining peer and forwards
the REGISTER message to that peer. This process of forwarding the
message repeats until the peer currently responsible for the space
Bryan, et al. Expires August 29, 2007 [Page 13]
Internet-Draft dSIP February 2007
the joining peer will occupy is found.
Once the peer responsible for the joining peer's portion of the
namespace is located, the joining peer then exchanges DHT state
information with this peer, called the admitting peer, to allow the
joining peer to learn about other peers in the overlay (neighbors)
and to obtain information about resources the joining peer will be
responsible for maintaining. Other DHT maintenance messages will be
exchanged later to maintain the overlay as other peers enter and
leave, as well as to periodically verify the information about the
overlay, but once the initial messages are exchanged, a peer has
joined the overlay.
4.4.1.2. Resource Registration
The peer registration does not register the peer's user(s) or other
resources with the P2PSIP network -- it has only allowed the peer to
join the overlay. Once a peer has joined the overlay, the user that
peer hosts must be registered with the system. This process is
referred to as resource registration. This registration is analogous
to the conventional SIP registration, in which a message is sent to
the registrar creating a mapping between a SIP URI and a user's
contact. The only difference is that since there is no central
registrar, some peer in the overlay will maintain the registration on
the users behalf.
Resource registrations are routed similarly to peer registrations.
The resource's peer calculates the resource-ID and contacts the peer
it is aware of nearest to the resource-ID. This search process
continues in either an iterative or recursive manner until the
responsible peer is located. This peer then stores the registration
for that user and returns a 200 response.
For redundancy, resources should also be registered at additional
peers within the overlay. These replicas are located by adding a
replica number to the resource name and hashing to identify a new
resource-ID for each replica. In this way, replicas are located at
unrelated points around the DHT, minimizing the risk of an attacker
compromising more than one registration for a single resource.
4.4.1.3. Session Establishment
Sessions are established by contacting the UA identified by the
registration in the DHT. The first step in establishing a session is
locating this peer, which is done by searching for a resource in the
DHT. The name of the target resource is used to calculate a
resource-ID and a REGISTER message with no Contact information (a
conventional SIP search) is sent to the closest known peer to that
Bryan, et al. Expires August 29, 2007 [Page 14]
Internet-Draft dSIP February 2007
resource-ID. The search iterates until the responsible peer is
located. The responsible peer then returns either a 200 OK with the
Contact information for the resource or a 404 Not Found. The session
is then initiated directly with the resource's UA.
4.4.1.4. DHT Maintenance
In order to keep the overlay stable, peers must periodically perform
book keeping operation to take into account peer failures. These DHT
maintenance messages are sent using REGISTER messages and the overlay
algorithm being used will dictate how often and where these messages
are sent.
DHT maintenance messages are routed similarly to peer registrations
and resource registrations. The peer calculates the Peer-ID of the
peer it wants to exchange DHT information with and contacts the peer
it is aware of closest to that Peer-ID. This search process
continues in either an iterative or recursive manner until the peer
is located at which point the peers exchange DHT maintenance
information.
4.5. Bootstrapping
When a peer wishes to join an existing overlay, it must first locate
some peer that is already participating in the overlay, referred to
as the bootstrap peer. Peers may use any method they choose to
locate the initial bootstrap peer --- the decision is outside the
scope of this specification. The following are a few of the many
methods that may be used:
Static Locations: Some number of peers in the overlay may be
persistent and have well know addresses. These addresses could be
configured into the peer application or obtained using an out-of-
band mechanism such as a web page.
Cached Peers: While this mechanism cannot be used the first time
that a peer runs, on subsequent attempts to join the overlay a
peer might attempt to use a previously contacted peer as a
bootstrap peer.
Broadcast mechanisms: Peers can use a broadcast mechanism to locate
the initial peer, for example by sending the first REGISTER
message to the SIP multicast address.
5. Message Syntax
This section provides normative text explaining the syntax of the
extensions we use for SIP messages.
Bryan, et al. Expires August 29, 2007 [Page 15]
Internet-Draft dSIP February 2007
5.1. Option Tags
We create a new option tag "dht" as described in RFC 3261. This
option tag indicates support for DHT based P2PSIP. Peers MUST
include a Require and Supported header with the option tag dht for
all messages that are intended to be processed using dSIP or include
P2P extensions. Clients supporting P2P and contacting another SIP
entity using a non-P2P mechanism for a transaction that may or may
later be P2P SHOULD include a Supported header with dht. For a
typical session establishment the search within the DHT MUST specify
Require dht, whereas the actual contact with the resource's UA SHOULD
include a Supported header with dht but SHOULD NOT include a Require
header with dht.
5.2. Hash Algorithms and Identifiers
All IDs used for an overlay must be calculated using the same
algorithm. Implementations MUST support the SHA-1 algorithm, which
produces a 160 bit hash value. The hash algorithm used is specified
in the DHT-PeerID header, described below. An implementation MAY
rely on a secret initialization vector, key, or other shared secret
to use the identifier as an HMAC, from RFC 2104 [10] such that no
peer may join the overlay without knowledge of the shared secret,
however this technique by itself does not protect the overlay against
replay attacks. See Security Extensions to the Distributed Session
Initiation Protocol (dSIP) [9]for information on how to protect
against replay attacks.
Both Peer-IDs and Resource-IDs MUST have the same range of values
(map to the same space). Formally:
P2PID = token
When using SHA-1:
P2PID = 40LHEX
5.2.1. Peer-IDs
The particular DHT algorithm being used MAY specify an alternate
mechanism for determining Peer-ID. Similarly, some security models
may assign Peer-IDs from a central authority. In the event that
neither of these mechanisms are being used, the Peer-ID MUST be
formed by taking the IP address of the peer, without the colon or
port, and with no leading zeros, and hashing this string with the
hash algorithm. Then the least significant sixteen bits of the hash
are replaced by the port used by the peer. For peers behind a NAT
participating in an overlay on the public Internet, they must
Bryan, et al. Expires August 29, 2007 [Page 16]
Internet-Draft dSIP February 2007
identify their address on the public Internet through a protocol such
as STUN [4] and use this address for their Peer-ID.
The string hashed to obtain the PeerID is formally defined below as
ipaddress.
ipaddress = IPV4address / IPv6reference
PeerID is formally defined as:
PeerID = P2PID
5.2.2. Resource-IDs and the Replication
Resource-IDs MUST be formed by hashing the resource URI after
converting it to canonical form. To do that, all URI parameters MUST
be removed (including the user-param) except for the replica URI
parameter, Any escaped characters MUST be converted to their
unescaped form. Formally:
ResourceID = P2PID
5.3. P2PSIP URIs
Because hashing URIs to produce identifiers is a non-trivial cost,
dSIP messages are constructed including these values already
calculated. This is strictly as a courtesy to peers processing
messages for this peer, as it prevents them from having to hash the
URI again before routing. Identifiers provided in a message are a
courtesy only and MUST NOT be used when making any changes to the
data stored in an overlay, as they may be spoofed or incorrect. If
the hash parameter is used incorrectly for routing, this only affects
the transmitting peer's user. If it is used to insert or modify
stored information, it can affect the system's integrity. Peers MUST
verify the hash of all URIs before making changes that affect the
overlay.
5.3.1. Peer URIs
A P2PSIP peer is represented by constructing a SIP-URI (or SIPS-URI)
with the keyword "peer" or a short form of "P" for the userinfo
portion. The URI parameter "peer-ID", or the short form "pID" MUST
be used.
PeerURI = ("peer@" / "P@") hostport ";" PeerID-Param ";"
uri-parameters
Formally, the peerID uri-parameter is defined as type other-param
Bryan, et al. Expires August 29, 2007 [Page 17]
Internet-Draft dSIP February 2007
from RFC 3261 with a pname of "peerID" or "pID" for short form, and a
pvalue which is of type PeerID. A peer receiving a PeerURI MUST
verify the hash value of the PeerID-Param before using it to update
its routing table.
PeerID-Param = ("peer-ID" / "pID") EQUAL PeerID
For search operations, where an identifier is being searched for, but
the host responsible for that identifier is unknown, hostport MUST be
set to "0.0.0.0". All non-search operations MUST specify a valid
hostport.
P2P Peer URIs MUST NOT include the resource-ID URI parameter (below),
as it is intended to define information about resources that are
stored in the overlay, not information about the peers making up the
overlay. P2P Peer URIs used in name-addr SHOULD NOT include any
display-name information, and peers receiving name-addrs for peers
with display-name information MUST ignore the information.
Examples, using a shortened hash for clarity:
The URI for a peer using the SHA-1 hash algorithm, with
hashed ID ed57487add matching an IP address 10.6.5.5 used
in a To header. Uses the short forms:
To: <sip:P@10.6.5.5;pID=ed57487add>
The URI for a peer using the SHA-1 hash algorithm, with
hashed ID ed57487add matching an IP address 10.6.5.5 used
in a To header. Uses the long forms:
To: <sip:peer@10.6.5.5;peer-ID=ed57487add>
5.3.2. Resource URIs and the resource-ID URI Parameter
Resource URIs are no different for P2PSIP resources than for non-P2P
SIP applications. However, because calculating the ResourceID is a
significant expense, the optional URI parameter resource-
ID=<Resource-ID> or the short form rID=<Resource-ID> SHOULD be
provided. This parameter is a courtesy only and MUST NOT be used
when making any changes to the data stored in an overlay without
being recalculated, as it may be spoofed or incorrect. The
resource-ID URI parameter is of type other-param as defined in RFC
3261.
resourceID-param = ("resource-ID" \ "rID") EQUAL ResourceID
P2P Resource URIs MUST NOT include the PeerID-Param URI parameter,
because this indicates that the target of the URI is a peer. P2P
Bryan, et al. Expires August 29, 2007 [Page 18]
Internet-Draft dSIP February 2007
Resource URIs MAY include other user-parameters such as user=phone.
Examples (again using shortened hashes for clarity):
The URI for a user resource with username bob@p2psip.org using
the SHA-1 hash algorithm, with hashed Resource-ID 723fedaab1.
The optional resource-ID URI parameter is included, using the
long form:
sip:bob@p2psip.org;resource-ID=723fedaab1
The URI for a user resource with username bob@p2psip.org using
the SHA-1 hash algorithm, with hashed Resource-ID 723fedaab1.
The optional resource-ID URI parameter is included, using the
short form:
sip:bob@p2psip.org;rID=723fedaab1
The URI, used in a To header for user Alice White, with username
alice@p2psip.org. This example omits the optional resource-ID URI
parameter:
To: "Alice White" <sip:alice@p2psip.org>
5.4. The DHT-PeerID Header and Overlay Parameters
We introduce a new SIP header called the DHT-PeerID header. This
header is used to express the Peer-ID of the sending peer as well as
to identify the name and parameters of the overlay. The format of
the DHT-PeerID header is as follows:
DHT-PeerID = "DHT-PeerID" HCOLON PeerURI SEMI algorithm SEMI
dht-param SEMI overlay-param *(SEMI generic-param)
Examples:
A peer with an SHA-1 hashed Peer-ID of a04d371e on IP 192.168.1.1.
We include the PeerURI, algorithm, dht-param, and overlay as well as
the optional expires header parameter. In this example, the overlay
name is chat and the DHT algorithm being used is dhtalg1.0
DHT-PeerID: <sip:peer@192.168.1.1;peer-ID=a04d371e>;algorithm=sha1;
dht=dhtalg1.0;overlay=chat;expires=600
5.4.1. Hash Algorithms and the algorithm Parameter
The hash algorithm used for the overlay is specified as a parameter
of the DHT-PeerID header. This parameter MUST appear in the DHT-
PeerID header. It MUST be the algorithm used to calculate all PeerID
Bryan, et al. Expires August 29, 2007 [Page 19]
Internet-Draft dSIP February 2007
and ResourceID values used in the message. It SHOULD NOT appear in
other headers in the message, but if it does it MUST match the value
in the DHT-PeerID header.
The hash algorithm is specified using the algorithm parameter from
RFC3261. The tokens used to identify the algorithm MUST be the same
as those used in other SIP documents such as RFC4474. [11] Currently,
those consist of 'sha1', indicating SHA-1 as defined in RFC 3174 [12]
and 'hmac-sha1', indicating HMAC-SHA1 as defined in RFC2104 [10].
Implementations MUST support the SHA-1 algorithm.
A peer MUST reject a message with 488 Not Acceptable here if it
specifies a different hash algorithm than that used by the peer's
overlay. An initial contact to a bootstrap peer may specify the hash
algorithm as the wildcard "*", in which case the joining peer
indicates its willingness to use whatever hash algorithm the
bootstrap peer identifies in its response. A peer responding to such
a request MUST route the message according to the rules described in
the Message Routing Section (Section 6) if all other elements of the
message are correct and the routing algorithm indicates such a
response is appropriate. If the normal response would be to allow
the join with a 200 OK, the receiving peer MAY respond with a 302
redirect to itself and specifying the algorithm used in this overlay,
in which case the joining peer should reissue the message with the
proper hash algorithm specification.
5.4.2. Overlay Names and the overlay Parameter
Each overlay is named using a string, which SHOULD be unique to a
particular deployment environment. Peers will use this value to
identify messages in cases where they may belong to multiple overlays
simultaneously. These are defined formally simply as a token:
overlay-name = "*" / token
The overlay-param parameter MUST appear in the DHT-PeerID header. It
SHOULD NOT appear in other headers in the message, but if it does it
MUST match the value in the DHT-PeerID header. This parameter is
defined formally as:
overlay-param = "overlay" EQUAL overlay-name
A peer MUST reject a message with 488 Not Acceptable here if it
specifies an overlay in which the peer is not participating. An
initial contact to a bootstrap peer MAY specify overlay-name as the
wildcard "*", in which case the joining peer indicates its
willingness to join whatever overlay the bootstrap peer identifies in
its response. A peer responding to such a request MUST route the
Bryan, et al. Expires August 29, 2007 [Page 20]
Internet-Draft dSIP February 2007
message according to the rules described in the Message Routing
Section (Section 6) if all other elements of the message are correct
and the routing algorithm indicates such a response is appropriate.
If the normal response would be to allow the join with a 200 OK, the
receiving peer MAY respond with a 302 redirect to itself, in which
case the joining peer should reissue the message with the proper
overlay specification.
5.4.3. DHT Algorithms and the dht Parameter
The routing algorithm used to implement the overlay is specified
using a dht-param in the DHT-PeerID header. It SHOULD NOT appear in
other headers in the message, but if it does it MUST match the value
in the DHT-PeerID header. This parameter is defined formally as:
dht-name = token
dht-param = "dht" EQUAL dht-name
The behavior of a peer receiving a message with a dht-param
specifying a routing algorithm other than that which it is following
is dependent on the routing algorithm. An initial contact of a
bootstrap peer MAY specify dht-param as the wildcard "*", in which
case the joining peer indicates its willingness to use whatever DHT
algorithm the bootstrap peer identifies in its response. A peer
responding to such a request MUST route the message according to the
rules described in the Message Routing Section (Section 6) if all
other elements of the message are correct and the routing algorithm
indicates such a response is appropriate. New routing algorithms
SHOULD be designed to maintain backward compatibility with previous
algorithms where possible. If the routing algorithm specified is
incompatible, a 488 Not Acceptable Here response MUST be returned.
5.4.4. PeerID Expires header parameter
The DHT-PeerID header MAY include an Expires parameter indicating how
long a recipient may keep knowledge of this peer. If not present, a
default of 3600 is assumed. Mobile peers may wish to specify a
shorter interval.
5.5. The DHT-Link Header
We introduce a new SIP header called the DHT-Link header. The DHT-
Link header is used to transfer information about where in the DHT
other peers are located. In particular, it is used by peers to pass
information about its neighbor peers and routing table information
stored by a peer.
Bryan, et al. Expires August 29, 2007 [Page 21]
Internet-Draft dSIP February 2007
DHT-Link = "DHT-Link" HCOLON PeerURI SEMI link-param SEMI
expires-param *(SEMI generic-param)
link-param = "link" EQUAL link-value
expires-param = "expires" EQUAL delta-seconds
The value of linkvalue -- that is, how you represent what type of
link this is, is defined by the DHT algorithm specification. The
generic-param leaves flexibility for an algorithm to add additional
parameters if needed.
As an example, the header might look like (using a shortened 10 digit
Peer-ID for clarity). The value *** here is intended to represent a
value determined by the particular DHT:
DHT-Link: <sip:peer@192.168.0.1;Peer-ID=671a65bf22>;link=***;expires=600
5.5.1. Expires Processing
Each DHT-Link header MUST contain an expires parameter. Each peer
maintains an expiration time for each of its neighbor and routing
table entries. These expiration times are updated whenever the peer
receives a response with a longer expiration time than it currently
maintains, most commonly in the PeerID header of a response to a join
or search. A peer MUST NOT report an expired entry in a DHT-Link
header. A peer MUST update the expires parameter with the current
value, adjusted for passed time, each time it generates a DHT-Link
header.
6. Message Routing
When a peer sends a message within the DHT, it begins by calculating
the target ID it is attempting to locate, which might be its own
location in the DHT, or a user's registration, for which it hashes
the user's URI to obtain the appropriate Resource-ID. It then
consults its routing table, and its other neighbor peers, for the
closest peer it is aware of to the target ID.
The messages in the overlay MAY be routed either iteratively or
recursively. The Request-Disposition header as described in [13]
SHOULD be used to indicate if the next node should process the
message using a recursive or iterative mechanism. If the header is
omitted, the receiving node may process the message either
recursively or iteratively.
If the Request-Disposition header is iterative, the contacted peer
MUST determine if it is responsible for that target ID. If it is
not, then the contacted peer MUST issue a 302 redirect pointing the
Bryan, et al. Expires August 29, 2007 [Page 22]
Internet-Draft dSIP February 2007
search peer toward the best match the contacted peer has for the
target ID. The searching peer then contact the peer to which it has
been redirected and the process iterates until the responsible peer
is located.
In recursive routing, the peer sends a message to the peer it knows
that is nearest to the target. If the contacted peer is not
responsible for the target ID, it MUST forward the query to the
nearest peer to the target that it knows, and the process repeats
until the target is reached. This process follows standard proxy
behavior in RFC 3261.
6.1. Peer Registration
When a peer (the joining peer) wishes to join the overlay, it creates
its Peer-ID and sends a REGISTER message to a bootstrap peer already
in the overlay, requesting to join. Any peer in the DHT may serve as
a bootstrap peer, although we expect that most UAs will be configured
with a small number of well-known peers.
Following the iterative routing scheme, the bootstrap peer looks up
the peer it knows nearest to the Peer-ID of the joining peer and
responds with 302 redirect to this nearer peer. The joining peer
will repeat this process until it reaches the peer currently
responsible for the space it will occupy.
If recursive routing is being used, the bootstrap peer looks up the
peer it knows nearest to the Peer-ID of the joining peer and forwards
the REGISTER message to that peer. This process of forwarding the
message repeats until the peer currently responsible for the space
the joining peer will occupy is found.
Once the peer responsible for the joining peer's portion of the
namespace is located, the joining peer then exchanges DHT state
information with this peer, called the admitting peer, to allow the
joining peer to learn about other peers in the overlay (neighbors)
and to obtain information about resources the joining peer will be
responsible for maintaining. Other DHT maintenance messages will be
exchanged later to maintain the overlay as other peers enter and
leave, as well as to periodically verify the information about the
overlay, but once the initial messages are exchanged, a peer has
joined the overlay.
6.2. Resource Registration
The peer registration does not register the peer's user(s) or other
resources with the P2PSIP network -- it has only allowed the peer to
join the overlay. Once a peer has joined the overlay, the user that
Bryan, et al. Expires August 29, 2007 [Page 23]
Internet-Draft dSIP February 2007
peer hosts must be registered with the system. This process is
referred to as resource registration. This registration is analogous
to the conventional SIP registration, in which a message is sent to
the registrar creating a mapping between a SIP URI and a user's
contact. The only difference is that since there is no central
registrar, some peer in the overlay will maintain the registration on
the users behalf.
Resource registrations are routed similarly to peer registrations.
The resource's peer calculates the resource-ID and contacts the peer
it is aware of closest to the resource-ID. This search process
continues in either an iterative or recursive manner until the
responsible peer is located. This peer then stores the registration
for that user and returns a 200 response.
For redundancy, resources should also be registered at additional
peers within the overlay. These replicas are located by adding a
replica number to the resource name and hashing to identify a new
resource-ID for each replica. In this way, replicas are located at
unrelated points around the DHT, minimizing the risk of an attacker
compromising more than one registration for a single resource.
6.3. Session Establishment
Sessions are established by contacting the UA identified by the
registration in the DHT. The first step in establishing a session is
locating this peer, which is done by searching for a resource in the
DHT. The name of the target resource is used to calculate a
resource-ID and a REGISTER message with no Contact information (a
conventional SIP search) is sent to the closest known peer to that
resource-ID. The search iterates until the responsible peer is
located. The responsible peer then returns either a 200 OK with the
Contact information for the resource or a 404 Not Found. The session
is then initiated directly with the resource's UA.
If the peer needs to have the session establishment routed through
the overlay, it MAY use the Request-Disposition header with a value
of proxy to request that intermediate nodes proxy the invite over the
overlay on their behalf. This is particular critical for NAT
traversal [6].
6.4. DHT Maintenance
In order to keep the overlay stable, peers must periodically perform
book keeping operations to take into account peer failures. These
DHT maintenance messages are sent using REGISTER messages and the
overlay algorithm being used will dictate how often and where these
messages are sent.
Bryan, et al. Expires August 29, 2007 [Page 24]
Internet-Draft dSIP February 2007
DHT maintenance messages are routed similarly to peer registrations
and resource registrations. The peer calculates the Peer-ID of the
peer it wants to exchange DHT information with and contacts the peer
it is aware of closest to that Peer-ID. This search process
continues until the current closest peer to the target Peer-ID is
located at which point the peers exchange DHT maintenance
information.
7. Peer/DHT Operations
The SIP REGISTER message is used extensively in this system.
REGISTER is used to register users, as in conventional SIP systems,
and we discuss this further in the Resource Registration
(Section 8.1) section of this document. Additionally, SIP REGISTER
messages are used to register a new peer with the DHT and to transmit
the information needed to maintain the DHT.
7.1. Peer Registration
After a peer has located an initial bootstrap peer, the process of
joining the overlay is started by constructing a REGISTER message and
sending it to the bootstrap peer. Third party registration MAY NOT
be used for registering peers into the overlay, and attempts to do so
MUST be rejected by the peer receiving such a request (although third
party registrations are used for other purposes, as described below).
The peer MUST construct a SIP REGISTER message following the
instructions in RFC3261, Section 10, with the exceptions/rules
outlined below.
7.1.1. Constructing a Peer Registration
The Request-URI MUST include only the IP address of the peer that is
being contacted (initially the bootstrap peer). This URI MUST NOT
include any of the P2P defined parameters. For example, a request
intended for peer 10.3.44.2 should look like: "REGISTER sip:10.3.44.2
SIP/2.0".
The To and From fields of the REGISTER message MUST contain the URI
of the registering peer constructed according to the rules in the
subsection Peer URIs (Section 5.3.1) in the Message Syntax section.
While allowing the IP address of the sender for To and From is
different than conventional SIP registers, there are two reasons for
this. First, in a P2P network, which peer the request is sent to,
and thus the domain for which the registration is intended, is not
important. Any peer can process the information, and the user name
is not associated with a particular IP address or DNS domain, but
Bryan, et al. Expires August 29, 2007 [Page 25]
Internet-Draft dSIP February 2007
rather with the overlay name, which is encoded elsewhere. In that
sense, the IP address used is irrelevant. Choosing the domain of the
sender ensures that if a request is sent to a non-P2P aware RFC 3261
compliant registrar, it will be rejected. RFC 3261 (section 10.3)
states that a registrar should examine the To header to determine if
it presents a valid address-of-record for the domain it serves.
Since the IP address of the sending peer is unlikely to be a valid
address for a non-P2P aware registrar, the message will be rejected,
eliminating possibly erroneous handling by the registrar.
The registering peer MUST also list its PeerURI in the contact field
when registering so that this may be identified as a registration/
update, rather than a query. The peer MUST provide an expires
parameter or expires header with a non-zero value. As in standard
SIP registrations, Expire headers with a value of zero will be used
to remove registrations.
The registering peer MUST provide a DHT-PeerID header field. It MAY
leave the overlay parameter set to "*" for its initial registration
message, but MUST set this parameter to the name of the overlay it is
joining as soon as it receives a response from the bootstrap peer.
The registering peer MUST include Require and Supported headers with
the option tag "dht".
Assume that a peer running on IP address 10.4.1.2 on port 5060
attempts to join the network by contacting a bootstrap peer at
address 10.7.8.129. Further assume that 10.4.1.2 hashes to
463ac4b449 under SHA-1 (using a 10 digit hash for example
simplicity), and the least significant bits are replaced with the
port number, yielding 463ac413c4 and that the overlay name is chat
and the dht-param is dhtalg1.0. An example message would look like
this (neglecting tags):
REGISTER sip:10.7.8.129 SIP/2.0
To: <sip:peer@10.4.1.2;peer-ID=463ac413c4>
From: <sip:peer@10.4.1.2;peer-ID=463ac413c4>
Contact: <sip:peer@10.4.1.2;peer-ID=463ac413c4>
Expires: 600
DHT-PeerID: <sip:peer@10.4.1.2;peer-ID=463ac413c4>;algorithm=sha1;
dht=dhtalg1.0;overlay=chat;expires=600
Require: dht
Supported: dht
Bryan, et al. Expires August 29, 2007 [Page 26]
Internet-Draft dSIP February 2007
7.1.2. Processing the Peer Registration
The receiving peer determines that this is a P2PSIP message based on
the presence of the dht Require and Supported fields. In the event
that the peer does not support P2P extensions, it MUST reply with a
420 Bad Extension response. If the peer examines the overlay
parameters and determines that this is not an overlay the peer
participates in, the peer MUST reject the message with a 488 Not
Acceptable Here response. Likewise if the peer examines the dht-
param and determines that the algorithm specified is not compatible
with its algorithm, the peer MUST reject the message with a 488 Not
Acceptable Here response. If a P2P peer receives a non-P2P request
it MAY reject it with a message such as 421 Extension Required or it
MAY process it as a conventional SIP message.
An implementation may support both P2P and conventional SIP messages.
In that case, it MAY include the dht Supported field with all
messages but MUST NOT include it with messages intended for
conventional nodes.
7.1.2.1. Routing the Peer Registration
The presence of peer-ID URI parameter in the To and Contact headers
and a valid expiration time indicate that this message is a peer
registration and the receiving peer MUST process this as a DHT level
request. The bootstrap peer SHOULD verify that the Peer-ID
corresponds to peer listed in the URI by validating the hash or the
peers credentials. If these do not match, the message SHOULD be
rejected with a response of 493 Undecipherable. The bootstrap peer
examines the Peer-ID to determine if it corresponds to the portion of
the overlay the bootstrap peer is responsible for. If it does, the
peer will handle the REGISTER request itself. If not, the bootstrap
peer will either provide the joining peer with information about a
peer closer to the area of the overlay where the joining peers
Peer-ID is stored (iterative routing) or forward the request along
the closest peer it knows about (recursive routing). If a Request-
Disposition header is present and set to proxy, the peer MUST use a
recursive routing mechanism, and if it is present and set to
redirect, the peer MUST use an iterative routing mechanism. In the
event that the Request-Disposition header is not present, the peer
may choose either mechanism.
In the case of iterative routing, if the receiving peer is not
responsible for the area of the hash table where Peer-ID should be
stored, the peer SHOULD generate a 302 message. The 302 is
constructed according the rules of RFC 3261 with the following rules.
The receiving peer MUST look in its list of neighbors or in the
routing table to find the peer with Peer-ID nearest the to joining
Bryan, et al. Expires August 29, 2007 [Page 27]
Internet-Draft dSIP February 2007
peer's Peer-ID, and use it to create a contact field in the form of a
peer URI, as specified in the P2P Peer URIs (Section 5.3.1) section
of this document, including appropriate URI parameters. The response
MUST contain a valid DHT-PeerID header. This response is sent to the
joining peer.
In the case of recursive routing, if the receiving peer is not
responsible for the area of the hash table where the Peer-ID should
be stored, the receiving peer should forward the request to the peer
it knows about that is closest to the Peer-ID.
A peer MUST NOT add a new peer to its routing table or redirect
requests to that new peer until it has successfully contacted that
peer itself. By redirecting a message to another peer, the contacted
peer indicates that it believes that peer to be alive and that it is
willing to route messages to it for NAT and Firewall traversal
purposes.
Using our example register from the previous section, assume that
iterative routing is being used and that the bootstrap peer
10.7.8.129 receives the message, determines it is not responsible for
that area of the overlay, and redirects the joining peer to a peer
with Peer-ID 47e46fa2cd at IP address 10.3.1.7. The 302 response,
again neglecting tags, is shown below. Note that the peer creating
the response uses its information to construct the DHT-PeerID header.
SIP/2.0 302 Moved Temporarily
To: <sip:peer@10.4.1.2;peerId=463ac413c4>
From: <sip:peer@10.4.1.2;peerId=463ac413c4>
Contact: <sip:peer@10.3.1.7;peerId=47e46fa2cd>
Expires: 600
DHT-PeerID: <sip:@10.7.8.129;peerId=084d299ff2>;algorithm=sha1;
dht-param=dhtalg1.0;overlay=chat;expires=600
Require: dht
Supported: dht
Upon receiving the 302, the joining peer uses the contact address as
the new bootstrap peer. The process is repeated until the peer
contacted is currently responsible for the area of the DHT in which
the new peer will reside. The receiving peer that is responsible for
that portion of the overlay is referred to as the admitting peer.
TODO: we should have example of how to forward request in a recursive
routing case
Bryan, et al. Expires August 29, 2007 [Page 28]
Internet-Draft dSIP February 2007
7.1.2.2. Admitting the Joining Peer
The admitting peer MUST verify that the Peer-ID is valid, as
described above. If these do not match, the message MUST be rejected
with a response of 493 Undecipherable. The admitting peer recognizes
that it is presently responsible for this region of the hash space --
that is, it is currently the peer storing the information that this
Peer-Id will eventually be responsible for. The admitting peer knows
this because the joining peer's Peer-ID is closest to its own
Peer-ID. The admitting peer is responsible for helping the joining
peer become a member of the overlay. In addition to verifying that
the Peer-ID was properly calculated, the admitting peer MAY perform
additional security checks [9]. Once any challenge has been met, the
admitting will reply with a 200 OK message to the joining peer. As
in a conventional registration, the Contact in the 200 OK will be the
same as in the request, and the expiry time MUST be provided.
The admitting peer MUST reply with a 200 response if the admitting
peer's Peer-ID is the closest to the joining peer's Peer-ID. Each
DHT algorithm MAY choose to define closest however they want, but the
DHT algorithm MUST be able to deterministically find the closest
Peer-ID. The admitting peer must populate the DHT-Link headers with
all values required by the DHT routing protocol so that the joining
peer can initialize its neighbors and routing table entries.
Additionally, the admitting peer MUST include its DHT-PeerID header
containing the admitting peer's Peer-ID and IP.
7.2. Peer Query
As with conventional SIP, REGISTER messages that are sent without a
Contact: header are assumed to be queries, as described in Section 10
of RFC3261.
7.2.1. Constructing a Peer Query Message
The peer looks for the routing table entry or neighbor peer that is
closest to the ID they are searching for. If the routing table has
not yet been filled, then the peer may send the request to any peer
it has available, including their other neighbor peers or even some
bootstrap peer. While these initial searches may be less efficient,
they will succeed. The Request-URI MUST include only the IP address
of the peer that the search is intended for. This URI MUST NOT
include any of the P2P defined parameters. For example, a request
intended for peer 10.3.44.2 should look like: "REGISTER sip:10.3.44.2
SIP/2.0".
Because this is a query, the sending peer MUST NOT include a contact
header. The sender MUST NOT include an expires header.
Bryan, et al. Expires August 29, 2007 [Page 29]
Internet-Draft dSIP February 2007
The peer MUST provide a DHT-PeerID header.
The peer MUST include Require and Supported headers with the option
tag "dht".
Assume that a peer running on IP address 10.4.1.2 on port 5060 wants
to determine who is responsible for Peer-ID 4823affe45, and asks the
peer with IP address 10.5.6.211 Further assume that the peer uses
SHA-1 (using a 10 digit hash for example simplicity), and that the
overlay name is chat. An example message would look like this
(neglecting tags):
REGISTER sip:10.5.6.211 SIP/2.0
To: <sip:peer@0.0.0.0;peerId=4823affe45>
From: <sip:peer@10.4.1.2;peerId=463ac413c4>
DHT-PeerID: <sip:peer@10.4.1.2;peerId=463av413c4>;algorithm=sha1;
dht-param=dhtalg1.0;overlay=chat;expires=600
Require: dht
Supported: dht
The To field of the REGISTER message MUST contain the PeerURI of the
identifier being search for, constructed according to the rules in
the subsection P2P peer URIs (Section 5.3.1) in the Message Syntax
section. If a specific peer is being sought, the PeerURI must
specify that hostport. If only the identifier is being searched for,
then hostport MUST be set to "0.0.0.0". The From URI MUST use the
searching peer's PeerURI.
7.2.2. Processing Peer Query Message
The receiving peer determines that this is a P2PSIP message based on
the presence of the dht Require and Supported fields. In the event
that the peer does not support P2P extensions, it MUST reply with a
5xx class response such as 501 Not Implemented. If the peer examines
the overlay parameters and determines that this is not an overlay the
peer participates in, the peer MUST reject the message with a 488 Not
Acceptable Here response. In the event a P2P peer receives a non-P2P
request, it SHOULD reject it with a message such as 421 Extension
Required.
7.2.2.1. Routing the Peer Query Message
The presence of a PeerURI and lack of an expiration time indicate
that this message is a peer query and the receiving peer MUST process
this as a DHT level request. The receiving peer SHOULD NOT alter any
of its internal values such as successor or predecessor in response
to this message, since it is a query. Otherwise, the message is
processed and routed as a peer registration (Section 7.1.2.1) until
Bryan, et al. Expires August 29, 2007 [Page 30]
Internet-Draft dSIP February 2007
the responsible peer is reached.
7.2.2.2. Responding to the Peer Query Message
If the receiving peer is responsible for the region that the search
key lies within, it MUST respond to the query. If the receiving
peer's Peer-ID exactly matches the search key, it MUST respond with a
200 OK message. If it is responsible for that region, but its
Peer-ID is not the search key, it MUST respond with a 404 Not Found
message. The peer MAY verify the Peer-ID and IP address presented by
the querying peer in the message. If these do not match, the message
should be rejected with a response of 493 Undecipherable.
7.3. Populating the Joining Peer's Routing Table
Once admitted, the joining peer SHOULD populate its routing table and
locate neighbors by issuing queries for peers with the appropriate
identifiers. If the admitting peer provided neighbor or routing
table information in its response, the joining peer MAY use this
information to construct a temporary routing table and neighbor
information and use this temporary table in the queries to populate
the table.
7.4. Transfering User Registrations
When a new peer joins, it splits the area in the hash space the
admitting peer is responsible for. Some portion of the user
registrations the admitting peer was responsible for may now be the
responsibility of the joining peer, and these user registrations are
handed to the joining peer by means of third party user
registrations. Third party registrations are allowed for user
registrations and arbitrary searches, but are not allowed for peer
registrations. These registrations are exactly the same as those
discussed in Registering and Removing User Registrations
(Section 8.1), except that as they are third party registration from
a peer, that is, the From header contains the PeerURI of the
admitting peer.
7.5. Peers Leaving the Overlay Gracefully
Peers MUST send their registrations to the closest peer before
leaving the overlay, as described in the section above.
Additionally, peers MUST unregister themselves with their symmetric
neighbors (if the DHT routing algorithm uses symmetric neighbors in
any form). These graceful exit REGISTER messages are constructed
exactly the same as one used to join, with the following exceptions.
The expires parameter or header MUST be provided, and MUST be set to
0. DHT-Link headers must be provided, as specified in DHT routing
Bryan, et al. Expires August 29, 2007 [Page 31]
Internet-Draft dSIP February 2007
algorithm
7.6. NAT and Firewall Traversal
The filtering properties of NATs and firewalls can lead to non-
transitive connectivity. Typically this will manifest itself in a
peer receiving a 302 redirecting it to another peer that it cannot
contact, most likely because address dependent filtering is
occurring. We discuss mechanisms to address these problems in [6].
7.7. Handling Failed Requests
When a request sent to another peer fails, the peer MUST perform
searches to update its pointers. If the failed request was sent to a
peer in the routing table or a neighbor peer, then the searches
discussed in Populating the Joining Peer's Routing Table
(Section 7.3) should be performed.
8. Resource Operations
The most important element of resource operations within the P2PSIP
DHT is that they are performed exactly as if using a conventional SIP
registrar, except that the registrar responsibilities are distributed
among the DHT members.
8.1. Resource Registrations
When a peer is in the overlay, it must register the contacts for
users and other resources for which it is responsible into the
overlay. This differs from the registrations described above in that
these registrations are responsible for entering a URI name to URI
location mapping into the overlay as data, rather than joining a peer
into the overlay. These registrations are very similar to those
outlined in section 10 of RFC3261.
The Request-URI that is constructed for the REGISTER MUST be
addressed to the peer the request is sent to. The To and From fields
of the REGISTER message MUST contain the Resource URI of the resource
being registered, as described in Resource URIs (Section 5.3.2). The
request MUST include the value dht in Require and Supported headers.
The request MUST include a DHT-PeerID header and MAY include one or
more DHT-Link headers.
The resource registration MUST include at least one Contact header
containing a location of the resource and allowing this to be
identified as a registration/update, rather than a query. The peer
MUST provide an expires parameter or an Expire header with a non-zero
Bryan, et al. Expires August 29, 2007 [Page 32]
Internet-Draft dSIP February 2007
value. As in standard SIP registrations, Expires parameters with a
value of zero will be used to remove registrations. Any valid
Contact for RFC 3261 is valid Contact for P2PSIP. Most users will
register a Contact with the address of the user's UA (which may or
may not be the IP address of the peer, since the peer could be an
adaptor peer). The Contact URI does not need to include the
ResourceID or other P2PSIP parameters as it is stored in the DHT but
not processed or routed by it in any way.
The message is routed in a fashion exactly analogous to that
described in the section on peer registration (Section 7.1). In
iterative routing algorithms, 302 messages are sent to indicate that
the message is to be redirected to another Peer URI. In recursive
routing algorithms, the receiving peer SHOULD forward the request to
the peer in its connection table that is closest to the ResourceID.
Once the message arrives at a destination that is responsible for
that portion of the hash namespace, the peer recognizes it as a
resource registration, rather than a peer wishing to join the system,
based upon the fact that the To and From fields do not contain a Peer
URI. The peer responds with a 200 indicating a successful
registration. The response is constructed as dictated by RFC3261.
The registering peer SHOULD construct and register replica
registrations using the same Contact headers, but with the replica
URI parameter used in the To and From headers.
8.2. Refreshing Resource Registrations
Resource registrations are refreshed exactly as described in RFC
3261, Section 10. Responsible peers should send a new registration
with a valid expiration time prior to the time that the registration
is set to expire.
Agents MAY cache the address where they previously registered and
attempt to send refreshes to this peer, but they are not guaranteed
success, as a new peer may have registered and may now be responsible
for this area of the space. In such a case if iterative routing is
being used, the peer will receive a 302 from the peer with which they
previously registered, and should follow the same procedure for
locating the peer they used in the initial registration.
As with initial registrations, the sending peer should use the
neighbor peer or routing table information provided in the 200 to
send these updates to the redundant peers as well.
Bryan, et al. Expires August 29, 2007 [Page 33]
Internet-Draft dSIP February 2007
8.3. Removing Resource Registrations
Resource registrations are removed exactly as described in RFC 3261,
Section 10. Responsible peers MUST send a registration with
expiration time of zero.
As with initial registrations, the sending peer MUST construct
replica unregister messages and use these to unregister the replicas.
8.4. Querying Resource Registrations
Resource queries are constructed as described in RFC 3261, Section
10. Querying peers should send a REGISTER message with no contact
header. As described in Peer Search (Section 7.2.1), this mechanism
can also be used to locate the peer responsible for a particular
Resource-ID.
A P2P environment can do little to protect against an individual peer
compromising the registrations it is responsible for. Accordingly, a
UA cannot trust a response from a single peer, whether it indicates a
successful search or an error. In the absence of other methods of
verifying the response (such as having a certificate of the user
being searched for and a signed registration that can be verified
with the certificate) a UA should search for the primary registration
and at least one replica. Because the locations the replicas are
stored are unrelated to the location of the primary registration, a
single attacker is unlikely to be able to compromise both entries.
As the overlay gains more peers and more replicas are searched for,
the odds of a compromise are reduced. Better protection for
registrations is discussed in [9].
8.5. Session Establishment
When a caller wishes to send a SIP message (such as an INVITE,
MESSAGE or SUBSCRIBE), the caller must first locate the peer where
this callee's information resides using the resource search procedure
described in the section titled Resource Location. (Section 8.4)
Establishing a session is done entirely in the normal SIP fashion
after the user is located using the P2P resource query. Once the
peer responsible for the Resource-ID is located, it will provide
either a 200, providing a contact for the users UA, or will provide a
404 if the user is not registered. If a 200 with a valid contact is
received, the call will then be initiated directly with the UAS of
the called using the standard RFC 3261 fashion for methods such as
INVITE or MESSAGE, or the INVITE can be processed by routing it
through the overlay if necessary for NAT traversal [6].
Bryan, et al. Expires August 29, 2007 [Page 34]
Internet-Draft dSIP February 2007
8.6. Presence
We use SUBSCRIBE/NOTIFY for this. We subscribe to every user on our
friend list when we come online. If the friends are online, that
means that we know exactly where they are. Peers MAY use the PeerIDs
of their friends' peers as additional routing table entries or
neighbor peers (essentially, cached values), consulting these first,
as connections are likely to be made to people on the user's friend
list. These should also be periodically checked, as described in the
DHT Maintenance (Section 6.4).
If friends are offline, one should periodically try to make the
connection. However, if a UA receives a SUBSCRIBE from a friend that
it believes to be offline, it SHOULD attempt to subscribe to that
friend. This will allow people that are reciprocally on each other's
friend lists to rapidly be notified when one or the other comes
online, therefore the retry interval for subscribing to offline
friends can be fairly long because it is only necessary in the case
of race conditions or other temporary failures in resource location.
8.7. Offline Storage
Delivery of messages to offline users, or voicemail for voice
applications, requires storing that information for later retrieval.
Storing user configuration information in a format accessible from
the network also will allow a user to retrieve their profile from any
computer. Cao et al. [18] describe an approach that separates the
storage of resource location information from the actual storage of
the offline research. We believe that this approach is in agreement
with the approach taken by the rest of this document, which relies on
the DHT overlay to store the registrar's location information, but
relies on external, conventional methods for the actual connection.
For offline storage, it also allows the use of other standard
protocols to store and retrieve the offline information, keeping the
P2PSIP scope restricted to storing resource mappings.
9. Pluggable DHT Algorithm Requirements
All dSIP peers MUST support the Chord pluggable DHT algorithm for
compatibility. They MAY support additional pluggable algorithms.
The requirements for new pluggable algorithms are defined in this
section.
Pluggable algorithm MUST use Peer-IDs and Resource-IDs as defined in
Hash Algorithms and Identifiers (Section 5.2) Pluggable algorithms
are free to define what hash algorithms they support, but they MUST
clearly specify what they are.
Bryan, et al. Expires August 29, 2007 [Page 35]
Internet-Draft dSIP February 2007
A resource with Resource-ID k will be stored by the peer with Peer-ID
closest to the Resource-ID. The definition of closeness may vary in
different DHT algorithms, but each DHT algorithm MUST guarantee
Resource-ID searches converge to exactly one peer responsible for
that portion of the namespace. As peers enter and leave, resources
may be stored on different peers, so the information related to them
is exchanged as peers enter and leave. Redundancy is used to protect
against loss of information in the event of a peer failure.
Each new DHT algorithm MUST define a value for the dht-name parameter
to be used in the dht-param parameter of the DHT-PeerID header, as
defined in DHT Algorithms and the dht parameter (Section 5.4.3).
Each new DHT algorithm MUST define the valid BNF for the link-value
used in the DHT-Link header, as defined in The DHT-Link header
(Section 5.5).
10. Security Considerations
The goal of P2PSIP is to scale gracefully from ad hoc groups of a few
people to an overlay of millions of peers across the globe. As such,
there is no one security model that fits the needs of all envisioned
environments; for the small network establishing a certificate chain
is ludicrously difficult, while for a global network the unrestricted
ability to insert resources and devise useful Peer IDs is a clear
invitation to insecurity. Any P2PSIP protocol must offer a range of
security models that can be selected according to the needs of the
overlay.
10.1. Threat Model
Without other security, the attacker is able to generate an ID and
become a valid peer in the system. They can see other peers and
process certain queries. Attackers may wish to receive
communications intended for other participants, prevent other users
from receiving their messages, prevent large portions of the users
from receiving messages, or send messages that appear to be from
others. Users would like to be sure they are communicating with the
same person they have previously talked to, to be able to verify
identity via some out of band mechanism. Attackers may try to squat
on all the good names. Users would like names that are meaningful to
them. Attackers may have computers that are many times faster than
the average user's. Attackers may be able to DOS other particular
peers and make them fail. To make a robust DHT, many peers need to
store information on behalf of the community. Peers may lie about
this and not store the information. Attackers may wish to see who is
communicating with whom and how much data is getting communicated.
Bryan, et al. Expires August 29, 2007 [Page 36]
Internet-Draft dSIP February 2007
Many of the threats to P2P SIP are also threats to conventional SIP.
As such, P2P SIP imports much of its security from conventional SIP.
However, because conventional SIP generally relies on secure servers
to maintain the integrity of the system, modifications to those
techniques are required to maintain the same level of security.
10.2. Protecting the ID Namespace
The fundamental protection that P2PSIP relies on is protecting the ID
namespace. In particular, many of the attacks on P2PSIP require
identifying a particular portion of the ID space and acquiring
control of that space. This is a common vector both for attacks on a
particular user, by obtaining control of the location in the overlay
where the user is registered, and on the overlay itself, by means of
a Sybil [19] attack when one is able to insert multiple identities at
different locations on the ring.
The P2PSIP ID Namespace is considered protected when an attacker is
not able to select an arbitrary Peer-ID and insert a peer at the
location by convincing other peers to route traffic to them. This
protects against hijacking and DoS attacks. The ID Namespace may
also be protected by restricting admission to the overlay to some
authorized (and trusted) set of individuals.
10.2.1. Protection Using ID Hashing
The default base security for P2PSIP determines Peer-IDs by hashing
the peer's IP address and appending the port number. The security of
this scheme depends on the ease with which an attacker can choose
their own Peer-ID. Because the port number is only appended to the
Peer-ID, an attacker gains nothing by selecting different ports on
the same node. Assuming that the SHA1 hash used to calculate the
Peer-ID is reliably random, the attacker's ability to succeed depends
on the number of separate IP addresses that they are able to obtain
from which to launch their attacks.
In the current predominantly IPV4 Internet, few attackers have access
to more than a handful of IP addresses, perhaps a few hundred at
worst. For a large-scale P2P system, this is unlikely to provide the
ability to hijack a particular user ID or control a sufficient
portion of the network to affect other peers, in particular when
registrations are replicated at independent peers. Ultimately,
however, a sufficiently skilled and provisioned attacker can
compromise this scheme.
As the Internet migrates to IPV6, however, it is unclear that the
assumption that few attackers have access to a significant range of
IP addresses will remain true. Therefore, hashing IP addresses to
Bryan, et al. Expires August 29, 2007 [Page 37]
Internet-Draft dSIP February 2007
Peer-IDs is assumed to provide a diminishing amount of security in
the future.
10.2.2. Cryptographic Protection
Stronger protection guarantees are possible by relying on
cryptographic techniques to restrict the generation of peer IDs,
either through requiring knowledge of a shared secret to calculate a
valid hash or by issuing certificates through a central authority.
These techniques are further described in Security for dSIP [9].
10.3. Protecting the resource namespace
The two primary vectors of attacks on resources in a P2PSIP overlay
are inserting illegitimate resources into the overlay and corrupting
the registrations for which a compromised peer is responsible.
For overlays that do not rely on certificates, once a peer has joined
the overlay there are no restrictions on its ability to register
resources. In an unsecured network, multiple peers can register the
same resource (username) in the overlay. However, self-signed
certificates [14] can be used to authenticate a user as the same user
previously contacted with that certificate. Unless a conventional
SIP authentication server is available, however, establishing
identity upon initial contact is still a problem. One potential
solution is for an overlay that is expected to persist over long
time-frames to store the credentials of previous users for
verification of a new registration. These techniques are beyond the
scope of this document.
The second form of resource attack, which is really an ID attack,
concerns the attacks that are possible when a peer has legitimately
inserted itself into the overlay and is now responsible for storing
resource registrations. Such an attack could occur through a
corrupted peer or by an attacker who convinces the CA to issue them a
certificate for a Peer-ID. In this case, the peer can corrupt any
resource that is assigned to it. In the absence of certificates, the
primary means of defense of such attacks is relying on the
replication described in Section Section 5.2.2. By storing replicas
of each registration on multiple peers and performing parallel
searches for resource lookup, the searching peer protects itself from
a single peer trying to corrupt the namespace.
Further protection from each attack vector is achieved by relying on
certificates for resource authentication [9].
Bryan, et al. Expires August 29, 2007 [Page 38]
Internet-Draft dSIP February 2007
10.4. Protecting the Routing
The DHT forms a complex routing table. When a peer joins, it may
contact a subversive peer that lies about the finger table
information it provides. The subversive peer could do this to try to
trick the joining peer to route all the traffic to a subversive group
of peers. Prevention of this attack relies on protecting the
namespace and (for hashed namespaces) identifying trusted bootstrap
peers to use when joining.
Resource searches are protected from a single subversive peer through
the use of parallel searches on replicated registrations. Similar
protection could be achieved through performing parallel searches
using multiple bootstrap peers for initial join, but such
specification is beyond the scope of this draft. When possible,
securing the namespace is a better solution.
10.5. Protecting the Signaling
The goal here is to stop an attacker from knowing who is signaling
what to whom. An attacker being able to observe the activities of a
specific individual is unlikely given the randomization of IDs and
routing based on the present peers discussed above.
10.6. Protecting the Media
As with conventional SIP, all the media SHOULD be encrypted.
Negotiating encryption for an end-to-end media session should be
performed in the same manner for P2PSIP communications.
10.7. Replay Attacks
Defense against replay attacks is discussed in [9].
11. Open Issues
There are certainly many open issues. Here are a few.
Still to be worked out are details of how P2PSIP names are
disambiguated from conventional names that use DNS based routing.
12. Acknowledgments
A team of people have worked on the various drafts related to the
dSIP protocol and extensions thereof. The team consists of: David
Bryan, Eric Cooper, James Deverick, Cullen Jennings, Bruce Lowekamp,
Bryan, et al. Expires August 29, 2007 [Page 39]
Internet-Draft dSIP February 2007
Philip Matthews, and Marcia Zangrilli.
Thanks to all who have been actively participating in the P2PSIP
efforts. Special thanks to Spencer Dawkins, Enrico Marocco, and
Jean-Francois Wauthy for providing editorial feedback, and Henry
Sinnreich, Eric Rescorla, and Alan Johnston for various discussions
related to this work.
13. IANA Considerations
This document would require registering the following:
o Option tag "DHT"
o "DHT-Link" as a Header Field
o "DHT-PeerID" as a Header Field
o "peer" as a valid value for parameter user (?)
o "Resource-ID" as a valid URI parameter (?)
o "hmac-sha1" as an Identity-Info 'alg' parameter
[ToDo: This section needs to be revamped to include all the new BNF
introduced]
14. Changes to this Version
While this is a -00 document, it has grown from the earlier drafts
draft-bryan-sipping-p2p-xx. As such, we discuss the changes from the
most recent version of that draft, -03.
1. The earlier draft has been split into a number of drafts:
1. This draft, providing the background and overall concept,
basic terminology for encoding P2P messages in SIP,
2. We have removed "-" from a number of headers and parameter names
to shorten the overall length of the messages. Additionally, we
have provided short versions for some strings in the syntax to
help reduce message size.
3. We have attempted to use the new terminology defined in [2]
wherever possible, and have attempted not to replicate
definitions here. In particular, we have substituted the use of
the term "peer" for "node"
4. As a consequence of the above, NodeID has been replaced with
PeerID, both in text and in the actual defined messages sent
over the wire.
5. We have made many changes to include details essential to using
this in real deployed systems or clarifying difficult concepts;
lessons learned from building a commercial application based on
this draft.
Bryan, et al. Expires August 29, 2007 [Page 40]
Internet-Draft dSIP February 2007
6. Large parts of the description of how an initial overlay is
formed were quite confusing as our description did not
explicitly embrace the NULL predecessor concept of Chord. We
have corrected this in the sections describing the algorithms.
7. A full and detailed example showing the startup of a 3 node
system has been inserted into the examples section.
8. A new section has been added detailing early work on
incorporating SIP identity into a P2P environment. This work is
then used in the security section.
9. The security section has been thoroughly rewritten to reflect
changes both in our thoughts and the thoughts of the P2PSIP
working group as a whole.
10. We corrected a number of outright errors and typos pointed by a
number of individuals, as mentioned in the acknowledgments.
15. References
15.1. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Willis, D., "Concepts and Terminology for Peer to Peer SIP",
draft-willis-p2psip-concepts-03 (work in progress),
October 2006.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Rosenberg, J., "Simple Traversal Underneath Network Address
Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-05
(work in progress), October 2006.
[5] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols", draft-ietf-mmusic-ice-13 (work in
progress), January 2007.
[6] Cooper, E., Matthews, P., Bryan, D., and B. Lowekamp, "NAT
Traversal for dSIP", Internet
Draft draft-matthews-p2psip-dsip-nat-traversal-00,
February 2007.
[7] Zangrilli, M. and D. Bryan, "A Chord-based DHT for Resource
Lookup in P2PSIP", Internet
Draft draft-zangrilli-p2psip-dsip-dhtchord-00, February 2007.
Bryan, et al. Expires August 29, 2007 [Page 41]
Internet-Draft dSIP February 2007
[8] Zangrilli, M. and D. Bryan, "A Bamboo-based DHT for Resource
Lookup in P2PSIP", Internet
Draft draft-zangrilli-p2psip-dsip-dhtbamboo-00, February 2007.
[9] Lowekamp, B. and J. Deverick, "Authenticated Identity
Extensions to dSIP", Internet
Draft draft-lowekamp-p2psip-dsip-security-00, February 2007.
[10] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[11] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[12] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
RFC 3174, September 2001.
[13] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.
[14] Jennings, C., "Certificate Management Service for The Session
Initiation Protocol (SIP)", draft-ietf-sip-certs-02 (work in
progress), October 2006.
15.2. Informative References
[15] Bryan, D., Shim, E., and B. Lowekamp, "Use Cases for Peer-to-
Peer Session Initiation Protocol (P2PSIP)", Internet
Draft draft-bryan-sipping-p2p-usecases-00, November 2005.
[16] Bryan, D., Jennings, C., and B. Lowekamp, "SOSIMPLE: A
Serverless, Standards-based, P2P SIP Communication System",
Proceedings of the 2005 International Workshop on Advanced
Architectures and Algorithms for Internet Delivery and
Applications (AAA-IDEA) '05, June 2005.
[17] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal
Underneath NAT (STUN)", draft-ietf-behave-turn-02 (work in
progress), October 2006.
[18] Cao, F., Bryan, D., and B. Lowekamp, "Providing Secure Services
in Peer-to-Peer Communications Networks with Central Security
Server", Internation Conference on Internet and Web
Applications and Services (ICIW) '06, February 2006.
[19] Douceur, J., "The Sybil Attack", IPTPS '02, March 2002.
Bryan, et al. Expires August 29, 2007 [Page 42]
Internet-Draft dSIP February 2007
Authors' Addresses
David A. Bryan
SIPeerior Technologies, Inc.
3000 Easter Circle
Williamsburg, VA 23188
USA
Phone: +1 757 565 0101
Email: dbryan@sipeerior.com
Bruce B. Lowekamp
SIPeerior; William & Mary
3000 Easter Circle
Williamsburg, VA 23188
USA
Phone: +1 757 565 0101
Email: lowekamp@sipeerior.com
Cullen Jennings
Cisco Systems
170 West Tasman Drive
MS: SJC-21/3
San Jose, CA 95134
USA
Phone: +1 408 421 9990
Email: fluffy@cisco.com
Bryan, et al. Expires August 29, 2007 [Page 43]
Internet-Draft dSIP February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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).
Bryan, et al. Expires August 29, 2007 [Page 44]
| PAFTECH AB 2003-2026 | 2026-04-22 22:47:41 |