SIMPLE Working Group S. Blau
Internet-Draft Ericsson AB
Intended status: Informational C. Holmberg
Expires: December 27, 2008 Ericsson
June 25, 2008
An Alternative Connection Model for the Message Session Relay Protocol
(MSRP)
draft-blau-simple-msrp-acm-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 December 27, 2008.
Abstract
This document defines an alternative connection model for MSRP UAs.
The model differs from the standard MSRP model, as defined in RFC4975
and RFC4976, in that it uses SDP in a more conventional way when it
comes to conveying endpoint address information, and also uses
mainstream mechanisms for NAT traversal instead of using MSRP relays.
Blau & Holmberg Expires December 27, 2008 [Page 1]
Internet-Draft MRSP June 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability statement . . . . . . . . . . . . . . . . . . . 4
4. The Alternative Connection Model for MSRP . . . . . . . . . . 4
4.1. Transport connection addressing . . . . . . . . . . . . . 4
4.2. COMEDIA usage . . . . . . . . . . . . . . . . . . . . . . 5
4.2.1. a=setup . . . . . . . . . . . . . . . . . . . . . . . 5
4.2.2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.3. a=connection . . . . . . . . . . . . . . . . . . . . . 6
4.3. NAT keepalive . . . . . . . . . . . . . . . . . . . . . . 7
4.4. ICE usage . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Comparisons with draft-denis-simple-msrp-comedia . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Blau & Holmberg Expires December 27, 2008 [Page 2]
Internet-Draft MRSP June 2008
1. Introduction
MSRP [RFC4975] is designed to use MSRP relays [RFC4976] as a means
for NAT traversal and policy enforcement. However, in many SIP
networks it is often desired to deploy MSRP without the use of MSRP
relays, and instead use more general NAT traversal mechanisms - such
as COMEDIA [RFC4145] and ICE [I.D-ietf-mmusic-ice] - while also using
SIP ALG controlled media relays for more application specific policy
control.
An example is the OMA defined "Instant Message using SIMPLE" [OMA-TS-
SIMPLE_IM-V1_0-20080312-D], where the UA of one endpoint of every
MSRP transport connection is a media server located in the network.
The media server has a global address and is handling application
specific policy control as well as NAT traversal, the latter through
use of COMEDIA which all IM MSRP clients are mandated to support.
Many networks where MSRP usage is emerging also contain ALGs that are
deployed for reasons of performance monitoring, lawful intercept,
address domain bridging, interconnect SLA policy enforcement, etc. A
typical example here is the 3GPP defined Interconnect Border Control
Function (IBCF) [3GPP TS23.228], which controls a media relay that
handles all types of SIP session media (voice, video, MSRP, etc).
Due to the fact that the MSRP connection model is not in a
conventional way using the address information in the SDP c- and
m-line for negotiating transport connection endpoints, and also
checks consistence between addresses in the MSRP protocol and in the
SDP a=path line, this forces the IBCF/media relay to act as an SDP
aware MSRP B2BUA, whereas for basically all other UDP and TCP
transported based media sessions it can acts as an SDP aware Relay-
NAPT - which is much simpler than having to act as an MSRP B2BUA.
To adapt MSRP to a more conventional SDP usage, this document defines
an alternative connection model for MSRP, mandating and detailing use
of COMEDIA [RFC4145] and optional use of ICE [I-D.ietf-mmusic-ice-
tcp], and use of SDP c- and m-line address information for transport
connection set up - instead of address information in the MSRP URI in
the a=path line.
The alternative connection model defined in this document also
includes mechanisms that makes UAs conformant to this document to be
able to use [RFC4975] compliant behavior when so needed for
interacting with [RFC4975] conformant UAs.
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Blau & Holmberg Expires December 27, 2008 [Page 3]
Internet-Draft MRSP June 2008
"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
The alternative connection model for MSRP, as defined in this
document, SHOULD be used when a UA does not use an MSRP relay to
proxy its MSRP communication.
UAs conformant to this document are fully interoperable with
[RFC4975] conformant UAs, since when interacting with such UAs they
will more or less fall back to [RFC4975] compliant behavior.
However, if a UA conformant to this document is behind NAT and
receives an SDP offer from an [RFC4975] conformant UA, NAT traversal
can only be achieved if the UA supports ICE (and the network provides
TURN servers) or if the network supports SBC assisted NAT traversal
for TCP.
4. The Alternative Connection Model for MSRP
4.1. Transport connection addressing
A UA SHALL follow the conventional use of address information
received in the SDP c- and m-lines, for determining the transport
connection endpoint address:port to connect to, instead of using the
address information in the MSRP URI received in the a=path line to
determine the remote transport connection endpoint address:port.
With such usage, applying COMEDIA and ICE and TLS in SDP offer/answer
exchanges for MSRP sessions can be done more or less in the
conventional way with very little MSRP dependencies, as detailed in
this document. Furthermore, this usage also allows any ALG/SBC in
the SIP signaling path to perform media anchoring in the same way
they today do for any TCP connections not used for MSRP, i.e. by
modifying the address:port information in the c- and m-lines, and
ignoring any a=path line.
When a UA sends an SDP offer, the MSRP URI in the a=path line of the
SDP offer (and eventually in the MSRP FromPath header) does not need
to include connection address information, it is recommended to
instead include an AoR to avoid the possibility to use it for address
resolution - the AoR may be useful for debugging purposes only.
The usage of an AoR in the MSRP URI should work fine in SDP offers,
even if the SDP answerer UA is conformant to [RFC4975], since in that
Blau & Holmberg Expires December 27, 2008 [Page 4]
Internet-Draft MRSP June 2008
case it will always be the SDP offerer that will establish the
transport connection based on address information in the SDP answer -
the MSRP URI matching will still work since this only requires the
MSRP URIs in the a=path headers to be identical to the MSRP URIs in
the MSRP protocol FromPath and ToPath headers.
When a UA receives an SDP offer from an [RFC4975] conformant UE, it
needs to populate the MSRP URI in the SDP answer (and eventually in
the MSRP FromPath header) with an address or FQDN in accordance with
[RFC4975]. In order for the SDP answerer to know whether this is
necessary or not, a UA conformant to this document SHALL include, in
SDP offers and answers, an "a=msrp-acm" attribute. The presence of
the attribute will also enable ALGs/SBCs to apply normal media
anchoring procedures and need not act as MSRP B2BUAs.
In accordance with [RFC4975], for an MSRP endpoint that receives TCP
open requests to be able to use a common port for all MSRP transport
connections, the initiator of an MSRP transport connection SHALL
always after having established a new transport connection send an
MSRP message, allowing the other endpoint to establish the binding
between MSRP session and transport connection.
4.2. COMEDIA usage
4.2.1. a=setup
A UA SHALL support the a=setup attribute [RFC4145], in order to
negotiate which endpoint is to establish the transport connection for
an MSRP session.
The support of a=setup is particularly useful when one MSRP endpoint
is a media server which is not behind a NAT. This since the media
server then make sure that transport connections for MSRP media is
always set up from the UA towards the server, and ensure that
possible NATs at user premises will not interfere with the connection
setup.
A UA SHALL always include an explicit a=setup line in SDP offers and
answers, since it is sometimes useful for the other endpoint, or for
the network, to know whether the sending endpoint supports a=setup or
not.
The a=setup "active", "actpass" and "passive" values SHALL be
supported, while the "holdcon" value MUST NOT be used.
Note: When the a=setup value is "actpass" or "passive", the IP
address:port value in the SDP MUST contain the actual address:port on
which the UA can receive a TCP Open request for the MSRP transport
Blau & Holmberg Expires December 27, 2008 [Page 5]
Internet-Draft MRSP June 2008
connection.
If the a=setup value is "active", the port number value MUST either
be the actual port number that will be used for the TCP endpoint or
the port value 9.
The a=setup "actpass" value SHALL be used in SDP offers whenever an
UA can determine a valid WAN transport endpoint address:port, i.e. an
address:port that the other endpoint can use as destination for a TCP
Open request. This is in order to a) allow the other endpoint to
answer with "a=setup:active" if it is behind NAT, and b) to be
compatible with MSRP endpoints that do not support COMEDIA and thus
always will always act as passive endpoints. If not the actual
transport address can be provided then the a=setup "active" value
MUST be used.
A valid WAN transport address:port can be determined 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 it 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 the UA is located behind a NAT, both SIP signaling and media
transport will pass trough it, and a UA can determine whether the
media transport will be NATed by inspecting the SIP Via header in the
200 OK response to the initial REGISTER request, comparing the IP
addresses in the Via sent-by and received parameters. If these are
not the same then there is a NAT in the path.
If an SDP offer includes a=setup:actpass, the SDP answer MAY include
a=setup:active, but SHOULD include a=setup:passive if the SDP
answerer knows that it is not located behind a NAT.
4.2.2. TLS
If a TLS transport connection for MSRP is negotiated, the client and
server TLS roles MUST negotiate the relevant parameter as specified
by 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.
4.2.3. a=connection
The a=connection attribute is defined as a means for SDP negotiation
of transport connection reuse. However, it seems that its use is
limited to mid-session SDP offer/answer exchanges while [RFC4976]
requires initial SDP offer/answer exchanges to result in reuse of a
Blau & Holmberg Expires December 27, 2008 [Page 6]
Internet-Draft MRSP June 2008
transport connection established via another existing SIP session at
the same UA, if the SDP for the remote endpoint of that connection
indicates the same host address, port and URI scheme.
A UA SHALL use a=connection lines for mid-session re-negotiation of
transport connection for an MSRP session, but SHOULD not include any
a=connection line in initial SDP offer/answer exchanges (if present,
it SHALL be ignored by the receiving UA). Instead the connection
reuse principles for initial SDP offer/answer exchanges for an MSRP
session SHALL be in accordance with [RFC4975].
4.3. NAT keepalive
An MSRP endpoint behind NAT MUST keep the NAT binding alive, in
accordance with chapter 10 in [I.D.ietf-mmusic-ice]. The character
string CRLF SHOULD be sent as NAT keepalive, but if the transport
connection was established using ICE then STUN MAY alternatively be
used.
4.4. ICE usage
A UA SHOULD support ICE [I.D.draft-ietf-mmusic-ice-tcp]. However,
the UA SHALL when using ICE for MSRP transport connection
establishment before starting to send any TCP Open requests perform
the normal MSRP checks for possible reuse of an existing transport
connection. If such is identified, the UA SHOULD preempt ICE
processing and send a new SIP offer which indicates a=connection:
existing and the SDP information for the selected connection.
5. Comparisons with draft-denis-simple-msrp-comedia
The denis draft extends MSRP SDP with COMEDIA in much the same way as
described in this document, but is somewhat looser in how COMEDIA can
be used. It does not for example mandate the usage of port 9 in SDP
if not a valid receive port is indicated and it allows a UA that is
not behind NAT to send an offer with a=setup:passive as an
alternative to a=setup:actpass.
The major differences between this draft and the denis draft,
however, is that the denis draft:
- only provides means for NAT traversal when there is a NAT only in
front of one endpoint.
- does not mention that for COMEDIA to be able to be used as a means
for NAT traversal the UA must also support sending NAT keepalives.
Blau & Holmberg Expires December 27, 2008 [Page 7]
Internet-Draft MRSP June 2008
- does not discuss the a=connection attribute in relation to MSRP
transport connection reuse between different SIP sessions
- does not describe how ICE could be used for MSRP connection
establishment (it does refer to an expired draft on this issue)
- maintains the [RFC4975] model, using the MSRP URI for addressing
purposes, which means that any procedures dependent on address
information in SDP need to be special for MSRP, and any SBC in the
session path must act as SDP aware MSRP B2BUAs.
6. Security Considerations
TBD
7. IANA Considerations
This document declares a new SDP attribute, "a=msrp-acm".
8. Acknowledgements
Thanks to Hadriel Kaplan for his comments.
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.
Blau & Holmberg Expires December 27, 2008 [Page 8]
Internet-Draft MRSP June 2008
[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.
9.2. Informative References
Authors' Addresses
Staffan Blau
Ericsson AB
P.O Box 407
Sweden
Email: staffan.blau@ericsson.com
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com
Blau & Holmberg Expires December 27, 2008 [Page 9]
Internet-Draft MRSP June 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Blau & Holmberg Expires December 27, 2008 [Page 10]