Internet DRAFT - draft-aoki-simple-interdomain-bcp

draft-aoki-simple-interdomain-bcp







SIMPLE WG                                                        E. Aoki
Internet-Draft                                                   AOL LLC
Expires: January 22, 2007                                       A. Houri
                                                                     IBM
                                                                O. Levin
                                                                 T. Rang
                                                          M. Trommsdorff
                                                   Microsoft Corporation
                                                           July 21, 2006


  Best Current Practices for Inter-domain Instant Messaging using SIP/
                                 SIMPLE
                  draft-aoki-simple-interdomain-bcp-02

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 January 22, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes best current practices that community
   administrators should use when interconnecting two or more instant



Aoki, et al.            Expires January 22, 2007                [Page 1]

Internet-Draft             Inter-domain IM BCP                 July 2006


   messaging and presence communities using SIP/SIMPLE.  These best
   practices are intended to assist in the efficiency and scalability of
   interconnections between large communities, and to ensure that
   security and user privacy are maintained across the link between
   communities.  The purpose of this document is to serve as the
   reference for the SIP/SIMPLE community towards inter-domain
   interoperability and also to identify new requirements specific to
   the inter-domain interface.


Table of Contents

   1.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Topology and Architecture  . . . . . . . . . . . . . . . . . .  4
   4.  Connecting SIP/SIMPLE Communities  . . . . . . . . . . . . . .  5
     4.1.  Configuration and Discovery  . . . . . . . . . . . . . . .  5
     4.2.  Connection Management  . . . . . . . . . . . . . . . . . .  6
     4.3.  Transport Security . . . . . . . . . . . . . . . . . . . .  6
     4.4.  Compression  . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Presence . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.1.  Handling Presence Requests . . . . . . . . . . . . . . . .  8
     5.2.  Presence Format  . . . . . . . . . . . . . . . . . . . . .  9
     5.3.  Automatic Periodic Presence Operations . . . . . . . . . . 10
       5.3.1.  Reasserting Subscriptions  . . . . . . . . . . . . . . 11
       5.3.2.  Reasserting Presence . . . . . . . . . . . . . . . . . 11
       5.3.3.  Polling Presence Requests  . . . . . . . . . . . . . . 11
   6.  Instant Messaging (IM) . . . . . . . . . . . . . . . . . . . . 12
     6.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . . 12
     6.2.  Page IM  . . . . . . . . . . . . . . . . . . . . . . . . . 12
     6.3.  Session IM . . . . . . . . . . . . . . . . . . . . . . . . 13
       6.3.1.  MSRP . . . . . . . . . . . . . . . . . . . . . . . . . 13
       6.3.2.  Other session based mecahisms  . . . . . . . . . . . . 13
   7.  SIP Miscellaneous  . . . . . . . . . . . . . . . . . . . . . . 14
   8.  Community Profiles . . . . . . . . . . . . . . . . . . . . . . 14
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
     9.1.  Implicit Authority . . . . . . . . . . . . . . . . . . . . 15
     9.2.  Spam Prevention  . . . . . . . . . . . . . . . . . . . . . 15
     9.3.  External Community Contacts Accuracy . . . . . . . . . . . 16
     9.4.  Address Confidentiality and Validity . . . . . . . . . . . 17
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
   12. Change History . . . . . . . . . . . . . . . . . . . . . . . . 18
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 18
     13.2. Informational References . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
   Intellectual Property and Copyright Statements . . . . . . . . . . 21



Aoki, et al.            Expires January 22, 2007                [Page 2]

Internet-Draft             Inter-domain IM BCP                 July 2006


1.  Conventions

   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 RFC-2119 [1].


2.  Introduction

   SIP and SIMPLE based presence and instant messaging systems are
   increasingly being adopted as a rapid and efficient means of
   communication between parties.  However, existing Internet Drafts
   describing these communications often assume an operational model in
   which individual users connect to one another (potentially with the
   aid of intermediary proxies) to exchange information and are largely
   free to specify their own connection and policy preferences.

   In a more typical real-world scenario, users exist as part of a
   messaging community administered by or on behalf of an organization.
   This organization may specify additional policies and requirements on
   the messaging traffic it administers and is often trusted to act on
   behalf of one or more users in its community.  Also, because these
   communities may be large and aggregate traffic for many users, they
   may be able to take advantage of certain economies of scale that an
   individual messaging user may not.

   This document specifies Best Current Practices that these messaging
   communities can employ to ensure that their interchange of presence
   information and instant messages (IMs) is secure, efficient, and
   consistent.  Its recommendations are based on the authors' collective
   experience derived from interconnecting multiple large enterprise and
   consumer instant messaging networks and is intended to serve as a
   non-normative reference for SIP/SIMPLE deployers that wish to
   encourage more seamless and efficient interoperation between
   messaging domains.

   Some of the recommendations in this document may be applicable to
   other forms of SIP traffic, including VoIP, video, or other media
   such as those discussed in the SPEERMINT working group.  However,
   while the authors encourage uniform practices across all media types,
   and this document may, from time to time, refer to SIP endpoints in a
   more generic sense, the best current practices described in this
   document are offered primarily within a presence and instant
   messaging context.

   The document is structured into the following main sections:





