SIMPLE Working Group B. Campbell Internet-Draft J. Rosenberg Expires: April 25, 2003 R. Sparks dynamicsoft P. Kyzivat Cisco Systems October 25, 2002 Instant Message Sessions in SIMPLE draft-campbell-simple-im-sessions-01 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. Campbell, et al. Expires April 25, 2003 [Page 1] Internet-Draft SIMPLE IM Sessions October 2002 This document describes a The Message Session Relay Protocol (MSRP), a mechanism for transmitting session-mode messages with minimal relay support. Additionally, this document describes using the SDP offer/ answer model to initiate such sessions. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation for Session-mode Messaging . . . . . . . . . . 4 3. Scope of this Document . . . . . . . . . . . . . . . . . . 5 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5 5. SDP Offer-Answer Exchanges for MSRP Sessions. . . . . . . 8 5.1 Use of the SDP M-line . . . . . . . . . . . . . . . . . . 8 5.2 URI Negotiations . . . . . . . . . . . . . . . . . . . . . 9 5.3 Example SDP Exchange . . . . . . . . . . . . . . . . . . . 9 5.4 Session Hosting . . . . . . . . . . . . . . . . . . . . . 10 6. The Message Session Relay Protocol . . . . . . . . . . . . 11 6.1 MSRP messages . . . . . . . . . . . . . . . . . . . . . . 11 6.2 MSRP Transactions . . . . . . . . . . . . . . . . . . . . 12 6.3 MSRP Sessions . . . . . . . . . . . . . . . . . . . . . . 13 6.4 Initiating an MSRP session . . . . . . . . . . . . . . . . 13 6.5 Handling VISIT requests . . . . . . . . . . . . . . . . . 16 6.6 Sending Instant Messages on a Session . . . . . . . . . . 17 6.6.1 Ending a Session . . . . . . . . . . . . . . . . . . . . . 18 6.7 Managing Session State and Connections . . . . . . . . . . 18 6.8 MSRP Relays . . . . . . . . . . . . . . . . . . . . . . . 19 6.8.1 Establishing Session State at a Relay . . . . . . . . . . 19 6.8.2 Removing Session State from a relay . . . . . . . . . . . 21 6.8.3 Sending IMs across an MSRP relay . . . . . . . . . . . . . 21 6.8.4 Relay Pairs . . . . . . . . . . . . . . . . . . . . . . . 21 6.9 Method Descriptions . . . . . . . . . . . . . . . . . . . 22 6.9.1 BIND . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.9.2 LEAVE . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.9.3 RELEASE . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.9.4 SEND . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.9.5 VISIT . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.10 Response Code Descriptions . . . . . . . . . . . . . . . . 23 6.10.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.10.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.10.3 401 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.10.4 403 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.10.5 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.10.6 500 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.10.7 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.11 Header Field Descriptions . . . . . . . . . . . . . . . . 24 6.12 T-URI . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.13 TR-ID . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.14 CAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Campbell, et al. Expires April 25, 2003 [Page 2] Internet-Draft SIMPLE IM Sessions October 2002 6.15 SChal . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.16 Content-Type . . . . . . . . . . . . . . . . . . . . . . . 25 6.17 L-URI . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.18 R-URI . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.1 No Relay . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.2 Single Relay . . . . . . . . . . . . . . . . . . . . . . . 28 7.3 Two Relays . . . . . . . . . . . . . . . . . . . . . . . . 31 8. Changes introduced in 01 version . . . . . . . . . . . . . 34 9. Security Considerations . . . . . . . . . . . . . . . . . 34 9.1 Sensitivity of the Remote URI . . . . . . . . . . . . . . 34 9.2 End to End Protection of IMs . . . . . . . . . . . . . . . 35 9.3 CPIM compatibility . . . . . . . . . . . . . . . . . . . . 35 10. IANA Considerations . . . . . . . . . . . . . . . . . . . 35 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 36 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . 36 Normative References . . . . . . . . . . . . . . . . . . . 36 Informational References . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 37 Intellectual Property and Copyright Statements . . . . . . 39 Campbell, et al. Expires April 25, 2003 [Page 3] Internet-Draft SIMPLE IM Sessions October 2002 1. Introduction The MESSAGE [7] extension to SIP [2] 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. This document describes the motivations for session-mode messaging, the Message Session Relay Protocol, and the use of the SDP offer/ answer mechanism for initiating MSRP session. 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. Session-mode messages never cross the SIP proxies themselves, unless proxies also act as message relays. 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 normally used outside of a SIP dialog, these requests will typically traverse the entire proxy network between the endpoints. Campbell, et al. Expires April 25, 2003 [Page 4] Internet-Draft SIMPLE IM Sessions October 2002 Due to network congestion concerns, the MESSAGE method has significant limitations in message size, a prohibition against 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 message transactions 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 [2]. 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. Scope of this Document This document describes the use of MSRP between endpoints, or via one or two relays, where endpoints have advance knowledge of the relays. It does not provide a mechanism for endpoints to determine whether a relay is needed, or for endpoints to discover the presence of relays. 4. Protocol Overview The Message Session Relay Protocol (MSRP) provides a mechanism for transporting session-mode messages between endpoints. MSRP also Campbell, et al. Expires April 25, 2003 [Page 5] Internet-Draft SIMPLE IM Sessions October 2002 contains primitives to allow the use of one or two relay devices. MSRP uses connection oriented, reliable network transport protocols only. It is intrinsically NAT and firewall friendly, and allows network connections to be shared across multiple message sessions. MSRP allows participants to positively associate message sessions with specific connections, and does not depend upon connection source address, which may be obscured by NATs. MSRP uses the following primitives: SEND: Used to actually send message content from one endpoint to another. VISIT (LEAVE): Used by an endpoint to establish a session association to the opposite endpoint, or to a relay that was selected by the opposite endpoint. "LEAVE" is used to remove the association. BIND(RELEASE): Used by an endpoint to establish a session at a relay, and allow the opposite endpoint to visit that relay. "RELEASE" is used to remove the session. The simplest use case for MSRP is a session that goes directly between endpoints, with no intermediaries involved. Assume A is an endpoint that wishes to establish a message session, and B is the endpoint invited by A. A invites B to participate in a message session by sending B two URIs. The first URI represents a the destination to which B should send messages. The second represents a identifier that B can use to connect to , or visit, A, and to which A will send messages. Both URIs are temporary, and must not duplicate the local or remote URIs used in any other active sessions. B "visits" A by connecting to A and sending a VISIT request containing the URI that A provided it. This establishes state at A that associates the connection from B with the URI. B then responds to the invitation, informing A that B accepts the URI that A assigned to it. A can now send messages to B using the SEND method with B's URI as the target. Likewise, B can invoke the SEND method targeting A's URI. When either party wishes to end the session, it informs the other party with a SIP BYE. B may end the message session by sending a "LEAVE" request, telling A that B will no longer use the URI. If no other sessions were using the network connection, B closes the connection. alternately, A can end the session by simply invalidating state associating the URIs and connections, and dropping the connection if no more sessions are using it. Campbell, et al. Expires April 25, 2003 [Page 6] Internet-Draft SIMPLE IM Sessions October 2002 This creates a race condition between A and B when closing a session. It seems that this does not really cause a problem, in that if an attempt to close a session fails because the other party closed it first, the desired outcome is still achieved. The end to end case looks something like the following. (Note that the example shows a logical flow only; syntax will come later in this document.) A->B (SDP): offer (i-am:a@a, you-be:b@a) B->A (MSRP): VISIT (b@a) A->B (MSRP): 200 OK B->A (SDP): answer(i-am b@a) A->B (MSRP): SEND (b@a) B->A (MSRP): 200 OK B->A (MSRP): SEND (a@a) A->B (MSRP): 200 OK B->A (MSRP): LEAVE (b@a) A->B (MSRP): 200 OK A slightly more complicated case involves a single relay, known about in advanced by one of the parties. The endpoint with the pre-existing relationship with the relay uses the BIND method to establish session state in the relay. The relay returns a pair of temporary URIs, one for local use, and one to offer to the remote endpoint. For endpoints A and B, and relay R, the flow would look like the following: A->R: MSRP: BIND R->A: MSRP: 200 OK (local:a@r, remote:z@r) A->B (SDP): offer (i-am:a@r, you-be:z@r) B->R (MSRP): VISIT (z@r) R->B (MSRP): 200 OK Campbell, et al. Expires April 25, 2003 [Page 7] Internet-Draft SIMPLE IM Sessions October 2002 B->A (SDP): answer(i-am:b@r) A->R (MSRP): SEND (z@r) R->B (MSRP): SEND (z@r) B->R (MSRP): 200 OK R->A (MSRP): 200 OK B->R (MSRP): SEND (a@r) R->A (MSRP): SEND (a@r) A->R (MSRP): 200 OK R->B (MSRP): 200 OK A->R (MSRP): RELEASE(a@r) B->R (MSRP): LEAVE(z@r) 5. SDP Offer-Answer Exchanges for MSRP Sessions. MSRP sessions will typically be initiated using the Session Description Protocol (SDP) [1] offer-answer mechanism, carried in SIP [2] or any other protocol supporting it. 5.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 MSRP 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 MSRP, left part of this value MUST be "msrp". For example, "msrp/tcp" for MSRP over TCP, "msrp/tls" for MSRP over TLS, etc. The format list MUST indicate the MIME content-types that the endpoint is willing to accept in the payload of SEND requests. If any of the allowed types are compound in nature, that is, they allow one or more arbitrary MIME body parts to be imbedded within them, then the format list MUST include the content-types allowed for the imbedded parts. Campbell, et al. Expires April 25, 2003 [Page 8] Internet-Draft SIMPLE IM Sessions October 2002 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, which may appear at the top level of the payload, or may be imbedded inside a message/cpim body part. m=message 49232 msrp/tcp message/cpim text/plain text/html 5.2 URI Negotiations MSRP offer/answer negotiations require the transmissions of one or two URIs. The first identifies the party sending the offer or answer. the second offers a temporary URI for the opposite party to use to connect to the sending party, or to a relay operating on behalf of the sending party. These URIs are respectively designated as "i-am" and "you-be". The i-am URI MUST be present in each SDP offer and answer. The you-be URI MUST be present if the party sending the offer or answer is proposing that its peer connect to the sending party or such a relay, and MUST NOT be present otherwise. The URI parameters are represented in SDP as a combination of domain part in the c-line address parameter and the user parts in a-line attributes. The "msrp:" scheme is implied, and MUST not be present in the a-line. For example, the following indicates an i-am URI of "msrp:2s93i@example.com" and a you-be URI of "msrp:8djese@example.com c=IN IP4 example.com m=message 7394 msrp/tcp text/plain a=i-am:2s93i a=you-be:8djese This approach implies that the i-am and you-b URIs will always share the same domain part. Is there any scenario where this would not be desired? Both the i-am and the you-b URIs MUST be temporary URIs assigned just for this particular session. They MUST NOT duplicate any URI in use in any other session hosted by the endpoint. Further, since the peer endpoint may use the you-be URI to identify itself when connecting, it should be hard to guess, and protected from eavesdroppers. This will be discussed in more detail in the Security Consideration section. 5.3 Example SDP Exchange Endpoint A wishes to invite Endpoint B to a MRSP session. A offers the following session description containing the following lines: Campbell, et al. Expires April 25, 2003 [Page 9] Internet-Draft SIMPLE IM Sessions October 2002 c=IN IP4 alice.example.com m=message 7394 msrp/tcp message/cpim text/plain a=i-am:2s93i9 a=you-be:8r90ew Endpoint B chooses to participate, opens a TCP connection to alice.example.com:7394, and successfully performs a VISIT transaction passing the URI of "msrp:8r90ew@alice.example.com". B indicates that it has accomplished this by answering with: c=IN IP4 alice.example.com m=message 7394 msrp/tcp message/cpim text/plain text/html a=i-am:8r90ew A may now send IMs to B by executing SEND transactions targeted to "msrp:8r90ew@alice.example.com", and B may SEND to "msrp:2s93i9@alice.example.com" 5.4 Session Hosting MSRP requires the use of connection oriented transport protocols. Part of the offer answer process involves determining which endpoint will "host" the session, that is, which will listen for the network connection. When a relay is involved, the hosting endpoint is the one that initializes session state at the relay with a BIND request. An endpoint indicates its desire to host a session by including a "you-be" URI in its SDP. Typically, the offerer will also be the host. If the offerer is in a position to accept a connection, or has access to a relay that can accept a connection on its behalf, then it SHOULD offer to host the session. If the offerer does in fact include a you-be URI, the answerer SHOULD accept the offerer's desire to host by visiting the URI provided, and, if successful, returning the offered you-be URI in the i-am URI of the answer. There may be situations where the endpoint inviting a peer to participate in an MDRP cannot, or does not wish to, host the connection. For example that endpoint may be behind a NAT or firewall that prevents inbound connections. In this case, the initiating endpoint MAY send an SDP offer with no you-be URI. If the answerer receives such an offer, it SHOULD act as session host, and return a you-be URI in the answer. Of course, if neither party is able and willing to host the session, then they cannot participate in an MSRP session. This probably requires the offerer to accept the offered you-be URI in its ACK. However, we are trying to specify this in terms of Campbell, et al. Expires April 25, 2003 [Page 10] Internet-Draft SIMPLE IM Sessions October 2002 the SDP offer/answer model only, and not depend on SIP's three phase INVITE. We could simply have the inviting party not include an offer, but in this case the invitee is likely to assume an RTP session is desired, unless some other mechanism is invoked to communicate the desired session type. There may be scenarios where the invitee is required by policy to use a particular relay, and by implication, must act as host on all session, even if the inviter included the you-be URI in the offer. The invitee may decline to accept the inviter's proposal to host by returning a different you-be URI, and an i-am URI that does not match the you-be URI of the offer. In this situation, the inviter SHOULD allow the invitee to host. Finally, there may be scenarios where both parties are required by policy to use different relays. This is similar to the previous case where the invitee overrides the inviter's proposal to host, except that the inviter does not return the you-be URI that the invitee proposed as its i-am URI in the ACK request. Each endpoint BINDs with its relay, and neither performs a VISIT. When one of the endpoints attempts a SEND operation, its relay will attempt to connect to the peer's relay. This will be described in more detail in the Relay Behavior section. 6. The Message Session Relay Protocol The Message Session Relay Protocol (MSRP) is a text based, messaging oriented protocol for the transfer of instant messages in the context of a session. MSRP uses the UTF8 character set. MSRP messages MUST be sent over reliable, congestion-controlled, connection-oriented transport protocols, such as TCP. 6.1 MSRP messages MSRP messages are either requests or responses. Requests and responses are distinguished from one another by the first line. The first line of a Request takes the form of the request-start entry below. Likewise, the first line of a response takes the form of response-start. The syntax for an MSRP message is as follows: Campbell, et al. Expires April 25, 2003 [Page 11] Internet-Draft SIMPLE IM Sessions October 2002 msrp-message = request-start/response-start *(header CRLF) [CRLF body] request-start = "MSRP" SP length SP Method CRLF response-start= "MSRP" SP length SP Status-Code SP Reason CRLF length = 1*DIGIT ; the length of the message Method = SEND / BIND / RELEASE / VISIT /LEAVE header = Client-Authenticate / Server-Challenge / Transaction-ID / Target-URI/ Content-Type Local-URI / Remote-URI Status-Code = 200 ;Success / 400 ;Bad Request / 401 ;Authentication Required / 403 ;Forbidden / 481 ;No session / 500 ;Cannot Deliver / 506 ;duplicate session Reason = token ; Human readable text describing status msrp-uri= msrp HCOLON user "@" domain Client-Authenticate = "CAuth" HCOLON username "," nonce "," digest-response Server-Challenge = "SChal" HCOLON nonce Transaction-ID = "TR-ID" HCOLON token Content-Type = "Content-Type" HCOLON quoted-string Target-URI = "T-URI" HCOLON msrp-uri Local-URI = "L-URI" HCOLON msrp-uri Remote-URI = "R-URI" HCOLON msrp-uri This syntax is not complete. In particular, we will need more work on Server-Challenge and Client-Authenticate header fields. All requests and responses MUST contain at least a T-URI and a TR-ID header field. Messages MAY contain other fields, depending on the method or response code. 6.2 MSRP Transactions An MSRP transaction consists of exactly one request and one response. A response matches a transaction if it share the same TR-ID value, and if the T-URI value in the response matches a the URI for the endpoint that sent the request. BIND and VISIT transactions are always hop by hop. However, SEND transactions are end to end, meaning that under normal circumstances the response is sent by the peer endpoint, even if there are one or more intervening relays. Campbell, et al. Expires April 25, 2003 [Page 12] Internet-Draft SIMPLE IM Sessions October 2002 Endpoints MUST select TR-ID header field values in requests so that they are not repeated by the same endpoint in scope of the given session. The TR-ID space of each endpoint is independent of that of its peer. Endpoints MUST NOT infer any semantics from the TR-ID header field beyond what is stated above. In particular, TR-ID values are not required to follow any sequence. MSRP Transactions complete when a response is received, or after a timeout interval expires with no response. Endpoints MUST treat such timeouts in exactly the same way they would treat a 500 response. The size of the timeout interval is a matter of local policy. 6.3 MSRP Sessions AN MSRP session is a context in which a series of IMs are sent, using SEND requests. A session has two endpoints (a host and a visitor) and may have one or more relays. A session is identified by the tuple of the host and visitor URIs. Note that an endpoint that is involved in multiple sessions will likely have completely different URIs in one session than in another. 6.4 Initiating an MSRP session When an endpoint wishes to engage a peer endpoint in a message session, it invites the peer to communicate using an SDP offer, carried over SIP or some other protocol supporting the SDP offer/ answer model. For the purpose of this document, we will refer to the endpoint choosing to initiate communication as the inviter, and the peer being invited as the invitee. The inviter SHOULD act as host for the session. An endpoint is said to host a session if one of two conditions are true. The host either directly listens for a connection from the peer endpoint, and maintains session state itself, or it initialized session state at a relay that will listen for a connection from the peer, using a BIND request. The peer that is not the host is designated as the visitor. The inviter MAY allow the invitee to act as host, if it is prevented from accepting connections by network topology or policy, and is not able to bind to a relay to act on its behalf. If the inviter chooses to host the session directly, that is without using a relay, it MUST perform the following steps: 1. Construct a local and visitor MSRP URI . These MUST share the same domain part, which MUST be resolvable to the inviter. The user parts MUST be distinct from each other. The user part of each URI SHOULD be temporary, SHOULD be hard to guess, and MUST not duplicate the any URI used in other active sessions hosted by Campbell, et al. Expires April 25, 2003 [Page 13] Internet-Draft SIMPLE IM Sessions October 2002 the inviter. 2. Listen for a connection from the peer. 3. Construct an SDP offer as described in Section 5, including the list of allowed IM payload formats in the format list. The inviter maps the local URI to the i-am attribute, and the visitor URI to the you-be attribute, as described in Section 5.2 4. Send the SDP offer using the normal processing for the signaling protocol. If the inviter chooses to ask the invitee to host the session, it MUST perform the following steps instead: 1. Construct a host URI as described above. It does not construct a visitor URI. Since the inviter will not accept network connections, it is not important that the URI resolve to the inviter. 2. Construct an SDP offer as described above. The M-line port value can be any non-zero value, since it will not actually be used. 3. Send the offer using normal processing for the signaling protocol. When the invitee receives the SDP offer and chooses to participate in the session, it must choose whether of act as the host or the visitor. A you-be attribute in the offer indicates that the inviter wishes to host, in which case the invitee SHOULD act as the visitor. If the invitee chooses to participate as a visitor, it MUST perform the following steps: 1. Connect to the host address and port from the C-line and M-line in the SDP offer, using the transport protocol from the M-line. 2. Construct a VISIT request, which MUST contain the following information: 1. A T-URI header field containing the visitor URI. 2. A TR-ID header field containing a unique transaction ID. 3. A size field containing the overall size of the message. 3. Send the request and wait for a response Campbell, et al. Expires April 25, 2003 [Page 14] Internet-Draft SIMPLE IM Sessions October 2002 4. If the transaction succeeds, send a SDP answer via the signaling protocol, according to the following rules: 1. The C-line is copied unmodified from the offer. 2. The M-Line contains the port from the original offer and protocol fields from the original offer, and a format list describing the SEND payload media types that the invitee is willing to accept. 3. No you-be attribute 4. A i-am attribute containing the user part of the visitor URI, that is, the same value that was in the you-be attribute on the offer. The invitee MAY choose to attempt to host the session under some circumstances. If the SDP offer did not contain a you-be attribute, the invitee MUST host the session, otherwise it is not possible to participate in the session at all. If the offer did contain a you-be attribute, but the attempt to connect to the host failed, the invitee MAY attempt to host the session. Otherwise, the invitee MAY attempt to take over as host because of a local policy requiring it. If the invitee chooses to host the session, it MUST perform the following steps: 1. Construct a local and visitor MSRP URI . These MUST share the same domain part, which MUST be resolvable to the invitee. The user parts MUST be distinct from each other. Both URI SHOULD be temporary, SHOULD be hard to guess, and MUST not duplicate URIs used in any active sessions hosted by the invitee. 2. Listen for a connection from the peer. 3. Construct an SDP answer as described in Section 5, including the list of allowed IM payload formats in the format list. The invitee maps the local URI to the i-am attribute, and the visitor URI to the you-be attribute, as described in Section 5.2 4. Send the SDP offer using the normal processing for the signaling protocol. When the inviter receives the SDP answer, it must determine who will continue to host the session. If the offer contained a you-be attribute and the answer did not, the inviter MUST continue host the session. If the offer did not contain a you-be attribute, and the answer did, then the inviter MUST allow the invitee to host the Campbell, et al. Expires April 25, 2003 [Page 15] Internet-Draft SIMPLE IM Sessions October 2002 session. If both the offer and the answer contained you-be attributes, this indicates that the invitee is attempting to become host. The inviter SHOULD allow the inviter to continue as host. If the inviter chooses to allow the invitee to host the session, it MUST send an acknowledgment of the SDP answer. If the inviter chooses to host in spite of the invitee's attemt to take over, the acknowlegement must repeat the i-am attribute from the original offer. If the inviter chooses not to host, it must perform the following steps: 1. Release any resources it acquired in expectation of hosting the session, if any. 2. Connect to the host address and port from the C-line and M-line in the SDP answer, using the transport protocol from the M-line. 3. Construct a VISIT request, which MUST contain the following information: 1. A T-URI header field containing the visitor URI from the SDP answer. 2. A TR-ID header field containing a randomly selected initial transaction ID. 3. A size field containing the overall size of the message. 4. Send the request and wait for a response 5. If the VISIT succeeds, acknowledge the answer via the signaling protocol. If either the connection attempt or the VISIT transaction fail, acknowledge the answer, then initiate the tear-down of the request using the signaling protocol. 6.5 Handling VISIT requests An MSRP endpoint that is hosting a session will receive a VISIT request from the visiting endpoint. When an endpoint receives a VISIT request, it MUST perform the following procedures: 1. Check if state exists for a session using a visitor URI that matches the T-URI of the VISIT request. If so, and no previous VISIT request for that URI has occurred, then return a 200 response, and save state designating the connection on which the Campbell, et al. Expires April 25, 2003 [Page 16] Internet-Draft SIMPLE IM Sessions October 2002 request was received as the visitor leg of the session. 2. If the session exists, but a VISIT request has already been received for it, return a 506 response, and do not change session state in any way. 3. If no matching session exists, return a 481 request, and do not change session state in any way. 6.6 Sending Instant Messages on a Session Once a MSRP session has been established, either endpoint may send instant messages to its peer using the SEND method. When an endpoint wishes to do so, it MUST construct a SEND request according to the following process: 1. Set the T-URI header field to the peer URI. (If the sender is the host, it used the visitor URI, and vice versa.) 2. Insert the message payload in the body, and the media type in the Content-Type header field. The media type MUST match one of the types in the format list in the SDP provided by the peer. 3. Set the TR-ID header field to a unique value 4. Send the request on the connection associated with the session. 5. If a 200 response code is received, the transaction was successful. 6. If a 500 response code is received, the transaction failed, but may possibly be successful if retried. The endpoint MAY retry the request with a new TR-ID header field value. If the endpoint receives 500 responses more than a threshold number of times in a row, it should assume the session has failed, and initiate teardown via the signaling protocol. The threshold value is a matter of local policy. 7. If any other response code is received, the endpoint SHOULD assume the session has failed, and initiate teardown. When an endpoint receives a SEND request, it MUST perform the following steps. 1. Verify that the T-URI header field value matches the local URI for an existing session. Campbell, et al. Expires April 25, 2003 [Page 17] Internet-Draft SIMPLE IM Sessions October 2002 2. If it does, render the message to the end user, and return a 200 response. The definition of "render" is a matter of local policy. 3. If it does not match an existing session, return a 481 response. 6.6.1 Ending a Session When either endpoint in an MSRP session wishes to end the session, it first signals its intent using the normal processing for the signaling protocol. For example, in SIP, it would send a BYE request to the peer. After agreeing to end the session, each endpoint MUST release any resources acquired as part of the session. The process for this differs depending on whether the endpoint is the host or the visitor. The host MUST destroy local state for the session. This involves completely removing the state entry for this session, invalidating both the local and remote URIs. If the host is using an MSRP relay, it MUST send a RELEASE request to the relay. It MUST send the RELEASE on the same connection used for the BIND. The RELEASE MUST include the local URI in the T-URI header field. The visitor MUST send a LEAVE request on the same connection on which it sent the original VISIT. The LEAVE request MUST include the visitor URI in the T-URI header field. The visitor MUST then invalidate any local state for the session. This approach creates a race condition in that both the RELEASE and LEAVE requests cause the session state to be invalidated at the host. Whichever of these occurs second will receive a 481 response. We may wish to consider if both of these methods are necessary. Is it sufficient to leave state cleanup entirely to the host? 6.7 Managing Session State and Connections A MSRP session is represented by state at the host device. As mention previously, session state is identified by the tuple formed by the local and remote URIs. And active session also has a connection associated with each of these URIs. The connection associated with the remote URI is known as the visiting connection. The connection associated with the local URI is known as the host connection. Note that when the session state is hosted directly by an endpoint, the host connection may not involve a physical network connection; rather it is a logical connection the device maintains with itself. Campbell, et al. Expires April 25, 2003 [Page 18] Internet-Draft SIMPLE IM Sessions October 2002 A given network connection may be associated with more than one session. In fact, when the session state is hosted by a relay, it is entirely possible for a single connection to be the host connection for one session, and the visiting connection for another. When session state is destroyed for any reason, the hosting device SHOULD check to see if each connection is currently associated with any other sessions. If not, the device SHOULD drop the connection. If a connection fails for any reason, the session hosting device MUST invalidate the session state. This is true regardless of whether the dropped connection is the host or visiting connection. Once a connection is dropped, the associated session state MUST NOT be reused. If the endpoints wish to continue to communicate after a connection failure, they must initiate a new session. 6.8 MSRP Relays 6.8.1 Establishing Session State at a Relay An endpoint that wishes to host a MSRP session MAY do so by initiating session state at a MSRP relay, rather than hosting directly. An endpoint may wish to do this because network topology or local policy prevents a peer from connecting directly to the endpoint. The use of a relay should not be the default case, that is, a hosting endpoint that is not prevented from doing so by topology or policy SHOULD host the session directly. In order to use a relay, an MSRP endpoint MUST have knowledge of that endpoints existence and location. We previously mentioned how an endpoint wishing to host a MSRP session constructs a local and remote URI. When using a relay, the endpoint delegates that responsibility to the relay. To establish session state at a relay, the endpoint MUST perform the following steps: 1. Construct a BIND request with a T-URI that refers to the relay. 2. Open a network connection to the relay at the relays address and the well-known port for MSRP relays, or at another port if so configured. 3. Send the BIND request on the connection. 4. Respond to any authentication request from the relay. 5. If the response has a 200 status code, use the URI in the L-URI Campbell, et al. Expires April 25, 2003 [Page 19] Internet-Draft SIMPLE IM Sessions October 2002 header field as the local URI, and the URI in the R-URI header field as the remote URI. The endpoint uses these URIs in exactly the same manner as it had constructed them itself. A MSRP relay listens for connections to its well-known port at all times. When it receives a BIND request, it SHOULD authenticate the request, either using digest-authentication, TLS authentication, or some other authentication mechanism. If authentication succeeds, the relay performs the following steps: 1. Verify the client is authorized to BIND to this relay. If not, return a 403 response and make no state change. 2. If the client is authorized, construct a local and remote MSRP URI. The domain part of both URIs MUST be the same, and MUST resolve to the relay. The URIs SHOULD be temporary, and hard to guess. The URIs MUST not duplicate URIs used in any active sessions hosted by the relay. If the relay wishes the visiting endpoint to connect over a point other than the MSRP relay well-know port, it MAY add the port number to visitor URI. 3. Create state for the session. The relay MUST associate the connection on which it received the BIND request with the local URI. 4. Return a 200 response, with the T-URI header field value copied from the request, the local URI in the L-URI header field, and the remote URI in the R-URI field. When an MSRP relay receives a VISIT request, it MUST perform the following steps: 1. Check the T-URI header field value to see it matches the remote URI for an existing session state entry. 2. If not, return a 481 response and make no state changes 3. If it matches, but a connection has already been associated with the remote URI, then return a 506 response and make no state changes. 4. If it matches, and no connection has been associated with the remote URI, then the VISIT succeeds. The relay associates the connection on it received the VISIT request with the remote URI for the session, and returns a 200 response. Campbell, et al. Expires April 25, 2003 [Page 20] Internet-Draft SIMPLE IM Sessions October 2002 6.8.2 Removing Session State from a relay An MSRP relay SHOULD remove state for a session when any of the following conditions occur: o The host performs sends an UNBIND request with a T-URI that matches the local-URI associated with the session. o The visitor sends a LEAVE request with a T-URI that matches the remote-URI associated with the session. o Either the host or visitor network connection is reset by the peer, or fails for any reason. 6.8.3 Sending IMs across an MSRP relay Once a session is established at a relay, the host and visitor may exchange IMs by sending SEND requests. Under normal circumstances, the relay does not respond to SEND requests in any way. If the T-URI of the SEND request matches the peer URI for the session, the relay MUST forward the request unchanged. Likewise, if the relay receives a response, where the T-URI matches the peer URI for the session, it MUST forward the request unchanged. If the relay receives a SEND request that does not match the opposite URI of the session, the relay MUST return a 404 response. If a SEND request arrives on a connection that has no associated sessions, the relay MUST return a 481 response. Note that this may occur in a situation where the relay has removed session state because of a failure in the peer connection. 6.8.4 Relay Pairs In rare circumstances, two relays may be required in a session. For example, two endpoints may exist in separate administrative domains, where each domain's policy insist that all sessions must cross that domain's relay. In this scenario, each endpoint BINDs with its own endpoint, and believes itself to be the session host. Neither endpoint sends a VISIT request. For a relay to support this scenario, it must implement some special behavior under the following circumstances: o A session is in a half-complete state; that is, the relay has returned a local and remote URI in a response to a BIND request, but has not observed a VISIT request using the remote URI. Campbell, et al. Expires April 25, 2003 [Page 21] Internet-Draft SIMPLE IM Sessions October 2002 o A SEND request arrives on a connection that is associated with at least one such "half complete" sessions, and the T-URI refers to a domain for which the relay is not responsible. Under these circumstances, the relay SHOULD attempt to open a connection with a device responsible for the domain in the T-URI, and forward the request. If a connection already exists, it SHOULD reuse the connection. Likewise, if a relay receives a SEND request on a connection not associated with a session, and the T-URI is associated with an existing connection, it SHOULD forward the request on that connection. If there is no such associated connection, it SHOULD return a 500 response. This scenario will often result in two effectively one-way connections between a pair of relays. Additionally, if one of the relays is behind a NAT, this scenario may fail. We believe this is acceptable for the two relay case, which should be fairly rare. 6.9 Method Descriptions This section summarizes the purpose of each MSRP method. All MSRP requests MUST contain the T-URI and TR-ID header fields. All requests MUST contain a length field in the start line that indicates the overall length of the request, including any body. Additional requirements exist depending on the individual method. Except where otherwise noted, all requests are hop by hop. 6.9.1 BIND The BIND method is used by a host endpoint to establish session state at a relay. BIND requests SHOULD be authenticated. BIND requests MAY contain the CAuth header fields. A successful response to a BIND request MUST contain the L-URI and R-URI header fields. 6.9.2 LEAVE The LEAVE method is used by a visiting endpoint to request that the host invalidate a session. The T-URI field MUST match that of the corresponding VISIT request. 6.9.3 RELEASE The RELEASE method is used by a host endpoint to request a relay to invalidate a session. The T-URI header field in a RELEASE request MUST match the L-URI header field returned in the successful response Campbell, et al. Expires April 25, 2003 [Page 22] Internet-Draft SIMPLE IM Sessions October 2002 to the corresponding BIND request. 6.9.4 SEND The SEND method is used by both the host and visitor endpoints to send instant messages to its peer endpoint. The T-URI header field MUST contain the temporary URI for the peer, that is a message sent to the visitor MUST use the visitor URI, and a message sent to the host MUST use the host URI. SEND requests SHOULD contain a MIME body part. The body MUST be of a media type included in the format list in the SDP provided by the peer. If a body is present, the request MUST contain a Content-Type header field identifying the media type of the body. There has been discussion that we could make media type identification more efficient by using the numeric index of the media type as listed in the SDP format list, rather than the full media type. This would have an advantage of space efficiency. The editor holds the opinion that the ease of readability more than offsets any space inefficiency, and is more in keeping with the philosophy that led us to choose a text-based protocol in the first place. The editor will, however, yield to any contrary consensus on the matter. Unlike other methods, SEND requests are end to end in nature. This means the request is consumed only by the opposite endpoint. Any intervening relays merely forward the request on towards its target. 6.9.5 VISIT The visiting endpoint uses the VISIT method to associate a network connection with the session state at the hosting device, which could be either the host endpoint or a relay operating on behalf of the host endpoint. The T-URI header field MUST match the visitor URI associated with the session. Notice that there is no authentication operation for the VISIT request. This is because the visitor URI acts as a shared secret between host and the visitor. This puts certain requirements on the handling of the visitor URIs that are discussed in Section 9 6.10 Response Code Descriptions This section summarizes the various response codes. Except where noted, all responses MUST contain the T-URI header field containing the URI of the endpoint that is the intended consumer of the response. Responses are never consumed by relays. Campbell, et al. Expires April 25, 2003 [Page 23] Internet-Draft SIMPLE IM Sessions October 2002 All responses MUST include the TR-ID header, with a value matching that of the corresponding request. 6.10.1 200 The 200 response code indicates a successful transaction. 6.10.2 400 A 400 response indicates a request was unintelligible. 6.10.3 401 A 401 response indicates authentication is required. 401 responses MUST NOT be used in response to any method other than BIND. A 401 response MUST contain a SChal header field. 6.10.4 403 A 403 response indicates the authenticated identity of the user attempting a BIND request is not authorized to perform such an action. A 403 response SHOULD NOT be used in response to any method other than BIND. 6.10.5 481 A 481 response indicates that no session exists that is associated with the connection on which the request arrived, and has a peer URI that matches the T-URI of the corresponding request. 6.10.6 500 A 500 response indicates that a relay was unable to deliver a SEND request to the target. A 500 response SHOULD NOT be used except for when multiple relays exist in a session, and a relay is unable to deliver the request to the next relay. Endpoints SHOULD NOT return 500 responses. 500 responses MUST NOT be returned in response to any method other than SEND. 6.10.7 506 A 506 response indicates that a VISIT request occurred in which the T-URI indicates a session that is already associated with another connection. A 506 response MUST NOT be returned in response to any method other than VISIT. 6.11 Header Field Descriptions Campbell, et al. Expires April 25, 2003 [Page 24] Internet-Draft SIMPLE IM Sessions October 2002 This section summarizes the various header fields. MSRP header fields are single valued; that is, they MUST NOT occur more than once in a particular request or response. 6.12 T-URI The T-URI Header field indicates the target of a request or a response. The semantics of T-URI vary with the method in question. 6.13 TR-ID The TR-ID header field contains a transaction identifier used to map a response to the corresponding request. A TR-ID value MUST be unique among all values used by a given endpoint inside a given session. MSRP elements MUST NOT assume any additional semantics for TR-ID. 6.14 CAuth The CAuth header field is used by a host endpoint to respond to offer digest authentication credentials to a relay, usually in response to a digest-authentication challenge. CAuth MUST NOT be present in a request of any method other than BIND. 6.15 SChal The SChal header field is used by a relay to carry the challenge in a digest authentication attempt. The SCHal header MUST NOT be used in any message except for a 401 response. The semantics of digest authentication in the context of MSRP are not fully defined at the time of this writing. We expect this work to be completed in a future version of this document, at which time the syntax of CAuth and SChal may change. 6.16 Content-Type The Content-Type header field is used to indicate the MIME media type of the body. Content-Type MUST be present if a body is present. 6.17 L-URI The L-URI header field is used by a relay to indicate the local URI for a session created with a BIND request. The L-URI header field MUST be present in a 200 response to a BIND request, and MUST NOT be present in any other request or response. Campbell, et al. Expires April 25, 2003 [Page 25] Internet-Draft SIMPLE IM Sessions October 2002 6.18 R-URI The R-URI header field is used by a relay to indicate the remote URI for a session created with a BIND request. The L-URI header field MUST be present in a 200 response to a BIND request, and MUST NOT be present in any other request or response. 7. Examples This section shows some example message flows for various common scenarios. The examples assume SIP is used to transport the SDP exchange. Details of the SIP messages and SIP proxy infrastructure are omitted for the sake of brevity. In the examples, assume the inviter is sip:alice@atlanta.com and the invitee is sip:bob@biloxi.com. In any given MSRP message, an "xx" in the length field indicates the actual length of the message 7.1 No Relay 1. Alice constructs a local uri of msrp:iau39@alicepc.atlanta.com and a remote uri of msrp: 9342iw@alicepc.atlanta.com, and listens for a connection on TCP port 7777. 2. Alice->Bob (SIP): INVITE sip:bob@biloxi.com c=IN IP4 alicepc.atlanta.com m=message 7777 msrp/tls text/plain a=i-am:iau39 a=you-be:9342iw 3. Bob->Alice: Open TCP connection to Alicepc.atlanta.com:7777, and perform TLS handshake. 4. Bob->Alice (MSRP): MSRP xx VISIT T-URI: 9342iw@alicepc.atlanta.com TR-ID: msrp:sie09s 5. Alice->Bob (MSRP): MSRP xx 200 OK T-URI: 9342iw@alicepc.atlanta.com TR-ID: sie09s Campbell, et al. Expires April 25, 2003 [Page 26] Internet-Draft SIMPLE IM Sessions October 2002 6. Bob->Alice (SIP): 200 OK c=IN IP4 alicepc.atlanta.com m=message 7777 msrp/tls text/plain a=i-am:9324iw 7. Alice->Bob (SIP): ACK 8. Alice->Bob (MSRP): MSRP xx SEND T-URI: msrp:9234iw@alicepc.atlanta.com TR-ID: 123 Content-Type: "text/plain" Hi, I'm Alice! 9. Bob->Alice (MSRP): MSRP xx 200 OK T-URI: msrp:iau39@alicepc.atlanta.com TR-ID: 123 10. Bob->Alice (MSRP): MSRP xx SEND T-URI: msrp:iau39@alicepc.atlanta.com TR-ID: 456 Content-Type: "text/plain" Hi, Alice! I'm Bob! 11. Alice->Bob (MSRP): MSRP xx 200 OK T-URI: msrp:9234iw@alicepc.atlanta.com TR-ID: 456 12. Alice->Bob (SIP): BYE 13. Alice invalidates session 14. Bob->Alice (MSRP): Campbell, et al. Expires April 25, 2003 [Page 27] Internet-Draft SIMPLE IM Sessions October 2002 MSRP xx LEAVE T-URI: msrp:9342iw@alicepc.atlanta.com TR-ID: 987 15. Alice->Bob (MSRP): MSRP xx 481 No Session T-URI: 9342iw@alicepc.atlanta.com TR-ID: 987 16. Bob invalidates local state for the session. 17. Bob->Alice (SIP): 200 OK 7.2 Single Relay This scenario introduces an MSRP relay at relay.atlanta.com. 1. Alice->Relay (MSRP): Alice opens a TLS connection to the relay, and sends the following: MSRP xx BIND T-URI: msrp:relay.atlanta.com TR-ID: 321 2. Relay->Alice (MSRP): MSRP xx 200 OK T-URI: msrp:relay.atlanta.com TR-ID: 321 L-URI: msrp:iau39@relay.atlanta.com R-URI: msrp:9342iw@relay.atlanta.com:7777 3. Alice->Bob (SIP): INVITE sip:bob@biloxi.com c=IN IP4 relay.atlanta.com m=message 7777 msrp/tls text/plain a=i-am:iau39 a=you-be:9342iw 4. Bob->Alice: Open TCP connection to relay.atlanta.com:7777, and perform TLS handshake. Campbell, et al. Expires April 25, 2003 [Page 28] Internet-Draft SIMPLE IM Sessions October 2002 5. Bob->Relay (MSRP): MSRP xx VISIT T-URI: 9342iw@relay.atlanta.com TR-ID: msrp:sie09s 6. Relay->Bob (MSRP): MSRP xx 200 OK T-URI: 9342iw@relay.atlanta.com TR-ID: sie09s 7. Bob->Alice (SIP): 200 OK c=IN IP4 relay.atlanta.com m=message 7777 msrp/tls text/plain a=i-am:9324iw 8. Alice->Bob (SIP): ACK 9. Alice->Relay (MSRP): MSRP xx SEND T-URI: msrp:9234iw@relay.atlanta.com TR-ID: 123 Content-Type: "text/plain" Hi, I'm Alice! 10. Relay->Bob (MSRP): MSRP xx SEND T-URI: msrp:9234iw@relay.atlanta.com TR-ID: 123 Content-Type: "text/plain" Hi, I'm Alice! 11. Bob->Relay (MSRP): MSRP xx 200 OK T-URI: msrp:iau39@relay.atlanta.com TR-ID: 123 Campbell, et al. Expires April 25, 2003 [Page 29] Internet-Draft SIMPLE IM Sessions October 2002 12. Relay->Alice (MSRP): MSRP xx 200 OK T-URI: msrp:iau39@relay.atlanta.com TR-ID: 123 13. Bob->Relay (MSRP): MSRP xx SEND T-URI: msrp:iau39@relay.atlanta.com TR-ID: 456 Content-Type: "text/plain" Hi, Alice! I'm Bob! 14. Relay->Alice (MSRP): MSRP xx SEND T-URI: msrp:iau39@relay.atlanta.com TR-ID: 456 Content-Type: "text/plain" Hi, Alice! I'm Bob! 15. Alice->relay (MSRP): MSRP xx 200 OK T-URI: msrp:9234iw@relay.atlanta.com TR-ID: 456 16. Relay->Bob (MSRP): MSRP xx 200 OK T-URI: msrp:9234iw@relay.atlanta.com TR-ID: 456 17. Alice->Bob (SIP): BYE 18. Alice->Relay (MSRP): MSRP xx RELEASE T-URI: msrp:iau39@relay.atlanta.com TR-ID: 42 Campbell, et al. Expires April 25, 2003 [Page 30] Internet-Draft SIMPLE IM Sessions October 2002 19. Relay->Alice (MSRP): (relay invalidates session state) MSRP xx 200 OK T-URI: msrp:iau39@relay.atlanta.com TR-ID: 42 20. Bob->Relay (MSRP): MSRP xx LEAVE T-URI: msrp:9342iw@relay.atlanta.com TR-ID: 987 21. Alice->Bob (MSRP): MSRP xx 481 No Session T-URI: msrp:9342iw@relay.atlanta.com TR-ID: 987 22. Bob invalidates local state for the session. 23. Bob->Alice (SIP): 200 OK 7.3 Two Relays In this scenario, both Alice and Bob are required by local policy to route all sessions through a local relay. 1. Alice->AtlantaRelay (MSRP): Alice opens a TLS connection to the relay, and sends the following: MSRP xx BIND T-URI: msrp:relay.atlanta.com TR-ID: 321 2. AtlantaRelay->Alice (MSRP): MSRP xx 200 OK T-URI: msrp:relay.atlanta.com TR-ID: 321 L-URI: msrp:iau39@relay.atlanta.com R-URI: msrp:9342iw@relay.atlanta.com:7777 3. Alice->Bob (SIP): INVITE sip:bob@biloxi.com Campbell, et al. Expires April 25, 2003 [Page 31] c=IN IP4 relay.atlanta.com m=message 7777 msrp/tls text/plain a=i-am:iau39 a=you-be:9342iw 4. Bob determines that, due to local policy, he must host the session through his own proxy. 5. Bob->BiloxiRelay (MSRP): Bob opens a TLS connection to his relay, and sends the following: MSRP xx BIND T-URI: msrp:relay.biloxi.com TR-ID: 934 6. BiloxiRelay->Bob(MSRP): MSRP xx 200 OK T-URI: msrp:relay.biloxi.com TR-ID: 934 L-URI: msrp:oeksd@relay.biloxi.com R-URI: msrp:kdowsw@relay.biloxi.com:7777 7. Bob->Alice (SIP): 200 OK c=IN IP4 relay.biloxi.com m=message 8910 msrp/tls text/plain a=i-am:oeksd a=you-be: kdowsw 8. Alice sees that Bob has requested to host instead. However, local policy requires her to insist on using the atlanta relay. 9. Alice->Bob (SIP): ACK c=IN IP4 relay.atlanta.com m=message 7777 msrp/tls text/plain a=i-am:iau39 10. Alice->AtlantaRelay (MSRP): MSRP xx SEND T-URI: msrp:oeksd@relay.biloxi.com TR-ID: 123 Content-Type: "text/plain" Campbell, et al. Expires April 25, 2003 [Page 32] Internet-Draft SIMPLE IM Sessions October 2002 Hi, I'm Alice! 11. AtlantaRelay recognizes it has received a SEND request targeted to a foreign domain. AtlantaRelay does a DNS resolution to find the relay at relay.biloxi.com, opens a connection to the well know port, and forwards the request. 12. BiloxiRelay->Bob (MSRP): MSRP xx SEND T-URI: msrp:oeksd@relay.biloxi.com TR-ID: 123 Content-Type: "text/plain" Hi, I'm Alice! 13. Bob->BiloxiRelay (MSRP): MSRP xx 200 OK T-URI: msrp:iau39@relay.atlanta.com TR-ID: 123 14. BiloxiRelay recognizes it has received a response targeted to a foreign domain. BiloxiRelay does a DNS resolution to find the relay at relay.atlanta.com, opens a connection to the well know port, and forwards the request. Note that BiloxiDomain cannot positively determine that it already has a connection _from_ relay.atlanta.com, as a NAT may obscure the source address on the original connection. 15. AtlantaRelay->Alice (MSRP): MSRP xx 200 OK T-URI: msrp:iau39@relay.atlanta.com TR-ID: 123 16. Alice->Bob (SIP): BYE 17. Alice->AtlantaRelay (MSRP): MSRP xx RELEASE T-URI: msrp:iau39@relay.atlanta.com TR-ID: 42 Campbell, et al. Expires April 25, 2003 [Page 33] Internet-Draft SIMPLE IM Sessions October 2002 18. Relay->Alice (MSRP): (relay invalidates session state) MSRP xx 200 OK T-URI: msrp:iau39@relay.atlanta.com TR-ID: 42 19. Bob->BiloxiRelay (MSRP): MSRP xx RELEASE T-URI: msrp:oeksd@relay.biloxi.com TR-ID: 938 20. BiloxiRelay->Bob (MSRP): (relay invalidates session state) MSRP xx 200 OK T-URI: msrp:oeksd@relay.biloxi.com TR-ID: 42 21. Bob->Alice (SIP): 200 OK 22. After a locally configured timeout period with no activity, AtlantaRelay and BiloxiRelay are free to drop their respective connections to each other. 8. Changes introduced in 01 version Version 01 is a significant re-write. References to COMEDIA were removed, as it was determined that COMEDIA would not allow connections to be used bidirectionally in the presence of NATs. Significantly more discussion of a concrete mechanism has been added to make up for no longer using COMEDIA. Additionally, this draft and draft-campbell-cpimmsg-sessions (which would have also changed drastically) have now been combined into this single draft. 9. Security Considerations There are a number of security considerations for MSRP, some of which are mentioned elsewhere in this document. This section discusses those further, and introduces some new ones. 9.1 Sensitivity of the Remote URI The remote URI of a MSRP session is used by the visiting endpoint to identify itself to the hosting device, regardless of whether the Campbell, et al. Expires April 25, 2003 [Page 34] Internet-Draft SIMPLE IM Sessions October 2002 session is directly hosted by the host endpoint, or is hosted by a relay. If an attacker were able to aquire the remote-URI, either by guessing it or by evedropping, there is a window of opportunity in which the attacker could hijack the session by sending a VISIT request to the host device before the true visiting endpoint. Because of this sensitivity, the remote URI SHOULD be constructed in a way to make it difficult to guess, and should be sufficiently random so that it is unlikely to be reused. All mechanisms used to transport the remote URI to the visitor and back to the host MUST be protected from eavesdroppers and man-in-the-middle attacks. This includes the VISIT request itself, as well as SDP exchange mechanism. Therefore an MSRP device MUST support the use of TLS for at least the VISIT request, which by extension indicates the endpoint MUST support the use of TLS for all MSRP messages. Further, MSRP connections SHOULD actually be protected with TLS. Further, an MSRP endpoint MUST be capable of using the security features of the signaling protocol in order to protect the SDP exchange and SHOULD actually use them on all such exchanges. End-to-end protection schemes SHOULD be preferred over hop-to-hop schemes for protection of the SDP exchange. 9.2 End to End Protection of IMs Instant messages can contain very sensitive information. As a result, as specified in RFC 2779 [4], instant messaging protocols need to provide for encryption, integrity and authentication of instant messages. Therefore MSRP endpoints MUST support the end-to-end encryption and integrity of bodies sent via SEND requests, using the session key generation mechanism described in MIKEY [5]. 9.3 CPIM compatibility MSRP sessions may be gatewayed to other CPIM [14]compatible protocols. If this occurs, the gateway MUST maintain session state, and MUST translate between the MSRP session semantics and CPIM semantics that do not include a concept of sessions. Furthermore, when one endpoint of the session is a CPIM gateway, instant messages SHOULD be wrapped in "message/cpim" [6] bodies. Such a gateway MUST include "message/cpim" as the first entry in its SDP format list. MSRP endpoints sending instant messages to a peer that has included 'message/cpim" as the first entry in the format list SHOULD encapsulate all instant message bodies in "message/cpim" wrappers. All MSRP endpoints SHOULD support the S/MIME features of that format. 10. IANA Considerations MSRP will likely require the IANA registration of an well-known port for MSRP relays. Additionally, we may have to register the "i-am" and Campbell, et al. Expires April 25, 2003 [Page 35] Internet-Draft SIMPLE IM Sessions October 2002 "you-be" attributes of the MSRP SDP exchange. 11. Open Issues This specification is far from complete, particularly in the areas of error handling and security considerations. If the working group chooses to fully specify MSRP, additional work is required in those areas. Further specification of the MSRP URI scheme will also be required. For example, this version does not describe URI comparison rules, or rules for resolving a URI using the DNS. The concept of an "msrps" URI scheme that required the use of TLS on all hops was discussed in the design team. This concept is not documented in this version, as it is not fully enough developed to include. Such a scheme is likely to appear in a future version of this document. 12. Contributors The following people contributed substantially to this ongoing effort: Rohan Mahy Allison Mankin Jon Peterson Brian Rosen Dean Willis Normative References [1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [2] 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. [3] Campbell, B., "Instant Message Sessions using the CPIM Message Format.", draft-campbell-simple-cpimmsg-sessions-00.txt (work in progress), October 2002. [4] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000. [5] Arkko, J., "MIKEY: Multimedia Internet KEYing", draft-ietf-msec-mikey-04 (work in progress), August 2002. [6] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging Campbell, et al. Expires April 25, 2003 [Page 36] Internet-Draft SIMPLE IM Sessions October 2002 Message Format", draft-ietf-impp-cpim-msgfmt-06 (work in progress), February 2001. Informational References [7] Campbell, B. and J. Rosenberg, "Session Initiation Protocol Extension for Instant Messaging", RFC 3428, 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. [14] Crocker, D., Diacakis, A., Mazzoldi, F., Huitema, C., Klyne, G., Rose, M., Rosenberg, J., Sparks, R., Sugano, H. and J. Peterson, "A Common Profile for Instant Messaging (CPIM)", draft-ietf-impp-cpim-03 (work in progress), August 2002. Authors' Addresses Ben Campbell dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 EMail: bcampbell@dynamicsoft.com Campbell, et al. Expires April 25, 2003 [Page 37] Internet-Draft SIMPLE IM Sessions October 2002 Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 EMail: jdrosen@dynamicsoft.com Robert Sparks dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 EMail: rsparks@dynamicsoft.com Paul Kyzivat Cisco Systems Mail Stop LWL3/12/2 900 Chelmsford St. Lowell, MA 01851 EMail: pkzivat@cisco.com Campbell, et al. Expires April 25, 2003 [Page 38] Internet-Draft SIMPLE IM Sessions October 2002 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 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 assignees. 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 Campbell, et al. Expires April 25, 2003 [Page 39] Internet-Draft SIMPLE IM Sessions October 2002 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, et al. Expires April 25, 2003 [Page 40]