SIMPLE Working Group C. Holmberg
Internet-Draft Ericsson
Expires: June 20, 2010 S. Blau
Ericsson AB
December 17, 2009
An Alternative Connection Model for the Message Session Relay Protocol
(MSRP)
draft-ietf-simple-msrp-acm-03.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 behind NATs to negotiate which UA will
initiate the establishment of the TCP connection, 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 June 20, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Holmberg & Blau Expires June 20, 2010 [Page 1]
Internet-Draft MRSP December 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 June 20, 2010 [Page 2]
Internet-Draft MRSP December 2009
1. Introduction
[RFC4975] defines that the MSRP UA which sends the SDP offer is
"active", and it is responsible to create the MSRP transport
connection towards the remote UA if a new connection is required.
[RFC4975] allows other mechanisms to be used to create MSRP transport
connection, but does not define any other mechanisms.
[RFC4145] defines a mechanism, COMEDIA, which endpoints can use to
negotiate the endpoint which initiates the creation of 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 (Open Mobile Alliance) 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, which
is always located in the network. The media server has a global IP
address and handles application specific policy control as well as
NAT traversal. The OMA IM (Instant Messenger) uses COMEDIA for NAT
traversal, and all OMA 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 which
uses COMEDIA 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 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
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
Holmberg & Blau Expires June 20, 2010 [Page 3]
Internet-Draft MRSP December 2009
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 a=setup attribute allows the media server
to ensure that MSRP UAs create the MSRP transport connections towards
the server, so that NATs at user's 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 provide a global IP address that the other endpoint
can use as 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
Holmberg & Blau Expires June 20, 2010 [Page 4]
Internet-Draft MRSP December 2009
compatible with MSRP UAs that do not support COMEDIA and thus always
will act as passive endpoints. If an MSRP UA cannot provide the
actual transport address, the UA MUST use the a=setup "active"
attribute value.
The MSRP UA can determine that it provides a global IP address in the
following scenarios:
- the UA can determine that it is not located behind a NAT;
- the UA relays its MSRP transport connections via a relay (e.g.
MSRP relay or TURN server); or
- the UA has used STUN signalling to retrieve NAT address:port
through the local port to be used for the the eventual transport
connection, 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 role
of TLS client and TLS server 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 June 20, 2010 [Page 5]
Internet-Draft MRSP December 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, Robert Sparks, Salvatore Loreto and Shida
Schubert for their guidance and input in order to produce this
document.
Holmberg & Blau Expires June 20, 2010 [Page 6]
Internet-Draft MRSP December 2009
8. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-simple-mscp-acm-02
o Changes based on WGLC comments from Salvatore Loreto and Shida
Schubert.
Changes from draft-ietf-simple-msrp-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",
Holmberg & Blau Expires June 20, 2010 [Page 7]
Internet-Draft MRSP December 2009
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
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 June 20, 2010 [Page 8]