Aoki, et al.            Expires January 22, 2007                [Page 3]

Internet-Draft             Inter-domain IM BCP                 July 2006


   o  Topology and Architecture (Section 3)
   o  Connecting Communities via SIP/SIMPLE (Section 4)
   o  Presence (Section 5)
   o  Instant Messaging (Section 6)
   o  SIP Miscellaneous (Section 7)
   o  Security Considerations (Section 9)


3.  Topology and Architecture

   This document describes Best Current Practices for the
   interconnection of two or more communities of messaging users.  A
   messaging community administers its own namespace of SIP addresses or
   has other administrative authority over a collection of users and/or
   SIP/SIMPLE endpoints, and for the purposes of this document, we
   consider these users as "represented by" a given SIP/SIMPLE presence
   and messaging community.  The users of an enterprise, the subscribers
   of a mobile operator, or the customers of a given service provider
   are examples of such communities.

   It is certainly true that an individual in one community (as
   represented by a presentity and/or instant inbox in a given domain)
   can communicate (perhaps through a series of proxies) to another
   individual in another community (i.e., a corresponding presentity/
   instant inbox in a different domain) without consideration of a
   broader messaging community or the kinds of practices described in
   this document.  However, in many real-world cases, domains represent
   a unit of administrative control that impose additional requirements
   around authorization, confidentiality, and the like.  Additionally,
   these best practices may also provide useful guidance where the edge
   proxy is a translating gateway and terminates inbound SIP/SIMPLE
   dialogs on behalf of a non SIP/SIMPLE messaging or presence system.

   A typical deployment topology illustrating how two SIP/SIMPLE
   communities might interconnect is shown in the figure below.

           /\                                                       /\
          /U-A                                                     /U-B
         /____\                   -----------                     /____\
                             /////           \\\\\
       _____   +-------+   //                     \\   +-------+       _____
      /    /   |       |  |                         |  |       |      /    /
     /R-A /    | EP-A  |  |         Internet        |  | EP-B  |     /R-B /
    /____/     |       |  |                         |  |       |    /____/
               +-------+   \\                     //   +-------+
        _____                \\\\\           /////               _____
       /    /                     -----------                   /    /
      /P-A /                                                   /P-B /



Aoki, et al.            Expires January 22, 2007                [Page 4]

Internet-Draft             Inter-domain IM BCP                 July 2006


     /____/                                                   /____/

   The edge proxies (EP-A and EP-B) for a given community are SIP
   proxies that have both ability and authority to route traffic from
   the public network to the SIP entities within that community.  Each
   edge proxy is said to "service", "be responsible for", "act on behalf
   of", or be "in" a community, which is to say that the edge proxy
   listens for requests intended for a given community (identified by
   its domain), routes the SIP traffic "to" and "from" the community,
   and in some cases provides authoritative answers on behalf of the
   users and entities within that community.

   The other components shown in the picture are logical SIP/SIMPLE
   entities internal to each community that participate in different
   aspects of presence and IM.  They include UAs/PUAs (U-A and U-B),
   Registrars (R-A and R-B), and Presence Servers (P-A and P-B).  The
   management and administration of these entities, the namespaces they
   occupy, and the local policies that apply to them remain under the
   administrative control of the community, and these recommendations do
   not attempt to establish federated identity or delegated policy
   administration across inter-domain links.

   Rather, this document is concerned with the protocols and deployment
   considerations of the "inter-domain interface" between two separately
   administered SIP clouds.  Put another way, the inter-domain interface
   is the path between EP-A and EP-B, where traffic can traverse any
   communication transport layer pertaining SIP/SIMPLE (e.g.  VPN for
   trusted domains).  This path may optionally include a chain of SIP
   proxies for application routing in-between.


4.  Connecting SIP/SIMPLE Communities

4.1.  Configuration and Discovery

   When a user in a given SIP/SIMPLE community wishes to communicate
   with users in a different community, a route must exist between the
   sender's edge proxy (EP-A) and that of the destination (EP-B).  To
   establish this route, an edge proxy needs to learn the Fully
   Qualified Domain Name (FQDN) of its peer proxy by means out-of-band
   to SIP.

   One means of discovery is the use DNS SRV records according to the
   procedures in RFC-3263 [9].  However, some communities may wish to
   implement more restrictive policy concerning other communities to
   whom their users may communicate.  These communities may choose not
   to publish DNS SRV records or to be reached on unpublished ports, or
   they may choose not to trust DNS for outbound connections.



