|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
## P2PSIPwg
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
Last Update: May 12, 2008
-- Color Legend: RFC Editor Queue
/ Processed by IESG
/ ID Exists
/ Recently Expired
-- Each I-D name is a link to an I-D description, which points to a text version, a two-page and fit-in-window PDF version, as well as the IETF Tools' HTML version.
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
## P2PSIPwg
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
## P2PSIPwg
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
| The charter of the P2PSIP working group
is reported below.
|
|
|
|
The Peer-to-Peer (P2P) Session Initiation Protocol working group
(P2PSIP WG) is chartered to develop protocols and mechanisms for the
use of the Session Initiation Protocol (SIP) in settings where the
service of establishing and managing sessions is principally handled
by a collection of intelligent endpoints, rather than centralized
servers as in SIP as currently deployed. A number of cases where such
an architecture is desirable have been documented.
The work focuses on collections of nodes called "P2PSIP peers" and
"P2PSIP clients". P2PSIP peers manifest a distributed namespace in
which overlay users are identified and provides mechanisms for
locating users or resources within the P2PSIP overlay. P2PSIP clients
differ from P2PSIP peers primarily in that they do not store
information in the overlay, but only use it to locate users and
resources. P2PSIP clients and peers use the resolution services of the
peers as an alternative to the SIP discovery process of
RFC 3263. In
this way, P2PSIP offers an alternative mechanism for determining the
correct destination for SIP requests. The working group's initial
charter scope will be to produce protocols to enable this alternate
mechanism for RFC 3263
functionality. Session management, messaging,
and presence functions are performed using conventional SIP.
This group's primary tasks are to produce:
|
|
| 1. |
An overview document explaining concepts, terminology, rationale,
and illustrative use cases for the remaining work.
|
| 2. |
A proposed standard defining a P2PSIP Peer Protocol. This protocol
is used between P2PSIP overlay peers, some of which may be behind
NATs. This protocol will define how the P2PSIP peers collectively
provide for user and resource location in a SIP environment with no or
minimal centralized servers. This protocol may or may not be
syntactically based on SIP, a decision to be made by the WG. The group
will identify and require one base P2P algorithm (likely a particular
Distributed Hash Table (DHT) algorithm), while allowing for additional
optional algorithms in the future.
|
| 3. |
Optionally, a proposed standard defining a P2PSIP Client Protocol
for use by P2PSIP clients, some of which may be behind NATs. This
protocol will define how the P2PSIP clients query and/or modify, the
resource location information of the overlay. While clearly a logical
subset of the P2PSIP Protocol, the WG will determine if the P2PSIP
Client Protocol is a syntactic subset of the P2PSIP Peer Protocol, and
whether the P2PSIP Client Protocol builds on the SIP protocol.
|
| 4. |
A usage document. This document will address how the protocols
defined above, along with existing IETF protocols, can be used to
produce systems to locate a P2PSIP peer or client, identify appropriate
resources to facilitate communications (for example media relays), and
establish communications between the users of these P2PSIP peers or
clients, without relying on centralized servers. Additionally, the
document will explain how P2PSIP and conventional SIP entities can
interoperate.
|
|
The initial work will assume the existence of some enrollment process
that provides a unique user name, credentials, and an initial set of
bootstrap nodes if that is required by the protocols. Developing a
non-centralized enrollment process is not in scope.
The work planned for the P2PSIP working group is distinct from, but
requires close participation with other IETF WGs, particularly SIP,
SIPPING, SIMPLE, BEHAVE and MMUSIC. The group cannot modify the
baseline SIP behavior, define a new version of SIP, or attempt to
produce a parallel protocol for session establishment. If the group
determines that any capabilities requiring an extension to SIP are
needed, the group will seek to define such extensions within the SIP
working group using the SIP change process
(RFC 3427). Similarly,
existing tools developed in the BEHAVE and MMUSIC groups will be used
for NAT traversal, with extensions or changes desired to support P2PSIP
presented to the BEHAVE or MMUSIC working groups.
The working group will assume that NATs and firewalls exist in the
Internet, and will ensure that the protocols produced work in their
presence as much as possible. Similarly, the WG will avoid making
protocol design decisions that would preclude the creation of anonymous
communications systems using techniques such as onion routing to
conceal the IP addresses of P2PSIP peers.
P2P networks pose unique security and privacy problems because an
adversarial relationship may exist between nodes. Attackers can mount
both integrity attacks on the stored data and denial of service
attacks on the system as a whole. The WG will not attempt a solution
to these issues for P2P networks in general. In order to simplify this
problem, the WG will assume that all participants in the system are
issued unique identities and credentials through some mechanism not in
the scope of this working group, such as a centralized server, and
that the data stored in the network will be authenticated by the
storing entity in order to address the integrity issue and to some
extent alleviate the DoS issue. Because signaling dialogs may be
routed through intermediate P2PSIP peers which may be untrusted by the
originating SIP UA, the WG will address the issue of establishing
authenticated signaling dialogs through such untrusted relays.
P2P systems also have privacy issues because the nodes that store data
objects and route requests are unrelated to the clients which want to
communicate. In the design of the P2PSIP protocol, the WG will assess
these privacy issues and determine to what extent they need to be
alleviated. The protocol document will contain a complete description
of the privacy properties of P2PSIP.
The following topics are excluded from the Working Group's scope:
|
|
| 1. |
Issues specific to applications other than locating users and
resources for SIP-based communications and presence.
|
| 2. |
Solving "research" type questions related to P2PSIP or P2P in
general. The WG will instead forward such work to the IRTF P2PRG or
other RG as appropriate. Examples include fully distributed schemes for
assuring unique user identities and the development of P2P-based
replacements for DNS.
|
| 3. |
Locating resources based on something other than URIs. In other
words, arbitrary search of attributes is out of scope, but locating
resources based on their URIs is in scope. Using URIs need not imply
using the DNS or having a record in the DNS for the URI.
|
| 4. |
Multicast and dynamic DNS based approaches as the core lookup
mechanism for locating users and resources. Approaches based on these
technologies may be reasonable ways to solve similar problems but that
is not the focus of this WG. These techniques may be in-scope for
locating bootstrap peers/servers or for interoperation with
conventional SIP.
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
## P2PSIPwg
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
| -
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
## P2PSIPwg
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
| -
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
## P2PSIPwg
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
p2psip-concepts-01
ID Exists
Nov 15, 2007
(30 p.)
[pdf(2)]
[html]
|
D. Bryan
P. Matthews
E. Shim
D. Willis |
|
Concepts and Terminology for Peer to Peer SIP |
|
This document defines concepts and terminology for use of the Session
Initiation Protocol in a peer-to-peer environment where the
traditional proxy-registrar and message routing functions are
replaced by a distributed mechanism that might be implemented using a
distributed hash table or other distributed data mechanism with
similar external properties. This document includes a high-level
view of the functional relationships between the network elements
defined herein, a conceptual model of operations, and an outline of
the related open problems being addressed by the P2PSIP working
group. As this document matures, it is expected to define the
general framework for P2PSIP.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
## P2PSIPwg
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
baset-p2psip-
p2pp-01
ID Exists
Nov 19, 2007
(95 p.)
[pdf(2)]
[html]
|
S. Baset
H. Schulzrinne
M. Matuszewski |
|
Peer-to-Peer Protocol (P2PP) |
|
This document defines the Peer-to-Peer Protocol (P2PP), an
application-layer binary protocol, for creating and maintaining an
overlay of participant nodes. The overlay can be created using
various structured and unstructured peer-to-peer protocols such as
Bamboo, Chord, Pastry, Kademlia, Gnutella, and Gia. P2PP uses a
secure transport, supports an application API, has mechanisms for NAT
and firewall traversal, exchanging node capabilities, and diagnostic
information. P2PP is designed to support a P2P Session Initiation
Protocol (SIP) network, but it can be used for other applications as
well.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
baumgart-p2psip-
p2pns-00
ID Exists
Nov 9, 2007
(20 p.)
[pdf(2)]
[html]
|
I. Baumgart |
|
Peer-to-Peer Name Service (P2PNS) |
|
This document describes P2PNS, a secure distributed name service for
P2PSIP. P2PNS can be used to resolve SIP AoRs to Contact URIs
without using DNS or central SIP servers. P2PNS provides several
security mechanisms to efficiently prevent identity theft and to
ensure the uniqueness of SIP AoRs in a completely decentralized and
untrusted network without login servers. The proposed proxy
architecture allows a seamless integration of legacy SIP UAs, avoids
modifications to the complex SIP protocol stack and facilitates the
deployment of P2PSIP networks. Because P2PNS provides a generic name
service it is not limited to P2PSIP but can also be used e.g. to
build a distributed DNS system.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
bryan-p2psip-
reload-03
ID Exists
Feb 24, 2008
(115 p.)
[pdf(2)]
[html]
|
C. Jennings
B. Lowekamp
E. Rescorla
J. Rosenberg
S. Baset
H. Schulzrinne |
|
REsource LOcation And Discovery (RELOAD) |
|
This document defines REsource LOcation And Discovery (RELOAD), a
peer-to-peer (P2P) binary signaling protocol for use on the Internet.
A P2P signaling protocol provides its clients with an abstract hash
table service between a set of cooperating peers that form the
overlay network. RELOAD is designed to support a P2P Session
Initiation Protocol (P2PSIP) network, but can be utilized by other
applications with similar requirements by defining new usages that
specify the data kinds that must be stored for a particular
application. RELOAD defines a security model based on a certificate
enrollment service that provides unique identities. NAT traversal is
a fundamental service of the protocol. RELOAD also allows access
from "client" nodes which do not need to route traffic or store data
for others.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
cirani-p2psip-
dsip-dhtkademlia-00
ID Exists
(Recently Expired)
Oct 25, 2007
(31 p.)
[pdf(2)]
[html]
|
S. Cirani
L. Veltri |
|
A Kademlia-based DHT for Resource Lookup in P2PSIP |
|
This draft describes a Kademlia-based protocol for Resource Lookup in
P2PSIP. The proposed protocol is based on dSIP, a SIP-based protocol
proposed by other authors as generic framework for a distributed SIP
Location Service. Although the dSIP authors have obsoleted the draft
by a newer approach based on a binary protocol named RELOAD, we are
still considering this SIP-based approach, due to implementation
simplicity, possibility of reuse of already available SIP stack
implementations, easy integration into existing UAs, minimization of
the number of required protocols for a P2P UA, and widespread support
for (and relative maturity of) the SIP standard.
|
|
|
|
|
|
|
|
|
|
|
| | |
garcia-p2psip-
dns-sd-
bootstrapping-00
ID Exists
(Recently Expired)
Oct 22, 2007
(11 p.)
[pdf(2)]
[html]
|
G. Garcia |
|
P2PSIP bootstrapping using DNS-SD |
|
This document describes a DNS-based bootstrap mechanism to discover
the initial peer or peers needed to join a P2PSIP Overlay. The
document specifies the use of DNS Service Discovery (DNS-SD) and the
format of the required resource records to support the discovery of
P2PSIP peers. This mechanism can be applied in scenarios with DNS
servers or combined with multicast DNS to fulfill different proposed
P2PSIP use cases.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
hautakorpi-p2psip-
with-hip-01
ID Exists
Nov 19, 2007
(20 p.)
[pdf(2)]
[html]
|
J. Hautakorpi
G. Camarillo
J. Koskela |
|
Utilizing HIP (Host Identity Protocol) for P2PSIP |
|
This document specifies how Host Identity Protocol (HIP) can be
utilized in Peer-to-Peer Session Initiation Protocol (P2PSIP)
networks. Peers in a P2PSIP network need to have long-lived
connections to other peers in the network, and HIP can be utilized to
setup and maintain those connections. HIP is a good choice for
connection maintenance, because it provides functionalities like
Network Address Translation (NAT) traversal, mobility, multi-homing,
and enhanced security properties.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
jiang-p2psip-
sep-01
ID Exists
Feb 01, 2008
(46 p.)
[pdf(2)]
[html]
|
X. Jiang
H. Zheng
C. Macian
V. Pascual |
|
Service Extensible P2P Peer Protocol |
|
This document describes the Service Extensible Protocol (SEP), which
is the peer protocol spoken between P2PSIP Overlay peers to share
information and organize the P2PSIP Overlay Network. SEP uses a
flexible forwarding mechanism to avoid congestion in the Overlay. It
also proposes a general service discovery method and a built-in NAT
traversal mechanism. By using these methods, SEP tries to improve
the success rate and reduce the latency of the transaction.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
li-p2psip-
client-protocol-00
ID Exists
Nov 12, 2007
(24 p.)
[pdf(2)]
[html]
|
L. Li
Ch. Zhang
Y. Wang
Y. Ji |
|
A SIP-based P2PSIP Client Protocol |
|
This document presents the motivation, design guidelines and high
level descriptions of peer-to-peer session initiation protocol
(P2PSIP) client protocol, which is spoken between P2PSIP peers and
P2PSIP clients. In this document, the necessity of P2PSIP Client is
identified firstly. Then, two fundamental guidelines for our design
are explained in details. Following these guidelines, the design of
proposed protocol and new extensions to existing SIP (session
initiation protocol) are described. Such a SIP-based protocol not
only makes itself backward-compatible with the vast existing SIP
devices, but also provides extra functions to satisfy some particular
requirements raised by P2PSIP.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
li-p2psip-
node-types-00
ID Exists
Nov 22, 2007
(12 p.)
[pdf(2)]
[html]
|
L Ch. Li
Y. Wang |
|
Different types of nodes in P2PSIP |
|
This document is an attempt to classify different types of node in
peer-to-peer Session Initiation Protocol (P2PSIP). Four possible
types of nodes in P2PSIP are discussed based on two characters:
whether it offers overlay-routing services and whether it offers
storage functions. The behaviors of each type of nodes and their
possible necessities are analyzed. This document is dedicated to be
a reference for clarifying some controversial terms in P2PSIP working
group, such as "client", "low-function peer", etc.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
marocco-p2psip-
xpp-01
ID Exists
Nov 16, 2007
(27 p.)
[pdf(2)]
[html]
|
E. Marocco
E. Ivov |
|
Extensible Peer Protocol (XPP) |
|
This document defines the Extensible Peer Protocol (XPP), a
lightweight binary protocol for end-to-end sessions between peers in
distributed overlay networks. One of the main goals while creating
this protocol was support for nodes located behind firewalls and
NATs. XPP therefore uses UDP and allows endpoints to simultaneously
initiate sessions. Given the choice of the underlying protocol
(UDP), XPP also defines mechanisms for message fragmentation and
reliability.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
marocco-p2psip-
xpp-pcan-01
ID Exists
Nov 16, 2007
(47 p.)
[pdf(2)]
[html]
|
E. Marocco
E. Ivov |
|
XPP Extensions for Implementing a Passive P2PSIP Overlay Network based on the CAN Distributed Hash Table |
|
This document defines a set of extensions for the Extensible Peer
Protocol (XPP) required for creating a P2PSIP overlay network based
on the CAN distributed hash table algorithm. It specifies how peers
and clients must behave in order to maintain the overlay and use it
for the establishment of multimedia communication sessions.
To limit the overhead due to maintenance operations and to allow the
adoption of security policies for preventing malicious nodes to
damage the overlay, joins are always initiated and controlled by
existing peers (hence the passive in PCAN).
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
matthews-p2psip-
id-loc-01
ID Exists
Feb 25, 2008
(15 p.)
[pdf(2)]
[html]
|
E. Cooper
A. Johnston
P. Matthews |
|
An ID/Locator Architecture for P2PSIP |
|
This document describes an architecture where peers in an peer-to-peer
overlay use special IP addresses to identify other peers. Two
of the advantages of this approach are that (a) most existing
applications can run in an overlay without needing any changes and
(b) peer mobility and NAT traversal are handled in a way that is
transparent to most applications.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
pascual-p2psip-
clients-01
ID Exists
Feb 24, 2008
(13 p.)
[pdf(2)]
[html]
|
V. Pascual
M. Matuszewski
E. Shim
H. Zheng
Y. Song |
|
P2PSIP Clients |
|
This document describes why and when some devices would better be a
Client rather than a Peer. The purpose of this document is to
facilitate the discussion and understanding about the Client node
type.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
song-p2psip-
security-eval-00
ID Exists
Feb 3, 2008
(17 p.)
[pdf(2)]
[html]
|
Y. Song
B. Y. Zhao
X. Jiang
H.. Jiang |
|
P2PSIP Security Analysis and Evaluation |
|
This document provides an analysis and evaluation of security with
P2PSIP overlay network. The draft compares security difference
between C/S and P2P, then partitions the P2PSIP architecture into
layers, and analyze the security issues in each layer and the
security relationship among the layers. Security issues with
different kind of application scenarios are distinct. This draft
classifies the application scenarios into two main types, and the
security threats with these two types of scenarios are analyzed in
detail.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
stiemerling-p2psip-
impl-02
ID Exists
Nov 19, 2007
(12 p.)
[pdf(2)]
[html]
|
M. Stiemerling
M. Brunner |
|
Peer-to-Peer SIP Implementation Report |
|
This memo is an implementation report about the peer-to-peer SIP
system developed in the European IST Ambient Networks research
project. This system replaces the traditional SIP proxy-registrar
function with a distributed lookup mechanism, adds overlay
functionality to the SIP signalling and to RTP traffic, takes care
about media/packet relay lookup and insertion into the SIP/RTP paths,
plus automatic adaptation of the voice transmission according to
changing network conditions. Standard, unmodified SIP user agents
are used for communication. The presented system is work in progress
and this memo is an attempt to gather IETF community feedback about
the described approach.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
zheng-p2psip-
diagnose-01
ID Exists
Feb 23, 2008
(21 p.)
[pdf(2)]
[html]
|
Y. Song
H. Zheng
X. Jiang |
|
Diagnose P2PSIP Overlay Network Failures |
|
This document describes a simple and efficient mechanism that can be
used to detect and localize failures in P2PSIP overlay network. This
document mainly consists of two parts: information carried in a
P2PSIP Peer "Echo request" message and "Echo response" message for
the purpose of fault detection and localization, and mechanisms for
processing those messages.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
