[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-blau-simple-msrp-acm) 00 01 02 03 04 05 06 07 08 09 10 RFC 6135

SIMPLE Working Group                                         C. Holmberg
Internet-Draft                                                  Ericsson
Expires: May 22, 2010                                            S. Blau
                                                             Ericsson AB
                                                       November 18, 2009


 An Alternative Connection Model for the Message Session Relay Protocol
                                 (MSRP)
                   draft-ietf-simple-msrp-acm-02.txt

Abstract

   This document defines an alternative connection model for MSRP UAs,
   which uses COMEDIA in order to create the MSRP transport connection.
   The model allows MSRP UAs which are located behind NATs to indicate
   that they want to initiate the establishment of the TCP connection
   towards the remote MSRP UA, in order for MSRP messages to traverse
   the NAT.  The document also defines how an MSRP UA which is located
   behind a NAT keeps the NAT binding alive.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 May 22, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Holmberg & Blau           Expires May 22, 2010                  [Page 1]

Internet-Draft                    MRSP                     November 2009


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Applicability statement . . . . . . . . . . . . . . . . . . . . 3
   4.  COMEDIA for MSRP  . . . . . . . . . . . . . . . . . . . . . . . 4
     4.1.  General . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     4.2.  a=setup . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     4.3.  TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     4.4.  a=connection  . . . . . . . . . . . . . . . . . . . . . . . 6
     4.5.  MSRP relay connection . . . . . . . . . . . . . . . . . . . 6
   5.  NAT keepalive . . . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   8.  Change Log  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8





















Holmberg & Blau           Expires May 22, 2010                  [Page 2]

Internet-Draft                    MRSP                     November 2009


1.  Introduction

   [RFC4975] defines that the MSRP UA which sends the SDP offer is
   "active", and is this responsible to create the MSRP transport
   connection towards the remote UA.  [RFC4975] also allows, but does
   not define, MSRP UAs to use other mechanisms in order to create the
   MSRP transport connection.

   [RFC4145] defines a mechanism, COMEDIA, which endpoints can use to
   negotiate which endpoint will create the media transport connection.

   COMEDIA is especially useful when an endpoint is located behind a
   NAT.  The endpoint can use the mechanism to indicate that it will
   create the media transport connection, in order for the media to
   traverse the NAT without the usage of relays.

   An example is the OMA defined "Instant Message using SIMPLE" [OMA-TS-
   SIMPLE_IM-V1_0-20090901-D], where one MSRP UA of every MSRP transport
   connection represents a media server, and which is always located in
   the network.  The media server has a global address and handles
   application specific policy control as well as NAT traversal.  The
   OMA IM uses COMEDIA for NAT traversal, and all IM MSRP clients
   support COMEDIA.

   This document defines how an MSRP UA uses COMEDIA in order to
   negotiate which UA will create the MSRP transport TCP connection
   towards the other UA.  The document also defines how an MSRP UA can
   establish an MSRP transport connection with a remote UA that does not
   support COMEDIA.


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

   An MSRP UA SHOULD use the alternative connection model, defined in
   this document, when the UA does not use an MSRP relay in order to
   proxy its MSRP media.

   An MSRP UA conformant to this document can interop with an [RFC4975]
   conformant MSRP UA.  However, if an MSRP UA conformant to this
   document is located behind NAT, and does not proxy its MSRP



Holmberg & Blau           Expires May 22, 2010                  [Page 3]

Internet-Draft                    MRSP                     November 2009


   communication via an MSRP-Relay node, and the UA receives an SDP
   offer from an [RFC4975] conformant remote UA, NAT traversal can only
   be achieved if the MSRP UA supports ICE and the network provides TURN
   servers, or if the network supports SBC assisted NAT traversal for
   TCP.


4.  COMEDIA for MSRP

4.1.  General

   This section defines how an MSRP UA uses the COMEDIA SDP attributes
   defined in [RFC4145], how an MSRP UA can use the COMEDIA TLS
   extensions [RFC4572], and how an MSRP UA keeps a NAT binding alive.

4.2.  a=setup

   An MSRP UA MUST support the SDP a=setup attribute [RFC4145], in order
   to negotiate which endpoint will create the MSRP transport connection
   towards the other UA.

   The a=setup attribute is particularly useful when one MSRP UA
   represents a network media server, or any other entity which is not
   located behind a NAT.  The media server can ensure that the user MSRP
   UAs will create the MSRP transport connections towards the server, so
   that possible NATs at user premises will not interfere with the
   connection creation.

   An MSRP UA MUST always include an explicit a=setup attribute in its
   SDP offers and answers, since it is sometimes useful for the other
   endpoint, or for entities in the network, to know whether the UA
   supports COMEDIA or not.

   An MSRP UA MUST support the a=setup "active", "actpass" and "passive"
   attribute values.  An MSRP UA MUST NOT use the a=setup "holdcon"
   attribute value.

   When the a=setup attribute value is "actpass" or "passive", the IP
   address:port value in the MSRP URI of the SDP a=path attribute 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 attribute value is "active", the port number value
   MUST either be the actual port number that the MSRP UA will use for
   the TCP endpoint, or the port value 9.

   If an MSRP UA can determine a valid WAN transport endpoint address:
   port, i.e. an address:port that the other endpoint can use as



