SIMPLE Working Group                                             S. Blau
Internet-Draft                                               Ericsson AB
Intended status: Informational                               C. Holmberg
Expires: April 20, 2009                                         Ericsson
                                                        October 17, 2008


 An Alternative Connection Model for the Message Session Relay Protocol
                                 (MSRP)
                   draft-blau-simple-msrp-acm-02.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 April 20, 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 COMEDIA for TCP connection
   establishment, and it allows the usage of SDP in a more conventional
   way for conveying endpoint address information.  Because of this, the
   model also allows for the usage of generic mainstream mechanisms for
   NAT traversal, instead of using MSRP relays.






Blau & Holmberg          Expires April 20, 2009                 [Page 1]


Internet-Draft                    MRSP                      October 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Applicability statement  . . . . . . . . . . . . . . . . . . .  4
   4.  The Alternative Connection Model for MSRP  . . . . . . . . . .  4
     4.1.  COMEDIA usage  . . . . . . . . . . . . . . . . . . . . . .  4
       4.1.1.  a=setup  . . . . . . . . . . . . . . . . . . . . . . .  4
       4.1.2.  TLS  . . . . . . . . . . . . . . . . . . . . . . . . .  5
       4.1.3.  a=connection . . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Transport connection addressing  . . . . . . . . . . . . .  6
     4.3.  NAT keepalive  . . . . . . . . . . . . . . . . . . . . . .  7
     4.4.  ICE usage  . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     8.2.  Informative References . . . . . . . . . . . . . . . . . .  8
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  8
   Intellectual Property and Copyright Statements . . . . . . . . . . 10






























Blau & Holmberg          Expires April 20, 2009                 [Page 2]


Internet-Draft                    MRSP                      October 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 generic 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 may be 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.

   NOTE: It is possible for a UA to only use the COMEDIA mechanism of
   the alternative connection model, but to use the MSRP routing
   mechanism defined in [RFC4975].

   The alternative connection model allows conformant UAs to fall back
   to [RFC4975] compliant behavior when interacting with [RFC4975]



Blau & Holmberg          Expires April 20, 2009                 [Page 3]


Internet-Draft                    MRSP                      October 2008


   conformant UAs.


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.  The UA SHALL use COMEDIA.  If ALGs are
   used the UA SHOULD use SDP c/m line conveyed address and port
   information for MSRP routing, otherwise the UA MAY use the address
   and port information conveyed in the MSRP URI (as per RFC4975).

   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.  COMEDIA usage

4.1.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



Blau & Holmberg          Expires April 20, 2009                 [Page 4]


Internet-Draft                    MRSP                      October 2008


   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.

   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.1.2.  TLS

   If a TLS transport connection for MSRP is negotiated, the client and
   server TLS roles MUST negotiate the relevant parameter as specified



Blau & Holmberg          Expires April 20, 2009                 [Page 5]


Internet-Draft                    MRSP                      October 2008


   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.1.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
   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.2.  Transport connection addressing

   If the UA supports the transport connection addressing mechanism
   defined in this chapter, the UA shall follow the procedures described
   below.

   The 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 in a 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
   connection based on address information in the SDP answer.  The MSRP
   URI matching will still work since this only requires the MSRP URIs



Blau & Holmberg          Expires April 20, 2009                 [Page 6]


Internet-Draft                    MRSP                      October 2008


   in the a=path headers to be identical to the MSRP URIs in the MSRP
   protocol FromPath and ToPath headers.

   When a UA sends an SDP offer, the UA SHALL include an "a=msrp-acm"
   attribute, which indicates that the UA supports the transport
   connection addressing defined in this specifciation.

   When a UA receives an SDP offer which contains an "a=msrp-acm"
   attribute, the UA SHALL include the attribute in the SDP answer.

   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), or the UA receives an SDP offer from a UA which
   only supports the COMEDIA usage mechanism of this specification (the
   receiving UA knows this if the SDP offer does not contain an "a=msrp-
   acm" attribute), the UA 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].

   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.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




Blau & Holmberg          Expires April 20, 2009                 [Page 7]


Internet-Draft                    MRSP                      October 2008


6.  IANA Considerations

   This document declares a new SDP attribute, "a=msrp-acm".


7.  Acknowledgements

   Thanks to Hadriel Kaplan and Remi Denis-Courmont for their comments
   and input on this document.


8.  References

8.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.

   [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.

8.2.  Informative References











Blau & Holmberg          Expires April 20, 2009                 [Page 8]


Internet-Draft                    MRSP                      October 2008


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 April 20, 2009                 [Page 9]


Internet-Draft                    MRSP                      October 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 April 20, 2009                [Page 10]