[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/