Holmberg & Blau           Expires May 22, 2010                  [Page 4]

Internet-Draft                    MRSP                     November 2009


   destination for a TCP Open request, the UA MUST use the a=setup
   "actpass" attribute value in SDP offers.  This is in order to allow
   the remote UA to send an SDP answer with an a=setup "active"
   attribute value if the UA is located behind NAT, and in order to be
   compatible with MSRP UAs that do not support COMEDIA and thus always
   will always act as passive endpoints.  If an MSRP UA cannot provide
   the actual transport address, the UA MUST use the a=setup "active"
   attribute value.

   An MSRP UA can determine a valid WAN transport address:port 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 the UA
   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 an MSRP UA is located behind a NAT, both SIP signaling and MSRP
   media will pass trough the NAT, and a UA can determine whether the
   media transport will be NATed by inspecting the SIP Via header in the
   200 (OK) response if the initial REGISTER request, by comparing the
   IP addresses in the Via sent-by and received parameters.  If these
   are not the same then the UA can determine that there is a NAT in the
   path.

   If an SDP offer includes an a=setup "actpass" attribute value, the
   SDP answer MAY include an a=setup "active" attribute value, but
   SHOULD include a=setup "passive" attribute value if the SDP answerer
   knows that it is not located behind a NAT.

   Once the active UA has established the MSRP transport connection, the
   UA MUST immediately send an MSRP SEND request, as defined in
   [RFC4975].

   NOTE: According to [RFC4975] the initiating UA is always active, but
   when COMEDIA is used the a=setup attribute is used to negotiate which
   UA becomes active.

4.3.  TLS

   If MSRP UAs negotiate a TLS transport connection for MSRP, the client
   and server TLS roles MUST negotiate the relevant parameter as defined
   in 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.






Holmberg & Blau           Expires May 22, 2010                  [Page 5]

Internet-Draft                    MRSP                     November 2009


4.4.  a=connection

   MSRP UAs MUST NOT use the SDP a=connection attribute.  [RFC4975]
   defines connection reuse procedures for MSRP, and this document does
   not modify those procedures.

   If an MSRP UA receives an a=connection attribute, the UA MUST ignore
   it.

   NOTE: If an MSRP UA uses ICE [I.D.ietf-mmusic-ice] when it
   establishes the MSRP transport connection, the UA needs to perform
   the normal MSRP checks for possible reuse of an existing transport
   connection before it sends any TCP Open requests.

4.5.  MSRP relay connection

   If an MSRP UA is located behind an MSRP relay [RFC4976], the UA MUST
   always initiate a transport connection towards the relay, no matter
   what value the client has provided in the a=setup attribute.

   NOTE: Even if an MSRP UA initiates the TCP connection towards its
   relay, the UA will only send a SEND request if the UA is active,
   based on the COMEDIA negotiation.


5.  NAT keepalive

   If an MSRP UA is located behind a NAT the UA MUST keep the NAT
   binding alive, in accordance with section 10 of [I.D.ietf-mmusic-
   ice].  The UA SHOULD use the character string CR-LF as NAT keepalive.
   However, if the NAT traversal method selected by ICE was based on
   successful connectivity checks, using STUN, then the UA MAY
   alternatively use STUN as defined in [I.D-ietf-mmusic-ice].


6.  Security Considerations

   The procedures define in this document do not impact the security
   characteristics defined in [RFC4975].


7.  Acknowledgements

   Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel
   Kaplan, Adam Roach and Robert Sparks for their guidance and input in
   order to produce this document.





Holmberg & Blau           Expires May 22, 2010                  [Page 6]

Internet-Draft                    MRSP                     November 2009


8.  Change Log

   [RFC EDITOR NOTE: Please remove this section when publishing]

   Changes from draft-ietf-simple-acm-01
   o  Procedures for using SDP c/m for routing of MSRP messages removed.
   o  Procedures related to modification of MSRP address information by
      intermediates moved to separate document.
   o  Solution to open issue on usage of the SDP a=connection
      implemented.


9.  References

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

   [I-D.ietf-mmusic-ice]
              Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols",
              draft-ietf-mmusic-ice-19 (work in progress), October 2007.






Holmberg & Blau           Expires May 22, 2010                  [Page 7]

Internet-Draft                    MRSP                     November 2009


9.2.  Informative References


Authors' Addresses

   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: christer.holmberg@ericsson.com


   Staffan Blau
   Ericsson AB
   P.O Box 407
   Sweden

   Email: staffan.blau@ericsson.com































Holmberg & Blau           Expires May 22, 2010                  [Page 8]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/