Aoki, et al.            Expires January 22, 2007                [Page 5]

Internet-Draft             Inter-domain IM BCP                 July 2006


   Accordingly, it is RECOMMENDED that local edge proxies have the
   ability to be statically provisioned with the list of valid DNS
   domains to which they may connect.  These are the DNS domains that
   the remote edge proxy has the authority and the ability to route to.
   Depending on local policy, this list may be used in conjunction with
   or in place of DNS lookups or other discovery mechanisms employed to
   locate a suitable route.

   Regardless of whether it is possible to discover the receiving edge
   proxy for a given domain, the destination community may have specific
   policies that govern who can connect to it.  The specification of
   these policies and rules surrounding their provisioning are out of
   scope of this document.  The SPEERMINT working group is investigating
   the provisioning issue in [14].

4.2.  Connection Management

   Connections between communities of presence and messaging SHOULD use
   reliable and congestion safe connection for transport.  These
   connections are bi-directional, semi-persistent, and are established
   on-demand by either edge proxy.

   For large communities, many thousands or millions of dialogs may be
   occurring concurrently.  Consequently, it would likely not be
   appropriate for a community to establish one connection per SIP
   dialog.

   Data for multiple SIP dialogs can and likely will flow across a given
   connection.  Conversely, the requests and responses that make up a
   given dialog may flow over any active connection that exists between
   the two SIP/SIMPLE communities and is not guaranteed to flow over the
   same connection as preceding requests.  If a connection fails or is
   closed by either side due to a locally defined inactivity period or
   policy, each side can initiate new connections at any time.

   Although SIP/SIMPLE communities may establish more than one
   connection to communicate with other, in consideration of
   scalability, it is RECOMMENDED that implementations limit the number
   of such connections to a reasonable number.  In any event, the
   receiving community's edge proxy MAY refuse to accept more than a
   given number of connections from a given edge proxy or from all of
   the edge proxies that reside within a given community.

4.3.  Transport Security

   In order to prevent spoofing, provide better control against spam,
   and allow privacy and secured transport, communities SHOULD use a
   mutually authenticated TLS connection between the edge proxies.  Of



Aoki, et al.            Expires January 22, 2007                [Page 6]

Internet-Draft             Inter-domain IM BCP                 July 2006


   course, if both edge proxies are in a joint secure area, they MAY
   connect over an insecure transport protocol.

   According to the TLS protocol RFC-4346 [2], for establishment of the
   mutually authenticated TLS connection, each server needs to present a
   valid certificate to the other server.  Each server also needs to
   trust the certificate authority that issued the certificate presented
   by the other proxy or trust the certificate itself.  Once a TLS
   connection is established between two edge proxies, it is trusted for
   the life of the connection as long as the certificate is valid.  When
   using a secure transport, the edge proxies of both sides may act as
   the security UA, leaving the internal components from dealing with
   the transport security.

   As indicated in the preceding section, one or more connections can be
   simultaneously maintained between two edge proxies.  If a group of
   TLS connections is maintained between the two edge proxies, the same
   certificate MUST be used for all connections servicing a given
   community.  This allows allocation of SIP dialogs among the TLS
   connections according to local policy and without requiring
   additional protocols between the communities.

4.4.  Compression

   SIP/SIMPLE is a relatively verbose protocol, and between very large
   communities, a significant amount of traffic will need to travel
   across the inter-domain boundary to transmit presence and messaging
   information.  In order to reduce the amount of data that passes
   between two communities, edge proxies may employ compression.  Data
   compression is particularly effective because much of the data,
   including SIP header names or addressee domain names, are repeated in
   each SIP message.

   Edge proxies that support TLS as recommended above MUST also support
   the mechanism of negotiating TLS protocol compression, as specified
   in RFC-4346 [2], and one or more TLS compression methods (other than
   the null compression method).  At the time of this writing, RFC-3749
   [12] and RFC-3943 [13] are examples of transport-level compression
   methods.

   Edge proxies may also implement data compression using another
   mutually agreed compression mechanism.  For example, RFC-3485 [10]
   specifies an application-level compression mechanism, SigComp, which
   uses a predefined data dictionary to reduce the overhead of
   repetitive SIP messages.  RFC-3486 [11] describes how to signal the
   use of SigComp or an alternate application compression mechanism
   within the SIP data flow.




Aoki, et al.            Expires January 22, 2007                [Page 7]

Internet-Draft             Inter-domain IM BCP                 July 2006


5.  Presence

