P2PSIP Working Group E. Cooper
Internet-Draft A. Johnston
Intended status: Standards Track P. Matthews
Expires: August 28, 2007 Avaya
February 24, 2007
Bootstrap Mechanisms for P2PSIP
draft-matthews-p2psip-bootstrap-mechanisms-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 28, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes mechanisms that a peer can use to locate and
establish a Peer Protocol connection to an admitting peer in order to
join an overlay network. In the first mechanism, the joining peer
uses multicast to locate a bootstrap peer; in the second, the node
uses one or more bootstrap servers to locate a bootstrap peer; in
both cases, the bootstrap peer then proxies the request by the
joining peer on to the admitting peer. Each mechanism has its
Cooper, et al. Expires August 28, 2007 [Page 1]
Internet-Draft Bootstrap Mechanisms February 2007
advantages and disadvantages, and a node can utilize both.
Requirements Language
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 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of the Mechanisms . . . . . . . . . . . . . . . . . . 5
2.1. Multicast Mechanism . . . . . . . . . . . . . . . . . . . 5
2.2. Bootstrap Server Mechanism . . . . . . . . . . . . . . . . 6
2.3. Common Procedures . . . . . . . . . . . . . . . . . . . . 6
2.4. Multicast Example . . . . . . . . . . . . . . . . . . . . 7
2.5. Bootstrap Server Example . . . . . . . . . . . . . . . . . 8
2.6. Pros and Cons of the Two Mechanisms . . . . . . . . . . . 10
3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Peer Protocol and Signaling Protocol . . . . . . . . . . . 11
3.2. URI Format . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3. Reducing the Load on Proxies . . . . . . . . . . . . . . . 13
4. Detailed Description of the Multicast Mechanism . . . . . . . 13
4.1. The Mechanism . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Discussion (Informative) . . . . . . . . . . . . . . . . . 14
5. Detailed Description of Bootstrap Server Mechanism . . . . . . 15
5.1. The Bootstrap Server . . . . . . . . . . . . . . . . . . . 15
5.2. Registering with the Bootstrap Server . . . . . . . . . . 15
5.3. Forming the Initial INVITE . . . . . . . . . . . . . . . . 16
5.4. Sending the INVITE . . . . . . . . . . . . . . . . . . . . 16
5.5. Handling the INVITE at the Bootstrap Server . . . . . . . 17
6. Detailed Description of Common Procedures . . . . . . . . . . 18
6.1. Handling the INVITE at the Bootstrap Peer . . . . . . . . 18
6.2. Handing the INVITE at the Admitting Peer . . . . . . . . . 18
6.3. Sending the ACK . . . . . . . . . . . . . . . . . . . . . 19
6.4. Forming the Initial Offer and Answer . . . . . . . . . . . 19
6.5. Sending a new INVITE with Replaces . . . . . . . . . . . . 19
6.6. Replying to the new INVITE . . . . . . . . . . . . . . . . 21
6.7. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7.1. Credentials . . . . . . . . . . . . . . . . . . . . . . . 22
Cooper, et al. Expires August 28, 2007 [Page 2]
Internet-Draft Bootstrap Mechanisms February 2007
7.2. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 26
Cooper, et al. Expires August 28, 2007 [Page 3]
Internet-Draft Bootstrap Mechanisms February 2007
1. Introduction
A peer wishing to join an existing P2PSIP overlay needs to somehow
locate and contact one or more peers in the overlay and then exchange
messages with these peers to add itself to the overlay. In addition,
the joining peer may be asked to prove that it is authorized to join
the overlay, and may wish to confirm for itself that the other nodes
really are the overlay they say they are.
As described in the P2PSIP Concepts and Terminology document
[I-D.willis-p2psip-concepts], a peer that serves as the initial point
of contact into the overlay is known as a bootstrap peer. With the
help of the bootstrap peer, the joining peer can locate and contact
the other peers in the network. However, in many cases it is more
efficient for the bootstrap peer to immediately forward the request
from the joining peer on to another peer which is better able to help
the joining peer join the overlay. This second peer, called the
admitting peer, might be, for example, a neighbor of the joining peer
in the overlay. In those cases where the referral is not done, the
first peer simply plays both roles: bootstrap peer and admitting
peer.
The protocol used by peers to construct and maintain an overlay is
known as the Peer Protocol. Work on this protocol is just beginning,
and many details are not yet known, but one thing that is established
is that the protocol must work through NATs to the greatest extent
possible. In order to do this, the peer protocol needs the concept
of a "control connection" between two peers over which the peer
protocol can run. This is the transport connection (e.g. TCP, UDP,
or some other transport) over which the peer protocol runs. The
peers at each end of the control connection need to establish this
connection and then take steps to maintain it in the presence of NATs
(e.g., by sending keep-alives).
Thus the goal of a bootstrap mechanism is to establish a control
connection between the joining peer and the admitting peer. Once
this connection is established, the joining peer can communicate with
the admitting peer using the peer protocol and do whatever is
required to become a fully functional member of the overlay.
Since the nature of the Peer protocol is still under debate, this
document is careful to make as few assumptions as possible about the
nature of the Peer Protocol. In particular, this document takes NO
POSITION on the question of whether the Peer Protocol is SIP-based.
However, this document does assume that SIP is the protocol used to
Cooper, et al. Expires August 28, 2007 [Page 4]
Internet-Draft Bootstrap Mechanisms February 2007
establish the connections over which the Peer Protocol runs. There
are a number of reasons for making this assumption:
o As argued in [I-D.matthews-p2psip-nats-and-overlays], the joining
peer and the admitting peer may both be behind (different) NATs.
In this case, TCP or UDP by itself is not sufficient, and an out-
of-band signaling protocol is required. SIP is one such out-of-
band signaling protocol;
o SIP is well-suited for setting up, modifying, and tearing down
connections;
o SIP has a number of security mechanisms, which can be used to
provide appropriate security for each bootstrap mechanism;
o There has been a lot of work recently to define SIP mechanisms for
setting up and maintaining connections through NATs; and
o It is likely that many peers in a P2PSIP network will need to
support SIP for other reasons (e.g., establishing multimedia
sessions).
The use of indirect SIP signaling to establish direct Peer Protocol
connections is analogous to the use of indirect SIP signaling to
create direct RTP streams.
2. Overview of the Mechanisms
The current version of this document describes two bootstrap
mechanisms: the Multicast mechanism and the Bootstrap Peer mechanism.
These two mechanisms are not rivals. On the contrary, an eminently
sensible approach is for a joining peer to first try the multicast
mechanism, and try the bootstrap server mechanism if the multicast
mechanism fails.
Two other bootstrap mechanisms are mentioned briefly in
[I-D.willis-p2psip-concepts]. These will be discussed in future
versions of this document. This section is non-normative.
2.1. Multicast Mechanism
The Multicast mechanism is intended to allow the joining peer locate
a bootstrap peer on the same subnet. It will also work between
subnets if the two subnets are joined in the same multicast domain -
typically, these will be adjacent subnets operated by the same
organization.
Cooper, et al. Expires August 28, 2007 [Page 5]
Internet-Draft Bootstrap Mechanisms February 2007
In the Multicast mechanism, the joining peer begins by multicasting
an SIP OPTIONS message addressed to the pseudo-user "bootstrap" and
specifying the name of the overlay the peer wishes to join (see the
section on URIs below). Peers willing to be a bootstrap peer reply
and list their unicast address in the reply. The joining peer then
selects one of these bootstrap peers, and unicasts an INVITE message
to it. The bootstrap peer, in turn, selects a peer to act as the
admitting peer and proxies the INVITE to that peer.
2.2. Bootstrap Server Mechanism
A P2PSIP Bootstrap Server is a SIP registrar and proxy, typically
located in the public Internet, that acts as an intermediary to
introduce the joining peer to a bootstrap peer. The Bootstrap Server
is not a part of the overlay, but is simply a well-known node that
acts as an "introduction service". Peers must know the URL of one or
more bootstrap servers: this might happen through configuration, for
example.
This mechanism begins with one or more bootstrap peers registering
with the bootstrap server. Each peer registers, using the standard
SIP registration mechanism, as the pseudo-user "bootstrap" and
specifies the name of the overlay with which it is associated (see
the section on URIs below).
Later on, a peer that wishes to join the overlay sends an INVITE
message to a bootstrap server address to "bootstrap" and specifying
the name of the overlay it wishes to join. If the bootstrap server
knows of one or more bootstrap peers in that overlay, it selects one
and proxies the INVITE onward to a bootstrap peer. The selected
bootstrap peer, in turn, selects a peer to act as the admitting peer
and proxies the INVITE to that peer.
2.3. Common Procedures
Both bootstrap mechanisms use ICE for help with setting up a control
connection through any NATs that may lie between the joining peer and
the admitting peer. Following the procedures of ICE, the joining
peer and the admitting peer include ICE candidates in their SDP offer
and answer, and then try all the various candidate pair combinations
to see which combinations work. The best working combination is then
selected as the path for the control connection.
At this point, the new control connection has been established, but
the SIP dialog for the connection still goes through the intermediate
proxies (the bootstrap server and/or bootstrap peer). If one of
these intermediaries was to crash or otherwise leave, then the
signaling channel would be broken, and it is common behavior for SIP
Cooper, et al. Expires August 28, 2007 [Page 6]
Internet-Draft Bootstrap Mechanisms February 2007
entities to tear down the bearer channel if they detect that the
signaling channel is broken. To handle this case, one endpoint
(usually the joining peer) sends an INVITE with a Replaces header
down the new connection. This causes the old dialog to be torn down
and replaced with a new dialog that runs along the control connection
itself.
2.4. Multicast Example
In this multicast mechanism example, a Peer A ("the joining peer")
wants to join a particular overlay. Peer A multicasts out an OPTIONS
message. Peers B and C, which happen to be on the same subnet as A,
are already members of the overlay in question, and thus respond to
the OPTIONS request. By chance, peer C responds first, and is
therefore selected as the bootstrap peer for the rest of the
exchange. Peer A then unicasts an INVITE to peer C. Based on peer
A's peer-id, peer C decides that peer D, rather than itself, is the
best peer to help peer A join the overlay. Thus peer C forwards the
INVITE to peer D ("the admitting peer") through the existing
connections in the overlay.
Peers A and D complete the INVITE transaction, and then execute the
ICE connectivity checks (in reality, these two steps would be done in
parallel). Once a working path for the new Peer Protocol connection
is selected, peer A sends an INVITE w/ a Replaces header on the
working path. This establishes a new dialog between peers A and D,
and causes peer D to send a BYE for the old dialog.
The following figure illustrates the call flow for this example. In
this figure, we use two diagramming conventions from : the labeling
of dialogs on the left-hand-side, and the collapsing of a multi-
message transaction into a single line.
Cooper, et al. Expires August 28, 2007 [Page 7]
Internet-Draft Bootstrap Mechanisms February 2007
Peer A Peer B Peer C Peer D
(Joining) (Bootstrap) (Admitting)
| | | |
| OPTIONS (multicast)| | |
|------------------->|----------------->| |
| | 200 OK | |
|<--------------------------------------| |
| 200 OK | | |
|<-------------------| | |
| INVITE | | |
dialog1|-------------------------------------->| |
| | | INVITE |
dialog1| | |----------------->|
| | | 200 OK |
dialog1| |<-----------------|
| | 200 OK | |
dialog1|<--------------------------------------| |
| ACK | | |
dialog1|-------------------------------------->| |
| | | ACK |
| | |----------------->|
| ICE Connectivity Checks |
|<-------------------------------------------------------->|
| Peer Protocol connection from A to D established |
|==========================================================|
| | | |
| INVITE (Replaces) | | |
dialog2|--------------------------------------------------------->|
| | | 200 OK |
dialog2|<---------------------------------------------------------|
| ACK | | |
dialog2|--------------------------------------------------------->|
| | BYE/200 OK | BYE/200 OK |
dialog1|<--------------------------------------|<-----------------|
| | | |
Figure 1: Message Flow for Multicast Example
2.5. Bootstrap Server Example
In this example, server X (a SIP proxy and registrar) acts as a
Bootstrap Server for a variety of different overlays, including
overlay "O". A URL for server X is known, through configuration, to
a number of nodes, including those interested in forming overlay "O".
At the start of this example, peer C, which is already a member of
overlay "O", registers with server X as a bootstrap peer for the
Cooper, et al. Expires August 28, 2007 [Page 8]
Internet-Draft Bootstrap Mechanisms February 2007
overlay.
Then, later, peer A decides to join the overlay. Peer A sends an
INVITE to server X specifying overlay "O", and server X proxies this
INVITE onward to peer C. When peer C receives the INVITE, it decides,
based on A's peer-id (given in the INVITE), that peer D (already a
member of the overlay) is the best peer to help peer A join the
network. Thus it forwards the INVITE to peer D (through the existing
connections of the overlay).
As in the multicast example, peers A and D complete the INVITE
transaction and then select a working path using ICE. Peer A then
sends an INVITE with a Replaces header on the working path. This
establishes a new dialog between peers A and D, and causes peer D to
send a BYE for the old dialog.
Cooper, et al. Expires August 28, 2007 [Page 9]
Internet-Draft Bootstrap Mechanisms February 2007
Peer A Server X Peer C Peer D
(Joining) (Bootstrap server) (Bootstrap) (Admitting)
| | | |
| | REGISTER/200 OK | |
| |<-----------------| |
| | | |
| INVITE | | |
dialog1|------------------->| | |
| | INVITE (R-R:X) | |
dialog1| |----------------->| |
| | | INVITE |
dialog1| | |----------------->|
| | | 200 OK |
dialog1| | |<-----------------|
| | 200 OK | |
dialog1| |<-----------------| |
| 200 OK | | |
dialog1|<-------------------| | |
| ACK | | |
dialog1|------------------->| | |
| | ACK | |
| |----------------->| |
| | | ACK |
| | |----------------->|
| | | |
| ICE Connectivity Checks |
|<-------------------------------------------------------->|
| Peer Protocol connection from A to D established |
|==========================================================|
| | | |
| INVITE (Replaces) | | |
dialog2|--------------------------------------------------------->|
| | | 200 OK |
dialog2|<---------------------------------------------------------|
| ACK | | |
dialog2|--------------------------------------------------------->|
| | | |
| BYE/200 OK | BYE/200 OK | BYE/200 OK |
dialog1|<-------------------|<-----------------|<-----------------|
| | | |
Figure 2: Message Flow for Bootstrap Server Example
2.6. Pros and Cons of the Two Mechanisms
The Multicast mechanism only works in the joining peer shares a
multicast domain with a bootstrap peer in the overlay. Most often,
Cooper, et al. Expires August 28, 2007 [Page 10]
Internet-Draft Bootstrap Mechanisms February 2007
this means that the two must be on the same subnet, though there are
situations where the two can be farther apart in Internet distance.
This means that the Multicast mechanism is particularly appropriate
when a number of peers are located on the same or perhaps nearby
subnets (for example, in an office or conference situation).
By contrast, the Bootstrap Server mechanism will work regardless of
the distance between the joining peer and the bootstrap peer. This
means that it is very appropriate when the joining peer is somewhat
isolated from other peers. However, this mechanism requires the use
of a well-known, publicly reachable third party (the bootstrap
server). To make the Bootstrap Server mechanism practical, it is
highly desirable to minimize the load on the bootstrap server to the
greatest extent possible, so that a single bootstrap server can serve
many different overlays.
3. Assumptions
This section lists and motivates the various assumptions this
document makes about the nature of a solution to the bootstrap
problem.
3.1. Peer Protocol and Signaling Protocol
As described in the Introduction, this document assumes that SIP is
used to signal Peer Protocol connections, but does not assume that
the Peer Protocol is based on SIP.
However, we do assume that the Peer Protocol either provides a way to
transport SIP messages, or there is a way to multiplex SIP messages
with the Peer Protocol messages on the same connection. This allows
us to send SIP messages along control connections for the purposes of
setting up and tearing down other control connections in the overlay.
Furthermore, we assume that ICE is used as the SIP/SDP extension for
setting up connections in the presence of NATs. As presently
defined, ICE supports setting up connections where the transport
protocol is either UDP or TCP - if a different transport protocol is
chosen for the Peer Protocol, then an appropriate ICE extension will
need to be defined. Since ICE, in turn, specifies that the STUN
protocol is used for keep-alives on connections established by ICE,
this implies that STUN messages will be multiplexed with the other
traffic on control connections.
Finally, we assume that there is a way to signal a Peer Protocol
connection in the SDP in the SIP message body. The details of how
this is done is not important to this document, but we assume that
Cooper, et al. Expires August 28, 2007 [Page 11]
Internet-Draft Bootstrap Mechanisms February 2007
this is done using some sort of new media type like "application/
p2psip-peer".
Our goal with the current version of this document is to specify
mechanisms to establish a Peer Protocol connection between the
joining node and the admitting node using SIP extended with ICE. Our
goal is to do this using existing SIP mechanisms wherever possible,
and avoid new extensions to SIP unless absolutely necessary.
3.2. URI Format
At present, there is no agreed-upon format for URIs related to P2PSIP
overlays. The current version of this document does not attempt to
provide one. Instead, this document merely assumes that whatever URI
format is chosen by the Working Group is sufficiently expressive to
describe the following concepts:
URI-format 1: A specific peer X in a specific overlay Y. This
document assumes that this is done by having the URI somehow
include both the peer-ID of peer X and the name of overlay Y. It
also assumes that (perhaps optionally) there is a way to indicate
an IP address associated with peer.
URI-format 2: The bootstrap service for a specific overlay Y. This
form does not specify the peer that should provide this service,
and is used when the joining peer wishes to contact any peer that
is willing to provide the bootstrap service.
URI-format 3: The bootstrap service for a specific overlay Y as
provided by a specific peer P. We assume that this format provides
a way (perhaps optionally) to indicate an IP address associated
with the peer. This format is used when a format-2 URI has been
proxied or redirected to a specific peer that will provide the
service.
A format 2 or format 3 URI expresses the fact that the goal of the
SIP request is to setup a connection for the purpose of admitting a
new peer into the overlay. Thus a peer receiving an INVITE with such
a URI knows that it should proxy the INVITE onward if it believes it
is not the most appropriate peer to handle the request - in this way,
the bootstrap peer proxies the INVITE onward to the admitting peer.
By contrast, a format 1 URI expresses the fact that the SIP request
is for the specific peer listed in the URI.
Future versions of this document may specify a particular URI scheme.
Cooper, et al. Expires August 28, 2007 [Page 12]
Internet-Draft Bootstrap Mechanisms February 2007
3.3. Reducing the Load on Proxies
The bootstrap server (if present) and the bootstrap peer act as
proxies in the signaling path between the joining peer and the
admitting peer. This document assumes that we want to remove these
proxies from the signaling path as soon as practical, leaving the
signaling to go directly from the joining peer to the admitting peer.
There are two motivations for this. First, leaving these proxies in
the signaling path is a burden on them. If they are stateful, this
consumes state. Even if they are stateless, they are still in the
path of any signaling adjustments.
Second, if the connection is long-lived, then leaving these proxies
in the signaling path would mean that the connection would be
dependent on their continuing availability. As a minimum, it would
be impossible to make any changes to the connection if the peer or
server crashed or otherwise became unavailable - many SIP UA today go
further and tear down the direct connection if they detect the
signaling path is broken.
To further reduce the load on bootstrap peers (beyond removing them
from the signaling path as soon as possible), this document assumes
that the usage of bootstrap peers should be spread as evenly as
possible. That is, if a number of different peers try to join at
approximately the same time, then with high probability they should
use different bootstrap peers to the extent possible.
4. Detailed Description of the Multicast Mechanism
This section contains the normative description of the multicast
mechanism.
4.1. The Mechanism
The procedure starts with the joining peer multicasting a SIP OPTIONS
message. The To header and Request URI use URI-format 2; that is,
the URI specifies the "bootstrap" service and the name of the
overlay, but does not specify a particular peer. The joining peer
lists its peer URI (i.e., URI-format 1) in the From and Contact
fields of the message. The message is sent on the well-known "all
SIP servers" multicast address "sip.mcast.net" (224.0.1.75 for IPv4).
Peers willing to act as bootstrap peers listen on this multicast
address. If an OPTIONS message arrives, the peer MUST verify that
the message is addressed to the "bootstrap" service and specifies the
name of the overlay that the peer is serving as bootstrap peer for;
Cooper, et al. Expires August 28, 2007 [Page 13]
Internet-Draft Bootstrap Mechanisms February 2007
if these conditions are not met, then the peer MUST silently discard
the message.
If these conditions are satisfied, then the peer SHOULD reply using a
200 OK, but MAY reply using a 302 Moved Temporarily if it wishes to
indicate other peers. In either case, the peer MUST include, in the
Contact header, a URI in format 3 specifying itself as the peer.
This URI MUST include a unicast address at which the peer can be
reached; the address included MUST be reachable from any node located
in the multicast domain. The peer SHOULD NOT include contacts for
other peers unless the peer knows, through some unspecified
mechanism, that those peers are currently members of the overlay and
are willing to act as bootstrap peers.
The joining peer will receive zero or more of these replies. As
specified in SIP [RFC3261], the second and subsequent replies to the
multicast request must be taken as retransmissions of the first reply
and will be discarded. Thus the joining peer selects a Contact URI
from the first reply and uses this as the bootstrap peer.
The joining peer then forms an INVITE message and unicasts it to the
selected bootstrap peer.
The INVITE message uses URI-format 2 in the To header, and URI-format
3 in its Request URI, where the latter specifies the selected
bootstrap peer. The URI of the joining peer (URI-format 1) is placed
in the From and Contact headers (see section 4.2).
To indicate that the bootstrap peer should proxy the INVITE onward to
an admitting peer (rather than redirecting with a 302 Moved
Temporarily), the joining peer includes a Request-Disposition header
with a "proxy" directive.
Further processing after this point follows the procedures in section
7.
4.2. Discussion (Informative)
It is important that peers that do not want to be a bootstrap peer
for the specified overlay not reply to the multicast OPTIONS message.
If they were to reply with an error message and if this was the first
reply received, then this reply would mask all subsequent replies.
For similar reasons, the authors have elected to use a OPTIONS
message for this mechanism, rather than an INVITE message. If the
mechanism used an INVITE, and if multiple peers replied with a 302,
then the joining peer would need to send ACK messages to each of
these peers - but this is contrary to the base multicast mechanism
Cooper, et al. Expires August 28, 2007 [Page 14]
Internet-Draft Bootstrap Mechanisms February 2007
specified in SIP [RFC3261] which says that subsequent replies are
ignored. The OPTIONS message avoids this problem because it does not
require an ACK.
5. Detailed Description of Bootstrap Server Mechanism
This section contains the normative description of the bootstrap
server mechanism.
5.1. The Bootstrap Server
A P2PSIP Bootstrap Server behaves as a standard SIP registrar and
proxy [RFC3261] except as described below.
The SIP registrar and proxy MUST understand the URI format used by
P2PSIP (see the section on URI formats). The SIP registrar SHOULD
support multiple registrations (i.e., contacts) for a "bootstrap"
service for a given overlay. The SIP proxy MUST obey the "redirect",
"proxy" and "no-fork" directives in the Request-Disposition header
[RFC3841].
A P2PSIP Bootstrap Server may act as either a stateful or stateless
SIP proxy. Acting as a stateless proxy may provide scalability
advantages.
A P2PSIP Overlay may use multiple independent Bootstrap Servers at
the same time, and a single Bootstrap Server may serve multiple
independent P2PSIP Overlays at the same time.
5.2. Registering with the Bootstrap Server
Using some mechanism, not specified here, the peers of a P2PSIP
Overlay select one or more peers to register with a given Bootstrap
Server. The set of peers selected to register with one Bootstrap
Server may be different than the set selected to register with a
different Bootstrap Server.
We also assume there is some mechanism, not specified here, by which
each bootstrap peer learns a URI for each P2PSIP Bootstrap Server it
needs to contact.
For each such URI, a peer uses standard SIP mechanisms [RFC3263] to
locate the proxy portion of the Bootstrap Server.
For each bootstrap server and bootstrap peer combination, the peer
registers as a bootstrap peer for the overlay. This is done with a
REGISTER message where the To and From headers contain a URI in
Cooper, et al. Expires August 28, 2007 [Page 15]
Internet-Draft Bootstrap Mechanisms February 2007
format 2, the Contact header contains a URI in format 3 (specifying
the specific bootstrap peer), and the Request URI contains the URI
used to reach the bootstrap server.
The peer SHOULD use a q value of 1 for the registration.
As part of the registration process, the peer SHOULD use the
mechanism specified in [I-D.ietf-sip-outbound] to establish and keep
a connection to the Bootstrap Server alive through any intervening
NATs. (A reason not to use this mechanism might be because the
bootstrap peer is in the same address domain as the bootstrap
server).
5.3. Forming the Initial INVITE
A peer that wishes to join an overlay begins by forming a SIP INVITE
message.
The To header of the INVITE message contains a URI in format 2 and
specifying the overlay the peer would like to join. The From and
Contact headers contain a format 1 URI specifying the joining peer.
To indicate that the bootstrap server should proxy the INVITE onward
to a bootstrap peer (rather than redirecting with a 302 Moved
Temporarily), the joining peer SHOULD include a Request-Disposition
header with a "proxy" directive. To indicate that the bootstrap
server should not fork the INVITE but rather select just one of the
bootstrap peers, the joining peer SHOULD include a "no-fork"
directive in the Request-Disposition header.
Since the joining peer may be located behind a NAT, the INVITE MUST
include the "rport" parameter defined in [RFC3581].
See section 7.4 for how the SDP body is constructed.
5.4. Sending the INVITE
We assume there is some mechanism, not specified here, by which a
peer that wishes to join an overlay learns the URIs of one or more
P2PSIP Bootstrap Servers. It is RECOMMENDED that the peer try these
bootstrap servers in some unspecified order until the peer succeeds
in locating a server that knows about the overlay.
For each bootstrap server, the joining peer adds a Route header to
the INVITE containing that bootstrap server, then uses standard SIP
mechanisms [RFC3263] to locate the proxy portion of the Bootstrap
Server, and sends the INVITE message to it.
Cooper, et al. Expires August 28, 2007 [Page 16]
Internet-Draft Bootstrap Mechanisms February 2007
5.5. Handling the INVITE at the Bootstrap Server
When the proxy portion of the P2PSIP Bootstrap Server receives the
INVITE, it handles it using normal proxy procedures as specified in
section 16 of the SIP specification [RFC3261]. As part of this
processing, it checks to see if it has one or more bootstrap peers
registered for the given overlay. If it does, it selects one of
these peers and forwards the INVITE to it (thus obeying the "proxy,
no-fork" directive in the Request-Disposition header). If there are
multiple bootstrap peers registered for the same overlay, the proxy
SHOULD select one of these peers in such a way that subsequent
INVITEs in the same dialog attempt go to the same bootstrap peer,
while subsequent INVITEs for different dialog attempts are likely to
select a different bootstrap peer.
The goal here is to spread the load across bootstrap peers. This
makes sure that no bootstrap peer gets overloaded, which means
that even less-capable peers can serve as bootstrap peers. In
addition, this allows an overlay to select only a small number of
bootstrap peers to register with the bootstrap server, thus
reducing the load on the bootstrap server.
However, in a Challenge-Response scenario, when the selected
bootstrap peer replies with a 401 containing a nonce, and the
joining peer then resends the INVITE with the appropriate
credentials, it would be nice if the bootstrap server routed this
new INVITE to the same bootstrap peer. If the bootstrap server
routed this new INVITE to a different bootstrap peer, this
bootstrap peer will reject the INVITE unless this second bootstrap
peer would have generated the same nonce for the INVITE. Though
there are nonce-sharing schemes that solve this problem, such
nonce-sharing schemes may not be appropriate in P2PSIP systems.
By ensuring that the new INVITE goes back to the same bootstrap
peer, we avoid the need for such nonce-sharing systems.
One way this selection might be done is to hash on the contents of
the From and Call-ID headers and use this hash value to select the
bootstrap peer. This approach will select the same bootstrap peer
for all transactions within the same dialog, but will usually
select a different bootstrap peer for different dialogs.
In many situations where either the joining node or the bootstrap
peer are behind NATs, the bootstrap server will need to remain in the
path of future transactions on this dialog to ensure that the
messages can traverse the intervening NATs. Thus the bootstrap
server MUST add a Record-Route header field to the INVITE, unless it
knows, through some outside mechanism, that this is not necessary.
Similarly, the bootstrap server MUST add the "rport" parameter
Cooper, et al. Expires August 28, 2007 [Page 17]
Internet-Draft Bootstrap Mechanisms February 2007
defined in [RFC3581] unless it knows, through some unspecified
mechanism, that this is not necessary.
Further processing after this point follows the procedures in section
7.
6. Detailed Description of Common Procedures
This section describes normative procedures that are common to both
mechanisms.
6.1. Handling the INVITE at the Bootstrap Peer
When the bootstrap peer received the INVITE, it selects a peer in the
overlay to act as the admitting peer.
The details of how this selection is done is outside the scope of
this document, since it depends on the nature of the Peer Protocol
and the nature of the algorithm used to select connections for the
overlay. However, one reasonable choice might be a peer that will
become the neighbor of the joining peer in the overlay.
A bootstrap peer MAY select itself as the admitting peer, in which
case the INVITE is handled as described in the next section.
If the bootstrap peer does not select itself as the admitting peer,
then the bootstrap peer forwards the INVITE to the admitting peer,
using the Peer Protocol's ability to transport SIP messages from one
peer to another as described in the P2PSIP Concepts document
[I-D.willis-p2psip-concepts]. Note that the details of how this is
done have not been agreed to yet - one possibility is that one or
more peers will act as intermediaries. It is expected that, as part
of these Peer Protocol forwarding procedures, the bootstrap peer add
a Record-Route header to force future requests in the dialog to pass
through the bootstrap peer - failure to do so would likely mean that
future requests would not make it through intervening NATs.
6.2. Handing the INVITE at the Admitting Peer
When the admitting peer receives the INVITE, it recognizes that the
INVITE is a request to set up a control connection for the bootstrap
mechanism because of the format of the Request URI (namely, a URI in
either format 2 or 3). It then processes the INVITE according to the
SIP specification [RFC3261], possibly sending preliminary responses
before the 2xx final response.
It is expected that the Peer Protocol will define rules for how
Cooper, et al. Expires August 28, 2007 [Page 18]
Internet-Draft Bootstrap Mechanisms February 2007
responses are sent and routed through the overlay. Once the response
gets back to the bootstrap peer, the rules of [RFC3261] take over for
routing the response back to the joining peer - in the case of the
bootstrap server mechanism, this means that the response is routed
back through the bootstrap server.
6.3. Sending the ACK
On receipt of the 2xx, the joining peer sends an ACK in response.
Because of the Record-Route header(s) added to the INVITE message,
the ACK is sent along the path of the original INVITE to the
bootstrap peer, which forwards it through the overlay to the
admitting peer.
6.4. Forming the Initial Offer and Answer
Associated with the INVITE transaction is an SDP offer-answer
exchange [RFC3264]. Typically, the SDP offer is contained in the
initial INVITE and the SDP answer is contained in the 200 OK
response, but the SIP specification [RFC3261] also allows other
possibilities. This document does not restrict the placement of the
SDP offer and answer beyond what is specified in [RFC3261].
The offer-answer exchange is used by the joining and admitting peers
to negotiate the parameters for the resulting Peer Protocol
connection. To do this, both the offer and answer SHOULD specify
exactly one media stream, and the media type for that stream MUST
specify the P2PSIP Peer Protocol. The details of how this is done
are outside the scope of this document.
The offer or answer MUST NOT include any of the following attributes:
"a=recvonly", "a=sendonly", or "a=inactive".
Peers SHOULD use ICE ([I-D.ietf-mmusic-ice] and
[I-D.ietf-mmusic-ice-tcp]) to determine a pair of transport addresses
to use for the Peer Protocol connection. This implies that both the
offer and answer should contain a set of ICE candidates - whether
these candidates are UDP candidates, TCP candidates, or other
candidate types depends on the transport selected for the Peer
Protocol.
6.5. Sending a new INVITE with Replaces
During the offer/answer exchange, both the joining peer and the
admitting peer use the rules described in ICE for deciding whether
ICE connectivity checks can be run or not.
If ICE connectivity checks can be run, then one or more connectivity
Cooper, et al. Expires August 28, 2007 [Page 19]
Internet-Draft Bootstrap Mechanisms February 2007
checks will then be executed to find working transmission paths
between the two peers. Following the rules in ICE
[I-D.ietf-mmusic-ice], as part of this process the two peers will
select one of them to be the controlling peer and the other to be the
controlled peer (in ICE terminology, these are called the
"controlling agent" and "controlled agent"). The controlling peer is
responsible for choosing the candidate pair to use for the connection
from amongst the working pairs, where a candidate pair consists of a
local candidate (= local IP address and port) and a remote candidate
(= remote IP address and port).
Once the controlling peer has selected a candidate pair to use for
the connection, it forms a new INVITE to send to the controlled peer.
The purpose of this INVITE is to establish a new dialog that goes
directly between the joining peer and the admitting peer, replacing
the dialog that goes via the bootstrap peer (and the bootstrap
server, if present).
The INVITE contains a Replaces header [RFC3891] that specifies the
dialog being replaced. The Replaces header contains the call-id, to-
tag, and from-tag of the dialog established by the initial INVITE; it
MUST NOT contain the "early-only" parameter, since that dialog may be
in the confirmed state. In addition, the pair (from-tag, call-id)
for this new INVITE must be distinct from the pair used in the
initial INVITE.
The INVITE contains the URI of the controlling peer (learned from the
Contact field in the previous INVITE transaction) as the Request URI
and as the URI in the To field, and the URI of the controlled peer in
the From and Contact fields.
The INVITE MUST contain an updated offer, since ICE requires that the
updated offer come from the controlling endpoint. Following the
procedures of ICE, the offer MUST include the local candidate from
the selected candidate pair and MUST NOT contain any other
candidates. This local candidate MUST also be placed in the m/c-line
of the offer.
In this way, this INVITE serves both to carry the Replaces and to
carry the updated offer needed for ICE.
This INVITE is sent using the selected candidate pair; that is, it is
addressed to the remote candidate in the pair and sent from the local
candidate in the pair. Following ICE procedures, the remote peer
must be prepared to receive this INVITE, since ICE requires that both
endpoints be prepared to receive STUN requests and "media" (in this
case, Peer Protocol and/or SIP messages) on a candidate as soon as
they advertise it.
Cooper, et al. Expires August 28, 2007 [Page 20]
Internet-Draft Bootstrap Mechanisms February 2007
If ICE connectivity checks are NOT run, then the two endpoints use
the address and port given in the m and c lines of the SDP for the
control connection, and it is the joining peer that sends the new
INVITE. The INVITE is formed as described above, except that updated
offer does not contain any of the attributes defined by ICE, since
ICE cannot be used for this connection. The updated offer MUST keep
the IP address and port in m and c lines unchanged.
6.6. Replying to the new INVITE
When the controlled peer receives the new INVITE, it replies with a
2xx that contains an updated answer. This 2xx is sent back along the
same new control connection as it was received. This updated answer
is formed in the same way as the updated offer: if ICE is used, the
updated answer MUST include the local candidate from the selected
candidate pair, MUST NOT contain any other candidates, and must
contain the local candidate in the m/c-line; if ICE is not used, the
updated answer MUST NOT contain any attributes defined by ICE, and
MUST keep the IP address and port in the m and c lines unchanged.
The receipt of the INVITE with the Replaces header triggers the
receiving peer to tear down the dialog that goes via the bootstrap
peer (and the bootstrap server if present). The is done by the
receiving peer sending a BYE on the existing dialog. Note that the
receiving peer may need to wait before sending the BYE if there is a
transaction outstanding on the old dialog - this might happen, for
example, if the admitting peer receives the INVITE for the new dialog
before receiving the ACK for the old dialog.
Once the new INVITE transaction is completed, the control connection
is ready for use as a Peer Protocol connection.
6.7. Keepalives
Keep-alives must be run on the control connection to maintain it in
the presence of NATs. To do this, control connections SHOULD use the
STUN Binding Indication method described in ICE
[I-D.ietf-mmusic-ice].
7. Security Considerations
The security details of the mechanisms presented in this document
have not yet been worked out in detail, so this section simply
presents some initial thoughts. Revisions to this document will
expand on the thoughts here.
Cooper, et al. Expires August 28, 2007 [Page 21]
Internet-Draft Bootstrap Mechanisms February 2007
7.1. Credentials
The authors envision the use of credentials to authorize four
different operations which form the bootstrap mechanisms described
here. Listing these in order of increasing privilege, these are:
1. The credentials required to send an INVITE through a bootstrap
server to a bootstrap peer.
2. The credentials required to register a new overlay with a
bootstrap peer and/or register a new contact for an existing
overlay.
3. The credentials required to have a bootstrap peer proxy an INVITE
through the overlay to the admitting peer.
4. The credentials required to set up a Peer Protocol connection for
bootstrap purposes.
Note that operations 1 and 2 are associated with the bootstrap
server, while operations 3 and 4 are associated with the overlay. It
is quite possible that the individual or group providing the
bootstrap server is distinct and only very loosely associated with
the group creating and using the overlay. In this case, the
credentials for operations 1 and 2 may be very different from the
credentials for operations 3 and 4.
Also note that credentials for operation 4 are likely to be the same
as those required to set up an arbitrary Peer Protocol connection.
If this is the case, then defining the format of these credentials
may be out-of-scope for this document.
Depending on the format of credentials chosen, peers might provide
the appropriate credentials in their initial messages, or provide
them only after being challenged. The mechanisms described in this
document have been designed to work with either approach (e.g. the
discussion in section 6.5).
7.2. Attacks
The bootstrap mechanisms described in this document do not introduce
any new SIP or SDP mechanisms, but merely use existing SIP and SDP
mechanisms in new ways. For that reason, none of the attacks against
these bootstrap mechanisms are new - they are simply applications of
existing attacks against the existing SIP and SDP mechanisms.
However, existing attacks can become more important in a bootstrap
context. Some attacks, which previously affected only a single user,
Cooper, et al. Expires August 28, 2007 [Page 22]
Internet-Draft Bootstrap Mechanisms February 2007
can now affect an entire overlay. For example, consider attacks
that, in a client-server SIP context, hinder a user from registering
with a registrar. If these attacks can be translated into a
bootstrap server context, then they can hinder an overlay from
registering with a bootstrap server, and thus potentially prevent the
overlay from forming. Similarly, attacks that, in a client-server
SIP context, hinder INVITEs from being proxied through a SIP proxy to
a specified user, will in a bootstrap server context, hinder peers
from joining the overlay, again potentially preventing the overlay
from forming.
8. IANA Considerations
This document raises no IANA considerations.
9. References
9.1. Normative References
[I-D.ietf-mmusic-ice]
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.
[I-D.ietf-mmusic-ice-tcp]
Rosenberg, J., "TCP Candidates with Interactive
Connectivity Establishment (ICE)",
draft-ietf-mmusic-ice-tcp-02 (work in progress),
October 2006.
[I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-07 (work in progress),
January 2007.
[I-D.willis-p2psip-concepts]
Bryan, D., Matthews, P., Shim, E., and D. Willis, "P2PSIP
Concepts and Terminology",
I-D draft-willis-p2psip-concepts-04 (work in progress),
February 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Cooper, et al. Expires August 28, 2007 [Page 23]
Internet-Draft Bootstrap Mechanisms February 2007
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the
Session Initiation Protocol (SIP) for Symmetric Response
Routing", RFC 3581, August 2003.
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891,
September 2004.
9.2. Informative References
[I-D.ietf-sipping-cc-transfer]
Sparks, R., Johnston, A., and D. Petrie, "Session
Initiation Protocol Call Control - Transfer",
I-D draft-ietf-sipping-cc-transfer-07 (work in progress),
October 2006.
[I-D.matthews-p2psip-nats-and-overlays]
Cooper, E. and P. Matthews, "The Effect of NATs on P2PSIP
Overlay Architecture",
I-D draft-matthews-p2psip-nats-and-overlays (work in
progress), February 2007.
Cooper, et al. Expires August 28, 2007 [Page 24]
Internet-Draft Bootstrap Mechanisms February 2007
Authors' Addresses
Eric Cooper
Avaya
1135 Innovation Drive
Ottawa, Ontario K2K 3G7
Canada
Phone: +1 613 592 4343 x228
Email: ecooper@avaya.com
Alan Johnston
Avaya
St. Louis, MO 63124
USA
Email: alan@sipstation.com
Philip Matthews
Avaya
100 Innovation Drive
Ottawa, Ontario K2K 3G7
Canada
Phone: +1 613 592 4343 x224
Email: philip_matthews@magma.ca
Cooper, et al. Expires August 28, 2007 [Page 25]
Internet-Draft Bootstrap Mechanisms 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).
Cooper, et al. Expires August 28, 2007 [Page 26]