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
/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
(/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.
Holmberg & Blau Standards Track [Page 1]
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 Holmberg & Blau Standards Track [Page 2]
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
uasato 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.
Holmberg & Blau Standards Track [Page 3]
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 Holmberg & Blau Standards Track [Page 4]
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.
Holmberg & Blau Standards Track [Page 5]
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议