5.1.  Handling Presence Requests

   In order to get the presence information from a user in a different
   community, the standard SIP SUBSCRIBE/NOTIFY mechanisms defined in
   RFC-3265 [3] and RFC-3856 [4] are used.

   An edge proxy may receive SUBSCRIBE requests for presentities that do
   not exist within its community or are restricted by local policy from
   communicating across communities.  For example, a mistyped contact
   name or the removal of a previously valid identity (e.g. enterprise
   user quits the company) could result in this case.

   In the inter-domain case, the receiving edge proxy typically answers
   on behalf of entities within the community it represents, so in
   accordance with RFC-3265 [3], it SHOULD reject the session by issuing
   one of the 4XX responses (e.g. "404 Not found" or "403 Forbidden") to
   SUBSCRIBE.  If one of the 4XX responses is generated, it is strongly
   RECOMMENDED that the originating community does not automatically
   (i.e. without user intervention) retry the same SUBSCRIBE request
   again.

   Alternately, the receiving edge proxy MAY accept the SUBSCRIBE using
   a 2xx response and indicate in a subsequent NOTIFY that the
   presentity is not available (i.e. has "closed" status).  A given
   community may wish to do this to maintain a greater level of
   confidentiality, as described in section 5.2 of RFC-3265 [3]; for
   example, in order to prevent dictionary attacks to harvest valid
   presentity addresses.

   In some cases, the receiving edge proxy may want to indicate that the
   principal specified in the Request URI is one for which presence does
   not apply.  For example, a SIP URI specified as the recipient of a
   subscription may correspond to a distribution list or other address
   that is explicitly known to have no presence data, regardless of the
   watcher.  In this case, the edge proxy responsible for a given
   community MAY return 604 ("Does Not Exist Anywhere") in response to
   the SUBSCRIBE request.  The edge proxy representing the requester's
   community MAY, upon receiving a 604 response, safely store local
   state that can be used to short circuit future similar SUBSCRIBE
   requests to that presentity from any watcher.  The watcher's proxy
   may treat any similar subsequent SUBSCRIBE requests that it would
   normally send to the presentity as having returned a 404 response
   code and MAY cache the 604 response for a relatively long-lived
   period of time not to exceed 30 days.  Note that because the
   originating edge proxy essentially turns the 604 response into a 404
   response, this optimization has the same confidentiality concerns as



Aoki, et al.            Expires January 22, 2007                [Page 8]

Internet-Draft             Inter-domain IM BCP                 July 2006


   returning 404 would.  On the other hand, the purpose of the 604
   response is to explicitly indicate that subsequent requests will fail
   for all watchers, so there should be no expectation of
   confidentiality in this case.

5.2.  Presence Format

   The basic presence format used between users in different communities
   is defined by Presence Information Data Format [5].  This standard
   format is signaled by including the "Accept" header with
   "application/pidf+xml" in the SUBSCRIBE as (at least) one of the
   possible presence formats the watcher understands.

   Any additional presence information MAY be exchanged over the inter-
   domain interface if encoded according to standard XML extension
   techniques.  At a minimum, edge proxies SHOULD accept the following
   additional standard user information:
   o  "activity" element defined in Rich Presence Extensions [15].
   o  "icon" element defined in Contact Information [16].
   o  "display-name" element defined in Contact Information [16].

   A PUA MUST be capable of receiving any XML extended schema, compliant
   with the standard, and gracefully ignore any extensions it doesn't
   understand.

   An example of a simple presence document is shown below:

      <?xml version="1.0" encoding="UTF-8"?>
         <presence xmlns="urn:ietf:params:xml:ns:pidf"
                   xmlns:es="urn:ietf:params:xml:ns:pidf:rpid-status"
                   xmlns:ci="urn:ietf:params:xml:ns:pidf:cipid"
          entity="sip:t-jones@example.com">
           <tuple id="0">
             <status>
               <basic>open</basic>
                <es:activities>
               <es:activity>on-the-phone</es:activity>
                </es:activities>
             </status>
             <contact>sip:tom-pc@example.com</contact>
           </tuple>
           <ci:display-name>Tom Jones</ci:display-name>
         </presence>


   The Presence Data Model [17] draft defines a more robust mechanism
   for specifying presence information for people, services, and
   devices.  A presence document that models the same presence



Aoki, et al.            Expires January 22, 2007                [Page 9]

Internet-Draft             Inter-domain IM BCP                 July 2006


   information using the conventions specified in that model might look
   like the following:

      <?xml version="1.0" encoding="UTF-8"?>
      <presence xmlns="urn:ietf:params:xml:ns:pidf"
       xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
       xmlns:rp="urn:ietf:params:xml:ns:pidf:rpid"
       xmlns:caps="urn:ietf:params:xml:ns:pidf:caps"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
       <tuple id="imsvc">
        <status>
         <basic>open</basic>
        </status>
        <dm:deviceID>mac:8asd7d7d7d</dm:deviceID>
        <caps:servcaps>
         <caps:methods>
          <caps:supported>
           <caps:INFO/>
           <caps:INVITE/>
           <caps:MESSAGE/>
           <caps:NOTIFY/>
           <caps:OPTIONS/>
           <caps:SUBSCRIBE/>
          </caps:supported>
         </caps:methods>
        </caps:servcaps>
        <contact>sip:t-jones@example.com</contact>
       </tuple>
       <dm:person id="tomjones">
        <rp:activities>
         <rp:on-the-phone/>
        </rp:activities>
       </dm:person>
       <dm:device id="toms_pc">
        <rp:user-input>idle</rp:user-input>
        <dm:deviceID>mac:8asd7d7d7d</dm:deviceID>
       </dm:device>
      </presence>

