MSRP Connection Model: An Alternative Connection Model for the Message Session Relay Protocol (MSRP)
Let endpoints behind firewalls negotiate who initiates the connection.
Holmberg, C. and S. Blau, "An Alternative Connection Model for the Message Session Relay Protocol (MSRP)", RFC 6135, DOI 10.17487/RFC6135, February 2011, <https://www.rfc-editor.org/info/rfc6135>.
@misc{rfc6135,
series = {Request for Comments},
number = 6135,
howpublished = {RFC 6135},
publisher = {RFC Editor},
doi = {10.17487/RFC6135},
url = {https://www.rfc-editor.org/info/rfc6135},
author = {C. Holmberg and S. Blau},
title = {{An Alternative Connection Model for the Message Session Relay Protocol (MSRP)}},
pagetotal = 8,
year = 2011,
month = feb,
} RFC text
Contents
Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 6135 Ericsson
Category: Standards Track S. Blau
ISSN: 2070-1721 Ericsson AB
February 2011
An Alternative Connection Model for the
Message Session Relay Protocol (MSRP)
Abstract
This document defines an alternative connection model for Message
Session Relay Protocol (MSRP) User Agents (UAs); this model uses the
connection-oriented media (COMEDIA) mechanism in order to create the
MSRP transport connection. The model allows MSRP UAs behind Network
Address Translators (NATs) to negotiate which endpoint initiates the
establishment of the Transmission Control Protocol (TCP) connection,
in order for MSRP messages to traverse the NAT.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6135.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
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 Simplified BSD License.
Table of Contents
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Applicability Statement .........................................3
4. COMEDIA for MSRP ................................................3
4.1. General ....................................................3
4.2. a=setup ....................................................3
4.2.1. General .............................................3
4.2.2. Attribute Usage .....................................4
4.3. TLS ........................................................5
4.4. a=connection ...............................................5
4.5. MSRP Relay Connection ......................................6
5. Interoperability with the Connection Model Defined in RFC 4975 ..6
6. Security Considerations .........................................6
7. Acknowledgements ................................................7
8. References ......................................................7
8.1. Normative References .......................................7
8.2. Informative References .....................................7
1. Introduction
The Message Session Relay Protocol (MSRP) core specification
[RFC4975] states that the MSRP User Agent (UA) that sends the Session
Description Protocol (SDP) offer is "active", and it is responsible
for creating the MSRP transport connection towards the remote UA if a
new connection is required. The core specification also allows, but
does not define, alternate mechanisms for MSRP UAs to create MSRP
transport connections.
[RFC4145] defines a connection-oriented media (COMEDIA) mechanism,
which endpoints can use to negotiate the endpoint that initiates the
creation of media transport connection.
COMEDIA is especially useful when one of the endpoints is located
behind a Network Address Translator (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 and without being required to support more complex
mechanisms (e.g., "TCP Candidates with Interactive Connectivity
Establishment (ICE)" [ICE-TCP]). In addition, COMEDIA allows the
usage of identical procedures in establishing Transmission Control
Protocol (TCP) [RFC0793] connections for different types of media.
An example is the Open Mobile Alliance (OMA)-defined "Instant Message
using SIMPLE" [OMA-SIMPLE], where one MSRP UA of every MSRP transport
connection represents a media server, which is always located in the
carrier network. The media server has a globally reachable 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 that
uses COMEDIA can establish an MSRP transport connection with a remote
UA that does not support COMEDIA.
2. Terminology
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 RFC 2119 [RFC2119].
3. Applicability Statement
Support of this specification is OPTIONAL for MSRP UAs in general.
UAs that are likely to be deployed in networks with NATs SHOULD
support this specification. It will improve the odds of being able
to make TCP connections successfully traverse NATs, since UAs behind
NATs can be requested to initiate the establishment of the TCP
connections.
4. COMEDIA for MSRP
4.1. General
This section defines how an MSRP UA that supports this specification
uses the COMEDIA SDP attributes defined in [RFC4145].
4.2. a=setup
4.2.1. General
An MSRP UA uses the SDP a=setup attribute [RFC4145] in order to
negotiate which endpoint will create the MSRP transport connection
towards the other UA.
An MSRP UA MUST always include an explicit a=setup attribute in its
SDP offers and answers, since it might be 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 send the "holdconn"
attribute value. If an MSRP UA receives the "holdconn" attribute
value, it MUST ignore it and process the message as if it did not
contain an a=setup attribute.
4.2.2. Attribute Usage
When the a=setup attribute value is "actpass" or "passive", the IP
address and port values in the MSRP URI of the SDP a=path attribute
MUST contain the actual address and port values on which the UA can
receive a TCP connection for the MSRP transport connection.
In accordance with [RFC4145], if the a=setup attribute value is
"active", the port number value should be 9.
If an MSRP UA can provide a globally reachable IP address that the
other endpoint can use as a destination for a TCP connection, 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 a NAT,
and in order to be compatible with 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 UA MUST NOT use the a=setup "passive" attribute value in an SDP
offer.
The MSRP UA can determine that it provides a globally reachable IP
address in the following scenarios:
o the UA can determine that it is not located behind a NAT;
o the UA relays its MSRP transport connections via a relay (e.g., an
MSRP relay or Traversal Using Relay NAT (TURN) server); or
o the UA has used Session Traversal Utilities for NAT (STUN)
[RFC5389] signaling to retrieve the NAT address and port through
the local port to be used for the eventual transport connection,
while also having determined that the NAT has endpoint-independent
mapping and filtering behavior [RFC5382], e.g., using the
mechanism defined in [RFC5780].
Some UAs can determine whether the SIP [RFC3261] signaling has
traversed a NAT by inspecting the SIP Via header field in the 200
(OK) response to the initial SIP REGISTER request, and comparing the
IP addresses in the Via sent-by and the received header field
parameters. If the IP addresses are not the same, then the UA can
determine that there is a NAT in the path. Even though the media
transport might not traverse the NAT, it is safe to assume that it
will. This comparing mechanism does not work in all scenarios,
though. For example, if SIP a request crosses a SIP proxy before
crossing a NAT, the UA will not be able to detect the NAT by
comparing the IP addresses.
If an SDP offer includes an a=setup "actpass" attribute value, the
SDP answerer MAY include an a=setup "active" attribute value in the
SDP answer, but SHOULD include an a=setup "passive" attribute value
if it 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 an MSRP UA conformant to this document uses Transport Layer
Security (TLS), it MUST use the TLS mechanisms defined in [RFC4975]
and [RFC4976].
According to [RFC4975], the connection can be established with or
without TLS mutual authentication. In case mutual authentication is
not used, the listening device waits until it receives a request on
the connection, at which time it infers the identity of the
connecting device from the associated session description. From the
TLS authentication point of view, it is thus irrelevant whether an
endpoint takes the active or passive role.
If an MSRP UA uses a self-signed TLS certificate to authenticate
itself to MSRP peers, it also includes its certificate fingerprint in
the SDP.
Note that fingerprints can only be exchanged in peer-to-peer
communication, as MSRP relays [RFC4976] will not receive the SDP
payloads containing the fingerprint attributes.
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.
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. Interoperability with the Connection Model Defined in RFC 4975
An MSRP UA conformant to this document can interoperate with a UA
that follows the connection model defined in [RFC4975]. However, if
an MSRP UA conformant to this document is located behind a NAT, does
not proxy its MSRP communication via an MSRP relay, and receives an
SDP offer from a remote UA that follows the connection model defined
in [RFC4975], then NAT traversal can only be achieved if the MSRP UA
supports ICE [ICE-TCP] or if the network supports Session Border
Controller (SBC)-assisted NAT traversal for TCP.
6. Security Considerations
According to the connection model defined in [RFC4975], the MSRP UA
that sends the SDP offer becomes the active party, and it is
responsible for creating the MSRP transport connection towards the
remote UA if a new connection is required.
When COMEDIA is used, either the sender or the receiver of the SDP
offer can become the active party. [RFC4975] requires that the
active party immediately issue an MSRP SEND request once the
connection has been established. This allows the passive party to
bind the inbound TCP connection to the message session identified by
the session id part of its MSRP URI. The use of COMEDIA does not
change this requirement, but the sender of the SDP offer is no longer
assumed to always become the active party.
The active party also takes the role of the TLS client, if TLS is
used to protect the MSRP messages. However, there are no procedures
in [RFC4975] that would break in case the receiver of the SDP offer
takes the role of the TLS client, and the level of security provided
by TLS is not affected.
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 producing this document.
8. References
8.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145,
September 2005.
[RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed.,
"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
[RFC3261] 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.
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and
P. Srisuresh, "NAT Behavioral Requirements for TCP",
BCP 142, RFC 5382, October 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
Using Session Traversal Utilities for NAT (STUN)",
RFC 5780, May 2010.
[ICE-TCP] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
"TCP Candidates with Interactive Connectivity
Establishment (ICE)", Work in Progress, February 2011.
[OMA-SIMPLE] Open Mobile Alliance, "Instant Messaging using SIMPLE",
OMA-TS-SIMPLE_IM-V1_0-20090901-D, September 2009.
Authors' Addresses
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: christer.holmberg@ericsson.com
Staffan Blau
Ericsson AB
PO Box 407
Sweden
EMail: staffan.blau@ericsson.com
AI ELI5
On this page
§1The NAT Problem with MSRP
MSRP is a protocol for relaying messages between endpoints in a media session. Normally, the endpoint that sends the SDP offer (the "offerer") becomes the active party and must open the TCP connection to the remote endpoint.
This works fine on the open Internet, but fails when an endpoint sits behind a Network Address Translator (NAT). A NAT blocks incoming TCP connections to protect the internal network. If the offerer is behind a NAT and must open a connection to the other side, it can do so because it initiates the outbound connection. But if the other side must open a connection to the offerer behind the NAT, the NAT rejects it—the offerer never initiated communication in that direction.
This RFC solves the problem by adopting COMEDIA (Connection-Oriented Media, defined in RFC 4145), a mechanism that lets both sides negotiate which one will open the TCP connection. An endpoint behind a NAT can say "I will open the connection," guaranteeing the connection passes through its NAT.
MSRP needs to open a connection. Normally, the person who starts the conversation opens it. But if you are behind a firewall that blocks incoming connections, you must be the one to open it or the firewall will reject the other person trying to reach you.
§2COMEDIA and the a=setup Attribute
COMEDIA uses Session Description Protocol (SDP) attributes to signal connection negotiation. The key attribute is a=setup, which can have four values:
active: "I will open the TCP connection."passive: "You open the TCP connection."actpass: "I can do either; you decide."holdconn: An older value that MSRP ignores.
An MSRP endpoint must include an explicit a=setup attribute in every SDP offer and answer. This tells the other side whether the endpoint supports COMEDIA or expects the traditional MSRP connection model.
The rules are: An endpoint offering the session MUST use actpass if it can provide a globally reachable IP address (no NAT, relayed through a proxy, or using STUN to detect the NAT address). It MUST use active if it cannot. It MUST NOT use passive in an offer. When answering, the endpoint MAY use active if the offer was actpass, or it SHOULD use passive if it knows it is not behind a NAT.
In the SDP handshake, each side announces whether it will open the connection (active), wants the other side to open it (passive), or is flexible (actpass). The endpoint behind the firewall can choose to open the connection to make sure it works.
§3Address and Port in SDP
When an endpoint declares itself passive or actpass, the MSRP URI in the SDP a=path attribute MUST contain the actual IP address and port where the endpoint can receive a TCP connection. This is the listening address.
When an endpoint declares itself active, the port number in the MSRP URI should be 9, a placeholder indicating that the endpoint will connect to the other side, not listen on that port.
An MSRP endpoint can determine that it provides a globally reachable address in several ways: by detecting that it is not behind a NAT, by relaying MSRP connections through an MSRP relay or TURN server, or by using STUN signaling to discover the NAT's external address and verifying that the NAT has endpoint-independent mapping and filtering behavior. Some endpoints detect NAT by comparing SIP Via header addresses between what they sent and what the server echoed back, though this method does not work in all network topologies.
If you say you will listen for a connection, you tell the other side where to find you. If you say you will open the connection, you give a placeholder port number because you will connect outward, not listen.
§4Opening the Connection and Sending the First Message
- SDP Offer (a=setup actpass)Offerer can receive or open connection
- SDP Answer (a=setup active)Answerer will open the connection
- TCP Connect + MSRP SENDAnswerer opens connection and sends first message
Once both sides agree on connection direction via the a=setup negotiation, the active endpoint opens the TCP connection and must immediately send an MSRP SEND request. The passive endpoint waits to receive the connection and infers the identity of the connecting side from the associated session description.
The Sieve URN parameter "addrbook" is used to identify address books. The mandatory one is urn:ietf:params:sieve:addrbook:default, referring to the user's default personal address book. Scripts can also reference :addrbook:personal, :addrbook:family, :addrbook:company, or implementation-defined variations.
The active side opens the connection and says hello first. The passive side accepts the connection and knows it came from the session it negotiated. Both sides then exchange messages normally.
§5Transport Layer Security
When using Transport Layer Security (TLS) to encrypt MSRP messages, the active endpoint takes the role of TLS client, and the passive endpoint acts as TLS server. Endpoints can authenticate using self-signed certificates if they include the certificate fingerprint in the SDP.
Note that fingerprints are only exchanged in peer-to-peer communication. MSRP relays do not receive SDP payloads containing fingerprint attributes, so they cannot participate in fingerprint-based authentication.
TLS security is not affected by which endpoint is active or passive—RFC 4975 procedures remain unchanged. The level of authentication and encryption provided by TLS works the same way regardless of connection direction.
If you encrypt the messages with TLS, the side that opens the connection acts as the client, and the side that listens acts as the server. Both can prove who they are using certificate fingerprints.
§6MSRP Relays and Relay Connections
An MSRP endpoint can relay its messages through an MSRP relay (a server that forwards messages between endpoints). When an endpoint is behind an MSRP relay, it MUST always initiate the TCP connection to the relay, regardless of the a=setup attribute negotiated with the remote endpoint. This ensures the endpoint can reach the relay.
However, the endpoint will only send an MSRP SEND request if the COMEDIA negotiation makes it active. This preserves the session semantics: the passive endpoint receives the connection from the relay and binds it to the correct message session.
When you go through a relay, you must connect to the relay so it can forward your messages. But whether you actually send messages depends on the COMEDIA negotiation with the other person.
§7Backwards Compatibility and Interoperability
An MSRP endpoint that supports COMEDIA (this RFC) can interoperate with endpoints that follow only the original RFC 4975 connection model. However, if a COMEDIA-supporting endpoint is behind a NAT, does not use an MSRP relay, and receives an SDP offer from an endpoint that does not support COMEDIA, NAT traversal fails. The only solutions then are to use ICE (Interactive Connectivity Establishment) for TCP or rely on a Session Border Controller (SBC) to assist with NAT traversal.
The requirement to always include an explicit a=setup attribute helps: when an older endpoint receives it, it may not understand it, but it signals that the newer endpoint supports COMEDIA. The older endpoint can fall back to its traditional behavior.
New COMEDIA endpoints can talk to old endpoints if both are in the clear. But if a COMEDIA endpoint is behind a firewall and an old endpoint tries to connect, it will not work without a relay or a complex protocol like ICE.
§8Security Implications
COMEDIA does not change the fundamental security model. The RFC 4975 requirement that the active party immediately sends an MSRP SEND request after establishing the connection still holds—this allows the passive party to bind the inbound connection to the correct message session.
With COMEDIA, either the offer sender or the offer receiver can become active, whereas traditionally only the offer sender could. This flexibility creates no new security weakness: the mechanism for identifying which endpoint owns the connection (via the SEND request) remains the same.
If TLS is used, the active endpoint becomes the TLS client. RFC 4975 procedures, which assume the offer sender is always active, do not break when the receiver becomes active instead. The security properties of TLS are not affected by which side opens the connection or takes the TLS client role.
Implementing this RFC is optional but strongly recommended for endpoints that may be deployed behind NATs, as it significantly improves the likelihood of successful connectivity without requiring relays.
Letting either side open the connection does not make things less secure. The first message still identifies who opened the connection, and encryption works the same way.