SIMPLE Working Group S. Blau Internet-Draft Ericsson AB Intended status: Informational C. Holmberg Expires: March 16, 2009 Ericsson September 12, 2008 An Alternative Connection Model for the Message Session Relay Protocol (MSRP) draft-blau-simple-msrp-acm-01.txt 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 March 16, 2009. Abstract This document defines an alternative connection model for MSRP UAs. The model differs from the standard MSRP model, as defined in RFC4975 and RFC4976 in the following ways: it uses SDP in a more conventional way when it comes to conveying endpoint address information, and it uses COMEDIA for connection establishment. Because of this, the model also allows for the usage of mainstream mechanisms for NAT traversal, instead of using MSRP relays. Blau & Holmberg Expires March 16, 2009 [Page 1] Internet-Draft MRSP September 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Applicability statement . . . . . . . . . . . . . . . . . . . . 4 4. The Alternative Connection Model for MSRP . . . . . . . . . . . 4 4.1. Transport connection addressing . . . . . . . . . . . . . . 4 4.2. COMEDIA usage . . . . . . . . . . . . . . . . . . . . . . . 5 4.2.1. a=setup . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2.2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.3. a=connection . . . . . . . . . . . . . . . . . . . . . 6 4.3. NAT keepalive . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. ICE usage . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Blau & Holmberg Expires March 16, 2009 [Page 2] Internet-Draft MRSP September 2008 1. Introduction MSRP [RFC4975] is designed to use MSRP relays [RFC4976] as a means for NAT traversal and policy enforcement. However, in many SIP networks it is often desired to deploy MSRP without the use of MSRP relays, and instead use more general NAT traversal mechanisms - such as COMEDIA [RFC4145] and ICE [I.D-ietf-mmusic-ice] - while also using SIP ALG controlled media relays for more application specific policy control. An example is the OMA defined "Instant Message using SIMPLE" [OMA-TS- SIMPLE_IM-V1_0-20080312-D], where the UA of one endpoint of every MSRP transport connection is a media server located in the network. The media server has a global address and is handling application specific policy control as well as NAT traversal, the latter through use of COMEDIA which all IM MSRP clients are mandated to support. Many networks where MSRP usage is emerging also contain ALGs that are deployed for reasons of performance monitoring, lawful intercept, address domain bridging, interconnect SLA policy enforcement, etc. A typical example here is the 3GPP defined Interconnect Border Control Function (IBCF) [3GPP TS23.228], which controls a media relay that handles all types of SIP session media (voice, video, MSRP, etc). Due to the fact that the MSRP connection model is not in a conventional way using the address information in the SDP c- and m-line for negotiating transport connection endpoints, and also checks consistence between addresses in the MSRP protocol and in the SDP a=path line, this forces the IBCF/media relay to act as an SDP aware MSRP B2BUA, whereas for basically all other UDP and TCP transported based media sessions it can acts as an SDP aware Relay- NAPT - which is much simpler than having to act as an MSRP B2BUA. To adapt MSRP to a more conventional SDP usage, which is more friendly to general NAT traversal methods and to ALGs, this document defines an alternative connection model for MSRP. The model differs from the [RFC4975] defined model in that COMEDIA [RFC4145] is used in SDP offer/answer exchanges, and that the c- and m-line address and port information is used in conventional SDP manner for determining transport endpoint, meaning that the address and port information in the MSRP URI in the a=path line is no longer used for routing. The alternative connection model allows conformant UAs to fall back to [RFC4975] compliant behavior when interacting with [RFC4975] conformant UAs. Blau & Holmberg Expires March 16, 2009 [Page 3] Internet-Draft MRSP September 2008 2. 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, RFC 2119 [RFC2119]. 3. Applicability statement The alternative connection model for MSRP, as defined in this document, SHOULD be used when a UA does not use an MSRP relay to proxy its MSRP communication. UAs conformant to this document are fully interoperable with [RFC4975] conformant UAs, since when interacting with such UAs they will more or less fall back to [RFC4975] compliant behavior. However, if a UA conformant to this document is behind NAT and receives an SDP offer from an [RFC4975] conformant UA, NAT traversal can only be achieved if the UA supports ICE (and the network provides TURN servers) or if the network supports SBC assisted NAT traversal for TCP. 4. The Alternative Connection Model for MSRP 4.1. Transport connection addressing A UA SHALL follow the conventional use of address information received in the SDP c- and m-lines for determining the transport connection endpoint address:port to connect to, instead of using the address information in the MSRP URI received in the a=path line to determine the remote transport connection endpoint address:port. With such usage, applying COMEDIA, ICE and TLS in SDP offer/answer exchanges for MSRP sessions can be done more or less in the conventional way with very little MSRP dependencies, as detailed in this document. Furthermore, this usage also allows any ALG/SBC in the SIP signaling path to perform media anchoring in the same way they today do for any TCP connections not used for MSRP, i.e. by modifying the address:port information in the c- and m-lines, and ignoring any a=path line. When a UA sends an SDP offer, the MSRP URI in the a=path line of the SDP offer (and eventually in the MSRP FromPath header) MAY include an AoR instead of connection address information. The AoR usage works fine even if the SDP answerer is a [RFC4975] conformant UA, since in such cases the SDP offerer will always establish the transport Blau & Holmberg Expires March 16, 2009 [Page 4] Internet-Draft MRSP September 2008 connection based on address information in the SDP answer. The MSRP URI matching will still work since this only requires the MSRP URIs in the a=path headers to be identical to the MSRP URIs in the MSRP protocol FromPath and ToPath headers. When a UA receives an SDP offer from an [RFC4975] conformant UA (the receiving UA knows this if the SDP offer does not contain an "a=setup" attribute), it needs to populate the MSRP URI in the SDP answer (and eventually in the MSRP FromPath header) with an address or FQDN in accordance with [RFC4975]. The presence of the "a=setup" attribute will also enable ALGs/SBCs to apply normal media anchoring procedures and need not act as MSRP B2BUAs. In accordance with [RFC4975], for an MSRP endpoint that receives TCP open requests to be able to use a common port for all MSRP transport connections, the initiator of an MSRP transport connection SHALL always after having established a new transport connection send an MSRP message, allowing the other endpoint to establish the binding between MSRP session and transport connection. 4.2. COMEDIA usage 4.2.1. a=setup A UA SHALL support the a=setup attribute [RFC4145], in order to negotiate which endpoint is to establish the transport connection for an MSRP session. The support of a=setup is particularly useful when one MSRP endpoint is a media server which is not behind a NAT. This since the media server then make sure that transport connections for MSRP media is always set up from the UA towards the server, and ensure that possible NATs at user premises will not interfere with the connection setup. A UA SHALL always include an explicit a=setup line in SDP offers and answers, since it is sometimes useful for the other endpoint, or for the network, to know whether the sending endpoint supports a=setup or not. The a=setup "active", "actpass" and "passive" values SHALL be supported, while the "holdcon" value MUST NOT be used. Note: When the a=setup value is "actpass" or "passive", the IP address:port value in the SDP MUST contain the actual address:port on which the UA can receive a TCP Open request for the MSRP transport connection. Blau & Holmberg Expires March 16, 2009 [Page 5] Internet-Draft MRSP September 2008 If the a=setup value is "active", the port number value MUST either be the actual port number that will be used for the TCP endpoint or the port value 9. The a=setup "actpass" value SHALL be used in SDP offers whenever an UA can determine a valid WAN transport endpoint address:port, i.e. an address:port that the other endpoint can use as destination for a TCP Open request. This is in order to a) allow the other endpoint to answer with "a=setup:active" if it is behind NAT, and b) to be compatible with MSRP endpoints that do not support COMEDIA and thus always will always act as passive endpoints. If not the actual transport address can be provided then the a=setup "active" value MUST be used. A valid WAN transport address:port can be determined if the UA can determine that it is not located behind a NAT, or if the UA relays its MSRP transport connections via a TURN server, or if it through STUN signaling from the local port to be used for the eventual transport connection has used STUN to retrieve NAT address:port while also having determined that the NAT is not address restricted. If the UA is located behind a NAT, both SIP signaling and media transport will pass trough it, and a UA can determine whether the media transport will be NATed by inspecting the SIP Via header in the 200 OK response to the initial REGISTER request, comparing the IP addresses in the Via sent-by and received parameters. If these are not the same then there is a NAT in the path. If an SDP offer includes a=setup:actpass, the SDP answer MAY include a=setup:active, but SHOULD include a=setup:passive if the SDP answerer knows that it is not located behind a NAT. 4.2.2. TLS If a TLS transport connection for MSRP is negotiated, the client and server TLS roles MUST negotiate the relevant parameter as specified by COMEDIA-TLS [RFC4572], and in accordance with [RFC4975] the MSRP URI scheme SHOULD be msrps and the m-line protocol indicator SHOULD be TCP/TLS/MSRP. 4.2.3. a=connection The a=connection attribute is defined as a means for SDP negotiation of transport connection reuse. However, it seems that its use is limited to mid-session SDP offer/answer exchanges while [RFC4976] requires initial SDP offer/answer exchanges to result in reuse of a transport connection established via another existing SIP session at the same UA, if the SDP for the remote endpoint of that connection Blau & Holmberg Expires March 16, 2009 [Page 6] Internet-Draft MRSP September 2008 indicates the same host address, port and URI scheme. A UA SHALL use a=connection lines for mid-session re-negotiation of transport connection for an MSRP session, but SHOULD not include any a=connection line in initial SDP offer/answer exchanges (if present, it SHALL be ignored by the receiving UA). Instead the connection reuse principles for initial SDP offer/answer exchanges for an MSRP session SHALL be in accordance with [RFC4975]. 4.3. NAT keepalive An MSRP endpoint behind NAT MUST keep the NAT binding alive, in accordance with chapter 10 in [I.D.ietf-mmusic-ice]. The character string CRLF SHOULD be sent as NAT keepalive, but if the transport connection was established using ICE then STUN MAY alternatively be used. 4.4. ICE usage If the UA is using ICE for MSRP transport connection establishment, it SHALL before starting to send any TCP Open requests perform the normal MSRP checks for possible reuse of an existing transport connection. If such is identified, the UA SHOULD preempt ICE processing and send a new SIP offer which indicates a=connection: existing and the SDP information for the selected connection. 5. Security Considerations TBD 6. Acknowledgements Thanks to Hadriel Kaplan and Remi Denis-Courmont for their comments and input on this document. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999. Blau & Holmberg Expires March 16, 2009 [Page 7] Internet-Draft MRSP September 2008 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005. [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006. [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007. [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", RFC 4976, September 2007. 7.2. Informative References Authors' Addresses Staffan Blau Ericsson AB P.O Box 407 Sweden Email: staffan.blau@ericsson.com Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Blau & Holmberg Expires March 16, 2009 [Page 8] Internet-Draft MRSP September 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. Blau & Holmberg Expires March 16, 2009 [Page 9]