5.3.  Automatic Periodic Presence Operations

   Some SIP/SIMPLE communities may reassert subscription requests or
   presence notifications without user intervention in order to provide
   a form of self-repair or to update stale data.  These reassertions
   will take the form of a new dialog, rather than a refresh of an
   existing subscription.





Aoki, et al.            Expires January 22, 2007               [Page 10]

Internet-Draft             Inter-domain IM BCP                 July 2006


5.3.1.  Reasserting Subscriptions

   A watcher within a SIP/SIMPLE community MAY automatically
   periodically generate re-SUBSCRIBEs towards a presentity within an
   external SIP/SIMPLE community (for example, in order to ensure
   contact accuracy).  In order to prevent gratuitous re-SUBSCRIBES from
   resulting in a large amount of traffic over the inter-domain link,
   the proxy representing the presentity SHOULD check the "Expires"
   header and return a "423 Interval too small" with a "Min-Expires"
   header field if the expiration interval specified for the
   subscription is too short.

   Similarly, absent any bilateral agreement between the administrative
   authorities for each community, a watcher MUST NOT gratuitously
   refresh the subscription more frequently than implied by the
   expiration time of the subscription unless necessary to communicate
   changes in subscription parameters, request a full state refresh
   after synchronization has been lost with partial notification state,
   or in response to explicit user activity.

5.3.2.  Reasserting Presence

   An entity within a SIP/SIMPLE community MAY automatically
   periodically generate NOTIFYs towards an external SIP/SIMPLE
   community.  In the absence of any bilateral agreement between the
   administrative authorities for each community, data refreshes within
   the same SUBSCRIBE dialog MUST NOT occur more frequently than every
   10 minutes.  This limitation doesn't apply to notifications about
   dynamic changes in users' state (for example, a user transitioning
   from an "open" to "closed" state).

5.3.3.  Polling Presence Requests

   Some watchers may choose to implement polling to update presence
   rather than create a presence subscription.  Because these requests
   generate traffic and load regardless of whether the presentity has
   changed state, they are very inefficient and, between large
   communities will result in large amounts of extraneous data traffic
   and processing.  Therefore, absent a bilateral agreement to the
   contrary, watchers SHOULD NOT poll for presence information at any
   interval shorter than 5 minutes.  A given community MAY reject polled
   presence requests (e.g., fetching presence with an expiration of 0)
   altogether.  Watchers that wish to have more up to date presence
   information should instead create a subscription using the standard
   presence subscription mechanisms.






Aoki, et al.            Expires January 22, 2007               [Page 11]

Internet-Draft             Inter-domain IM BCP                 July 2006


6.  Instant Messaging (IM)

6.1.  General

   At the time of this writing, IM networks in the field still rely on
   both Page Mode and Session Mode for the exchange of instant messages.
   These modes will likely continue to coexist, possibly within the same
   network, with each mode optimized for and being used by different
   applications and potentially resulting in different user experiences.

   A given UA MAY query its peer's IM capabilities using the SIP OPTIONS
   request specified in RFC-3261 [6] if it wishes to determine whether a
   particular mode is supported for the exchange of instant messages.

   A UA that receives a request to initiate an instant messaging
   exchange using a mode that it can not or will not support SHOULD
   respond with a "488 Not Acceptable Here" response with a Warning
   header field value explaining why the offer was rejected and
   expressing the acceptable IM mode(s) by including its capabilities as
   specified in section 11.1 and 21.4.26 of RFC-3261 [6] and as shown
   for each mode specifically in the sections below.

6.2.  Page IM

   UAs must minimally support Page mode IM, pursuant to RFC-3428 [7].
   In order to indicate the support of Page Mode, a UA responds to the
   OPTIONS request by including the Allow header with listing the
   MESSAGE as one of the methods it supports as shown in the example
   below:

         SIP/2.0 200 OK
         Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
          ;received=192.0.2.4
         To: <sip:carol@example.com>;tag=93810874
         From: Alice <sip:alice@atlanta.com>;tag=1928301774
         Call-ID: a84b4c76e66710
         CSeq: 63104 OPTIONS
         Contact: <sip:carol@example.com>
         Contact: <mailto:carol@example.com>
         Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, MESSAGE
         Accept: application/sdp
         Supported: foo
         Content-Type: application/sdp
         Content-Length: 274

         (SDP not shown)





