Network Working Group A. Niemi Internet-Draft Nokia Expires: August 30, 2007 February 26, 2007 Message Session Relay Protocol Adaptation for Interactive Connectivity Establishment (ICE) draft-niemi-simple-msrp-ice-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 30, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This memo defines an alternate rendezvous mechanism for the Message Session Relay Protocol (MSRP) using Interactive Connectivity Establishment (ICE). Niemi Expires August 30, 2007 [Page 1]
Internet-Draft ICE MSRP February 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 4 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 5. Session Negotiation . . . . . . . . . . . . . . . . . . . . . 6 5.1. Generating the Initial SDP Offer . . . . . . . . . . . . . 6 5.2. Generating an Updated Offer . . . . . . . . . . . . . . . 7 5.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 8 5.4. Falling Back to non-ICE Behavior . . . . . . . . . . . . . 9 5.5. Transport Security . . . . . . . . . . . . . . . . . . . . 9 5.6. ICE Lite with MSRP . . . . . . . . . . . . . . . . . . . . 10 6. Sending MSRP Messages . . . . . . . . . . . . . . . . . . . . 10 6.1. Multiplexing STUN and MSRP . . . . . . . . . . . . . . . . 10 6.2. Providing Path Information in the MSRP Header . . . . . . 11 6.3. Requesting and Sending Progress Reports . . . . . . . . . 11 7. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Niemi Expires August 30, 2007 [Page 2]
Internet-Draft ICE MSRP February 2007 1. Introduction The Message Session Relay Protocol (MSRP) [1] defines a mechanism for transmitting a series of related instant messages in the context of a session. This session is established using a separate session negotiation protocol, such as the Session Initiation Protocol (SIP) [2], and the Offer/Answer Model with the Session Description Protocol (SDP) [3]. The Relay Extensions for the Message Session Relay Protocol (MSRP) [7] is a companion specification for MSRP that defines the necessary extensions to MSRP for introducing intermediary elements called relays along the path of an instant messaging session. The relays serve two important functions: o Enable clients to establish connections in the presence of Network Address Translator (NAT) and firewalls; and o Enable domain administrators to apply policy control for instant messaging sessions. To address the first, however, there is another body of work around Interactive Connectivity Establishment (ICE) [4] that addresses NAT traversal in a more generic way for virtually all types of multimedia sessions that are based on the SDP offer/answer model. The intent of this memo is to describe an alternate rendezvous mechanism for MSRP sessions using SIP, the SDP offer/answer model, and ICE. This alternate rendezvous mechanism has the following benefits: o Single infrastructure can be used for NAT traversal of all types of multimedia sessions, instead of having to maintain protocol- specific relays o Even in the presence of relay elements, the MSRP clients are able to negotiate an end-to-end TLS session o The clients can use ICE to determine a best possible route for the messages, so that if possible, relay usage can be avoided altogether This memo is intended as a drop-in replacement for MSRP relays, but it specifically does not address the issues of policy enforcement, or interception of messages for logging or other purposes. It does, however, offer a more affordable model for MSRP deployment that leverages the common ICE-style strategy for establishing sessions between clients. It also provides for backwards compatibility for Niemi Expires August 30, 2007 [Page 3]
Internet-Draft ICE MSRP February 2007 non-ICE aware clients. 2. Document 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 BCP 14, Key words for use in RFCs to Indicate Requirement Levels [5] and indicate requirement levels for compliant implementations. 3. Background During the design of the MSRP protocol, several requirements were identified that required accommodating MSRP-specific relay functionality in the protocol [7]. Most importantly: o Relays were required both for NAT traversal purposes, as well as (Ed: maybe more importantly?) for policy enforcement, e.g., message tracking and logging. o Relays needed a way to do connection sharing in an inter-domain setting. This required MSRP messages to carry routing information, and have an interruptible message chunking mechanims. The consequence of these requirements was that plain transport level relays, such as TURN [8] or SOCKS Protocol Version 5 [9] could not be used with MSRP. Also, the decision to use a relay is inflexible in MSRP. The client will need to decide before a session attempt whether or not to employ a relay. Route optimization per session is not possible, which leads to suboptimal use of the relay resources. Of course, if relays are predominantly used for policy control, then such flexibility is not necessary either. Connection-Oriented Media Transport (COMEDIA) [10] and Connection- Oriented Media Transport over the Transport Layer Security (TLS) Protocol [11] in SDP define extensions to SDP for describing TCP- based and TLS-based sessions, for which TCP Candidates with Interactive Connectivity Establishment (ICE) [6] provide a way to implement connection validation with Simple Traversal Underneath Network Address Translators (STUN) [12] based probes; as well as have media relaying by Obtaining Relay Addresses from Simple Traversal Underneath NAT (STUN) [8]. Again, during the development of MSRP, there was extensive discussion on whether or not to adopt the COMEDIA SDP extensions as baseline for describing MSRP sessions. The decision was not to adopt COMEDIA Niemi Expires August 30, 2007 [Page 4]
Internet-Draft ICE MSRP February 2007 directly, but only to reuse certain key concepts instead: o The direction in which TCP connections are established is fixed in MSRP to the offerer always taking the active role, and the answerer being passive o MSRP does not negotiate connection reuse explicitly, contrary to COMEDIA (with the a=connection SDP attribute). Instead, connections can be shared implicitly among multiple sessions, if the MSRP session paths are compatible. o The mechanism for mutually authenticated TLS using self-signed certificates in a leap-of-faith manner is shared between the specifications (both use the a=fingerprint mechanism). As a result, MSRP does not use COMEDIA extensions. It turns out COMEDIA isn't strictly required once a session is negotiated using ICE. The reason is that in ICE, candidates already describe the connection direction, and in case of an ICE restart, the intention is clear without using the COMEDIA a=setup and a=connection attributes. The idea behind this specification is to offer an alternate strategy to NAT traversal in MSRP that is especially geared towards deployments that offer not only voice and instant messaging, but also other types of media sessions, out of which many may be connection oriented. In such a setting it is highly appropriate to be able to run a single TURN infrastructure, instead of protocol-specific MSRP relays. 4. Overview of Operation An MSRP session using ICE is a relatively straightforward adaptation of ICE-TCP [6]. To initiate an MSRP session, the initiator collects ICE candidates, each of which are one of three types: o An active candidate for which the agent will attempt to open a TCP connection. o A passive candidate for which the agent will be in passive mode and only listen for incoming connections o Simultaneous open candidate, for which the agents will attempt a TCP simultaneous open The candidates are prioritized and an in-use candidate is selected following normal ICE-TCP procedures.The active candidates are paired with the passive ones and the simultaneous open candidates with each Niemi Expires August 30, 2007 [Page 5]
Internet-Draft ICE MSRP February 2007 other. For backwards compatibility, MSRP agents include the default session negotiation in their SDP in addition to the ICE candidates. This way, an agent can fall back to the default negotiation using the MSRP a=path SDP attribute, in case the opposite agent does not support ICE. 5. Session Negotiation FIXME: Need to check and prune all of the examples in this section. Specifically, they're all wrong, and need to be fixed. Also need the relay candidates to be shown as well. OPEN ISSUE: ICE-TCP suggests that for backwards compatibility's sake, the ICE client should include all of the COMEDIA attributes into its offers (a=setup, a=connection), even though they are useless. Since MSRP doesn't use COMEDIA to begin with, it seems safe to not use it with ICE either. This section defines the detailed procedures for setting up an MSRP session using ICE. 5.1. Generating the Initial SDP Offer In preparation for sending an MSRP offer, the client first gathers a set of candidates, as specified in [6]. It prioritizes them, and selects an in-use candidate that is most probably going to work. For backwards compatibility, the MSRP client MUST set the a=path attribute to contain an MSRP URL that mirrors the IP address and port of the in-use candidate. I.e., the MSRP URL is a composition of information also present in the c= and m= lines of the SDP. The secret portion of the URL in the a=path attribute SHOULD be set to the ice-pwd; although this is only a matter of convenience and is not a strict requirement. An example SDP offer with an MSRP session using ICE is shown in Figure 1. Niemi Expires August 30, 2007 [Page 6]
Internet-Draft ICE MSRP February 2007 v=0 o=jdoe 2890844526 2890842807 IN IP4 s= c=IN IP4 192.0.2.3 t=0 0 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=message 7746 TCP/MSRP * a=accept-types:text/plain a=path:msrp://192.0.2.3:7746/asd88fgpdd777uzjYhagZg;tcp a=candidate:1 1 tcp-so 2130706178 10.0.0.5 12534 typ local a=candidate:2 1 tcp-pass 2130706178 10.0.0.5 12534 typ local a=candidate:3 1 tcp-so 1694498562 192.0.2.3 7746 typ srflx raddr \ 10.0.0.5 rport 12534 a=candidate:4 1 tcp-act 1694498562 192.0.2.3 7746 typ srflx raddr \ 10.0.0.5 rport 12534 a=candidate:5 1 tcp-pass 1694498562 192.0.2.3 7746 typ srflx raddr \ 10.0.0.5 rport 12534 a=candidate:6 1 tcp-pass 1694498562 192.0.2.3 7746 typ relay raddr \ 10.0.0.5 rport 12534 Figure 1: Example SDP Offer 5.2. Generating an Updated Offer FIXME: Needs text. Niemi Expires August 30, 2007 [Page 7]
Internet-Draft ICE MSRP February 2007 v=0 o=jdoe 2890844526 2890842807 IN IP4 s= c=IN IP4 192.0.2.3 t=0 0 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=message 7746 TCP/MSRP a=accept-types:text/plain a=path:msrp://192.0.2.3:7746/asd88fgpdd777uzjYhagZg a=candidate:1 1 tcp-so 2130706178 10.0.0.5 12534 typ local a=candidate:2 1 tcp-act 2130706178 10.0.0.5 12534typ local a=candidate:3 1 tcp-pass 2130706178 10.0.0.5 12534 typ local a=candidate:4 1 tcp-so 1694498564 192.0.2.3 7746 typ srflx raddr \ 10.0.0.5 rport 12534 a=candidate:5 1 tcp-act 1694498562 192.0.2.3 7746 typ srflx raddr \ 10.0.0.5 rport 12534 a=candidate:6 1 tcp-pass 1694498560 192.0.2.3 7746 typ srflx raddr \ 10.0.0.5 rport 12534 a=candidate:6 1 tcp-pass 1694498550 192.0.2.3 7746 typ relay raddr \ 10.0.0.5 rport 12534 Figure 2: Example Updated SDP Offer 5.3. Generating the SDP Answer FIXME: This example is just a copy-paste. Niemi Expires August 30, 2007 [Page 8]
Internet-Draft ICE MSRP February 2007 v=0 o=jdoe 2890844526 2890842807 IN IP4 s= c=IN IP4 192.0.2.3 t=0 0 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=message 7746 TLS/MSRP a=setup:holdconn # Also useless... a=connection:existing a=fingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB a=accept-types:text/plain a=path:msrp://192.0.2.3:7746/asd88fgpdd777uzjYhagZg a=candidate:1 1 tls-so 2130706178 10.0.0.5 12534 typ local a=candidate:2 1 tls-act 2130706178 10.0.0.5 12534typ local a=candidate:3 1 tls-pass 2130706178 10.0.0.5 12534 typ local a=candidate:4 1 tls-so 1694498562 192.0.2.3 7746 typ srflx raddr \ 10.0.0.5 rport 12534 a=candidate:5 1 tls-act 1694498562 192.0.2.3 7746 typ srflx raddr \ 10.0.0.5 rport 12534 a=candidate:6 1 tls-pass 1694498562 192.0.2.3 7746 typ srflx raddr \ 10.0.0.5 rport 12534 Figure 3: Example SDP Answer with TLS 5.4. Falling Back to non-ICE Behavior If either the answer or the offer contains no ICE candidates, the session needs to fall back to the normal MSRP session mode. The MSRP client checks for the presence of ICE attributes in the SDP, and if there are no candidates shown, this means that the peer does not support ICE. If an offer contains no ICE candidates, the MSRP client MUST NOT use ICE in its answer, and fall back to negotiating MSRP in the default way. Similarly, if the answer doesn't contain ICE candidates, the agent MUST fall back to normal MSRP negotiation. 5.5. Transport Security FIXME: Needs text. Niemi Expires August 30, 2007 [Page 9]
Internet-Draft ICE MSRP February 2007 v=0 o=jdoe 2890844526 2890842807 IN IP4 s= c=IN IP4 192.0.2.3 t=0 0 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=message 7746 TLS/MSRP * a=fingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB a=accept-types:text/plain a=path:msrp://192.0.2.3:7746/asd88fgpdd777uzjYhagZg a=candidate:1 1 tls-so 2130706178 10.0.0.5 12534 typ local a=candidate:2 1 tls-act 2130706178 10.0.0.5 12534typ local a=candidate:3 1 tls-pass 2130706178 10.0.0.5 12534 typ local a=candidate:4 1 tls-so 1694498562 192.0.2.3 7746 typ srflx raddr \ 10.0.0.5 rport 12534 a=candidate:5 1 tls-act 1694498562 192.0.2.3 7746 typ srflx raddr \ 10.0.0.5 rport 12534 a=candidate:6 1 tls-pass 1694498562 192.0.2.3 7746 typ srflx raddr \ 10.0.0.5 rport 12534 Figure 4: Example SDP Offer with TLS 5.6. ICE Lite with MSRP FIXME: Needs text. 6. Sending MSRP Messages OPEN ISSUE: If ICE concludes successfully, is it safe to conclude that no MSRP relays are in use, which would allow dropping the To- Path and From-Path from subsequent SENDs? 6.1. Multiplexing STUN and MSRP Since the connectivity probes are STUN packets that are sent over an already established connection, the MSRP clients MUST support multiplexing STUN and MSRP messages over the same connection. OPEN ISSUE: ICE-TCP requires agents to use RFC4571 [13] framing, even if the media is not RTP/RTCP. Is this going to be a problem? Seems like a bug in ICE-TCP. Niemi Expires August 30, 2007 [Page 10]
Internet-Draft ICE MSRP February 2007 6.2. Providing Path Information in the MSRP Header OPEN ISSUE: Since ICE handles connection validation, and there are no MSRP relays in the path, are the To-Path and From-Path necessary any longer? 6.3. Requesting and Sending Progress Reports Because the proposed mechanism always establishes an end-to-end transport connection, it is known to the sender whether a message chunk has successfully been delivered to the other endpoint when the response to the SEND request is received. Therefore, success reports SHOULD NOT be requested, and failure reports SHOULD be explicitly disabled (Failure-Report: no) for an MSRP session using ICE-TCP. 7. Backwards Compatibility This memo introduces new behavior for MSRP clients that affect backwards compatibility: 1. Rather than relying on MSRP for connection validation, this specification relies on ICE connectivity probes, which happen before any MSRP messages are sent. 2. Since relayed candidates are not specific to MSRP, it is no longer possible to multiplex several different MSRP sessions in the same inter-domain connection. 3. As a consequence of the previous two items, MSRP messages may no longer required to include the To-Path and From-Path header fields. 4. In order to implement ICE connectivity probes, implementations must add support for multiplexing STUN and MSRP messages over the same connection. FIXME: discussion of the drawbacks here. 8. Security Considerations FIXME: Needs text. 9. IANA Considerations There are no IANA considerations. Niemi Expires August 30, 2007 [Page 11]
Internet-Draft ICE MSRP February 2007 10. Acknowledgements The following people provided comments and suggestions and engaged in interesting discussions on the topic: Remi Denis-Courmont, Markus Isomaki, Miguel Garcia. 11. References 11.1. Normative References [1] Campbell, B., "The Message Session Relay Protocol", draft-ietf-simple-message-sessions-15 (work in progress), July 2006. [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] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [4] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-11 (work in progress), October 2006. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Rosenberg, J., "TCP Candidates with Interactive Connectivity Establishment (ICE)", draft-ietf-mmusic-ice-tcp-01 (work in progress), June 2006. 11.2. Informative References [7] Jennings, C., "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", draft-ietf-simple-msrp-relays-08 (work in progress), July 2006. [8] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal Underneath NAT (STUN)", draft-ietf-behave-turn-02 (work in progress), October 2006. [9] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996. [10] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Niemi Expires August 30, 2007 [Page 12]
Internet-Draft ICE MSRP February 2007 Session Description Protocol (SDP)", RFC 4145, September 2005. [11] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006. [12] Rosenberg, J., "Simple Traversal Underneath Network Address Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-04 (work in progress), July 2006. [13] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, July 2006. Author's Address Aki Niemi Nokia P.O. Box 407 NOKIA GROUP, FIN 00045 Finland Phone: +358 50 389 1644 Email: aki.niemi@nokia.com Niemi Expires August 30, 2007 [Page 13]
Internet-Draft ICE MSRP February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Niemi Expires August 30, 2007 [Page 14]