SIMPLE Working Group C. Holmberg
Internet-Draft S. Blau
Intended status: Standards Track Ericsson
Expires: December 11, 2011 June 9, 2011
Alternative Connection Establishment (ACE) for the Message Session Relay
Protocol (MSRP)
draft-ietf-simple-msrp-sessmatch-12.txt
Abstract
This document defines an MSRP extension, Alternative Connection
Establishment (ACE). Support of the extension is optional. MSRP
endpoints can implement the extension in order to allow MSRP
communication in networks where SIP Application Layer Gateways (ALGs)
anchor the MSRP connection, without the need for the ALGs to enable
MSRP B2BUA functionality. The document also defines a Session
Description Protocol (SDP) [RFC4566] attribute, a=msrp-ace, that can
be used by MSRP endpoints to indicate support of the ACE extension.
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 11, 2011.
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
Holmberg & Blau Expires December 11, 2011 [Page 1]
Internet-Draft MRSP June 2011
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Applicability statement . . . . . . . . . . . . . . . . . . . 4
4. Alternative Connection Establishment Mechanism . . . . . . . . 4
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. MSRP Offerer Procedures . . . . . . . . . . . . . . . . . 5
4.3. MSRP Answerer Procedures . . . . . . . . . . . . . . . . . 6
4.4. Usage With The Alternative Connection Model . . . . . . . 7
5. ALG assumptions . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. MSRP awareness . . . . . . . . . . . . . . . . . . . . . . 7
5.3. TCP connection reuse . . . . . . . . . . . . . . . . . . . 8
5.4. SDP integrity . . . . . . . . . . . . . . . . . . . . . . 8
5.5. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6.1. Man in the middle . . . . . . . . . . . . . . . . . . . . 9
6.2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7.1. IANA Registration of the SDP a=msrp-ace attribute . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Holmberg & Blau Expires December 11, 2011 [Page 2]
Internet-Draft MRSP June 2011
1. Introduction
The Message Session Relay Protocol (MSRP) [RFC4975] is designed to
use MSRP relays [RFC4976] as a means for Network Address Translation
(NAT) traversal and policy enforcement.
However, many Session Initiation Protocol (SIP) [RFC3261] networks,
in which MSRP usage is emerging, also contain SIP Application Layer
Gateways (ALGs), that anchor and controls media, perform tasks such
as NAT traversal, performance monitoring, lawful intercept, address
domain bridging, interconnect Service Layer Agreement (SLA) policy
enforcement, etc. An example is the Interconnection Border Control
Function (IBCF) [3GPP.23.228], defined by the 3rd Generation
Partnership Project (3GPP). The IBCF controls a media relay that
handles all types of SIP session media (voice, video, MSRP, etc).
MSRP, as defined in RFC 4975 [RFC4975] and RFC 4976 [RFC4976], does
not work when an MSRP endpoints communicate with such ALGs, unless
the ALGs implement MSRP Back-To-Back User Agent (B2BUA)
functionality. The reason is that ALGs modify the address:port
information in SDP c/m-line in order to anchor media, and since the
active MSRP UA establishes the MSRP TCP connection based on the MSRP
URI of the SDP a=path attribute, this means that the MSRP connection
will not, unless the ALG also modifies the MSRP URI of the topmost
SDP a=path attribute be routed through the ALG, which in many
scenarios will prevent the MSRP connection from being established.
However, if the ALG modifies the MSRP URI of the SDP a=path
attribute, then the MSRP URI comparison procedure [RFC4975], which
requires consistency between the address information in the MSRP
messages and the address information carried in the MSRP URI of the
SDP a=path attribute, will fail. The matching will fail if ALGs
modify the address information in the MSRP URI of the SDP a=path
attribute, but do not enable MSRP B2BUA functionality and perform the
corresponding modification in the associated MSRP messages. However,
the enabling of MSRP B2BUA functionality requires substantially more
resource usage in the ALG, that normally result in negative
performance impact.
This specification defines an MSRP extension, Alternative Connection
Establishment (ACE), that in certain cases allows MSRP endpoints to
communicate with ALGs without a need for the ALGs to enable MSRP
B2BUA functionality. In such cases, ALGs that anchor the MSRP
connection simply modify the SDP c/m-line address information
(similar to what it does for non-MSRP media types), and MSRP
endpoints that support the ACE extension can use the SDP c/m-line
address information for establishing the TCP (or TLS) connection to
be used for sending and receiving of MSRP messages.
Holmberg & Blau Expires December 11, 2011 [Page 3]
Internet-Draft MRSP June 2011
The ACE extension is fully backward compatible. In scenarios where
MSRP endpoints that do not support the ACE extension are able to
establish MSRP connectivity, an MSRP endpoint that supports the ACE
extension behaves in the same way as an MSRP endpoint that does not
support it. The ACE extension only provides an alternative mechanism
for negotiating and providing the address information for the MSRP
TCP connection. Once the MSRP TCP connection has been created, an
MSRP endpoint that supports the ACE extension MUST act according to
the procedures (e.g. for creating MSRP messages, performing checks
when receiving MSRP messages etc) defined in RFC 4975 (and RFC 4976,
when it is using a relay for MSRP communication).
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].
In this specification the terminology "fingerprint based TLS
authentication" and "name based TLS authentication" are used to refer
to the two cases where:
1. An MSRP endpoint uses a self-signed TLS certificate and sends a
certificate fingerprint in SDP (fingerprint based TLS
authentication).
2. An MSRP endpoint uses a certificate from a well known certificate
authority and the other endpoint matches the hostname in the received
TLS communication SubjectAltName parameter towards the hostname
received in the MSRP URI in SDP (name based TLS authentication).
3. Applicability statement
This document defines an MSRP extension, Alternative Connection
Establishment (ACE). Support of the extension is optional. MSRP
endpoints can implement the extension in order to allow MSRP
communication in networks where SIP Application Layer Gateways (ALGs)
anchor the MSRP connection, without the need for the ALGs to enable
MSRP B2BUA functionality.
4. Alternative Connection Establishment Mechanism
Holmberg & Blau Expires December 11, 2011 [Page 4]
Internet-Draft MRSP June 2011
4.1. General
This section defines how an MSRP endpoint that supports the ACE
extension generates SDP offers and answers for MSRP, and what SDP
information elements the MSRP endpoint uses when creating the TCP
connection for the MSRP messages.
4.2. MSRP Offerer Procedures
When an MSRP endpoint sends an SDP offer for MSRP, it generates the
SDP offer according to the procedures in RFC 4975 (and RFC 4976, if
it is using a relay for MSRP communication), with the following
additions and modifications:
1) The MSRP endpoint MUST include an SDP a=msrp-ace attribute in the
MSRP media description of the SDP offer.
2) If the MSRP endpoint is not using a relay for MSRP communication,
it MUST include an SDP a=setup attribute in the MSRP media
description of the SDP offer, according to the procedures in RFC
6135.
3) If the MSRP endpoint is using a relay for MSRP communication, it
MUST include the address information on the relay (the MSRP URI of
the topmost SDP a=path attribute), rather than the address
information of itself, in the SDP c/m-line associated with the MSRP
media description. In addition, it MUST include an SDP a=setup:
passive attribute in the MSRP media description of the SDP offer.
When the MSRP endpoint receives the first SDP answer to the SDP offer
above, and the SDP answer indicates that the offered MSRP media has
been accepted by the remote MSRP endpoint (i.e. the port number of
the MSRP media description is not set to zero), if the MSRP media
description of the SDP answer does not contain an SDP a=msrp-ace
attribute, the MSRP endpoint MUST check whether any of the following
criteria is fulfilled:
1) The SDP c/m-line address information associated with the MSRP
media description does not match the information in the MSRP URI of
the topmost SDP a=path attribute, and the MSRP media description
contains an SDP a=setup:active attribute (indicating that the remote
MSRP endpoint is "active").
2) The MSRP media description contains multiple SDP a=path attributes
(indicating that MSRP relays are used).
If any, or both, of the criteria above is fulfilled, the MSRP
endpoint MUST fallback to RFC 4975 behavior, by sending a new SDP
Holmberg & Blau Expires December 11, 2011 [Page 5]
Internet-Draft MRSP June 2011
offer according to the procedures in RFC 4975 and RFC 4976. The new
offer MUST NOT contain an SDP a=msrp-ace attribute.
NOTE: In the absence of the SDP a=msrp-ace attribute in the new
offer, the ALG will in all cases have to, in order to be able to
anchor MSRP media, enable MSRP B2BUA functionality.
NOTE: The MSRP endpoint can send the new offer within the existing
early dialog [RFC3261], or it can terminate the early dialog and
establish a new dialog by sending the new offer in a new initial
INVITE request.
In all other cases, where the MSRP endpoint becomes "active", it MUST
use the SDP c/m-line for establishing the MSRP TCP connection. If
the MSRP endpoint becomes "passive", it will wait for the remote MSRP
endpoint to establish the TCP connection, according to the procedures
in RFC 4975.
4.3. MSRP Answerer Procedures
When an MSRP endpoint receives an SDP offer for MSRP, if the MSRP
media description does not contain an SDP a=msrp-ace attribute, the
MSRP endpoint MUST check whether any of the following criteria is
fulfilled:
1) The SDP c/m-line address information associated with the MSRP
media description does not match the information in the MSRP URI of
the topmost SDP a=path attribute, and the remote MSRP endpoint will
become "active" (either by default, or by negotiation using the
procedures in RFC 6135).
2) The MSRP media description contains multiple SDP a=path attributes
(indicating that MSRP relays are used).
3) The MSRP endpoint uses a relay for MSRP communication, and is not
able to become "passive" (the MSRP media description of the offer
contains an SDP a=setup:passive attribute).
If any, or all, of the criteria above is fulfilled, the MSRP endpoint
MUST fallback to RFC 4975 behavior, and generate the associated SDP
answer according to the procedures in RFC 4975 and RFC 4976. The
MSRP endpoint MUST NOT insert an SDP a=msrp-ace attribute in the MSRP
media description of the SDP answer.
In all other cases, the MSRP endpoint generates the associated SDP
answer according to the procedures in RFC 4975 and RFC 4976, with the
following additions and modifications:
Holmberg & Blau Expires December 11, 2011 [Page 6]
Internet-Draft MRSP June 2011
1) The MSRP endpoint MUST include an SDP a=msrp-ace attribute in the
MSRP media description of the SDP answer.
2) If the MSRP endpoint is not using a relay for MSRP communication,
it MUST include an SDP a=setup attribute in the MSRP media
description of the answer, according to the procedures in RFC 6135.
3) If the MSRP endpoint is using a relay for MSRP communication, it
MUST include the address information on the relay (the MSRP URI of
the topmost SDP a=path attribute), rather than the address
information of itself, in the SDP c/m-line associated with the MSRP
media description. In addition, it MUST include an SDP a=setup:
passive attribute in the MSRP media description of the SDP offer.
If the MSRP endpoint included an SDP a=msrp-ace attribute in the MSRP
media description of the SDP answer, and if the MSRP endpoint becomes
"active", it MUST use the received SDP c/m-line for establishing the
MSRP TCP connection. If the MSRP endpoint becomes "passive", it will
wait for the remote MSRP endpoint to establish the TCP connection,
according to the procedures in RFC 4975.
4.4. Usage With The Alternative Connection Model
An MSRP endpoint that supports the ACE extension MUST in addition
also support the mechanism defined in RFC 6135, as it extends the
number of scenarios where the ACE extension can be used, and ALGs do
not need to enable MSRP B2BUA functionality. An example is where a
MSRP endpoint is using a relay for MSRP communication, and it needs
to be "passive" in order to use the ACE extension (instead of doing a
fallback to RFC 4975 behavior.
5. ALG assumptions
5.1. General
This document does not specify explicit ALG behavior, eventhough some
of the procedures will be enabled by ALGs. However, as the main
reason behind the ACE extension is to allow MSRP endpoints to
communicate in networks where ALGs are present, this document makes
certain assumptions regarding to how such ALGs behave.
5.2. MSRP awareness
This document assumes that an ALG, in order to support
interoperability between UAs that support the ACE extension and UAs
that do not support the extension, is MSRP aware, meaning that it
implements MSRP B2BUA functionality, and that it enables that
Holmberg & Blau Expires December 11, 2011 [Page 7]
Internet-Draft MRSP June 2011
functionality in cases where support of the ACE extension is not
indicated. In cases where support of the ACE extension is indicated
by at least one MSRP endpoint, the ALG can simply modifies the SDP
c/m-line address information for the MSRP connection. However, MSRP
communication will work if the ALG enables MSRP B2BUA functionality
also in such cases.
5.3. TCP connection reuse
When the ACE extension is used, in cases where ALGs do not need to
enable MSRP B2BUA functionality, the ALGs are not required to parse
and modify the MSRP payload. An ALG that does not parse the MSRP
payload might not enable re-usage of TCP connections for multiple
MSRP sessions. Instead, in order to associate an MSRP message with a
specific session, the ALG often assigns a unique local address:port
combination for each MSRP session.
5.4. SDP integrity
This document assumes that ALGs are able to modify the SDP address
information associated with the MSRP media, and therefore can not be
deployed in environments that require SIP identity [RFC4916] based
peer-to-peer SDP protection.
5.5. TLS
This document considers two approaches how an ALG handles TLS
protected MSRP connections.
In the first approach, the ALG relays the MSRP media packets at the
transport layer. The TLS handshake and resulting security
association (SA) are established peer-to-peer between the MSRP
endpoints. The ALG will see encrypted MSRP media packets, but is
unable to inspect the cleartext content.
In the second approach, the ALG acts as a TLS B2BUA, meaning that
separate SAs are established between the ALG and each MSRP endpoint.
The ALG decrypts MSRP media packets received from one MSRP endpoint,
and then re-encrypts them before sending them toward the other MSRP
endpoint. With this approach, the ALG can inspect and modify the
MSRP message content.
6. Security Considerations
Holmberg & Blau Expires December 11, 2011 [Page 8]
Internet-Draft MRSP June 2011
6.1. Man in the middle
In some cases, where MSRP B2BUA functionality does not need to be
enabled, the ACE extension makes it easier for a man in the middle
(MiTM) to transparently insert itself in the communication between
MSRP endpoints in order to monitor or record unprotected MSRP
communication. It does not however make it easier for a MiTM to
monitor TLS protected MSRP, or in any significant way modify TLS
protected MSRP content or even find out that the packets contain MSRP
messages, since that would require the MiTM to implement MSRP B2BUA
functionality, no matter if UAs support the ACE extension or not. It
would thus require the MiTM to terminate the TCP/TLS/MSRP connection
in both directions.
6.2. TLS
The ACE extension supports the usage of name based authentication for
TLS, also in the presence of ALGs.
NOTE: If an ALG acts as a TLS B2BUA, MSRP endpoints will also be able
to use fingerprint based authentication for TLS, no matter if they
support the ACE extension or not. In such cases, as the ALG acts as
a TLS endpoints, MSRP endpoints might be given an incorrect
impression that there is an end-to-end SA between the MSRP endpoints.
If an ALG does not act as a TLS B2BUA, fingerprint based
authentication will not work, as the "SIP Identity" based integrity
protection of SDP will break. Therefore, in addition to the
authentication mechanisms defined in RFC 4975, an MSRP endpoint
supporting the ACE extension SHOULD also support an authentication
mechanism that does not rely on peer-to-peer SDP integrity.
It is RECOMMENDED that an MSRP endpoint supports one of the following
authentication mechanisms:
1) TLS certificates together with support of interacting with a
Certificate Management Service [ref to draft-ietf-sip-certs], to
which it publishes the public version of its own self-signed
certificate and from which it fetches on need the public certificates
of other endpoints.
2) TLS-PSK managed e.g by MIKEY-TICKET based Key Management and Key
Management Service [RFC6043].
NOTE: 3GPP has specified usage of the MIKEY-TICKET based Key
Management and Key Management Service authentication mechanism for
the IP Multimedia Subsystem (IMS).
Holmberg & Blau Expires December 11, 2011 [Page 9]
Internet-Draft MRSP June 2011
When an MSRP endpoint generates an SDP offer for MSRPS it MUST, in
addition to the SDP attributes associated with the TLS authentication
mechanisms described in RFC 4975, it MUST include any information
elements associated with the other authentication mechanisms that it
supports.
Unless the MSRP endpoints are able to use name based authentication,
and they support a common authentication mechanism, they MUST use
that mechanism. If the MSRP endpoints do not support such common
authentication mechanism, they MUST try fingerprint based
authentication, which will succeed if there are no ALGs present. If
that also fails, the MSRP endpoints MUST either:
1) Consider the TLS authentication as failed, in accordance with RFC
4975; or
2) If the SIP signalling between the MSRP endpoints is protected
through e.g. SIPS, use fingerprint based authentication without
requiring peer-to-peer SDP integrity, and thus trust the network
endpoints in the signaling path for SDP integrity.
NOTE: As defined in RFC 4975, if TLS authentication fails, the user
need to be able to decide whether to try to anyway establish an MSRP
connection.
7. IANA Considerations
7.1. IANA Registration of the SDP a=msrp-ace attribute
This section registers a new SDP attribute, a=msrp-ace. The required
information for this registration, as specified in RFC 4566, is:
Holmberg & Blau Expires December 11, 2011 [Page 10]
Internet-Draft MRSP June 2011
Contact name: Christer Holmberg
Contact e-mail: christer.holmberg@ericsson.com
Attribute name: a=msrp-ace
Type of attribute: media level
Purpose: This attribute is used to indicate support of the MSRP
Alternative Connection Establishment (ACE) extension
defined in RFC XXXX. When present in an MSRP media
description of an SDP body, it indicates that
the sending UA supports the ACE the mechanism.
Values: The attribute does not carry a value
Charset dependency: no
8. Acknowledgements
Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel
Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto, Shida Schubert,
Ted Hardie, Richard L Barnes, Inaki Baz Castillo and Saul Ibarra
Corretge for their guidance and input in order to produce this
document.
9. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-simple-msrp-sessmatch-11
o Modification of the sessmatch mechanism.
o - Extension name changed to Alternative Connection Establishment
(ACE)
o - Session matching procedure no longer updated.
o - SDP c/m-line used for MSRP TCP connection.
o - sessmatch option-tag removed.
o - a=msrp-ace attribute defined.
o - Support of RFC 6135 mandatory.
Changes from draft-ietf-simple-msrp-sessmatch-10
o Sessmatch option-tag added, based on WG discussions and concensus.
Changes from draft-ietf-simple-msrp-sessmatch-08
Holmberg & Blau Expires December 11, 2011 [Page 11]
Internet-Draft MRSP June 2011
o OPEN ISSUE regarding the need for a sessmatch option-tag removed.
Changes from draft-ietf-simple-msrp-sessmatch-07
o Sessmatch defined as an MSRP extension, rather than MSRP update
o Additional security considerations text added
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, 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.
[RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model
for the Message Session Relay Protocol (MSRP)", RFC 6135,
February 2011.
10.2. Informative References
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, June 2007.
[RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based
Modes of Key Distribution in Multimedia Internet KEYing
(MIKEY)", RFC 6043, March 2011.
[3GPP.23.228]
3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP
TS 23.228 5.15.0, June 2006.
Holmberg & Blau Expires December 11, 2011 [Page 12]
Internet-Draft MRSP June 2011
Authors' Addresses
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com
Staffan Blau
Ericsson
Stockholm 12637
Sweden
Email: staffan.blau@ericsson.com
Holmberg & Blau Expires December 11, 2011 [Page 13]