Aoki, et al.            Expires January 22, 2007               [Page 12]

Internet-Draft             Inter-domain IM BCP                 July 2006


   As described for presence, above, an edge proxy handling requests for
   the destination community may receive MESSAGE requests for IM
   addresses that do not exist within the community or are restricted by
   local policy from communicating with other communities.  In these
   cases, the receiving community SHOULD return a 4XX response (e.g.
   "404 Not found" or "403 Forbidden") to MESSAGE.  If one of the 4XX
   responses is generated, it is strongly RECOMMENDED that the
   originating UA refrain from issuing additional MESSAGE requests
   within a reasonable timeframe.  A receiving community MAY alternately
   return a 2xx response and fail to deliver the message.  A given
   community may wish to do this in order to prevent dictionary attacks
   to harvest valid IM addresses.  If the address is not a valid
   endpoint for instant messages regardless of sender, the receiving
   edge proxy MAY return 604 Does Not Exist Anywhere.  The sending edge
   proxy may cache the 604 response and immediately return a 404
   Forbidden to subsequent MESSAGE requests from any sender to the
   specified address.  This behavior is analogous to that described for
   presence requests in Section 5.1, above.

6.3.  Session IM

   UAs may also support a session-based IM protocol.  UAs that wish to
   use a session-based IM protocol should initiate a session by sending
   an INVITE request and negotiating an appropriate session protocol.
   If the peer can not or does not wish to support session-based IM, it
   will return a 415 or 488 response code.  In this case, the
   originating UA may fall back to page-mode IM.  Alternately, the
   originating proxy may use the OPTIONS request to query the peer's
   capabilities in advance.

6.3.1.  MSRP

   At the time of this writing, the Message Sessions Relay Protocol
   (MSRP) [18] is under definition within the SIMPLE working group.
   Once it is standardized, it will become a valid IM means over inter-
   domain links.

6.3.2.  Other session based mecahisms

   Prior to the standardization and widespread adoption of MSRP among
   instant messaging and presence communities, some communities have
   adopted interim non-standardized solutions for grouping messages
   within a logical session.  As with all SIP traffic, communities that
   understand and wish to use these mechanisms may do so by negotiating
   their use according to SIP RFC-3261 [6] and SDP "Offer-Answer Model"
   RFC-3264 [8] procedures.





Aoki, et al.            Expires January 22, 2007               [Page 13]

Internet-Draft             Inter-domain IM BCP                 July 2006


7.  SIP Miscellaneous

   SIP public proxies (i.e. those proxies through which a SIP message
   transits between edge proxies of SIP/SIMPLE communities) SHOULD
   preserve all SIP headers and parameters they don't understand.

   If the accumulated length of Record Route headers in incoming (from
   an inter-domain link) SIP request exceeds the local policy of the
   receiving community, the recipient SHOULD reject the session by
   responding with "513 Message Too Large" to the request.  Subsequent
   retries are unlikely to yield different results, and these requests
   should not be retried unless the calling party believes that some
   amount of state has changed.


8.  Community Profiles

   Before connecting separately administered SIP/SIMPLE communities,
   each community should review its own local procedures and implement
   these relevant best practices in order to "play nicely" in a global
   SIP/SIMPLE environment.  Each community also SHOULD take precautions
   in order to defend itself (both reactively and proactively) from
   potentially badly behaving other communities.  This document
   describes a number of these best practices.

   However, in some cases, communities will want to exchange details
   about their local policy or specific implementations.  Policies
   regarding rate limits, which communities can connect to one another,
   and other inter-community concerns are examples of the kind of
   "profile" information that a community may wish to make known to its
   potential peers.

   At the time of this writing, the majority of this profile information
   is not or can not be enforced by signaling and control mechanisms in
   the communciations protocols themselves.  Until a standardized means
   to exchange profile data is available and widely deployed, many of
   these parameters will be specified out of band, either through non-
   standardized protocols or via out-of-band agreements.

   Notwithstanding these agreements, communities that communicate with
   external entities SHOULD adhere to the general provisions in this
   document and MUST adhere to the provisions referenced in the security
   considerations section, below.


9.  Security Considerations

   This document describes a number of requirements and best practices



Aoki, et al.            Expires January 22, 2007               [Page 14]

