SIPPING WG E. Shim
Internet-Draft S. Narayanan
Expires: August 30, 2006 G. Daley
Panasonic
February 26, 2006
An Architecture for Peer-to-Peer Session Initiation Protocol (P2P SIP)
draft-shim-sipping-p2p-arch-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 30, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes an architecture for peer-to-peer SIP systems
in which a separate and independent peer-to-peer overlay layer
provides a distributed resource placement and search service for SIP.
It also aims to help identify what should be specified for
interoperation.
Shim, et al. Expires August 30, 2006 [Page 1]
Internet-Draft P2P SIP Use Cases February 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Scope of the architecture document . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 5
4. SIP entity operations . . . . . . . . . . . . . . . . . . . . 8
4.1 P2P UA Behavior . . . . . . . . . . . . . . . . . . . . . 9
4.2 P2P Proxy Behavior . . . . . . . . . . . . . . . . . . . . 9
4.3 P2P Registrar Behavior . . . . . . . . . . . . . . . . . . 10
4.4 Example Call Flows . . . . . . . . . . . . . . . . . . . . 11
4.4.1 Call Flow between P2P UAs . . . . . . . . . . . . . . 11
4.4.2 Call Flow between CS UA and P2P UA within the same
domain . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Peer Initiation . . . . . . . . . . . . . . . . . . . . . . . 14
5.1 Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 14
5.2 Association and Authentication . . . . . . . . . . . . . . 16
5.3 Association . . . . . . . . . . . . . . . . . . . . . . . 16
5.4 Authentication . . . . . . . . . . . . . . . . . . . . . . 17
5.5 NAT/FW Traversal . . . . . . . . . . . . . . . . . . . . . 17
6. Registration . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Becoming a Super Node . . . . . . . . . . . . . . . . . . . . 18
8. Formats of Resource Records for SIP . . . . . . . . . . . . . 19
9. P2P Overlay API . . . . . . . . . . . . . . . . . . . . . . . 20
10. What Needs To Be Specified . . . . . . . . . . . . . . . . . 22
11. Security Considerations . . . . . . . . . . . . . . . . . . 23
11.1 Bootstrapping Security . . . . . . . . . . . . . . . . . . 23
11.2 ON/SN Authentication . . . . . . . . . . . . . . . . . . . 23
11.3 Peer Transport Security . . . . . . . . . . . . . . . . . 23
11.4 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 24
11.5 Network Address Translators . . . . . . . . . . . . . . . 24
11.6 Registration . . . . . . . . . . . . . . . . . . . . . . . 24
11.7 Session Endpoint Discovery and Security . . . . . . . . . 25
11.8 Ill Behavior of Ordinary Nodes . . . . . . . . . . . . . . 25
11.9 Ill Behavior of Super Nodes . . . . . . . . . . . . . . . 26
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
13.1 Normative References . . . . . . . . . . . . . . . . . . . 26
13.2 Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . 29
Shim, et al. Expires August 30, 2006 [Page 2]
Internet-Draft P2P SIP Use Cases February 2006
1. Introduction
The Session Initiation Protocol (SIP) [1] has been used largely in
the client/server model. In the client/server model, the User Agent
nodes, being client nodes, typically use services provided by
dedicated server nodes such as SIP Proxy, SIP Registrar, and location
server. Those servers are physically different from the nodes with
User Agents, statically configured to play their roles, and managed
by administrators.
In comparison, in the Peer-to-peer (P2P) networking model, the
participating nodes, or peers, which are sharing their computing and
networking resources, perform all or some of the server functions in
a distributed fashion, thus eliminating need for all or some of the
dedicated servers. There are two fundamental functions required to
realize the P2P networking model. First, the peers, distributed
randomly over the physical network, should be able to form an overlay
network, which is managed in an automatic and distributed fashion.
This function is called herein the P2P overlay management function
that mainly handles peers joining and leaving the overlay network.
Second, the peers should be able to discover resources that are
distributed among the peers, and furthermore, should be able to place
resources among the peers when remote peers dynamically create the
resources for use. This function is called the P2P Service Function
that mainly handles lookup and placement of resources. The above two
functions together are referred to as 'the P2P overlay functions'.
SIP can be used in the P2P networking model. In particular, the P2P
service function can be used to provide a distributed location
service for SIP. For convenience of presentation, SIP operating in
the P2P networking model is called 'P2P SIP (Peer-to-Peer Session
Initiation Protocol)'.
1.1 Scope of the architecture document
This document aims to describe an architecture for systems based on
P2P SIP. The key characteristic of the P2P SIP architecture is that
a separate layer, independent of SIP, provides the P2P overlay
functions and SIP is an application using the services of the layer.
In this document, the components of the P2P overlay network are
identified along with the specification of the overall network
architecture of the P2P overlay. This document also defines new P2P
SIP logical entities and their behavior corresponding to the logical
entities (UA, Proxy, Registrar) defined by the SIP specification.
Example call procedures are presented to demonstrate how these new
P2P SIP entities will operate to establish SIP signaling. The
initiation procedure required for a new peer to become part of the
P2P overlay is also specified. This version of the document assumes
Shim, et al. Expires August 30, 2006 [Page 3]
Internet-Draft P2P SIP Use Cases February 2006
all the peers in the network are well-behaved nodes and thus ignores
the possible denial of service problems due to nodes not contributing
to the well being of the overlay, in the main text. An initial
discussion on this is provided in the Security Considerations
Section 11. This is an important problem that will be addressed in
future versions of the document.
2. Terminology
In this document, words which are normally key words, such as "MUST",
"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are used
COLLOQUIALLY and are not intended to be interpreted as described in
RFC2119 [1].
Peer-to-Peer (P2P) Architecture: An architecture in which nodes
(peers) cooperate together to perform tasks. Each node has
essentially equal importance and performs the same tasks within
the network. Additionally, nodes communicate directly with one
another to perform tasks. Occasionally, nodes with better
resources (such as not being behind NATs) may have a more
significant role.
(P2P Overlay) Bootstrapping: Finding a peer already participating in
the target P2P overlay network in order to join the P2P overlay
network.
Bootstrap seed(s): A super node on the P2P overlay network that is
used as the first point of contact for new P2P entities coming
online.
Bootstrap server(s): A server on the network that provides a peer
with the address of a node already in the P2P overlay network.
Neighbor or Neighboring Peer: A peer whose contact information such
as IP address is known and maintained by the local peer.
P2P Overlay Entity: An entity in the protocol stack that implements
the P2P overlay functions.
P2P Overlay Functions: The P2P overlay management function and the
P2P service function.
P2P Overlay Layer: A protocol layer that handles the P2P overlay
functions.
P2P Overlay Management Function: Peer initiation and handling join
and leave of peers to maintain a P2P overlay network.
P2P Proxy: A SIP proxy on a device with the P2P overlay layer.
P2P Registrar: A SIP registrar on a device with the P2P overlay
layer.
P2P Service Function: Placing resources on certain peers and
discovering locations of target resources in the P2P overlay
network, in short, placement and lookup of resources.
Shim, et al. Expires August 30, 2006 [Page 4]
Internet-Draft P2P SIP Use Cases February 2006
P2P SIP System: A system in which P2P SIP is used to realize
applications such as VoIP, Presence and Instant Messaging.
P2P SIP: SIP running over a P2P overlay network in which SIP
resources, such as user location information, are managed by a P2P
overlay network.
P2P UA (P2P User Agent): A SIP UA (user agent) on a device with the
P2P overlay layer.
Peer Initiation: Bootstrapping and any other tasks necessary for a
peer to reach the state in which the peer can perform placement
and search in the P2P overlay network.
Peer: A network node offering its own resources for other peers and
using resources of other peers for its own good. The term 'peer'
is used interchangeably with 'node' in the context of peer-to-peer
overlay networks.
Peer-to-Peer (P2P) Overlay Network: An overlay network formed and
self-managed by the participating peers.
Resource Record: A record about a resource that may include the
resource itself or include just meta-data about the resource. To
share a resource, a peer creates a resource record that is
accessible to other peers. Looking up a resource is equivalent to
looking up a resource record.
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). Nodes
located in this hash space also have a unique identifier within
the hash space. Nodes store information about resources with keys
that are numerically similar to the node's identifier in the hash
space [13].
Terminology defined in RFC3261 [2] is used without definition.
3. Architecture Overview
A peer in the P2P SIP system is comprised of two layers: the P2P
overlay layer and the SIP layer. The P2P overlay layer handles all
the P2P overlay functions. The P2P overlay layer does not interpret
semantic meanings of the resources placed or looked up by the higher
layers including SIP. But its design goal is serving SIP and thus
SIP-based real-time media applications. That is, other applications
may use the P2P overlay layer presented here but the architecture and
the algorithm used for this P2P overlay layer may not necessarily be
optimal for all applications.
From the perspective of SIP, the P2P overlay layer provides mainly a
location service for various SIP resources. One of the most
important information, or resource, for SIP operation is the user
location, i.e., the IP address corresponding to a SIP URI [2].
Typically, the caller precisely knows the SIP URI of the call
Shim, et al. Expires August 30, 2006 [Page 5]
Internet-Draft P2P SIP Use Cases February 2006
recipient before a call is made. DHT (Distributed Hash Table) based
structured P2P networks support efficient search mechanisms when the
resource names are precisely known, thus, meets the requirements of
P2P SIP well. Therefore, we propose the use of DHT for the P2P
overlay layer.
P2P overlay networks can be comprised of peers with different amount
of physical resources operating in various network environments. The
larger a P2P overlay network is, the more significant the
heterogeneity of peers will be. Even though every peer is ideally
supposed to contribute its physical resources to the services of the
P2P overlay network for other peers, peers without proper physical
resources had better be exempted from the obligation for better
performance of the P2P overlay network in overall.
So peers are classified into two types: super nodes (SNs) and
ordinary nodes (ONs). For DHT-based P2P overlay networks, super
nodes participate in building and maintaining the DHT. Ordinary
nodes do not participate in DHT. Super nodes serve search requests
by routing the search traffic or generating replies to search
requests. To discover a resource from other peers, an ordinary node
sends a search request message to a super node. Then the super node
routes the search request message in the DHT. In a sense, super
nodes comprise a distributed storage and search service network.
Either an ordinary node or a super node could use the service
provided by the overlay network. Depending on the system
requirements, some systems based on P2P SIP may be comprised of only
super nodes. A farm of SIP proxies using P2P SIP among themselves is
an example of such a system. In this document, unless particularly
mentioned, a system is assumed to have the two types of peers. The
P2P SIP specification will contain descriptions of the protocols
between the ON-SN pair and the SN-SN pair.
Since only the super nodes participate in the DHT, the P2P overlay
network has a hierarchical structure: the core consisting of super
nodes forming a DHT with a periphery of ordinary nodes.
Each ordinary node is associated with one or more super nodes. The
relationship between the ordinary node and those super nodes is like
that of a client and servers or of a host and routers. The ordinary
node uses the storage and lookup services of the overlay network core
through the associated super nodes. SIP has its own hierarchical
structure. SIP proxies form a kind of infrastructure providing call
request routing services and SIP UAs use the services. SIP event
servers store the event subscription records and distribute event
information to the subscribers. In general, the hierarchy of peers
in the P2P overlay layer is independent of the hierarchical structure
of SIP. A UA with P2P overlay layer is referred to as P2P UA in this
Shim, et al. Expires August 30, 2006 [Page 6]
Internet-Draft P2P SIP Use Cases February 2006
document, and similarly a proxy or a registrar with P2P overlay layer
is referred to P2P Proxy or P2P-Registrar respectively. For example,
it is possible to build a P2P VoIP network comprised of only P2P UAs
running over a P2P overlay network with the distinction of super
nodes and ordinary nodes. It is also possible to run a P2P Proxy
process over an ordinary node. Super nodes are good candidates to be
P2P-Proxies but not all super nodes in a P2P overlay network have to
become a P2P Proxy. The choice of SIP entity on a peer node will
depend on the specific system design. Authorization to join the P2P
overlay network is based only on user credentials, i.e., a device is
authorized based on the credential of the user or the service using
the device. A user can change devices freely and use multiple
devices simultaneously. Authentication and authorization is provided
primarily by a central logical entity named a login serverHow a user
subscribes to a login server is out of scope of this document. Out-
of-band methods such as web pages can be used.
There are four types of entities in the P2P overlay network, a
logical view of which is depicted in figure 1.
+---------+ +------------+ +----+
| Login | | Bootstrap | | ON | +----+
| Server | | Server | +----+ | ON |
+---------+ +------------+ | +----+
| |
+----+ V |
| ON |--------> +----+ +----+ <--------+
+----+ --+ | SN | ============ | SN |
| +----+ === +----+ +----+ <---------+
+----+ | || | SN | || |
| ON | +----> +----+ === +----+== +----+ |
+----+ -------> | SN | ^ ^ | SN | +----+
+----> +----+ | | +----+ <------- | ON |
+----+ | ^ | | ^ +----+
| ON | --+ | +--------+ +-- + |
+----+ | | | |
+----+ +----+
| ON | | ON |
+----+ +----+
Figure 1: A logical view of the P2P overlay network with
four types of entities: Ordinary Node, Super Node,
Login Server, and Bootstrap Server.
Once a node knows one or multiple nodes participating in a P2P
overlay network, it can start the process to join the network. A
Shim, et al. Expires August 30, 2006 [Page 7]
Internet-Draft P2P SIP Use Cases February 2006
bootstrap server is an entity that provides a new node with the
information about existing nodes in the target P2P overlay network.
The login server and the bootstrap server facilitate formation of a
P2P overlay network. When other means become available for their
functions, they can be omitted. In this sense, they are optional
entities.
4. SIP entity operations
The separation of the P2P overlay layer and the SIP layers allows for
the possibility of a P2P SIP network that consists of multiple P2P
overlay networks with a P2P Proxy routing SIP signaling messages from
one overlay to another. These individual P2P overlay networks MAY
either correspond to a single SIP domain where every P2P SIP entity
on the particular overlay network will be from the same SIP domain,
or a P2P overlay network MAY have P2P SIP entities from multiple SIP
domains. When a P2P UA tries to establish a call to another P2P UA
in the same P2P overlay network, the INVITE message will be sent
directly to the destination P2P UA based on a lookup in the P2P
overlay network. If a P2P UA tries to establish a call to another
P2P UA in a different P2P overlay, the INVITE message will be
forwarded to a P2P Proxy of the local overlay network which in turn
will route the INVITE message to the final destination through the a
P2P Proxy associated with the remote domain.
The P2P service function may be used for SIP in various forms,
resulting in different network composition scenarios. There are
three key logical entities defined by SIP [SIP], a User Agent (UA), a
Proxy and a Registrar. Each of these SIP entities could potentially
include a P2P overlay layer and become part of the P2P overlay
network. These SIP entities with a P2P overlay layer are referred to
as P2P UA, P2P Proxy or P2P-Registrar. Different combination of the
P2P and Client-Server (CS) SIP entities could be combined to create
the network composition of a particular SIP domain. Table 1
summarizes what we consider as meaningful network composition
scenarios and the roles of the P2P layer from the SIP perspective.
+---+----+-------+---------+----------------------------------------+
| | UA | Proxy |Registrar| Role of P2P Overlay Layer |
+---+----+-------+---------+----------------------------------------+
|(a)| P2P| P2P |Not | Replace the Registrar, the location |
| | | |Required | database and DNS lookup for local proxy|
+---+----+-------+---------+----------------------------------------+
|(b)| CS | P2P | P2P | Replace the location database |
+---+----+-------+---------+----------------------------------------+
Shim, et al. Expires August 30, 2006 [Page 8]
Internet-Draft P2P SIP Use Cases February 2006
Table 1. Network composition scenarios for a SIP domain
In the above table, 'P2P' implies that the corresponding SIP entity
is on a peer device participating in the P2P overlay and 'CS' implies
a client-server SIP entity. The behavior of each P2P SIP entity is
described below.
4.1 P2P UA Behavior
The P2P UA uses the P2P service function to store its user location
information in the P2P overlay network or to look up user location
information for target UAs it may want to contact. So, for user
registration, the P2P UA creates a user location record as described
in Section 8 and requests its local P2P overlay layer to place the
user location record in the overlay network by calling the P2P
overlay API functions, either add() or update(). Based on the
lifetime set in the user location record, the P2P UA periodically
refereshes the user location record. The configuration information
required by the P2P UA is one or more of the SIP-URIs by which it can
be contacted and the identifier of the overlay network which the P2P
UA should join.
To make an outgoing call, a P2P UA SHOULD try retrieving the resource
record in the following order:
- The target UA associated with the callee.
- The local Proxy associated with its own domain.
It is important to note that these location records should be
verifiable by means of some secure signature based on credentials
derived from the login server. If both of these lookups fail, the
P2P UA MAY try a DNS lookup for the local proxy associated with its
own domain. A P2P UA MAY be configured to try the local proxy
always. The default behavior described above SHOULD be followed in
the absence of such a configured choice.
Once the next hop is identified and an INVITE message is sent to that
node, the P2P UA behaves the same way as the UA in the client server
model. For incoming calls, the P2P UA behaves the same way as the UA
in the client server model.
4.2 P2P Proxy Behavior
A P2P Proxy plays the role of a gateway between two P2P overlay
networks or between a clisent-server SIP domain and a P2P overlay
network. Hence, a P2P Proxy MAY be a part of more than one P2P
overlay network. Once the local P2P overlay layer completes
initiation and joins the P2P overlay network, a P2P proxy generates
its location record based on its domain name and requests its local
Shim, et al. Expires August 30, 2006 [Page 9]
Internet-Draft P2P SIP Use Cases February 2006
P2P overlay layer entity to place the record in the overlay network.
Since there can be multiple proxies for the same domain, the P2P
proxy uses add() function of the P2P overlay API to place its
location record. The P2P Proxy is responsible for keeping the
location record on the overlay up-to-date by adding a new record as
the old record gets close to expiration. The configuration
information required by P2P Proxy is the domain name it is associated
with and the overlay identifier that corresponds to the particular
domain.
Upon receiving an INVITE message, a P2P proxy determines whether the
callee's URI belongs to a domain it supports or a remote domain. In
the former case, the P2P proxy MUST lookup user location records of
the callee in the corresponding overlay network and forwards the
INVITE message to the location of the callee. Once having found the
location or multiple possible locations of the callee and verifying
the authenticity of these location record(s), the P2P proxy behaves
the same way as the proxy in the client server model. If the lookup
in the P2P overlay fails and it knows a SIP location server for the
local domain, the P2P proxy MAY contact the SIP location server for
the callee's location.
- If the callee's URI belongs to a remote domain, the P2P proxy
SHOULD locate the remote proxy associated with the URI using DNS
as specified by the client-server SIP specification.
The architecture as described in this document allows for the
possibility of constructing a transit P2P overlay network among P2P
Proxies that can be used to locate the P2P Proxy of the remote
domain. In order to achieve this, the overlay identifier
corresponding to the transit network must be configured into these
P2P Proxies. In such a scenario, the P2P Proxy will try a lookup of
the remote proxy on this overlay network before falling back to DNS
lookup as a backup to reach other proxies that are not part of this
transit overlay network.
4.3 P2P Registrar Behavior
When a P2P overlay network is used to store location information of
CS UAs (UAs operating in the client server model), the Registrar
serving the CS UAs is configured to participate in the P2P overlay
network, thus called a P2P Registrar. If a P2P Registrar is
configured, it functions as the front of the P2P overlay network.
When a SIP registration message is received, the P2P Registrar
generates a user location record for the registering UA and requests
the P2P overlay layer to place the location record in the overlay
network.
Shim, et al. Expires August 30, 2006 [Page 10]
Internet-Draft P2P SIP Use Cases February 2006
4.4 Example Call Flows
The following example call flows provide an indication of the
messages required to establish sessions in various environments.
Further work is required in this area, and the following is presented
for indicative purposes only.
4.4.1 Call Flow between P2P UAs
Now let's look at how a simple one-to-one call is established between
two P2P UAs. Figure 2 illustrates an example sequence of message
transfer during call establishment where both the caller and the
callee are P2P UAs and have public IP addresses. Also, both P2P UAs
are in the same overlay network. It is assumed that there is no
firewall blocking SIP or the P2P overlay protocol between peers. In
this scenario, the user on node 1 (an ON) is the caller and the user
on node 4 (an ON) is the callee. The user location record of the
callee happens to be stored at node 3. With a call establishment
command from the application, the UAC is given the SIP URI of the
callee. The UAC does not have the location information for the
callee, thus generates the resource key for the user location of the
callee, and requests the P2P overlay layer to search for the callee's
location by calling the P2P overlay API described in Section 9(step
1).
Upon receiving the search request, the P2P overlay layer generates a
search request message that contains the resource key from the SIP
layer and sends it to the associated super node (step 2). The
associated super node checks its local storage and forwards the
search request message to the next hop according to the DHT routing
table (step 3) if it does not have the target resource. The peer who
has the target resource sends a search reply message containing the
resource, i.e., the callee's user location record in this case (step
4). The search reply message is directly sent back to the SN
associated with the caller peer, i.e. the search reply does not
retrace the path of the search message. Upon receiving the search
reply message, the associated super node forwards the reply to the
calling ordinary node (step 5). The P2P overlay layer of the calling
peer returns the resource to the SIP layer (step 6). The UAC
interprets the user location record and identifies the IP address and
the port number for the UAS. Then the UAC generates an INVITE
message and sends it to the UAS directly (step 7). From this point,
the two UAs can communicate directly with each other.
Shim, et al. Expires August 30, 2006 [Page 11]
Internet-Draft P2P SIP Use Cases February 2006
+----------------------------------------------------------+
| +----------------------------------------------------+ |200 OK
| | INVITE (7) | |(8)
V | V |
+------------+ +------------+ +------------+ +------------+
|+----------+| |+----------+| | | |+----------+|
||SIP Layer || ||SIP Layer || | | ||SIP Layer ||
|+----------+| |+----------+| | | |+----------+|
| | ^ | | | | | | |
| |(1) |(6) | | | | | | |
| V | | | | | | | |
|+----------+| |+----------+| |+----------+| |+----------+|
|| P2P ||--> || P2P ||--> || P2P || || P2P ||
|| Overlay ||(2) || Overlay || (3) || Overlay || || Overlay ||
|| Layer || || Layer || || Layer || || Layer ||
|| (ON) || || (SN) || || (SN) || || (SN) ||
|+----------+| |+----------+| |+----------+| |+----------+|
| Node 1 | | Node 2 | | Node 3 | | Node 4 |
+------------+ +------------+ +------------+ +------------+
^ | ^ |
| |(5) | |(4)
+----------------+ +----------------+
Figure 2: A simple call procedure between two P2P UAs
4.4.2 Call Flow between CS UA and P2P UA within the same domain
It is possible to run CS UAs and P2P UAs within the same domain.
Such a composition of a network is useful when CS UAs were already
deployed and P2P UAs are incrementally deployed.
The SIP Registrar is configured to operate as P2P Registrar. The CS
UAs sends registration messages to the P2P Registrar. Then the P2P
Registrar places the location information of CS UAs in the overlay
network via the P2P overlay layer. The P2P UAs place their location
information in the overlay network themselves via the P2P overlay
layer. Figure 3 illustrates an example sequence of message transfer
during call establishment where the caller is a CS SIP UA and the
callee is a P2P UA. In this scenario, both have public IP addresses
without firewall restrictions on SIP or overlay messages. Note that
the overlay network is represented by word 'overlay' and messages
between peers in the P2P overlay layer are not depicted.
UA1, a CS UA, sends an INVITE message, aiming to establish a call
with UA2, to its proxy, which happens to be connected to the P2P
overlay network (Step 1). This proxy then resolves location of UA2.
Shim, et al. Expires August 30, 2006 [Page 12]
Internet-Draft P2P SIP Use Cases February 2006
In this case, the proxy queries the P2P overlay network(Step 2). The
reply contains UA2's location record (step 3). Subsequently, the
INVITE message is forwarded to the discovered location (Step 4).
Upon receiving the INVITE message, UA2 sends a reply message to the
proxy (step 5) that, in turn, forwards it to UA1.
+----------+
|SIP |add(UA1 location) add(UA2 location)
REGISTER |Registrar |-------------> overlay <----------+
/--->|(P2P) | ^ | |
/ +----------+ | | |
/ | | |
/ +---------------------+ | |
/ | get(UA2 location) (2) | |
+----+ / +----------+ <---------------+ +-----+
|UA1 |/ |SIP | UA2 location (3) |UA2 |
|(CS)|----------->|Proxy |----------------------------->|(P2P)|
| | INVITE(1) |(P2P) | INVITE (4) | |
| |<-----------| |<-----------------------------| |
+----+ 200 OK(6) +----------+ 200 OK (5) +-----+
| ^
+-----------------------------------------------------------+
ACK (7)
Figure 3. A call from a CS UA to a P2P UA
When UA2, a P2P UA, calls UA1, a CS UA, UA2 can discover UA1's
location from the P2P overlay network (step 1 and 2). After that,
UA2 sends an INVITE message to UA1 directly (step 3). In this case,
there is no need to go via a Proxy. Figure 4 illustrates this call
procedure.
Shim, et al. Expires August 30, 2006 [Page 13]
Internet-Draft P2P SIP Use Cases February 2006
+----------+
|SIP |add(UA1 location) add(UA2 location)
REGISTER |Registrar |----------> overlay <----------------+
/--->|(P2P) | | ^ |
/ +----------+ | | |
/ | | |
/ | +------------------+ |
/ | get(UA1 location)(1)| |
+----+ / +---------------->+-----+
|UA1 |/ UA1 location (2)|UA2 |
|(CS)|<-----------------------------------------------------|(P2P)|
| | INVITE (3) | |
| |----------------------------------------------------->| |
+----+ 200 OK (4) +-----+
^ |
+-----------------------------------------------------------+
ACK (5)
Figure 4. A call from a P2P UA to a CS UA
5. Peer Initiation
When a node decides to participate in the peer-to-peer SIP network,
it needs to connect to other nodes, and identify peer super nodes
(SN). In order to do this, it starts operation as an ordinary node
(ON). After identifying if it is able to contact SN that compose the
DHT, a peer may become a SN itself.
Below is a summary of the sequence of functions undertaken by a node
in joining the peer-to-peer network. This peer initiation must be
done independently for each P2P overlay network it is trying to join.
Subsections follow describing all of these operations:
(1) Bootstrap
(2) Association and authentication.
(3) NAT/FW traversal (At this stage, outbound sessions are
possible).
In order to receive inbound calls, the peer will then have to
register at least one SIP URI as described in Section 6, and later
the peer MAY also want to become a SN as described in Section 7.
Once a node is a SN, it agrees to service requests by peer SNs, and
allow ONs to connect, register and search through it.
5.1 Bootstrapping
A node wishing to join a peer-to-peer overlay network needs to select
Shim, et al. Expires August 30, 2006 [Page 14]
Internet-Draft P2P SIP Use Cases February 2006
which overlay to join. While a peer may join different overlays, it
will be necessary to maintain separate authorization, registration,
hash tables, as well as separate lists of bootstrap servers. When
discerning which network to join, a node may select to bootstrap only
SNs which have one particular overlay identifier, or to use a default
identifier. This overlay identifier needs to be exchanged in peer-
to-peer messages, as each peer may itself be participating in
multiple P2P overlay networks.
Bootstrapping the ON requires identification of SNs whom a peer
should try to contact initially. Connecting to these SNs provides a
mechanism whereby the peer can contact the peer-to-peer network,
establish trust within that network and start participating in
sessions.
Addresses for the initial contact may be gained by methods outlined
below.
1. Service location (multicast)
2. Cached addresses
3. Last good address
4. Pre-configured bootstrap server(s).
Ordering of attempts to contact SNs is needed for a number of
reasons. We RECOMMEND the above order, as described:
(1) Service Location
A peer can try sending a local multicast request to find if there are
other P2P SIP nodes in the same local area network or administrative
domain.
When P2P SIP is used within a corporate network, this solution for
bootstrapping will be able to identify local resources and even in
the global scenario, once a single node in the same broadcast/
multicast domain joins the P2P overlay, other nodes can bootstrap
locally.
As an example, peers may be able use the Service Location Protocol
(SLP) to identify SNs participating in the P2P network [3][4]. Where
a directory agent is not configured on the network, peers multicast
queries to find a SN, which would act as an SLP Service Agent. If an
existing directory agent is found, this may provide a list of active
SNs.
(2) Cached Addresses:
A peer may retain information about SNs proposed by its SN during its
Shim, et al. Expires August 30, 2006 [Page 15]
Internet-Draft P2P SIP Use Cases February 2006
prior connection to the network. The list allows the SN to notify
the ON of dynamic changes in service availability, and shows if the
ON should first try to use the same SN again.
(3) Last Good Address:
A peer may attempt to contact its last known SN, with which it had a
successful connection. This address may be tried after learned
cached addresses, in order to allow for robustness and spreading of
ONs between SNs within the network.
(4) Preconfigured Bootstrap Server:
The IP address or domain name of a server in the Internet that
maintains a list of currently available SN addresses could be
configured in peers. This server may not participate in the peer-to-
peer network, and the protocol to access the server list may be an
existing protocol like HTTP.
This address is contacted last, as the bootstrap servers are
considered potential failure points, and the intention is to reduce
the load on these devices.
5.2 Association and Authentication
After gathering information about potential SNs, the peer should
contact candidates, and attempt to authenticate with one or more of
them.
5.3 Association
Selection of the transport for contacting the SN is provided through
the bootstrap process. As such, where multiple choices exist for a
particular IP address or the information about the SN does not
specify which protocol and port to contact the SN on, the ON must
select amongst the following mechanisms by which to contact the peer.
By default, it may be useful to contact the server in the following
order:
- UDP
- TCP
- Fallback Transport.
UDP is favored, as the SN may need to retain less state for each
associated ON.
The Fallback Transport may be HTTP based, and potentially proxied, in
order to gain access through networks which otherwise would not be
Shim, et al. Expires August 30, 2006 [Page 16]
Internet-Draft P2P SIP Use Cases February 2006
able to make these lookups.
Initial contact should confirm the presence of the SN, and ensure
that the SN is functioning in that role. Additional handshakes to
perform mutual return reachability tests may also be incorporated.
5.4 Authentication
In order to participate in the peer-to-peer network as an ordinary
node, credentials MAY be needed to show a node's right to retrieve
and update information. After the association
Additionally, the ON will wish to authenticate the SN, in order to
identify that the connection between the SN and ON is direct, and
that the SN has sufficient authority to undertake operations on the
ON's behalf in the P2P network.
An example authentication scheme is to make use of TLS, in order to
authenticate the ON and SN and derive a secured channel for
communicating between them [6]. Where UDP based operations are
undertaken, the datagram-based version of TLS is used analogously
[draft-rescorla-dtls]. In this scenario, each node requires a
certificate from a mutually acceptable source, and SNs are guaranteed
to already possess one as they would have gone through the initiation
procedure themselves.
5.5 NAT/FW Traversal
In order to undertake peer-to-peer communications with other nodes on
the Internet, SIP messages will need to be exchanged, and media
channels set up between end nodes. In order to ensure communications
are available at session initiation time, it is necessary to test
whether an ON is behind a NAT or a restrictive firewall, which may
limit session establishment from that address.
Therefore, peers should test reachability, for example, by performing
ICE operations, with the SN as the STUN server in order to identify
what type of connectivity they possess [11][5]. Additional
configuration of relay servers may be necessary, and the SN can
identify a TURN server to contact (which may be itself or another
SN). Upon completion of this testing, a set of viable derived
addresses SHOULD be generated on the ON, for use in session
initiation [10].
An ON MAY immediately start retrieving peers' URIs and initiating
outbound calls.
Shim, et al. Expires August 30, 2006 [Page 17]
Internet-Draft P2P SIP Use Cases February 2006
6. Registration
In order to receive inbound calls, a peer needs to publish
information in the p2p network listing addresses and ports using
which it may be contacted. Using the reachability information gained
through NAT and Firewall traversal operations, a peer may advertise a
set of addresses and ports by instructing the SN to place or replace
records in the DHT referring to the ON's own identity. Multiple
records may be managed by specifying the preference relationships as
described in ICE [11]. The API for managing data on the P2P overlay
is presented in Section 9.
7. Becoming a Super Node
Super nodes are self-selected dynamically and automatically. In
order to become a SN, a node
(1) MUST be able to receive messages on predetermined protocols
and ports from other SNs on the overlay network.
(2) SHOULD be online stably. - This requirement may need a metric
to be defined in the future to make it more specific.
(3) SHOULD have sufficient physical resources such as CPU power,
memory size, and network bandwidth. - This requirement may need a
set of metrics to be defined in the future to make it more
specific.
If a peer wishes to become a SN, it MUST be able to receive P2P
overlay management and service function messages from other peers on
pre-defined protocols and ports. When a P2P overlay network spans
over the global Internet and contains peers private IP addresses as
well as peers with public IP addresses, SNs need to perform STUN, and
possibly TURN server operations thus it is RECOMMENDED that SNs
should be on the public Internet, and publicly addressed [5][10]. If
all the peers of a P2P overlay network are in the same address realm,
for example, a LAN befind a NAT, SNs don't have to have, or, actually
can't have public IP addresses.
SN operation requires that the peer reserve space to store a portion
of the hash table, and transfer data into and out of its own storage,
as it or other devices enter or leave the set of SNs. If SNs stay
online only for a short period, signaling traffic to restore the DHT
becomes heavy and search performance may degrade significantly. So
it is desirable to select nodes that are likely to stay online
longer. Different from the first requirement, the second and third
requirements provide only relative criteria. Specific threshold
values for the metrics of the two requirements should be decided
depending on the target system characteristics.
Shim, et al. Expires August 30, 2006 [Page 18]
Internet-Draft P2P SIP Use Cases February 2006
8. Formats of Resource Records for SIP
The peer placing a resource and the peer retrieving the resource via
search should use the same format for the resource record and the
same algorithm to assign a key to a given resource record.
Otherwise, the resource cannot be discovered or interpreted properly.
The resource record is specific to the application that creates and
uses the resource record. It is opaque to the P2P overlay layer.
An example of a user location record is given below.
<resource>
<version>1.0</version>
<!--------- resource format version -->
<type>user location</type>
<!--------- type of the resource -->
<key>19873761ab24</key>
<!--------- key for the resource -->
<lifetime> 3600 </lifetime>
<!--------- lifetime of the record -->
<timestamp>19809832142</timestamp>
<!--------- indicate which is more recent-->
<user_URI> user@example.com </user_URI>
<location>
<node_IP>178.14.234.21</node_IP>
<!--------- the IP address at which the user can be reached-->
<transport>TCP5060 UDP5060 TCP80 TCP443</transport>
<!--------- the list of ports the UA is listening to-->
</location>
<location>
<node_IP>192.168.0.100</node_IP>
<!--------- the IP address at which the user can be reached-->
<transport>TCP5060 UDP5060 TCP80 TCP443</transport>
<!--------- the list of ports the UA is listening to-->
</location>
</resource>
The algorithm for resource key generation depends on the type of
resource. In general, it has the following form.
key = hash(<resource name>).
The resource name is composed as a concatenation of the resource type
name and a string identifying the resource instance within the type.
For user location information, the user URI can identify the resource
instance, and, therefore, the key is generated as follows:
key = hash("user location"+<user_URI>),
where "user location"+<user_URI> is a concatenation of "user
location" and the value of user_URI element. For the above example
Shim, et al. Expires August 30, 2006 [Page 19]
Internet-Draft P2P SIP Use Cases February 2006
user location, the input for the key generation function is "user
location|user@example.com". Using the concatenation method, the user
URI can be used to identify many types of resources. For the hash
function, a cryptographic hash function like SHA-1 [12] should be
used in order to distribute keys uniformly in the key space.
Another type of record is the proxy location record. An example of a
proxy location record is given below.
<resource>
<version>1.0</version>
<!-------- resource format version-->
<type>proxy location</type>
<!-------- type of the resource-->
<key>19873761ab24&l;/key>
<!-------- key for the resource-->
<lifetime> 36000 </lifetime>
<!-------- lifetime of the record-->
<timestamp>198023422</timestamp>
<!-------- indicate which is more recent-->
<domain> example.com </domain>
<location>
<node_IP>178.14.234.21</node_IP>
<!-------- the IP address at which the user can be reached-->
<transport>TCP5060 UDP5060 TCP80 TCP443</transport>
<!-------- the list of ports the proxy is listening to-->
</location>
<location>
<node_IP>192.168.0.100</node_IP>
<!---------- the IP address at which the user can be reached-->
<transport>TCP5060 UDP5060 TCP80 TCP443</transport>
<!---------- the list of ports the proxy is listening to-->
</location>
</resource>
The resource name for a proxy location record is "proxy location"+
<domain>.
9. P2P Overlay API
The P2P overlay layer provides an API by which requests for resource
placement and search over the P2P overlay network can be made. The
semantics of the core functions of the API are described below:
get(in overlay_id, in key, out records, out error)
- action: look up a resource from the P2P overlay network
identified by the overlay_id.
Shim, et al. Expires August 30, 2006 [Page 20]
Internet-Draft P2P SIP Use Cases February 2006
- input parameter
overlay_id: An identifier that uniquely identifies a particular
overlay the node is a member.
key: the key of the target resource.
- output parameters
records: records of the resources returned from the search.
One or multiple records may be included.
error: an error code.
add(in overlay_id, in key, in record, in lifetime, in option, out
error)
- action: place a resource in the P2P overlay network. If a
resource of the same key exists in the overlay network already,
the resource given in the call is added in the network in
addition to the existing resource. That is, add() cannot be
used to change existing resources in the overlay network.
- input parameters
overlay_id: An identifier that uniquely identifies a particular
overlay the node is a member.
key: the key of the resource to be placed.
record: the record of the resource to be placed.
lifetime: lifetime of the resource to be placed.
option: option for placement.
NO_UPDATE_OPTION: Indicates that the record is not updatable;
Then no credentials to identify the source need to be stored
along with record. If updatable, a security credential (likely
derived from the security credentials generated during
authentication procedure) is associated with the record.
- output parameters
error: the error code.
update(in overlay_id, in key, in record, in lifetime, in option,
out error)
- action: update a resource in the P2P overlay network and
create one with the given record if a resource with the given
key does not exist yet. The update operation is allowed for
existing resources whose owner (or creator) is the same as the
updating user. This is verified based on security credentials.
If the stored resource doesn't contain any associated security
credentials the update operation will fail.
- input parameters
overlay_id: An identifier that uniquely identifies a particular
overlay the node is a member.
key: the key of the resource to be placed.
record: the record of the resource to be placed.
lifetime: lifetime of the resource to be placed.
Shim, et al. Expires August 30, 2006 [Page 21]
Internet-Draft P2P SIP Use Cases February 2006
option: option for placement.
- output parameters
error: the error code.
remove(in overlay_id, in key, out error)
- action: remove the resources of the given key from the
overlay network. Like the update function, this is allowed for
existing resources whose owner (or creator) of the resources is
the same as the requesting user. If the authentication doesn't
succeed or if there is no associated security credentials, the
remove operation will fail.
- input parameter
overlay_id: An identifier that uniquely identifies a particular
overlay the node is a member.
key: the key of the target resource.
- output parameters
error: an error code.
If anyone is allowed to remove or update location records of other
users, it becomes so easy to block or interfere with incoming calls
to a particular user. So it is imperative to give the owner of a
resource record the authority to set access control policies for the
resource record, in particular, about updating and removing the
resource record. To support the above API, the P2P overlay layer
manages resource records based on the resource key and resource's
owner identity. Conceptually the overlay layer stores every resource
record with a control information record that includes the resource
key, the owner identity, and the access control policy set by the
owner.
10. What Needs To Be Specified
For interoperation between different devices, the following
interfaces MUST be specified: the SN-ON interface, the SN-SN
interface, the ON-Login Server interface, the SN-login server
interface, and the peer-bootstrap server interface. Since nodes
startup as ON and complete bootstrap before changing to a SN, there
is only one interface with the bootstrap server.
And the formats of resource records for SIP MUST be specified.
Section 8 describes two example resource record types and their
formats.
The API (application program interface) of the P2P overlay layer,
like that in Section 9, is not required to be specified in the
syntatical level that depend on implementations of the SIP layer and
the P2P overlay on each device. However, there MUST be a common set
of services the SIP layer can receive from the P2P overlay layer,
Shim, et al. Expires August 30, 2006 [Page 22]
Internet-Draft P2P SIP Use Cases February 2006
which can be captured in a semantic definition of the P2P overlay API
like that in Section 9.
11. Security Considerations
Peer-to-peer networks need to balance between providing appropriate
trust, and reducing requirements for centralized authority.
Particularly, it is important not to aim at solving generalized
distributed trust problems but instead to focus on use-cases
appropriate to endpoint identification and session establishment.
11.1 Bootstrapping Security
Becoming an ordinary node requires use of dynamically configured
super node information. Where SN information is received from an
untrusted source, or over an unsecured channel, care should be taken
in attempting to contact these nodes, so that time and resources are
not wasted contacting bogus servers.
Additionally, care should be taken not to unduly extend trust to
discovered devices, even where the origin of the SN information is
trusted. This is important, as there may be a change in the trust of
a particular node between the time which SN information was gathered
and the time it is used by the ON for bootstrapping. As such, it is
important that nodes authenticate peers in order to establish
relationships.
11.2 ON/SN Authentication
When connecting to the network, a node needs to authenticate that its
selected SN is trusted, and that it is talking directly to that node.
Similarly, the SN needs to identify that the ON is a valid
participant in the network, and that it is authorized to perform
lookup, and record update operations for P2P SIP.
This authentication needs to occur without constant reference to a
single login server, which would limit scalability, introduce a
single point of failure and therefore defeat the peer-to-peer
paradigm.
11.3 Peer Transport Security
Message authentication must be used between one node and another in a
peer-to-peer network. Where privacy against non-P2P participants is
required, encryption should also be used. Use of encryption suites
with key negotiation may achieve not only the requirement for mutual
authentication, but also data transport security as well [6][7][8].
Shim, et al. Expires August 30, 2006 [Page 23]
Internet-Draft P2P SIP Use Cases February 2006
11.4 Firewalls
Firewalls are typically configured by an organization in order to
prevent certain classes of traffic passing across administrative
boundaries. While application-level gateways exist which control
message contents at upper layers, most firewalls control data flows
by allowing data transfer on ports assigned to specific services.
Any firewall traversal technique that uses an assigned port purely to
find an open channel through a gateway is therefore likely to be
contravening the security policy of the peer's network. This may
particularly be the case where external devices such as tunnel
servers allow inbound session initiation through port relay [10].
Additionally, operation of SN services on ports normally preserved
for other purposes may expose that node to access or attack from
outside the intended boundary of the peer-to-peer network, as such
ports may not be blocked by a firewall.
11.5 Network Address Translators
Peer-to-peer session establishment through a NAT or firewall may
require tunneling assistance from a relay device on the public
Internet. If only a small number of relay devices are available,
they are a potential single-point of failure, and may be subject to
denial of service attacks. Relay devices pose a particular threat in
that compromise of a peer's relay may allow packet insertion or
modification. As such, message exchanges SHOULD authenticate the
peer's credentials, rather than relying entirely on channel security.
11.6 Registration
When a SIP entity places a location record in the P2P overlay network
to register a URI, the information in the record controls the address
at which it can be contacted. Modifications to such information need
to be authenticated, in order to ensure communications sessions are
not redirected, or subject to man-in-the-middle attacks. This
requires that SIP entities generating location recorrds SHOULD sign
their own location record updates, and that updates with different
credentials do not overwrite each other.
Additionally, these signed update messages need to provide a
freshness information, in the form of a monotonically increasing
number (which may be the origin peer's clock), to ensure that any
update operations do not replace newer registrations.
Registration of a device's address may also indicate its location in
the physical world. Where this is an important consideration,
adoption of a derived transport address from a TURN server may allow
Shim, et al. Expires August 30, 2006 [Page 24]
Internet-Draft P2P SIP Use Cases February 2006
a level of indirection and privacy [10].
11.7 Session Endpoint Discovery and Security
Where no central servers are required to identify endpoints,
centralized mechanisms for identifying valid SIP transport and
security are no longer applicable [9]. Instead, peers SHOULD use the
credential information associated with the other peer to verify the
address, port, and preference information for particular SIP URIs
advertised in the DHT.
The content or origin of get() commands may divulge information about
the location or identity of the requester. In order to maintain
privacy, a SN may remove identifying information when making a
request on another's behalf. Rate limitation of the requests from a
source may be performed in order to limit abuse and overload of the
P2P network.
11.8 Ill Behavior of Ordinary Nodes
Ordinary nodes do not have direct access to the DHT, but they are
able to read and place data into it. As such, they gain many of the
advantages of being on the overlay, without contributing to its
maintenance. As maintaining the DHT requires some bandwidth,
computing and storage resources, some ONs may wish to not become SNs,
even if this would benefit the overlay network's operation. While
nodes are to be encouraged to transform into SNs, it is in practice
hard to enforce them to take on the SN role.
Any node may place useless or distracting information on the overlay,
through generation of update() and add() commands. Unless user
credentials are used as the basis of checks to update or add new
information, it may be possible to remove other users' legitimate
data, which may have further security consequences. If two devices
purport to add information pertaining to the same record, both need
to be retained, distinguished by their credentials, as the SN
performing DHT operations will typically be unable to identify which
is correct.
As mentioned before, updates of the hash table are likely to be more
computationally onerous for SNs, as authenticity checks may be
required in order to modify records. As such, it may be possible to
deny service on a portion of the hash table by continually sending
the SN update() and add() operations.
In some DHT systems, knowledge of routing mechanisms may be used to
generate get() queries which increase the processing delays across
the entire overlay network, or focus additional traffic at a
Shim, et al. Expires August 30, 2006 [Page 25]
Internet-Draft P2P SIP Use Cases February 2006
particular SN with constrained resources.
11.9 Ill Behavior of Super Nodes
A super node is a device with direct ability to change the topology
of the overlay network. It is able to receive read-only and
modifying operations on the network, and may be able to insert,
modify, drop, or selectively transmit the messages it receives. It
is responsible for maintaining the data sent to it, and passing a
portion of the hash table to its peers upon joining or leaving the
network. As such, the SN has a great amount of influence and power
within a P2P network, and compromise of an SN (or a collection of
SNs) seriously jeopardizes the operation of the network.
Therefore, it is very important to use strong authentication and
authorization to ensure that participant SNs are valid candidates to
join the DHT. Additionally, it is important to maintain additional
backups for data that may be under control of an SN that goes bad.
Use of origin authentication, integrity and freshness checks may at
least ensure that items stored in the DHT are unmodified upon
storage.
12. Acknowledgements
The authors would like to thank Salman Basset and Henning Schulzrinne
for the discussion with them on P2P SIP architecture issues and their
comments. Their work provided the authors with valuable information
on a large scale P2P Internet telephony system.
13. References
13.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] 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.
[3] Gutterman, E., Perkins, C., Veizades, J., and M. Day, "SLP:
Service Location Protocol, Ver 2", RFC 2608, June 1999.
[4] Gutterman, E., "Service Location Protocol Modifications for
IPv6", RFC 3111, May 2001.
[5] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN -
Simple Traversal of User Datagram Protocol (UDP)Through Network
Shim, et al. Expires August 30, 2006 [Page 26]
Internet-Draft P2P SIP Use Cases February 2006
Address Translators (NATs)", RFC 3489, March 2003.
[6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[7] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
December 2005.
[8] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[9] Rosenberg, J. and H. Schulzrinne, "IP Encapsulating Security
Payload (ESP)", RFC 3263, June 2002.
13.2 Informative References
[10] Rosenberg, J., Mahy, R., and C. Huitema, "Traversal Using Relay
NAT (TURN)", draft-rosenberg-midcom-turn-07.txt (work in
progress), February 2005.
[11] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols", draft-ietf-mmusic-05.txt (work in
progress), July 2005.
[12] "Federal Information Processing Standards Publication 180-1
Secure Hash Standard",
http://www.itl.nist.gov/fipspubs/fip180-1.htm, April 1995.
[13] Baset, S., Schulzrinne, H., Shim, E., and K. Dhara,
"Requirements for SIP-based Peer-to-Peer Internet Telephony",
draft-baset-sipping-p2preq-00 (work in progress), October 2005.
Authors' Addresses
Eunsoo Shim
Panasonic Digital Networking Laboratory
Two Research Way, 3rd Floor
Princeton, NJ 08540
USA
Email: eunsoo@research.panasonic.com
Shim, et al. Expires August 30, 2006 [Page 27]
Internet-Draft P2P SIP Use Cases February 2006
Sathya Narayanan
Panasonic Digital Networking Laboratory
Two Research Way, 3rd Floor
Princeton, NJ 08540
USA
Email: sathya@research.panasonic.com
Greg Daley
Panasonic Digital Networking Laboratory
Two Research Way, 3rd Floor
Princeton, NJ 08540
USA
Email: gregd@research.panasonic.com
Shim, et al. Expires August 30, 2006 [Page 28]
Internet-Draft P2P SIP Use Cases February 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Shim, et al. Expires August 30, 2006 [Page 29]