TOC 
P2PSIP Working GroupE. Cooper
Internet-DraftA. Johnston
Intended status: Standards TrackP. Matthews
Expires: August 28, 2007Avaya
 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 © 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 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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).



Table of Contents

1.  Introduction

2.  Overview of the Mechanisms
    2.1.  Multicast Mechanism
    2.2.  Bootstrap Server Mechanism
    2.3.  Common Procedures
    2.4.  Multicast Example
    2.5.  Bootstrap Server Example
    2.6.  Pros and Cons of the Two Mechanisms

3.  Assumptions
    3.1.  Peer Protocol and Signaling Protocol
    3.2.  URI Format
    3.3.  Reducing the Load on Proxies

4.  Detailed Description of the Multicast Mechanism
    4.1.  The Mechanism
    4.2.  Discussion (Informative)

5.  Detailed Description of Bootstrap Server Mechanism
    5.1.  The Bootstrap Server
    5.2.  Registering with the Bootstrap Server
    5.3.  Forming the Initial INVITE
    5.4.  Sending the INVITE
    5.5.  Handling the INVITE at the Bootstrap Server

6.  Detailed Description of Common Procedures
    6.1.  Handling the INVITE at the Bootstrap Peer
    6.2.  Handing the INVITE at the Admitting Peer
    6.3.  Sending the ACK
    6.4.  Forming the Initial Offer and Answer
    6.5.  Sending a new INVITE with Replaces
    6.6.  Replying to the new INVITE
    6.7.  Keepalives

7.  Security Considerations
    7.1.  Credentials
    7.2.  Attacks

8.  IANA Considerations

9.  References
    9.1.  Normative References
    9.2.  Informative References

§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

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 (Bryan, D., Matthews, P., Shim, E., and D. Willis, “P2PSIP Concepts and Terminology,” February 2007.) [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 establish the connections over which the Peer Protocol runs. There are a number of reasons for making this assumption:

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.



 TOC 

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] (Bryan, D., Matthews, P., Shim, E., and D. Willis, “P2PSIP Concepts and Terminology,” February 2007.). These will be discussed in future versions of this document. This section is non-normative.



 TOC 

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.

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.



 TOC 

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.



 TOC 

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 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.



 TOC 

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.


      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



 TOC 

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 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.


      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



 TOC 

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, 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.



 TOC 

3.  Assumptions

This section lists and motivates the various assumptions this document makes about the nature of a solution to the bootstrap problem.



 TOC 

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 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.



 TOC 

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.



 TOC 

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.



 TOC 

4.  Detailed Description of the Multicast Mechanism

This section contains the normative description of the multicast mechanism.



 TOC 

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; 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 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [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.



 TOC 

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 specified in SIP (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] which says that subsequent replies are ignored. The OPTIONS message avoids this problem because it does not require an ACK.



 TOC 

5.  Detailed Description of Bootstrap Server Mechanism

This section contains the normative description of the bootstrap server mechanism.



 TOC 

5.1.  The Bootstrap Server

A P2PSIP Bootstrap Server behaves as a standard SIP registrar and proxy [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) 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] (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Caller Preferences for the Session Initiation Protocol (SIP),” August 2004.).

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.



 TOC 

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] (Rosenberg, J. and H. Schulzrinne, “Session Initiation Protocol (SIP): Locating SIP Servers,” June 2002.) 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 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] (Jennings, C. and R. Mahy, “Managing Client Initiated Connections in the Session Initiation Protocol (SIP),” January 2007.) 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).



 TOC 

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] (Rosenberg, J. and H. Schulzrinne, “An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing,” August 2003.).

See section 7.4 for how the SDP body is constructed.



 TOC 

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] (Rosenberg, J. and H. Schulzrinne, “Session Initiation Protocol (SIP): Locating SIP Servers,” June 2002.) to locate the proxy portion of the Bootstrap Server, and sends the INVITE message to it.



 TOC 

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 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [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 defined in [RFC3581] (Rosenberg, J. and H. Schulzrinne, “An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing,” August 2003.) unless it knows, through some unspecified mechanism, that this is not necessary.

Further processing after this point follows the procedures in section 7.



 TOC 

6.  Detailed Description of Common Procedures

This section describes normative procedures that are common to both mechanisms.



 TOC 

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 (Bryan, D., Matthews, P., Shim, E., and D. Willis, “P2PSIP Concepts and Terminology,” February 2007.) [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.



 TOC 

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 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261], possibly sending preliminary responses before the 2xx final response.

It is expected that the Peer Protocol will define rules for how responses are sent and routed through the overlay. Once the response gets back to the bootstrap peer, the rules of [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) 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.



 TOC 

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.



 TOC 

6.4.  Forming the Initial Offer and Answer

Associated with the INVITE transaction is an SDP offer-answer exchange [RFC3264] (Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with Session Description Protocol (SDP),” June 2002.). 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 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] also allows other possibilities. This document does not restrict the placement of the SDP offer and answer beyond what is specified in [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.).

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] (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” January 2007.) and [I‑D.ietf‑mmusic‑ice‑tcp] (Rosenberg, J., “TCP Candidates with Interactive Connectivity Establishment (ICE),” October 2006.)) 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.



 TOC 

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 checks will then be executed to find working transmission paths between the two peers. Following the rules in ICE (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” January 2007.) [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] (Mahy, R., Biggs, B., and R. Dean, “The Session Initiation Protocol (SIP) "Replaces" Header,” September 2004.) 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.




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.



 TOC 

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.



 TOC 

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 (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” January 2007.) [I‑D.ietf‑mmusic‑ice].



 TOC 

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.



 TOC 

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).



 TOC 

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, 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.



 TOC 

8.  IANA Considerations

This document raises no IANA considerations.



 TOC 

9.  References



 TOC 

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 (TXT, HTML, XML).
[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.


 TOC 

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.


 TOC 

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


 TOC 

Full Copyright Statement

Intellectual Property

Acknowledgment