Internet-Draft             Inter-domain IM BCP                 July 2006


   for interconnecting distinctly administered SIP/SIMPLE communities
   for the purpose of exchanging presence and instant messages.  Because
   these inter-domain connections traverse the public Internet, it is
   especially important to be conscious of security in order to preserve
   user privacy and to take into account scalability and operational
   requirements for the network.

   In that vein, this entire document describes a number of practices
   that directly or indirectly relate to security, but in particular,
   Section 4.3 describes specific tactics meant to defend against
   eavesdropping and man-in-the-middle attacks, and to provide for data
   integrity and other protections.  Other sections describe conventions
   and techniques that can be used to mitigate the risk of DOS attacks
   and to prevent undue traffic over the network.

   It is important to note that this document primarily describes the
   interactions that take place over the inter-domain interface.
   Because these inter-domain connections exist between edge proxies and
   not directly between end-user UAs, issues surrounding the
   authentication of UAs internally or of securing intra-community
   traffic are considered out of scope.  Nonetheless, each community is
   assumed to be responsible for its own internal security, and edge
   proxies are explicitly assumed to be authoritative and responsible
   for traffic originating within a community.

9.1.  Implicit Authority

   In the inter-domain model described here, a domain is assumed to have
   the implicit authority to terminate requests and responses on behalf
   of entities under its administrative control.  In this model, all
   inter-community communications originating from or terminating in a
   given domain MUST pass through the edge proxy acting on behalf of
   that domain.  The edge proxy for a given community MAY reject
   connections from entities purporting to be part of a given domain
   that do not traverse that domain's edge proxy.

9.2.  Spam Prevention

   Given the prevalence of spam in other communications media, spam
   prevention deserves special consideration.  Spam is defined in this
   case as unsolicited presence requests and instant messaging traffic
   and sent from an inter-domain link to a recipient unwilling to
   process this traffic.

   The SIP and Spam [19] document discusses many techniques that can be
   used to reduce spam with their advantages and disadvantages.

   This document concentrates on technologies that are deployable today



Aoki, et al.            Expires January 22, 2007               [Page 15]

Internet-Draft             Inter-domain IM BCP                 July 2006


   and the techniques applicable to the multi-domain topology with SIP
   edge proxies on the borders of each domain or community.  Because
   edge proxies (and the intermediate proxies, if deployed) are
   interconnected using mutually authenticated TLS links, the
   fundamental trust model for parties in the network can be reliably
   maintained.

   Each community is assumed to be responsible for taking measures to
   prevent its own users from generating spam.  Each community is also
   responsible for preventing unauthorized access that would allow a
   malicious third party to gain access to the network for the purpose
   of sending spam.  These techniques are considered out of scope of
   this document.

   Each community SHOULD have mechanisms in place to disable its own
   users that are injecting spam into the inter-domain interface.  Most
   efficiently, this can be achieved by toughening the local policies
   and/or by using block and allow lists that limit a local user's
   ability to send messages based on that user's standing within the
   community.  The specifics of these local policies are out of scope of
   this document.

   A receiving community's edge proxy SHOULD take into account factors
   such as the level of trust in the calling party, the number of
   instant messages received from a given sender or community (either to
   a single recipient or aggregated across all users in a community), or
   using any of the other techniques listed in [19].  The receiving
   proxy MAY reject or close connections, provide degraded service, or
   employ other local policy to deal with these attacks.

9.3.  External Community Contacts Accuracy

   An additional issue that occurs with inter-community presence is that
   presence subscriptions are typically long-lived and are identified
   only with a SIP "Address of Record" (AoR).  If a principal leaves a
   community and is subsequently replaced by another principal having
   the same address as the departed principal, the new principal may
   receive messages for, or be exposing presence to, entities that are
   trying to communicate with the previous principal.

   Therefore, for inter-community communications, it is REQUIRED that
   the communities not reassign a removed user AoR to a new user for at
   least 90 days after the old user was removed from the community.

   In order to ensure the validity of a user's contact lists and ACLs,
   it is strongly RECOMMENDED that the network services periodically re-
   SUBSCRIBE to all external contacts in the lists at least every 45
   days.  If such a resubscription results in a permanent error result,



Aoki, et al.            Expires January 22, 2007               [Page 16]

Internet-Draft             Inter-domain IM BCP                 July 2006


   the watcher may assume that the contact is no longer valid and may
   clean up the contact lists and ACLs based on some logic that is out
   of the scope of this document.

9.4.  Address Confidentiality and Validity

   This document proposes a new usage of the 604 response code to
   indicate that a request URI is not a valid presentity and/or instant
   inbox for any watcher or sender.  The use of this response code is
   suggested as an optimization that allows a given domain to avoid
   sending traffic over the inter-domain link that will very likely
   result in a failure.  While the use of the 604 response code is
   optional, its use does warrant some additional security discussion.

   The 604 response as described here is intended to be cached at the
   requestor and used to prevent subsequent requests to the same
   recipient from being issued.  It should therefore only be returned
   for extant, valid addresses that are explicitly indicated not to have
   presence and/or messaging capabilities, not for addresses that are
   simply invalid or unassigned.

   An attacker could use this knowledge to determine that a 604 response
   for a given request means that the address specified in the request's
   URI is valid and refers to some entity within the domain.  Domains
   that wish to maintain the confidentiality of valid addresses within
   their domain should not use the 604 response code and should instead
   return a 2xx code with a subsequent NOTIFY message containing
   potentially correct data.

   One other issue is that the 604 response may have a long-lived cache.
   If an address for which a 604 had previously been returned suddenly
   becomes a valid presentity and/or instant inbox, other domains would
   not necessarily recognize this fact until their local cache of the
   604 response had expired.  This document specifies a maximum cache
   duration so that, in the worst case, this local cache may be stale
   for up to 30 days.


