SIMPLE Working Group B. Campbell Internet-Draft J. Rosenberg Expires: April 25, 2003 dynamicsoft October 25, 2002 Instant Message Sessions in SIMPLE draft-campbell-simple-im-sessions-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 April 25, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract The SIP MESSAGE method is used to send instant messages, where each message is independent of any other message. This is often called pager-mode messaging, due to the fact that this model is similar to that of most two-way pager devices. Another model is called session- mode. In session-mode, the instant messages are part of a media session that provides ordering, a security context, and other functions. This media session is established using a SIP INVITE, just as an audio or video session would be established. This document describes a method of initiating and managing message sessions using SIP. Campbell & Rosenberg Expires April 25, 2003 [Page 1] Internet-Draft SIMPLE IM Sessions October 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation for Session-mode Messaging . . . . . . . . . . . . 3 3. Message Session Mechanisms . . . . . . . . . . . . . . . . . . 4 4. SDP Offer-Answer Exchanges for Message Sessions. . . . . . . . 5 4.1 Use of the SDP M-line . . . . . . . . . . . . . . . . . . . . 5 4.2 SDP Extensions for Connection Oriented Media . . . . . . . . . 6 4.3 Session Parameters . . . . . . . . . . . . . . . . . . . . . . 6 5. Example SDP Exchange . . . . . . . . . . . . . . . . . . . . . 6 6. Baseline Implementation Requirements . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8 Normative References . . . . . . . . . . . . . . . . . . . . . 8 Informational References . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11 Campbell & Rosenberg Expires April 25, 2003 [Page 2] Internet-Draft SIMPLE IM Sessions October 2002 1. Introduction The MESSAGE [7] extension to SIP [3] allows SIP to be used to transmit instant messages. Instant messages sent using the MESSAGE method are normally independent of each other. This approach is often called pager-mode messaging, since it follows a model similar to that used by many two-way pager devices. Pager-mode messaging makes sense for instant message exchanges where a small number of messages occur. There are also applications in which it is useful for instant messages to be associated together in some way. For example, a user may wish to join a text conference, participate in the conference for some period of time, then leave the conference. This usage is analogous to regular media sessions that are typically initiated, managed, and terminated using SIP. We commonly refer to this model as session-mode messaging. One of the primary purposes of SIP is the management of media sessions. Session-mode messaging can be thought of as a media session like any other. This document describes a method to use SIP to manage message sessions. This document does not propose an actual message session mechanism; there may any number of mechanisms that are appropriate for different applications and environments. 2. Motivation for Session-mode Messaging Message sessions offer several advantages over pager-mode messages. For message exchanges that include more than a small number of message transactions, message sessions offer a way to remove messaging load from intervening SIP proxies. For example, a minimal session setup and teardown requires one INVITE/ACK transaction, and one BYE transaction, for a total of 5 SIP messages. Normal SIP request routing allows for all but the initial INVITE transaction to bypass any intervening proxies that do not specifically request to be in the path for future requests. In the default usage, instant messages themselves are sent end-to-end, without touching intervening SIP proxies. Each pager mode message involves a complete SIP transaction, that is, a request and a response. Any pager-mode message exchange that involves more than 2 or 3 MESSAGE requests will generate more SIP requests than a minimal session initiation sequence. Since MESSAGE is typically used outside of a SIP dialog, these requests will typically traverse the entire proxy network between the endpoints. Due to network congestion concerns, the MESSAGE method has significant limitations in message size, a prohibition against Campbell & Rosenberg Expires April 25, 2003 [Page 3] Internet-Draft SIMPLE IM Sessions October 2002 overlapping requests, etc. Much of this has been required because of perceived limitations in the congestion-avoidance features of SIP itself. Work is in progress to mitigate these concerns. However, session-mode messages are always sent over a reliable, congestion-safe transport. Therefore, there are no restrictions on message sizes. There is no requirement to wait for acknowledgement, so that messages can be overlapped. Message sessions allow greater efficiency for secure message exchanges. The SIP MESSAGE request inherits the S/MIME features of SIP, allowing a message to be signed and/or encrypted. However, this approach requires public key operations for each message. With session-mode messaging, a session key can be established at the time of session initiation. This key can be used to protect each message that is part of the session. This requires only symmetric key operations, and no additional certificate exchanges are required after the initial exchange. The establishment of the session key is done using standard techniques that apply to voice and video, in addition to instant messaging. Finally, SIP devices can treat message sessions like any other media sessions. Any SIP feature that can be applied to other sorts of media sessions can equally apply to message sessions. For example, conferencing [9], third party call control [10], call transfer [11], QoS integration [12], and privacy [13] can all be applied to message sessions. Messaging sessions can also reduce the overhead in each individual message. In pager-mode, each message needs to include all of the SIP headers that are mandated by RFC 3261. [3] However, many of these headers are not needed once a context is established for exchanging messages. As a result, messaging session mechanisms can be designed with significantly less overhead. 3. Message Session Mechanisms This document does not define a specific message session mechanism. However, all message session mechanisms will need to address a common set of issues, resulting in several requirements which are discussed here. The first issue is congestion safety. Instant messages can vary significantly in size, ranging from a few bytes to many megabytes. As a result, all message session mechanisms need to be congestion safe. This issue is discussed at length in the MESSAGE method specification [7], and is the reason for the restrictions on the transport protocols used for the MESSAGE method. These Campbell & Rosenberg Expires April 25, 2003 [Page 4] Internet-Draft SIMPLE IM Sessions October 2002 considerations apply to message session mechanisms as well. Any message session mechanism MUST be congestion-safe. Most media session types are currently based on the Real Time Transport Protocol [8]. While message sessions are managed much like any other media session, there are some significant differences in the underlying transport mechanisms. RTP is designed for media types that take the form of time sequenced data, where the temporal relationship between packets is critical for proper playback. In many cases, small amounts of packet loss are acceptable, as long as the temporal relationships can be maintained. Message sessions are different, in that while message ordering is important, the time between messages typically is not. Reliable delivery of a message is much more important. Of course, there are exceptions; one can imagine a media session type that transferred text as it was typed, with typing patterns preserved at the receiving end. While this may be an interesting application, it falls outside of the class of message-oriented media session that are the subject of this document. Due to the different nature of message-oriented media sessions, and due to the network congestion concerns when sending instant message content over non-congestion controlled transports, message session mechanisms MUST use a reliable, congestion-safe network transport, such as TCP or SCTP. Additionally, if multiple sessions exist between the same pair of devices, those devices SHOULD share the same connection across all of the sessions. 4. SDP Offer-Answer Exchanges for Message Sessions. This specification describes the usage of SDP for the establishment of instant messaging sessions. This approach is used by all message sessions mechanisms. 4.1 Use of the SDP M-line The SDP m-line takes the following form: m= For non-RTP media sessions, The media field specifies the top level MIME media type for the session. For message sessions, the media field MUST have the value of "message". The proto field MUST designate the message session mechanism and transport protocol, separated by a "/" character. For example, "cpim/tcp". The meaning of any entries in the format list MUST be described in the specification for the message session mechanism. If said mechanism Campbell & Rosenberg Expires April 25, 2003 [Page 5] Internet-Draft SIMPLE IM Sessions October 2002 supports multiple payload types, acceptable types SHOULD be described in the format list. The following example illustrates an m-line for a CPIM message session, where the endpoint is willing to accept payloads of plain text or HTML m=message 49232 cpim/tcp text/plain text/html 4.2 SDP Extensions for Connection Oriented Media SDP is typically used with UDP based media protocols. In particular, base SDP does not provide support for negotiation of a two-way media session where a single connection is used in both directions, which is expected to be the normal model for message sessions. Therefore, endpoints wishing to establish message sessions MUST follow the COMEDIA [2] extensions to SDP, both for the negotiation of connection parameters, and for the establishment and management of the connections themselves. 4.3 Session Parameters Any additional session parameters that are to be negotiated in the SDP exchange MUST be communicated in the form of attribute lines. Such parameters specific to a particular message session mechanism MUST be defined in the specification of the mechanism 5. Example SDP Exchange Endpoint A wishes to invite Endpoint B to a message session using the CPIM session mechanism. [4] A offers the following session description containing the following lines: c=IN IP4 alice.example.com m=message 7394 cpim/tcp text/plain a=direction:both a=uri:im:2s93i9@alice.example.com Endpoint B chooses to participate, but prefers to initiate the connection. B answers with a media description including the following lines: c=IN IP4 bob.example.com m=message 8493 cpim/tcp text/plain text/html a=direction:active a=uri:im:849ro3@bob.example.com Campbell & Rosenberg Expires April 25, 2003 [Page 6] Internet-Draft SIMPLE IM Sessions October 2002 B then opens a TCP connection to alice.example.com:7394. A and B can begin to exchange instant messages on this connection using the CPIM message session mechanism. 6. Baseline Implementation Requirements To help ensure some degree of interoperability between endpoints supporting message sessions, any endpoint that supports message session as described in this document MUST support the cpim message session mechanism [4] over TCP. The CPIM session mechanism is a minimalist approach that is fairly inexpensive to support. Such endpoints MAY support any number of other message session mechanisms. 7. Security Considerations Instant messages can contain very sensitive information. As a result, as specified in RFC 2779 [5], instant messaging protocols need to provide for encryption, integrity and authentication of instant messages. Any IM session mechanism MUST satisfy those requirements. Any protocol that is used as a messaging session transport protocol MUST provide a means for encryption, authentication, and message integrity of the message. This mechanism MUST operate even in the face of intermediaries in the transport protocol. That is, it MUST provide a means of end-to-end security functions. It is RECOMMENDED that any such mechanism make use of session keys that can be established through SIP, such as those created by MIKEY [6]. Encryption, authentication and message integrity for messaging sessions can also be provided through the use of secure transport protocols, such as TLS. It is RECOMMENDED that message session mechanisms make use of TLS, and that implementations SHOULD support it. The usage of SIP to establish an instant messaging session introduces additional security considerations. Because SIP can be used to establish a session key for the messaging sessions, the SIP exchange itself needs to provide proper authentication in order for the instant messages themselves to be authenticated. Authentication of SIP users is provided with S/MIME, and therefore, implementations MUST support S/MIME. 8. IANA Considerations This document does not require IANA registrations. Campbell & Rosenberg Expires April 25, 2003 [Page 7] Internet-Draft SIMPLE IM Sessions October 2002 9. Open Issues There is still ongoing discussion about the m-line format. An alternative proposal is for the protocol field to only designate the network transport protocol, and the first entry in the format list designate the session mechanism to be used on that protocol. This approach may make software layering easier, where a connection management layer need not be aware of the message session mechanism used. There is still controversy over the security considerations. In particular, whether this draft should strongly the use of session keys negotiated in the SDP exchange, or leave that decision to the designers of any particular message session mechansim. The final version of this document needs more examples, and may require further formal definitions. 10. Contributors The following people contributed substantially to this document: Rohan Mahy Allison Mankin Jon Peterson Brian Rosen Jonathan Rosenberg Robert Sparks Dean Willis Normative References [1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [2] Yon, D., "Connection-Oriented Media Transport in SDP", draft- ietf-mmusic-sdp-comedia-04.txt (work in progress), July 2002. [3] 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. [4] Campbell, B., "Instant Message Sessions using the CPIM Message Format.", draft-campbell-simple-cpimmsg-sessions-00.txt (work in progress), October 2002. [5] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000. Campbell & Rosenberg Expires April 25, 2003 [Page 8] Internet-Draft SIMPLE IM Sessions October 2002 [6] Arkko, J., "MIKEY: Multimedia Internet KEYing", draft-ietf-msec- mikey-04 (work in progress), August 2002. Informational References [7] Campbell, B. and J. Rosenberg, "Session Initiation Protocol Extension for Instant Messaging", draft-ietf-sip-message-07 (work in progress), September 2002. [8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [9] Rosenberg, J. and H. Schulzrinne, "Models for Multi Party Conferencing in SIP", draft-ietf-sipping-conferencing-models-01 (work in progress), July 2002. [10] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo, "Best Current Practices for Third Party Call Control in the Session Initiation Protocol", draft-ietf-sipping-3pcc-02 (work in progress), June 2002. [11] Sparks, R., "SIP Call Control - Transfer", draft-ietf-sip-cc- transfer-05 (work in progress), July 2001. [12] Camarillo, G., Marshall, W. and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002. [13] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", draft-peterson-sip-privacy-longterm-00 (work in progress), March 2002. Authors' Addresses Ben Campbell dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 EMail: bcampbell@dynamicsoft.com Campbell & Rosenberg Expires April 25, 2003 [Page 9] Internet-Draft SIMPLE IM Sessions October 2002 Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 EMail: jdrosen@dynamicsoft.com Campbell & Rosenberg Expires April 25, 2003 [Page 10] Internet-Draft SIMPLE IM Sessions October 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Campbell & Rosenberg Expires April 25, 2003 [Page 11]