summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6135.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6135.txt')
-rw-r--r--doc/rfc/rfc6135.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc6135.txt b/doc/rfc/rfc6135.txt
new file mode 100644
index 0000000..9ed18a3
--- /dev/null
+++ b/doc/rfc/rfc6135.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+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.
+
+
+
+Holmberg & Blau Standards Track [Page 1]
+
+RFC 6135 MSRP February 2011
+
+
+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]
+
+RFC 6135 MSRP February 2011
+
+
+ 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.
+
+
+
+
+
+
+
+Holmberg & Blau Standards Track [Page 3]
+
+RFC 6135 MSRP February 2011
+
+
+ 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]
+
+RFC 6135 MSRP February 2011
+
+
+ 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]
+
+RFC 6135 MSRP February 2011
+
+
+ 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.
+
+
+
+
+
+
+Holmberg & Blau Standards Track [Page 6]
+
+RFC 6135 MSRP February 2011
+
+
+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.
+
+
+
+
+
+Holmberg & Blau Standards Track [Page 7]
+
+RFC 6135 MSRP February 2011
+
+
+ [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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holmberg & Blau Standards Track [Page 8]
+