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: open on-the-phone sip:tom-pc@example.com Tom Jones 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: open mac:8asd7d7d7d sip:t-jones@example.com idle mac:8asd7d7d7d 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: ;tag=93810874 From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 63104 OPTIONS Contact: Contact: 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]