10.  IANA Considerations

   None.


11.  Acknowledgments

   Thanks to Sharon Fridman, Followap for a review of the document and
   helpful suggestions, and to the members of the SIMPLE working group
   mailing list who provided additional comments and feedback.



Aoki, et al.            Expires January 22, 2007               [Page 17]

Internet-Draft             Inter-domain IM BCP                 July 2006


12.  Change History
   Initial Version: This document was derived from
      draft-levin-simple-interdomain-reqs-03.txt
      New protocol requirements for SIP/SIMPLE were moved to a separate
      draft
      Reworked language to be more consistent with BCP drafts
   -01 Clarified some ambiguities in the earlier draft and cleaned up
      some language issues to make it more readable.
      Updated some references to newer drafts
   -02 Resubmitting to resolve an error with the draft's expiration date
      on the -01 version.


13.  References

13.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
        Protocol Version 1.1", RFC 4346, April 2006.

   [3]  Roach, A., "Session Initiation Protocol (SIP)-Specific Event
        Notification", RFC 3265, June 2002.

   [4]  Rosenberg, J., "A Presence Event Package for the Session
        Initiation Protocol (SIP)", RFC 3856, August 2004.

   [5]  Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
        J. Peterson, "Presence Information Data Format (PIDF)",
        RFC 3863, August 2004.

   [6]  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.

   [7]  Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
        D. Gurle, "Session Initiation Protocol (SIP) Extension for
        Instant Messaging", RFC 3428, December 2002.

   [8]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
        Session Description Protocol (SDP)", RFC 3264, June 2002.

13.2.  Informational References

   [9]   Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
         (SIP): Locating SIP Servers", RFC 3263, June 2002.



Aoki, et al.            Expires January 22, 2007               [Page 18]

Internet-Draft             Inter-domain IM BCP                 July 2006


   [10]  Garcia-Martin, M., Bormann, C., Ott, J., Price, R., and A.
         Roach, "The Session Initiation Protocol (SIP) and Session
         Description Protocol (SDP) Static Dictionary for Signaling
         Compression (SigComp)", RFC 3485, February 2003.

   [11]  Camarillo, G., "Compressing the Session Initiation Protocol
         (SIP)", RFC 3486, February 2003.

   [12]  Hollenbeck, S., "Transport Layer Security Protocol Compression
         Methods", RFC 3749, May 2004.

   [13]  Friend, R., "Transport Layer Security (TLS) Protocol
         Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943,
         November 2004.

   [14]  Houri, A., "RTC Provisioning Requirements",
         draft-houri-speermint-rtc-provisioning-reqs-00 (work in
         progress), June 2006.

   [15]  Schulzrinne, H., "RPID: Rich Presence Extensions to the
         Presence Information Data Format  (PIDF)",
         draft-ietf-simple-rpid-10 (work in progress), December 2005.

   [16]  Schulzrinne, H., "CIPID: Contact Information in Presence
         Information Data Format", draft-ietf-simple-cipid-07 (work in
         progress), December 2005.

   [17]  Rosenberg, J., "A Data Model for Presence",
         draft-ietf-simple-presence-data-model-07 (work in progress),
         January 2006.

   [18]  Campbell, B., "The Message Session Relay Protocol",
         draft-ietf-simple-message-sessions-15 (work in progress),
         July 2006.

   [19]  Rosenberg, J., "The Session Initiation Protocol (SIP) and
         Spam", draft-ietf-sipping-spam-02 (work in progress),
         March 2006.













Aoki, et al.            Expires January 22, 2007               [Page 19]

Internet-Draft             Inter-domain IM BCP                 July 2006


Authors' Addresses

   Edwin Aoki
   AOL LLC
   360 W. Caribbean Drive
   Sunnyvale, CA  94089
   USA

   Email: aoki@aol.net


   Avshalom Houri
   IBM
   Science Park Building 18/D
   Rehovot,
   Israel

   Email: avshalom@il.ibm.com


   Orit Levin
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   USA

   Email: oritl@microsoft.com


   Tim Rang
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   USA

   Email: timrang@microsoft.com


   Michael Trommsdorff
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   USA

   Email: mtromm@microsoft.com






Aoki, et al.            Expires January 22, 2007               [Page 20]

Internet-Draft             Inter-domain IM BCP                 July 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Aoki, et al.            Expires January 22, 2007               [Page 21]